#bzr 2007-10-08
<bialix> ok
<jml> Hello #bzr
<lifeless> hello little island
<bialix> luks: fixed and pushed to launchpad
<jml> Has anything changed between 0.90 and 0.91 wrt options passed to SSH? (particularly NoHostAuthenticationToLocalhost)
<lifeless> I don't believe so
<mwhudson> ah
<lifeless> however the port will have changed, because of the bug in spivs patch
<lifeless> from default to 22-if-not-supplied
<mwhudson> jml: https://bugs.edge.launchpad.net/bzr/+bug/146715
<ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Triaged] 
<mwhudson> launchpad.dev:5022 ftw
<luks> bialix, thanks
<bialix> luks, I don't understand how to right-align of push-button
<bialix> there is exists some layot managers in Qt?
<bialix> umm
<Verterok> moin
<lifeless> hola
<Verterok> lifeless: Hi, time for one or two questions?
<Verterok> I was wondering if the LogFormatter approach (like the one in bzrlib.log.LogFormatter) is the correct one for other commands like status, annotate so we can plug different output formats (like xml :) ).
<Verterok> or maybe you (based on a more extensive knowledge of the internals) can give me a hint of an alternative approach?
<lifeless> Verterok: sure
<lifeless> so you want to use a process boundary right ?
<lifeless> I think in that case that having some sort of filter for the output, that is selectable by your plugin code is good
<lifeless> many of these things are already split into data generation/data presentation
<lifeless> e.g. status
<lifeless> status --short kicks in a different formatter
<lifeless> in short - yes, that sounds fine to me, though the LogFormatter interface doesn't strike me as the easiest to use ;)
<Verterok> right, I'm having a few problem with LogFormatter
<Verterok> mostly because I don't have any context of the current revision to be logged only the revision itself
<igc> morning all
<Verterok> I'm stating to write a kind of stack for the log --xml, just to have some extra information about the context
<Verterok> hi
<lifeless> wb igc
<igc> thanks lifeless
<Verterok> also I recently added version, plugins and info command to the xmloutput plguin, and beuno added missing. we talk a bit about doing some kind of refactoring so we can avoid keep copying code from bzrlib and just plug to it.
<Verterok> I just wonder if this kind of changes have any possibility of being accepted.
* Verterok brb
<lifeless> Verterok: of course they do
<spiv> Good morning.
<i386> morning
<i386> how was your weekend spiv?
<spiv> Very pleasant.
* i386 couldnt relax and find "flow"
<i386> thus, feeling pretty haggard this morning
<dfc> hello. i am having some trouble deciding what style of layout i would like for my repo. I think i want the nested-style or nested-tree.
<dfc> i have a few "projects" that I use on all of my machines proj1-4 and a few that I only use on certain machines projA-C
<dfc> is it best to do a init-repo basename ; bzr init basename/projBLAH
<dfc> and only check out the branches that I need on each machine
<dfc> versus just bzr init basename
<dfc> where basename has many subdirs/braches with my proj directories?
<Peng> Well don't do that.
<dfc> what is the status of nestedtree support?
<Peng> I don't know.
<Peng> I *think* it's more or less supported, but not really exposed in the UI.
<s|k> I had to kill a stalled commit and now I have a locked file
<s|k> what are my options
<lifeless> s|k: bzr break-lock
<s|k> thanks
<s|k> my commit keeps stalling
<s|k>  Committing 1383/1386
<s|k> it just stays there
<lifeless> are you commiting a very big file
<lifeless> like an iso or something?
<s|k> I don't think so
<lifeless> is this local or network
<s|k> network
<s|k> remote server
<lifeless> sftp? bzr+ssh ?
<s|k> sftp
<lifeless> is there network activity happening?
<s|k> no
<s|k> it shouldn't take this long
<s|k> the biggest thing in there is dojo
<s|k> it's just text
<lifeless> is there anything in ~/.bzr.log ?
<s|k> hrm
<s|k> I'll check
<s|k> lifeless: has a a bunch of lines with what I added and then added revision_id and then KnitRepository and the final line is "fetch up to rev {..
<s|k> nothing about an error or anything
<s|k> the directory where it's supposed to go on the remote server is empty.
<s|k> and it's still stalled
<s|k> I'm going to set up svn and see if that works, oh well
<lifeless> oh
<lifeless> bye then
<Odd_Bloke> :/
<abentley> Peng: Nested trees are not currently supported.
<Peng> Weren't they supported for a while?
<abentley> No.
<Peng> ....
<Peng> Nested trees != subtrees?
<abentley> Subtrees are part of the implementation of nested trees.
<abentley> But subtrees aren't supported, either.
<beuno> Verterok, hey, just uploaded the spanish doc branch: https://code.launchpad.net/~beuno/bzr/bzr.doc_es
<beuno> I'm pretty sure uploadind the whole bzr branch was on overkill, but I'm lazy toda
<beuno> *today
<Peng> bzr upgrade --dirstate-with-subtree?
<abentley> --dirstate-with-subtree is hidden because it's not supported.
<Peng> What's the definition of "supported" we're using here?
<abentley> It will make Bazaar act weird and fail in interesting new ways.
<Peng> Haha, cool.
<Peng> Okay, then, not supported. :)
<Peng> So there are formats that aren't listed in 'bzr help upgrade'. Where are they listed?
<abentley> Hidden formats are not listed anywhere.
<lifeless> well
<lifeless> in the code
<lifeless> bisection is a lovely way to find interesting cache bugs
<Peng> In the code is what I meant
<Peng> grep register_metadir bzrdir.py
<abentley> Ah.  I thought you were talking about help output.
<Peng> Not really.
<Peng> Help output, code, whatever.
<Peng> I was just wondering what all of the secret hidden formats were. :)
<poolie> good morning
<igc> morning poolie
<poolie> hello igc, welcome back
<poolie> igc, quick call?
<igc> thanks - great to be back
<igc> sure
<dfc> i would like to have a copy of an upstream svn repo in one of my shared repositories. do i use svn-import ?
<Peng> bzr-svn?
<poolie> dfc, either of those would work
<dfc> i am confused about branches/co/pull and bzr-svn
<dfc> i have set up my shared repo according to the reccomendations (i hope) such that they do not have working trees. if I do a bzr svn-import svnrepo mysharedrepo/importedsvnrepo
<dfc> that would result in the importedsvnrepo being just like any other branch inside of my shared repo?
<lifeless> finally, fixed bisection
<lifeless> real lesson in the limits of tdd
<poolie> mm?
<lifeless> theres a theoretical hole with tdd, which is to have something sufficiently complex, and not decomposible, that you get what appears to be rock solid, fully tested, does everything code, that is actually completely broken
<lifeless> I had this
<lifeless> anyhow
<lifeless> I now have bisecting indices that I think are solid
<poolie> iow you test each step you make, but you miss some tests you should have added?
<lifeless> you test each step you make
<lifeless> but the steps combine so rapidly that there are missing interactions
<lifeless> where you can't write small enough steps
<poolie> strangely enough i was just thinking about that this morning
<poolie> spiv, thanks for your promised fix for bug 146715
<ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Triaged]  https://launchpad.net/bugs/146715
<lifeless> blech, another glitch
<lifeless> breakfast first, fix that after
<lifeless> oh, btw, diff is 50% faster with bisection
<spiv> poolie: I've sent it to the list now, it turned out to be essentially very easy (just don't set default_port for bzr+ssh:// or sftp://).
* igc lunch
<Verterok> beuno: ok, branching from it right now. which part of the doc are you translating right now? (to avoid working in the same thing)
<abentley> poolie: Hi.  Your BB feature request: do you have a preference for lines vs kb?
<poolie> abentley, if i was doing it i'd probably go by lines of the final diff
<poolie> disregarding the packed section
<abentley> Okay.
<poolie> if that's easy
<abentley> Hmm.  I'll see.  Sound really start hiding the packed section anyway.
<abentley> s/Sound/Should
<poolie> abentley, my review got error 503
<poolie> maybe just because you were upgrading or tweaking it?
<abentley> Yes, I was just upgrading it.
<poolie> cool
<poolie> spiv, re your patch
<poolie> it looks ok
<poolie> except i don't really see why ssh needs to be treated differently
<poolie> with this in place, does it mean ssh://host/ != ssh://host:22/ ?
<poolie> in a sense i suppose that's right - we don't know that they're the same
<poolie> but maybe that is too pedantic
<lifeless> to me
<lifeless> default ports should be left None all the way down the stack
<lifeless> thats kinda what default menas
<poolie> that's what i was going to say too
<abentley> poolie: did you want this number in the list of merges or for individual requests?
<lifeless> it would be nice when looking at the list to be able to use it as a 'that will be easy to review' hint
<beuno> Verterok, I've marked with TODO_ the ones that need translating, it's the latest, so you can grab pretty much anyone you want
<beuno> I was going to aim for the guide next
<abentley> Yeah, I'm guessing that was what he was looking for.
<abentley> We'll see waht the performance is like.
<Verterok> beuno: ok, I'll help with that, maybe server or plugins. anyway, I let you known when I start working on one of these
<lifeless> abentley: you could cache it
<beuno> Verterok, you rock  :D
<abentley> Yeah.  I've just put it up without caching, and perf seems acceptable.
<Verterok> beuno: this is going to be my first translation...let's see what happen :P
<abentley> Caching would mean changing the DB schema, which I can do if necessary, but I'd rather not.
<poolie> abentley, lifeless, yes, that's what i was wanting it for
<abentley> poolie: It's up now.  You likey?
<poolie> so if calculating the number of lines would be too slow but you can get the blob size direct from the db quickly
<poolie> that would be ok with me
<poolie> wow, sweet
<abentley> Well, it's only hitting 24 bundles, so it seems alright for now.
<abentley> I probably will cache it eventually.
<dfc> i am all sorts of confuyed. i create a repo with no trees in /repo and i created a branch there /repo/project .
<dfc> i then did bzr branch /repo/project ~/localcopy
<dfc> i have committed changes to localcopy but when i try and branch from /repo/project to another computer/directory it says revision 0
<poolie> dfc, you need to push if you want to get them back into the parent branch
<dfc> poolie: push gives me an error
* spiv -> lunch
<dfc> poolie: it says no push location
<poolie> how about if you say
<dfc> it knows where it was branched from.
<poolie> so to back up a bit
<dfc> i guess i expected the push command to publish the changes to its closest ancestor
<poolie> do you want ~/localcopy to be an independent branch, or just a checkout of the branch in your repository?
<dfc> i gues i am struggling with that
<dfc> in that i know i am supposed to understand the difference but i dont
<lifeless> do you want them to be able to have different content
<dfc> not really
<dfc> the problem is one of the machines is a laptop that will not always have access to the parent branch so i do not understand how the checkout will work
<dfc> so if i want them to be the same i do a checkout
<dfc> what if i wanted an independent branch? how would i update the parent every now and then?
<poolie> abentley, so what is the meaning of -r for bzr send now?
<abentley> It controls the patch preview, and it controls how the merge is applied, but it does not control which revisions are included in the bundle.
<poolie> so the merge is done as if you'd typed merge -r XXXX
<ubotu> New bug: #150427 in bzr ""bzr send -r" needs help text" [Undecided,New]  https://launchpad.net/bugs/150427
<abentley> poolie: Right.
<abentley> Or -r X..Y, for that matter.
<ubotu> New bug: #150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [Undecided,New]  https://launchpad.net/bugs/150438
<poolie> is there already a bug about hpss server-side hooks?
<poolie> spiv, can you please answer daniel pittman re hpss hooks, and file an rfe bug if there isn't  one already?
<poolie> hello jamesh
<jamesh> hi poolie
<poolie> reading ll's repo format patch
<poolie> abentley, just what goes on the bb 'mine' page?
<poolie> it's not just patches originated by me...
<lifeless> named commit of a specific file
<lifeless> real    0m17.163s
<lifeless> user    0m15.861s
<lifeless> sys     0m0.744s
<lifeless> thats with bisection, which is now good I think, for the index layer, but the pack wrapper needs a tad more love
<poolie> "
<poolie> Subclasses do not *have* to call the constructor, so this is in fact nor
<poolie> out of date."
<poolie> ??
<poolie> not out of date?
* igc dinnner
<sandrot> what's the difference between base, tree and other when conflicts arise
<sandrot> Hmm, BASE last revision, THIS, working tree, OTHER new merge
<spiv> sandrot: BASE is the most recent common ancestor of the two branches.  So the changes between BASE and THIS are the changes in your branch, and the changes between BASE and OTHER are the changes to be merged with your changes.
<sandrot> spiv: awesome
<sandrot> a quick look at bzr help conflicts and bzr help resolve wasn't very helpful
<sandrot> bzr help THIS or OTHER or BASE don't do much either
<sandrot> think it should be added to the docs?
<spiv> Yeah, it should be explained somewhere.
<spiv> It's familiar to some people from other systems, but we shouldn't assume that everyone knows that.
<sandrot> yeah, after a few diff's I got it and it made sense
<sandrot> but it's f-ing late and at this hour I rely on bulleted docs =)
<sabdfl> hey revisionistas
<sabdfl> lifeless: i saw your landings over the w/e
<sabdfl> is it possible now to do a bzr upgrade to pack format repos?
<Peng> Has he said that people should yet?
<Peng> It is experimental, after all.
<igc> sabdfl: I think packs are still a few days away from being ready in bzr.dev IIUIC
<sabdfl> ok
* igc night all
<baijum> I was going through : http://bazaar-vcs.org/OneZeroDocumentation Do you have plan t release PDF versions of docs ?
<baijum> Creating PDF will not be much difficult, just: rst2latex.py and pdflatex would be enough. I have created such a PDF here for tutorial: http://bazaar-vcs.org/Documentation?action=AttachFile&do=get&target=tutorial.pdf
<baijum> I used a LaTex style available here: http://svn.zope.org/grok/trunk/doc/style.tex?view=markup
<baijum> May be you can also use: http://rst2a.com/api/
<baijum> Hi sabdfl
<baijum> sabdfl: got one minute ?
* baijum is away now
<Ng> can I get bzr to show me a diff between a checked out directory and the parent (remote, http) branch?
* baijum is back
<spiv> Ng: bzr diff -r submit: uses the parent branch if there's no submit branch.
<spiv> Ng: or possibly you want "bzr diff -r ancestor:URL"
<Ng> spiv: ahh, cool, thanks :)
<spiv> Ng: "bzr help revisionspec" summarises the available goodies :)
<Ng> ta
<sabdfl> baijum: sure
<baijum> sabdfl, I was going through : http://bazaar-vcs.org/OneZeroDocumentation Do you have plan to release PDF versions of docs ?
<baijum> Creating PDF will not be much difficult, just: rst2latex.py and pdflatex would be enough. I have created such a PDF here for tutorial: http://bazaar-vcs.org/Documentation?action=AttachFile&do=get&target=tutorial.pdf
<baijum>  I used a LaTex style available here: http://svn.zope.org/grok/trunk/doc/style.tex?view=markup
<baijum>  May be you can also use: http://rst2a.com/api/
* baijum copy pasted this from log (there was no reply)
<spiv> baijum: ISTR plans for a PDF version were mentioned on the list at some stage, perhaps search the list archives?  Or perhaps post to the list about it.
<baijum> spiv: if it is part of agenda for 1.0 release, that's fine.
<spiv> baijum: I'm not sure off the top of my head.
<sabdfl> baijum: looks good, i'm sure mrevell and others would appreciate a patch to spit out the pdf automatically
<baijum> sabdfl: I will try to create a script to automate this
<mrevell> baijum: that sounds good. If you have any other suggestions for the docs, feel free to ping or mail me. I'm working on them for at least the next few weeks.
<mrevell> baijum: Thanks for looking at an automated PDF script!
<baijum> mrevell, it is just two commands, so I wonder I should automate it or not
<sabdfl> thanks baijum
<baijum> np
<baijum> mrevell, I have one more suggestion
<baijum> For each document you can use .. contents:: directive
<baijum> *without* .. sectnum:: directive
<baijum> then
<mrevell> baijum: I think that'd depend on how poolie_ and others wanted to manage the creation of such a PDF as part of the release process. DId you say you'd posted to the bazaar list about this?
<baijum> I am not sure I will get enough time to dig more ...
<mrevell> baijum: I'm looking in the mailing list logs now. It'd be great to get a discussion about this on the bazaar list.
<mrevell> baijum: I can post to the list and quote the discussion here.
<baijum> ok
<baijum> while generating tex source: use --use-latex-toc option
<baijum> this will give you a good table of contents
<baijum> you will be also required run "pdflatex" command two time to get a proper TOC
<baijum> see this: example http://svn.zope.org/grok/trunk/doc/grok2pdf.sh?view=markup
* baijum is Zope 3 guy, and just a user of bzr
<baijum> that's all I wanted to say.
<baijum> and if you want permission to use: zope style for latex, I can arrange that
<baijum> http://svn.zope.org/grok/trunk/doc/style.tex?view=markup
<mrevell> baijum: Ah I see, well thanks for the input. I'll get a discussion going on the bazaar development list as I think it's a great idea.
* mrevell looks at Zope style for latex
<gabe> hi all
<gabe> i have a checkout
<gabe> bzr st shows files removed and   'kind changed' and unknow
<gabe> but these operations were performed from another checkout
<gabe> how do I get this checkout to reflect the new structre? bzr update   doesn't do this :(
<corporate_cookie> I'm having a bit of trouble installing paramiko ..python dose not seam to recognize its out there and thus BZR is saying Unable to import paramiko (required for sftp support): No module named Crypto.Util.randpool
<corporate_cookie> however Crypto.Util.randpool is our there ...I can see it
<vila> corporate_cookie: try
<vila> python
<vila> import paramiko
<vila> what does he say ?
<corporate_cookie> vila ImportError: No module named paramiko
<corporate_cookie> this is the problem
<corporate_cookie> i cant get python to recognize paramiko
<vila> so that's a problem in your installation, if python can't find paramiko, neither can bzr
<vila> what's your os ?
<corporate_cookie> Red Hat Enterprise Server 4
<vila> ouch, python 2.3 ?
<corporate_cookie> python -V shows i'm running python 2.4.4
<corporate_cookie> is there a way to verify python is installed correctly ?
<vila> python -v should show you some interesting paths
<vila> or even better
<vila> python
<vila> import sys; print sys.path
<vila> so that you have the complete list. paramiko must be in one of them to be found
<vila> how did you install it ?
<corporate_cookie> I made an rpm from src
<vila> hmm, can't remember the rpm command that lists the installed files
<corporate_cookie> vila import sys; print sys.path gives me
<corporate_cookie> '', '/usr/local/lib/python24.zip', '/usr/local/lib/python2.4', '/usr/local/lib/python2.4/plat-linux2', '/usr/local/lib/python2.4/lib-tk', '/usr/local/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages'
<corporate_cookie> ...which is missing paramiko
<corporate_cookie> is there a way to edit this path ?
<vila> no, paramiko must be *inside* one of this to be found
<vila> or alternatively you can use PYTHONPATH
<vila> ha, what says rpm -q paramiko -l
<corporate_cookie> vila allas, it tells me package paramiko is not installed
<corporate_cookie> when i do apt-get install paramiko ...it tells me I have the latest version
<vila> err, you said you made an rpm, you didn't install it ?
<corporate_cookie> i made a python rpm ..i installed paramiko through apt (from the DAG repo)
<corporate_cookie> i did install the python2.4 rom
<corporate_cookie> er rpm
<vila> so paramiko should be installed for for python apt-get thinks is the right one, which may not be your python-2.4.4.
<corporate_cookie> ah i see
<vila> s/for for/for which/
<corporate_cookie> vila:  what  dose s/for for/for which/ do ?
<vila> :) substitute "for for" in my previous sentence by "for which"
<vila> a workaround is to create $HOME/lib/python, define a symlink there pointing to where paramiko is installed and add a PYTHONPATH=$HOME/lib/python in your profile
<vila> paramiko seems to be pure python so that should work
<corporate_cookie> vila:  what dose s/for which/for which/ do ?
<corporate_cookie> (pardon my denseness )
<vila> I said: "so paramiko should be installed for for python apt-get thinks is the right one, which may not be your python-2.4.4."
<vila> I wanted to say: "so paramiko should be installed for which python apt-get thinks is the right one, which may not be your python-2.4.4."
<vila> s/for for/for which/ is the sed command to apply to my sentence to fix it, it's just a shortcut to tell people I have made a typo
<corporate_cookie> sweet golly ... i got ya :" )
<corporate_cookie> vila:  I installed paramiko via src  with python2.4 setup install --prefix= /usr/local/lib/python2.4/site-packages/paramiko
<corporate_cookie> paramiko (so far as the readout states) was able to install and byte compile correctly
<corporate_cookie> yet python is still not seeing it ... any ideas ?
<vila> ok, so back to:
<vila> python
<vila> import paramiko
<vila> message crossed on the wire, hold on
<corporate_cookie> ok
<vila> what did setup install said ?
<corporate_cookie> byte-compiling /usr/local/lib/python2.4/ ...
<corporate_cookie> i also get copying build/lib/paramiko/config.py -> /usr/local/lib/python2.4/site-packages/paramiko
<corporate_cookie> ..it copies each lib
<vila> Good.
<vila> ls -l  /usr/local/lib/python2.4/site-packages/paramiko
<corporate_cookie> this shows me all the py and pyc files
<vila> try again:
<vila> python2.4
<vila> import paramiko
<corporate_cookie> yet python2.4 .... import paramiko still yeilds an import error
<vila> import sys; print sys.path
<corporate_cookie> '', '/usr/local/lib/python24.zip', '/usr/local/lib/python2.4', '/usr/local/lib/python2.4/plat-linux2', '/usr/local/lib/python2.4/lib-tk', '/usr/local/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages'
<corporate_cookie> hum
<vila> asme here ;-)
<vila> s/asme/same/
<vila> hold on !
<vila> --prefix= /usr/local/lib/python2.4/site-packages/paramiko is wrong
<vila> should be
<vila> --prefix= /usr/local/lib/python2.4/site-packages/
<vila> ls -l  /usr/local/lib/python2.4/site-packages/paramiko should have shown you paramiko only or you used completion and didn't realize their was two paramiko at the end ?
<corporate_cookie> ls -l  /usr/local/lib/python2.4/site-packages/ shows me bzrlib, lib, and paramiko
<vila> and ls -l  /usr/local/lib/python2.4/site-packages/paramiko ?
<corporate_cookie> ls -l  /usr/local/lib/python2.4/site-packages/paramiko shows me whats in the   /usr/local/lib/python2.4/site-packages/paramiko folder
<corporate_cookie> which are the py's and pyc's
<vila> python
<vila> import bzrlib
<vila> ?
<corporate_cookie> no errors
<vila> print bzrlib.__file__
<corporate_cookie>  usr/local/lib/python2.4/site-packages/bzrlib/__init__.pyc
<vila> hmm, so paramiko is present but refuses to import, should be missing some dependency
<vila> import pycrypto
<vila> http://www.lag.net/paramiko/
<vila> points to
<vila> http://www.amk.ca/python/code/crypto.html
<vila> install pycrypto, rinse, repeat
<corporate_cookie> i have pycrypto
<corporate_cookie> lol : )
<vila> sorry, you lost me there :-)
<vila> import pycrypto raises no errors ?
<vila> you said: "ls -l  /usr/local/lib/python2.4/site-packages/ shows me bzrlib, lib, and paramiko"
<corporate_cookie> ah ha
<corporate_cookie> it dose yeild an error
<corporate_cookie> damn you apt ...it installed pycrypto in python2.3
<vila> :-)
<vila> of course, that's the python *it* knows :)
<fullermd> See, if you were using a BSD system, you wouldn't have these problems   ;)
<vila> fullermd: I was just about to say that :-)
<fullermd> Great minds think alike.
<vila> Your majesty is too good...
* fullermd permits vila to kiss his hand.
* vila remembers he sould prepare the dinner unfortunately so can't kiss fullermd's hand...
<fullermd> Ah well.  Another time, perhaps.
<vila> sure :)
<NfNit|oop> fullermd: How so?  (re: BSD)
<fullermd> Oh, I was mostly just prodding around with a sharp stick.  Mixing package-manager-controller and manual stuff on any system gets you in trouble.
<vila> Words of wisdom :)
<vila> I try to keep $HOME/[bin|lib|rest of the zoo]  as empty as possible :)
<vila> The real fun begins when you need to test some code on several platforms sharing some sources from nfs mounted volumes while using different versions of required libraries
<fullermd> Variant symlinks ftw!
<vila> Additional bonus if the said platforms use different OSes and different processor endianess (too easy otherwise)
<fullermd> At least one of which should be a non-Von Neumann architecture   ;)
<vila> variants symlinks do not work for *source* (think python or perl) :-)
<vila> You make me wonders about installing a *BSD on my old Bebox :-)
<corporate_cookie> vila:  looks like your pycrypto fix worked ..thanks for the help and patience!
<vila> corporate_cookie: you're welcome, happy hacking with bzr :)
<corporate_cookie> thanks : )
<fullermd> Bebox??  Man, I always _thought_ you were nuts...
<vila> hehe, I know there is a BSD port somewhere, but I never had the courage to try it...
* vila 's daughters screaming: "HUNGRY!!!"
<vila> ok, ok, Have to go :)
<ubotu> New bug: #150682 in bzr "must handle IOError exceptions gracefully" [Undecided,New]  https://launchpad.net/bugs/150682
<AnMaster> is there any way I can hide specific changes from bzr missing and prevent them from getting added in a bzr merge without parameters
<AnMaster> like blacklist changesets from getting merged
<AnMaster> would be a very useful feature
<AnMaster> can't find anything like it though
<AnMaster> iirc svnmerge got it so can't see why bzr don't
<bialix> bzr call this cherrypicking
<bialix> but bzr has not full support of cherrypicking
<bialix> because bzr use DAG to manipulate history there is no simple way to juggle with revisions -- otherwise it breaks DAG
<AnMaster> bialix, ah
<AnMaster> sucks
<bialix> hm
<AnMaster> what version control support it
<AnMaster> because I will change from bzr now, it is not an alternative for this project
<bialix> try darcs ten
<bialix> then
<AnMaster> what about git?
<bialix> it's only RCS I know that allows you to juggle with patches
<bialix> git -- is not my kind of tools because I'm working on windows
<AnMaster> well I'm on *BSD and Linux
<bialix> it's your way, that's my way
<erikgz> is there an easy way to do bzr over ssh?
<LeoNerd> Well there's sftp for an easy start, which is an SSH subsystem
<AnMaster> now this is odd. when I use merge with -r argument it no longer shows that as merged...
<AnMaster> so well cherrypicking in bzr is totally missing
<AnMaster> not nice if you try to maintain stable and trunk
<AnMaster> and merge history won't be nice even if/when that feature is added
<AnMaster> ..........
<bialix> record for cherrypicking is missing
<AnMaster> exactly
<AnMaster> when will that get added?
<bialix> may be in 2008
<AnMaster> when in 2008?
<bialix> I don't know
<AnMaster> I see
<bialix> bzr has very long list of features nice to have
<bialix> but main goal for 1.0 release is performance
<bialix> https://blueprints.launchpad.net/bzr/
<bialix> https://blueprints.launchpad.net/bzr/+spec/bzr-cpick-data
<AnMaster> bialix, so for now I will recommend people I know to not use bzr
<AnMaster> thanks for that
<AnMaster> I like bzr but no cherrypicking makes it almost useless
<AnMaster> night
<bialix> someone always will be unhappy
#bzr 2007-10-09
<lifeless> abentley: hi. I would like to still see the branch nickname from the bundle, in BB. is that possible/easy?
<abentley> lifeless: I think so.
<abentley> This would have to be the head revision branch nick.
<lifeless> hmm maybe it wasn't the nick. There was a field in the bundle header I used to read when you showed the bundle
<igc> morning
<tetron> quick Q, is there an easy way in bzr to have it embed the current repository revision to a file?
<tetron> i.e. so an "about" dialog has the current build rev
<fullermd> Not automatically, via keyword expansion.
<fullermd> You can do it manually via sed'ery.  Depending on language, you can use the version-info command to generate a source file containing it.
<tetron> fullermd: great, thanks
<poolfool> Um ... does bzr support any type of keyword expansion (ala CVS)?
<fullermd> Nyet.
<poolfool> Ok ... is that on the roadmap to 1.0 land?
<fullermd> Don't think so...   that path is pretty full of performance and suchlike.  It's post-1.0.
<poolfool> Thanks.
<poolfool> Or what is thanks in Russian?
<fullermd> Urg.  Now you're straining my knowledge of the language   :p
<fullermd> Spasibo?
<abentley> lifeless: perhaps you're thinking of the branch's public location?  that is already shown.
<lifeless> abentley: could be
<lifeless> abentley: hey, got time to chat about merge base?
<abentley> I'm not feeling well.
<lifeless> abentley: oh, thats a shame. Get well soon.
<lifeless> abentley: I feel that we have a regression on merge base selection, and I'd be happy to fix it if we can chat about it at some point.
<poolie> spiv, hi
<spiv> poolie: Hello
<spiv> lifeless: have you looked at my reconcile patch from Friday?
<lifeless> spiv: no I haven't, thanks for reminding me
<lifeless> I will be pairing with poolie much of today
<lifeless> hi poolfool, welcome back :)
<poolie> spiv, i was thinking about the default port number thing
<lifeless> vila: hola
<poolfool> Thanks ... How is life?
<lifeless> vila: what is transportstats?
<lifeless> poolfool: good :)
<poolfool> poolie: Hey, I sent you an email earlier today (chaffinMichael@gmail) about the redhat SPEC file ... hope it helps.
<spiv> poolie: did you come to any conclusions?
<bigdog> I have a question for you guys,  I have some use cases, and am not sure if bzr would work.
<bigdog> I have binary files 100meg-1gb
<lifeless> food time
<lifeless> but yes, bzr will work, ifyou have enough ram
<bigdog> lifeless: happy eating
<beuno> bigdog, I use bzr to keep track of big files, one thing to keep in mind, bzr needs to put everything in memory
<lifeless> we're starting to address teh amount of ram needed.
<beuno> so 1gb file means at least 2gb available  :D
<bigdog> ok, I did not realize the files needed to be in memory, just the history info.
<beuno> lifeless, my gfx guys will be happy to hear they can start wasting space again on 1gb files  :p
<bigdog> beuno: these are 3d modeling files
<beuno> bigdog, right, I get my guys to zip 'em up
<beuno> split them if needed
<beuno> not convenient, but works
<bigdog> guys: thanks for the info
<beuno> bigdog, :D
<lifeless> bigdog: np
<lifeless> spiv: thanks for the trivia
<lifeless> spiv: My pointy haired side wonders if it was really worth looking at the python source to find out though ;)
<fullermd> Wha?  Of course it is.  It's like spending $200 to win a $10 bet; you gotta keep your priorities straight.
<bialix> fullermd: I'm impressed
<fullermd> Hmm?
<bialix> Spasibo is indeed thanks in russian
<fullermd> Oh, good.  My memory still occasionally works   :)
* bialix impressed by talents of fullermd
<poolie> mark used "spasibo" the other day and i was wondering what it meant
<fullermd> Oh, don't be _too_ impressed.  I have a Russian vocabulary of maybe a half dozen words, and I'm useless with the alphabet   :p
<bialix> mark sabdfl?
<bialix> he was in Moscow
<poolie> yes
<poolie> and Zvyozdny Gorodok
* bialix knows a guy who meets Mark
<fullermd> I know only moderately more German, have forgotten much of the French I knew (which was only ever good enough to pidgin-talk my way about at its peak), can count to 6 in Korean and 10 in Spanish...
<bialix> yes, star town
<fullermd> Luckily, I'm American, so nobody expects me to handle anything but English anyway   ;>
<bialix> that's why I'm impressed (a bit)
<lifeless> fullermd: Americans don't speak English though ;)
<fullermd> lifeless: I speak the King's English.  It was good enough for Elvis, it's good enough for me!
<lifeless> fullermd: do you have Blue Suede Shoes ?
<fullermd> They're out in my pink Cadillac.
<lifeless> then I guess you're good enough for the language
<lifeless> :)
<fullermd> I'm glad you think so.  Otherwise, I'd'a had to don a gold lame suit and start hopping around the channel.
<fullermd> And NOBODY wants that...
<lifeless> hmmm
<ubotu> New bug: #150820 in bzr "hashcache is invalidated when a file's containing directory is	renamed" [Wishlist,Confirmed]  https://launchpad.net/bugs/150820
<lifeless> ciaoish, going off net for battery
<i386> lifeless: we should do beer sometime
<lifeless> i386: definately
<vila> lifeless: a transport decorator as a plugin that will be published RSN
<vila> I wanted to play a bit with some ideas in a sandbox
<lifeless> vila: cool; have you seen the trace+ decorator ?
<vila> yup, give me a good laugh :) Looks like we were partly on the same track
<lifeless> heh
<vila> the intents are a bit different though, transportstats collect every transport method call, the analysis being done later
<lifeless> hmm
<vila> well nearly every
<lifeless> like get_transport() ?
<vila> no
<vila> like has, get, get_bytes, put_bytes, etc
<lifeless> so every Transport method call :)
<vila> with some exceptions like put_non_atomic_file that are written in terms of other methods
<lifeless> I'd like to flesh trace+ out
<lifeless> hmm, I don't think they should be exceptions, because a given transport may choose to implement it natively
<vila> the big part was to serialize without being to much a resource hog
<vila> honestly, there are some problems, so far I aimed at something simple so that I can display bytes read bytes written latency etc
<lifeless> sure
<lifeless> sounds nice
<vila> and even for that a simple decorator may not be enough, readv and open_write_stream may need specific implementations to measure latency more correctly or real bytes read too
<vila> but I think the serialization part is mostly good so far, I have to profile a bit to see if a C implementation is needed, but the API is quite cool to use :)
<vila> let say I want to add a new method 'get_half_file(relpath, start, middle)' all I have to do is add: 'register_stat('Transport.get_half_file', TransportGetHalfFile, "%(relpath)us %(start)L %(middle)L")
<vila> and the serialization is taken care of, an TransportGetHalfFile object will be created at deserialization time with attributes (base, relpath, start, middle)
<vila> anyway I shouldn't talk that much before coffee, bbl :)
<lifeless> lol
<igc> time to complete the gutsy upgrade - bbl
<lifeless> may the repo be with you
<lifeless> are you running on the real hardware yet ?
<igc> I am on my server and it upgraded ok last night
<igc> still running on Parallels on my MacBook
<igc> I'll try on the raw hardware in the next week or two hopefully
<lifeless> for a frozen distro the churn rate is humungous
<igc> and sadly, my patch to the help explaining how to use bzr got dropped
<igc> sigh
<lifeless> igc: :(
<ubotu> New bug: #150834 in bzr-pqm "Make STARTTLS and AUTH work better" [Undecided,New]  https://launchpad.net/bugs/150834
<poolie> igc, which patch?
<poolie> lifeless: back now?
<lifeless> yes
<lifeless> meetings over
<poolie> in a bit of searching i cannot find a dirstate bug that is fixed by this
<lifeless> ok
<poolie> which i am a bit surprised by
<lifeless> I would assume it was only erroroneous on the cache side then
<poolie> so now i'm trying to decide whether to
<poolie> 0- just put it up to merge
<poolie> 1- run under kcachegrind
<poolie> 2- think harder about what kind of failure that could cause
<lifeless> I don't think 1 will help
<poolie> i have confirmed that it's not rereading them
<poolie> so, yeah, it seems redundant
<lifeless> I think its passing all tests
<lifeless> so this is fine in terms of our quality metric
<poolie> it would have been nice to have closed off additional bugs
<poolie> ok
<lifeless> it would be nice if you do think of a 'X should break under the old code' to come back to it
<lifeless> but I think we're at diminishing terms
<lifeless> *returns*
<poolie> agree - just one thing - can you look at _cmp_path_by_dirblock_py and confirm for me that
<poolie> the docstring is backwards
<poolie> wrt negative vs positive
<lifeless> do you mean cmp_by_dirs ?
<poolie> both of them
<poolie> they all have similar docstrings and i think they're all wrong
<lifeless> well
<lifeless> only one is exposed
<lifeless> >>> import bzrlib.dirstate
<lifeless> >>> bzrlib.dirstate.cmp_by_dirs
<lifeless> <function cmp_by_dirs_py at 0x2b178b89db90>
<lifeless> >>> bzrlib.dirstate.cmp_by_dirs('foo', 'bar')
<lifeless> 1
<lifeless> >>> bzrlib.dirstate.cmp_by_dirs('bar', 'foo')
<lifeless> -1
<lifeless> I haven't read the code
<bialix> poolie: are you here?
<poolie> hi bialix
<bialix> hi poolie. when next feature freeze planning?
<poolie> i'm leaving it open for a couple more days to try to land pack changes
<poolie> i should send mail about that
<bialix> I'd like to fix bug 129298 for 0.92
<ubotu> Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress]  https://launchpad.net/bugs/129298
<poolie> that would be good
<bialix> I'm thinking about providing standalone installers for some plugins, like bzrtools
<bialix> so this bug is show stopper for me
<bialix> I think I'll send merge request in next couple of days
<poolie> k
<poolie> bialix: maybe there should be just one installer and it should ask you which plugins you want?
<bialix> pollie: it's possible, but I'm slightly worried about size of all-in-one installer
<bialix> even though now I have radiomodem and moderate quality of internet, I'm still remember dial-up days
<poolie> yes, i see
<bialix> bzrtools is pretty small though
<poolie> right
<bialix> QBzr is bigger (+3MB to installer) because it carries Qt libraries
<poolie> if bzr-gtk needed to install the gtk libraries that could make it a lot bigger
<poolie> exactly
<bialix> yeah, that's why I think QBzr is better choice for win32: it's much smaller
<poolie> oh, interesting
<igc> my leaning is toward one installer. Can we see what size it would be first before taking another path?
<bialix> ok, it's doable
<poolie> maybe one big one and one smaller one
<bialix> I'll do sone experimenting tonight and post result tomorrow
<igc> thanks
<bialix> anyway as sane solution, I could provide bare installer (only bzr.exe) and rich installer (with batteries included)
<bialix> but I understand that there is already zoo of installers for win32
<igc> I know it seems a small detail but multiple installers means cross-checking versions match, etc.
<igc> anything we can do to lower the barrier to entry is very valuable I think
<igc> and one installer fits into that camp IMHO
<bialix> IMO, rich installer with plugins is the sane answer to hsn_ who 2 days ago complains about bzr is hard to install on windows
<bialix> but I'm not planning to include bzr-gtk
<bialix> I dislike PyGTK bloat
<igc> sounds like QBzr is shaping up nicely though
<poolie> it does
<poolie> it's kind of a shame to have the duplication
<bialix> well it lacks QOlive, otherwise it's very good
<bialix> it's inevitable
<bialix> Lukas did very nice work with side-by-side diff
<poolie> in Q or G?
<bialix> Q
<bialix> but I'm using bzr-gtk about a year ago, may be they more similar than different
<bialix> now
<bialix> my point about Q vs G is: Q more windows-alike than G
* bialix think that Q is first letter from "cool"
<poolie> spiv: hi, what's new with hpss?
<Peng> What interesting branches are there, for someone useless who just likes reading changelogs?
<poolie> Peng, https://code.launchpad.net/
<Peng> Sure, but there are a lot of them, I don't know what they're all for, and I don't know which ones have been merged into bzr.dev and abandoned.
<bialix> what colors means
<bialix> ?
<bialix> green and blue?
<poolie> one is 'uses bzr natively' and one is 'imported from cvs or svn'
<poolie> Peng, i'm not sure what you're looking for
* Peng shrugs.
<Peng> Interesting changelogs.
<poolie> on bazaar, or something else?
<poolie> hello mwh_
<mwhudson> poolie: hi
<poolie> mwhudson, Peng's question is something i'd like code to answer more
<poolie> 'show me some interesting code'
<poolie> or interesting changes
<Peng> I guess I'm curious what's going on with Bazaar.
<poolie> https://code.edge.launchpad.net/~bzr/bzr/trunk plus http://bundlebuggy.aaronbentley.com/ gives a good picture
<bialix> umm, packs?
<poolie> http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n http://bundlebuggy.aaronbentley.com/?selected=merged
<Peng> What about the hpss stuff?
<poolie> ping spiv
<mwhudson> poolie: there's https://code.edge.launchpad.net/+recently-changed-branches
<vila> lifeless: transportstats pushed on launchpad bazaar.launchpad.net/~v-ladeuil/bzr/transportstats
<ubotu> New bug: #150860 in bzr "Transports should explicitly track whether a port was specified" [Undecided,New]  https://launchpad.net/bugs/150860
<egx0r> I'm using Emacs 23.0.0.x and the bundled vc isn't all that good with bzr. Are you guys aware of any bzr plugins for Emacs or should I just start making my own?
<quicksilver> DVC
<egx0r> quicksilver: Thanks! I'll look into it
<AnMaster> $ bzr branch http://leaves.freeshell.org/envbot emerge-trunk
<AnMaster> bzr: ERROR: http://leaves.freeshell.org/envbot/.bzr/checkout/format is redirected to http://myspace.com/redmartian
<AnMaster> hum
<AnMaster> how do I branch it, I can pull from it but not branch from it
<AnMaster> odd
<AnMaster> there is no checkout of it on server as far as I know
<Peng> It's normal for there not to be checkouts on the server.
<Peng> All that's needed is the ".bzr" directory.
<AnMaster> so why this error?
<AnMaster> and yes the .bzr is there
<AnMaster> ...
<Peng> ...
<Peng> Well, http://leaves.freeshell.org/envbot/.bzr/checkout/format redirects to http://myspace.com/redmartian.
<AnMaster> Peng, yes I wonder why I get this error when trying to pull another developer's branch
<Peng> That would be why you get the error.
<AnMaster> Peng, it seems that server redirect any non-existing file to there
<Peng> That's dumb.
<Peng> Is that branch using some ancient format or something?
<Peng> That file isn't new.
<Peng> Oh.
<Peng> No .bzr/checkout at all. Which makes sense.
* Peng shrugs.
<Peng> I don't know why Bazaar cares about that file.
<Peng> But redirecting 404s to MySpace is the dumbest thing I've ever heard of.
<Peng> </mean>
<AnMaster> Peng, I agree
* AnMaster is complaining to that developer now
<AnMaster>  http://pastebin.ca/730542
<AnMaster> anyone got any idea about that?
<AnMaster> Peng, maybe you?
<Peng> AnMaster: Not sure. Is it a checkout or a branch?
<AnMaster> this is a branch of that repo
<Peng> I know I've heard of this, I just don't remember it.
<Peng> Augh, Barney.
<AnMaster> Repository checkout (format: dirstate-tags)
<AnMaster> Location:
<AnMaster>   repository checkout root: .
<AnMaster>         checkout of branch: http://www.vmlinux.org/jocke/bzr/bzrweb/
<AnMaster>          shared repository: /usr/home/envbot/bzrweb
<Peng> It's a checkout.
<AnMaster> hm what
<AnMaster> odd
<Peng> bzr unbind
<Peng> I think there's a bug filed on that locking error, and it might've been fixed.
<AnMaster> interesting
<AnMaster> is there any plugin or something for cherrypicking, while other version control systems support it, they don't support other features that bzr got (like support for "dumb" static pages only web servers)
<AnMaster> Peng, so I need some combination of mercurial and bzr it seems
<Peng> I have no idea. :P
<mwhudson> mercurial doesn't have any more support for cherrypicking than bazaar does, does it?
<jelmer> don't think so. darcs is the king of cherrypicking
<jelmer> I mean, I don't think mercurial supports cherrypicking mor ethan mercurial
<Peng> Mercurial has the transplant extension.
<Peng> Not sure how well it does it.
<mwhudson> bzr has the rebase plugin, too :)
<AnMaster> is there anything like git bisect for bzr?
<jelmer> AnMaster: there is bzr-bisect
<AnMaster> ah, link?
<jelmer> https://launchpad.net/bzr-bisect
<AnMaster> as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
<jelmer> that's not possible yet as Bazaar does not have per-file properties yet
<jelmer> although I guess it is possible to set revision properties with that information
<AnMaster> jelmer, hm
<AnMaster> easy handling of back/forward merging between stable and development branch and ability to ignore some changesets from list of changes to merge back to stable branch
<AnMaster> that is what I need
<AnMaster> and tracking what changes have been merged back of course
<AnMaster> jelmer, so what distributed version control systems can handle that?
<Zindar> you want partial merges?
<AnMaster> <AnMaster> as for cherrypicking, I need something comparable to svnmerge http://www.orcaware.com/svn/wiki/Svnmerge.py
<Zindar> oki.. darcs is the best at that.. but sucks in many other ways
<Zindar> but .. it's made to do exactly that
<Zindar> bzr isn't... it is planned
<AnMaster> yes so I understood, but bzr got several other nice features
<AnMaster> Zindar, any idea when
<Zindar> it's the one feature I really really want
<Zindar> post 1.0 sometime I would think
<AnMaster> and when will that be?
<AnMaster> this year?
<Peng> AnMaster: Mercurial puts changes in their stable branch then merges them into the development branch.
<Zindar> 1.0 will be I think.. but.. when the cherrypicks will come.. no idea
<Peng> (I mean that's how the Mercurial project handles it.)
<Zindar> peng: hg, git, bzr all can do it...
<AnMaster> Peng, I need to be able to both handle forwardport and backport
<Zindar> but the tracking is less then optimal
<AnMaster> and yes I understood that darcs got many other problems and I would prefer to stay with bzr, but I need this feature quite fast
<Zindar> AnMaster: you CAN handle it in bzr.. but it doesn't track the log, and you'll get the same thing twice when you go back and forward
<Zindar> so.. less then optimal
<AnMaster> indee
<AnMaster> indeed*
<AnMaster> so I'm looking for a usable solution
<AnMaster> as I can't handle it with maybe 200 changes ignored and 50 ones spread out between them that have been merged back
<AnMaster> because it is not merging forward that is most common, merging back is
<luks> do you ever merge the backported branches (complete branch, not just cherry picking) back to the dev branch?
<AnMaster> probably not but could happen
<luks> I don't see the problem with bzr/hg/git-like cherry picking then
<AnMaster> they may diverge, for example if some bug fix that affects backported branch but not dev branch because dev branch have rewritten that entire module or such
<luks> but then you need a new fix, not the cherry-picked one from the dev branch
<AnMaster> indeed
<AnMaster> luks, but a lot of the time changes can be backported by cherry-picking
<luks> so, bzr merge -rbefore:X..X && bzr commit
<AnMaster> that doesn't keep track of what changes I merged back last I tried
<AnMaster> wait, before: ?
<luks> yep, but my point is that you don't need that
<AnMaster> luks, I do when I need to see if I merged back some change or not, and if I decided to not merge it back
<luks> before: is the left-most parent revision
<luks> AnMaster: well, you see the commit message
<AnMaster> because I can't keep track of something like what 50 revisions out of maybe 200 revisions were merged back in my head
<luks> but you still do the merges manually
<luks> cherry-picking tracking is only useful for automatic merges
<luks> (when you merge the whole branch)
<AnMaster> svnmerge is manual (http://www.orcaware.com/svn/wiki/Svnmerge.py), yet I would call it much more useful than your suggestion
<luks> how is it more useful?
<AnMaster> as in "possible to handle with a lot of changes"
* luks still fails to see the problem
<AnMaster> afk
<luks> the cherry picked changes will have different revnos in svn
<luks> so you still can't see which changes were merged
<AnMaster> yes I can, because it is stored in svn properties
<luks> svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch
<AnMaster> read the link I gave
<luks> I know about svnmerge, I
<luks> I've used it a lot
<luks> but then I found out bzr-svn :)
<AnMaster> example:
<AnMaster> svnmerge avail
<AnMaster> 8074,8079-8080,8082-8083,8088-8089,8097-8098,8101-8103,8107,8109-8112,8115-8118,8121-8127,8129-8130
<AnMaster> <luks> svnmerge is only useful if you go the other way around, that is if you decide to merge the branch with cherry-picked stuff back to the dev branch <-- so yes I can see what ones can be merged
<AnMaster> $ python ./svnmerge.py integrated
<AnMaster> 132-7508,7510-7516,7519-7525,7527-7536,7538,7553,7557-7560,7573-7576,7580-7586,7601-7603,7605,7607-7613,7615-7620,7622,7624,7626,7628,7632,7634-7664,7667-7669,7671-7675,7677-7692,7694-7714,7717-7722,7726-7727,7729-7732,7734-7741,7744-7752,7755,7762-7766,7770-7794,7796,7798-7806,7809,7814-7819,7821-7828,7832,7838,7852,7877,7879,7952,7982,7995,8003,8005,8009,8019,8023,8029,8031,8035,8037,8040,8042,8044,8066,
<AnMaster> 8069,8071-8072,8075,8077,8084,8086,8090,8092,8099,8113,8119,8131-8132,8134,8136
<AnMaster> luks, so what do you mean with "<luks> so you still can't see which changes were merged"
<luks> I didn't know about 'svnmerge.py integrated'
<AnMaster> there you are then
<luks> but this approach would really not work well in and DVCS
<luks> any
<AnMaster> indeed
<AnMaster> but really that is an example from inspircd's stable branch. luks could you keep track of that without something like svnmerge avail/integrated? if you could, I'm impressed by your memoru
<AnMaster> memory*
<luks> I prefer to not keep track of things like this myself
<luks> if I have a bug, and I need to backport it, then I backport it
<AnMaster> exactly, so I need bzr to keep track of it for me
<quicksilver> I've never wanted to have cherry-picking on that kind of scale
<quicksilver> maybe I just haven't worked on projects like that
<luks> and forget about it (in my head, not in my VCS)
<luks> in bzr you can have custom per-revision properties
<luks> so theoretically you could write a plugin that remembers which revisions were merges
<AnMaster> luks, no I can't because I don't know python
<luks> the problem is that this info wouldn't be very useful if you have more than one branch
<luks> it works in svn, because you have incremental per-repo revnos
<AnMaster> but I need some way to keep track of cherry picking on this scale and even larger
<luks> or even better you could always associate commits with bug IDs
<luks> and then check for fixed bug IDs, not revisions
<AnMaster> sure but some bugs you discover when coding something else, then you fix it without first opening a bug
<AnMaster> anyway didn't know you could integrate bzr with trac in such a way
<luks> well, not with trac
<luks> but there is 'bzr commit --fixes'
<AnMaster> luks, and I use trac
<AnMaster> and that doesn't work with ci --fixes afaik?
<AnMaster> + what about reopened bugs
<luks> trac would need to be tweaked to understand this data
<luks> but yeah, it wouldn't work for reopened bugs
<AnMaster> indeed
<AnMaster> luks, but why are you so much against cherry-picking?
<AnMaster> I can't see why
<luks> I'm not against cherry-picking at all
<luks> the problem is that in DAG-based systems it's not trivial to implement true cherry-picking, because it breaks the graph
<AnMaster> still it is a feature I need :)
<quicksilver> There is an objection to cherry-picking which is that it is unsound, because revisions potentially depend on all preceding revisions
<hsn_> i need cherry pick as well
<quicksilver> however, if the programmer is prepared to deal with the unsoundness then that's his problem
<AnMaster> quicksilver, maybe, but what would you suggest instead to handle stuff like the example above
<luks> AnMaster: I think you need a list of manually merges changes, not a true cherry-picking
<quicksilver> AnMaster: I would bzr merge in the changes I wanted; or in some cases apply diffs by hand if the commit was not atomic enough
<quicksilver> AnMaster: and I'd make notes of what I was doing in the commit message
<luks> e.g. I use https://code.edge.launchpad.net/~luks/+junk/bzr-pick for semi-automatic cherry-picking
<quicksilver> AnMaster: if the scale of the problem grew larger, I would structure my commit messages in some standard way
<quicksilver> AnMaster: and then write tools to gnerate the right messages and parse the log file
<luks> it would be trivial to add revision properties to remember the origianl revision IDS
<luks> and give you the list later
<luks> but I don't think the list would be useful to you
<AnMaster> luks, something like svnmerge indeed, and I normally merge 1) from other developers stable branch to my stable, and other developers trunk to my trunk. 2) from my trunk to my stable and from my stable to my trunk
<AnMaster> not really from other devlopers trunk to my stable
<AnMaster> luks, "+junk"?
<luks> "+junk" = no product in launchpad
<AnMaster> ah
* AnMaster doesn't use launchpad
<luks> the plugin does nothing else but: bzr merge -r before:X..X && bzr commit
<luks> but it's nice to have it in one step, and don't have to copy&paste commit messages
<quicksilver> AnMaster: mind you, I wasn't actually *objecting* to cherry picking
<quicksilver> AnMaster: I was just letting you know what an objection might be
<AnMaster> hm
<quicksilver> it's not clear that it has a sound semantic model :)
<AnMaster> ok, still it is clear to me that not having some system to handle the problem is unsound for developers
<AnMaster> ;P
<quicksilver> generally speaking, I don't share changesets between branches to that extent
<quicksilver> if they are that close, I merge them
<quicksilver> if they're not close, I don't bother to keep back and forward porting stuff :P
<AnMaster> depends. for inspircd (using svn), it is about 1.1 is stable and there are new maintenance releases of it, while 1.2 (trunk) is rewriting some core parts, still code in many of it's modules is mostly the same
<quicksilver> certainly there are many different ways to organise projects
<quicksilver> and many different ways to use your VCS
<AnMaster> 1.2 changes how it handles nicks for example by changing to using UUIDs for users to track them instead of using nick for it
<AnMaster> and my irc related project that uses bazaar is now about first stable version too, and we would benefit from the same development model, apart from that we also need to be distributed
<zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
<schierbeck> jelmer: hello
<corporate_cookie> Is the default python interpreter usually specified with a symlink ?
<quicksilver> on debian that's certainly typical
<corporate_cookie> thanks quicksilver
<quicksilver> debian (and debian-derived OSes) symlink binaries via /etc/alternatives
<corporate_cookie> this is what i thought ..however i changed the symlink on RHEL4..and the default interpreter did not change
<corporate_cookie> alas : )
<quicksilver> to be honest, default is a fiddly concept
<quicksilver> what actually *matters* is what the #! line says
<quicksilver> if your #! says /usr/bin/python2.3 then it's going to use that
<quicksilver> if #! says /usr/bin/python and /usr/bin/python is a symlink, then that's fine
<zorg_the_false> q. i run kubuntu feisty, any suggestion for a 'good' ui frontend ?
<corporate_cookie> quicksilver: ...alas I'm just a lazy bum who doesn't want to change quite a few #! lines
<zorg_the_false> sudo apt-get install bzr-gtk -> "bzr-gtk: Depends: bzr (< 0.91~) but 0.91-2 is to be installed"
<quicksilver> corporate_cookie: then blat a symlink over whatever the #! is pointing at
<zorg_the_false> but0.91-2 is the one provided by the repository
<quicksilver> corporate_cookie: so if the #! is /usr/bin/python2.3, make that a symlink to what you want
<corporate_cookie> thanks quicksilver
<zorg_the_false> ah ok the repository doesnt contains the last version of bzr-gtk
<zorg_the_false> it is only available from source
<jelmer> schierbeck, hi
<AnMaster> hm launchpad seems quite ubutntu specific, it should really be more distro neutral
<AnMaster> to be any useful
<AnMaster> of course not sure what is the right place to complain about that
<mrevell> jelmer: Hi - can you answer a quick question about lp:
<mrevell> AnMaster: Hi
<mrevell> AnMaster: I work for the Launchpad team
<mrevell> AnMaster: What changes would you like to see to Launchpad to make it more distro neutral?
<AnMaster> mrevell, I'm a FreeBSD user so all the ubutntu stuff in the settings for user account seems a bit offending
<eolo> hi all. I have a dramatic problem with official docs!! Is there a straightforward 'howto' to start a bzr smart server accessed via bzr+ssh?
<AnMaster> like ubuntuwiki, why would I want that
<AnMaster> if you want a wiki, why not a launchpad wiki instead
<Peng> eolo: The only setup needed is bzr in the PATH ..
<AnMaster> why force it to be ubuntu wiki
<AnMaster> "This is your wiki name in the Ubuntu wiki. You cannot remove it because without it you won't be able to login there."
<AnMaster> ...
<AnMaster> I have no plans to login there
<radix> AnMaster: I use Launchpad without doing anything related to Ubuntu at all, and it doesn't get in the way at all
<AnMaster> "Ubuntero:  No (apply now)  "
<AnMaster> what is that btw?
<eolo> Peng: what do you mean, bzr is by default in the path: /usr/bin/bzr
<mrevell> AnMaster: Right, I see. The Ubuntu wiki uses Launchpad to authenticate users. Does it get in your way?
<mrevell> AnMaster: An Ubuntero is someone who has signed the Ubuntu Code of Conduct.
<AnMaster> mrevell, not really I guess but why not make it distro neutral.
<AnMaster> ok so what about <other distro> wiki/code of conduct
<luks> eolo, then it should just work, no need to 'start' anything except your ssh server
<AnMaster> do you support that too?
<AnMaster> :)
<eolo> Peng: The server starts but i cannot connect to it to branch
<eolo> perhaps i'm using wrong addresses
<AnMaster> mrevell, if you did fine, it is this ubuntu fixation that gets irritating for non-ubuntu users
<AnMaster> mrevell, by the way, is the code for launchpad open source?
<mrevell> AnMaster: You can add other wikis to your Launchpad profile. I'll post a message to the launchpad-users list with your comments. Ubuntu has obviously been a major user of Launchpad since the beginning but more and more projects are now using Launchpad. I'll raise your concerns with the LP team.
<Peng> eolo: Well then, it should work.
<eolo> i shouldn't issue the command bzr serve?
<luks> bzr serve is for bzr://
<eolo> and for bzr+ssh?
<mrevell> AnMaster: Launchpad isn't yet open source but I know that our aim is to release it as open source.
<luks> eolo, a ssh server
<AnMaster> mrevell, ah nice. oh and at least it shouldn't list ubuntu wiki at contact details
<AnMaster> or at least be possible to disable that
<AnMaster> can't find where to disable it
<mrevell> AnMaster: I think the wiki is listed under contact details as it's an opportunity to tell more people where to find out more about you.
<AnMaster> mrevell, and the way you do wiki user pages indicate they should be in root namespace of wiki
<luks> mrevell, not if it's wiki.ubuntu.com and the person doesn't use it :)
<AnMaster> some people use mediawiki and such where that is not the case
<mrevell> AnMaster: You mean rather than MediaWiki's User:Name?
<AnMaster> exactly
<AnMaster> then my username is still Name and base url is still http://foo.whatever  but url to user page is not http://foo.whatever/Name
<eolo> so if i have a bzr repo in /home/user/django-projects an a remote host which command should i use to branch from there?
<mrevell> AnMaster: You could type User:YourName in the box, that's no problem.
<mrevell> luks: I think we have a bug about this actually. Let me find it
<AnMaster> mrevell, and really as luks said, that wiki I never visited or plan to visit
<eolo> ?? Should i have initialized the repo in a special way?... sorry about silly question
<luks> eolo, bzr branch bzr+ssh://example.com/home/user/django-projects/project
<AnMaster> mrevell, and another detail, some developers may not be tied to any specific os/distro
<AnMaster> even though FreeBSD is my primary OS
<AnMaster> I also use OpenSolaris and OpenBSD
<AnMaster> and sometimes even linux (Slackware mainly then)
<mrevell> AnMaster: Here's a link to a bug report that deals with your complaint: https://bugs.launchpad.net/launchpad/+bug/29542 Would you mind adding your comments there? I'll still raise your issue with the LP team
<ubotu> Launchpad bug 29542 in launchpad "Launchpad pages have hardcoded references to Ubuntu" [Medium,Confirmed] 
<AnMaster> ubotu? argh this place is infected ;)
<eolo> luks: ERROR: Not a branch: ????
<luks> eolo, do you have a branch there?
<AnMaster> elmo, try sftp too instead of bzr+ssh I guess
<AnMaster> mrevell, is pasting parts of irc log ok? I'm not motivated to write it down once again
<mrevell> AnMaster: So long as it's edited to be specific to the issue, that's fine.
<AnMaster> indeed I will cut out other bits of course
<mrevell> AnMaster: thanks :)
<AnMaster> mrevell, btw you don't need to highlight me on every line, once every now and then works fine
<AnMaster> ;P
<AnMaster> mrevell, for bug tracker, any special stuff needed to make it not mess up newlines
<AnMaster> like {{{ }}} of trac
<AnMaster> or <pre> or whatever of others
* AnMaster mostly use trac, mantis and mediawiki
<mrevell> There isn't a pre-formatted option for the LP bug tracker.
<AnMaster> no preview button I notice
<radix> LP bug comment text is already pre-formatted, it won't mess up your new lines
<AnMaster> ah seems to be pre-formatted anyway good
<radix> (and description text)
<AnMaster> radix, well I see that now, but other systems are not the same
<AnMaster> mrevell, anyway added comment with what I think is relevant
<mrevell> AnMaster: Thanks!
<AnMaster> mrevell, what language is launchpad in?
<mrevell> Python
<AnMaster> would it work with fastcgi or does it depend on a LAMP setup or such?
* AnMaster prefers freebsd + lighttpd + fastcgi + postgresql
<AnMaster> something to note for when you make it open source
<AnMaster> mrevell, :)
<AnMaster> mrevell, hm this "ppa" seems ubuntu specific too
<mrevell> AnMaster: Launchpad is built around a PostgreSQL, modified Zope and Apache setup.
<AnMaster> should be called "uppa" then ;)
<mrevell> as for PPA, yes right now it is Ubuntu specific but it may well be made available for other distros in the future. I think the plan is to complete the beta and get it into production and then to look at what might come next.
<AnMaster> mrevell, so ppa is a server side build system to build for different arches?
* AnMaster ponders unusual languages like D
<AnMaster> C/C++ and a few more sure
<mrevell> PPA is a build system, yes, but also an apt repository hosting service. It supports x86 and AMD64 atm
<mrevell> AnMaster: We should probably take this to #launchpad if we carry on. Don't want to hijack the bzr channel :)
<AnMaster> ah ok didn't know about that channel
<AnMaster> mrevell, just one thing: <ubotu> Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
<AnMaster> huh?
<mrevell> Where did you see that?
<AnMaster> in /msg here on freenode
<AnMaster> I didn't say anything to it in /msg or anything
<AnMaster> so I don't know what it is on about
<AnMaster> mrevell, any idea?
<mrevell> AnMaster: Let me look into that for you
<AnMaster> I did not enter any irc info into my profile, or rather I did, and then removed it directly
<AnMaster> mrevell, so what caused it?
<mrevell> AnMaster: I'm not all that familiar with Ubotu but there's a page that explains more about it at https://wiki.ubuntu.com/UbuntuBots The person that maintains ubotu - seveas - appears to be offline atm
<AnMaster> mrevell, well I can't be bothered to try to find that person, so if you like you said will handle it, fine for me
<AnMaster> :)
<mrevell> I'll see what I can find out for you
<AnMaster> as far as I know I didn't give it any command...
<AnMaster> mrevell, btw, the message was at 17:52:23 (UTC+2)
<mrevell> ok, thanks
<AnMaster> hm
<AnMaster> <AnMaster> ubotu? argh this place is infected ;)
<AnMaster> was at that point
<AnMaster> silly of it to react on that if that is what it did
<LarstiQ> 6/names
<LarstiQ> meh
* fullermd steals one of LarstiQ's 6 names.
<LarstiQ> :)
<acuster> Hey all, how do I cleanup a bzr branch? i.e. bzr branch trunk working, then I want to blow away working?
<mwhudson> rm -rf
<jaavaaguru__> rm -rf working?
<acuster> and the shared repository doesn't mind?
<acuster> how does it clean itself up?
<mwhudson> ah, you can end up with some unreferenced revisions in there
<mwhudson> my general approach to that is to not care
<mwhudson> though i think there's a plugin that can remove them
<acuster> that kind of cruft has a way of coming back to bite me
<acuster> ah, so bzr needs a remove-branch command
<zorg_the_false> q. i use eclipse 3.3 for a c++ code of around 330kline, what is the status of the eclipse plugin ?
<james_w> zorg_the_false: I'm not sure. I think it has basic functionality.
<zorg_the_false> james_w: ok. i dont need big funky. but i do need stability...
<zorg_the_false> aka this is my text editor when i code :)
<zorg_the_false> let me code, dont crash :)
<ubotu> New bug: #151027 in bzr "[bug]  RepoFetcher run between the same location" [Low,Triaged]  https://launchpad.net/bugs/151027
<dennda> hi there
<dennda> i have a problem with pushing my updates
<dennda> http://pastebin.ca/731020
<dennda> any idea why that is
<fullermd> http isn't writable, so you can't push over it.
<dennda> thats https. and if i am not totally mistaken, this worked once
<dennda> anyways: how can I solve this then?
<fullermd> https is just http with bits scrambled  ;p
<james_w> dennda: you need to use sftp://
<fullermd> You want to use bzr+ssh instead (or sftp, but bzr+ssh is better)
<fullermd> The LP page for that branch should tell you the URL via that scheme.
<dennda> bzr +ssh says Permission denied (publickey).
<dennda> err
<dennda> no ssh key
<dennda> that's probably it
* fullermd nods.
<fullermd> LP only does key auth.
<joes2> hi. any sysadmins around for the apache server which hosts the wiki?
<joes2> i'm the sysadmin for apache.org, and would like to help you with your spam problem
<james_w> joes2: great, thanks. I'm not sure who the admins are. There was some discussion on the list about the spam problem recently.
<james_w> I think the admins are canonical's sysadmin tead.
<james_w> s/tead/team/
<Peng> tead: team lead? :)
<joes2> those guys don't hang out here?
<james_w> sometimes, I'm not sure who all the team are, so I can't say for sure.
<james_w> joes2: if you would post to the list I am sure you would get somewhere. I don't think there is anyone who really knows online at the moment.
<joes2> which list?
<james_w> unless you want to wait a couple of hours for lifeless or poolie
<james_w> bazaar@lists.canonical.com at least someone will know who to contact.
<joes2> it's not urgent.  at apache.org i think we've managed to drive the spammer off.
<joes2> i was wondering if the same thing would work for your wiki
<james_w> that's good, it would be great to use your skills. Sorry I can't give you the information that you need right now.
<joes2> are they on .eu time?
<james_w> .au
<joes2> ok. i'll try back later then. thanks for the info
<james_w> thanks.
<baijiutong> does anyone know if it's possible to use bzr-svn to only push to svn repos when you tell it to?
<baijiutong> when i do a 'ci' on a repo that i've cloned from a svn repo, it pushes it to the svn repo
<baijiutong> i'm almost brand new to bazaar, so maybe that's not the right workflow for things.
<james_w> baijiutong: you probably want to run 'bzr unbind'
<baijiutong> okay
<baijiutong> will that allow me to push back to the svn repo, or should i be using branches and merges for that?
<james_w> baijiutong: in future if you use 'bzr branch' instead of 'bzr checkout' then you will get what you want.
<james_w> see 'bzr help checkouts' for some more information on the difference.
<baijiutong> i figured that out playing about just now, sorry :)
<james_w> baijiutong: no problem. I'm glad you are sorted.
<baijiutong> someone's finally got a patch for the python subversion bindings at least proposed to macports
<baijiutong> so this is my first chance to really play around with bzr.. :)
<baijiutong> ahh, and then from that branch, when you want to commit to svn, you push it there
<baijiutong> oh, too bad it does them each as individual commits.. i was hoping to hide stupid mistakes i make on my own from my coworkers :P
<dash> I've got uncommitted changes in my WC. I'd like to make a new branch and commit those changes to that branch, instead of the current one.
<dash> is there an obvious command for doing that?
<dash> or should I branch first, commit, then rename the directories? :)
<fullermd> branch ; merge --uncommitted
<dash> aha.
<dash> i sort of remember that now.
<fullermd> Well, that way works too, and may be easier.
<fullermd> Or even commit, branch the old rev, and rename the dirs.
#bzr 2007-10-10
* Starting logfile irclogs/bzr.log
<poolie> back
<beuno> igc, now that I think of it, was in inapropriate for me to use your slides?   it just occured to me you might not of wanted them out yet
<poolie> spiv, hi?
<spiv> poolie: hello
<spiv> poolie: I'm just replying to your review; it'll be on the list in a moment.
<spiv> poolie: sent.  I'm a bit unclear about what you wanted done to the test_suite generation.
<poolie> ok
<poolie> i guess basically i would rather that test_suite() methods were not using testloaders and so on them selves
<spiv> So you'd like the loader.loadTestsFromModuleNames to be elsewhere?
<poolie> hm
<spiv> And maybe direct calls to scenario_applier.adapt too?
<poolie> am i correct in thinking that the test_check_reconcile tests are meant to be run once per (format, scenario) pair?
<spiv> Right.
<poolie> why can't you do two calls to multiply_xxx
<poolie> one for the reconcile tests, and one for everything else?
<spiv> I can, although that means figuring out what the interface to mulitply_xxx should be :)
<poolie> what is wrong with the current one?
<spiv> It also means leaving a "# test_check_reconcile is intentionally omitted from this list because it is parameterised further down." comment in the main list of modules.
<poolie> ok
<spiv> (that was one of the minor annoyances that lifeless' suggestion avoided)
<spiv> By the current one you mean "adapt_modules"?
<poolie> though, really to me that suggests
<poolie> maybe it's bad to have an exception here to the rule that every test within a subdirectory is run through the same parameters
<spiv> Yeah, that's a good point.
<poolie> i mean multiply_tests_from_modules
<poolie> but since this isn't a different implementation, just a different test, it doesn't seem to need its own directory
<spiv> Well, I'm not sure what you meant the interface for multiply_tests_from_modules to be, precisely.
<poolie> that function already exists in tests/__init__
<spiv> Oh.
* spiv looks
<poolie> i think adding such a comment that test_check_reconcile is special
<spiv> I can certainly use that to at least improve the way I combine the disk format scenarios and the remote scenario.
<poolie> is no worse than the current list with [format_applier]  repeated for each module but that
<poolie> right, you can just pass in the concatenated lists rather than making an applier object
<poolie> then
<spiv> But multiply_tests_from_modules doesn't do the cross product I need for the other part.
<poolie> no, you need to generate the cross product in making your scenario list
<spiv> it multiplies tests by scenarios.
<poolie> for scenario_class in brokenness_scenarios:
<spiv> Right, I need to make a cross product of the scenarios.
<poolie>   for repo in all_repo_scenarios:
<spiv> I can do that too, it just didn't occur to me and I didn't realise that's what you were suggesting :)
<poolie>      scenarios.append(..., )
<spiv> Ok, I understand now :)
<poolie> ok
<poolie> that actually makes it easier to trim out the repositories that don't make sense to test
<spiv> I'm not sure why I didn't know about multiply_tests_from_scenarios sooner.
<poolie> well, it's relatively new and not used everywhere
<spiv> Yeah, rather than generating a bunch of tests that are doomed to skip.
<poolie> i think it's a lot simpler than the lower level code though
<spiv> Yeah, that will be an improvement.
<poolie> i should probably go and update the existing callers to make them use this
<poolie> um
<spiv> (and it deals with my concerns about the coupling of module loading and scenario application in adapt_modules too)
<poolie> i think it might actually be nicer if the applicability of scenarios was described on the class, not in test_suite()
<poolie> so your brokenness tests would just be
<lifeless> mmm
<poolie> class:
<lifeless> I think that couples things still wrongly
<poolie>   repeat_per_scenario = [every_repository, every_brokenness] 
<lifeless> it couples the interface of the scenario with the application
<lifeless> I think that would be a mistake
<poolie> what is 'that'?
<poolie> putting them in the class?
<lifeless> yes
<poolie> i don't understand you
<lifeless> uhm
<lifeless> I'm focused on my refactoring right now
<lifeless> I'll try to express myself better tomorrow or something
<lifeless> k folk, I'm off
<lifeless> poolie: 60% now I think.
* lifeless waves
<raddy> Hello Everybody
<raddy> Is it possible to browse and download latest commits via browser?
<zorg_the_false> raddy: yes there are several web front-end on the website
<zorg_the_false> in the 3rdpartyapps section if i remember correctly
<mwhudson> i'm not sure what downloading a commit involves
<raddy> zorg_the_false: is the web front end needs to be installed in the server or in client?
<mwhudson> but browse, sure
<zorg_the_false> raddy: dunno
<thumper> raddy: what do you mean exactly?
<raddy> thumper: see, i want to download latest code from bzr using project, is it possible via web browser?
<thumper> raddy: and what do you hope your web browser will show you?
<raddy> thumper: the file. or latest changes, kind of websvn
<thumper> ok, and you want to see the latest changes of bzr?
<raddy> thumper: also want to download the specific file
<thumper> raddy: http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes
<zorg_the_false> hehe go look  on the site
<zorg_the_false> you got screenshots and all
<i386> lifeless: ping
<lucasvo> hi
<lucasvo> my bzr doesn't run because of unsupported locales settings
<poolie> hi lucasvo
<poolie> i386, he's left
<poolie> lucasvo, well, you should either set your locale to one that's supported on your machine
<poolie> eg by LANG=C or LANG=en_AU.utf-8 or something
<poolie> or enable that locale
<poolie> on linux, that's often controlled by /etc/localegen.conf or something similar
<lucasvo> poolie: http://pastebin.com/m578c789e
<poolie> are you on ubuntu or debian?
<poolie> sudo dpkg-reconfigure locales?
<lucasvo> poolie: ubuntu dapper
<poolie> what locale do you want to use?
<lucasvo> en_USA
<poolie> i think you mean en_US
<poolie> or rather en_US.utf-8
<poolie> not sure
<lucasvo> yes
<lucasvo> poolie: the dpkg-reconfigure did not work
<poolie> is en_US.utf-8 working in other situations on your machine
<poolie> ?
<i386> poolie: ahh thanks
<lucasvo> poolie: how can I set it?
<poolie> to set the locale for your shell, just do
<poolie> export LANG=en_US.utf-8
<ubotu> New bug: #151208 in bzr "util/configobj should be deleted" [Undecided,New]  https://launchpad.net/bugs/151208
<poolie> to set it for your whole session, which is generally what you want, choose the right thing from the gdm language menu
<smartgpx> Is the author of the mini tutorial online and available, please?
* Starting logfile irclogs/bzr.log
<ubotu> New bug: #151353 in bzr-eclipse "Package renaming fails" [Undecided,New]  https://launchpad.net/bugs/151353
<ubotu> New bug: #151356 in bzr-eclipse "Invalid value in project properties" [Undecided,New]  https://launchpad.net/bugs/151356
<ubotu> New bug: #151357 in bzr-eclipse "Better detection of lack of bzrxml plugin" [Undecided,New]  https://launchpad.net/bugs/151357
<ubotu> New bug: #151371 in bzr-eclipse "bad char at end of log messages" [Undecided,New]  https://launchpad.net/bugs/151371
<jam-laptop> wow, I finally come back to #bzr and nobody is around talking
<jam-laptop> Has the conversation gone away since I left?
<Peng> ubotu's still talking. :)
<Peng> [14:46:28]  <ubotu> Error: I am only a bot, please don't think I'm intelligent :)
<Peng> Huh.
<Peng> I should start saying that to people/
<james_w> jam-laptop: hi. how are you?
<jam-laptop> !ubotu how are you
<ubotu> Sorry, I don't know anything about how are you - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<jam-laptop> ubotu help me
<ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<jam-laptop> ubotu you rock
<ubotu> Sorry, I don't know anything about you rock - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<jam-laptop> james_w: Doing pretty well. Trying hard to get enough sleep :0
<james_w> that must be tough.
<jam-laptop> It can be, depends on the day.
<james_w> it's good to have you back though.
<james_w> the channel has seemed quieter on the user help front, but busier on development during .au time.
<jam-laptop> yeah, it has been good to see Martin doing more work lately.
<jam-laptop> :)
<jam-laptop> He has certainly been active at bug triage.
<james_w> it's not that questions aren't being answered, but it seems we have less easy errors to make.
<james_w> yeah, that's been great to see, the bug list did need some tending.
<fullermd> jam-laptop: Hey dere, welcome back.  How's the family?
<jam-laptop> Pretty good
<fullermd> Eggcelent.
<bialix> !ubotu bzr
<ubotu> bzr is Bazaar-NG, a decentralized revision control system designed to be easy for developers and end users alike. Decentralized revision control systems give people the ability to work over the internet using the bazaar development model.  See http://bazaar-vcs.org/QuickHackingWithBzr for a quickstart guide.
<bialix> !ubotu windows
<ubotu> For help with Microsoft Windows, please visit ##windows or your nearest mental health institute. See http://launchpad.net/distros/ubuntu/+bug/1 http://linux.oneandoneis2.org/LNW.htm and !equivalents
<bialix> nice
<bialix> !ubotu python
<ubotu> Sorry, I don't know anything about python - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<bialix_> jam?
<jam-laptop> bialix_: hi
<bialix_> hi
<bialix_> do you saw new version of Pyrex announce?
<jam-laptop> yeah, seems interesting
<jam-laptop> I'm not really sure how to maintain compatibility
<jam-laptop> For now, I think we just try to avoid __new__
<jam-laptop> And live with the warning
<jam-laptop> (maybe add a comment about why we aren't switching yet)
<jam-laptop> The problem is that we are dependent on the platform to ship the right version of pyrex
<jam-laptop> to go along with bzr
<jam-laptop> so it is better to expect <0.9.6 until 0.9.6 has been out for a while.
<bialix_> plaform -- you mean Ubuntu?
<jam-laptop> or windows
<jam-laptop> or mac
<jam-laptop> or RH
<jam-laptop> or ...
<jam-laptop> Whoever is compiling Bazaar
<bialix_> well, IIUC, the real problems occurs with 0.9.7
<jam-laptop> right
<jam-laptop> Is there an expected time for 0.9.7?
<bialix_> I don't think so
<jam-laptop> We also can ask the packagers to make it depend on <=0.9.6
<bialix_> author of Pyrex (Greg) is very peculiar person, as I can see from Pyrex ML
<bialix_> there is Cython though
<bialix_> but I'm not sure how well they solve windows-compatibilty problems
<dato> don't packagers just compile the .c files shipped in the tarballs?
<bialix_> (and Cython use hg)
<dato> (at least debian and ubuntu do that)
<jam-laptop> Well, at the moment we use __new__ in a couple places, but they could just as easily be done in __init__
<bialix_> may be switch to __init__ will be enough
<jam-laptop> well, it will get us through for now, I think
<bialix_> I forget: what's important difference between new and init in Pyrex?
<jam-laptop> __new__ happens before __init__
<jam-laptop> It gives you a chance to initialize your C structures
<bialix_> aha
<jam-laptop> before the Python object is created, IIRC
<jam-laptop> But we don't really need it
<jam-laptop> I just did a quick "s/__new__/__init__/" and "make; ./bzr selftest test_knit test_dirstate" still works
<jam-laptop> bialix_: do you want to submit a patch to the mailing list?
<jam-laptop> vila: ping
<bialix_> not now
<jam-laptop> k, I'll send something
<bialix_> btw, just looking at cdef class Reader
<bialix_> there is something suspicious
<bialix_> self.text_size = PyString_Size(text)
<bialix_> actually self.text_size is int, but PyString_Size returns ssize_t
<bialix_> it's nitpicking though
<jam-laptop> Except for in Python2.4 when it is still int
<jam-laptop> So I didn't worry about it
<bialix_> I like that Pyrex now handle ssize_t natively
<jam-laptop> Plus it would be PySsize_t
<jam-laptop> or something like that
<jam-laptop> We can <int> cast it if you prefer
<bialix_> yeah, you're right
<jam-laptop> But until 0.9.6 or so PySsize_t wasn't a recognized size
<jam-laptop> sorry, recognized type
<jam-laptop> so we had other issues with it.
<bialix_> vila seems to be AFK
<bialix_> btw, recently there was little discussion wo flame war) in Pyrex ML about VCS for Pyrex
<bialix_> noone argument wons
<jam-laptop> patch sent
<bialix> jam said: "__new__ happens before __init__.It gives you a chance to initialize your C structures" -- from this point changing name from new to cinit is reasonable and straightforward
<mhagger> I'm the cvs2svn maintainer.  I was wondering whether there would be much enthusiasm in this community for a "cvs2bzr" based on our code.
<mhagger> cvs2svn already has a git output module, and I don't think it would be much work to add output to bzr (given a little bit of help from somebody with bzr expertise)
<jam-laptop> bialix: Actually I switched from __new__ to __init__ (not __cinit__) because __cinit__ doesn't work with pyrex <0.9.6
<mhagger> cvs2svn only does one-time conversions (not incremental) but it is very robust and has *a lot* of features.
<jam-laptop> mhagger: there will probably be some interest. I know there are a couple of ways to convert from cvs to bzr (cscvs, cvsps-import, tailor)
<bialix> jam-laptop: right, I just thinking slow about your point
<jam-laptop> But if your CVS parsing is superior
<jam-laptop> then it will certainly get used
<mhagger> [See http://cvs2svn.tigris.org/cvs2svn.html for some details] 
<bialix> yes, yes, yes: I have too much f interest of converting my old cvsnt repo to bzr
<jam-laptop> I personally wrote cvsps-import, which uses 'cvsps' to parse the CVS info and build up changesets
<jam-laptop> But I don't think cvsps is all that great
<jam-laptop> So I would be happy to use a different back end
<mhagger> Yes, I think that cvsps has known problems
<bialix> I rememeber cvs2svn claimed it's not supporting cvsnt. something changed in last 2 years?
<mhagger> jam-laptop: Perhaps you are just the expert I am looking for :-)
<jam-laptop> Though it would be nice if it could be repeated
<jam-laptop> mhagger: most likely :)
<mhagger> No, we still don't support CVSNT
<jam-laptop> I know ddaa and lifeless both have cried some tears of blood trying to work on converting from CVS
<bialix> :-(
<jam-laptop> cscvs actually has some of the most advanced CVS work I've encountered
<mhagger> bialix: Though if you use the --use-cvs option and make sure that the CVSNT binary is used, there might be some hope.
<jam-laptop> in that it even keeps snapshots
<jam-laptop> so when people do manual surgery on CVS
<jam-laptop> it can still  recover
<bialix> cvsnt have really killer feature: pseudo-atomic commits and merge history
<jam-laptop> mhagger: I think bialix is also looking to support some of CVSNT's extended tags
<bialix> mhagger: it's really works for me in the past, thanks
<mhagger> bialix: I don't have anything against CVSNT except for the rather unpleasant very commercial community around it
<bialix> IIUC, the main problem with cvsnt is absense of tech docs
<mhagger> If a CVSNT expert wants to join forces, I doubt that it would be too hard to add CVSNT support to cvs2svn
<mhagger> bialix: Exactly.  And lack of developer time over in cvs2svn-land :-)
<bialix> time is always too little
<mhagger> I've only read a little bit about cscvs
<bialix> I used TortoiseCVS a lot, and it use cvsnt internally
<mhagger> But it looked like it doesn't support branches ?!?
<jam-laptop> mhagger: the biggest problem with cscvs is it isn't very human friendly
<jam-laptop> mhagger: Last I knew, it can support them
<jam-laptop> but it refuses to "guess" where the branch point occured
<jam-laptop> so you have to give it a bit of a nudge
<mhagger> Ah, that's good to know.
<jam-laptop> But yeah, I think that was one of the reasons I didn't use it over cvsps
<mhagger> There are two ambiguities about branch creation in the CVS record: when and whence
<bialix> cvscs is not working in pure windows
<mhagger> Branch creation does not include timestamps
<mhagger> and it is also often ambiguous what is the parent branch of a given branch.
<fullermd> cvsps-import has been a good friend to me...  I like the auto-handling of branches and tags.
<mhagger> cvs2svn has heuristics for both problems, and allows the user to specify a "hints" file to help with the second problem.
<jam-laptop> mhagger: is it possible to store some conversion information, so that if you convert a second time, you can start where you left off?
* bialix nods
<jam-laptop> I know I've found that cvsps isn't terribly deterministic
<mhagger> No, not yet.  I've thought about what it would take to add that feature, but it would be a lot of work
<jam-laptop> I've had small updates cause it to shift things around quite a bit
<jam-laptop> mhagger: well, aren't you using an intermediate DB anyway?
<mhagger> IMHO trying to make the conversion deterministic is not the right route
<jam-laptop> I'm not trying for deterministic
<jam-laptop> just recording what has happend
<jam-laptop> ed
<jam-laptop> so you can continue without having to start all over
<mhagger> Yes
<mhagger> You basically just have to remember the frontier of the last conversion
<jam-laptop> converting 175k revisions is a bit painful
<jam-laptop> (The Mozilla source tree has ~175k revisions across 55k files)
<bialix> our beloved mozilla tree
<mhagger> But the real trick is that CVS allows history to be changed; for example, branches and revisions can be deleted; tags can be moved, etc
<jam-laptop> mhagger: which is, to my understanding, why cscvs keeps state snapshots
<mhagger> I use the mozilla repo for testing cvs2svn.  It converts in about 17 hours on a modest computer
<jam-laptop> so it can say "you deleted X, I can workaround that"
<mhagger> That is converting to SVN.  Converting to git should be much faster
<fullermd> I'd like to see what bzr does to the BSD tree after the inventory gets reworked...
<jam-laptop> fullermd: you're just trying to make me cry, right?
<fullermd> Well, you don't have to do it with tailor this time   ;)
<jam-laptop> (I'm a little curious to, but that is a ways off)
<fullermd> That alone should chop like 95% of the time off.
<jam-laptop> yeah
<jam-laptop> Well, Tailor using raw "cvs" to update the WT
<jam-laptop> means you have an enforced 1s pause for each revision
<bialix> btw, guys, when I gave a talk in Kiev this spring one guy asked me about speed of bzr comparable to baz
<jam-laptop> though when we last tried to convert, bzr was taking 6s+ to work out the inventory
<fullermd> Yah.  Miserable.
<jam-laptop> so it didn't really matter.
<fullermd> Well.  Considering that's a 1s pause for each _file_ in the revision...  it still adds up.
<jam-laptop> bialix: I would say that bzr smokes baz in all ways possible
<bialix> he used baz (or tla) to follow FreeBsd mainstream
<bialix> or something similar
<fullermd> bzr should be a lot faster now though.  That was what, aroudn 0.11 or something?
<bialix> no, it was around 0.15
<jam-laptop> fullermd: yeah, but it shows up as 'sleep' time, and the total %sleep was still pretty low
<bialix> dirstate!
<bialix> windows locking problems!
<bialix> you remember?
<fullermd> bialix: Nono, I mean last time jam-laptop fiddled with the BSD tree conversion.
<jam-laptop> fullermd: I think it was 0.11
<jam-laptop> that sounds about right
<bialix> oh, sorry
<mhagger> I added git output to cvs2svn a couple of months ago, and it only required two files with a total of like 300 lines of code.
<jam-laptop> fullermd: it *might* have even been back with weaves (<0.8)
<jam-laptop> but I don't think I would be that foolish
<fullermd> Oh, I'm pretty sure it wasn't that far back.
<mhagger> Of course that is using the excellent and well-documented git-fast-import tool to actually built the repository
<bialix> fullermd: FreeBSD still uses CVS?
<fullermd> We've still got at least one good dirstate fuggery around.  Get that fixed, then we can try it with the 150k file trees to find more   ;)
<fullermd> bialix: Yah.
<fullermd> See http://wiki.freebsd.org/VersionControl
<bialix> ok, so I remember a question right
<mhagger> So if somebody is interested to help create a bzr backend for cvs2svn, please let me know
<fullermd> I'm just _dying_ to fill in bzr columns there.  But without inventory reworking, it'll say "bzr rocks, it's slow as molasses, and you'll need to buy a 500 gig drive to store the inventory knit"
<bialix> mhagger: you're using some sort of pluggable architecture?
<mhagger> Yes
<mhagger> 90% of the work is deciphering the CVS history, and the results are easily available to the output backend
<mhagger> (It's all Python, by the way)
<bialix> I know
<bialix> I read the sources occasionaly
<bialix> just wonder how hard to add miniml cvsnt tags support
<bialix> minimal^
<mhagger> bialix: Discussion of the details of adding CVSNT support should probably move to #cvs2svn.  We'd be glad to have you over there :-)
<bialix> well, I read man on RCS files, then I looking on my old cvsnt/TortoiseCVS repos, and have some ideas
<bialix> but from first view cvs2svn parsing code seems a bit complicated
<mhagger> How do people get content into bzr?  Is there a documented interface or tool for adding content?
<bialix> jam, please
<jam-laptop> sorry, I was distracted
<mhagger> (I.e., the equivalent of "svnadmin load" or "git-fast-import"?)
<bialix> we have bzrlib, it's written in Python
<bialix> we have very reach API
<jam-laptop> mhagger: generally you use the python api
<mhagger> Is it documented?
<bialix> yes
<jam-laptop> If *I* were doing this work, I would probably just adapt the cvsps-import code
* bialix nods
<mhagger> Sure, that's probably doable.
<bialix> at least it's a good example
<jam-laptop> mhagger: All of the code has docstrings (part of our review process requires them). There is some higher level documentation, though some of it could be better.
<jam-laptop> And you'll find people here to be pretty helpful
<bialix> and jam our expert
<mhagger> I even though about adding a cvsps-compatible output format for cvs2svn so all the other tools could use it right away.
<jam-laptop> mhagger: well, I wouldn't recommend it
<jam-laptop> the cvsps output has some... issues
<mhagger> Yes, that's what I decided :-)
<jam-laptop> Like you can have text comments that look like meta-info
<jam-laptop> I have a parser which generally handles it
#bzr 2007-10-11
<jam-laptop> (it is just state based, and knows that key X follows key Y)
<mhagger> Doesn't it work by parsing rlog output?  Isn't that already ambiguous?
<jam-laptop> mhagger: cvsps works by parsing rlog, I don't know the details on that side
<jam-laptop> (As I work above cvsps, not below it)
<bialix> mhagger: here some basic examples http://bazaar-vcs.org/Integrating_with_Bazaar
<jam-laptop> Though I have some hooks to invoke cvsps with the "correct" arguments.
<jam-laptop> I found the cvsps command line to be pretty ugly
<bialix> and here http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html -- epydoc like docs
<jam-laptop> So if your tree isn't too tricky, you can do "bzr cvsps-import CVSROOT MODULE OUTPUT" and not need to know anything about cvsps (other than have it available)
<mhagger> jam-laptop: Would you be interested in working together on this?  I bet we could have something done in a day or two
<jam-laptop> mhagger: I would be happy to help when I can
<jam-laptop> I work full time on the project
<bialix> mhagger: just another question about cvsnt
<bialix> cvsnt (as I say) have record about merge points
<bialix> AFAIK before 1.5 svn does not record merges
<mhagger> jam-laptop: Do you work for Canonical?
<jam-laptop> mhagger: yes
<bialix> is this concept fit to current cvs2svn?
<mhagger> cvs2svn doesn't try to deduce merge points, because there is no such info in standard CVS
* bialix wonder if name of project one day becomes cvs2any...
<mhagger> What is the form of the mergepoint information?
<bialix> I understand it, hence my question
<bialix> wait
<bialix> something like this: mergepoint1     @1.5.2.1@;
<jam-laptop> mhagger: so if you are interested in poking at it a bit, I'm guessing the only thing that would need to change would be to write a Parser to replace the cvsps Parser
<jam-laptop> As long as the "_PatchSet" objects can contain the information you want to copy over
<mhagger> jam-laptop: By "parser" I assume you mean "the huge amount of code needed to read RCS files and deduce the changesets"
<jam-laptop> cvsps-import uses rcs to directly extract the texts, so it sort of depends on how cvs2svn extracts stuff
<jam-laptop> mhagger: well the Parser takes cvsps Patches and turns them into meta-info plus a list of (file, version) data
<mhagger> Maybe we should move this to #cvs2svn to avoid disturbing the good folks of #bzr?
<jam-laptop> mhagger: but you've already done all the work to do that part of the parsing
<jam-laptop> mhagger: na, this is an open channel
<mhagger> Yes, of course
<jam-laptop> the #bzr policy is to discuss anything even remotely related to #bzr
<jam-laptop> unless the channel is extra busy
<mhagger> Yes, we parse, then put everything in a dependency graph, then remove cycles in the graph, then topologically sort, and the changesets fall out.
<bialix> btw, cvsnt mark changesets with ids: commitid        44441d436f80000;
<mhagger> ...with lots of extra code for working with vendor branches, CVS's spurious commits, etc
<jam-laptop> bbiab
<mhagger> bialix: Does the mergepoint indicate that all changes on the 1.5.2 branch through 1.5.2.1 have been merged into that revision?
<mhagger> ...or only that the single 1.5.2.1 delta has been merged, or what?
<mhagger> bialix: To support CVSNT...
<bialix> because I don't have access to docs -- I can't say for sure
<bialix> but I can do some experiments
<bialix> with TortoiseCVS
<bialix> to see what happens
<mhagger> (1) The RCS parser would have to be enhanced a bit.  Currently it discards the newphrases
<bialix> generally my TortoiseCVS workflow was very close to one we use in bzr
<bialix> i.e. I'm always merge full branch history, not cherrypicking it
<mhagger> (2) I think that CVSNT supports some other file modes (i.e., binary vs. text vs. keyword expansion etc)
<mhagger> Those would have to be supported.
<bialix> 2) -- I think so
<mhagger> (3) The commitid information would have to be used.  I don't think this would be very difficult.
<bialix> 3) at least it could be used as suggestion?
<mhagger> (4) Whatever different strange corner cases, corruption etc that exist in CVSNT repos would have to be dealt with.
<mhagger> Yes, the most trivial thing to do with commitids is to use it as an exclusion criterion: if the commitids are different, then the revisions *cannot* be part of a single commit.
<bialix> what do you mean by corruption?
<mhagger> There are a few forms of CVS repo corruption that we have seen repeatedly.
<bialix> ah, ok
<mhagger> Probably resulting from CVS bugs in some historical version or something
<mhagger> or maybe poor disaster recovery
<mhagger> Presumably CVSNT has similar things
<bialix> may be
<bialix> btw, I don't remember, is cvs2svn supports CVS modules?
<mhagger> Not the modules file.  It is not clear what to do with it.
<mhagger> but cvs2svn supports CVS repositories with multiple projects
<bialix> in bzr we have concept of nested trees, but it still not production ready
<mhagger> each project can be converted independently of the others; for example, branches and tags in different projects can be considered distinct.
<jam-laptop> mhagger: well, that and the fact that most people do manual surgery to rename files, etc
<jam-laptop> And if you do it "correctly" you still have a bunch of cvsadmin work to do
<mhagger> Ouch let's not even talk about that
<mhagger> :-)
<mhagger> Often there is too little left in the history to know what happened, so figuring it out is too much to ask of a conversion tool
<mhagger> Maybe it needs a "mechanical Turk" module :-)
<bialix> mhagger: can you have some sort of description of real CVS format for ,v files?
<mhagger> bialix: man rcsfile is a good start
<bialix> yeah, but this man is a bit short and unclear
<mhagger> Somewhere there is also documentation specific to CVS that describes their file extensions briefly
<bialix> I mean: to understand what is standard CVS words, and what is cvsnt specific claims
<lifeless> lo jam-laptop, welcome back to irc :)
<jam-laptop> hi lifeless, good to be around :0
<mhagger> jam-laptop: I suggest that to get started you send an email to the cvs2svn dev mailing list with references telling us where to find cvsps-import and what modules to look at.
<bialix> (jam was unhappy because there was no one to talk with, so we start to talk with ubotu) :-)
<bialix> lifeless: ^
<mhagger> bialix: I don't know of better RCS file documentation.  Of course one could try to figure it out from the CVS source code.
<lifeless> well
<lifeless> rcs source code :)
<mhagger> I've seen enough of them to understand them pretty well
<mhagger> Well, RCS files as used by CVS.  So you need to know both.
<lifeless> modules is well documented - new repos get a sensible modules
<mhagger> CVS uses its own RCS file parsing machinery, so I guess it is definitive.
<lifeless> its runtime evaluated
<lifeless> IIRC that is.
<lifeless> anyhow, I haven't read all the backlog, would someone like to clue me in on the question quickly :) ?
<mhagger> We're discussing the possibility of adding a bzr backend for cvs2svn
<mhagger> (I'm the cvs2svn maintainer)
<lifeless> the cvs2svn script, last time I looked, was relatively easy to break with 'impossible' (but they happen) timestamp + ,v topological ordering combinations across files
<mhagger> lifeless: Then I guess the last time you looked was before cvs2svn 2.0 :-)
<lifeless> I don't mean this as a criticsm btw
<lifeless> sounds like its improved massively
<mhagger> The new code uses a dependency graph to deduce changesets, and fixed all the known bugs in 1.x
<mhagger> It uses quite a bit more RAM, but otherwise works very well.
<lifeless> does it ever run incrementally, or is it a 1-shot tool ?
<mhagger> I don't know of a CVS repo that it can't handle
<mhagger> 1-shot, unfortunately.
<lifeless> righto
<lifeless> cscvs for all its flaws is incremental
<mhagger> Maybe a deep-pocketed sponsor could encourage an incremental conversion feature ;-)
<lifeless> so it has extra state added to its output to allow incremental operation
<mhagger> What are the pros and cons of cscvs?  I'm not really familiar with it.
<fullermd> I know every time it was tried on the BSD repo, it fell over.  That might have been pre-2.0, though.
<mhagger> FreeBSD works now.
<fullermd> Sweet.
<mhagger> There are some problems with symbols being defined multiple times in a single file.  These have to be resolved manually using a "hints" file.
<fullermd> There's some Scary Shit(tm) hidden in there.  Any conversion that can swallow it deserves biiig kudos.
<mhagger> It is not clear even how a perfect system would deal with corruption like that.
<lifeless> well
<mhagger> (The repeated symbols, I mean)
<lifeless> one is doomed to failure
<lifeless> the question is how close one wants to come to success ;)
<lifeless> anyhow, cscvs, whats different - its geared for incremental runs, which means detecting ,v file moves and the like
<lifeless> added complexity
<lifeless> multiple front end and back ends
<mhagger> There were some FreeBSD guys hanging around a couple of weeks ago (converting to git) and I'm pretty sure they were successful after I added the hints file workaround for their duplicated symbols
<lifeless> its really vcs2vcs these days
<mhagger> What input/output formats does cscvs have?
<mhagger> I'm impressed by incremental conversions.  I've thought about how to add it to cvs2svn and it will be a good chunk of work.
<lifeless> its nasty
<lifeless> don't :)
<mhagger> [At least if your incremental conversions really work robustly!  It's easy to do a "works most of the time" solution.] 
<lifeless> ddaa and mwh know cscvs way better than I do these days
<lifeless> but reads-from svn, cvs
<lifeless> writes to bzr (we use this), tla (but we don't use this - it may be bitrotten now)
<mhagger> Does it read arbitrary svn repos, or only repos that use the stylized trunk/tags/branches structure?
<lifeless> so, cscvs is meant to break loudly if the incremental conversion looks horked, and let you manually correct the state, then resume
<lifeless> oh, thats probably the other big difference
<lifeless> its branch-at-a-time
<lifeless> so any svn repo, you just identify the path to convert
<lifeless> what else is interesting
<mhagger> CVS is also branch-at-a-time?
<lifeless> oh yeah, there is pure python cvs wire protocol implementation in there
<lifeless> yes
<mhagger> Hmmm, that's curious
<lifeless> cscvs was originally written for a vcs which had no concept of free-form branch naming
* mhagger thinks about whether that simplifies conversions significantly
<lifeless> long as you convert the parent branch[es]  first, and provide a way to find them
<mhagger> It sure must reduce the computational resources needed for a conversoin
<lifeless> thats one area could do with improvement actually
<fullermd> Here's a Q: How easy would it be to use some of the properties work planned/done to store up info on file rev sources, so I could "bzr find src/foo.c cvsrev:1.234"?
<lifeless> fullermd: theres a header in the revision already
<lifeless> fullermd: have a look at one of the cvs conversions on launchpad
<mhagger> OK it's bedtime in Berlin...
<mhagger> Let me just repeat my offer:
<mhagger> If somebody with bzr experience is willing to join forces, I'd be happy to work on a bzr backend for cvs2svn.
<lifeless> well
<lifeless> I'm happy to answer any questions and sketch out the right bits of the bzrlib api to use
<mhagger> It shouldn't be more than a couple of days work
<lifeless> we should have everything you might want already present
<bialix> if it's possible to have some progress with merge points, I can help
<fullermd> lifeless: Know one of them offhand?
<lifeless> drop me a mail if you like, describing what the backend ends - 'robert at canonical'
<mhagger> I mostly don't have time to find everything and learn all of the bzr concepts
<lifeless> fullermd: no
<lifeless> and I'll come back to you with a brain dump and such
<mhagger> OK, thanks lifeless
<mhagger> I'll try to get to it in the next couple of days.
<mhagger> If you are interested, meanwhile look at cvs2svn source files cvs2svn_lib/git_output_option.py and git_repository_recorder.py
<lifeless> I am swamped :(
<mhagger> I guess what you need will be pretty obvious by analogy
<lifeless> I'm racing against the next release clock to get my performance impoved repository merged
<mhagger> Goodnight, thanks for the interesting conversation!
<bialix> night
<lifeless> night
<lifeless> I think I have one bug left in this bisection work
<lifeless> and it will be done
<jelmer> hmm,     'InventoryDirectory' object has no attribute 'snapshot'
<lifeless> right
<lifeless> commit builder has that logic now
<lifeless> faster, more tightly coupled to the repository so different repos can do different things
<poolie> hi
<lifeless> morning
<lifeless> I think I am going to factor out a ParsedRegions class
<lifeless> once I fix this bug
<poolie> good morning
<poolie> i'm feeling much better today
<poolie> i made some progress on commit
<lifeless> cool
<lifeless> I'm a tad seedy
<poolie> i suspect a bug in how update_base_.... interacts with the inventory cache
<lifeless> and horms wedding party is tonight
<lifeless> poolie: what sort of bug?
<poolie> something like the inventory and dirstate being out of sync
<poolie> it's just a gut feeling so i don't want to debate if it's likely or not
<poolie> i'm just going to see if the same test fails on other wt formats
<lifeless> fair enough
<poolie> what i see in particular is that
<poolie> an apparently correct delta is passed in,
<poolie> but when the test looks at the inventory later, some files have not been removed
<lifeless> so its looking at the inventory of the parent?
<lifeless> or the inventory of the tree?
<poolie> the test is looking at the wt inventory iirc
<lifeless> that would be a bug
<poolie> yes, apparently
<lifeless> in the test - because the update_...delta() method is meant to update the parent tree
<poolie> anyhow, that was what i suspected last night
<poolie> oh,
<poolie> interesting
<poolie> of course
<poolie> but really we seem to need something that both updates the parent tree and also the wt
<lifeless> (you can see the method being tested in bzrlib.tests.workingtree_implementations.test_parents)
<lifeless> why do we need to update both? updates to the current tree can be done directly in dirstate representation
<lifeless> poolie: unless there is a performance problem, it seems cleaner to me to do the wt changes and the basis tree changes separately; and theres no performance problem I see doing it separately
<poolie> hang on
<lifeless> okydoky
<poolie> i think you're right, i was expecting it to update both of them the same way
<poolie> which is not quite sensible
<poolie> um
<poolie> i agree you can probably do it efficiently with two separate calls
<lifeless> the wt changes are uncommon
<lifeless> whereas the parent changes always
<poolie> right, only for autoremove and similar things
<m0rra> umm. hasn't the documentation been updated for a long time or what..? instead of bzr in the documentation, i need to use baz. also it shows the latest version is 0.91, but i have 1.4.2 and all the commands are different.?
<lifeless> m0rra: 'baz' is a very old tool
<lifeless> m0rra: I think you have the wrong software package installed somehow
<lifeless> m0rra: if you are on ubuntu/debian install 'bzr'.
<poolie> we should fix that package naming
<poolie> there is a bug for it
<poolie> bazaar->baz
<m0rra> ah, i see. i apt-get installed bazaar...
<poolie> ok, i see the problem
<lifeless> food time for roberts
<lifeless> Do you want a morning sync; I have plenty to do without syncing
<poolie> me too, i'm just going to persist with this
<poolie> only question would be, do you want me to declare a freeze, declare a slip, do nothing?
<igc> morning
<jml> why is build_tree in TestCaseInTempDir and not TestCaseWithMemoryTransport?
<poolie> hi jml, igc
<jml> poolie: hello
<poolie> jml, i can't see a good reason why
<igc> hi poolie
<poolie> withMemoryTransport is robert's invention, he may be able to help when he gets back
<jml> thanks.
<lifeless> uhm
<lifeless> those raisins are hysterical
<jam-laptop> lifeless: doesn't 'build_tree' build on disk
<poolie> hi jam-laptop
<lifeless> disk or transport
<jam-laptop> And "WithMemoryTransport" doesn't have a disk location?
<lifeless> can do either
<lifeless> MemoryTransport still has local disk, because of the bug where we write config files
<lifeless> when you do anything
<lifeless> and also because posix makes it hard to chdir /nonexisting/path :)
<lifeless> poolie: release wise - your call, I'm fine however you play it
<jelmer> lifeless: Btw, any news on my pqm patches - or should I wait until after 0.92 before asking you about those again?
<lifeless> jelmer: yah, wait a bit
<lifeless> very single-track right now
<lifeless> hmm
<lifeless> someone has disputed the neutrality of the bzr wiki page
<lifeless> simply because it doesn't list cons
<tetron> cons?
<bialix> pros and cons
<bialix> bzr has only pros
<spiv> bialix: I wish :)
<spiv> bialix: then I'd have no work to do ;)
<keir> hmm, if i bzr push to a bzr+ssh server that doesn't exist, it shouldn't bail with a 20 item traceback, should it? it sais ssh: projects.launchpad.net not found; then a huge traceback follows
<bialix> no, we work on new features, to increase amount of pros ;-)
<bialix> no should not
<keir> lifeless, which wiki page?
<bialix> there is bug report about this
<bialix> !ubotu fas
<ubotu> Sorry, I don't know anything about fas - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<bialix> stupid ubotu
<bialix> !ubotu traceback
<ubotu> Sorry, I don't know anything about traceback - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<bialix> never mind
<spiv> keir: no, it shouldn't, I think there's a bug open about that.
<spiv> Oh, as bialix said :)
<bialix> keir: it's also traceback when your connection suddenly dropped and some more unpleasant things
<keir> that's not very nice
<bialix> indeed
<bialix> jam-laptop: ping?
<i386> hey lifeless
<i386> I managed to crawl into work
<lifeless> lol
<lifeless> I was working at the usual time :)
<lifeless> keir: wikipedia's 'Bazaar_(vcs)' page
<i386> lifeless: I think I may go home
<lifeless> lol
<i386> apparently Jaq didnt turn up for work this morning
<lifeless> ahha
<adhoc> hi guys...
<adhoc> can i use bzr with an authenticated web proxy ?
<lifeless> vila will really know
<lifeless> but I think you can yes
<jam-laptop> spiv: ping
<spiv> jam-laptop: pong, although I want to get some lunch in a minute
<jam-laptop> spiv: k, I just wondered if you had any ideas about trying to track down memory leaks in python
<jam-laptop> and what the gc.set_debug() flags really mean.
<jam-laptop> Feel free to respond to my email
<jam-laptop> (I'm worried I'm setting a refcount incorrectly, and wondering if gc.collect() can tell me about that sort of problem)
<jam-laptop> It sounds like it can, but I'm not positive what everything means
<lifeless> hi jam-laptop long call ?
<jam-laptop> about 1 hr
<jam-laptop> just dealing with other stuff
<spiv> jam-laptop: I'm not very familiar with the precise meanings of the various gc.DEBUG_* flags.
<spiv> jam-laptop: although if you're worried about refcounts, perhaps sys.getrefcount or gc.get_referrers may help you test hypotheses.
<jam-laptop> well reading http://www.python.org/doc/current/lib/module-gc.html
* igc food
<jam-laptop> DEBUG_UNCOLLECTABLE
<jam-laptop> seemed relevant
<spiv> (I'm not sure, but I'm guessing that Pyrex would tend to generate objects that play nicely with get_referrers)
<jam-laptop> typing is slow with a baby in one arm Z)
<spiv> Right, everything I know about those flags I learned from that page :)
<spiv> Well, I guess I could spend some quality time with Modules/gcmodule.c ;)
<jam-laptop> don't worry about it too much
<lifeless> spiv: so is your reconcile patch landed?
<lifeless> WOOT
<lifeless> lunchies
<lifeless> so who is dogfooding
<lifeless> packs that is
<lifeless> mwhudson: ping
<fullermd> bzr.dev is edgy enough for me...
<lifeless>     def all_revision_ids(self, transaction):
<lifeless>         """See RevisionStore.all_revision_ids()."""
<lifeless>         rev_file = self.get_revision_file(transaction)
<lifeless>         return rev_file.get_ancestry(rev_file.versions())
<lifeless> thats a WTF moment right there
<poolie_> Subject:  	Should we baptized "in the name of the Father, Son, and Holy Spirit" or "in Jesus' name"?
<poolie_> now that is offtopic
<poolie_> "either, as long as it is a utf-8 name"
<fullermd> Sounds like a difficult debate.  We should compromise and do it in my name instead.
<lifeless> wow
<lifeless> I just managed to trip a md5 has collision on pull
<poolie_> really?
<lifeless> yeah, packs with the same data have the same content :)
<lifeless> so the question is why I'm copying this data at all
<lifeless> igc: poolie_: jam-laptop: partial-index-using packs pushed to my usual 'repository' branch
<poolie_> (reading ian's paper)
<lifeless> ah, I think I know
<lifeless> see if this scans
<lifeless> do a commit, adds a revision that triggers autopack
<lifeless> something causes a failure right there
<lifeless> mm more detail
<lifeless> we autopack
<lifeless> add the new pack and its indices
<lifeless> then start removing the obsoleted packs
<lifeless> which is where it breaks
<lifeless> the result is that we have a set of packs, which when packed generate the same pack again
<lifeless> and that new pack is already present
<lifeless> if this theory is right
<lifeless> doing a manual pack will let me pull bzr.dev
<lifeless> because it doesn't aim for the log distribution
<igc> thanks lifeless
<lifeless> spiv: what did you think of my python bug ? :)
<lifeless> yup, doing a pack let it work
<lifeless> wow, performance jump :)
<spiv> lifeless: cute
<lifeless> spiv: is your reconcile patch ok'd ? and merging ?
<lifeless> poolie_: igc: spiv: requesting a review of the index bisection patch.
<lifeless> This is the last patch needed to send in a patch adding packs.
<poolie_> hm, how big is it?
<poolie_> big
<poolie_> ok
* poolie_ rolls up his underscore sleeves
<lifeless>  NEWS                              |   10
<lifeless>  bzrlib/bisect_multi.py            |   64 ++++
<lifeless>  bzrlib/index.py                   |  504 ++++++++++++++++++++++++++++++++++++--
<lifeless>  bzrlib/tests/__init__.py          |    1
<lifeless>  bzrlib/tests/test_bisect_multi.py |  344 +++++++++++++++++++++++++
<lifeless>  bzrlib/tests/test_index.py        |  290 +++++++++++++++++++++
<lifeless>  bzrlib/tests/test_knit.py         |   12
<lifeless>  7 files changed, 1198 insertions(+), 27 deletions(-)
<keir> sweet, we have patch markers now?
<poolie> mm?
<poolie> i imagine he ran diffstat by hand
<poolie> it would be nice if send did it though
<keir> oh, i didn't know that command existed
<lifeless> keir: 'bzr send -o- | diffstat'
<lifeless> also there is a diffstat plugin
<lifeless> but I haven't used it so can't comment
* fullermd still misses CVSish +/- in log   :|
<lifeless> keir: my repository branch now does the naive bisection robustly
<keir> lifeless, niiice!
<poolie> fullermd, i can't remember what that is
<lifeless> keir: looks like there is *tonnes* of room for improvement on this though, with the design we've been batting around
<keir> lifeless, yeah, i like the differential encoding of the hash table
<poolie> i'll read that patch then take a break i think
<keir> lifeless, it's a nice little trick
<fullermd> revision 1.7
<fullermd> date: 2006/01/21 01:17:04;  author: mfuller;  state: Exp;  lines: +29 -7
<lifeless> yup
<lifeless> I think that + topological grouping on the first graph, is going to be quite a huge win
<keir> lifeless, i agree totally
<fullermd> Easier on my eye than diffstat for a quick glance at magnitude.  Maybe that's just familiarity, but...
<lifeless> fullermd: per-file
<keir> fullermd, i def. prefer diffstat
<keir> i'd even like to get diffstat by default on commit and such, but i'm crazy
<poolie> lifeless, is it possible at all for lookup_keys_via_location to be split up?
<poolie> or _parse_region for that matter
<keir> lifeless, on a slightly different note, i've been trying to figure out what i don't like about the bzr dev docs
<lifeless> fullermd: also, you know about diffstat's format parameter ?
<lifeless> keir: I think the diffstat plugin may do that
<fullermd> I s'pose once I dig into writing commit mailings on bzr, I'll end up having to get my brain on diffstat, since it exists and a straight +/- doesn't.
<lifeless> keir: if it doesn't, you can definately do a post-commit hook plugin to do it
<keir> lifeless, and it's that there isn't a clear description of the underlying data structures but absenting implementation details
<keir> lifeless, in a self-contained and digestible form
<fullermd> lifeless: I've looked through the manpage; didn't see anything that would give me that sort of output...
<lifeless> poolie: _parse_region is about 10 lines, are you looking at the updated patch ?
<poolie> i'm looking at the current one in BB
<keir> lifeless, i've done all this thinking about how to do nicer indicies and whatnot, and really, i still don't understand how _everything_ is structured
<poolie> http://bundlebuggy.aaronbentley.com/request/%3C1191820213.8537.0.camel@lifeless-64%3E
<lifeless> poolie: thats the old one
<poolie> thump bb on the side :)
<lifeless> actually list sluggishniss
<lifeless> its not in my mailq
<poolie> ok, i'll check again soon
<poolie> am going to get fresh air first
<lifeless> kk
<poolie> if that's ok
<lifeless>  /wave
<lifeless> fullermd: so there is a -f option
<lifeless> fullermd: but none match your desire. However.. the good news is its open source
<lifeless> :) :) :) :) :)
<lifeless> also, we have a pure python version in the diffstat plugin I believe, that would be easy to do cvs style summaries
<lifeless> keir: I think thats a good point; and one we're incrementally achieving with the doc/developers/ text files
<keir> lifeless, but (apologies for being blunt) the dev docs are _all over the place_
<lifeless> keir: if you've read the doc/developer/repository.txt file from the pack branch
<keir> the HACKING file is very good
<keir> but the other stuff is... a bit of overload for starting out
<lifeless> blunt is fine :)
<poolie> keir, you could usefully point out 'doc/developer/something is crack'
<lifeless> or
<poolie> to provoke people to clear up or remove it
<lifeless> 'where do I go to get XXX' ?
<keir> heh
<lifeless> which will either get better references made
<lifeless> or a bug saying we're missing that
<keir> what i want is a 1 or 2 page summary of the data structures i need to reason about in bzr
<keir> and their relations
<keir> for example. in repositories.txt, i expect to see a description of what repositories _are_ before going into the requirements of their commands!
<keir> what data is in it?
<keir> what are the types?
<keir> their relations?
<lifeless> hmm
<lifeless> I think there are two separate things here
<keir> everything in that file should go in repository_scaling_considerations.txt
<lifeless> one is the interface
<lifeless> the other is the implementation
<keir> right
<lifeless> much of what you are asking is implementation specific
<keir> i don't think so
<lifeless> and is/should be accessible by 'pydoc bzrlib.repofmt.pack_repo'
<keir> fundamentally, bzr stores a bunch of DAG's with data tied to the edges / nodes
<lifeless> well
<lifeless> the bzr-svn repo fmt does not store the same dags at all
<keir> sure, bzrlib exposes an API for manipulating and accessing that format
<keir> whaaa?
<lifeless> heh
<lifeless> meltdown ? :)
<keir> this is what i mean
<fullermd> Run!  Run while you still can!
<keir> what i like about git and mercurial, is that i can easily understand the structure
<lifeless> bzr-svn is expected to meet the same interface
<keir> so reading and understanding the code is a snap
<lifeless> and we should document the interface in the manner you are talking about
<lifeless> I agree we have a problem here
<keir> i keep going back to mercurial's dev page: http://www.selenic.com/mercurial/wiki/index.cgi/Design
<keir> honestly, my lack of understanding this stuff has made me less inclined to believe bzr is fundamentally better than the competition
<keir> i really do agree with linus on 'get your data structures right; code comes and goes'
<keir> and if bzr doesn't have it's data structures straight and documented... it's a bit scary
<keir> i'm sure it's all sensible, but it's a big black box from the outside
<keir> i've even read lots of the docs and hacked the code!
<lifeless> I think that data structures come and go to
<lifeless> *too*
<lifeless> there is a higher cost in changing your mind
<keir> yes
<spiv> That doesn't mean we shouldn't document them clearly, though :)
<lifeless> but only a god can predict what the data structure needs to be at the start of a project
<lifeless> right
<keir> i agree
<keir> but nevertheless, perhaps the lack of documenting data structures and a bigger focus on api is what helped hg become 'preferred' in some sense, because it is much faster at network and most other stuff?
<lifeless> so anyhow, we have varying degrees of quality here, on different things written at different times
* keir is ranting a bit :P
<lifeless> uhm
<keir> please take everything i'm saying with a grain of salt
<lifeless> I think being faster at network and disk is much more noticable to users :)
<keir> exactly
<lifeless> note that you simply cannot do most things with hg over the wire
<lifeless> wire level its push/pull only
<keir> but regardless, hg seems to have hit the sweet spot
<lifeless> well it hit a sweet spot, for some things
<lifeless> they have made compromises I consider unacceptable
<lifeless> like the 'fail to notice sub-stat-size-preserving granularity changes'
<lifeless> bug
<keir> ok
<lifeless> and the renames are always heuristics
<keir> anyway, i didn't want to start a hg debate
<lifeless> and these things have come about, IMNSHO, because they put performance first and everything else has been assessed against that from day one
<keir> mainly i want good docs on just what is stored in .bzr
<keir> at the level of abstraction exposed by the api
<keir> in form that lets me reason about how it might be represented on disk
<keir> i understand both what git is storing and how it's storing it
<keir> and i spent faaar less time with git!
<fullermd> It's just that in git you can't figure out the commands to do stuff with it   ;)
<lifeless> so
<keir> fullermd, yes. i am not saying git is better in usability.
<lifeless> http://bazaar-vcs.org/Classes/
<lifeless> this is pre-the-recent-doc-layout-change
<lifeless> before we were putting all docs into the tree
<lifeless> but I was working towards basically what i think you want in that wiki-space
<lifeless> its most definately not enough, but if its in the right direction, please say so
<keir> i want gratuitius pictures with arrows :)
<keir> i might even make them
<keir> if i knew what to draw
* keir reads
<keir> on the WorkingTree page
<keir> the part 'basis inventory'
<keir> is _exactly_ what i'm looking for but in much more detail
<lifeless> bbiab, need to walk in circles and think about locking
<lifeless> back
<keir> the 'pending merges' should be 'an ordered list of secondary parents (aka, [revid] *) to give the next commit.
<keir> (also on Classes/WorkingTree)
<keir> maybe i'm crazy, but i want less english and more syntax :P
<keir> so the revision history for a file is a sub-graph of the revision graph, correct?
<lifeless> the nodes are a subset
<keir> ok
<lifeless> and the edges follow the same reachablility rules
<lifeless> that is if A is reachable from C in a per-file graph
<lifeless> then A is reachable from C in the revision graph
<keir> now, is that an implementation by-product? i'd vote to describe that
<lifeless> so the file graph is C:[A] 
<lifeless> but the rev graph is
<lifeless> C:[B] , B:[A] 
<lifeless> this is a model, its part of the interface
<keir> ok
<lifeless> how you store/if you store is implementation
<keir> yes, of course
<keir> great
<lifeless> theres a proof of this I sent to the mailing list a few weeks back FWIW
<keir> seen this: http://eagain.net/articles/git-for-computer-scientists/ ?
<lifeless> no browser handy sorrry
<keir> vt100 got you down?
<keir> :P
<lifeless> no, the mozilla tree doe
<lifeless> s
<lifeless> 550MB of source
<keir> oh wow
<lifeless> its what I profile with
<lifeless> smaller trees are too quick, not enough granularity from the profiler
<lifeless> :)
<fullermd> You probably have.  It's the usual "there are blobs, and there are things that point at blobs, and things that point at things that point at blobs, and..." git exposiiton.
<lifeless> righto
<lifeless> 'I have a database thanks bye'
<keir> gitkthxbye!
<lifeless> poolie: patch has hit the list now; evo was retarted on me
<lilr0bbie> hello
<lifeless> what does everyone think about replacing 'knitrepo.py' with 'knits.py' and 'weaverepo.py' with 'weaves.py'
<lifeless> spiv: oh, and ping, can we chat on the phone about lock tokens and packs ?
<lilr0bbie> umm.. i was wondering if anyone could help me with problems using bzr on an ntfs fuse-mounted system?
<lifeless> fullermd: this ones for you
<spiv> lifeless: sure, just a sec
<fullermd> Eek.
<keir> what does a revision have in it
<fullermd> lilr0bbie: Attribute changes?
<keir> a list of parents; a list of chaged files (as fileid's? what's a fileid?)
<lilr0bbie> fullermd: thats the one
<lifeless> keir: parents, properties, commit message
<lilr0bbie> fullermd: i have searched for solutions using google but none unfortunately
<fullermd> Oh good.  I identified the problem, now somebody else can handle the solution side   :)
<lilr0bbie> fullermd: argh lol... i am fearing atm that there is none...
<spiv> lifeless: I'm probably about +0 on that file renaming, fwiw.
<fullermd> I'm not sure there is one, actually.  If all the files in the branch have the same (all +x or all -x), you might be able to change mount options to make it work right...
<lilr0bbie> fullermd: I will try that...
<fullermd> Another option would be to use the branch part of that branch (the VCS data), but use a working tree somewhere else and not touch the NTFS-mounted WT.
<keir> lifeless, http://bazaar-vcs.org/DataStructures
<keir> is the revision ID included in the revision also? as in the sequential numberings
<fullermd> revno you mean (not revid).  I don't think that's "included" anyway, just derived whenever; it's not consistent for the rev, so...
<keir> ok
<keir> so how are the changed files in a particular revision modeled?
<keir> if a revision only has parents, properties, and a commit message
* keir drops a pin
<lifeless> you do a diff between inventorie
<lifeless> inventories
<lifeless> for a revision id X, there is an inventory X
<lifeless> the 'changes in X' really is code for 'the delta from X.parents[0]  to X'
<keir> aah
<keir> so what's in an inventory?
<keir> snapshots of file contents?
<keir> *ducks*
<lifeless> inventories map paths to fileid:content_version
<lifeless> e.g. /foo -> 'foo_id':revisionid
<lifeless> also they hold some inline things like the execute bit, symlink targets
<lilr0bbie> fullermd: i found a way to make it work.  I need to force the ntfs drive to mount with full permissions (i.e., fmask=0,dmask=0) in order to allow this to work, then it seems to "ignore" the fact that it can't set the permissions properly
<lifeless> 'foo_id':revisionid there, is the key used in the .tix indices to retrieve texts
<keir> fileid:content_version is like (fileid, revid)
<lifeless> yes, I'm just changing syntax to confuse you
<keir> lifeless, http://bazaar-vcs.org/DataStructures
<keir> you can see where i'm going
<lifeless> no browser ?
<lifeless> lol
<keir> so the inventory split is exposed at the API level?
<keir> lynx is sufficient
<keir> links rather
<lifeless> what do you mean 'split' ?
<keir> inventory / revision
<lifeless> yes
<keir> i have to run :( i'll come back and chat about this later
<lifeless> revision objects are git commit objects
<keir> but i want to fill out this document
<lifeless> inventory objects are hg manifests
<lifeless> roughly
<lifeless> hmm
<lifeless> do we have a handy three-way-diff-of-arbitrary-sequences?
<lifeless> 3merge I mean
<poolie> keir, can you please turn that wiki page into a doc patch at some point?
<mwhudson> lifeless: pong?
<fullermd> Great, look what you did...
<mwhudson> tee hee!
<smartgpx> Good morning. Is it appropriate to seek help with a 'broken' branch here?
<quicksilver> definitely
<quicksilver> although I'm not the person who can help you :(
<smartgpx> Running bzr v091 on winXP. I have a simple 'personal branch' [bzr-versioned working tree]  that cannot be copied/cloned with the 'bzr branch' command. Fails with bzr: ERROR: Unable to delete transform temporary directory.
<smartgpx> The destination working tree is not populated. There are 4 files in limbo, but far more than this in the source tree.
<quicksilver> hmm
<quicksilver> have you always used it on winXP?
<quicksilver> or was it ever on another OS ?
<fullermd> I think that's come up before.  Case-related, maybe?  Dig around the list archives (I don't know anything beyond a vague memory of it being discussed before)
<quicksilver> yeah, that's what I was probing at with other OSes
<quicksilver> if you have two files identical other than case, OSX and XP will get very confused
<quicksilver> (we have lots of OSX machines runnin bzr here)
<smartgpx> The branch has only resided on one machine. OS has been Win XP throughout. Branch +working tree was originally developed during 4Q06 using bzr at about v0.10.
<smartgpx> Recently moved bzr to v091 and I think I was prompted to upgrade the branch? Might that have introduced a problem?
<quicksilver> can you clone old versions?
<quicksilver> bzr branch -rXYZ foo new-foo
<quicksilver> try for a few different revisions, from very old to quite recent
<smartgpx> '
<smartgpx> "bzr branch -rXYZ foo new-foo"  Interesting tip - I'll give it a try next time I'm at that machine.  Thanks for now. DJ
<metze> hi *
<metze> how can I disable the process bar on bzr 0.8.2?
<Peng> There were progress bars in 0.8.2? I would've thought they were newer.
<vila> jam-laptop: pong (finally)
<smartgpx> FAO: quicksilver Re: 'broken' branch. I think you were right about it being a case-differentiation problem.
<jam-laptop> morning vila
<vila> jam-laptop: morning ! How are you and how goes the family ?
<jam-laptop> all in all, things are going well
<smartgpx> The first commit after the last one that will unpack correctly  has this - amongst other changes:
<jam-laptop> we aren't completely exhausted all the time :)
<jam-laptop> I had a quick question for you on the new ConfigObj
<vila> hehe, I know that :)
<vila> seen the new bug ?
<jam-laptop> I believe I'm seeing it have cycles (and thus not get properly garbage collected)
<jam-laptop> vila: bug 151208?
<ubotu> Launchpad bug 151208 in bzr "util/configobj should be deleted" [Undecided,New]  https://launchpad.net/bugs/151208
<smartgpx> "  removed: ReadFile.FEC  - added:   ReadFile.fec"
<jam-laptop> I was just wondering if the new version did anything about that. (I'm guessing not)
<vila> yes, still want a more detailed summary ? I can re-read the web page, but I think if you want more details than "it passes the test suite" you can... wait... you're searching a bug fix for your gc pr isn't it ?
* vila still can't read while typing ;-)
<vila> I doubt it does, but I can double-check, but if you can reproduce your pb, just download the latests version and install it it's only one file, no zip no nothing
<vila> seems the quickest and best check to me
<smartgpx> If that really is the cause of the problem (which new readers might like to know is "bzr: ERROR: Unable to delete transform temporary directory ..../.bzr/checkout/limbo. - then is there a way to unravel the problem retrospectively?
<jam-laptop> k
<jam-laptop> I figured a quick check with you would be good :)
<jam-laptop> I doubt it is the overall problem
<jam-laptop> just something I encountered
<vila> jam-laptop: just re-read http://www.voidspace.org.uk/python/configobj.html#version-4-4-0 until version 4.2.0, nothing catches the eye
<jam-laptop> np
<smartgpx> The only other instance of "Unable to delete transform temporary directory" in the Launchpad buglist is 137681. This is also a bzr v0.91 report. Might this be a new issue at v.091?
<JWK> hello all
<JWK> I was wondering....where can I find some sort of tutorial on bzrlib internals?
<bialix> you mean: how to use bzr from python? or how to hacking bzr in python?
<JWK> use bzr from python, to embed repository fetch/update/commit/branch features in my app
<bialix> http://bazaar-vcs.org/Integrating_with_Bazaar
<bialix> it's a little tutorial you want
<bialix> then probably try to read bzrlib/builtins.py source code: it contains implementation for almost all commands
<JWK> erm...I'd rather not use a working tree, but modify the repository directly
<JWK> that doc reports: "Manipulating the Repository Directly => TBD (by someone else who knows what their doing)"
<JWK> :-)
<bialix> you cannot commit without working tree
<bialix> but you can create new revisions
<bialix> for fetch/update/branch -- you need to use branch API
<JWK> hmm
<bialix> good example of branch/repo manipulations is probably repo-push plugin
<bialix> (may be and not so good and slightly outdated, but it works for me)
<bialix> repository in the end is just big storage
<JWK> can I use branch api without a working tree?
<bialix> repository without branch is a but useless thing
<bialix> JWK: yes, you can
<bialix> because bzr have idea of treless branches
<bialix> has^
<bialix> treeless branch -- branch w/o working tree
<JWK> ok...so repository and branch modules should do
<bialix> yes
<JWK> If I need to add a new revision to a repository, I don't neew a wt either, right?
<bialix> I'm not sure about commit though, but I think some plugin (e.g. conversion from CVS to bzr) is use direct commit of revisions in repo without creating real wt
<bialix> if we think about commit as 2-step process: gather changes in tree, and then commit it
<JWK> thanks...that's the kind of hint I was looking for :-)
<bialix> then yes -- second step should not be heavily rely on wt
<bialix> actually bzrlib/commit.py
<bialix> contains logic to create new revisions
<JWK> it appears that the core part is actually called CommitBuilder and is provided by repository.py itself
<jam-laptop> bialix, JWK: You might be able to use CommitBuilder directly, but I'm pretty sure bzrlib/commit.py is fairly committed to using something on disk.
<jam-laptop> Though maybe that is just through the Inventory layer...
<jam-laptop> cvsps-import goes a different route... but wait
<jam-laptop> it does use CommitBuilder, IIRC
<jam-laptop> igc: ping
<jam-laptop> Are you still awake?
<bialix> /me still awake
<bialix> /me ?
<jam-laptop> bialix: I never did respond to your ping yesterday, is there still something you need a response one?
<jam-laptop> (on)
<jam-laptop> I was wondering if igc was around
<bialix> I understand
<bialix> I'm working on fixing bug 129298
<ubotu> Launchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress]  https://launchpad.net/bugs/129298
<bialix> my new code is bzr.exe-specific
<bialix> have no Idea how to test it. and whether I should test it
<tetron> why is bzr branching so damn slow?  even with the smart server, it takes orders of magnitude longer to checkout a branch with only one (!) revision than it does to download a tarball
<keir> tetron, we know, it's being fixed
<keir> tetron, the problem is the current repository format requires two roundtrips per file
<tetron> that's gross
<keir> hopefully 0.92 will have packs (like git packs)
<keir> tetron, i know, i was shocked when i learned that too.
<jam-laptop> bialix: you are trying to create a 'plugins' directory somewhere on disk after the installer finishes?
<tetron> I thought the whole point of the smart server is it asks for "everything from version X to version Y" and the server bundles it all up into one big compressed chunk and sends it all at once..
<keir> packs are 50% of rsync speed or sometimes better
<tetron> that would be nice
<jam-laptop> bialix: I would tend to focus on testing the functions you are using do what you want them to, and not worry too much about it happening after the installer runs
<keir> tetron, sadly no. i actually wrote a plugin to do that aaages ago
<tetron> keir: I've had to go through various contortious involving cron jobs that create tarballs to get around bzr checkout slowness
<keir> tetron, have you tried the newer versions? it's gotten faster lately.
<tetron> crap, I'm still using 0.18
<tetron> I thought I had upgraded on this box
<keir> network stuff is still slow though :(
<tetron> well, it's frustrating, I've been using bzr for a year and performance improvements have always been "right around the corner"
<tetron> and maybe other stuff has gotten faster, but the checkout speeds are just embarassing, and that's probably driving a lot of people away from bzr
<keir> tetron, i completely agree
<keir> tetron, i came to bzr because of usability, launchpad integration, and the commitment to testing
<tetron> actually, I know for a fact that it's driving people away from bzr, I know one project that switched away from CVS a couple months ago and they went with Hg on the basis of performance
<keir> yeah
<tetron> although Hg is a pain in the butt to use in other ways that bzr isn't
<tetron> which is why I prefer bzr
<keir> i still put bzr being baked at 1 year
<keir> packs will help tons
<tetron> yes
<tetron> it sounds like it
<bialix> jam-laptop: actually creating a directory without support inside bzrlib is worth nothing
<bialix> so I modify default plugins path for bzr.exe
<jam-laptop> well, moreso than packs will be getting spiv's streaming work merged into 0.92
<jam-laptop> Getting it *right* is actually pretty difficult
<jam-laptop> bialix: well, that is why I say somewhere on disk
<keir> streaming?
<jam-laptop> since "inside bzrlib" means that it will be inside the zip file
<jam-laptop> keir: the basic "give me everything for these revisions/everything in the ancestry of this one"
<jam-laptop> The problem is making sure that you properly get everything
<jam-laptop> associated with the fact that when you do "bzr branch" we ignore unreferenced revisions
<jam-laptop> And handling shared repositories
<jam-laptop> standalone branches
<jam-laptop> etc
<keir> yes
<jam-laptop> Anyway, I think Andrew has actually done all the work to get there
<jam-laptop> and I thought we wanted to land it this week
<jam-laptop> But I know he got caught up in some specific details
<keir> jam-laptop, do you have a sec to help me get the rest of the data structures into this doc: http://bazaar-vcs.org/DataStructures
<jam-laptop> where we were recording 2 things slightly differently
<bialix> jam-laptop: sorry for my english, but you misunderstand me
<keir> jam-laptop, i'm trying to make a doc which is 'the data model as exposed by the bzr api'
<jam-laptop> keir: how much do you want the "logic" versus what the disk is?
<keir> jam-laptop, i want the data model
<jam-laptop> Or I guess what the current api is
<keir> jam-laptop, but implementation is relevant
<keir> i don't care about the api at all really
<keir> the api is just a way to access / manipulate things in some model of the data in .bzr
<keir> what is that model?
<keir> it's not clearly and concisely described anywhere
<keir> hg and git both have very nice docs on this
<keir> and bzr not having this has been a barrier for me on contributing
<bialix> the main idea of that bug is not to have directory 'plugins' somewhere on disk, but IMO have proper support of installing and loading plugins from there
<bialix> so I change a bit plugins.py: get_default_plugin_path() should return 2 directory for bzr.exe instead of one
<jam-laptop> keir: care to point me to one of those references so that I have a better idea of what you are thinking
<jam-laptop> bialix: you *could* look at "sys.frozen"
<keir> jam-laptop, git for computer scientists
<jam-laptop> and then have a test
<keir> http://eagain.net/articles/git-for-computer-scientists/
<jam-laptop> such that if X is True, I get paths A and B
<jam-laptop> if X is false, I get just path A
<jam-laptop> And then the normal caller will use 'sys.frozen' as X
<bialix> jam-laptop: I'm indeed look at sys.frozen. I tried to ask you opinion whether I should write a test for this complicated bzr.exe-only stuff
<keir> for hg: http://www.selenic.com/mercurial/wiki/index.cgi/Design
<bialix> jam-laptop: I'm feeling unhappy to write 20-100 lines test for 2-lines change
<jam-laptop> bialix: I understand, but as a maintainer it means you don't have to worry about me breaking it in the future
<jam-laptop> I don't think it has to be a huge amount of testing
<keir> jam-laptop, i want to start with a very concise overview of the data model (which should be detailed enough that I could write a SQL schema for it), then have a couple examples of real dat
<jam-laptop> keir: do you mind if I write up an overview in ReST on that same page, and then ask you to fill it in?
<keir> jam-laptop, not at all
<jam-laptop> if it is in ReST, then we will likely pull it into the core docs
<keir> jam-laptop, i plan on making it ReST anyway
<jam-laptop> rather than in Wiki
<keir> jam-laptop, and putting it in core docs
<bialix> jam-laptop: actually about this special test: it's never will be run on PQM, so I can't use it for automatic regression testing, otherwise I need very complicated fixture for test, and selftest anyway does not pass on win32 -- and this makes me unhappy about testing
<keir> jam-laptop, i wanted to show people what i was working on
<bialix> keir: you could use ReST in our wiki
<keir> bialix, oh, news to me!
<jam-laptop> bialix: you can write a test that function "get_plugin_paths(is_frozen)" returns different values when 'is_frozen' is true versus fals
<jam-laptop> false
<keir> jam-laptop, just add the rough content, i'll deal with making it nice and expanding
<bialix> just add at the start of document line #! format rst
<jam-laptop> keir: you start with a "#FORMAT rst"
<jam-laptop> but I'll do that
<keir> jam-laptop, should we bother with the wiki? i'd rather put it in core docs
<keir> jam-laptop, and link prominently to it in HACKING
<jam-laptop> keir: well, it is easier to collaborate between you and I on the Wiki
<keir> jam-laptop, sure
<jam-laptop> and then when we get it worked out
<jam-laptop> move it
<keir> jam-laptop, great
<bialix> keir, err sorry, jam is right
<bialix> here example: http://bazaar-vcs.org/Talks?action=raw
<bialix> /me brain damaged by shebang
<keir> tetron, what parts of hg do you dislike?
<tetron> keir: the thing that annoys me the most is when doing a merge and there are conflicts, hg insists on popping up a merge window for every conflict, in order, with no way to go back or forward or just tell it to shut up and mark the files as conflicted like every other reasonable VCS
<keir> tetron, oh, that would be annoying
<bialix> keir: iiuc it play very terrible when you're on windows, because hg need some diff3/merge3 program
<tetron> yup, it's obnoxious like that
<tetron> it has a concept of multiple "heads" in a branch, which is usually just used for merging but it's possible to have them be named and distinct, which can cause chaos if somehow you branch off from someone and change the name, and then try to merge back later
<tetron> the hg logs are flat, they don't show branch merges as distinct changesets the way bzr does
<keir> is there a way to specify what bzr to run when doing bzr+ssh? the default path bzr+ssh uses gets the wrong one on my machine
<jam-laptop> keir: try looking at it
<jam-laptop> I don't have a lot more time right now, but it should give you a start
<bialix> jam-laptop: thanks for suggestion. I think it's time to a some refactoring in plugins.py
<jam-laptop> keir: The env var BZR_REMOTE_PATH
<keir> jam-laptop, aah, cool.
<keir> jam-laptop, but it's different for every host...
<jam-laptop> keir: I think Aaron has a patch pending to allow you to set it in ~/.bazaar/locations.conf
<jam-laptop> I'm not sure if that has been merged or not
<jam-laptop> bbiab
<bialix> keir, keir, Aaron's path is already merged
<bialix> patch^
<keir> jam-laptop, this is going in a different direction than what i want. i literally want a bulleted-list style description such that i could go and write a SQL schema
<keir> jam-laptop, i'll hack on it
<keir> hi aaron
<keir> did your patch to allow setting BZR_REMOTE_PATH per-host in locations.conf get merged?
<keir> abentley, nevermind bialix answered but i missed his response.
<keir> in an InventoryEntry, what type is a 'parent_id'?
<keir> is it a Revision ID?
<keir> or a (fileid, revisionid) tuple? (aka another inventoryentry)
<luks> file_id
<keir> and 'name' is just filename relative to the inventory root?
<luks> to the parent
<keir> what is the type of 'parent'?
<luks> ehm, parent is the parent id, no?
<luks> which is a fileid
<keir> ok
<keir> so why is name even necessary?
<luks> to construct the full path
<keir> so this 'name' entry is there for the strong renaming support?
<luks> e.g. (1, 'foo', 0), (2, 'bar', 1) -> 'foo/bzr'
<keir> and generally the 'name' field will be exactly the same 'myfile.txt' for ever rev, if it's not renamed?
<luks> yes, but fileid is used in all internal operations
<luks> if you rename a file, it will still have the same inventory entry
<keir> yes
<keir> ok
<luks> heh, I just noticed I typed 'foo/bzr' instead of 'foo/bar' above :)
<keir> :)
<keir> in your above example you had (fileid, name, parent_file_id), right?
<luks> yes
<keir> ok. and in this case, parent is strictly relating to _directories_ and not revision history?
<luks> yes
<keir> damn. calling it parent_id is madly confusing
<luks> well, calling it parent_id is very usual in databases
<keir> because in revisions the 'parents' are relating to revisions
<luks> to make a tree in flat DB
<keir> right
<keir> the SHA1 hash is a hash of the fulltext of that particular fileid,rev?
<keir> or is it a hash of the delta?
<luks> of the fulltext
<luks> but generally, inventory can't know much about deltas
<keir> interesting
<keir> what is in Revision.parent_sha1s
<keir> obviously they are sha1's, but it's not clear what the 'sha1' of a parent is
<keir> is it a sha1 of the textual representation of the parent revision?
<luks> not sure about that
<jam-laptop> keir: I'm pretty sure that is unused at the moment
<keir> jam-laptop, yes, i just noticed that
<jam-laptop> At 1 point references were (revision_id, sha1) tuples
<jam-laptop> But that was a long time ags
<jam-laptop> ago
<keir> jam-laptop, refresh that page and see revision and inventory section
<keir> jam-laptop, i am specifically not wanting paragraph-style descriptions because it is harder to digest
<keir> so if you do bzr diff -r1:2
<keir> how is the inventory used?
<keir> is the inventory linerally scanned to find (fileid,revid) tuples with the rigth fileid?
<luks> it takes the inventory for r1 and r2 and checks the differences
<luks> then it takes fulltexts for r1 and r2 or each modified file, and prints the diff
<keir> so this is fast if it's sorted on revid
<luks> keir: there is only one revision of a file in inventory
<luks> so there is no need to find fileid,revid tuples
<keir> i'm confused then
<luks> inventory is a versioned file
<keir> so there's one inventory per file?
<luks> no
<luks> one per repository
<keir> if an inventory is a big list of (fileid,revid,metadata)
<luks> but the content changes for every revision
<keir> then for one rev, there will be many fileid's
<keir> so if you sort by rev, you get all your relevant fileids in one spot
<luks> it's more a dict fileid->metadata
<keir> so you can go fileid-> complete revgraph for that file
<keir> ?
<luks> inventory is a snapshot of the tree at given revision
<luks> there is always only one version of each entry in it (the most recent version)
<keir> wait. so there's only one inventory per revision?
<luks> not sure what do you mean by 'per revision'
<keir> if i do a commit, is there a new, standalone inventory generated
<luks> yes
<keir> and there is an inventory per-file?
<keir> sorry
<keir> a new inventory file per rev?
<luks> it's not really a file
<luks> the inventory knit contains all the inventories
<keir> so a repository has many inventories?
<luks> you confuse me :)
<keir> bzr confuses me!
<luks> think of it like of a regular file in your branch
<keir> ok
<luks> if you commit, bzr will generate a new snapshow of inventory and store it in the inventory knit file
<keir> so there's a 1-1 mapping revision to inventory
<luks> so there is only one inventory knit per repository
<luks> but the knit contains also historical inventories
<luks> keir: basically yes
<keir> ok
<keir> i was confused about that
<keir> what i didn't understand is why bother storing the revision for each fileid in an inventory
<keir> shouldn't an inventory have a _single_ revision ID and then every file inside has an implied revision id from the inventory?
<keir> the description i've been hearing is that an inventory is a list of (fileid, revid, metadata)
<keir> repeated per file changed in this revision
<luks> you usually modify only some files in a commit
<keir> sure
<keir> ooh
<keir> i see
<luks> so most of the inventory entries wont even change
<keir> so all that delta info gets duped?
<keir> per rev?
<keir> if it isn't changed?
<keir> i.e. the (fileid, revid, metadata) in an inventory for rev 10 where that file wasn't changed since rev 5, will contain the same (fileid,revid,metadata) as in rev 5?
<luks> yes
<luks> but this all is stored in a knit, so the data are not duplicated on the disk
<keir> why bother listing unchanged files?
<keir> ah, ok
<keir> so a revision isn't really a snapshot of a tree
<keir> an inventory is
<luks> I think inventory is a 'snapshot of a tree' by definition
<jam-laptop> keir: It might help to realize that we *logically* think of things in "fulltext" form. We happen to store a lot of them as deltas
<jam-laptop> but that is handled at a lower level
<jam-laptop> (It depends on the Repository format)
<keir> ok
<jam-laptop> We will probably undergo another change in the near future
<jam-laptop> to break an inventory into many separate files on disk
<jam-laptop> for performance reasons
<jam-laptop> but you can still think of it as logically one big manifest
<keir> i thought the inventories were going to get packed?
<luks> packs are just masked knits :)
<jam-laptop> "packed" just means storing in a single delta-compressed file
<jam-laptop> logically we still work in terms of a group
<jam-laptop> And when they are in packs
<jam-laptop> it just means they are in several distinct chunks inside the pack
<jam-laptop> rather than one big hunk
<keir> so right now 1) a single file has multiple inventories 2) the inventories are not spatially coherent?
<jam-laptop> keir: yes, we are moving to storing all the data for one or more revisions in one big file (a pack)
<jam-laptop> keir: I'm not sure what you mean by "single file". But right now:
<jam-laptop> Every revision has a unique Inventory
<jam-laptop> The revision maps the exact text for every file in the tree
<jam-laptop> sorry
<jam-laptop> The Inventory maps the exact text for every file in the tree.
<jam-laptop> At the moment, that Inventory is serialized as one big text
<jam-laptop> and it is stored delta compressed just like we store file texts
<jam-laptop> And we have 1 file for every file object and Inventory and Revision
<jam-laptop> (knits)
<jam-laptop> In the future
<jam-laptop> we will be switching from 1 file per object
<jam-laptop> to having file texts stored next to inventories next to revision texts
<jam-laptop> We are calling that a "pack"
<jam-laptop> We are *also* moving to split up the 1-big inventory text into multiple smaller texts
<keir> so what's in a knit? a series of deltas?
<jam-laptop> keir: deltas + occasional fulltext snapshots
<keir> that seems sensible.
<jam-laptop> so if you have 10,000 entries you don't have to reconstruct all of them
<jam-laptop> to get the last one
<jam-laptop> a Knit is similar to Hg's revlog
<jam-laptop> except we delta based on ancestry
<keir> and you're going to change that by 'transposing' the current per-file storage so that related diffs occur coherently in a single file?
<jam-laptop> rather than just the last node in the file
<jam-laptop> keir: correct
<jam-laptop> There are other things we might do (change what kind of diff algorithm we use, etc, etc)
<jam-laptop> But that is at a disk storage layer, which is hidden underneath the Repository abstraction
<keir> yes. i suspect switching to libxdiff or xdelta will be a big space win
<keir> and a branch is a big list of revisions?
<keir> corresponding to a linear thread of development?
<luks> branch is a pointer to the 'head' revision
<luks> other info is derived from the history graph
<luks> and it's linearized by going through the left-most parents
<keir> ok
<fullermd> bzr is a magic cauldron; you put your data in, let it sit for 4-6 hours, baste occasionally.  Serves 3-10000.
<keir> :)
<keir> where are weaves described?
<keir> nevermind
<keir> found it
<keir> so how are inventories stored now so that they don't list duplicate (fileid,revidY) for files that didn't change in revidX?
<luks> the same way usuall versioned files are stored - "19:08 < jam-laptop> keir: deltas + occasional fulltext snapshots"
<keir> an inventory is not text; so it is serialized then diffed'?
<luks> it's xml
<keir> euwwwwrrrrrrr
<luks> :/
* keir gets an icky feeling
<keir> that really is unfortunate
<keir> so packs are the same? inventories are diff'd XML?
<keir> so right now, to generate a diff 1) find revision id A and B 2) find corresponding inventories 3) get list of files that differ 4) hit knits for the texts and do a diff
<keir> so .bzr is really just revisions, inventories, and texts?
<keir> ignoring branches
<fullermd> And whipped cream.  Don't forget the whipped cream.
<cbarrett> ahoy
<mneptok> ARRR!
<fullermd> Ignoring the WT too.  You're talking about .bzr/repository/ it seems.
<keir> :)
<keir> yes
<cbarrett> mneptok: nice regurg impression
<keir> so a WT is just the checked out files and a pointer to the branch?
<fullermd> Status of the checked out files.  What revision it's on.  Pending merges.  Probably other bits&pieces...
<keir> ok
<JWK> bbl
<danigm> hi, I'm learning bzr, I'll make some projects, and I'm considering svn, bzr, and other vcs. But I don't understand bzr. When I have a branch in a server, I make a branch to my pc, and work on it, and then merge and push it. It's a correct use of that?
<Peng> danigm: Yes?
<Peng> danigm: That's the same as all over the other distributed VCSes.
<keir> danigm, you work (hack/commit/hack/commit/hack/...) then merge (gets new changes from server that happened inbetween) then push
<Peng> You won't necessarily need to merge.
<fullermd> Yes, it's _a_ correct use.  The problem (and the great thing) is that DVCS's support a large number of possible workflows, so the 'correct' one is pretty situation-dependant.
<danigm> if you don't merge, you can't push
<Peng> danigm: If there are no new changes on the server, you don't need to merge.
<cbarrett> usually it's called a "pull" to get new changes from the server.
<Peng> That too.
<cbarrett> a merge is an operation to decrease the number of heads, where a head is a revision with no children.
<danigm> I only use svn before, and you make commit in server directly, it's possible with bzr?
<Peng> danigm: Yes. But why?
<danigm> I don't know
<cbarrett> danigm: why do you want to use bzr?
<danigm> cbarrett: I'll make a game with some people, and I need a vcs
<danigm> I'm considering put the project in launchpad
<Ohrmann> Hello i need help with a freshly installed Windows version of bzr? Can anyone help?
<james_w> Ohrmann: what's the problem? I haven't used Windows bzr before, but knowing the problem is a start.
<Ohrmann> Ok i used the installer and now i try to "bzr init" and i get always an error "bzr: ERROR: Unknown branch format: 'Bazaar-NG meta directory, format 1\r\n'"
<Ohrmann> Oh no im an idiot. I tried to use bzr in a subdirectory of an archive.
<Ohrmann> Sorry for the nois
<Keybuk> a question about cherry-picking ... I'm doing merge -r X-1...X, which gives me a conflict in ChangeLog (shock)
<Keybuk> the odd thing is that the conflict includes far more data from the ChangeLog than what was in that single commit
<mwhudson> i wonder what bzr uses for the merge base in that situation
<Keybuk> am I cherry-picking the right way?
<luks> I usually get better results for such situations (especially changelogs) with the weave merge
<mwhudson> maybe things might become a little more obvious if you passed --show-base to merge
<Keybuk> mwhudson: example?
<Keybuk> I'm doing the pretty standard use-case of cherry picking commits from trunk onto a stable branch to make a new stable release
<Keybuk> so say I want to take revision 726 from trunk, how would I do that?
<Keybuk> luks: weave made an even worse job of it
<Keybuk> it merged the entire changelog from trunk into the branch
<Keybuk> without even marking a conflict
<Alien_Freak> hey guys
<keir> so in the .tix, it seems (fileid,revid) entries have two parents. one is the text delta parent (i think?) and the other is the history parents. is this right?
<keir> and no delta parent implies a fulltext
<keir> and the same for .iix files (inventory index)
<CardinalFang> Ugh.  Have developers tried the web site's download instructions lately?
* CardinalFang runs  $ time bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
<keir> CardinalFang, we're working on it
<keir> pack repos are coming in 0.92
<CardinalFang> I know speed-ups are on the map.  Maybe the native non-HTTP server is better so that newbies aren't scared off.
<keir> not much, yet
<keir> someone else is hacking on that
<CardinalFang> keir, I'm not sure you understood.  I'm saying that "bzr://" would be better than "http://" if you're trying to make a good first impression.
<CardinalFang> I'm new, and I'm trying to test whether bzr will be useful for my new projects.  By Ubuntu box comes with "bzr", but I know it's under rapid development, so I want to see if the recent code is good enough right now.  Getting its own source took 18 minutes.
<keir> CardinalFang, i agree, but it's not that much faster than http yet!
<CardinalFang> Oh.
<fullermd> Well.  [bzr+] http would work too...
<james_w> Keybuk: it's hard to know what the problem is without seeing the revisions and the outcome.
<james_w> Keybuk: however what you have said is the normal way to approch this.
<james_w> if the merge includes things that are not present with diff with the same arguments then it may indicate a bug, I'm not sure.
<Keybuk> $ bzr branch -r 665 http://bazaar.launchpad.net/~keybuk/upstart/main upstart
<Keybuk> $ cd upstart
<Keybuk> $ bzr merge -r 725..726 http://bazaar.launchpad.net/~keybuk/upstart/main
<Keybuk> compare "bzr diff ChangeLog" to "bzr diff -r 725..726 http://..."
<Keybuk> the conflict includes the *entire* ChangeLog text on the main branch
<Keybuk> rather than what was actually in that commit
#bzr 2007-10-12
<ubotu> New bug: #151731 in bzr "bzr merge puts entire ChangeLog from other branch into conflict, rather than just the diff cherry-picked" [Undecided,New]  https://launchpad.net/bugs/151731
<james_w> Keybuk: I think that may be intended behaviour, I'm going to ask for clarification.
<Keybuk> james_w: that implies that backporting a one line fix, with a minor conflict, can create a very very pessimal merge
<james_w> Keybuk: yes, it does.
<Keybuk> I find it hard to understand why this behaviour would be "intended"
<jeremyb> lastlog -clear
<igc> morning all
<acuster> aha, he's asleep. Sensible lad.
<acuster> ciao
<lifeless> something whack with my link apparently
<lifeless> sorry I was offline..
<keir> lifeless, hey
<lifeless> hi keir
<keir> jam helped me add a bit to http://bazaar-vcs.org/DataStructures
<keir> also, just to confirm: .iix is inventory index, and the two node refs are (history parent refs) then (delta parents)? and delta parents is empty if it's a fulltext?
<keir> and same for .tix text indexes?
<lifeless> yes
<lifeless> I'd like to drop the history parent refs for .iix
<jelmer> keir: revisions can contain custom properties as well
<lifeless> it only really needs delta parents, but I have not had time yet
<jelmer> keir: Never mind, missed the "at least"
<keir> lifeless, great
<lifeless> looks like it won't happen for this format I suspect, but who knows
<keir> jelmer, yes, i realize that
<keir> so in the new packs, the inventory is just a knit of a XML file?
<keir> but stored in a pack file
<lifeless> packs haven't changed the way inventories are managed in the repository other than the same transform done to revisions, signatures and file content
<keir> ok
<lifeless> that is the index is changed from a .kndx to many .iix's
<keir> right
<keir> and one iix may have many inventories in it
<acuster> Hey all, what's the difference between bzr svn-import and bzr branch (with bzr-svn installed and from an svn repo)?
<lifeless> right, one for each inventory knit record in the associated .pack
<lifeless> acuster: bzr svn-import may help out
<jelmer> acuster: svn-import clones all branches in a repository, branch just one
<acuster> oh. Hey jelmer.
<acuster> I tried a bzr co and got a core dump :-)
<lifeless> jelmer: packs have partial index reads now
<lifeless> jelmer: I haven't analysed your callgrind yet though
<jelmer> lifeless: cool - what does that mean though ? :-)
<jelmer> acuster: on a public repository?
<lifeless> jelmer: if you only need one file read, you don't parse all the index data now
<jelmer> lifeless: faster incremental push/pull?
<jelmer> ah, k
<acuster> yeah. svn.geotools.org/geotools/trunk
<jelmer> http:// .. ?
<acuster> the same one that was giving me a weird state after a branch (had a Removed: section)
<acuster> yeah
<lifeless> abentley: around? feeling better?
<acuster> I don't think it does svn:// but am asking
<abentley> Yeah.
<acuster> its an old version of subversion 1.1.4
<eolo999> hi, do you know how to branch with bzr+ssh on a non-default sshd port?
<acuster> jelmer, actually, it looks like I tried to co into a blank directory (was not initialized as bzr). That gave:
<eolo999> I changed my default sshd port due to bot attacks and now i can't branch using bzr+ssh protocol
<acuster> python: /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed.
<acuster> and dumped core (not sure of what)
<jelmer> acuster, what version of bzr-svn are you running?
<jelmer> acuster: what was the exact command you were running?
<acuster> 0.4.2-1
<acuster> mkdir somedir
<acuster> cd somedir
<acuster> bzr co http://svn.geotools.org/geotools/trunk/
<acuster> and 0.90-1bazaar1
<jelmer> acuster: please try a more recent version
<jelmer> acuster: 0.4.2-1 had some issues with http:// repositories
<acuster> your latest conflicts with the latest I can get
<acuster> that was the best I could do on feisty but perhaps there are packages elsewhere
<eolo999> bzr+ssh always try to connect on port 22 or i can change it?
<acuster> aha
<jelmer> acuster: the bazaar-vcs.org repository should have more recent packages
<Odd_Bloke> eolo999: Have you tried 'bzr+ssh://<host>:<port>/...'?
<jelmer> eolo999: bzr+ssh://host:port/... doesn't work?
<eolo999> tried... but i always mistype, go and check...
* eolo999 is checking
<acuster> jelmer, later than your .debs?
<eolo999> i'm really sorry i wrote address.comi... as i told you: i ALWAYS mystype
<jelmer> acuster: it has a more up-to-date version of the bzr package
<jelmer> see http://bazaar-vcs.org/DistroDownloads
<acuster> thank you
<lifeless> abentley: so this merge base thing.
<Odd_Bloke> eolo999: Heh, "mystype". ^_^
<abentley> Mmm?
<lifeless> I think we're picking worse merge bases that we did in 0.17ish times
<lifeless> IIRC you identified a problem with the current logic
<lifeless> but my memory is hazy
<lifeless> I mailed you a particular case that stood out for me, where it clearly took a history shortcut
<abentley> My memory is hazy too.
<lifeless> heh
<lifeless> if you could look in your inbox, oh a week or so back
<abentley> Okay.  If you could run graph-ancestry on these things it would be helpful.
<lifeless> sure thing
<abentley> That's usually where I start.
<lifeless> I don't know what your debug process is for this I guess
* lifeless digs around in sent mail
<lifeless> oct 5th
<lifeless> I'll just paste the revids here for my easy access
<lifeless> robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv
<lifeless>  pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl
<abentley> Heh, on my mail client, that's oct 4th.
<lifeless> :) in the old world :)
<eolo999> thanks guys...bye
<lifeless> bye
* eolo999 go to bed
<abentley> lifeless: Has your revision been merged into mainline?
<lifeless> no
<abentley> Is it the packs branch?
<lifeless> yup
<lifeless> http://people.ubuntu.com/~robertc/baz2.0/repository
<lifeless> I'll pull it to the knits version for you, one sec
<abentley> Oh, I just stated a pull of the knits version.
<lifeless> its just annotating the recent work, will be a few minutes
<lifeless> hmm, it would be nice to show that in some senses
<abentley> Like a progress indicator?
<lifeless> yeah
<lifeless> [== ]  Pull phase 0/2
<lifeless> not enough info to understand why it is slow
<keir> i remember way back in the day jam was working on a progress bar refactor
<abentley> Well, when I really thought about it, it generalized to a "status" API.
<abentley> Where status data about multiple operations could be transmitted, instead of this linear 0-1 scale.
<lifeless> so jam-laptop what do you think you'll hack on now, between diapers that is
<abentley> lifeless: I think the problem with the graph code was that if it hits a null revision it can stop before it discovers some comon ancestors.
<lifeless> wow
<lifeless> that png breaks display
<abentley> lifeless: You can set --max-distance to reduce the graph complexity.
<lifeless> yah doing so now :)
<abentley> I thought it was already defaulted, but maybe not.
<poolie> good morning abentley, lifeless
<abentley> Morning.
<lifeless> abentley: if it is defaulted, its too big for me :)
<lifeless> anyhow
<lifeless> I did track the ancestry using log
<lifeless> and it was definately a shortcut, as I mention in my mail
<lifeless> the push is maybe 10% done?
<lifeless> if you have a packs branch you can probably pull it directly more easily ;)
<abentley> Well, what I want to know is do we have a bunch of LCAs.
<abentley> My packs branch is quite out of date, I think
<lifeless> okies
<lifeless> >>> import bzrlib.repository
<lifeless> >>> r = bzrlib.repository.Repository.open('..')
<lifeless> >>> tips = ['robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv', 'pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl'] 
<lifeless> >>> g = r.get_graph()
<lifeless> I'm all set to answer any questions :)
<lifeless> >>> g.heads(tips)
<lifeless> set(['pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv'] )
<abentley> sry.
<abentley> g.find_lca('pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv' )
<acuster> bzr co (using bzr-svn) should just get the last revision or is also building the same history as bzr branch?
<lifeless> >>> g.find_lca(tips[0] , tips[1] )
<lifeless> set(['robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc'] )
<abentley> acuster: By default, it will be fetching the branch history.  You want that, unless you have very fast (LAN-speed) access to the server.
<abentley> lifeless: Do you think that's an accurate result?
<lifeless> does 'bzr find-merge-base' show the actual merge base used ?
<abentley> lifeless: Yes, I updated it when I changed the graph code.
<acuster> abentley, is that smaller than the stuff fetched for a 'bzr branch' or the same?
<abentley> acuster: the same.
<lifeless> robertc@robertcollins.net-20071004220007-6tb7pyeknkhpnfyq
<jelmer> acuster: just the last revision is possible using 'bzr checkout --lightweight'
<abentley> lifeless: I think maybe you're misunderstanding the question?
<acuster> but I can't branch from the checkout right? checkouts are just dumb trees?
<abentley> acuster: You can actually branch from a checkout.
<lifeless> abentley: should the merge base it chose be one of the lca's ?
<abentley> Even if it's just a dumb tree.
<acuster> lol. so what is the difference?
<lifeless> back shortly, need greasy food
<acuster> jelmer, bzr 0.91-2 and 0.4.3 (in plugins/) doesn't crash
<lifeless> abentley: ok, the conversion to knit data has completed
<abentley> lifeless: no.  If those really are the LCAs, the algorithm will find *their* lca.
<jelmer> acuster: ok, cool
<acuster> thanks for your help
<abentley> acuster: A branch is an independent line of development.  A checkout is a copy of the source tree, and when you commit in it, the results go into another branch.
<abentley> lifeless: pulling
<acuster> but you can branch from a checkout and checkout from a branch? Cool. I did not expect that kind of flexibility
<lifeless> abentley: its likely that there are two valid lca's there - this branch merges from many
<abentley> What does g.find_lca('robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc') give you?
<abentley> I ran it myself, and it gives 'pqm@pqm.ubuntu.com-20070823005013-ada9x55rc31yiwou', which is the value from your email.
<abentley> So unless we're hitting a bug in the find_lca stage, the algorithm is behaving as intended.
<lifeless> back
<lifeless> ok
<lifeless> I think the problem then is this recursive definition
<lifeless> either of the first lca's is a reasonable base
<lifeless> their common point is however much further back
<acuster> okay, let's let the bzr branch run. Thanks all for your help. goodnight
<abentley> lifeless: The problem is that neither one of them is a reasonable base.
<lifeless> our old code would have picked one though ?
<abentley> Yes.
<lifeless> and as a user, our old code felt much nicer
<abentley> Silently discarding differences in the other.
<lifeless> huh?
<abentley> Each side makes different merge resolutions.  If you choose a too-recent merge base, one side's merge resolutions are silently discarded.
<lifeless> if the base is merged into both sides, that's not the impact
<abentley> Yes it is.
<abentley> It's a damned-if-you-do, damned-if-you-don't situation.
<lifeless> is there a mail/wiki/doc that lays this out?
<abentley> Yeah.  1 sec.
<abentley> http://article.gmane.org/gmane.comp.version-control.monotone.devel/3256 http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264
<lifeless> abentley: I see
<lifeless> abentley: hmm I think
<lifeless> abentley: so concretely, I've been dealing with the same conflicts when merging bzr.dev -> branch A -> B -> C -> packs
<lifeless> and by the third and forth *repeated resolution* I'm entirely over them
<abentley> So you've got four branches in flight?
<lifeless> yah
<lifeless> not right now, but earlier on when I had many patches outstanding
<lifeless> earlier this week I had three
<lifeless> bzr.dev, readv, index, repository
<abentley> Well, as long as you're always merging in one direction, that shouldn't give criss-cross.
<lifeless> well
<lifeless> repository gets merges direct from bzr.dev
<lifeless> I also get conflicts in the other direction
<lifeless> when I merge bzr.dev to repository, after something from e.g. readv was merged to bzr.dev
<lifeless> the reason repository gets merges from bzr.dev is that I only create these other branches when I realise I need to change some infrastructure
<lifeless> so I then branch bzr.dev to e.g. readv
<abentley> So I internalized Nathaniel's observations a long time ago.  My solution was always "so don't do three-way".
<abentley> I really do feel like there's no good option, so I picked the one that didn't lead to silently discarding changes.
<lifeless> so the conceptual problem I have here
<lifeless> is that a criss cross graph that doesn't have criss-cross changes should be safe
<lifeless> we're getting conflicts because, to use NEWS as an example,
<lifeless> one side actually has added a single new entry
<poolie> woot
<poolie> one
<poolie> less failure
<lifeless> :)
<poolie> ok, i think the basis update is right, except it causes a somewhat obscure failure in  test_rio_version
<lifeless> cool
<poolie> the problem is that with this change, the root directory is not given the right revision on a commit
<lifeless> uhm
<lifeless> there are tests for setting that I'm quite sure
<lifeless> rephrasing, I think it should be settable via the update... method, so I'd look at the delta creation I guess
<poolie> since the delta is the only thing i changed i guess that's where the problem is
<poolie> however, there are no really direct tests for it, so i'm adding one
<lifeless> hmm
<lifeless> the delta returned by record_entry_contents ?
<poolie> i'm just thinking out loud here, not necessarily trying to distract you, btw
<lifeless> there are some direct tests for the deltas' returned by record_entry_contents, though there are several layers there involved in making the tests easy to write
<lifeless> thats fine, its friday avo, I'm trivially distracted
<lifeless> btw, Portal is *cool*
<lifeless> finished it this morning before work :)
<poolie> yep, i tried it briefly this morning :)
<poolie> i'm trying to maintain self control
<poolie> :)
<lifeless> did you lookup your steam name?
<poolie> yby30
<poolie> ok, so the RootCommitBuilder isn't giving back a delta for the root on the second commit
<lifeless> thats right
<lifeless> unless the root has changed
<poolie> should it get a new revision on each commit, or not ?
<poolie> some code seems to think that it should
* igc food
<lifeless> it should get a new rev on knit1 repos, but not on knit3
<poolie> so CommitBuilder.record_entry_contents should be saying the root has changed
<poolie> but it does not
<poolie> in fact it seems to leave the same revision id in there
<poolie> so, it would seem that someone else is updating the root revision id at a later time
<poolie> and, indeed there's a _check_root method that fudges it
<lifeless> right
<lifeless> thats how I've currently minimised the differences
<ubotu> New bug: #151844 in bzr "bzr info (Windows)" [Undecided,New]  https://launchpad.net/bugs/151844
<igc> lifeless, pollie: anything you want reviewed today by me?
<igc> poolie: ^^
<igc> robert's bisection one looks the most important ...
<igc> but I gather poolie is already working on that
<poolie> i already posted some changes
<igc> saw those
<poolie> lifeless, ok, so the bug seems to be repository.py +296
<poolie> assuming that there's always no delta on the root
<poolie> which is odd
<lifeless> well
<lifeless> I think its 'no delta should be shown as always delta'
<lifeless> (for non RootCommitBuilder)
<poolie> mm?
<lifeless> wooties
<lifeless> I have fine grained concurrency
<poolie> ok, i think i've fixed it
<poolie> the commit code could do with a good scrub
<lifeless> heh, its been getting one
<poolie> can you tell me what this line is doing, about 269 of repo.py:
<poolie>         if ie.revision is not None:
<poolie>             if self._versioned_root or path != '':
<poolie>                 # not considered for commit
<poolie> oh nm, i see
<lifeless> this is something I hope to fix shortly, by not passing ie's into record_entry at all
<lifeless> but what it is doign is carryign over unmodified entries
<lifeless> (which the commit.py code signals by keeping the ie.revision attribute from the basis)
<lifeless> and for non versioned roots this is fallacious
<lifeless> ok
<lifeless> igc: poolie: fine-grained-locking packs pushed
<lifeless> bbiab
* i386 thinks Atlassian's fisheye should support bzr
<lifeless> igc: yes
<lifeless> meh
<lifeless> i386: yes
<i386> we have git support internally
<i386> (sucks)
<poolie> oh, you work there?
<poolie> lifeless, can you please fix the permissions on /srv/www.bazaar-ng.org/rsync/bzr/bzr.dev/.bzr/checkout/dirstate
<poolie> and the containing directories
<lifeless> sure, whats wrong with them ?
<poolie> they're owned by you and mode 0644
<poolie> this seems kinda selfish :)
<lifeless> chmod g+x enough ?
<poolie> g+wX would be better
<poolie> because i want to update the wt
<lifeless> .bzr$ chmod g+wX -R .
<poolie> and check the group too i guess
<lifeless> group is bazng
<lifeless> theres files there jam owns too
<lifeless> merge-hashes for instance
<poolie> and also the wt please
<poolie> hrm
<lifeless> done, huge list of errors
<poolie> but fortunately jam's files seems group-writable
<poolie> you seem to have made some regular files g+x
<lifeless> bzr revert ;)
<poolie> won't fix the controlfiles
<lifeless> oh, but we don't care about them do we?
<poolie> i guess it's harmless
<poolie> just wierd
<poolie> weird
<lifeless> wierd is weird
<lifeless> :)
<poolie> find .bzr -type f -perm +0111 -user $USER -exec chmod -x {} \;
<igc> i386: I'm a big fan of JIRA and Confluence. bzr support in JIRA and FishEye would be sweet indeed.
<lifeless> ok, one patch sent
<lifeless> working on index patch cleanup now
<i386> igc: I think there is an issue on jira.atlassian.com for that
<i386> go vote on it :)
<poolie> lifeless, do you have a rule-of-thumb number for how long a basis_inv.iter_entries takes?
<lifeless> uhm
<lifeless> seconds? IIRC
<lifeless> I saved 10 seconds at one point by removing one such loop, though it did stuff in the middle
<lifeless> I haven't measured for entry in ..:pass
<poolie> ok, update_etc patch sent
<lifeless> wicked cool
<lifeless> just finished the index changes from review, mailing now
<lifeless> have a good weekend
<lifeless> grab me on steam for games :)
<poolie> night all
<igc> night poolie
<igc> in fact, night all - have a good weekend
<poolie> good night igc
* Starting logfile irclogs/bzr.log
<lifeless> mwhudson: hey
<lifeless> mwhudson: please try packs again, indices are now partial-read enabled
<mwhudson> lifeless: ok
<mwhudson> probably not going to get to that today
<sabdfl> lifeless: how goes the effort to land packs?
<bialix> hi
<bialix> someone familiar with git here?
<lightyear> hi there.
<lightyear> I have a question about if it is possible with bazar or I should stop searching for the feature
<lightyear> I have remote-server (webspace) without any ssh or shell acces and want to commit the latest changes to the working dir over there.
<lightyear> as I can see push is only updating the .bzr and not the working dir
<CardinalFang> lightyear, Do you have any way to send files, in general?  FTP?  HTTP put?
<lightyear> do I have any possiblity to update the working copy remotely
<lightyear> yep. Currently I do all with ftp
<lightyear> and the syncing with push works in generally
<lightyear> but the working copy is not updated.
<lightyear> is there a way to do this, CardinalFang ?
<dato> without shell access, I've never heard of a way
<CardinalFang> lightyear, Well, I suppose you could send a snapshot of your checked-out tree also.  Not with BZR, but with something else.
<lightyear> the idea was, that I've only to commit the changes over ftp, because the connection is damn slow.
<lightyear> so I've to copy that manually (doing release or the whole working-dir) outside of bazar.
<CardinalFang> Yeah, I get it.  On the remote server, though, unless you have a way to execute arbitrary commands, then there's no way to send only metainfo and have it explode into a snapshot.
<lightyear> so bazar is not even theoritically able to do this?
<CardinalFang> Nothing could, no.
<lifeless> if you can do rsync
<lightyear> can't
<lifeless> then there is a plugin that will rwsync the specific files across
<lightyear> so. wait there would be a way without command-executing on the serveR?
<lightyear> but that can't be done over a ftp-connection because it is using the algo of rsync?
<CardinalFang> Yeah, I think rsync requires "rsync"-the-program to run on the remote end.
<lifeless> the problem with ftp is that its very hard to get full file system behaviour
<lifeless> night all
<CardinalFang> g'night.
<lightyear> night, lifeless
<lightyear> thanks for the help
<lightyear> afaik rsync can work over ftp....
<lightyear> no. I need the deamon :(
<CardinalFang> So, lightyear, if you can run programs on the far end, then your problem is solved.  Else, you have to schlep all the bits.  The far end is a dumb data-store.  You get out only what you put in.
<lightyear> okay. thank you CardinalFang
<lightyear> so bazar is not able to read the archive of the remote and do a checkout there. that is what I wanted to know.
<CardinalFang> It could, but bazaar isn't there.  It's here.
<hsn_> how python determines Codec for encoding charset on Windows?
<hsn_> it would be nice to have it displayed in bzr version
<lightyear> CardinalFang, would it be possible, if I write a plugin for it?
* lightyear is able to write python code and is very interested in that kind of a feature
<bialix> lightyear: it's possible to write plugin
<lightyear> is it possible with the plugin api to write something like this is the question....
<bialix> hsn_: looking at terminal settings
<CardinalFang> lightyear, I'm afraid you've misunderstood.  This isn't a bazaar problem.  Your endpoint is crippled.  You could write a plugin that wraps one of dozens of tools that upload trees of files, or you could just run one of those programs directly.
<hsn_> bialix: because when i run bzr under eclipse it seems to use incorrect ascii encoding. from command line it works fine
<bialix> hsn_: try this: python -c "import locale; print locale.getpreferredencoding()"
<bialix> I don't know much about eclipse, probably it run bzr with dummy stdout, that use ascii encoding
<bialix> if you run bzr from another program with redirecting all stdin/stdout/stderr to pipe or file, then bzr internally will use encoding from locale
<bialix> so my best guess: something wrong happens when eclipse grab output of bzr
<bialix> hsn_: you can use very simple plugin to look at encodings that see bzr
<bialix> or could look in .bzr.log :-)
<hsn_> bzr is using 'ascii' encoding under eclipse. Its in error message from bzr 'ascii' codec can not encode...
<bialix> in what command?
<hsn_> bzr version --xml
<bialix> C:\work\Bazaar\mydev\bzr.dev>bzr version --xml
<bialix> bzr: ERROR: no such option: --xml
<hsn_> you need bzrxml plugin
<bialix> so, problem in this plugin
<bialix> try to run plain 'bzr --no-plugins version'
<hsn_> nope, it will do without --xml too, because bzr with ascii codec complains about non-ascii characters in pathname
<bialix> it's very common error here: try to print non-ascii strings to stdout
<bialix> you run with --no-plugins flag?
<hsn_> no
<bialix> can you try with --no-plugins?
<hsn_> yes if i change bzr.bat
<bialix> why for???
<hsn_> add --no-plugins
<bialix> you cannot run bzr from eclipse as from command line?
<hsn_> bzr.bat is executed by eclipse-bzr plugin, i dont have source code for plugin
<bialix> does eclipse have some sort of command to run any arbitrary program?
<bialix> bug 131100
<ubotu> Launchpad bug 131100 in bzr "`bzr --version` should care about encoding of stdout" [Medium,Fix released]  https://launchpad.net/bugs/131100
<bialix> I fixed this bug for 0.91
<bialix> and it really fixed
<bialix> you can fix bzrxml plugin yourself though
<hsn_> why do you think that bug is in bzrxml?
<bialix> because it's common error of many python programmers: pretend that "print" always print to real terminal
<bialix> and never thought about non-ascii users
<bialix> in bzr ML there is recent patch from Lukas that fixes similar problem
<hsn_> testing it without bzrxml plugin
<hsn_> bzr --no-plugins version seems to work from eclipse fine, i will do more tests
<bialix> as you wish
<hsn_> you understand how Windows are using its 2 encoding? They use one for gui programs and second for command line programs. What kind of encoding is used for Filenames?
<bialix> for filenames windows internally used unicode
<bialix> but you can get it in ANSI encoding (you called it gui)
<bialix> you can control encoding of terminal with 'chcp' command
<bialix> it's very handy
<hsn_> locale.getpreferedencoding() in command-line windows returns cp1250 but output seems to be in 852 encoding
<bialix> just select Lucida Console font for terminal
<bialix> try in terminal: chcp 1250
<hsn_> yes chcp 1250 in console changes bzr output to 1250 too
<bialix> so now you too know kung-fu :-)
<hsn_> ok. now how to fix bzrxml insert calling to some locale function?
<bialix> you read bzr ML?
<hsn_> sometimes yes
<bialix> one sec
<bialix> http://bundlebuggy.aaronbentley.com/request/%3C5288a560710120333t50ad35eagccd51987e20adea5@mail.gmail.com%3E
<bialix> you need to add line: encoding_type = 'replace' in the body of cmd_version class in bzrxml plugin
<bialix> and change all print 'foo'
<bialix> to: print >>self.outf, 'foo'
<bialix> that's basically all
<bialix> hsn_: may I ask you a question?
<hsn_> yes
<bialix> it seems you're novice in bzr
<hsn_> i am using it since 0.14 or 0.15
<bialix> oh, all 2007 :-)
<hsn_> i used tla before
<bialix> you don't read ML because it's not interesting or because it too devel-centric?
<hsn_> no, because my time is limited and there are too much messages/day
<bialix> ok, thanks
<hsn_> i am using bzr because its easier to use than git or hg
<bialix> you familiar with git?
<hsn_> i used it for a while, but it was too hard for ppl working with me to learn
<bialix> I have a question about rebase
<bialix> how rebase deal with conflicts?
<dato> stops rebasing, and gets you back to the shell for you to resolve them
<dato> and then you do `bzr rebase-continue`
<bialix> it's rebase revision by revision?
<bialix> (probably git rebase-continue)
<dato> oh
<dato> sorry
<bialix> :-)
<bialix> it's ok
<dato> missed the context and thought you meant rebase in bzr :)
<bialix> I can't use svn fro the same reason
<dato> so nothing I said applies to git
<bialix> does we have rebase in bzr?
<dato> plugin
<dato> by jelmer
<bialix> ah
<bialix> never tried it
<bialix> just interesting how git-rebase deal with conflicts
<bialix> git people push too much noise about rebase
<hsn_> i never used rebase in git
<bialix> hsn_: you said hg is also hard to use
<hsn_> hg is easier to use than git
<bialix> but?
<hsn_> there doesnt seems to be much interest in fixing hg bugs
<dato> you mean upstream is unresponsive? or what?
<hsn_> i want to say that if i compare speed of hg releases and speed of bugfixing, its very unlikely to get some bugs fixed soon
<bialix> luks: ping
<ubotu> New bug: #152008 in bzr "Ability to unmerge or revert a merge sensibly" [Undecided,New]  https://launchpad.net/bugs/152008
<bialix> luks: ping
<luks> hi bialix
<bialix> hi luks
<bialix> have a question about qdiff
<bialix> can you give a hint where text of diff decoded to/from utf-8?
<bialix> I need to to do something with bug 148159
<ubotu> Launchpad bug 148159 in qbzr "qdiff and qannotate treats file content as utf-8" [Undecided,In progress]  https://launchpad.net/bugs/148159
<luks> hmm
<bialix> I want to introduce new branch option 'default_encoding' and use it as hint for decoding files content
<bialix> otherwise qdiff will use utf-8
<luks> it should be after running PatienceSequenceMatcher on it, but before passing it to Qt
<luks> currently it's a bit hardcoded in diffview.py
<bialix> treediff = TreeDiff(self.tree1, self.tree2, self.specific_files, complete)
<bialix> in TreeDiff class?
<luks> I'll need to take a look at the code
<luks> one moment
<bialix> there is FileDiff.make_diff method
<bialix> my best guess it should be done here
<luks> I'd like to do as little unicode decoding as possible
<luks> decoding all lines of all files is a waste of CPU
<bialix> so?
<luks> one more moment, still thinking :)
<bialix> Patience sequence matcher invoked in FileDiff.make_diff
<luks> okay, decoding all lines in FileDiff.make_diff is probably the best option
<luks> there is a bunch of unused code (html_diff_lines) and the current side-by-side diff is calculated in diffview.py
<bialix> I'm not dare enough to delete this code
<luks> I'll have to refactor these things, and then can be the decoding optimized
<luks> but for now decoding all of them should be fine
<bialix> before sequence matcher or after?
<luks> after
<bialix> what about this code:
<bialix>             if old_lines and not new_lines:
<bialix>                 self.groups = [[('delete', 0, len(old_lines), 0, 0)] ] 
<bialix>             elif not old_lines and new_lines:
<bialix>                 self.groups = [[('insert', 0, 0, 0, len(new_lines))] ] 
<luks> add it after the whole block
<luks> these ifs are just to avoid sequence matching
<bialix> ah, try it now
<bialix> this place try to decode line to unicde fro utf-8
<bialix> File "C:\work\Bazaar\plugins-repo\qbzr\diffview.py", line 157, in markup_intraline_changes
<bialix> probably this place you call hardcoded
<bialix> and many others too
<luks> you can remove them
<luks> everything that calls .decode("utf-8", "replace") in diff.py or diffview.py
<bialix> so, I do decoding in one place and remove all others from all places, right?
<luks> yes
<bialix> you do decode to unicode a bit too often
<bialix> I found 3 places so far for only one file
<bialix> qdiff for one file
<bialix> heh, it's finally working
<bialix> so, you have some objections for new branch config option?
<luks> yes, I have a habit of writing extramly ugly code if it's for myself :)
<luks> no, not at all
<bialix> I'm inclined to use branch-level option to allow different projects have different encodings
<bialix> because qbzr is utf-8 :-)
<luks> it's a shame that these configs are not propagated on push/pull
<bialix> well, another option is to have such option in revisions property
<bialix> like --fixes or --author
<bialix> it's require some plugin hacking
<bialix> or just qcommit can do this :-)
<luks> I think I'd really prefer something like .bzrprops
<luks> but I don't mind using a branch config for now
<luks> as long as the default is utf-8 :)
<bialix> .bzrprops should be in past revisions, but my old revisions don't have it
<bialix> it's the problem for me
<bialix> it will be show-stopper to browse history
<luks> oh, right
<bialix> of course, default always be utf-8
<bialix> it's inevitable
<bialix> luks: do you have in mind some roadmap for qbzr?
<luks> no, the development was driven only by what I currently needed
<bialix> well, so I'll try to scratch my itches and help you if possible
<luks> I really didn't intend to create some generally usable tool
<bialix> why not?
<luks> I just wanted to use bzr, and but I was too used to tortoisesvn
<luks> so I needed something similar
<bialix> before bzr I used TortoiseCVS
<luks> and I still consider it my own personal tool :)
<luks> I tried to use bzr-gtk before, but it was just too weird
<luks> but I liked the idea of using a command line shell instead of windows explorer
<luks> (with GUI for commit, etc.)
<bialix> I'm happy with FAR and using bzr from command line a joy for me
<bialix> but I'm thinking about convenient log/diff viewer, and your QBzr fit my expectation on 100%
<bialix> but now I feel that qstatus will be very good thing
<bialix> and I agree with you about gtk
<bialix> on windows it's very unfriendly
<luks> the problems I had with it are not directly gtk-related
<bialix> but overall design?
<luks> GUI design
<luks> not even GNOME uses dialogs like that
<luks> but I didn't feel like hacking a gtk app on windows
<bialix> hmm, have no experiance with gnome
<luks> and now I ended up using Qt on GNOME :)
<luks> because it simply looks more native than bzr-gtk, even though gtk is the first class citizen in GNOME
<bialix> I think it's a very funnily
<luks> another thing that annoyed me about bzr-gtk is the order of Ok and Cancel buttons
<luks> don't know why, but if I'm on GNOME I expect the buttons to follow the GNOME standard, and on Windows the Windows standards
<bialix> you're using standard windows scheme in QBzr
<luks> and somehow have no problem switching between them
<luks> bialix: no, it uses different scheme on each platform
<bialix> are you sure with my latest changes?
<luks> yes
<bialix> but... how???
<luks> QDialogButtonBox handles that
<bialix> wow
<bialix> it's magic
<bialix> I never realize this
<luks> so on GNOME I have [Cancel]  [Ok]  and on Windows [Ok]  [Cancel] 
<bialix> cool
* bialix starts thinking that Qt is really right thing
<bialix> luks: I'm planning to put QBzr in standard standalone windows installer with some others plugins
<luks> hmm
<luks> wouldn't it be too big?
<bialix> with gtk it will be bigger as twice of qbzr
<bialix> currently your installer is 3MB
<bialix> bzr.exe installer is about 4.5 MB
<bialix> so I'll have in the end about 7 MB installer
<bialix> I'm also concerned about size
<bialix> may be there will be 2 standalone installers: bare bzr.exe and big pack with some popular plugins
<bialix> and if you're planning to switch to bzr version scheme one day, I'm happy to include Queue.py std module to bzr.exe
<luks> Queue.py is no longer required
<luks> but no, I don't plan to have releases synchronized with bzr
<bialix> but you planning to use multithreading...
<luks> maybe...
<luks> I'd rather keep backward compatibility than force users to specific version of bzr
<bialix> bzrlib API is very fast changing sometimes. how you achieve backward compatibility?
<luks> well, most of the API is not changing
<bialix> it's good
<CardinalFang> Ick.  Cloning from a remote repo.  I don't have enough space in /tmp to contain a whole repo.
* CardinalFang assumes it's /tmp that is the problem -- "No space left on device".
<bialix> luks: good night, thanks for help with qdiff, I'll prepare the patch
<CardinalFang> remote.RemoteRepository._get_tarball downloads a tarball into a "tempfile"-created temp file.  Could it instead (uncompress+) untar the stream as it goes, instead of making a file and then operating on the file?
<luks> CardinalFang: currently no, but the next version should support streaming natively
<CardinalFang> NameError: name "next version" is undefined
<CardinalFang> Is that v2?  Or 0.9z?
<luks> 0.92
<CardinalFang> Ah, cool.  Thanks.
<luks> at least there is a patch for that, I assume it's going to be included
<CardinalFang> I see in tempfile.py that it reads from env variables.  Is there a way to poke the environment for only bzr, e.g., with ~/.bazaar/bazaar.conf .
<CardinalFang> ?
<luks> no idea
<CardinalFang> Hmm, doesn't look like it.
<CardinalFang> Aw crap, it's not local.  The server makes a tarball too.  That's where I'm running out of space.  Crap.  Crap crap crap.
<lifeless> CardinalFang: if you apply the hpss patch from spiv, its on BB, to the client and server, then the tarball method won't be used
<CardinalFang> lifeless, Thanks.
<weigon> I don't get my head around why I should to a checkout instead of a branch
<weigon> I have read http://bazaar-vcs.org/CheckoutTutorial but I'm not really sold
<Peng> weigon: You should use a branch. The only reason to use a checkout is if you absolutely can't retrain your brain to use bzr commands instead of svn commands. :)
<weigon> ah, so I'm fine :)
<Peng> weigon: Also, lightweight checkouts are useful for when you don't want a copy of the entire history.
<hsn_> Peng: bzr update in checkout does equivalent of svn up ?
<Peng> hsn_: Yes.
* Peng waits to be proved wrong. :P
<LeoNerd> It can even be abbreviated 'bzr up'
<hsn_> testing it
#bzr 2007-10-13
<hsn_> yes. in checkouts it works like in svn. in branches it doesnt
<Peng> Right.
<Peng> In branches, you use 'bzr pull'.
<lifeless> actually it does the same thing in branches as svn up in a branch
<lifeless> that is, nothing :)
<lifeless> (well, takes your tree up to the state of the branch)
<keir> what's the status of nested trees? right now i'm symlinking one project into another, but that's not too optimal!
<keir> lifeless, is bzr going to support repositories > 4gb on 32 bit machines?
<keir> right now packs won't scale like that
<keir> at least, i don't think they will because repack requires fitting everything in memory
<hsn_> #151968
<hsn_> ubotu: 151968
<ubotu> Sorry, I don't know anything about 151968 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<lifeless> keir: repack doesn't buffer everything in ram
<lifeless> keir: it buffers a single knit record at a time + the source and target indices
* lifeless waves
<Daviey> Hey, has anybody got a suggestion on how to auto email commits(+comments) to certain addresses?
<Daviey> (non LP bzr)
<luks> depends on what do you mean by "auto"
<Daviey> luks: this - https://edge.launchpad.net/bzr-email :)
<Daviey> Hmm.. but that is client side...  I really wanted the branch to do it :/
<Daviey> (server side)
<luks> oh, you meant sending mails to e.g. commits mailing list
<Daviey> yeah.. but rather than a ML a list of addresses
<luks> I haven't tried, but what about https://edge.launchpad.net/bzr-hookless-email/
<Daviey> thats the one :)
<Daviey> thanks
<Kamping_Kaiser> should bzr automatically update the default `bzr pull` location when you do a pull from a different server?
<Odd_Bloke> Kamping_Kaiser: No, you need to pass --remember for it to do so.
<Kamping_Kaiser> Odd_Bloke, oh. cheers.
<Odd_Bloke> Kamping_Kaiser: :)
<Kamping_Kaiser> :)
* Kamping_Kaiser notices from survey that bzr supports bzr+ssh
<bialix> luks: ping?
<luks> bialix: pong
<bialix> hi luks
<luks> hi
<bialix> something really weird wit qannotate
<bialix> with
<bialix> and this is not my fault
<bialix> try to qann bzrlib/merge3.py
<luks> what's the problem?
<bialix> it throw away series of lines
<bialix> especially: class Merge3 ... it's simply missing in qann window
<bialix> say me it's not win32-related
<luks> hm, not in mine
<bialix> screenshot: http://bialix.com/qbzr/qann-merge3.png
<bialix> does not matter: with my latest encoding support or before it
<luks> sorry, I'm back (stupid wifi was disconnecting me)
<luks> yes, I see it too on windows
<luks> no idea what could be causing it
<bialix> IMO it's < sign
<luks> hm, it depends on whether Pygments is installed
<bialix> line 39
<bialix> I'm running standalone bzr.exe
<bialix> so no Pygments here
<bialix> may be we should escape < sign?
<luks> uhh, right, it doesn't escape html at all
<luks> so &, < and > need to be changed to xml entities
<bialix> i think so
<bialix> htmlize from util.py is enough?
<luks> htmlize creates also links
<luks> not sure if that's a good idea in code
<bialix> cgi.escape?
<luks> but maybe yes
<luks> I'd prefer to not use the cgi module
<bialix> ok
<luks> diffview.htmlencode
<luks> should be moved to util
<bialix> I see
<bialix> want me to do this?
<luks> I'll do it
<bialix> ok, thanks
<bialix> luks, do you know how to plug-in new merge algorithm?
<luks> nope
<bialix> merge3 is wtf for me time to time
<ubotu> New bug: #152360 in bzr "AssertionError: empty revision for the inv_entry TREE_ROOT when doing "bzr branch -r 1 bzr.dev foo"" [Critical,Confirmed]  https://launchpad.net/bugs/152360
<nilton> hi. how can i setup a bazaar server over https with apache?
<nilton> or how is the best way to setup a bazaar server?
<nilton> can anyone give some tips on setting up a bazaar server?
<nilton> I'm reading the docs but I don't think I see how to do it...
<keir> nilton, you don't need a server
<keir> http will do
<keir> or if you have ssh access, do bzr+ssh://
<nilton> keir: i would like to do it over http...
<nilton> but i need to setup dav and use a bzr plugin, so i can write to it, right?
<keir> nilton, yes. i don't know anything about DAV :(
<nilton> do most bazaar projects use bzr+ssh protocol? because for svn projects dav over http is the default choice...
<Peng> Actually, I'd say most use sftp.
* jelmer always uses bzr+ssh
<Peng> Yeah.
<Peng> I meant to add that bzr+ssh is replacing sftp.
<AfC> nilton: you can configure things so that http:// requests are internally forwarded to a bzr smart server (though I personally have never made this work). We just run a Bazaar daemon to serve bzr:// now for reads, and the few people with write access push via bzr+ssh://
<Peng> You've never made forwarding work, or never made bzr+http work?
<nilton> AfC: I've read something about that on http://doc.bazaar-vcs.org/latest/en/user-guide/server.html
<nilton> but i didn't see anything about forwarding http to a bzr server... the docs seems somewhat scaterred..
#bzr 2007-10-14
<AfC> Peng, nilton: there is a mans whereby you can transparently, internally redirect a http:// request to a mod_python running a Bazaar server instance. It's purported to work from http:// although that may still be a bug.
<AfC> Good morning
<Alien|Freak> is there a guide for importing an svn tree to bzr?
<jelmer> Alien|Freak: not really - what sort of information are you lookjing for?
<Alien|Freak> history
<Alien|Freak> it's just one project really.. but I want to import the history from an svn repo to a bzr repo
<jelmer> Alien|Freak, the bzr-svn plugin has a svn-import command that can do that
<Verterok> moin
<lifeless> ~
<jdub> hey folks
<jdub> bzr-rebase is still not available in gusty
<jdub> which is problematic for folks already using bzr-svn
<jdub> hrm
<jdub> so i've installed bzr-rebase from debian
<jdub> but get the following on svn-upgrade:
<jdub> Using saved location: http://svn.automattic.com/wordpress-mu/trunk
<jdub> bzr: ERROR: Repository KnitRepository('file:///home/jdub/src/wordpress/wpmu/.bzr/') is not compatible with repository SvnRepository('http://svn.automattic.com/wordpress-mu')
<jdub> 
<jdub> (which is the same as what i get with merge)
<jdub> oh, rm
<jdub> shared repo
<jdub> jelmer: ping
<jelmer> 'morning jdub :-)
<jdub> hi :-)
<jelmer> The local repository has to be upgraded to a newer format ('bzr upgrade --dirstate-with-subtree')
<jdub> hrm, is there a reason why bzr upgrade doesn't change to that by default?
<jelmer> that format is only required by subtrees, which aren't the supported yet
<jelmer> and it's not the default format
<jdub> oh, another problem -> bzr-svn recommends bzr-rebase >= 0.2
<jdub> debian only has 0.1
<jdub> am i safe? :)
<jelmer> jdub: No, I'd recommend using the branch of bzr-rebase for now
<jelmer> also, it looks like gutsy is two releases behind for bzr-svn :-/
<jdub> i can just branch those into ~/.bazaar/plugins, right?
<jelmer> yep
<jelmer> lifeless: Any chance we can update that before gutsy?
<jdub> https://code.launchpad.net/~jelmer/bzr-svn/trunk <- this branch?
<jelmer> nope - that's the next unstable release series, 0.4 is http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<jdub> https://code.launchpad.net/~jelmer/bzr-rebase/trunk <- for rebase? :)
<jelmer> yup (-:
<jdub> ok
* jdub relieves his launchpad anxiety
<jelmer> I think lp:bzr-rebase and lp:bzr-svn as urls should work as well
<spiv> Yeah, they do.
<jdub> currently doing svn-upgrade, will report :-)
<jdub> boh
<jelmer> jdub: something broke?
<jdub> http://en.pastebin.ca/735991 <- yeah
<jelmer> thanks
<jelmer> jdub: Argh, this has actually regressed because I don't have rebase here locally so it's not running the testsuite.
<jelmer> jdub: I'll see if I can fix rebase and release 0.2 tomorrow. Should've been done earlier..
<jelmer> jdub: Should I email you once I get this fixed?
<jdub> not wildly pressing, i'm just pottering around with relaxing maintenance things atm 8)
<jdub> but i would like to do some more work on blogo some time ;)
<jdub> i guess the pressing part of it is that gusty could really do with this stuff updated
<jelmer> well, it needs to happen anyway and I keep postponing it
<jelmer> and yeah, would be nice to have it in gutsy
<jelmer> time for some sleep first though
<jelmer> g'night!
<jdub> ciao :)
<jdub> thanks again
<abentle1> jdub: in case it's not clear, dirstate-with-subtree is a watershed, and not currently supported.  So don't convert a shared repo to it unless all the branches are bzr-svn branches.
<jdub> abentle1: ah, ok. in this case, they are (or branches of bzr-svn)
<nick125> Is there a way to setup a centralized bzr repositority over HTTP without WebDAV?
<vila> nick125: for read-only access, yes, just serve the .bzr directory and you're done
<jelmer> james_w: were you working on git-like support for branches?
<hsn_> you mean more branches in one directory? thats pretty evil
<jelmer> hsn_: Yes, it is. I wouldn't want that to be in bzr as default (because it will be confusing for a lot of users)
<jelmer> but it can be pretty useful for C projects
<jelmer> or large projects
<jelmer> I now have 10 working trees, all of which take up a lot of space (C files and object files)
<hsn_> jelmer: dispace is cheap
<hsn_> human work isn't
<jelmer> Why does it cost human work?
<jelmer> also, disk space is actually a problem on my machine
<jelmer> 640 Mb per Samba tree * 10 trees = 6 Gb
<jelmer> that's a fair share of my 80Gb notebook disk
<luks> but do you always use only one branch?
<jelmer> no, I work on all of these in parallel
<luks> and how would you build them in parallel with git-like branches?
<hsn_> you can use shared repos
<luks> this is why I personally don't like it
<luks> I prefer to have multiple branches ready to use
<jelmer> hsn_: it's not the history that is the problem
<jelmer> it's the working tree
<hsn_> whats are benefits of git model vs lightweight checkouts and shared repo?
<jelmer> luks: when I switch, the build system takes care of building the few files that are different
<jelmer> hsn_: Each lightweight checkout is still 640 Mb for me
<vila> does that include uncommitted changes ?
<jelmer> vila: in git you have to commit changes before switching to a different branch, but I guess you could shelve them in bzr
<vila> how does that play with makefiles ?
<vila> every file which has a non-empty diff between branches get touched ?
<jelmer> yes, and rebuild
<vila> can't you just get that with the right merge commands ?
<jelmer> generally, I only tend to have a few percent of the files changed between branches
<jelmer> vila: you're right in that it shouldn't be too hard to implement
<jelmer> just changing last-revision of the working tree
<jelmer> and then updating the working tree
<vila> 'revert -r' followed by  'merge --remember' should address quite a good part of the cases no ?
<jelmer> I don't think you'd want to do a merge
<jelmer> there are also a couple of other things - such as being able to list the possible branches
<luks> what about tree-less branches + one checkout?
<vila> luks: that's what we are talking about
<jelmer> luks: that works, but impossible to push at once
<hsn_> you cant checkout into directory with checkout?
<vila> jelmer: I agree that the '-r rev' parameters should be assisted
<vila> jelmer: what do you mean 'impossible to push at once' you're pushing in one branch at a time
<james_w> jelmer: I was looking at it. It's not easy though.
<james_w> jelmer: (there is now git-stash to allow you to switch with changes in the working tree).
<jelmer> james_w: should be quite simple - what problems did you hit?
<james_w> jelmer: there are things like what it means to push in to a branch that is using this system, do you have a default thread that it goes to, or the one that is currently checked out.
<james_w> (I use thread to try and avoid overloading the branch term).
<james_w> and from the branch API it is hard to know what the operation is.
<jelmer> james_w: Is your work-in-progress published somehwere?
<james_w> jelmer: no, it's just playing around at the moment. Would you like to see it anyway?
<jelmer> james_w: yes, please
<james_w> http://jameswestby.net/bzr/threads/dev/
<james_w> There's no ui to it, just look at threads.py and tests/
<jelmer> thanks
<james_w> I'm not sure but I think it might need to provide a Branch, Repository and WorkingTree, CommitBuilder and others.
<james_w> or at least API changes may be needed.
<james_w> tests/test_threads.py is where the interesting stuff is.
<james_w> At the moment it is written for quilt style, but it could be adapted for git style.
<jelmer> hmm, I was thinking of something much simpler
<jelmer> UI only really, perhaps only a new branch format
<james_w> I would be interested in your ideas, I'm all for simplicity.
<bialix> jelmer: switch command in bzrtools -- may be this is answer for your question?
<jelmer> bialix: partially, I'd like to have the branches in one directory, otherwise it's impossible to propagate them
<bialix> I use repo-push plugin for this task
<vila> bialix, jelmer, james_w : It looks like you're all having specific  workflows that share many bits, that may be worth documenting if only to understand what can be reused and what should added to bzr (core or plugins)
<bialix> I don;t use switch, but use repo-push a lot to sync my branches at work and at home via USB d=flash disk
<vila> jelmer: Is that what you called 'impossible to push at once' ?
<vila> jelmer: just trying to understand
<jelmer> vila: there's no way to push a set of 10 branches to a remote machine at once
<vila> jelmer: only because you don't have the UI you mean ?
<Qhestion> has anyone used the bazaar plugin for eclipse?
<hsn_> :raises hand
<Qhestion> hsn: does it work? *sceptical look*
<Qhestion> oops, misspelled your name... for highlighting only: hsn_
<Odd_Bloke> Qhestion: It's still in alpha/beta, so probably suck-it-and-see is the only way you're going to find out whether it does what you need...
<Qhestion> wrong
<Qhestion> the other way is asking
<Odd_Bloke> Qhestion: The last commit to trunk was 2 days ago.  The odds of someone having used it in the last 2 days being in-channel to answer your question are fairly low.
<Qhestion> maybe
<Qhestion> but chances are
<Qhestion> and i didnt say "latest version"
<Qhestion> i just wanted an overall impression
<Qhestion> i mean - chances are that even the dev of it is here
<Qhestion> i alread had such situattions
<Odd_Bloke> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Qhestion> oh forgot that...
<Odd_Bloke> The dev is Verterok, who's not in channel ATM.
<Qhestion> ok, thank you
<Qhestion> but it anyway was just a try
<Qhestion> i think i will stick to the console and come back in half a year...
<Qhestion> this is what i know, and i know that works :)
<Qhestion> k, cu
<sri> yo
<hsn_> element tree is part of python2.5?
<nick125> hsn_: Yup.
<hsn_> i am updating wiki windowsinstall page to python 2.5, it seems to be easier
<hsn_> less packages needed than for python2.4
<schierbeck> jelmer: ping
<jelmer> schierbeck, pong
<schierbeck> can i ask you something about the viz?
<jelmer> sure
<schierbeck> it seems weird to me that one must specify the branch being visualized with set_branch()
<schierbeck> when will you ever use the viz without a branch?
<schierbeck> wouldn't it be more reasonable to specify it in the constructor?
<hsn_> maintainer of bzr for win32 around?
<jelmer> schierbeck: The idea is that eventually it should be possible to visualise a set of branches (like gitk --all)
<jelmer> hsn_: that's bialix I tihnk
<jelmer> schierbeck: but I don't think being able to pass it to the constructor is a bad idea
<schierbeck> jelmer: i'm looking at extracting the treeview into its own file
<schierbeck> and having to define a set_branch() there, too, seems a bit much
<jelmer> schierbeck: feel free to remove it if you think that makes sense
<schierbeck> ok :)
<ubotu> New bug: #152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [Undecided,New]  https://launchpad.net/bugs/152746
#bzr 2008-10-06
<tethridge> I'm trying to push my first branch to launchpad.  I've registerd a branch and now I'm trying to push it, but I'm getting an error that reads "bzr: ERROR: Transport operation not possible: http does not support mkdir()"
<tethridge> anybody know what I'm doing wrong?
<fullermd> You need to use bzr+ssh to push to launchpad, not http.
<beuno> tethridge, yes, you need to specify your Launchpad id with:   bzr launchpad-login <username>
<beuno> that will start using bzr+ssh instead of http (which is the default read-only)
<tethridge> that did the trick
<tethridge> thanks
<beuno> np
 * beuno is off for a run
<kees> in RCS and CVS, there are in-file ident tags ($Id, $Source, etc).  How can I get bzr to update these?
<kees> (i.e. the strings that "ident" looks file)
<fullermd> The phrase you're looking for is "Keyword Expansion".  There's no in-core support for it.
<fullermd> There's a proof-of-concept plugin floating around somewhere.  That keyword should bring it up.
<kees> fullermd: thanks, yeah.  the search terms were not obvious (id, tag, rcs) heh.
<fullermd> http://bazaar-vcs.org/KeywordExpansion specifically.
<kees> thanks.  I had just found it too :)
<markh> is support for platform-specific line endings (ie, windows line endings) still moving, or has it stalled?
<fullermd> I haven't heard anything about it recently...
<Peng_> Was it ever not stalled?
<markh> its a bummer as it prevents me from effectively using a launchpad mirror of a CVS branch on Windows - the "real" CVS trunk and the bzr branch aren't identical at all on my platform - every single file differs :(
<fullermd> Well, it was backfiring for a while.
<markh> in the short term, I wonder if I can convince launchpad to allow a branch to nominate the line-ending for such an import...
<fullermd> I dunno.  I thought at the end of the last spurt, the POC plugin for it was roughly completeish.  Not sure.
<markh> POC?
<bob2> proof of concept
<bob2> I thought the only issue was dumb editors destroying the existing line endings
<markh> right - the wiki at http://bazaar-vcs.org/LineEndings doesn't refer to an impl...
<bob2> so it seems a bit weird that the bzr import of a cvs branch is broken
<markh> right - how to change the copy in the working tree?
<markh> well - not "broken"
<fullermd> Well, either that, or Pinocchio On Crack   ;)
<markh> the cvs checkout on windows has \r\n, the bzr branch has \n
<bob2> weird
<fullermd> Anyway.  It might have been an actual bundle for bzr.dev instead of a plugin.  That would make it tougher to play with.
<markh> why is it wierd?
<markh> if I checkout on linux, the cvs branch has \n
<bob2> cvs is stupid like that
<markh> ie, cvs does have basic line-end translation
<markh> heh
<markh> or smart ;)
<bob2> bzr just faithfully copies it
<markh> I get the correct line endings
<bob2> so the bzr import should just have whatever was in the cvs repo
<bob2> and the only issue would be editors messing it up
<markh> the cvs repo stored \n IIUC
<markh> but I expect if the cvs import process was run on Windows, the bzr repo would get \r\n
<markh> assuming that import process just does a normal "cvs co" on the platform
<snova> i'm getting an error when i try to set my launchpad username
<markh> (ie, I expect that the cvs import process doesn't use the repo at all - it just uses whatever cvs checkout/export does on the platform - subtle but important difference)
<snova> can anybody help?
<bob2> snova: pastebin the error
<markh> snova: if you give us a clue *what* error, we might :)
<snova> where?
<bob2> paste.pocoo.org
<snova> it's a paltry two lines, going there now...
<snova> here: http://paste.pocoo.org/show/87187/
<snova> oddly enough, i can still push/checkout branches under my username (like ~snova/+junk/test)
<markh> it looks a little like curl-ca-bundle.crt can be found by pycurl
<markh> can't
<snova> i thought it had something to do with certificates
<markh> IIUC, that .crt file is full of certificates
<snova> might it be possible to download launchpad's certificate manually?
<markh> I think that file contains some top-level trusted issuers, which allows a whole lot of sites automatically
<markh> try executing with '-v', then looking in .bzr.log.  IIUC, there should be some messages about that .crt missing if that is the problem.
<markh> (probably even without -v - I'm not sure)
<snova> it doesn't look very useful. just the same error and a traceback
<fullermd> You could work around it by shutting off pycurl momentarily.
<snova> how?
<snova> i found a file on my system that might be useful: /usr/share/apps/kssl/ca-bundle.crt, which appears to contain a bunch of certificates
<fullermd> I'd do it just by chmod'ing away the pycurl module while doing it...
<fullermd> Hacky, to be sure.
<snova> i've done worse
<snova> what will bazaar do without pycurl? fall back to something else?
<fullermd> Yeah, it'll use urllib, which doesn't do cert validation (and thus won't fail from not knowing the CA)
<snova> i guess i'll find out -- oh, it worked now.
<snova> i'll try putting it back and seeing what happens -- how might i test it?
<fullermd> Normal operations you can force one or the other with URL decoration, but since you don't directly type the URL for lp-login...
<snova> i tried lp-login again (without arguments) and i got the same error. the configuration file is correct now, though.
<snova> i could just remove python-pycurl, nothing depends on it except a package i can get rid of anyway
<snova> i don't even know why i have it (the extra package, that is)
<snova> thanks everybody, removing the python-pycurl package worked
<snova> goodbye
<chandlerc> jelmer: any news on my segfault bug? its really blocking me currently
<kiko__> chandlerc: what are you getting a segv on?
<chandlerc> bzr-svn
<kiko__> chandlerc: crashing inside an extension?
<chandlerc> kiko: bug #276219
<ubottu> Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219
<chandlerc> its extra weird, the python wrapper is pulling a null pointer out instead of a valid C-string
<jelmer> chandlerc: just repleid
<jelmer> *replied
<markh> I guess it would be interesting to know if path starts out as the "impossible" value of NULL, or something in the frames called by that manage to set it.
<jelmer> Verterok|out: ping
<nbjayme> hello i have a question on the use of sftp.
<nbjayme> i have multiple priv keys and i want to use an identify file named launchpad.net.  how do I specify that in bzr push sftp ?
<nbjayme> like, i.e. -i <identity file> when using ssh.
<bob2> are you using openssh?
<nbjayme> i am under ubuntu ... yes i believe it's openssh.
<nbjayme> xubuntu (to be more correct).
<bob2> http://paste.pocoo.org/show/87195/ -> ~/.ssh/config
<nbjayme> thanks!  i'll try that. :)
<vila> hi all
<nbjayme> hello too. :)
<nbjayme> bob2 your config worked. thanks.
<bob2> great
<nbjayme> i tried uploading my branch but launchpad returned an error that mkdir is not allowed.
<nbjayme> i also done the bzr push bzr+ssh  but i am not allowed to create a directory.
<nbjayme> so, i cannot create a directory under trunk, noh?
<bob2> trunk is a branch?
<nbjayme> okay, thanks again bob2.
<jml> nbjayme: what's the exact error message that Launchpad gives you?
<nbjayme> here is bzr+ssh error:  ERROR: Generic bzr smart protocol error: bad response ("Not allowed to execute '/home/bzrrepo/bin/bzr serve --inet --directory=/ --allow-writes'.\r",)
<nbjayme> here is bzr push sftp error:  Permission denied: "/boi-php/trunk/boiChat": [Errno 13] mkdir failed
<nbjayme> this project can have multiple modules... boiChat is one.  I was thinking the trunk can accept multiple branch (like a shared repo).... may need to setup my local repo then to meet what's expected by trunk.
<jml> nbjayme: branches on Launchpad need to live in ~<username>/<project>/<branch-name>
<jml> nbjayme: if you aren't pushing to something that looks like lp:~foo/bar/baz (or bzr+ssh://bazaar.launchpad.net/~foo/bar/baz), then it's not going to work.
<nbjayme> jml, thanks.... i was able to commit using ~<username>.  will people that want to download the branch need to place ~<username>?
<jml> nbjayme: they'll need to use whatever username you used.
<nbjayme> okay. thanks much. :)
<jml> nbjayme: if you are the maintainer of that project, you can register that branch as the development focus
<jml> nbjayme: or as the branch for a release series
<jml> so then people can do: bzr branch lp:<project-name>
<nbjayme> jml... it's still all new to me though, sorry for newbie questions.  you mean I need to specify that by clicking "link the branch to this series"?  then they can do lp:<project-name>?
<jml> nbjayme: yes, if that series is the 'development focus' (i.e. trunk)
<nbjayme> thanks!  :-)  i've done it.
<jml> nbjayme: since most people will probably want to fetch trunk, this is Launchpad's way of making it more convenient.
<jml> nbjayme: it's one of my favourite features :)
<nbjayme> thanks so much.... will upload additional projects in the coming weeks. :-)
<vila> jml: sorry to bother you, but can you ping mthaddon about pqm being blocked
<vila> jml: by the way, did I thank enough for showing me iswitch ?
<james_w> hey vila
<james_w> iswitch?
<vila> james_w: iswitch is an emacs dwimmy package to change buffers, really handy
<james_w> ah
<vila> jfroy: ping
<Odd_Bloke> I have someone who wants to use bzr-svn on a Subversion working directory and be able to communicate commits to the server once he has access to it again.  Can this work?  If so, how?
<intellectronica> hya. i'm giving LP-hosted stacked branches a try. everything works fine, but i'm having problems when trying to submit to PQM
<Odd_Bloke> intellectronica: That _probably_ means that the bzr that PQM is using doesn't have a bzr that understands stacked branches.
<intellectronica> Odd_Bloke: i don't think that this is a problem with the PQM. i get the same problem when trying to branch back from the branch i pushed. i get 'Permission denied (publickey)'
<james_w> intellectronica: when you created the stacked branch did you use lp:whatever as the "stacked-on" url? Or did you use http://bazaar.lp.net/... ?
<intellectronica> james_w: i used lp:
<Odd_Bloke> intellectronica: "lp:" will probably have resolved to your bzr+ssh:// URL, which won't work for PQM.
<james_w> intellectronica: what I think has happened is that is translated to a bzr+ssh://intellectronica@ URI, which no-one else can access
<intellectronica> james_w: still, the push went fine, and LP shows me that it's there
<james_w> push from you may be ok, as you have access to both branches
<Odd_Bloke> intellectronica: Have you tried a pull from the http location of the branch?
<james_w> creating the stacked branch with http://... as the stacked-on URI may be worth a try
<intellectronica> so, problem solved. turns out i needed to specify my lp username in the URLs used in locations.conf (since it is different from my local username, which ssh would have used by default)
<intellectronica> bzr+ssh works fine after that, b.t.w
<Odd_Bloke> intellectronica: It might not for other people, FWIW.
<kiko> intellectronica, I find it interesting that launchpad-login doesn't fix that under the covers.
<kiko> intellectronica, I think it's worth reporting a bzr bug with lots of details and the workaround. I'll talk to martin about it
<intellectronica> kiko: indeed. it obviously does the right thing when i try to push, just not when i try to read
<kiko> exactly
<kiko> intellectronica, did you file the bug?
<intellectronica> kiko: not yet. will do shortly, though
<kiko> cool, I want to use it in a reply to salgado
<intellectronica> kiko: https://bugs.launchpad.net/launchpad-bazaar/+bug/279037
<ubottu> Launchpad bug 279037 in launchpad-bazaar "bzr tries using local username when reading from LP" [Undecided,New]
<jelmer> Odd_Bloke, hi
<Odd_Bloke> jelmer: Ho.
<jelmer> Odd_Bloke, What would be blocking me from using PQM with a git repo?
<Odd_Bloke> jelmer: I don't know, TBH.
<jelmer> Odd_Bloke, but on the PQM side of things?
<Odd_Bloke> jelmer: Not sure, I'll look into it in a while.
<Odd_Bloke> jelmer: If you look at Bazaar2Handler in pqm/__init__.py in the PQM source, that's all that is needed.
<jelmer> Odd_Bloke, ah, ok, that doesn't look too bad
<jelmer> Odd_Bloke, it looks like some of your branches are not yet merged - is that correct?
<Odd_Bloke> jelmer: http://bzr.daniel-watkins.co.uk/pqm/dependencies.png are the branches waiting to be merged. :p
<jelmer> Odd_Bloke, wow..
<jelmer> Odd_Bloke, is there an integration branch that contains all of them?
<Odd_Bloke> jelmer: Not yet, that's on my TODO list.
<Odd_Bloke> I'm getting "bzr: ERROR: exceptions.ImportError: cannot import name bisect_right" with a traceback whenever I try to run bzr.dev.  Any thoughts on what might be causing this?
<Odd_Bloke> Happens even with '--no-plugins'.
<nevans> I just used the rebase plugin (because rebase-push is the only bzr-svn workflow that puts all changesets into the svn-repo)... but it didn't rebase the first changeset.
<nevans> got a bunch of conflicts, but I resolved them rather than notice what had happened.
<nevans> so I can't run rebase-abort anymore
<nevans> is there an easy way to find the previous branch head (prior to rebasing), and get back to it?
<jelmer> nevans: "bzr heads" should give you a ist of heads
<nevans> jelmer, thanks.  running that now.
<nevans> jelmer: any idea why rebase might have missed a changeset?
<jelmer> nevans, what do you mean by first changeset exactly?
<nevans> running rebase 0.4.1 and bzr 1.7.1
<Odd_Bloke> Oh, epic fail.  I have a directory called 'bisect' in the directory I was running from, which happens to be a Python module. >.<
<nevans> I had three changesets in my branch that weren't in the parent... after the rebase, only two of them were rebased on top of the parent
<jelmer> Nephyrin, was one of them a merge revision perhaps?
<nevans> all of new/modified files in that first commit were lost
<nevans> jelmer, yeah, it was.
<jelmer> nevans, rebase skips merges by default
<nevans> ahhh
<jelmer> nevans, you can force it to rebase merges by using --always-rebase-merges
<nevans> yeah... I think I'll need to use that.  :)
<jelmer> rebasing a merge will potentially cause a lot of conflicts though
<nevans> I was merging from a third branch into a branch based off of svn-trunk
<nevans> then rebasing that branch against svn-trunk
<jelmer> Btw, rebase is not the only workflow anymore these days that makes all revisions end up in svn
<nevans> oh?
<nevans> cool... because using rebase just feels a bit weird.  :)
<jelmer> you can set push_merged_revisions = True; that'll push revisions that were merged in branches/FOO
<nevans> interesting.
<nevans> I'll play around with that.
<nevans> thanks!
<nevans> jelmer: any news on #248289?
<nevans> that ticket is why I originally switched to the rebase-push workflow...
<nevans> https://bugs.launchpad.net/bzr-svn/+bug/248289 (concurrent access problems)
<ubottu> Launchpad bug 248289 in bzr-svn "concurrent access problems" [Medium,Triaged]
<jelmer> nevans, no, that requires changes in bzrlib
<mdmkolbe> Help! bzr complains that it can't aquite lock "(remote lock)".  I think it broke when the network died durring a commit.  How do I fix it?
<jelmer> mdmkolbe: bzr break-lock <url>
<mdmkolbe> jelmer: thanks, that fixed it.  Yea!
<clemente> Hi, I'm just trying to continue the patch I did on another computer. And I try on a branch of lp:bzr :  bzr pull  "http://bundlebuggy.aaronbentley.com/download_patch/%3C87abdj9e18.fsf@yahoo.com%3E"
<clemente> And I get: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<clemente> How could they diverge?
<clemente> And I don't want to merge, only to pull
<james_w> clemente: if lp:bzr has moved on in the meantime they will be diverged
<james_w> clemente: if you don't have any local commits on top of lp:bzr then "bzr pull --overwrite" will do what you want
<jelmer> hmm, somebody needs to give pqm a kick
<clemente> james_w: ok, with --overwrite it is applied (because the still applied cleanly). That's what I needed; thanks
<clemente> If a patch can apply cleanly (with no conflicts), shouldn't pull really pull it even if the branches diverged? (I think there was some discussion about that)
<fullermd> Pull doesn't apply patches.
<fullermd> Pull syncs _branches_.  You can't sync to something that's not a superset of you without losing data.
<fullermd> Hence, requiring forcing.
<clemente> fullermd: I understand that a bit, but I think an unexperienced new user can see this as a limitation
<clemente> because... sometimes you can sync without losing data
<clemente> It is like applying a patch and then commiting afterwards
<fullermd> But then your branch isn't synced.
<clemente> If the remote changes are different to the local changes, a clean merge is possible
<fullermd> pull makes it so that the branches are the _same_, not the files.  If 'log' doesn't show EXACTLY the same thing on both sides, the branches are different.
<fullermd> If you want to merge, then you use merge.
<fullermd> In git, they're not so distinguished; you have merge which fast-forwards (pulls) if it can, or falls back to merging if it can't.
<fullermd> But they're distinct actions, which is why bzr makes them different commands.
<clemente> fullermd: yes, git confused things for me still more
<fullermd> pull means "update my _mirror_ of that other branch".  merge means "bring in the _changes_ from that other branch".
<clemente> But --speaking as a user who looks at the interface-- merge joined my branch with the trunk; what I was looking for is to _bring the changes_ but without joining the two branches
<clemente> Now I know that it's bzr pull --overwrite
<luks> not really, pull --overwrite will get rid of your local revisions
<clemente> And how can bzr otherwise bring the changes without joining the branches?
<clemente> Well, for the patches it would be âbzr patchâ.... but for the new _revisions_?
<luks> if you care only about changes, not the original revisions there is bzr-rebase
<luks> if you care about the revisions, there is no way
<luks> pull --overwrite is something you want to use _only_ if you want a mirror of the pulled branch
<clemente> I wanted to do this only so that Bundle Buggy could detect that I superseded my own patch (written in another computer). I assume this objective will be difficult...
<luks> if you have two diverged merge requests (branches), and want BB to recognize one of them as superseeded, you need to merge
<luks> or pull the other branch before committing to the new branch
<clemente> luks: you mean pull --overwrite from the patch, right?
<clemente> The two branches (on each computer) are disconnected
<luks> clemente: the patch represents the branch
<clemente> Thanks, that was very useful
<clemente> I have a hard time trying to correlate bzr commands/plugins (for instance, rebase) with the actions they do in fact to the revision graph shown by âbzr visâ
<clemente> I would like a âbzr visâ where you could edit/drag/cut/copy/... nodes :-)
<mathiaz> james_w: Hi - I'd like to get your input on using bzr branches for packaging. Here is the situation - the dovecot packaging branch in debian is in svn.
<mathiaz> james_w: here: svn://svn.debian.org/svn/collab-maint/deb-maint/dovecot/branches/1.1-work/debian
<mathiaz> james_w: I'd like to create an ubuntu branch that has the structure ubuntu/debian/
<fullermd> clemente: There are few manipulations of nodes that you can do, without replacing the nodes.
<mathiaz> james_w: the problem is that the debian svn repository has just the files in debian/ - it doesn't have a sub-directory debian/ with the files in it.
<clemente> fullermd: if you start from the top, this doesn't affect the older nodes (below)
<fullermd> clemente: rebase is for doing those sort of changes
<mathiaz> james_w: so how can I structure an ubuntu/ directory that would have a debian/ branch in it ?
<clemente> fullermd: For instance, what I wanted was just to âcutâ the wire which connected my branch with the trunk branch...
<clemente> fullermd: ok, I should learn it
<fullermd> Well, there aren't any "wires" per se connecting branches.  The important thing is the revision graph.
<fullermd> Essentially, you can add nodes into the top of it; pretty much any other action is destructive to one degree or another.
<clemente> ok, I wanted to cut the âedgeâ which connected the latest revision nodes of each branch (mine, and trunk)
<clemente> There are many operations on the top nodes which could be represented graphically and through drag & drop
<fullermd> Well, you can represent a lot graphically.  You're more limited in what you can do within the constraints of the bzr revision graph   :p
<fullermd> You can't create a new node "underneath" an existing one, for instance.
<clemente> That would replace all the upper nodes
<fullermd> Right.  You'd have to create a whole new set of all the nodes after that point.
<fullermd> Which means that everybody else's copy of the branch would now be incorrect, and need to be force-sync'd.  Any work they'd done on top of those old revisions would have to be recreated or it couldn't be merged or kept up to date.  etc.
<fullermd> (which isn't to say it's necessarily or always a Bad Idea; just that it has reprecussions, so it needs to be done deliberately)
<james_w> hey mathiaz, "bzr join" can do that I think
<james_w> mathiaz: I've never used it though
<clemente> fullermd: I suppose this graphical revision editor would be too ambitious to be placed in the bug tracker as a RFE... :-)
<fullermd> Well, in thse sense that rather open-ended wishlist items don't fit the bugtracker well...
<fullermd> It could be a handy thing to have around.  Probably more "useful" to define a full rewriting engine and language, then write a GUI frontend for it.
<fullermd> I've mentally fiddled with a language from time to time for it.
<fullermd> It's definitely something that's needed.
<mathiaz> james_w: hm - it kind of works. I think I was looking for something similar to svn externals definition.
<clemente> That's very interesting. The revision specification has already many ways to locate revisions, but --I think-- not to manipulate them
<mathiaz> james_w: the problem is that I cannot add the files in debian/ to the ubuntu branch.
<mathiaz> james_w: I've joined to the debian/ branch with the --reference option.
<fullermd> Yeah, that's what revspecs are for; ways of specifying revisions   :)
<james_w> mathiaz: yeah, --reference is more like svn:externals, but it's experimental, so I would recommend it if this is more than an experiment.
<james_w> mathiaz: I hope it becomes supported soon.
<fullermd> A good general mechanism for rewriting history is certainly necessary.  But it's also necessarily an extraordinary action.
<mathiaz> james_w: right - I'm working on the dovecot package for now.
<mathiaz> james_w: whenever I touch a package that is maintained in svn in debian I look into ways to create an ubuntu branch in bzr.
<mathiaz> james_w: while still making it easy to forward patches to debian/.
<mathiaz> james_w: in this case it's a bit tricky as it's a package in experimental that doesn't use a pkg-name/debian/ structure.
<mathiaz> james_w: I'd like to end up with an ubuntu branch I could use bzr bd with.
<james_w> mathiaz: I'm glad you are trying these things. It's a shame I often don't have a good answer for you.
<mathiaz> james_w: but I don't see how I can connect the debian branch with ubuntu/debian/
<mathiaz> james_w: ok - thanks for the help. I'll play with this a little bit more.
<james_w> there's the merge-into plugin, which is similar to "bzr join" without --reference, but I don't know if it will have a benefit over "bzr join" for your case.
<james_w> mathiaz: I'm interested by "the problem is that I cannot add the files in debian/ to the ubuntu branch." Could you expand?
<mathiaz> james_w: http://paste.ubuntu.com/54737/
<mathiaz> james_w: and that's when I try to join the subtree: http://paste.ubuntu.com/54738/
<james_w> mathiaz: can you try "bzr join" without --reference please?
<james_w> mathiaz: I believe it still allows you to "bzr pull" later
<mathiaz> james_w: http://paste.ubuntu.com/54740/
<mathiaz> james_w: well - what I'd like to be able to do is also bzr diff in debian/
<mathiaz> james_w: and get the diff with the debian svn branch
<james_w> mathiaz: hmm, yeah, I guess that "bzr diff -r branch:svn://..." might work, but I don't really know
<james_w> mathiaz: that looks sensible
<mathiaz> james_w: hm - bzr diff --old seems to almost work
<james_w> mathiaz: confusing but sensible
<mathiaz> james_w: hm - bzr  merge doesn't work once I've joined the debian branch.
<james_w> mathiaz: are you in ./debian?
<mathiaz> james_w: yes - it fails with an error about Key 'new-2' not found
<mathiaz> james_w: http://paste.ubuntu.com/54741/
<james_w> mathiaz: I would guess it's a bug then
<james_w> mathiaz: rather than not being supposed to work
<james_w> mathiaz: sorry about that, it looks like you can't really do what you want currently
<mathiaz> james_w: oh well - this not the end of the world. I'll survive :D
<james_w> you always do :-)
<clemente> What format does tree.set_parent_ids([....]) expect?
<clemente> Is that the ârevision graphâ?
<james_w> clemente: a list of revision ids
<james_w> which are strings
<clemente> and what relation is there between the elements of that list?
<clemente> Is that function declaring that each left-most is parent of the right-most ?
<james_w> the left-most is the first item in the list
<james_w> the right-most is the last item
<clemente> And each revision is the parent of the revision right to it
<clemente> So ["a","b","c"] is a tree with 3 revisions, right? The first one (in time) was "a", then came "b", then came "c"
<james_w> no, it's just about the parents of the working tree
<james_w> [] is the tree before any commits
<james_w> ["x"] is a normal tree
<james_w> ["x", "y", ...] is a tree with pending merges
<clemente> ouch! I thought that all parents were listed there. So that's why it's more normal to list just one revision there. Thanks
<clemente> Only parents of the working tree. Not the parents of those parents, etc.
<james_w> yup
<clemente> A tree has a revision as its parent. And which parent has that revision?
<clemente> Does it matter for tree.set_parent_ids()?
<james_w> it doesn't matter
<james_w> the parent(s) are stored as part of the revision
<james_w> or rather the revision tree, which is referenced by the revision, I think
<clemente> I always think that I must describe the whole revision graph, from [] to any revision
<james_w> that only really happens in tests I think
<clemente> I'm seeing this on a test I'm writing: bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_with_utf8_symlink(RemoteBranchFormat-default) is leaking threads among 2 leaking tests
<clemente> The tests are failing and I throw KnownFailure
<clemente> Is something wrong?
<clemente> Ran 7 tests in 0.661s.  OK (known_failures=5).  The other 2 âleak threadsâ...?
<james_w> that's not necessarily your test
<james_w> if you comment out your test do they go away?
<james_w> I'm not even sure whether it's deterministic
<clemente> It's my test. âI'm leaking threadsâ if I do just âtree = self.make_branch_and_tree('tree1')â but not if I do âprint "a"â
<clemente> Mmm... not only my test. Others do it too:  ./bzr selftest test_sprout_from_any_repo_revision
<clemente> bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_from_any_repo_revision(RemoteBranchFormat-default) is leaking threads among 2 leaking tests
<stefanlsd> Does anyone know why this doesnt work - bzr branch lp:~ubuntu-dev/mplayer/ubuntu     -  It just hangs and doesnt download anything... - would it be a bzr thing with big repo's?
<clemente> stefanlsd: works here. Try pressing ENTER several times (>4). Maybe you are also experiencing bug 246052
<ubottu> Launchpad bug 246052 in bzr-dbus "Bazaar halts and silently expects input from STDIN" [Undecided,Confirmed] https://launchpad.net/bugs/246052
<james_w> clemente: hmm, self.make_branch_and_tree shouldn't leak threads, if it is, it's not your fault
<clemente> stefanlsd: in any case, to see what the bzr process is doing, you can attach to it with: strace -p pid_of_the_bazaar_process
<stefanlsd> clemente: thanks. thats useful - repeating this over and over http://pastebin.ubuntu.com/54761/
<clemente> stefanlsd: the send() and recv() show that it's downloading things from the net
<clemente> send("GET /") is requesting
<clemente> So it is just slow...
<stefanlsd> ok... heh. slow
<clemente> So that you can enjoy Bazaar longer :-)
<clemente> Bazaar could show more information during that time (or something else to read); maybe you can find or file a bug report about that
<stefanlsd> joys of being in south africa :)
<clemente> Ok, I wrote my second patch much faster than the first one; thank you for helping beginners to learn Bazaar :-)
<james_w> mathiaz: I just came across bug 203376, which I think is what you are hitting. It's fixed in 1.7, which unfortunately isn't in Intrepid
<ubottu> Launchpad bug 203376 in bzr "traceback when merging a branch with a 'bzr join'ed branch" [Medium,Fix released] https://launchpad.net/bugs/203376
<clemente> stefanlsd: by the way, the âbranchâ command I started when you said that, has finished right now successfully on my machine. 108 Mb
<mathiaz> james_w: ok. It turns out that I missunderstood the branch structure. The branch actually follows the pkg-name/debian/ structure :D
<james_w> heh
<mathiaz> james_w: so I've setup a merge mode for bzr builddeb.
<mathiaz> james_w: it's just that the svn branch has two other directories in addition to the debian directory.
<stefanlsd> clemente: aah. ouch.  mm.  is it possible for me to branch ignoring all previous changes history etc?   just want the latest so i can merge a 5 line patch into...
<mathiaz> james_w: that confused me.
<stefanlsd> clemente: i'm on 8mb so far :)
<james_w> ah, at least it works
<mathiaz> james_w: so now I've co the debian svn tree, and branched it to an ubuntu/ branch.
<mathiaz> james_w: I've setup merge mode for builddeb and added the configuration to the bzr branch.
<clemente> stefanlsd: mmm... from memory, I think there are âlightweight checkoutsâ to check out just the latest things, and âstacked branchesâ to have a part here and another remote (I think, please correct if needed)
<mathiaz> james_w: now I have to import the ubuntu changes.
<mathiaz> james_w: any suggestions ?
<james_w> does ubuntu touch anything outside of ./debian/ ?
<mathiaz> james_w: let me check that
<clemente> clemente: probably with âstacked branchesâ you could do that. Although I never used them
<clemente> clemente: stop talking to yourself!
<james_w> mathiaz: it's not easy though
<james_w> mathiaz: I don't think I can offer you more that diff+patch or equivalent currently
<clemente> stefanlsd: see ./bzr help branch   on bzr >=1.6 for --stacked
<mathiaz> james_w: right - I may try to use loom again
<stefanlsd> clemente: yeah. reading about stacked right now. sounds interesting...
<jelmer> chandlerc: ping
<clemente> After âbzr selftestâ:  Ran 14132 tests in 956.732s.  FAILED (failures=37, errors=43, known_failure_count=27)
<clemente> Is this the normal state? I mean failures!=0
<james_w> no, shouldn't be
<james_w> if the "./bzr" you said a moment ago means you are on linux at least
<james_w> windows may have that, I'm not sure
<clemente> yes I am
<james_w> yeah, should be 0 failures
<james_w> PQM tries to ensure that
<clemente> Most of them are like:
<james_w> platform differences etc. can mean that it's not always 0 on your machine
<clemente>     self.run_bzr('patch --silent mypatch')
<clemente> AssertionError: Unexpected return code
<clemente> not equal:
<clemente> a = 0
<clemente> b = 3
<james_w> ah, you might like to run the tests with --no-plugins
<james_w> assuming that you aren't testing a plugin
<clemente> Aren't plugins required to pass tests?
<james_w> shouldn't be
<james_w> it won't load the tests of the plugins either
<james_w> and nothing in bzr core should rely on a plugin being present
<clemente> I only had 2: bzr_push_and_update  bzr_rebase
<jelmer> clemente, patch is in bzrtools
<clemente> jelmer: mmm... do I have bzrtools installed? :-)
<clemente> I think not
<clemente> Does it mean that if I add it to my Bazaar, the bug will disappear?
<jelmer> clemente, It appears like you have bzrtools installed
<jelmer> clemente, does "bzr plugins" list  bzrtools?
<clemente> jelmer: yes... But I don't know where did it find it
<clemente> Not in ~/.bazaar/plugins
<jelmer> clemente, in the system folkder perhaps?
<clemente> probably. I thought that if I ran bzr like ./bzr, the system folder wouldn't be read
 * clemente has bzrtools in /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools
<stefanlsd> is there a suggested ppa for 1.7?
<clemente> Ran 13889 tests in 954.235s. OK (known_failures=27). 862 tests skipped   <== with --no-plugins. Runs as expected
<clemente> what's a PPA? :-)
<james_w> stefanlsd: the ~bzr one I expect
<clemente> Ok, Personal Package Archive
<clemente> Only for Debian?
<stefanlsd> mmm. looks like..  https://edge.launchpad.net/~bzr/+archive
<clemente> and Ubuntu, etc?
<james_w> clemente: just for Ubuntu currently
<jelmer> lifeless, 'morning
<lifeless> hi jelmer, how are you?
<jelmer> lifeless, Good, thanks
<jelmer> just got "bzr svn-serve" working
<lifeless> schweet
<james_w> hey lifeless, have you had a chance to review my config-manager patch?
#bzr 2008-10-07
<Leefmc> Question: How do you check to see if your local branch copy of a project is current?
<jml> so, I wrote a couple of Bazaar commands over the weekend. I'd like it if someone could look over the code and tell me if I'm doing anything gratuitously stupid: lp:~jml/+junk/bzr-establish
<Leefmc> Without actually merging
<jml> Leefmc: bzr missing, I think.
<Leefmc> nice, thanks
<jml> Leefmc: or you could do 'bzr merge --preview'
<Leefmc> gotcha
<Leefmc> Now if i have a /trunk and a lightcheckout of /trunk at /wrk, and im _in_ wrk, will merge commands and whatnot mess up my light checkout? In otherwords, do i need to do all merge previews and merges in /trunk and not /wrk? (ie, merge in trunk, and update my light checkout.. or something.)
<bob2> they'll modify the checkout
<bob2> and if you commit, modify /trunk
<Leefmc> bob2: Ok i think i understand, but is that a good thing or bad thing? Is merging from the server to the working branch (lightcheckout) /wrk a bad thing? Should that server/client transactions be done in the real branch (/trunk)?
<bob2> no, it is fine
<fullermd> You can't merge into a branch per se; only into a working tree.  The working tree colocated with the branch isn't any more "real" than any other.
<markh> Does 'UserWarning: lock on <open file u'.../.bzr/checkout/dirstate', mode 'rb' at 0x0301BF50> not released' imply I've taken a lock on a tree object and not explicitly unlocked it?  Or maybe a branch object?  Any other clues?
<spiv> markh: that you've taken a lock on a tree and not released it, yes.
<markh> spiv: thanks
<markh> are there any bzrlib api functions that implicitly take a lock for you and expect you to release it?
 * markh wouldn't have thought so...
<fullermd> lifeless: Can you elaborate a little on what that means re manually zeroing errno?
<spiv> markh: not that I can think of
<lifeless> fullermd: errno = 0; retvalue = readdir(handle); if (!retvalue) { if errno == XXX ()...
<jam> markh: I think DirState.initialize and maybe a couple others, but generally, no
<spiv> markh: not sure if you're already considering this, but it could be a lock_read rather than a lock_write.
<LeoNerd> .oO( Why did I read that as  DireStraits ?)
<spiv> LeoNerd: because you're dreaming about getting Money for Nothing? :)
<lifeless> spiv: its the chicks; its always the chicks
<markh> jam: thanks.  All the locks I can see correctly use finally, so its something subtle.  I think I'm getting closer via 'print' debugging :S
<fullermd> lifeless: Mmm.  Does readdir() even set errno?
<lifeless> fullermd: is that rhetorical?
<fullermd> Mmph.  Blah, need to fix that manpage   :|
<fullermd> I hate functions like that   :|
<lifeless> fullermd: apue recommends this for all C library functions - set errno before calling if you want to consult it after for any reason other than 'I already know an error has occured'
<lifeless> fullermd: its the 'NULL -> EOF || ERROR' that makes readdir suck in this case
<fullermd> Yah.  There's a half dozen functions with those sorta stupid dual meanings.
<fullermd> I don't recall that suggestion in the book, though.  I don't think I've seen such a thing recommended elsewhere.
<lifeless> it's not prhased quite like that
<lifeless> quoting mwhudson quoting it
<lifeless> "There are two rules to be aware of with respect to errno.  First, its value is never cleared by a routine if an error does not occur."
<LeoNerd> That's not quite always true. There are a few functions that will zero it first
<lifeless> well, eratta -> the author :P
<fullermd> Generally, because it internally calls one of those stupid ambiguous functions.
<fullermd> Wow, I've got a receipt for a muffler I bought 10 years ago serving as a bookmark in it, too.
 * fullermd sighs.
<fullermd> It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout   :(
<poolie> lifeless, why would you want to check errno if an error has not occurred?
<poolie> i thought it's value was undefined then
<fullermd> poolie: Because some functions (like readdir()) have ambiguous returns.
<fullermd> It returns NULL for both "Done" and "Oops"
<poolie> ah, i see
<poolie> that's pretty crazy
<poolie> istr there are other routines which tread on errno - changing the value from 0 even if an error did not occur
<poolie> because one occurred at a lower level
<fullermd> Lots of them do.
<fullermd> You just have to know which of them have ambiguous returns.
<jml> spiv: just email bugs to me.
<spiv> jml: but how will I know what their Status and Importance are? ;)
<jml> spiv: The planning committee will inform you in due course
<lifeless> argh
<lifeless> jelmer: please please please please please please please please
<lifeless> jelmer: stop bzr-svn bitching about versions ? kthx
<jelmer> lifeless, uhm
<jelmer> lifeless, when does it do that?
<lifeless> $ bzr info
<lifeless> bzr-svn is not up to date with installed bzr version 1.8dev.
<lifeless> There should be a newer version of bzr-svn available.
<lifeless> bzr: ERROR: Version mismatch
<jelmer> it already doesn't if you're running a development (e.g. not released) version
<lifeless> jelmer: I run whatever branch you tell me to
<lifeless> jelmer: till it breaks, then I generally remove it until I actually need it
<jelmer>     if (bzrlib_version in desired or
<jelmer>         ((bzrlib_version[0], bzrlib_version[1]-1) in desired and
<jelmer>          bzrlib.version_info[3] in ('dev', 'exp'))):
<jelmer>         return
<jelmer> lifeless, what bzr-svn branch are you running?
<lifeless> I don't know, I removed the symlink already
<lifeless> sorry
<lifeless> I have a trunk, 0.3, 0.4
<lifeless> trunk was most recently pulled into
<jelmer> 0.3 is waay outdated (and would rightly warn about being incompatible), the other two are marked as being compatible with bzr 1.7
<lifeless> http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/
<jelmer> so shouldn't warn if you run bzr 1.8dev
<lifeless> jelmer: I should note, I don't pull plugins routinely
<lifeless> jelmer: I bet if I pull and build it will get your update to say 1.7 is ok
<lifeless> 2008-09-24 10:44
<lifeless> is the last date on the trunk dir
<jelmer> the latest revision should be from about 10 hours ago
<lifeless> sure
<lifeless> I'm not saying you haven't updated it to say 1.7 is ok
<poolie> that's interesting, you can using sigaction to say that system calls should be automatically restarted after particular signals
<jelmer> ah, sorry
<lifeless> I'm saying that *I haven't updated* and I wish it would not force me to to shut it up
<poolie> it seems like this would fix bug 173007 for instance
<ubottu> Launchpad bug 173007 in bzr "SIGQUIT debugging breaks networking" [Medium,Triaged] https://launchpad.net/bugs/173007
<jelmer> lifeless, so it sounds like you should update :-)
<jelmer> lifeless: There's no easy way to warn lazily
<lifeless> jelmer: uhm, thats the point, it interrupts workflow to force that, for instance on a train its hard
<lifeless> jelmer: sure, check the api minimum version rather than the bzrlib version
<lifeless> jelmer: and ask for module specific versions for more precise api's that you depend on
<lifeless> thats what we wrote that stuff for, to stop bzr-svn and bzrtools having to be so whingy
<jelmer> lifeless, what APIs have a separate version though?
<lifeless> there is no evolution at the moment because you're checking the bzr command version not the library api compatibility version; and we're not being granular about the library because noone is using it
<lifeless> start using granular apis and tell me what you're using and we'll start being explicit about those modules
<lifeless> but please don't claim a better way isn't possible - we discussed this, came up with a solution, I wrote the bzr end, and nothing has happened since
<jelmer> I'm claiming bzr-svn can't do better than this at the moment
<jelmer> I'll happily use other APIs that are available when they're there
<jelmer> and matter
<lifeless> import bzrlib.api
<lifeless> api.require_api(bzrlib.repository, (1, 6))
<lifeless> the api is available
<jelmer> ok, fair enough
<jelmer> please file a bug
<lifeless> done
<poolie> lifeless, i fixed 279381, and found quite a nice other bug right next to it
<jelmer> lifeless, just tried it out
<jelmer> lifeless, require_api() doesn't allow multiple versions
<jelmer> lifeless, which makes it impossible for bzr-svn to claim support for bzr 1.6 and 1.7
<jelmer> bug 279447
<ubottu> Launchpad bug 279447 in bzr "bzrlib.api.require_api() doesn't allow multiple versions" [Undecided,New] https://launchpad.net/bugs/279447
<jelmer> lifeless, it also doesn't allow bzr-svn to provide any information about which API versions it itself provides, e.g. new arguments to functions can break code that calls out to bzr-svn
<lifeless> jelmer: so for the former
<lifeless> jelmer: are you doing conditional stuff in bzr-svn?
<lifeless> jelmer: or is it just that the bzrlib api update wasn't granular enough?
<jelmer> lifeless: both
<lifeless> for the latter I'm not all that concerned, once we know what you're using and have api versions in place it should stop being an issue
<lifeless> erm
<jelmer> yes, but that will still hurt people in the mean time
<lifeless> for 'wasn't granular enough' ^
<jelmer> I run both bzr.dev and bzr 1.7 with the same bzr-svn
<lifeless> jelmer: secondly, it raises incompatible version - you can probe twice
<lifeless> try:
<lifeless>     api.require_version()
<lifeless> except IncompatibleApi:
<jelmer> using bzrlib.api.require_api() will break
<lifeless>   api.require_version()
<lifeless> we can add a require_any_version(object, version_list) if you like
<jelmer> that would be nice, otherwise I have to add utility functions that myself
<lifeless> jelmer: as for "doesn't allow bzr-svn to provide any information about which API versions it itself provides" - I'm not sure what you mean there
<jelmer> lifeless, If a new argument is added for e.g. Branch.update_revisions(), does that mean the minimum_api_version and api_version are both updated?
<jelmer> even if a default value is set for that argument?
<lifeless> jelmer: yes
<jelmer> ok, that addresses my concern
<lifeless> jelmer: we can also look at being more precise
<lifeless> jelmer: e.g. we could have bzrlib.branch.client_api and bzrlib.branch.provider_api
<lifeless> jelmer: the big problem is that noone is using this stuff
<jelmer> another thing is that the error message from require_api() is not shown to the user - bug 279451
<ubottu> Launchpad bug 279451 in bzr "IncompatibleAPI error should not be masked by "could not load plugin error"" [Undecided,New] https://launchpad.net/bugs/279451
<lifeless> jelmer: so I can write tweaks to it and it still won't fit what you need: you have to tell us, and I will fix the things you tell me, and we'll iterate
<lifeless> jelmer: I'll add a multi-version require
<lifeless> I'm not sure about the second, it sounds like the could not load plugin error hack is broken
<lifeless> or perhaps 'import foo' is translating the error to ImportError
<jelmer> I just get "Unable to load plugin 'svn' from '/home/jelmer/.bazaar/dev-plugins'" if IncompatibleAPI is raised by bzr-svn
<jelmer> lifeless: Thanks - I'll happily migrate once it's at the same level as it is atm
<lifeless> jelmer: try python -c 'import bzrlib.plugins.svn'
<jelmer> bzrlib.errors.IncompatibleAPI: The API for "<module 'bzrlib.repository' from '/usr/lib/python2.5/site-packages/bzrlib/repository.pyc'>" is not compatible with "(1, 7)". It supports versions "(1, 7, 0)" to "(1, 7, 0)".
<lifeless> jelmer: ok, so its the bzrlib wrapper that needs tuning
<lifeless> poolie: whats the standard for bazaar plugin maintainers now?
<poolie> a high standard :)
<lifeless> I mean
<poolie> more specifically?
<lifeless> what group
<poolie> should they join on launchpad?
<lifeless> no
<lifeless> what group should be the maintainer for a new plugin
<lifeless> whats the meta group, is it still 'bzr' ?
<lifeless> or is it different
<poolie> launchpad.net/~bzr explains that ~bzr is the overall thing, ~bzr-core is for just bzr itself
<poolie> therefore, plugins can either get their own group of which ~bzr is a member, or just be owned by ~bzr
<poolie> lifeless, speaking of (vaguely) this kind of thing, you have an approved patch "make dist includes plugins"
<poolie> should we just do it, or withdraw the patch?
<lifeless> http://bazaar-vcs.org/BzrMigration doesn't mention lp's code import service; hmm
<lifeless> poolie: there is a note in the comments/thread/etc about that patch, it doesn't run setup.py for plugins, so e.g. bzr-svn will fail
<poolie> ok
<lifeless> I said in the thread that I might get back to it 'eventually' but that we probably need that to go forward
<poolie> does that mean we can use it but just not include bzr-svn?
<lifeless> and if someone else wanted to that would be loverly
<lifeless> poolie: yah, anything trivial will just work
<lifeless> poolie: 'trivial' -> bzrtools, bzr-loom, etc
<lifeless> mwhudson: oh lol; when will launchpad support --development2 ? :>
<mwhudson> lifeless: i sent you an email about that
<lifeless> mwhudson: did you? cool
<lifeless> I have lots of mail
<poolie> could i beg a review from someone for the bug 279381 fix so it can go in 1.8rc1
<ubottu> Launchpad bug 279381 in bzr "_readdir_pyx.pyx in python 2.5 causes errors with bzr" [High,In progress] https://launchpad.net/bugs/279381
<lifeless> mwhudson: any hint on finding it?
<mwhudson> lifeless: well, not really, but i sent a mail saying that something like bazaar.edge.launchpad.net would make it a lot easier
<lifeless> fullermd: https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk
<lifeless> fullermd: I'm just about to 'upgrade' it to pack-0.92
<lifeless> fullermd: but if you're in the bzr group you can read it direct from the writable area
<fullermd> Huh?
<lifeless> fullermd: ?
<fullermd> In reference to what?
<lifeless> 12:25 < fullermd> It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout   :(
<lifeless> fullermd: ^
<fullermd> Oh   :p
<fullermd> Yeah, I'm still short a month and a hundred gigs of space to do the conversion...
<lifeless> fullermd: you don't need to
<lifeless> fullermd: install that plugin
<fullermd> Yah, but it offers me conversion options, is my point   :p
<lifeless> fullermd: thats to be helpful
<lifeless> fullermd: it will stop the confusion though
<fullermd> Well, ending the use of CVS will do that too   :)
<fullermd> It's the VCS version of bug 1 after all.
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Won't display info)
<lifeless> lol
<lifeless> anyhow, quick hack done, install it or not :P
<lifeless> but don't complain about taking 30 seconds to realise its CVS in future :>
<lifeless> mwhudson: is there some way to trigger mirrors yet ?
<poolie> spiv, still here?
<mwhudson> lifeless: the api might work at last, i haven't tried for a while
<lifeless> https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk
<lifeless> its hosted, pack-0.92 *now*
<spiv> poolie: yeah
<lifeless> been > 5 minutes, no change
<poolie> could you read http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480810062029v75a37f54qb79c168f3b81cab2%40mail.gmail.com%3E for me quickly?
<lifeless> poolie: looks wrong to me:
<lifeless> poolie: EINTR is ctrl-C yes?
<poolie> no, that's sigint
<lifeless> I thought it was one of those dual-arrival-path things
<lifeless> like SIGPIPE/EPIPE
<poolie> http://www.wlug.org.nz/EINTR
<poolie> it will happen if for example somebody suspends the process or resizes the window while you're in that system call
<lifeless> it looks like you have altered ENOENT's behaviour
<poolie> i don't think i did, but i do notice that it's inconsistent with the comment
<poolie> i think that in both the before and after versions, we terminate the loop successfully on getting enoent
<spiv> lifeless: the ENOENT behaviour looks the same to my eyes
<spiv> i.e. ENOENT -> continue
<lifeless> bb:approve
<poolie> i inverted the sense of that test for (subjective) clarity
<lifeless> spiv: continue will exit the loop, I think poolie is right it was inconsistent with the comment
<lifeless> mvo: hi1
<poolie> so the comment should be s/swallow this and continue/treat this as the end of the directory
<spiv> poolie: I also voted bb:approve, but technically it should bb:tweak because I pointed out an unnecessary semi-colon ;)
<lifeless> poolie: actually I suspect all those special cases were due to the missing errno=0
<poolie> linux doesn't document that it can happen and http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html is unclear about how it should be handled
<poolie> the eintr thing is definitely wrong and potentially quite scary
<poolie> as i said
<poolie> anyhow thanks
<mvo> hey lifeless
<lifeless> I don't know that EINTR can happen here; it backs onto getdents - Id need to read through
<lifeless> but its not a bad condom to have
<lifeless> hi mvo
<lifeless> I saw your mail, I don't have any handy suggestions, that looks like storm complaining about something
<mvo> lifeless: thanks, I had hoped you had some sort of magic bullet. I look into it again then (squeeze it in between the ubuntu beta bug squashing)
<poolie> i wonder if i should just delete the enoent case
<poolie> neither treating it as eof (and potentially missing things) or retrying (and spinning) is very desirable
<lifeless> poolie: I suggest not at this point, rather get this change in
<lifeless> poolie: and do a test branch people can test with other changes; pqm is not a good assessor for this
<lifeless> is 1.8 still open ?
<lifeless> poolie: ^
<poolie> yes
<poolie> but i'm planning to start making it soon
<lifeless> I'm asking because I've got a little api patch for jelmer
<lifeless> I don't care if it goes in 1.8/1.9, but the docstring needs a version :P
<lifeless> I love bzr-search sometimes :)
<lifeless> :!bzr search -d ../bzr.dev Unable to load plugin
<lifeless> jelmer:
<lifeless> :!./bzr st
<lifeless> Unable to load plugin 'cvs'. It requested API version (1, 0, 0) of module <module 'bzrlib' from '/home/robertc/source/baz/api/bzrlib/__init__.pyc'> but the minimum exported version is (1, 7, 0), and the maximum is (1, 8, 0)
<lifeless> jelmer: better?
<persia> Good day.  I'm trying to solve a particular problem in arranging a branch history, and wondered if anyone could help me with a recipe.
<poolie> hey
<poolie> maybe
<persia> Specifically, I want to revert about 20 commits from trunk to get back to an older version, add some patches that were applied back then in some new revisions, and then reapply the changes to trunk as a base for a new revision.
<persia> (this is a workaround for a package only partially managed in VCS in Ubuntu)
<poolie> ok
<poolie> so if i were in this situation i'd think about just being lazy and applying the old changes on top of your current tip
<poolie> otherwise, you should look at launchpad.net/bzr-rebase to rewrite the revisions
<persia> bzr-rebase looks like what I want, but it seems to assume I have a clean starting point.  Is there perhaps a means by which I can start a branch from an earlier revision?
<poolie> sure
<poolie> bzr branch -r 123 . ../rewritten-trunk
<poolie> for instance
<poolie> then work over there, and when you're sure you're happy, bzr push --overwrite into your publishing location
<persia> Thanks!  That's precisely what I want.  That way I can pull the old version, apply the patches, and bzr merge will do the right thing.  Thanks!
<poolie> you're very welcome
 * persia deletes everything
<poolie> !!
<persia> I work with patchsets.  quilt is very comfortable for me.  replaying the set of changes I made is trivial, but I need to rebranch to get clean history.
<lifeless> I'm pretty sure rebase can do what you want from an older base
<persia> lifeless, Hrm?  There's only one extant branch, which has more in it than I want.  My first attempt included reverting stuff that I then wanted to unrevert.  bzr branch -r makes it trivial to get it right.
<lifeless> persia: I may be wrong; you have a something that works now though, so cool - use that
<vila> hi all
<poolie> hm, our extern decl of errno doesn't quite work for it to be assigned
<poolie> this may be tricky
<poolie> as it's not a real variable...
<poolie> not necessarily a real variable anyhow...
<lifeless> usually isn't
<poolie> ah, "global errno"
<poolie> python scoping yay
<vila> regarding bug #277537, I found a problem exhibited here: http://paste.ubuntu.com/54894/
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New] https://launchpad.net/bugs/277537
<lifeless> ubottu: thats due to merges, its not a bug
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<vila> And I just came across a comment saying: '# we hope there are no repositories with inconsistent parentage anymore.' in knit.py
<vila> Did I found such a repo ?
<lifeless> vila: well, I'll have to look I guess
<lifeless> vila: but I suspect its linear-expectations confusing people
<vila> seen my paste ?
<vila> annotate is provided with parent in wrong order, which is the cause of the wrong annotation
<vila> s/parent/&s/
<vila> lifeless: here is the script I used: http://paste.ubuntu.com/54897/
<vila> branches built as explained in https://bugs.edge.launchpad.net/bzr/+bug/277537/comments/3
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New]
<vila> ubottu: you just said that, pay attention please :)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<poolie> hey vila
<vila> hey :)
<poolie> i have to say that's really not one of python's nicest features, that adding an assignment statement changes the meaning of references to that variable occuring earlier in the text
<poolie> i understand what's happening but it's still gross
<chandlerc> jelmer: pong
<vila> lifeless: Tell me where you end up before leaving and if you think I can continue from there (sounds a bit hairy to me, but yet, I didn't think I could go that deep before trying either)
<lifeless> vila: I probably won't look at it this week
<lifeless> vila: I was simply commenting
<vila> oh :-/
<vila> lifeless: may be you can give some hints about that comment then ? A way to find if parentage *is* inconsistent in that repo ?
<lifeless> 'bzr check'
<vila> ouch, I can go fix some coffee then :)
<poolie> lifeless, if you're still here, what was it that you wanted to merge into 1.8?
<poolie> oh the api thing
<lifeless> poolie: I put 1.9 in the docstring
<poolie> so you did
<poolie> i was just looking at it
<lifeless> poolie: as it sounds like 1.8 is basically baked
<poolie> i'm just seeing if a knife comes out cleanly
<lifeless>  ?!
<jml> lifeless: were you using 'baked' in a more colloquial sense?
<Odd_Bloke> The old murder/cake confusion.
<jml> First you will be baked, then there will be cake.
<lifeless> jml: no, I'm just sufficiently tired that following my sentence and poolies reply stumped me
<jml> lifeless: :)
<jml> Rest assured that there is absolutely no chance of a dangerous equipment malfunction prior to your victory candescence.
<lifeless> you want me to DE before VC ?
<Odd_Bloke> abentley: In the 'merged' messages Bundle Buggy sends, would it be possible to show the revision number in which the change was merged, or would that cause considerable extra grief?
 * Odd_Bloke is trying to mark a bug as Fix Released, and likes to mention when it was merged to bzr.dev so people can be sure they have the fix.
<jml> Odd_Bloke: Launchpad should so do that for you.
 * jml waves his hands a bit
<Odd_Bloke> jml: Less waving, more coding! :p
<jml> Odd_Bloke: I'm waiting for some tests to run :)
<Odd_Bloke> Oh. Carry on.</xkcd>
<Odd_Bloke> One thing that would be nice to do in LP is to link a bug report to an arbitrary URL, which Launchpad then goes and mirrors for you, unlinking it if the URL isn't mirrorable.
<poolie> jml/lifeless, i was referring to cookbook instructions as to when a cake is cooked
<jml> poolie: yeah, I guessed.
<poolie> but thanks for the Portal reference
<poolie> > "1953 - Aperture Science begins operations as a manufacturer of shower curtains. Early product line provides a very low-tech portal between the inside and outside of your shower. Very little science is actually involved. The name is chosen to make the curtains appear more hygienic.
<jml> poolie: heh
<jml> poolie: where's that from?
<stefanlsd> Could someone have a look at this for me please - http://pastebin.ubuntu.com/54943/     - i have a problem pushing with http. Giving me you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. I am using --use-existing-dir
<spiv> stefanlsd: try pushing to bzr+ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel
<spiv> stefanlsd: what led you to try pushing to http://code.edge.launchpad.net/...?
<spiv> stefanlsd: Actually, you probably need "bzr push bzr+ssh://stefanlsd@ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel"
<spiv> stefanlsd: Or more simply, "bzr push lp:~stefanlsd/mplayer/devel" (do "bzr launchpad-login stefanlsd" first if you've never run "bzr launchpad-login" before).
<stefanlsd> spiv: mm. i wanted to do http as im going thru a proxy...
<spiv> stefanlsd: Launchpad doesn't offer any way to push to a branch via HTTP at the moment.
<spiv> Only via sftp/bzr+ssh.
<stefanlsd> spiv: aah. that sucks :)   -  so you can only branch from http currently?
<spiv> That's right.
<stefanlsd> spiv: kk. thanks for that.
<abentley> Odd_Bloke: It would be a bunch of extra work, because Bundle Buggy doesn't currently determine which new revision merged the change.
<Odd_Bloke> abentley: OK, don't worry about it.
<Odd_Bloke> abentley: If I were to look into it sometime, would you be open to a patch to do it?
<abentley> Odd_Bloke: certainly.
<maysam> hi, does anybody know if there is any Bazaar plug-in for visual studio 2008?
<sabdfl> how do i see the version of bzr on a remote server, like bazaar.launchpad.net?
<sabdfl> other than the web interface :-)
<abentley> sabdfl: I'm not sure whether we can do that.
<abentley> I can grovel the code...
<ericvw> So I have a varchar() column in my database,  when I try to save something like P4_testCases, I get the following message:/mysql/base.py:83: Warning: Data truncated for column 'project_id' at row 1
<ericvw> any ideas?
<ericvw> wrong channel :D
<__lucio__> hi. bzr question: im trying to merge my branch into trunk, but bzr merge thinks trunk is newer, so its removing my changes. same thing if i merge trunk into my branch. what can i do?
<Odd_Bloke> __lucio__: How do you mean 'removing your changes'?
<__lucio__> Odd_Bloke: i have more lines in the new branch, but when i merge with trunk, the lines are gone.
<Odd_Bloke> __lucio__: Have you committed them?
<__lucio__> its trying to make my branch look like trunk, not trunk look like my branch
<sabdfl> thanks abentley. would be a nice little hpss patch if we can't already do it
<sabdfl> bzr version URL
<__lucio__> Odd_Bloke: yessir
<Odd_Bloke> __lucio__: And you're just running 'bzr merge <BRANCH>'?
<__lucio__> Odd_Bloke: trunk$ bzr merge $MY_BRANCH and mybranch$ bzr merge $TRUNK
<abentley> sabdfl: Yes, grovelling the code suggests we can't do it yet.
<Odd_Bloke> __lucio__: Can you make these branches publically available?
<sabdfl> thanks abentley for checking it out
<__lucio__> Odd_Bloke: not really. are you in canonical?
<Odd_Bloke> __lucio__: Nope.
<abentley> sabdfl: np.  I'm taking Community Help Rotation to new levels :-)
<Odd_Bloke> abentley: Speaking of which, can you help __lucio__? I'm at something of a loss (and meant to be working :p).
<james_w> __lucio__: when you split the branch did you use "revert" at all?
<__lucio__> one clue: i may have branched the full branch and removed some of the code there. that branch is in trunk now.
<__lucio__> james_w: i dont remember.
<james_w> yeah, I've you've reverted the bits left in your branch in something that has ended up in trunk then I think bzr will consider them unwanted and not merge them,.
<james_w> I'm not sure what debugging flags we have for merge
<abentley> Odd_Bloke, __lucio__: bbs
<abentley> james_w: -Dmerge is it.
<james_w> thanks abentley
<james_w> __lucio__: could you run again with "bzr merge -Dmerge $MY_BRANCH" please?
<__lucio__> james_w sure
<james_w> __lucio__: if there is no extra output then it means it goes in to ~/.bzr.log
<beuno> james_w, what's happening is actually expected
<beuno> he had 1 big branch
<james_w> hey beuno
<beuno> branched from that
<beuno> and deleted all the branched lines from the second and first one
<beuno> merged the first one
<beuno> and is now merging the second one, which is the parent of the first, and deletes it's lines
<beuno> hi  :)
<james_w> ah, rubbish
<james_w> do you know of a way to get the result he wants?
<beuno> my guess would be that he may be able to, either merge, commit, and merge from the old revision again
<abentley> james_w: merge, revert text changes, commit.
<beuno> that's it
<beuno> what abentley seaid
<beuno> *said
<__lucio__> revert text changes: this is by hand or some other way? bzr revert file by file?
<james_w> "bzr revert ."
<__lucio__> then bzr ci --unchanged?
<james_w> umm, dunno
<__lucio__> beuno: ?
<abentley> __lucio__: You shouldn't need --unchanged, because it will still show pending merges if you do "revert ."
<abentley> It only clears pending merges on "revert" (no dot).
<__lucio__> abentley: ahh.. thanks. i thought that revert and revert . where the same.
<__lucio__> now.. did i just kill all the changes that where in trunk? (not done by me)
<abentley> __lucio__: Yes.  You should merge an older revision of trunk that has no changes.
<abentley> __lucio__: (instead of what you just did, so uncommit)
<abentley> Then after you've redone the merge;revert .;commit, merge should work properly.
<__lucio__> thanks a lot abentley, Odd_Bloke, beuno. got it.
<beuno> __lucio__, :)
<abentley> __lucio__: np
<psusi> I'm trying to follow the revision history of a project ( https://code.launchpad.net/~scott/upstart/0.5 ) and am a bit confused... I can see a merge done from another branch, but I can not figure out where that branch is
<psusi> what exactly is the meaning of branch nick:?
<abentley> psusi: It is a hint about the purpose of the branch.
<psusi> abentley: so how do I figure out where the branch actually is?  I would like to view the history of, or check out, just that branch that was merged into the trunk
<abentley> psusi: We don't really track merges by branch, we track them by the code that was merged.
<abentley> psusi: So you can just checkout the revision that was merged into trunk.
<abentley> That will have the full history of that set of changes.
<abentley> There are other way of looking at it, like "bzr viz" from the "bzr-gtk" plugin.
<psusi> well, it says in revision 1045 that 1024.1.3 was merged to this branch.... what I can't figure out is what branch IS 1024.1
<abentley> psusi: And you don't need to.  bzr checkout -r 1024.1.3 will give you a checkout with that history.
<psusi> hrm....
<psusi> it doesn't seem to want to checkout from an existing checkout
<abentley> psusi: Well, no, that's usually a bad idea.  You can branch instead.
<psusi> so why is it identified as 1024.1?  going by the branch nick and looking at the history, i tlooks like I started with a side branch and 1024.1 is the trunk that was merged in again, rather than being split off from 1024
<psusi> I thought the 1024 part was supposed to indiciate that the other branch split off from this one in 1024?
<abentley> psusi: All a dotted revno means to me is that it's not a mainline revision.
<abentley> 1024.1 is not a meaningful revno, AIUI.
<psusi> so how does it choose the first number?  I thought the docs said it picked it based on the common ancestor
<abentley> psusi: beats me.
<psusi> I see....
<abentley> 1024.1.3 is a meaningful revno, because it refers to a revision.
<psusi> right, but in what branch? ;)
<abentley> psusi: Locations aren't meaningful.  they may have changed.  The domains may have gone away.  We have the changes that were made in that branch.  We don't need a physical location.
<abentley> Actually, a more literal response would be that 1024.1.3 refers to a revision in https://code.launchpad.net/~scott/upstart/0.5
<psusi> hrm.... ok, so 1024 DOES appear to be a common ancestor
<psusi> bzr log -r 1024 in both branches shows the same entry
<psusi> hrm.... so when the first branch shows it merged in 1024.1.1 to 1024.1.3, it is saying there were 3 changes made on the other branch since it split off in 1024 that were pulled back in, right?
<abentley> psusi: Yes, the log entries will show which revisions were merged.
<psusi> but when you look at the history of the other branch, its history shows all the way back to 1... but it shows 1025, 1026, and 1027, which the first branch calls 1024.1, 1024.2, 1024.3
<abentley> psusi: That's right.  Revnos are relative to the branch.
<psusi> hrm... but the log does not record when a branch was made does it?
<abentley> Another way to see the differences between branches is with "bzr missing"
<abentley> psusi: No, branch creation is not versioned data.  It will record the first commit to the branch, the same as it records all other commits.
<psusi> hrm.... so when looking through the log and I see the branch nick changed... it was upstart-tooling, and now it is upstart-0.5... so he was working on all this in the upstart-tooling branch first, then branched it to upstart-0.5 right?
<psusi> hrm... the pieces are starting to come together I think....
<abentley> psusi: That's how it looks.
<psusi> seems pretty similar to git... just tries to hide the details and apply human friendly identifiers
<psusi> I think my brain just is having a hard time wrapping around that since the human friendly identifiers are a poorly fit synthetic
<abentley> psusi: There are certainly similarities and differences.
<abentley> psusi: If you like opaque identifiers, you can always use --show-ids.
<psusi> hrm....
<james_w> jam: hi, do you think it would be a good idea to backport http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/46310 for the Ubuntu packages?
<james_w> perhaps even release 1.6.2
<james_w> (it's GraphIndex and _buffer_all)
<jam> james_w: I'm not a big fan of backporting. And while those help, they also hurt sometimes as well (hopefully not as often as they help). Is there something that is specifically being hit ?
<jam> I guess 1/2 of that is strictly good
<jam> (as in, always better than what we have now)
<james_w> no, just trying to make sure we have a solid release in Intrepid
<jam> james_w: backport 1.7.1 then :)
<jam> Intrepid isn't a LTS, right?
<james_w> heh, not that solid :-)
<james_w> no, it's not
<jpe> is it possible to update or merge a subdirectory or file in a branch?
<mtaylor> is the owner of bzr-builddeb aroud? jelmer is that you?
 * mtaylor is wondering if there's a feature he's missing before filing a feature request...  bzr bd -S works great for making source packages, but there isn't an _easy_ way to also do the equiv of bzr bd --builder='debuild -S -sd'
<mtaylor> so that if I'm making the same package for 4 different release series, I don't upload the tarball to launchpad 4 times... :)
<jam> mtaylor: I believe you can configure the default builder either by project or overall
<abentley> jpe: You can specify a path to a file/directory with merge.
<jam> in ~/.bazaar/builddeb.conf for global
<jam> or in .bzr-builddeb/default.conf
<mtaylor> jam: yeah... I can do the default builder - but what I _really_ want is two different builders :)
<jam> for a specific project
<jam> one style for the first
<jpe> abentley, is this the -d flag?
<jam> and a different for the rest?
<james_w> mtaylor: it's me
<james_w> mtaylor: and yeah, it sucks, you're not missing anything
<abentley> jpe: No, it's the first parameter to merge.
<mtaylor> james_w: ok. well, thanks
<mtaylor> james_w: and double thanks for writing it in the first place - can't tell you how much better it makes my life in general :)
<james_w> mtaylor: I haven't thought up a good way to do this yet, but I'm going to try and crack it fairly soon.
<jpe> abentley, isn't that the branch to merge from?
<mtaylor> james_w: awesome.
<mtaylor> james_w: I have no good suggestions
<james_w> mtaylor: if you do please send them my way :-)
<mtaylor> james_w: will do!
<abentley> jpe: It is the branch and path to merge from.
<jpe> abentley, an example would be to merge changes in the doc subdirectory of the bzr source and nothing outside that directory
<mtaylor> james_w: I'm still trying to figure out a sensible way to automatically manage a set of packaging and a branch for each of (dapper,edgy,feisty,gutsy,hardy,intrepid) so that I don't have to manually build 6 source packages
<mtaylor> james_w: for which I also have no good ideas as of yet
<abentley> jpe: e.g. bzr merge http://bazaar-vcs.org/bzr/bzr.dev/doc
<jam> james_w: wasn't there a program written on top of builddeb which at least did basic templating  in order to build multiple versions from the same branch?
<jam> I don't remember the name
<jam> I do remember that it wasn't working for jelmer at one point
<mtaylor> that would make me happy
<jpe> abentley, so the rough equivalent of svn update doc is bzr merge <upstream-branch>/doc ?
<mtaylor> of course, I've also been tempted to write a custom merge algorithm for debian/changelog files... but that sure hasn't happened
<mtaylor> Format <RepositoryFormatKnit3> for file:///home/mtaylor/package/pkg-mysql/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<mtaylor> I tried --rich-root-pack, and got a message about no subtree support
<abentley> jpe: sounds plausible.  I've never really used svn.
<jpe> abentley, I think it is; thanks
<james_w> mtaylor, jam: you may be after autoppa
<james_w> mtaylor: it's another problem I'm going to look at in the next couple of months
<mtaylor> james_w: mmm. autoppa sounds good
<mtaylor> anybody: ? Format <RepositoryFormatKnit3> for file:///home/mtaylor/package/pkg-mysql/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<beuno> mtaylor, sounds like you need to upgrade that branch to packs
<mtaylor> beuno: I tried upgrading to --rich-root-pack - it whined about subtrees
<beuno> ah, that's out of my league then
<mtaylor> I don't think I'm actually _using_ subtrees... is there a way to tell and/or remove them if I'm using them accidentally?
<mtaylor> aha! --pack-0.92-subtree seems to have helped
<beuno> ugh
<beuno> wouldn't it be nice if we could recommend what upgrade should do?
<fullermd> mtaylor: If you're not actually using subtrees, you can 'pull' it into a rich-root-pack format branch (and theoretically "should").
<fullermd> It's kinda going around behind the tool's back, to do something it "should" do directly.  Two wrongs make a right  ;)
<mtaylor> yay!
<thrope_> hi - I have a truck bzr-svn checkout and hten I've been working in branches
<thrope_> I made some changes is one branch - pulled them back into trunk and successfully updated other unmodified branches
<thrope_> but one branch I've been working on gives and error:
<thrope_> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<thrope_> but I'm confused because they do have a common ancestor up to revision 11 or so
<thrope_> I had this error before actually as well so it must be something wrong with my workflow
<thrope_> ah found it - it had rememberred an old merge location
<mtaylor> james_w: what about a flag to turn on a feature where it looks in build-area for a source package already built with a tarball included, and if it finds one, it turns on -sd by default?
<bpierre> hi
<bpierre> I've made some modification to bzrtools, how do I submit it? Do I register a new branch in launchpad?
<lifeless> bpierre: you can, or you can just send a patch by doing 'bzr send'
<bpierre> lifeless: ok
<psusi> how do you see what branches are contained in a shared repository?
<Jc2k> lifeless: bzr-playground has all gone a bit wrong. looks like loggerhead is down, new bzr-p users cant create a /bzr/$username folder because of permission problems and someone said the mirror was out of date too
<Jc2k> lifeless: but regardless, one of the tomboy maintainers was hugely impressed already
<Jc2k> (with merging and speed of branching and such)
<lifeless> Jc2k: the mirror has just been restarted
<lifeless> didn't know about loggerhead
<lifeless> following up with sysadmins
<Jc2k> ty
<Jc2k> some soundbites:
<Jc2k> 21:06 < sandy> god this is so fucking awesome
<bpierre> lifeless: and if I register a branch on launchpad, I can then request a merge when I feel it's ready to be included in the mainline?
<Jc2k> 21:37 <@sandy> Jc2k: btw, that merge worked beautifully, as you predicted
<Jc2k> 21:38 < Jc2k> :)
<Jc2k> 21:38 <@sandy> so fucking awesome is bzr
<lifeless> bpierre: yes
<lifeless> psusi: bzr branches <repo root>
<bpierre> does launchpad use things like bundlebuggy?
<lifeless> psusi: or 'ls'
<lifeless> bpierre: the BB main author is working on the review system for launchpad
<bpierre> ok
<psusi> lifeless: ls doesn't work though if you don't have the working trees checked out... branches will though right?
<lifeless> bpierre: so its growing up to become like BB :)
<lifeless> psusi: ls will still work, because a branch has a dir - even without a tree
<bpierre> but the review system right know support mail?
<psusi> that's what I was looking for... was wondering why bzr info -v just says it's a shared repo but not what's IN the shared repo ;)
<lifeless> bpierre: yes
<bpierre> and it's the same when requesting a merge?
<bpierre> same system?
<lifeless> bpierre: I don't understand the question
<psusi> lifeless: it does?  can't I remove the entire directory, or have several branches in one tree that is a shared repo and bzr switch between branches instead of cd?
<lifeless> psusi: if you remove the entire dir then your branch is gone, though the head will remain in the repository
<psusi> ( the entire directory meaning the subdir of the branch, while leaving the repository in the main direcotory intact )
<lifeless> psusi: you can have several branches and switch using 'bzr switch'
<lifeless> psusi: switch switches a tree between branches
<bpierre> you can either send a bundle by mail to a specific address, or request a merge for a registered branch, and then have something that works kinda like bundlebuggy: people can comment, and one (or more) appointed integrators can accept the merge?
<psusi> right... well wouldn't the point of switch be to avoid having each branch in its own direcotory? instead switching one directory between them as needed?
<lifeless> psusi: directories are really quite cheap; its what you put in them :P.
<psusi> well, yea... I just don't like clutter ;)
<lifeless> psusi: the point of switch is to avoid having many copies of your source code expanded on disk
<psusi> right... so if you have a dozen branches and only really want to check out and work on the trunk... you don't want all of the branches expanded on disk
<psusi> but you are saying you at least have to have subdirecories cluttering things up for each branch, even if they don't have an expanded tree in them?
<lifeless> psusi: err
<lifeless> if you have a branch at /repo/A and another at /repo/B
<lifeless> you don't need any of the subdirectories of your code under those
<psusi> can't you safely rm -fr /repo/B and later bzr checkout it if you need it?
<lifeless> check it out from what?
<psusi> from /repo
<lifeless> have you used git?
<psusi> yes
<lifeless> ok
<lifeless> git has 'refs' right?
<psusi> yea
<lifeless> each branch is a ref
<psusi> are the refs not stored in the shared repo?
<lifeless> (more or less)
<psusi> ohh... so if you delete the branch, you loose the ref?
<lifeless> the refs that make up your branches are stored in /repo/A/.bzr/branch/last-revision
<psusi> and thus, can't find the head for that branch any more?
<lifeless> right
<lifeless> you can recover a head from 'bzr heads --dead'
<psusi> I see...
<lifeless> and pull that into a fresh branch
<jam> lifeless: provided it wasn't merged
<lifeless> jam: well, then its in your history anyhow and pull . -r XX will do it
<jam> The *named* ref is gone if you delete the branch
<jam> lifeless: right, but you don't know the *name* anymore
<lifeless> jam: of course
<lifeless> jam: did I sound confused ? :P
<jam> I was mostly trying a different tack on explaining the situation
<fullermd> I smelled confusion.  And a little egg salad.
<jam> and "bzr heads --dead" doesn't work if the branch has been merged
<lifeless> ah yes I see
<lifeless> psusi: so there are a few reasons for why we do it this way
<psusi> bzr branches does not appear to be a valid command...
<lifeless> psusi: the primary user visible concept people work with are 'branches'
<psusi> so there is no way to have the refs stored in the shared repo too, like git?
<lifeless> so we wanted to make those as visible as possible
<lifeless> psusi: not in any of the repository formats shipped in bzr core
<jam> psusi: well you could create your own text file with "name revision-id"
<lifeless> psusi: bzr-svn and bzr-git obviously support that :P
<jam> and then refer to them by revision-id later
<psusi> ok... seems nice as a default... I'd just like the option to be able to tidy up old obsolete branches from the directory tree, yet still have them in the repo
<jam> psusi: you could always "mv branch old/branch"
<jam> either a file or a directory is going to get cluttered
<jam> s/either/either way/
<lifeless> psusi: If I want to keep the old branch (e.g. a failed experiment that might be useful), I would:
<lifeless> mkdir obsolete
<lifeless> mv failed-branch obsolete/
<psusi> so if you don't want to keep it.. just rm -fr, then run some sort of packing/cleaning operation on the repo?
<lifeless> yah
<lifeless> bzr branches is in the bzrtools plugin
<psusi> hrm... now to figure out if it is possible to get buildd to build a personal branch from launchpad...
<lifeless> james_w: does bzr-builddeb know about the buildd service yet ?
<lifeless> james_w: ppa's I mean
<psusi> hrm... why would you want to bzr split?
<psusi> and would that remove that subdirecotory from the original branch when you commit it, or are they just shadowed by the new branch?
<lifeless> psusi: it turns a versioned subdirectory into a tree object
<lifeless> psusi: its a bit raw, I'd ignore split for now.
<psusi> k... so why would you want to switch if you have the other branch in its own directory anyhow?  like with svn you switch so yuo only have to checkout project/A branch into the project direcory... then you switch the project directory so it is now project/B
<psusi> but it sounds like with bzr, you have to have project/A and project/B
<psusi> all the time... so if you want to switch, you just cd
<bpierre> a branch can only contains bzr metadata
<bpierre> and not it's associated tree
<psusi> ??!@
<bpierre> only project/A/.bzr and project/B/.bzr
<psusi> I got two branches with their trees in a shared repo right now
<bpierre> you can remove the tree with remove-tree
<psusi> ohh, you mean it MAY only contain the metadata, i.e. not hve the tree
<bpierre> and only keep the metadata
<bpierre> yes
<psusi> I read it as it can ONLY have the metadata, and can NOT have the tree ;)
<bpierre> and then you can use a lightweight checkout witch switch
<bpierre> *with switch
<lifeless> psusi: sorry did you mean 'split' or 'switch' they are very different things
<psusi> switch
<psusi> so if you are in /proj/A and you bzr switch ../B, then /proj/A becomes /proj/B?  then how do you get back to A?
<lifeless> Jc2k: loggerhead should be restored to sanity
<bpierre> psusi: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reusing-a-checkout
<psusi> ohh... I think I see... it wouldn't make sense to do that... only makes sense when you're using a central repo model
<lifeless> psusi: it makes sense without a central repo
<bpierre> but you can work like that locally!
<lifeless> psusi: consider this:
<psusi> it does?
<lifeless> /repo/A and /repo/B, are bare branches
<lifeless> no working tree, just the ref & configuration data
<lifeless> cd /repo
<lifeless> bzr checkout --lightweight A working
<lifeless> cd working
<lifeless> bzr switch B
<lifeless> bzr switch A
<lifeless> bzr switch B
<lifeless> etc
<psusi> ohh, well yea... I suppose you could make another working directory to switch back and forth in
<psusi> but why bother when you can just cd between the two? ;)
<bpierre> less space?
<lifeless> because A and B don't have any source code to edit ?
<bpierre> plus you can have uncommited changes
<jam> psusi: wel, I've switched to it because I have 200ish feature branches
<jam> and I didn't really want a WT in each
<psusi> well, it would be equivalent then to remove-tree + cd + checkout
<lifeless> psusi: thats a lot more work for the system to do
<bpierre> not if you have uncommited changes
<psusi> though I guess it would probably be a bit less work
<psusi> hrm... I see...
<lifeless> psusi: also some people find it useful to only have one copy, so they can be sure that their editor window is looking at the right code
<jam> psusi: on the other hand, I generally have 3-4 WTs that I have checked out
<jam> as i work on more than one thing at a time
<lifeless> psusi: basically the point is - you *can* choose to use a single working tree and switch
<jam> so I have a checkout for "Trunk", Work1, Work2
<jam> and work1 and work2 switch often
<lifeless> psusi: *or* you can just have a bunch of branches with colocated trees that you can edit on
<psusi> yea... I guess that's why I was looking for a model of refs without having each branch directory...
<lifeless> or some combination, bzr doesn't care, and supports you doing this
<jam> lifeless: side question. Any thought on how to make Repository._generate_text_index not be glacially slow for something like the mysql repository? (65k revisions, 256k text revisions)
<jam> I tried just bumping up the cache size and batch size, in case it was cache thrashing
<jam> but at inventory cache of 100, it is using 600MB and still taking a long time
<lifeless> psusi: if you have bare branches and a single wt you edit in you'll have no problems with your editor getting confused :P
<lifeless> jam: less inventory snapshots
<psusi> lifeless: yea... I just have to get used to having a working tree in one directory and the other directories just being branch heads with no tree... just seems odd at first
<jam> lifeless: do you think that is really it? AFAICT the time is spent during "revision_tree(id).inventory"
<psusi> compared to git
<jam> find_text_key_references() finishes in about 20s
<jam> psusi: well, git branch heads have no tree
<lifeless> psusi: I appreciate its different; all the modern vcs's have similar differences, and in different areas to add to the disconnect when you first play with one
<jam> they are just listed in a text file
<psusi> jam: right, but unless you look in the direcotrory, youc an't tell that... they all look like directories, be they branches with no tree, or a working tree
<jam> psusi: if it is an issue, put them all in a directory called "branches" and have the rest in "working_trees"
<jam> but sure, I understand it is *different*
<lifeless> jam: tbh, I'm not really interested in further tweaks on sngle document inventories
<jam> lifeless: well, I'm trying to justify "reconcile" as it takes.... I don't really know, but it has been 2hrs so far
<lifeless> jam: we're so close to pinning down the performance envelope of split ones that I'd rather see your time and mine going into that than optimising something we know can't ever possibly scale
<bpierre> jam: https://bugs.launchpad.net/bzr/+bug/269456 has been marked as 'Fix commited', is the fix available somewhere?
<ubottu> Launchpad bug 269456 in bzr "checkout operation consume too much resources" [High,Fix committed]
<jam> bpierre: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48E64F01.1000106%40arbash-meinel.com%3E
<bpierre> jam: thanks
<psusi> bzr missing... it shows revisions that are in the other branch, and not this one?  and the revision numbers are relative to the other branch?  so if you want to see what is in this branch, that is not in the other one, you have to cd to the other branch and missing this one from there?
<radix> psusi: no, bzr missing shows both
<radix> psusi: i.e., it shows revisions that the current branch has and the other branch doesn't, and vice versa
<Spaz> 9
<Spaz> oops
<psusi> radix: how do you differentiate?
<radix> psusi: it prints a header
<psusi> ohh... I see... missing/extra... and then the revision numbers are relative to this branch for extra, and that branch for missing
<fullermd> Alternately phrased, the revision numbers are for the branch where they are (after all, by virtue of being 'missing', they can't have a number in the other  ;)
<spiv> jam: oh, I remember why unlock can't reraise; it's impossible to tell at that point if there is a live exception or a previously handled one that just happens to still be in sys.exc_info()
<spiv> e.g. "try: foo(); except: pass" will tend to leave a real-looking exception in sys.exc_info().  The only way to distinguish an active exception from stale is by controlling the try/except around the function call and observing if an exception was actually raised.
<spiv> So the best you can do is have a helper function that does the call-function, observe-exception, unconditionally-unlock, reraise-if-appropriate sequence for you.
<spiv> With python 2.5 we could at least spell that helper as "with write_locked(foo): ..."
<spiv> But 2.4 doesn't have that syntax.
<spiv> So you need something more like "foo.write_lock(); call_and_unlock_safely(foo, foo.method)"
<spiv> (Hmm, maybe you couldn't do better in 2.5.  It doesn't matter anyway, as we support 2.4...)
#bzr 2008-10-08
<lifeless> spiv: what about
<lifeless> def unlock(exc_info=None)
<spiv> lifeless: that still requires the caller to do most of the work
<spiv> lifeless: to correctly set exc_info you still need a "try: foo(); except: exc_info=sys.exc_info() ... yadda yadda"
<spiv> lifeless: there's just no way around the fact that Python gives you no way to determine from a finally block if an except was being raised.
<spiv> lifeless: here's the problem in a nutshell: http://rafb.net/p/wy3M5l13.html
<spiv> Well, there is one way that might mostly work: introspecting the traceback object to see if the top of the stack is where you expect, i.e. a line inside the relevant try block in the current function.
<spiv> Except that could also fail in edge cases, and would be ugly as hell.
<spiv> Shorter summary: Python sucks.
<lifeless> when was try:finally:except: added?
<spiv> try-except and try-finally have been in there since I started using Python.  Or are you asking about a single try with both except and finally?
<lifeless> the latter
 * jml needs to fix bzr-removable to work with split trees
<spiv> 2.5.
<meoblast001> hi
<meoblast001> how do i download the latest version of a branch?
<jml> meoblast001: do you already have a copy of the branch?
<meoblast001> yeah
<meoblast001> i just want to update it
<meoblast001> with the new stuff from launchpad
<jml> meoblast001: cd into it and 'bzr pull'
<meoblast001> how do i cd into it
<meoblast001> like.. the local folder?
<jml> meoblast001: that's right.
<meoblast001> ok
<meoblast001> im downloading it
<meoblast001> thanx
<meoblast001> just downloading a project of someone i know to see how much it has advanced
<jml> cool.
<meoblast001> i dont think he's been commiting changes =P
<meoblast001> yay... now to worry about the advancement (or lack thereof) of my own project
<jml> meoblast001: :)
<jml> meoblast001: you can get a fairly good idea of a branch's activity by looking at its web page on Launchpad, btw.
<meoblast001> yeah
<meoblast001> im thinking about posting my project in Crystal Space forums in the Projects section so maybe someone will come along and help me
<meoblast001> i only have 2 ppl on my team
<meoblast001> and im the only programmer
<ferringb> meoblast001: project being?
<ferringb> just curious, haven't heard activity crystal space wise in a long while
<meoblast001> its a racing game im making with CS
<meoblast001> the game is very crappy so far cuz im the only programmer and i dont have enough time nor experience to write a whole game all on my own
<meoblast001> im doing as much as i can and relying on lots of support from #crystalspace
<meoblast001> ferringb: heres the Launchpad site https://launchpad.net/nickybearracing
<meoblast001> launchpad page rather
<meoblast001> i have it precompiled for x86 systems
<jml> meoblast001: btw, if you set that branch to be the development focus of the project, people will be able to fetch it with 'bzr branch lp:nickybearracing'
<meoblast001> oh
<meoblast001> i'll do that
<meoblast001> jml: done
<jml> meoblast001: cool
<meoblast001> =)
 * spiv ducks out for some errands and early lunch
 * meoblast001 hardly considers himself a programmer
<lifeless> jml: perhaps the first branch pushed should become the trunk series by default
<jml> lifeless: perhaps.
<jml> lifeless: I think it should, but I also think that setting a dev focus should set the "This project officially uses Launchpad for code hosting" flag.
<lifeless> jml: btw, I find it weird that I have to opt-in to using bugs etc
<jml> lifeless: yes, me too.
<jml> lifeless: but I've had that discussion wrt to code twice already, and have too many other things on my plate to try again just now.
<lifeless> spiv: ping
<Peng_> Awesome, a 15 MB autopack.
<Peng_> ...over bzr+ssh
<meoblast001> ok.. i messed up on a file and i need to pull the old data back
<meoblast001> i need to replace everything i have with everything launchpad has... how do i do that?
<bob2> messed up = edited but haven't commited?
<meoblast001> yes
<meoblast001> i didnt commit
<bob2> "bzr revert" will remove all local uncommited changes
<meoblast001> k thanx
<meoblast001> i just suck at programming so bad that i couldnt solve a very simple problem
<spiv> lifeless: pong
<lifeless> spiv: so
<lifeless> spiv: item keys introduced by
<spiv> Ah, that old thing.  What about it?
<lifeless> fragmented inventories have components that are not strictly introduced by a revision
<lifeless> spiv: further, we don't want to copy already present fragments
<lifeless> spiv: but we can't predict what fragments are already present unless we know the edge of the local graph I think
<lifeless> spiv: my conclusion is that this api needs to get deprecated and a newer one added
<lifeless> that has a cut facility
<spiv> lifeless: that'
<spiv> s a bit abstract to me.  It sounds plausible, but maybe the simplest thing is to describe the API you're thinking of replacing it with?
<lifeless> add a new parameter that lists the surface of revisions we have [that are relevant]
<poolie> spiv, hey good catch with the default arguments
<poolie> omgpython
<spiv> poolie: hooray for code review :)
<spiv> abentley: would you mind adding andrew.bennetts@c.c to bundlebuggy as an authorised email address?  (I think it currently expects just andrew@)
<poolie> your'e right that making it a parameter is a yagni
<spiv> poolie: oh good.  That makes the solution uncontroversial :)
<vila> hi all
<vila> poolie: ping ?
<spiv> vila: oh of course, it's daylight savings here now, so you're turning up an hour later :)
<spiv> vila: hi :)
 * spiv is about to disappear and go to a yoga class
<vila> spiv: oh, since when ?
<spiv> Since last weekend.
<vila> Haaa, and it's 17:21 your time ?
<spiv> Right.
<vila> ok
<vila> So *you* are leaving one hour earlier :)
<spiv> So when you say hello it's time for me to finishing things up for the day :)
<vila> Yeah, we should all work at least 13h/day so we can say hi/bye every day :)
<spiv> Hah.
<spiv> Although it often seems like that's what lifeless does :)
<spiv> Thinking of which...
 * spiv -> gone!
<poolie> markh, are you still around at all? is it hard or easy to make the windows python-based installers?
<RAOF> Is my google-fu weak, or is there little documentation about setting up a PQM instance available?
<Kinnison> IME, very little
<Kinnison> Although I thought there was a GSoC student working on PQM, so perhaps he produced some?
<RAOF> Kinnison: That's kinda annoying.  Maybe I'll just wait for Launchpad to grow a PQM instance for me :/
<RAOF> Heh.  Or I'll bug Rob & Jono mercilessly!
<eMBee> a group, and then make files readable by that group
<eMBee> ooops
<hno> Hmm... something is fishy in bzr 1.7.1. Running 1.7.1 both on cliend and server, and after a relatively small remote change "bzr update" suddenly downloaded 11 MB of data. Total remote repository size is 70 MB and increased by some KB only since the last bzr update..
<spiv> hno: if it's via bzr:// or bzr+ssh://, try using -Dhpss next time and see if the ~/.bzr.log file gives more info about what's going on.
<hno> spiv: It's bzr+ssh
<spiv> hno: my guess is that it's fetching most of the remote index files (how big is .bzr/repository/indices?) for some reason
<spiv> hno: if so, then there are various improvements planned that should help that.
<hno> indicies is a total of 7 MB.
<Peng_> It's dumb enough to use 11 MB of bandwidth for 7 MB of indexes plus everything else.
<hno> I don't get why it at all need to fetch the index files in a bzr update.. There is no local modifications and the local head is an ancestor of the remote head. Better to just ask for a bundle from the local head revision to current head of the remote branch.
<Peng_> It may be using the indexes to find out which revisions such a bundle would include.
<hno> Peng_: Well, it could do this optimistically by first asking based on the local revision.. or keep track of which revision that was last updated/merged.. But that's my outside view. I don't really know how deep checks bzr needs to do to find a common ancestor.. maybe revision number (the long version) isn't sufficient.
<hno> or revision-id which is the more proper term..
<Peng_> Right. I'm sure it can (and does) do it more efficiently than that. I was just saying.
<Peng_> If it's reproducable, use -Dhpps like he suggested to help diagnose it.
<hno> Peng_: Will try to reproduce it. At the moment both my local repositories have already updated.
<spiv> hno: there are several known inefficiencies.  Ideally it should be a matter of finding out what the remote revision is with a single round-trip, finding out how much is missing from the local repo with a couple of quick round trips, and then requesting those revisions in a single stream.
<spiv> hno: there's various reasons why that's not quite the case at the moment, but we're working on it.
<BjornW> hi, what would be the bzr equivalent of: svn export --force [SOURCE] [DESTINATION]
<hno> spiv: Thanks.
<spiv> BjornW: "bzr export SOURCE DESTINATION" probably.
<spiv> I'm not sure what effect --force has on svn export.
<BjornW> spiv: it will overwite exisiting exports
<BjornW> spiv: Mhhhm I cannot overwrite an export with bzr?
<spiv> Hmm, it may be "bzr export DESTINATION SOURCE", actually.  Check the docs :
<spiv> :)
<spiv> Hmm, doesn't look like it.  You could export to a tar file and then let tar do the overwriting.
<hno> Hmm.. almost could reproduce it. Created a new repository with a branch some revisions back, and then did a bzr pull from the remote. But it fetched "only" 4MB this time.
<spiv> BjornW: it would be a reasonable feature to add, I think.  File a bug.
<BjornW> spiv: will do, thanks for your help
<abentley> spiv: done
<hno> Indeed. There is lots of index accesses.
<Elvanor> Hello, I am searching for a VCS with the following features: 1) deal correctly with binary files, 2) limit the total repository file size (by keeping only a limited number of versioned items)
<Elvanor> I was told by the git guys to come here...
<Elvanor> So can bazaar do what I need?
<Elvanor> all my source code is currently in SVN, I am happy with that, but I want to setup a separate tool for backing up binary files: PDF files, GIMP images
<bob2> 1 can be done by everything bar cvs
<spiv> abentley: thanks!
<Elvanor> bob2: yes but 2) is harder
<Peng_> You mean throwing out old history?
<Elvanor> Peng_: yes
<Elvanor> automatically, if possible
<Peng_> Yeah...not so possible with bzr.
<Peng_> (I mean, it is /possible/, with tons of rebase or something, but it's not intended or efficient.)
<Elvanor> Peng_: do you any other system allowing this easily?
<Elvanor> git people told me it would be easy with bazaar
<Peng_> I wonder why the git people thought that?
<james_w> you can just delete the old revisions and leave ghosts in the mainline I guess
<Elvanor> Peng_: someone said: well, do check out bzr, it can certainly prune more easily as its commit IDs are just UUIDs
<Peng_> james_w: That's safe?
<Elvanor> Maybe what I need is more a backup system... but I want the ability to share files between users with locks, commits etc
<Peng_> james_w: But won't it need them to reconstruct stuff?
<Peng_> Elvanor: Oh. That git user is correct. Part of bzr's design does theoretically make it easier to mutate history, at least in some ways.
<Peng_> (But it does hash at least some things too, and what would it do if it came across two differing revisions with the same ID?)
<james_w> Peng_: yeah, just deleting it isn't safe, but it's possible
<Peng_> (Which doesn't apply to mainline ghosts, which would work,  Iguess.)
 * Peng_ dies of parenthesis abuse.
<Lieven1> does anyone know from where I can get the latest source code of tortoisebzr?
<Lieven1> I tried lp:tortoisebzr, but it seems to be really outdated
<jelmer> hi Lieven1
<jelmer> markh, ^
<jelmer> Lieven1, I think tortoise is part of bzr.dev now, but I'm not entirely sure
<Lieven1> I don't think it is, or at least, I can't find it
<CardinalFang> Hi all.  My group uses a very large bzr tree, and we often try to speed up our actions by branching two trees at the same time or pushing two or more trees at the same time.  I don't have specifics right now.  For branching or updating, we sometimes get index-file-missing errors, and when pushing one of the pushes hangs.  I suspect that there's some shared-repo data that isn't locked correctly, locally or remotely.  I don't have
<CardinalFang> enough to file a bug, yet, but I just want to remark about it in case someone has a flash of insight.
<CardinalFang> Expect a full bug or two filed in a week or so.
<jam> CardinalFang: bug #153786 most likely
<ubottu> Launchpad bug 153786 in bzr "pack repositories do not retry when concurrent operations pack" [High,Triaged] https://launchpad.net/bugs/153786
<CardinalFang> hmm.
<ccxCZ> Hi, does file id change when it's moved renamed?
<Peng_> ccxCZ: no
<Peng_> ccxCZ: That's the point of file IDs. :P
<pekuja> is it possible/viable to host a bazaar repo on a server with no bazaar installed?
<cody-somerville> pekuja, sure
<pekuja> the idea is to have a repo in the public_html of my shell account so that I can push through ssh and others can pull through dumb http
<pekuja> so should I basically do a clone of my repo on my local machine and copy it over to the server? should something like that work?
<pekuja> sorry if this is really obvious. I'm reading the user guide but I'm kinda tired tonight :-/
<cody-somerville> pekuja, just do a bzr push via the sftp transport layer
<pekuja> that will create the clone?
<cody-somerville> yup
<pekuja> cool, that sounds super easy
<cody-somerville> pekuja, it is :)
<cody-somerville> pekuja, you can also use launchpad for hosting your branches if you'd like
<pekuja> oh, right... I guess that's an option. it's not really a project of any public interest though. just using the vcs for coding a university course project type thing
<fynn> Hi. Suppose I took a .bzr directory renamed it to "foo", and moved it to ~/bar. is there a way to recreate all the monitored from "foo" without changing its name to .bzr?
<fynn> (I could rename it to .bzr and do "bzr revert", but I'm wondering if there's a solution without the rename stage.)
<cody-somerville> fynn, What are you *really* trying to accomplish?
<fynn> cody-somerville: I'm backing up file trees by making them into Bazaar branches, then archiving the root .bzr directory.
<fynn> cody-somerville: right now, the final stage of a restore involves a "rename the 'backup' directory to '.bzr'" step.
<james_w> fynn: it may be possible with some python
<fynn> I was hoping to eliminate that step, so as to make the process more elegant.
<fynn> james_w: OK, thanks. I might hack that then.
<james_w> fynn: but no, it's not just an environment variable or command line switch or anything
<fynn> *nod*
<fynn> also, as a bzr newbie, just to make sure:
<fynn> james_w, cody-somerville: do any of you guys see a problem with using bzr for (version-controlled) backups in that way?
<fynn> e.g. could I possibly encounter any issue with restoring a perfect copy from such a backup?
<james_w> I don't think so
<fynn> alright... btw, if I have a source tree ~/foo, and I make it into a Bazaar branch (with "bzr init; bzr add; bzr ci"), the *only* change to ~/foo is the creation of ~/foo/.bzr, and the directories/files under it?
<james_w> yup
<james_w> .bzrignore if you do "bzr ignore something"
<fynn> james_w: so outside of the creation of ~/foo/.bzr and ~/foo/.bzrignore themselves, any further VCS work, no matter how many subdirectories and files are monitored beneath ~/foo, and no matter how many of them I choose to ignore, will only happen inside ~/foo/.bzr and ~/foo/.bzrignore themselves?
<james_w> yup
<fynn> james_w: thanks a lot. that's such a relief after .svn creating itself in _every monitored subdirectory_.
<fynn> looks like my new backup scheme with bzr is viable.
<fynn> OK, something I don't get: inside the branch ~/foo I have a file ~/foo/bar.py that I now want to ignore.
<fynn> but commanding "bzr ignore bar.py" issues a warning about it already being monitored, and doesn't ignore it.
<fynn> so how should it be done?
<fullermd> Ignore doesn't unversion a file that's already versioned; it just prevents 'add' from automatically adding it (and 'status' showing it unknown, etc)
<fullermd> You'll have to use bzr rm to unversion it.
<fullermd> (possibly with --keep of course)
<fynn> fullermd: I see, thanks.
<fynn> --keep is nice.
<fullermd> I have it aliased to be the standard 'bzr rm' behavior.
<fynn> fullermd: apropos aliases: is there a way to make "bzr st -SV" the default behavior of "bzr st"?
<fynn> i.e. set a persistent configuration setting that would implicitly add the -SV flags to every "bzr st" command?
<fullermd> You could just alias st to 'stat -SV'
<fynn> yeah, I guess that's the best solution.
<fullermd> Well, I've got rm aliased to rm --keep, and missing aliased to missing --line and such   :p
<fynn> fullermd: "aliased" as in bash alias, right?
<fullermd> No, bzr alias.
<fullermd> bzr help alias
<fynn> bzr: ERROR: No help could be found for 'alias'. Please use 'bzr help topics' to obtain a list of topics.
<fullermd> Mmm.  What version do you have?
<fynn> 1.5
<fullermd> Looks like the 'alias' command came in with 1.6.  They've been supported for ages before that though; you just have to set them manually in the config file.
<fynn> cool, thanks.
<fullermd> Make an [ALIASES] section in your ~/.bazaar/bazaar.conf, and add a line that says "st = stat -SV"
<fullermd> There's a wiki page about it I think.
<luks> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-aliases
<fynn> that's what I like so much about bzr: so many features, so convenient.
<fynn> and organized quite elegantly too.
<abeaumont> hmmm, i have an error with ftp transport and mode, i've seen a bug report and patch https://bugs.launchpad.net/bzr/+bug/259855 , but i'm still getting the same problem :?
<ubottu> Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed]
<fynn> fullermd, luks: that worked, thanks a bunch.
<abeaumont> i also have added a feature to bzr upload plugin, is there any developer of this plugin around?
<beuno> abeaumont, yes
<beuno> hello
<beuno> you can upload the branch
<beuno> fle a merge request
<beuno> and we'll review it to get it into the tree  :)
<fynn> can I have a different bazaar.conf apply to different repos?
<abeaumont> beuno: ok, I'll do that
<beuno> thanks abeaumont
<abeaumont> beuno: done :) i hope i did everything right, otherwise just tell me (i'm new to launchpad)
<beuno> abeaumont, did you file the merge request against trunk?
<awilkins> Can anyone things of commands that should take siblings in the same way that "switch" does (apart from merge, which is the top of my list)
<fullermd> pull?  missing?  push?  diff?  stat?  bind?  reconfigure?  send?
<fullermd> Really, pretty much ANYTHING that can refer to a branch.
<abeaumont> beuno: oh, no, forgot that
<abeaumont> beuno: ok, done
<beuno> abeaumont, got it!  will get to it in a few hours.  Many thanks!
<abeaumont> beuno: perfect, thanks!
<awilkins> !wake aeris
<ubottu> Sorry, I don't know anything about wake aeris
<awilkins> Sorry bot
<fynn> can I have a different bazaar.conf apply to different repos?
<Odd_Bloke> fynn: You might want to look at locations.conf.
<fynn> Odd_Bloke: thanks, looks to be just what I was looking for.
<spsneo> hey how can I use bzr client behind http proxy?
<spsneo> please help
<Spaz> magic.
<spsneo> Spaz: hey can u help me ?
<Spaz> set http_proxy in your environment
<spsneo> ya I have already done that
<Spaz> http://bazaar-vcs.org/ConfiguringBzr#head-39a4bf80d496af410e013585de6268ca55928d38
<Spaz> if it doesn't work, i don't know what to tell you :p
<Spaz> sorry
<spsneo> Spaz: do u know anybody who would help me
<Spaz> spsneo, what is your problem with it
<Spaz> if you set http_proxy (export http_proxy="http://proxy.crap.here") then it should work
<spsneo> i am trying this : bzr branch lp:inx trunk
<Spaz> if not then it sounds like your proxy is either misconfigured or something is broken
<Spaz> that is a local operation i believe
<spsneo> but it gives a long list of errors
<Spaz> hm
<Spaz> pastebin them please
<spsneo> Spaz: i guess this is the command to get the branch from launchpad
<Spaz> hm
<spsneo> Spaz: http://pastebin.com/d65492841
<Spaz> bzr: ERROR: socket.gaierror: (-5, 'No address associated with hostname') <-- that is all i needed to hear
<Spaz> the hostname doesn't resolve.
<Spaz> meaning you're using a hostname that is invalid
<spsneo> normally what is the method to get a copy of trunk from lp ?
<Spaz> spsneo, depends
<Spaz> what project do you wish to check out?
<spsneo> inx on lp
<Spaz> odd...
<Spaz> spsneo, it sounds like an issue with your proxy
<spsneo> Spaz: I also thought so
<spsneo> Spaz: so is there no solution?
<Spaz> spsneo, don't use an http proxy
<Spaz> spsneo, or fix your http_proxy environmental variable
<spsneo> Spaz: I am in an university
<Spaz> hm
<Spaz> i would bet $10 that your http_proxy variable is set wrong
<spsneo> actually I am behind a firewall also
<spsneo> hehe no ways
<Spaz> export http_proxy="http://proxy.url.org:port" ?
<spsneo> svn is working fine
<Spaz> is it in that format
<Spaz> hm
<spsneo> yaya
<Spaz> sounds like a possible bug
<Spaz> that or your DNS server might be down
<Spaz> not much i can do in either case spsneo
<spsneo> ya its in the format : http_proxy="http://user:pass@proxy.url.org:port"
<Spaz> ah ok
<Spaz> is the actual address resolving?
<Spaz> run host proxy.url.org or such
<spsneo> Spaz: well I am behind a firewall as well which allows only http and https
<james_w> bug 186920
<james_w> too late
<ubottu> Launchpad bug 186920 in launchpad-bazaar "bzr launchpad does not handle proxy when used for name resolution " [Undecided,Confirmed] https://launchpad.net/bugs/186920
 * mwhudson hmms
 * mwhudson gruntles
<Peng_> ?
<mwhudson> Peng: i want to add a keyword parameter to Branch.open/BzrDir.open_branch without breaking all branch implementations
<mwhudson> (well, branch format implementations i guess i really mean)
<Peng_> Oh
<jam> mwhudson: good luck with that
 * fullermd would like a pony when you get done with that.
<jam> I think you have to create a new api that calls back, if you *really* don't want to break compatibility
#bzr 2008-10-09
<poolie> hello
<mwhudson> jam: i'm not sure i understand
<lifeless> mwhudson: this is for stacking?
<mwhudson> lifeless: yeah
<mwhudson> i guess i could only change BranchFormat7.open
<mwhudson> and do most of what bzrdir.open_branch does myself
<mwhudson> lifeless: i replied to your mail
<lifeless> mwhudson: a hook to alter is less disruptive than a signature change which will propogate many levels deep
<mwhudson> indeed
<lifeless> but conceptually
<lifeless> if you change open I'd rather see a 'transform_fallback' parameter rather than disable/enable
<lifeless> with the transform being required to return a url when given a url
<mwhudson> fair enough
<mwhudson> changing open appears to be a can of worms though
<mwhudson> so i'm going to give a hook a go
<mwhudson> lifeless: what do you think the hook should do?
<lifeless> that is, you can't disable stacking, but you can change the pointer
<mwhudson> take a url, give a url, or take a url, give a repository, or ... ?
<lifeless> you need something that takes a url beca use you want to get there before url connection is attempted
<mwhudson> indeed
<lifeless> I think its easier to allow url->url
<lifeless> because then these transforms can stack
<mwhudson> point
<mwhudson> lifeless: something roughly like this? http://pastebin.ubuntu.com/55463/
<poolie> mwhudson: so will it be acceptable to you that if you can't open the stacked-on branch at all, then you can't deal with the stacked branch at all?
<mwhudson> poolie: yes, i think so
<mwhudson> (i mean, i _guess_ you could just return the url of an empty branch backed on to a memorytransport as from the hook if you really wanted to be evil)
<poolie> so i think that means launchpad can't do anything with branches that are stacked on locations not on launchpad?
<poolie> i don't think that'd be a good idea
<mwhudson> if launchpad can't open the branch, what can you do?
<mwhudson> poolie: if people do 'bzr push lp:whatever --stacked-on http://somerandomhost.com/trunk i think it's ok *for now* for this to not work
<poolie> ok
 * jml agrees with mwh
<poolie> i think that's fine, and it's good to be clear about ti
<poolie> it8
<poolie> it**
<lifeless> mwhudson: s/should/must/
<mwhudson> lifeless: right
<lifeless> also please check None is not returned or something like that
<mwhudson> lifeless: makes sense
<poolie> mwhudson: re that hook, it seems like you should perhaps pass the stacked branch url too
<mwhudson> poolie: yes, probably
<mwhudson> poolie: or the stacked branch itself, maybe
<poolie> mwhudson: there's also external documentation of hooks that should be updated
<poolie> maybe, probably, though it deserves a warning that it's half-baked
<mwhudson> certainly
<ferringb> curious... anyone looked at long term memory usage of bzr/api consumers?
<ferringb> noticed an annoying trend of loggerhead/trac-bzr both developing heavy leaks, wondering if others have seen it for alternative apps
<Odd_Bloke> ferringb: I suspect those are the only long-running consumers that we have.
<Odd_Bloke> Though I don't know how the Eclipse plugin does it, and there is 'bzr shell' in bzrtools.
<lifeless> ferringb: its likely python memory fragmentation, though it could be a genuine leak
<lifeless> ferringb: I suspect bzr itself isn't leaking, based on previous tests
<ferringb> lifeless: I doubt it's memory fragmentation
<ferringb> actually I know it's not
<ferringb> have at least one reproducible ~18/20MB leak
<ferringb> if it were fragmentation, it would level off at some point (very least the growth wouldn't stay linear)
<lifeless> ferringb: ok
<ferringb> either way, setting up to heappy it, just wondering if anyone else has seen odd behaviour
<lifeless> loggerhead on launchpad has trouble from time to time
<lifeless> much better since the big overhaul
<ferringb> yeah, upgraded recently, been happy w/ the results for the most part
<ferringb> lifeless: curious, launchpad allow the misc cralwers to scrape loggerhead pages?
<lifeless> I think its blocked
<lifeless> back soon, doofing
<spiv> There's the utf8 cache in bzrlib.cache_utf8 that bzrlib.osutils.safe_revision_id uses, if an unbounded number of revision IDs get seen by the process that would grow without bound...
<ferringb> spiv: rough size of utf8 cache entries?
<spiv> # of revisions * (length of an average revision id + 40 bytes)
<spiv> (where 40 bytes is a guesstimate of the size of the overhead of a PyString object plus keeping a dict entry or two)
<spiv> Hmm, maybe length of a revision id * 2, because I guess the cache keeps the unicode and the str version.
<spiv> Basically, 20MB would be a pretty huge number of entries in that cache!
<mwhudson> lifeless, poolie: i just sent a bundle to the list
<mwhudson> with an inappropriate subject, wahoo
 * mwhudson resends
<jam> spiv: by my math with your numbers, it only takes 67K revisions to hit 20MB
<spiv> jam: Well, that's not so impossible.  But if one process is repeatedly leaking 20MB at a time, that still adds up pretty quickly to an unusually huge number of revisions.
<lifeless> paths too
<markh> poolie: ?
<lifeless> jam: your abbreviations are unclear to me
<lifeless> jam: I didn't reply to your first mail about readahead in btree indices because I read your mail as saying you weren't done
<jam> I'm not, I was asking for comments, though
<poolie> markh: hi
<lifeless> jam: "seems worth investigating"
<lifeless> jam: though, please consider with gc repositories
<markh> poolie: hi.  Can you think of an example of some "doctest-ish mappings" I could use as a kindof "template"?
<lifeless> jam: which for text reconstruction, have a radically different read pattern
<jam> last I tried gc, performance was pretty abysmal
<jam> at least for the 'fetch' case
<lifeless> jam: yes, and we know why :P
<jam> and it would have the same structure for "log"
<jam> since those aren't compressed anyway
<lifeless> yes
<markh> I'm not sure what they would look like exactly.  I would have thought normal unittests that use the api would be easier?
<markh> (but I've never quite drank the doctest kool-aid :)
<lifeless> doctest--
<markh> "doctest == testable documentation" in my book, and its not clear that is what we are doing
<markh> but - I'm not trying to argue the merits of that, but if doctests are desired a template would help alot.
<lifeless> markh: whats the context here btw?
<markh> case sensitivity
<lifeless> blackbox tests?
<markh> that's what I would have thought.  Poolie suggested "  Maybe a good place to begin would be with a kind of doctest-ish description of what mappings are meant to occur and where."
<lifeless> markh: I would translate that as write some docs about the problem
<poolie> write some docs that have quoted fragments of code
<lifeless> markh: but yeah, I think chat to poolie at this point
<poolie> i don't mean that they should necessarily be executable, because doctest other than as testable documentation has some drawbacks
<poolie> did you read alexander's wiki page?
<markh> maybe "black-box doctests"?  ie, quote shell commands using bzr rather than code?
<markh> I read the wiki page after sending my initial mail.  Its fairly good but a little light on specifics.
<markh> It also fails to address that windows isn't truly case-insentitive generally - its closer to "case retaining"
<lifeless> case preserving case insensitive is the usual description
<markh> ie, the case of the filename is retained, but any case can be used to access it.
<markh> right - and the wiki doesn't make that distinction.
<poolie> so i made that (perhaps too vague) suggestion because i think we need to converge from the somewhat general document on the one hand with actual code on the other
<markh> eg, FAT truly is case-insensitive IIUC
<poolie> but i don't know if people genuinely agree where those tests should go
<lifeless> markh: VFAT isn't, and real FAT can store arbitrary bytes, its up the fs layer on top :P
<markh> lifeless: OK - the FAT FS layer on windows is truly case insensitive IIUC :)
<RAOF> VFAT is awesomely the worst of both worlds.  You can have both File1 and file1 in the same directory, but windows will only see one. :)
<lifeless> markh: I'm pretty sure that if you put a FAT fs into current windows, it treats it as VFAT just for kicks
<markh> poolie: so a reasonable first step would be docs that demonstrate the problem and identify the preferred solution, but doesn't actually identify code that might need changing?
<markh> those docs could then be turned into regular black-box tests and then the impl can be determined?
<poolie> right
<markh> ok cool, thanks.
<poolie> i think they could possibly actually be run as doctests
<poolie> treating them as "this is a testable document of how we're generally handling case sensitivity"
<lifeless> I'd be strongly tempted to just write blackbox tests for specific commands
<markh> maybe, but I fear the doctests then get pollued with 'open('foo').close() etc to actually setup the test trees etc, but I haven't looked any many of the existing doctests yet.
<lifeless> doctests are viciously harsh to work with when you need filesystem support
<lifeless> you can spend days just getting things to work right
<markh> yeah
<poolie> right
<lifeless> by strongly tempted, I actually mean, you couldn't pay me to write this sort of thing as a doctest
<poolie> so, to be clear, i'm suggesting a document that has some code or command examples, even if they're not actually executable
<poolie> a pseudocode doctest
<poolie> don't worry, you couldn't pay me enough to have me try to make you do it :)
<lifeless> :P
<jelmer> hmm, 1.8.1 removes MutableTree.get_file_with_stat() ?
<jelmer> s/1.8.1/1.8rc1/
<poolie> jelmer, really, i thought it was added?
<jelmer> I must be too tired to read the traceback right
<jelmer> yeah, never mind me
<lifeless> jelmer: thats new, part of commit race closing
<jelmer> bzr-rebase doesn't provide MapTree.get_file_with_stat() yet
<lifeless> thats more likely :)
<mwhudson> spiv: seen https://bugs.edge.launchpad.net/bzr/+bug/278673 ?
<ubottu> Launchpad bug 278673 in launchpad-bazaar "Traceback when uploading to an invalid location" [Undecided,Triaged]
<jelmer> I'll fix it tomorrow when I'm actually awake...
<mwhudson> spiv: i have the feeling it might be fixed in bzr.dev by now
<jelmer> g'night
<spiv> mwhudson: Actually, I suspect it isn't
<mwhudson> spiv: slacker
<mwhudson> :)
<spiv> Nope, I don't think it is.
<ferringb> spiv: not a process as much as a request via trac-bzr
<ferringb> spiv: reasonably sure trac-bzr in general has it's own issues, but either way tracing it (finally got my hijacker working again)
<jml> I'm doing a merge and getting a contents conflict on a file
<jml> thing is, the file doesn't exist in the branch being merged into.
<jml> what's the deal?\
<lifeless> jml: it used to exist
<lifeless> jml: left side change -> delete
<lifeless> jml: right side change -> modify
<jml> lifeless: thanks.
<spiv> lifeless: can we turn you into a "bzr explain-conflict" plugin? :)
<lifeless> spiv: no
<lifeless> spiv: but you can patch the conflict system to explain itself more
<jml> lifeless: if I try to get the log for the path, I get: bzr: ERROR: Path does not have any revision history
<jml> lifeless: AIUI, this conflicts with your theory.
 * spiv -> lunch
 * jml is perplexed
<lifeless> jml: deep history is not checked
<lifeless> jml: try ls -r ancestor:other-branch
<jml> lifeless: it's in the list.
<jml> lifeless: but that doesn't help me learn why it was deleted.
<lifeless> log -v might
<lifeless> or log -m '\bbasename\b'
<jml> lifeless: by 'basename', you mean os.path.basename(), right?
<jml> no results.
<lifeless> shame, they didn't mention the file while commiting its delete
<lifeless> jml: log -v is probably the key
<lifeless> jml: one possible thing is 'rm foo; add foo; commit;
<jml> lifeless: log -v doesn't give any results either.
<lifeless> jml: the file is in the branch?
<jml> lifeless: no.
<lifeless> jml: is it in trunk ?
<jml> lifeless: yes.
<jml> lifeless: merging trunk into the branch raises the conflict.
<lifeless> and log -v in the branch doesn't show it being deleted anywhere ?
<jml> lifeless: that's right. 'bzr log -v path/to/file' says bzr: ERROR: Path does not have any revision history
<lifeless> that command is useless for this
<lifeless> I mean literally 'log -v'
<lifeless> log PATH needs PATH to be in the WT, or *the last commit* only.
<lifeless> 2-commits back and the path won't be found
<mwhudson> can i get someone to look at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48ED5C67.9020408%40canonical.com%3E please?
<jml> lifeless: ok, so log -v and grep?
<lifeless> jml: yes
 * jml tries
<lifeless> jml: btw I would have said 'log FILE' if that was what I meant :)
<poolie> mwhudson: i'll look
<mwhudson> poolie: thanks
<poolie> i set up an rdesktop-accessible windows vm for testing and packgaing
<poolie> mwhudson: +1
<mwhudson> poolie: thanks
<jml> lifeless: is there some way I can do this without generating the log for the entire history of this branch?
<lifeless> jml: -r -1..ancestor:otherbranch
<lifeless> jml: but it will take just as long
<lifeless> jml: so don't interrupt what you are doing
<jml> lifeless: ok.
<lifeless> jml: (log incrementally generates output, so the time-to-find-first-reference is identical)
<jml> lifeless: incidentally, I think Bazaar could handle this use case better.
<lifeless> indeed
<lifeless> I'd like bzr search to index changes better
<lifeless> and the inventory work I'm doing at the moment should help too
<jml> lifeless: would that make 'bzr log removed_file' do something?
<lifeless> jml: no more than it does today
<jml> :(
<lifeless> jml: searching all the way to the dawn of time is what it doesn't do today
<lifeless> jml: and its hard to justify that it should do that by default, because that will always be somewhat expensive
<lifeless> jml: however, a search index could do it fast
<jml> lifeless: I'd settle for 'bzr log --deleted FILE' or similar
<lifeless> and if the search tech advances sufficiently we can make it be part of core
<jml> or something that gave me the revno of when it was deleted.
<jml> learning why a file was deleted seems to be a good thing for a version control to help you do.
<lifeless> sure
<spiv> abentley: shelf 2 sounds very cool
<abentley> spiv: Thanks.
<lifeless> abentley: hi
<poolie> jam: thanks for the ppa packaging updates and documentation!
<abentley> lifeless: Hi.
<lifeless> abentley: got time to chat about your new tree method?
<poolie> i have some queries but i guess you may be gone
<abentley> lifeless: A bit.  Gotta be up early for a chat with sabdfl.
<lifeless> abentley: ok. well basically I feel like its making things vis-a-vis inventory less clear, without actually reducing inventory usage; I'd rather see things just using inventory directly than via that method. But - I have context for what drove it etc, and I'd like to understand those reasons.
<lifeless> s/have context/have no context/
<abentley> lifeless: We haven't officially deprecated inventory, but I hope we'll be able to.
<abentley> lifeless: PreviewTree doesn't have one, because I thought it would be a good way to push that process along.
<abentley> lifeless: It's somewhat a cheat to get the InventoryEntry without having an Inventory.
<lifeless> abentley: right, thats why I think its less clear, without being better in any other way
<abentley> lifeless: It's better in that I don't have to implement PreviewTree.inventory
<abentley> lifeless: We talked about this on the list in just the past week.
<abentley> lifeless: jam was especially in favour of it.
<lifeless> ok
<lifeless> do you remember the thread name? I should read it and reply I guess
<lifeless> shelf2 sounds nice
<lifeless> and I do want you to get this patch in
<lifeless> also
<lifeless> woo
<lifeless> all tests passsing on my split inv format
<abentley> lifeless: great stuff.
<abentley> lifeless: Thread was: [MERGE] Enable merging into PreviewTree
<abentley> lifeless: The other way I can avoid implementing PreviewTree.inventory is to use Tree.iter_entries_by_dir to get single entries.
<abentley> lifeless: Would you prefer that?  poolie's distaste with that pattern inspired this patch.
<lifeless> let me read that thread; at this point I would say implementing a trivial inventory subclass (you only need to override __getitem__ and __iter__ probably) is likely clearer and not much more code
<abentley> lifeless: Okay, catch you later.
<lifeless> abentley: I'll reply to the older thread
<lifeless> poolie: want a chat?
<poolie> lifeless: yes, but this time i'm really playing squash at 5
<lifeless> :P
<lifeless> sure whenever then
<poolie> markh: if you're still here, are there any docs on building windows installers/packages?
<lifeless> grab me tomorrow morning if you like
<poolie> now's fine, at least briefly
<markh> poolie: in general its usually "setup.py install"
<poolie> that's all?
<lifeless> poolie: ok ringing asap
<markh> that's the theory :)  You will need the appropriate MS compiler installed, but you don't even need to make sure its in your environment
<markh> poolie: some packages have extra requirements - eg, bzr-svn needs the apache runtime libs installed somewhere and env vars set to point at it - but setup.py documents that
<markh> (not to mention the svn libs themselves :)
<Wyverny> So, I have a basic question. And I can't find the answer around the interwebs. What's the difference between init and init-repo. What's their interaction when both of them are used?
<markh> Wyverny: try 'bzr help repositories'
<Wyverny> I have that open.
<markh> "By default just running 'bzr init' will create a repository within the new branch but it is possible to create a shared repository which allows multiple branches to share their information in the same location. When a new branch is created it will first look to see if there is a containing shared repository it can use."
<markh> "To create a shared repository use the init-repository command"
<markh> so usually you would create a shared repo in /src/myproject, then use 'bzr init' to create branches *under* /src/myproject
<markh> all the branches would then share the same repo
<Wyverny> I see. I get it. Thanks. I knew it was something simple.
<Wyverny> Can there be only a single .bzrignore? Or can I have one per branch?
<bob2> it is only per-branch
<bob2> (as a file in the root of each branch)
<Wyverny> Oh, great.
<Wyverny> Simple questions, simple answers. I'd buy you guys a beer if you were around ;)
<markh> in an hour I'll have one for you anyway ;)
<vila> hi all
<Mez> hey, I want to setup my own system so that I can have multiple devvies access a bzr repo for push, but want to secure it...
<Mez> I don't want to have to setup SSH account for them, and dont want anything that encroaches my security on my system...
<Mez> any ideas? (I'm looking for something similar to how svn does users over HTTP preferably)
<jml> Mez: afaik, ssh or ftp are your only options.
<Mez> which means setting up new user accounts :9
<jml> Mez: you can restrict it so that the devs don't get shells on your computer
<Mez> jml, I know that... but I don't want to have more UNIX accounts that I have to manage and secure
<jml> Mez: *nod*
<jml> Mez: although, as a non-sysadmin I'm curious, why do you think that UNIX accounts are more difficult to manage than htpasswd and authz files?
<Mez> because they're covered in my audits ;)
<jml> Mez: ah hah.
<lifeless> ciao
<jml> lifeless: cya
<jml> Mez: so, if this is an open source project, you can host the branches on Launchpad for free.
<jml> Mez: but I am filing a bug *right now* about this :)
<Mez> jml, yeah, it is, but I don't want to push it out to public till it's code-ready at the moment
<Mez> jml, feel free to subscribe my nick to tbe bug
<jml> Mez: done.
<jml> Mez: incidentally, are you aware of Launchpad's +junk feature? I often push branches to ~jml/+junk/whatever when I don't feel they are ready for public consumption.
<jml> (I understand there are different levels of "not read")
<jml> ready, rather.
<spiv> Mez: FWIW, there are SSH/SFTP servers that don't use UNIX accounts.  They're not necessarily easy to setup, though...
<Mez> spiv, exactly
<Mez> spiv, names?
<spiv> Mez: Some assembly required (i.e. hacking), but you can build such things with Twisted Conch.  You could probably do it with paramiko too.
<spiv> I wouldn't be surprised if there are others, although I've never looked.
<spiv> (I know it's possible with Twisted, because I've done so... that code is now part of what runs bazaar.launchpad.net)
<Mez> spiv, i'm not really that good with python
<spiv> Mez: "just use +junk branches on Launchpad" is a pretty good answer for branches of experimental open source projects, though.
<spiv> I guess I understated when I said "not necessarily easy to setup" :)
<Mez> spiv, release a user friendly version of the code for bazaar.launchpad.net ;)
<jml> Mez: working on it.
<Mez> jml, ?
<jml> Mez: Launchpad is scheduled to be open sourced in the next year.
<Mez> yeah, yeah, I know
<jml> (spiv originally wrote bazaar.launchpad.net, but I've been maintaining it for the last couple of years)
<jml> anyway, it's time for me to leave the computer and enjoy the sunlight.
<spiv> jml: good plan
<spiv> Hooray, I have usertest reliably running multiple runs of its 'network' suite, including starting & stopping a bzr server.  (And as a bonus, using --strict.)
 * spiv runs it with a simulated 500ms latency loopback network device on bzr.dev and 1.7.1
<Mez> spiv, could coh not be used to have br serve work as an ssh server which has a file in the branch that lists the people with access's h keys (like an authorized keys)
<Odd_Bloke> For today's controversial and incorrect suggestion: Dropping support for Python 2.5 :D
<poolie> hello
<poolie> hey spiv, well done!
<poolie> Mez: that would be nice
<poolie> not so hard to do, as we already have an ssh server used in testing
<Mez> poolie, Id write it if I knew how
<poolie> if you'd like to try we can help you
<Mez> haha, I can probably get it to the point where it makes a server, and authenticates, but getting it to interact with bzr is the hard part
<poolie> so StubSSHServer in tests/blackbox/test_serve.py is probably close to what we need...
<Mez> argh
<Mez> Im not even going to TRY and do a branch on here
 * Mez wonders if the eeePC would be able to cope and decides to do a lightweight CO instead
<Mez> poolie, actually, yeah, it could probably work from that
<Mez> poolie... if i could send you this as a script that took a couple of arguments, would you guys be able to integrate it somehow?
<poolie> well, send through or post to the pastebin what you come up with, and w'll try to help
<spiv> Mez: I would like "bzr serve" to be able to run a simple SSH daemon, I think that would be neat.
<spiv> Mez: if you make any progress towards that, please do post it here or send it to the mailing list
<spiv> poolie: http://rafb.net/p/flZlui28.html is the summary report with 500ms latency and the 'network' test suite from usertest trunk
<spiv> poolie: no surprises (mostly the same, bzr.dev a little bit better in a few cases).
<spiv> poolie: oh, and those are the results from running on a bzr.dev repo.
 * spiv -> dinner
<poolie> i wonder why the AddTasks ones were so much slower?
<poolie> well done though, that's great
<poolie> is the patch up for review?
<Mez> spiv, but wouldnt that cause issues for people using it in its current state?
<poolie> Mez: presumably it would listen for ssh on a different port
<Mez> aswell...
<Mez> (as the current functionality of bzr serve)
<jml> Mez: there's already talk of having bzr serve --http run a webserver, making the command more of a swiss army knife
<Mez> ah, kk
<Mez> JOAT functionality ;)
<Mez> bzr serve uses the I/O of the socket right, so, if i wired that up to have SSH auth on the front end, then I could hopefully, just pass the stream into that, and make a new protocol name that makes bzr auth with SSH first, and then use the "normal" protocol... right?
<poolie> right
<Mez> yay :D makes life sooooo much easier then
<poolie> it may be easiest to have the serve process spawn off a subprocess connected up over pipes
<Mez> argh, confusing, but i think I know what you mean
<Mez> but to be fair, doing it that way means I shouldnt have to do too much "fake ssh" and it'd work nicely
<Mez> (can use relative paths!)
<james_w> hey Mez
<Mez> hey james_w :D how're things/
<james_w> good thanks, you?
<Mez> tired
<Mez> should be asleep by now ;)
<Mez> but i always stay awake on my days off ;)
<Mez> poolie, though I doubt you'd be happy with me pulling in conch as a dependency ?
<poolie> use paramiko, we already depend on it
 * Mez doesnt know how to do it with paramiko though :0
<Mez> more learning :-0
<Mez> gonna sleep, will look at it later
<spiv> poolie: Not sure why AddTask is slower, judging from http://benchmark.bazaar-vcs.org/usertest/log/usertest.log it's probably just noise.
<poolie> thanks spivvo
<poolie> night
<Odd_Bloke> abentley: Shelf 2 sounds really cool. :)  I've been wanting a git-gui-esque tool for commits, and this should make it much easier.
<intellectronica> hya. i'm getting the following error when trying to push to a (stacked) branch on LP:
<intellectronica> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://intellectronica@bazaar.launchpad.net/%7Eintellectronica/launchpad/me-too-ui-updates/.bzr/repository/')
<intellectronica> any idea what this might be?
<intellectronica> abentley: ^^^
<spiv> intellectronica: I have a patch to fix that bug
<intellectronica> spiv: is that something that i can apply locally, or something that would need to happen on the server?
<spiv> intellectronica: https://bugs.edge.launchpad.net/bzr/+bug/230902, http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081008054310.GC19754%40steerpike.home.puzzling.org%3E
<ubottu> Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]
<spiv> intellectronica: local
<spiv> intellectronica: note that fixing that bug won't make things work, exactly.  It'll just let us see what the real underlying error is, rather than this secondary error.
<intellectronica> spiv: ok, i'll give it a try. thanks!
<spiv> intellectronica: My guess is you'll see an error like the one stub reported in the comments of that bug (i.e. what he saw after applying my fix)
<spiv> intellectronica: If so, I don't have any insight into that, but following up with abentley and/or filing a bzr bug would be appropriate.
<intellectronica> b.t.w this only happens if i try to push to the existing branch. pushing to a new branch in the same repository works fine
<spiv> intellectronica: a -Dhpss trace *might* give a hint
 * spiv -> bed
<spiv> intellectronica: I'd love to hear how it goes, though.
<intellectronica> spiv: sure, i'll update when i have more info
<intellectronica> good night
<spiv> intellectronica: thanks!
<Jc2k> lifeless: awake :-\?
<idnar> http://code.mumak.net/2008/10/more-bzr-hacking.html --- what are "working trees"?
<abentley> intellectronica: It's worth noting that initial push and subsequent pushes use quite different code paths.
<spiv> idnar: what SVN calls the working copy, basically.  i.e. files on disk that you can look at, edit, and run commands like "commit" and "revert" on.
<intellectronica> abentley: i don't know if this is relevant. i pushed to that branch many times. the last time just a few minutes before it stopped working
<abentley> With that patch applied, the real error won't be masked, and we'll have more hope of solving it.
<spiv> intellectronica, abentley: random sleepy thought: maybe autopacking in a stacked repo does something funny?
 * spiv -> really sleep!
<abentley> spiv: Does autopacking in general still do something funny?
<spiv> (if autopacking is occuring, the .bzr.log will say so)
<idnar> spiv: how does that differ from a bound branch?
<abentley> I know jam had a patch for that.
<abentley> idnar: They're completely different concepts.  A bound branch does not necessarily have any files that you can edit, commit, etc.
<idnar> I guess I'm just confused about terminology
<abentley> A working tree is just the collection of files that that you can edit, commit, etc.  It may be in the same place as your branch.  It may be in a different place.
<idnar> okay
<idnar> and how do "repositories" work?
<idnar> man
<idnar> maybe it would be easier if I forgot everything I thought I already knew about bzr and started again
<idnar> I'm reading some docs now, and nothing seems familiar :P
<awilkins> idnar: I've admined SVN repos for years, and it took me a few days to get a handle on DVCS
<idnar> awilkins: I'm familiar with half a dozen DVCS tools, and I use them on a regular basis
<idnar> it's just that bzr has changed so much since I last used it
<awilkins> Ah, yes, the pace doth quicken most fleetly
<awilkins> I started around 0.9, I think it's jsut got better rather than scarier since then :-)
<idnar> last time I used bzr, it didn't even work at all on win32 due to assumptions about path delimiters
<awilkins> Since about 1.6 it's even been quite nippy on windows
<awilkins> Although it still makes you green when you bzr st the same tree on Linux and get the rsponse back in less than a second
<awilkins> OTOH, Mercurial still doesn't work for my project on windows because of the escaping-caps-with-underscores-in-long-paths thing
<idnar> I'm a darcs user most of the time
<awilkins> I tend to stick with things that work well on win32, alas.
<awilkins> Does darcs?
<idnar> I haven't run into any issues
<idnar> it can be a bit tricky to get ssh working, but that's not really darcs's fault
<awilkins> I've had success with bzr+ssh on windows
<awilkins> Also with bzr+http over IIS
<awilkins> You're right about SSH being a PITA though
<idnar> anyhow, to be candid, I prefer hg to bzr in situations where darcs isn't appropriate
<idnar> but then, bzr has launchpad integration
<awilkins> Fair enough ; I never used it long enough to try it for the aforementioned reason
<idnar> which is cheating, but it's pretty darn convenient
<awilkins> I had a project that needed good, easy merges
<idnar> and of course, there are plenty of projects where I don't get to choose the VCS tool
<awilkins> SVN wouldn't cut it, and was too slow
<idnar> so I need to know how to use pretty much everything :P
<awilkins> Hg I tried next, but epic fail oin long paths with lots of caps in
<idnar> honestly, part of my preference for hg is probably just that my mental image of bzr is still circa 0.6 or whatever where everything sucked
<Peng_> There's work on long paths in hg.
<awilkins> git was too immature at the time (on win32)
<idnar> (like, horrifically awful network performance)
<awilkins> And still is, IMHO
<awilkins> (git, immature on win32, that is)
<idnar> man, git
<awilkins> I have no opinion on the horrible network performance of bzr
<idnar> I didn't think it would be possible to come up with a more confusing tool than tla
<idnar> and then I tried git out
<idnar> bzr's network performance got fixed ages ago
<Arjen> idnar: When was that?
<awilkins> My main problem with bzr and network performance is unrelated to the network protocols ; it's more to do with it considering network shares on Windows to be local filesystems
<idnar> uhm, 0.7? 0.8? something like that, I think
<Peng_> ...Bzr's network performance used to be horrific, and now it's fast? It's still pretty bad, so wow, it must've been *terrible*.
<awilkins> My problem is that unpacking is probably faster than, copying files over an SMB share on a VPN
<idnar> well, I checked in about 100MB of repository
<idnar> then I checked in a one-line change to a single file
<idnar> and pushed that over the network
<awilkins> but bzr will copy files if it can.. regardless of network speed, if you are using filesystem urls
<idnar> and watched bzr transfer something like 200MB of data before it completed
<fullermd> Oh, it was.  Weave-era network access was unbelievably painful.
<idnar> that was one of the reasons I gave up on bzr at the time
<Peng_> Hahaha, that's awesome.
<idnar> so I dunno if it's great now or whatever
<fullermd> It's still not overly pleasant, but at least now it's "Jeez, that's slow" rather than "Hey, where'd T Rex go?"
<idnar> but I haven't run into any "okay, this is just impossible" situations yet
<awilkins> And it still knocks the likes of SVN out of the parlk
<awilkins> *park
<idnar> I probalby need to sit down and do an in-depth side-by-side comparison of hg and bzr, just to get rid of my flawed mental image of bzr
<awilkins> SVN over DAV is painful in it's own special way
<idnar> SVN is really awful for me, because most SVN repositories are on the other side of a 400ms latency link for me
<idnar> so any DVCS basically wins automatically
<idnar> because I can commit locally etc.
<Arjen> idnar: wait, you mean git 0.8?
<idnar> Arjen: no, bzr
<idnar> I guess you were asking about git, not bzr
<Arjen> I was
<idnar> git hasn't ever really changed in the "oh my god complicated" department
<idnar> as far as I can tell
<Arjen> Not even in 1.5 and 1.6?
<idnar> did they remove commands in 1.5 and 1.6? :P
<Arjen> ALl the low-level commands where moved to a separate directory, out of your PATH
<awilkins> You could technically add a bzr-stylee porcelain to git, I suppose
<idnar> anyhow, it still takes me half an hour just to figure out how to fetch a copy of a project's source code from git
<Peng_> "git clone"?
<Arjen> Indeed
<Peng_> I have no idea what to do after that to pull new changes or branch or commit or anything, but I do know "clone".
<idnar> when it works, it's fine
 * Peng_ doesn't use git much
<idnar> but when you get an error message, it's nearly impossible to tell what you did wrong
<Arjen> Peng_: git branch, git fetch, git merge
<Arjen> idnar: True, in a number of cases
<idnar> if I was familiar with git concepts in-depth, I'd probably have no problems interpreting the error message
<Arjen> I've been playing with bzr lately, but I can't seem to do basic stuff.  Like, getting it to tell me when a file was deleted, even if I know the file-id
<idnar> but I don't, so all I know is that the URL someone gave me isn't something I can "git clone", with no idea of what to do next
<Arjen> Or basic grepping in the source at a revision
<awilkins> Arjen: The "when did my file get deleted" one is tricky at the moment because of the way inventories are stored
<awilkins> Arjen: You have to compare inventories from each revision to work it out.
<Arjen> awilkins: then 'git log --diff-filter=D -- $file' is a viable alternative ;-)
<awilkins> Delta-storage for inventories would probably make that work a lot easier - anyone working on that?
<LarstiQ> ehm
<LarstiQ> awilkins: I'm reasonably sure that is the case
<LarstiQ> awilkins: and what Arjen mentioned would work the same way?
<awilkins> LarstiQ: That it's being worked on or that it already so? I was working under the impression that each revision stores the inventory in-toto
<awilkins> I think the point is that you cant tell when a file is deleted from doing a log on just the file because it's deletion is not one of the log entries it participates in
<awilkins> It just one day isn't there... rather than an entry which explicitly says "delete this file-id"
<LarstiQ> awilkins: afaik it's inventory deltas for ages
<awilkins> LarstiQ: Is it "we store the inventory" and that's delta compressed, or "we store what changed in the inventory for each revision" ?
<LarstiQ> awilkins: but regardless of storage, doing the same operation as git log --diff-filter=D should be possible right now
<LarstiQ> awilkins: I don't really see a big difference between the two
<awilkins> It's been asked in here more than once and I've not seen a quick, concise way of doing it that didn't involve running the whole log
<awilkins> LarstiQ: The former has no way of telling when the file was deleted just from reading inventories containing the file-id
<awilkins> LarstiQ: You also then have to check all the children of inventories with that file-id to see if it becomes absent
<awilkins> LarstiQ: Which is not very nice to have to index
<LarstiQ> awilkins: right, but I'm under the impression the git log does it brute force as well
<Arjen> It does
<awilkins> I have no idea, but it seems a waste both way
<awilkins> And i've yet to see a cheap and easy way of finding deletion revisions for a single file in bzr
<awilkins> An inventory entry that said "deleted this file" would probably help a lot
<Arjen> renames should be easier, I think?
<awilkins> renames should be very easy, the file retains it's id
<Arjen> But there's no command-line method to do that?
<awilkins> Arjen: I wrote a log-on-fileid option into it once in about 5 minutes
<awilkins> Arjen: So it's not hard... it just didn't solve the problem it was aimed at (finding deletions)
<awilkins> Arjen: Very small hackage on log command required
<awilkins> Arjen: It uses file-id internally anyway for "log foo"
<LarstiQ> Arjen: log would be what I'd use
<Arjen> And script it
<Arjen> Which is of course a valid method, but requires work ;-)
<awilkins> List a revision where you know the file is, grab the file-id, hack log --file-id in
<Arjen> Uhm, hack log.py, you mean?
<james_w> what, no jelmer? Unheard of.
<Peng_> Is it safe to use a relative path as a branch's parent?
<LarstiQ> Peng_: safe as in? If you then move the branch or it's parent around it won't be able to find the parent
<Peng_> LarstiQ: Well sure, but will random commands fail? What if Launchpad mirrors the branch?
<LarstiQ> Peng_: but it's ideal for when your branches are available via http and /srv/bzr wouldn't really help someone who mirrors
<LarstiQ> Peng_: no, no problems there
<Peng_> Heh, that's exactly why I'm asking. I just did "bzr missing" on a branch in /srv/bzr whose parent is right next to it, and it contacted the HTTP server since that's what I'd set the parent to.
<LarstiQ> Peng_: this was also the exact usecase for it :)
<Peng_> :)
 * Peng_ goes off to edit some branch.conf files.
<awilkins> james_w: jelmers client had an excess flood earlier
<james_w> jelmer: hey
<james_w> jelmer: I was just looking at https://bugs.launchpad.net/bugs/132191 and can't really work out what's going on any more
<ubottu> Launchpad bug 132191 in bzr-gtk "installs unuseable desktop file to bzr commit-notify" [Medium,Triaged]
<james_w> jelmer: the "bzr commit-notify" command still doesn't work on Ubuntu, but I can't find anything disabling it. There seems to be a bzr-notify script in bzr-gtk, is this intended to be used now?
<LarstiQ> doesn't work in what way?
<LarstiQ> james_w: you might want `bzr lan-notify` from bzr-dbus
<james_w> hey LarstiQ
<james_w> "bzr commit-notify" gives unknown command
<abadger1999> Hey all, I was experimenting with 1.6.1-rich-root format on one of my branches.
<LarstiQ> abadger1999: and? :)
<abadger1999> but it seems I can't push from that to a branch with the default format.
<abadger1999> How do I convert the branch back to default?
<abadger1999> (I actually converted a shared repository so losing and recreating all the revisions would be painful.)
<LarstiQ> abadger1999: default being pack-0.92?
<abadger1999> Yeah.
<abadger1999> LarstiQ: bzr upgrade --default
<Peng_> Rich roots store extra metadata. You kind of can't downgrade.
<Peng_> It's possible to bzr init && bzr pull.
<Peng_> (to downgrade)
<Peng_> But bzr upgrade won't do it.
<abadger1999> Peng_: pull as opposed to branch?  I'll try that.
<LarstiQ> maybe we should have a bzr downgrade
<Peng_> Just hava it print "Hahaha, nice try."
<LarstiQ> Peng_: ooh, I can make that
<abadger1999> Peng_: Nope.  That didn't work.
<abadger1999> bzr: ERROR: KnitPackRepository('file:///home/badger/pkgdb/.bzr/repository/') is not compatible with
<abadger1999> KnitPackRepository('file:///home/badger/programming/.bzr/repository/') different rich-root support
<Peng_> ....Really?
<abadger1999> Same error as I get when I tried to bzr branch from the richroot repository to a non-richroot shared repository.
<abadger1999> Really.
<Peng_> Huh.
<abadger1999> bzr-1.7rc2
<abadger1999> bzr init 0.3.x ; cd 0.3.x ; bzr pull ~/programming/0.3.x
<abadger1999> There's shared repositories on both sides of that.
 * abadger1999 tries without shared repo
<LarstiQ> Peng_: bzr get http://richtlijn.be/~larstiq/downgrade
<abadger1999> LarstiQ: Does that have a test case? :-)
<LarstiQ> abadger1999: I don't have a good answer
<LarstiQ> abadger1999: doh!
<LarstiQ> abadger1999: I'll add it right away
<abadger1999> :-(
<abadger1999> heh
<jelmer> james_w, yes, bzr-notify should be used now
<abadger1999> Well, gorramit.  This sucks.
 * abadger1999 figures out least time consuming method of recreating all the changes
<jelmer> james_w, Still there?
<Peng_> LarstiQ: :D
<james_w> jelmer: yeah.
<james_w> jelmer: The .desktop is out of date in this version then. I presume it's fixed in experimental?
<jelmer> james_w, It's not yet fixed in experimental, though it should be trivial
<james_w> jelmer: ok, I've uploaded a fixed desktop file to Ubuntu. Would you like me to make the change for experimental?
<jelmer> james_w, I hope to fix it upstream in a couple of days, not sure if it's important enough to fix in experimental before then
<james_w> oh, it's fixed upstream I think
<james_w> 603 	Exec=bzr-notify
<james_w> there is one more change here that passed me by though, changing the icon names in the .desktop files
<fullermd> "There are some issues we would like to address and I'm looking to talk to some people with Subversion internals experience that can help us optimize the Subversion experience for our users."
<fullermd> Your solution; I has it.
<awilkins> Kittens?
<fullermd> Well, given the choice between handing my code to kittens or subversion...
<awilkins> Well, only if "kittens" is the codename for VSS around here
<awilkins> I would say that VSS is only marginally better than "big network share" if only it didn't waste so much of your time
<metajack> Anyone know why trac-bzr is showing revision names with %2F and %3A?
<fullermd> Double encoding I presume.
<jfroy|work> ack, bzr-svn just died on me :|
<jelmer> hi jfroy|work
<jfroy|work> Tried to branch a svn branch (previously used with bzr), and the command died with bzrlib.errors.KnitCorrupt: Knit _KnitGraphIndex(CombinedGraphIndex(GraphIndex
<jfroy|work> jelmer: hello, and help! :p
<jfroy|work> Does that error ring any bells?
<jelmer> jfroy|work, please file a bug
<jfroy|work> Will do.
<visik7> jfroy|work: works here using bzr.1.7
<visik7> not with bzr-dev
<jfroy|work> Any way to make bzr-svn happy again?
<jfroy|work> I'm using 1.7.1 and 0.4.13
<rockstar> jelmer, hi
<jelmer> rockstar, hi
<visik7> jfroy|work:  bzr branch 1.7  and bzr-svn trunk
<jelmer> jfroy|work, I'd need to look into it
<rockstar> jelmer, someone in my dent feed would like an updated trac-bzr release.
<rockstar> Looks like you're the team owner.
<jfroy|work> I think this is happening only for a subset of a large svn repository.
<jfroy|work> I have a checkout of another unrelated svn branch hosted in the same repository working fine.
<jelmer> jfroy|work, yeah, this sort of error would be related to a specific branch
<jelmer> rockstar, I am, though pretty much by default
<jelmer> rockstar, trac-bzr needs to be fixed to work with bzr >= 1.6
<rockstar> jelmer, well, this user says he's got all his bugs fixed with bzr 1.6 in trunk.
<jelmer> rockstar, if he does, he hasn't published his branch on launchpad
<aruiz> lifeless: ping
<rockstar> He was going to use svn, because he thought trac-bzr was broken, but then he said all the bugs were fixed in trunk, so he used that.
<jelmer> rockstar, I'm aware of at least one bug remaining in trunk
<jelmer> since it uses _get_weave() which was removed in bzr 1.6
<jelmer> rockstar, is there a particular reason he wants a release rather than just using trunk as is?
<flacoste> i created a repository with --no-trees, is it possible to add a tree to branch in the repository afterwards?
<luks> bzr checkout . should do it
<metajack> jelmer: are revision names in trac supposed to show with %2F?
<jelmer> metajack, in URLs, yes, other than that, no
<metajack> jelmer: also, revision 44 of lp:trac-bzr does not seem to fix the %3A problem for 'current:'
<flacoste> luks: ok, thanks, i'll try that
<metajack> jelmer: they show up everywhere with escaping for me.
<metajack> (running interpid latest bzr and trac, and trac-bzr from lp:trac-bzr trunk)
<metajack> jelmer: I'm the user rockstar was talking about btw :)
<jfroy|work> jelmer: is there any way to fix the issue, say by resetting the bzr svn props on all the files or some flag to bzr?
<jfroy|work> the bug is https://bugs.launchpad.net/bzr-svn/+bug/280850, btw
<ubottu> Launchpad bug 280850 in bzr-svn "bzrlib.errors.KnitCorrupt raised while checking out or branching a specific Subversion branch" [Undecided,New]
<jelmer> jfroy|work, not really without knowing what's actually happening
<jelmer> jfroy|work, I'll see if I can have a look at it later tonight
<jfroy|work> No rush, I can fallback to svn in the meantime.
<lexrupy> hello all
<lexrupy> I got here a new (to me) behavior of bazaar checkouts
<lexrupy> when I was out of network, I performed a bzr commit, and "automagically" the commit behaves as I had "bzr commit --local"
<lexrupy> is that natural?
<jelmer> metajack, are you sure you're running trunk?
<jelmer> (it passes the tests)
<metajack> jelmer: Pretty sure.  I see the revision 49 change in backend.py on the machine.
<jelmer> metajack, trac-bzr is pretty much unmaintained at this point
<jelmer> I've been fixing things that I hit since I had an instance of it running
<metajack> I assume you must not be using bzr 1.6+ on that instance.
<metajack> I think all the 1.6 bugs are fixed now, and it's just down to this double quoting issue.
<jelmer> menesis, trunk still uses _get_weave() and that's gone in 1.6
<jelmer> menesis, so I'm sure there's at least some code paths that break with 1.6
<metajack> There is a patch for that in the tracker, and it works.
<metajack> I assumed that had made it to trunk since the other part of that patch was in revision 49.
<jelmer> I didn't merge that patch because it's very inefficient
<metajack> Better inefficient than completely broken, no?
<jelmer> metajack, In my case, the two would be the same since trac has already taken the system down a couple of times
<jelmer> metajack, Anyway, I'm happy to hand over the trac-bzr-team maintainance to somebody else if they're interested
<jelmer> but I have no interest in continuing to work on it myself
<metajack> Sigh.
<metajack> This has pretty much been the only thing preventing me from using bzr.  I'm sad to see it abandoned.
<metajack> I will spend another little while trying to fix it. If I'm successful perhaps I will take you up on the maintainer offer.
<jelmer> Thanks - it needs somebody who can spend more time on it then the occasional ad-hoc fix I have been doing.
<lexrupy> anyone can confirm this to me?
<lexrupy> please
<jam> lexrupy: I haven't seen that behavior before
<jam> Though I thought there was something with bzr-gtk that would detect your network connection
<jam> jelmer do you remember that?
<lexrupy> ... I also not before this version
<fullermd> Does info still show it as a checkout?
<lexrupy> yes
<lexrupy> now I am using version that comes with ubuntu 8.10beta
<lexrupy> bzr --version returns => Bazaar (bzr) 1.6.1
<lexrupy> I have also bzr-gtk installed
<lexrupy> I found it very strange, because earlyer versions (also 1.6.x downloaded from ppa repo) were not doing this
<fynn> Bazaar always keeps the file ownership and permissions on *NIX systems, right?
<lexrupy> and with that versions I also used bzr-gtk
<lexrupy> fynn: I never had this kind of problems... permissions always kept right
<fynn>  So if I delete a monitored some_file.py, and then "bzr revert some_file.py", I should always get some_file.py with the same permissions and ownership information?
<lexrupy> fynn: I cannot do the rigtht answer for this question....
<lexrupy> going back to my "issue"
<lexrupy> the good part is that all things gone right
<Peng_> fynn: The only permissions bzr cares about is the execute bit.
<Peng_> fynn: Also, try it and see. :P
<lexrupy> local commits, and the when network was resumed I done "bzr update", all things happened as I had "bzr commit --local" off the network, a merge has been done and next commit goes to master branch
<lexrupy> *gone to master branch
<miracle2k> I want to go to (and use) a certain revision of a branch. what is the right way to do that? "bzr revert -r d"?
<luks> depends on your definition of 'use'
<fullermd> Depends on just what you mean by "go to and use".
<luks> heh
<miracle2k> actually, I want to use the 1.8.0 release of bzrtools, since the trunk requires a new bzr version
<miracle2k> so i have a branch of lp:bzrtools, except that I need an older version
<miracle2k> I know I could do "bzr checkout -r", but what would I do if I have an unbound branch?
<fullermd> I'd just pull down to the version you care about.
<Odd_Bloke> miracle2k: 'bzr uncommit -r' is probably what you want.
<fullermd> Then you're all set to pull up to a later version when you want to.
<fullermd> No, don't do that; it's extra work.  Just use pull.
<Odd_Bloke> Uhm... how is it extra work?
<fullermd> Because you have to do a revert afterward.
<miracle2k> I already tried "bzr pull -r tag:release-1.8.0", except it gives me "no revisions to pull"
<Odd_Bloke> Hmm, true.
<Odd_Bloke> miracle2k: 'pull --overwrite'
<fullermd> You need --overwrite to pull, since you're moving backward.
<miracle2k> ah, I see, that works.
<miracle2k> thanks everybody
<poolie> hello
<poolie> vila: are you still here?
<lifeless> poolie: hi
<lifeless> poolie: middayish ok with you ?
<lifeless> poolie: also, for usertest, patches via lp merge requests or to the list ?
<poolie> i think so
<poolie> i should check with steph
<poolie> i don't know, either
<poolie> did spiv post his yet?
<lifeless> not sure
<lifeless> I'm adding st -r -2..-1
<poolie> lifeless: also, you need to tell marianna _today_ when you're arriving and departing
<lifeless> oh frell
<lifeless> I need to book tickets
<poolie> you don't necessarily need to book as there are plenty of flights, but you do need to decide
<poolie> but you should book soonish
<lifeless> marianna is in the uk yes?
<poolie> yep
<lifeless> righto
<lifeless> btw, usertest doesn't lock itself out :P
<lifeless> and bzr.inv is a tad slower at fetch
<lifeless> hilarity ensued
<poolie> ah
<poolie> i wondered how that could be happening
<lifeless> so looking at it
<lifeless> the output name rearranging is in the bash script
<lifeless> so I think we need to lock in the bash script
<lifeless> as the output name stuff should be protected
<poolie> yes, we should
<poolie> i started adding one but because it needs to be bulletproof against the machine stopping, as happened a couple of times, i was a bit lazy
<Accidus> Hmm... I want to use a different version of a plugin. I've set the BZR_PLUGIN_PATH variable to point at the new directory, but bzr still doesn't list it under 'bzr plugins'.
<lifeless> poolie: well, we can unwedge after a restart
<lifeless> Accidus: you need to point at the containing directory
<lifeless> if your plugin is /foo/bar/myplugin
<lifeless> BZR_PLUGIN_PATH should be /foo/bar
<Accidus> That's what I did.
<lifeless> poolie: also I think there is a stock shell lock utility one can use, I don't recall the name offhand
<lifeless> Accidus: does bzr report an error loading it perhaps?
<lifeless> Accidus: and are you on windows?
<Accidus> Do I need to look anywhere, or will it output it to the terminal?
<Accidus> Now, working on Ubuntu
<Accidus> * no
<lifeless> it should put a one-liner to the terminal
<lifeless> and details to ~/.bzr.log
<Accidus> No error reported on terminal
<lifeless> Accidus: well look in the log anyhow :)
<Accidus> No, doesn't seem to contain any errors
<Accidus> Here's what I did. I probably missed something
<lifeless> it should say
<lifeless> looking for plugins in XXX
<lifeless> where XXX is your path
<Accidus> 1. Set the BZR_PLUGIN_PATH to point to /home/accidus/dev/plugins
<Accidus> And the actual plugin is a directory under plugins
<Accidus> So that if I ``ls $BZR_PLUGIN_PATH'', I see the plugin's dir listed
<Accidus> Ah. I have an idea.
<Accidus> Okay. I'm stoopid
<Accidus> Never mind me. Sorry to have wasted your time.
 * Accidus blushes.
<lifeless> ?
<lifeless> poolie: btw please let the current usertest run complete
<lifeless> poolie: I will get valuable data from it even though its glacially slow
<Accidus> Didn't export the env var
<Accidus> So bzr didn't have it.
<poolie> did you kill off the others?
<lifeless> poolie: yes
<lifeless> poolie: oh foo, just realised, they're stomping on teh same file, so I won't gain data anyhow
<lifeless> poolie: so don't worry, I'll nuke that one too
<lifeless> poolie: how does this sound - I will disable the cronjob
<lifeless> poolie: and start a fresh run
<poolie> if it's going to be slow i'd rather get the locking etc fixed up
<poolie> i can do it in a bit
<lifeless> it will be, I'd like a result today though and I suspect that even with just one running it will be pushing it to finish by 5
<lifeless> I've just started a task with cron disabled; its easy enough to kill that and please do so if you want to
<lifeless> I'm also trying to dig up an easy locker for us
<dfc> Is the bzr service up and running on lp?
<dfc> i am getting an odd error and the references that I can find for it have all coincided with a lp outage.
<jam> lifeless: I'm looking over your "repository" code. Quick point of clarification
<jam> you have a "chk_serializer" module
<jam> which seems to be an XML derived form
<jam> is that meant to go away in time?
<jam> also, some quick naming thing for CHKInventory. you use the term "entry" in multiple ways. For example:
<lifeless> jam: not unless we kick away all the existing code that checks serializer objects; its used for the revision objects
<jam>             return self._bytes_to_entry(
<jam>                 self.id_to_entry.iteritems([file_id]).next()[1])
<lifeless> jam: inventory objects are not serialized through it, and finally
<jam> lifeless: sure, but not for inventory objets?
<lifeless> its used for equality testing
<lifeless> repo1.serializer != repo2.serializer
<jam> lifeless: k. I mostly just wast trying to understand, as you added special code to unpack inventories
<lifeless> dfc: afaik it is
<jam> _unpack_entry is only used for inventory stuff
<jam> I realize it is "work in progress" I just wanted to make sure I understood
<dfc> AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer'  . . . .. . . > http://pastebin.com/f57b9959d
<dfc> lifeless: any idea why I would be getting that message?
<jam> dfc: you only get that error if you run "-Dhpss" what is the failure without it?
<jam> dfc: (the cause is buggy code in a debug statement)
<dfc> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<lifeless> jam: that code fragment uses entry in the same way I think
<lifeless> dfc: I suspect a ssh key issue
<lifeless> dfc: try ssh bazaar.launchpad.net
<jam> lifeless: I think you need "sftp bazaar.launchpad.net"
<jam> since it doesn't support plain connections
<lifeless> jam: no, ssh will test auth just fine
<lifeless> 08:36 < jam>             return self._bytes_to_entry(
<lifeless>                                                  ^ convert from bytes to an inventory entry object
<lifeless> 08:36 < jam>                 self.id_to_entry.iteritems([file_id]).next()[1])
<lifeless>                                              ^ a CHKMap (aka persistent dict) from file id to inventory entry
<jam> lifeless: so that code is a bit confusing because "id_to_entry" is "id_to_bytes" object
<jam> I understood what was happening eventually
<lifeless> ok
<lifeless> thanks for looking!
<jam> you also poke at CHKMap._root_node directly in CHKInventory, is it meant to be that coupled?
<lifeless> I'm being cautious about making things public attributes
<lifeless> given all the insane fuss about it in reviews over the last few mnoths
<jam> then I'm a bit surprised that you expose "CHKInventory.id_to_entry" as a plain attribute, and hide CHKMap._root_node
<jam> id_to_entry seems like an implementation detail
<jam> are you planning on making it more public?
<lifeless> I very much expect fetch and inventory delta iteration to walk the maps
<lifeless> if that ends up being in methods on CHKInventory then id_to_entry will become private
<lifeless> so root_node is something I'm not sure how/where/when it belongs; its part of the how-to-make-COW-clean question
<lifeless> which isn't that functional, but is important for safety and cleanliness
<lifeless> id_to_entry is something I am sure it is in the right place; I'm not 100% it is public but I suspect it is
<jam> lifeless: are the final value nodes all single-inventory-object bytes?
<jam> I don't see anywhere that they are aggregated
<lifeless> jam: thats right
<lifeless> jam: I was working on the 'what breaks when we have multiple documents per inventory' issue
<lifeless> this was a fast to implement way to achieve that
<jam> so the 4.4k entries in .cix for bzrtools is because there are that many total versions of the various inventory lines?
<jam> I'm still understanding why some values in that index have an "N" as the prefix, but I'll get to that somewhere
<lifeless> you'll have 1 entry per inventory (the root node of the CHK) and 1 per unique inventory entry value
<lifeless> isn't N no end of line ?
<lifeless> (how are you looking at the index - be sure you get \x00 seperators visible)
<lifeless> spelling blah
<jam> lifeless: "bzr dump-btree --raw | vim -R -"
<jam> \x00 shows up just fine
<lifeless> ok
<lifeless> whats an example with a leading N ?
<jam> sha1:0004feba9f0af7777528a6ac7a62abb83cd6ed3d \00 \00 N3131511 228
<jam> I added spaces around \00 to make it obvious
<lifeless> yes thats the no end of line marker
<jam> ah
<lifeless> it says no end of line, starts at 3131511 for 228 bytes
<lifeless> so its a value
<lifeless> because values are chkvalue:\n%(BYTES)s
<lifeless> and the serialiser for inventory entries doesn't put a trailing \n as that would be awkward
<lifeless> so specifically its a chkvalue of an inventory entry
<lifeless> jam: so my general approach for testing the next bits...
<lifeless> jam: I want to parameterise CHKMap by how to aggregate values/internal nodes
<lifeless> jam: and pass those same parameters to CHKSerializer
<lifeless> so we get several different serializer values
<lifeless> then we can trivially run up N different formats each behaving differently but with all the higher level iteration etc code the same
<lifeless> jam: I'm not going to do this immediately, just sketching out the approach in the hope you'll want to dive in :P
<jam> so just to make sure I understand
<jam> at the moment you have a structure with 1 root node that contains a chk to every file-id
<lifeless> jam: what I'm going to do now is to teach fetch to use CHKInventory.update(inv_delta) rather than full reserialization
<jam> basically, just as though you took the current inventory and hashed each line separately and put it into the repository
<lifeless> jam: yes, thats a fair description. layerwise it sounds different :)
<lifeless> jam: actually, not quite, you missed the inventory object itself; the 4-liner that has root id, chk root and revision.
<lifeless> so meta node, dictionary root, and one chk per file id
<jam> k
<ricardokirkner> hi. is this the place to (also) make questions about bzr-svn?
<lifeless> ricardokirkner: sure
<lifeless> jelmer: your public awaits
<ricardokirkner> I am trying to compile bzr-svn from trunk (I know, I know)... and I'm getting some import issues
<ricardokirkner> namely 'cannot import name foreign'
<lifeless> ricardokirkner: there was a patch on the list for this
<lifeless> ricardokirkner: I believe its been applied already, just pull again
<lifeless> jam: another related thing is to add a path_to_id map
<lifeless> jam: and use it it avoid full iteration when populating .children
<ricardokirkner> lifeless, I just checked it out... last revno is 1935
<ricardokirkner> mhh... I did bzr branch lp:bzr-svn is this correct?
<ricardokirkner> or should I use another branch?
<lifeless> ricardokirkner: I'm not sure
<lifeless> see the bzr-svn docs on  the wiki
<ricardokirkner> alright.. and I will look in the mailing list
<ricardokirkner> thx
<jam> ricardokirkner: I think the lp:bzr-svn branch isn't particularly stable
<jam> I would recommend using a released version
<ricardokirkner> jam, ok
<ricardokirkner> jam, I wanted to build bzr-svn, in order to debug some issues with http authentication
<ricardokirkner> but I can first try with a more stable release
<jam> ricardokirkner: well, he also uses tags
<jam> so you might do "bzr branch lp:bzr-svn -r bzr-svn-0.4.9"
<jam> I'm not 100% sure his naming scheme, but it is something like that
<jam> you can branch the whole thing and then "bzr revert -r tag:..." as well
<ricardokirkner> alright.. I'm checking the 0.4 series right now
<Peng_> FWIW, I run bzr.dev and lp:bzr-svn/0.4 without issues, but I only use bzr-svn for pulling things.
<Peng_> (And bzr-svn does occasionally break, but not in data-lossy ways or anything.)
#bzr 2008-10-10
<jelmer> re
<jelmer> maybe one day, after bzr-gtk gets a pqm, we can add a pqm for bzr-svn as well and make sure it always passes the testsuite...
<lifeless> yes
<lifeless> I"m  blocked on that as I mentioned :(
<sminnee> Hi everyone
<sminnee> I was wanting to get some information about the current status of nested trees
<poolie> sminnee: they're partially supported at the moment but still classed as expeirmental
<sminnee> poolie: it seems as though it's been that way for nearly 2 years?
<sminnee> do you know what kind of risks there are in using it that make them experimental
<sminnee> I'm currently on svn and svn:externals are an absolutely critical feature for me.
<poolie> abentley could probably give you a more accurate answer
<poolie> i think not all merges work across them correctly
<lifeless> ok, bbiab
<sminnee> poolie: but if you were keeping your merges restricted to happening within a single subtree, you would be okay?
<sminnee> for example, i have "projects" and use svn:externals to link the applicable modules into each project
<sminnee> so if I was branching and merging solely within the context of individual modules, i would be okay?
<poolie> i think that would work
<poolie> possibly we should just promote this to properly supported and deal with anything else that crops up
<sminnee> poolie: i would vote for that approach :) it's a very useful feature and has been in-development for some time.
<sminnee> I might have a play with them and complain when they start breaking, then :P
<poolie> that'd be good :)
<poolie> spiv, do you want to talk about the unlock exception handling?
<spiv> poolie: ok
<poolie> here, or on the phone?
<spiv> Here's fine, I think.
<spiv> I'm still pretty uncomfortable about the suggestion to suppress exceptions during unlock.
<poolie> btw i did your tweak regarding the default argument - in fact i removed it
<poolie> so i'm not sure if it's simpler and cleaner, or just too careless
<spiv> It feels like it moves the complexity of handling unexpected conditions from a single, obvious place (the callsite) to a much broader and harder to determine scope.
<poolie> however, unless we can really think of a case where it makes a difference, i think we should do it
<poolie> hm
<poolie> that's one way to look at it
<spiv> So concretely, doing what I propose is clearly correct, and we know how it will behave.
<poolie> but another way is doing this just changes the particular cleanup functions, rather than adding something to every caller
<spiv> And hiding exceptions from unlock isn't clearly correct, at least not to me :)
<sminnee> I have another question if you're not sick of noobs: bzr svn-import for an HTTP svn repository doesn't seem to like 401 responses.  Does it support authenticated svn repositories over HTTP?
<poolie> i thought it did
<poolie> if jelmer is still here you could ask him
<jelmer> yep, I am
<poolie> spiv, so i'd cast it as
<jelmer> sminnee, What's the error you're getting
<sminnee> jelmer: bzr: ERROR: Invalid http response for http://svn.silverstripe.com/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<poolie> clarifying the behaviour of unlock to say "if the transport is closed, unlock will not raise an error"
<sminnee> ooh I see - it seems to think it's a bzr repos
<spiv> So, here's another reason to do it my way: when we shift to requiring Python 2.5, I think we'll want to do it with a "with" statement anyway.
<sminnee> I executed ~/bzr/test: bzr svn-import http://svn.silverstripe.com/ repos
<jelmer> sminnee, bzr doesn't support http auth, bug 256612
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612
<jelmer> sminnee, you can work around it by using svn+http://svn.silverstripe.com/
<sminnee> jelmer: thanks.  Now I get "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("REPORT request failed on '/!svn/bc/64032'", 175002) " which sounds more like an issue with my repos.
<sminnee> I could use svn: or svn+ssh: however I get a different error ;) bzr: ERROR: exceptions.UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid data
<jelmer> sminnee, are you using bzr-svn 0.4.13 ?
<spiv> poolie: Hmm.  I'm not sure that just suppressing/avoiding errors due to the transport being closed will actually fix these bugs.
<sminnee> jelmer: yeah, looks like it. I just downloaded and installed bzr 1.7.1
<spiv> poolie: the underlying exception in at least one of these cases is some form of "revision X not present", i.e. a logic bug in bzr, rather than an environmental problem.
<jelmer> sminnee, please file a bug
<sminnee> jelmer: sure thing.
<poolie> and then the knock-on effect is that there's already a request pending, or that there's a write group open?
<spiv> Right.
<poolie> spiv, so the difference in behaviour between these options (as opposed to in the code)
<poolie> is just in the case where the unlock fails but there was no earlier failure, right?
<spiv> Hmm.  I think so.
<spiv> So there are four cases, (operation ok, unlock ok), (operation fails, unlock ok), (operation ok, unlock fails), and (operation fails, unlock fails).
<poolie> right
<spiv> (Which co-incidentally is why there are four test methods for my proposed helper :)
<poolie> in the current trunk code, we get case 4 wrong by showing the unlock exception when we want to show the original exception
<spiv> We seem to be disagreeing about the (ok, fails) case.
<poolie> mm
<poolie> i should say i'll be glad to have this fixed whatever solution we decide on
<spiv> In (ok, fails) I think I'd rather get the exception immediately.
<jelmer> hmm, did the API of record_entry_contents() change?
<poolie> yes
<poolie>     * ``CommitBuilder.record_entry_contents`` returns one more element in
<poolie>       its result tuple - an optional file system hash for the hash cache
<poolie>       to use. (Robert Collins)
<poolie> if i'd reviewed it i might have asked for a new name for the new protocol....
<sminnee> jelmer: here you go: https://bugs.launchpad.net/bzr/+bug/281035 there were similar looking bugs reported with the 'ascii' codec but i didn't see a UTF8 one.
<ubottu> Launchpad bug 281035 in bzr "unicode error on import-svn call." [Undecided,New]
<poolie> spiv, so you said in the patch for http://bundlebuggy.aaronbentley.com/project/bzr/request/<20081008054310.GC19754%40steerpike.home.puzzling.org>
<poolie> s/patch/letter
<poolie> that you can't distinguish those cases from inside the unlock, which is correct as far as i know
<spiv> Right.
<poolie> i kind of dislike needing to push the contents of these blocks into separate functions just to wrap them this way
<spiv> So the advantage of your idea is that unlock doesn't need to distinguish.
<poolie> yes, it is
<poolie> would anyone care?
<spiv> Yeah.  I don't much like it either, but I don't think it is actually *bad*, just mildly irritating.
<spiv> And in the case of functions like commit, it was probably large enough that it should be broken up somewhat anyway ;)
<poolie> with your patch the failure from unlock is totally lost
<spiv> Well, we can make that emit a warning.
<poolie> (though that is somewhat of a quibble because obviously we could both log it and re-raise)
<poolie> right
<spiv> I should have mentioned that idea in the patch (similarly we could do that in needs_write_lock)
<spiv> So this requires a time machine, but how soon might we require Python 2.5?
<spiv> If hypothetically it were tomorrow, then the decision I think would be easy: just start using with blocks.
<poolie> sure
<poolie> i don't think we should hold our breath
<poolie> by making decisions in the hope of switching soon
<poolie> because as was pointed out there, some distros are very slow
<jonoxer> Is there are "bzr-noobs" channel I can ask user questions on? I don't want to hassle everyone here with my stupidity
<poolie> hello jon!
<poolie> you're welcome here
<jonoxer> hey poolie!
<spiv> jonoxer: this is it.  I just hope noobs don't feel hassled by developers debating patches :)
<poolie> spiv, so what would your __exit__ clause do if it hit an exception in unlocking?
<poolie> allow it up, but only if there was no previous exception?
<spiv> file:///usr/share/doc/python2.5/html/lib/typecontextmanager.html (assuming you have python2.5-doc installed)
<spiv> If __exit__ blocks don't return a true value, then they propagate an error from within the block.
<spiv> Er, s/__exit__ blocks/__exit__ functions/
<poolie> yes, i see
<poolie> so you'd have something like this?
<poolie> try: unlock() except e: if orig_exc_type: return False; else: raise
<spiv> Well, just simply "try: unlock(); finally: return False" would be fine.
<spiv> At least, AIUI.  I haven't tried it out yet :)
<poolie> really?
<poolie> surely that will always hide the unlock execption?
<poolie> in other words (ok, fail) -> ok
<spiv> The __exit__ function receives the live exception as arguments (or three Nones if there is no exception from within the block).
<spiv> Hmm, that's true.
<spiv> So, your way is right :)
<poolie> lol
<spiv> Good thing I'd write tests... ;)
<poolie> so, we're all set? ;-)
<spiv> If we were using 2.5, sure :)
<poolie> so basically, i don't want to put extra work on the callers unless we actually care about seeing exceptions from unlock
<poolie> i'm not sure that we do
<spiv> Any exceptions at all?
<poolie> aside from systemerror
<spiv> Also, it just occurred to me, it's harder to write a test for a negative.  i.e. how do you write a per-branch test that "br.unlock() never raises"?
<poolie> well, you can't, any more than you can write a test for 'foo always does the right thing'
<poolie> however, you can test appropriate representative cases
<poolie> so...
<poolie> in practice i think we'd have a version that does raise exceptions, and we could test that
<spiv> Suppressing errors still makes me nervous.  How about this: unlock tries not to raise, but if it catches a non-internal error, warns the user
<poolie> right
<spiv> (And if it catches an internal error, maybe .bzr.log it)
<poolie> or even warn in either case
<spiv> At least that way if it goes wrong, we'll know why :)
<poolie> i guess i just feel like doing otherwise is getting too twisted up about an error for which we can't do anything
<poolie> there is another drawback though, which is that often people will get these warnings in addition to another error
<spiv> Well, I don't think "Connection lost\nWarning: TooManyConcurrentRequests" is helpful for a user.
<poolie> but that's probably reasonable, because it will tell them that the thing was not locked
<poolie> no, but if it was
<poolie> "Connection lost\nCould not unlock <.........>: smart medium already in use"
<poolie> maybe that's more plausible
<spiv> But then I find myself thinking "but if it's internal, and there isn't another exception, the user should know about it", i.e. I keep wanting it my way :)
<spiv> Maybe I can break that habit ;)
<poolie> should know about it in a stronger way than getting a warning?
<spiv> A "Could not unlock: $reason" message seems ok, although it's still a bit poor UI-wise to spray internal details to the user.
<spiv> Right, that's where my mind was taking me before I realised we'd been down that path already ;)
<poolie> so, we can choose to show more or less details as appropriate
<spiv> Ideally we'd tell the user "Could not unlock: connection was lost", I think.
<poolie> i guess the main difference is that in the (fail, fail) case, your approach would show just the original message, and mine would show both
<poolie> actually no, because i think we agreed earlier that it should log the exception too
<spiv> Right.
<poolie> and i think it is desirable not to ever hide them completely
<poolie> so it's just a matter of making them reasonably presentable
<spiv> The only significant difference is in the (ok, fail) case.  Exception vs. warn-without-interrupting.
<poolie> right
<poolie> can you think of any particular case that would make it more clear which is better?
<spiv> We almost always are just about to finish after an unlock, so the difference is usually minimal.
<spiv> I wonder if GUIs have a different requirement?
<poolie> i'm not sure
<poolie> i think actually they're going to converge on the same behaviour: if an exception occurs during a bzrlib call, log it, but don't stop
<spiv> Would LockBroken still be raised if the lock was broken from under us?
 * spiv thinks about what bazaar.launchpad.net needs
<jml> bzr processes that take up a third as much memory :)
<poolie> spiv, LockBroken is a good question but it makes me think that actually the higher-level code should be validating the lock earlier
<poolie> eg before switching the names file
<jonoxer> OK, time for my noob question. Scenario: migrating a team of devs from SVN to BZR. We have several existing SVN repos of varying sizes. I'm doing trials with a small repo while I figure this out. bzr-svn is installed. For simplicity we'll probably move to a central repo model on bzr so the workflow stays almost the same
<spiv> I don't think that's right.
<poolie> an exception indicating something bad happened in the paste is not much better than a warning...
<poolie> jonoxer: ok
<spiv> For SFTP, that would involve lots of round trips.  I think it's reasonable to be optimistic that evil hasn't happened.
<jonoxer> So far I've tried a couple of different things to see what happens...
<poolie> (this is kind of a digression but surely it would just take one round trip, to read the lock info file?)
<poolie> anyhow, yes, i think it's reasonable to be optimistic
<poolie> launchpad is an interesting case too
<spiv> It does, but you're proposing doing it several times, rather than just once when releasing the lock?
<poolie> as is the smart server; what should it do if unlocking fails
<poolie> am i?
<spiv> Well, I don't know what you mean by "should be validating the lock earlier eg before switching the names files" then.
<poolie> i guess my point was, if we want to avoid evil, it's better to check for it at the point where it'll actually help us avoid it
<poolie> i was assuming that we rename the names file just once, at the end of the write group
<spiv> Because at the moment over vfs transports we do do that one round trip at lock release time already, but it sounds like you're saying we should be doing something else?
<spiv> If someone breaks a lock from under an active client, there's not much we can do to stop bad things happening.  We can at least notice that it happened and let the user know, and that's what we're doing atm.  I'm not sure there's real benefit to doing anything more, but then I'm unclear on what you're suggesting :)
<poolie> i think the current behaviour is fine
<jonoxer> 1. Branching off an SVN repo (using "bzr branch file:///home/subversion/repositories/test testbzr"), which gives me a local working copy. That seems fine
<jonoxer> But what I need to do is create a shared repo, so...
<poolie> spiv, i'm saying that if the point of it is to say "something bad happened in the past" then a warning may be enough
<spiv> Ok.
<poolie> on the other hand if we're trying to actively detect the lock being stolen and change the client's behaviour to cope, then it'd have to be checking it earlier than unlock time - but this is probably in vain, because it could be stolen at any time
<spiv> Right.
<poolie> jml, btw are you coming here for lunch?
<jonoxer> 2. My reading (maybe wrong) of the guide at http://bazaar-vcs.org/SharedRepositoryTutorial is that I need to init a repo, then branch into it, so I tried this:
<spiv> jonoxer: "bzr init-repo --rich-root-pack testrepo", then use "testrepo/testbzr" rather than "testbzr" as the destination.
<jml> poolie: sure. was just waiting for your reply on #canonical :P
<spiv> jonoxer: the --rich-root-pack is necessary because bzr-svn requires a non-default format.
<jonoxer> spiv: aha, thanks, trying that now
<jonoxer> aha, seems to be good so far, thanks spiv! I'd tried "--dirstate-with-subtree" and "--subversion" (which I'd come across in some docs) but not --rich-root-pack
<spiv> poolie: I think I'm ok with making unlock try not to raise.
<poolie> spiv, anyhow, that's what i think, let's not spin on it
<spiv> poolie: but...
<spiv> poolie: what about fixing this bug for 1.8? :)
<poolie> hm
<poolie> so 1.8rc1 is already out, 1.8final is meant to be monday
<poolie> do you think this should be merged across?
<spiv> I think we should merge the initial patch I proposed as-is for 1.8.
<poolie> which bug exactly?
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/230902
<poolie> 230902
<ubottu> Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]
<jonoxer> OK, so now I need to make a branch from the repo, but a simple "branch" command fails ("ERROR: Not a branch...")
<spiv> jonoxer: you branch branches, not repos.
<poolie> ok, so this is more than just cosmetic
<poolie> spiv, that's ok with me for 1.8
<spiv> Right.  It'll still fail, but at least we'll know the real reason why :)
<spiv> poolie: thanks
<jonoxer> spiv: cool, so what is the equivalent to SVN's "checkout"? That seems synonymous with "branch" in bzr parlance
<spiv> jonoxer: you also checkout branches (not repos).  Let's see if I can find a good glossary for our terminology...
<spiv> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts
<jml> spiv, poolie: did you see the bug I filed yesterday about unlocking?
<spiv> jml: that rings a bell, but man, that was a whole day ago!
<jonoxer> spiv: thanks, I think I'm getting closer now. I appreciate the assistance
 * jml pokes around for a link
<jml> https://bugs.edge.launchpad.net/bzr/+bug/280608
<ubottu> Launchpad bug 280608 in bzr "Stacked-on branch not unlocked when commit_write_group fails on stacked branch" [Undecided,New]
<spiv> jonoxer: so if you've created a repository "repo", and have branches inside that repo, e.g. "repo/branch1", "repo/branch2", then you can do "bzr branch repo/branch1 DESTINATION".  You can't do "bzr branch repo DESTINATION" because there's no branch at "repo".
<spiv> jonoxer: I'm guessing that's the confusion that caused your "Not a branch" error.
<spiv> jml: that patch looks highly plausible to me.
<jml> spiv: it's courtesy of lifeless.
<spiv> Yeah, I saw.
<jml> oh good.
<spiv> I mean, not only does it come from lifeless, it also makes a self-evidently plausible improvement :)
<jml> spiv: heh
<jml> so, I'm not going to get around to turning it into a real patch.
<jml> but it seems related to the discussion you were having earlier.
<jml> speaking of bugs!
<poolie> speaking of launchpad deleting leading whitespace sucking
<jml> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/280595
<ubottu> Launchpad bug 280595 in launchpad-bazaar "RevisionNotPresent error when mirroring stacked branches" [Undecided,New]
<poolie> isn't that particularly ironic for a project written in python? :)
<jml> poolie: heh, I guess so :)
<poolie> so that patch does look plausible, and i think it is relevant too
<poolie> if unlock did not default to raising exceptions, it would tend to be safer when we need to unlock several things
<spiv> poolie: in fact, the leading whitespace is intact, it's the non-leading whitespace that it's collapsed.
<spiv> Thus screwing over exactly the most interesting parts of a diff.
<poolie> trailing the +
<poolie> that's true
<jonoxer> spiv: that explanation made a bunch of things click in my head. Looking good so far
<jonoxer> I now have a repo and a working copy that's branched from a branch in the repo    :-)
<poolie> bug 281051
<ubottu> Launchpad bug 281051 in malone "non-leading whitespace should be preserved" [Undecided,New] https://launchpad.net/bugs/281051
<jonoxer> spiv: I'm nearly there, problem now is I can't push commits from my local branch back to the repo, so I think I must have stuffed that up somehow
<jonoxer> I get the "This transport does not update the working tree of..." warning
<jonoxer> But I thought it was a repo, not a working tree?
<spiv> jonoxer: you can have a repo, a branch, and a working tree co-located in the one directory.
<spiv> (or a subset of those)
<jonoxer> Cool, so I'm pretty sure what I have at that end is just a repo, nothing else, hence the "update working tree" warning
<jam> poolie: bug #60730  is a bit more colorful about it
<jonoxer> So what is the procedure for getting my locally committed changes back to the repo?
<ubottu> Launchpad bug 60730 in malone "Malone breaks patches by messing with whitespace (dup-of: 2627)" [Undecided,New] https://launchpad.net/bugs/60730
<ubottu> Launchpad bug 2627 in launchpad-foundations "Bug comment and description whitespacing being munched yet again" [Medium,Confirmed] https://launchpad.net/bugs/2627
<poolie> hee hee
<jam> poolie: also, what about getting accounts on the win32 host
<jam> jonoxer: I would guess you have more :) but you can run "bzr remove-tree" on the remote end
<spiv> jonoxer: you get that warning if the branch you're pushing to does have a working tree, and you're pushing over the network.  If you don't want a working-tree there, run "bzr remove-tree" on the remote side.
<poolie> yeah i thought it must have been reported already
<poolie> jam, i'll send you a password soon
<jam> poolie: I reported one of my own a while back, which was already marked "dupe"
<poolie> i was trying to work out ssh
<jam> as you can see, 2627 means it has been around for a *long* time
<poolie> i won't go into details but for now you need to use rdesktop
<jam> poolie: well, I spend 50% of the time on Vista, which has "Remote Desktop" or whatever, so I think I'm okay there
<poolie> also 'apt-get install rdesktop'
<jonoxer> spiv: at the other end it shows a directory called "trunk" (which was what I specified as the destination when I grabbed the data from the svn repo) which is odd, because I thought bzr repos kept everything in the '.bzr' dir. But when I do "bzr remove-tree" I get "bzr: ERROR: No working tree to remove"
<poolie> jam, sent
<jam> jonoxer: "trunk" is a branch
<jam> branches also have locations on disk
<jam> not like svn
<jam> you need to do "bzr remove-tree trunk" or "cd trunk; bzr remove-tree"
<jonoxer> jam: groovy, that didn't complain (left the trunk dir there, which I assume is normal), now to test if I can push to the repo
<spiv> jonoxer: right, that's normal.
<spiv> jonoxer: it's probably better to think of it as "pushing to the branch" rather than to the repo.  Having a repo shared between multiple branches is essentially just an optimisation detail that doesn't affect behaviour.
<jonoxer> Woot! We have success, local changes pushed OK, then pulled down to a branch in another location. Thanks spiv and jam!
<spiv> jonoxer: you're welcome
<jonoxer> spiv: yes, I think a lot of my problem is getting myself out of the SVN mindset
<jonoxer> I read bzr tutorials and I *think* I get it, then realise I've totally misunderstood the intent behind it because I'm seeing things through SVN-colored glasses
<spiv> Yeah, it's surprisingly hard to avoid making those sorts of assumptions.
<jam> poolie: what is the username supposed to be?
<Mez> is there cruisecontrol functionality available for bzr?
<Mez> (or the other way round)
<mwhudson> there's PQM, which might be a little bit the same
<mwhudson> (i don't know much about cruisecontrol)
<jonoxer> Speaking of PQM, is there a good howto on it somewhere? My google-foo is weak and I can't find one so far, and https://launchpad.net/bzr-pqm doesn't have much on it
<AfC> jonoxer: that's question-of-the-day around here.
<jonoxer> Hey AfC! Good to see you
<AfC> jonoxer: heya mate :)
<AfC> jonoxer: ['fraid I can't help you. We don't use PQM]
<gnomefreak> im unable to break the lock i used "bzr break-lock" i also used "bzr break-lock lp-29094736:///~gnomefreak/iceowl/iceowl-0.x/.bzr/repository/lock"
<RAOF> jonoxer: I don't think your google-fu is particularly weak; I just think PQM's documentation is particularly weak :)
<gnomefreak> here is the output of the above commands http://pastebin.mozilla.org/551713
<jonoxer> RAOF: I've grabbed the package and looking through the code now to figure out what it does, but the package itself is remarkably documentation-free
<RAOF> gnomefreak: "bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x" should work
<RAOF> If it does, it's probably worth filing a bug that the URL that error suggests you use is stupid and wrong.
<Mez> lp-29094736 ???
<gnomefreak> RAOF: thanks that worked. im not6 getting why its given me a lp-####
<gnomefreak> will file bug as soon as i get done with everything that i started
<gnomefreak> file it under package bzr?
<RAOF> Yeah, that's probably the best place.
<RAOF> At least to start.
<gnomefreak> ok thanks
<mwhudson> gnomefreak: there is already a bug that the suggested url is stupid and wrong
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/250451
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [Undecided,Confirmed]
<gnomefreak> mwhudson: thanks i was reading that
<poolie> sminnee: if you're still around, apparently there is another branch that's better for using nested branches
<poolie> and that is
<poolie> https://code.edge.launchpad.net/~larstiq/bzr/nested-trees
<sminnee> thanks poolie
<sminnee> out of interest, how have you found launchpad?
<poolie> i just type in 'launchpad.net' and there it is :-) badabing
<sminnee> *groan*
<poolie> actually i think it's quite nice in many ways, though i've also got about 200 bugs i'd like fixed
<gnomefreak> is there a different way to push to branches outside of bzr push lp:~gnomefreak/iceowl/iceowl-0.x
<poolie> gnomefreak: which part do you want to do differently?
<gnomefreak> poolie: the whole command
<sminnee> poolie: this is a total noob question, but how do I download and install that version of bzr? :)
<gnomefreak> that command is hanging
<fullermd> Well, you could add an alias so you could "bzr gently-suggest" instead...
<poolie> gnomefreak: did it say it's waiting for a lock or anything?
<gnomefreak> no
<poolie> sminnee: there should be a 'bzr branch' command on that page; run it, and then follow the INSTALL instructions in the resulting directory
<gnomefreak> give me a minute
<gnomefreak> poolie: http://pastebin.mozilla.org/551726  that is all and its benn running close to 30 minutes
<poolie> gnomefreak: ah that would be why it's so slow
<mwhudson> iceowl == unbranded thunderbird?
<gnomefreak> mwhudson: sunbird
<poolie> try running 'bzr upgrade sftp://gnomefreak@bazaar.launchpad.net/%7Egnomefreak/iceowl/iceowl-0.x'
<mwhudson> oh ok
<mwhudson> that's not likely to be so big i guess
<poolie> or ask mwhudson to fix it on the server
<poolie> mwhudson, jml, we should seriously do something about this ^^
<mwhudson> poolie: do some kind of mass upgrade to packs?
<poolie> i think so
<mwhudson> my kneejerk reaction says "no"
<mwhudson> but i'm willing to be influenced
<jml> poolie: so, we'd very much like to allow users to ask us to do a server-side upgrade.
<gnomefreak> iceowl branch is big but never taken this long before. im waiting for lock to break
<mwhudson> what we really do want to do is have a button that says "upgrade this branch"
<poolie> right
<jml> poolie: we've got a plan for this, but it's pending some db discussions
<poolie> :/
<RAOF> I even filed a bug that proposed exactly that, so you can get your fill of bugfixing karma at the same time!
<gnomefreak> poolie: what does this command do outside of bzr upgrade (already had done this
<gnomefreak> )*
<poolie> which command?
<gnomefreak> bzr break-lock lp:~gnomefreak/iceowl/iceowl-0.x
<mwhudson> rocky: if i wanted karma, i'd actually _use_ blueprints
<poolie> it breaks the lock held by the previous process
<mwhudson> RAOF: ^^
<poolie> you should kill the process on your laptop if it's not already
<gnomefreak> i had screwed up my branch thats why i was trying to overwrite it
<RAOF> mwhudson: :P
<poolie> mwhudson/jml, is there any chance we could do these one-by-one on request?
<poolie> gnomefreak: then it's probably easier to just delete the branch,
<poolie> upgrade your local copy, and then push
<poolie> that'll actually be faster
<gnomefreak> ok try that
<poolie> switch machines, biab
<mwhudson> poolie: sure, i can run "bzr upgade lp:whatever" on devpad
<gnomefreak> there really is something wrong and im getting tired
<gnomefreak> even got trace back
<gnomefreak> poolie: traceback
<poolie> that's no good
<gnomefreak> im gonna run outside for smoke here is the output http://pastebin.mozilla.org/551729
<spiv> gnomefreak: you need to run "bzr launchpad-login gnomefreak" first
<poolie> spiv, would that really give a timeout?
<spiv> Oh, hmm.
<spiv> In that case, don't know :)
<poolie> it looks to me like a transient timeotu
<spiv> Hmm, that's probably the first network request that "bzr push lp:..." does.
<spiv> It *might* be an issue with connecting to the HTTPS port?
<spiv> Actually, why does the launchpad plugin need to connect to Launchpad to resolve "lp:~x/y/z"?
<gnomefreak> should i try after login?
<beuno> spiv, I think to check for permissions
<gnomefreak> starting off same way
<gnomefreak> ah it did work
<gnomefreak> well ill check when its done
<poolie> i'd just retry it and see if it gets the same thing, i think it's transient
<gnomefreak> im getting the progress bar
<spiv> beuno: hmm, surely the way to do that is to just try using it? :)
<beuno> spiv, I'm sure there's a reason somewhere. Also, it's a wild guess based off things I read on IRC, so take with a grain of salt
<beuno> and, it's 1am
<spiv> beuno: go to sleep :)
<beuno> you're a wise man
<beuno> good night spiv
<beuno> have a nice weekend!
<mwhudson> spiv: because the client makes very few assumptions about the structure of urls
<mwhudson> which is a good thing i guess *cough*source package branches* cough
<gnomefreak> is there a way to login automagickly?
<spiv> gnomefreak: you only need to run "bzr launchpad-login" once, then the userid is saved in your ~/.bazaar config.
<poolie> night beuno
<spiv> gnomefreak: or do you mean an SSH passphrase, or something like that?
<gnomefreak> spiv: oh ok thanks
<gnomefreak> spiv: no just the login command itself
<gnomefreak> bzr launchpad-login gnomefreak
<spiv> Ah right.  Yeah.  That only needs to be done once (and I believe current versions of bzr will warn you if don't have it set but need it set)
<gnomefreak> good night its getting late
<spiv> gnomefreak: good night
<gnomefreak> thanks for the help everyone
<abentley> lifeless: One way I could update my patch is to replace create_by_entry with something that uses the Tree API instead.  Would that work for you?
<lifeless> abentley: it likely would; I can't really say without seeing, but yes, looking at create_by_entry it just wants kind and file_id
<lifeless> abentley: that sounds like a good idea to me
<lifeless> abentley: I'm guessing my concerns made sense?
<abentley> lifeless: cool.
<abentley> lifeless: You raised some good points.  I don't want to add an Inventory to PreviewTree, and changing it this way actually does get us further away from inventories.
<abentley> In a meaningful way.
<lifeless> excellent
<jonoxer> Time for my next noob question. I now have a repo working, but I'm not sure of the best way to share it so multiple devs can pull/push to it. What's the current accepted wisdom? Using bzr+ssh requires them to have shell on the repo host, AFAIK, so maybe using the built-in smart server? We've been using webdav with SVN up until now
<spiv> jonoxer: bzr+ssh is the usual approach
<spiv> jonoxer: it's possible to use one system account with multiple SSH keys associated with it, I think
<jonoxer> spiv: the host has LDAP and all devs have shell at the moment, but I'm guessing I'll have privilege problems on the repo itself
<spiv> jonoxer: you can restrict SSH to only allow the user(s) to run bzr, i.e. disallow shells.
<spiv> Make the repo group-owned (sticky) and group-writeable.
<jonoxer> I just did a test as a different user and even with group write privs I got an access denied error. Playing with it now
<jonoxer> Aha, I think I've found the problem, it was LDAP auto user creation not behaving how I expected so the user didn't have the privileges I thought it did-
<jonoxer> I'm getting a traceback from bzr when trying to push as a different user. I've checked that the user I'm doing it as has write privs (I can SSH in, touch a file and remove it from inside the repo, and it works) but bzr dies each time
<jonoxer> After the failure I do break-locks which reports that a lock has been created (and breaks it successfully) but pushing still fails with a traceback
<spiv> jonoxer: pastebin the traceback?
<jonoxer> spiv: yep, in a moment, just trying one or two more things now
<jonoxer> I can still push as the original user (after breaking locks of the second user)
<jonoxer> spiv: http://pastebin.com/d4a3e305e
<spiv> Argh, ok, one of those.
<spiv> I think that happens to be the one I'm about to land a fix for for 1.8
<spiv> Yep, almost certainly it is.
<jonoxer> Aha, so I'm probably not doing anything specifically wrong? Any workarounds, or maybe I should try using the bzr server instead of bzr+ssh?
<spiv> jonoxer: an error is occuring somewhere, but that triggers a secondary error which obscures the original error and triggers the traceback
<spiv> jonoxer: the patch on https://bugs.edge.launchpad.net/bzr/+bug/230902 will fix the secondary error, and let the real error show.
<ubottu> Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]
<jonoxer> OK, so I probably still have something wrong but we can't tell what from the trace
<spiv> The "ValueError: I/O operation on closed file" is an interesting clue, though.
<spiv> Is there a ~/.bzr.log on the server-side?  Does it have a traceback?
<jonoxer> I'll see
<spiv> I'm wonderinf if that short traceback at the top of your paste might have happened on the server side.
<jonoxer> Yes, there are logs for both the first and second users
<jonoxer> Trying again while tailing the log...
<jonoxer> Got the entry while doing a failed push. Doesn't say much though
<jonoxer> Just this: http://pastebin.com/d4e6272d8
<spiv> Double-check the permissions inside the remote .bzr directory and subdirectories?
<vila>  hi all
<spiv> Googling suggests that others have seen this error when the permissions are somehow wrong inside the .bzr/repository/ directory on the server.
<spiv> Another thing to debug this would be adding "-Dhpss" to the command line of the client, and the looking at the ~/.bzr.log to see where exactly in the network conversation it fails.
<jonoxer> I've gone through the permissions fairly carefully, I think they're correct (not ruling it out though). I'll try -Dhpss now
<spiv> I'd expect that if the permissions were wrong, it'd be fairly obvious (e.g. a file inside .bzr/repository/... owned and only readable by one user)
<spiv> You're welcome to pastebin the ~/.bzr.log with the -Dhpss info in it.
<jonoxer> The log looks normal until it gets to repo/.bzr/repository/pack-names, then does the traceback, checking now
<jonoxer> I don't get it, the permissions on that file are fine for that user. I'll paste the log
<jonoxer> spiv: http://pastebin.com/d249d52ee
<spiv> jonoxer: hmm
<spiv> jonoxer: the weird thing is that that log doesn't show that the client got a reply to its 'put' of the pack-names file.  Which suggests that the *server* is breaking the connection, rather than merely returning an error.  In which case I'd expect something to appear in the ~/.bzr.log on the server-side :/
<spiv> jonoxer: try over sftp:// instead of bzr+ssh:// ?
 * spiv hopes jonoxer's IRC client reconnects...
<spiv> Ah, welcome back.
<jonoxer> oops, back, sorry spiv
<spiv> jonoxer: the weird thing is that that log doesn't show that the client got a reply to its 'put' of the pack-names file.  Which suggests that the *server* is breaking the connection, rather than merely returning an error.  In which case I'd expect something to appear in the ~/.bzr.log on the server-side :/
<spiv> jonoxer: try over sftp:// instead of bzr+ssh:// ?
<jonoxer> spiv: tried sftp and got a more helpful error, it says "Generic path error: 'cjhuxwva3sro9dvdasy9.fetch': Failure: unable to rename to '../packs/f6cafb9b2fdb7d84f652ef20be2694e1.pack'"
<jonoxer> which looks like permissions, as you say
<spiv> It does indeed!
<jonoxer> I'm probably only a step or two away from having this working but unfortunately I've gotta run. I'll have to pick it up again later, thanks for all your help Spiv, I appreciate it
<spiv> Unless you have a wacky filesystem that doesn't support POSIX semantics for renaming files ?
<spiv> jonoxer: Ok.  Have a good weekend.  I'll be around on Monday if inspiration doesn't strike :)
<jonoxer> Ext3, so should be OK
<spiv> Yeah, ext3 should be more than ok :)
<jonoxer> I still have a feeling it's related to the way LDAP is dishing out the group to that user on login, so I'll try working through the auth logs etc as well and see if anything weird is going on. I'll also try creating a local user manually (avoid LDAP altogether) and see if that helps
<jonoxer> Bye!
<chmac> I ran something like `cd ~/bonkers/; bzr init; bzr add blah/; bzr ci -m "1"`
<chmac> Now I've realised all my code is within blah/ and I'd like to do something like this
<chmac> mv ~/bonkers/blah ~/blah
<chmac> However, that will break the bzr repo as the ~/bonkers/.bzr/ directory will no longer be in the right place
<chmac> Is there an alternative?
<chmac> In svn each directory is self contained, so I can just ignore the parent dir, but not in bzr
<chmac> Ok, this kinda worked `cd ~/bonkers; bzr mv blah/* ./; bzr ci -m "Move"; bzr rm blah/; bzr ci -m "Tidy"`
<bob2> kinda?
 * spiv heads off
<EarthLion> hey can you put a limit on bzr log so you just see the last x amount
<james_w> EarthLion: either --limit
<james_w> or "-r -100.." or similar
<EarthLion> thanks a lot
<EarthLion> also is i want to do a bzr diff -r 100 but i just want to see a list of files that have changed (like when you do bzr status) instead of a readout of the changes
<EarthLion> is that possible?
<james_w> EarthLion: -v
<james_w> EarthLion: you might want to look at "bzr help log" to see what else is available
<EarthLion> ok thanks
<EarthLion> makes those two commands make things a lot easiar :)
<lakshmanan> hey.. i am using launchpad and i am using "staging"  section of launchpad(staging.launchpad.net) to learn about launchpad.... i am not able to push my branch to my project's trunk branch.. please help
<beuno> lakshmanan, what seems to be the problem?
<lakshmanan> beuno, hey.. thanks for the response... i used this command   bzr push lp://staging/schoolmanagement to push my changes to my sample project's trunk branch... but it says this error ..bzr: ERROR: Transport operation not possible: http does not support mkdir()   now what should i do
<beuno> lakshmanan, you need to specify your Launchpad username first with:   bzr launchpad-login <username>
<lakshmanan> but that was the url given in that branch's launchpad page
<beuno> lakshmanan, the url is correct
<lakshmanan> beuno, can you gimme the full command i must give to push my changes
<beuno> you just need to be logged in to push to launchpad
<lakshmanan> i am logged in
<beuno> bzr launchpad-login your_launchpad_username
<beuno> lakshmanan, ^
<beuno> you just need to do that once
<lakshmanan> beuno, oh you mean i must login to launchpad via terminal... am i right?
<beuno> lakshmanan, yes. bzr needs to know your launchpad username
<lakshmanan> beuno, thanks,it works but it says... ERROR: Target directory lp://staging/schoolmanagement already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway     ... but it worked. thanks...i dont understand how this thing(.bzr directory does not exists) works.... can u explain
<beuno> lakshmanan, ah, right, that's a one-time error as well, because of you trying to push before
<beuno> just add the --use-existing-dir flag once to the push command
<beuno> and from now on, everything will go smoothly
<lakshmanan> i did... it worked.. thanks
<beuno> :)
<strk> a 'branch ' is been running for over 2 hours, I don't see much processor, memory or network activity. bzr log doesn't give any sign either
<strk> last time I killed the process the repository (on-line, shared) got corrupted.
<strk> what do I do ? :>
<beuno> strk, you're pushing or branching?
<strk> branching
<beuno> is the branch big?
<beuno> 2 houts sounds too much
<beuno> *hours
<strk> yes, it's big
<strk> last two lines from .bzr.log are:
<strk> 2965.718  http readv of e74eb7f199645e105baf57aca1ee3638.pack  offsets => 119 collapsed 6
<strk> 3013.203  http readv of 2c779c251220f8afce08bcec69277e32.pack  offsets => 34285 collapsed 308
<strk> that's how much  50 minutes ?
<jdo> anyway to undo a bzr clean-tree?
<jdo> :-)
<strk> I killed it, starting from scratch using sftp (it was http)
<strk> now, I'll try to branch from a collegue machine on this lan, any help is appreciated with this experiment
<Odd_Bloke> jdo: I'm not aware of one, I'm afraid.
<jelmer> hmm, apparently there exists a funny VSS -> Subversion gateway
<jelmer> and it does all kinds of funny things
<jelmer> Microsoft's CodePlex site is running it
<flacoste> what should I make of:
<flacoste> bzr: ERROR: KnitPackRepository('file:///home/francis/canonical/windmill/.bzr/repository/')
<flacoste> is not compatible with
<flacoste> RemoteRepository(bzr+ssh://flacoste@bazaar.launchpad.net/%7Elaunchpad-pqm/windmill/trunk/.bzr/)
<flacoste> different rich-root support
<flacoste> ok, i think this is because i'm trying to branch a bzr svn branch into --1.6 format repository
<flacoste> or just into a repository?
<LarstiQ> flacoste: right, bzr-svn uses a rich root format, which is not the default
<flacoste> can I make a shared repository that can be used by bzr-svn branches?
<flacoste> init-repo --subversion i guess
<flacoste> oh
<flacoste> --1.6.1-rich-root
<flacoste> that might also work
<t3tech> Is there user documentation for the Eclipse plugin somewhere that I'm not finding?
<beuno> t3tech, all I know of is: http://bazaar-vcs.org/BzrEclipse
<beuno> but Verterok|out is the one to ask, unfortunetely he's off on vacation
<t3tech> beuno: yeah that's I've been able to find.
<beuno> t3tech, I suspect there's not help or tutorial for it
<beuno> s/not/no
<t3tech> I'm trying to figure out if there is some way to use it with an existing eclipse project that I'm just starting to use bzr on or if I need to create a new eclipse project .... etc.
<beuno> maybe awilkins knows?
<t3tech> well I just found this - https://answers.launchpad.net/bzr-eclipse/+question/25148 which basically says use richt click --> Team --> Share Project but that option is greyed out for me. Hmm
<t3tech> Think I've figured it out... was right clicking in the wrong place. doh!
<AmanicA> :)
<nevans> just had a race condition error with bzr-svn: while I was in the middle of pushing three revisions, another developer committed a revision of their own.  now "bzr pull" won't pull their revision down.  :(
<jelmer> nevans, hi
<jelmer> nevans, can you perhaps pastebin the "svn log -v" output of the svn repository somewhere?
<nevans> jelmer: yeah
<nevans> I made a bugreport on lp, too
<nevans> https://bugs.launchpad.net/bzr-svn/+bug/281460
<ubottu> Launchpad bug 281460 in bzr-svn "race condition when pushing to svn repo" [Undecided,New]
<nevans> jelmer, do you want me to get svn log -v for the entire repo, or just that branch?  also... how far back do you want the revision history?
<nevans> it's got ~15549 revisions in just that branch.  :)
<jelmer> nevans, the entire repo - just the first 100 or so should do
<nevans> I tried to run "bzr log -vr 15544" (the missing revision) from within the svn working copy... now bzr is busy "generating file id map  1455/15543"
<jelmer> nevans, I mean svn log rather than bzr log
<nevans> yeah... I'm getting that now.
<nevans> just thought I'd let you know. :)
<jelmer> yes, it's correct it'd be determining the file id map first in the case of bzr log
<nevans> jelmer, I'm going home soon (at work now).  Let me know if there's anything else that would be helpful (did you get my private msg with the pastebin URL?)
<nevans> thanks!
<jelmer> nevans, yep, thanks
<nevans> jelmer, just let me know via the lp ticket if you need anything else to debug.
<beuno> jelmer, hi!
<beuno> I see you managed to get LH on Debian's NEW queue again  :)
<beuno> any plans to get it into Ubuntu, or are you going to let it trickle down in Jaunty?
<jelmer> beuno, I'm going to let it pass for Intrepid
<beuno> jelmer, so maybe we can upload it to bzr's PPA?
<beuno> :)
<jelmer> beuno, Sure, I'll leave the actual uploading to other folk though, I don't want to commit to keeping it up to date
<beuno> jelmer, fair enough, I'll be "people"
<beuno> thanks for all the work on the package !
<jelmer> beuno, you're welcome
<beuno> I'm off home now
<jelmer> Thanks for loggerhead (-:
<beuno> :)
#bzr 2008-10-11
<chandlerc[g]> jelmer: ping
<jelmer> chandlerc, pong
<chandlerc[g]> jelmer: i'm working on the segfault
<chandlerc[g]> jelmer: but not sure what a good next step is if it doesn't reproduce for anyone else
<chandlerc[g]> i'm happy to do any amount of debugging on my end to fix this as its a complete blocker for me at the moment
<jelmer> chandlerc[g], I would recommend trying to get the testcase as small as possible, that will help debugging
<chandlerc[g]> the test case i posted is the smallest one i can come up with
<chandlerc[g]> but it only fails for me
<chandlerc[g]> i think its something specific on the two systems i have thats causing it, but i'm not sure how to track that down
<jelmer> have you tried running inside valgrind?
<chandlerc[g]> how can i do that? run python via valgrind?
<chandlerc[g]> (ie, will that put the c code in question under valgrind)
<jelmer> yeah, run Python inside of valgrind, indeed
<chandlerc[g]> yea, it has to, or gdb wouldn't have worked
<jelmer> or something like "make valgrind-check" inside of the bzr-svn directory
<chandlerc[g]> yikes
<chandlerc[g]>  ERROR SUMMARY: 2084 errors from 139 contexts (suppressed: 172 from 1)
<chandlerc[g]> i don't know how useful thats going to be
<jelmer> chandlerc[g], did you run with the python suppressions?
<chandlerc[g]> what are those?
<chandlerc[g]> or how do i find them
<jelmer> see the Makefile
<chandlerc[g]> jelmer: i'll be continuing my investigations later this evening. In case you're not around, anything in particular I should be looking for?
<chandlerc[g]> my other steps are to compile editor.c with full debugging symbols
<chandlerc[g]> and hopefully the svn libs as well
<chandlerc[g]> let me know if there is anything that would be specifically enlightening here.
<chandlerc[g]> i suspect this is going to be a bug in the svn bindings though. =/ un-fun...
<jelmer> it could very well be
<jelmer> I wonder what's causing the path to be NULL though..
<ferringb> hmm.  if I were trying to pull the revids for a specific path, what's the best way- get_ancestry was my first thought, but that seems to just give me all revids for that repo
<ferringb> scratch that.  bzrlib.log.find_touching_revisions suffices
<kingfishr> When I try to branch a project over ftp, I get "bzr: ERROR: Unable to connect to HOSTNAME; (111, 'Connection refused')"
<kingfishr> that's not particularly useful...
<bob2> do other ftp clients work?
<kingfishr> yes
<kingfishr> with passive, too
<bob2> anything more useful in ~/.bzr.log?
<kingfishr> checking
<kingfishr> Not particularly
<kingfishr> It's throwing a SocketConnectionError
<kingfishr> bob2, would it help if I were to pastebin the logfile?
<kingfishr> Ah! got it
<kingfishr> I need to use a different port
<kingfishr> whoops
<bob2> hehe
<ferringb> actually... why would bzrlib.log.find_touching_revisions continue on past a delete?  seems like it would be inspecting revs for no reason post delete
<chandlerc> jelmer: if you happen to be around, i'm digging in again on this
<stefanlsd> I've deleted two tags locally, but want to delete them on the repo in lp now. although i cant seem to push them up. any ideas?
<glatzor> hello, when performing an action on my repository I only get the following error message:
<glatzor> bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable"
<glatzor> /usr/lib/python2.5/site-packages/bzrlib/lock.py:79: UserWarning: lock on <open file u'/home/renate/Entwicklung/gnome-packagekit/ubuntu/.bzr/checkout/dirstate', mode 'rb' at 0xa0a7728> not released
<glatzor>   warn("lock on %r not released" % self.f)
<glatzor> bzr break-lock is of no help
<Leefmc> Question: Anyone familiar with the workflow of having multiple branchs and a working branch, along with needing to download updates from the main launchpad branch?
<Leefmc> I'm having trouble figuring a good workflow, without destroying my working branch.
<LarstiQ> Leefmc: what do you mean with destroying your working branch?
<Leefmc> LarstiQ: Sorry, read what i said in #launchpad and we'll take it here :)
<LarstiQ> Leefmc: I did, but it wasn't really clear to me.
<LarstiQ> Leefmc: what do you do that destroys your working branch?
<Leefmc> LarstiQ: Well on the destroying my working branch, if i have a working branch /wrk of /trunk, and i am in /wrk and use bzr update, it adds to my /wrk branch. This seems fine, until you notice that now /wrk and /trunk are not the same. /wrk has the updates from lp:* but /trunk does not. You cannot commit the changes to /trunk either, because according to /wrk, no changes have been made
<LarstiQ> Leefmc: is /wrk a branch, or a working tree?
<LarstiQ> Leefmc: I suspect it's just a working tree from how you described your workflow
<LarstiQ> but if not, I'd like to get that confusion out of the way first
<Leefmc> LarstiQ: bzr/git have hazed my definitions of this, pardon if i am using them wrong. /wrk is a lightcheckout, thats all :)
<Leefmc> lightcheckout of /trunk
<LarstiQ> right, a lightweight checkout is just a working tree, good
<LarstiQ> Leefmc: so /wrk is bound to /trunk, and then you `bzr update` in /wrk.
<Leefmc> I am doing it this way so i can imitate my old git workflow of being able to create test branches of the fly (/trunk, /test, /brokencode, etc) and swap between them without having to move my IDE, etc.
<LarstiQ> right
<Leefmc> LarstiQ: Correct, because i am trying to avoid the workflow of jumping around, even in terminal.
<LarstiQ> Leefmc: that is a common workflow for that situation
 * LarstiQ nods
<LarstiQ> Leefmc: I'm a bit confused though. Afaics `bzr update` in /wrk should also have updated /trunk.
<LarstiQ> Leefmc: could you show me the output of `bzr info -v` from /wrk ?
<Leefmc> Well for example, when i did, there were 2 new files downloaded from launchpad, but those two were not in /trunk.
<LarstiQ> aaah
<LarstiQ> I think I may get it now
<LarstiQ> Leefmc: /trunk is not a tree-less branch?
<Leefmc> I sort of destroyed all that already, im back to my "pre update" stage of my repo, since i simply copied it before i toyed
<Leefmc> LarstiQ: Not sure, what do you mean?
<LarstiQ> Leefmc: there are three main domain concepts in Bazaar. Branch, (Working)Tree, Repository
<LarstiQ> Leefmc: the repository just stores revisions. A branch is a pointer to a revision in the revision DAG determing a line of development, and a working tree is the actual tree of files so you can edit and commit (plus some metadata)
<LarstiQ> Leefmc: they can be in different areas, or in the same directory
<LarstiQ> Leefmc: now, if my hypothesis is correct, /trunk is both a branch and a working tree
<Leefmc> ah
<LarstiQ> Leefmc: the update in /wrk will have updated the branch part of /trunk, but not the working tree part
<LarstiQ> Leefmc: you can confirm this by checking for existance of /trunk/.bzr/{checkout,branch}
<LarstiQ> Leefmc: the former being the data for a working tree, and the latter for a branch
<LarstiQ> of course, my hunch could be wrong
<LarstiQ> Leefmc: but please check this :)
<Leefmc> LarstiQ: Assuming i understand you correctly, yes there are /trunk/.bzr/checkout & branch directories
<LarstiQ> Leefmc: if I'm correct, a `bzr update` in /trunk will bring its working tree up to date with its branch. But in your workflow it does not make much sense to have more than one working tree.
<LarstiQ> Leefmc: right
<Leefmc> LarstiQ: So first off, for future reference, because i suspect the problem is the same for all my machines then, what did i do wrong when creating my setup of /repo, /repo/trunk, and /repo/wrk ?
<Leefmc> LarstiQ: And secondly, what can i do to fix it?
<LarstiQ> Leefmc: So, the recommended setup in your case is to have a repository that defaults the branches in it to be tree-less, and then have your branches in there. You can create one with `bzr init-repo --no-trees /project/`
<LarstiQ> or repo
<LarstiQ> s/project/repo/ in that case
<LarstiQ> Leefmc: any branch you will create in that will not have a working tree by default
<LarstiQ> Leefmc: to remove trees from branches that have one, you can `bzr remove-tree`
<Leefmc> gotcha
<Leefmc> LarstiQ: And that will also fix my problem correct?
<LarstiQ> Leefmc: your branches will no longer have working trees, so you shouldn't get confused anymore
<LarstiQ> Leefmc: is /trunk in a shared repository? bzr info will tell
<Leefmc> LarstiQ: Would i be able to simple dump everything, create a new repo (bzr init-repo --no-trees /repo) and create a new trunk (bzr init /trunk) and a new working dir (bzr checkout --lightweight /trunk /wrk) ?
<LarstiQ> Leefmc: you could, but then you'd lose work?
<Leefmc> LarstiQ: Yes, it says that /repo is the shared directory. (trunk is in /repo/trunk)
<LarstiQ> Leefmc: ah cool
<LarstiQ> Leefmc: you can also change your existing repo to be tree-less from henceforth
<Leefmc> LarstiQ: My work is on my other machine, and soon i am going to push it to launchpad to replace the fowlups i've made when trying to figure this out. (I updated /wrk and then made a change and commited to see if it would commit to /trunk, but instead it uploaded to launchpad)
<LarstiQ> Leefmc: ok, that sounds as if /wrk is not actually bound to /trunk?
<LarstiQ> Leefmc: just to be clear, when we're talking about /trunk we mean /repo/trunk, and not something else outside of /repo?
<Leefmc> LarstiQ: It was a lightcheckout, but beyond that i do not know. I may have changed something aswell in my misguided search for information and understanding
<Leefmc> LarstiQ: Yes, /repo/trunk, pardon my lazy typing :)
<Leefmc> LarstiQ: All mentions of /wrk and /trunk have really been /repo/trunk and /repo/wrk
<LarstiQ> good, good
<LarstiQ> Leefmc: I'm fine with lazy typing, just want to make sure I'm not assuming a situation which isn't true :)
<Leefmc> LarstiQ: So am i correct in the understanding that bazaar "needs" a working tree? (or working branch.. im still confused on the difference of branch/tree, but i can get that from a re-read of the bzr intro)
<LarstiQ> Leefmc: `bzr info` is the goto command to find out where /wrk is bound to :)
<Leefmc> LarstiQ: It says that the lightcheckout root is ".", the repo checkout root is /repo/trunk, and that it is a checkout of branch lp:myproj
<LarstiQ> Leefmc: you need a working tree to edit files/commit etc. But not for publising changes and such. launchpad hosts branches, there are no working trees there.
<Leefmc> gotcha
<LarstiQ> Leefmc: a lightweight checkout provides a working tree that says "my branch is over <there>, go bother it for more information"
<Leefmc> yea
<LarstiQ> Leefmc: so for you, I'd keep to having just that one for a working tree, no others.
<woeye> greetings all. following the discussion a bit. what is the difference between a lightweight checkout and a symbolic link then?
<woeye> (i am currently reading a bit about bazaar and whether it would makes things easier for me - coming from git *g*)
<LarstiQ> woeye: the branch you're linking to might not have a working tree. Or it might exist somewhere else on the network.
<woeye> ok, I see. especially the network thing is an important one. forgot that ;)
<LarstiQ> woeye: but especially the first one is important imo
<Leefmc> LarstiQ: Im still a bit confused on how it let two working trees (/wrk and /trunk) play off eachother. Understanding of that will come with experience i assume :)
<LarstiQ> woeye: if you'd use a symlink, bzr switch would then point the symlink somewhere else, so far so good. But every branch you point to would need to have a working tree, or get one created at switch time.
<woeye> yeah, I see
<LarstiQ> woeye: you can imagine the pain if you have a couple of trees of, say, mysql laying around and need to recompile from scratch every time
<woeye> do you know django? I think that lightweight checkouts would make the handling of "shared app" folders way easier
<LarstiQ> woeye: Heard of, but not actually familiar with.
<woeye> django allows to share python packages between projects (web applications)
<woeye> typically you have a folder where all shared code goes in
<LarstiQ> woeye: django specific site-packages vs zc.buildout for each webapp?
<woeye> sort of. the thing is, sometimes you need different versions of the shared code. or you would have to keep every depending web app up-to-date
 * LarstiQ nods
<woeye> (which is currently my problem ;) )
<Leefmc> LarstiQ: Anyway, imma hop on my othermachine and overwrite my bad pushes. Thanks again LarstiQ, you've been a huge help!
<LarstiQ> woeye: the concept has been drilled into me the last couple of PUN meetings ;)
<LarstiQ> Leefmc: pleased to be of help! If you have any more questions, you know where to find me :)
<woeye> so, what i need is a web app container folder which contains the code for the app itself and a lightweight checkout of a shared code branch
<woeye> of course I could also have different branches floating around. but things get very confusing quickly
<woeye> what I like about bazaars approach is to have a central repo where all projects reside. easier to maintain imho.
 * LarstiQ heads out for dinner
<LarstiQ> woeye: do you have a link describing this?
<woeye> hm, let me see ...
<woeye> this wiki page describes it a bit: http://code.djangoproject.com/wiki/BestPracticesToWorkWith3rdPartyAppsAndMakingYoursPortable
<woeye> now, the main feature for me is that I can have a central repo where all projects (and all releases) reside and build some kind of virtual structures with lightweight checkouts.
<woeye> having lots of git branches floating around on my disk is not so cool
<Leefmc> LarstiQ: So if you do not have a working tree, you cannot even _see_ the contents of a branch? (ie, /trunk/somefile.py will not be shown?)
<clemente> âbzr shelveâ is asking me âShelve this change?â but it shows me actually two changes which are very close. The blocks are: added chunk, common line, removed line, added chunk. That common line sets them apart
<clemente> It would be good if it had something like a âbâ option to break that change appart in smaller chunks
<woeye> bzr status doesn't show files recursively? there's only bzr add --dry-run for this?
<fullermd> What do you mean, doesn't show recursively?
<woeye> subdirectories of subdirectories
<fullermd> It shows the whole tree, unless you limit it.  And even then, it descends into the whole subtree you specify.  I don't think it even HAS a --no-recurse...
<woeye> when I did a bzr init followed by a bzr status I could only see the status of the current top level directory
<fullermd> Oh.  It won't descend into unversioned directories, no.  They're none of bzr's business until you tell it to care about them.
<woeye> ok
<vadi2> Hi, I have a question - how can I move bzr into one folder below? I accidentally made the branch above the root folder of the project.
<AmanicA> vadi2: did you do much in it yet?
<AmanicA> vadi2: you can either just delete the .bzr and init the real root (and loose all history)
<AmanicA> vadi2: or, (make backup first!) say your structure is /myproject/subfolder/.bzr  then do cd /myproject/subfolder; bzr mkdir subfolder; bzr mv files subfolder
<AmanicA> vadi2: mv ../root_files . ; cd ../.. ; mv myproject myproject.old mv myproject.old/subfolder myproject
<kimus> hi, need help configuring a hook on a repository. where's the plugins directory on the repository?
<vadi2> AmanicA: no it's above, so it's /.bzr/myproject
<vadi2> AmanicA: other non-project files are currently set as "unknown"
<AmanicA> vadi2: so say its projects/myproject with projects/.bzr
<kimus> can anyone can help me on how to create a hook on bzr on the repository?
<vadi2> AmanicA: it's actually .bzr in projects and projects/myproject
<AmanicA> vadi2: try again: so say its /opt/projects/myproject with /opt/projects/.bzr
<kimus> does bzr support hooks on the repository?
<vadi2> yes
<kimus> vadi2: yes? how?
<fullermd> I don't think it does, actually.  Only hooks on the branch.
<vadi2> sorry, that was to AmanicA. I'm not familiar with bzr coding
<kimus> i want to do something on the server on evry commit
<kimus> it's this possible?
<vadi2> every commit, yes
<vadi2> there is a publish bot that does something on every commit
<kimus> vadi2: goo, how?
<vadi2> though it's local to the user
<vadi2> not server
<vadi2> i don't know, you can look at it's code though
<vadi2> sec...
<fullermd> I don't know if the smart server supports running hooks yet or not.
<kimus> what? local to the user??
<vadi2> yes.
<kimus> so back to svn then...
<vadi2> like I said
<vadi2> I've seen this one plugin do it
<vadi2> I don't know if bzr supports hooks or no.
<vadi2> if you're interested, read the api or something
<AmanicA> vadi2: cd /opt ; mv projects myproject; mkdir projects; mv projects.old/otherprojects projects; cd myproject; bzr mv myproject/files . ; rm myproject
<kimus> the only hooks I saw was for the plugins dir... and I bet it's only for user not the server :-S
<AmanicA> kimus: yes you can run hooks on the server, what protocol are you intending to use?
<vadi2> I cannot guarantee anything. But you do know about loggerhead?
<kimus> AmanicA: anyone that does the job. i'm testing with ssh now
<AmanicA> kimus and fullermd, you'll need 1.8 or dev version to get it to work (the patch I made was only merged recently)
<kimus> dev version??... ouch
<AmanicA> kimus: to get the hooks to be kciked off you'll need a smart server i.e. bzr+ssh or bzr+http etc.
<AmanicA> kimus, I run it in production, cos I have to be current
<kimus> I'm testing on bzr+ssh protocol now
<AmanicA> you can try the 1.8rc
<kimus> AmanicA: I can try... but what's the confs?
<AmanicA> (my patch was for bzr+http)
<kimus> I have to configure something right?
<kimus> AmanicA: only works on bzr+http ?
<AmanicA> dont think so, I havn't used bzr+ssh much, but I think the hooks should work
<kimus> AmanicA: let's say it works. what I need to configure for the hooks work? where to put the .py scrits?
<AmanicA> hooks are plugins
<AmanicA> and plugins go in site-package/bzrlib/plugins or ~/.bazaar/plugins
<vadi2> AmanicA: instead of "bzr mv myproject/files .", can I use "bzr mv myproject/* ."
<AmanicA> there is a plucing which lets you configure it to run scripts
<kimus> so the plugins are system wide and not only for a repository  ?!?!?
<vadi2> there are a lot of files there to move manually
<AmanicA> vadi2 no
<AmanicA> vadi2: cos youre moving it out of the branch
<AmanicA> kimus: yes
<kimus> AmanicA: wtf! that it's a bit stupid :-S
<AmanicA> but kimus you might be able to cnfigure the shell_hooks plugins to run different scripts depending on the location
<AmanicA> kimus youre just used to svn
<kimus> AmanicA: cvs works fine also :-p
<AmanicA> kimus: does svn have a way to install hooks globally?
<kimus> with cvs I can co and commit the hooks :-)
<vadi2> AmanicA: thanks for your help
<AmanicA> kimus: interesting
<AmanicA> vadi2: did it work?
<sky-g> kimus: I was just looking at the package etckeeper (tip from a guy in #git).  It uses hooks and supports bzr and has some bzr sample code to install a hook plugin (I think)  Whether this is for local or what you refer to as "server" I couldn't say
<vadi2> AmanicA: no, error, but it's ok to just start with a clean history as the past isn't too important at this point
<AmanicA> cool
<kimus> AmanicA: ever repository has different types of needs regarding hooks (building, mirroring, etc) because they can be diferent languages and tipes
<kimus> *types
<kimus> so, a global hook is not has good has repo only hooks
<fullermd> The hook code is global.  That doesn't mean every branch has to invoke it.
<kimus> fullermd: only know one way... some IF's on the hook :-p
<sky-g> kimus: you're right.  but a hook is a hook... it's open, so you should be able to write your script to do stuff only when it's appropriate (e.g. for a certain repos) right?
<sky-g> what's wrong with ifs? :-)
<kimus> sky-g: sure... but not ideal. it should have a configuration on the repo to add hooks
<fullermd> They get lonely without ands and buts   :p
<kimus> did you saw: http://bazaar-vcs.org/BzrHooks ?
<fullermd> There's no configuration on the repo.  There's only configuration on the branch.
<kimus> fullermd: whatever. a conf in branch it's ok for me
<fullermd> Your hook would just need to have an _enable switch that the branch sets.
<kimus> fullermd: didn't understood what you said
<fullermd> There's also the shell-hooks, but I don't know how well that works.
<sky-g> etckeeper example, if it helps: http://pastie.org/290221
<fullermd> Well, your plugin has access to all the same config as the rest of bzr.  So it could just check if "frobnicate_enable" is set.
<kimus> sky-g: I'll check that... but for me is a workaround it should be possible to configure hooks (by the client) on the repo/branch
<kimus> sky-g: i can do what a .py don't need the etckeeper. i can do my IFs :-D
<chandlerc[g]> jelmer: jsyk, i've now re-produced this madness on a freshly built, debugging enabled python. talking to python guys to try and figure out how the invariant for that function is violated
<jelmer> chandlerc[g], hi
<jelmer> chandlerc[g], reproduced it without bzr(-svn) ?
<chandlerc[g]> no, but *any* call to that method returning a null pointer is broken
<chandlerc[g]> and if you know of anything i can do inside of gdb, at the point it does this, with a full debugging python interpreter, its sitting here
<chandlerc[g]> i don't know enough about python to know how to manipulate the self object and dig out the context for this call
<chandlerc[g]> jelmer: bzr-svn rocks. =] using it on the non-messed-up system, and its shoving revisions into subversion perfectly
<chandlerc[g]> despite it being branched around 3 ways to get it from the broken machine to the working one, and developed on and off for a month across both machines
<jelmer> chandlerc[g], sorry, my knowledge of Python internals is a bit limited as well in that regard
<jelmer> chandlerc[g], glad you appreciate bzr-svn, pity you're hitting this issue though :-(
<chandlerc[g]> jelmer: i'm about 99.9% confident its a python issue
<chandlerc[g]> rather, a python + svn issue
<chandlerc[g]> i'm not going to loose sleep over it when it works on Ubuntu, and doesn't on Gentoo. i'll wait for updates to the whole damn thing
#bzr 2008-10-12
<jelmer> chandlerc, do you use any fancy compiler flags on Gentoo?
<ferringb> I'm getting a revision_id from a file w/in a branch that isn't in said branches revision_history()... I'm assuming this is a submerge of some sort, but how should I go about tracing it back to a rev in the branches revision_history?
<chandlerc[g]> jelmer: not really
<chandlerc[g]> jelmer: -O3 -fomit-frame-pointer.. i really only aim for inlining and reducing register pressure
<chandlerc[g]> jelmer: and bzr-svn is compiled with nothing, and lots of debugging, i don't install it via gentoo tools
<jelmer> chandlerc[g], what about the compile flags for python itself?
<chandlerc[g]> i reproduced it with a hand built, debugging enabled python
<chandlerc[g]> was still using the system installed subversion libs and bindings tho
<teratorn> I repository A, which has been in use for a long time. Now recently I've created repository B to hold some related work, and I've committed many revisions to it. I would like to import repo B in to a sub-directory of repo A, including all revision history.. is this possible?
<teratorn> *I have
<bob2> sure
<teratorn> bob2: OK, how? :)
<bob2> cd A/somewhere ; for branch in `bzr branches ~/B` ; bzr branch ~/B/$branch $branch ; done
<bob2> but that breaks for  branches in nested dirs - I think you'd need to use push --create-prefix
<bob2> cd ~/b ; for branch in $(bzr branches) ; do (cd $branch ; echo bzr --create-prefix push ~/a/somewhere/$branch) ; done
<teratorn> bob2: thanks, I'll experiment
<bob2> repo-push would be ideal. but I don't think it can push into a subdir of a repository
<fullermd> Well, I would read the question as asking rather about merge...
<teratorn> bob2: "bzr branches" just prints a single newline when run on either of my repos
<teratorn> bob2: and besides.. I don't wish to have a separate branch existing within a subdirectory of another branch... I wish to merge revisions from repo B in to A, except I want the files in repo B to appear inside a subdir of repo A
<teratorn> I'm going to delete repo B once this is done
<bob2> I think we're conflating branches and repositories
<teratorn> ok, probably so :)
<bob2> in bzr, repositories are just places where branches live and share storage.  you can not ever use a repository, and it'll only cost you some disk (and maybe bandwidth).
<teratorn> ok
<bob2> are A and B branches (ie contain files you've commited etc)?
<teratorn> yes
<teratorn> so yeah, I was using the wrong terminology
<bob2> are A and B related at all (ie is one a branch of the other)?
<teratorn> no
<teratorn> but I've decided that the content is logically related, and so I've decided to merge the branches
<teratorn> s/merge/combine/
<teratorn> and I have no idea what that means in terms of BZR
<bob2> I think the trick would be: (in B) "bzr mkdir subdirwhereyouwantthefilestoappearinA ; bzr mv * subdirwhereyouwantthefilestoappearinA" (in A) "bzr merge -r0..-1 ../b ; bzr commit -m 'merge in B.'"
<bob2> er, commiting in B after the mv
<bob2> fullermd: right?
<teratorn> sounds like we're getting there... the thought that I would have to "mirror" the directory structure occured to me
<bob2> (you could do the mv after the merge, but it'd be fiddler if any of the names collided)
<fullermd> Pretty much, yeah.  With rich roots, 'bzr join' should be able to automate some of that.  Ditto for the 'merge-into' plugin.  But it's not that hard to do it manually.
<fullermd> (don't forget to commit after the mv in B before you merge)
<teratorn> bob2: OK, well yes what you suggested did work.
<teratorn> looking at 'bzr log' in A it seems that all the revisions from B are now sub-revisions of the revision I committed to A after merging
<teratorn> and I suppose when I push to SVN it will only go through as a single commit
<teratorn> so Trac won't have my actual history...
<teratorn> is this always how bzr merges work?
<fullermd> Well, when you try and shove it into a round hole like SVN...  ;)
<dereine> how can i rename files?
<james_w> dereine: is "bzr mv" what you are after?
<dereine> thx i tought mv would be do easy ^^
<lifeless> spiv: call?
<spiv> lifeless: sure.  I'm on skype if you want to use that.
<lifeless> its trying ...
<lifeless> fooding
<poolie> lifeless, spiv, anyhow today i was going to finish setting up kerguelen to the point it can at least manually build correct packages
<poolie> and then do 1.8final and 1.8rc1
<arjenAU> poolie: morning! hey quick q... I did mv of a version controlled file (without bzr mv), then mistakenly did bzr commit but aborted it, renamed back, then bzr mv but then bzr says it's not under revision control. I think that something does get committed at least as far as the live state is concerned?
<arjenAU> I can run through it in a fake repo to reproduce ... this is 1.7 I think
<poolie> if you can write a reproduction script that would be good
<arjenAU> on it. no worries.
<lifeless> poolie: cool
<poolie> when you say "aborted" do you mean you uncommitted, or you pressed ^C during the commit?
<lifeless> poolie: I'm working on  fetching inventories faster
<poolie> if the latter, it's possible that you caught it after the workingtree was updated but before the branch was updated
<poolie> since it is not precisely atomic across those objects
<poolie> lifeless: and doing something on usertest? writing more scripts?
<poolie> lifeless: btw i looked yesterday and orcadas was still running the same job
<arjenAU> and we have a hit. ok wraping up the script
<poolie> since it runs bzr branch several times
<poolie> you can reproduce it?
<arjenAU> poolie: https://bugs.launchpad.net/bzr/+bug/282402
<ubottu> Launchpad bug 282402 in bzr "bzr losing track of file in aborted commit of rename" [Undecided,New]
<arjenAU> ye that ;-)
 * arjenAU forgot about the bot
<lifeless> poolie: no, I mentioned usertest to andrew in the context of 'usertest is still fetching'
<poolie> is that meant to be an 'uncommit'?
<arjenAU> nop
<lifeless> poolie: it only clones the full repo once
<poolie> arjenAU: ??
<poolie> # abort the following commit, because we realise we should've done the rename through bzr
<poolie> bzr commit
<poolie> what does that mean?
<arjenAU> poolie: exit out of the changelog editor without saving, so it does not commit
<poolie> oh i see
<arjenAU> except SOMETHING is stored anyway...
<arjenAU> yea. and veyr common possibly, it's so easy for the fingers to type mv and late realise that it was wrong - you realise when you see the changelog in commit, so you back out, ....blahdiblah and there you are, a murdered history
<arjenAU> I haven't tracked what is actually mucked up where, but since you guys will fix this I won't bother ;)
<poolie> :)
<lifeless> arjenAU: so you've done 'mv foo bar'
 * arjenAU hugs all bzr devs - great work everybody, thanks! sooooo easy. kinda feels like bk when I first got to use it years ago
<poolie> i answered it
<lifeless> arjenAU: and "bzr commit -m ''" loses the fact foo existed
<lifeless> ?
<lifeless> I bet its the implicit delete code
<poolie> yes, it is
<lifeless> 6ok cool
<arjenAU> never use -m
<lifeless> -> repository code
<poolie> lifeless: i remember you have an opinion about that but i can't remember which way it points :)
<poolie> against or in favor of implicit delete?
<lifeless> poolie: I want auto-add and auto-delete in commit, for symettry
<lifeless> poolie: I wrote a patch to do auto-add in commit, it was .. contentious
<poolie> ok
<arjenAU> oh hmm... well commit doesn't auto-add things, so I don't want it to auto-rm things either
<lifeless> but yeah, I'm fine with the functionality
<poolie> i agree they should be symmetrical but i suspect it should default off
<arjenAU> but it should be either or none
<arjenAU> you know you could make it even more nifty
<lifeless> poolie: the thread is there on the list :>
<arjenAU> if a file vanishes, grab a hash of the alst revision and see if any of thenew files is the same?
<arjenAU> suggesting a rename!
<arjenAU> won't work if it was also edited, but...
<poolie> i think there's a bzr-autorename plugin that does this?
<arjenAU> plugins, plugins...
<lifeless> poolie: I'm really quite happy with the behaviour of 'bzr rm' now
<lifeless> poolie: I'm thinking of going back to it and removing some of the extra knobs
<arjenAU> ok so anyway you guys have an angle on what's going on. that's good, then I can move on and see the update soon!
<lifeless> arjenAU: you do know you can 'bzr revert foo' too, to restore bzr's tracking of it after it was renamed
<arjenAU> lifeless: so it's kinda half committed?
<arjenAU> lifeless: I'm just trying to get my head round what bzr is thinking there
<lifeless> arjenAU: no; the commit is writing an update to the staging area
<lifeless> arjenAU: there is a thing called dirstate that lists what is versioned in your current tree
<arjenAU> ye, so autoremoves shouldn't be written there before the commi is confirmed, then eh?
<lifeless> arjenAU: commit has two major tasks: to add a new revision to the repository, and to update the dirstate to record what was committed so it doesn't show as changed anymore
<lifeless> arjenAU: and its just unlocking rather than rolling back the change to the dirstate
<arjenAU> gotcha. so it's kinda half committed
<lifeless> arjenAU: so its precisely equivalent to 'mv foo bar' && 'bzr rm'
<arjenAU> ye ok. so with bzr revert I can undestroy my world. but you're going to fix it anyway ;-)
<lifeless> arjenAU: to restore the data for 'foo', you can do 'bzr revert foo'  (which will restore the dirstate entry) and then 'mv bar foo'
<arjenAU> foo bar. yea
<lifeless> oh sure, its a bug, but its kinda cosmetic compared to some of the performance and functionality stuff
<arjenAU> lifeless: dude this is serious, I keep tripping over it
<lifeless> (no, bar foo, to put your copy of bar back)
<MattCampbell> Does bzr work with Python 2.6 yet?
<lifeless> MattCampbell: there is a patch, I don't know if its landed yet
<poolie> MattCampbell: it is landed, it should work in 1.8rc1
<poolie> bug reports welcome
<jonoxer> Hi ppl! After all the assistance on Friday to reset the svn hard-wiring in my brain I'm back with another question. One that will make ArjenAU very happy
<jonoxer> I've successfully switched a few svn repos to bzr by doing something like: "bzr branch file:///home/jon/temp/svn/blah blah" (with the bzr-svn plugin installed)
<arjenAU> jonoxer: go for it, grasshopper. your world will be better
<jonoxer> But it runs out of memory about 3 hours and 11,000 commits into converting a 21,000 commit, 4.4G repo
<jonoxer> I get a traceback from bzr
<jonoxer> This is on a machine with 2G RAM, 4G swap, and it doesn't ever fill the swap
<lifeless> jonoxer: well, whats the traceback
<jonoxer> Is there any recommended way to convert a large repo?
<jonoxer> lifeless: I'll pastebin it, gimme a sec...
#bzr 2009-10-05
<RenatoSilva> how to write a multi-line commit comment in command line?
<Peng_> RenatoSilva: That's a question for your shell, nothing bzr-specific.
<Peng_> It works automagically in bash. You can just hit Enter while writing a string. But I dunno about any other shells.
<Raim> if you do not trust that, you can use a file for the message: bzr commit -F msg.txt
<RenatoSilva> ok
<Raim> but actually I would prefer using a real editor
 * RenatoSilva trying to find how to do that in windows
<mneptok> cygwin?
<RenatoSilva> I use MinGW
<igc> morning
<igc> hi mneptok!
<superm1> hey guys.  i'm having a hard time pulling a new reversion: [mlimonciello@devel mythbuntu-weekly-build]$ bzr pull
<superm1> Using saved parent location: http://bazaar.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-weekly-build/
<superm1> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-weekly-build/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<superm1> any suggestions?
<verterok> igc: hi
<Peng_> superm1: What version of bzr?
<superm1> Peng, should be a freshly installed 2.0.0
<Peng_> superm1: Just for fun, try "bzr --no-plugins pull".
<superm1> Peng, same thing
<wgrant> superm1: Did you 'bzr co' from an HTTP URL? It sounds like you have a branch bound to an HTTP URL.
<wgrant> (in which case 'bzr up' is what you want, not 'bzr pull')
<verterok> igc: good news! I finally got a working installer for PyQt+sip, but only for OS X 10.5...I need to work on the 10.4 version
<Peng_> Ooooh.
<superm1> wgrant, well this c/o was from ages ago.  since then the branch got upgraded to 2a, and i had to upgrade bzr, and then it stopped working
 * Peng_ goes /away
<wgrant> superm1: It shouldn't be related to the upgrade.
<superm1> wgrant, bzr up does the same thing :(
<wgrant> superm1: pastebin 'bzr info -v'
<superm1> wgrant, it looks like it might have been something related to being bound to HTTP though. i just did bzr unbind, and it's doing more stuffs
<superm1> yup, that worked swimmingly! thanks!
<wgrant> Strange.
<poolie> hello all
<poolie> hi igc, are you at work today?
<verterok> hi poolie
<GaryvdM> Hi igc.
<igc> hi verterok. Very well done. Even getting the Leopard one out will be huge step forward!
<igc> hi poolie. Are you back in Oz today?
<igc> hi garyvdm!
<poolie> hi, i am
<poolie> i'm just cleaning up my receipts and office atm
<igc> poolie: I'm well thanks
<poolie> glad to hear it
<igc> poolie: just arrive back this morning? Must be tired I'd imagine
<poolie> yesterday morning
<poolie> slept a lot, ok now
<poolie> for the moment :)
<igc> :-)
<GaryvdM> superm1: This is a guess... Maybe you have the webdav plugin, but that location does not support webdav.
<GaryvdM> superm1: If you have a launchpad account, with a ssh key set up, then set bzr launchpad-login, and run bzr pull lp:~mythbuntu/mythbuntu/mythbuntu-weekly-build/.
<igc> poolie: a new qbzr (0.14.3) is out which fixes a bad bug in TortoiseBzr apprently
<GaryvdM> Tha will then use bzr+ssh
<igc> poolie: I'm not sure if it's serious enough to warrant rebuilding the Windows installer for. GaryVdM may know
<igc> poolie: otherwise, I'm hoping you're keen to make the big announcement today.
<igc> poolie: we don't want it coming out after the 2.1.0b1 one :-) :-)
<poolie> igc, i am
<igc> verterok: did you see the os x tour?
<GaryvdM> superm1: This is a guess... Maybe you have the webdav plugin, but that location does not support webdav.
<GaryvdM> superm1: If you have a launchpad account, with a ssh key set up, then set bzr launchpad-login, and run bzr pull lp:~mythbuntu/mythbuntu/mythbuntu-weekly-build/. That will then use bzr+ssh rather than http.
<verterok> igc: nope
<poolie> igc, btw it's a holiday here so spiv will be away
<poolie> i'm swapping it for next week
<poolie> and lifeless is in montreal of course
<verterok> igc: btw, I've been trying to get a app bundle working, I have a working bzr.app bundle (with some hacks to py2app)...but only for CLI, I'm having some problems with qbzr/explorer
<GaryvdM> Hi Poolie.
<poolie> hi gary
<poolie> and verterok
<pygi> GaryvdM, poolie hey ho folks
<igc> poolie: ah - didn't know about your public holiday
<GaryvdM> poolie: I sent my gpg key :-) - I'm not sure if I sent the correct part.
<GaryvdM> Hi pygi!
<poolie> k, i just got back from a launchpad meeting in london yesterday
<poolie> still catching up on stuff
<GaryvdM> ok - sure.
<zsquareplusc> what's up when some viewers show 9 revisions and some other 400... (there are 400 revs merged into that tree)
<zsquareplusc> well, the actual problem is that bzr qlog shows e.g. rev 398 and when i try to remove that with merge -r 397..398 it says so such revision
<zsquareplusc> bzr log even shows negative revsions :/
<zsquareplusc> is there a way to repair that?
<mwhudson> zsquareplusc: oh that bug
<mwhudson> zsquareplusc: i think reconcile will fix that
<zsquareplusc> mwhudson: indeed, it did. thanks
<zsquareplusc> now that merge command just did nothing. bzr merge . -r 397..398  says "all changes applied" and changed nothing
<zsquareplusc> how do i remove the changes introduced by a revision? i thought the command above should work.
<bob2> Y..X
<zsquareplusc> ah.. heh, the example in bzr revert has negative numbers, translating that to positive rev numbers isn't easy ;-)
<mwhudson> zsquareplusc: you need to reverse the numbers
<zsquareplusc> mwhudson: yep. i understood the hint by bob2
<mwhudson> ah cool
<fbond> I'm getting a "file id ... is not present" error with 2.0.0.
<fbond> This is a branch with a single committed revision.
<fbond> I'm doing a diff before committing a second revision.
<fbond> Standalone tree (format: pack-0.92)
<fbond> Is this a known issue?
<fbond> Doing bzr init in a new dir followed by bzr pull gives me a working branch.
<fbond> Format is 2a in that branch.
<SamB_XP> I'd guess it's bitrot in the support for pack-0.92 ...
<SamB_XP> I would have guessed that even before you tried 2a
<fbond> SamB_XP: Not sure which bzr version I was using when I *created* that pack-0.92 branch.
<fbond> I'm using bzr from the PPA, so I get updates...
<SamB_XP> well, if it pulled okay, it must not be too bad!
<fbond> Guess so.
<fbond> I'd rather stick with pack-0.92 for some reason.  I like to sit on the new formats for a bit usually.
<SamB_XP> so, I'd make a bug and attach that repo to it
<fbond> This is an internal project, though, so not a big deal in this case.
<SamB_XP> as a tarball
<SamB_XP> ... if it's not a big deal ...
<fbond> SamB_XP: Hm, can't publish this particular repo.
<SamB_XP> oh, not so good :-(
<fbond> Maybe a log would be okay?
<fbond> I don't mind creating a bug.
<fbond> Hm, I just created a new pack-0.92 branch and pulled into that.  Works fine.
<fbond> Not sure what would've been wrong with my other branch... (looks like an issue with the WT, not the branch itself, for whatever that's worth).
 * igc lunch
<davidstrauss> abentley: If I have an addition to bzrtools, should I just submit it as a merge proposal to lp:bzrtools?
<davidstrauss> Any idea why a process would hang on process.stdin.write?
<davidstrauss> I'm trying to pipe to tar for a bzrtools extension
<davidstrauss> and tar runs properly, but the code never moves beyond process.stdin.write
<SamB_XP> davidstrauss: maybe it needs stdout read ?
<SamB_XP> or possibly stderr?
<davidstrauss> SamB_XP: I've already decided to move to tarfile, anyway
<davidstrauss> SamB_XP: but thanks
<SamB_XP> probably wise ;-)
<SamB_XP> that's more portable anyway
<poolie> davidstrauss: if i was there, i'd run strace on the tar process and see what it's doing rather than reading from stdin
<abentley> davidstrauss: Sure.
<davidstrauss> abentley: This utility downloads a tarball and replaces the current stuff in the branch with the tarball contents.
<davidstrauss> abentley: Candidate for bzrtools?
<abentley> davidstrauss: Sounds like the import command.
<davidstrauss> abentley: where is that defined?
<davidstrauss> abentley: Neither code nor bzrtools seems to have one
<davidstrauss> abentley: nevermind
<abentley> davidstrauss: It's part of bzrtools.  It's mainly defined in the file upstream_import.py
<davidstrauss> abentley: looks perfect. thanks.
<davidstrauss> abentley: And it does exactly what I want with directory stripping, etc.
<CameronP> Hi Everyone -
<poolie> igc, please don't push to the web site branch for the moment while we're deploying it
<igc> poolie: ok, I'm done in any case
<poolie> ok, it's done
<igc> poolie: awesome!
<poolie> igc, search isn't working well though - i don't know if i broke it, or if it was just not working?
 * igc takes a look
<CameronP> Getting an error with v 2.0.2 - when trying to commit bzr: ERROR: Invalid url supplied to transport: "file:///home/developm/public_html/xyz/": Win32 file urls start with file:///x:/, where x is a valid drive letter
<CameronP> I think it might be a bzr upload plugin issue
<poolie> igc, do you think we should redirect the /Welcome page too?
<poolie> i think maybe so
<igc> poolie: no, please leave Welcome there as the Wiki home page
<poolie> CameronP: 2.0.2?
<CameronP> yeah 2.0.2
<igc> poolie: buttons aren't rendering properly either btw
<poolie> CameronP: could you please file a bug with the traceback from bzr.log, then paste the number here
<poolie> the ones next to the left hand links? i'm fixing it
<CameronP> sure, how do i do the traceback from bzr.log
<igc> poolie: also Get Xxx buttons
<poolie> CameronP: open it in notepad and copy from it
<CameronP> ah should i do it from the server (linux) or the client im comitting from (winblows)
<poolie> the client
<igc> kirkland ping
<poolie> igc, the buttons should be ok now
<poolie> the default font still looks a bit small to me?
<igc> poolie: edit it in css/html-elements.css maybe
<igc> poolie: maybe search.html has to move to the end directory as well?
<igc> poolie: also, the wiki pages aren't rendering correctly in case you didn't know
<poolie> i hadn't seen that but you're right
<poolie> igc, looks ok again now?
<igc> poolie: much better
<igc> poolie: btw, clicking on the Bazaar logo in the Wiki goes to the home page, not Welcome
<igc> is that what we want?
<poolie> (trying to fix search)
<poolie> hm
<poolie> probably yes?
<igc> I guess we need a link in the header to both somehow?
<poolie> i'd like to eventually have the top nav bar include a link to the wiki and then be common to both
<igc> that would be good
<poolie> so i propose to change the search thing to have it just present results in a google page
<poolie> like
<poolie> http://www.google.com/cse?cx=009852948614216791564%3Adr5xzrczfnu&ie=UTF-8&q=checkout&sa=Search
<poolie> i think ej is trying to have it present them within this page
<poolie> which would be nice but i can't see how it would work with this current code a
<poolie> and last time i tried it put it in the wrong place in the page
<poolie> also i might pay for the ads to be removed from that page
<igc> ok. I know kirkland helped her get it working but he's probably asleep now
<kirkland> igc: not sleeping, just not paying very close attention
<igc> hi kirkland. we've just make the website live but search isn't working
<kirkland> igc: url?
<igc> probably because index.html moved to en/index.html
<kirkland> igc: yup, should be trivial to fix
<poolie> hello kirkland
<igc> http://bazaar-vcs.org/
<poolie> can you tell me how you're setting this up?
<igc> poolie: another minor quibble - the bazaar icon is missing from the tab in ff now
<poolie> this is the iframe approach?
<igc> favicon.ico?
<poolie> ok
<kirkland> <form id="searchbox_009852948614216791564:dr5xzrczfnu">
<kirkland> add action="/en/"
<poolie> ok, i see
<igc> poolie: something has gone weird btw
<poolie> mm?
<igc> well done? We couldn't get that effect if we tried :-) :-)
<poolie> which effect?
<igc> try refeshing your page
<poolie> wow
<poolie> lots of strange spacing?
<igc> yep, something about links
<igc> I suspect
<igc> all mine are yellow and on newlines
<kirkland> missing a close </div>
<CameronP> poolie: should i file this bug under the upload plugin or under bazaar - i have confirmed when the auto upload feature is turned off of the plugin on the server, I no longer get the error
<poolie> ok, bzr-upload then
<poolie> igc, kirkland, ok, search and links are ok now istm
<kirkland> poolie: well done
<igc> poolie: much better
<igc> search button on line below box though?
<poolie> on the results page? i know
<igc> main page
<poolie> ok, i see why
<poolie> yay version control :)
<poolie> we need to switch this to some kind of templating system
<igc> verison control ftw!
<CameronP> https://bugs.launchpad.net/bzr-upload/+bug/442798
<ubottu> Launchpad bug 442798 in bzr-upload "error with --auto feature turned on with 2.0.2" [Undecided,New]
<realbadapple> can anyone tell me what the progress of nested trees is?
<poolie> CameronP: the thing is, there is no 2.0.2
<poolie> realbadapple: it's still pending; the best option atm is probably scmproje
<poolie> scmproj*
<realbadapple> anyone? nested trees! how soon till this work flow will be supported?
<realbadapple> sorry poolie
<igc> realbadapple: it's a feature under development
<realbadapple> did not notice the response
<igc> realbadapple: it won't be in production for another 5-6 months given we're now on 6 months releases
<realbadapple> thanks can't wait!
<igc> realbadapple: it *may* appear earlier in a beta but use scmproj for now if you can
<realbadapple> this would really help with useing eclipse for development
<realbadapple> scmproj?
<realbadapple> is it a plugin?
<igc> yep
<poolie> http://bazaar-vcs.org/ScmProj
<realbadapple> ok thanks I'll give it a look
<poolie> k, search looks good now
<igc> realbadapple: if you haven't already, see http://bazaar-vcs.org/BzrPlugins
<igc> that page has just been reorganised so it ought to be easier to find plugins now
<poolie> i'm just going to handle the noscript case a bit better by falling back to the google-hosted version
<realbadapple> ya I've glanced at the plugins page but have not looked closely
<igc> poolie: search is good for me now. It's pretty damn cool actually
<poolie> indeed
<igc> thanks a heap kirkland!
<poolie> though it gives me sex ads when i search for 'test'
<kirkland> igc: cheers
<igc> :-(
<poolie> so i'd like to get them off
<poolie> like many things in life, a small matter of handing over money :}
<igc> poolie: maybe we want a Search and an "I'm feeling lucky" button in the nav bar ...
<igc> the latter gives the ads :-)
<igc> poolie: so favicon.ico is the only issue I can see now
<poolie> well, and noscript search
<mneptok> igc: heya! (late)
<igc> hi mneptok - great to hear from you!
<poolie> hello mneptok
<poolie> igc, i think the favicon is now/soon fixed
<igc> pooie: yep - working now
<poolie> do you have any opinion about how to do templating?
<luke-jr> with pizza.
<poolie> i tested in lynx and it looks pretty good, including search
<poolie> ?
<luke-jr> templating is always more enjoyable when you have pizza.
<mneptok> poolie / igc: i've been sort of incomunicado the past 10 days while my wife and i moved to a new house we just bought. there's a guest bedroom if any bzr devs feel like seeing New Mexico before/after North American sprints. :)
<igc> poolie: how about this ...
<igc> With true rename tracking for files and diriectories,
<igc> you can refactor code without fear of merging.
<igc> still too sales-ish?
<poolie> oh thanks very much mneptok
<igc> poolie: I haven't though about templating
<poolie> no plans to go there atm
<poolie> igc, i might try to convert it to cheetah tomorrow
<poolie> i'm going to stop for today now
<igc> sphinx uses jinja fwiw: http://sphinx.pocoo.org/templating.html#working-the-the-builtin-templates
<poolie> ok
<poolie> consistency++
<davidstrauss> Before I go down any more rabbitholes, is there a streamlined way to take a bzr branch and check in the current working copy to CVS?
<poolie> there are dozens of libraries implementing "string % kwargs" :_)
<poolie> davidstrauss: just have one directory which is both a bzr and cvs checkout?
<davidstrauss> poolie: More like git-cvsexportcommit
<igc> davidstrauss: is the export command useful to you for that?
<DaffyDuck_`> Is there a file under .bzr which will always be updated when some change has been made? (a commit, a tag created, changes have been pulled, etc?)
<davidstrauss> igc: Not really. The complexity is in the CVS/ metadata.
<igc> DaffyDuck_`: .bzr/branch/last-revision goes close
<DaffyDuck_`> I'm looking for some kind of "last change" timestamp, which convers _all_ types of changes.
<poolie> davidstrauss: what is it that you want to have happen in cvs?
<igc> I'm not sure you ought to rely on a given file. Can you use a hook instead?
<igc> (filenames can always change over time as formats evolve)
<igc> DaffyDuck_` ^^
<poolie> see you later igc
<davidstrauss> poolie: I need to take the working tree from Bazaar and push it to CVS as a commit on a specified branch.
<igc> see ya poolie
<davidstrauss> poolie: Well, I don't need to take the working tree. I can use a full-on commit.
<bialix> hello bzr 2.0
<bialix> hi igc
<igc> hi bialix
<bialix> congrat on new webpage rollout. I have one comment though, about BzrExtra
<igc> bialix: ru tranlsation of explorer is looking complete btw
<Phurl> hi all
<igc> as is the fr one
<Phurl> how can i get a rss feed from launchpad
<Phurl> is there a public hosting site for that?
<bialix> that page listed plugins in the same end. It's a bit obscure
<igc> I was wondering whether a 0.8.3 was worth it with
<Phurl> or do i need my own server?
<bialix> Phurl: what do you mean?
<Phurl> i would like a rss feed from commits
<Phurl> i found some scripts and such to do that
<Phurl> but i am missing this in lauchpad
<bob2> you mean a rss feed of commits to mainline?
<Phurl> in general I don see any rss feed option
<Phurl> yes or to my branch
<Peng_> Loggerhead has one.
<Phurl> or anything from the project
<bialix> Phurl: do you mean RSS feed for branch hosted on lp?
<Phurl> yes bialix
<Phurl> exactly
<bialix> Phurl: I'm not aware about such feature
<Phurl> ok
<bialix> you may ask in #launchpad though
<Peng_> Launchpad has one too: http://feeds.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/branch.atom
 * Peng_ points at the feed button in Firefox's location bar.
<Phurl> nice!!!
<Phurl> thanks
<bialix> hmm, I'd prefer to have explicit URL on the page
<Peng_> bialix: It is explicitly in the page, just in the <head> section.
<Phurl> bialix, perfect
<Phurl> http://feeds.edge.launchpad.net/~kosova/+junk/openstreetmapkosova/branch.atom
<bialix> explicit in the terms of I can copy-paste it
<igc> bialix: what do you find confusing about BzrExtras again?
<bialix> igc: it's hard to find plugins now
<bialix> igc: I mean there is no more short way to plugins from main page anymore
<bialix> Phurl: you mean Peng_
<igc> bialix: would it help if the plugins link came at the top?
<igc> bialix: see the footer links too btw
<bialix> igc: IMO it will be nice
<bialix> igc: this is just observation
<igc> plugins is under Extras
<igc> at the bottom of the main page
<Phurl> Peng, thanks!!!
<bialix> observation of monday morning mind, my personal wtf for today
<igc> bialix: also, there's a "Browse the plugins registry" under the introductory text
<bialix> igc: and btw content of BzrPlugins page is a bit long now ;-) I dunno is it possible to workaround this fact
<bialix> I mean list of contents
<igc> not that I know of
<igc> I guess we could limit the depth of the contents but it kind of defeats the purpose
<bialix> you're right, it is (Browse plugins). hmm, but other (main links) at top and big icon don't imply this
<bialix> anyway, congrat for new site rollover, I really hope to see BIG announce in next few days
<igc> bialix: right, so we could move plugins higher up on the BzrExtras page
<bialix> it's a bit wrong situation IMO
<igc> bialix: I thought poolie was going to do it today but it might be first thing tomorrow now
<bialix> it seems so
<igc> bialix: I suspect he wants people to test the website overnight first
<bialix> may be
<bialix> igc: re translations, I'm a bit digressed. Do you want me to sync translations with lp?
<igc> he's only just back from London btw
<igc> bialix: it was just an fyi
<igc> I'm wrapped that the ru and fr translation are so complete!
<bialix> igc: ah ok, I'm a bit busy at work
<bialix> and don't check it regularly
<igc> bialix: if we need to repackage the windows installer to include 0.14.3, then ...
<bialix> perhaps your new welcome page require translations template update
<bialix> I can do it right now
<bialix> igc: jam said he think that 2.0.1 is more preferrable
<bialix> maybe it's time to release 2.0.1 and do big announcement with 2.0.1?
<igc> cool. So maybe we'll include an explorer 0.8.3 in that as well - just updated translations
<bialix> igc: if you have access to http://pypi.python.org/pypi/bzr
<bialix> there is still 1.17!!!
<bialix> it require update
<igc> it does. I can't do it right now but I'll put it on my list
<bialix> please
<bialix> this delayed announce stuff is open can for such nit problems here and there
 * bialix believes release should be very focused on day job, not something that lasts for weeks
 * bialix believes release should be very focused one day job, not something that lasts for weeks
<igc> agreed
<bialix> grrrrr
<bialix> new lp ui is....
<bialix> grrr
<bialix> translations ui becomes worse and worse in last few month IMO
<igc> bialix: I hoped you like the explorer tour btw. It should help get some more Windows users on board which will be good for all of us
<igc> got to go now
 * igc dinner
<bialix> igc: it seems quality of russian translations is below my quality standard. I have to review new stuff before importing it into trunk
<igc> ok
<arnarl> Is there an unrevert in bzr? A couple of times now I've forgotten to add the filename that I want to revert and accidentally reverted all changes.
<bialix> igc: the tour is FANTASTIC
<bialix> arnarl: your changes backed up in *.~1~ files
<arnarl> Is there some cure for my stupidity? Not that I have lost much work this time, but still :-)
<bialix> there is no unrevert, but changes are usually saved in ~N~ files
<arnarl> a, nice I.
<bialix> you may want to use qrevert GUI dialog (from QBzr plugin) as safer revert
<arnarl> I thought those were some emacs tmp files...
<arnarl> I just try to commit often
<bialix> commit often is ok
<arnarl> but, I did not know about the *.~n~ files
<arnarl> bialix: so thnx
<arnarl> :-)
<bialix> glad to help
<nedosa> hi, quick question about hosting a bzr server on ec2, is there a way to pass an identity file to bzr+ssh ?
<nedosa> similar to invoking the -i option on ssh
<lifeless> not currently
<lifeless> you can configure things in .ssh/config
<lifeless> or add the identity to your agent
<nedosa> lifeless: cheers, i guess i have to dig around and see how can i add identity info to my ssh agent
<mwhudson> nedosa: ssh-add /path/to/identity.pem?
<nedosa> mwhudson: fantastic, thanks !
<CameronP_> Hi All
<CameronP_> trying to use bzr patch command - should it work fine with a .diff file, in  the directory of the file I want to patch?
<CameronP_> I dont think Im meant to use it in  thatway ;) oops
<matkor> Hi ! Is there any way to find when file containing given text was deleted from given file ? in bzr or bzrtools ?
<matkor> Like:  for every rev listed in  bzr log <file> do  bzr diff -c <rev> | grep <text>
<Tak> there's a bisect plugin
<matkor> Tak: "Use a binary search algorithm to apply a test of the source code for each revision", test may be simple grep ?
<Tak> the test may be whatever you wish
<Tak> basically you say "yes" or "no" for every iteration
<matkor> Tak: Ok. thanks
<davidstrauss> matkor: bzr-search does good indexing, too
<davidstrauss> matkor: bi-sect may not work if the file's been deleted more than once
<matkor> davidstrauss: Thanks.  bzr-search is another module ?
<DaffyDuck_`> Has any work gone into making bzr less resource hungry in 2.0? (see bug 408526 and bug 408531).
<ubottu> Launchpad bug 408526 in bzr "bzr commit on large projects require large amounts of memory (dup-of: 109114)" [Undecided,New] https://launchpad.net/bugs/408526
<ubottu> Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Triaged] https://launchpad.net/bugs/109114
<ubottu> Launchpad bug 408531 in bzr "bzr branch on large projects require vast amounts of memory" [Undecided,New] https://launchpad.net/bugs/408531
<davidstrauss> matkor: yes
<Peng_> DaffyDuck_`: bzr 2.0 with the 2a format holds a lot less in memory.
<Peng_> DaffyDuck_`: IIRC, it's down to file text + compressed version when committing.
<DaffyDuck_`> Peng_: Would that specifically be 2.0, 2a or a combination of both? I already use 2a, but with 1.7/1.8, but they both exhibit the problem.
<Peng_> DaffyDuck_`: It requires the 2a format, but I don't know the version of bzr.
<Peng_> Ah, it's 1x file bytes + 2x compressed bytes: https://bugs.edge.launchpad.net/bzr/+bug/109114/comments/15
<ubottu> Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Triaged]
<DaffyDuck_`> Peng_: That's promising! Thanks!
<michaelforrest> #ubuntu-desktop, #ubuntu-devel, #ubuntu-doc, #ubuntu-installer,
<michaelforrest> #ubuntu-website, #whatwg
<michaelforrest> (oops - tried a /join command that didn't work - sorry)
<phinze> can someone help me translate this into bzrlib API terms?  i want to build a pre-commit hook that greps through the incoming diff for a keyword.
<phinze> would this be checking through bzrlib.delta.report_changes(oldtree.iter_changes(newtree), ???)
<phinze> hmm or maybe better bzrlib.diff.show_diff_trees(oldtree, newtree, stream_to_string), and loop through that looking for my keyword
<LpSolit> when I get a patch created with bzr, how can I know which file revisions the patch was made against?
<LpSolit> cvs diff adds the file revision number to the file, so it's easy to know
<LpSolit> but bzr diff only adds the date the file was edited, it looks like
<Lo-lan-do> Is it a bundle generated with bzr send, or just a diff generated with bzr diff?
<LpSolit> Lo-lan-do: with bzr diff
<Lo-lan-do> Not sure you can then.
<LpSolit> :(
<Peng_> LpSolit: Why not use "bzr send"?
<LpSolit> Peng_: 1) because I never heard about it, and 2) because people create patches using bzr diff
<LpSolit> does bzr send alter my installation?
<LpSolit> or does it only generate a patch?
<bialix> LpSolit: why you need to know revision then?
<Lo-lan-do> It generates a patch with extra metadata
<LpSolit> bialix: because in Bugzilla (it's a bug tracking system developed by Mozilla), we want the ability to display patches with their context, i.e. patches most of the time have 3 lines of context, and we have the ability to display patches with as many lines of context as you want
<LpSolit> bialix: so you can select context=50 and you have the same patch redisplayed with 50 lines of context
<LpSolit> this works for years with CVS
<LpSolit> and I have to update Bugzilla internals to work with bzr
<Peng_> You can't do that with bzr, though it likely wouldn't be hard to add.
 * LpSolit wonders if what I said is clear enough
<bialix> `bzr send --no-bundles` is roughly equal to plain diff but with revision id
<LpSolit> let me try bzr send
<bialix> Peng_: it can be done with plugin
<LpSolit> $ bzr send --no-bundles test_config.t
<LpSolit> bzr: ERROR: no such option: --no-bundles
<LpSolit> Peng_: would it be reasonable to request to append the revno to the file name?
<bialix> --no-bundle sorry
<LpSolit> so instead of --- process_bug.cgi	2007-10-12 07:21:59 +0000 , we would have:
<LpSolit> --- process_bug.cgi	2007-10-12 07:21:59 +0000 344
<LpSolit> or something like that
<LpSolit> maybe revno:344
<bialix> LpSolit: revno is local info for the branch
<Lo-lan-do> It's still valuable info.  Not everyone uses branches everywhere :-)
<bialix> in the a diff context you should use revision id
<bialix> IIRC svn shows revno in the diff comment
<Tak> yeah, it does
<LpSolit> same for cvs
 * LpSolit really needs this info
<LpSolit> bzr send --no-bundle -o toto.diff
<LpSolit> Using saved submit location "test_config.t" to determine what changes to submit.
<LpSolit> bzr: ERROR: Not a branch: "/var/www/html/selenium/bugzilla/bzr/3.4/t/test_config.t/".
<LpSolit> what is it trying to do? :)
<bialix> send requires trunk branch available and passed as 1st argument
<bialix> and send works with committed changes
<bialix> perhaps it's not what you need
<LpSolit> no, it's not
<LpSolit> before committing changes, the patch has to be approved by reviewers first
<bialix> IMO you can file a bug asking for this feature or write plugin
<bialix> > before committing changes, the patch has to be approved by reviewers first
<bialix> in bzr we working another way
<bialix> commit your changes, then send a patch for review
<bialix> LpSolit: bzr is DVCS
<bialix> commit won't clutter trunk until it will be merged
<LpSolit> yes, I know that. Being a CVS user for many years, the change is not obvious :)
<LpSolit> oh, right
<bialix> LpSolit: look https://code.launchpad.net/bzr/+activereviews
<bialix> abentley: can you restart bundle buggy please?
<abentley> bialix: done.
<bialix> abentley: error 503
<abentley> bialix: Bundle Buggy is currently plowing through a big backlog of email, but it works for me.
<bialix> now and for me
<bialix> LpSolit: look also http://bundlebuggy.aaronbentley.com/
<bialix> this one works with the output of bzr send command
<bialix> abentley: thanks
<LpSolit> where is the metadata?
 * LpSolit is looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49F22B67.8020703%40aaronbentley.com%3E
<abentley> bialix: np.  btw, launchpad also works with send.
<bialix> abentley: IIRC the e-mail should be GPG-signed, right?
<LpSolit> oh, I can see it when downloading the patch
<LpSolit> ok
<abentley> bialix: Yes, and you need to have a Launchpad account with that GPG key.
<bialix> I was not aware about assigning GPG to account
<lgoodrich> Hello all. I've come up dry on google so I'm wondering if anyone on here knows. Is there any way to delete a file from your revision history?
 * bialix forgot about GPG
<lgoodrich> I was able to do it in Subversion a while back through an annoying process of exporting and importing the repository. I'm hoping there is at least some similar way, if not easier.
<bialix> lgoodrich: if you mean to completely remove history for the file then no
<lgoodrich> not even through some sort of export, filter, then import process?
<bialix> this will works
<LpSolit> bzr log test_config.t
<LpSolit> ------------------------------------------------------------
<LpSolit> revno: 48
<LpSolit> timestamp: Mon 2008-10-20 01:41:26 +0000
<LpSolit> works
<bialix> but after re-import you'll have completelly unrelated history
<LpSolit> but: bzr cat -r date:2008-10-20,01:41:26 test_config.t    returns:
<LpSolit> bzr: ERROR: The file id "test_config.t-20081020014126-eujmy2eg2qvr-1" is not present in the tree <Inventory object at b74a650c....
<LpSolit> what's wrong with that?
<LpSolit> I'm trying to use the timestamp when the revision id is not available
<bialix> bzr cat -r date:2008-10-20 test_config.t
<bialix> maybe
<lgoodrich> hmm, I'll see if its worth the hassle, thanks
<LpSolit> bialix: same error
<bialix> is it possible the file was renamed?
<LpSolit> no, the file is still here: http://bzr.bugzilla.org/selenium/3.4/annotate/head%3A/t/test_config.t
<bialix> this page http://bzr.bugzilla.org/selenium/3.4/changes?filter_file_id=test_config.t-20081020014126-eujmy2eg2qvr-1
<LpSolit> hum, so it matches what the error message was reporting
<LpSolit> test_config.t-20081020014126-eujmy2eg2qvr-1
<bialix> says the date should be 2008-10-19
<bialix> perhaps TZ issue
<bialix> it's a bug though
<bialix> see 20081020 in the file-id
<LpSolit> doesn't work with 2008-10-19 either
<bialix> it's the timestamp when file was added
<LpSolit> if I type: bzr cat -r 48 test_config.t, I get the file content
<bialix> there is plugin file-revno which can print revno number of the last change for the file
<LpSolit> so it only fails with date:
<bialix> file a bug please
<LpSolit> bialix: URL to your bug tracker?
<LpSolit> I know you don't use Bugzilla :)
<bialix> https://bugs.launchpad.net/bzr
<LpSolit> bialix: thanks! https://bugs.launchpad.net/bzr/+bug/443419
<ubottu> Launchpad bug 443419 in bzr "bzr cat -r date:YYYY-MM-DD,HH:MM:SS filename doesn't work" [Undecided,New]
<bialix> thanks
<maxb> Hi. I've been considering moving a project from cvs to bzr. After deliberation, I think the sticking point is bzr's worldview of having a branch, not a repository, as the primary object. Specifically, I'll end up losing history (or at least having it cumbersome to access) as parts of it become confined to branches which no one remembers to look at
<eferraiuolo> I was wondering if there was a planned binary Mac OS X 10.6 install for bzr-explorer?
<maxb> I'm wondering if anyone has any bzr documentation or evangelism that might help me understand how this isn't a problem for more people.
<lifeless> eferraiuolo: I suspect there is
<mwhudson> maxb: bzr log --include-merges shows that "lost" history
<mwhudson> maxb: if that's what you mean
<mwhudson> maxb: (or qlog or whatever)
<maxb> Only if it actually got merged
<lifeless> maxb: what do you mean by 'more cumbersone'?
<maxb> As in, in any other VCS, I would point <some log viewer> at the repository and explore all the history
<lifeless> well, I dispute the 'any other' phrase :)
<lifeless> in any DVCS it would only be 'all the local history', in other ones like codeville, they behave like bzr
<lifeless> however, qbzr can do viz on multiple branches
<lifeless> I think a bug on it to allow qbzr <root of repo> to work would be well received
<lifeless> maxb: anyhow, I think it isn't a problem because people don't need to do it
<maxb> I suppose my consternation is magnified by this being a conversion from CVS, and knowing that I'll have to coax people away from CVS practices
 * mwhudson has almost entirely forgotten that software development is even possible with CVS, let alone how it is done
<lifeless> maxb: so, one use case is 'find a brnach name' which is replaced by 'ls' [or 'bzr branches']
<maxb> mwhudson: I wish I _could_ - but I'm forced to use it at work :-) Hence the attempt to plot a way out.
<maxb> lifeless: A use case I'm concerned about is "Find a tag. I don't know which branch it's in"
<lifeless> maxb: so, what bzr does is merges release branches to trunk
<maxb> ls / bzr branches are somewhat problematic unless you have *all* branches locally
<lifeless> maxb: so all tags are in trunk
<lifeless> maxb: yes, but see under distributed
<maxb> I think you are right, using bzr is going to entail convincing cvs2bzr to merge branches to trunk whereever possible, for the past, and convincing developers of the same, for the future
<jam> maxb: well if a feature isn't merged to trunk, then it would stand to reason that the tag isn't there, no?
<bob2> what are all these unmerged branches in cvs being used for?
<maxb> Well, some of them probably have been merged. (but being CVS, you can't tell). And some are ad-hoc "just getting a release out there" branches
<poolie> jam, hi?
<maxb> I wonder how plausible it would be to write a tool which can add an extra parent to an EXISTING revision?
<maxb> I realise this can only work if you know you hold the only copy of the repository
<maxb> But it would be an interesting option for patching up a cvs conversion before making it public
<jam> maxb: filtering the output of 'cvs2bzr' (the fast-import file) is the perfect time to do that
<jam> before it gets imported
<maxb> jam: Well.... sort of. It's a lot easier to find the joinpoints if you can 'bzr viz'
<jam> maxb: you can iterate over it
<jam> convert, filter, convert again, etc
<maxb> this is true. I'm just a bit unsure how you'd inject the information back into the conversion
<jam> maxb: you might look at fastimport's 'filter-branch' stuff
<igc> morning
<meoblast001> hi
<meoblast001> i have my email in Bazaar set to "meoblast@aol.com"
<meoblast001> if i change my email address, that might become a problem
<meoblast001> is it safe to just set it to "meoblast"
<malept> hi, I have a repository being served with the bzr+http protocol. I recently upgraded the server from 1.9 to 2.0, and now commands to it die with "An attempt to access a url outside the server jail was made". I'm not entirely sure how to fix this.
<wgrant> meoblast001: Some applications (eg. Launchpad) identify you by email address, so changing it to just 'meoblast' would result in Launchpad no longer linking your commits to you.
<meoblast001> ugh
<meoblast001> i don't like aol though
<meoblast001> i plan to switch
<meoblast001> and when i do, everything will recognize me as a new person entirely
<wgrant> Is it really a problem if some of your old commits have an old email address?
<meoblast001> wgrant: well, services, such as ohloh, detect developers by email
<meoblast001> new email makes you a different developer
<malept> meoblast001: those services allow you to have multiple emails per user
<wgrant> Right.
<wgrant> You can easily merge the users.
<malept> I am certain of this for at minimum, LP and Ohloh.
<meoblast001> do pretty much all services like that have those features?
<bob2> meoblast001: also, changing to 'meoblast' would cause a discontinuity now, anyway
<bob2> meoblast001: just the same as moving to a new email address would
<meoblast001> bob2: well, if you do it the normal way ;)
<meoblast001> keep in mind pretty much no one but me and one other developer has a checkout of my project
<meoblast001> so now is the best time to fix screw ups
<poolie> hello igc
<igc> hi poolie
#bzr 2009-10-06
<meoblast001> wgrant: so having old email addresses is normal?
<spiv> Good morning.
<igc> hi spiv
<wgrant> meoblast001: People change email addresses. You cannot change them in old commits. I think so.
<meoblast001> well, you can, but it's not normal :P
<meoblast001> and it breaks compatibility of all branches
<igc> verterok: see https://answers.edge.launchpad.net/bzr-explorer/+question/84897. Was it ok to say that?
<meoblast001> wgrant: one last question, do most version control systems also use emails like bazaar does?
<meoblast001> bazaar is the only real version control system i've used with any of my projects
<wgrant> meoblast001: I think all the DVCSes do, but I couldn't be sure.
<malept> hi spiv, I believe you know the most about smart http servers?
<wgrant> SVN does whatever it wants.
<spiv> malept: probably, yeah
<malept> spiv: what does ""An attempt to  access a url outside the server jail was made""
<malept> mean?
<meoblast001> wgrant: well, as linus torvalds says, svn is horrible, right? ;)
<wgrant> meoblast001: Yes.
<malept> (followed by a chroot-[somenumber]:///)
<spiv> malept: probably that you're hitting https://bugs.edge.launchpad.net/bzr/+bug/348308
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged]
<spiv> malept: there's a work-around in the last comment.
<verterok> igc: yes it was ok, I plan to make a installer for Tiger...but I don't have Snow Leopard and don't think I'm going to buy it in the short or medium term (as my main desktop is Ubuntu)
<igc> verterok: cool. As long as the code for the installer is available, I'm sure someone will step up and do the Snow Leopard build.
<malept> spiv: ok, thanks for the pointer
<igc> In the worse case, I have a copy (which might work in a Parallels VM)
<verterok> igc: I'm using jfroy's package branch as with that approach was quite easy to get it working :)
<verterok> igc: also I added some infrastructure to make it compatible with all supported OS X versions ;)
<igc> verterok: sounds very promising. I'm sure we'll have a heap of OS X users take up Bazaar once Explorer can be easily installed
<jfroy|work> making a bundled version of Explorer shouldn't be terribly hard I think
<verterok> jfroy|work: bundled? like a standalone "bzr.app"?
<jfroy|work> yeah
<jfroy|work> that's what we should go for
<jfroy|work> guessing widely, either you can use a shell script doing "bzr explore" as the bundle's main executable
<verterok> jfroy|work: I have been trying to build such beast using py2app, without much success. but I have a CLI only bzr bundle working
<jfroy|work> or setup a small C program that loads up the interpreter and kicks off the command
<verterok> jfroy|work, igc: the main issue I think is some bug in python 2.5 subprcoess module that makes explorer and Qbzr unusable :(
<jfroy|work> cute
<verterok> jfroy|work, igc: I keep getting: [Errno 4] Interrupted system cal
<verterok> *call
<verterok> each time I click in any button of explorer :(
<verterok> igc, jfroy|work: I just pushed my branch, isn't finished yet but works for me (tm): lp:~verterok/+junk/OSX-package
 * verterok needs to run, bbl
<verterok> later!
<igc> bye
<poolie> igc, i'm planning to fire the announcement today
<poolie> and then... should i tweak the web site more, or leave it to you?
<igc> poolie: cool. Got KDE screenshots overnight so I'm just uploading a KDE tour now
<igc> poolie: I'm happy for you to tweak the website from here
<poolie> ok
<poolie> i think my next thing would be to either get the fonts working
<poolie> s/working/the right size
<poolie> though that might be better left to someone who knows what they're doing :)
<poolie> or to change it to be templated, so that we can add some dynamic content
<igc> templated would be good
<igc> I think we're better to leave the font tweaking to web designers myself
<igc> it's fiddly
<poolie> right
<poolie> spiv, hi?
<spiv> poolie: hey
<spiv> poolie: had a good trip home?
<poolie> yes thanks
<poolie> igc, is it really worth having totally separate tours for every environment?
<poolie> is it the same content and just different screenshots?
<igc> poolie: content is 95% the same but there are differences
<igc> poolie: people like to see programs running in their environment
<igc> and its the best way IMO to drill home the cross-platform message
<poolie> ok
<igc> poolieL I still see lots of comments on IRC like "explorer is only for Windows isn't it"
<igc> so I want to put that to bed forever
<poolie> i was wondering if one document showing multiple systems would get that across more effectively
<poolie> if people land on the windows one they might still be confused
<igc> the fist paragraph in every tour points to the others
<igc> first
<poolie> spiv is there a master bug for toomanyconcurrentrequests masking other errors?
<spiv> poolie: bug 429747 is the closest, I think.
<ubottu> Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,In progress] https://launchpad.net/bugs/429747
<poolie> how did you get along with that bug last week?
<quidnunc> If I tried an upgrade and it fails, how do I restore the original version?
<poolie> quidnunc: mv .bzr  bzr.broken; mv backup.bzr .bzr
<spiv> poolie: so the only_raises decorator appears to work well.  The test fallout from applying it to various unlock methods was pretty minimal.
<poolie> ok
<spiv> I've pushed up an update to that which adds a brief section to HACKING which tries to explain when to use it, and which exceptions to allow when using it.
<quidnunc> poolie: I get "ERROR: No repository present" after doing that (bzr log)
<poolie> k
<poolie> what else is new with you?
<poolie> what's in your .bzr now, quidnunc?
<quidnunc> poolie: branch, branch-lock checkout, backup.bzr, branch-format, README, repository.backup
<poolie> quidnunc: really? is this with an old bzr perhaps?
<poolie> anyhow it looks like you have to restore repository.backup to being just 'repository'
<quidnunc> poolie: dunno:  bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/trunk
<poolie> inside .bzr
<quidnunc> poolie: Thanks, that seemed to work
<poolie> i hope to work on making upgrade smarter soon
<spiv> poolie: https://bugs.edge.launchpad.net/bzr/+bug/437626 has me stumped
<ubottu> Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Critical,Confirmed]
<poolie> ah
<poolie> me too a bit, i've never seen that message before
<spiv> lifeless and I wrote the code with that assertion.
<idnar> so it's all you fault
<idnar> *your
<spiv> Hmm...
<idnar> ;)
<AfC> idnar: :)
<spiv> I wonder if that assertion requires a stacked target to occur, which would suggest stacked branches locally.
<poolie> so
<poolie> can you reproduce it?
<spiv> Hmm, yes, it's triggered by the target..
<spiv> No, although I wasn't trying with stacking locally.
<spiv> Although it would be a bit weird for "bzr branch" to produce a stacked branch locally.
<spiv> I mean, it's possible to make that happen, but I'd be surprised if people had actually configured that.
<spiv> I wonder if it's something like: "make shared-repo; make branch in it stacked on launchpad; make branch a new branch from launchpad".
<spiv> i.e. perhaps doing a fetch for a non-stacked branch into a repo that was previously only used for stacked branches causes this?
<poolie> oh, because it's creating effectively a situation with lots of ghosts?
<poolie> because the repo is kind of hollow underneath the other branches?
<poolie> could be
<spiv> Yeah.
<spiv> Just trying to reproduce that now.
 * spiv blinks at the *five* bzr+ssh connections bzr branch --stacked -r1000 lp:~ubuntu-core-dev/upstart/ubuntu reports.
<poolie> !
<poolie> not so hot
<mwhudson> impressive
 * igc lunch
<AfC> If an Ubuntu mirror is out of date, is there a central place to report that to?
<poolie> afc, probably, but i don't know it off hand
<poolie> maybe mirrors@ubuntu.com
<AfC> poolie: k
<poolie> sending announcement soon...
<AfC> It would really be better if the "Bazaar Explorer" thing wasn't used in the same sentence as "GNOME" on your website, as it not a (HIG compliant, GTK based) GNOME application.
<spiv> Lots of hail.
<vila_> hi all
<vila_> poolie: yeah for annoucement :)
<bialix> hello bzr 2.0
<AfC> spiv: fun tip: if you throw an appropriate base image from Terry Hills radar into the Weather Applet's Preference -> General Tab -> "Enable radar map -> Use custom address for radar map" Address field, say http://www.bom.gov.au/radar/IDR714.gif its
<AfC> spiv: automatically & always there when you pop up the weather Details dialog
<bialix> 2.0.0 is announced! Hooray! it's finally happens
<bialix> somebody, adjust topic of the channel please
<Lo-lan-do> And it should even be in testing tonight :-)
<bialix> in testing? what?
<Lo-lan-do> squeeze
<spiv> AfC: thanks!
 * bialix singing and dancing
<igc> bialix: pypi updated too btw
* igc changed the topic of #bzr to: Bazaar version control system | 2.0.0 is out! <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/
<jml> what I would like, in bzr
<jml> is a way of pulling all of my trunk branches when I come online
<spiv> jml: yeah, that would be nice
<jml> such a plugin would actually be quite simple
<jml> I mean, having a single command to do this would be quite simple.
<spiv> jml: I guess you could put a shell script in /etc/network/if-up.d/...
<jml> hmm
<spiv> There's probably a more desktop-oriented way to do the same thing that would actually run as your user.
<spiv> Presumably triggered off a dbus event.
<spiv> I know that empathy does stuff in reaction to online/offline state changes.
<igc> jml: jam wrote a update-mirrors plugin you could use as a starting point
 * igc dinner
<jml> igc, thanks.
<mrevell> Hey peoples of the Earth, if I put this in Launchpad's identi.ca stream does it make sense? "Yet more congrats to the Bazaar community! Bazaar 2.0.0 is now out! If you haven't already, try the new default repo format, 2a -- zoooooom!" I'm thinking particularly wrt the 2a format comment, obviously.
<spiv> mrevell: by "make sense" do you mean "is it accurate", or "is it appropriate"?
<mrevell> spiv: accurate
<mrevell> spiv: Happy also to take comments wrt how appropriate it is, though :)
<spiv> It seems accurate to me, but I'm not enough of a microblogging user to know if people following @launchpad would mind it or not.
<spiv> I'd possibly not mention "2a" by name, just call it the new default repo format.  I'm not sure why I say that, though :)
<spiv> I guess because users shouldn't have to care about that sort of jargon.
<mrevell> spiv: Yeah, won't mention "2a" by name. As for whether people will mind, I think it'll be fine. I tweeted/dented the new bzr website and got a thumbs up back.
<mrevell> cheers sp
<mrevell> cheers spiv
<igc> mrevell: LP users may also be interested in the "visual tours" we've put together in the last few days. See http://doc.bazaar-vcs.org/explorer/en/index.html
<mrevell> Ah, thanks igc. I was planning to blog about bzr 2.0.0 on the LP blog ... I'll mention the visual tours there too. ta.
<igc> mrevell: there's tours for GNOME, KDE, Windows and Mac OS X so that should help communities encourage casual contributors
<mrevell> ah, very cool
<spiv> mrevell: I suppose squeezing in a tiny URL to a 2.0.0 tour or release notes would be good too.
<mrevell> spiv: Yeah, good point. I guess I can lose the "zooom" :)
<spiv> mrevell: Aw, I liked the the zooom! :)
<mrevell> spiv: heh :) I've changed it to "Bazaar 2.0.0 is now out -- congrats to the bzr community! The new default format gives faster & smaller repos - zoooooom! http://is.gd/3ZZ78"
<spiv> mrevell: :)
<mrevell> Okay, cheers guys, posted.
<bialix> igc: many thanks
<ddaa> So, 2.0 is out, so when people say "bzr is much slower than hg and git", we can say "no, not anymore with 2.0".
<ddaa> Congrats for the release BTW.
<ddaa> But where are the benchmarks we can point people at so they'll at least consider it?
<ddaa> I'd love to be able to say more than just "trust me, it's fast now, yes, I know I it's the 5th time I say that"
<Kinnison> Hmm, with 2.0 out, I might consider switching to packaged bzr instead of running bzr.dev
<Kinnison> congrats guys
<Lo-lan-do> ddaa: I'm still having the feeling that the periodical repacks take too long.  But maybe my hardware is too old.
<lifeless> Lo-lan-do: are you running 2a?
<lifeless> Lo-lan-do: and are you talking local or remote?
<Lo-lan-do> I am.
<Lo-lan-do> Local.
<lifeless> Lo-lan-do: and do you have the C extensions?
<lifeless> {2a is the format, not the bzr software version}
<Lo-lan-do> Don't know.  Do the debs have them?
<lifeless> they should
<lifeless> if you have 2.0.0 it will nag if they don't
<Lo-lan-do> It doesn't seem to be complaining.
<Lo-lan-do> http://paste.debian.net/48296/
<Lo-lan-do> lifeless: Does that sound extreme to you? Maybe it's some misconfiguration on my sideâ¦
<Lo-lan-do> Hm.  A bzr pack of a similar repo only using rich-root-pack on faster hardware happens in 15 seconds.  I guess my desktop PC is to blame.
 * Lo-lan-do tries to compare with really identical repos
<lifeless> Lo-lan-do: rich-root-pack and 2a times are not comparable
<Lo-lan-do> Yeah, which is why I'm scping the 2a repo to the fast server.
<Lo-lan-do> It only has bzr 1.16.1 though.  Another skew.
<lifeless> Lo-lan-do: so, 3 minutes, how many revs?
<lifeless> Lo-lan-do: or, how big is .bzr/repository/packs
<lifeless> Lo-lan-do: and note that autopack *doesn't* do as much work as 'bzr pack'
<Lo-lan-do> 7662 revisions, 67M
<Lo-lan-do> Good to know.
<Lo-lan-do> Hm.  1.16.1 with better hardware does the bzr pack in 1m25s on modern hardware.  Better.
<Lo-lan-do> Is it expected that branching from a rich-root-pack repo into a 2a one is slow too?
<johnf> jelmer: you about?
<spiv> Lo-lan-do: yes, doing that has to convert all the data.  It's basically the same as doing "bzr upgrade".
<Lo-lan-do> I see.
<Lo-lan-do> Ah yes, 2a to 2a is indeed *much* faster.
<Lo-lan-do> I can live with that :-)
<spiv> Right, because it can simply copy most of it, rather than needing to extract and re-compress everything.
<spiv> (And extract from a slower format...)
 * Lo-lan-do waits for everyone to have a 2a-capable client
 * Lo-lan-do reads /etc/bash_completion.d/bzr.simple
<Lo-lan-do> Would it make sense to cache the results of bzr commands?
<mzz> I doubt it, for most of them
<Lo-lan-do> Er, sorry, missing quotes.
<Lo-lan-do> Would it make sense to cache the results of "bzr commands" (for completion)?
<mzz> "bzr help commands" you mean?
<Lo-lan-do> Yes
<mzz> that sounds reasonable to me
<mzz> however, plugins.
<Lo-lan-do> Yes, and upgrades and so on.
<mzz> for upgrades I'd expect just checking the mtime of the bzr executable used to suffice
<Lo-lan-do> I guess I could stat /usr/bin/bzr and expire stuff, but it doesn't handle plugins.
<mzz> but I haven't thought about that very hard :)
<mzz> for plugins you could similarly track the contents of the plugins directories, but that's not entirely trivial and may not always suffice
<Lo-lan-do> I'm thinking about a dpkg trigger that would regenerate a static file when installing/removing a bzr* package, but it wouldn't handle locally-installed stuff.
<lifeless> I would cache within a shell lifetime, I'd hesitate to cache longer than that
<lifeless> Lo-lan-do: it also wouldn't handle optional deps being added or other such things; the list of commands is turing complete
<Lo-lan-do> Yay.
<mzz> and for locally-installed plugins you'd have to recursively check if any subpackages got their files updated, iiuc.
<Lo-lan-do> Right.  I'll probably go the simple way and cache within the shell's lifetime.
<michaelforrest> I always type 'bzr commit -am "commit message"' when I'm switching between git and bzr a lot. I wish it didn't error.
<michaelforrest> (bzr: ERROR: no such option: -a)
<luks> see that git is doing to your branch? :)
<luks> meh
<luks> *brain
<luks> it's hard to NOT type branch in this channel
<mzz> michaelforrest: I rarely use git, but iirc you mean you want bzr commit to accept and ignore -a?
<luks> can't you somehow set git to use -a by default?
<michaelforrest> mzz: yeah something like that - I'd rather have git accept and ignore -a than set git to do -a by default
<michaelforrest> (for some reason...)
<michaelforrest> (maybe because I'm more likely to do incremental commits from the command line with git, whereas I'd use bzr qcommit  to do incremental commits with bzr)
<michaelforrest> maybe that's crazy though. it would probably better to change git's defaults as per luks' suggestion..
<mzz> I don't remember how difficult it is to write a bzr plugin that'd do this
<luks> pretty easy
<michaelforrest> having a go at writing a plugin...
<luks> an evil version would be http://paste.pocoo.org/show/143301/
<luks> but yes, it is crazy :)
<beuno> michaelforrest, you want to add all files and commit?
<michaelforrest> beuno: I just don't want the error when I accidentally type -am instead of -m
<michaelforrest> beuno: I will have to risk bzr suddenly adding a command -a that does something very different to what git does (please let's not let that happen ;) )
<beuno> michaelforrest, creating a plugin that adds -a and does nothing should be very close to trivial
<michaelforrest> beuno: yeah that's what I'm doing.
<michaelforrest> beuno: my plugin is called "git_cushion"
<luks> have you seen the code I pasted?
<beuno> michaelforrest, "lol"
<luks> surely it's not nice, but I'm not sure if it's worth creating a nice solution for this
<beuno> michaelforrest, let me know if you need help
<michaelforrest> luks: yeah first I tried using my brain but then I just pasted your code in and it worked :)
<michaelforrest> plugin created.
<michaelforrest> sweet.
<lifeless> bug 440631
<ubottu> Launchpad bug 440631 in bzr "mutable_tree.has_changes() should not take a parameter but always check against basis" [Medium,Fix committed] https://launchpad.net/bugs/440631
<lifeless> vila_: I find the description a little brief; perhaps paste in IRC conversations or something?
<vila_> lifeless: ouch, you're in Sydney ?
<lifeless> montreal
<vila_> haa, you scared me :)
<lifeless> as per my mail last week or so ;P
<vila_> yeah, sorry, I remember now, I'm just bad at connecting dates and mails
<vila_> ..unless I use my agenda that is :)
<vila_> lifeless: updated
<crisb> vila_: about 405745 - I thought there was no client thread in test_http_impl_urls?
<vila_> crisb: .....
<vila_> but you were talking about two threads no ?
<vila_> ooooh, waitaminute
<vila_> one main thread and one thread for the server,
<vila_> crisb: the server is blocked in select(), the main thread blocks on close() ?
<crisb> must be!
<vila_> crisb: but what is the python interpreter doing ?
<crisb> vila_: how do you mean?
<vila_> if they are only two threads python is supposed to give control to one...
<vila> now, the "dirty" part is that we are closing the socket from the main thread why the server is listening in the other thread... Does the police check such things ?
<vila> the code police I meant
 * vila don't want to trigger NSA loggers...
<crisb> vila_: well the trouble is when I invoke pdb by sending SIGQUIT it causes the server thread to exit as select() returns, so I only see the trace from the main thread
<crisb> vila_: but attaching with dbx I can see both of them hanging around
<vila> crisb: yeah, the bug don't want to be observed... Schroedinger ?
<Lo-lan-do> It's just shy.
<vila> crisb: that's unknown territory to me but are you saying that you can see the python interpreter going in circles without releasing any of the threads ?
<crisb> vila: yes its blocked on close() and select()
<vila> I can understand blocked on select(), but not on close(), anything relevant from dbx ?
<vila> wait a minute, what bzr version do you use exactly ? What code is before close() a simple shutdown(RW) or ?
<crisb> this is bzr 2.0.0
<jam> morning all
<jam> hey vila, are you around?
<vila> my right eye is writing a unit test for has_changes while my left one discuss the AIX hangs on server.close(), I'm all ears to you though :)
<crisb> vila: and its using shutdown(RWRD), but i've tried changing it to just RW
<jam> vila: just wondering about the status of https://code.edge.launchpad.net/~vila/bzr/selftest-fixes/+merge/10364
<jam> (this is the --parallel stuff you were working on)
<vila> crisb: no no, I meant a full shutdown, so both read and write
<jam> I'm trying to par the review queue down a bit, and that is "needs fixing" from Robert but "needs review" overall.
<crisb> vila: yes thats the original code
<vila> jam: yeah, interrupt level 3 or 4, I need some setup for ec2 and I want to test ec2 by installing a windows host and I want a local windows host first, which is progressing sllloooowwwllly
<vila> crisb: all right, so I don't understand why it accepts to shutdown (not blocking) but not to close...
<jam> vila: so should I mark it "Work in Progress" ?
<vila> and shutting the socket down should also unblock the select
<jam> (sorry about the interrupt levels, I've been there myself)
<vila> jam: good idea, I'll do if you don't
<jam> done
<vila> jam: thanks
<crisb> vila: yes, plus looking at netstat and lsof output, the socket is still in LISTEN state!
<Pilky> anyone know if there are any other sites for hosting open source bzr repositories besides launchpad?
<vila> crisb: so something is wrong there.. can you see the comment in TestingHTTPServerMixin.tearDown ?
<jam> Pilky: I thought Sourceforge and Savannah both would let you push code up. Certainly any sftp or ftp locations could be used.
<jam> I'm not sure how much integration they have with code browsers, etc.
<crisb> vila: yep!
<vila> crisb: it's as if your python didn't realize it uses the same socket in both threads and can't propagate the shutdown from the main thread to the server thread....
<Pilky> jam: I've used sourceforge before and it has similar issues to launchpad and savannah looks like it might be the same from first glance
<Pilky> I'm looking more for something with the simplicity and usability of github/bitbucket
<jam> Pilky: "similar issues" ?
<Pilky> usability issues
<jam> care to be more specific?
<Lo-lan-do> Pilky: fusionforge has a bzr plugin now
<Lo-lan-do> Slightly more usable than sourceforge and savannah, even :-)
<Pilky> well basically I feel launchpad shows too much on each page without good separation, overcomplicates things and is just generally not easy to navigate or administrate
<Pilky> jam: it's improved a lot over the past year or so, but it's still a long way off the likes of github and bit bucket
<Pilky> Lo-lan-do: I'll take a look
<Lo-lan-do> Doesn't do Launchpad's automated branching/tracking/merging/reviewing, but it has the advantage of being installable :-)
<Pilky> hmm, seems better, but still not quite what I'm looking for
<crisb> vila: the plot thickens! shutdown is throwing ENOTCONN :)
<Pilky> I might have to look into seeing if it's possible to design a much simpler, more usable UI for launchpad while keeping the current feature set
<vila> crisb: hmm, good, now we know why it's still listening !
<Pilky> do it as a side project and then see if the launchpad team are interested in it at all
<ddaa> Pilky: you probably should write stuff from scratch. Launchpad is massively complex because it intertwines different facets such as bugs, branches, questions, project registry, karma, etc.
<ddaa> branches can be generated in 3 different ways (code imports, mirrors, hosting), etc.
<vila> crisb: and is self.socket different from None ?
<ddaa> the reason lp UI is complex is not because lp folks don't know what they're doing, it's because it does something complex.
<crisb> vila: yes indeed
<vila> crisb: ..... so it means we can't shutdown the socket before the first connection ? Thats' silly, how can we shutdown a server then 8-/
<crisb> vila: hmm yes.  just check the fileno() in select() and shutdown() are the same
<crisb> vila: both 5, so its not like the threads havent got the same fd
<Meths> Where does bzr get its Platform string from on Windows?
<vila> crisb: I more and more feel that we may be in a dead end here because AIX implements sockets differently...
<Meths> Cool, you fixed bzr shelve on Windows with v2.0.0.  Thanks devs :)
<vila> crisb: what I'm reading from a google search with "aix socket bug shutdown select" seems to indicate that shutdown() not interrupting select() is considered a bug by many (not sure that include AIX devs though... :)
<vila> crisb: sorry I should leave, can you be there earlier tomorrow ?
<vila> crisb: otherwise just add a comment to the bug with your last experiments... :-/
<crisb> vila: sure, could we not just send the other thread a signal so select() exits?
<jam> Meths: 'import platform'
<vila> crisb: hehe, that's what shutdown is supposed to do !
<jam> Meths: "platform.platform(aliased=1)"
<jam> it is in the python standard library
<Meths> jam: thanks
<jam> I'm not 100% sure where it gets it from, but you could read the code
<jam> vila, crisb: "if sys.platform == 'aix': os.kill(other_thread, SIGHUP)" ?
<vila> jam: you can't kill a thread :-/
<vila> jam: especially when it is in a blocking call...
<jam> signal.sethandler(SIGHUP, IGNORE)
<jml> or if it's a mailing list thread.
<Lo-lan-do> Even with a Godwin point?
<jam> os.kill(os.getpid(), SIGHUP)
<Lo-lan-do> Damn, /me loses
<jam> signal.sethandler(...)
<jam> "if sys.platform == 'aik': self.knownFailure()" ?
<jam> vila: ^^
<vila> jam: I'm afraid we'll have to use that yes, but AIUI (crisb can confirm or not) that will be all http tests...
<jam> vila: can you setDaemon() those threads so that it doesn't cause python to block on shutdown?
<vila> jam: they are daemonic threads and that's why we have so many problems with thread/socket leaks
<crisb> vila: isnt it naughty to be doing things on the same socket from different threads at once anyway? maybe thats why close() hangs
<vila> jam: at least closing the server thread somehow guarantee that they will be gc'ed later, if we don't close that socket, we exhaust the threads/sockets far quicker, unless you run with --parallel=fork and workaround the problem, but you need some cores..
<vila> crisb: well, now that it fails, you can say it's naughty :-) But AIX is the first to not be happy with that :D
<jam> crisb: if you are allowed to talk to yourself via a socket, then it seems like it shouldn't be naughty
<jam> you probably shouldn't talk on the same side in both threads
<jam> I suppose it depends if it is considered 'allowed', but certainly it is used in places...
<jam> (such as our test suite :)
<crisb> :)
<vila> jam, crisb: the clean way to resolve that will be to have a boolean ste to stop the server and explicitely connect once with a client that explicitly close its socket...
<crisb> is it just python that wont let you kill threads?  i've used pthread_kill with SIGUSR1 as a way of unblocking other thread before
<vila> crisb: yup, it's python
<jam> crisb: looking here: http://docs.python.org/library/threading.html#thread-objects
<jam> it looks like we have start/run/join, but no kill
<vila> crisb: as jam said :-D
<jam> http://www.velocityreviews.com/forums/t330554-kill-a-thread-in-python.html
<jam> Interesting method
<jam> basically hijacks the system 'trace' functionality to check at every line of execution if the thread should exit
<jam> doesn't sound like it would help with select/shutdown, though.
<vila> jam: indeed :-/
<vila> but I think having the server loop check a boolean and replacing shutdown() by stop = True, connect(server.address) close() server.close() may work, I'll try that tomorrow
<jam> vila: enjoy your evening
<jam> do you have AIX to check?
<vila> we don't care if neither the client nor the server understand what that last connection is about...
<vila> jam: hehe no
<vila> crisb: I don't think you can provide a VirtualBox VM with an AIX installed don't you ?
 * vila really wants to trigger NSA or IBM lawyers here :)
<kennethd> from launchpad, it looks like `bzr branch lp:mailman/2.2` should get me mailman's source, but it tells me: "ERROR: Not a branch: /home/kenneth/src/lp:mailman/2.2/"
<LarstiQ> kennethd: what version of bzr are you using?
<kennethd> 0.11.0 (from debian etch)
<kennethd> is it too old for that format url?  is there another format url i can use?
<LarstiQ> 0.11 is way way ancient
<LarstiQ> kennethd: yes there is, but then your client likely doesn't understand the repository format used
<kennethd> well, it is debian etch :)
<LarstiQ> kennethd: so I'd recommend to upgrade bzr to something released this decade first ;P
<LarstiQ> kennethd: you could try backports.org, or just install bzr by hand (you can run it from the unpacked tarball, do run make though)
<Pilky> ddaa: true, I'll probably have to look into it at some point down the line, got enough stuff on my plate at the moment development wise
<kennethd> LarstiQ: got 1.5 from the tarball, thanks
<LarstiQ> 1.5?
<LarstiQ> kennethd: that's a bit of a weird version choice?
<Tak> note to self: never try to dpush a branch with multiple revisions
<kennethd> oh, i didn't notice there's a 1.16 there too ... well, it is downloading mailman at least
<jam> kennethd: and a 1.17, 1.18, and now 2.0.0...
<LarstiQ> kennethd: yeah, 1.15 (1.5 too) should work well enough for that
<kennethd> jam: oh, well i got the source from backports.org
<LarstiQ> backports.org needs a packaging update
<LarstiQ> jelmer: in case you have time, ^^?
<jam> Lo-lan-do: did you see my review of your earlier patch?
<jam> https://code.edge.launchpad.net/~jameinel/bzr/lolando-branch-root/+merge/12740
<jam> I tried to send you the emails directly
<Lo-lan-do> jam: Yes, I was just busy.  Will try to address your concerns sometime this week.
<jam> Lo-lan-do: no problem, just cleaning out the review tracker a bit and that reminded me
<lifeless> jam: lp merge re views update now
<lifeless> so I don't think you need to resubmit stuff anymore
<jam> lifeless: well, I also wanted to poke people to remind them that it needed reviewing, I could probably have done that a different way
<jam> lifeless: did I hear correctly that you are in Canada now?
<jam> (well, "this week" not specifically a move)
<lifeless> this week
<lifeless> yes
<lifeless> Montreal
<lifeless> jam: I'd remind people by mailing the list ;)
<jam> lifeless: asking for a code review mails the list, too...
<lifeless> jam: yes, but discards the old thread
<lifeless> which is something I find annoying ;)
<jam> well, for most I just asked for code review from 'bzr-core'
<jam> that one I probably should have just done the same
<jam> I don't remember specifically why I thought it was necessary
<lifeless> :)
<dwt> Hi there, I'm currently looking at the 2.0 release and I can't seem to be able to penetrate the nomenclature around it. For example, what is a rich-root repository format - and where could I look up stuff like this? (google seems unwilling to help...)
<Pilky> dwt: I believe rich-root is mostly for use with subversion integration
<Lo-lan-do> It was introduced for that, but it's been generalised since then.
<mzz> the new default repository format (2a) supports rich-root
<dwt> thanks for the answers - is there a way to get deeper information on what this means?
<dwt> from what I've found it means the repository supports more metadata
<mzz> I'd say "look at "bzr help formats" but it is unfortunately a bit stale in 2.0
<mzz> afaik what it says about rich-root is correct, but it doesn't realise "some appropriate time in the future" has arrived
 * dwt is reading bzr help formats
<Peng_> Rich root formats give the root directory a file ID, just like every other directory.
<dwt> Peng: Thanks!
<jfroy|work> Is there API to run a specific command in bzrlib, or should I just allocate the command class and call its run method?
<jam> jfroy|work: depends what you want, but there is "run_bzr()"
<jfroy|work> bascially run a sequence of bzr commands w/o launching individual bzr processes (to avoid the cost of launching the interpreter and all)
<jelmer> jfroy|work: hi
<jelmer> ehm, sorry
<jfroy|work> eh, hi :)
<jelmer> jfroy|work: I was actually looking for johnf, but it seems he disappeared
<Tak> jfroy|work: there's builtins...
<jfroy|work> verterok: http://home.devklog.net/~bahamut/bzrexplorer.app.zip
<jfroy|work> I consider it crude :p
<Pilky> jfroy|work: that link doesn't work
<jfroy|work> doh
<jfroy|work> ok, let's try this again
<jfroy|work> http://home.devklog.net/~bahamut/BazaarExplorer.app.zip
<jfroy|work> ok that works
<jfroy|work> Hacked up a quick bundle for explorer :|
<jfroy|work> Kind Of Worksâ¢
<verterok> jfroy|work: cool, using py2app?
<jfroy|work> manually :p
<Pilky> ah, thought it was going to be everything bundled up into one thing
<verterok> jfroy|work: oh, I need to learn that :)
<jfroy|work> well using Build Applet from the dev tools, then fixing it up
<Pilky> so I didn't have to fight with all the QT stuff that doesn't want to install on my machine
<jfroy|work> right, this only launches a user-installed explorer
<jfroy|work> still need to bundle the rest with this
<jfroy|work> Qt & etc.
<jfroy|work> so it's not anywhere near done.
<jfroy|work> just more convenient than running it from a terminal :p
<Pilky> heh
<Pilky> I might package up BazaarX this week, not had a crash since I refactored so it might be good enough to call 0.1
<Pilky> and also start work on 0.2
<dwt> any screenshots yet?
<Pilky> dwt: http://dropbox.mcubedsw.com/skitchpics/BazaarX%200.1.png
<dwt> thanks!
<dwt> Looks nice so far - I'm looking forward to try it. :)
<Pilky> only does add, commit and remove, but that's 90% of what most people do
<Pilky> hoping to add move and possibly log in 0.2
<crisb> jam: vila's suggestion about the AIX select()/ close() hang has worked :)
<verterok> Pilky: I builded a PyQt installer for 10.5, but requires Qt installed (hopefully I'll upload it tonight)
<Pilky> verterok: that would be useful if it also works for 10.6
<Pilky> Qt installed fine, PyQT wouldn't install for some reason, kept complaining about QT's structure not being able to be verified
<verterok> Pilky: I don't have 10.6 :(
<Pilky> well, if it works with Python 2.6 I'd assume it would work fine with 10.6
<verterok> Pilky: it depends on the system python...so it's a problem across all versions (10.4, 5 and 6) ;/
<verterok> Pilky: the OS X python ins't the same as the python.org python, I can try to build it to get some feedback  :)
<Pilky> sure
<Pilky> jfroy|work: probably knows the internals better than me given that he did the 10.6 bzr installer
<vila> crisb: passing around, what did you implement ? Which tests are passing ?
<crisb> vila: the fake connect to get the select out and setting the boolean :)
<crisb> vila: all tests from  bzr selftest -s bt.test_http -v now pass
<vila> \o/
<vila> \o/
<crisb> vila: more details in 405745
<vila> crisb: Congrats !!!
<vila> bug #405745, ubottu, url please
<ubottu> Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,Confirmed] https://launchpad.net/bugs/405745
<vila> good bot
<vila> crisb: excellent, can you publish a branch with your patch ?
<crisb> vila: sure - do you know why its saying that one test is leaking threads? is that relevant at all?
<crisb> vila: never mind, just tried it here on linux and its the same without the patch
<vila> crisb: because the threads spawned by the server for the client connections are daemonic ones as well as the server thread itself,
<vila> your patch un-hang it, but we didn't join()ed it, the gc will, later, get it back
<vila> crisb: your patch address the root problem I had here. On top of it, I can now 1) collect the client threads, 2) close them properly and join them, 3) join the server thread......... 5) profit
<vila> ... and get rid of the leaking tests, because if your patch works for http, it will also work for ftp so we will get rid of some other leaking tests there
<crisb> vila: bonus!
<vila> crisb: and *that* in turn, will allow the full test suite to pass again on OSX and gentoo and maybe even make some more progress on windows *without* resorting to the --parallel=fork trick
<vila> crisb: so those three lines are really worth their bits on gold :-D
<vila> aaaargh s/on/in/
<vila> . o 0 (Once again the typo-gremlin attacked the joke)
<crisb> vila: where's my cheque then ;)
<vila> Please receive my gratitude and enjoy our full test suite in all its glory :-D
<crisb> virtue is its own reward eh :)
<poolie> hello vila
<kenichi> what's the easiest way to see when a branch was branched?
<beuno> kenichi, I don't think there's a good way of doing that
<kenichi> beuno: i'm thinking of svn's --stop-on-copy type thing... nothing?
<beuno> kenichi, I have no idea what that does
<beuno> what information are you looking for?
<poolie> hi beuno
<beuno> a date, or a revision?
<beuno> hey poolie!
<poolie> kenichi: you can look at the branch nick in the log
<poolie> there's no option to cut off the log at the point where it changed but that would be kind of useful
<kenichi> poolie, beuno: thanks.  i can see in the log where the nick switches... but i have to hunt.  hmmm...
<igc> morning all
<poolie> hi igc
#bzr 2009-10-07
<maxb> I've produced a fast-import file with cvs2bzr, and "bzr fast-import"ed it, and some branches appear to be missing!
<maxb> Is there anything obvious I should look at?
<spiv> igc: ^
<igc> maxb: bzr fast-import only generates branches for 'heads' in the final revision graph. Maybe some branches are now similar tags on trunk?
<igc> simply
<maxb> hmm
<maxb> It's a cvs2bzr conversion, so in theory branches should only branch, never merge
<maxb> It's possibly there might be a trunk revision which is tree-wise identical in this case, though?
<maxb> Is there any way I can dump all the revisions in a *repository*, to grep for the commit messages on the missing branch?
<igc> maxb: maybe some branches were made from trunk and never received any changes after creation?
<maxb> I can see a commit on the branch in the fast-import stream
<igc> maxb: qlog lets you browse a repo and search within it
<maxb> an entire repo? I thought it took branches
<igc> log will only take a branch; qlog is smarter than that
<maxb> I apologize, it appears my missing branch got merged by a tag in an unexpected way
<igc> maxb: maybe we need to improve the feedback fast-import gives?
<igc> maxb: could you raise a bug if there's a problem or we could do better?
<maxb> would be nice - it's a little scary when a branch name you know should exist, doesn't
<igc> maxb: I'll be online now for a hour or two so a bug report is the best way to get things improved
<igc> max: if nothing else, maybe we need an FAQ or better doc
 * igc bbl - out for a bit
<maxb> Perhaps it should say something like "Branch A is wholly merged into branch B - not writing an active branch"
<igc> back
<poolie1> igc, hi, does bug 430179 still need fixing in bzr itself?
<ubottu> Launchpad bug 430179 in bzr "windows 2.0rc2 installer has a "Bazaar Explorer" shortcut on the desktop that does nothing" [Critical,Confirmed] https://launchpad.net/bugs/430179
<igc> I don't believe so. The installer is a separate project now
<igc> poolie1: ^^^
<poolie1> thanks
<igc> poolie1: bbiab - need to pick up kids from school
<poolie1> spiv, how are you today?
<spiv_> poolie1: good, fixing https://bugs.edge.launchpad.net/bzr/+bug/389413
<ubottu> Launchpad bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [High,In progress]
<spiv> poolie1: I'm thinking it might be nice to have a debug flag that mutters whenever a tree, branch or repository object acquires a lock, releases a lock, and acquires it again.
<poolie1> to tell you they should have just held it the whole time?
<poolie1> that could be good
<spiv> Right.
<poolie1> what happened on bug 437626 btw?
<ubottu> Launchpad bug 437626 in bzr "exceptions.AssertionError: second push failed to complete a fetch set" [Critical,Confirmed] https://launchpad.net/bugs/437626
<spiv> All I know is in the bug comments: basically, I'm still stumped.  We really need a way to reproduce it.
<spiv> No random combinations of fetching stacked and unstacked branches into a shared repo triggered it for me, and none of the commands that crashed for the various affected users crash for em.
<garyvdm> Hi all.
<garyvdm> Do the new windows installers come with a ssh agent, or do I need to install one?
<poolie1> ok
<poolie1> i asked if it's reproducible and if so to give us a tarball
<poolie1> garyvdm: i'm not sure but i think they don't
<naoki> Hi, all.
<poolie1> hello
<naoki> My company is going to start using bazaar now.
<naoki> repository layout is: /home/bzr/repos/<shared-repo-name>/<branch-name>
<naoki> We want to backup this repos.
<naoki> And I don't want to use rsync, because rsync copies even if repo is broken.
<igc> hi garyvdm
<garyvdm> Hi igc
<naoki> Is there easy backup way based on "bzr pull"?
<igc> naoki: is the repo-push plugin the sort of thing you're after?
<naoki> https://launchpad.net/bzr-repo-push
<naoki> good!
<igc> naoki: I haven't used it myself but it sounds a good match
<naoki> I'll try it.
<poolie1> hi igc
<igc> hi poolie1
<igc> poolie1: http://bazaar-vcs.org/Roadmap?action=diff
<igc> I like the last line :-)
<poolie1> :)
<poolie1> so igc, what are you working on this week?
<igc> poolie1: until yesterday, doc and website polish
<igc> today I need to fix the keywords plugin to use that hook we added for it
<poolie1> hm
<igc> right now, I'm grabbing a branch of lp so I can test my faster-log-file patch on that as jam/you requested
<poolie> i think i'd prefer if you could work on some core bugs first
<igc> in summary, clearning backlog
<igc> poolie: sure. fire away
<poolie> maybe bug 441126
<ubottu> Launchpad bug 441126 in xsplash "No xsplash on boot (shutdown works fine)" [Undecided,Invalid] https://launchpad.net/bugs/441126
<poolie> no, bug 441125
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [Critical,Confirmed] https://launchpad.net/bugs/441125
<garyvdm> It seems the windows installer comes with paramiko, but I'm not sure how to point it to my private key.
<naoki> Do you using pageant?
<garyvdm> naoki: I was not. I thought paramiko was an agent. I am now, and it's working.
<naoki> I use paramiko with pageant always. But I think paramiko can work with $HOME/.ssh/config.
<naoki> Host hostname
<naoki>     IdentityFile  path_to_identity_file
<naoki> Hmm, I'm sorry. I tried it but I can't.
<poolie> garyvdm: i don't think paramiko is an agent
<poolie> it can be a client of pageant
<poolie> spiv could i persuade you to put bug numbers in your branches?
<spiv> poolie: in the branch names?  Sure.
<poolie> yes
<vila> hi all
<poolie> hello vila
<igc> hi vila
<igc> poolie: I'm having trouble reproducing bug 441125
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [Critical,Confirmed] https://launchpad.net/bugs/441125
<igc> I can't run 'bzr reconcile remote-url' because it's read-only to me
<igc> if I branch locally and run reconcile, it works fine
<igc> can I grab the branch as a set of files somehow?
<spiv> igc: grab them via SFTP?
<spiv> lftp should be able to recursively fetch the .bzr directory.
<poolie> good idea
<poolie> it does seem to have been hit a few times
<poolie> in that there were a few dupes
<igc> poolie: right. All are are reported by scott on upstart branches though so it's possibly the same data(?) problem
<igc> s/are/three/
<poolie> true
<poolie> i don't know why he sent three reports
<igc> different files in different branches
<poolie> was he just mad about the error, or just being cautious in deduping?
<poolie> probably the second
<spiv> I'd guess the second.
<igc> me too
<poolie> ok, good night...
<vila> good night poolie
<spiv> poolie: good night
<RenatoSilva> Is there a way to 'extrac' a committed merge, as it was not a merge but a single commit?
<bialix> hello all
<vila> RenatoSilva: bzr diff -c<revno> ?
<vila> hi bialix
<bialix> bonjour vila :-)
<RenatoSilva> vila: sorry?
<RenatoSilva> vila: how to apply the diff
<bialix> bzr patch
<RenatoSilva> vila: and how to remove merge meta-info
<vila> bzr merge -c<revno> ; bzr revert --pending-merges ?
<RenatoSilva> bialix: if I bzr uncommit, when I commit again it'll know it's a merge
<vila> what's wrong with that merge ?
<RenatoSilva> vila: bzr merge? it's already emrged!
<RenatoSilva> vila: I didn't say something's worng with the merge :)
<bialix> sorry RenatoSilva, I've wedged to your conversaton without realizing context
<vila> RenatoSilva: no, you didn't say, but somehow, I was under the impression you wanted to nuke it :)
<vila> bzr uncommit ; bzr revert --pending-merges ?
<vila> bzr st
<RenatoSilva> the actual problem was that I did a bzr send at work, to bzr pull + push at home. But before this last I pushed new revisions in trunk, so I had to use bzr mergel rather than bzr pull
<vila> RenatoSilva: try issuing 'bzr st' before and between all commands to see what happen
<RenatoSilva> what's st?
<vila> bzr status
<RenatoSilva> ok, will --pending-merges keep the file changes though?
<vila> RenatoSilva: yes, experiment in a side branch if you prefer
<RenatoSilva> ok brb
<vila> RenatoSilva: oops, --forget-merges not --pending-mergees
<vila> RenatoSilva: 'bzr help revert' for more
<RenatoSilva> ok just saw it
<RenatoSilva> vila: workred fine \o/ love you! haha
<RenatoSilva> vila: thank you!
<vila> RenatoSilva: Always happy to help (TM) :D
<RenatoSilva> bialix: I wanted to know bzr patch anyway, thanks
<RenatoSilva> how to run a diff between two branches?
<RenatoSilva> or between last revs from each one
<Lo-lan-do> bzr diff $branch1Â --new $branch2
<vila> RenatoSilva: bzr diff --old <other-branch> or bzr diff --new <other-branch>
<RenatoSilva> ok
<vila> RenatoSilva: for more details: 'bzr help diff' :-D
<RenatoSilva> I'm not getting a normal result
 * igc dinner
<RenatoSilva> ok got it working now
<RenatoSilva> thanks!
<johnf> jelmer, lifeless: you about?
<lifeless> moin
<kevinbsmith> Greetings all. I'm trying to find details about bzr repo security features, like how hard it would be for an attacker to modify without being detected. I can't find any information on the bzr web site or in the FAQ. Can anyone point me to docs/articles about that?
<Lo-lan-do> kevinbsmith: You can add GPG signatures to revisions.
<visik7> what happen if I checkout a bzr repo inside another bzr tree ?
<kevinbsmith> Lo-lan-do: yes, but from what I have read, it allows any valid sig, not only from a list of approved committers
<kevinbsmith> Lo-lan-do: also, i would have thought that the sha1 revids would provide automatic protection against corruption
<Lo-lan-do> kevinbsmith: I believe you could set a value for gpg_signing_command that would only trust one specific keyring.
<kevinbsmith> Lo-lan-do: I haven't seen complete docs on the gpg_signing_command either, but mostly I would like to see a description of the built-in uses of sha1 digests
<jderose> kevinbsmith: sha1 (or equiv.) checksum provide integrity checks, but can't prevent against tampering
<kevinbsmith> jderose: My hope would be that if anyone modified existing code or an old commit, the sha1 would mismatch and the repo would be declared corrupted
<Lo-lan-do> There's "bzr check" for that.
<jderose> kevinbsmith: as for the bzr sha1, see `bzr help testament`
<kevinbsmith> jderose: and that if someone added a new file, commit, or revision, it would either be ignored by our build process (because it wouldn't be on the trunk) or would quickly be detected as new code by any developer who did a sync
<Tak> is there a reason bazaar explorer opens a console window?
<jderose> kevinbsmith: yes, but an attacker can just modify the sha1sum also.... with a signature, key would need access to the private key to forge it
<kevinbsmith> jderose: ok, so what I would love to see is a one-page explanation of what security features are built into bzr (sha1, check), and what is available (gpg, testament).
<jderose> kevinbsmith: but i'm glad you are bringing this up as it's a feature i want in bzr also, to use as you're thinking: so a build process can authenticate the author(s).  ;)
<kevinbsmith> jderose: I *think* it's secure enough, but my opinion doesn't matter, and honestly yours isn't of much help when I try to communicate with other team members about their concerns
<jderose> kevinbsmith: bzr already has revision hashes and revision signing.  but as far as i know it doesn't have any built-in way to check these signatures.
<kevinbsmith> jderose: even full docs about gpg signing would be helpful
<jderose> kevinbsmith: the information is there, you just might need a little glue on your build server.  can anyone else comment on this?  last i knew there still wasn't anything like `bzr verify`
<kevinbsmith> There used to be a page on the bazaar wiki about security...but it's gone now :(
<kevinbsmith> The ideal would be a point-by-point response to this paper: http://www.dwheeler.com/essays/scm-security.html
<jderose> kevinbsmith: the revision signing is easy: in ~/.bazaar/bazaar.conf,  just add "create_signatures = always"
<jderose> like:
<jderose> [DEFAULT]
<kevinbsmith> (like the Aegis folks did, linked to at the very bottom)
<jderose> # Other stuff you might have...
<jderose> create_signatures = always
<kevinbsmith> but that only requires any valid sig, not a sig from a known team member (as far as I can tell)
<jderose> kevinbsmith: then when you `bzr commit`, it will automatically sign the revision (so using some kind of agent is helpfull)
<kevinbsmith> so we would have to somehow go back and scan for unknown signers
<jderose> kevinbsmith: like i said, bzr doesn't itself check the signatures... your build process will have to do that and you will have to provide it a list key keys from which signatures are accepted
<jderose> kevinbsmith: its not do hard using the bzrlib API to scan through the list of signatures for all the revisions in a branch
<kevinbsmith> i would still love to hear that sha1 would give us 90+% of the protection we actually want/need
<jderose> kevinbsmith: i'd like to hear that i won the lottery.  ;)
<jderose> all the sha1 can do is assert to the integrity of the repository, not the authors of the revisions
<kevinbsmith> jderose: heh. but seriously, a little documentation about such a key part of the data format doesn't seem too much to ask. Even two sentences would help
<kevinbsmith> jderose: right, but detecting unexpected changes would go a long way for us
<kevinbsmith> jderose: and just knowing that the repo hasn't been tampered with would be a really good start
<kevinbsmith> jderose: I think I'll file a bug against the docs
<jderose> kevinbsmith: but how would you know a change was unexpected?  someone besides your trusted commiters could insert malicious revisions with perfectly good sha1sums.
<jderose> yeah, more is needed in the docs
<kevinbsmith> jderose: but they would show up as a new commit, and i code review all commits
<kevinbsmith> jderose: and there are only 2 of us, so I know what work is being done at all times
<jderose> but the commands to look at are `bzr sign-my-commits` and `bzr testament`
<jderose> and the "create_signatures = always" config variable
<jderose> kevinbsmith: well, i guess they'll show up as new commits either way.... if you are reviewing all the commits and just want a way to make sure nothing slips by, using branches can accomplish what you want:
<jderose> bzr uses a hierarchical history (one of its best features, IHMO).
<kevinbsmith> jderose: but so far I have no evidence that if an attacker modified files directly in the repo that the corruption would automatically be detected
<jderose> so when you `cd my_branch; bzr merge ../other_branch` for example, first it will just change the working tree... nothing is commit yet
<jderose> is the repo something you control physically? if not, you need signatures, otherwise there is no way to know it wasn't changed (unless you store the past revision checksums in some trusted place to compare)
<jderose> so i guess my final advice is: i don't think bazaar has a verification command yet, but i can create the signatures easily and you can create a verification command yourself without too much work
<jderose> kevinbsmith: just put "create_signatures = always" in your bazaar.conf in the [DEFAULT] section
<jderose> kevinbsmith: unless maybe i'm still not quite getting what you're after.  ;)
<kevinbsmith> jderose: i still think bzr has/does what we need, but really need a statement from one of the authors to that effect. And I need to know under what circumstances an attack would automatically be detected, or what commands to run when in order to manually detect a problem.
<kevinbsmith> jderose: I appreciate your answers
<jderose> lifeless:  does bzr have a command yet to verify revision signatures?
<pickscrape> Hi, can anyone point me at documentation on how to package a bzr plugin for ubuntu/debian?
<jderose> pickscrape: i would look at one of the existing packaged plugins, like bzr-builddeb
<jderose> kevinbsmith: np. hope you find the solution you're looking for.
<pickscrape> Hi, can anyone point me at some documentation on packaging a bzr plugin for ubuntu/debian?
<jderose> pickscrape: i think you dropped before getting my reply: (07:21:46 AM) jderose: pickscrape: i would look at one of the existing packaged plugins, like bzr-builddeb
<pickscrape> jderose: aha, I didn't see my original message go through, hence me restarting my client and reposting :) Thanks for replying again.
<jderose> np.  in my experience, following the example of a similar package is usually the best way to start a debian/ubuntu package
<pickscrape> I tried that with bzr-svn but didn't see anything in the source about actually packaging the plugin. I'll have a look at bzr-builddeb and see what I can pick out.
<gioele> hello
<kevinbsmith> jderose: I just created launchpad bzr bugs 445434 and 445428 requesting better docs
<ubottu> Launchpad bug 445434 in bzr "Documentation should have more details about gpg signing" [Undecided,New] https://launchpad.net/bugs/445434
<ubottu> Launchpad bug 445428 in bzr "Documentation should describe protection against repository corruption" [Undecided,New] https://launchpad.net/bugs/445428
<jderose> pickscrape: do you mean packaging at the Python distutils/setuptools level, or the Debian level?
<pickscrape> jderose: I want to create a .deb of a bzr plugin.
<jderose> pickscrape: have you done any Debian/Ubuntu packaging before?
<pickscrape> jderose: I haven't... I've looked around a bit and currently feel like someone who can't swim very well being told to jump into the deep end of the pool :)
<jderose> well, the first step is a large one.  using bzr-builddeb as an example, you pretty much just create a debian/ directory like it has, but with some details changed to fit your package.
<jderose> pickscrape: so next question, have you done any python distutils/setuptools packaging?
<pickscrape> No, the closest I've ever been to was some gentoo ebuilds. I've never done any binary packaging before.
<gioele> are there compiled .deb or PPAs for Dulwich (needed by bzr-git)?
<jderose> pickscrape: for any Python stuff, packaging first using distutils is a good idea because it allows anyone to install it if they have Python (which they need anyway).  see http://docs.python.org/distutils/index.html
<pickscrape> Ah, that's what produces eggs right?
<jderose> pickscrape: for the Debian package, you're pretty much putting some extra meta-data in debian/ and telling it to call your setup.py script
<jderose> pickscrape: yes, and it also can build, install, and make release tarballs for your Python package
<pickscrape> jderose: thanks a lot for your pointers, much appreciated.
<jam> morning lifeless and vila
<vila> morning jam !
<pickscrape> jderose: I do have one more question though... Do the installers target a specific python version or are they able to install to whatever version is installed on the machine being installed to?
<jderose> pickscrape: normally they will install under what ever version of Python you run setup.py under
<jderose> you can pick the system default with "#!/usr/bin/env python"
<pickscrape> If they install to whatever version of python is installed, then that is ideal. We have people running anything from 2.4-2.6 and I'd rather not have to package for each individually :)
<pickscrape> jderose: thanks again for your help.
<jderose> np.
<awilkins> jelmer: How's bzr-svn at detecting SVN merges?
<awilkins> I'm really missing that "copy" feature that bzr lacks now.... copied some large files so I could copy a new released version of them in the SVN tree.. I'm guessing that's part of the large download I'm seeing and the rest is probably because the merge I did is being taken as a plain commit.
<jam> awilkins: from what jelmer has said before, merges in svn are generally 'cherrypicks' and so they aren't represented in bzr-svn
<jam> since bzr itself doesn't do a lot with a cherrypick
<awilkins> jam: Yes... I thought SVN had improved this and had some merge properties now. I shall take a squizz at the properties on the relevant revision
<jam> awilkins: they *do* have an 'svn:merge' property
<jam> which has stuff like "merged: 200-210,212,214,218-300"
<jam> however
<jam> 1) I don't think it applies to the whole tree underneath that point
<awilkins> Not necessarily
<jam> 2) It easily allows non-contiguous ranges, which means that in bzr they would look like a cherrypick
<awilkins> Yes, I think it could work for a subset of cases
<awilkins> I think mine is probably one of the ones that could work, but I appreciate the problem
<jam> awilkins: anyway, AFAIK bzr-svn ignores the values because of the problems
<awilkins> I wish now I'd done the merge locally
<jam> jelmer would have to give details
<awilkins> And pushed it up to the server... was trying to save their repo space by copying some large text resources that have some differences between versions.
<awilkins> I should just make the damn build process more sophisticated and get different versions of the resources by manipulating the VCS
<awilkins> But they are all using SVN (in a contracted CollabNet server, no less), and I'm the maverick using bzr
<CaMason> hi guys. I just did bzr shelve, followed by bzr unshelve, and I've got an error saying "The file id xxx is not present in the tree"
<CaMason> I've got a number of changes that were shelved and I need to get them back :'(
<vila> CaMason: 'bzr version' says ?
<CaMason> 1.13.1
<vila> hmpf, shelve was still part of bzrtools then ?
<CaMason> I have no idea :o
<vila> bzr help shelve
<CaMason> says nothign about 'tools'
<vila> ok, so it was already part of bzr core
<vila> CaMason: I'm pretty sure that has been fixed in 2.0
<vila> CaMason: what os/version are you using ?
<CaMason> This is Ubuntu 9.04. This was installed via apt
<vila> CaMason: https://launchpad.net/bzr  look at https://launchpad.net/~bzr/+archive and follow the instructions to update your package sources
<CaMason> will this help me get back my changes?
<vila> CaMason: it should allow you to use 'bzr unshelve' and get back your changes yes
<CaMason> ok good :)
<vila> CaMason: I'm 90% confident...
<CaMason> ok, updates appearing in my update manager. Installing
<jelmer> awilkins: jam's comments are correct
<jelmer> awilkins: svn only has a notion of cherrypick merges
<jelmer> awilkins: even if you do a 'full' merge it's stored as a series of cerrypicks
<awilkins> jelmer: Bah. How's the rename support... I know that it can't assume that copied + deleted is a rename (from the SVN > BZR direction) but does bzr-svn manage to translate it's renames into copy + delete from BZR > SVN - It's trying to upload an awful lot of data for just "this node is now this node and this one is dead".
<CraigMason> had a random BSOD :o
<awilkins> jelmer: I tried to work it out from reading the code... then tried to do a quick test... ran into the "older libraries" thing, and a minor bug in URL parsing (merge later)
<awilkins> jelmer: Ok, confirmed it does the copy+delete thing properly
<awilkins> jelmer: Still doesn't explain to me why it uploads 10s of MB when I rename a few large text files ( multi-MB text files)
<awilkins> Hang on, it's not a bug in the bandwidth bar is it?
<awilkins> There's no way it's hitting the speeds it says it is, or that it's uploaded 750MB in less than 2 mins
 * awilkins lets upload finish and checks server log, which is correct *phew*
<Tak> shouldn't rebase have a --force option?
<NET||abuse> hmm, trying to push back up from a branch on an eeepc to a bigger laptop.  the ip of big laptop was x.x.x.26   but i switched it over to a new ip int he network,, how do i overwrite the :parent address?
<NET||abuse> my push line is bzr push --remember :parent
<NET||abuse> so i need to reset :parent to the new address.
<jelmer> tak: what would --force do?
<Tak> allow you to rebase when you have local changes
<Tak> ala merge --force
<Lo-lan-do> NET||abuse: bzr pull --remember $newaddress
<jelmer> Tak: rebase works in the local working tree
<jelmer> tak: so it would have to back that up somewhere
<Tak> hmm
<Tak> shelve/unshelve?
<jelmer> Tak: yeah, I guess it could do that under the covers
<NET||abuse> Lo-lan-do, ahhh, very smart,,, I actually had just altered my .bzr/branch/branch.conf file.
<NET||abuse> or whatever that conf file is called.
<NET||abuse> thanks though..
<NET||abuse> good to know alternate wya.
<Lo-lan-do> I'd like to see a command-line interface to set/unset/modify the "related branches" settings though.
<NET||abuse> Lo-lan-do, yeh, i was thinking there was nothing coming up in the command line reference about those types of methods.
<NET||abuse> aliases serve the function of giving you locations to name, but just hte defaults are set and not alterable without transaction it seems.
<Lo-lan-do> Yes.
<beuno> jelmer, hi. Are you OK if I upgrade bzr-stats to 2a?
<james_w> cgit isn't very pleasant to use
<james_w> better than some, and quick, but less productive overall IME
<jelmer> beuno: yeah, go ahead
<jelmer> beuno: and thanks :-)
<beuno> jelmer, thanks. I'm playing around with it so you can see only mainline commit counts, or second, third, fourth level, etc
<beuno> (second level is to get around PQM hogging all the commits)
<jelmer> beuno: ah
<beuno> abentley, how do you feel about upgrading hitchhiker?  :)
 * beuno wants his shared repo with bzr stuff again
<vila> beuno: You should definitely play a bit with qlog to see some nice graphs
<beuno> vila, I should give it another go, for sure
<abentley> beuno: upgrade how?
<beuno> abentley, to 2a
<kfogel> abentley: is there any bzr access method that is resumable?  (I.e., picks up where it left off?)
<abentley> kfogel: No.
<kfogel> abentley: thank you.
<abentley> kfogel: Did you see jam's message where he suggested doing smaller pulls instead?
<kfogel> abentley: this is in the getting launchpad thread?
<jam> abentley: I think it was just a direct email and not on a mailing list
<kfogel> abentley: I'm in "Running rocketfuel-setup and getting launchpad" on launchpad-dev@.
<jam> kfogel: I'll forward it to you
<kfogel> jam: thank you.
<jam> kfogel: sent
<kfogel> jam: excellent, thx.
<abentley> beuno: I'll think about it.  It's sometimes used as a recovery tool, so backwards-compatibility might be more important.
<abentley> beuno: You can certainly pull it into a 2a repository, even before I switch.
<beuno> abentley, it seems to be no-rr
<abentley> beuno: You mean it won't convert on the fly?
<beuno> abentley, yeap, bzr gets angry when you try to branch a non-rr into a rr shared repo
<jam> beuno: it shouldn't
<jam> I do it on the windows host
<jam> build host
<jam> it gets angry the *other* way
<jam> rr => non_rr shared repo
 * beuno checks his setup
<jam> now, you can't contribute patches from your rr repo back to the non-rr project
<beuno> AH
<beuno> you're right
<beuno> my previous setup did not work
<beuno> so, ignore me then
<alchemist__> I am seeking some advice on how to set permissions on a linux shared repository host so that everyone can read the repo - only certain users can merge to trunk - and other users can only merge to branches - is there any documentation on this?
<kfogel> jam: your mail is great, I'm quoting it in a reply, but wondering why you didn't just follow up to all with it in the first place?
<jam> kfogel: I did, everyone didn't include the list
<jam> kiko sent it to me and aaron specifically
<kfogel> jam: ah
<kiko> kfogel, I'm confusing that way sometimes
<jam> I'm not on LP-dev anyway
<jam> and it would have been bounced
<kfogel> jam: np
<kfogel> kiko: s'okay, I can just be Human Mail Relay
<luke-jr_> jelmer: bzr-svn refuses to branch now :(
<luke-jr_> after I sanitized the Svn layout
<luke-jr_> nm, found a config thing I didn't update
<Oli``> How do I rollback one file?
<vila> Oli``: 'bzr alias rollback=revert' and 'bzr rollback file' or just 'bzr revert file'
<Oli``> vila: and that just takes the file backwards one revision?
<Oli``> (well to the last revision it was edited)
<vila> Oli``: yes, alternatively you can use 'bzr shelve' and chose which modifications you want to keep in the file and which you want to.. shelve
<vila> err, I meant 'bzr shelve file'
<vila> Odd_Bloke: but look at 'bzr help shelve' 'bzr help revert'
<vila> Oli``: but look at 'bzr help shelve' 'bzr help revert'
<vila> Odd_Bloke: sorry, blame xchat :-/
<dereine> is it possible to branch and checkout in the same directory like on git?
<Noldorin> hello. how can i use the --filters option on bzr export?
<maxb> Hi, how does bzr handle interrupted network connections during pulls? Is it able to make use of the data it transferred already, or will it start again from the beginning
<spiv> maxb: it generally starts again from the beginning :(
<maxb> Ah. There's a discussion going on on the Launchpad mailing list about whether there should be a nightly tarball to help people on dodgy connections do the initial bulk transfer
<Noldorin> hmm. why is bzr export silently failintg when i specify a DEST?
<wgrant> maxb: Did you see the suggestion on the list to do a gradual pull?
<mneptok> wgrant: that got filtered as porn by SpamAssassin
<maxb> oh, now I do
#bzr 2009-10-08
<igc> morning
<spiv> igc: morning
<matt2000> I'm trying to upgrade from bzr 1.13 to 2.0... yum doesn't seem to know about bzr (yum upgrade bzr says 'Could not find update match for bzr' and yum install bzr complains about missing dependencies)I don't think I compiled from src; anyway I can't find any bzr sources lying around.  Is there a way to figure out how it was installed in the first place? I'm on Centos 4.7.
<spiv> "bzr --version" will tell you where bzrlib is installed, which may give a clue.
<SamB_XP> you can install software on breathmints now ?
<jderose> matt2000: also, `rpm -qi bzr` will show if there's an rpm package installed
<igc> hi spiv
<matt2000> thanks. bzr --version says ' bzrlib: /usr/local/lib/python2.4/site-packages/bzrlib'
<matt2000> rpm says 'package bzr is not installed'
<spiv> matt2000: /usr/local suggests you did something like "python setup.py install" from a tarball or a checkout.
<spiv> (And maybe even used stow!)
 * SamB_XP thinks centos sounds like a breath mint
<matt2000> spiv, thats possible. so can python setup.py help me upgrade to 2.0?
<spiv> matt2000: python's distutils (the library behind setup.py) doesn't really do upgrades or uninstalls :(
<matt2000> SamB_XP: I think XP sounds like something I get for slaying orcs & dragons.
<spiv> It can install over the top, which often works, but isn't really a good idea.
<SamB_XP> matt2000: no, I think you need to slay software engineers to get XP
<matt2000> spiv: so what happens if I gather up the dependencies yum is asking for and do yum install bzr ?
<spiv> matt2000: the good news is that probably uninstalling is a matter of deleting /usr/local/lib/python2.4/site-packages/bzrlib, /usr/local/bin/bzr, and maybe one or two other things.
<spiv> matt2000: (have a quick poke around /usr/local for likely stuff)
<matt2000> also, I though yum was supposed to get dependencies for me. Or am I spoiled by apt-get ?
<spiv> matt2000: then if you install it the regular way with yum it should all be good.
<spiv> matt2000: For future reference, GNU stow is really handy for installing stuff manually into /usr/local, because it makes it easy to delete later.
<matt2000> hmm, maybe I did compile form source... I've got pycrpyto & paramiko src tarballs in /root, which are bzr deps I think?
<matt2000> how would I upgrade to 2.0 form sources? Does `make install` take care of that?
<spiv> "make install" doesn't know anything about upgrading as such.  It will happily write files over the top of an existing install, which is very roughly the same.
<spiv> (But has been known to cause mysterious failures with some past releases)
<matt2000> ah ha! bzr --version == 2.0.0
<matt2000> spiv, thanks for the guidance
<spiv> matt2000: you're welcome
<johnf> jelmer, lifeless: ping
<spiv> jam: you wouldn't happen to still be around would you?
<poolie> hello spiv
<spiv> poolie: hello
<spiv> poolie: https://code.edge.launchpad.net/~spiv/bzr/debug-flag-relock/+merge/12972 is still waiting for a re-review from you, should be an easy one :)
<poolie> ok
<poolie> igc, did you get my mail of Bazaar strategy from London?
<igc> poolie: yep
<poolie> ok
<poolie> so that kind of subsumes the previous 'news from london' thread, in that it's a summary at the end of the week
<poolie> thanks
<mwhudson> poolie: it looked like there were some unfinished sentences in your strategy mail
<poolie> yes, i blame jetlag, sorry
<mwhudson> ok :)
<poolie> i see one of them was probably just missing an "etc"
<spiv> poolie: I'll make a mental note to just fill in all your unfinished sentences with "etc" :)
<poolie> "I think we should etc"
<poolie> :)
<emmajane> igc, ping?
<igc> hi emmajane!
<emmajane> igc, hey :)
<emmajane> I've read the documentation, but I need help. :/
<emmajane> igc, I think in your email you're saying to set up a working tree (e.g. http://www.emmajane.net/node/884) but I don't actually see that in the documentation on "how to work on LP projects" so I just want to make sure I'm not going to mess stuff up again.
<jam> spiv: I'm around now for a bit
<spiv> jam: oh, hey
<spiv> jam: I was just going to ask about your thoughts on my reply on the only_raises review, seeing as you hadn't responded yet and I wanted to land it.
<jam> spiv: I replied to your review of my branch
<jam> spiv: as for your stuff...
<jam> the problem is that if you supress something, nobody ever knows to go look for anything
<spiv> jam: but then I realised you gave me permission to land it so that discussion can happen independently.
<jam> you never "get the information back"
<jam> I don't feel terribly strongly, but it is just a general statement
<jam> as for the "abort_write_group" stuff
<jam> that is not quite the same
 * igc reads emmajane's article
<jam> because if we didn't print the error then
<jam> it ends up being printed at the end
<jam> (often we see: "abort_write_group: Foo failed\nFoo failed\n"
<spiv> The problem is that often (practically all the time? -- Not A Metric) the fact unlock failed doesn't actually contain any real information.
<jam> spiv: it says you need to run break lock
<emmajane> igc, I didn't have anything that I'd worked on, so I've just chucked all my branches and will start again. :)
<emmajane> igc, I just want to make sure I set it up correctly this time though
<emmajane> I was specifically looking at: http://doc.bazaar-vcs.org/test/en/tutorials/using_bazaar_with_launchpad.html
<spiv> jam: that only happened when LockContention is acquired on a lock attempt, I thought/
<spiv> ?
<emmajane> but there wasn't anything about best practices for working trees
<jam> spiv: so, if you are getting an error during unlock, that means you had a write lock
<jam> as read locks are no-ops
<jam> so if you get an unlock error, that means the branch is left locked
<spiv> jam: grep doesn't show anywhere talks about break-lock during unlock for me.
<jam> spiv: I'm not saying the error specifically says that, I'm saying it tells someone that
<jam> as in, it can be inferred
<jam>  / we can fix the error message
<jam> I won't say there is lots of useful information that you must not suppress
<spiv> Oh, I see.  The problem is often it doesn't convey that, or it is already being conveyed.
<johnf> Anyone seen this before?
<johnf> bzr: ERROR: documents is not an index of type <class 'bzrlib.index.GraphIndex'>.
<jam> just being conservative
<jam> spiv: "bzr:interrupted" doesn't convey that to me at all
<igc> emmajane: that tutorial probably needs some love - LP is more powerful now with merge proposals and other goodies
<jam> though when I try to push again, it will tell me
<emmajane> igc, :)
<igc> emmajane: http://doc.bazaar-vcs.org/latest/en/user-guide/organizing_branches.html is the key thing to read
<spiv> i.e. if the unlock is happening because of "connection reset" then allowing that error through is going to more clearly hint "you probably need break-lock" than "TooManyConcurrentRequests"
<emmajane> igc, lovely!!
<jam> spiv: though connection reset can happen at any time
<spiv> So it seems to me that it's an improvement for at least some cases.  KeyboardInterrupt is a tricky case.
<igc> emmajane: and one more thing ...
<jam> whether or not a lock was taken
<emmajane> igc, I started at the "in five minutes" and then went to the tutorial and then to LP.
<jam> and I certainly agree "TooManyConcurrentRequests" is generally completely bogus
<igc> you don't need to merge your feature branch back into your trunk & push
<jam> I've never had *that* actually be true
<spiv> jam: and it can happen while waiting for a response to an unlock RPC, in which case you don't actually know if you need to break-lock or not :)
<spiv> Oh, it's always true.
<jam> TooMany has only ever happened IME when the connection was closed, etc.
<spiv> Just not in any sense that's relevant to users.
<igc> instead, you can push your feature branch to LP as ~emmajane/projectname/branchname
<jam> spiv: 1 request cannot be concurrent
<igc> emmajane: then propose it as a merge
<emmajane> igc, ok
<jam> spiv: can it?
<emmajane> igc, I should be able to do this quickly and then I'll ping you again when I'm ready to upload.
<igc> emmajane: to propose a merge, run "bzr lp-open" and click the necessary link
<spiv> jam: no, but it won't be raised unless the medium has been asked to track multiple requests.
<jam> spiv: then is the bug that ConnectionReset doesn't clear the current pending request?
<jam> since it certainly doesn't seem like it is still active
<spiv> More likely a bug that code attempts to keep using a connection after a ConnectionReset.
<jam> We're a bit off topic, but I've never felt that I've gotten a genuine case where we issued 2 requests concurrently. Just that one gets interrupted, so we go on to the next
<jam> and the lower level thinks we issued 2
<spiv> It's pretty much always a symptom of a bug, like an AssertionError.
<jam> spiv: right. I think the intent of it is even a 'programmer error' if it was actually genuine
<jam> something like issuing a request while iterating over the results of a record stream, etc.
<spiv> Right.  Although reentrantly trying to issue an RPC during cleanup while the previous response hasn't been completed also fits the description of 'programmer error'.
<jam> perhaps
<jam> though if the connection is broken transiently
<jam> one could argue that you reset and try again
<jam> which would allow clean shutdown even after a hiccup
<AfC> It's amazing that we spend huge amounts of time worrying about bandwidth and performance of our DVCS system transmitting a few bytes of patch from A to B, and yet for a few lines of kernel patch our distro is mirroring and then each of us are downloading 30 MB of binary package
<jam> AfC: I've been suprised that debs don't do any sort of incremental updates as well
<jam> surprised
<spiv> Or we perhaps should arrange to keep raising ConnectionReset (or whatever) on subsequent attempts to use that connection.
<AfC> jam: yeah. I mean, that's just the use case that rsync is optimized for
<AfC> jam: although that would assume that the tar files we create were more or less consistently ordered to some defined spec [which I believe is, by accident, the case],
<AfC> jam: but more to the point the compression algorithm would have to have clear boundaries so that (for example) a new file mean new compression headers etc so that rsync could easily detect the unchanged regions (ie, unchanged files)
<AfC> but that would seem worth achieving
<spiv> Anyway, my basic theory is that the original error which will now be reported cleanly to the user ought to be conveying the idea that "your operation has failed, some human cleanup may be necessary" better that saying "unlock failed with TooManyConncurrentErrors."
<spiv> Especially given that some unlocks don't actually involve releasing locks on disk (read locks, or locks acquired with a token or when leave_lock_in_place has been called).
<jam> spiv: but those unlocks won't actually raise errors...
<spiv> Probably they won't.
 * igc grabs some lunch - bbiab
<spiv> Except for MemoryError, or novel bugs, or ...
<jam> spiv: given that they aren't issuing rpcs, they won't raise TMCE
<poolie> hi igc, jam, spiv
<poolie> afc
<jam> hi poolie
<spiv> I see emitting a friendly "I could not release this physical lock" as an orthogonal issue, really.
<spiv> I'm not against doing that at all, I just don't see it as more than tangentially related to a patch to suppress unwanted exceptions from quashing other exceptions.
<jam> spiv: and my concern is that squashing too hard means we may lose information, and never know about it.
<poolie> i agree with spiv
<jam> generally, I'm fine with always squashing TMCE
<jam> but that isn't the only thing being squashed
<poolie> it's possible we could squash say SyntaxError
<spiv> Because for instance it needs to be done at a slightly lower layer to be correct, because "Repository.unlock" doesn't directly map to "release physical lock on disk".
<poolie> i think maybe for developers this should always print to stderr
<poolie> for some appropriate value of 'developres'
<jam> poolie: well, the path we've taken to date is version_info[3] == 'final'
<spiv> Also, TMCR isn't the only exception that has caused this, just the most common one.
<jam> spiv: I'm certainly not asking for a traceback, and I think you did completely the right thing there
<poolie> mm
<jam> my concern is whether we want a one-line warning versus just mutter
<poolie> i'm thinking we should have -Developer
<jam> debug_flags = eveloper,hpss ?
<poolie> it's also a bit connected to python warnings
<poolie> mm, or -Ddeveloper
<poolie> like libowfat :)
<poolie> i think if we're going to far, we'll start getting bugs about "why am i always told the branch is already locked?"
<jam> poolie: I have to say I don't have a clue how to parse libowfat :)
<poolie> too*
<spiv> I expect that an unfortunately timed connection loss during SFTP could trigger the same problem, for example.  Or a wireless card drop out during HTTP, or while accessing something over NFS, etc.
<poolie> on the gcc command line, '-lowfat'
<jam> poolie: ahh
<jam> fun
<poolie> and then the first step would be to say 'an error prevented %s being unlocked'
<poolie> and then we could take it further
<poolie> spiv, it is still going into mutter right?
<spiv> Which is why I'm whitelisting rather than blacklisting, because I don't think it's feasible to anticipate all the possible errors.
<spiv> Yep.
<jam> poolie: so I tried to get the queue down, but still no response on the cache cix stuff
<poolie> i saw your swathe of review mails
<poolie> that was impressive
<jam> also, does anyone know how to get LP to do partial merge requests?
<jam> I'd like to split up my static-tuple branch
<jam> but I'm not going to put in the effort if I can't generate nice merge proposals
<poolie> with partial diffs?
<emmajane> igc, Ok. I tried doing the push from my feature branch just to my own stuff on LP and I'm getting an error.
<emmajane> igc, I did: bzr push lp:~emmajane/bzr-website/utility-nav
<emmajane> and it said:
<emmajane> (apologies for the four-line spam)
<emmajane> Using default stacking branch /~bzr/bzr-website/trunk at lp-46082192:///~emmajane/bzr-website
<emmajane> bzr: ERROR: KnitPackRepository('lp-46082192:///~bzr/bzr-website/trunk/.bzr/repository')
<emmajane> is not compatible with
<emmajane> CHKInventoryRepository('lp-46082192:///~emmajane/bzr-website/utility-nav/.bzr/repository')
<emmajane> different serializers
<emmajane> (five line)
<emmajane> (more if I keep counting incorrectly and continue to correct myself)
<jam> poolie: right, I want to create N branches, each one building on the other
<jam> but I want to submit it relative to the previous branch
<jam> so it can actually be reviewed in pieces
<jam> I thought you could do something like that via email
<jam> but I've never tried
<jam> so I was hoping someone else had
<spiv> jam: I think I have in the past, when lp code reviews would use the preview diff from the email.
<jam> spiv: I thought if you sent a cherrypick request "bzr send -r X..Y" it would do so
<spiv> (or whatever the terminology was)
<jam> but you think that was because of the preview diff?
<spiv> But I think now that there's only one kind of diff, and LP generates it, I'm not sure that would work.
<spiv> But I haven't tried recently, so I might be wrong.
<spiv> mwhudson: ^ ?
<mwhudson> spiv: i think you're right
<mwhudson> i haven't tried it myself either
<jam> spiv: question for you
<jam> about python
<poolie> jam, i've heard something about them working on mp dependencies
<jam> foo = MyObject()
<poolie> but it's not live yet
<spiv> emmajane: your local branch is in the shiny new 2a format, but lp:bzr-website isn't (it's 1.9-rich-root)
<jam> assert 1 = sys.getrefcount(foo) -1
<jam> foo = ('tuple')
<jam> assert 2 = sys.getrefcount(foo) -1
<jam> Is this because the compiler is adding the static tuple into the function frame?
 * emmajane grumbles.
<emmajane> spiv, thanks :)
<spiv> emmajane: if you do "bzr init --1.9-rich-root lp:~emmajane/bzr-website/utility-nav" before pushing it should work.  You may need to delete the old branch first.
<jam> spiv: or we should just upgrade lp:bzr-website
<spiv> emmajane: or get igc to upgrade lp:bzr-website to 2a :)
<spiv> jam: almost, except your phrasing sounds dangerously like you're going to volunteer! ;)
<spiv> jam: that hypothesis sounds close
<spiv> jam: although I think it's because the static tuple is defined in the function or code object, rather than the frame.
<spiv> But ICBW.
<AfC> Did I understand the 2.0.0 release announcement to mean that any bzr >= 1.16.0 can read from a public branch that is in 2a format?
<emmajane> spiv, It didn't like it when I just pasted that command. So probably I need to nuke the .bzr folder in the feature branch and re-initialize?
<emmajane> (Warning: never be the last one to talk to the newbie or you'll get all the pings.) ;)
<spiv> AfC: that sounds correct.
<spiv> (I don't remember the precise version offhand, but that's the right ballpark.)
<spiv> emmajane: right.  Or go to https://code.launchpad.net/~emmajane/bzr-website/utility-nav and delete it through the web UI.
<AfC> spiv: ok, thanks. Now that I think of it, that makes sense (as thereabouts was when the format was introduced experimentally) ...
<AfC> I wonder if I was to upgrade my public branches to 2a whether that would screw over people using (say) 1.18.1 (ie, has all this furious bug fixing been in new code, or does it mean that that 1.18.1 is also buggy with respect to the 2a format?)
<igc> emmajane, poolie: it sounds like we ought to switch bzr-website to 2a
<emmajane> spiv, ok, deleted from the web interface, re-ran the init and am now pushing the featurebranch
 * emmajane scrolls back up to find igc 's next instruction. :)
<poolie> igc, it would be good but i think you'd need to check escudero had a new bzr first
<poolie> afc, i think 1.18.1 is ok, but it'd be better to get them onto 2.0.x
<poolie> or otoh wait until everyone is on 2.0.x
<AfC> poolie: right. I'm balancing the [very few] hackers I have (using Debian's bzr or Ubuntu Intrepid's bzr or whatever ancient code) versus the gain I'd see as the person who interacts with said public branch the most :)
<spiv> AfC: skimming the NEWS file I don't see any critical correctness bugs relating to 2a fixed in 2.0.0 vs. 1.18.1, but there were quite a few performance bugs and even one segfault fixed.
 * emmajane clicks all the buttons
<emmajane> igc, ok, I think there's something there for you to review now?
<AfC> spiv: yeah. Well. I'll be "responsible" and wait a bit longer before upgrading. But once Ubuntu and Fedora  have 2.0.x in them (Gentoo does already) then really there won't be much justification for me to hold back further.
<spiv> emmajane: looks like a decent merge proposal to me.
 * emmajane blinks at AfC. *gentoo* is ahead of Ubuntu?
<zobi1> is there a working bazaar bundle for textmate?
<emmajane> that's awesome :)
<AfC> emmajane: of course
<emmajane> spiv, \o/
<zobi1> oops, just got disconnected. repost: is there a working bazaar bundle for textmate?
<AfC> emmajane: the only place where Ubuntu or Fedora tend to be ahead of Gentoo is in and around the GNOME constellation, since they're always is such a rush to get it ready for their next 6 monthly release AND they have an "exception" or whatever hardwired into their release guidelines.
<AfC> emmajane: But for most other things they're all tight about freezing and thereby shipping ancient code. Fedora seems to update more broadly and willingly than [the Debian culture inherited by] Ubuntu.
<AfC> but I don't have an objective measure of that yet.
<emmajane> AfC, huh.
<igc> thanks emmajane. I'll review that now
<arkanes> that doesn't really match my experience
<idnar> AfC: you should probably specify whether you're talking about stable releases or not
<idnar> eg. bzr 2.0 has been in debian sid for a while now
<arkanes> there's a lot of things you need to manually unmask to get half-decent recent versions of in gentoo, and broken ebuilds in those unmasked packages are really common
<AfC> idnar: I'm encompassing both stable and development experiences in one sweep. But taking the example you cite, bzr, what version is in Intrepid?
<jam> AfC, emmajane: Depends if you consider ppas, etc. But yeah, I think gentoo tends to be a bit closer to crack-of-the-day
<idnar> which would probably be a better comparison with Gentoo than, say, Debian 4.0
<mneptok> AfC: depends on if you use default repos, backports, or a PPA
<AfC> mneptok: whatever Canonical Inc is officially supporting and shipping (so, no PPA)
<idnar> intrepid apparently has 1.6.1, but that's, what, a year old?
<AfC> idnar: and that's my point.
 * emmajane nods
<mneptok> what does Gentoo officially support?
<mneptok> (i.e. when i dial Gentoo paid support, what version do they expect me to have?)
<emmajane> mneptok, don't be difficult just because you're right. ;)
<idnar> AfC: yeah, but I don't really understand the issue; if you want software that's newer than a year old, run a release that's newer than a year old. you might then want to complain that Debian doesn't release often enough, but Ubuntu seems to release often enough that that's not such a major issue
<AfC> mneptok: it's a community distro. It doesn't officially support anything. But as a rolling-release distro (ie, Gentoo, Arch) it tends to have fairly up to date packages, taken as an average.
<arkanes> it doesn't seem very reasonable to compare what is essentially a static distribution with constantly updating packages (gentoo) with a distro with rapid, regular releases
<idnar> and if you want the latest and greatest, then run the latest and greatest
<mneptok> AfC: it's easy to decide to potentially break things when you have no paying customers ;)
<arkanes> you can view ubuntu releases as snapshots if you want instead
<mneptok> !info bzr
<ubottu> bzr (source: bzr): easy to use distributed version control system. In component main, is optional. Version 1.13.1-1 (jaunty), package size 5171 kB, installed size 17768 kB
<mneptok> 1.13 in Jaunty
<AfC> and you're proud of this?
<mneptok> (using default repos)
<idnar> AfC: what I'm saying is
<mneptok> 2.0 is default in Karmic
<idnar> AfC: if you want "always being updated", Debian already provides that, as does Ubuntu to an extent
<mneptok> so, upgrade your distro. you know, just like you would do with a rolling release.
<AfC> Yeah, well, I've made that mistake. Running Karmic has been hell the last month.
<m3ga> i've created a repo using bzr 2.0.0 and i'd like to pull it from a machine 1.13.1, but can't because of version mismatch. can't the repo be downgraded?
<arkanes> AfC: I'm not really sure where you're going with this
<m3ga> thats what you're talking about isn't it? (hi AfC)
<idnar> anyhow, having said all of that, I'm not planning to rush out and upgrade everything to 2.0/2a right away either, I'd rather take my time ;)
<arkanes> AfC: it's not like unmasking every experimental and half-working ebuild in gentoo is going to get yuo a stable system
<AfC> m3ga: yeah, if you init{,-repo} a branch in --format=$something_older and then pull into it, it'll convert
<m3ga> ah, thanks
<bob2> I don't think you can go back from 2a
<bob2> well, you can, but only to a rich root format
<AfC> bob2: yeah, that sounds familiar
<AfC> m3ga: but in that case, --format=1.9-rich-root or such
<bob2> --1.9-rich-root
<bob2> 2slow
<m3ga> hmm, can't create --pack-0.92 like all my other repos.
<m3ga> bzr 2 available for jaunty?
<AfC> m3ga: not from Ubuntu, but in the Bazaar PPA, yes
<mneptok> https://edge.launchpad.net/~bzr/+archive/ppa
<igc> emmajane: I'll approve and merge that change
<emmajane> igc, does that mean I can go to sleep now? :)
<igc> emmajane: sure :-) night
<emmajane> igc, thanks :)
<emmajane> oh. wait.
<emmajane> I have the new icon too.
<m3ga> thanks mneptok and AfC. Got it
 * emmajane figures out where to put that.
<igc> you can use the same branch and push again if you like
<emmajane> k
<bob2> mneptok: ah, --rich-root-pack
<bob2> oops
<emmajane> igc, erm I get an error when I try to merge into the same place.
<emmajane> propose a merge into the same place rather
<emmajane> "There is already a branch merge proposal registered for branch lp:~emmajane/bzr-website/utility-nav to land on lp:bzr-website that is still active."
<igc> emmajane: when you push?
<emmajane> igc, when I use the web interface to request a merge
<igc> emmajane: try "resubmit proposal"
<emmajane> igc, I don't see an option for resubmit...
<igc> right hand top corner?
<emmajane> https://code.edge.launchpad.net/~emmajane/bzr-website/utility-nav
<igc> of the current merge proposal
<emmajane> and that's an internal server error.
<emmajane> um.
<emmajane> http://bazaar.launchpad.net/~emmajane/bzr-website/utility-nav/files
<igc> yuk
<igc> I'll pull your branch in any case
<emmajane> :)
<emmajane> the only change was adding the new icon from danno
<igc> well, merge your branch into my trunk to be more explicit
<idnar> you should still be able to resubmit from https://code.edge.launchpad.net/~emmajane/bzr-website/utility-nav/+merge/13038
<idnar> even if the code browser is spewing errors (which seems to happen far too frequently)
<emmajane> idnar, thanks
<emmajane> igc, I resubmitted
<igc> thanks. looks good.
<igc> emmajane: committed to trunk now.
<emmajane> \o/
<igc> emmajane: night (and thanks)
<emmajane> igc, thanks for making sure I was doing it right :)
<igc> np
<igc> emmajane: I figure telling you is double value as you often tell others :-)
<emmajane> :)
<emmajane> igc, it's true. :)
<emmajane> igc, is it on your plate to update the In 5 Minutes guide to include the working tree info?
<emmajane> if not I'll add it to my plate.
<igc> emmajane: it's not on my plate
<emmajane> ok
<igc> my plate is struggling with enough other stuff :-(
<emmajane> heh. have you been up to the buffet and overloaded your plate? ;)
<igc> emmajane: the one downside to pulling stuff into separate projects is that I'm now managing merges to a dozen or more of them!
<emmajane> :(
 * emmajane gives you a tray to put your plate on? :/
<igc> emmajane: I can easily spend all day on bzr and never touch the core project
<emmajane> I've got a few people firing me explorer docs as well.
<igc> emmajane: cool. Some screencasts on explorer would be sweet btw
<igc> hint hint :-)
<emmajane> heh. I was just complaining about screen casting to someone :)
<emmajane> Ubuntu + screencasting = fail.
<emmajane> I've had to buy a windows box. :(
<igc> :-(
<emmajane> yeah
<emmajane> I record in Ubuntu and then transfer to windows to add voice and render.
<emmajane> I'll see if I can bribe jacine into doing one for OSX though.
<igc> emmajane: karmic?
<emmajane> whatever 9.04 is.
<igc> jaunty
<emmajane> I'm lousy at remembering the animal names.
<igc> emmajane: I just upgraded to karmic today
<emmajane> I should upgrade my laptop that never gets used just to see how it all looks.
<emmajane> i'm afraid of upgrading production machines though
<igc> it looks really nice
<emmajane> cool :)
<jam> first patch on the static-tuple wagon is up for review: https://code.launchpad.net/~jameinel/bzr/2.1-simple-set/+merge/13039
<jam> second is in the email queue
<jam> 3 4 5 I'll probably work on tomorrow
<jam> night all
<emmajane> igc, Ok. I'll scan through the list again tomorrow to see if there's any leftover things before starting on the inner pages.
<igc> night jam
<jam> 2 is up https://code.launchpad.net/~jameinel/bzr/2.1-export-c-api/+merge/13041
<jam> though it royally screwed things up
<jam> the email looks like it through out my carefully worded submit request
<jam> and then inlined the attachment
<jam> and then generated its own *full* merge result
<jam> ignoring the fact that I asked for a cherrpyick
 * jam grumpy
<jam> abentley: ^^ I'm going to bed, and I assume you are sleeping, but if you could explain what is going on, I'd like to understand.
<jam> Is it just not possible in launchpad's code-review to get decent stacked changes reviewed?
<jam> hmm... I wonder if I could cheat and actually request the submission to be merged into my other branch
<jam> and just make 'bzr-core' the reviewer...
<jam> anyway, will try something tomorrow
<spiv> jam: g'night
<vila> hi all
<vila> jml: testtools requires python >= 2.5 (more precisely functools), is that a bug or a feature ?
<mtaylor> bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/mordred/src/drizzle/.bzr/repository/') has no revision ('mordred@inaugust.com-20090924230420-zc4vxrr30uxgo4eb',)
<mtaylor> anything in general I can do to work around it when bzr tells me things like that?
<jelmer> johnf: ping
<poolie> mtaylor: is this when pushing?
<mtaylor> poolie: no... I was giving the rebase plugin a try
<mtaylor> poolie: I'm guessing it doesn't like stacked branches?
<poolie> maybe, i'd have to see the traceback
<poolie> probably best if you file a bug on that
<mtaylor> poolie: k. will do
<poolie> thanks
<mtaylor> poolie: should I file it on bzr or on bzr-rebase?
<poolie> probably rebase at first
<mtaylor> k
<mtaylor> poolie: fwiw: bug 446075
<ubottu> Launchpad bug 446075 in bzr-rewrite "bzr crashed while trying to run bzr rebase" [Undecided,New] https://launchpad.net/bugs/446075
<vila> For those interested in bug #405745, the failure with python-2.4 was due to some bits missing in socket.py and SocketServer.py, nothing really problematic
<ubottu> Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745
<poolie> we should get the crash message to tell people what bug subject to use
<mtaylor> poolie: yeah.
<mtaylor> poolie: sorry - that's like the worst bug subject every isn't it
<poolie> not the worst :)
<mtaylor> :)
<poolie> 'bzr crash' is better
<poolie> or 'problem'
<poolie> 'halp'
<poolie> :)
<spiv> Or "ubuntu cds"
<mtaylor> or 'discount viagra'
<vila> so the leaks due to http (bug #392127) are still down ~300 to 0
<ubottu> Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127
<poolie> woo vila
<vila> s/down/down from/
<poolie> can we enforce that there are 0 now?
<vila> and I have good hopes the same fix could be applied to ftp (I'm not sure hpss needs it though I seem to remember spiv telling so, ref?)
<vila> enforcing 0 is one or two patches away I'd say
<spiv> vila: maybe, I'd have to look to check...
<vila> The main problem is that the threading module seems to be less than reliable when it comes to counting active threads...
<spiv> There's a thorny thread leak involving sftp and a blackbox test.
<vila> spiv: don't worry, I'll look at the code for hpss, but I've already fixed RecordingServer and I'm not sure you were referring to that or something else
<spiv> vila: sure it's not simply a matter of a race between when you check the count and when you do the enumerate?
<spiv> There's a SmartTCPServer_for_testing that you may need to look at.
<vila> spiv: what race ? I ask for the count and get 2, I do enumerate I get 1
<vila> spiv: ok, I'll look at that
<spiv> vila: so between doing the count and the enumerate one thread finished?
<poolie> igc, what's the deal with https://code.edge.launchpad.net/~ian-clatworthy/bzr/faster-log-file/+merge/7535
<vila> spiv: no, AFAICT it's already finished, the proof being that enumerate() doesn't see it and all involved threads has been joined
<spiv> vila: the implementation of active_count and enumerate in 2.6 don't leave much room for disagreement.
<igc> I need to test it on an LP file (bushy tree project)
<spiv> vila: i.e. they are identical except one does len(_active) + len(_limbo), and the other does _active.values() + _limbo.values() (and those two vars are ordinary dicts).
<vila> spiv: it's as if the thread was still alive for a short time after join()
<spiv> Ah, that sort of thing I could easily believe.
<vila> spiv: I can't reproduce reliably, but I've seen it in ~5% of the cases
<vila> spiv: but then it becomes a bit hard to detect leaks...All I got is false positives...
<poolie> igc, is https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-update-bug/+merge/10959 the one you were asking me to read?
<vila> So the answer to poolie question: "Can we enforce 0" is: "No, because of the false positives :-/"
<poolie> i'm sure i won't work on it before i go
<igc> that's the one
<igc> it's mainly tests but 2 bits of code iirc
<poolie> so is there anything i can sensibly do today/tomorrow?
<igc> that's the main thing I was hoping for
<vila> spiv: anyway, my goal to reduce it as much as I can, bug #392127 is significant here as the "Can't create new thread" was blocking the full test suite on gentoo, OSX and windows
<ubottu> Launchpad bug 392127 in bzr "bzr >= 1.16 on gentoo: can't start new thread" [High,In progress] https://launchpad.net/bugs/392127
<vila> I don't know the *next* bug that will block the full test suite on windows though :)
<poolie> igc: what's the main thing? just a review?
<igc> yes
<poolie> it's not redundant with robert's comments?
<poolie> it looks basically ok but i'm a bit dopey so i'll look again tomorrow
<igc> poolie: I wanted to land that in 2.1b1 so we have a public dowlonad for using really needing content filtering to work
<poolie> i'd be a bit wary of putting it into 2.0.1
<igc> users
<poolie> just because of the history leading up to 2.0
<poolie> mm
<igc> right
 * poolie looks
<bialix> hello all
<johnf> Before I file a bug has anyone seen this before
<johnf> bzr: ERROR: documents is not an index of type <class 'bzrlib.index.GraphIndex'>.
<bialix> poolie made my day: "There is a good amount of work in bzr.dev - 4 a4 pages of news - so it'd be good to get it out." ROTFL
<vila> hello bialix
<spiv> johnf: no, that's new to me.  I wonder if it's something to do with a plugin?
<bialix> bonjour vila
<johnf> spiv: remind me how do I make plugins not load?
<awilkins> --no-plugins
<vila> johnf: rings no bell, the 'documents' token makes me think it could realted to a plugin
<vila> johnf: you can also do 'BZR_PDB=1 bzr <command>' to have pdb called and do 'bt' there
<spiv> vila: so in Python 2.6 when a thread finishes it acquires the global _active_limbo_lock, calls self.__stop (which would wake up the thread doing the join), deletes its entry from the _actives dict and then releases the lock.
<spiv> vila: but active_count and enumerate both acquire that global lock before doing their work
<spiv> vila: so, I would expect that when join returns that the other thread is still alive momentarily, but that you would not be able to see that by calling threading.enumerate or threading.activeCount
<johnf> ok it is a plugin
<vila> spiv: I agree with the theory :D
<vila> spiv: to add data: using 'del thread ;thread = None' helped
<johnf> ahh search plugin is the culprit
<vila> I'm not sure I've addressed the issue completely though...
<vila> since that wasn't reproducible nor my main goal, I'd look into it when the ~2000 remaining leaks will be fixed...
<spiv> vila: maybe set threading._VERBOSE = True?
<spiv> (and run without -O)
<vila> spiv: I note that
<igc> hi vila, bialix, johnf
<bialix> hi igc
<spiv> vila: yeah, doing "del thread ;thread = None" sounds likely to help more for the fact of just adding a small delay rather than because of what it does.
<bialix> wow! bzr.dev's NEWS is almost 500KiB in size! crazy
<vila> spiv, poolie: Anyway, given the amount of work and thinking involved when tracking leaked threads, a warning still sounds fine, we use threads in the test infrastructure and so far this has triggered bugs for selftest only, no need to block
<vila> In a given working tree where 'make' has been run,  py2.4 do not want to load some extensions that 2.5 and 2.6 happily load, any takers ?
<spiv> vila: extensions were built with 2.5?
<vila> python --version
<vila> Python 2.6.2
<vila> So I think it was with 2.6
<vila> s/I think/I'm sure/
<vila> ha, .bzr.log mentions pycurl not available for 2.4, may be related...
<vila> eeerk, pycurl not supported for 2.4 ? The package dependencies says: Depends: python (>=2.5) ???
<vila> on jaunty
<vila> well, yeah, makes sense, sorry
<bialix> vila: btw is pycurl still needed? esp @ py2.6?
<vila> what matters is that pycurl is supported by the default python version
<vila> bialix: for windows you mean ? Still the same answer: do you care about verifying the certificates ?
<bialix> for windows yes, I don't care but if I do then I need? The problem is there is no pycurl build for 2.6 for windows
 * vila cries
<bialix> sorry, I did not want
<vila> :D
<bialix> that's better
<fullermd> Oooh, it's THAT easy to make vila cry?  I'll hvae to remember that...
<bialix> I don't understand what I do but I'll try to not do it in the future
<vila> bialix: nice try !
<vila> lol
<bialix> :-)
<vila> The problem when you think you will fix a bug tomorrow is that you still encounter it today (or something like that) :D
<spiv> fullermd: mentioning any random collection of frustrating software is a good way to make a developer cry.  "pycurl + windows" -> sad.  "sourcesafe + anything" -> sad ;)
<bialix> LOL
<bialix> what's bad about pycurl on windows?
<fullermd> Funny you should mention that, I was just thinking we should try and get sourcesafe working on SCO...
<vila> fullermd: by the way, not a single 8.0rc1 crash since I swapped the IDE controller
<bialix> or maybe you mean "anything + windows" == mwhaa-mwhaa-haa
<vila> bialix: nope, he just refer to the fact that pycurl is not packaged for 2.6 on windows (you just mentioned that)
<fullermd> Wacky.  I wonder what it didn't like about the original choice.
<vila> fullermd: I don't :-)
<bialix> vila: oh, I was not aware you are aware that pycurl is not packaged
<vila> bialix: *you* just said it
<vila> err, too many negatives here I think :D
<bialix> I'm working as answering machine in ru_bzr, so just yesterday one man asking me about pycurl.
<bialix> vila: I'm happy to not think about pycurl anymore, I'm just need to know right answer
<vila> bialix: nothing has really changed
<vila> 2.6 allows a true https test server, so we have better test coverage which allows adding new features more easily, adding the features is still needed though...
<bialix> vila: I remember you've tried to use ssl module from py2.6. Hence my naive question
<vila> yes, the ssl module is used for that *and* can be used to implement certificate verification, I "just" need "time" :D
<fullermd> Well, you don't really NEED all that sleep, do you?
<bialix> as you said: sometimes people need to lie down and stare to the ceil ;-)
<vila> fullermd: well, no, but I hoped I could continue to sleep a bit without being noticed... thanks....
 * igc dinner
<vila> working around 2.4 missing features by trying to use other 2.5 features is.... bound to fail
<fullermd> Well, obviously.  2.5 features aren't advanced enough for that, you need to use some of the 2.6 stuff.
<vila> yeah, finally a good use case for 'from future import _feature_'
<vila> spiv: if you're still there and can re-review https://code.edge.launchpad.net/~vila/bzr/405745-http-hangs/+merge/13050, that would be very nice :)
<hsn> is somewhere documented bazaar api for plugin writers?
<mzz> hsn: pointing your favorite apidoc tool at bzrlib should do the trick
<mzz> hsn: (also reading other plugins)
<mzz> hsn: I don't know if there's a nice introduction to writing plugins up anywhere
<hsn> you mean eclipse?
<mzz> hsn: that's definitely not *my* favorite apidoc tool, but just use whatever you like :)
<bob2> http://bazaar-vcs.org/WritingPlugins
<mzz> ah, great
<hsn> i need to write repo export plugin
<mzz> hsn: might want to use the existing fastimport one
<hsn> what is fastimport?
<mzz> hsn: imports and exports a format that was originally invented for git iirc but supported by many dvcs systems now
<mzz> hsn: depends a bit on what your "repo export plugin" is for, obviously
<hsn> we will move from bazaar to Jazz SCM
<james_w> yeah, look at writing a fastimport importer for Jazz
<hsn> https://jazz.net/wiki/bin/view/Main/SCMChangeSetArchive - Jazz import SCM format
<mzz> yeah, consider writing something that converts from fastimport format to that
 * awilkins looks at Jazz, sees word "Rational" and shudders
 * mzz wonders why he's not allowed to read that wiki page without an account
<bialix> why commit don't commit files in alphabetical order?
<bialix> http://pastebin.com/m5b205d56
<smartgpx> bialix - 'bzr ci' does commit in alpha order, but 'bzr qci' does not.
<jam> bialix: from the paste you gave, it looks like we commit in the order you supplied the arguments.
<jam> so "bzr commit" does
<jam> but "bzr commit foo bar a q z" will commit in that order
<smartgpx> bialix: my python is close to non-existent, but I think the
<smartgpx> question becomes " what order is used to build the tree passed
<smartgpx> to QBzrCommitData in commit.py in QBzr?"
<bialix> jam: if you look closely on arguments passed to commit -- you'll see they all in alpha order
<bialix> jam: [u'host.c', u'host.h', u'i2c.c', u'i2c.h', u'main.c', u'packets.h', u'version.h']
<bialix> jam: but commit emits different order: host.c host.h packets.h i2c.c version.h main.c i2c.h
<bialix> smartgpx: "'bzr ci' does commit in alpha order, but 'bzr qci' does not." -- qci invokes plain commit under the hood, do you know?
<bialix> hi jam
<smartgpx> bialix: yes, I realise that - but try for yourself -
<bialix> try what?
<smartgpx> ci and qci give different results. (I can see that the
<smartgpx> logging gives the same file order... )
<jam> bialix: we go through "osutils.minimum_path_selection()" which seems to use a set() and then passes that to the next level
<jam> so we step through the supplied filenames in a 'set()' ordering
<bialix> it sounds like the case
<smartgpx> bialix: compare "bzr ci" with [after uncommit] "bzr qci"
<smartgpx> file size and datestamp seem NOT to be an influence
<bialix> smartgpx: see http://pastebin.com/m6d4ac53b
<bialix> jam is right -- it's a set() issue
<bialix> jam: may I file a bug and provide the patch to fix this?
<jam> smartgpx: 'bzr ci a b c' will have the same issue
<jam> bialix: I would be ok with it, but why does it matter?
<jam> just visually pleasing?
<bialix> because I pedantic and this was my wtf moment for today
<bialix> and visualy pleasing
<smartgpx> bialix: sorry, hadn't thought of passing the explicit file
<bialix> np
<smartgpx> list to 'bxr ci'. Yes, its does not do what one would
<smartgpx> expect. (But perhaps there was never a contract that the
<jam> bialix: so interestingly, I think minimum_path_selection already has the sorted list
<smartgpx> commits would be performed in the order you expected.  :-) )
<jam> and just turns it into a set for the heck of it
<jam> we might consider changing that
<bialix> I hope it's not performance critical change
<smartgpx> Right, that's one bit of tinkering for today. Now, is
<smartgpx> Vincent (vila) active right now?
<jam> bialix: well, there are going to be some other issues
<jam> looking at the code
<vila> smartgpx: pong
<jam> for example, we may add items to the search list
<jam> and see this comment
<smartgpx> vila: are you free to discuss the webdav issue I raised?
<jam> http://paste.ubuntu.com/288646/
<jam> where it specifically asks "should we be sorting here?"
<vila> smartgpx: bug # ?
<smartgpx> vila: probably my misunderstanding and not a bug, so no # yet
<vila> oh, yes, wait a min
<bialix> jam: it seems (commit.py) that specific files should be sorted http://pastebin.com/d5b846202
<vila> smartgpx: I need to find your mail back
<bialix> but apparently they're not.
<smartgpx> vila: don't bother, no details in it
<vila> smartgpx: ok, shoot then
<jam> bialix: so the iter_changes code needs a set at the moment, because it uses things like 'set.add()'
<bialix> heh
<jam> which is why I pointed at the line that is doing the 'consuming' and asks whether we should be in sorted order
<smartgpx> vila: this is probably a deficiency in the webdav'd server
<smartgpx> I am trying to push to..
<smartgpx> I tried bzr push https+webdav to a path I have access to
<bialix> jam: it's in commit.py?
<jam> bialix: that code is in _dirstate_helpers_pyx.pyx
<bialix> oh
<smartgpx> and got back bzr: ERROR: Invalid http response for https://zdrive.le.ac.uk/d/djr/TryBzrWD/webdav: Unable to handle http code 415:  Unsupported Media Type
<jam> commit is now layered on top of 'iter_changes'
<jam> on the flip side it also probably means that 'bzr diff foo bar baz' isn't going to be in sorted order either
<smartgpx> vila: but on reading the docs for the Server again it says...
<jam> I would say that in iter_changes you could keep a sorted list, along with the set
<jam> and work that way
<jam> or change the internal set into a list, and extract one, and always append to the end, etc
 * bialix checking diff
<vila> 415 !!! lol, what's that :)
<bialix> jam: diff is sorted
<bialix> jam: IIRC filenames for diff sorted manually
<bialix> maybe I can just sort entries after iter_changes in commit.py?
<vila> smartgpx: do you administer that webdav server ?
<jam> bialix: I think it would be better to have the search_specific_files be a sorted list
<bialix> in qdiff we did:
<bialix>                 for (file_id, paths, changed_content, versioned, parent, name, kind,
<bialix>                      executable) in sorted(changes, key=changes_key):
<bialix> so diff is sorted
<vila> down to 44 leaking tests...
<vila> ... but still chasing a random hang :-/
<bialix> but iter_changes apparently returns unsorted list
<smartgpx> vila: No, I don't run the server. The docs say \
<bialix> jam: it seems some clients of iter_changes (like status and diff) sort the list ourselves; but commit is not
<smartgpx> "Known Problem 1: You cannot create new files using WebDAV.
<smartgpx> You can move, delete, rename, open and view the properties of a file, but you cannot create new files.
<jam> bialix: I would like to avoid batching if we can
<jam> and sorting afterwards requires batchnig
<jam> batching
<bialix> what is batching?
<smartgpx> vila: www.w3.org says "10.4.16 415 Unsupported Media Type
<jam> bialix: grouping everything together before going on to the next step
<vila> smartgpx: that sounds coherent with 415 Unsupported media type
<smartgpx> The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. "
<vila> smartgpx: yeah, got my RC2616 handy
<vila> smartgpx: I never encounter 415 before
<smartgpx> vila: So, I just wanted to close the dangling query with
<bialix> jam: I don't understand
<vila> s/RC2616/RFC2616/
<smartgpx> you to say that I am prepared to accept this is a server
<smartgpx> shortcoming, not failure in the webdav plugin.
<vila> smartgpx: well, if the server doesn't let us *create* files, there is little we can do...
<bialix> jam: commit.py has 2 methods: _update_builder_with_changes, _filter_iter_changes
<bialix> the former invokes iter_changes
<bialix> I can sort there
<smartgpx> vila: Yes agreed. It's odd that I can create directories
<vila> the webdav plugin requirement is that the server implement a subset of commands that allows emulating a remote file system, a very rough file system, but a file system, so not being able to create files...
<smartgpx> but not files. And the IE 'web folders' client must have
<jam> bialix: consider the 'initial commit' case, where you don't supply any specific files, and it commits 10-20k files
<jam> I don't want to wait to sort those 20k entries before we commit
<jam> I'd rather have it just stream
<vila> smartgpx: that may be because directories are not really on disk but "collections" in DAV lingo, may be that server has some special purposes to begin with ?
<jam> 'specific files' is always going to be a fairly small list
<jam> because it is supplied by a human (most times)
<smartgpx> a way of creating the files when it uploads them.
<bialix> unless it supplied by our dumb qcommit
<vila> smartgpx: IE web folders ?
<Tak> yeah, md-bzr often specifies a large list of files as well
<bialix> so what about to not filter is there is no specific_files?
<bialix> or to not sort if len(iter_changes) > 100, say?
<jam> bialix: I really think sorting specific files is the 'right' approach
<jam> and I even think it isn't too hard to do in the internals
<bialix> jam: but they're sorted
<jam> search_specific_files is a set
<jam> change that into a sorted list
<jam> inside _iter_changes
<jam> or submit a bug, and see if one of us gets around to it
<bialix> unlikely
<bialix> this turns to be not 5-minutes fix, so I don't want to increase entropy
<bialix> it's only for me the page https://launchpad.net/bzr loading toooooo long?
<bialix> because of downloads links?
<bialix> sheeze, 1718  	 Open bugs.
<bialix> according to kfogel book number of open bugs is good sign, but I think it's actually Gaussian graph
<bialix> jam: no sir, I'd keep myself from filing new non-critical bugs
<fullermd> I can open a bunch if that'll help  ;)
<bialix> fullermd: it does not help me
<jam> bialix: filed as bug #446382
<ubottu> Launchpad bug 446382 in bzr "commit with specified files does not go in lexicographical order" [Medium,Confirmed] https://launchpad.net/bugs/446382
<bialix> jam: thanks
<bialix> so fixing iter_changes will definitely provides benefits for other clients as status and diff
<hsn> fastimport format can handle all bazaar features? i.e. tags and directory renames?
<bialix> hsn: no
<bialix> hsn: there was discussion in ML about extending fastimport format
<bialix> you need to ask Ian (igc)
<tsmith> hey is there such a thing as bzr diff -r9..HEAD ?
<bialix> bzr diff -r9..-1
<Lo-lan-do> "bzr diff -r9.." should be enough, no?
<idnar> what is bzr cbranch?
<idnar> somehow the help text fails to explain what it actually /does/
<roychri> Hello fellow bzrers,  I am new to bzr and I have troubles.  I created a local repo (bzr init) added some file and committed.  I use "bzr push sftp://..."  and it created a folder on my remote server with folder .brz and no errors.  When I try to branch from the "http" version, I get bzr: ERROR: Not a branch: "http://example.org/code/bzrtest/.bzr/branch/".
<roychri> where example.org is replaced with my actual site domain, of course.
<roychri> Any ideas?
<bialix> roychri: permissions?
<roychri> bialix: readable by all.
<bialix> Lo-lan-do: maybe, but in fact it's easier for git-man to remember that HEAD is -1 in bzr
<bialix> roychri: can you open the URL in the error?
<bialix> and see there format file
<roychri> I see branch.conf but I do not see any file called "format"
<roychri> by openiing the url
<roychri> But the branch.conf file is empty.
<bialix> that's the problem
<bialix> without format file the branch is inconsistent
<roychri> hmm
<roychri> why would the "push" not put it there and not report any errors?
<bialix> can you check over sftp?
<bialix> that the file is there?
<roychri> I am on the server with SSH.  Not there.  but it's in my local repo.
<roychri> wait
<roychri> it's there
<roychri> sorry
<roychri> but not listed on the web
<roychri> ok, I see the problem
<bialix> permissions?
<roychri> I have an .htaccess file in one of the parent folder
<roychri> <FilesMatch "...lots of stuf...|format">Order allow,deny</FilesMatch>
<bialix> ok
<roychri> nice, thanks bialix :)
<roychri> works now.
<bialix> happy to help (TM)
 * bialix feels that quote is a bit incorrect, vila should know the right one
<vila> bialix: *always* happy to help (tm) and the original author is jam (from my pov :)
<bialix> right
 * bialix writes this on the wall
<Tak> jelmer: ping
<vila> . o 0 (threads... sockets... You're soooo funny... not)
<vila> down to 50 tests leaking (from 2000 this morning) but.... --parallel=fork now hands......
 * vila cries
<vila> s/hands/hangs/
<fullermd> vila: Well, look at the bright side; if it's hung, it's not leaking   :p
<vila> fullermd: Yeah, I thought that for a while and then... the idea that fixing socket and thread related bugs can trigger another one that seems so unrelated, but I just realized how I should balance join(timeout) to track such hangs (since each one is a painful bug)
<vila> and, well, I stopped crying :)
<bialix> jelmer, lifeless: ohloh is failed to import bzr.dev branch: https://www.ohloh.net/p/bazaar/enlistments
<jam> well, I finally got up all of my static-tuple work up for review
<jam> split into 6 easier-to-review proposals
<jam> now I just need to find someone who will actually do a review.
<bialix> jam: nice post
<jfroy|work> I have a branch of a svn repository that has a bunch of ghost revisions and some sha1 mismatches
<jfroy|work> reconciling doesn't solve any of those things
<jfroy|work> is there a way to clean things up, perhaps by replaying each commit into a new branch?
<jfroy|work> I don't care about creating a new history -- I just want to preserve the content of the history
<bialix> jam: why in purple branch you don't merge blue branch; according to your method it should be done, no?
<bialix> oj, you merged green one
<bialix> nice
<jam> bialix: they are independent features, both based on one earlier feature
<bialix> I see now
<jam> (use static tuples in chk map is independent of using it in btree index, but both require static tuples to exist first)
<Tak> jfroy|work: ugh, I've had that a couple of times
<jam> wow, I've finally managed to have more commits in bzr than poolie. Not bad considering he had a 1500 commit head start :)
 * bialix dreaming about the tool of preserving annotations when only space changed inside the line
<jam> bialix: with the current code it would actually not be too hard to do
<bialix> not be too hard?
<Tak> I've transitioned to only dpush/pull/rebase with svn branches
<bialix> according to soe theory if you drop any "no" and "not" you'll see the truth
<bialix> too hard
<bialix> :-)
<jfroy|work> Tak: I used bzr-svn 0.3 on that branch and every version since then, including development version
<jfroy|work> So I blame it on that -- pretty sure bzr-svn 1.0 is reliable now
<jfroy|work> I just kind of want to start over with that branch w/r to bazaar (and I'm transitioning to a new svn repo soon)
<jam> bialix: well, define 'too hard', but there is 1 line of code that needs to be changed...
<jfroy|work> maybe I should just migrate using svn and filter out all the bzr-svn metadata out, but last time I looked at doing that, it didn't seem entirely trivial
<jam> well, 2 lines if you count word-wrap
<bialix> lol
<jam> _annotator_py.py line 143
<jam>         matcher = patiencediff.PatienceSequenceMatcher(None,
<jam>             parent_lines, text)
<jam> change that to something that creates matches ignoring whitespace
<jam> and boom
<jam> it is something I wanted to get to with annotation policies, etc
<jam> the code is mostly factored out to do so
<jam> I just didn't finish it
<bialix> cool
<jam> bialix: as a trivial example, you could do:
<jam> http://paste.ubuntu.com/288759/
<jam> well, technically this: http://paste.ubuntu.com/288760/
<jam> the previous paste had a typo where I used parent_lines twice
<jam> I'm not sure that ignoring whitespace changes completely is the right answer, since indentation is meaningful in python
<jam> change the .strip() to .rstrip()
<jam> and you have one that ignores changes to trailing whitespace
<jam> which would include \r\n => \n conversions
<bialix> well, in C identation is not so critical
<jam> sure
<jam> thus the change would be application specific
<jam> there are also those who feel you should do it via an AST
<jam> since changing
<bialix> and even in Python if you change identation, it's not always you're new author then
<jam> foo = bar
<jam> to foo = \
<jam>  bar
<jam> also is not a real change
<bialix> yes, this is too
<bialix> but more complex
<jam> bialix: anyway, annotation is a fuzzy concept anyway. but if you just want to ignore whitespace, my patch should work
<bialix> *nods*
<bialix> always when I think about this whitespace stuff I'm leaning to show 2 authors: original author and the second one who made whitespace changes only
<barry> hi everybody.  i'm starting to play with bzr-pipeline and i'm stuck on something.  is anybody able to help me?
<jam> barry: while usually I would refuse to help you on principle, right now I'm refusing because I need to get food. :)
<jam> but when I get back I'll give you a hand
<barry> jam: :D
<bialix> jam: ???
<tsmith> wow! BZR 2.0 is out!
<jfroy|work> mmm
<jfroy|work> branching lp:bzr/2.0 is stuck in "Finding revisions" slow mode
<jfroy|work> and isn't on the fast stream fetching code path
<jfroy|work> as far as I can tell anyways. I'm branching into a brand new 2.0 repo
<jfroy|work> nevermind
<jfroy|work> it just started
<jfroy|work> I guess finding revisions takes a while
<jfroy|work> could use better progress though, if possible
<arkanes_> whats the magic switch to get bzr to show tracebacks instead of  just "error"?
<bialix> bzr -Derror foo
<arkanes_> thanks
<Noldorin> can bzr handle symbolic links in repos?
<Noldorin> and additionally, can it handles LNK files?
<bob2> yes for symlinks
<bob2> I guess yes for shortcuts, since they're just normal files
<Noldorin> bob2: yeah, but i mean actually getting it to resolve the lnk file into the destination file
<soren> I'm trying to make use of the package branches on Launchpad. The package in question is of an upstream project that also uses bzr. Even though these branches share most of the current code, they share no ancestry. I would like to be able to get to the point where I can take the package branch, and merge from the upstream branch so that changes since the last sync point (upload of a new release to Ubuntu) get applied and nothing else.
<soren> I /thought/ I had done this..
<soren> I took the package branch, and did a "bzr merge -r 0..tag:RELEASE_someversion <upstream branch>".
<soren> Then I did "bzr revert .".
<soren> This reverted all the code changes (which was basically a load of conflicts (presumably because bzr has internal file id's for the files in the individual branches)), but kept the merge marker.
<soren> I committed this change.
<soren> At this point, I expected to be able to do a "bzr merge <upstream branch>" and end up with a branch with the changes between tag:RELEASE_someversion and tip applied.
<soren> However, the file id business came back to haunt me :)
<soren> It basically reported everything as being a big conflict.
<soren> My use of "bzr revert ." is new. I saw it in "bzr help revert". I've previously done something like this by doing "bzr diff | patch -p0 -R", but when I have to deal with conflicts, this does not give the expected results.
<bob2> Noldorin: isn't that a job for your os?
<Noldorin> bob2: it should be, yes. but this is windows we're talking about here :P
<soren> I suppose my question is: Is there are way to /really/ make bzr think that I've merged two branches (leading it to believe that files named the same are actually the same file, rather than remembering that they have no common ancestry and must as such be in conflict).
<fullermd> soren: Not at present.  Your problem is that you need a way to say 'these file-id's are the same file' (at the least).
<soren> fullermd: Right. Hm... That's a shame.
<tsmith> hey
<tsmith> in a nutshell waht's the major reason to upgrade from bzr 1.18 to 2.0?
<fullermd> There's discussion about it every so often, and there are proposals about it.  It's just a SMOP at this point.
<soren> fullermd: SMOP?
<tsmith> simple matter of programming
<soren> Simple Matter Of..
<soren> Ah.
<tsmith> he's saying it's very possible but no one takes or has the time
<tsmith> i'm firmly in the "has no time" category ;/
<tsmith> money seems to help SMOP be resolved, from what i see lol
<soren> I understand.
<fullermd> Everybody pretty much agrees in broad that it should be done.  It's just always a little ways down the stack.
<tsmith> does bzr have the concept of "HEAD"? like what if i want to diff -r10 to r12 (HEAD) but don't know it's r12?
<soren> I can't even figure out a proper way to do it manually. :(
<tsmith> it doesn't seem possible to do bzr diff -r10..HEAD
<soren> tsmith: -1
<soren> tsmith: -1 references the last commit.
<tsmith> -1?
<soren> Yes. It indexes from the end of the list rather than the beginning.
<awilkins> Or you can use an open ended range
<awilkins> bzr diff -r 10..
<soren> True, true.
<tsmith> -r120.. is taking FOREVER
<tsmith> but -r120..-1 was quite zippy
<awilkins> (not sure if that diffs against TREE or TIP though
<tsmith> what's the difference?
<awilkins> Ah, is the tree pretty large?
<tsmith> it has many branches and each branch is ~80 MB
<awilkins> Tip will be the last committed revision, which is a known state. Tree would be your current working tree.
<awilkins> Which it will have to iterate over to determine it's state
<awilkins> Although the dirstate stuff will help
<fullermd> Neither will go to the tree.  That would happen if you did '-r120'
<fullermd> '-rX..' and '-rX..-1' should be exactly equivalent.  Except when they're not.
 * awilkins believes fullermd but cannot see why r120..-1 would be faster than r120.. in that case
<tsmith> -r120..-1 took 0.673s; -r120.. took 3.822s
<tsmith> the diffs are the same
<tsmith> i did -r120..-1 first so it can't be memory cache
<fullermd> It's not impossible that it's doing something shupid.
<tsmith> like diffing every revision between 120 and 138?
<tsmith> soren, thank you very much for the -1 concept
<fullermd> No, but maybe something like building and walking the whole ancestry tree to figure out the latest rev.
<tsmith> yeah my diskk was quite busy
<fullermd> Though with 138 revs, unless it's a very broad history tree, that shouldn't take 3 seconds.
<fullermd> Unless it had to suck it all in from disk, maybe.  What's it like with the cache all warmed from the previous run?
<tsmith> 0m0.641s
<tsmith> alright here's a protip for everyone
<tsmith> to have Linux trash your disk cache:
<tsmith>  sudo sync ; sudo echo 3 | sudo tee /proc/sys/vm/drop_caches
<fullermd> So, same order of actual _work_, but spun a lot on the disk loading stuff presumably unused for doing it.
<tsmith> same command w/o cache: 0m6.330s
<pingveno> How do I branch at a specific revision of a branch?
<pingveno> Another branch, that is.
<fullermd> File a bug for it, please.  That magnitude difference is way out of line.
<tsmith> bzr branch -r
<fullermd> pingveno: branch -rX $SRC
<mathepic> bzr branch has a -r option
<tsmith> lol that's a simple question ;)
<pingveno> For revision?
<pingveno> -r = revision
<mathepic> -r specifies the revision number (--revision is its long one)
<awilkins> See `bzr help revisionspec` for all the manifold ways of stating revision numbers
<mathepic> You also can find the option listed under "bzr help branch", but it tells you to see "bzr help revisionspec"
<pingveno> Arg! This computer doesn't have bzr installed.
<mathepic> Download it. :D
<pingveno> I'm not the administrator on this computer. ;)
<pingveno> I wish my laptop was working...
<awilkins> pingveno: Windows or Linux?
<awilkins> pingveno: You can run it on either without admin rights
<pingveno> Both. It's a hardware issue.
<awilkins> No, "this" computer, what's it running
<mathepic> Does anyone know if its possible to get bzr cdiff working on windows or at least redirect it to bzr diff | colordiff (I have colordiff on cygwin)
<mathepic> Might not be the right place to ask that though, since its from bzrtools
<awilkins> mathepic: there's  `bzr diff --using colordiff
<pingveno> awilkins: The keyword is "can".
<tsmith> mathepic, i have an alias for "diff --using colordiff" nin my cygwin
<pingveno> Perhaps talking to the administrators would help...
<awilkins> pingveno: If you have a need to do things with bzr to be productive... I see no issues with downloading it and running it from your home folder / windows user profile
<pingveno> awilkins: I'll be seeing the guys who do the server administration tomorrow, so I'm not particularly worried. ;)
<mathepic> What happens if I aliase something to cdiff
<mathepic> Even though its already there
<mathepic> Alias seemed to overide it
<mathepic> Its not finding colordiff
<mathepic> I think its because colordiff is only available over bash
<mathepic> Is there a way to make bzr recognize commands available from bash
<fullermd> You mean for bzr aliases to run external commands?  No.
<mathepic> Thats not what I mean
<mathepic> I'm trying to alias bzr cdiff to bzr diff --using colordiff
<mathepic> colordiff is not an exe
<mathepic> so it doesn't recognize it as a program when trying to use it as a diff backend
<fullermd> Well, I presume it looks through the path.  A fully qualified path might work.
<fullermd> Don't really know.
<johnf> lifeless, jelmer; ping
<lifeless> johnf: hi?
<johnf> howdy
<johnf> so I wanted to discuss bzr packaging in debian and version numbers.
<johnf> Was hoping jelmer would be around as well. Maybe I should send an email to the packaging list
<lifeless> johnf: you should
<poolie> hello
<poolie> hello lifeless
<lifeless> hi poolie
<poolie> hi jam?
 * spiv yawns
<fullermd> That 'waking up' thing will kill you yet...
<poolie> mathepic: that should work, i'm not sure why not
<lifeless> -> food
<mathepic> It doesn't find colordiff though - I checked /cygwin/bin and colordiff is not an exe
<poolie> there is a colordiff plugin you could try
<mathepic> I'd prefer to make diff use my existing backend though
<poolie> mathepic: please file a bug for it
<poolie> it may be easy to fix
<mathepic> Okay, I will.
<mathepic> do I file it in the master project (Bazaar VCS and Tools) or the main one (Bazaar Version Control System)
<mathepic> nevermind, the master project doesn't bug track
<jam> poolie: hi, I can't stay long, though
<jam> thought I'd mention that the static tuple stuff is up for review
<jam> in hopefully 'bite-sized' chunks
<spiv> jam: oh, nice.  You got LP code review to cope with that?
<mathepic> Okay, I submitted the bug report
<zsquareplusc> and there is a problem... i have a branch. it says its out of date and i need to use "bzr update" when i do it says i need to check some files in a hidden folder. but it leaves the lock set.
<mathepic> exact message?
<zsquareplusc> i've deleteted the files, ran update -> error, break-lock, delete, update->error, break-lock... like 3 or four times until it stopped complaining and update actually worked :/
<zsquareplusc> bzr: ERROR: This tree contains left-over files from a failed operation.
<zsquareplusc>     Please examine <..>/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.
<zsquareplusc> my complaint is that it leaves the lock set and that i had to repeat the procedure multiple times
<mathepic> Report the bug
<poolie> jam, just tell me the email address for your wordpress username?
<igc> morning
<igc> hi jam, poolie, spiv
<poolie> hi igc
#bzr 2009-10-09
<jam> spiv: I cheated, I submitted each one as being proposed to the previous one, rather than bzr.dev
<poolie> jam, good point about testing the readdir change
<poolie> i had not yet done it
<igc> poolie, jam: http://bazaar-vcs.org/Benchmarks
<igc> lifeless, spiv, vila: ^^^
<spiv> igc: the numbers for samba are pretty weird!
<igc> spiv: very. fastimport does an implicit pack at the end so maybe there's an obscure bug in that
<igc> spiv: or maybe samba's trunk is very dull vs other branches?
<spiv> Also that the fully packed size is an order of magnitude smaller that git, unlike in the other tests.
<poolie> igc, i saw that earlier
<poolie> maybe before your changes
<igc> poolie: yep, new figures
<poolie> http://bazaarvcs.wordpress.com/2009/10/08/bzr-size-benchmarks/
<SamB_XP> are they pretty figures ?
<igc> poolie: the early hg figures were 'du -sb' instead of 'du -sh' - we're even more impressive now!
<poolie> ?
<poolie> oh, ignoring gas at the end of the files
<igc> yeah, real vs apparent size
<igc> actual size taken on disk is more meaningful IMO
<poolie> yes
<SamB_XP> not just your opinion!
<SamB_XP> in actual practice, too!
<mwhudson> wow yeah, those samba numbers are cracful
<lifeless> poolie: hai
<lifeless> igc: interesting
<igc> hi lifeless
<lifeless> igc: its not clear to me what the 'bzr branch' column means
<igc> lifeless: see 'how we tested'
<lifeless> I have
<igc> lifeless: maybe it needs a different column heading?
<igc> so it's what a user gets when they grab just the trunk
<lifeless> step four in the process looks like one command
<lifeless> 'bzr trunk only'
<lifeless> or something, would be clearer
<igc> ok
<lifeless> it would be good to have a comparison figure for that too with hg/git
<lifeless> I realise that that is trickier to accomplish in git/hg
<lifeless> so I wouldn't suggestspending mondo time on it
<lifeless> ayhow, those numbers are very encouraging; the samba project figure is a bit disappointing
<lifeless> I presume that fast-import is cleaning obslete now?
<igc> lifeless: I'm wondering if it's a bug in fast-import? or pack?
<igc> yep
<igc> lifeless: it does a pack at the end and then deletes the obsolete packs
<lifeless> igc: repository-details may help diagnose
<d1b> lifeless: figure out that group-pack problem re large binary files ?
<d1b>  / else. or should i file a bug.
<RenatoSilva> Is losing secondary comments the only disadvantage of bzr revert --forget-merges when merging branches?
<AfC> Is there a magic way to use meld when going through a conflicting file?
<AfC> I realize that `bzr diff --using meld` does just that, but in the case of a conflict I'm trying to figure out if there's a better way to use it than manually doing
<AfC> $ meld src/bindings/org/gnome/gtk/LinkButton.java.THIS src/bindings/org/gnome/gtk/LinkButton.java.OTHER
<AfC> as I just did
<lifeless> d1b: the one where I explained bzr is operating as designed ?
<lifeless> d1b: you can file a wishlist bug on that if you like
<jam> lifeless: what is that, no deltas between pack files?
<jam> hey igc, the numbers look interesting. very good except for samba looking a bit crazy
<igc> jam: yeah. I was hoping you'd get curious and tell me why :-)
<jam> igc: I'd need the source data
<jam> I thought there was something about samba copying a bunch of v3 or v4 stuff into another tree
<jam> it may be that we end up tracking those separately
<jam> and not getting the right cross-file compression
<jam> igc: is the data accessible somewhere?
<lifeless> jam: no, N identical parallel files
<jam> jelmer: ^^ can you comment about the shape of the samba tree?
<igc> jam: I'll push the imported repo somewhere and email you the location
<bob2> RenatoSilva: out of interest, why?
<igc> jam: also http://bazaar-vcs.org/BzrPopularity is interesting
<RenatoSilva> bob2: because I want to use it :)
<jam> lifeless: you're talking about d1b's issue, right? (or samba?)
<RenatoSilva> bob2: but I wonder if I'm doing WOP
<lifeless> jam: both possibly
<lifeless> jam: but intending to speak on dib's
<bob2> RenatoSilva: don't know what that means
<jam> lifeless: so the idea is that multiple identical files aren't getting fully de-duped?
<jam> igc: i agree. Interesting that we are above hg, and the 39k there is close to the 36.7k that downloaded bzr-setup 1.13
<RenatoSilva> bob2: http://uncyclopedia.wikia.com/wiki/Workaround_Oriented_Programming
<bob2> RenatoSilva: what are you working around?
<lifeless> ja	80MB images/movies
<lifeless> jam: 80MB movie files; separate file ids
<RenatoSilva> bob2: I don't know, that's why I wonder :)
<igc> jam: right: the 39k is the combination of the different Windows installers
<igc> roughly
<bob2> RenatoSilva: why are you reverting the merge metadata to begin with?
<jam> lifeless: yeah, and we explicitly cap a group based on file-id
<RenatoSilva> bob2: the Portuguese version is so much better description :) http://desciclo.pedia.ws/wiki/Programa%C3%A7%C3%A3o_Orientada_a_Gambiarras
<jam> igc: I mean that popcon says 39k for installs, and we have ~39k downloads
<lifeless> jam: we did use too much memory though
<jam> lifeless: how much?
<jam> I would expect at least 160MB
<jam> since they aren't likely to zlib well
<wgrant> Note that popcon isn't reliable at all.
<jam> wgrant: as in a margin of error of 100%, or 20%
<wgrant> jam: Potentially thousands of percent.
<AfC> I have no idea why you are counting downloads. I mean, other distros? People who don't have popcon installed?
<jam> I was mostly commenting about how close the numbers were
<wgrant> jam: It's optional, and well hidden in the installer.
<jam> AfC: number of downloads of the windows installer is probably pretty accurate, since there is one "canonical" source
<wgrant> jam: So not only will most people not have it turned on, those that do will be a very skewed sample.
<RenatoSilva> bob2: I'm not reverting, but since I knew about --forget-merges, I thought it was nice when the merge commit can summarize all the work done during the secondary branch
<bob2> RenatoSilva: that's what happens when you don't --forget-merges
<lifeless> jam: intwo swap n a 2400MB vm or something like that
<jam> lifeless: would it be a repack?
<lifeless> jam: no, single commit
<jam> hmm... something funny then
<lifeless> sorry, that was a 400MB vm I meant to type, damn hotel latency
<jam> I did quite a bit of testing w/ a 120MB text file
<jam> though that zlib'd very well
<AfC> jam: well, I can tell you that one of the biggest reasons that Sun screwed up Java was that they restricted mirroring *specifically* so that they could count downloads. That alone probably cost them the existence of .Net.
<AfC> jam: But in Open Source we don't count users because we *cannot*. ~10 distros with significant user bases, all of which have broad mirror networks. Corporate installations with no outside connectivity.
<AfC> you know all that of course
<AfC> which is why I was *flabbergasted* to see Emma mention that was on your website.
<jam> AfC: we phone home :)
<jam> wait... no we don't
<aglauser> Hi, new bzr user here (Windows)
<aglauser> A quick question about .bzrignore, if I may.
<lifeless> shoot
<spiv> aglauser: sure
<aglauser> I can't seem to work out the syntax for ignoring an entire subdirectory, with out ignoring other directories with the same name
<jam> aglauser: ./path/to/subdir
<jam> needs a '/'
<jam> you can use './foo' to get one at the top level
<RenatoSilva> bob2: as I said, I'm not reverting. But it seems to me that the only diff is that I lose the secondary revision info. That is, it's just like the diffs introduced by the merge were made directly in trunk
<aglauser> Does the /**/ glob still work, or was that only older versions?  I'm at 2.x
<fullermd> RenatoSilva: No, you ARE reverting.  You're just not reverting the _files_.  All you're doing is building up hurt against future merges.
<bob2> RenatoSilva: it is unclear to me why you're doing this, but ok
<jam> aglauser: ** should work
<fullermd> I mean, if you don't want to track merges, you can just use CVS   :p
<bob2> RenatoSilva: new versions of bzr already hide the merged revisions in log output, if that is your concern
<RenatoSilva> bob2: and that seems nice to me when e.g. your secondary branch has only one commit or all the changes can be summarized on a single commit comment
<RenatoSilva> fullermd: huh???
<bob2> RenatoSilva: which is what bzr does already
<bob2> RenatoSilva: 'bzr log' on 1.18+ iirc
<RenatoSilva> fullermd: I'm NOT reverting. I'm writing on IRC. I'm talking about an idea. I'm not even running bzr. So huh?
<fullermd> Well, I'm not putting 2 level teaspoons of arsenic in my coffee either, but I wouldn't expect people on IRC to tell me it's a good idea if I suggested it   :p
<fullermd> ...  well, OK, maybe they would...
<SamB_XP> fullermd: tell me who so I can avoid them!
<aglauser> Thanks, it seems I've got the right pattern now.  I think the ./ was the key
<RenatoSilva> bob2: ok, but I want to know of any other problems IF I use --forget-merges
<bob2> RenatoSilva: you lose all the merge metadata
<bob2> RenatoSilva: I don't understand why you would do it at all
<spiv> RenatoSilva: you lose bzr's record that those revisions are already merged.  So it's no better than applying a diff with patch.  bzr uses the revision history to calculate merges, so if you forget that data then bzr can't calculate merges as usefully... which means you will get unnecessary conflicts.
<spiv> Because the next time you merge that branch, or another branch that does incorporate those revisions, bzr will think it needs to reapply those changes, because it has no record of them being merged.
<RenatoSilva> bob2: bob2: my main, current reason is that I have branches with a single commmit. When I merge them I think the merge look in qlog is useless. It's a single commit and would be cleaner to have it only in the trunk line, just like I never had used another branch, but committed directly into trunk. The secondary branch was just a sandbox.
<Peng_> RenatoSilva: You could use "pull" instead of "merge", I suppose.
<spiv> So use pull, or even "bzr merge --pull".
<bob2> or fix qlog to work like log
<SamB_XP> bob2: that would hardly be a fix!
<fullermd> Actually, qlog already IS collapsed by default...
<spiv> Right, there's no reason why qlog couldn't have a heuristic to hide single-revision branches from the mainline by default (I'm surprised it doesn't already).
<jam> spiv: it defaults to hiding everything until you click the twisty
<spiv> But if the concern is literally "I want the new revision to be directly on the end of the existing history", then that's what pull is for, so I'd say use that.
<RenatoSilva> spiv: those conficts only if I try to merge the updated secondary branch again, right? But in my case I'd delete the branch right after merging. But ok, it's the same as diff + patch, which seems easier btw :)
<jam> I happen to disagree with RenatoSilva's analysis that it is "worthless"
<jam> but perhaps..
<RenatoSilva> Peng_: I use pull when I can, but sometimes I need merge
<lifeless> RenatoSilva: I think you should do this if it makes you happy.
<lifeless> RenatoSilva: understand that *if* you have other people building on the source branch, you will be creating future conflicts when you do this.
<RenatoSilva> bob2: and the branches with a single commit, well when I change them I tend to uncommit and commit again...
<lifeless> bob2: Peng_: fullermd: spiv: This is a great example of one of the use cases in my history-edting manfesto
<spiv> lifeless: *nod*
<RenatoSilva> jam: what's worthless?
<jam> lifeless: I'm curious if you saw http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html from today
<jam> its what I did to get the static-tuple stuff up for review
<jam> breaks the changes into diffs post-facto, *and* preserves annotations
 * RenatoSilva gave up of using rebase, ihrc the timeline becomes unordered (the rebased revision is greater in number, but older in date o.O )
 * RenatoSilva suffers the uncommit syndrome
 * RenatoSilva starts to realize that he just can't fight against the merge fact
<spiv> jam: and interestingly they still appear on https://code.edge.launchpad.net/bzr/+activereviews
<jam> spiv: they are on the bzr project, and I requested bzr-core review them
<spiv> jam: although it's a shame that the ordering isn't dead-obvious, but it's not hard to discover.
<jam> spiv: yeah, I submitted them "in order"
<jam> so if you go by the "22 hours ago" vs "10 hours ago" you can use that as a guide :)
<jam> also it is sorted correctly in my view, but I see them in the "I am waiting on" section.
<lifeless> jam: I hadn't no
<lifeless> not much time to read during sprints
<spiv> jam: you also get forward and back links, of a sort, on the individual branch pages.
<jam> spiv: ah sure, because I requested to merge it into the other branch
<jam> it is unfortunate I'll probably have to do the "merged" manually
<spiv> jam: "proposal or merging into X", and "N branches proposed for merging into this one"
<jam> but that is worth having small diffs for review
<lifeless> jam: thats what I want loom to manage
<jam> lifeless: the main thing is doing it at the *end* after I've done all the work in a dogpile
<lifeless> jam: yes
<jam> especially when exploring, it is hard to figure out what your separations are going to be (at least for me)
<jam> also, it allows avoiding the "spurious merges" between the loom threads
<lifeless> jam: I'm saying loom should support post hoc separation
<jam> lifeless: sure
<jam> I think the main difference is that loom would probably want to start from the 'upstream' thread, and I was more branching from downstream
<jam> I think 'up' does basically what I was doing with my merges
<lifeless> jam: I don't see why it would :)
<RenatoSilva> are plugins written to 1.x fully compatible with bzr 2.0?
<SamB_XP> RenatoSilva: depends
<jam> RenatoSilva: many, but I wouldn't say all
<SamB_XP> but mostly they can be easily made to work
<SamB_XP> if they worked for a recent 1.x
<jam> 1.18 vs 2.0 is "as big" of a difference as 1.17 vs 1.18
<jam> interestingly enough 2.0 vs 2.1 will be a bigger difference
<jam> but we are changing numbering systems
<RenatoSilva> jam: iirc I use xmloutput and bzr-email only
<jam> so it is actually 2.0.0 vs 2.1.0
<RenatoSilva> jam: will wait a bit more then :)
<jam> RenatoSilva: bzr-email works fine
<jam> xmloutput... I know we bundle it with the windows installer
<jam> so there should be *a* version that just works
<lifeless> RenatoSilva: move to 2.0.0 as soon as you can ;)
 * igc lunch
<RenatoSilva> jam: with the windows installer? not in 1.x right? Can't remember of it being listed there
<RenatoSilva> jam: I submitted some fixes to xmloutput that were merged but not release,d it is still in 0.8.3. So either you have a modified version in 2.0 or the 0.8.3 or trunk has no need to change in 0.8.3 right
<jam> RenatoSilva: I think we started with 2.0
<jam> RenatoSilva: we packaged "bzr-xmloutput-release = 0.8.5"
<jam> not sure what makes you say it is still at 0.8.3, but there is a tag in the branch @ 0.8.5
<RenatoSilva> jam: you're from canonical right? it would be nice if you release your private, improved version of bzr-email. The one currently there is a bit simple
<jam> RenatoSilva: I don't know of a "private, improved version"
<jam> I use the stock version from "bzr branch lp:bzr-email"
<RenatoSilva> jam: release 0.8.5???? let me check that, I thought I was subscribed to the branch....
<jam> but yes, I' min canonical
<RenatoSilva> jam: e.g. public bzr-email does not have html, and does not allow customization of body/subject, and does not work for me without a patch
<jam> RenatoSilva: I thought I saw something about html being mentioned on the mailing list, but I've never used it or seen it
<jam> RenatoSilva: "doesn't work for you" ?
<jam> have you proposed the patch?
<RenatoSilva> jam: the emails sent by LP when you change branches are done by something similar to bzr-email, but not released to the public
<lifeless> RenatoSilva: LP's code is public
<lifeless> RenatoSilva: its not a bzr plugin though
<RenatoSilva> jam: something about TLS
<jam> RenatoSilva: grab the latest from the bzr-email branch
<jam> I'm pretty sure that is fixed
<jam> may not be in a tarball, etc
<jam> though it is packaged for Karmic ( I checked with james_w just a couple weeks ago)
<RenatoSilva> jam: this is the patch to make it work: https://code.launchpad.net/~renatosilva/bzr-email/ignore-tls
<RenatoSilva> jam: I don't know if you mean what's done here
<jam> http://bazaar.launchpad.net/~renatosilva/bzr-email/ignore-tls/revision/40
<jam> though you build on top of that, so obviously something is different in your situation
<RenatoSilva> jam: see bug https://bugs.launchpad.net/bzr-email/+bug/388723
<ubottu> Launchpad bug 388723 in bzr-email "SSL error on starttls()" [Undecided,New]
<RenatoSilva> jam: it's a hand shake error, maybe and likely server problem, but I thought it would be nice to allow users not being affected by such broken servers
<RenatoSilva> jam: so I created the disabling option, it's working fine with me now.
<RenatoSilva> latest version of bzr-xmloutput is 0.8.4, from where did you get 0.8.5 to pack together with 2.0?
<RenatoSilva> https://launchpad.net/bzr-xmloutput
<lifeless> poolie: gnight; we can try to hook up sunday avo or something
<lifeless> poolie: or perhaps my morning (7hr from now)
<mneptok> lifeless: you're not in AUS/NZ?
<poolie> ok
<RenatoSilva> thanks all
<poolie> wow nice work igc
<poolie> you should send that to the bazaar list too
<igc> poolie: which bit?
<poolie> the benchmarks and the mail about them
<igc> ok
<poolie> if you want to
<poolie> hi spiv
<spiv> poolie: good afternoon
<poolie> how's stuff? what are you up to?
<spiv> I'm reading through jam's patch flood.
<spiv> I'm greatly looking forward to cutting our memory consumption!
<igc> spiv: me too! I was hoping you'd choose to review those patches (with your Python internals knowledge)
<spiv> Also used -Drelock to squash a simple (and probably not very wasteful in practice) relock in cmd_missing, mainly to see what it feels like.  I'm going to leave -Drelock on in my bazaar.conf for a while and see if that encourages me to squash some easy bugs.
<spiv> It's a bit depressing that almost every command trips it, though.
<spiv> I'm particularly wondering about extending the -Drelock thing to allow writing test assertions about it.
<spiv> I don't know that we really want to explicitly add "assertNoRelockingHappened" or whatever to lots of individual tests, but it would be nice to find and easy-yet-firm way to drive it towards zero instances.
<spiv> But maybe blackbox tests could test for that by default, and then individual tests or test cases could opt out?
<spiv> Oh, and I spent some time (re)reading the summary of the London meeting.
<d1b> lifeless: no.
<d1b> the one where it took 11 minutes to commit the large files into the bzr repo.
<d1b>  also most 4 times longer than the time to copy the files.
<d1b> however, i am tempted to go and have a look at the code, and submit a patch for where a file is sufficiently large to store and make comparisons against a sha1 or similar hash of the file.
<poolie> spiv, could you review jam's cix patch, if you didn't alread?
<d1b> that obviously will require other changes to ensure that the binary files are kept avilable for the various locations in the repository (if one changes the others shouldn't etc.).
<poolie> d1b, you're committing a rename of a large file?
<d1b> poolie: it was a worst case senario i ran bzr 2 against, 5 167mb video files.
<d1b> the files were identical
<poolie> under different names?
<d1b> poolie: yes.
<poolie> k
<poolie> probably best to start by profiling it and looking at the developer docs on profiling
<d1b> poolie: lifeless already has a kcachegrind / valgrind dump thingy.
<d1b> poolie: a workaround would be to not try to group-compress large binary files.
<spiv> poolie: ok
<poolie> cool
<igc> spiv: what's .bzr/upload for? any ideas? why would there be a xxxxxx.reconcile file in there?
<igc> poolie: ^^^
<spiv> igc: do you mean .bzr/repository/upload ?
<spiv> igc: it's where pack files are created initially.  Once all the content has been added and the pack file finished, then they are moved from upload/ to packs/ and then added to pack-names.
<spiv> igc: similarly indices.
<igc> spiv: thanks
<spiv> igc: the name they are given in upload/ has a suffix that varies depending on which code path created it.  *.reconcile is made by the ReconcilePacker (or the GC variant, etc)
<igc> spiv: right. so a crash of reconcile leaves a xxx.reconcile file there. It makes sense now
<spiv> igc: which is a long-winded way of saying "you probably hit ^C or similar during a 'bzr reconcile' at some time :)"
<igc> spiv: nah, reconcile is falling over for keybuk
<spiv> Ah, right.
<spiv> Yes, that'd do it.
<igc> i can reproduce it
<arjenAU> lifeless: i am going to kick you later for being too smart a nerd.
<arjenAU> lifeless: ok so skipping the nistallation bit... how do I actually use the bzr-hg tool. commands, syntax on bzr branch, whatever??
<vila> hi all
<igc> bbiab
<poolie> nice post there
<poolie> arjenAU: basically you can just urls to hg repositories
<poolie> there are no new commands
<arjenAU> poolie: ok so back one step. how do I install the sucker
<arjenAU> poolie: all these plugins are lacking in docs. I'm not a python person
<poolie> are you  on ubuntu?
<poolie> i think it's in the ppa?
<arjenAU> hmm didn't show up in synaptic. I am on the PPA
<poolie> no, it's not
<arjenAU> I grabbed the tarball and did python thingie build and then install. no worky
<bialix> hello all
<bialix> igc: what is scary numbers for Samba import?
<poolie> bialix, this one i think: https://launchpadlibrarian.net/21176883/gwibber.64x64.png
<poolie> blah
<poolie> http://bazaar-vcs.org/Benchmarks
<bialix> yes, benchmarks
<bialix> and why Firefox trunk bigger than import?
<bialix> questions, questions...
<poolie> different packing maybe?
<bialix> or trunk is branch + tree?
<bialix> and import is treeless?
<bialix> somebody should explain
<bialix> really guys
<poolie> well, reply to ian and ask
<bialix> if it's even for me wtf -- then you can expect many gibes from outside
<poolie> there is a page of details but it doesn't say what trunk only is
 * poolie burned out 
<poolie> good night
<bialix> night
<wgrant> Why does the bzr home page now say "rockin'" and give a nonsensical user count?
<bialix> where?
<wgrant> Near the bottom, just above the anonymous logos.
<bialix> ah see
<wgrant> I recognise them, but I imagine most will not...
 * bialix don't know what is purple cog icon means
 * bialix as well as globe
<bialix> I dunno, emmajane and igc constantly improving this page
<bialix> there is branch with page source
<wgrant> The purple thing is GNOME Do, the globe is Gwibber.
<bialix> clearly Gnome/Ubuntu centric point of view
 * bialix goes away for my work on windows xp
<bialix> :-P
<mneptok> bialix: do you know of any Windows software projects using bzr? if so, suggest they be added.
<igc> hi bialix
<igc> bialix: I just run the commands. Exactly what pack does under the covers is outside my depth of knowledge
<igc> bialix: but fast-import imports a whole repository while 'branch' just grabs the revisions referenced by trunk
<bialix> mneptok: it should be a BIG project right? no I don't know
<mneptok> bialix: not necessarily. but something at least noteworthy.
<bialix> igc: I suppose Bazaar Import size is the size of treeless shared repo? and trunk is the sizer branch with tree?
<bialix> mneptok: oh, I know many. QBzr per example. It will count?
<bialix> PhotoBatch, Leo editor
<bialix> there is page with links to these projects
<mneptok> bialix: ask emmajane or igc :)
<igc> bialix: import size is just repo size - see "how we measured" link
<bialix> du -sh?
<igc> bialix: branch size is still just the .bzr size - there's no point comparing the working tree as it's the same across each tool
<bialix> that's nice that I know what du is
<bialix> but this is not windows utility
<igc> h=human readable
<igc> s=summary (don't show each subdirectory)
<bialix> will be much simpler if you just wrote in plain english
<igc> the plain english bit is the directories being compared :-)
<bialix> mneptok: http://bazaar-vcs.org/WhoUsesBzr
<bialix> igc: then I'm bad in english today. Sorry and nm
<maxb> bzr qlog is amazing, but its revision sorting algorithm is a bit suboptimal. It seems to optimize keeping the trunk revisions consecutively displayed, at the cost of vastly increasing the horizontal space used for the graph
<bialix> maxb: this is because in bzr mainline is special
<bialix> igc: also I think 36K windows downloads is extreme.
<bialix> igc: for most releases this number is order of magnitude smaller
<bialix> I dunno why 1.13.1 so big, but it seems pretty wrong for me
<wgrant> Attempting to put correct numbers there is an exercise in foolishness.
<bialix> I agree
<bialix> I dunno why there is need numbers
<bialix> foolishness is good word
 * wgrant should probably check the list for similar complaints.
<bialix> recent thread is 42,000 too much
<ploum> Hello
<ploum> I've a big problem
<ploum> I cannot create repository on my http server anymore
<ploum> I receive :
<ploum> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was made: 'chroot-3102421996:///'.")
<igc> bialix: would your company be interested in putting your logo on our home page?
<spiv> ploum: there's a bug about that, with a workaround:
<spiv> ploum: https://bugs.edge.launchpad.net/bzr/+bug/348308 and the workaround is in comment #8
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged]
<ploum> funny, I was already subscribed to this bug but it was so old
<ploum> thanks for the info
<bialix> igc: unlikely :-)
<bialix> we are very small company working in narrow niche
<igc> bialix: we're happy to promote companies and projects using Bazaar there
<igc> bialix: but QBzr is probably too close to Bazaar itself sorry
<igc> bialix: i.e. users won't see it as a separate project to Bazaar
<igc> bialix: by user, I mean typical home page visitor
<bialix> igc>	bialix: but QBzr is probably too close to Bazaar itself sorry -- I know, it was joke
<bialix> igc: for my company the problem is we made embedded systems not software per se
<bialix> so we have hardware which you can take in hands
<bialix> software is just companion
<igc> bialix: ah - ok
<igc> night all - have a good weekend
<bialix> bye
<spiv> igc: g'night
<igc> night spiv
<faldridge> can anybody help me understand the difference between bzr checkout svn+ssh://foo.com/foo vs bzr svn-import svn+ssh:///foo.com/foo?
<faldridge> the main reason for my question is that I've tried the former approach twice on a history-rich svn repo and I've gotten failures both times, so I'm considering trying the other approach.
<faldridge> but I don't understand the example at <http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html> on using svn-import
<asabil> hi all
<faldridge> hi
<bialix> faldridge: can you tried to simply `bzr branch svn+ssh://foo.com/foo`?
<bialix> faldridge: the main author of bzr-svn is jelmer
<bialix> faldridge: always when I need a copy of svn repo of upstream I'm just running bzr branch
<faldridge> bialix: I have not tried that; it wasn't listed on the bzr-svn plugin doc.  What does that do differently than bzr checkout?
<bialix> bzr branch will create bzr mirror of svn repo
<bialix> I think it's similar to svn-import
<bialix> what is the product of bzr checkout I really don;t know
<bialix> can you show me the output of bzr info -v in the your checkout?
<bialix> pastebin?
<faldridge> bialix: I can't right now; the bz checkout svn+ssh method is also reaaaaaaally slow, and I'm in the middle of trying to grab a different history rich svn repo right now....
<bialix> ah
<faldridge> bialix: is the bzr branch method faster?  I could always kill the process and try it
<bialix> I dunno, really
<bialix> I don't expert in bzr-svn
<bialix> in theory branch and checkout should be the same speed
<faldridge> bialix: ok, but do you know if doing bzr branch on an svn repo is significantly slower than bzr branch on a bzr repo?
<bialix> yes
<bialix> because it converts from svn to bzr format on the fly
<faldridge> right, thought so.
<naoki> history horizon is strongly required by bzr-svn users.
<bialix> history horizon?
<faldridge> I really want to manage my local branches of svn-based projects with bzr, but the slowness and erratic failing may be a deal-breaker.
<naoki> bzr use single connection. svn use a connection per revision.
<bialix> it's not implemented yet
<naoki> So bzr branch from remote svn comsumes long time.
<bialix> faldridge: try to catch jelmer later (after several hours)
<faldridge> bialix: will do, thanks
<faldridge> naoki: is there a reason bzr doesn't use multiple connections?
<naoki> I don't know.
<faldridge> possibly because it doesn't need them unless pulling from an svn repo
<jackalborn> i have a quick question if anyone is around
<bialix> shout
<jackalborn> i was wondering if it was possible to create a centralized model using my web page on godaddy as a server with bazaar
<jackalborn> and if so if there was any information i could read about how to go about setting it up
<jackalborn> that anyone knew of
<bialix> what is godaddy?
<faldridge> bialix: a popular web host
<jackalborn> oh sorry, i mean to say my web host
<bialix> what access do you have to it?
<jackalborn> full as far as i know
<bialix> http/ftp/sft/ssh?
<jackalborn> lemme see
<jackalborn> http/ftp/ssl/ssh?
<bialix> can you install bzr there?
<jackalborn> it uses MySQL databases
<bialix> bzr don't use MySQL
<bialix> there is 2 modes to access bzr branches: over dumb transport (http/ftp) and over smart server (bzr/bzr+ssh/bzr+hhtp)
<bialix> the latter require bzr installed on your host
<bialix> the former does not
<bialix> if you have ssh then you have sftp IMO, sftp is also dumb transport
<bialix> dumb trabsport access is usually slower as you understand
<bialix> dumb transport access is usually slower as you understand
<jackalborn> is one dumb transport better over another?
<bialix> http is read-only
<bialix> ftp is not really recommended
<bialix> sftp is good enough because it's based on SSH connections
<bialix> I'd say sftp for write access, and http for read-only
<jackalborn> sounds do able
<bialix> ftp is often works but sometimes there is quircks with different ftp servers implementations
<jackalborn> looks to me like using SSH requires me to move my website to a new server and update site code / hurt my brain
<bialix> jackalborn: just remember there is no special ACL support
<bialix> so everything exposed via public_html will be readable by anyone, usually
<jackalborn> i'm sorry i dont even know what ACL is :/
<jackalborn> ah got it
<jackalborn> so the other option is setting up a machine at home and putting bzr on it and having it act as a central server?
<bialix> ACL == access control list
<bialix> I'm not sure what is central server for you
<jackalborn> i see
<bialix> how many people will work with it?
<jackalborn> i've only ever used CVS and a little SVN so  this is kinda new to me
<jackalborn> 5 or less i'm suspecting
<jackalborn> probably 3 for now
<bialix> it should be private repo?
<jackalborn> well i dont want just anyone coming along and walking off with our assets or code
<jackalborn> if thats what you mean
<bialix> there is bzr_access script to setup restricted access to smart server
<bialix> jackalborn: so you need restricted access for your team
<bialix> either via sftp and don't expose it via http
<bialix> or via bzr+ssh
<bialix> in any case sftp/ssh
<jackalborn> gotcha
<bialix> I've used ftp in the past
<bialix> to communicate with autsourcers
<jackalborn> but straigh ftp is no dice right?
<bialix> it works good enough
<bialix> it depends
<bialix> how good is your ftp server
<bialix> bzr require append access
<bialix> or this is called feature?
<jackalborn> i dont realy know honestly
<bialix> raname support and so on
<bialix> *rename
<bialix> it will be easier for you to just try
<jackalborn> yeah
<bialix> bzr init ftp://...
<bialix> bzr push ftp://...
<jackalborn> i'll have to go about setting it up then
<bialix> with any small history
<jackalborn> so really its just making a folder on the ftp and having bzr access it?
<bialix> yep
<jackalborn> wowo
<jackalborn> will that should be an eaasy test then
<bialix> you can even setup password for ftp access in authentication.conf config file
<bialix> so you don't need to type it everytime
<jackalborn> sounds good
<jackalborn> thank you very much for your help
<bialix> always happy to help (tm)
<jackalborn> i look forward to testing this out when i get the guts to once again wade into the horrors that is working with my web server. first thing in the morning :)
<jackalborn> thanks bialix, have a good night
<bialix> bye, it's a still day for me
<sender> how should I proceed if I need a branch inside a branch?
<bialix> just branch and all
<sender> bialix: what I have now is one branch containing everything, I use split to move a directory from that branch to a separate branch. can I just run pull in the subbranch and then commit in the main branch?
<bialix> are you asking about Nested Trees support?
<sender> bialix: I guess so :)
<bialix> it's not implemented yet
<bialix> there is plugin that emulates it
<sender> ok, interesting
<sender> scmproj, right? can this be used in prod?
<bialix> I'm the author and use it in production
<bialix> there is many rough edges
<bialix> but you can pull in subbranch and then commit
<bialix> it's far from ideal
<bialix> honestly
<bialix> it's more like meccano
<bialix> but it really works
<sender> ghehe :) i like meccano
<sender> Someone here tries to do this with split and join... I guess these are more configuration tools, and not the way to do Nested right?
<bialix> split and join is the part of Nested Trees
<bialix> scmproj is indifferent to split and join
<bialix> scmproj works on the set of branches
<bialix> you can define how you want to lay out your branches and then run some commands for all your branches in one go
<bialix> you can "construct" your own command
<bialix> it's a bit similar to how git works with submodules
<sender> do you define a sort of recipe?
<bialix> no
<bialix> there is generic command project-command or pcmd
<bialix> you supply one or several bzr commands to it, using some templates and then it runs your commands for each branch
<sender> sounds good
<bialix> e.g. to get bzr status for all branches you run: bzr pcmd st
<bialix> to get latest log message: bzr pcmd "log -r-1 --short"
<bialix> and so on
<bialix> under the hood scmproj just cd to each branch and run the command there
<bialix> so you get N separtate results for N branches, not 1 integrated result
<bialix> this is major limitation
<bialix> Nested Tress should work seemless
<bialix> Nested Tress should work seamless
<sender> ok, sounds workable though
<bialix> one my working project consist 3 branches
<bialix> 1 main branch
<bialix> 1 library
<bialix> 1 interface headers to communicate with another program
<bialix> if your branches is more or less separate, then you don't have much troubles
<sender> ok, ive got one repo, pulled 2 branches in
<sender> now what? :)
<sender> bzr pcmd st gives, error: not a branch
<bialix> to start with scmproj: first you need to initialize configuration
<bialix> bzr pinit PATH
<bialix> it will create .scmproj directory with branch inside it
<bialix> there is project.cfg
<bialix> you need to describe your components in project.cfg
<bialix> at least you should specify RELPATH for each component
<sender> ok, that's the source?
<bialix> source?
<bialix> what do you mean?
<sender> where you are branching from
<bialix> BRANCH_URL is source
<sender> ok, what is RELPATH?
<bialix> local relative path of each branch root
<bialix> relative to directory where .scmproj resides
<sender> ofcourse, thnx :)
<sender> So RELPATH is mandatory, I guess BRANCH_URL can come from bzr info?
<bialix> sender: http://pastebin.com/d42cfdd5f
<bialix> RELPATH is mandatory for all local operations
<bialix> BRANCH_URL is mandatory to clone existing project, update it or push it back
<sender> ok, got it right now
<bialix> you can have one branch right in the root of your project with RELPATH = .
<bialix> I find this handy
<sender> that's great
<sender> this has so much potential
<bialix> it's easy as lego
<sender> meccano, lego ;)
<bialix> and somewhat limited as I said
<bialix> right
<bialix> you saw logo?
<sender> logo writer?
<sender> bzr pcmb st now gives me # Done.
<bialix> no, picture of scmproj: https://launchpad.net/bzr-scmproj
<sender> let's try pull
<sender> ghehe :)
<bialix> bzr pcmb st now gives me # Done. <-- so there is no components defined
<sender> oh :/
<bialix> edit project.cfg
<bialix> this is first thing you need to do to setup project as a whole
<sender> http://pastebin.com/d6221495
<bialix> it should be http://pastebin.com/d32e2e632
<bialix> component is mandatory keyword
<sender> ok
<flo_hns> hello all. I'd like to setup a hook on my bzr server to forbid pushes by commiter with a badly set email address. What hook should i use ? the doc is very scarce...
<sender> easy fix... bzr pcmd st now shows me clear output about my branches
<bialix> sender: good
<sender> bialix, missing works fine, now pull
<lifeless> moin
<sender> works great, awesome!
<bialix> flo_hns: pre_change_branch_tip I suppose
<bialix> hi lifeless
<bialix> sender: cool
 * bialix goes for lunch
<flo_hns> bialix: ok thanks, I'll try it. and how can I cancel a push ? possibly with an error message ? shoud I return false, or call something ... ?
<lifeless> arjenAU: ?
<sender> bialix: thanx a lot!
<lifeless> mneptok: Montreal
<bialix> flo_hns: ask lifeless, he is guru
<arjenAU> lifeless: for a non-python person, installing a plugin is a non-trivial process. I do it once in many months and thus I have absolutely no idea what to do. and then there's no docs on what I get. plus it didn't actually install afaics (jaunty from lp dl of hg-bzr).
<flo_hns> lifeless: hello. I'd like to add a hook to my server, to forbid pushes by commiters who have a badly set email. which hook should I override, and how can I cancel a push from there ?
<arjenAU> lifeless: the README does not tell me anything.
<arjenAU> lifeless: but you're a nice guy and you do great work. but please bridge the gap to lesser gods ;-)
<bialix> sender: bzr pci will commit entire project + .scmproj config
<lifeless> arjenAU: hmm I try to write docs about it in plugins :) - which plugin was this that didn't ell you anything?
<lifeless> flo_hns: bzr help hooks | grep pre_tip_change
<lifeless> flo_hns: there are docs there
<arjenAU> lifeless: hg-bzr. just the README of the tarball saying what to do to get it installed would be fab. I think it's about 2 lines. except it didn't work on my jaunty. the install phase did not install anything in the bzrlib/plugins dir.
<flo_hns> lifeless: indeed :) thanks!
<arjenAU> lifeless: I did sudo python setup.py install or whatever the py was
<lifeless> arjenAU: ah; well please file ugs, thoug jelmer is really the dude for bzr-hg these days; I last touched it years ago
<lifeless> s/ugs/bugs
<arjenAU> lifeless: hum. the amount of effort involved in filing a bug for this kind of basic stuff.... yes I know i'm spending time on the whinge also
<lifeless> arjenAU: use the email interface :)
<lifeless> subject: <>
<lifeless> to: new@bugs.launchpad.net
<lifeless>  affects bzr-email
<lifeless>  done
<arjenAU> lifeless: that's intersting. so how does it know which project
<lifeless> blah blah blah
<arjenAU> lifeless: ah. that makes it more handy
<zombor> hi, im trying to install 2.0 on xubuntu 8.10, but when i add the repo and apt-get update, it says "Ign https://launchpad.net intrepid Release"
<zombor> any idea why?
<zombor> if i use synaptic, i get "GPG error: https://launchpad.net intrepid Release: The following signatures were invalid: NODATA 2Failed to fetch https://launchpad.net/~bzr/+archive/dists/intrepid/main/i18n/Translation-en_US.bz2"
<Mez> bzr: ERROR: KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/.bzr/repository/')
<Mez> is not compatible with
<Mez> KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/repository/')
<Mez> different rich-root support
<Mez> Can someone explain?
<Mez> (this is me trying to branch something.
<beuno> Mez, sure
<beuno> you'the branch you're trying to get is a newer format
<beuno> and you have a local shared repository with an older format
<Mez> coool. bzr upgrade on the repo seems to have worked.
<beuno> :)
<Mez> or not ...
 * Mez upgrades trunk too
<Mez> [##############-     ] Copying content into repository.:Transferring revisions 0/668
<Mez> stuck :(
<beuno> Mez, what does .bzr.log say about it?
<Mez> 83.758  Resizing the inventory entry cache from 23074 to 50752
<Mez> grrr
<Mez> 11.620  creating repository in file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/.
<Mez> 16.626  Resizing the inventory entry cache from 10240 to 23074
<lifeless> Mez: be patient
<Mez> 83.758  Resizing the inventory entry cache from 23074 to 50752
<beuno> lifeless, hi!
<lifeless> Mez: it will ive an update only at 100 rev s
<beuno> lifeless, do you know if we already have a bug about bzr not inviting you to upgrade when it you try to interact with 2a?
<lifeless> beuno: do you mean 'bzr should invite' ?
 * beuno has +filebug open, and is not afraid to use it
<beuno> lifeless, well, something better than:
<beuno> 08:11 < Mez> bzr: ERROR: KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/.bzr/repository/')
<beuno> 08:11 < Mez> is not compatible with
<beuno> 08:11 < Mez> KnitPackRepository('file:///home/mez/development/bzr/io/mobilefun/projects/trunk/.bzr/repository/')
<beuno> 08:11 < Mez> different rich-root support
<lifeless> beuno: I don't think we do
 * beuno files it
<Tak> is there any situation when upgrading would be bad?
<Tak> (at the point when that error is encountered)
<beuno> Tak, well, maybe you end up upgrading trunk, and other users with older versions of bzr can't access it anymore
<beuno> but, well, this becomes a chicken and egg problem at some point
<Tak> right - if you can't pull from your other branch, *something* has to happen
<Tak> I'm wondering if bzr should just go ahead and do the upgrade
<beuno> lifeless, maybe bug 53271 represents it?
<ubottu> Launchpad bug 53271 in bzr "Should suggest 'bzr upgrade' when giving error about unsupported format" [Medium,Confirmed] https://launchpad.net/bugs/53271
<Mez> lifeless: It just feels like it's taking WAYYYYY too long.
<beuno> Mez, how big is the branch?
<lifeless> beuno: no, I don't think it does
<lifeless> Mez: strace it; don't interrupt :)
<Mez> 931M ... :(
<beuno> Mez, relax, it will take a while
<Mez> hasn't taken this long to branch before though....
<Mez> and strace isn't giving ANY output
<Mez> tell a lie, now it does.
<beuno> Mez, the new format needs to do a few extra things
<beuno> it's *much* faster and smaller, but it needs to do a lot of heavy lifting to convert
<Mez> beuno: so it's going to take this long every time I branch ?
<beuno> Mez, no, the upgrade is a one-off thing
<beuno> Mez, what version of bzr are you using?
<Mez> beuno: 2.0.0.
<spiv> It's more that it has to extract and decompress all the data from the old format, and the old format is a bit slow.  Normally when you branch bzr can just copy rather than extracting then recompressing, but obviously it can't do a straight copy when converting formats.
<beuno> Mez, great, so you just need to bite the bullet this time, then it should be much faster than before
<Mez> beuno: though if I don't upgrade trunk it'll do this every time? I cna't upgrade te trunk branch until everyone's moved to new bzr.
<beuno> Mez, no, if you have you're local repository upgraded, you can interact with older formats
<liel_> Hello
<lifeless> Mez: once you upgrade, everyone else has to
<lifeless> Mez: its in the docs;)
<liel_> I tried to upload my code to a branch in Launchpad, but bzr returned an error: "bzr: ERROR: These branches have diverged. ". What does it mean?
<Mez> lifeless: so I'm about to fuck over the other devs?
<Mez> because I'm using karmic and they're not ?
<lifeless> Mez: if they don't have 1.16, yes.
<beuno> Mez, you're just upgrading locally though, no?
<lifeless> Mez: 2a requires rich-root repositories to push into, it can downgrade seamlessly with any -rich-root format.
 * Mez shrugs
<lifeless> Mez: if they don't have -rich-root then you're doing a one-way transition
<Mez> they seem to have 2.0.0 themselves :D
<beuno> liel_,  that you need to bring in changes made remotely with "bzr merge REMOTE_BRACH"
<james_w> Mez: you don't have to upgrade to the 2.0.0 format
<lifeless> beuno: a local upgrade past the -rich-root transition means 'cannot push to the network without upgradingg it too'
<lifeless> beuno: you will want to memorise that :)
<beuno> lifeless, I thought the case was the other way around
<liel_> james_w: I recived: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified"
<beuno> local in 0.92, remote in 2a
<lifeless> beuno: local 0.92, remote 2a, you can push, can't pull.
<liel_> What this message mean? my English is weak so it is hard for me to understand this message
<muffinresearch> in loggerhead I'm finding that shared branches don
<muffinresearch> I'll try again - in loggerhead branches from a shared repo can't be checked out
<muffinresearch> is that a known limitation?
<beuno> muffinresearch, you're using loggerhead to serve branches?
<muffinresearch> in as far as it is displaying a message with the command for checking out branches over http
<beuno> muffinresearch, it is not a known bug, but I have my suspicions of why that is...
<muffinresearch> beuno - it works for me with standalone branches but not for ones that are in a shared repo
<beuno> muffinresearch, could you file a bug for it?
<muffinresearch> sure will do
<beuno> thanks
<spiffyte1h> The bzr-svn how-tos tell me to start with "bzr init-repo --default-rich-root reponame", but bzr 1.5 on Debian is giving me "ERROR: no such option: --default-rich-root"
<jelmer> spiffyte1h: 1.5 is pretty old; I suspect it would support --rich-root-pack
<jelmer> spiffyte1h: but I would also recommend installing a newer version of bzr and bzr-svn
<spiffyte1h> Ah, but that would be too easy! It's much more fun working within the ancient confines of Debian Stable on your company's dev server :)
<muffinresearch> beuno https://bugs.edge.launchpad.net/loggerhead/+bug/447229
<ubottu> Launchpad bug 447229 in loggerhead "Checking out branches from a shared repo results in 'No repository present' error" [Undecided,New]
<spiffyte1h> jelmer: --rich-root-pack worked fine, thanks!
<beuno> muffinresearch, thanks
<tsmith> i <3 bzr
<tsmith> it's the greatest thing since cvs
<faldridge> jelmer: could you explain the difference between just doing a bzr branch, doing bzr checkout on an svn repo, and using bzr svn-import on an svn repo?
<faldridge> s/bzr branch/bzr branch on an svn repo/
<jelmer> faldridge: 'bzr branch' clones a single branch in the repository
<jelmer> faldridge: 'svn-import' imports multiple branches in the repository
<jelmer> faldridge: 'bzr checkout' clones a single branch and binds to it
<jelmer> faldridge: (if you commit to a bound branch, your local changes automatically end up in that branch too)
<faldridge> ah, so for the initial pull, bzr branch and bzr checkout would produce nearly the same results?
<jelmer> faldridge: yes
<Peng_> The end result of "bzr svn-import" is no different than manually running "bzr branch" once for each branch. Right?
<faldridge> jelmer: what I'm seeing and I'm guessing it's unavoidable is that doing a bzr checkout on a history-rich svn repo takes forever in some cases and fails altogether in one other case.
<faldridge> and from your answer that svn-import would just take even longer
<jelmer> Peng_: yes (preceded by the initialisation of a shared repo)
<faldridge> s/answer/answer it seems/
<jelmer> faldridge: yes, copying history in svn is slow
<jelmer> faldridge: In the case where it fails altogether, how does it fail?
<Peng_> jelmer: Err, right. Oops.
<faldridge> two different errors messages in two tries.  Let me try again now and I'll let you know (it might be a little while)
<phinze> hmm api confusion here... i have an instance of a branch i just sprouted, and i'd like to push to the default location
<phinze> new_branch.push(new_branch.get_push_location())
<phinze> i'm missing a step there
<jelmer> phinze: you need to push to a Branch instance (push location is a string)
<jelmer> phinze: perhaps something like:
<jelmer> new_branch.push(Branch.open(new_branch.get_push_location())) ?
<phinze> there it is, thanks jelmer :)
<faldridge> jelmer: would not having commit access hinder my ability to do a binding pull on an svn repo?
<phinze> hmm, not quite: "NotBranchError: Not a Branch: (url of remote push location)"
<phinze> this is a new push branch location
<jelmer> faldridge: if you're pulling into a branch that's bound to a svn repo that you don't have access to, that would be a problem (since you can't upload new revisions)
<jelmer> phinze: ah
<jelmer> phinze: In that case you might need branch.bzrdir.sprout() IIRC
<faldridge> jelmer: ok, I'm trying the bzr branch method.
<phinze> jelmer: ok will try that
<jelmer> phinze: assuming the target exists as a directory:
<phinze> push_location is "bzr+ssh://..." style
<jelmer> phinze: t = get_transport(new_branch.get_push_location()); new_branch.bzrdir.create_clone_on_transport(t)
<phinze> heyo, that worked... new_branch.create_clone_on_transport(get_transport(new_branch.get_push_location())
<phinze> such a big API, i get lost easily, thanks jelmer :D
<faldridge> jelmer: using bzr branch to produce an unbound mirror worked.  The curious thing to me, though, is that I don't have commit access on the repos in which I was able to produce a bound mirror
<jelmer> faldridge: If you would commit in a bound branch bzr would attempt to put your commits in the original svn repository as well
<jelmer> faldridge: and that would fail, since you don't have commit access
<faldridge> jelmer: what if I made a local branch of the bound branch and committed on it?  Would that fail as well?
<jelmer> faldridge: no, that would succeed - since it wouldn't try to push the data to the svn branch
<jelmer> faldridge: alternatively, you can also unbind the bound branch
<jelmer> faldridge: "bzr unbind"
<faldridge> great, thanks!
<faldridge> thanks so much for your help.   I really, really hate svn's branching/merging syntax so you've been a lifesaver!
<NEBAP|work> can somebody tell me which project management tool has bazaar support? I've found some few month ago, but now I couldn't find any of them ..
<Tak> project management tool?
<NEBAP|work> hmm, don't know how I should describe it in another way. Are there any webapps out there that support bazaar? (I remember a name like track, but seems to be wrong)
<visik7> loggerhead
<NEBAP|work> ah ok
<NEBAP|work> is that the only one?
<jrwren> launchpad?
<jrwren> launchpad is open source now... run LP.
<NEBAP|work> ??
<NEBAP|work> so you can install launchpad on your own server?
<Tak> oh yeah, trac has a bzr plugin as well, right?
<NEBAP|work> ah that's the one I found ^^
<NEBAP|work> Tak: thank you
<NEBAP|work> project management ^^
<Tak> launchpad is probably better integrated with bzr
<Peng_> Redmine supports bzr.
<phinze> is there a way to list the diff being stored on a shelf?  bzr unshelve --dry-run just shows me the modified files like `bzr st` which isn't very useful
<Tak> hey - the pydoctor doc link has disappeared from http://bazaar-vcs.org/Documentation
<phinze> aha appears there is a bug regarding this: https://bugs.launchpad.net/bzr/+bug/317896
<ubottu> Launchpad bug 317896 in bzr "bzr unshelve --dry-run should produce a diff" [Undecided,Confirmed]
<NEBAP|work> Tak: but launchpad seems to be a bit overloaded for my needs ^^
<Tak> ok
<NEBAP|work> any experiences with redmine?
<NEBAP|work> or is it possible to use only a few features from launchpad?
<NEBAP|work> e. g. source browser and issue tracking
<phinze> NEBAP|work: use redmine+bzr heavily where i work
<NEBAP|work> phinze: so? Can you recommend it?
<phinze> seems to work out ok, the source browser sort of sucks -- we use loggerhead separately for that
<NEBAP|work> ok ^^
<phinze> the only limitation that gets me is the fact that you have to link one branch to one project to integrate commit messages with issue updates
<NEBAP|work> then it seems to better make a small bug tracker and use loggerhead as the source browser is the most important feature for me ..
<phinze> so when i commit to the project foo branch and have a message like "hey i'm done, closes #1234"... it has to be an issue that exists in project foo
<phinze> so depending on how many projects you're dealing with you may run into that
<NEBAP|work> k
<NEBAP|work> thank you :)
<phinze> np
<phinze> if you end up trying it and have questions, feel free to ping me
<NEBAP|work> thank you :D
<NEBAP|work> does launchpad use loggerhead?
<Peng_> Yes.
<NEBAP|work> k
<NEBAP|work> phinze: does the redmine source browser support syntax highlighting? Sadly the online demo isn't available ..
<Peng_> Loggerhead supports syntax highlighting. :D
<lifeless> does loggerheads rpc support mean we can use bzr+http with http://b.l.n
<Peng_> (That is, Loggerhead has 30 lines of code to run stuff through Pygments if it's available.)
<NEBAP|work> k
<phinze> NEBAP|work: i believe redmine source browser can run stuff through coderay... but like i say, it's not the best thing in the world, which is why we use a separate instance of loggerhead
<NEBAP|work> couldn't find any screenshots of loggerhead, but I'll check loggerhead at first
<Peng_> NEBAP|work: You can play around with Launchpad's instance: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/
<NEBAP|work> phinze: ok thanky you :D
<Peng_> lifeless: b.l.n doesn't support it.
<NEBAP|work> k, will check that at first :D
<NEBAP|work> does it need additional apps, or will it run in any python environment?
<Peng_> NEBAP|work: It requires some Python libraries.
 * Peng_ points at the README
<NEBAP|work> k thanks, hopefully I can get it running on my webspace ..
<lifeless> Peng_: thanks
<Peng_> lifeless: Loggerhead itself supports it, though. Seems to be broken in trunk, hmm.
<NET||abuse> hey guys... made a mistake, was trying to ignore a set of log files, but not the containing directory,, but ended up removing the directory, then re-adding it,, then committing and pushing up to another laptop... now on that other laptop,, i have a lot of var.moved logs.moved and cache.moved  files.. want to get rid of them ... easy way?
<Peng_> b.l.n handles .bzr through Apache. I guess nobody thought of pointing .bzr/smart over to Loggerhead.
<lifeless> Peng_: I'm not sure we should willy nilly ;)
<lifeless> Peng_: but I'd love it if you were to file a bug saying we should consider it
<Peng_> lifeless: I'm busy right this second, but sure.
<Peng_> (FYI, it was only broken when using "bzr serve --http", and I just fixed it.)
<Peng_> lifeless: I'll add a comment to bug #165087.
<ubottu> Launchpad bug 165087 in launchpad-code "Cannot branch from bzr+http URLs" [Low,Triaged] https://launchpad.net/bugs/165087
<lifeless> thanks!
<jfroy|work> jelmer: updated 342065 with a new backtrace
<niemeyer> Greetings!
<niemeyer> Congrats on 2.0!
<niemeyer> Was just looking at the upgrade procedures, and was wondering about something regarding migration of Launchpad branches
<niemeyer> Is it the case that ~team/project/trunk cannot be used anymore?
<niemeyer> Assuming that this was the place the old branch was held
<james_w> I believe so, but someone else will be able to confirm
<jam> niemeyer: so you *can* upgrade in place, but it often causes more headaches than downloading, upgrading locally, unsetting the dev focus, pushing a new trunk, and setting the new branch as the dev focus
<james_w> doesn't upgrading in place break branches that are stacked on the focus?
<jam> james_w: IIRC it means they must be upgrade, but lifeless claims you can upgrade them once the dev focus has been upgraded
<james_w> ah, ok
<bialix> vila: ping
<jam> bialix: vila generally has stopped working about 2hrs ago
<bialix> hello jam
<bialix> ok
<mneptok> lifeless: any plans for US travel?
<niemeyer> jam: I see, thanks
<niemeyer> lifeless: So is that the case?  Can they be upgraded in place after the stacking base has been upgraded?
<jam> mneptok: well, he was in Canada this week... but I believe he explicitly avoids the US. Doesn't like being fingerprinted, etc.
<Tak> heh
<lifeless> niemeyer: yes you can upgrade after
<lifeless> mneptok: no, back homeward bound in 2 ours
<lifeless> *hours*
<lifeless> mneptok: where are you at the moment ?
<niemeyer> lifeless: That's awesome!
<jfroy|work> yay
<jfroy|work> fast-export | fast-import will work to create a new branch out of a borked branch
<jfroy|work> (bortked -> ghosts and sha1 mismatches)
<Peng_> Oh, cool.
<SamB_XP> jfroy: of course, it will have no relation to the previous branch ...
<jfroy|work> SamB_XP: which is fine
<jfroy|work> (in this case0
<jfroy|work> *)
<SamB_XP> just pointing out the obvious in case it had escaped anyone's thinking somehow
<SamB_XP> 'twould be a harsh truth to realize a day or so later ;-)
<jfroy|work> yeah
<jfroy|work> My goal at this point is only to un-borked the main development branch of the project, ditch every other branch and go from there.
<SamB_XP> hmm ... it would be kind of cool if fast-export could do several branches at once ...
<SamB_XP> ... or can it ?
<mneptok> lifeless: Albuquerque, New Mexico
<emmajane> lifeless, he's as far away from snow as possible.
<Tak> actually, albuquerque is up in the mountains, isn't it?
<mathepic> I asked this yesterday but nobody had a solution
<mathepic> I'm trying to use colordiff as a bzr diff backend
<mathepic> But I'm on windows with cygwin
<mathepic> so it doesn't seem to recognize it (colordiff is not an executable)
<lifeless> you'll need to either use bzr from cygwin
<lifeless> or have a batch /command script that runs colordiff
<mathepic> Running it from cygwin doesn't solve the problem
<mathepic> $ bzr diff --using colordiff === modified file 'Makefile' bzr: ERROR: colordiff could not be found on this machine
<mathepic> Can't post multiple lines very well
<mathepic> I opened up colordiff with emacs
<mathepic> it is a perl script
<lifeless> mathepic: running from cygwin won't help:
<lifeless>  you need a *cygwin version* of bzr
<mathepic> Oh
<lifeless> normal bzr uses win32 python that uses CreateProcess
<mathepic> Will that have any significant drawbacks on performance?
<lifeless> *cygwin* bzr uses cygwin python which uses fork/exec
<mneptok> Tak: it is. ABQ is at ~5.5feet elevation
<lifeless> mathepic: I'm not sure of the performance implications; jam, who has signed off, may know.
<Tak> *10^3?
<lifeless> mathepic: but you can create a .cmd script to run colordiff
<mathepic> I hate windows so much...
 * Tak at literally 5.5ft
<mathepic> What would the batch script contain
<mathepic> Since I can't access colordiff unless I'm in cygwin
<mathepic> I guess I can just run "bzr diff | colordiff", but I was hoping to get an alias that would achieve the same thing
<idnar> what about bzr cdiff?
<mathepic> bzr diff --using "perl /bin/colordiff"  doesn't work with colors
<mathepic> nor does bzr cdiff
<idnar> ah
<mathepic> I'm thinking cdiff isn't compatible with windows
<mathepic> Is there any alternative to "colordiff" for colorize diff
<mathepic> under cygwin
<lifeless> mathepic: I repeat, you'll need a command script
<lifeless> crate one and it should be fine
<lifeless> as to what it contains, 'perl.exe colordiff $1 $2' or something like that
<lifeless> I have to go, got a plane to catch.
<malept> hi, I'm attempting to use smart server support in loggerhead with a repository. `bzr info` on the repository is fine, but on the branch it gives me "No repository present: chroot://[something]". I'm kind of at a loss as to how to debug this.
<zsquareplusc> or "bash -c colordiff"
<lifeless> malept: its a bug, it was discussed earlier today with someone else; I don't remember more sorry
<malept> lifeless: discussed in here?
<lifeless> yes
<lifeless> ciao
<malept> lifeless: have a good flight
<mathepic> zsquareplusc, that almost worked but colordiff starts wanting me to input text
<zsquareplusc> mathepic: yes, and does piping not work? "|"?
<mathepic> Yeah the piping will work, I'm just trying to get an alias
<Peng_> malept: I don't know what's going on there. I'd expect you to hit bug #348308, but this is something different.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
 * zsquareplusc has not yet used aliases
<Peng_> malept: Do you mind filing a bug? https://bugs.edge.launchpad.net/loggerhead
<Peng_> malept: Oh, you/someone did. https://bugs.edge.launchpad.net/loggerhead/+bug/447229
<ubottu> Launchpad bug 447229 in loggerhead "Checking out branches from a shared repo results in 'No repository present' error" [Low,Triaged]
<malept> Peng_: yeah, just found it in the irc logs from today
<Peng_> Ah. I didn't see the discussion; when was it?
<Peng_> Never mind, grepped.
<davidstrauss> What unit testing framework does bzr use?
<malept> :)
<davidstrauss> lifeless: ^^ you would know :-)
<malept> Peng_: I had already patched my fastcgi loggerhead script to deal with the smart server jail bug (using your monkeypatch)
<Peng_> malept: Ah.
<Peng_> davidstrauss: Bazaar uses Python's unittest, plus (optionally) subunit and/or testtools.
<malept> Peng_: speaking of my fastcgi script, would it be useful if it was distributed with loggerhead?
<davidstrauss> Peng_: Is that built into Python?
<malept> davidstrauss: unittest is, for sure
<davidstrauss> ok, cool
 * davidstrauss is about to force unit testing on bcfg2.
<Peng_> subunit & testtools are not.
<Peng_> malept: Waitwait. A FastCGI script? Neat! Can I see it? :D
<LarstiQ> davidstrauss: and convenience classes/methods built on top of unittest
<malept> Peng_: sure, mind if I PM you the link?
<Peng_> malept: ok
<maxb> Hi. Would someone be able to guide me to an example of using bzrlib to get a list of all rev-ids in a branch?
<maxb> Or alternatively, what is the best way whether to check whether rev-id is contained within the history of a branch
<maxb> I don't suppose anyone here is familiar with where in the qbzr code the algorithm for ordering revisions in qlog lives?
<SamB_XP> maxb: there was a bug about how to check whether a revision is in the history of a given branch ...
<SamB_XP> ... it has the word "predicate" in the title, I believe
<luks> maxb: regarding the list of all revision-ids: branch.repository.get_ancestry(branch.last_revision())
<maxb> Ah - I found branch.get_revision_id_to_revno_map() and was attempting that
<maxb> It seems rather sloooow though
<SamB_XP> it would be, yes
<luks> and the revisions in qlog are topologically sorted
<luks> which is in bzrlib.tsort
<luks> (unless you mean the actual graph layout, not just the ordering)
<SamB_XP> luks: perhaps he was hoping to stick something in to order by commit date when possible ;-)
<maxb> SamB_XP: exactly :-/
<SamB_XP> I guessed this because I have often wished that bzr viz had such an option
<maxb> toposort with a preference for commit date where feasible would make the history much more readable in many cases
<maxb> So, on the "is it in the history" question, basically I've discovered bzr fastimport has a bug where it discards tags which aren't on the left-hand history
<luks> well, sorting by date would require making the graph flat
<maxb> So I'm trying to rewrite its "is this tag in this branch" logic to respect all the history, not just the left-hand
<maxb> luks: "flat" ?
<luks> a simple list
<maxb> I don't require that it be completely date-ordered.
<luks> otherwise you would need arrows on the lines, because they could be directed both up and down
<luks> how would it work?
<maxb> I just want it to be date-ordered where topological constraints do not dictate otherwise
<luks> the only point where you possibly chance choose the ordering is a merge point (node with multiple parents)
<luks> er, have a chance
<luks> to
<luks> but of course that would break the mainline concept
<maxb> ?
<maxb> It's perhaps worth noting that this comes into its own and is only really relevant when viewing the graph of a repository - i.e. many heads to the graph
#bzr 2009-10-10
<Ddorda2> hello, i have a problem when trying to pull a branch: http://ddorda.pastebin.com/d2e2d83e3
<wgrant> Ddorda2: It shouldn't be an ugly error like that, but it means you need to get a newer version of bzr
<Ddorda2> does it have any PPA or something?
<wgrant> Ddorda2: Since you seem to be on Ubuntu, try https://launchpad.net/~bzr/+archive/ppa
<Ddorda2> wgrant: thank you for reading my mind
<Ddorda2> wgrant: it fixed the problem, thanks a lot :D
<wgrant> Ddorda2: Great.
<johnf> jelmer: Just noticed you are working on bzr-hg. Are you close to doing another release?
<johnf> I was just about to look at the debian package as it is blocking bzr from moving into testing
<jonasfa> Do BzrEclipse works with bazaar 2.0?
<jonasfa> ??
<jonasfa> Do BzrEclipse works with bazaar 2.0?
<Tak> jonasfa: probably? try it and see?
<RenatoSilva> is there a way to clean bzr --info infos?
<Tak> you mean forget the related branches?
<RenatoSilva> yes
<Tak> you can use the --remember option to make it remember a new one
<RenatoSilva> I know, but forget
<RenatoSilva> how to forget
<Tak> hmm, I don't know of a way
<wgrant> RenatoSilva: Try looking in .bzr/branch/branch.conf
<RenatoSilva> wgrant: I`m already using that ?) I wondered if bzr had an option though
<wgrant> RenatoSilva: Not that I've seen.
<RenatoSilva> s/?)/:)
<RenatoSilva> ok thanks anyway
<jackalborn> hello again
<jackalborn> i just installed bazaar on my windows machine and i'm not quite sure how to share my project with other "scattered acoss the world"
<jackalborn> as the page puts it
<mzz> jackalborn: if you have server space anywhere you can push to that (using various protocols, the manual lists a few). If you don't have server space of your own you can use launchpad
<jackalborn> i cant run a server off my spare machine?
<mzz> jackalborn: sure. You may already be running enough of one though. For example: if you have a plain http server on the server, and ssh access to it off your windows system, you're set
<wgrant> Or FTP access.
<mzz> or that, or being able to run bzr on the server in smart server mode, or one or two others I forgot. I'm currently fighting with the documentation, I thought it had an overview
<jackalborn> i'm not really sure how i would tell if this spare computer has ssh or if it's running a http server
<mzz> http://doc.bazaar-vcs.org/latest/en/user-reference/index.html#url-identifiers and/or http://doc.bazaar-vcs.org/latest/en/user-guide/branching_a_project.html but I think I'm not finding the right page
<SamB_XP> jackalborn: what OS does it have ?
<jackalborn> windows xp
<mzz> ok, then it's not running ssh and probably not running an ftp server
<SamB_XP> okay, my guess is "no" on both counts
<mzz> who do you want to share with?
<jackalborn> another computer on the network and another devolper outside of my network
<jackalborn> idid find this
<jackalborn> http://doc.bazaar-vcs.org/bzr-0.12/server.htm
<mzz> for "outside of my network" you need an internet-facing server, which I'm guessing (hoping :P) this windows xp box isn't
<mzz> if this is an opensource project using launchpad is an option
<jackalborn> it probaly is not
<jackalborn> it's not so much opensource
<mzz> if it's not an open project you'd need your own server, or you'd need to communicate by sending each other bundles
<jackalborn> indie game dev
<mzz> http://doc.bazaar-vcs.org/latest/en/user-guide/sending_changes.html may be of use there
<mzz> (haven't read the entire page, sorry)
<jackalborn> no worries i'll read it and fill you in on what it says :)
<poolfool> Jackalborn: Are you new to revision control in general or just to bazaar
<poolfool> Jackalborn: ?
<jackalborn> i use revision control at work, perforce. and i've actually set up an svn server on a windows machine and use tortoise cvs
<poolfool> Jackalborn: I use perforce at work as well, setup and maintain CVS and SVN at work as well (Yuk).
<jackalborn> but i think that whole thing was just luck
<jackalborn> yuk is a good word for it
<jackalborn> i've also used google code
<poolfool> Jackalborn: I found the Scenarios page (http://bazaar-vcs.org/Scenarios) to be of hudge help ...
<jackalborn> with tortoisecvs
<poolfool> Jackalborn : but maybe you can try each local hosting your own repo and then pass back and forth packs(?)
<poolfool> Not pretty but a solution
<jackalborn> i'm going to try to set up a repo on my ftp
<jackalborn> if that doesnt work then i will definatly be doing that
<jackalborn> ugly as it may be
<poolfool> I have to say that bzr is a much nicer tool after you learn it ... but the perforce GUI can lead to some bad habits ... Oops
<jackalborn> haha
<jackalborn> perforce spoils me rotten
<wgrant> What's so good about Perforce?
<jackalborn> it's simple and i didnt have to set up a thing
<jackalborn> check in, check out
<jackalborn> no worries
<bob2> same with bzr
<wgrant> Isn't that rather because somebody already set it up?
<jackalborn> although we did have a guy check out the entire depot once by accident
<bob2> cd source ; bzr init ; bzr add . ; bzr ci -m "initial import"
<jackalborn> wgrant: yes
<poolfool> I guess after you have been subjected to CVS hell and some of it's warts (non-atomic) well ... Perforce can be nice.
<poolfool> Heaven help you if your meta data gets corrupt ... and your snap shot is old ... Oops.
<jackalborn> it took me like 2 weeks to set up that svn server and get it working
<jackalborn> and then a month later that machine died
<wgrant> SVN is awkward like that.
<wgrant> With bzr you don't need any specialised software on the server.
<poolfool> I guess one of the 'nice' things about administrating a Perfoce server vs. CVS/SVN is it comes out of the 'box' and just runs on Linux /or/ Windows.
<poolfool> I also had to do a lot (less then a week) of hunting around the web to figure out how to setup CVS (and then SVN) on a Linux box with SSH and password authen back to active directory ... kind of crazy.
<jackalborn> just reading that hurts my head
<jackalborn> i cant even imagine
<bob2>  a matter of pointing pam_ldap/nss_ldap at the ad server?
<poolfool> Actually I tried the pam_winbindd (I think) ... but the pam_ldap would have been much nicer.
<wgrant> If you have SFU on the AD server, sure.
<poolfool> SFU ?
<wgrant> But most people use winbind or likewise, I believe.
<wgrant> Services for Unix. IIRC it adds some attributes to AD to make it less impossible to use nss_ldap with.
<poolfool> Ahhhh .... I tried that .... long time ago and well ... I hear it's much better in the last 5 years.
<poolfool> But again. Lets say I was setting up Bzr on an Linux box, I have an Active Directory server for my company.
<poolfool> Lets say SSH access, how would I tie access back to the AD ... key here is single password (or key) per user to cut down on their end?
<jackalborn> so i set up an ftp server on my other computer and i'm able to connect to my repot and it's trunck from this computer
<jackalborn> but now i cant seem to do anything with it all the buttons in bazzar give me an error
<jackalborn> "Action not yet supported by current app_suite
<poolfool> Jackalborn: .... I am guessing you are using the new gui interface (gnome)?
<jackalborn> windows gui interface
<jackalborn> think i got it working though
<poolfool> Jackalborn: I use the command line mostly .. different from perforce but you can do a /lot/ from the command line.
<lifeless> davidstrauss: as answered; bzr uses a _heavily_ extended verrsion of python's unittest. If you want a easy-to-write-tests-in-environment, nose is good
<lifeless> its also, like bzr's tests, a single extension dimension - you only get to step away from the core unittest once.
<lifeless> davidstrauss: grab me Monday/Tuesday and I'll happily give you a quick rout of some other things you can use
<lifeless> testtools isn't a testing framework, its useful flue for folk maintaining test suites
<lifeless> subunit also isn't a framework, but its great interoperabolity glue between tests and reporting toolchains (e.g. things like Hudson)
<jackalborn> thank you all for all your help
<jackalborn> night
<dash> how do I keep bzr svn-import from consuming 10G of RAM when importing my svn repo? :)
<mzz> is there a nice way to spit out a series of patches (one per rev) to separate files? "bzr log -p" is close, but I'd have to manually split it into files, or invoke it in a loop, or something
<spiv> dash: do it incrementally, I guess.
<spiv> dash: I assume you're running the latest, shiniest bzr and bzr-svn and subvertpy?
<dash> bzr 2.0, bzr-svn 1.0
<dash> i am doing it incrementally
<dash> that just means it spends as much time in the spin-up phase as in the actual import phase
<arkanes> any idea how I can fix: bzr: ERROR: No such file: 'f2jvnez07njqaw00l791.pack': [Errno 2] No such file or directory: '/Applications/World of Warcraft Public Test/Interface/AddOns/.bzr/repository/upload/f2jvnez07njqaw00l791.pack'?
<arkanes> command is just 'bzr merge'
<arkanes> huh, createing an "upload" directory under .bzr/repository fixed it
<MAfifi> Hi. I'm running fedora 10 64-bit. I installed bzr as an rpm using yum. I then downloaded the qbzr plugin and placed it in the plugins directory ~/.bazaar/plugins/. Now when I issue the command "bzr self test qbzr", I get the error message "
<MAfifi> bzr: ERROR: No module named elementtree.ElementTree
<MAfifi> You may need to install this Python library separately.
<MAfifi> The version installed by yum is 1.16.1.
<mathepic> Just don't use qbzr
<mathepic> Command line is so much cooler
<mathepic> Sorry, terminal. "Windows" terms have gotten into my head. Eek.
<MAfifi> I originally installed qbzr as a dependency for qbzr-explorer.
<mathepic> If I recall
<mathepic> ElementTree is extremely recommended for bazaar
<mathepic> but not needed
<mathepic> Like, i think it speeds up performance on XML by A LOT.
<mathepic> Let me find the page
<mathepic> I can't find the exact page
<mathepic> I'm not an expert on Fedora since I use Ubuntu, but this package looks like it should do it
<mathepic> https://admin.fedoraproject.org/pkgdb/packages/name/python-elementtree
<luks> it is needed by bzr
<luks> all the xml serializers/deserializers use it
<luks> but it's been built-in since python 2.4 or 2.5
<MAfifi> Anyway, it's no longer built in fedora 10 and upwards.
<luks> what version of python and bzr are you using?
<MAfifi> Yes, I've python 2.5 installed system-wide(the one used by default_.
<MAfifi> But the problem is that it still complains about it not existent.
<luks> can you try running the command with -Derror
<MAfifi> I think I might have figured out the problem from bazaar log.
<luks> and pastebin the whole traceback?
<luks> something is probably not using the builtin module
<MAfifi> Actually it was refering to elementtree.ElementTree inside bzrlib.
<luks> yes, I wanted to know where exactly
<MAfifi> I don't have the log(; I've deleted it in favour of a fresh install of bzr 2.0).
<MAfifi> I've installed 2.0, and going to try over.
<MAfifi> I installed it using easy_install; hope it works this time.
<mathepic> Also, qbzr technically isn't a requirement for Bazaar Explorer - When I was looking into it, I think it said you can configure it to use bzr-gtk instead
<MAfifi> I didn't have either, so I decided to try with qbzr.
<luks> mathepic: it is a requirement for bazaar explorer
<luks> it builds on qbzr
<luks> you can tell it to use bzr-gtk
<mathepic> "If you wish to use bzr-gtk dialogs with Explorer, select gtk as the application suite. gtk will only appear as an option if you have the bzr-gtk plugin installed."
<mathepic> Do a search for gtk at http://doc.bazaar-vcs.org/explorer/en/visual-tour-gnome.html
<luks> ok, we can excange quotes :)
<luks> "BzrExplorer provides most of its functionality by calling out to mini-applications provided by "application suites", namely the QBzr and bzr-gtk plugins. QBzr is required while bzr-gtk is optional."
<mathepic> Contradicting documentation
<luks> not really
<mathepic> Mine makes it sound like you can replace the qbzr applets with gtk applets
<luks> you can
<luks> but note that BE is a Qt application
<mathepic> Ahh.,
<luks> it uses some of qbzr's functionality internally
<luks> you *can* use bzr-gtk for external dialogs where possible
<mathepic> K
<mathepic> Terminal is still the fastest way to go. :D
<luks> browsing history on terminal is definitely not the fast way to go
<luks> bzr log / <copy> / bzr diff -c <paste> / hm, no bzr st -c <paste> / back to bzr log / <copy> / bzr diff -c <paste>, and so on :)
<luks> that's now very efficient
<MAfifi> Partially good news! "bzr selftest qbzr" doesn't complain now.
<mathepic> Cool.
<MAfifi> It seems qbzr(at least the version I downloaded) was built against the latest version of qbzr.
<mathepic> Err, typo?
<MAfifi> However, I still get some failing tests as illustrated here: http://pastebin.com/d7ff6f5fd
<MAfifi> However, the self test of the explorer plugin itself is fine.
<mathepic> Personally, I wouldn't worry about it all that much.
<MAfifi> Me, neither.
<MAfifi> And now the big surprise, "bzr explorer" works. Thanks to all of you guys for your suggestions/hints.
<luke-jr> I'd like to cleanup/fix the Bazaar repositories for a project. Is anyone available who might be able to assist me? :)
<mathepic> What do you mean "cleanup/fix the Bazaar repositories"
<RenatoSilva> Suggestion for bzr: when committing, ask the user if he wants to add the unknown files that appeared since last commit.
<dash> Man. that would be super annoying
<RenatoSilva> why
<Peng_> He said the *new* unknown files, so it wouldn't be *that* annoying.
<dash> yeah that would be less bad.
<RenatoSilva> For example: bzr status = file 1; touch file2; bzr commit ---> The following new files has been added since your last commit: file2, do you want to add them before  committing? [Y/n]
<dash> RenatoSilva: write an extension :)_
<Peng_> That reminds me, I need to turn off the strict pushing thing.
<mathepic> Yes, please
<Peng_> "Yes, please" what?
<mathepic> I think I've done 3 commits today where immediately after committing I realized I didn't add the files yet
<RenatoSilva> mathepic: I committed and pushed once without remembering to add the files, that's the main reason for my suggestion :)
 * wgrant wonders why people don't 'bzr st' more often.
<Peng_> wgrant: Cuz we think we remember the status.
<dash> wgrant: also the unknown files list is at the bottom
<dash> pushing the interesting part off the top of the terminal :)
<RenatoSilva> wgrant: in my case, status just does not have my attention all the time. When I added the files, that was not pretty clear in my mind, so that "oh mush bzr add", it was more like "oh these are my changes"
<dash> also there's like a zillion unversioned files
<RenatoSilva> dash: doesn't bzr have extensions lists for ignoring files?
<wgrant> Why? They aren't ignored?
<dash> RenatoSilva: Yeah but they don't all have the same extension
<dash> RenatoSilva: also some files I'd want to add have the same extensions
<RenatoSilva> dash: if they have the same extensions but you want to ignore just some of them, then you must not add the extension to ignore list right?
<mathepic> RenatoSilva: Yeah, I did that three times today. Luckily it was to my own project...
<dash> RenatoSilva: yes! I did not.
<RenatoSilva> dash: by extension you mean a bzr plugin?
<RenatoSilva> bug 448310 :)
<RenatoSilva> where's the bug bot ha
<RenatoSilva> https://bugs.launchpad.net/bzr/+bug/448310
<mathepic> That would be better as a blueprint, if bazaar supports them
<mathepic> And Bazaar does, so yeah...
<mathepic> Its not really a bug
<RenatoSilva> bugs also are feature requests
<wgrant> Blueprints are very, very rarely a better idea.
<wgrant> That is more appropriate as a bug.
<RenatoSilva> afaik blueprints are for BIG feature requests
<luke-jr> is it possible for files and revisions to have multiple ids?
<mathepic> Oh
<mathepic> Wow
<mathepic> One of my most hated grammar mistakes
<mathepic> "Remember him to do this"
<mathepic> And its in the bug title
<RenatoSilva> mathepic: sorry I'm not English native haha
<RenatoSilva> mathepic: what's the right form?
<mathepic> RenatoSilva: Remind
<luke-jr> ...
<luke-jr> :/
<luke-jr> so I have 3 bazaar trees
<luke-jr> README in all 3 refers to the same file
<luke-jr> but they have different file-ids
<luke-jr> how can I make the 3 trees cross-mergable?
<wgrant> luke-jr: /win 2
<wgrant> Argh.
<wgrant> luke-jr: There's probably something in bzr-rebase to help with that.
<wgrant> luke-jr: But you'd have to modify the history of two of the trees to be compatible with the third.
<wgrant> Hm, no, rebase probably won't work.
<wgrant> Bug #231674 is relevant.
<ubottu> Launchpad bug 231674 in bzr-rewrite "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674
<luke-jr> wgrant: we have numerous branches in the wild. I don't want to break their mergability
<luke-jr> wgrant: I really need a repository which can understand that files have multiple file-ids
<luke-jr> and tolerate any of them on merging trees
<luke-jr> does such a format exist, and if not, how hard would it be to make a custom format for it?
<johnf> jelmer: you about?
<wgrant> luke-jr: There was a discussion recently (on the bazaar mailing list, maybe?) about having revision ID aliases, but there's nothing done about that yet.
<luke-jr> :/
<wgrant> luke-jr: How did these multiple sets of history come about?
<luke-jr> wgrant: bzr-svn's shortfalls
<luke-jr> or rather, that's part of the cause
<luke-jr> wgrant: our project is very old
<luke-jr> we in fact have 6 data sources for the repositories
<luke-jr> original CVS
<luke-jr> forked CVS #1
<luke-jr> forked CVS #2
<luke-jr> Subversion migration
<luke-jr> bzr-svn branch of Subversion trunk
<wgrant> luke-jr: Heh, the alias thing came up in exactly the bzr-svn case...
<luke-jr> bzr-svn branch of Subversion 0.2.8
<luke-jr> the two bzr-svn branches are incompatible at the moment
<wgrant> Sounds like you imported it badly.
<wgrant> bzr-svn can do branches/tags fine if you tell it to.
<wgrant> If I were in your situation, I think I would declare a flag day and declare one history as canonical.
<luke-jr> no, it can't.
<luke-jr> wgrant: both branches have active development. we can't do that.
<wgrant> luke-jr: You would prefer to maintain a custom repository format forever rather than writing a bit of conversion code?
<luke-jr> wgrant: hmm, that might be an option
<luke-jr> is it possible to change file-ids easily?
<wgrant> luke-jr: See the conversation transcript in the bug I referenced. It suggests how to do it with rebase.
 * luke-jr doesn't see what rebase has to do with this O.o
#bzr 2009-10-11
<wgrant> luke-jr: You want to replay the revisions from each incompatible branch onto the canonical history, mapping file IDs.
<luke-jr> that would be ugly. :/
<luke-jr> can't just sed the branch? :p
<wgrant> It would be ugly. But a lot less ugly than maintaining incompatible branches or your own aliasable repository format.
<wgrant> It is a one-time cost.
<luke-jr> ok, how about pasting on missing history?
<wgrant> What do you mean?
<luke-jr> bzr-svn only got the last N revisions of the history
<luke-jr> we need to restore the full history too
<wgrant> Do any of the bzr branches have the full history?
<luke-jr> no
<luke-jr> except the prototype ones I'm making now with cvsps-import
<wgrant> Why didn't bzr-svn catch it all?
<luke-jr> it doesn't follow hierarchial changes
<luke-jr> after moving to Subversion from CVS, we rearranged the repository structure to be nicer
<wgrant> Are the old CVS and Subversion repos no longer in use?
<luke-jr> the Subversion one is, but not for the branches in Bazaar right now
<wgrant> Even so, that's fairly inconvenient as it means compatibility has to be maintained somehow.
<luke-jr> not really
<wgrant> So, what I would do:
<wgrant>  - Somehow get a consistent and complete copy of the history into a bzr branch.
<wgrant>  - Hack rebase so it maps the file IDs (as in the bug).
<wgrant>  - Rebase all of the branches on top of the new history.
<luke-jr> can I get cvsps-import to use a file-id file?
<wgrant> (or some prefix of the new history)
<wgrant> I don't know.
<luke-jr> can current-trunk-revision-2 be made to sit cleanly on top of a revision N?
<wgrant> "current-trunk-revision-2"?
<TheMusicGuy> I'm trying to get a very simple installation of bzr onto my shared web host. I don't have root access, but all I need to be able to do is list files in a repo.
<TheMusicGuy> I only have FTP access to the host; no telnet, ssh, etc.
<TheMusicGuy> How can I do it?
<wgrant> TheMusicGuy: Why do you want bzr on there? You don't actually need bzr on the server just to host a branch.
<TheMusicGuy> because webbzr needs it
<TheMusicGuy> I want to be able to browse branches with a web interface
<wgrant> Ah.
<mathepic> Any reason you can't use LaunchPad?
<TheMusicGuy> its not for a project. Its for homework.
<wgrant> Trying to get a web interface like that up on a shared host with only FTP access sounds like more trouble than it's worth.
<TheMusicGuy> I use bzr and my personal web host for backing up school work.
<wgrant> Although it is more than likely doable.
<TheMusicGuy> sorry, I didn't see your last post
<TheMusicGuy> webbzr seems like it would work, but I need to have a bzr install on there somewhere
<wgrant> Do you really need webbzr?
<TheMusicGuy> that looked like the simplest solution. Its just three files, only one of which is actually a PHP file. Configuration is as simple as changing a few lines in the top of the script.
<mathepic> For three files, I really doubt you need a web interface
<mathepic> Oh
<mathepic> webbzr not your project
<mathepic> Nevermind, I misunderstood.
<mathepic> How big is your project/homework?
<TheMusicGuy> pretty big.
<TheMusicGuy> Can't I just upload an install of bzr into some directory on my server and tell webbzr to use that?
<TheMusicGuy> I don't need to make any changes or create any files from the web interface.
<TheMusicGuy> read-only is fine.
<mathepic> Where can I find the source of webbzr
<TheMusicGuy> http://bazaar.enseed.com/app/webbzr/
<mathepic> Why exactly do you need a web interface anyway
<TheMusicGuy> so I can access the repo from workstations that don't have bzr installed while still using bzr
<RenatoSilva> btw, hg's web ui has an interesting feature, you can donwload a whole tree using a single link where you specify a revision/tag, loggerhead could have the same thing :)
<RenatoSilva> I mean, the tree is packaged as .zip or so
<quidnunc> Stupid question: How do I switch to the last commit with a given nick (branch?)
<quidnunc> ?
<loxs> is there some way to check what percentage of the code is contributed by each developer?
<mathepic> I just saw that
<mathepic> somewhere
<mathepic> just looking around Synaptic
<mathepic> This might do it
<mathepic> bzr-stats
<mathepic> "This is a simple plugin for Bazaar that can list the contributors to a
<mathepic> branch and what they worked on."
<mathepic> I don't know if it does percents though
<loxs> thanks
<james_w> I don't think that works by line if that is what you are looking for
<james_w> though perhaps it has a mode for that
<mathepic> I don't understand why Canonical never updated the bzr in the Ubuntu repository
<mathepic> You have to use the bzr in the PPA for 2a (and thus LaunchPad)
<wgrant> mathepic: Launchpad doesn't force you to use 2a.
<wgrant> mathepic: And the bzr team can't push inappropriate updates into Ubuntu releases just because both have Canonical involvement.
<wgrant> Ubuntu has a strict stable release update policy.
<TheMusicGuy> Ah, nevermind. I just figured out that the filesystem layout of my host won't work for webbzr. I'll have to rework it before I can do this...
<wgrant> mathepic: bzr's new (and IMO less insane) release schedule should be a bit nicer to distros.
<mathepic> I just took a look at the policy
<mathepic> Ugh
<wgrant> It is necessary.
<lifeless> wgrant: weeeel
<lifeless> wgrant: it is what is
<wgrant> lifeless: That much is clear.
<wgrant> lifeless: (what are we talking about? the SRU policy?)
<lifeless> wgrant: yes
<wgrant> lifeless: I'm sure you know the disasters that have come about.
<wgrant> But it is perhaps overly strict for less core components.
<wgrant> Although it would be particularly foolish to ever SRU 2.0.0, because of the default format change.
<lifeless> wgrant: I'd call it tricky rather than foolish
<lifeless> wgrant: 'needs to be one with vare'
<wgrant> lifeless: I don't want my Jaunty system to one day start creating incompatible repositories.
<lifeless> it does that right now ;)
<wgrant> Does it?
<lifeless> yes, it will be making pack-0.92, which can't pull in a growing number of projects
<lifeless> at some point the fraction will pass 50%
<lifeless> but we could do 2.0.0 with a plugin for the default back, or other such techniques
<wgrant> Pulling an existing branch into a new branch doesn't seem like a very common case.
<lifeless> regardless, I think the concept of a 2.0.0  SRU is not foolish
<lifeless> wgrant: you said repository
<wgrant> lifeless: Shh.
<wgrant> 2.0.0-sans-default-change would be nice, but I can't really see it happening.
<lifeless> wgrant: all the upstream code imports are going to be moved to 2a
<lifeless> the ubuntu branches are 2a
<wgrant> I know.
<jelmer> johnf: hi
<luke-jr> Does anyone have the 'fileid' or 'graft' plugins mentioned at the end of http://bazaar-vcs.org/BzrPlugins ?
<wgrant> luke-jr: Those links have them...
<wgrant> Oh, wow, they are old.
<wgrant> A weave repo!
<luke-jr> wgrant: those links are empty and "unauthorized"
<wgrant> luke-jr: Not quite - try checking them out with bzr
<Zand3r> Hello all... Does anyone have a URL to hand where someone has documented their usage of qbzr-eclipse? I've
<mathepic> I've never even heard of qbzr-eclipse
<Zand3r> mathepic: Not that you are necessarily interested but this is what I am 'trying' to use http://bazaar-vcs.org/QBzrEclipse
<Zand3r> I'm evaluating bzr for our project and the Bazaar Explorer gui seems great and makes sense but we use an Eclipse based IDE for microcontroller code and I just can't see what the workflow should be between bzr and Eclipse.
<mathepic> I don't use eclipse, but I get along just fine switching between my editor and the terminal
<mathepic> I tried bzr-eclipse when I was using eclipse and it wasn't very good
<mathepic> I just took a look at the page for qbzr-eclipse
<mathepic> Scrolled down
<mathepic> Found a link to this bug
<mathepic> https://bugs.edge.launchpad.net/bzr-eclipse/+bug/121936
<ubottu> Ubuntu bug 121936 in bzr-eclipse "Eclipse hangs in bazaar operations that require user input" [High,Triaged]
<mathepic> Yep, thats the same one I just posted
<mathepic> Oh wait, that one was for bzr-eclipse
<Zand3r> Yes... I had seen that which is why I opted to try qbzr-eclipse which doesn't seem to have the same issues documented (presumably because it uses the more standard qbzr gui widgets)
<mathepic> I never had a problem pushing with bzr-eclipse when I used it
<mathepic> It just didn't have all the commands
<mathepic> And was super slow
<Zand3r> My problem seems to stem from the fact that using a standard text editor I could just work with files in whatever directory (branch) I want but in Eclipse when I branch I'd have to re-import the project directory again each time which doesn;t seem like a seemless workflow.
<Zand3r> Maybe its my lack of experience with VCSs in general but there seems to be a conflict between bzr which has a directory per branch and eclipse which expects a single directory per project and has no way to easily switch that project view toa different directory (branch)
<mathepic> Can't you just refresh the directory in Eclipse?
<mathepic> Project = Branch in general
<mathepic> Do you need more than one Branch?
<Zand3r> Say I have a project called 'Project' and I go to bzr explorer and create a branch called 'Project-Feature'.... bzr explorer creates a new directory for that new branch but the Eclipse project is still pointing at the original directory.
<mathepic> Can Bzr Explorer turn an existing project into a branch
<mathepic> I'm not sure
<mathepic> I don't use it
<mathepic> Go to terminal, go to the directory of the project
<mathepic> And use the command "bzr init"
<mathepic> It will turn your project into a branch
<mathepic> Then use "bzr ignore ...." for files you want to be ignored
<mathepic> then "bzr add" to add the rest
<mathepic> And its set up
<Zand3r> OK.. but just so I understand, if you were to then branch from that (to work on a new feature without immediately affecting the main/original branch) then what would you do? I 'think' branching will create a new directory that the Eclipse project will not be pointed to - yes?
<mathepic> You probably wouldn't want two branches in the same project
<mathepic> Just create a new project for the second branch
<dorins> Zand3r: you could set up an eclipse workspace for a lightweight checkout and then bind that checkout to different branches using 'bzr switch'
<dorins> I was considering this workflow at some point, I think
<Zand3r> hmm... ahh... so I just understood what mathepic is suggesting I think.... using the terminal (or bazaar explorer) I could branch the project which would create a new directory and then import that into Eclipse as a new project, work on it.... then using the terminal (or bazaar explorer again) merge the tested changes into the original project at which time i should be able to 'refresh' the project in Eclipse which will cause it to update.
<mathepic> You don't have to create a new directory to branch
<mathepic> You can use the existing directory, which happens to be the directory of your project
<mathepic> Oh wait
<mathepic> For the first step you could either branch from anotther branch or you could use an existing local project
<mathepic> Depending on whether the branch already exists somewhere
<Zand3r> dorins: Thank you - not ignoring what you have suggested, am looking for details of lightweight checkouts
<dorins> this might help: http://doc.bazaar-vcs.org/latest/en/user-guide/reusing_a_checkout.html
<mathepic> I've never dealt with those - Is that basically having multiple branches in one directory and being able to switch between which ones you are using
<mathepic> It says there are no local commits; that is a signifigant disadvantage.
<Zand3r> dorins: Thanks... I will run through the lightweight checkout workflow to familiarise myself with it... it looks like it would solve the issue of working across multiple branches without having to manually import each one into Eclipse as a new project (I could just refresh the one project after switching) but as mathepic suggests there does appear to be several disadvantages associated with that approach (including the fact that I'd have to make sur
<Zand3r> committed work on a branch before switching to another branch)
<mathepic> It looks like it takes away the whole distributed side
<dorins_> mathepic: the branches can be local themselves, each in it's own directory. But the working tree is a lightweight checkout that you bint to any of the branches as you work on them. This way you can share a single eclipse workspace for all branches.
<dorins_> arr,  wifi on linux is still causing me greef
<dorins_> s/greef/grief
<Zand3r> ok... well I've realised that Eclipse can not import projects (branches) that are already in the Eclipse workspace so it seems that branching, etc. needs to take place outside of the Eclipse workspace in which case dorins' lightweight checkout approach might work best in the context of using Eclipse (keeping in mind that I'm [a] new to all this and [b] haven't run through and actually tried it yet)
<Zand3r> Unless i'm totally misunderstanding how to use qbzr-eclipse which does add a 'branch' option to the Eclipse IDE but doesn't seem to then let me use the branch it creates.
<Zand3r> Thanks for the help both of you - I do really appreciate it - I'll continue to work through this
<lifeless> moin moin
<itistoday> how does the bzr-git plugin work?
<itistoday> can't find any docs on it
<lifeless> itistoday: do you mean 'as a user how do I use it' or 'what does the code do' ?
<itistoday> lifeless: the former
<itistoday> sorry for not being more specific
<lifeless> have you installed it?
<itistoday> yeah i think so
<lifeless> itistoday: nothing to apologise for, I just want to answer the right question :)
<lifeless> ok, 'bzr plugins' should list 'git' if you've installed it
<itistoday> yeah it's there
<lifeless> cool
<lifeless> so, generally you  can just give git:// or git+ssh:// urls to bzr now
<itistoday> and then use bzr with it?
<lifeless> there is a new command to do bulk imports from git I think, 'bzr help git' should give some info on that, or perhaps 'bzr help commands | grep git'
<lifeless> itistoday: yes
<lifeless> itistoday: it aims to be transparent
<itistoday> hmm... will git still work?
<lifeless> yes
<itistoday> ah that's good to konw
<itistoday> what if i've already imported something with git?
<itistoday> do i have to re-check it out with bzr?
<lifeless> itistoday: to use it with bzr? its recommended I think
<lifeless> you can just cd to the git tree and run commands like 'bzr diff' 'bzr commit' etc
<lifeless> but I don't think that 'bzr ignore <path>' will do the right thing yet ;)
<itistoday> lifeless: thanks, i'll give it a shot, seems like i need to install dulwich, will do that now
<itistoday> well neat
<itistoday> it seems to work like magic
<itistoday> i'm so happy i can stay in bzr land
<lifeless> :)
<fullermd_> Gehm's Corollary   :p
<itistoday> there's a bzr-hg too :-)
<itistoday> hey cool, bzr 2.0 has been released, need to get that
<itistoday> how do i install dulwich, or any other plugin, and make sure that it only installs into ~/.bazaar?
<itistoday> doesn't seem to be a way... at least for dulwich
<LarstiQ> dulwich is more a support library than a plugin
<LarstiQ> itistoday: it's a python libgit
<itistoday> ah
<itistoday> bzr-hg seemed to work nicely though
<itistoday> guess they work differently
<LarstiQ> hg itself is written in python, no need to write an implementation/wrappers for it :)
<LarstiQ> itistoday: you'll note that bzr-svn uses subvertpy which wraps libsvn
<itistoday> LarstiQ: ah gotcha
<itistoday> wonder what came first, hg or bzr
<itistoday> they're pretty similar
<itistoday> think the hg guys should just team up with bzr ;-)
<itistoday> too many vcs' give developers headaches
<fullermd_> That's on the schedule for right after the X radeon and radeonhd drivers merge, and MySQL and Postgres combine efforts.
<itistoday> hehe
<lifeless> itistoday: bzr came first
<mathepic> Hg started when that one guy stopped giving free BitKeeper licenses to Linux Kernel devs, right?
<mathepic> I have no idea when Bazaar started though
<itistoday> lifeless: thanks
<lifeless> mathepic: thats when git started; hg started a little earlier than that
<mathepic> I thought they both started in response to it
<mathepic> Where is your source? I can't find a "reliable" one
<lifeless> my memory :)
<mathepic> Go fix Wikipedia then :)
<lifeless> mpm - the hg author - is the guy to ask
<lifeless> I *thought* he started sketching stuff out back in feb that year
<RenatoSilva> Someone said here that diff 2.0 2.1 > 1.18 2.0, so what's so new in 2.0 to not justify a 1.19?
<lifeless> RenatoSilva: the default format has changed
<lifeless> this is a very user visible alteration that we want to make sure people are aware of and take the time to upgrade properly; major releases signal such things
<RenatoSilva> if I upgrade to 2.0, will the old branches be converted automatically?
<mathepic> No
<mathepic> bzr upgrade
<RenatoSilva> mathepic: does it work fine? or have you been receiving some trouble reports?
<mathepic> I didn't have to
<mathepic> run bzr upgrade
<mathepic> then bzr check
<lifeless> RenatoSilva: what are you really asking
<RenatoSilva> lifeless: if upgrading to the new format using bzr upgrage will always work fine
<lifeless> RenatoSilva: you should read the upgrade guide
<RenatoSilva> ok it's not trivial then, I'll google for that, thanks
<lifeless> RenatoSilva: it often is. sometimes its not.
<RenatoSilva> ok
<itistoday> is there a way that i can check whether two branches are different?
<Peng_> itistoday: "bzr missing"?
<itistoday> Peng_: thanks, that worked
<itistoday> is there anything special i should do to remove a branch?
<itistoday> or will just rm'ing it work fine?
<itistoday> (it's part of a shared repo)
<Peng_> itistoday: Just rm it. If the branch had any unique revisions, they'll still be in the repo, but it's not worth the effort of removing them.
<Peng_> Unless you, like, added an ISO.
<itistoday> Peng_: thanks
#bzr 2010-10-11
<stewart> hi! I'm trying to write a python program that uses bzr lib to take a series of revisions in one branch A and re-applies them to a subdirectory of branch B (A and B are different and have no common history in bzr, although in reality they do)
<stewart> i've managed to get the logger to output a patch for each revision in the gap i want
<stewart> but... a) i'm sure there's a better way and b) i'm wanting the metadata as a sep object so that I can construct a commit message.
<stewart> I'm also having some issues of revno versus revid and wondering why the difference? as in, why can't i just use the full id everywhere?
<peitschie> hi stewart... things have been rather dead all day here to warn ya.  I suspect the regulars are on their weekend :)
<peitschie> it might be worth posting the questions to the mailing list?
<fullermd> stewart: I can't help you with the bzrlib stuff.  But the reasons for revno vs revid is that they have different properties of permanence and convenience.
<fullermd> Certainly you _can_ just use the revid everywhere.
<thumper> hi stewart
<stewart> fullermd, not in bzrlib calls it seems. i get strange errors passing things around.
<stewart> thumper, hi!
<thumper> stewart: have you looked at a plugin that has replay?
<thumper> stewart: it may not do exactly what you want
<thumper> stewart: but may be close
<stewart> thumper, haven't seen one...
 * thumper wonders where replay lives
<mwhudson> bzr-rewrite i think
<fullermd> Mmm.  I'd be tempted to assume an API that requires a revno and refuses a revid (other than ones inherently biased to that of course) is a bug...
<thumper> stewart: I agree with fullermd about the revid thing
<stewart> most of the things i've seen have either been a) epically undocumented or b) tries something with ids of files :)
<thumper> stewart: I use revid almost everywhere in bzrlib calls
<fullermd> Oh, well, stuff with file-id's is totally outside that axis   :)
<thumper> a revno is a valid revision speci
<thumper> as is revid:some-long-id
<thumper> at least I think so...
<thumper> s/speci/spec/
<thumper> most bzrlib calls will work with revision specs
<stewart> thumper, check out my loop in http://paste.drizzle.org/show/65/  - the obvious of passing in the id from iter_merge_sorted_revisions to make_log_request_dict ends in an error for me.
<fullermd> Revision specs sit way up at the top of the API, right below the UI.
<thumper> stewart: why are you wanting to convert a revid to a dotted revno?
<thumper> for log.make_log_request_dict ?
<stewart> thumper, i don't know.
<stewart> thumper, an attempt to get it to work :)
<thumper> stewart: so... you are trying to get the diff for a particular revision?
<stewart> thumper, yep.
<stewart> thumper, to then apply to another tree.
<mwhudson> stewart: there are definitely easier ways of doing this
 * thumper wants a simple way to do this too
<thumper> abentley pointed me at some docs
<thumper> let me see if I can find them
<stewart> thumper, just for reference, the config file being used is http://paste.drizzle.org/show/66/
<stewart> thumper, the next step is to parse the revision and work out if it would apply or not. as i only want revisions that touch a certain subdirectory :)
<thumper> http://doc.bazaar.canonical.com/developers/integration.html was the doc, but it doesn't give an example of getting the diff
<thumper> stewart: I know there is a relatively simple way to get an iterator of the changes
<thumper> stewart: and check the files for each change chunk
<thumper> stewart: so it shouldn't be too hard...
 * thumper thinks
<thumper> we do get diffs for particular revisions in LP
<thumper> like in the outgoing email
 * thumper checks the code
<thumper>  gah
<thumper> sometimes the bzrlib code reminds me of looking at zope internals
<thumper> stewart: I'll point you at the bzrlib.diff file
<stewart> thumper, luckily, i've never had to deal with zope internals
<mtaylor> zope internals are AMAZINGLY convoluted
<thumper> stewart: http://paste.drizzle.org/show/67/
<stewart> thumper, it would be nice if a bunch of this was exposed via command line interfaces too. for the purposes of what i'm doing now, a list of revisions and a loop in shell would have been fine :)
<thumper> stewart: that is how we get a text representation of the diff between two revisions
<thumper> stewart: yep...
<thumper> stewart: luckily bzr plugins a pretty easy to write
<thumper> stewart: to actually get to the guts of the diff, you need to look at the differs
<mwhudson> stewart: how about this: http://pastebin.ubuntu.com/510517/
<thumper> stewart: IIRC you get some form of iterater over changes
<mwhudson> stewart: then for i in $(seq $(bzr revno)); do bzr diff -c $i > $i.diff; done ?
<stewart> mwhudson, relatively close... the next step being to have teh diff in a variable that i can analyse and change before applying to another tree.
<mwhudson> stewart: use a stringio instead of a real file?
<stewart> mwhudson, looking
 * stewart not a python programmer. is ENOTPERL :)
<stewart> or, rather, ENOTC
<poolie> hi stewart, mwh
<stewart> poolie, hi!
<fullermd> I heard of somebody once doing some stuff with bzrlib via Inline::Python or something   ;)
 * thumper leaves stewart in poolie's capable hands
<spiv> Hi poolie
<poolie> hi spiv, how are you?
<poolie> i thought today i'd try to clear the queues a bit, both mine and others-
<spiv> Sounds good.  I'm going to finish up my split-NEWS branch, then also look at the review queue, seeing as I promised vila I'd look at some of his patches :)
<poolie> k
<poolie> stewart: are you all set now?
<stewart> poolie, possibly... enough to go occupy myself for a while at least :)
<jbowtie> Bazaar doesn't use blueprints?  (according to launchpad)
<jbowtie> Should I just write up my proposal on the mailing list, then?  Or propose an Ubuntu-level blueprint for UDS?
<spiv> The mailing list is a good place for discussion.  For work-in-progress documents (which can include proposals) you could consider a merge-proposal to add to doc/developers/, or a wiki page... and probably post to the list about it.
<poolie> jbowtie: for what proposal?
<jbowtie> poolie: My binary diff/merge proposal. Right now it's sitting in a text file on my hard drive.
<jbowtie> I was thinking of splitting it into three blueprints: core changes, archive handling, GIMP xcf file handling.
<poolie> ok
<poolie> i'm coming to think that doing blueprints
<poolie> can be most useful if you're clear what you're trying to achieve
<poolie> (which sounds obvious)
<jbowtie> ..and therefore?
<lifeless> poolie: you may like to know that consolidation of the various trackers in LP is back on the table
<poolie> sorry jbowtie, distracted
<poolie> therefore, are you writing this
<poolie> - to get it straight in your mind
<poolie> or
<poolie> - to make sure no one objects later or
<poolie> - to get other people to find mistakes before you do or
<poolie> - because you want other people to actually do it..
<poolie> etc
<poolie> i think the spec tracker is most useful, perhaps, when there is a long dependency chain and the person writing the spec is not the one who will implement it
<poolie> but that's not really true for us
<poolie> so for you, i think just sending mail and then turning the thing into user-oriented docs should be enough
<poolie> don't send mails that are individually too big or you may swamp people and they'll glaze over
<jbowtie> OK, that sounds reasonable. I'll split it up into bite-sized pieces for the mailing list.
<poolie> may also help to think 'what is the simplest thing in this direction that could possibly help?'
<jbowtie> Is it helpful to create a tracking bug for future reference?  Once I have some consensus, of course.
<jbowtie> Or is better to just wait until I have a branch with something implemented.
<poolie> jbowtie: well, do whatever helps you best
<poolie> my feeling is that bugs generally should be something where you can say when it's done
<poolie> or at least you should be able to decompose them into that
<poolie> so a bug like "should support managing non-source files" is kinda true but it's pretty hard to say when you have enough "support"
<poolie> but if you make it something more specific about diffing an archive by diffing the components
<poolie> it's more clear what's needed
<poolie> and you can always file more bugs ify ou want more
<poolie> spiv, in https://code.launchpad.net/~mbp/bzr/http-messages/+merge/37931 i'm inclined to just land it
<spiv> poolie: +1
<poolie> thanks
<spiv> poolie: I can definitely think of more nice-to-have things (e.g. checking for content-type == text/html before munging), but I'd rather have it landed than wait for polish that will rarely matter.
<poolie> mm
<poolie> this area is in practice really messy
<spiv> Yeah, exactly.
<poolie> exhibit A, the tendency for browsers to hide the error message together even though it's html
<spiv> So I'm happy for incremental improvements to be driven by practical experience.
<spiv> Rather than what I think would be nice-to-have :)
<poolie> spiv, i don't know if this was you but "compatibility breaks" seems to list a lot of internal changes at the moment.
<poolie> or were you trying to fix that?
<spiv> I don't recall doing anything to cause or fix that.
<spiv> I did move some news entries to b3 that were misattributed to b2, I don't think that involved any recategorisation thouhg.
<poolie> k
<poolie> i might fix them up but i don't want to clash with your splitting-up branch
<spiv> It shouldn't clash, or if it does I think I can cope without undue pain.
<poolie> still otp?
<poolie> you know we could just keep NEWS for the current series and move it away for old ones
<poolie> if that's an easier change
<spiv> poolie: not otp, but still helping thumper somewhat
<spiv> I think that's fractionally harder, actually, because it makes the build logic slightly more complex
<AfC> Hi
<poolie> hi afc
<poolie> spiv, hi, iirc keyboardinterrupt is under systemerror, not exception?
<spiv> poolie: in recent Python (definitely 2.6, maybe 2.5?) it is under BaseException but not Exception, yes
<spiv> I'd be ok with catching and reraising it explicitly if you like
<poolie> i think it's good the way it is
<poolie> in general i think it's pretty important repr methods don't crash
<gour> morning
<gour> can someoned comment some of the points mentioned in regard to bzr in http://selenic.com/pipermail/mercurial/2010-April/031191.html ?
<poolie> ah, i don't know
<spiv> gour: most of those points are a matter of personal taste, as the poster says.
<poolie> one benchmark recently found us faster than them on commit
<poolie> and some other operations
<poolie> but people who don't like that result can always find a different benchmark
<gour> spiv: in few places, iirc, i saw criticism at "bazaar relies on a linear integer index for its revision numbering
<gour> are there any consequences about it?
<poolie> we have a deterministic numbering of revisions on any graph
<spiv> gour: I've seen other people comment on how much they like our revnos compared to the other DVCS systems.
<spiv> gour: matters of taste can have consequences :)
<poolie> hg last i looked had a numbering that varied between different copies of the repo depending what order they pulled
<gour> spiv: heh
<gour> after mostly stopping using darcs, i used monotone a bit, which i like, but considering whether bzr/hg may be better due to wider support
<poolie> oh, and for colocated branches, i think bzr-colo is very very nice
<gour> that's plugin?
<poolie> yes
<gour> btw, what's with fast-import plugin after Ian left us?
<spiv> No-one is actively working on it, but it also seems to be working very well for most people.
<glyph> is there a way to list branches in a remote repository?
<glyph> 'bzr ls' seems to only work on branches.  I'm looking for some equivalent to 'svn ls .../branches/'
<gour> spiv: https://bugs.launchpad.net/bzr-fastimport/+bug/541626
<ubot5> Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors' (affected: 5, heat: 24)" [High,Confirmed]
<fullermd> gour: 'bzr ls' is for listing stuff within a branch.  bzrtools provides a 'branches' command that lists branches under a given location.
<fullermd> (but only on indexable transports)
<gour> fullermd: you thought about glyph ^^^
<fullermd> Bah.  All you 'g' folk look alike   :p
<vila> hi all !
<fullermd> Well, there goes the neighborhood.
<vila> On the subject of neighbourhood, I heard complaints about goat smells....
<vila> no pointing fingers of course
<fullermd> Goats?  I don't see no *burp* goats 'round here...
<poolie> hi vila
<vila> poolie: hey !
<glyph> fullermd: what makes a transport 'indexable'?
<fullermd> glyph: Roughly, "I can do ls on it"
<vila> glyph: the ability to list a directory
<fullermd> So e.g. http doesn't count.
<glyph> PROPFIND!
<fullermd> sftp does.
<glyph> you can hella do ls on http.
<poolie> and webdav does
<poolie> maybe we should do that
<vila> glyph: PROPFIND is for DAV and can work for more than just directories iirc
<glyph> vila: I work on calendarserver.org, so I know _all about_ all the crap PROPFIND can do ;-)
<glyph> but one of the things it can do is list a directory.
<vila> glyph: great ! :)
<vila> glyph: thanks for confirming :)
<spiv> Doesn't the bzr-webdav plugin provide listdir?
 * glyph tries 'bzr branches' on a few representative things
<spiv> (Although you may need to use http+webdav as the url scheme)
<vila> spiv, glyph : yes, bzr-webdav does it (with PROPFIND ;-) but it's rather crude (from memory)
<vila> I haven't touch this plugin code for the last two years :-/
<vila> err, last year
<vila> times doesn't fly that fast finally
<lifeless> poolie: so, I'd return a small class with __iter__
<lifeless> poolie: -or-
<lifeless> poolie: there is a iter caching decorator around somewhere
<poolie> i thought about that but it seems too easy to get it wrong and have it accidentally called earlier
<lifeless> its trivial, might want to embed it itself
<poolie> and then i thought, yagni
<poolie> load_tests is called barely any later than the test module is loaded, probably
<poolie> so you just need to make sure any wanted stuff is created earlier
<lifeless> first iter it iterates its delegate, caches the results, etc
<lifeless> poolie: yeah, also in bzr's case its registries are initialized before any tests are laoded.
<lifeless> library init, plugin load, test load
<poolie> right
<poolie> i do think in the other course there are a couple of antipatterns
<poolie> one is holding an iterator in a place where it could possibly be resued
<poolie> because the second attempt will tend to just look like [] rather than an error
<poolie> and the other is anything that takes "might be a callable or might just be the thing" tends to give a similar trap
<lifeless> poolie: I don't like the 'might be callable or object'  either ;)
<poolie> specifically saying '.scenarios' might be a list or might be callable (or a list of callables) is a dangerous idea
<lifeless> poolie: agreed; it is currently defined as 'an iterable' which implies 'not a generator'
<lifeless> (for it to be a generator it needs to be defined as 'an iterable which will be iterated once'
<lifeless> (as you know :P)
<lifeless> afk for a bit
<vila> spiv: I briefly looked at your split-NEWS mp, sounds nice, don't forget to fix all references and usage descriptions in docS though
<spiv> vila: thanks
<peitschie> hi guys.... is there an easy way to get from the sha1 to the commit message for a given rev in a tree?
<spiv> vila: it also needs some of the non-sphinx glue fixed up :/
<vila> spiv: exactly, or we should accelerate the switch-to-sphinx work
<vila> peitschie: sha1 ? Did you mean revid ?
<peitschie> vila: as in the specific key that is printed in the sha1 static tuple thingy
<vila> peitschie: ECONTEXT
<fullermd> I put those little sheets in my dryer to avoid static tuple thingies.
<spiv> peitschie: static tuple thingy?  Are you trying to debug a traceback?
<peitschie> spiv: yup...repo keeps dying from bug #485601... i have tried reconcile and a few other things... but it works for a few commits then dies again
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<peitschie> vila: so i have dropped into a pdb session and found NoSuchRevision(<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x01C1EAF0> has no revision StaticTuple('sha1:9e2e17285dde089256cf0a2567416008c67559b4',))
<peitschie> vila: I don't quite understand how to get the ECONTEXT from there however....
<vila> poolie: https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 might be a good place to play with your new ideas about load_tests, there are a nuch of very similar tests there that could be parametrized from the _ubuntu_series_shortcuts dict
<vila> poolie: there are fine *as is*, but look simple enough for you to play with too
<vila> peitschie: haaa. now you give me context :)
<peitschie> vila: I only just got the error back again :)... sorry!
<vila> peitschie: so this sha1 is not directly linked to a tree revision, more probably linked to a *file* revision, so the way to the commit message is a bit longer
<spiv> peitschie: your original question isn't very on target, because that SHA-1 is not directly associated with a particular revision
<spiv> (And quite possibly there are multiple revisions referring to that record)
<peitschie> spiv: indeed :).  I'm trying to figure out the revision at which things are starting to go haywire :)
<vila> peitschie: you probably need to go up a bit in the stack...
<spiv> peitschie: are stacked branches involved?
<peitschie> spiv: is a bound branch the same as a stacked?
<spiv> peitschie: no
<peitschie> spiv: as far as I know I have no stacked branchs... I do have a local repo, with a bound branch that points to a remote repo though
<spiv> peitschie: if you don't know what stacking is, and you aren't hosting the branches on Launchpad, then it's reasonably safe to say it isn't involved.
<spiv> Is bzr-svn involved?
<peitschie> yupperz
<peitschie> sorry... need to clarify that
<peitschie> the central trunk code gets checked into is svn
<vila> poolie: oh, re-reading the comments on https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787, yes a helper first and on top of that the parametrization, I was thinking about adding the helper myself as part of landing, thoughts ?
<peitschie> so most dev changes are bzr => svn => bzr
<peitschie> having said that, this exact bug is bzr => bzr
<spiv> peitschie: have you tried the suggestion in jelmer_'s latest comment?
<spiv> (upgrade to bzr-svn 1.0.4 or newer and a fresh conversion from svn->bzr?)
<peitschie> spiv: that is likely a good place to start.  I've upgraded and run reconcile on the central repository, but the challenge is the difficulty of migrating all teh version history across to a "clean clone"
<spiv> *nod*
<peitschie> spiv: i'm not sure of an easy way to simply fetch all the ghosts from the old repository... or whether that might defeat the whole purpose of the clean clone and migration
<peitschie> spiv: is it likely to be a bad idea to use fetch-ghosts or similar do you think?
<spiv> peitschie: so
 * spiv hmms
<spiv> I'd try making a new shared repo, and branch into it all the branches you already have in SVN
<spiv> Then I guess try to branch across all the others
<spiv> I don't think it would hurt to try fetch-ghosts
<spiv> Although my guess is it won't help
<spiv> I have something else that may help
<peitschie> spiv: the branches into the new one is painful... there is currently >500 I think :)
<peitschie> spiv: yah?
<spiv> peitschie: bzr branch lp:~spiv/+junk/bzr-chk-used-by ~/.bazaar/plugins/chk_used_by
<spiv> Then look at 'bzr help chk-used-by'
<spiv> It may help you answer your original question
<peitschie> spiv: oh!  thas cool :)... thanks very much for that
<spiv> peitschie: IIRC it expects keys to be written as 'sha1:........'
<spiv> it's pretty rough and simple, just something I threw together for debugging a different bug a while back.
<peitschie> spiv: hmm... comes out blank on both sides
<spiv> peitschie: I don't think it will ever give any results on an SVN repo
<peitschie> spiv: i've tried various combinations of with and withouth sha1 :)
<peitschie> spiv: yep... I'm running this between the bzr => bzr broken stuff
<spiv> well, it can't tell you about keys that aren't there, of course :)
<spiv> Well, hmm.
<spiv> And it only reports CHK root keys, I guess.
<peitschie> i figured ;)... i'm running this in on boths sides of the break
<peitschie> oh... so this could likely not be a root key then
<spiv> Actually, it will tell you about any root key that is referenced by an inventory in your repo.
<spiv> I don't think it actually requires that root key to even be present (although perhaps it would raise an exception if it isn't?)
<peitschie> spiv: hmm... quite mysterious.  do repo => repo transfers cause any inventories to be re-evaluated in any way?
<peitschie> spiv: I wonder if this is related to ghosting somehow
<vila> ping losa about pqm upgrade status
<mthaddon> vila: it's on my list - should be able to get to it soon
<vila> mthaddon: great ! And which kind of upgrade will be done ? I'm waiting for a testtools one myself, but I understand a lucid one has also been discussed
<mthaddon> vila: I thought you'd rejected that possibility as you wanted to maintain python2.4 compatibility?
<vila> mthaddon: indeed, but I lose on this front, I need to address it in another way, hence my question :)
<vila> mthaddon: indeed, but *if* I lose on this front, I need to address it in another way, hence my question :)
<mthaddon> I wasn't aware of that...
<vila> aware of what ?
<mthaddon> (from your first comment it sounded like you had "lost" at that and we were going to upgrade to lucid)
<vila> or did my missing *if* started a misunderstanding :-/
<vila> no, I have no idea why the lucid update is proposed so I don't know if it's required for some more important reasons or it if makes it impossible to only upgrade testtools, hence my query for status
<poolie> vila, hi there
<poolie> i'm going to sign off soon
<poolie> i'm interested in what you think about https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941
<poolie> and about news
<poolie> thanks for making a 2.3b2 freeze
<vila> poolie: clarification about news, I duplicated the entries as it was the *current* policy, I agree we should change the policy, but until it's done, I've applied the old one
<poolie> fair enough
<poolie> i think soon spiv is going to split the news files and that would be a good moment to change
<vila> poolie: exactly, I've looked at it but it's not proposed yet and I've already asked for the docs to be fixed too :) This kind of imply explaining how we should address that :)
<vila> about the http test, I agree with the approach (I haven't review it yet, I'm starting pp'ing with non-core contributors ;) but it seems you're also discussing it with lifeless so I was tempted to wait for more stuff from you ;)
<vila> poolie: s/variations/scenarios/ sounds nice to me
<vila> for the attribute name I mean
<vila> poolie: and my remark about barry's shortcuts was related too
<poolie> sorry, which remark?
<vila> <vila> poolie: https://code.edge.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787 might be a good place to play with your new ideas about load_tests, there are a nuch of very similar tests there that could be parametrized from the _ubuntu_series_shortcuts dict
<vila> <vila> poolie: there are fine *as is*, but look simple enough for you to play with too
<vila> poolie: I went ahead, introduced the helper and sent the result to pqm already
<poolie> ah, yes
<poolie> i think, generally, if you can write it out just as a series of tests
<poolie> or a static list, in a single test, that might be better?
<poolie> maybe not - if they're variations then you can run just one of them
<vila> well, the problem with a single test is that you get only one failure...
<poolie> right
<poolie> anyhow, i should go
<poolie> good night
<Christian12> Hi I have a general question concerning version control tools. atm we have a central coldfusion test server(unix). The developers run windows machienes and work directly on the files on that system. when the development is dont the files are replicated to the prod system. Which bazaar workflow would fit best in this case? Do I need to install on all local machines a webserver + coldfusion?
<vila> mthaddon: can you clarify why a lucid upgrade is needed ?
<mthaddon> vila: it's not necessarily needed - it's just that's what we're upgrading all the servers in the DC to, so we were asking if it made sense to do that
<vila> ok
<vila> grrrRRRR pqm submission failing but no mail :(
<vila> ping losa, two of my last submissions to pqm failed and I didn't get the associated email
<vila> old problem with some MTA dropping it because it's too big, but I can't reproduce locally and I need some hints about which tests are failing :-/
<vila> the submissions are related to https://code.edge.launchpad.net/~vila/bzr/609186-shortcuts/+merge/38098
<mthaddon> vila: we're getting mail returned from the address PQM is trying to send to...
<mthaddon> vila: seems your smtp gateway thinks it's spam and is rejecting it
<vila> mthaddon: ha !
<vila> mthaddon: argh :(
<vila> mthaddon: can you forward to my canonical email both the pqm mail and the spam report ones ?
<mthaddon> k, have done
<vila> thks !
<vila> I hate spam and it's unintended consequences....
<vila> mthaddon: I got the spam report one but not the pqm one (that part cited in the first doesn't mention any failure)
<mthaddon> vila: that email includes the entire test run output
<vila> mthaddon: the spam report says it's truncated but more importantly, I see *no* failures there
<mthaddon> vila: what about https://pastebin.canonical.com/38477/ ?
<vila> mthaddon: it's an *expected* failure XFAIL not FAIL
<mthaddon> well there's definitely something it doesn't like: > merge http://bazaar.launchpad.net/~vila/bzr/609186-shortcuts http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<mthaddon> > Command failed!
<vila> mthaddon: right, that's why it doesn't get merged, but this doesn't tell me why. I briefly see ~36 failures in the summary on the pqm web page but no details
<vila> mthaddon: I received mails for other failures for other mps though: Conflicts during merge: Text conflict in NEWS
<vila> mthaddon: I *can* address these ones, but the one I ask your help about seem to be related to *test* failures, that's why I need the pqm email which is supposed to include pqm-stdout.gz and pqm-stderr.gz
<mthaddon> I don't have access to that
 * vila bangs head on desk
<mthaddon> if you can fix your SMTP server, you can resubmit and they'll get sent through
<vila> mthaddon: my ISP smtp server ? I can't fix that. I'm searching the right way to get in touch with them about their spam filter going mad
<mthaddon> or you could submit from an email that doesn't have a broken spam filter
<vila> hmmm, pqm authenticates on the gpg signature not the originating email right ?
<vila> nah, the gpg sig *is* for a given email
<vila> mthaddon: by the way, isn't there a RT ticket about configuring the news_merge plugin on pqm (which would have let 3 of my proposals goes through instead of failing) ?
<mthaddon> there may be - we've been a little busy with the release recently... :)
<vila> mthaddon: I'm not complaining, just checking that it has been reported correctly
<vila> mthaddon: I fully realize the help you're providing
<vila> gah, no irony intended in this :-(
<mthaddon> none taken :)
<vila> mthaddon: it's just that I'm patch pilot this week and as such the main pqm user so I try to sync on what is needed :-/
<vila> well, I'm also the RM so even more pqm uses...
<vila> starting with 5 submissions and getting 5 failures including 2 with no clue about what failed made me a bit... you know... surprised :)
<mthaddon> vila: I do see three pqm log files on the server with "Conflicts during merge: Text conflict in NEWS" in them about 45 mins ago
<mthaddon> dunno why PQM is running the test suite if there's a merge conflict though...
<mthaddon> that seems sub-optimal
<vila> I've got mails for ~nmb/bzr/311518-apache-doc-rewrite , 551391-log-memory-usage and ~nmb/bzr/484101-default-format
<vila> but they all say: Ran 0 tests in 0.000s
<vila> so I'm pretty sure the test aren't run if the merge fails
<mthaddon> hmm
<vila> I'm after thw two other (really the same submitted twice) where tests have failed (to the best of my understanding)
<vila> (the fact that I got mails for failures doesn't make the spam report easier to understand either :-/ But that's clearly another topic :)
<mthaddon> what time would they have been sent?
<mthaddon> and does this look possible - http://paste.ubuntu.com/510805/
<vila> just before the others... 2hours before at most
<mthaddon> that paste is the previous one to the merge failures
<vila> argh, the traceback is not supposed to lead to a failure :-(
<vila> it's a transient issue
<vila> err
<vila> sporadic issue
<vila> mthaddon: I suspect this traceback escaped the redirections, is still not leading to a failure and that we just need the redirected files.... which may not be on pqm anymore having been sent by mail :-/
<vila> mthaddon: I assume you didn't edit that pastebin of course (just checking the 1% unlikely event ;)
<mthaddon> nope, didn't edit it
<Amythang> I did a push to a new location, I was expecting the source to go over but only the .bzr dir went, whats the best way to do this?
<Amythang> maybe I should start from beginning, I'm a lone developer, been using bazaar on my local machine. Now I have to move my stuff to the live server for the first time
<Amythang> should I install bazaar on the live server or am I ok with pushing the changes to server?
<zyga> (disk wise)
<vila> Amythang: the usual big question is: do you need the history on the server (the .bzr dir) or do you need the files themselves (the working tree)
<vila> Amythang: or both or some variant ? (Including: eerk, I certainly don't want the history to be readable by everybody on the internet, it's a web site ! I only want to publish the web site !)
<Amythang> yes good point, I guess I will not need the history
<vila> Amythang: in that case, have a look at the bzr-upload plugin
<Amythang> ok thanks :)
<vila> Amythang: and start by removing the .bzr dir on the server
<millun> hi, wondering what i should use for Eclipse's /workspace/ dir. colocated repository, right?
<dOxxx> mornin'
<vila> dOxxx: hey !
<vila> millun: sounds right
<millun> thanks vila
<vila> millun: I assumed you mean using bzr-colo right ?
<millun> i am using the GUI thingy. yes, prolly
<vila> millun: I know little about it :-/ But I suspect they use 'colocated' as implying that
<vila> dOxxx: Just read your mail, perfect
<vila> dOxxx: if you have any doubt about which plugin version you should use, the default answer should be: use trunk, we'll see with plugin authors about doing proper releases before 2.3.0final
<vila> use tip from the trunk I meant
<vila> jam: ping
<vila> jam: can you try to feed-pqm https://code.edge.launchpad.net/~vila/bzr/609186-shortcuts/+merge/38098
<vila> jam: pqm just hates me and I can't reproduce any error with that whatever I try (including using the hardy slave which should almost identical to pqm)
<vila> jam: losa told me the mail is bounced by my ISP as being spam :-( So use my canonical address to forward it to me if you get one
<vila> jam: pingeling ?
<vila> mgz: ping
<jam> vila: I'm off today (Columbus day) but since I'm around right now, do you still want me to propose it?
<vila> jam: argh, damn, sorry :(
<jam> Well, I am around right now
<vila> jam: yes please, this drives me nuts
<jam> sent
<jam> I'll forward you whatever pqm tells me
<vila> jam: I'm trying to contact my ISP about it, but it's.... non-trivial :-/
<vila> jam: great !
<vila> jam: got something ?
<jam> vila: text conflict in NEWS
<GaryvdM> Hi all
<GaryvdM> jam: poolie has given me access to the aws account, so I can start and stop instances :-)
<GaryvdM> jam: last time I used it, I tried to create a new snapshot. But I don't have access to shutdown, which I believe is necessary to create a snapshot.
<GaryvdM> Stopping the instance does not work...
<GaryvdM> jam: When the instance is up, please could you give me permission to do that.
<vila> jam: pqm is *really* playing with my nerves, merged, conflict resolved, care to try again (I'm out but will pass around later) ?
 * GaryvdM waves to villa
<vila> GaryvdM: _o/
<vila> jam: Of course this NEWS conflict is *not* the problem I'm after, just a fallout of *other* mps I've landed
<dOxxx> bzr 2.3b2 mac os x 10.6 installer uploading
<dOxxx> vila: config changes for 2.3b2 mac os x installer have been pushed. you can pull and build the 10.5 installers anytime.
<vila> dOxxx: fetch-externals.py -p -u ?
 * jelmer waves to vila, d0xxx, GaryvdM, jam
<dOxxx> vila: yes
<dOxxx> hey jelmer
<vila> dOxxx: cool, uploading then :)
<vila> hey jelmer !
<vila> jelmer: you can upload 2.3b2 to debian ;-)
<maxb> vila: he already has
<vila> meh, why isn'y it showing on http://packages.debian.org/search?keywords=bzr then ?
<vila> not complaining, just trying to understand !
<maxb> sid (unstable) (vcs): easy to use distributed version control system
<maxb> 2.3.0~beta2-1: alpha amd64 hppa i386 kfreebsd-amd64 kfreebsd-i386 powerpc powerpcspe sparc sparc64
<vila> sid ? shouldn't that be experimental ?
<vila> maxb: and where did you get that ? I learned about 'rmadison -u debian bzr' last week but it's still a different output
<vila> maxb: will you update the beta ppa ?
<maxb> vila: What I pasted into the channel, I copied from the link you provided
<jelmer> vila: I've already uploaded it yesterday evening :-) it should turn up at some point today.
<maxb> As to why sid, well, jelmer's preference, I suppose? :-)
<vila> jelmer: cool :)
<vila> maxb: interesting, it's not showing in my firefox... cache issue ?
<dOxxx> vila: At some point, I would like to clean up the mac installer scripts to move some of those functions out of config,.py and into build.py, and improve fetch-externals.py to be a bit smarter about what and when it updates and downloads. If you have any suggestions, feel free to make merge proposals.
<maxb> I suppose
<vila> dOxxx: I did :) I'd like config.py to be turned into a isntaller.conf as some point :) I thought you were in the CC: or even in the To: of the email I wrote about that...
<GaryvdM> vila: Must be cache - I see 2.3.0~beta2-1
<GaryvdM> ctrl+F5
<dOxxx> vila: oh yeah, I saw that. I actually kinda prefer it as a python source file since that gives it some flexibility while still being a syntax that everybody understands
<vila> right, it was cached
<dOxxx> vila: I'm a great believer in python syntax as a config language, I even wrote a config language for my work that uses python syntax :)
<vila> hehe
<vila> dOxxx: I don't think we would go as far for bzr, if only for security concerns
<dOxxx> vila: as a remote downloaded config file?
<dOxxx> I suppose yeah that could have security concerns
<vila> dOxxx: yes, think branch.conf and may be soon repo.conf and project.conf or company.conf
<dOxxx> hmm
<dOxxx> XML! ;)
<vila> dOxxx: you can't allow arbitrary code to be taken into account when you pull/merge/commit
<vila> dOxxx: I thought you said user-friendly ? :)
<dOxxx> :)
<dOxxx> well, it's that or write something from scratch
<dOxxx> I dislike ini files, they're very limited
<dOxxx> are the windows installer config files using ini format?
<vila> dOxxx: well, we use configobj which is an ini-like syntax, but values can be strings or list, sections can be used for dicts, the variable names accept dots, so you can also use that to have dicts
<GaryvdM> dOxxx: No - They python
<dOxxx> GaryvdM: oh yes, I remember now, they use classes instead of just dicts and lists
<vila> dOxxx: no, but I'm talking about bzr config files and if they can't address the installer needs, that may be a sign we need to support more features (or think about how to use them better)
<GaryvdM> http://bazaar.launchpad.net/~bzr/bzr-windows-installers/trunk/annotate/head%3A/bazaar_releases.py
<dOxxx> vila: I see
<vila> GaryvdM: by the way, I found the bazaar releases calendar back (see 2.3b2 wiki page) but it seems I can't update it
<vila> note to self: ping poolie about it
<dOxxx> vila: if we were to use the bzr config file format, then we'd have to agree on a common set of conventions on the layout on top of that, to be able to share it amongst windows and mac
<vila> dOxxx: that's exactly what I wanted us to discuss on the ml :)
<vila> GaryvdM: on the other hand, the fact that the calendar exists and that nobody use it (and even forgot about it) may be an indication that it's not the right tool ;)
<vila> GaryvdM: I tend to use launchpad for that, the https://edge.launchpad.net/bzr/+series page is a good summary for me
<GaryvdM> vila:  I was thinking about it, and I think that launchpad should be able to output milestones and releases as a ical. I'm going to log a feature request...
<vila> GaryvdM: good idea
<dOxxx> vila: I'm replying on the ML
<vila> dOxxx: great
<GaryvdM> vila: I would like a ical so I can load into tb+lightning.
<vila> tb.... tb ?
<GaryvdM> thunderbird
<vila> ha, of course
<vila> all I could think of was traceback :)
<vila> I should really go to sleep, tomorrow will be another long day :)
<vila> have fun !
<GaryvdM> Good night.
<dOxxx> vila: night!
<achiang> is there a bzr way to do 'git rebase' ? google tells me of a plugin, but i'm not terribly excited about plugins. maybe there's an idiomatic bzr way to do it?
<dash> the idomatic way is to not rebase, generally
<dash> what's your situation?
<dash> what are you tryign to deal with>
<achiang> i want to do some work based on a branch that has a merge proposal (in launchpad) but hasn't landed yet
<achiang> call the proposed branch "A" and the new work i want to start "B"
<dash> sure. so you can merge the merge proposal into your branch and then do your work,
<achiang> oh, but "A" and "B" both branched from master at the same time
<dash> sure, that's fine.
<achiang> i guess coming from a git world, i don't really want to introduce a merge commit into B
<dash> why not?
<achiang> it's technically correct, i understand this point. but it just looks strange to me when reading branch history
<dash> oh?
<dash> it indicates clearly what your history is
<achiang> i guess i want my history to look more linear
<achiang> i'm not describing my "issue" very well
<dash> well, it will
<dash> your trunk will show a merge from A then a merge from B
<dash> s/trunk/master/, whatever :)
<achiang> B requires code in A to work properly. thing is, i started B a while ago before i knew that i needed A
<achiang> that is, i started down the B path, got some stuff working, then realized that a cleaner way to accomplish B was to have some other code that was logically separate. so i refactored trunk to incorporate A
<dash> achiang: sure. so merge A into B, no worries.
<mwhudson> achiang: the 'avoiding merge commits' thing is considered a non-goal in bzr
<dash> that won't affect your mainline log view.
<achiang> a normal person would have simply done A, and then done B. i want the history to resemble what a normal person would have done. :)
<dash> achiang: why?
<achiang> ah, so if i merge A -> B now, and then A -> trunk and then B -> trunk, the A->B merge doesn't appear in trunk?
<dash> achiang: like i said, your 'bzr log' output on master will contain the merge commit from A and the merge commit from B
<dash> achiang: not at the top level. it's a nested commit of the merge into master.
<dash> so the data is there if you look for it but it's not displayed by default.
<achiang> mwhudson: i mean, git allows these merges too. it's just a workflow issue
<mwhudson> achiang: well yeah, but the tools and conventions are oriented around common workflows
<achiang> dash: to answer your "why do you want that" question, it's mostly to satisfy my own quirks. i'm coming from a kernel workflow where we work hard to avoid merge commits if possible, mostly because that's the convention that the kernel community has settled on. one way that "leaf node" developers can avoid merge commits is by using a rebase command
<dash> no comment on the mental health of kernel developers :)
<achiang> of course, there are other workflows as well, and that's why i'm asking here to see what other folks do
<achiang> so in bzr-land, merge commits are no big deal, i guess
<dash> right
<achiang> and i guess i could embrace that convention. it'll just take some personal readjustment. :)
<achiang> mwhudson: dash: thank you for the advice.
<mwhudson> achiang: np
<Kamping_Kaiser> and incase it wasn't mentioned, bzr has a rebase too :)
<GaryvdM> Kamping_Kaiser: Yes - achiang did say he read of the plugin
<Kamping_Kaiser> GaryvdM: thanks; i missed it in the scrollback
 * Kamping_Kaiser will lurk more
<GaryvdM> Kamping_Kaiser: Sorry - I did not mean for that to sound harsh.
<Kamping_Kaiser> GaryvdM: no problem, i didn't take it that way
<peitschie> mornin all
<poolie> hi jam?
<poolie> lifeless: if nothing is on fire would you be so kind as to reread https://code.edge.launchpad.net/~mbp/bzr/597791-http-tests/+merge/37941
<thumper> poolie: hi
<poolie> hi there thumper
<thumper> poolie: got time for a call?
<thumper> poolie: I have a few questions
<jam> hey poolie, today is a holiday, so I'm mostly off, but if it is something quick, I'm around right now
<poolie> jam, not urgent, just saying hi
<poolie> i forgot it was still your monday
<poolie> have a good day
<GaryvdM> Hi poolie, jam.
<GaryvdM> poolie: could you maybe help me with the thing I asked jam earlier?
<GaryvdM> not sure if it's in your scrollback?
<poolie> probably not, can you ask again?
<GaryvdM> poolie: last time I used the ec2 instance, I tried to create a new snapshot. But I don't have access to shutdown, which I believe is necessary to create a snapshot. Stopping the instance does not work...
<poolie> within the vm, you don't have permission to shutdown?
<GaryvdM> poolie: no - and I think you xan give that to me without giving me full admin
<GaryvdM> *can
<poolie> jam, still here?
<jam> poolie: yeah. You can do a snapshot from the ec2 console
<jam> vs the commandline tools
<jam> for some reason the website is able to reliably shut it down, but the firefox extension and the command-line tools didn't seem able to
<jam> anyway, heading out now
<GaryvdM> jam: should I try ie?
<poolie> i think i've seen it not take the snapshot until it shuts down
<poolie> thumper: remote.py, _rpc_open_2_1
<GaryvdM> poolie: yes, but I cant shutdown, only stop. Ill try see if I can shutdown using msie..
<peitschie> wow... i'm impressed
<peitschie> i've just branched our entire repo with the process taking a peak of 2Gb under linux
<peitschie> avg around 500mb-1gb
<peitschie> 6500 revs.... with some largish individual files in it
<peitschie> i couldn't do this in one sitting 3 months ago :O
<peitschie> (this is bzr+svn btw as well)
<poolie> peitschie: that's great
<jelmer> 'morning peitschie, poolie
<poolie> hi jelmer, gary
<poolie> gary, you have your own local account on the machine and it's not allowed to run shutdown?
<peitschie> mornin jelmer :)
<GaryvdM> Yes
<lifeless> poolie: reread
<poolie> thanks
<poolie> hi GaryvdM
<GaryvdM> poolie: Hi
<poolie> it might be simplest if you get jam to give you that access tomorrow
<GaryvdM> poolie: Ok
<GaryvdM> I'm busy trying to see if I can do et from msie.
<GaryvdM> *it
<GaryvdM> Nope. I'll ask John to help tomorrow.
<maxb> jelmer: You uploaded 2.3b2 to unstable, but didn't push to pkg-bazaar
<jelmer> maxb: Woops
<jelmer> maxb: Pushed, sorry.
<maxb> jelmer: bzr mark-uploaded? :-)
#bzr 2010-10-12
<maxb> Hmm
<maxb> I was going to push 2.3b2 to the beta-ppa
<maxb> But now I think it would be better if I first figured out how to make bzr selftest run as part of the build
<maxb> But I'm too sleepy for that, so later.
<lifeless> mgz: around?
<thumper> poolie: I've been thinking about the underlying problem
<thumper> poolie: and I've come up with two repeating problems
<poolie> ok
<thumper> 1) we have no initial idea if we are trying a write or read operation
<thumper> 2) we don't have a clear way to ask "does this exist" without poking the filesystem
<thumper> by removing the FileNotFound errors
<thumper> it opened a world of hurt
<thumper> which stopped being able to push branches
<thumper> and I can't think of a clean way to get errors out of translatePath
<thumper> with lead me to think that we should have an earlier check
<thumper> which can have better "smarts"
<thumper> I wish we had some smart command that allowed us to say: I want branch "X" for writing
<thumper> or I want branch "Y" for reading
<thumper> although even that probably isn't enough
 * thumper is thinking stacking
<thumper> we could then do our smart branch lookup
<thumper> with clean semantics early on
<poolie> i agree specifying that earlier would be good
<poolie> it would also let us give a better message on http
 * thumper nods
<lifeless> what are the contracts and constraints of translatePath ?
<thumper> lifeless: well...
<thumper> lifeless: probably best talked through if you're willing
<poolie> what do you mean by "without poking the filesystem"?
<peitschie> jelmer: are you around atm?
<jelmer> peitschie: yep
<peitschie> jelmer: cool.  a quick query, I'm recreating our svn repo from scratch, but want to preserve the history from the existing bzr branches.... is fetch ghosts likely to reintroduce any history issues?
<peitschie> jelmer: or is there a better way to get the bzr history linked up in the new repository?  theres quite a few branchs (~400 i think...) so manually is a little bit painful :)
<peitschie> jelmer: a bit more context might help for you... specifically, we've encountered bug #485601 again... I didn't create the new repo last time as suggested so am doing it now :)
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<peitschie> jelmer: argh... realised that missed some vital joining bits as well!  What I *mean* to say, is I am creating a new bzr shared repo from the existing svn trunk
<jelmer> peitschie: yeah, fetch ghosts should do the right thing in that case
<peitschie> jelmer: cool!  that will make this a lot less painful than I feared
<poolie> thumper: i'd like to see a bug saying what the behaviour ought to be case by case
<peitschie> jelmer: oh... that was a fun experience
<peitschie> jelmer: I can't fetch ghosts... as this encounters bug #485601 again
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<jelmer> :-(
<peitschie> i suppose that makes sense... lol... now just gotta find a way to fool things...
<peitschie> hmm... there seems to be a specific checkin that has poisoned the broken repo
<peitschie> as soon as I attempt to pull any branch across that references this broken rev, things go dodgey
<peitschie> awww... i scared jelmer off :(
<peitschie> jelmer: if I can hunt down the exact svn checkin that causes this rev error... would that be of any assisstance with the missing chk nodes bug?
<jelmer> peitschie: I'm not sure - didn't somebody (you?) already post a script for reproducing the chk node bug?
<GaryvdM> Yhea - Productive night for me. - Goodnight all...
<peitschie> jelmer: I haven't been able to yet.  I posted some more thoughts about it... but I keep struggling to be able to reproduce
<jelmer> g'night Gary
<peitschie> jelmer: i'm pretty much shooting in the dark with the latest one, as I spent ages the other night trying various permutations to try and get the crash.  I've posted up on that bug the exact workflow we use essentially... but haven't been able to narrow down why it works 99% of the time
<peitschie> jelmer: bzr-svn is frustratingly stable sometimes :D
<jelmer> peitschie: a way to reproduce the chk node bug or even a public repository that demonstrates the issue would be a big help.
<jelmer> peitschie: unfortunately this is a combination of a bzr-svn and a bzr bug; bzr (imho at least) shouldn't be giving an exception this low in the stack, it should give a sane exception when called with invalid parameters.
<jelmer> peitschie: and of course bzr-svn is at fault for calling it with invalid parameters in the first place.
<peitschie> jelmer: i know! (programming is my day job too... without reproduction steps it's usually a lost cause) problem is I don't know what I'm looking for really.  I can verify which part of the check is failing on the insert, and have dabbled with dropping break-points in various spots to see the stack... but my knowledge of bzr is lacking heavily
<peitschie> jelmer: that would correlate with my impressions too... this is a joint bug of some type.  I can make the exception throw out the chk node it's complaining about... but don't know what to do with it from there.  That is why I was wondering if potentially identifying the file/commit/? that this is related too and comparing this to the svn properties or similar might give some hints?
<peitschie> jelmer: of course... i'm still hopelessly unbazaared so have been lurking here for help
<jelmer> it should be possible to convert the chk node back to the related file id
<jelmer> I need to get some sleep though.. I'm usually around during Australian mornings, or perhaps one of the other bzr devs can help debug.
<spiv> jelmer: g'night!
<peitschie> jelmer: fair enough :).  Thanks for your help!  sleep well
<spiv> Hmm, I suppose my chk-used-by hack could be extended to look at more than just root keys.
<jelmer> spiv: hi and goodnight (-:
<spiv> :)
<peitschie> spiv: would you have some time to give me a hand again?  I've recreated a clean repo from svn trunk, and am trying to branch history across to the new repo... but keep hitting the same chk nodes issue
<spiv> peitschie: hmm, what can I do though?  Extend chk-used-by to look at more than just root nodes?
<peitschie> spiv: thas pretty much all I was hoping for if you could :)
<peitschie> oh... wait... thats a little cool
<peitschie> if i fetch the right revision set, I get "Cannot add revision(s) to repository: missing referenced chk root keys"
<spiv> peitschie: ah!
<spiv> peitschie: that's good :)
<peitschie> spiv: if I branched an svn branch that suffered from bug #522637... would bazaar automatically recover from that bug on the way through the branching? or will I then need to reconcile the repo afterwards...?
<ubot5> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637
<spiv> peitschie: 'bzr branch' won't usually automatically correct that
<spiv> peitschie: but is the source branch an svn branch?
<peitschie> spiv: yes.  The "Central" source control is svn, so that has trunk.  So what I did was branch straight from that trunk again.  I'm wondering though if the revision data bzr is finding in there is incorrect tho... and so I am essentially creating a freshly broken repository
<spiv> peitschie: ok, that's very interesting
<peitschie> spiv: running the chk-used-by i have now gotten 3 revisions in the broken one that use it
<spiv> peitschie: because AFAIK bzr-svn is causing CHK records to be created on the fly (because the underlying SVN repo doesn't use that)
<spiv> peitschie: which version of bzr itself are you using?
<poolie> hi spiv
<peitschie> spiv: we only just upgraded to 2.2.1 in the last few weeks.  We've been running on 2.0 & 2.1 for the last 3ish months.... with around 3000 commits to svn in that time... I think roughly 9000 commits to the bzr repo
<spiv> 2.2.1 is new enough to have the fix to 522637, so it shouldn't be generating non-canonical CHKs that cause the error you just saw.
<peitschie> spiv: that is correct... but I suspect the bug happened prior to 2.2.1 being released.  Looking at this stuff, the bug happened on a commit to svn trunk on sept 1st
<peitschie> spiv: what I mean by that is the missing sha1 is referenced by that commit at the earliest
<peitschie> spiv: which happened to be a commit to svn directly, so the network repo would have gotten second hand info about that commit when it updated from svn.... mayb a non-canonical chk was created and inserted along side that revision?
<spiv> peitschie: hmm
<spiv> I wouldn't have thought that the SVN repo would be storing references to CHKs at all, though
<peitschie> spiv: let me go look :)
<spiv> Because that's an implementation detail of bzr's 2a format
<spiv> And not something that would make sense to store in SVN, because it has its own mechanisms already to store trees of files.
<peitschie> i know bzr-svn stores a bunch of properties along with the checkin
<peitschie> from previous glances it looks like bzr-svn stores enough information to be able to track base revisions and such
<spiv> Right
<spiv> The CHK stuff is basically just a storage optimisation, though
<spiv> It's possible to fully represent the data bzr records without it (just it will tend to be less efficient to do so)
<spiv> FWIW grepping the bzr-svn source I don't see any obvious sign that it would ever store CHK info in a SVN repository.
<peitschie> ahh k
<peitschie> well... the data stored against the rev is things like:
<peitschie> slidetraytemperature-20100901004344-1c1ttvdesj7oryzv-1
<peitschie> 13860@464e02c1-a7d9-0310-851b-f51ca712b586:products%2FBondAdvance%2Ftrunk%2FBond%2FInstrument%2FInstrumentControl%2FController%2FMessageAdaptors%2FHeatersAdaptor.cs
<peitschie> ahh
<peitschie> wait
<peitschie> so it was merged into svn eventually
<peitschie> but the revision was directly committed to bzr first
<peitschie> then svn just had the merge committed
<peitschie> it looks like the referenced chk root key was introduced as part of a merge
<peitschie> that is... the first time this referenced sha appears is when i merged from svntrunk to my feature branch
<spiv> Ok, and the bzr repo you are branching into is the same one that has this other bzr branch that has been merged into svntrunk?
<peitschie> yep
<peitschie> essentially... we have svntrunk, then a network repo that also has a copy of svn trunk + all feature branches
<spiv> And this bzr data pre-dates you upgrading to bzr 2.2.1?
<peitschie> then each dev has a local repo with a bound branch to their feature
<peitschie> yep... this data pre-dates 2.2.1
<spiv> If so, it's fairly likely that following the repair instructions on #522637 will fix it.
<peitschie> I did run the repair tool for that bug tho
<peitschie> so this is the repo after that tool has been run across it
<peitschie> and at this point, if I recreate the local devs repo, they can commit to their feature only until someone checks into svntrunk
<peitschie> at this point, the dev that committed to svntrunk can continue to commit as per normal, but every other dev hits the missiing chk nodes bug
<peitschie> (to recreate teh local dev repo, I simply branch the NETWORK bazaar version of svntrunk into a new repository, so the dev gets all the bzr history with their repo)
<spiv> Did the
<spiv> repair tool log any lines like "Non-canonical CHK map for ..." in your ~/.bzr.log?
<spiv> Also, could you elaborate on "at this point" a bit more?
<spiv> Each dev has their own bzr repo, I assume?
<peitschie> (i didn't connect that was ur tool btw.  i do appreciate all your work here... i'm in awe of the tool you guys have built here)
<spiv> But as soon as they pull/merge a revision from svntrunk that was committed by another dev using bzr-svn they encounter this bug?
<peitschie> so.. the setup is as you said
<spiv> And precisely on which operation do they get an error?
<peitschie> each dev has their own repo, but the feature branchs are actually bound branches that point to the network one (so we keep things backed up in case an individual pc dies)
<spiv> (ugh, my grammar is terrible!)
<peitschie> *usually* the dev will hit this bug when they attempt to merge & commit changes from svn trunk into their feature branch
<peitschie> e.g., bzr merge ..\svntrunk && bzr commit -m "Merging trunk"
<peitschie> it will then blow up with bug #522637 at this point, and refuse to commit
<ubot5> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637
<spiv> So the merge succeeds, but the commit fails?
<peitschie> yep
<spiv> That's extra bizarre :)
<peitschie> they can then simply throw away the commit, and keep working as normal and committing... but can never get changes in from svn trunk
<spiv> And they are definitely using 2.2.1?
<peitschie> i never realised how close bizarre and bazaar sounds until ppl say that all the time in real life lol
<peitschie> they are now... and the same issue still occurs
<spiv> Hmm.
<spiv> What if they run the repair tool (on their local repo *and* the bound repo) between the merge and the commit?
<spiv> (And does the repair tool log anything about non-canonical chk maps in ~/.bzr.log?)
<peitschie> due to how long the repair tool takes I haven't tried that
<peitschie> i checked my logs and the first run of the tool has been lost unfortunately
<spiv> Yeah, I understand :(
<peitschie> i was hoping that once the network repo was fixed, each dev then only needs ~30mins to get their working sets back up again
<peitschie> hmm
<peitschie> so it appears that either way, teh reconcile has still left this revision hanging in the network repo that causes the missing chk root keys
<spiv> This is sounding very much like 522637, though, or something closely related.
<spiv> When you say "network repo", you mean the repo that devs have their branches bound to?  Or the SVN repo?
<peitschie> the one their branches are bound to
<peitschie> oh wait... i meant to say way prior... the merge works, but the commit actually blows up with bug #485601... not the one i had there
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<peitschie> *but* if I attempt to branch the networked version of svntrunk (this is all bzr only... not svn interaction), I get bug #522637
<ubot5> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637
<spiv> Hmm.
<peitschie> if it'd help i can draw up a pretty diagram and instructions lol... it is a slightly convoluted workflow to explain :)
<spiv> Hmm.  The distinction between those two errors might not be very important: one is that the root node of a CHK map is missing, the other is that a non-root node is missing.
<spiv> It's otherwise a sanity check at the same point in the code.
<peitschie> thats what i started suspecting.  dont know if that helps anything much tho
<spiv> Either way, it suggests that at some point CHK maps are either not being generated correctly (i.e. the wrong nodes), or generated incompletely, or that we are losing nodes during a fetch.
<spiv> All 3 options should be equally impossible :)
<spiv> The slightly different errors are certainly interesting, and I think a useful hint.
<spiv> But I'm pretty sure they are a manifestation of the same root cause.
<spiv> What's weird is that these checks are run on every write to the repository.
<peitschie> i'm looking at the earliest rev to reference these and seeing where it came from
<spiv> So if the merge works, and it does, then the data being pulled across by merge is apparently complete.
<peitschie> mm... it's not a big merge either
<spiv> (Not necessarily *correct*, bug 522637 can create data that passes this check but causes trouble for new data generated against the bad data)
<ubot5> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637
<peitschie> has 2 revs... 1 rev is a single binary file, second rev is a few sources + a bunch of binary files
<spiv> Only file modifications
<spiv> ?
<peitschie> 1st is a file modification, 2nd are all new files
<spiv> Hmm.
<spiv> Ok, at this point I'd really like to know that it's not another case of 522637.
<spiv> I can't see how, but obviously some assumptions need questioning at this point :)
<spiv> https://code.edge.launchpad.net/~jameinel/+junk/bzr-check-chk is a plugin that will be useful
<peitschie> getting it now...
<spiv> You can give it a range of revisions, and it can tell you if they are broken in a way that reconcile --canonicalize-chks will repair
<peitschie> range... it works by branch or repo?
<spiv> Branch
<spiv> So you can use it to relatively cheaply check if e.g. 'bzr merge' from svntrunk has this corruption.
<peitschie> i'm running it over the networked repo's trunk at the moment
<peitschie> then i'll do it in the branch it first appeared in
<spiv> In fact, it seems to me that if 'bzr merge ..\svntrunk && bzr commit' fails on commit but not merge that it's likely that either the new revisions fetched by 'merge' are broken, or the most recent parents of those are, or one of the recent parents of the current tip you are trying to commit on are.
<peitschie> that would reflect how it appears to behave
<spiv> Note that tool is actually slower than 'bzr reconcile --canonicalize-chks' per revision, so it'll only be faster to use it if you give a range of revisions rather than letting it check the whole repo.
<peitschie> if i then delete the individual dev's repo, and create a brand new clone from the network repo again, the problem goes away... until the next bzr checkin lands in svn that both the dev and the remote repo retrieve
<peitschie> ok... check-chk on trunk hasn't turned up anything for the revision range where the affected root key was merged in
<peitschie> i've widened the range to work earlier slightly and am running again
<spiv> Basically at this point I'd really like narrow down where the corruption is being introduced.
<spiv> Because so far in isolation all the individual pieces sound fine.
<peitschie> ahh the fun of complex interactions :)
<spiv> And e.g. glancing at the bzr-svn source it seems to be fetching revisions from SVN to bzr in a totally reasonable way, so I wouldn't tend to suspect it.
<spiv> Except that the only people reporting this bug are using bzr-svn...
<peitschie> i wonder if it is something related to two different repos with slightly different history available coming up with a slightly different revision somehow
<peitschie> svn would b the key then, because of it's effect on ghosting various parts of teh revision
<peitschie> under normal bzr operation, the situation doesn't seem quite as common as for bzr-svn
<peitschie> (the ghosting situation that is :))
<spiv> Possibly, yes.  I mean, in principle that should be fine!  But obviously *something* isn't fine.
<peitschie> on a side note, are you aware of any tools for generating a bunch of changes for a branch?  I've been considering throwing together a fuzzer of sorts so that I can set up a repository and essentially simulate a whole bunch of changes being made... working on the theory that i will eventually hit this again
<spiv> No, not really.
<spiv> I mean, we have a perfectly decent API ;)
<peitschie> oh... that check-chks doesn't work with a branch that has ghosts by the way
<peitschie> i didn't want to go through the api for fear that it was bzr-svn's use of said api that was doing something "unusual"
<spiv> Oh, interesting.  I guess I can see that.
<lifeless> well bzr-svn is an implementation of the api
<lifeless> so its a bit special in that regard
<peitschie>  i can't run check-chk on the clean checkout of svntrunk due to the ghost thing... is there any easy way we can fix that?
<spiv> peitschie: specify revisions one by one?
<peitschie> lifeless: thats wat was one of the questions... one of teh bugs is only affecting bzr-svn users, which suggests bzr-svn's usage is a little different from standard bzr somehow... likely in some very subtle way... hence why i'm thinking of fuzzing via the file system directly rather than the bzr api
<lifeless> peitschie: I think you misunderstand me.
<lifeless> peitschie: bzr-svn is an *implementation* of the API
<lifeless> peitschie: its not a consumer of it in the usual sense, at all.
<lifeless> peitschie: this is what makes bzr-svn glue in so nicely to the core
<peitschie> lifeless: ahh.  sorry :S.  gotchya
<peitschie> spiv: so far it hasn't reported any issues with either the new or old repo
<spiv> Hmm, I wonder if bzr-svn isn't roundtripping inventories perfectly.
<peitschie> is there any way to verify that you can think of?
 * spiv adds a note to the bug while he's thinking of it, so jelmer will see it
<spiv> Basically, compare the CHK root keys before and after roundtripping.
<peitschie> hmm
<peitschie> i can probably try and branch the revisions just prior to this issue from the broken dir
<spiv> i.e. make a revision in bzr repo A, commit/push it to the SVN repo, and fetch it into bzr repo B.  I suppose if you're seeing this bug, and this theory is right, you already have examples of this.
<spiv> Then use the bzr APIs to tell you what the CHK root keys for that revision's inventory are in A vs. B.  They are supposed to be the same.
<peitschie> the challenge is finding the exact combination that causes it to break :).  things work the large majority of the time... so it is a specific sequence of somethings that does it
<spiv> You can probably see how to adapt bzr-check-chk or similar to just print the key for a given revision.
<peitschie> yep
<spiv> (If this theory is right, then it will pass the 'canonical-form' check, because the bug isn't the layout of the CHK, it's that actual inventory contents for a given revision ID are not the same in the two repos.)
<peitschie> (all check-chks came back without any issues btw)
<spiv> Ok, that's good to know.  Thanks for that.
 * spiv -> lunch
<peitschie> spiv: let me know wen ur back... i could use a few more pointers :)
<peitschie> spiv: i found the dodgey rev... now i need to get the details out of it somehow
<spiv> peitschie: back
<peitschie> spiv: wb :)
<spiv> peitschie: oh nice
<spiv> Tell me more about this dodgy rev!
<peitschie> spiv: it's rather ... unexpected.  the key revision is a pure bzr rev that has stacked on an svn rev
<peitschie> i don't know how to get other debug info out of it yet... i'm quickly testing checking out these revs against trunk
<peitschie> once this single bzr rev gets into a branch, every branch from that point onwards shows the missing chk node entry bug
<spiv> A pure bzr rev in the same repo it was created it?  Or a pure bzr rev that has travelled via the svn repo?
<peitschie> (when i try and branch it into my clean repo)
<peitschie> pure bzr
<peitschie> so the dev branched off svn trunk (a rev the repo already had), then performed a checkin to their feature branch (pure bzr)
<peitschie> i can pull the svn rev into the clean repo
<peitschie> i cant pull the dev checkin to the repo
<spiv> "pull the svn rev into the clean repo" -- pull from svn -> bzr, or from the first bzr repo?
<peitschie> first bzr => second (new clean from svntrunk) bzr repo
<spiv> Ok.  I'd definitely like to know if the chk root keys for that rev in both repos match.
<spiv> And I assume both the bzr rev and the rev from svn trunk both pass check-chk?
<peitschie> checking now
<peitschie> these revs were way outside the range i was checking before
<peitschie> back in early june sometime
<spiv> What do the two revs look like in terms of changes?  Modifies, adds, deletes?
<peitschie> the svn rev just prior is adding 2 files
<peitschie> the first bzr checkin after is deletes & modifications
<peitschie> check-chks says nothing special for those two
<peitschie> im currently branching at various trunk revs to see what happens once that revision lands back into trunk
<peitschie> ag... duh.. thats not gonna help because the new repo has all trunk revs >.<
<peitschie> ok... whats the best way to get all the info we can about these two revisions that cause the problem?
<spiv> Modify bzr-check-chk to print the root keys
<spiv> (even if they pass the check)
<peitschie> they pass the check without any issues
<spiv> and then use that to make sure the root keys for those revs are the same in both repos
<peitschie> ahh... thats gonna b fun
<peitschie> the second commit is only present in one repo... i can't get it in the other
<spiv> Hmm, yeah.  Well, just check that one.
<spiv> I think it will match, but I'd like to check my assumptions :)
<peitschie> sorry it's taking so long
<peitschie> i've dropped pdb into ther and am trying to find what i want on the inventory :)
<spiv> inv.id_to_entry.key() and inv.parent_id_basename_to_file_id.key()
<peitschie> thnx!
<spiv> I don't suppose you're able to send me a copy of the repo that exhibits the problem?
<peitschie> its 1.2Gb... so it's a little difficult
<peitschie> oh... thats not so good i suspect
<peitschie> shas for the svn checkin in question are different
<echo-area> Hi
<echo-area> I'm getting trouble similar to https://bugs.launchpad.net/bzr/+bug/377261
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 5, heat: 21)" [High,Confirmed]
<echo-area> The difference is that I got different stack backtrace than that bug
<echo-area> Should I file another bug?
<peitschie> echo-area: probably a good idea.  It is easier to mark a bug as a duplicate than split a bug out :).  Make sure you mention the other bug in it as well to make it easier for whoever is checking to see
<echo-area> peitschie: Okay, I'll do that.  Thanks
<spiv> peitschie: ah, so we are getting close after all!
<peitschie> spiv: it is starting to look that way a bit.  wat next?
<spiv> peitschie: that probably does explain why the next revision that depends on it can't be fetched
<spiv> peitschie: if you don't mind sharing some of your data,
<spiv> peitschie: send me the output of print inv.id_to_entry._dump_tree(True) and inv.parent_id_basename_to_file_id._dump_tree(True) for both
<peitschie> spiv: i can probably talk to people.. I work at a commercial company so things will need to be a little careful.  Whats the easiest way for you to get 1.2Gb...?
<peitschie> spiv: even better :)
<peitschie> spiv: so you want that of the rev in question correct?
<spiv> Yes, and from both repos
<spiv> The output will, I hope, be different :)
<spiv> And actually, it'd be great if you can send me the output for the parent revision (or revisions?) of that rev-from-svn too.
<peitschie> yep... so you want the rev that breaks things, and it's parent rev in both sides?
<peitschie> is 7zip ok for the file?  It's way smaller than zip...
<spiv> I *think* so.  bzip2 is also good.
<poolie> spiv, there is a 7z in ubuntu
<peitschie> spiv: I'm attempting to send it now... i'm behind a proxy tho, so if this fails i can email it
<spiv> email is fine, andrew.bennetts at canonical.com
<spiv> My IRC client says 'DCC unknown ctcp XXXX from peitschie ...'
<spiv> So I guess that's not going to work :)
<peitschie> yups :)... emailing now
<peitschie> it's sent
<spiv> Thanks!
<peitschie> now heres to hoping it's useful in some way...
<spiv> Received ok, I think this is going to be helpful
<spiv> What is r4686 is the rev from svn?
<peitschie> thats the one that magically starts breaking things
<peitschie> so i have a checkin on a branch just past that point, which i cannot branch into my "clean" bzr repo
<peitschie> that reminds me, do you want the info from the checkin just past 4686 as well?
<spiv> So interestingly 4685 differs in both revs too
<peitschie> i've been chasing those back...
<spiv> er, in both *repos*
<peitschie> they were differening back to the first bzr checkin made
<peitschie> so up until the first checkin, it's all identical.  once the first checkin was made, the files immediately start differing
<spiv> The inventories have the same files and directories, with the same IDs, with the same contents and the same lengths and the same executable bits...
<spiv> *but* some of those files and directories have different revision IDs
<peitschie> i thought so
<spiv> Which is the inconsistency that is causing all your trouble.s
<spiv> So, how precisely were these two repositories created?
<peitschie> so... repo 1 (broken) was created with a check out of the entire svntrunk
<peitschie> that then served as our network repo since then (early june)
<peitschie> repo 2 was created by rechecking svntrunk out a few days ago... that has had no other use at this point
<peitschie> as soon as the first bzr checkin is made to the repo, the bzr info that i'm dumping changes
<spiv> peitschie: hmm!
<spiv> So adding a new bzr revision to the SVN repo is causing future bzr checkouts from that repo to get different results for old revisions?
<peitschie> it is looking like it!
<peitschie> i am wondering... we got bitten by https://bugs.launchpad.net/bzr-svn/+bug/587819 ages ago
<ubot5> Launchpad bug 587819 in Bazaar Subversion Plugin "race condition when doing a bzr commit to an svn repo (dup-of: 515850)" [Undecided,New]
<ubot5> Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored (affected: 4, heat: 23)" [High,Triaged]
<peitschie> i had to manually delete all bzr revision properties from the svn history
<peitschie> i wonder if someone forgot to delete their svn cache prior to a checkin...
<peitschie> and if that might have poisoned the stack
<spiv> peitschie: ooh, sounds messy!
<spiv> peitschie: that sounds plausible
<spiv> peitschie: I'm out of my depth on that degree of SVN-fu, though.
<spiv> peitschie: I think at this point we need jelmer for further diagnosis
<peitschie> spiv: i suspected we were hitting that point as well :)
<spiv> I've added some more comments to the bug.  We're definitely much much closer now, thank you very much for your persistence.
<spiv> And patience :)
<peitschie> it's a pleasure :).. i like working with you guys
<peitschie> with those dumps that I sent... I dont mind if you pass them out to a dev or too.. just make sure they don't get too far out of ur sight please :)
<spiv> Ok, I'll pass them onto jelmer as well
<spiv> You should probably add a bug comment with the suspicions about svn caches and deleting old bzr rev props
<peitschie> yep... will do
<peitschie> if it is related to that... that took a scarily long time to bite :S
<peitschie> spiv: wb :)... another quick query... is it worth me doing a check-out of svn using an older version of bzr (2.0 or 2.1) to see if that is different too?
<spiv> Hmm, I don't think so.  But then I still don't quite know what's going wrong, so what would I know? :)
<peitschie> hehe... i know that feeling :S
<peitschie> i'll hold off then and see how far jelmer can get on wat we've given him
<peitschie> thanks again for all your help digging that out... It would have taken me all week to do that without your guidance!
<spiv> If my own experience with these bugs is any guide, longer probably ;)
<peitschie> aint that the truth... it scares my poor little mind thinking about it :S
<mgz> lifeless: I'm around now if you're still after me.
<lifeless> mgz: yeah, you fixed timing data from parallel stuff
<lifeless> I was wondering if any of that was still in bzrlib, or if its all in testtools nows
<mgz> it's moved to testtools basically.
<mgz> https://code.launchpad.net/~gz/bzr/use_testtools_timings_625594/+merge/36784
<mgz> that's the bzr mp that does it.
<lifeless> thanks
<vila> hi all !
<vila> poolie: did you get an email for the shortcuts failures ? Can I have a copy ?
<mgz> vila: yes, lp:~gz/bzr/escape_selftest_console_output_633216 depends on a non-broken-with-unicode testtools version
<vila> poolie: regarding the http tests, the code is not called because the http client coalesce the offsets. The tests need to be tweaked to avoid that, but doing so led to a hang when I briefly tried yesterday. Why it hasn't been noticed before is... unfortunate :-/
<mgz> and I'd like to see the failure spiv got with it as well.
<vila> mgz: yup, hence my ping in the review comments
<vila> spiv: ^
<vila> poolie: and to avoid problems, please send this mail to my canonical address
<vila> poolie: I reported the problem to my ISP but I'm not holding my breath, *one* postmaster for millions of users to handle false positive spams... hmmm, does it blend^W scale ?
<mgz> should make pqm post a summary to the mp
<poolie> hi vila, i did get a failure mail
<poolie> vila: sent
<poolie> mgz we should use tarmac
<mgz> or that.
<poolie> vila, i'm also reviewing your config mp
<poolie> or, at least, work out why not to use it
<poolie> vila, well, it's nice we noticed now
<vila> poolie: noticed what ?
<poolie> noticed the http test wasn't reached
<vila> ha, yes, we may just get rid of the tests, they try to ensure a pretty unlikely regression and the hang may be a real bug in the test server
<vila> poolie: if you can't "work out why not to use it" I'd be happy to land it and work on the *next* steps ;)
<vila> poolie: ok, got the PQM failures mail. That's insane, what the hell is different on the pqm instance...
<poolie> vila, i meant either use Tarmac or get a good idea why not
<poolie> but maybe not today
<vila> poolie: did Tarmac allows running the test suite before landing ?
<poolie> it should
<poolie> i haven't tried this week
<vila> ok
<poolie> i mean i haven't tried yet; i hope to try this week or next week before UDS
<poolie> have you touched fastimport at all?
<vila> never
<vila> hmm, at least nothing I can recall, I may have fixed some test failures though ;)
<lifeless> PQM has code to comment on the MP
<lifeless> and rockstar has overhauled the API - a small tweak to use the new API next week, and it should be usable.
<lifeless> using tarmac would be good too
<lifeless> poolie: I've merged your testscenarios patch; it needed a little tlc to be up to your normal standards, so I did that as I merged.
<poolie> thanks, i saw
<poolie> vila, are there any unit tests for urllib2_wrappers?
<poolie> nm, i can grep
<GaryvdM> Morning all.
<lifeless> poolie: if you want to depend on testscenarios, I'd be delighted to do a release of it for you
<vila> poolie: I don't think so. For historical reasons, I always wrote tests against both _pycurl.py and _urllib.py
<vila> poolie: thanks for the review !
<vila> poolie: note that s/from fnmatch import fnmatch/import fnmatch/ is actually a genuine case where it's *required* I need to access *another* symbol in the module !
<poolie> lifeless: i wouldn't mind
<poolie> it's not very compelling at the end because we have the equivalent in hose
<poolie> *house
<poolie> the main thing i would like to do would be to clean up ad-hoc parameterization by subclassing
<poolie> unfortunately it's a bit hard to grep for
<lifeless> poolie: grep -i 'base|mixin' tests ?
<poolie> that'll be close, also for xxx comments
<poolie> if they can all be cleaned up in a good way that'd be quite a positive step
<poolie> probably no reason why they can't be
<poolie> well, positive for the code and good validation of scenarios
<lifeless> yes, OTOH you could in principle delete the in-tree copy eventually :)
<lifeless> I'll see about a release this weekend or so
<poolie> i'd kinda like to delete the in-tree copy
<poolie> i wonder, empirically, how much pain do dependencies cause for packagers?
<poolie> vila, i pushed my branch, i'm curious what you think of the tests
<vila> poolie: tests are nice
<vila> poolie: as for the fix... I don't understand why 'port' is not set in auth... istm it should in which case your fix is not in the right place, but ibmw
<vila> poolie: it's especially weird that you create the auth *section* with port, but still get no port in the auth entry
<vila> poolie: may be I just don't remember the code path well enough anymore :-/
<vila> poolie: ha, right, you explained that clearly in the cover letter, sorry, went straight for the diff
<vila> poolie: I replied to your config review and need additional answers to progress :)
<poolie> thanks for that
<vila> poolie: I've approved you mp for the auth password (port really) and I'm now changing my hat to RM and will announce 2.3b2
<vila> poolie: we have installers for OSX and windows ready and maxb is working on the beta ppa (activating the test suite run AIUI) so it should be ready soon too
<vila> maxb: Did I get this right ? Do you need help there ?
<poolie> thanks vila
<maxb> vila: Aaaaaaaaaaaaaaaaaaaagh. Why? WHY!? WHY is bzr packaged using cdbs!??!
<poolie> night all
<maxb> (I just looked at the debian/rules and cried)
<vila> maxb: excuse my Klatchian, but what is cdbs ?
<maxb> on the plus side, it appears there is a test invocation already in there, but disabled
<maxb> cdbs is an evil monstrosity that results when someone thinks it's a good idea to build an extensible class library of Makefile fragments
<maxb> for debian package building
<maxb> Well I'm just going to ignore that and pray just toggling the conditional works :-)
<vila> hehe, sounds like a plan ;)
<aboeing> hi. does anyone know how to insert a revision string into source code from bzr?
<aboeing> for example, after a commit, set a variable REVISION_STRING = 1234
<lifeless> the feature used to do that is 'filters'
<aboeing> lifeless: thanks, would you have an example of this?
<lifeless> have a look on the plugins page
<lifeless> there's at least one filter there - the end of line one, for windows users.
<aboeing> Thanks, found this which looks like what I need: https://launchpad.net/bzr-keywords
<inge> Dear Members of bzr channel, we have a problem with bzr and file system access I wonder if anybody can help.
<inge> The repositories are located at a server which is mounted to a directory any user can internally access, this is /home/bzr.
<maxb> It's always best to actually ask a technical question rather than asking to ask. it lets people gauge whether they have relevant experise.
<maxb> * expertise
<inge> Anytime I do a bzr co --lightweight /home/bzr/REPOSITORY the bzr command will not return. I can only kill the shell but the bzr process still exists as a zombie and locks a file in the repository "dirstate"
<inge> Our assumption is that it could have something to do with NFS4 we migrated to lately, does anybody know something about it?
<mgz> if you ctrl+\ where is the process stuck at?
<mgz> blaming nfs is probably right.
<inge> ctrl+\ does not do anything
<Kamping_Kaiser> inge: what were you usinb before you put in nfs?
<inge> we where using nfs3, no problems then
<inge> I was trying to attach to the bzr process with gdb but that doesn't work.
<inge> Am I the only one with this problem?
<mgz> feel free to poke around on the bug tracker, nothing springs to mind though]
<mgz> you might find it useful to add a break point earlier in the process then step through to work out where the hard hang is happening
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it  ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> inge: yes, there are known issues with nfs4
<vila> inge: well, known may be a bit optimistic, the problem AIUI is that we don't understand what is happening, but the suspicion is against nfs
<vila> inge: but the 'dirstate' file is part of the working tree, it shouldn't be in the repo
<vila> inge: may we don't assign the same meaning to repo here...
<vila> inge: thinking more about it, the problem I'm aware of related to nfs4 is about OS locks, which are only used for the dirstate files, so if your working trees are *not* accessed via nfs, i.e. only the branches and their repos, then you should be fine
<vila> inge: I'm about to leave for a lunch break, but I'll read and answer your questions if needed when I'll be back
<inge> vila: I meant the dirstate file in the branch, e.g.: REPOSITORYNAME/.bzr/checkout/dirstate, this is I think part of the branch. The working  trees are not affected by this problem, nor are the update or commit commands.
<vila> inge: checkout/ is what defines a working tree, do you *need* a working tree there ?
<inge> I think your suspicion with OS locks could be true, checking out first runs normally, only at the end, maybe some finishing operation, it hangs.
<inge> vila: I am a bit confused about the checkout/working tree stuff. Just to explain our setup: We have a central branch/repository on a server A, there only the .bzr directories exist. From the other computer e.g. mine I do e.g. a checkout --lightweight to get a cvs like copy of the current files. So no working tree on the server, only at my personal computer.
<vila> inge: right, so: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<vila> inge: from what you're describing, REPOSITORYNAME/.bzr/checkout/dirstate shouldn't *exist* so we need to find why it's there and get rid of it
<vila> inge: can we do that in1/2 hour ? (I didn't get really get this lunch break ;-)
<inge> Yes of course, I will wait.
<vila> cool, read this url above, I find it quite good at helping us talk about the same things with the same words
<inge> I am already reading
<fullermd> Oh look, bzr ls doesn't take multiple args.
<vila> fullermd: what a shame, file a bug ;)
<vila> inge: I'm back
<inge> me too, had to reboot, to many zombies
<vila> err, which one of you is really you ? ;)
<vila> ha ok
<inge> sorry, double entry on notebook
<vila> so, basically in the end, you need to: 'bzr reconfigure --no-tree' while logged on the server, but I'd like to understand how you end up there
<vila> err, --with-no-trees
<inge> I don't know if that really is the problem, but I think I have repository and branch in the same location
<vila> inge: it's ok, it's what we call standalone branches as opposed to branches using a shared repository
<vila> inge: if you have several branches related to the same project, it's generally best to use a shared repo
<inge> I migrated the repositories from cvs using tailor, then multiple branches where generated and cross merging, maybe something went wrong then.
<vila> my guess would be that someone has been working on the server and used working trees there
<inge> Yes that's what we are in general doing.
<inge> Your guess could be true. From time to time I find some files next to the .bzr directory on the server. The guy the files beling to  says he is only working in his working tree, not on the server.
<inge> Any idea about that?
<vila> it's a bit unclear but I suspect some operation on the lightweight checkout *also* update the remote working tree
<inge> bzr: ERROR: Requested reconfiguration of '/home/bzr/trunk/MIP/' is not supported.
<vila> on the server ?
<vila> ha, right, sorry, that should be 'bzr reconfigure --branch'
<inge> yes, I am on the server with ssh
<vila> that will remove the working tree too
<vila> hmm, check for uncommitted changes first maybe :-}
<vila> but the command should do that hopefully
<inge> okbzr: ERROR: Working tree "/home/bzr/trunk/MIP/" has uncommitted changes (See bzr status).
<vila> :)
<vila> pfew
<inge> yes uncommitted chages, status shows 100 conflicts with files that are not there, I will need a moment to figure that out
<vila> hmm, most probably accumulated cruft
<vila> if you can confirm that, 'bzr revert --no-backup' will restore a pristine working tree
<vila> but don't use --no-backup if you're unsure
<inge> what about the subdirectories in .bzr, checkout and branch, can I delete them?
<vila> no
<inge> I am unsure about the --no-backup, I don't want a working tree there but a clean repository with no branch and no working tree
<vila> never touch anything under .bzr/ unless told otherwise :) The only exception being .bzr/branch/branch.conf but even for that we're working on providing a command to edit it
<vila> inge: the --no-backup is to restore a clean working tree so you can do 'bzr reconfigure --branch' which will delete .bzr/checkout
<vila> err, and you want a lean *branch* with its own private repository
<vila> *clean
<vila> unless you also want to use a shared repository for multiple branches but we can look into this later
<vila> or unless you are already using a shared repository and suddenly get a branch and a working tree there in which case I misunderstood
<inge> Yes I want a shared Repository, and I got this branch and working tree in there. Think it was not created correctly by tailor, or we messed it up during merges
<inge> vila: ok I went to all repositories and did bzr reconfigure --branch --force and now the checkouts etc. work, no hangs anymore so far
<inge> vila: thank you very much for your help.
<vila> inge: great !
<vila> inge: if you encounter again some weird combination that ends with a remote working tree, please file a bug with a reproducing recipe !
<inge> Ok I will, but this time I really don't know how to reproduce that
<vila> sure, no problem
<poolie> GaryvdM, hi?
<jam> morning vila, hey poolie
<poolie> hi there jam
<poolie> that's a bad sign :)
<vila> hey jam
<vila> poolie: :)
<jam> poolie: I was thinking the same thing
<jam> I shouldn't see vila wake up, and you shouldn't see me come online
<jam> though you were saying you wanted to see me around more :)
<poolie> good night vila, jam
<GaryvdM> Hi jam
<vila> poolie: good night ;)
<jam> sleep well poolie
<jam> hey GaryvdM
<cbz> trying to use bzr on windows can't find a set of options that will print out the full content of the file with changes
<cbz> Tried bzr --diff --using=/path/to/gnu/diff --diff-options="-iwb -U 100000" - but it only shows the limited section around the changes
<cbz> any  ideas?
<GaryvdM> cbz: I think you are probably looking command line solution. For that I have no idea, but if you open qdiff, and select Unidiff, and Complete, it will give you that.
<trashbird1240> I'm trying to migrate a repository from hg to bzr
<trashbird1240> I've used fastimport and everything appears to have worked, but how do I update my working tree or create a branch?
<trashbird1240> I've followed http://wiki.bazaar.canonical.com/BzrMigration#Mercurial%20%28hg%29
<sender> jelmer: you there? any news on the bzr-svn bug that we spoke about last week? :)
<jelmer> sender, hi
<jelmer> sender, I remember talking with you about it but I don't remember which bug that was. Do you have the bug #?
<jelmer> sender, I should be able to have a look at it after I finish my work day.
<vila> jelmer: it seems that  bzr-svn and bzr-rewrite needs an API bump to be used with 2,3b2 anf trunk
<vila> abentley: bzr-pipeline and probably bzrtools as well
<jelmer> vila: that's already happened
<jelmer> vila: are you sure you're using the respective trunks?
<vila> jelmer: not me someone on the ML
<vila> I thought he said he get latest versions, may be it's not running from source...
<jam> vila, jelmer: I think he's using a ppa, and got the latest bzr but not updated plugins
<GaryvdM> vila: the only plugin that is in the windows installer that has not been bumped in it's trunk is pipeline.
<vila> jam: meh, which ppa then ? The beta one still propose 2.3b1
<jam> then again, he says "I'm trying this new release" so he certainly could be running bzr 2.3b2 from source but all plugins from the system
<jam> /usr/local/lib/... makes it sound like he ran "setup.py install" at least
<GaryvdM> Maybe a debian user?
<maxb> Language in that email makes me think he is running setup.py install from *source tarballs*
<maxb> Can anyone think of an easy way to figure out if bzr selftest is loading compiled extensions or not?
<roryy> i get a warning if i don't have compiled extensions, fwiw
<maxb> Normally yes. But I think bzr selftest might be different
<jam> maxb: you can check the features themselves, and the end of the selftest tells you "X tests not running because of features ..."
<jam> GaryvdM: he was also clear that he was running Ubuntu
<GaryvdM> oh - I missed that...
<vila> maxb: selftest is no different, I see a warning everytime I run without extensions
<maxb> hmm. Then, either I'm lucky and magically the right thing is happening, or ./bzr is picking up the compiled extensions from my system bzrlin
<maxb> *bzrlib
<vila> maxb: I dunno what you are trying to do, but I have a bzr installed and running './bzr' warns
<maxb> I was briefly testing how to run the selftest inside the debian package build
<vila> maxb: 'make check' ?
<maxb> There was existing code in the debian/rules to do ./bzr selftest --no-plugins,
<vila> maxb: or 'make check-nodocs'
<vila> ha
<vila> may be it's triggered after the extensions are built ?
<vila> that would makes sense
<maxb> it was triggered before they were built. It still didn't warn in my local test
<vila> make clean should get rid of the existing ones
<maxb> Anyway, I decided that I need to leave shortly so I threw a best-guess into the bzr-beta-ppa for the builders to chew on
<mtaylor> w00t! new bzr error I've never seen!
<mtaylor> oh - nevermind
<vila> mtaylor: go ahead, we love enthusiastic bug reports ! ;)
<mtaylor> vila: $ bzr branch lp:drizzle/elliot
<mtaylor> bzr: ERROR: Permission denied: "Cannot create 'elliot'. Only Bazaar branches are allowed."
<maxb> heh, that's changed from earlier today
<mtaylor> well - in _this_ case, lp:drizzle/elliot isn't valid - it should have been lp:drizzle/elliott
<vila> mtaylor: oh yeah, it's a lp one, never made sense to me either
<mtaylor> the error message should be "you're an idiot - learn to spell!"
<vila> maxb: grrrrrr no module named testtools...
<maxb> oh. duh. obviously
<vila> maxb: you need it to run the tests, I should have thought about it and warned you
<maxb> If I'd actually thought about it, or tested in a chroot, I would have realized
<jelmer> sender, still there?
<rubbs> is there a reference to all the branch aliases? I created a branch and pushed it to our central server, now I want to bind the one I pushed from to the one I pushed too. What's the easiest way to do that?
<jam> rubbs: bzr bind :push ?
<jam> bzr help location-alias
<rubbs> jam: that did it thanks.
<rubbs> ah, awesome that's exactly the help entry i was looking for
<slangasek> if a remote branch is stacked on a branch which has been moved, how can I make bzr look at the new location instead?
<slangasek> (case in point: lp:~chessy/live-build/live-helper.chessy, and lp:~vcs-imports/live-helper/trunk/ vs. lp:~vcs-imports/live-build/trunk/)
<jelmer> slangasek: Hi
 * slangasek waves :)
<jam> slangasek: edit .bzr/branch/branch.conf to reference the new location?
<jelmer> slangasek: I think "bzr reconfigure --stacked-on=<new-url>" <branch-url> should do that
<mwhudson> slangasek: use lftp to edit .bzr/branch/branch.conf
<slangasek> ah, but I don't have commit access to the remote branch :)
<mwhudson> find someone who does :/
<jam> hey mwhudson, just checking what the next step for the forker service is. you mentioned pqm being frozen, and I don't really know when to remind you to try and land it again.
<slangasek> lool: ping ;)
<mwhudson> jam: i'll try to remember when pqm reopens i guess
<slangasek> jam, jelmer, mwhudson: thanks, will take it up with the branch owners
<jam> mwhudson: do you have a date so I could help you remember? (this week, next, etc?)
<mwhudson> slangasek: also an admin or a bazaar-expert (eg thumper) can do this for you
<mwhudson> jam: if i haven't merged it by next monday, certainly give me a prod
<jam> mwhudson: k, thanks
<slangasek> mwhudson: mattman should be around, let's make him do it :)
<jam> slangasek: though he isn't in #bzr
<slangasek> 5~
<slangasek> jam: nevertheless, he's where I can get at him :)
<thumper> jam: hi
<jam> hey thumper
<thumper> jam: do you have 15 minutes for a chat?
<jam> I probably have 15, though I'm supposed to chat with poolie today (he probably is sleeping in, since I saw him < 8 hrs ago)
<thumper> ok
<thumper> jam: skype?
<jam> works for me
<peitschie> mornin everyone
#bzr 2010-10-13
<poolie> hi jam
<jam> hi poolie, I tried calling earlier
<poolie> hi there
<poolie> want to talk now?
<jam> sure
<jam> espec if we can make it quick
<poolie> give me a call?
 * maxb uploads the fourth try at 2.3b2 to beta ppa :-)
<lifeless> 2.3b2.4?
<lifeless> could be a confusing version number
<lool> slangasek: pong
<slangasek> lool: hi - sorted now, no worries :)
<lool> slangasek: Ok; sftp to what branch?
<lool> slangasek: Ok  :)
<maxb> ugh, failed test again
<maxb> Here goes 2.3.0~beta2-1~bazaar1~maverick5, may it have better luck than the last 4
<poolie> hi spiv?
<spiv> poolie: hi poolie
<spiv> I'm nearly done with split-NEWS
<poolie> cool
<spiv> Just writing up docs on how to start a new release with it, which of course reveals improvements I should make to that process :)
<spiv> Or rather, how to start a new series.
<maxb> yay successful build
 * spiv -> lunch
<maxb> So, fixes to make the testsuite work on the buildds.... should I target those at 2.2? 2.1?
<poolie> i'd say 2.2, or maybe even only trunk
<poolie> how likely is it to have adverse consequences?
<maxb> Very little, given I only touch setup.py and test code
<maxb> And actually, having touched the test code, I don't technically need to touch setup.py
<poolie> 2.2 sounds good then
<poolie> could you nag or whatever the sru team?
<maxb> Do we actually have test results in the bug yet?
<maxb> Also, perhaps I should target my test fixing into 2.1, in case we want to SRU lucid again
<peitschie> spiv: are you around?
<spiv> peitschie: I am, yes
<peitschie> spiv: was just wanting to quickly check if you'd heard anything regarding the data we were playing with yesterday?
<spiv> I think jelmer & jam have basically identified the cause
<spiv> What remains is to figure out what to do about it :)
<peitschie> oh!  that was quick!
<peitschie> is it likely to be a difficult thing to fix?  I ask as i'm being pushed to decide if we do branching in svn... or whether we can continue with bazaar
<peitschie> tho i'd love to stay with bzr for the project... this bug in particular is causing mega hassles trying to get changes committed back to svn, or merge changes in from svn :S
<spiv> I'm not sure, I don't think I've seen the full discussion between jam and jelmer.  It's related to what happens after a ghost is filled in.
<peitschie> ah k :)... sounds like it might be safest to let the project do the branching in svn... then i'm not under time pressures (or emotional pressures!) for this to get fixed immediately
<spiv> It sounds like there needs to be some clarification/decision about precisely what bzr's expectations are there (so that bzr-svn can meet them), but also how to do that in a way that is as useful as possible.
<peitschie> yes... thats understandable.  bzr-svn does seem to be the cutting edge of ghost handling in bzr world
<spiv> Yes, it seems so!
<spiv> It seems likely that there is a corebzr issue here, but bzr itself doesn't tend to make it easy to create ghosts.
<spiv> They in practice tend to come from imports/conversions from foreign systems.
<peitschie> yes... i had noticed that a lot of core bzr seemed to struggle with ghosting in various ways... though the most recent version definitely has been a huge improvement
<peitschie> either way... i'm very gratified to hear the probable cause was found!
<spiv> Me too:)
<poolie> hi spiv,
<poolie> when you're done with news could you look at james's bug 653307?
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 7)" [Critical,Triaged] https://launchpad.net/bugs/653307
<spiv> Sure.  Another one :/
<chx>  never know whether  diff -r 17210..17200  include 17200 and 17210 or not
<chx> does it or not...?
<poolie> chx: it names two trees
<poolie> the one committed by 17210 and the one committed by 17200
<poolie> and it gives the diff between them
<chx> that does not help me :)
<chx> does it include the differences introduced in 17200?
<poolie> so it excludes the first and includes the right
<poolie> stewart: want to be  a bzr-stats maintainer?
<stewart> poolie, sure.
<poolie> :)
<poolie> congrats
<stewart> poolie, next thing i was going to add was some extra mapping of email addresses to the same people... the mysql tree is rather chaotic with what people committed as.
<poolie> by all means still ask for reviews
<poolie> but now you can merge them yourself
<chx> poolie: so it exclude 17200 and includes 17210?
<chx> poolie: that sort of "includes the first" sitll does not help me :(
<chx> poolie: yes. it does. i see. i do not understand at all.
<chx> poolie: but i see.
<stewart> poolie, great.
<chx> poolie: thanks
<poolie> chx it's easier if you remember that the numbers are assigned when you commit, after you finish changing the tree
<chx> poolie: i still do not understand a word. what tree?
<chx> anyways, back in ten.
<vila> hi all !
<peitschie> hi villa
<peitschie> *vila
<vila> _o/
<peitschie> thats the cutest wave eva lol
<vila> \o_ \o/ _o/ _o_ hop hope morning exercise
<vila> s/hope/hop/ typo
<poolie> hi there vila
<poolie> i'm trying to work out if we actually agreed on not having rcs
<vila> Seen  my last comment on the review ? I misremember ?
<vila> It seem I fail to reach agreement for even the tiniest details these days :(
<poolie> ah, it's ok
<poolie> isn't my graph nice? :)
<vila> I believe the agreed plan is that we will do an API freeze in the last
<vila> beta, then make a 2.3 branch, then release 2.3.0 directly off that
<vila> branch, then possibly a 2.3.1 etc into Natty.  rcs are unnecessary
<vila> overhead since the final source is normally good.
<vila> straight from your mail
<vila> Message-ID: <AANLkTim4JhUYhHkWhMFr6bqPo5KhjtCFZmrUJw_iZQX7@mail.gmail.com>
<vila> and indeed part of the [RFC] Releases planning thread
<vila> graph.. which graph ? :)
<poolie> "less open bugs"
<vila> wow fix vs confirmed... amazing
<poolie> and it's really pulled ahead the last few months
<vila> Wow in progress decreasing, excellent. I still need to purge my queue...
<vila> the 1700 figure is also interesting to compare with the one reported by fixed-in (~1142 or something)
<vila> I'm not sure I de-dupe in fixed-in  for that matter
<spiv> A loosely related graph I find interesting: http://webnumbr.com/active-bzr-branches-on-lp
<spiv> Which is climbing, but perhaps indicates more that LP's classification of "active" is incorrect than anything else.
<vila> https://code.edge.launchpad.net/ubuntu is still surprising to me
<vila> but indicates a strong activity nevertheless
<ddaa> are those all native lp hosted bzr branches?
<ddaa> or some kind of automated churn?
<spiv> vila: ta, created http://webnumbr.com/bzr-branches-for-ubuntu ;)
<spiv> (although sadly the point-and-click thingy failed and I had to go read some xpath docs)
<vila> spiv: great thanks !
<vila> ddaa: who knows...
<CcxCZ> so when is next stable release planned? (whether I should bother publishing ebuild w/ py2.7 fix)
<vila> CcxCZ: are you subscribed to the bazaar ML ?
<CcxCZ> nope
<CcxCZ> is it on gmane?
<vila> I think so
<spiv> http://news.gmane.org/gmane.comp.version-control.bazaar-ng.general I think
<vila> The topic is under discussion, and two points are relevant for you if you're involved in gentoo packaging
<CcxCZ> I'm not an official packager, I just try to fix bugs when I bum pinto them
<vila> CcxCZ: One is that it would be very nice to know which bzr/plugins versions are carried (any gentoo command to get that updated will be awesome)
<vila> the other is that https://edge.launchpad.net/bzr/+series is supposed to be the most up-to-date source for release dates
<vila> as far as 2.3 is concerned, we expect to release it next February
<vila> for 2.2 we say 2.2.2 should be released 2010-11-18 but I think that would be later (we will release it *iff* we encounter critical bugs)
<vila> CcxCZ: what fix are you referring to ?
<CcxCZ> launchpad/xmplrpc
<vila> do you have the bug number ?
<CcxCZ> wait, I'll get it
<CcxCZ> https://code.launchpad.net/~toshio/bzr/python27-lp-fix/+merge/35487
 * vila cries lp in maintenance mode
 * ddaa hands vila a tissue
<ddaa> careful with the faux-amis :-)
<vila> CcxCZ: let's try again later, but what I'm trying to understand is whether the fix has landed in the 2.2 branch or not and whether you are backporting it to 2.2.1 in gentoo only or use the lp:bzr/2.2 branch
<vila> ddaa: cries is not about crying ?
<vila> with tears of blood ?
<vila> :)
<ddaa> ah okay, I assumed you merely meant "shouts" :-)
<vila> ddaa: nah, I use ALLCAPS when shouting but I alsmot never shout for work related problems, I keep that for private stuff and even there...
<CcxCZ> no, I had to apply the patch to 2.2.something
<vila> CcxCZ: err, so you mean you backported it to gentoo only right ?
<CcxCZ> backported it to my personal gentoo overlay, yes
<CcxCZ> 2.2.1 it was I think
<vila> CcxCZ: ok, so excuse my poor gentoo knowledge here, but will this patch find its way to the 'official' gentoo distro ?
<vila> CcxCZ: I'm trying to understand how we could reduce the overall work here and whether we should apply your patch to the lp:bzr/2.2 branch or not
<vila> ha, lp is back, so the fix has landed in 2.3b2 already
<CcxCZ> nope, unless I convince the dev he should add it, so I came here to check whether I should bother to do so, or should I just wait for next release
<vila> CcxCZ: ok, hmm, right, I see the patch now, definitely not critical so unlikely to get backported to 2.2,
<vila> CcxCZ: I think that answers your question: it will be available in 2.3 only
<vila> CcxCZ: now, do you know a way in gentoo to get which bzr/plugins versions are installed ?
<CcxCZ> gtg now, back in few minutes, kay?
<vila> CcxCZ: Sure !
<spiv> vila: I don't think 'critical' is precisely the criteria for a backport to a stable branch
<spiv> It's more 'is the benefit worth the risk (and effort)?'
<spiv> So a medium importance bug that has an utterly safe fix would be a good candidate for a backport, for instance.
<vila> spiv: that doesn't really fly with the SRU policy, but it seems I can't summarize this sort of thing so feel free to amend our doc on the subject
<spiv> vila: I believe it does fit the SRU policy
<spiv> "# Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)."
<spiv> Especially as part (1) is bolstered by our large automated test suite.
<spiv> It also fits with what I recall poolie saying in the past.
<vila> spiv: I'm not the one that needs to be convinced... my understanding of the current situation is that 2.2.1 is still not in maverick-updates
<spiv> That's more to do with a smooth, effort-free path for getting our stable micro releases into -updates than anything else though, isn't it?
<vila> spiv: and for this particular case, unconditionally overriding the python implementation is a risk to miss more 2.7 fixes
<spiv> (And making our test suite pass in the package build environment helps create that smooth path)
<spiv> vila: haha 2.7 fixes
<spiv> vila:
<spiv> 2.7 is already being handled more conservatively by upstream than previous 2.x releases for updates, because they don't plan any more 2.x at all.
<vila> right, more conservatively in this case still means they broke 2.6 compatibility...
<spiv> Right, but this fix is fine on 2.6 too
<vila> ... which I won't remember in 6 months
<spiv> Well, to be less abstract: I think the risk that this specific workaround for 2.7 might cause problems later is pretty low.
<spiv> And if a future 2.7 does break it, and passes the SRU process for maverick-updates, then I'm sure a corresponding fix for bzr would be accepted for maverick-updates too :)
<spiv> We should get the python package build to pass bzr's test suite too, not just the bzr package ;)
<CcxCZ> vila: I'm back but I'm not sure I understand the question. Plugins (except for launchpad) are packaged as normal gentoo packages: dev-vcs/bzrtools, dev-vcs/bzr-svn, ...
<vila> CcxCZ: I only have a basic knowledge of gentoo, so this may be obvious to you, I'd like to know what command or series of commands I should use to get the plugin list and their associated versions
<CcxCZ> bzr version / bzr plugins seems best to me :-) but I just used `equery list -f 'bzr'` to get all packages with 'bzr' in name
<CcxCZ> note that equery is in gentoolkit package and not installed by default
<CcxCZ> vila: what do you need it for?
<vila> CcxCZ: doh, good point on  bzr version / bzr plugins :-D
<vila> CcxCZ: I need it to get a distro point of view about what is packaged
<vila> CcxCZ: but bzr version/plugins may do it, I need to make sure my setups don't interfer here
<vila> which BZR_PLUGIN_PATH=+site:+core should do
<vila> CcxCZ: sounds like a very good plan, portable, easy to explain, usable by anybody, excellent
<CcxCZ> equery belongs -f '/usr/lib(64)?/python.*/site-packages/bzrlib/.*'
<CcxCZ> should search for packages that installed files matching regex
<CcxCZ> since gentoo ebuilds are usually written in version-agnostic way, the version numbers should match
<vila> CcxCZ: ok, so both commands (and bzr version/plugins too for that matter) tells me about *installed* packages (and my VM only has bzr itself installed)
<vila> CcxCZ: is there a variant that can tell me about plugins that *can* be installed ?
<CcxCZ> not really, because ebuilds don't have any identificator marking it as 'bzr plugin', but equery list -pf 'bzr' should give you an idea (or -pof if you want to search overlays)
<CcxCZ> or you can use online tool http://gpo.zugaina.org/Search?search=bzr
<vila> CcxCZ: some result: only bzr-2.2.0
<vila> ha, let me try that
<vila> CcxCZ: hmm, from http://gpo.zugaina.org/dev-vcs/bzr-git, 'gentoo' is the official and 'funtoo' an overlay ? What is bzr-git-9999 ?
<CcxCZ> 9999 means current head is pulled from developers' vcs
 * spiv wonders what happens if the branch has more than 9999 revisions...
<vila> ha, and the Overlay: bazaar (layman) just has no icon right ?
<CcxCZ> use gentoo-portage.com to see only normal portage
<CcxCZ> spiv: it's bumped with some nines :-)
<CcxCZ> there are packages like that
<CcxCZ> (they use date as version number iirc)
<spiv> CcxCZ: heh :)
<vila> CcxCZ: excellent, I think gentoo-portage.com is a good starting point for me now
<vila> for me for now ?
<vila> CcxCZ: so http://gentoo-portage.com/dev-vcs/bzr says that 2.0.1, 2.0.4, 2.2.0 and 2.2.1 are available right ? (As in the user can decide which one is installed)
<CcxCZ> note the keywords: 'arch' means stable, '~arch' means testing (for now)
<vila> CcxCZ: I was about to ask :)
<vila> CcxCZ: weird, http://gentoo-portage.com/Search?search=dev-vcs%2Fbzr doesn't mention qbzr even if http://gentoo-portage.com/Search?search=qbzr says it's part of dev-vcs...
<vila> CcxCZ: anyway, food for thought, thanks for the juicy pointers ;)
<CcxCZ> also you may want to read this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3
<CcxCZ> maybe http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2 before that
<vila> CcxCZ: thanks
<CcxCZ> vila: the uri you posted searches for dev-vcs/bzr* but qbzr is dev-vcs/qbzr
<vila> ha, implicit globs...
<vila> we should lobby the qbzr devs to switch to bzrq :) I'm sure they will love the idea :D
<CcxCZ> substring search raher than glob, but whatever :-)
<vila> CcxCZ: indeed: http://gentoo-portage.com/Search?search=bzr is the best fit
<vila> net-libs/libzrtpcpp  is irrelevant but fun anyway :)
<vila> http://packages.gentoo.org/category/dev-vcs?full_cat is a good summary too, even if I don't understand everything there :)
<jelmer> yeah, libzrtpcpp always comes up in searches for bzr in debian/ubuntu as well :-)
<CcxCZ> vila: just msg me if you need anything gentoo-specific
<vila> CcxCZ: ok, thanks !
<sender> jelmer: hi, are you available? :)
<jelmer> sender, hey
<jelmer> sender, I'm at work at the moment, I can help later tonight though
<mgz> launchpad seems slow today. making lots of nutty packages?
<mgz> *natty
<vila> naughty ?
<mgz> very.
<mgz> wonder if I can find a big enough chunk of time today to look at hooks...
<vila> don't tell me :-/
<rubbs> I created a repo and one of my devs can not add a .bzrignore file. He's in the group that owns .bzr dir and it's mod'd to 775 at this point. am I missing something? bzr: ERROR: Cannot lock /home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate: [Errno 13] Permission denied: u'/home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate'
<Glenjamin> sounds like something inside .bzr isn't owned by him
<vila> rubbs: mod'd -R ?
<jam> morning vila
<vila> jam: morning !
<rubbs> yeah. I'm bombing the whole thing and running again. It's possible I missed something, and this is more for instructional purposes.
<rubbs> It's possible I have an odd sticky bit set up or something
<vila> /home/httpd implies this is also served via http ? As such it's owned by the web user ?
<vila> nah, www user or whatever is used for your install
<rubbs> also I had one other quick question. My devs like to connect to the dev server with this: http://www.expandrive.com/windows It's basically sshfs for windows. Would this cause problems if their working tree is on the sshdrive, but they are working in windows? with a windows version of bzr?
<vila> ouch
<rubbs> vila: /home/httpd in this case is misleading. it's not a web directory at this point.
<rubbs> mostly being used as an "example" to teach bzr
<vila> there have been problems with sshfs in the past about renames and locks (not sure about locks)
<rubbs> ah, and originally we had a lock problem. I think I manually fixed that.
<vila> I *used* to work with sshfs, I still use nfs a bit, but as a rule... mounted file systems are more trouble than benefits IME
<rubbs> k
<rubbs> so maybe I should have them pull things locally and bind to the dev machine.
<vila> that being said, we support it AFAIK
<vila> rubbs: yup
<rubbs> k
<rubbs> thanks for all your help/advice. I'll have to check into a few things
<vila> maxb: yeehaa for the beta-ppa !
<vila> maxb: does this mean the tests are running there ? For bzr only or did you try for some plugins too ?
<vila> maxb: did you remove the install-related failing one ?
<vila> mgz: was your lanchpad remark about 'updating diff' ? Because I see that right now for two mps of mine
<vila> mgz: and it's more than slower than normal...
<mgz> yeah, and slowness of sending out email too.
<mgz> ha, funny indentation error, wonder who the blame is on
<mgz> wow, that's ancient. vila from rev 2900?
<vila> me ? Can't be. blame emacs :)
<vila> where is that ?
<mgz> well it's you or jam from rev 1185
<mgz> bzrlib\config.py line 965
<mgz> causes this:
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.test_config/TestIniBaseConfigOnDisk/test_reload_see_new_value/
<vila> wow indenting the first mkdir address that ?
<vila> and it never failed before on windows ???
<jam> vila: I would imagine that the first time we have to mkdir 2.0 we have to mkdir the parent dir
<jam> and we never have a case where one-but-not-both needs to be created
<vila> which reminds me that I never really grok that code, what if we need to create more than 2 parents ?
<vila> mgz: revno 2900... was only fixing a module.symbol :)
<mgz> it was 2900.something, does qblame have a mainline revs only option somewhere?
<vila> mgz: dunno, but in the file graph window you have a contextual menu including show file differences
<mgz> anyway, it's an easy fix to get us down to 4 failures on windows babune +- random sftp failures
<vila> shoot !
<mgz> and I think I've got bugs on the remaining ones too.
<vila> random as in ?
<mgz> oh, maybe not the test_unicode_bzr_home one, the error on that changed recentlyish
<mgz> as in, sometimes they fail, sometimes they don't
<vila> haha
<vila> but *how* do they fail :)
<jam> vila: well, the changes that AppData don't exist are pretty much NIL...
<vila> I see so many different spurious failures that I kind of lost track sometimes
<jam> but yes, it could be turned into an os.makedirs()
<jam> it is pretty old code
<mgz> with PermissionError but if we're lucky fixing your transport cleanup with fix those too
<vila> jam: not throwing stones (or I should throw them at myself) as I was never able to run these specific tests when I was looking at the code
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/196/ <- see two new sftp failures hiding the fact I just fixed two tests
<mgz> ^I think that config code is fine bar the missing indent
<mgz> ...is it worth adding a test just for this... hmmm... nah.
<vila> mgz: no ! We already have a failing test !
<mgz> righty.
<vila> http://babune.ladeuil.net:24842/job/selftest-windows/189/testReport/bzrlib.tests.test_bundle/TestReadMergeableFromUrl/test_smart_server_connection_reset/ is surprising, we don't translate the exception correctly ?
<mgz> that's bug...
<vila> err, sry for the url in an old build, I just check it has been failing consistently for a while
<mgz> bug 581311
<ubot5> Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows (affected: 1, heat: 5)" [Medium,Confirmed] https://launchpad.net/bugs/581311
<mgz> see comment #1 for my thinking.
<mgz> I'm not completely certain just wrapping the error is right.
<vila> just reading
<vila> I don't remember if we reconnect automatically on CONNRESET, but if we do, then I see no reason to not do it too for CONNABORTED
<vila> does CONNABORTED exist on *nix ?
<mgz> yup.
<mgz> errno.ECONNABORTED on nix.
<mgz> now gmail has decided to be pants as well as launchpad. will someone please unbreak the internet?
<vila> sudo repair internet
<Kinnison> This incident has been reported to your systems administrator.
<vila> :)
<Glenjamin> Does anyone else run bzr smart over HTTP+WSGI?
<Glenjamin> i've been getting some weird errors lately, which have mostly been fixed by disabling the pyrex-built C extensions. I reported one, but haven't really had time to sit down and make reproducible test cases
<Glenjamin> (as i need to make my server work :))
<vila> mgz: the only explanations I can find about ECONNABORTED only mentions the *server* side and it occurs if the client close the socket between the listen() and the accept()...
<mgz> Glenjamin: I have done, but found it's pretty much always worse than just http
<mgz> unless you really need push, and then I don't really trust it to be correct
<Glenjamin> mgz: writeable with access controller by ldap (through apache)
<mgz> ^right, I don't think we expect to be hitting it under unix semantics, but winsock is slightly different
<vila> mgz: all in all, I think we shouldn't care and just process it as a CONNRESET
<vila> mgz: the specific error code is raised only on windows anyway
<mgz> okay, but then do we only catch the windows varient?
<mgz> can bzr use ldap directly?
<vila> mgz: your call, if you can write the associated tests with sufficient precision :-P i.e. just *add* the windows specific one on windows, who knows if/when someone will ever unify them...
<Glenjamin> mgz: it could actually, but there's not really a clean place to slot in smart-server authentication
<Glenjamin> and/or access control
<Glenjamin> Aside from "just use ssh", which in most cases is a good solution
<Glenjamin> with a short nickname on a remote master branch, and then doing "bzr nick" on a local bound branch, I'm getting part of the progress bar left over
<Glenjamin> and can't reproduce on loggerhead :<
<Glenjamin> *launchpad even
<vila> Glenjamin: with which bzr version ?
<vila> Glenjamin: whatever, file a bug, poolie has fixed quite a few in this area and is definitely the one to talk to about it
<Glenjamin> 2.1.1 on ubuntu
<Glenjamin> i'll try an upgrade first
<vila> wow, yes, try an upgrade
<vila> Glenjamin: still on lucid ? Try maverick :-D
<Glenjamin> LTS :)
<vila> Glenjamin: use the stable ppa !
<vila> :D
<Glenjamin> don't upgrade servers that aren't broken!
<Glenjamin> we do, but we don't update packages very often
<vila> Glenjamin: you just said it was broken ! (Ok, I stop :)
<Glenjamin> dunno why I didn't try that first, it's fixed
<dev001> @ a 'bzr  multi-pull' in my system_wide_plugins dir, i'm, today, getting a bunch of " ... minimum exported version ..." errors: http://pastebin.com/6YN3sGxw.  Some, not all, of my pulls are failing.  What to do here?
<jelmer> dev001, is that repeatable? I mean, after you've done that multi-pull don't most errors go away?
<dev001> jelmer: hm.  took three iterations, but, yes ... the errors are all gone now.  anything to worry about ?
<jelmer> dev001: no
<dev001> jelmer: that's what i like to hear :-) thx.
* Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it  ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | Launchpad down/read-only from 22:00 - 00:00 UTC for a code update
<metaperl> hello... it seems that bzr has the concept of revision (http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief)  by default which means it's fairly easy to track back in history ... that seems to be missing from git unless you manually do some sort of tagging of each commit?
<maxb> metaperl: revision == commit, more or less. I don't understand what difference you are seeing
<metaperl> maxb:  it may just be my inability to use github, but I have problems moving back in time to find a file that is no longer in my repository. that being said, I just browsed around on launchpad and tried to move through various revisions of the bzr source and did not find that straightforward either. I might be better off with the old school svn
<maxb> hah!
<maxb> I don't think it's any easier there
<poolie> hi maxb, jam
<mgz> what's the easiest way of creating a working tree with bzr over sftp?
<poolie> bzr-upload?
<poolie> fix wts to work over transports? :)
<poolie> i've been meaning to do that for years :/
<mgz> heh. I read the note in the push docs, and thought someone might have already done it.
<peitschie> morning everybody
<mgz> is that bug 606249 or is there also an earlier one poolie?
<ubot5> Launchpad bug 606249 in Bazaar "WorkingTree should use transport (affected: 1, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/606249
<poolie> i don't see why it would actually be all that hard
<poolie> it is that one, but i wouldn't be surprised if there's an equivalent old bug
<mgz> bug 44663 also talks about the restriction but isn't about lifting it
<ubot5> Launchpad bug 44663 in Bazaar "When push can't create a working tree, some basic info should be made available (affected: 0, heat: 0)" [Wishlist,Confirmed] https://launchpad.net/bugs/44663
<poolie> mgz i think basically we just need to audit for the places it uses local directory access
<thumper> abentley: bzrtools is bitching about versions
<thumper> abentley: just a FYI
<poolie> check all those capabilities are supported by transports, or update them if not
<poolie> make sure that it doesn't get substantially slower using a localtransport
<poolie> (which is basically an aspect of the previous point)
<mgz> all sounds doable.
<jbowtie> Just pinging for feedback on my new sphinx theme ( http://lists.ubuntu.com/archives/bazaar/2010q4/070526.html )
<mgz> I like it bar the orange.
<mgz> I'm not convinced by the ubuntu font for paragraph content, but it's nice for headlines.
<jbowtie> I'm kind of punting on the color selection until I see the proposed overhaul of the main site - I know someone has been working on it.
<jbowtie> But I think we really need to bring the main site, wiki, and documentation together visually.
<jbowtie> mgz: I could dial back on the ubuntu font for para content, but it actually looks great in print. I'll take a fresh look in a couple of weeks when I'm less besotted with it.
<mgz> yeah, that's worth doing. twas, emmajane? that did a rehaul of the main site last yearish, I'm not really sure more big changes there are a good plan, but tightening everything up would really help.
<jelmer> 'morning poolie, mgz, jbowtie
<mgz> hey jelmer.
<mgz> ...just about to ask you about a bug, but launchpad is going down so I'll leave it for next time I remember.
<poolie> hi there jelmer
<peitschie> mornin jelmer
<jbowtie> Hi jelmer - it seems to me bzr-svn never has to deal with branch divergence; do you have some magic code that prevents that?
<jbowtie> Every time I commit from bzr-tfs subsequent pulls complain about branch divergence for some reason, trying to track that down.
<jelmer> mgz: Ah, yep - I guess it's time for our new release. :-)
<jelmer> hi peitschie
<jelmer> jbowtie: bzr-svn sets the branch tip manually when pulling, it has its own code to notice branch divergence
<jelmer> jbowtie: Which methods are you overriding exactly?
<jbowtie> jelmer: For branches, just pull and is_compatible
<jbowtie> Most of the stuff I'm doing is in the repository classes.
<jelmer> jbowtie: Branch.pull() or InterBranch.pull() ?
<jbowtie> jelmer: GenericInterBranch.pull() - don't really have a TFS-native representation due to silliness in TFS workings.
<poolie> hi jbowtie
<jbowtie> hi poolie, thanks for the feedback on the binary diff/merge stuff.
<poolie> you're welcome, thanks for tackling it
<poolie> i can see the point about just handling big files well but it's not really either/or
<jbowtie> I agree, but fixing big file support is likely a harder problem - need to rethink repository format for that one.
<jbowtie> I've also got plans for .xcf files as well - my real driver - but I think tackling archives first will cover a much wider array of use cases.
<jbowtie> jelmer: Do you know where the branch tip is being set in bzr-svn?  I'm not seeing anything obvious in branch.py
<jelmer> jbowtie: It should be in InterBranch.update_revisions(), look for a call to self.target.generate_revision_history()
<jbowtie> jelmer: Found it, thanks. Looks like it is exactly the chunk of logic I need to implement to fix my bug.
<jelmer> jbowtie: Great. :-)
<jelmer> jbowtie: Btw, I was wondering whether it was possible to use bzr-tfs against codeplex.com, apparently it runs a Team Foundation Server. Have you tried that?
<jbowtie> jelmer: I have not tried that yet, I suspect they're running TFS 2010 which bzr-tfs doesn't support yet (though someone submitted a patch I need to review)
<jelmer> jbowtie: They have a broken (what I assume is a) tfs-to-svn bridge, which is causing strange errors when bzr-svn is used against it.
<jelmer> jbowtie: Ah, ok.
<jbowtie> jelmer: I'll have a look at supporting that once I've fixed the disappearing revision bug (revisions make it to the repository but not the branch)
<GungaDin> when cherry picking, will there ever be a way to track history of these revisions in the future? or is it now just like a regular merge of the deltas?
<GungaDin> or the text?
<jbowtie> Which is, you know, kind of an issue...
<jbowtie> GungaDin: Tracking cherry picks is something on the roadmap for the future. See http://wiki.bazaar.canonical.com/CherryPick
<GungaDin> but when it's done in the future, will it possible for cherry picked revision in the past?
<dash> bzr, the global causality violating VCS
<peitschie> lol
<fullermd> Causality?  Bah.  What did it ever do for me?
<jbowtie> GungaDin: I assume not, but that depends on how it is ultimately implemented. With a cherry-pick we currently preserve the revid but not the ancestry.
<jbowtie> In theory you could reconstruct the ancestry via repository forensics.
<jbowtie> I think I just coined a new job description.
<dash> jbowtie: please, we prefer to be called "programmer-archaeologists"
<jbowtie> dash: Depends on whether you consider it a reconstruction of ancient history or solving a case of patricide.
<fullermd> I think it's more matricide, 'cuz when you find out it happened the first word out of your mouth will be "mother-".
<jbowtie> fullermd: Actually depends on whether it's the left -hand or right-hand parent that's lost.
<jbowtie> Besides if it's repository forensics, I can put "Private Eye" on my business cards.  P
<fullermd> Ah, a whole new field of ancestral chirality is opening up.
<jbowtie> GungaDin: Did that answer your question?
#bzr 2010-10-14
<GungaDin> yes.
<GungaDin> thx.
* Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it  ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<GungaDin> is there a special way to rename a branch in bzr?
<LeoNerd> mv
<LeoNerd> A branch doesn't need to know its own name.. it's simply a location, a directory path on disk
<KombuchaKip> What is the difference between bzr pull and update commands?
<fullermd> pull is for updating one branch relative to another.  update is for updating a working tree relative to its branch.
<spiv> 'pull' brings a branch up-to-date with another copy of that branch (so long as they haven't diverged).  'updated' brings a tree up-to-date with its branch.
<fullermd> (except for bound branches, which break the rules to keep you on your toes)
 * KombuchaKip is confused
<fullermd> My work here is done   :)
<jbowtie> The way I remember it is:  bzr checkout, use bzr update; bzr branch, use bzr pull.
<KombuchaKip> So in the centralized model, does it make a difference?
<peitschie> KombuchaKip: in the centralized model, you are usually be using checkouts correct?
<jbowtie> In the centralized model (svn-style) you would typically do bzr checkout, which means you'd be using bzr update (because other people are checking into the same branch)
<KombuchaKip> peitschie: Yes, I use typically a checkout first time.
<peitschie> KombuchaKip: jbowtie beat me to it :).... so you'll be using update, not pull
<KombuchaKip> peitschie: Ok, so I will just forget pull for now.
<peitschie> KombuchaKip: yup :).  when to start treading into branching and such, then you can learn about pull/push/merge etc.
<KombuchaKip> peitschie: Fair enough. I'm still trying to decide whether to use it for my project (www.avaneya.com) or not, but leaning towards it and away from svn.
<peitschie> KombuchaKip: bzr is definitely worth a look.... even if you decide to stick with svn for now, don't write bzr off though :)
<KombuchaKip> peitschie: My main concern is compression and handling of large binary files.
<KombuchaKip> peitschie: Well, fortunately I have the luxury of choice at this point since nothing is under SCM yet so I can still choose.
<peitschie> KombuchaKip: that does help.  What size binary files are you talking about out of interest?
<KombuchaKip> On the order of tens of megs to possibly around a gigabyte.
<KombuchaKip> peitschie: And they won't compress well, nor will deltas be computed likely efficiently.
<peitschie> KombuchaKip: ahh... i get the feeling bzr may struggle with those resources.  Though work is being done to improve large binary management... I suspect gigabytes will likely blow its socks off
<KombuchaKip> peitschie: I hope though that there is some attractive GUI for managing an apt repository that draws from Bazaar source.
<KombuchaKip> peitschie: Well, to be fair, I don't know of any SCM that handles them well.
<fullermd> I think that's the arena that Alienbrain targets.
<peitschie> KombuchaKip: i'm not too knowledgable about the apt repo based on bazaar source guis... I think there are a few
 * KombuchaKip googles said
<KombuchaKip> peitschie: Yes, I'll take a look.
 * fullermd glances at the site.
<fullermd> Oh, and alienbrain is highly portable; it works on both Windows AND MacOS!
<peitschie> KombuchaKip: but your definitely right about large binaries... to some degree i'd suggest for now managing their life cycle outside your code if possible?
<peitschie> lol... wow! both of them?
<KombuchaKip> fullermd: lol ;) I only run GNU.
<fullermd> In Africa, the GNU runs YOU!
<KombuchaKip> peitschie: Yes, that might be best to do. I'll only commit source media asset files, like models and such and have derived works like large videos generated by make.
<KombuchaKip> fullermd: ;)
<KombuchaKip> Hmm Alienbrain doesn't look like it's free.
<fullermd> I think it's highly not.
<peitschie> yes... it's so non-free my wallet would hurt from talking to it i think :(
<KombuchaKip> peitschie: hah. It would be nice if we had something free for stuff like this. Or rather, eventually extend the functionality of Bazaar and work within its framework to have it more flexible for artists and their data too.
<peitschie> KombuchaKip: it's definitely coming :).  there is a lot of activity on the mailing lists around these types of problems... so even if its not there yet, bzr moves quite quickly... so i don't see it being terribly far off (<6months if progress maintains)
<fullermd> Well, the needs of meda management and text file management are pretty divergant.
<KombuchaKip> fullermd: Agreed.
<fullermd> AB's biggest selling point is integration with all sorts of meda-type programs (photoshop, stuff from Avid, etc)
<fullermd> Second to that is handling big files.  I mean *big*, multi-hundred-gig-plus, files.
<peitschie>  KombuchaKip: it wont jump up to gigabytes overnight... but tens of megs is becoming more easily within range with current advances... merge tool work is being done to allow merging of binary data (e.g., merging images, tars etc)
<fullermd> bzr probably isn't going to target files that size any time soon  ;)
<KombuchaKip> fullermd: I understand.
<peitschie> hehe... for sure.... theres a lot of very specialised memory management stuff that needs to happen at that level
<KombuchaKip> Thanks for everyone's help and advice. I'm going to go eat some avocados now.
<jbowtie> Yeah, it would be great if we get the Unity3D people to talk about how they do asset management.
<jbowtie> They've got some sort of homegrown VCS for managing all those ame assets.
<jbowtie> *game assets
<KombuchaKip> Well, I'll be sure to add Bazaar to game credits and boast of how great it is on the project website.
 * peitschie thinks acovados then bzr sounds like a life preference
<KombuchaKip> peitschie: As a raw foodist, I like my software raw as well. I don't like it when the source code is cooked out of it.
<peitschie> rofl
<peitschie> i never thought of it that way... my mind expands once again :-/
<fullermd> Well, I know I've dealt with software that felt like it gave me salmonella before...
<KombuchaKip> peitschie: Raw food goes perfectly with free software. I can't stand proprietary food. No joke, we've got patents on food now. Monsanto.
<KombuchaKip> fullermd: Or diarrhoea.
<peitschie> KombuchaKip: open source does tend to build the freshest binaries...
<KombuchaKip> peitschie: I even mailed Stallman a copy of The China Study since we need to get him raw. His mind is already raw, but his body needs to be too so he'll be around for another century and finally finish Hurd.
<KombuchaKip> peitschie: That's right, organic too, and not sprayed with DRM.
<peitschie> KombuchaKip: hehe... i dont know if a century is going to be enough for Hurd to get there.  Looks like Duke Nukem Forever might beat Hurd completion lol
<KombuchaKip> peitschie: Oh probably. At the least, I think he is actually reading it and that's the main thing. I want to see him healthy.
<peitschie> KombuchaKip: an admirable aim for sure :)
<KombuchaKip> peitschie: ;) Alright, dinner time.
<KombuchaKip> By the way, what's the "Gateway to LAN" I see in the Bazaar preferences for? Sounds cool.
<jbowtie> OK, here's a scenario. Decided to branch a large, slow repository. Connectivity is lost partway through.
<jbowtie> So on disk I have most of a repository, no branch, no working tree.
<jbowtie> What I'd like to do is implement some sort of resume command that just pulls the rest of the repository revisions, creates the branch, creates the working tree.
<jbowtie> Where do I start?  Somewhere in sprout?
<jbowtie> Looks like what I want is BzrDir.open_branch(), followed by WorkingTreeFormat2.initialize(), followed by a bzr pull. Does that sound right?
<lifeless> jbowtie: bzr checkout .; bzr pull
<lifeless> ?
<spiv> jbowtie: the key problem at the moment is that the partial stream from the remote repository will almost never be in a wholly complete/consistent state, so bzr atm can't simply save the partially fetched revision data into the local repository.
<lifeless> jbowtie: note that bzr's streaming fetch does /one/ big transaction, so unless you're doing just-in-time conversion, you won't be actually resuming anything.
 * spiv looks up the relevant bug
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/116148, and also https://bugs.edge.launchpad.net/bzr/+bug/125067
<ubot5> Launchpad bug 116148 in Bazaar "bzr branch should be resumable if interrupted (affected: 4, heat: 10)" [Wishlist,Confirmed]
<jbowtie> spiv: OK, at least its bzr and not my code.
<spiv> What you can do is fetch smaller amounts, e.g. 1000 or even 100 revs at a time.
<jbowtie> lifeless: Actually I'm converting a foreign repository, commits after each revision, so that should be all right.
<spiv> Oh, 1 at a time works too :)
<spiv> In that caes lifeless' first suggestion is good.
<jbowtie> Oh, I actually missed that line. I'll see if that works.
<jbowtie> That didn't work, mucked up the bookkeeping playing with bzr reconfigure I think.
<jbowtie> But I'll try it if I lose the server connection again.
<poolie> hi spiv
<spiv> Hi poolie.  I've made some progress on bug 653307, as perhaps you've seen in my comments to it.
<ubot5> Launchpad bug 653307 in Ubuntu Distributed Development "Import fails with missing referenced chk root keys (affected: 1, heat: 8)" [Critical,In progress] https://launchpad.net/bugs/653307
<spiv> I've got a simple 'bzr cross-check' tool now that compares the inventory roots agree for the common inventories of 2 or more repos.
<spiv> It seems to be a similar kind of problem to bug 485601.
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
<peitschie> spiv: you need a test sucker?
 * fullermd mentally pictures a giant squid with a clipboard...
<spiv> peitschie: this is a different bug, not involving bzr-svn :)
<spiv> peitschie: (but so far looks like a similar sort of cause in the relevant code that creates bzr branches out of deb packages)
<peitschie> spiv: I did see that on the description... I was thinking more that I have the two pure bzr repositories made from svn that exhibit the issue if you had any interest in the results to this check :)
<poolie> hey spiv, that sounds good
<vila> hi all
<bialix> bonjour vila!
<vila> _o/
<mgz> morning all.
 * fullermd waves at vila.
<maxb> 16:03 < vila> maxb: yeehaa for the beta-ppa !
<maxb> 16:05 < vila> maxb: does this mean the tests are running there ? For bzr only or did you try for some plugins too ?
<maxb> 16:05 < vila> maxb: did you remove the install-related failing one ?
<maxb> Tests work! bzr only. I caused it to skip, but it was only testing whether the install script would actually run, so that's valid - since the package build implicitly tests that anyway :-)
<vila> excellent work ! That's a significant stepping stone on the MRE road
<vila> So, how did you skip the test ? Unconditionally or based on source tree availability ?
<maxb> It had existing code to skip based on the presence/absence of setup.py, but the code was dodgy - it tested presence in one directory, then tried to execute it in a different directory
<maxb> So I fixed that
<maxb> In the packaging branch only. Need to merge propose that
<vila> maxb: ok, can you put up... yeah :) Can you try to target 2.2 for it ?
<maxb> Not 2.1? In case we want to SRU lucid?
<vila> I don't think we'll be able to run the tests successfully for 2.1 (or did I misremember ?)
<vila> maxb: but if you can target 2.1, that's better anyway
<maxb> oh, alright
<vila> maxb: I mean, I'd be delighted to be able to run the tests for 2.1, but I prefer to focus on 2.2 and 2.3
<vila> maxb: you may want to update bug #644015
<ubot5> Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite (affected: 1, heat: 155)" [Undecided,Confirmed] https://launchpad.net/bugs/644015
<C-Keen> DerGuteMoritz: ah it is something in my code, could affect the gazette as well then
<C-Keen> oops sorry
<jbowtie> Cause I don't really want spend the next 8 hours pulling revisions by hand when I already have 95% on disk.
<vila> jbowtie: still there ? If the local repo is sane, bzr won't pull the already present revisions
<jbowtie> vila: Yes and sounds good.
<vila> jbowtie: bzr missing should tell you, but it can be a bit verbose...
<ddaa> No help in #emacs, so I'll ask here...
<jbowtie> vila: Almost works, this is where some of the corner-cutting in my bzr-tfs plugin rears its ugly head.
<ddaa> anyone knows how to teach emacs that ReST comments are multi-line?
<jbowtie> Not this vim user.  ;)
<vila> ddaa: no idea
<jbowtie> vila: Just implemented Transport.clone, looks like I now need to implement Branch.get_rev_id.... oh, well, next milestone was overdue anyway.
<jbowtie> Thanks for the hints, will go away and hack for a bit until this works.
<vila> jbowtie: make sure your plug your transport into the test suite
<vila> jbowtie: that could reveal many subtle bugs there
<jbowtie> vila: Yeah, it's probably far enough along now to make that worthwhile.
<vila> jbowtie: roughly you need a get_test_permutation function defined in your transport module
<vila> jbowtie: hmm, you also need a test server... that may be more complex :-/
<vila> jbowtie: there is lp:bzr-local-test-server that can help use a real server under certain conditions though
<jbowtie> vila: One of the reasons I've been putting it off. But I can mock it since it's all XML messages in the end.
<vila> ha
<jbowtie> vila: Don't laugh, it's horribly painful even when it works.  :)
<vila> jbowtie: not laughing at all, it was more a: 'Ha, hmm, yeah, not trivial'
<jbowtie> vila: It's also why it's so slow in creating a repository. Anything I can do to make that more resumable is a big win.
<yann2> Hello, I ve got a question about the "decentralised with shared mainline" workflow
<yann2> the developer creates his own branch using bzr branch, regularly gets update to the mainline using bzr merge...
<yann2> commits locally using bzr commit - but how can he push his changes back to the mainline?
<Glenjamin> it depends on who has write access to mainline
<yann2> I cant seem to find how to do a bzr merge <dest>
<Glenjamin> basically you bzr push <dest>
<yann2> the push wont overwrite changes made to the mainline by other users?
<Glenjamin> if there are changes which the destination doesn't have, the push will be rejected
<Glenjamin> hang on, i'm not explaining this well, lemme start again
<yann2> ok I think I understand - user tries to push, fails because mainline has modifs the user doesnt have - so user needs to merge and push again?
<Glenjamin> yann2: thats correct - but with one caveat
<Glenjamin> push makes the destination a mirror of the source, so pushing could alter the order of the history slightly
<Glenjamin> the best approach is to have a direct mirror of the central branch locally
<Glenjamin> merge your feature branch into that, then push it back to central
<yann2> you mean bzr pull instead of bzr branch?
<yann2> ah you mean having two branches locally, one a direct mirror, and one a branch of that mirror...
<Glenjamin> yes
<Glenjamin> in order to merge to mainline, you have an exact mirror of mainline on local, and use that to merge and update mainline
<yann2> so bzr pull to a local mirror, bzr branch from that mirror, bzr merge to the mirror and bzr push to sync the local mirror with the mainline?
<Glenjamin> where you bzr branch your feature branch from is unimportant, but yes
<Glenjamin> you can also use bzr checkout and bzr update to have your local mirror of mainline remain in sync
<yann2> I got only one dev so will try without for now... but will definitely get back to this if we get more
<yann2> afraid I might scare him otherwise :)
<Glenjamin> yeah, if you're not too worried about history order possibly changing, then just push
<yann2> thanks for your help
<elmo> how do I review a branch against mainline without merging it?
<elmo> and preferably without making a copy of mainline and merging into that to do the diff
<Glenjamin> merge --preview, or (q)diff
<Glenjamin> bzr diff --old=path/to/mainline
<elmo> Glenjamin: thanks
<aa_> hi everyone, can I extract a subdirectory of a repo as a new repo with revision history intact?
<spiv> aa_: you can use the bzr-fastimport plugin to export the history, and then filter it to only have the directory you want, and import that.
<spiv> So the answer is: sort of.  You can synthesise a new revision history that just contains the subdirectory.
<aa_> spiv: ok, great, that sounds like what I meant anyway, a new history would need to eb generated I guess
<aa_> spiv: thanks :)
<spiv> Another option is you could also just make a commit that deletes everything except the subdirectory, and moves that subdirectory to the root of the tree.
<aa_> spiv: ooh, didn't think of that
<aa_> but then I have all the revision history too
<spiv> Right.
<spiv> So which you want depends on exactly what effect you want.
<aa_> the first one
<spiv> *nod*
<virus_found> Hello. Why is it so?  $bzr revno lp:cuneiform-linux    returns "491", but   $bzr log -r491     returns "bzr: ERROR: Requested revision: u'491' does not exist in branch: BzrBranch7('file:///home/virus_found/abs/cuneiform/src/cuneiform-linux/')"
<virus_found> Do I need to pull/fetch/whatever it in order to see the log of 491 revision?
<rubbs> you don't need to pull, but you do need to specify the remote location if you want to read the remote location's log
<virus_found> Oh, thanks, I'll try.
<rubbs> something like $ bzr log -r491 lp:cuneiform-linux
<rubbs> np.
<virus_found> Thank you so much :)
<virus_found> Works.
<rubbs> not a problem. glad to have helped
<virus_found> :)
<vila> mgz: ping, do you have a wip about the transport hook ?
<vila> mgz: and did we have a bug for it ?
<mgz> vila: not yet but it's down for today, and no.
<mgz> I'm guessing branching off lp:~spiv/bzr/hooks-refactoring is the lower conflict path.
<vila> mgz: but you have a branch already no ?
<mgz> nope. I read some background, but haven't had multiple uninterrupted hours till now.
<mgz> (I do now have a branch, but really just now)
<vila> mgz: what did I try then ? Only a pastebin'd patch ?
<mgz> oh, I'm not building on that one, it was just a hack branch to test the theory.
<vila> oh I know, I found it back
<mgz> ah, sorry, I didn't realise you wanted it again, would have pasted the link
<vila> np, my question was vague anyway
<mgz> okay, that's a hook stubbed out.
<mgz> as a post connect hook is going to (potentially) be called multiple times per transport
<mgz> accounting for reconnections
<mgz> but disconnect is a once? per transport thing, what should the test code do with this new hook exactly?
<mgz> okay, implemented.
<mgz> working backwards though, now I need to work out what tests I need.
<awilkins> Is there an svn-fast-import (not export) ?
<vila> mgz: sry, wasn't paying attention. Hmm, yes, it could be called multiple times by transport but only once by connection (i.e. only if we need to reconnect)
<vila> awilkins: meh, may be the svn devs know better ? ;)
<mgz> my code at the moment is just calling disconnect multiple times in this case and it seems to not blow up.
<mgz> so I'll do that for the moment and people can think of better ways in review
<vila> Hmm, disconnect should be protected against multiple calls because a connection can be shared between several transports
<vila> mgz: yup, it is (at least the http one I'm looking at)
<awilkins> vila, The use case is ; I want to give a training course, splitting the participants into two groups, Group B gets Bazaar, Group S gets subversion
<awilkins> vila, Although silly me, I shall probably construct a repo in Bazaar and just push it into an SVN one
<awilkins> vila, Was just thinking that you could store course materials as fast-export and run it on any VCS
<vila> awilkins: things are often clearer when you need to explain them to someone other than.. yourself ;)
<vila> Also, groups B S... are you sure ? ;)
<awilkins> Bazaar and Subversion :-)
<awilkins> I might address group S first in any given location :-|
<vila> Oh, I got that, but some people have such perverse habits to deform everything the teachers say...
<Glenjamin> then always say them in the other order
<Glenjamin> "Groups S and B"
<awilkins> Anything that excites their neurones enough to keep them conscious
<vila> awilkins: good point
<awilkins> Not like I'm training nuns
<fullermd> Not habitually anyway.
<vila> fullermd: Dunno why I wsa thinking about you... so you finally managed to get noticed when someone thinks about you... explain why you can't sleep anymore ;)
<fullermd> Sleep?  I've heard of that, I think...    I thought it was just a rumor.
<awilkins> In the same tone, I will call my working copy folder "WC"
<awilkins> Although my course materials for this are usually sandwich recipes. Less hilarious.
<vila> sandwich recipes in working copy folders ?
<fullermd> I think he's just trying to flush out all the bad puns.
<awilkins> It's something people can edit and merge without thinking about code ; has a list of steps and a list of ingredients people can disagree about, etc
<awilkins> Sometimes I have to give this kind of instruction to people who are not programmers
<Glenjamin> interesting, what format?
<awilkins> .txt
<vila> Glenjamin: triangle or baguette
<awilkins> Cut crosswise! Remove crusts! To toast, or not to toast, that is the question!
<fullermd> Wrong question.  Corned beef or proscuitto?
<vila> nope, baguette ham butter, the ultimate
<awilkins> Corned beef or pastrami
<fullermd> Acceptable.  As long as it's measured in pounds.
<Glenjamin> i cut mine like this: http://pastebin.com/Dr6cZ3BN
<vila> gherkin is a nice option
<awilkins> Trapezoid cut sandwiches .....
 * awilkins gathers some ideas for "libraries"
<Glenjamin> halfway between rectangles and triangles
 * awilkins now has trapezoid, oblong, diagonal sandwich cut ASCII arts :-)
<awilkins> You get authors credit on the trapezoid one
<mgz> okay, two crappy tests I've ripped off parth.
<mgz> really this needs some higher level stuff checking that say, the http transport uses the hook
<mgz> but might put up for review as is so I stay way ahead of schedual for the day
<mgz> vila: mp posted.
<vila> mgz: reviewed and pre-requisites pinged
<vila> mgz: thanks !
<mgz> vila: thanks back! might be worth giving it a go on babune too to check it's as good as the hack on all tests, I only did a subset.
<vila> mgz: started
<vila> mgz: hmm, almost. Re-started
<vila> mgz: be aware that I upgraded a bunch of hosts today, so all failures may not be your fault ;)
<mgz> :)
<vila> mgz: doesn't look good: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-gentoo/lastCompletedBuild/testReport/
<mgz> cool, gives me a set of tests to check.
<vila> probably very shallow
<mgz> and some of it at least is just me being dumb.
<mgz> okay, the other part looks like a clash with transport_util
<mgz> just updating that should do.
<mgz> it's like... exactly the code I wrote but tests only.
<vila> mgz: which part ?
<vila> mgz: I'm almost off ;) But ping me later if you want a re-rerun, I'll pass around
<mgz> the adding a hook in _set_connection bit. am just deleting code now to see how much of the rest is needed.
<mgz> will do vila.
<vila> mgz: oooooh, I see, this probably can be rewritten better now, this is very very old code ;)
<mgz> right. :)
<mgz> I'm hoping for a delete-whole-file, just thinking through what the scheme replacing stuff is trying to do.
<vila> while this may shed some doubt about my memory, I think it re-enforce my coherency :)
<vila> the scheme replacing stuff is only there to get the right kind of transport because that was the only one with the right hook at the time
<mgz> I'll try deleting it and seeing how many broken pieces I get.
<vila> but there is still the begining where ftp/sftp is selected for all kind of environments, *this* will be harder to delete and test
<vila> mgz: you don't have to address that yet IMHO, a big FIXME would be enough
<roryy> that's a FIXME in extra large font?
<vila> roryy: yup, red and blinking
<mgz> well, transport_util seems to only be used in those few tests that failed in babune, so I have hopes for moving any logic we still need somewhere closer to site
<sidnei> heya, is it possible to mark a (autogenerated) text file as binary in bzr so that it doesn't show up in diffs and so it gets different conflict resolution? or is that a stupid idea?
<MTecknology> Is there a difference between bzr up and bzr pull?
<fullermd> MTecknology: Yes.  That was easy   :)
<MTecknology> :P
<MTecknology> thanks
 * fullermd is a helper!
<MTecknology> fullermd: indeed
<fullermd> For my next trick...
<MTecknology> fullermd: You going to write a bzr plugin to do everything I'm doing?
<fullermd> Yes!
<fullermd> I think.
<fullermd> If that's code for "eat a sandwich and take a nap".
<MTecknology> that doesn't sound like a plugin
<MTecknology> the plugin i want...
<fullermd> What do you have against napping?
<Glenjamin> its probably the sandwich he objects to
<Glenjamin> is bzr xml output included by default in most packages?
<MTecknology> I meant it doesn't sound like a bzr plugin
<MTecknology> bzr create-new-server-configure-it-and-migrate-existing-site-in-one-layout-to-new-server-on-completely-different-setup
<fullermd> Hm.  Well, I'm flexible; I'll go with cocktail shrimp if that's better...
<MTecknology> ^ that's the bzr plugin you should make for me :D
<Glenjamin> sounds to me like you should configure your servers more uniformly :D
<fullermd> You wouldn't have this problem if all your stuff was in Teh Cloud!
<fullermd> 'cuz then you'd just, like, waft sites around, and it would all work perfectly with no effort and scale infinitely.  Says so right here on the label.
<MTecknology> In dev I need to fully lock off every website from every other website on the same system
<MTecknology> when the dev site moves live it needs to change to a setup where it runs entirely different - designed for high caching and huge req/s
<fullermd> I use Makefiles (or their immoral equivalent) for that sorta thing.
<MTecknology> I know makefiles are great for this, but I'm just using a bash script
<MTecknology> and a python script
<Glenjamin> what language is the app?
<MTecknology> ... and about 4 other python scripts
<MTecknology> It's Pressflow
<Glenjamin> if you know python, i'd always use python scripts over bash
<Glenjamin> and generally spend your time developing a proper build/deploy script - deployment/building is the most important feature of any app
<MTecknology> except in bash I can just say.. tar "$(grep ... | sed ..).tgz" "$root_dir$(grep ...)"
<Glenjamin> and no-one can read that
<Glenjamin> short != good
<MTecknology> I had to learn python to do this actually
<MTecknology> I never worked with python before
<Glenjamin> then you could have used php-cli
<MTecknology> There's some pretty screwy things I need to do to make this work too
<fullermd> Oh, that's nothing.  I spent a giant pile of time last weekend in the bowels of Apache and mod_rewrite.  You wanna talk about some screwy things...
<MTecknology> yucky
<MTecknology> apache is too much like msft to me
<Glenjamin> anyway, i missed the start of this conversation, i don't actually know what the original problem was
<Glenjamin> apache is a known quantity, mostly :)
<MTecknology> I've saved many people by moving to Linux because of the high system load Windows caused for older hardware
<MTecknology> And also s/Linux/Ninx/ s/Windows/Apache/
<MTecknology> Glenjamin: my original problem.. I asked about bzr pull vs. bzr up - then the convo kinda digressed
<Glenjamin> ah yes
<Glenjamin> reminds me, does post-pull run after update?
<mgz> vila: pushed some updates if babune can have another go at running the branch when you next pass this way
<vila> mgz: passing, noticed http://babune.ladeuil.net:24842/job/selftest-subset-maverick/9/testReport/bzrlib.tests.test_source/TestSource/test_coding_style/
<yann2> is it possible to do a bzr export to a remote server?
<mgz> gra, need to watch my reindent
<vila> mgz: started a new one
<yann2> or what bzr command should I use to deploy the latest version of a branch to a production server?
<vila> mgz: that's what you get for reporting an indent bug this morning ;)
<vila> yann2: lp:bzr-upload if you don't want to publish your history
<mgz> I need a pre commit hook with some stuff, juggling editors means I always mess something whitespacey up.
<vila> yann2: lp:bzr-push-and-update if your want both the branch and the working tree on the remote server
<yann2> I dont have such a command vila
<vila> yann2: there are plugins
<vila> they*
<yann2> how do I install them?
<yann2> I dont want the history so upload looks like it
<vila> yann2: that os/bzr versions are you using
<yann2> ubuntu server 10.4
<yann2> 64bits if thats of interest
<vila> yann2: http://doc.bazaar.canonical.com/plugins/en/
<vila> yann2: upgrade to 10.10 :-D
<yann2> cant, just upgraded to 10.4 :)
<vila> ha no, server, LTS ?
<yann2> yep, keeping all my servers lts
<vila> yann2: I suggest using the bzr ppa to get access to the latest stable release and plugins
<yann2> https://itwiki.thehumanjourney.net/images/7/7f/Devworkflow.png trying to get this done
<vila> rats, upload is not part of the stable ppa
<vila> yann2: yup, typical use case for bzr-upload
 * vila off
<maxb> Well, we can add bzr-upload easily enough... :-)
<maxb> Shall I do it right now?
<yann2> it is packaged on 10.4 , I just checked :)
 * maxb wonders if anything has changed between lucid and what's in sid
<yann2> any idea how to access the man though?
<yann2> ii  bzr-upload                0.1.1+bzr60-1             Bazaar plugin for uploading to web servers
<yann2> seems exactly like what I was looking for though ;)
<GaryvdM> yann2:  Once installed: bzr upload --help
<yann2> cheers
<maxb> A fair number of fixes after revno 60
<yann2> maxb, what issues should I be aware of?
<yann2> I like to stick to regular repos whenever possible, but if there are serious bugs of course I'll install a ppa
<maxb> I don't use it myself, I just glanced at the commit logs
<GaryvdM> zazyPing2
<GaryvdM> sigh
<yann2> I get this error using bzr-upload if anyone has an idea: http://pastebin.ca/1962389 ...
<Glenjamin> as a general rule, i like having the remote deployments be a branch/checkout - it means you can be sure exactly what revision they are
<yann2> Glenjamin, but then the .bzr archives would be accessible via http?
<Glenjamin> depends on your config
<yann2> well even I'd like to keep that out of the vhost if I can
<yann2> but right now  I get nothing working :(
<Glenjamin> yann2: try sftp instead of bzr+ssh
<yann2> that worked :) thanks a lot
<mwhudson> jam: did you get the mail about lp-service failures?
<mwhudson> jam: is it just that the acceptance tests are not starting a forking service?
<jam> mwhudson: that's what it looks like. I didn't see those tests when I was looking around
<jam> it seems "bin/test lp.codehosting" doesn't actually run the codehosting tests
<jam> (it runs *all* tests for some reason)
<jam> anyway, I'll fix it up, thanks for running it for me
<mwhudson> jam: basically all the bzr+ssh tests failed and non of the others, so it's likely something fairly simple
<lifeless> jam: bin/test -t <pattern>
<mwhudson> jam: that sounds strange
<mwhudson> lifeless: should work without the -t though
<lifeless> zope.testrunner is extremely idiosyncratic
<jam> lifeless: that *loads* all tests and then runs a subset
<jam> which is ok, but slow
<mwhudson> then the pattern just matches the module path
<lifeless> jam: yes, but it works :)
<mwhudson> of course, you should _always_ have -vv in there
<jam> bin/test lp.codehosting.sshserver runs the subset I thought I cared about :)
<mwhudson> sadly not
<mwhudson> jam: you ok to make the required changes?
<mwhudson> oh, you already said that
<eross> how do I check something out without having to be a contributer - eg.  not entering a pass phrase
<lifeless> use an anonymous protocol like http
<jam> mwhudson: I'll let you know if I can't figure out how to get the service running, but I'm hoping it will be fairly straightforward
<mwhudson> jam: yeah, it shouldn't be too bad, there's code to manange the ssh server process, you'll just need to make it manage the forking service too
<jam> mwhudson: at this point, I should be updating against launchpad/devel, correct?
<mwhudson> jam: yep
<GaryvdM> jam: Out of interest, have you ever worked with python amd64 on windows?
<jam> GaryvdM: nope, I've never had 64-bit windows (ever)
<Glenjamin> i ran it briefly once, 3rd party lib support was poor, and 32-bit mode was fine
<eross> ty
<GaryvdM> jam, Glenjamin: Cause Iq
<GaryvdM> jam, Glenjamin: Cause I'm trying to do an amd64 python installer, and I'm finding what Glenjamin said.
<Glenjamin> I last tried it 2-3 years ago
<Glenjamin> dissapointing it hasn't improved since :s
<Glenjamin> but in general, windows x64 has transparent support for all 32 bit apps, and hopefully bzr isn't using more than 3.4gig of memory
<GaryvdM> e.g. no 64 installer for setuptools, but found on from 3rd party.
<jam> Glenjamin: well, you can only get access to 2GB of memory unless you run special flags, and then you can only get 3GB
<jam> (both boot-time flag /3G and the program needs a bit toggled to say that it is high-bit safe)
<Glenjamin> heh, that'll teach me to be vauge in a tech-related channel :D
<jam> I just looked into it very closely in the past for other work
<jam> as when you have a 4GB machine, it is a shame that you can't actually use it in a single process
<jam> also, if you are allocating *large* chunks of memory
<Glenjamin> anyway, my point was that if you're trying to run bazaar in 64 bit python, you're probably savvy enough to go build it yourself
<jam> the cap is often like 1.3GB because of fragmentation due to how windows maps shared libraries into your process space
<jam> Glenjamin: well, we were hoping to build an installer for people, so that they wouldn't have to be savvy enough to install it themselves
<Glenjamin> oh i see
<Glenjamin> as a windows 64 user, i'd say ~50 of my apps run in 32bit mode, and there are no issues with this
<jam> Glenjamin: I would also say that memory consumption usually doubles in python 64-bit, since almost everything is a 'long' or a pointer
<jam> so while you have access to more, suddenly you consume a lot more too
<Glenjamin> a quick survey shows: 40/83 processes running in 64-bit mode
<jam> Glenjamin: and the other 43 are all system processes, right ? :)
<Glenjamin> hrm
<Glenjamin> 4 non-system 64-bit processes
<Glenjamin> so yeah - i'd expect windows users to be happy with a 32-bit installer. unless 64-bit turns out to be simple (which i doubt)
<jam> Glenjamin: people are currently complaining because of running OOM with large files and enough mem to handle them otherwise
<Glenjamin> oh
<jam> not *many* people, but enough that we're trying
<jam> at least to give them the option
<Glenjamin> well i'm happy to test out the installer if you want
<GaryvdM> Glenjamin: thanks, watch this space.
<Glenjamin> do you guys know of a version control tool that can version inside of archives?
<Glenjamin> for example, docx is just a compressed set of mostly xml files - in theory a VCS could apply this knowledge to intelligently merge word documents
<dash> Glenjamin: that would require knowing how to intelligently merge xml files :)
<Glenjamin> haha
<poolie> hello jam
<jam> hi poolie, shocking to see you here so early
<vila> jam, poolie: ouch, I should really go then ;)
<jam> sleep well, vila
<vila> hehe, soon, soon
<poolie> heh, yeah, sleep well
<poolie> hi jam, i'm trying to migraet towards your timezone
<poolie> i'm actually fairly often on 30-60m after this
<vila> poolie: I just noticed that my mps about bug #323111 were first posted more than a month ago, I will go to sleep and dream that they'll get reviewed enough for me to fix them so that we can land them :-D
<ubot5> Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 2, heat: 9)" [Medium,In progress] https://launchpad.net/bugs/323111
<poolie> that would be nice
<poolie> jam, how are you?
<jam> poolie: doing pretty good. there were some failing "acceptance" tests because we weren't starting the extra service there, I'm tracking that down now
<poolie> oh ok
<jam> not sure why mailman is repeatedly failing to import
<jam> while running codehosting tests
<poolie> ah, i think i've seen failures there too
<poolie> trying to load something that looked like it might be auto generated?
<poolie> mailman_path.py?
<poolie> something like that?
<jam> "no module named mailman.monkeypatches.lpmoderate"
<poolie> mm i saw that too; you could ask on the lp list i guess
<poolie> is bzr rebase included in the windows installer?
<poolie> re https://answers.edge.launchpad.net/bzr/+question/129467
<poolie> s//rewrite
<Glenjamin> rebase in the message implies its not up to date?
<jam> poolie: rebase was renamed to 'rewrite' and the new installer installs the new one, but doesn't delete the old one
<jam> known bug, I believe it is attributed to bzr-windows-installers
<Glenjamin> Are there any plans to put xmloutput in core? I've run into a few things lately where tools are parsing the normal log output (since they usually copy the svn implementation and tweak it). It'd be nice to be able to rely on xml being available
<maxb> Is there any convention to log messages for bzr - wrap at 80 characters, vs. one linebreak per notional paragraph?
<maxb> s/convention/recommendation/ I guess
<poolie> wrap before 80, like in code
<poolie> Glenjamin: i'd be happy to see it in core if you would like to put up a merge proposal
<peitschie> mornin all :)
<maxb> Did I do something wrong with https://code.edge.launchpad.net/~maxb/bzr/2.1-test_setup-skip-properly/+merge/38465 - why is it listing a PQM revision under "Unmerged revisions" ?
<jam> maxb: because you started at bzr/2.1 and targeted bzr
<jam> and that specific revision hasn't propagated up eet
<jam> yet
<jam> did you mean to target lp:bzr/2.1 ?
<jam> (The branch name would hint at that)
<maxb> urgh
<maxb> I entered ~bzr-pqm/bzr/2.1 in the form. I guess the radio button must have been wrong
<jam> maxb: it is possible that entering text doesn't update the radio button
<jam> IIRC I filed a bug on that a long time ago
<jam> for a different form, though
<maxb> right, reproposed properly this time :-)
<jelmer> maxb: Did you see my updated meta-lp-deps mp?
<maxb> I did. And then I forgot about it. Oops :-)
<jam> mwhudson: got the failing tests to run, now to fix... oops EOD
<mwhudson> jam: ok
<jam> the one good thing is that while waiting for the test suite to run, it gives me time to work on bzr code
<mwhudson> jam: i'll subscribe to the branch and look to see for stuff tomorrow morning
<spiv> Hooray hard disk failure :/
#bzr 2010-10-15
<jelmer> spiv: :-( Is your data ok?
<spiv> jelmer: yeah, everything on that disk is backed up every 3 hours
<spiv> So at worst we'll have lost some mail I guess... and a whole bunch of time.
<poolie> hi spiv
<poolie> spiv, raid1 :)
<poolie> you know it makes sense
<spiv> poolie: :)
<spiv> I'm not sure that futzing with making raid work is actually a net savings of time ;)
<LeoNerd> RAID of course also doesn't protect you from  rm -rf
<LeoNerd> Or ext3 bugs
<spiv> The current arrangement is basically have a dedicated backup drive and a cronjob for rdiff-backup.
<spiv> LeoNerd: right
<spiv> So we'd want to add another drive rather than repurpose the existing backup drive.
<maxb> 'Error -3 while decompressing data: incorrect data check' ... hmm, mysterious
<poolie> spiv, you may be right
<poolie> i bought a UPS but it has been a net loss of time so far
<poolie> (more for the sake of avoiding spikes than to stay up and running)
<lifeless> spiv: you might like to look for ForwardingResult in bzrlib.tests
<lifeless> spiv: theres a trivial patch waiting for someone ;)
<sidnei> hi poolie, i can't remember if i asked you this before or not, so here goes: is it possible to mark a text file as binary in bzr so that it doesn't show up in diffs and so it gets different conflict resolution? or is that a stupid idea?
<poolie> it's a good idea but it's not currently supported
<poolie> there's a bug asking for it
<sidnei> poolie, we're storing minified css/js files in a branch, and we constantly get conflicts on them. the fix is always to re-build them from the original source. it also makes merge proposals pretty nasty.
<poolie> patches welcome :)
<poolie> it won't be too hard
<poolie> you know you want to :)
<sidnei> i do :)
<sidnei> maybe during paternity leave
<sidnei> poolie, would that be bug #218128?
<ubot5> Launchpad bug 218128 in Bazaar "want a way to mark files as binary even if they look like text (eg pdf files) (affected: 9, heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/218128
<poolie> yes
<sidnei> bug #491556 seems relevant too
<ubot5> Launchpad bug 491556 in Bazaar "Add option to ignore files from diff view but not VCS (affected: 3, heat: 1)" [Wishlist,Confirmed] https://launchpad.net/bugs/491556
<jbowtie> CodePlex is happy for me to test bzr-tfs against their servers, even if the tests generate malformed weirdness.
<jbowtie> So we may actually get something halfway robust this release.
<lifeless> jbowtie: awesome
<jbowtie> lifeless: thanks.
<poolie> rocking
<jelmer> jbowtie: Great :-)
<jelmer> Some people have already been using bzr-svn against their svn bridge, I suspect that may have a fair bit more impact on their servers because of the mapping that has to happen on both sides.
<FryGuy-> jbowtie: are you the guy that handles the bzr-tfs?
<jbowtie> FryGuy-: Yes, that's me.
<FryGuy-> also, is it normal for bzr merge to complain about uncommitted changes, but bzr st shows nothing? :(
<FryGuy-> Hi. I'm the guy that puts broken branches into the repository
<jbowtie> Yes, I was going to review those over the weekend.
<lifeless> FryGuy-: no, thats not normal
<lifeless> FryGuy-: are you perhaps using 'bzr st .' rather than 'bzr st' ?
<FryGuy-> Unfortunately, I've broken my tfs repository, and bzr-tfs no longer can work on it
<jbowtie> I really appreciate you taking the time to do that, it's really helpful.
<FryGuy-> [24]: bzr merge C:\dev\botevent
<FryGuy-> bzr: ERROR: Working tree "C:/dev/robogames/registration/" has uncommitted changes (See bzr status).
<FryGuy-> [25]: bzr st
<FryGuy-> [26]:
<lifeless> thats ...  bizarre
<jbowtie> Ouch, hopefully it wasn't bzr-tfs that broke it.
<FryGuy-> glad it's not bazaar. hehe
<lifeless> uhm, you don't have any aliases perhapss?
<FryGuy-> no this is my local machine, not my work machine
<lifeless> try 'bzr commit' - it should pop up an editor with whatever changes it thinks exists
<lifeless> or 'bzr revert', if you're sure you have no changes.
<jbowtie> FryGuy-: What does bzr info say about those branches?
<spiv> Or 'bzr --no-aliases --no-plugins st'
<FryGuy-> [26]:
<FryGuy-> bzr commit
<FryGuy-> Committing to: C:/dev/robogames/registration/
<FryGuy-> missing application/config/config.template.php.OTHER
<FryGuy-> aborting commit write group: PointlessCommit(No changes to commit)
<FryGuy-> [27]:  bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow.
<lifeless> hah, added but missing
<lifeless> FryGuy-: bzr remove --new
<lifeless> should do it
<FryGuy-> ah
<FryGuy-> i did it another way, but ya
<spiv> Hmm, that's perhaps a bug in 'bzr st'
<lifeless> spiv: 'feature' ><
<FryGuy-> bzr rm application/config/config.template.php.OTHER
<FryGuy-> should I file a bug report?
<spiv> FryGuy-: yes, please do.
<spiv> At a minimum that error shouldn't suggest 'See bzr status' if that command won't tell you anything :)
<FryGuy-> well, i'm glad there's some experts in here at least :)
<jbowtie> I'm going to have to start prioritising my bzr work, too many open branches on my local machine.
<jbowtie> OK, just proposed an actual plan of attack for large binaries on the mailing list. Please find the glaring flaw in my logic.
<KombuchaKip> jbowtie: Man, I really started a shit storm opening pandora's box in bringing up that whole issue with my game.
<poolie> hi spiv
<jbowtie> KombuchaKip: We were always going to have the issue eventually, might as well get it sorted now.
<poolie> are you persisting on the inventory package importer failures?
<KombuchaKip> jbowtie: Fair enough. And at least now we'll have a good real world case study to test it on.
<jbowtie> KombuchaKip: That's the plan. I was going to need this solved before I could start writing my diff/merge proposal for Blender files anyhow.
<jbowtie> And if no one finds a glaring flaw in my approach, it'll be a glorious opportunity to really learn the messy internals of bzr.
<KombuchaKip> jbowtie: Excellent. I'll let you know the repository URL as soon as I get it up so you can see how well it runs on our large game data files. I'd have the repository up sooner, but sadly DreamHost doesn't have Bazaar over any other means than ssh.
<poolie> spiv i think you win some kind of prize for single largest diff
<poolie> even though it's mechanical
<spiv> poolie: yes, I am persisting on that, in between trying to recover from the disk failure.
<poolie> :} sorry, didn't mean to lack sympathy there
<poolie> is it kaput?
<spiv> Don't worry, no lack of sympathy inferred :)
<spiv> We're a bit puzzled atm, actually.
<lifeless> spiv: just checking it wasn't lost - did you see the code duplication I referenced in tests ?
<spiv> We're fearing an issue in something other than the disks, because while copying from the backup drive to the new drive we started getting IO errors too.
<spiv> lifeless: I did, branch pushed even, just haven't lp-proposed it yet
<lifeless> awesome thanks
<spiv> lifeless: thanks for noticing!
<spiv> On one hand it would be nice to discover all our data is completely intact, even stuff since the last 3-hour backup window... on the other, hard drives are cheap and quick-ish to replace, other components not so much.
<poolie> do you have offsite backups too?
<poolie> duplicity to s3 is very good
<spiv> For some key stuff, but not for the bulk.
<spiv> I think when we last looked s3 was more expensive than we were willing to pay.  Someone recently pointed us to crashplan which looks tempting.
<poolie> hm
<poolie> we could swap gpg-encrypted duplicities with each other
<poolie> i have a few tens of GB free, at least
<spiv> That sort of thing starts making Tahoe sound more interesting :)
<poolie> mm
<dmuir> anyone, how do I deal with a path conflict?
<dmuir> ah, found it in the docs
<dmuir> hmm, looks like the docs are wrong
<dmuir> it says to use `bzr mv PATH2 PATH1` + --action=take-other or --action=done to resolve the conflict
<dmuir> I tried being smart and did bzr resolve PATH2 --take-this
<dmuir> but this resulted in bzr crashing
<dmuir> I re-read the docs, and I misunderstood because of a formatting bug
<dmuir> filed a bug report for the crash
<jbowtie> dmuir: Can you also file a bug report for doc formatting bug?
<dmuir> sure
<jbowtie> dmuir: Thanks. I'll fix that up this weekend.
<dmuir> had a look at the bzr.dev docs and it looks like it has been fixed there
<dmuir> jbowtie: should I still submit a bug report?
<jbowtie> dmuir: Well mention which version of the docs you were looking at and I'll get the fix backported to the appropriate branch.
<dmuir> it was 2.2, but that said, in some ways the formatting was better in 2.2
<jbowtie> dmuir: I'm about to go offline, I'll have to continue the conversation in the bug tracker.  ;)
<dmuir> ok
<poolie> hi
<poolie> hi vila?
 * vila still shaving :)
<poolie> your face, or a yak?
<vila> poolie: hi, almost there but typing with a single hand, expect more typos :)
<poolie> go away and be in the moment :)
<vila> my dace :D (must eome yaks are easier)
<fullermd> I thought you said you'd make MORE typos   :p
<vila> face some. that's MORE :)
<fullermd> See, that's why I gave up shaving last millennium.  Saves me all those tpyos.
<poolie> woo, feedparser took my patch to enable cache contro/
<vila> hi all ! (Shaved and showered)
<vila> poolie: thanks for the reviews !
<vila> poolie: reading the modify-config one
<vila> 1) regarding indentation: I disagree but don't care enough either to block on this so I'll fix it
<vila> 2) regarding sections: I won't to keep avoiding them until we are a clearer plan but it *will* be taken into account (later)
<vila> 3) regarding config_id/paths. As explained in the COVER letter (I think) I don't want to force the user to use paths for --scope
<vila> So it's more coherent to display them in the output. Now we *also* need a way to make the relationship more obvious
<vila> But since there will be scopes that are not taken into account yet, I'd like to address that later too
<vila> (default values in code, command line, env variables are such scopes)
<vila> and they don't have a clear path equivalent (of course we can just say that in the output but... I feel it's too soon)
<vila> and a minor point is also that it makes testing harder since the paths are ugly there and not relevant to the real usage
<vila> poolie: I still don't get what shell scripting use case you have in mind
<poolie> re 1- i'd like to understand your thoughts there
<poolie> 2- i don't understand
<poolie> 3- that's fine; it could be nice for followon work
<vila> 3ok
<poolie> re shell scripting: people like to get bzr output that's easily machine parseable
<poolie> eg for emacs or shell scripts
<poolie> if I can say just, oh i don't know
<poolie> mail -s 'here you are' `bzr config submit_to`
<poolie> i think that's nicer than needing to strip it out
<poolie> i don't mind if that's, say
<poolie> `bzr config --just-the-value submit_to`
<poolie> (hypothetically)
<vila> ha, right, so that's the --active option which only output the *value*
<poolie> ok, great
<vila> typing too slow, yeah, right
<poolie> then perhaps that should be in the user docs too?
<vila> indeed
<vila> and implemented ;)
<vila> 2 sections are useful but in the actual implementation... messy
<vila> so I avoided supporting them even if I *want* them supported once we settle on (for example) use them *only* for paths
<poolie> (i don't think we should reproduce all the help in the user guide, but we do get some feedback saying there's not enough there, and like tests or washing up it's much easier to do it as you go
<vila> got you
<poolie> are you talking about printing which section of the config it came from?
<spiv> Hooray, all data recovered.
<vila> yes
<vila> but also about specifying it when setting a value
<vila> the use cases I presented are all when working in a given working tree (or branch)
<poolie> hooray
<poolie> spiv, so you have more than daily rdiff backups?
<poolie> you may have a point there
<poolie> spiv, i think you should land your news branch soon before it goes stale
<vila> but in the long term it's probably useful to be able to work on any config scope by specifying the right options from the command line
<vila> but since sections are still unclear I prefer to not implement anything before they are clearly defined
<poolie> fair enough
<poolie> we could have a followon bug for that too
<vila> the whole idea of this proposal is to have a rough version *now* that can already help us understand what is going on
<poolie> yup
<vila> hence the reference to 'bzr config -d lp:bzr' showing a config value almost everybody forgot
<poolie> i really support the principle of not insisting on things fully fleshed out in every respect when they first land
<poolie> ?
<spiv> poolie: yes, just doing that now
<vila> right, that's why I feel a bit blocked on some mps even if I tried to make it clear that some parts will need further work ;)
<spiv> No conflicts with trunk atm, so hopefully it'll be trouble-free...
<poolie> vila, let's get you unblocked
<spiv> poolie: regarding backups, it seems the drives are only failing intermittently atm, so it's been relatively easy to copy everything (also, our rdiff runs every few hours, not just daily)
<poolie> i might change mine to be more frequent too
<spiv> Intermittent failures is a weird way for a drive to behave, but better than total failure I guess.
<poolie> i just put up a patch for https://bugs.launchpad.net/duplicity/+bug/433970 that makes duplicity to S3 something like 6x faster
<ubot5> Launchpad bug 433970 in Duplicity "Add an option to connect to S3 with regular HTTP (and not HTTPS) (affected: 3, heat: 16)" [Medium,In progress]
<poolie> i was very pleased
<poolie> pretty small patch
<poolie> that does suck; i have seen it before for mechanical failures
<spiv> I'd suspect cables or something, but both drives had read errors on totally different hardware.
<vila> poolie: https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690 is the one I have in mind, it's opt-in now so I don't know what is missing here or in the pre-requisites
<poolie> i had a confusing thing with my sata drives a while ago where the cable was loose and it gave intermittent errors
<poolie> i'll have a look
<vila> no whatsnew for modify-config... wtf ! I'm 95% sure I put something there.... did I commit in wrong tree ?
<vila> by the way, using paths for section in configs have several consequences I thought about:
<vila> 1) it can be used in *all* config files, so we could merge bazaar.conf and locations.conf
<vila> 2) , it can apply to paths that describe branches but *also* to relative paths inside a working tree or colocated branches or branches in a repo
<vila> 3) it could even be used for ignores (opening a path to be more compatible with foreign vcs that implement ignore rules in multiple files
<poolie> what do you mean for 'paths for section'?
<poolie> making everything like location.conf?
<vila> what we do in locations.conf
<vila> i.e. this applies only to the matching path, highest levels being inherited
<vila> which works pretty well for scalars but need some... tweaks for lists
<vila> s/pretty well//
<vila> like the ability to say: I want to add values to the inherited list (removing values... I don't know what to do with the idea)
<poolie> mm, and also there's the question of 'match the most specific path' vs 'match in the most important relevant config file'
<poolie> i probably asked for it, but should we really have 'bzrlib.transform' vs maybe just 'transform'?
<vila> the later takes priority I'd say
<poolie> i'm typing too fast
<vila> I think I understand and that
<poolie> you're saying the most important relevant match? that works for me
<vila> yeah
<vila> regarding bzrlib.transform vs transform, my take was to allow aliases but you disagreed, this is related to what namespace we want there
<poolie> we could say the 'bzrlib' is implicit
<vila> it's a little bit less important than the sections though (or may be not)
<vila> it's higly tempting yes
<vila> but what about 'alias', 'bookmarks' and whatever plugin authors want to use
<poolie> plugin.bookmarks?
<poolie> plugin.bookmarks.auto_record?
<vila> which immediately raises: whine, this is too long, why is bzrlib taking all the good short names
<poolie> but surely bzrlib.transform.orphan_policy is a bit inconsistent with bookmarks.auto_record?
<vila> yup
<vila> aliases kind of avoid the issue
<vila> which is not necessarily good
<vila> it 's a bit like selftest -s, we have a clearly defined name space, but we know some shortcuts are more important than others
<poolie> in some ways avoiding the 'plugins.' from the name is good because it allows code to move
<poolie> a bit like that
<poolie> i wonder if we will ever have overlap with multiple things wanting the same name?
<vila> and there should be some easy way to avoid name collisions at the alias definition registration
<vila> :)
<vila> there is always the case of different plugins clashing
<vila> or worse: bzr-core starting to use some names without knowing that a plugin was using it
<poolie> i think that would be a real concern if there was no namespacing at all
<poolie> but if we have a single word namespace, perhaps it's less so
<poolie> but if we have a single word namespace, perhaps it's less so
<poolie> git does use git.core.thing vs others
<vila> git.core sounds redundant vs git though
<vila> from a user pov, 'bzr.' 'svn.' might be enough
<vila> we don't *have* to say 'bzrlib.transform.orphan_policy' when 'bzr.orphan_policy' is enough
<poolie> i think some amount of grouping of the options is useful though
<poolie> in programs that get a lot of them (dozens or a hundred) then having them just all randomly named makes things a bit harder
<vila> but that requires specifying 'bzr.orphan_policy' when declaring 'bzrlib.transform.orphan_policy' (but may be I'm over-concerned here)
<poolie> how about bzr.transform.orphan_policy then
<vila> yeah, I don't have hard numbers about what could *become* config variables in the code base
<vila> hmm, s/bzrlib/bzr/ and be done, seducing
<vila> s/bzrlib.plugins.name/name/
<vila> the later should work too, very-unlikely to clash since that requires having a plugin named after a bzrlib module
<vila> checking with http://doc.bazaar.canonical.com/plugins/en/
<vila> pfew, email vs email_message
<vila> bisect vs bisect_multi
<vila> that's the closest, so no clash
<vila> and if a clash would happen... that would strongly suggest inclusion in core anyway :)
<poolie> right
<poolie> obviously you can just have random names and then group them in metadata or in the documentation
<poolie> but then everything needs to know about that
<poolie> i think there's quite a few things that will make more sense as config options
<poolie> especially if we allow for builtin defaults, and for per-process settings
<poolie> and make the internal api a bit cleaner
<poolie> as i think you've started doing
<vila> yup, I should really focus on documenting what I have in mind in a.... developer doc and make a mp for that for feedback
<vila> and refer to it for a ML discussion
<poolie> that'd be good, and also user docs
<vila> indeed, but user docs aren't enough, I should have said that: user doc *and* dev doc since I'd like to change the internal model
<vila> I think this sums up my feelings regarding the modify-config mp: I wanted to land *something* so I can refer to it in these docs
<vila> so I deliberately avoid some issues and implement some hacks with an unspecified target which led to annoying questions raised in the review :)
<vila> I *don't* have an hidden agenda, I just happen to not have published it yet :)
<vila> it just happend that I don't have ?
<vila> right, I happen every day :)
<poolie> i'm replying again now
<poolie> vila, ok, a few more tweaks and let's land it
<poolie> i think i did many more reviews this week than when i was officially pp last week
<poolie> which is fine
<vila> indeed, thanks for that, the queue is back under control
<vila> now if we could get testtools updated on pqm....
<poolie> mm
<poolie> i'm going to leave the rest of them to you i think
<poolie> i still wanted to finish my lp dkim fixes today and it's 6.30 already
<poolie> maybe next week i'll try tarmac
<vila> I don't have mps I haven't review at least once any more
<vila> some are waiting for either another reviewer or testtools upgrade or more input from the reviewee
<poolie> well, "leave them to someone else" then
<vila> sure, I even ping them when needed ;)
<vila> hmm, I know another reason why I don't like indenting the inplace files: it's one of the very few cases where emacs don't DTRT when I press TAB anywhere in the line :)
<vila> AAAARGH, still not fixed in maverick... why oh why can't process monitor remember that I *want* to see the command line !!
<vila> sudo process-monitor show-me-your-config-files-so-I-can-nuke-them
<bigjools> Can anyone help me work out why bzr is giving me this error please?  http://pastebin.ubuntu.com/513683
<spiv> bigjools: random guess: bzr-pqm plugin is old?
 * bigjools checks
<spiv> Hmm, a glance at the revision history for bzr-pqm suggests I'm probably right.
<bigjools> spiv: that was it, thank you
<spiv> Cool.
<poolie> spiv i think you broke 'make doc-website'
<poolie> shell cruftiness disliking parens in filenames
<ddaa> or lack of proper shell quoting
<poolie> yep
<poolie> that's crufty
<poolie> ddaa, do you remember off hand how to avoid that in a makefile?
<poolie> if i just put "$@" does that do the right thing?
<poolie> ie quote the words individually
<vila> poolie: can't reproduce locally, what error are you seeing ?
<poolie> me either
<poolie> +/srv/doc.bazaar.canonical.com/bzr/bin/update-bzr-docs:36> dchroot -c karmic --directory /srv/doc.bazaar.canonical.com/bzr//bzr.dev make doc-website
<poolie> I: [karmic chroot] Running command: "make doc-website"
<poolie> python tools/generate_release_notes.py doc/en/release-notes/index.txt d......
<poolie> /bin/sh: Syntax error: "(" unexpected
<poolie> it may be something about dash vs zsh
<vila> poolie: I got one error at first run but re-running was enough until it fails in tex for some encoding issue
<poolie> i did get a unicode error in latex but that's not so important
<vila> ha karmic... karmic ?
<vila> ha, so we got the same latex error at least
<vila> why and where is karmic involved there oh, where the cron job is running ?
<vila> I also got a bunch of conflicts in my trunk mirror where I use to run make *docs* thingies, could that be related ?
<poolie> that's andrew's change, but it's not what's breakign escudero
<poolie> i'm getting tired
<vila> ok
<vila> poolie: the web site itself is not broken so this could wait right ?
<poolie> mm
<poolie> i think the docs will just be stale until it's fixed
<poolie> and it will keep sending me mail
<vila> one by hour or by day ?
<vila> poolie: anyway, this way we are sure this doesn't get forgotten :-p
<poolie> a few a day
<poolie> oh, and bialix will mail me after a couple of days :)
<poolie> going by history
<poolie> vila https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/38522 should fix it
<poolie> i can't reproduce it either so it's kind of blind
<vila> hmm, I wonder if it was due to some persistent sphinx data and as such, will never recir
<vila> recur
<poolie> i'm just looking
<poolie> yep, that fixed it
<poolie> i mean, cleaning the tree and reverting seem to have fixed it
<spiv> poolie: odd!
<poolie> stupid danilo finding unicode bugs :/
<vila> poolie: ok, your mp isn't needed right ?
<poolie> if ascii was good enough for jesus...
<vila> lol
<poolie> not sure, i might like to land it anyhow
<vila> except for deleting the release-notes part: approve
<poolie> why not delete it?
<poolie> it's included in 1.18
<vila> haaa, including the entry ?
<vila> we were duplicatong in theses days ? ;) tsk tsk
<poolie> no, i suspect andrew moved it to 1.18 when 1.17.1 didn't happen
<vila> just kidding, if the entry exist somewhere that's all I care, remove this objection
<spiv> poolie: presumably there was a filename with a ( in it for some strange reason?
<mgz> is spiv's 27816 line diff getting reviewed? :)
<poolie> because there was a release called '1.17.1 (unreleased0'
<poolie> it looks messy in the ToC anyhow
<vila> spiv: the privous generate-release-notes.py was creating it yes
<poolie> it's not exactly likely to get released now :)
<spiv> Oh, huh.  The new build process won't do that :)
<poolie> it was detritus in this tree
<poolie> right
<spiv> "$@" is good practice anyway
<poolie> i don't know what caused it to break but a clean trunk has fixed it
<spiv> And the unreleased release is pretty uninteresting, so +1 on your patch, but pretty unimportant now.
<vila> mgz: alaready landed and spiv got the record
<spiv> \o/
<vila> spiv: since you're there, can we land https://code.edge.launchpad.net/~spiv/bzr/hooks-refactoring/+merge/36101 or do you need something done there ?
<spiv> Or if you are Unicode 6.0 enabled: ð
<vila> it seems I'm not Unicode 6.0 enabled :)
<Glenjamin> what char is that?
<mgz> I'm guessing one of the new two-people-holding-hands ones
<spiv> vila: there's a docstring tweak to make, otherwise I think it's good to land.
<spiv> mgz: U+1F64C is PERSON RAISING BOTH HANDS IN CELEBRATION
<vila> spiv: in the pyutils module ?
<poolie> \N{CHEERS}
<spiv> Apparently new versions of the relevant Xorg module will add Compose, \, o, / as a binding for it...
<poolie> mm
<poolie> i wish there was some better discovery mechanism for compose sequences than googling for 'linux compose sequence'
<vila> spiv: by the way, do you think python compatibility methods can be added there (like when we want to carry fixes that exist for 2.6 or 2.7 and use them for 2.4 or 2.5) ?
<poolie> which last time i looked suggested you read the X11 source :)
<Kinnison> poolie: I just tend to guess, and if that fails, run unicode in a terminal and c&p :-)
<spiv> poolie: me too
 * spiv applies some guess work
<spiv> poolie: /usr/share/X11/locale/en_US.UTF-8/Compose ?
<poolie> gucharmap is ok
<poolie> i'd like to press Compose-something then type "celebration" and have it find it...
<spiv> poolie: Compose F1 ;)
<spiv> poolie: that would be lovely
<mgz> thanks for the testtools reviews lifeless! will just leave a couple of comments in the mps.
<vila> spiv: by the way, do you think python compatibility methods can be added there (like when we want to carry fixes that exist for 2.6 or 2.7 and use them for 2.4 or 2.5) ?
<spiv> vila: python compat methods are harder, because sometimes they use syntax that simply won't compile in earlier versions
<spiv> vila: which suggests that we perhaps should have pycompat_27 or whatever for things backported from 2.7
<spiv> etc
<vila> spiv: ha, sure, I was thinking about things like open_socket_as_you_should and... what was it... the addinfo_url stuff
<spiv> Hmm, I don't think the addinfo_url thing is a good candidate for such a general module.
<vila> ok, nm
<spiv> You'd start forcing imports of that sort of stuff on every invocation unless you use some contortions.  The cure would be worse than the disease.
<poolie> \N{PERSON LEAVING COMPUTER}
<mgz> ehehe
<Glenjamin> i suppose in theory everything that requires compatibility needs to be abstracted behind at least 1 layer, and then that layer adds the compat if necessary
<spiv> Glenjamin: or in some cases you can simply write the code in such a way that it works directly on all supported versions
<spiv> Excellent, new hard drives installed and backups restored.
<vila> grrr, pqm accepting submissions far too fast again and no feedback on what is failing again
<vila> ping losa, something is weird in the bzr.dev pqm branch, submissions are accepted far too fast (as in: the tests don't run so some error is seen as success)
<mgz> doesn't poolie's makefile change just need to land?
<vila> my first suspicion will go to cruft in doc/en/release-notes leading to conflicts and some unexpected consequence that my crystal ball refuses to reveal
<spiv> +1 mgz
<spiv> Hmm
<vila> mgz: why can't I reproduce locally then ?
<spiv> Although, I think the checkout is constructed from scratch each time, so old detritus shouldn't be an issue.
<spiv> But I "makefile changes land" swiftly followed by "weird landing issues" is a pretty suspicious combination.
<spiv> It wouldn't hurt to throw poolie's change at PQM and see what happens, though.
<vila> well, I don't know what damage has already occurred so I prefer quick losa check first
<mgz> hm, vila, can I get some of your time today to help me with leak things?
<vila> mgz: sure
<mgz> the second babune run from last night shows I fixed the obvious things, but...
<mgz> for some reason the actual leak prevention bit isn't working
<mgz> http://babune.ladeuil.net:24842/job/selftest-subset-windows/11/ <- took nearly four hours to complete
<mgz> when I was testing locally, every run has been fine, except one where *everything* hung. so there's something odd going on.
<vila> mgz: let's retry just this one then, something weird happened this night too for the jaunty and karmic claves (took several hours each)
<mgz> I'd blame babune too were it not for the fact one run I got it too.
<vila> when ?
<mgz> there was no obvious trigger, just testing a subset from the console, so there's still something non deterministic here
<vila> I mean, when did you see that, yesterday ?
<mgz> yup, last night, after I'd pushed up the last change
<mgz> I frantically reverted stuff to try and work out what I'd broken... but never saw it again
<mgz> I still sometimes get a leak, but I've not seen any other hangs, and it was *everything* hanging
<vila> shudder
<mgz> which is clearly what babune had to make it over three hours
<mgz> http://babune.ladeuil.net:24842/job/selftest-subset-windows/11/testReport/bzrlib.tests.per_branch.test_branch/TestReferenceLocation/ <- see multiple tests taking 5 seconds.
<mgz> the hack branch didn't get that... might just be bad luck, or might be something borked
<vila> one possible cause could be the hook is not taken into account because all hooks are cleared for test isolation but I don't believe it
<mgz> right, manually checked that for the first rev and the hook clearing happens before the hook is added.
<vila> http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-windows/11/consoleFull
<mgz> but it does feel like the hook was ripped out entirely for that one run.
<vila> hangs all over the place indeed
<vila> right, the current run also has hangs, I'll kill it
<mgz> ValueError: line 6 of the doctest for bzrlib.pyutils.calc_parent_name has an invalid option: '+SKIP'
<mgz> bah, hadn't seen that before
<mgz> will want fixing on trunk.
<mgz> (presume it's using some 2.6/2.7 only doctest feature)
<vila> where do you get that ?
<mgz> it's from spiv's hook refactoring branch that I'm building on.
<spiv> mgz: oh :(
<vila> which has landed
<mgz> okay, -s bt and I can get hangs, I'll see if that happens again, then maybe I can debug this
<spiv> mgz: the docs don't say it is new :(
<spiv> Ah, they do, but not at the description of SKIP
<spiv> further down they say: Changed in version 2.5: Constant SKIP was added.
<spiv> It's probably reasonable to just not doctest this module, but poolie may disagree.
<mgz> that might be what broke pqm
<mgz> as doctests are weird and get compiled before most other things happen
<mgz> can't avoid 'em with -s for instance
<spiv> (I only added ths module to the list of doctested modules at poolie's request during review)
<vila> indeed, pqm use python2.4 but we are supposed to catch such errors :-/
<spiv> mgz: hmm, seems improbable: if it would break pqm, then it wouldn't have landed.
<vila> spiv: it *has* landed
<mgz> it breaks the test suite at an odd place, you don't get failures, just a traceback internal error.
<spiv> vila: sure
<mgz> but yeah, I thought we were now checking the return code properly
<spiv> vila: which therefore suggests it doesn't break pqm
<vila> I can reproduce locally with py24
<vila> well, locally, on hardy
<spiv> (and regardless the other possiblity is it had failed to land, in which case of course pqm is not broken because it didn't land)
<spiv> (so my argument is independent of the specific outcome...)
<spiv> Anyway, bedtime for me.
<spiv> Good luck figuring out what's broken :/
<spiv> So far all the candidates have been my branches...
<vila> nah, 2 for you 2 for me
<vila> shudder no subunit installed for py24 on hardy ... grrrr
<vila> hmpf, reproduced
<mgz> night spiv.
<vila> the error is output in selftest.log which means we have *some* output and as such we happily consider the tests as passing
<vila> so that's the bug that 'broke' pqm
<mgz> ...I was sure we checked the return code now
<mgz> after last time the suite broke before being run
<vila> see the Makefile for the actual check, I'll dig the mp to refresh my memory about details and alternate implementations that were discussed
<mgz> I remember various shell weirdness.
<mgz> At least cmd consistently sucks!
<vila> basically the idea was that bzr failures where supposed to leave stdout empty leading to an empty selftest.log and we used that to catch errors
<vila> and then subunit-stats is supposed to fail it it sees a failure in this non-empty selftest.log
<mgz> I see.
<vila> but in this case, the doctest outputs something which subunit-stats doesn't interpret and we're doomed
<spiv> vila: I'm surprised
<spiv> vila: (not disagreeing, just surprised)
<spiv> But, also, I'm really going to bed now :)
<vila> spiv: sleep well
 * vila crosses fingers hoping that no failure will appear caused by one the unchecked submissions
<vila> at least tests are running again, unping losa
<zpletan> I am trying to "bzr branch lp:gimp", which is >300MB (don't really know exactly how big).  I have a rather slow internet connection, which died 320MB into bzr's downloading.  Is there a way I can have bzr pick up where it left off, rather than re-downloading the first 320MB which takes around two hours?
<vila> zpletan: what did you get locally in the end ?
<vila> zpletan: i.e. `ls -lR .bzr/` and pastebin the output
<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.
<vila> mgz: any progress ?
<mgz> yeah, got some tests that reliably hang, have hook installed
<vila> doh
<zpletan> vila: http://paste.ubuntu.com/513847/
<mgz> so, the hook is currently covering less than the hack was, just need to work out where
<mgz> possibly smart server things, investigating.
<vila> zpletan: unlucky :-/
<zpletan> Bummer.  Thanks anyway!
<vila> the file feufc824zjpib16c8n3m.pack is probably borked
<vila> zpletan: wait ! There are different workarounds
<zpletan> vila: still here - go ahead
<vila> zpletan: the easiest one is to pull in chunks:
<vila> bzr init gimp ; cd gimp ; bzr pull -r100 lp:gimp
<vila> then
<vila> bzr pull -r200 ; bzr pull -r 300
<mgz> suspicious looking:
<mgz> # FIXME: No test are exercising the hooks for the test server
<mgz> # -- vila 20100618
<mgz> self.run_server_started_hooks()
<vila> depending on your internet connection you can try bigger increments
<mgz> where's that defined?
<zpletan> vila: thanks - I'll try that
<vila> mgz: irrelevant, that;s the smart server specific hooks
<mgz> you didn't do any dodgy voodoo in the method?
<vila> zpletan: also, file a bug asking for resumable pull, search for a duplicate this has been asked before
<zpletan> will do - thanks
<vila> mgz: when you say the hook is there, have you checked it is called and if yes, when ?
<mgz> it's not called.
<mgz> just using -Ethreads now to narrow things down.
<vila> not called at all or called too late ?
<mgz> at all, for the test I'm running.
<vila> and is it present with the right content /
<mgz> sec, I'll paste you my output
<mgz> I don't like that I'm getting the same thread id multiple times in the hang output at the end either
<vila> s/def _add_disconnect_cleanup(transport)/def _add_disconnect_cleanup(self, transport)/ ?
<vila> nah, nm
<mgz> it gets called for other tests.
<mgz> http://paste.ubuntu.com/513854/
<mgz> http://paste.ubuntu.com/513855/ <- the old hack branch
<vila> will be joined before started...
<vila> isn't that lovely
<vila> right, so, I'd add some prints for each hook call and each get_transport call
<mgz> http://paste.ubuntu.com/513856/ <- hook does work for some tests
<mgz> but clearly not all of 'em...
<vila> some transports are used internally during setup, I fail to see why they can escape the hook nor why they could lead to hand...except if they are the ones hanging the *server* may be
<mgz> that was my thought.
<vila> ha, got a theory
<vila> the hook fires later so the disconnect happens... sooner ? meh, doesn't fly :)
<vila> ha, no, the disconnect happen at different times, so *new* causes lead to hangs
<vila> hmm, still no godd
<mgz> I'll add some printing to my old hack so we can see where that's called in the test.
<vila> first, let's make sure no transport escape the hook, then we can think about why disconnect fails to address the hangs
<vila> right, got it
<mgz> ...it is the server.
<mgz> despite the fact it's client threads leaking.
<vila> I think the server cleanup and the transport cleanup are not registered in the same order as with the hack
<mgz> well, the server gets registered with the hack, but the hook never fires
<vila> right, because we are shutting down the server before trying to disconnect
<vila> which is weird
<mgz> http://paste.ubuntu.com/513866/ <- with the hack, disconnect gets queued
<mgz> http://paste.ubuntu.com/513854/ <- there's no "hook" line printed here at all.
<mgz> so disconnect will never be called.
<vila> but did the transport connected ?
<mgz> presumably, the test passes. I've not traced through yet to work out why the hook doesn't fire.
<vila> mgz: 'Client thread' may be misleading here, all threads are for the server, one for the listen, the others for the accept
<vila> yeah, one print for get_transport, one print for set_connection (or transport.connect), one print in the hook
<mgz> seems RemoteTransport doesn't call _set_transport
<mgz> *_set_connection
<vila> because it delegates to the... what's the attribute name
<mgz> _shared_connection ?
<vila> RemoteHTTPTransport delegates to _http_transport, should be fine
<vila> RemoteSSHTransport... is unclear, which kind is involved for you ?
<mgz> RemoteTCPTransport
<vila> ha
<mgz> so, we want to do something with the _build_medium methods?
<mgz> trying to work out the prettiest way to sort this out with the various transport classes doing rather different things
<vila> mgz: right, you've put your finger in the hole between remote transport and all the others: _set_connection is not used
<vila> so, from memory, spiv said the medium is the connection so _set_connection wasn't making sense or something
<vila> this may mean you need to call the hook in a different place
<vila> an additional different place
<vila> wll, it's that or force the _set_connection call even with no credentials
<vila> see comment in remote.py:136  The medium is analogous to the connection for ConnectedTransport: it
<vila>         allows connection sharing.
<vila> ha, I forgot those ones, see also get_smart_client() and get_smart_medium()
<vila> I'm pretty sure we can deprecate get_smart_client though, will need to check with spiv
<mgz> scattering the hook around more places does make the tests happy again
<vila> how many more ?
<mgz> well, currently inside some _build_medium methods, I've done a full test run to see if that covers everything the get_transport hack did, but it looks good so far
<vila> so, I'm not sure _build_medium is called on reconnects
<mgz> alternatively inside the `if medium is None` block in RemoteTransport.__init__ but not sure that's the right interaction either
<vila> but I'm not sure either that the remore transports handle reconnects :)
<mgz> ...I think I'll push that, it seems right-ish for TCP and HTTP (which overrides __init__) so it's probably worth a run
<vila> mgz: so a better place would be in smart/medium.py but do we have access to the transport hooks there...
<mgz> not as a transport hook, no.
<vila> at least that's where disconnect() and _ensure_connection() are defined
<mgz> the medium gets passed the details from the transport instance, but not the instance itself
<mgz> okay vila, I've pushed that. can I have another babune windows run to check that was the only missing element.
<mgz> we can discuss in the mp if we want a different hook approach, per transport rather than per connection/medium does have some downsides.
<vila> the one we need here is clearly per connection
<vila> it may make sense to have one for the transports and one for the remote transport
<vila> if only to avoid to fire twice for RemoteHttpTransport
<vila> ideally the should be one Connection object that can be inherited for this and some other attributes
<vila> s/the/there/
<mgz> as pushed, RemoteHTTPTransport correctly only fires once (the hook is in parent __init__ which is upcalled on a path that doesn't re-fire)
<mgz> ...wait, I thought, but maybe not.
<mgz> it has _http_transport *and* _from_transport, confusing.
<vila> which means it doesn't get called when the underlying http transport reconnect ?
<vila> _from_transport is for cloning
<mgz> I was trying to just leave the unlying http transport to hook on _set_connection, and not re-call
<vila> transports connects only when needed, you can have multiple clones before the first connection occurs
<mgz> but haven't quite done it right.
<mgz> unlying = underlying, clearly.
<vila> yup
<vila> transport != connection is clearly the issue here
<mgz> not undying. it's not a zombie transport.
<vila> I read it as underlying
<mgz> or untrying. a lazy transport.
<vila> ehehe
<mgz> I'll write some of this up in the mp after I've had some lunch. That, and respond to jam and lifeless in other mps... so much fun, so little time.
<vila> mgz: right, I'll look there
<jam> vila: I thought I'd point you to bug #389674, there is a bugfix patch that seems about correct, but will need some lovin to land. I don't know whether the contributor is able to finish off the work, though I only just asked
<ubot5> Launchpad bug 389674 in Bazaar "NotImplementedError(_PreviewTree.inventory) when unshelving must create the parent directory (affected: 4, heat: 20)" [Medium,Confirmed] https://launchpad.net/bugs/389674
<vila> jam: I wouldn't dare take credit for a patch you wrote :-P
<jam> well, I'm not immediately planning on playing with it, seemed a PP thing to do. But looks like it can wait for now
<vila> jam: I've subscribed to the bug so it wont fall off my radar, but I'd like to finish my buf 323111 review tweaks and I have to leave early today (as in less than an hour)
<jam> vila: np, it certainly is the end of the week anyway, just something that caught my eye
<vila> ubot5: when I mistype buf you're supposed to understand I meant bug
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<vila> jam: the weird thing is that I seem to recall seeing a mail from you not so long ago with the same kind of patch...
<vila> ha, maybe the patch was inlined in the mail
<jam> I just hacked something quickly and pasted it into the bug report
<mgz> http://babune.ladeuil.net:24842/job/selftest-subset-windows/13/ <- worked, 41 mins. so, just need to work out how best to hook and will be sorted.
<vila> mgz: whereas the karmic run seem to be hanging making me wonder if finally the same bug is not revealing itself on Ubuntu too...
<vila> nah, autofs4 playing tricks... again :-/
<vila> I should really stop mounting file systems in slaves no matter how convenient it seems to be at first
<mgz> jam: I've updated lp:~gz/bzr/require_unicode_committer_614593 per your review, if you could just double check the change is sane
<jam> mgz: do you have a quick link?
<mgz> https://code.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334
<jam> mgz: looks good to me
<vila> mgz: feeling lonely in the review queue ?
<mgz> you're still there with me!
<mgz> ack, no, you've just been merged.
<mgz> darn...
<vila> mgz: hehehe
<vila> is your transport hook mp up-to-date ? A single additional call is enough ?
<mgz> I've just worked off the rest of my debt and am about to write up the earlier chat in the mp.
<mgz> The mp works for stopping leaks currently, but the hook still needs work to be generally useful I think.
<mgz> s/mp/branch/
<vila> mgz: that could be a followon submission, stopping leaks properly is significant enough to land asap (needs a NEWS entry, err, release-notes :)
<mgz> yeah, see my cunning plan in not writing NEWS there?
<mgz> one fewer merge-from-trunk needed.
<vila> yeah, add some kind of epic fail myself regarding doc, so don't expect me to look elsewhere :)
<mgz> oh, one other thing from that mp.
<mgz> you say in the first comment "Don't forget the hooks-help.txt file."
<vila> if you haven't done it yet, I *urge* you to merge from trunk, there is HUGE probability that pqm will fail with conflicts otherwise
<mgz> where is this, and what needs not forgetting about it?
<mgz> ^I will still need one nightmare merge from trunk, clearly
<mgz> with luck it won't even be than bad a dream.
<vila> mgz: cleanup your doc/en/release-notes dir first if you ever generate the doc
<vila> doc/en/user-reference/hooks-help.txt
<vila> all hooks are documented there AFAIK
<mgz> ...is auto generated?
<mgz> I don't have such a file in a clean tree.
<vila> could be :)
<mgz> good good, one less thing to worry about.
<vila> meh, I have both a hooks.txt and a hooks-help.txt... what a mess
<vila> ok, bzr ls -V | grep hook gives an empty output, so definitely generated from the docstring :)
<vila> right, so calling from RemoteTransport.__init__ is probably wrong as no connection has occurred yet... Moreover there is a FIXME about medium being a private parameter for tests only
<vila> :-/
<vila> mgz: I don't know what to say... my feeling is that we should just file a bug asking for some sort of re-design as this is getting out of scope for the fix you had in mind which is good-enough here since I'm pretty sure a medium never re-connect
<vila> mgz: I'd approve your actual proposal with a FIXME above the remote hook call explaining that it's called once per connection but *before* the connection occurs and mentioning the lack of _set_connection call (which *becomes* an issue now)
<vila> mgz: unless you have a better idea to differ the hook call in medium._ensure_connection
<mgz> sure but a hook is a public thing so we don't want to land anything too screwy. it's the weekend now, so can leave deciding anything for now
<mgz> but can probably come up with something a little cleverer than the current that still works for leak squashing.
<vila> one solution would be to have another hook for transport *creation* and have the post_connect covers the reconnect case and make the tests set both
<vila> since disconnect() can be called multiple times, that should work
<vila> but there will still be a bug in the post_connect hook if it can't be implement for smart transports
<mgz> hm, looking at the commit builder code, I'm having third thoughts about the require_unicode_committer change too
<mgz> there's no point doing a per_repo test for something we're throwing on in __init__ I bet.
<mgz> and there's a _validate_unicode_text method I could have used but... it doesn't actually... do that
<mgz> so rev props, message, and all the other text is probably also vulnerable
<mgz> ...I'll get my lonely mps done in the end!
<vila> yeah, if a losa can upgrade testtools on pqm we may even empty the queue ! Two records in the same week !! The biggest diff and the smaller queue !!!!!1111!!
<vila> at that point, I think I should stop working and start drinking for good :)
<mgz> right. :)
<vila> mgz: you haven't feed-pqm'd https://code.edge.launchpad.net/~gz/bzr/require_unicode_committer_614593/+merge/38334, want me to do it ?
<mgz> no, see my rethink just ^ up there about whether it's exactly right.
<vila> mgz: land this one and make a new one then or at least land the minimum before working on the next, less job for the reviewer and for you
<vila> s/job/work/
<vila> bah, the two can be said with the same word in french ;)
<mgz> at the least I think I should probably move the test from bt.per_repository.test_commit_builder to somewhere like bt.test_repository.TestCommitBuilder as the test never gets as far as building a real repo now
<mgz> making the other params more robust against bad input should probably be another mp though.
<vila> yup
<vila> and you may encounter other problems, so better land the bug fix and file other bugs
<vila> this can also help people if they encounter a slightly different bug and don't consider the one you have fixed
<vila> ok, I'm off, have a nice evening, week-end all !
<mgz> hm, maybe the test is okay where it is, there are multiple commit builder classes, just seems wasteful.
<mgz> bye vila!
<txdv_> fucking shit, why does bzr log the nick of the branch
<txdv_> is there any way to change it?
<txdv_> i want to change the branch nick in the last 5 commits
<LeoNerd> It's recorded in the revision metadata. So, no.
<txdv_> that fucking sucks
<txdv_> why should someone use bzr at all it can't even handle stuff like that
<LeoNerd> You could rewrite it somehow, but then that's done by creating new revisions, so you'll break anyone else who's seen it up to that point...
<txdv_> nobody has seen it
<LeoNerd> Well.. what you're describing is called Rewriting History.
<LeoNerd> Ah, well.. then rewrite it then :)
<txdv_> and how do i do it? :/
<LeoNerd> Offhand, I'm not sure. Perhaps someone else in here knows. Likely some variant on  bzr rewrite
<txdv_> i was so fucking pissed of my assignment that i named the branch penis
<txdv_> ;(
<LeoNerd> Heh.. Yes.. it is a little nonobvious that the directory's basename gets recorded...
<txdv_> i like the concept of branches in git better
<txdv_> a branch in bzr is the directory name
<txdv_> ...
<LeoNerd> Well.. bzr tries to be fairly minimal in this regard. People already understand directories on disks... so we'll just store one branch per dir. People already know how that works.
<LeoNerd> Trying to put multiple independent branches in one directory just adds complexity to the model for no real benefit.
<txdv_> checking out a branch in git is faster
<txdv_> branching is faster
<txdv_> especially if they differ just by a small n of commits
<LeoNerd> Hrm?
<LeoNerd> bzr can share commit information just fine...
<LeoNerd> I do that all the time. :)
<LeoNerd> I have the actual commits stored in /var/bzr/leo/ itself, and all the individual branches live at e.g. /var/bzr/leo/perl/Foo-Bar.CRAZYFEATURE
<LeoNerd> Creating a branch just creates the initial container and says "OK this is a branch of that revision".. small constant data; the actual revisions are stored in the repo
<txdv_> now rebase is not even at the pc at my work
<txdv_> in other words it's not even in the default package
<txdv_> im in a world of pain
<LeoNerd> If you can't install it on that machine, you could run it someplace you can install, and push it across...
<LeoNerd> E.g. a home machine or whatever..
<txdv_> i bad to copy 200mb
<txdv_> that's not the problem
<txdv_> renaming those branches is
<txdv_> rebase doesnt work
<AfC> huh?
<txdv_> im using it wrong
<AfC> $ mv before after
<AfC> Branch renamed.
<txdv_> and what about the history
<txdv_> i already made 5 commits and i want to rename the BRANCH NAME in the HISTORY
<AfC> oh, that's fixed
<AfC> {shrug}
<AfC> most of us have learned to ignore that
<txdv_> a collective mind of bzr users?
<txdv_> or what do you refer to with 'most of us'? xD
<AfC> most of us who long ago decided that "feature", as implemented, was completely useless, and so learned to ignore it on the rare occasions we do `bzr log --format=long`
<AfC> (this one is in the same general category as wanting to be able to "fix" commit messages after the fact. The idea is to make a change, but record somewhere in the meta data that such a change was made [ie layered on top].
<AfC> This seems agreed as the right thing to do, but for reasons I can't quite make sense of, it hasn't been done yet.
<AfC> I suspect the real reason is that the core developers of Bazaar a) write pithy thin commit messages they don't care about fixing, and b) likewise ignore the "branch nick" field.
<AfC> So, {shrug} fair enough, it hasn't been acted on by anyone as yet)
<txdv_> ill just stick to the branch name penis then
<txdv_> and push it at my work
<AfC> Well, if you used that, then it's your own damn fault I should think
<txdv_> yeah
<txdv_> obviously a feature missing
<txdv_> it's my god damn fault
<txdv_> it surely is, i started using bzr
<AfC> Or, as you've already mentioned, use the rebase plugin.
<AfC> {shrug}
<AfC> you have options.
<LeoNerd> To be honest, I'd say it's a mistake to store that branch nick in the first place. It adds nothing to meaning, and isn't really interesting...
<LeoNerd> I know of no interesting use to try to read it.
<AfC> LeoNerd: yeah, it's a bit of a professionalism failure there, I'd say
<LeoNerd> Anyway. Lunchtime.
<txdv_> omg bzr is starting to piss me off massively
<txdv_> change is in the log of the last revision, diff doesn't show any changes, though the change is not in the working directory
<AfC> txdv_: $ bzr diff -r -1..
<jam> txdv_: I would have said "bzr diff -r -2..-1" but I'm not sure what you are trying to look at
<txdv_> i guess a bzr update did it
<AfC> jam: of course (just realized what I'd typed, thanks)
#bzr 2010-10-16
<peitschie> mornin everyone :)
<_spm_Draget> I have setup sftp on my server. Since configuring all rights is possible but prone to errors, I have the sftp-only user chrooted to directory X which is currently his homedirectory. Now, the bzr repository has to be under X for him to access. Symlinks do not work. But if others want to use it, they need to be able to access X too. Basically meaning I need the same chroot folder for all people using the repo.
<_spm_Draget> Or I have just one dedicated user that is for accessing that one bzr repositories and all teammembers share the same user/password.
<_spm_Draget> CAn anyone think of a more elegant solution?
<fullermd> If symlinks broke a chroot, it would kinda defeat the purpose   8-}
<_spm_Draget> Yeah, I know :P
<_spm_Draget> But I have configured webdav and sftp... sftp giving me a headache to make a flexibe authentification system on a shared repository as I explained above and webdav only working as an addition plugin that is not available some large distributions =(
<fullermd> Well, if you need multiple people to access something, they all need access to it.  That means they need to not chroot somewhere that doesn't contain it.  Not really a shortcut to that...
<_spm_Draget> fullermd: I thought about it... but using a shared chroot would break the concept of home-folder... I would have to chroot them to /srv or /srv/bzrâ¦ ofcourse all other /srv services have the appropiate userrights but I am still not completly happy with this. Hmmâ¦ ssh allows public key infrastructure. I never tried it, but maybe I can generate key for all users and if I want to disallow access I can block single keys, instead of
<_spm_Draget> having to change the password.
<vila> _spm_Draget: yup, that's the way to go
<vila> _spm_Draget: and disallow password for the login
<gthorslund> vila: thx for fix in 661490. I somehow thought it was the >= instead of <= first, but got confused trying to understand how versions was supposed to be compared.
<vila> gthorslund: np, obviously this haven't been tested for a long time :-/ So, kudos for raising the issue !
<gthorslund> vila: I actually tried it since I wanted to test 539937. revno 75 said it fixed some issue like that.
<vila> gthorslund: yeah, I wondered about that too, but I don't use the plugin myself, so I just fixed the obvious
<vila> gthorslund: so any light you can shed on the subject will certainly be appreciated
<fullermd> Phew.  Finally got my website rework done and live.  It only took a year.
 * fullermd scratches off one more thing that used to be in CVS...
<vila> fullermd: that still leave this ftp server...
 * fullermd notes that he does NOT run ftpd   :p
<vila> they all say that
<fullermd> Oh, not true.  Some of them say "Why yes, I am running ft...   AAUGH!  Why are you stabbing me??  *sputter*  *bleed*"
<vila> Haaaaaa, 10 not 11 and the Ubuntu font becomes so more enjoyable....
<vila> fullermd: yeah, there is still a lot of  education to be done to fully switch to ssh... Generating and handling keys is still seen as arcane...
<fullermd> Let 'em use passwords.  That's fine.
<fullermd> Heck, let 'em use TFTP, come to that.  I just want to kill FTP, burn the body, eat the ashes, crap them into a shallow grave, and dance on it.  Is that so much to ask?
<vila> certainly not :)
 * vila takes some distance just in case :)
<fullermd> 'till then, I'll just sit around watching my web log to see what I broke in redoing everything.  Great excitement...
<vila> hehe
#bzr 2010-10-17
<maxb> jelmer: What is the intended minimum version of Subversion supported by subvertpy?
<maxb> 0.7.4 seems to have broken vs. svn 1.4
<jelmer> maxb: 1.4 should still be supported. Can you file a bug?
<ddaa> I vaguely recall that one point, plugins needed to be installed in directory that had a specific name for each module
<ddaa> for example, bzrtools needed to be in a directory called bzrtools, not bzr_tools
<ddaa> and bzr-svn needed to be in a directory called "svn"
<ddaa> Has things become more flexible, or easy to figure out, or is documentation, guesswork or source code inspection still required to find out the correct dirname?
<jelmer> ddaa: They still have to have a specific name.
<jelmer> ddaa: generally though "bzr-<foo>" becomes <foo>
<ddaa> yeah, I'm figuring this out
<ddaa> I guess, except for very simple plugins with only the __init__.py
<ddaa> or maybe those using relative imports
<jelmer> ddaa: It would be nice if we supported one extra layer of directories there. So you could just put *any *directory in ~/.bazaar/plugins and have bzr look in that directory for your plugin name.
<jelmer> That way we could support eggs, users didn't have to know about what name to give the directory, and several other standard python tricks would work (e.g. no need to override package_dir in setup.py)
<ddaa> yep, that would make sense and there would be no backwards compatibility issue.
<ddaa> it would make startup microcospically slower, but I don't imagine that being an issue
<maxb> ddaa: BZR_PLUGINS_AT is a slight exception - it provides a way to run plugins that are not in a directory with the expected name. However you still need to know the name
 * ddaa nods
<maxb> i.e. BZR_PLUGINS_AT=svn@/home/maxb/wc/bzr/bzr-svn/trunk for example
<ddaa> that's quite advanced though. Thank you for the reminder, I need to put a link to that doc.
<maxb> jelmer: acknowledged, will file a bug in the next day or so once I've had time to investigate a little more
<ddaa> Is there a stable URL for the documentation of the latest bzr documentation on doc.bazaar.canonical.com?
<jelmer> maxb: Thanks. Is it just building that's failing or something at run time?
<maxb> 1.4: --> fails in testsuite. build succeeded because of C's charming "hey, undefined function, let's just assume it takes no parameters and returns int" behaviour
<maxb> 1.5: --> fails in build, for a different reason
<jelmer> oh, if 1.5 fails as well I might have a look now.
<maxb> they are two distinct bugs
<maxb> the 1.5 failure was a "wrong number of parameters for function" compile error for svn_wc_crawl_revisions3, IIRC
 * maxb afk
<mgz> hm, I could probably fix this NFD issue pretty easily, but don't have a mac
<mgz> babune will probably do once we land the leak fix and vila puts up a mac slave
<mgz> expanding all voiced kana must be hell annoying.
 * jelmer is tempted to start hacking on bzr-mtn
<mgz> jelmer is already too much of a superman.
<mgz> while you're here, though, mind if I repurpose bug 587074 as a non-utf-8 filenames don't work bug, now you've fixed utf-8 ones?
<ubot5> Launchpad bug 587074 in Bazaar Git Plugin "Branching tree with non-ascii filenames fails (affected: 1, heat: 2)" [Medium,Fix committed] https://launchpad.net/bugs/587074
<vila> mgz: adding a mac slave requires the leak fix
<mgz> I... said that!
<vila> mgz: fixing the NFD issue would be great, but I fear it has to be pretty invasive as it requires, at the minimum, to store the native paths in the dirstate (imbw, but I'm 80% sure, jam could be more precise)
<vila> mgz: right, sorry
<mgz> well, there's a choice. either bzr normalises the internal store or it doesn't.
<vila> mgz: that's because I thought about it more and I think we should land the hack_transport one waiting for a proper hook fix
<mgz> that's an option.
<vila> mgz: and I thought about that because I start suspecting it to address some spurious failures on babune
<mgz> yeah, might do the random sftp failures on babune
<vila> including some 'lost connection during test;
<mgz> we've not seen any in the branches we've tested that disconnect transports properly
<vila> mgz: there is another one related to cleanup_pipe, surprisingly it triggers for some sftp tests (we may be using an http server during the setup...)
<vila> bug #655557
<ubot5> Launchpad bug 655557 in Bazaar "http cleanup_pipe related test failures (affected: 1, heat: 13)" [Medium,Confirmed] https://launchpad.net/bugs/655557
<vila> the number itself is screaming: I want to be fixed by vila
<mgz> you missed an ever better number by 2.
<mgz> *even
<vila> or by 4 :)
<vila> 4 instead of 7 would have respected 6 5 4, meh so by 3
<vila> mgz: did you get better ideas for the hook fix ?
<mgz> not so far, I agree that it'd be good to have som input from spiv on it, as smarts are his baby
<mgz> hey GaryvdM
<vila> mgz: when we implemented shared connections, the medium == connection was good enough
<GaryvdM> Hi mgz/vila
<vila> GaryvdM: hey :)
<GaryvdM> mgz: saw your installir patch - Tommorow :)
<GaryvdM> *installer
<mgz> I think it should also fix your cpp runtime issue, but I don't quite remember where you hit that, so I might need to add something extra
<vila> GaryvdM: while you're there, it would be good if windows installers always mentioned the '-1' in their name (and '-n' when needed)
<GaryvdM> vila: Ok
<vila> GaryvdM: it's documented this way in... our doc (can't remember the file name)
<vila> GaryvdM: no big deal, but I think it will make things clearer *when* a '-2' is needed
<GaryvdM> mgz: I figured it out - we are excluding MSVCP60.dll, and not MSVCP90.dll
<GaryvdM> *but not
<mgz> we don't want to exclude it now, as qt really does need it
<GaryvdM> yes
<mgz> (unless we ship the mingw qt, which we probably don't)
<mgz> + want to
<vila> mgz: why ? Wouldn't using mingw address the microsoft related problems once and for all ?
<mgz> yeah, we'd get mingw related problems instead.
<mgz> they've got some other pointless dll we'd need to bundle somehow, and generate bigger and slower libraries
<vila> Are they known ? Wouldn't them be easier to address ?
<vila> ha
<vila> bigger and slower sounds... surprising though
<mgz> blast, thought I had a repo, but it's a different bug
<mgz> oh, nope, two different symptoms of the same
<mgz> and the workaround still works.
<mgz> bah, and it is fixed already, and has a targetted bug, but not one that includes the error message, so search didn't find it.
<lifeless> heh
<mgz> I'm gonna create a giant chain of dupes here I think...
<lifeless> on i18n filenames?
<lifeless> please be careful be to be sure they /are/
<mgz> 662254 > 303954 > 205636 > 192859
<lifeless> rather than similar symptoms with different call sites
<mgz> nope, this is different symptoms and ways to break add.
<lifeless> my rule of thumb is 'if I can fix one bug without fixing the other, its not a dupe'
<lifeless> mgz: and I have a hunch that that will apply here
<mgz> it all seems fixed, but may want some specific tests as poolie was mostly looking at the symlink angle I think.
<lifeless> mgz: sounds wise to me
<GaryvdM> Hi mgz
<mgz> hey Gary
<GaryvdM> I just tried a build of your branch
<GaryvdM> Still getting a MSVCP90.
<GaryvdM> dll can't be found error
<GaryvdM> I'd like to try find a better fix
<GaryvdM> any ideas?
<GaryvdM> mgz: is there maybe a env var I can set to point to it?
<mgz> right, when, is what I want to know.
<mgz> I'm copying over when we were copying msvcr90 before, but that may be too late for py2exe
<GaryvdM> When dose the env var get set? = Before I run the build
<GaryvdM> *does
 * GaryvdM need a dose of how to spell does...
<GaryvdM> mgz: ok - now I understand what you were saying
<GaryvdM> mgz: so my question is, how do we tell setup.py py2exe what msvc_redist_dir is .
<mgz> we don't strictly need to I think, if we can just make it stop whining
<mgz> it's not smart enough to bundle it itself, if we can tell it to shut up then copy it across later
<mgz> or, we could copy it before, to somewhere py2exe sees
<GaryvdM> mgz: so if we tell it to ignore it, like this: http://bazaar.launchpad.net/~garyvdm/bzr/no_MSVCP90.dll_2.2/revision/5102 - would that be ok, because bzr-windows-installer will copy it anyway?
<mgz> I believe so.
<mgz> We don't copy it yet though, so you need that branch of bzr and my branch of bzr-windows-installers
<GaryvdM> Ok - I'm going to build with our 2 branches.
<mgz> what the hell, my new tests still fail with trunk merged...?
<mgz> I... *checked* it worked with dev ;_;
<GaryvdM> http://pastebin.ubuntu.com/515194/  - Huh - Is this stacking error? How do I fix?
<GaryvdM> Yes - it's a 2a repo, and it is stacked on ~ree/gf.recipe.bzr/trunk which is Packs 6 rich-root
<GaryvdM> mgz: that worked well, except I built 2.3b2, and not 2.2.1, so I start new build.
<GaryvdM> and submit mp for my branches.
<thumper> jelmer__: are you up?
<jelmer__> thumper: Hi
<thumper> jelmer__: https://code.edge.launchpad.net/~vcs-imports/mesa/master
<thumper> jelmer__: has the problem been fixed in bzr-git?
<jelmer__> thumper: No, I haven't looked at it again yet. As far as I can tell it only affects the mesa import and I can't reproduce it locally.
<jelmer__> thumper: This is bug 649531.
<thumper> jelmer__: not even with an incremental?
<ubot5> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/649531)
<thumper> jelmer__: I'm wondering if we have fixed it since then, and may have been a transient bug
<thumper> jelmer__: perhaps blowing away the server copy and starting again _might_ fix it
<jelmer__> thumper: I haven't tried a local incremental import yet since I don't really have an easy way to do that.
<thumper> jelmer__: the LP codeimportworkers can be run locally :)
<jelmer__> thumper: I don't think anything significant has changed since last time, though it's worth a shot.
<jelmer__> thumper: Is this particular import significant for some reason?
<thumper> jelmer__: only because of https://answers.edge.launchpad.net/launchpad-code/+question/122971, and I'm feeling bad it isn't working
<jelmer__> thumper: Ah, ok.
<jelmer__> thumper: Also, are retries of failed imports now happening daily ?
<thumper> no
 * jelmer__ tries another clone of mesa with -Dverify with the hope his machine won't run out of memory
<maxb> jelmer__: Hi. I'm trying to implement subvertpy tests which need to assert different things based on the version of Subversion being used. I was contemplating using subvertpy.wc.version() as an indicator of the underlying libsvn version, even in non-WC tests. Too horrid, or ok?
<jelmer__> maxb: That's alright.
<jelmer__> maxb: Please note that we have both version() and api_version()
<jelmer__> I suspect you'd want api_version() in this case.
<maxb> Ah, correct, since all the compatibility decisions are made at compile time
<maxb> although, hmm
<maxb> well, never mind, I think I'll just use api_version everywhere for now :-)
<peitschie> hiya jelmer, maxb
<poolie> hi there maxb, jelmer, peitschie
<peitschie> oh... hi poolie :)
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | 2.3b2 is officially released, test it  ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<poolie> (spiv is pp)
<maxb> poolie: Hi. In https://code.edge.launchpad.net/~maxb/hydrazine/lp-promote-ppa-v2/+merge/38389, is the implication of (tweak) that I should consider the MP approved having fixed the lack of NEWS entry?
<poolie> yes
<maxb> just checking :-)
<poolie> np
<poolie> it's not a big deal but i meant to suggest you would have just one news entry like
<poolie> * New lp-promote-ppa command to promote (copy) packages from one ppa to another.  By default all packages are copied, or the source packages can be filtered by name or distroseries.
<poolie> something like that
<poolie> go ahead and merge; you should have access
 * GaryvdM successfully ran ./setup.py build with 64bit python on windows. \o/
<GaryvdM> going to run selftest now
<maxb> I like that style of NEWS entry better --- /me tweaks and lands
<mgz> you're on a roll Gary.
<mgz> file bugs if you see test failures babune doesn't! (and that aren't smart-server random junk)
<GaryvdM> Hmm  ./setup.py build givs no errors, but I see warning: some compiled extensions could not be loaded
<GaryvdM> How can I see where those warnings come from. Nothing in .bzr.log
<mgz> -Werror ?
 * GaryvdM tries that
<maxb> GaryvdM: ./setup.py build -i ?
<maxb> Or rather, python setup.py build -i, as setup.py's should not be exectuable by convention
<poolie> GaryvdM: great :)
<GaryvdM> maxb: I'm using msys, so ./setup.py works :) - I'll try -i
<GaryvdM> build_ext -i
<maxb> hurrah, successful subvertpy test run on hardy
<GaryvdM> maxb: Thanks.  build_ext -i was what I needed.
<peitschie> jelmer: i just quickly wanted to touch base and see if you'd had any time for the missing chknodes bug in bzr? (bug #485601)
<ubot5> Launchpad bug 485601 in Bazaar Git Plugin "mesa incremental import fails with bzrlib.errors.RevisionNotPresent (affected: 1, heat: 7)" [Medium,Triaged] https://launchpad.net/bugs/485601
<peitschie> err... thats not the bug at all....
<peitschie> hey ubot... try bug #485601 again...?
<ubot5> Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601
 * peitschie is very puzzled
<jelmer> peitschie: So, we now have a clearer idea of why that bug is cropping up (after discussion with spiv and jam)
<jelmer> peitschie: The question is what to do with ghosts in bzr-svn.
<peitschie> jelmer: thats what I figured would b the sticking point :).  are there any ideas or workarounds at this point? or are we looking a longer wait with this?
<jelmer> peitschie: there are some ways you can work around it - basically trying to avoid ghosts
<jelmer> peitschie: The issue crops up when you merge from another branch that fills in ghosts.
<peitschie> jelmer: we've actually been trying to do that at the moment... the major difficulty is that essentially devs can't merge directly to svn from any place other than the central network repository
<peitschie> jelmer: i've gotten them feeding svn updates via the network repo, so that works ok... but committing is sticky as they need to ssh into the network repo box and do the commit locally there... i couldn't think of any other way to prevent all ghosting :(
<jelmer> peitschie: What do you mean with the network repo exactly?
<jelmer> is that a svn repository?
<peitschie> jelmer: sorry... fixing other issues :)
<maxb> jelmer: merge proposal filed for subvertpy compatibility issues mentioned earlier today.
<peitschie> jelmer: so by network repo I mean the shared bzr repository
<peitschie> jelmer: in order to avoid the ghosting, I needed a centralized copy of all the unique revisions.   I did this by creating a shared repository devs create bound branches in their own local repositories
<peitschie> jelmer: so wen a dev commits to their local feature branch, that is automatically replicated up to the network shared bzr repo
<peitschie> jelmer: so that all works great at the moment... I have a cron job atm pulling svn updates in to the repo (i.e., there is a branch of svntrunk in the network repo, and the cron job runs 'bzr pull' all the time)
<jelmer> peitschie: ah, cool
<peitschie> jelmer: the catch is that as soon as a dev tries to merge their feature into svntrunk locally (having branched svntrunk from the shared repo, and then bound it to the real SVN repo), they are no longer able to pull in updates from the central network repo
<jelmer> peitschie: right, because in that case they end up with ghosts again
<peitschie> jelmer: yup :).  so far, the only workaround I can think of is to get the dev to perform the final merge into svntrunk directly on the network repo via ssh
<jelmer> maxb: When you said using wc.api_version() in the other tests I thought you meant using e.g. svn.ra.api_version() in test_ra.py
<maxb> um, didn't I?
 * maxb rechecks diff
<jelmer> maxb: You did, but you also added a call to wc.api_version() to test_repos.py
<jelmer> maxb: I've followed up to the MP.
<maxb> jelmer: because there is no subvertpy.repos.api_version()
<jelmer> peitschie: A proper solution to ghosts and bzr-svn will probably take a while longer.
#bzr 2011-10-10
<jelmer> hey poolie
<poolie> hi jelmer!
<poolie> biab
<vila> hello all ~
<vila> !
<poolie> hi vila, jam
<jam> morning poolie
<jam> and vila
<poolie> hi jam
<vila> anybody managed to land something recently ? mgz and I believe rt #48346 has broken pqm
<vila> for values of recently starting at last Friday
<jam> vila: the last pqm email I see is Sept 7th.
<jam> so at least those emails have been broken
<vila> jam: yup, me too (see rt), first root cause. But then bzr-email was.... upgraded/reconfigured and now the submissions are failing
<mgz> morning all
<vila> ha crap, I thought mgz commented on the rt, looks like he failed to connect there then
<mgz> I didn't comment, no
<vila> mgz: np, I just pinged mthaddon anyway.
<vila> mgz, poolie, jam: _o/
<mgz> I don't understand bug 871386
<ubot5> Launchpad bug 871386 in Bazaar "recipe fails to build" [Undecided,Incomplete] https://launchpad.net/bugs/871386
<mgz> last two lines of traceback make it look like a non-ascii symlink, but I can't actually find one in the branch
<mgz> so maybe it's a bzr-git or submodules or something else problem
<hakermania> Hey, how do I tell lp that I changed version and I'm now developing the 2.2 one and not the 2.1 for example?
<hakermania> And then, in the project page in lp, in the place of the trunk there will be another dot, saying 2.2.... I can't figure it out :P
<jam> hakermania: you want to create a new series, I think
<vila> poolie: you're PP this week ;)
<hakermania> jam, How will I?
<jam> hakermania: what's the project? I'll try to give you URLs
<hakermania> jam, https://launchpad.net/wallpaper-changer Thanks!
<jam> hakermania: if you go to that page, and look at the timeline, underneath it should be a "Register a series"
<jam> The direct link would be: https://launchpad.net/wallpaper-changer/+add-series
<poolie> thanks vila
<vila> poolie: there are still a couple of reviews I should finish, already on it
<hakermania> jam, well, and now I'll give it the same name and info but next version number?
<vila> reminder for packagers and installer builders: 2.5b2 has been frozen !!
<poolie> well, i did a decent number of reviews so far today
<vila> poolie: haven't checked my mail yet
<vila> or rather, all of my mail ;)
<poolie> but thanks for the review
<poolie> s//reminder
<Riddell> morning
<mgz> morning Riddell!
<poolie> good morning riddell, mgz
<vila> Riddell: hey
<vila> jam: I thought you targeted bzr.dev but your proposal for request retry are against 2.1 ?
<vila> proposalS even
<jam> vila: everything is currently targetted to 2.1 because that will give clean diffs
<jam> I don't plan on landing that before updating it to target bzr.dev
<vila> ha, thanks for confirming
<vila> we can't land anything currently anyway
<poolie> jam, eliz just wrote about bzr pulls from savannah timing out after an hour
<poolie> could there be anything in bzr related to that?
<jam> poolie: I'm pretty sure savannah said that they explicitly timeout the inetd stuff at 1 hour
<jam> I could be wrong
<jam> but I remember in the bug discussion that savannah was unhappy about idle connections
<jam> because they wanted to limit to something like 40 active conns
<jam> vila: 6202 Patch Queue Manager       2011-10-06 [merge]
<jam> Is the last merge I've seen
<jam> so nothing in trunk since friday
<vila> yup
<vila> mgz fights with one submission but ended up with an error even with all tests passing
<hakermania> jam, sorry for saying it again, but you may not notice, don't know. I asked you whether in the new series registration I set the same name and info and change only the version :)
<jam> hakermania: I didn't see it ealier, just a sec
<jam> hakermania: name is the name of the series, so in your case, I think you want "2.2"
<jam> summary can be whatever you want, it is meant to describe the series
<jam> and 'branch' is whatever branch you want to be the 2.2 series branch.
<jam> this may just be your development branch
<jam> but you may have a separate release branch
<jam> the way *bzr* does it, is that we have 'trunk' where active development is done
<jam> which then gets periodically snapshotted into a stable branch
<poolie> Riddell: hi, shall we have a chat?
<mgz> do you want me to reopen your email rt then vila on the basis that might have borked pqm?
<Riddell> poolie: ok, mumble?
<poolie> sip?
<Riddell> sip doesn't like me :(
<vila> mgz: I tried to re-open but I don't have enough rights :-/
<mgz> ...maybe just file a new one?
<vila> mgz: addind your data there and adding you as a CC should still be possibl
<vila> e
<jam> mgz: it is still funny to see your full name :)
<vila> I'm tracking mthaddon in #launchpad-ops anyway, you can job the chase if you want ;)
<mgz> ehehe, yes jam I'm still adjusting to it myself
<jam> not used to seeing your own name?
<mgz> ...it showing up in commit messages, not the name itself, I've had long enough with it now.
<jam> :)
<hakermania> jam, that's weird, I don't remember where I set the revisions to go to the '2.1' release, and even when I click on the 'Change Details' of the current trunk in the 'Name:' field I had set 'trunk', and not 2.1 o.O
<jam> hakermania: you are looking for 'development focus' ?
<vila> mgz: mthaddon is there, join us
<hakermania> jam, what do you mean? I am just using bzr and lp's trunk system so as to update online the developing  unstable code, so I assume we are saying the same thing.
<jam> hakermania: I guess I don't understand your statement: " I don't remember where I set the revisions to go to the '2.1' release"
<hakermania> jam, when I started uploading the development focus I should have somewhere set the release to be 2.1, lp could not know by itself. And I haven't set it as the 'Name:' of the series as you suggest me to set it (for the 2.2 version). In the 2.1 version in the 'Name:' field I've set 'trunk' and not 2.1 so I assume there's another way to set the version.
<vila> poolie: to start with, I'll focus on getting numbers for the past month[s] , I'll look at getting these numbers produced in real time once I get a better idea about how it was worked until now
<vila> poolie: we have something like ~60GB of logs to play with (or ~300MG if we look at the driver's log only, but they start mentioning the success only recently)
<jam> hakermania: there are also "milestones" which is a single snapshot of a release series
<hakermania> jam, let me try some things.
<hakermania> jam, please go here: https://launchpad.net/wallpaper-changer and see what is created by creating a new series: https://launchpad.net/wallpaper-changer I actually want this ->https://launchpad.net/sni-qt/trunk
<poolie> vila, 'to start with' towards counting successes?
<vila> poolie: yes
<vila> poolie: and getting some idea about the rythm
<jam> hakermania: then what you want is to go to: https://launchpad.net/wallpaper-changer/trunk and find the "Create milestone" or "Create release" links
<jam> about the middle of the page
<hakermania> cool
<jam> you can delete the series
<jam> hakermania: note we do both in bzr: https://launchpad.net/bzr/+series
<jam> we have a stable *series* of releases
<hakermania> jam, i see, what's the difference of a milestone and a release? What's a milestone?
<poolie> a milestone that has been released has a release
<poolie> a milestone that's in the future is just a milestone
<hakermania> poolie, o.O
<mgz> hm, that wasn't the best worded commit message ever, sorry jelmer.
<vila> poolie: raw numners: http://paste.ubuntu.com/705308/ except for some spikes it's ~200/day
<vila> numbers
<jam> hakermania: a milestone is a projected future release
<jam> "I will release 2.3 in February next year"
<hakermania> Oh, that's what I need :D
<jam> and these are the bugs I want to fix in it, etc.
<hakermania> jam, thanks, you are very helpful, now how do I get bzr to upload revisions to this milestone and not to the previous one? Will it automatically?
<jam> hakermania: *bzr* pushes revisions to trunk
<hakermania> jam, which means :O?
<jam> you never push revisions to milestones
<jam> and you weren't doing it before
<vila> hakermania: milestones are attached to a series, each series has an associated branch, it could be the same one for all series, but if you want to maintain separate series, you'll define different branches
<jam> so I'm not sure what you want it to be doing
<hakermania> jam, vila, thanks for the info, what a basically want to achieve is to have online the developing code of the next release!
<hakermania> What's the right way to do it?
<jam> right, you'll generally just push stuff to 'trunk', and then mark releases from there from time to time
<hakermania> how do I "mark releases from there from time to time"
<hakermania> ?
<vila> hakermania: on the milestones only
<jml> In lp:udd, does AllQueue.next_job loop on packages forever?
<jml> I'm guessing not, but I can't quite tell
<hakermania> vila, Ok, so, now I will continue pushing the developing code. Sometime this code will be stable and I will be ready for the next release. I will create a milestone then giving it the name of the release (2.2)?
<__bsm__> Hi to all, I have one user question. Using bzr 2.4 on Win xP, issue is that I cannot diff ps1 file (windows powershell) because bzr cosinder it as binary
<__bsm__> Any suggestions how to tell bzr it is text file?
<vila> hakermania: yup, you get the idea
<hakermania> vila, jam, thanks for the help, I have to keep these info somewhere now because till the release I'll forget :P
<vila> hakermania: hehe, the trick I use for bzr itself, is to create milestones ahead of time with rough estimate dates
<TimMiao> hi there, I just installed the bzr 2.4.1 on my macbook air, would anyone please tell me how could I can remove it from system? thank you in advance!
<vila> hakermania: as the expected release date approaches, I refine the dates
<poolie> TimMiao: how did you install it?
<vila> hakermania: also the https://launchpad.net/bzr/+milestones page is a rough planning that helps me keeping track of what is coming
<TimMiao> poolie: I downloaded from bzr website, mount the downloaded file, and then double click the .mpkg file, follow the wizard to finish the installation.
<TimMiao> poolie: now I can't see the installed bzr in Application folder, and I don't know how to remove it from system
<hakermania> vila, I thought that you create the milestone only when the release is ready.  So, can you create a milestone, set an 'expected date' and when the release is ready to set the milestone to 'released' or something?
<hakermania> vila, and 'released' goes to? PPAs?
<vila> hakermania: yup, you can't release without a milestone but you can create the milestone ahead of time
<vila> hakermania: out of scope
<vila> hakermania: what a release allow you to produce is project specific
<__bsm__> I changed file assoc in Win to notepad.exe, still bzr does not treat it as text file
<hakermania> vila, :P But 'released' means that a new version is available. Is it up to me the 'where'?
<vila> hakermania: yes
<vila> hakermania: for bzr, for example, once the release is created, I upload the source tarball
<poolie> TimMiao: sorry i don't know much about macs
<vila> hakermania: I then tell the packagers and installer builders to go ahead from there
<poolie> is there no system uninstall facility?
<poolie> suggest you search for the 'bzr' executable and 'bzrlib' directory
<TimMiao> poolie: thank you
<hakermania> vila, how do you get someone to build the package for you? I do all the job myself :P
<vila> hakermania: hehe, we have some really fine people around ;)
<vila> hakermania: if you look at https://launchpad.net/bzr/2.5/2.5b2 (our latest release to date)
<vila> hakermania: you'll see the tarball and the windows installers
<vila> hakermania: I uploaded the tarball last Thursday, jam uploaded the windows installers a couple of hours ago
<vila> hakermania: the mac installer will probably follow
<hakermania> vila, I see.
<vila> hakermania: as for the packages themselves, they may not be tracked on this page, but they will refer to 2.5b2 and may use the tarball uploaded there
<vila> hakermania: the release stuff here is really targeted at upstream releases
<hakermania> vila, so it's up to cooperation
<vila> hmm, well, that's not true, but I think it's easier for you to think about it this way to start with
<vila> hakermania: yup, that's what lp is good at, helping people collaborate around projects
<vila> hakermania: https://code.launchpad.net/bzr may help you get the picture for bzr too (which branches are associated with which series)
<hakermania> vila, what I do is build/fix the code, push it now and then, when something has been accomplished, make a new release, send the code to lp to make the PPAs, I get from there the DEBs and I put them to sourceforge, I then update everywhere the links (site, forum signatures etc) and then I (will) send the package to REVU for inclusion to 12.04 :P Too much to do :/
<poolie> night all
<vila> hakermania: you're 'purple' ? It's hard to keep context with all you nicks ;)
<vila> s/you/your/
<vila> bah, the second one
<hakermania> vila, puple? what? I'm hakermania
<hakermania> Do you see me as 'purple'?
<vila> hakermania: that's your real name reported by xchat
<hakermania> weird, I've registered this nickname(hakermania), from now on consider purple==hakermania = true
<vila> hakermania: may be just a coincidence... but I seem to remember a pur... ok
<vila> so, for "to lp to make the PPAs, I get from there the DEBs and I put them to sourceforge", why don't you just tell your users to use the PPA ?
<vila> hakermania: and the PPA may be able to use recipes so the builds occur automatically
<vila> hakermania: you also define different PPAs for daily, beta and stable and have different policies to populate them
<vila> s/you also/you can also/
<vila> or may :)
<hakermania> vila, because there are far too many unexperienced users out there, imagine that there are folks out there that don't know whether they have gnome 2 or 3. We had too many emails saying the program's not working while they actually used the wrong version (gnome 2 instead of 3 or vice versa). Also, I use PPAs only for stable releases. Oh, and also in the site I put the sourceforge's links because there package seems more well-organized.
<hakermania> Every version has its own folder, its own readme file, it's good.
<vila> hakermania: your call, just mentioning ;)
<hakermania> vila, Does it look good: https://launchpad.net/wallpaper-changer/trunk ? After the code's stable I release the milestone? ALl OK?
<hakermania> I'm anxious about it a little bit :/
<vila> hehe, I know the feeling :) Yeah, it looks ok (but since I have to write access here, the display is slightly different)
<__bsm__>  I have one user question. Using bzr 2.4
<__bsm__>                 on Win xP, issue is that I cannot diff ps1 file
<__bsm__>                 (windows powershell) because bzr cosinder it as
<__bsm__>                 binary, any suggestions?
<vila> hakermania: you probably have a (+) Release now button for 2.2 that I don't see myself
<hakermania> vila, I do
<vila> hakermania: you're all good then I think
<vila> __bsm__: what encoding is used for this file ? utf-16 is not handled as text so far in bzr, if you don't need it, try utf-8 instead
<__bsm__> vila, thanks, I will check now
<hakermania> vila, nice, but when the new release is out, will I just continue to push the code simply? Maybe I will create a new milestone for the next release :)? Am I right? And when I "(+) Release now" the milestone will this be shown on the 'overview' page of the project? Sorry for the so many questions, I just want to be sure. And thanks.
<vila> hakermania: yup to all :)
<hakermania> vila, perfect
<vila> hakermania: you probably want to *tag* your release too
<hakermania> vila, what's this :P
<vila> hakermania: as there is no other explicit way to find the revision corresponding to a milestone that I know of
<vila> hakermania: bzr tag wallpaper-changer (bzr help tag, bzr help tags for details)
<jml> hmm.
<jml> has anyone run "branch_branches_from_lp" in a while?
<jml> because it looks broken in trun
<jml> k
<hakermania> vila, oh yes, that would be nice.
<vila> hakermania: ghaa, 'bzr tag wallch-2.2' or something
<hakermania> vila, do I run this before the last push that corresponds to the new release?
<vila> hakermania: exactly
<vila> hakermania: or not
<vila> hakermania: you tag an older revision
<hakermania> vila, so first I push the code, then tag it...
<vila> hakermania: you *can* tag an older revision
<vila> hakermania: no, it's better to tag it first
<vila> hakermania: but if you forget, you can catch up
<__bsm__> vila, encoding was UCS-2 Big Endian, I converted it to UTF-8, committed two revisions, and diff now works, thank you,
<__bsm__> i cannot compare to prefious commits, but it will work for future
<vila> jml: sorry, where is this function ?
<hakermania> vila, I don't get you. *Tagging* is a way to show which revisions is for which version. Ok, so, let's say I have a rather stable code now, and I push it to create the next revision. After the push, I tag it to show that this revision is the last one for the version 2.2. Or not :P ?
<jml> vila: it's a script.
<jml> vila: in the top-level
<vila> jml: of ? udd ? lp ? bzr ?
<jml> vila: I'm just doing a branch now that moves the code out of those scripts into udd/scripts/
<jml> vila: of udd, sorry
<vila> ha
<vila> jml: rings no bell as you can see :) Let me have a look
<jml> vila: basically, it says distribution_name in a function where it should say distribution.name
<jml> vila: but comments say the script is used mostly for debugging
<vila> the initial comment says "debug purposes"
<jml> yeah.
<jml> I'm guessing james_w hasn't needed to debug stuff for a while :)
<vila> jml: qblame says maxb only, may suffer from bitrot :)
<jml> yeah.
<vila> the script, not max
<jml> heh heh
<idnar> heh
<jml> vila: do we have Python 2.5 on udd production?
<vila> jml: in addition to 2.6.5 you mean ?
<jml> vila: what I really mean is, 'can I use "with"?'
<vila> jml: yes, I even have a wip to use wip replacing all the try commit/except rollback/finally close for the db cursors
<vila> s/use wip/use with/
<jml> vila: oh cool.
<jml> vila: I was thinking of doing the same thing
<vila> jml: :) I'd like to add the smallest set of tests I can find to go with it
<jml> vila: oh
<jml> vila: that's a drag.
<vila> jml: the other ~related point is to use name tuples or something for the rows, but one step at a time
<mgz> vila: did you get mail about the landing on 2.4 from PQM? at least the merge worked.
<jml> vila: yeah.
<vila> mgz: not checked yet, but babune is busy
<mgz> the big problem is fixed at least, so that's fine
<vila> checked, got a bazaar-commit mail from pqm \o/
<mgz> okay, so the rt really can be closed now, good good.
<mgz> and we'll have a happy fullermd as a side effect.
 * vila nods
<vila> and an additional heartbeat
<vila> mgz: so you changed your mind about test = self ?? It *was* a class attribute
<vila> mgz: or would you have preferred an __init__ attribute (which unfortunately cannot be done) ?
<fullermd> The world is better for everyone when fullermd is happy.
<fullermd> Well, for me anyway.  Which is close enough to "everyone" as far as I'm concerned...
<mgz> vila: I thought self.overrideAttr(InnerClass, "testcase", self) was the best option I think
<mgz> given you couldn't put it on the instance
<vila> ha ! That one.
<vila> hmm, a bit weird to use overrideAttr for a class that is embedded in the test itself though
<mgz> it keeps a scoping a little clearer, and avoids test->class->test->...
<vila> I don't get it, it needs to be done after the class declaration so is less clear than inside of it as testcase = self
<vila> or is it that it will help your cycle detection stuff ?
<mgz> yep, you need the gc to clean up the test if you leave a copy of self on an inner class
<vila> mgz: bah, doesn't work: AttributeError: class FailingDuringResponseHandler has no attribute 'testcase'
<vila> so we need testcase = None in addition...
<mgz> meh, that's an annoyance of overrideAttr we should fix
<mgz> but I wouldn't worry about changing that now vila
<mgz> I can poke this stuff after it's on 2.5 with the tests actually being cleaned up properly
 * vila nods
<jml> vila: udd cleanup branch up at https://code.launchpad.net/~jml/udd/clean-up-scripts/+merge/78816
<vila> jml: not really reviewed but I have some questions
<jml> of course
<vila> jml: I posted them, but we can discuss here,
<jml> vila: ok. I'll pull up the page.
<vila> jml: the most annoying bit is having the same name in both places and different parts of the whole importer referring to different paths
<jml> vila: sorry, I don't quite understand
<vila> jml: I understand (and value !) the desire to make them easier to test but the added scripts seem to be... a bit empty for no good reason
<vila> jml: which part ?
<jml> vila: they aren't empty. I've mostly bzr moved the things out of the tree into a package
<jml> vila: and then created near-empty scripts that call them
<jml> oh, maybe that's what you meant
<vila> yes
<vila> the mostly empty ones are... why do we need them ?
<jml> vila: well, it's either that or use entry points and buildout
<vila> buildout ?
<jml> vila: you need something to execute
<jml> vila: executing python scripts that are inside packages is yuck.
<vila> ha
<vila> oh
<jml> vila: I was thinking in a separate branch that the scripts in top-level right now could be moved into bin/ and renamed to be a little nicer.
<vila> but I've seen many packages (may be not many, but some) using the __name__ == main idiom to know they are run as a script while still allowing import
<jml> vila: but I don't want to change the interface in this branch
<jml> vila: yeah, but no one likes using them
<vila> oh
<jml> vila: e.g. 'python -m testtools.run <foo>'
<jml> *blech*
<vila> hmm, the one I had in mind was... unittest ?
<jml> vila: yeah, it's the same
<jml> vila: these things are scripts, the public interface should look like any executable
<vila> hmm
<jml> vila: the advantage of having very small executable Python scripts is that you don't have to test them.
<vila> different names for the scripts then may be, but the other trend was to move the basic functions out of the scripts anyway
<jml> vila: and also, if we want to merge some of the Python modules, we can
<vila> right
<jml> move code out of udd.scripts.list_packages into udd.icommon for instance
<jml> this is, in some ways, an intermediate refactoring.
<vila> intermediate step then but both trends go in the same direction
<vila> hehe, yeah
<jml> yeah.
<vila> oh right
<vila> then the logic becomes clearer but they don't deserve to go under udd/scripts then, they should just go under udd
<jml> vila: also, I still largely believe that this document is right: http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html
<jml> vila: well...
<vila> ha, let me read that
<jml> vila: I guess so. Some of them are very scripty.
<vila> it (the url) says don't give a '.py' to scripts, which I agree with
<vila> can be done separately but we may need a TODO to keep track
<vila> bah, and the REAME is bit-rotting too
<jml> yeah.
<jml> We can file bugs, or I can just do the *.py thing right now.
<jml> But I don't want to do that before this branch lands.
<vila> jml: my BIGGEST issue is that these changes are not testable, not even as smoke tests (but I'm not blaming anybody here, just explaining my lack of enthusiasm ;)
<jml> vila: ah yes.
<jml> vila: well, of course, the thing is that the old code wasn't testable either.
 * vila nods
<vila> but I said anybody :)
<jml> vila: making a change like this is necessary to making them testable
<vila> this stuff works, not the same as testable, but still a valuable kind of test
<jml> vila: and even if, say, I added a bunch of tests, we wouldn't be guaranteeing against regressions
<jml> because I'd just be making up what I thought the behaviour should be :)
<vila> it will help yes, I agree, my issue is how can I safely accept this
<jml> hmm.
<vila> hehe
<jml> Well, we could run the scripts.
<jml> If you have a staging environment, we could try that
<vila> bah, not even, the only staging (local) one I have cannot write to lp (or chaos is around the corner)
<jml> Hmm.
<jml> Well, I don't see how you can safely accept *any* change then.
<vila> oh
<vila> that's because you don't see the goats
<jml> vila: heh
<vila> jml: more seriously, did you run them locally, which ones ?
<jml> vila: no, I haven't yet.
<jml> vila: the changes are self-evidently correct :P
<jml> (I'll run them now)
<jml> except, ugh, I'm *still* part-way through my database run.
<vila> jml: can you do that, tell me the ones you didn't and I'll aprove, land, deploy and see what breaks
<vila> argh
<vila> jml: my rough estimates for the importer is that it takes 36 hours before starting again
<vila> jml: depending on what you really do as an import, this could of course be far shorter
<jml> vila: does it just loop forever?
<vila> mass_import ? Yes !
<jml> vila: as in, it goes through all packages again once it's done?
<vila> it runs unattended
<vila> yes
<jml> vila: I thought it needed constant fuelling from new cronjob runs.
<vila> for new packages I think it's still needed, but the corresponding job updates the db and mass_import query it (IIUC)
<vila> hmm
<vila> looking at one of your scripts, importing 'main' ? Why not a more descriptive name ?
<jml> Because it *is* descriptive?
<vila> main ? For a script yes, but if we intend to merge this script-wanting-to-be-part-of-packages, less
<jml> then we can rename it when we do that merging?
<vila> fair enough ;)
<jml> We could have a module called builtins and change all of the scripts to be cmd_foo and then rename main to run() if you'd like :)
<vila> oh
<vila> I thought about making the importer a bzr plugin if you really want to know ;)
<jml> vila: yeah, I thought about it too
<jml> vila: but then I realized you'd need sub-sub-commands.
<vila> there was too much stuff in the scripts to tackle it safely though ;)
<vila> for what ?
<jml> vila: bzr udd list-packages
<jml> I guess you could just have a prefix or something
<vila> oh, I thought about bzr list-packages directly, it's not as if this will be distributed widely
<vila> but it could also be udd-list-packages, there is not much to share into the udd command
<vila> not use
<vila> nor use
<jml> vila: I guess so.
<vila> jml: but jokes aside, why not make a builtin.py and indeed rename the mains into cmd_xxx ?
<vila> jml: not making it a plugin doesn't mean we can't use some naming conventions ahead of time
<vila> so many negatives >-/
<jml> vila: mostly because that's more work
<jml> vila: and it's the same naming structure
<vila> that's an honest answer, I like that ;)
<jml> udd.scripts -> udd.builtins; module_name -> cmd_module_name; main -> run
<vila> not even the run part for now
<jml> With the bonus of having to disentangle naming clashes from the existing scpts.
<jml> scripts.
<vila> keep the separate modules
<vila> bah, don't answer
<vila> no, I understand
<vila> but a TODO explaining the road ahead still sounds easy and valuable
<jml> OK. I'll do that.
<vila> great
<vila> let me know when you managed to run them locally as smoke tests and which ones are left to test,
<vila> from there I can land.deploy and be ready
<jml> Thanks.
<vila> jml: and when you have time, a private discussion about what you're doing in *your* pkgimport.import_script will probably help me help you ;)
<jml> vila: oh, it doesn't have to be private
<jml> vila: I'm downloading source packages and extracting the *.symbols files from them
<vila> and you upload nothing ?
<jml> vila: no. It's for maintaining a database locally.
<vila> jml: to know when you've processed all packages, search for "All packages requeued, start again" in your logs/driver/progress_log file
<vila> jml: it's in AllQueue in mass_import
<jml> vila: thanks.
<vila> jml: if you want to make it faster, you can raise the number of threads (default to 8), beware of bug #724893 though (unless you already ran into something like that)
<ubot5> Launchpad bug 724893 in Ubuntu Distributed Development "concurrent db access are not handled" [Medium,Confirmed] https://launchpad.net/bugs/724893
<jml> vila: lifeless warned me against that.
<Riddell> mgz: unicode question, why does the str one seem to give utf8 bytes while the unicode one gives latin-1 bytes? http://paste.kde.org/132169/
 * mgz looks
<mgz> that's an optical illusion
<mgz> in the str case, it gives whatever bytes your terminal gave it, which is utf-8
<mgz> in the unicode case, it decodes those bytes to a unicode characters, of 2 or 4 bytes each depending on the platform
<mgz> however, the python 2 repr only prints ascii for both str and unicode
<mgz> and the escape sequence \xa3 is just a shorter way of saying \u00a3
<mgz> so, u'a\xa3a' is really a 3 character * 4 byte value
<mgz> and 'a\xc2\xa3a' is a 4 character * 1 byte value
<Riddell> ah, so unicode repr being different from str repr is what I was missing
<Riddell> unicode, always strangely more complex than you think :)
<mgz> I've got a bunch of hacks I use when working with text in a python repr
<mgz> to save this kind of confusion when looking at reprs
<mgz> ^*repl
<mgz> Python 3 has a repr that doesn't backslash escape printable unicode characters, and as of 3.3 even mostly works correctly
<mgz> then you get into other kinds of unicode hot water though :)
<Riddell> whee
<daveb_> so, how can I merge, just a subset of commits?
<daveb_> and then merge the rest later?
<hakermania> vila, heh, im back from the 6-hours-lesson I had -_- I'd stack to what *tagging* is...remember?
<lifeless> wgz: hi
<lifeless> wgz: btw check out testresources.FixtureResource
<lifeless> wgz: its the shim I was talking about
<pfsmorigo> hi, how do I revert all changes in a directory locally?
<nigelb> bzr revert
<pfsmorigo> nigelb: gives me error: bzr: ERROR: Cannot lock LockDir(http://bzr.savannah.gnu.org/r/grub/trunk/grub/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<nigelb> That's beyond wat[B
<nigelb> pfsmorigo: That's beyond what I know :)
<theDUBBER> www.thedubber.altervista.org
<poolie> hi jelmer, hi all
<Riddell> morning poolie
<poolie> hi
<jelmer> hi Riddell, poolie
<poolie> hi jelmer
<poolie> jelmer if you get a chance can you try to get the hardy buildd backports done?
<poolie> (if you didn't already)
<poolie> not necessarily tonight :)
<jelmer> poolie: I started with it, but it's not trivial since bzr-builder relies on current quilt
<jelmer> I'm hoping to upload a new package tomorrow
<poolie> hm
<poolie> quilt's only a build dependency?
<jelmer> for bzr, yes
<poolie> hm
<jelmer> but bzr-builder uses it at run-time
<poolie> ah
<poolie> perhaps we should just backport quilt?
<jelmer> There's already an up to date bzr in the canonical-bazaar/cat-proposed PPA
<poolie> is it controversial only because it would have to go into cat for everything?
<poolie> maybe we could have a separate ppa for this?
<jelmer> poolie: That's what I did earlier, but lamont prefers to not introduce a new quilt as it might break other stuff
<poolie> would putting it in a buildd-specific ppa reduce that risk sufficiently?
<jelmer> poolie: I'm not sure, from my experience it's very hard to get stuff changed on the buildds
<poolie> yeah so it seems
<poolie> obviously we have to be careful but otoh this is blocking at least some users at present
<jelmer> so I think just fixing bzr-builder to work with an older quilt would be a lot quicker
<poolie> ok, so it's feasible but just not trivial?
<jelmer> yep
 * fullermd frowns.
<fullermd> When did -x stop working?
<poolie> seems to have worked for you there :)
<fullermd> Oh, I see.  It works, it just lies its butt off about what it's doing.  That seems...  suboptimal.
<Noldorin> hi jelmer
<poolie> for which command?
<Noldorin> jelmer, not going to pester you about bzr-git today heh...just had a quick question :-)
<fullermd> ci
<jelmer> hi Noldorin
<Noldorin> jelmer, does git have an equivalent to bzr's lightweight checkouts?
<fullermd> Mmm.  bug 268135 and bug 552805 at least...
<ubot5> Launchpad bug 268135 in Bazaar "bzr commit -x doesn't change the --show-diff output (iter_changes does not support excludes)" [Medium,Confirmed] https://launchpad.net/bugs/268135
<ubot5> Launchpad bug 552805 in Bazaar "Commit message template does not exclude files" [Medium,Confirmed] https://launchpad.net/bugs/552805
<fullermd> Well, it's only 3+ years old anyway...
#bzr 2011-10-11
<fullermd> Noldorin: I have vague memories that say it has an env variable you can use to point at an object store elsewhere at least...
<jelmer> Noldorin: somewhat
<Noldorin> fullermd, hrmm. sounds hacky
<Noldorin> basically i just don't want to pull all the RCS crud.
<jelmer> Noldorin: you can create a tree in a different location and then set an environment variable
<fullermd> Noldorin: Well, you did say "git", didncha?   ;>
<Noldorin> fullermd, fair point ;-)
<jelmer> Noldorin: yeah, as fullermd says
<Noldorin> would it let me avoid pulling all the branch data?
<fullermd> I expect it only works on local disk.
<achiang> hello, is there a way to get the diff of my tree, starting from -r -1 to the current dirty state?
<fullermd> (well, mounted filesystem anyway.  A little NFS across the internet never hurt anybody...)
<fullermd> achiang: Wouldn't that just be 'bzr diff'?
<jelmer> Noldorin: it doesn't work for remote repositories
<Noldorin> jelmer, fullermd ah, so i thought. oh well to that idea then.... thanks anyway :-)
<achiang> fullermd: hm, i didn't explain myself... i fixed something in -r -1 based on a review comment, but pretty much rewrote the commit at the top of the tree. I want to show what the diff would look like if i never committed -1 at all...
<achiang> so i want -r -2 to current state, i think
<fullermd> Do you mean "if I hadn't run 'ci' with what's in -r-1" or "if I'd not made the changes in -r-1"?
<fullermd> The former would be -r-2.  The latter would be...   uh...   magic.
<wgrant> achiang: 'bzr diff -r-2..' will show you the combined differences.
<achiang> well, asked another way, i want the output that loggerhead might show you if you submitted an MP consisting of 2 commits that modified the same section of source
<wgrant> "diff -r -2.."
<fullermd> No, "-r-2.." is equivalent to "-r-2..-1".  You want "-r-2".
<achiang> i tried bzr diff -r -2 (with a space)
<achiang> oops, i mean i tried bzr diff -r -2..
<achiang> i have uncommitted changes... any way to get those into the combined diff?
<fullermd> That's what "-r-2" does.
<fullermd> Though I imagine what the MP shows is actually more like a merge --preview from the other side, which may not correspond to that diff if there are other changes.
<achiang> fullermd: hm, it works now. i *thought* that is what i was typing, but i must have gotten it wrong
<achiang> thanks all
<vila> hi all !
<poolie> hi there vila
<mgz> morning all
<vila> poolie: hey, 1-on-1 ?
<vila> mgz: heya
<poolie> yes please
<jam> morning all
<jam> poolie, vila, mgz, Riddell, jelmer: standup?
<poolie> hi
<poolie> absolutely
<poolie> mumblicious?
<jam> i'm on
<jam> but I'm all alone
<jam> well, jelmer stopped by for a second :)
<jam> http://pad.ubuntu.com/RXCaDM4J3u
<poolie> Riddell: have a 'dulce et decorum' badge :)
<mgz> poolie: like jelmer asked earlier, what's the plan on 1-1s?
<mgz> I'd managed to miss a google calendar thing from you last week as well.
<poolie> jam, mgz, did you see http://people.mozilla.com/~tglek/lpc2011/ - you might like it
 * mgz looks
<poolie> wow especially: http://glandium.org/blog/?p=1764
<poolie> running a busy-loop in the background makes the benchmark faster
<poolie> (through not letting the cpu spin down)
<mwhudson> there was an SMP bug on ARM recently where running ping -f localhost made usb transfers go 10x faster
<mgz> hm, been seeing the updates going by on p.m.o but presentation is new to me
<lifeless> mwhudson: win
<mwhudson> lifeless: turns out assumptions along the lines of "this architecture will only ever be uniprocessor" are dangerous :-)
 * mwhudson puts the computer down
<nigelb> mwhudson: Really? o_O
<lifeless> mgz: did you see my ping about FixtureResource ?
<lifeless> mgz: http://bazaar.launchpad.net/~canonical-launchpad-branches/python-oops-amqp/trunk/view/head:/oops_amqp/tests/__init__.py#L83 - example of use
<mgz> lifeless: thanks
<lifeless> mgz: RabbitServer() is a Fixture. That declaration is using a resource
<lifeless> mgz: and you wrap the test suite in an OptimisingTestSuite(); done.
<mgz> where do I find rabbitfixture?
<mgz> also, I'd be very sad if I was a test given a resource called 'rabbit' and it wasn't an actual bunny
<lifeless> mgz: pypi rabbitfixture ;)
<mgz> woho! a fluffy friend... wait no... ;_;
<mgz> <http://pypi.python.org/pypi/rabbitfixture> is 404?
<lifeless> bwah. it should be
<lifeless> lp:rabbitfixture too, for sure
<mgz> lp will do.
<lifeless> (not that its code is particularly relevant
<lifeless> (its convoluted due to dealing with heinous erlang stuff)
<mgz> lifeless: I'm curious how reset is handled.
<mgz> the answer seems to be... it's not
<mgz> but actually there is quite a lot of interesting code in there
<lifeless> mgz: reset defaults to stop(); start()
<lifeless> mgz: doing a smarter one is an optimisation rather than a semantic facility
<mgz> right.
<mgz> but is also the whole point, in some respects
<lifeless> sure
<mgz> the way this uses TempDir and EnvrionmentalVariableFixture is enlightening too
<lifeless> :)
<lifeless> cool
<lifeless> mgz: is that a good thing ?
<mgz> understanding is always good
<lifeless> :>
<mgz> so the way useFixture is used there helps seperate concerns, but punts entirely on resource reusage
<lifeless> right
<lifeless> this is the Fixture-does-not-have-introspection-apis issue I was trying to explain
<lifeless> fixture is a neat easy api, but hard to do layers-of-resource-reuse with
<mgz> the filesystem is prepared seperately from the environment, and then a super-fixture inits and uses both
<lifeless> its totally easy to take the end result and wrap that as a Resource
<mgz> okay, and I can see how FixtureResource could be changed to split RabbitServerResources and RabbitServerRunner and have the latter depend on the former
<mgz> ...in fact, let me do that as an exercise
<lifeless> ah, thats where its tricky
<lifeless> because the optimiser runs before setUp
<lifeless> by definition
<lifeless> and because RabbitServer acquires its dependencies by calling useFixture(new object)
<lifeless> but please - have a fiddle :)
<mgz> okay, I see the problem
<lifeless> but that said, you can use the testresources contract with a fixture that expects it
<lifeless> testresources injects the dependencies as attributes
<lifeless> so a fixture which expects a self.config to exist before its setup and go after its cleaned up, will work fine in conjunction with testresources - but not standalone :)
<lifeless> so the handwaving plan is to expose a static, optional, graph api for fixture
<lifeless> which testresources can introspect and do its thing on, and which fixtures can bring up itself if its running standalone
<mgz> I don't see why fixtures shouldn't init other fixtures in their init
<mgz> is there a reason that might be a bad thing?
<lifeless> mgz: well, init != setUp
<mgz> right.
<lifeless> mgz: is 1230am; thats a good question, but I'm just barely managing to delete unneeded tests right now ;)
<lifeless> mgz: let me get back to you on it; see if I can page in m thoughts (if I had any prior ones)
 * mgz cuts lifeless some slack
<mgz> okay
<mgz> lifeless, mind if I just propose this to lp:python-oops-ampq so you can look at the diff at your leisure?
<lifeless> mgz: uhm yeah :) - 20 folk will get mail, and someone will review it
<mgz> ...maybe pastebin would be wiser
<lifeless> you could just push a branch up, no need for the proposal angle
<mgz> good plan
<mgz> okay, `bzr diff -r2..3 lp:~gz/python-oops-amqp/rabbitserverresource`
<mgz> I think that's correct, and should do bascially the same thing as the current formulation
<mgz> it doesn't seem very generalisable without defining a specific interface on top of fixtures though
<lifeless> I will look tomorrowish at it; 1am now, just winding down for halt()
<mgz> night :)
<deni> hi guys.... does bzr have something like git submodule?
<deni> anyone?
<briandealwis> deni: I've not actually used git submodule, but from what I vaguely understand, you might want to check out bzr-externals
<briandealwis> deni: there's a similar project called scmproj that has a different approach
<deni> briandealwis: tnx i'll check it out
<jelmer> maxb: hi
<maxb> hi
<jelmer> maxb: Is there a branch with the python-helper used in the daily PPA?
<maxb> there is
<maxb> somewhere.... :-)
 * maxb hunts
<maxb> https://code.launchpad.net/~maxb/ubuntu/maverick/python-backport-helper/ppa
<maxb> apparently
<maxb> Which surprises even me
<maxb> Suggestions of a better place welcome
<jelmer> maxb: Is it used by just bzr at this point? If so, would you mind having it owned by ~bzr?
<maxb> That's fine
<maxb> It's not used elsewhere
<maxb> (But having it under ubuntu/maverick isn't exactly helpful either)
<jelmer> yeah
<mgz> if I'm a plugin, how do I go about adding something to the library_state?
<jelmer> mgz: that's a good question
<mgz> it seems I can address it as bzrlib.global_state by the time I'm imported, but I don't know if that's the right way or not
<jelmer> maxb: and that's used by both lucid and maverick?
<maxb> yes
<poolie> hi maxb
<maxb> hello
#bzr 2011-10-12
* poolie 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: poolie
<poolie> hi vila?
<jam> morning all
<poolie> hi jam
<mgz> morning!
<poolie> hi gz
<AuroraBorealis> hiya
<poolie> hi AuroraBorealis
<mgz> AuroraBorealis: did you see the various bugs I filed on Sunday for the meliae issues you had?
<AuroraBorealis> i saw the email, were the links in that?
<mgz> I think I mentioned the bug numbers, was going to subscribe you to all of them but wasn't sure you'd want the bugspam
<AuroraBorealis> nah its fine
<AuroraBorealis> subscribe away~
<mgz> I will do so :)
<AuroraBorealis> and looking at that link you sent me for the win7 sdk
<AuroraBorealis> it seems to be for net framework 3.5 instead of 4
<AuroraBorealis> cause i reinstalled the other one i used and it did not give me the 64 bit libs
<mgz> hm, maybe it has to be the 3.5 one?
<mgz> you can probably just install that as well.
<mgz> I unticked the samples and doc options and it was only 400MB or so
<AuroraBorealis> yeah
<AuroraBorealis> i'm installing it
<AuroraBorealis> if this works, then chalk up another for "why i hate developing anything in windows"
<mgz> yeah, that was a very annoying diversion
<mgz> when you get that working, try `import random; from meliae.scanner import dump_all_referenced; with file("_random_module.json", "w") as f: dump_all_referenced(f, random._random)`
<mgz> as that was one of the objects that was a dead end in the dump you sent me and prevented it being loaded
<AuroraBorealis> ok
<AuroraBorealis> will work on it
<AuroraBorealis> fffuuuasdfjklasdfjklasdfjklsdfjklsdfjkl;sdfajk
<AuroraBorealis> Installation of the "Application Verifier" product has reported the following error: Fatal error during installation.
<mgz> heh. is that an optional component you can just not install?
<AuroraBorealis> lets see if it is
<jelmer> mgz: we'll need to tweak your fix for unicode changelogs in bzr-builddeb
<jelmer> mgz: python-debian's changelog is unicode in newer versions but bytestrings in older versions, it seems
<poolie> hi jelmer
<jelmer> hi poolie
<mgz> jelmer: ha. so, we do need ugly fallback code after all.
<mgz> I take it previously no encoding was specified in the rules at all, so there's no actual way of decoding them?
<jelmer> mgz: yep
<jelmer> mgz: though the convention is to have them in utf8
<mgz> okay, so potentially we can just do .decode('utf-8', 'replace') so we don't error out.
<mgz> or decode, catch the error, give a warning, and decode ascii-replace
<jelmer> mgz: I don't think we should do any replacement, we should just keep the existing text as is
<jelmer> mgz: and encode the commit message before appending it instead
<mgz> well, replace is an encoding. given random bytes, we need to do some kind of munging to get them in a bzr commit message.
<mgz> without a specified encoding it's a choice between: asking the user, guessing, or munging
<mgz> and as the rules now state that the file must be utf-8, getting people to fix their changelogs seems reasonable
<mgz> jelmer: is there a bug report, or have you just run across a changelog file that failed?
<jelmer> mgz: http://people.canonical.com/~jelmer/recipe-status/bzr.html
<mgz> thanks!
<mgz> hm, that ftb looks like a C locale thing, the test needs a requires UnicodeFilenameFeature
<mgz> ...though there are a bunch of other issues as well on lucid
<jelmer> mgz: succeeds on oneiric though
<jelmer> mgz: (otp with poolie)
<mgz> yup, I'll bug you after the call
<mgz> (I get a different error with LANG=C so I'm guessing the difference is the debian changelog package version, the older one is borked)
<quicksilver> On the rare occasions I have to rollback a merge, I find myself rewriting history because otherwise I won't be able to merge it again later when it's fixed
<quicksilver> is that right?
<jam> lifeless: are you around? I'm trying to use testscenarios with nosetests, and I'm getting a weird assertion error from nose
<jam> mgz: ^^ maybe you've played with testscenarios while you're playing with the other stuff?
<mgz> I have... but not nose.
<mgz> what's the traceback?
<jam> mgz: http://paste.ubuntu.com/706709/
<jam> well, full traceback, just a sec
<jam> http://paste.ubuntu.com/706711/
<jam> It looks like testscenarios is creating a new instance, and nose's ResultProxy is asserting that it has the same instance
<mgz> yes.
<mgz> that's exactly what it looks like.
<mgz> I don't see an easy way around that, you have to duplicate tests for scenarios
<jam> mgz: ResultProxy.assertMyTest has "The test I was called with must be my .test  or my .tests's .test, or my .test.test's .case"
<mgz> if you can arrange for the multiplication to happen before nose gets a sniff of the tests, that might work
<jam> Sounds like you can add the '.test' attribute
<mgz> that may be okay as a hack-around, if none of your tests already have a 'test' attribute
<jam> nope
<jam> at least my initial poke at it didn't work
<mgz> you'll need to write a test loader then I guess, so nose only sees the suite after the scenarios have been handled
<jam> yeah, looks like
<jam> mgz: do you know if nosetests supports the 'load_tests' api?
<jam> (not bzr's, but python's )
<jam> and does that work on py2.6... guess I'll have to keep trying
<mgz> it should, but that's a 2.7 change iirc
<jam> http://docs.python.org/library/unittest.html#load-tests-protocol
<jam> mgz: It looks like it calls 'load_tests' but it is assuming it is a test suite
<jam> and doesn't pass it any parameters
<jam> it just treats it as yet-another-test
<mgz> yeah, that's the 2.7 api change I think
<mgz> unittest implemented something slightly different from all the existing load_test type things that were floating around already
<jam> mgz: ugh, the whole reason to use nosetests was so i didn't have to write my own test loader...
<jam> well, test runner + loader + everything else
<jam> mgz: it looks like "python -m testtools.run discover" will work as long as you have py 2.7 or the 'discover' package available.
<mgz> yup, that sounds like a better bet
<mgz> testtools can also work without discover with minimal boilerplate
<mgz> basically import your modules in a test_suite function in __init__.py and use an existing TestLoader
<jam> mgz: of course, now I have to figure out how I went from 119 tests to 144 tests...
<mgz> more tests, that's a good thing! :)
<mgz> (because scenarios are working?)
<jam> mgz: I was using mixins before, and had 119 tests
<jam> I'm switching to scenarios for the same number of permutations
<jam> and "-v" for verbose doesn't actually do anything...
<jam> It might be scenarios doing it differently, because in the pre-scenario code 'py -m testtools.run discover' also gives 119
<jam> but without -v, I don't know *what* extra tests are running
<jam> :(
<jam> jml: poke about "testtools.run"
<jam> Is '-v' supposed to list the tests like unittest does?
<jml> jam: don't know, sorry.
<jam> because: py -m testtools.run discover -v
<jam> looks identical to without -v
<mgz> pretty sure testtools' TestResult doesn't have a verbosity concept
<mgz> would be nice if it did the same thing as bzrlib
<jam> mgz: the TestResult doesn't, the TestRunner does.
<jam> I've found the issue:
<jam> TestToolsTestRunner is a stand-in for unittest.runner.TextTestRunner
<jam> and TestToolsTestRunner doesn't support verbosity
<jam> of course, testtools code is actually broken because it accesses a "runner.TextTestRunner" variable, but never imports 'runner'...
<mgz> the runner only passes the verbosity param on to the result I believe
<mgz> but did you try --list instead?
<mgz> would tell you what tests you gained.
<jam> mgz: to make matters worse, it is also trying to pass other flags like 'buffer' and failfast
<jam> which aren't supported by py2.6's unittest.TextTestRunner
<jam> so this is the hackaround that works: $ py -c "import sys; from testtools import run; import unittest; prog = run.TestProgram(testRunner=unittest.TextTestRun
<jam> ner(verbosity=2), stdout=sys.stdout)" discover
<jam> mgz: '--list' takes an argument... ?
<jam> which is extra weird
<jam> as I don't see code actually requesting a value
<jam> and I can pass anything for the value
<mgz> jam: the discover version shouldn't..
<mgz> the non-discover version needs a suite name
<jam> mgz: http://paste.ubuntu.com/706758/
<jam> you tell that to my testtools
<mgz> it sounds like you have the potential of many bugs to file
<jam> or even: http://paste.ubuntu.com/706760/
<mgz> ...yup, I get the same with 2.7
<jam> mgz: yeah, the issue is they have OptParse
<jam> which defaults to taking an argument
<jam> unless you set "action=store_true" sort of thing
<jam> uhg
<jam> ugh
<jam> --list doesn't do scenario multiplication
<jam> because that is done in 'run()'
<mgz> >_<
<mgz> it works in bzr selftest...
<jam> I think that's 4 or 5 bugs
<jam> mgz: we don't use TestWithScenarios
<jam> we implemented it ourself.
<mgz> clearly bzr did it better.
<hrw> hi
<hrw> can someone help with 'bzr dailydeb'?
<jelmer> hrw, hi
<jelmer> hrw, sure, what about it?
<hrw> jelmer: is there a way to tell bzr to not try to update with lp? lp:gcc-linaro is huge repo so each attempt of 'bzr dailydeb recipe .' (where . == bzr copy of lp:gcc-linaro) takes ~1h of bzr work and then fail due to some bugs
<jelmer> hrw: if you run it inside of a shared repository it shouldn't have to fetch from Launchpad again each time
<jelmer> hrw, alternatively, you can specify /path/to/gcc-linaro rather than lp:gcc-linaro
<hrw> jelmer: local repo was fetched wth 'bzr pull lp:gcc-linaro' and thats all
<hrw> I am not a fan of bzr so my knowledge of when repo is 'shared repo' and when not == null
<jelmer> hrw: try "touch .bzr/repository/shared-storage"
<hrw> the 'Finding revisions' part of bzr is fun - takes several minutes on 1 commit branch
<mgz> jelmer: I've just proposed a bzr-builddeb change that should greenify my problem test from earlier
<jelmer> mgz, thanks, I'll have a look
<mgz> also, is touching a magic file really the best way? o_O
<mgz> I guess maybe using bzr reconfigure would be two commands
<mgz> okay, I'm about to push the testcase cleanup branch. watch out for falling chickens.
<hrw> Merging '/home/hrw/devel/canonical/2011-oneiric/ci/code-bzr/gcc-linaro/' in to './gcc-linaro-native-{{debupstream-base}}-{revno}-{revno:packaging}'.                  212kB     1kB/s \ Finding revisions
<hrw> where it is trying to find revisions? in 'ci/code-bzr/gcc-linaro' bzr branch?
<hrw> or in a branch to which it merges?
<jelmer_> mgz: still there
<jelmer_> mgz: ?
<jelmer_> mgz: With your patch, that test fails for me on oneiric
<jelmer_> mgz: I wonder if we should just open('debian/changelog', 'w').write("""...""") to make things simpler
<kirkland> does this error message look familiar?
<kirkland> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
<kirkland> for full python traceback, see https://launchpadlibrarian.net/82565565/cloud-init-output.log
<jelmer_> kirkland: you're interrupting a discussion about that very issue
<jelmer_> :)
<kirkland> jelmer_: :-)  is this affecting bzr in 11.10 in general?
<kirkland> jelmer_: if so, is there a bug i can link to?
<jelmer_> kirkland: it's an issue with bzr-builddeb automatically determining a commit message from a debian changelog message which contains non-ascii characters
<kirkland> Daviey: ^
<kirkland> jelmer_: is there a bug #?
<jelmer_> kirkland: lp:bzr-builddeb should have a fix, but that fix regressed on pre-oneiric
<jelmer_> kirkland: bug 853664
<ubot5> Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664
<kirkland> jelmer_: okay, so i think this is manifesting itself in a strange way for us...
<kirkland> jelmer_: are you familiar with etckeeper?
<kirkland> jelmer_: we're trying to install/use etckeeper on Ubuntu Orchestra installed servers, to maintain /etc in bzr automatically
<kirkland> jelmer: subsequent package installation is failing, as etckeeper is failing to commit some changes
<kirkland> jelmer_: digging through it, it looks to me like it's this bug
<jelmer_> oh, that'd be odd
<kirkland> jelmer_: can you have a look at that log and confirm?
<kirkland> jelmer_: see https://launchpadlibrarian.net/82565565/cloud-init-output.log
<jelmer_> kirkland: ok, that's definitely a different issue
<mgz> kirkland: sec, I'll link you to the right bug for that one
<jelmer_> kirkland: It seems like the file system encoding is not set to UTF-8, is that right?
<mgz> jelmer_: how annoying, there's some incomptabile change in debian.changelog then... but my version works with *both*
<jelmer_> mgz: there indeed is an incompatible change in debian.changelog..
<mgz> jelmer_: what's the traceback on oneiric?
<kirkland> jelmer_: I'm not sure -- how would i tell that?
<jelmer_> mgz: I've pasted it to the MP
<jelmer_> kirkland: is it supposed to be a standard Ubuntu system? If so, then the fsenc should be UTF8 (from the logs, it looks like it's not)
<jelmer_> kirkland: we use Python's sys.getfilesystemencoding() to determine the encoding, let me have a look at what Python uses
<mgz> kirkland: you want bug 715547
<ubot5> Launchpad bug 715547 in Bazaar ""bzr add" crashed: UnicodeDecodeError in smart_add with ascii codec" [Medium,Confirmed] https://launchpad.net/bugs/715547
<kirkland> mgz: ah, thanks.  that bug is a bit older
<mgz> particularly comment 7 there
<jelmer_> mgz: in this specific case the file system encoding isn't UTF8
<mgz> your problem is you're running without a locale that has a particular encoding set, but have filenames that aren't just ascii
<mgz> there's an etckeeper specific bug along the same lines.
<kirkland> mgz: how do i check my fsenc?
<jam> mgz: I think stuff like testtools and testscenarios was inspired by "look at all this neat stuff we have in 'bzr selftest', lets try to make it generic so other people can use it".
<jam> but since it isn't one unified code base, and it is trying to interoperate with unittest/nosetests/py.test, etc
<jam> and then there are the licensing issues
<jam> like bzrlib is gpl, but these should be BSD-ish
<jam> etc.
<jam> I know I tried to pull some of the progress bar stuff into (I think subunit), but robert was worried about the licensing clashes.
<mgz> jam: that's a good point.
<mgz> kirkland: what is calling the bzr commands that gave the output you pasted?
<mgz> kirkland: basically that needs to run in a defined locale, so with LANG/LC_ALL set to something appropriate
<jelmer_> mgz: 'python -c 'import sys; sys.getfilesystemencoding()'
<kirkland> mgz: do you think it would be sufficient in etckeeper itself to [ -n "$LANG" ] || LANG=en_US.UTF-8
<mgz> well, that'd work
<jelmer_> kirkland: aren't ubuntu systems supposed to be UTF8 by default?
<jelmer_> kirkland: as a workaround, setting LANG=en_US.UTF-8 should work but I think the core issue is elsewhere
<kirkland> jelmer: interactive shells -- yes
<kirkland> jelmer_: I suspect the problem is that these are non-interactive shells
<kirkland> jelmer_: one bug report is about cron, which runs with a *very* minimal env
<kirkland> jelmer_: the other one is juju, same thing
<mgz> I don't really see why there shouldn't be an encoding set even in those sorts of situations
<jelmer_> kirkland: even if it's non-interactive, Python should not return anything but UTF8 for the filesystem encoding
<mgz> LANG and LC_MESSAGES and such like I guess I can see if we pretend unix is still a multi-user system with accounts using different languages
<jelmer_> I can understand if it's something non-UTF8 for the terminal encoding
<mgz> jelmer_: it goes off the unix locale, which is all it has to work with
<jelmer_> mgz: but if the filesystem is always utf8 on Ubuntu, it should use that fact and always return utf-8
<mgz> posix doesn't give python a way of knowing that's what python wants.
<mgz> *ubuntu
<mgz> right, I need to go, I think I should be third time lucky on the builddeb mp
<jelmer_> mgz: why not? the choice has been made for Ubuntu that the fs is UTF8 AFAIK
<mgz> sure, but what should python do to tell that? I guess you could argue for a build-time patch.
<jelmer_> mgz: that's what I had in mind
<jelmer_> Python already hardcodes the fs encoding to mbcs for windows and utf8 for apple
<mgz> right, really is cake time now
<lifeless> jam: nosetests is pretty evil
<hrw> hi
<hrw> stupid(?) question: why it is taking so long when bzr is branching from local dir to other local dir? "cp -a" is faster then bzr
<james_w> bzr is also doing integrity checks
<hrw> james_w: ~400MB copy takes 5 minutes ;(
<hrw> but it is much faster then doing it with sources at launchpad - then it is 1h
<hrw> anyway - 13 minutes for 'bzr dailydeb' to generate source pacakge I consider fine enough. will do local tests and once it will work I will give it for launchpad to try
<hrw> have  anice rest of day
<poolie> hi all
<james_w> hi poolie
<poolie> hrw: maybe you should do 'bzr init-repo DIR' which will avoid copying when you branch inside that directory
<poolie> jelmer_, wgz, jam, emacs are seeing a connection drop exactly 1h after it started
<poolie> is there any way this could be connected to a timeout in bzr?
<mwhudson> there's an hour timeout in lp for idle connections
<poolie> done in twisted ssh?
<poolie> this is on savannah
<mwhudson> yeah
<mwhudson> ah ok
<poolie> in this case it's not idle - of course it might be getting detected as idle
<jelmer_> g'morning poolie, mwhudson
<jelmer_> poolie: has this always happened or after the deployment of a newer bzr on the server/client side?
<spiv> poolie: AFAIK there's no timeout like that in bzr
<poolie> hi jelmer, spiv
<poolie> they've only mentioned it recently
<poolie> "what changed" is always a good question
<mwhudson> maybe they're running the site being somelike like my old netgear router :-)
<mwhudson> *behind
<mwhudson> (long lived tcp connection?  what would you want one of *those* for?)
<poolie> with openfirmware, of course :)
<mwhudson> ah ture
#bzr 2011-10-13
<poolie> cinerama, https://bugs.launchpad.net/bzr/+bug/255687
<ubot5> Ubuntu bug 255687 in Bazaar "log and annotate should work on removed files" [Medium,Confirmed]
<wgz> still dark outside...
<AuroraBorealis> its dark outside here too!
<poolie> hi wgz
<poolie> beautiful day here
 * fullermd searches around to find a window, and discovers darkness there too....
<wgz> :)
<fullermd> It's like a giant plague, taking over!  It probably covers half the world by now   :(
<wgz> okay, nearly time for bus
<wgz> cow-orking today.
<poolie> oh great
<poolie> i'm out for a bit to play squash, probably back later
<jam> poolie: i think I mentioned earlier, but they put a 1hr inetd timeout on savannah, i believe.
<jam> I don't think it is from bzr, I think it is from their configuration.
<jam> morning all
<Pegasus_RPG_> Hello. I just wanted to find out what the best way of moving/copying a bzr checkout to another PC is?
<Pegasus_RPG_> (I'm on a slow Internet connection and don't want to have to check it out again)
<mgz> good morning.
<mgz> kirkland deserves some praise, fix up etckeeper in oneiric from yesterday
<poolie> hi mgz, jam
<poolie> jam, oh it kills it after an hour regardless?
<jam> poolie: I'd have to track down the original message, let me check
<jam> https://bugs.launchpad.net/bzr/+bug/824797
<ubot5> Ubuntu bug 824797 in Bazaar "bzr serve doesn't drop idle/dead connections" [High,Fix released]
<jam> I may have just been confused
<jam> because he closed the connection himself after 1 hour
<poolie> i think that's imapd, or maybe inetd, closing it
<cjwatson> hey, I'd like to have a working Debian dpkg import today for Ubuntu precise opening, and apparently it's blocked on bug 714622
<ubot5> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<cjwatson> I've deleted the 1.16.0~ubuntu8 tag from the natty branch, since AFAICS it doesn't correspond to anything that was ever accepted into the archive
<cjwatson> could somebody please requeue it and see if that's enough to fix this?
<poolie> hi cjwatson
<poolie> i'll do that now
<poolie> mgz: hi meet cjwatson
<mgz> hi cjwatson!
<cjwatson> heya
<poolie> cjwatson: do you mean 'an import of dpkg itself'?
<cjwatson> I mean package-import
<cjwatson> http://package-import.ubuntu.com/status/dpkg.html
<cjwatson> sorry for slow response, I'm doing Ubuntu 11.10 publishing
<poolie> it's running now
<poolie> btw multi-tarball inputs should be supported fairly soon
<poolie> cjwatson: it seems to be failing on
<poolie> AssertionError: ('steve.langasek@linaro.org-20110325000519-s1f74q0j9esmvs1s', '0d73da5a0af194cfc458d9ec624b6f42209f35f7') != (u'james.westby@ubuntu.com-20110324170447-1m0lwg8kvwt6yfli', u'c7a0e118cb0af317cf3e7af7874192fa4c405d0a') for dpkg 1.16.0~ubuntu6 in natty, something has changed
<poolie> could that be a similar problem?
<cjwatson> hmm
<cjwatson> ok, I'll have another look in a minute, worst case is deleting a tag likely to solve the problem?
<poolie> it seems possible
<cjwatson> hmm
<cjwatson> I don't see the latter revision id in either lp:ubuntu/dpkg or lp:ubuntu/natty/dpkg
<cjwatson> where might it be coming from?
<poolie> hm, let me see if i can work out more
<poolie> cjwatson: i'll try a full reimport
<cjwatson> poolie: um
<cjwatson> poolie: will that trash existing revision ids?  we are actually using lp:ubuntu/dpkg
<cjwatson> definitely don't want to lose that
<poolie> i killed it
<jam> cjwatson: the 'latter' revision_id is probably the one the package importer stores in its sql database tracking what has been imported.
<jam> It is the one that the importer had imported to match the given debian revision.
<jam> well, ubuntu revision, obviously :)
<jam> lifeless: you mention that nose is evil, do you have a recommended test runner?
<cjwatson> is it possible to excise that, or would that cause other problems?
<jam> cjwatson: it is possible, though I don't specifically know a way that isn't hacking the sql database directly.
<jam> lifeless: I'm trying "py -m testtools.run" but it is a bit wonky
<jam> like '-v' for verbose doesn't do anything, etc.
<poolie> i think we do need to excise them, and that would be a good fix for this
<lifeless> jam: I usually use testr
<poolie> cjwatson: i need to go and get S from uni in a bit, but jelmer and mgz will be here soon and may be able to fix it
<lifeless> jam: which builds on py -m subunit.run
<lifeless> (which extends testtools.run)
<poolie> or maybe maxb?
<cjwatson> ok, thanks
<maxb> I can look at it at lunchtime
<maxb> (London lunchtime, that is)
<poolie> thanks
<mgz> cool, I'm not sure which bits to poke with package stuff yet
<poolie> maybe max can tell you about it
<poolie> night all
<mgz> night poolie.
<jam> night poolie
<jam> mgz: so, after tons of bug filing I found the problem :)
<jam> (why I was running more tests)
<jam> the old, non-scenario code was using mixins, of the form class TestsForX(Mixin, TestCase)
<jam> and I accidentally had the same "TestsForX" class name in two places.
<jam> So scenarios really did give me better coverage, as it is a lot harder to make the mistakes you can make with mixins
<jam> figuring that out was very clumsy with the bugs I ran into.
<mgz> jam: ha, that's actually really interesting
<jam> mgz: also, if I use the 'load_tests' hook, then 'discover --list' works correctly, since the suite of tests is determined at load time, rather than at run time.
<jam> but -v is still broken, etc.
<jam> (and I had to patch --list to make it work :)
<jam> mgz: also lots of other oddities. Like testscenarios.TestWithScenario inherits directly from unittest.TestCase rather than testtools.TestCase
<jam> which matters when you try to run with --verbose
<jam> because TextTestRunner uses test.shortDescription() to determine what name to print
<jam> and unittest.TestCase returns the docstring or nothing
<jam> (thus using str(Test) for the representation)
<jam> while testtools.TestCase returns self.id() as the short description
<jam> so TestWithScenarios was doing the multiplying correctly, but it wasn't showing the new test ids.
<jam> because str(test) wasn't changing.
<Mez> I'm currently reviewing our internal code hosting stuff for bzr.  Anyone know of any tutorials for a decent setup (pref with stuff like hookless emails etc) or a good way of working within a team?
<Mez> What we've got a the moment is a kind of "mish-mash" repository (basically bzr+ssh) and was wondering if anyone knows a better way of doing it.
<Mez> I'd use something like LP's code-hosting if it wasn't a proprietary development
<cjwatson> canonical-bazaar / LOSA: Please stop the package importer for Oneiric
<cjwatson> (per http://wiki.ubuntu.com/ReleaseProcess)
<gnuoy> cjwatson, ok, I'll take a look
<Riddell> Mez: launchpad is open source
<Mez> Riddell: indeed it is - however - it's not exactly the best solution for us as a whole.
<lifeless> Mez: thumper made a standalone lp based codehosting system
<Mez> If it were easy enought to pull out the code-hosting stuff on it's own, that'd be fine - but the rest of it would just get in the way (and the setup/dependencies to get LP running locally is a bit of a pain)
<Mez> lifeless: oh, cool - that's exaclty the kind of response I wass hoping to hear :)
<lifeless> its designed for school projects and soon, but should be close enough to consider
<Mez> yeah - just looking over it now.  I have a feeling that I might even be able to contribute to it.
<Mez> (Mainly, I see the ability to add stuff like code review/merges/pqm-esque stuff)
<Mez> (I do like LP's Pqm-esque stuff)
<mgz> jam: do you know how to stop the package importer for Oneiric as cjwatson asked?
<mgz> gnuoy and I are... not completely sure what to do
<cjwatson> james_w should but probably isn't up yet
<james_w> hi
<cjwatson> aha
<james_w> I wish I wasn't :-)
<james_w> mgz, gnuoy, it's mass-import on jubany, it has an init script
<mgz> cjwatson: done (with more than a little help :)
<cjwatson> thanks!
<lifeless> Ran 23 tests in 4.600s
<lifeless> OK
<lifeless> bah
<ccxCZ> Mez: I plan to do something like codehosting system eventually, basically by integrating bzr, sphinx, roundup and buildbot
<ccxCZ> lightweight, componentized & extensible
<ccxCZ> but it will take some work, mainly on the sphinx front I think
<Mez> ccxCZ: actually - sloecode looks promising - however, I think zope is broken in Oneiric.
<Mez> http://paste.ubuntu.com/707279/
<ccxCZ> not zope, just older zope.interface than paste requires it seems
<ccxCZ> either upgrade or use different wsgi launcher (I use uwsgi)
<ccxCZ> zope.interface is independent of the rest of zope and used by other projects aswell, eg. twisted
<mgz> okay, looks like the basic idea of the morning works: <http://pastebin.ubuntu.com/707284/>
<mgz> I shall now go and have lunch
<awilkins> qbzr diff viewer ; any way to make the view options sticky or preconfigure them?
<awilkins> Specifically I want to make "ignore whitespace" sticky because the project team I'm working with have annoyingly different whitespace settings in their IDEs (yes, I should just slap them, but that's not an option. Sadly.)
<mgz> awilkins: you can pass the option on the command line to qdiff, but I don't think there's a conf option for it
<mgz> awilkins: could file a bug against qbzr for that, but really sounds like you need to do some slapping
 * fullermd is occasionally irritated at the unconfigurability of qdiff too.
<fullermd> If I used it more often, I'd have local hacks sitting around in the code like there's no tomorrow.
<mgz> I think there's some blame for bzrlib for various parts not quite being flexible enough for reuse in a gui
<awilkins> Alas, I can only limit my slapping to people I manage
<awilkins> These are the guys who thought they were OOOO so clever to sit around wasting hours discuss code formatting standards and then don't stick to a consistent IDE config (as predicted by Yours Truly - the only config you should use is the DEFAULT one)
<awilkins> Unless your IDE is clever enough to infer formatting rules from the files it opens (which Eclipse isn't, apart from line endings, it seems)
<fullermd> If you just converted to APL, you wouldn't have to worry about formatting rules...
<jay567> hi
<jay567> i need to install from source, but i don't find the right download
<mgz> under downloads on launchpad, the last one should always be a .tar.gz source package
<mgz> eg, https://launchpad.net/bzr/+downloads
<mgz> *ie
<jay567> thank you, i didn't see the right bar, thought it would have to be under 'code'
<jay567> there i am again... the downloaded package says python 2.6 needed... on the pages all i've seen is 2.4, whioch i have to work with
<mgz> you need 2.3 then jay567
<mgz> bzr-2.3.4.tar.gz same page, further down
<kirkland> mgz: ;-)  thanks
<jay567> :)
<jay567> next obstacle: ImportError: No module named distutils
<jay567> in setup.py
<mgz> jay567: ...do you have a full python installed, or just a core system package?
<mgz> distutils is part of the standard library and should be packed in "python"
<jay567> i want to run bazaar on a server of my university...
<jay567> maybe i can get them to install some modules for me...
<mgz> and you have no ability to request packages?
<mgz> if they can give you a working python (and ideally some build tools, pyrex and gcc), then you can do a user install of bazaar
<mgz> or they might just be able to install the bazaar package for you.
<mgz> jay567: as a final option, you may be able to get away with not having bazaar there as you can still work over sftp for instance
<jay567> what do you mean by user install? isn't this what i tried? (python setup.py install --home $HOME)
<fullermd> Well, you can run it in place without installing.  Though you may not even be able to build the C extensions without distutils, so you may be stuck with the slower pure-python variants...
<mgz> jay567: yes, that kind of thing.
<mgz> as fullermd says, you can get away without using install at all, but without the extensions you may not be better off then you would be just treating the server as a filesystem where you can put branches
<fullermd> Well, even without the extensions, I'm sure using it for bzr+ssh would beat the crap out of sftp, unless the server itself is mind-zonkingly slow and very [network-topologically-] close by.
<fullermd> Dumb servers are occasionally a necessary evil.  But they're way more the short word than the long one   :p
 * mgz defers to the greater wisdom
<jay567> ;)
<jay567> ehm
<fullermd> (it's not greater wisdom; I just take any excuse to say "mind-zonkingly", 'cuz it's way fun.  You should try it sometime.)
<fullermd> Try just running 'gmake' in the dir, see if it can do enough to build the C extensions.  I'm betting 'no', sadly...
<jay567> so if i commit to a 'server', my local bzr calls the server-bzr via ssh... yes?
<jay567> gmake and make just return the distutils error
<fullermd> There are a lot of variations, depending on details of your setup.  But in practice I'd say 'no'.
<fullermd> Just think of the server and your local as separate branches, that you sync up occasionally (probably only working on one side at a time)
<fullermd> So you commit locally, then you 'push' to the server, which calls that bzr over an ssh channel.
<jay567> yes
<fullermd> Yeah.  Figured.  Sounds like a pretty wacked out python install to not have distutils though.
<jay567> i think they are pretty afraid of the students, every student from the computer science faculty has a shell account there
<fullermd> As well they should be   :p
<mgz> jay567: try asking nicely for a proper python and build tools.
 * fullermd remembers being a CS student once, and it would be a pretty dumb staff/prof who wasn't scared to death of him   :p
<jay567> :P
<jay567> so, what do I need to do to get the 'push' working? tell my local bzr where to find the bzr binary on the server?
<fullermd> Well, there's an env var I'd have to look up to give the remote path.
<fullermd> Easier probably just to put it in your $PATH though.
<jay567> yes
<fullermd> You could e.g. have a ~/bin/bzr symlink that points to ~/src/bzr-a.b.c/bzr
<fullermd> (assuming ~/bin/ is in your path of course.  But naturally it is, surely)
<jay567> i see
<fullermd> It should Just Work(tm) then.  With the python fallbacks, so slower in various operations than would be possible otherwise, but it'll work.
<jay567> i don't thnk performance is a big issue
<jay567> where do i put the config files in this case?
<james_w> and there is precise :-)
<james_w> the package importer has just seen it and created all the jobs to create the branches, it will get to them when it is started again
<mgz> james_w: should be be started again?
<mgz> *it be
<james_w> we should get notification when they are ready for it
<james_w> I expect it could be started now, but let's wait
<slangasek> jam, poolie: as far as bug #714622 is concerned, I think the correct course of action for *all* the affected packages is to take the revid currently on the branch as authoritative... bad form as it may be, if someone has bzr push --overwritten (or otherwise changed the tag), they've done so for a reason.  As long as someone's doing db surgery, could you do so for the other 48 affected packages on http://package-import.ubuntu.com/status/ ? :)
<ubot5> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<slangasek> (this would help me for sysvinit in particular)
<CaMason> Hi guys. How can I 'merge' / squash 2 commits into one?
<jelmer_> CaMason: "bzr uncommit; bzr uncommit; bzr commit -m "Commit message for the squashed commit"
<jelmer_> wgz: hi
<wgz> jelmer: hi, just back from cow-orking
<wgz> I see from your summary page the builddeb test tweak worked for maverick and natty
<jelmer_> wgz: did you perhaps request a rebuild for bzr-builddeb?
<jelmer_> I'm a bit surprised by the upload error
<wgz> have you got a bug for the other lucid failures? I guess it's some known issue with the debian helper script not existing in that ancient a release?
<wgz> jelmer: nope, I shouldn't have touched any buttons
<jelmer_> wgz: I've fixed those I think
<jelmer_> http://people.canonical.com/~jelmer/recipe-status/bzr.html
<jelmer_> I had to backport cython for hardy as well
<wgz> ha, I see what you mean about the 'failed to upload'
<wgz> is that not just something about today being release day?
<jelmer_> wgz: that usually happens when somebody hits the "Request a build" button
<jelmer_> and the same version gets built twice
<wgz> (looking at the <https://code.launchpad.net/~bzr/+recipe/bzr-builddeb-daily> page)
<wgz> right, food time for me.
<maxb> Anyone know why the UDD importer is not running?
<wgz> I stopped it.
<wgz> and james_w said "let's wait" when I asked about restarting after the release was done.
<wgz> it may well now be time to start it again.
<wgz> if you have any idea, please say maxb :)
<maxb> I'm not clear why it needed to be stopped at all?
<maxb> cjwatson was asking about getting the dpkg import fixed today, but I'm confused, as it appears to have last run successfully
<wgz> after that, another item on his checklist for the release was to stop the Bazaar importer
<wgz> ...I don't have any more information than that, I'm afraid
<maxb> Oh, wait, it'll be so it's not trying to do stuff whilst LP's branch-distro.py process is executing
<james_w> exactly
<james_w> we don't want to be pushing up branches for the new series before that has run, otherwise it will lead to a huge increase in storage used
<wgz> what's the run time on that? :)
<james_w> 18397 outstanding jobs
<james_w> it
<james_w> it's around 18 hours IIRC
<maxb> Hmm - the web UI currently says precise has no packages
<james_w> jam, thanks for the package import status notifications on branch, it's very nice to have
<maxb> Does that mean the initialize-from-parent / branch-distro stuff is not under way yet?
<james_w> maybe there was a bug in i-f-p, let me check my scrollback
<maxb> I suspect a cache of some kind, looks like only the counts on https://launchpad.net/ubuntu/precise are zero
<maxb> there are definitely publications for precise - which explains the UDD queued jobs, actually
<james_w> maxb, yeah
<james_w> seems like there were some problems with publishing, but I can't tell if they were resolved
<james_w> the people in question left for the day though, so it may be completed tomorrow
<james_w> branch-distro has been started though
<poolie> hi all
<wgz> hey poolie
<jelmer_> hey poolie, wgz
<poolie> hi there
<Riddell> morning poolie
<poolie> hi there
<poolie> can anyone update me on the udd importer?
<poolie> i guess there is scrollback, perhaps i'll just read that
#bzr 2011-10-14
* poolie 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: jelmer
<poolie> ok good night
<nigelb> g'nite poolie :)
<nigelb> drat, its already pub time for you :P
<jam> morning all
<mgz> morning all
<mgz> jelmer_: your recipe-status page wants a new column :)
<jelmer_> mgz: it should automatically add one once there is a build for precise
 * jelmer_ reruns the script
<mgz> cool. while I'm bugging you jelmer_, are there user instructions for getting started with colocated branches in core anywhere?
<jelmer_> mgz: not really. do you mean bzr-colo or the colocated branch support that's in the core?
<mgz> I mean in core, as I think with the devel format support landing it should be somewhat possible to use now?
<jelmer_> mgz: yep
<jelmer_> basically, use --development-colo to create a directory and then use the ,branch=name syntax to specify a specific branch
<mgz> thanks, I will play around.
<cjwatson> hmm.  maybe I should just prepare this dpkg upload outside UDD; pretty awkward to work on getting the import fixed while the importer is stopped, I guess
<cjwatson> oh, here, lp:debian/dpkg is up to date now
<cjwatson> woo.  massive pile of conflicts, but unblocked.
<mgz> do we know what the signal is to restart the importer? james_w said last night we should wait for the branch import which takes ~18 hours
<CaMason_> Hi guys. How can I 'merge' / squash 2 commits into one?
<mgz> CaMason_: if they're ones you just did and haven't pushed anywhere, just use uncommit twice then commit
<CaMason_> thing is, these 2 commits are behind another commit
<CaMason_> I want to squash 318..319 together, and I'm at 320
<LeoNerd> You cna't without "rewriting history"
<LeoNerd> Rewriting history is bad and evil and upsets anyone who's checked out / branched / etc... since the rewrite.
<mgz> one option, there, again provided you've not pushed anywhere public,
<CaMason_> nobody has - this is a local branch
<LeoNerd> But if you want, you could e.g. checkout -r318; merge -r320; replay the rest.
<mgz> is uncommit, shelve, uncommit, uncommit, commit, unshelve, commit
<mgz> or what LeoNerd said is less accident prone
<CaMason_> mgz, ah yes, that would work!
<LeoNerd> Oh, a shelve stack. Another possible
<mgz> I do tend to get myself into trouble on occasion when I'm juggling too many shelves and uncommits in one branch
<mgz> making a new branch from the oldest point and cherrypicking revisions across is less destructive
<CaMason_> I tried a cherrypick with `bzr merge -r 318..319` but it carried across the revisions
<mgz> `bzr revert --forget-merges` will always let you lose the explicit merge info
<CaMason_> oops wrong button
<CaMason_> ok thanks. The shelve-stack worked. I'll remember the other suggestions though
<mgz> cool!
<CaMason_> also, I was testing these merges in a seperate branch. In git, I'd now do a ff-merge. Would `bzr pull` be about the same?
<mgz> you may want --overwrite
<mgz> but otherwise yes.
<CaMason_> good stuff. Thanks
<CaMason_> btw, would a shared repository make it quicker to create new branches?
<spiv> CaMason_: yes
<spiv> (a shared repo by itself doesn't avoid the cost of building the working tree every time, but it does save copying the history)
<quicksilver> I was about to ask you if there was a command to do something like 'bzr ls'
<quicksilver> it turns out there is
<quicksilver> it's called 'bzr ls'
<quicksilver> TIAS++
<jelmer_> :)
<james_w> mgz, it's on the release team's checklist for opening a new series, so we'll get a ping
<james_w> mgz, you could ask a l-osa whether the branch-distro is finished yet, and start it if it is
<mgz> james_w: great, thanks
<mgz> so, apparently the branch-distro script failed, which blocks restarting the importer.
<mgz> there's a log on carob with more information, but I'm not sure how to get there from chinstrap to look.
<mgz> as am not allowed agent forwarding, and trying to follow the instructions on the wiki for the alternative setup just fork-bombs myself with ssh processes
<mgz> so clearly someone more competent will have to handle this.
<mgz> that might mean Monday.
<fullermd> I doubt it.  Nobody's competent on monday...
<mgz> :)
<fullermd> jelmer_: Is that .THIS file supposed to be there?
<jelmer_> fullermd: which one?
<fullermd> added: bzrlib/tests/per_repository/test_fileid_involved.py.THIS test_file_involved.py
<fullermd> +-20051215205901-728a172d1014daaa
<jelmer_> fullermd: where is that?
<fullermd> Is that commit you just put through PQM.
<fullermd> s/Is/In/
 * fullermd khan tipe.
<jelmer_> fullermd: that's indeed not supposed to be there, thanks.
<fullermd> PQM mailing again ++.  Makes it so much easier for me to pick people to harass in passing   8-}
<cr3> hi folks, bzr seems to ignore buildout-templates/bin/lint.in because I have "bin" in my .bzrignore file. aren't bzrignore patterns supposed to be absolute?
<cr3> maybe I'm supposed to use ./bin instead of just bin
<wgz> for the bin in the root of your project only, yes
<cr3> wgz: I now see this is actually well documented, my mistake :)
<cr3> wgz: I guess I'll prepend './' to every pattern that's just in the root, just to be extra explicit
<Noldorin_> hi jelmer_
<jelmer_> hi Noldorin_
<Noldorin_> how's it going?
<jelmer_> Noldorin_: alright, how are you?
<Noldorin_> jelmer_, not too bad. just very busy i'm afraid, with my own job(s) now
<Noldorin_> jelmer_, so no time to really look into the bzr-git issue, sorry. unless i get really lucky over the next week or so, you will probably beat me to it ;-)
<wrv> hi
<jelmer_> hi wrv
<elmo> does anyone know any simple-ish plugins using pre-commit hooks off the top of their heads?
<jelmer_> elmo: I think james_w had a plugin that tried to run a testsuite in pre_commit, let me see if I can find it..
<elmo> jelmer_: actually don't worry, I'm being an idiot - a hook, won't do what I want
<james_w> https://launchpad.net/bzr-testrunner
<elmo> jelmer_: thanks though
#bzr 2011-10-15
<maxb> james_w: Did branch-distro finish OK yet?
<wgz> maxb: apparently there were issues, but I'm not sure if that actually blocks restarting the importer
<wgz> see the irclog for yesterday
 * maxb will assume it does block it
<wgz> ha, but looking at the instructions again today I think I know what I did wrong with their funny way of setting up ssh forwarding
<wgz> so, I can probably get the log, which might mean something to you maxb
<maxb> You might be crediting me with more knowledge of LP internals than I actually have, there
<maxb> There's more than one way of setting up ssh forwarding?!
<wgz> their way isn't the way I've always done it, so I screwed it up yesterday by not reading the example config properly
<wgz> okay, the log just has a bunch of warnings about stacking, as was mentioned, but at the end gives an error
<wgz> of generic nature.
<wgz> don't know if that means any more to you than it does to me maxb.
<darkstarz> can some please provide the link for the latest (stable) verision of bzr for ubuntu (11.04)
<nigelb> darkstarz: you just want to install it?
<nigelb> sudo apt-get install bzr should do it
<darkstarz> yes , I am a beginner
<darkstarz> i would like to install and test it out
<nigelb> ah
<nigelb> go to software center
<nigelb> and search for bazaar
<nigelb> and click install
<darkstarz> thnx
#bzr 2011-10-16
<exarkun> Can I make bzr-svn use a specific cache directory?
<jelmer_> exarkun: there isn't a configuration option, though you should be able to symlink ~/.cache/bazaar/svn to something else of course
<exarkun> But that won't help me have two different bzr processes use two different svn caches
<eQuiNoX__> hey guys, im new to bzr(im more familiar with git/hg); im having to push to launchpad and i have outgoing ssh blocked here so how could i go about doing this?
#bzr 2012-10-08
<mgz> morning
<jelmer_> w7z!
<mgz> heh, you have spotted my current pattern? :)
 * jelmer_ renames mgz to mbz2
<vila> :)
<vila> hi guys
<jelmer_> hi vila, how are you?
<mgz> hey vila!
<vila> fine, still fighting that damn coughing for the last three weeks, getting there ;)
<jelmer_> ouch
#bzr 2012-10-09
<mgz> morning
<exarkun> hi, I wonder if anyone who knows about the smart server jail saw my question in the logs from the weekend and can shed some light on my issue
 * fullermd has half of that covered   8-}
<lifeless> exarkun: I did not.
<lifeless> exarkun: I might be able to.
<fullermd> lifeless: He was doing something with writing some file in a hook, that complained about jailbreaking.
<fullermd> I can probably dig up the logs...
<fullermd> http://paste.ubuntu.com/1269933/  is a quick block of it.
<exarkun> ah, a keyboard
<exarkun> fullermd: thanks
<exarkun> lifeless: any thoughts?
<lifeless> exarkun: ok
<lifeless> exarkun: can I see your hook ?
<exarkun> lifeless: http://twistedmatrix.com/~exarkun/restart_server.py
<lifeless> exarkun: which line throws the error ?
<exarkun> oh, codepad.org is broken :(  http://pastebin.com/KkUbcrAJ
<exarkun> line 30, params.branch.create_checkout(to_location=checkout.path, lightweight=False)
<exarkun> lightweight=True succeeds
<lifeless> ok
<lifeless> so here is what I suspect is happening
<lifeless> firstly the jail
<lifeless> what happens is that code in the server runs with a transport url like chroot-1234://foo
<lifeless> where // is rooted at the repository
<lifeless>  / branch (may be distinct for distinct verbs, I'd need to check)
<lifeless> this is so that code can't accidentally traverse up outside the repository
<lifeless> e.g. due to bugs
<lifeless> its only a soft chroot through
<lifeless> you can escape it by opening a new transport on local disk / memory / wherever
<lifeless> or by poking through the chroot object innards
<lifeless> so, lightweight=True has no reason to chdir to .. repeatedly
<lifeless> because its using the branch and the branches repository
<lifeless> lightweight=False has to search for a containing repository to reuse for its new branch
<lifeless> exarkun: if you look in bzrlib/smart/request.py you'll see that the pre_open_hook has a list of allowed transports, thats thread specific
<lifeless> exarkun: and knows to translate file:// into any of those transports (by mapping across).
<lifeless> exarkun: so, long story short, you probably want to explicitly allow the transport you're going to be using
<lifeless> the jail is entirely there to prevent awfuck moments when you delete your hard drive due to a badly written hook that assumes its running in a user context, for instance.
<exarkun> I don
<exarkun> 't see an API for adding to the allowed transports though
<exarkun> Should I just mutate the thread-local directly?
<lifeless> exarkun: yes, its a public symbol
<lifeless> exarkun: bzrlib.smart.request.jail_info.transports.append(transport.open('file:///home/foo'))
<lifeless> or whatever
<exarkun> hee hee, "symbol"
<lifeless> attribute
<lifeless> doohicky
<lifeless> thingamy
<exarkun> file:///home/foo doesn't have to be a bzr branch or repository or anything?  I don't really know what a bzrlib transport is.
<lifeless> exarkun: a transport is just a vfs directory
<exarkun> lifeless: Thanks.
<exarkun> lifeless: Regarding the transport.open, I don't see a bzrlib.transport.open function.  Maybe get_transport?
<exarkun> Hm, seems not, with the result of get_transport appended to the list, I still get a jail error.
<exarkun> lifeless: Once I add get_transport('file:///home/foo'), the error just changes to be about file:///home/
<exarkun> I guess I could just add file:///
<lifeless> exarkun: there is/was a standalone=True you could pass I think
<lifeless> which would tell it not to seek a containing repository
<exarkun> I used file:/// it works :/
<exarkun> thus ends my interest in the matter for the time being
<exarkun> thanks again for getting me there
<lifeless> exarkun: np
#bzr 2012-10-10
<bob2> "Not checking SSL certificate for xmlrpc.launchpad.net" <- eh?
<fullermd> XML and RPC have already exhausted the TLA support, so it can't do SSL at the moment.
<mgz> morning
<bobsapp> so i shelved some changes
<bobsapp> but i never went back to them and i want to get rid of them.
<bobsapp> in fact i fixed the bug before unshelving them.
<bobsapp> can i somehow discard the shelf?|
<mgz> `bzr shelve --list` then `bzr unshelve --destroy N`
<bobsapp> many thanks!
<mgz> the first command telling you what N to use (if you used a message when shelving)
<mgz> otherwise you can `bzr unshelve --preview` to see which if you hae multiple shelves and no way of telling which is which
<bobsapp> I think the problem is i was trying to do too much stuff at once.  Should have just not shelved those changes at all.
<bobsapp> in the first place
<bobsapp> In my manpage i dont have unshelve destroy
<bobsapp> yeah i might have an older version of bzr
<bobsapp> I have delete only which is the same thing though
<bobsapp> it worked fine.
<mgz> gah, sorry :)
<mgz> one of shelve/unshelve uses destroy, one uses delete, and I always forget which is which
<mgz> jelmer: can you have a look at torkvemada's branch? I got him to make the mp more verbose and add some tests based on one of your hook additions
<jelmer> mgz: Yeah, bzr-git can create branches an dpush to them
<jelmer> mgz: a somewhat annoying problem there is that dpush itself won't create new branches, unlike push
<jelmer> mgz: but fixing that requires a bzr core change
<jelmer> mgz: I'm not convinced about the commit hooks
<jelmer> mgz: Commit until now was a pretty private object, passing it to a hook seems like a bad idea to me
<mgz> wait, now I need to do my lines :)
<mgz> is there a better way to do what he wants though?
<jelmer> mgz: you're a shakespear man, you can handle it.
<mgz> Commit.commit takes an impressive list of arguments
<jelmer> mgz: pass specific arguments to start_commit I guess
<jelmer> I guess it's just... message, revprops, committer and maybe the two timestamp bits?
<mgz> hey, I said that! :)
<jelmer> :)
<mgz> when does Revision._check_properties get called... don't want a hook that can introduce borked properties...
<jelmer> I guess we
<jelmer> 'll ship 2.6 beta 2 in quantal?
<mgz> seems that's going to happen
<jelmer> so then it's perhaps not so bad to land a somewhat riskier change now
<mgz> having multiple things trying to hit freeze window makes life painful
<jelmer> yeah
<cr3> if I "bzr checkout --lightweight lp:~cr3/checkbox/optical_write_test" and then do this in the directory "bzr st --short -r bzr+ssh://bazaar.launchpad.net/+branch/checkbox/", I get: bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {bzr+ssh://bazaar.launchpad.net/+branch/checkbox/} because its ancestry shows a ghost at {tarmac-20120922215931-44bbvwzadme5c8rd}')
<cr3> I don't understand what that means :(
<jelmer> cr3: there is a reference to a revision that is not present in the repository
<jelmer> cr3: that revision is necessary for determining the revno
<jelmer> cr3: -r with a URL doesn't make sense
<jelmer> -r takes a revision, not a branch
<cr3> jelmer: odd, I got that from utilities/find-changed-files.sh in the launchpad source: rev=`bzr info | sed '/parent branch:/!d; s/ *parent branch: /ancestor:/'`
<cr3> jelmer: maybe "parent branch" in some contexts is a revision, not a branch. that would explain it
<jelmer> cr3: no, a parent branch is always a URL
<jelmer> cr3: "branch:URL" is a revision though
<jelmer> cr3: so perhaps it's just removing the word 'parent' there
<jelmer> -rbranch:lp:bzr returns the tip revision of lp:bzr
<cr3> jelmer: aha, it replaces "parent branch" with "ancestor", so you have "ancestor:URL" which works fine when I branch a project, not when I checkout though
<w7z> that GhostRevisionsHaveNoRevno thing with lightweight checkouts of stacked branches is bug 1049124
<ubot5> Launchpad bug 1049124 in Launchpad itself "bzr log -rxxx crashes out with 'ghost' in branch, but not in trunk" [Low,Triaged] https://launchpad.net/bugs/1049124
<jelmer> I guess it should just be saying NoSuchRevision?
<w7z> jelmer: the cute thing is it actually has the rev... it's just in the stacked on branch, not the immediate branch
<awilkins> jelmer, Ping?
<jelmer> awilkins: hi
<awilkins> Running into a problem pushing to a remote SVN repo - it looks like #394527 (with a slightly different message)
<awilkins> "bzr: ERROR: At least one property change failed; repository is unchanged "
<awilkins> It pushes about 8.5Mb and then coughs that up. The revision in question is not especially large but does rename a root level folder and nest it inside a new folder of the same name as the original
<awilkins> So foo => foo/new-foo
<awilkins> Alas, I have no access to the server logs or configuration, it's commercial SVN hosting
<jelmer> awilkins: not sure if there's much I can help with there :-/
<awilkins> jelmer, Yeah, was just hoping for a miracle :-)
<jelmer> awilkins: I guess you could split up the commit so each change would be smaller
<jelmer> that might not be very easy though
<awilkins> jelmer, I have a feeling it's that one folder move, and all the paths inside being written as metadata in the revision properties
<awilkins> The rest of it is pretty small changes to text files
<jelmer> awilkins: that sounds about right
<jelmer> for the bug you linked
<awilkins> Yeah, I suppose I could ask if they'll raise that XML limit
<awilkins> I'm trying to find an SSH port I can hit it through to circumvent it
<awilkins> Bah, doesn't help that it's a horrible old build of CentOS in there
 * fullermd upgrades pre-2a branches...
#bzr 2012-10-11
<mgrandi> anyone here? :>
<mgrandi> need help with merging =(
<fullermd> Vaseline and a crowbar?
<mgrandi> haha
<mgrandi> so say we have a branch
<mgrandi> and then we have newer version of code that we want to merge into this branch
<mgrandi> but how can we make bzr merge this newer version into the branch? apparently bzr can't do it because the file ids are different in the 'new' code
<mgrandi> so it just moves the old code to .moved and puts the new stuff in place
<bob2> why did you do that
<mgrandi> its 'generated' code
<mgrandi> well thats why im asking on how to do it since that isn't working =P
<bob2> fix your system
<bob2> so the ids match
<fullermd> If the file-id's are different, you're out of luck.  Your choices turn into "remake things so they're the same", "pick one over the other", or "take up cobbling"
<mgrandi> so there is no way to do it if the ids don't match at the moment?
<mgrandi> hmm.
<fullermd> If both branches have nontrivial history, remaking becomes a lot harder.  If they're out in the wild, that verges well into impractical.
<bob2> fix your things
<mgrandi> well its crappy cause its not our code, we are decompiling it
<bob2> you should have used bzr-load-dirs or similar to get the vendor code in
<fullermd> In the wild, one-over-another becomes pretty impractical too, unless you can coordinate the universe.
<mgrandi> and we are trying to fix it
<bob2> how did you even make this happen
<mgrandi> what is bzr load dirs?
<bob2> the thing that you google
<bob2> did you "bzr rm -r * ; SPLOOSH RANDOM FILES EVERYWHERE ; bzr add . ; bzr commit -m 'teh import'"?
<mgrandi> we decompiled the code, and started versioning / editing that
<mgrandi> only reference i to see about bzr-load-dirs is from you in 2009 o.o
<bob2> no idea how you got the code into bzr
<bob2> but even "bzr branch whocares ; SPLOOSH FILES ; bzr add ; bzr commit -m'update import'" mostly works
<mgrandi> but git-load-dirs looks like what we want, but i dunno where the bzr version is
<fullermd> You could transistion stuff into git, do merges, then pull it back into bzr.  But that's a long way around to the "pick one over the other" case too; one of the branches would have to be dead afterward.
<bob2> what commands did you run
<fullermd> (or perhaps it's more of a "pick a third over each", and both branches dead afterward)
<bob2> I can only see you being in this situation if you did a "bzr rm theworld"
<bob2> is that what happened?
<mgrandi> i mean we haven't commited anything yet, we just got to the 'pending merge' etc
<bob2> yes you have
<bob2> you did something to your vendor branch
<bob2> what did you do?
<mgrandi> just tried putting the newly decompiled code into a new branch and tried to merge that into the stuff we were walking on
<bob2> yes a new branch obviously won't work
<bob2> clone the previous dump
<mgrandi> there wasn'ta  vendor branch yet, thats what we are going to add soon, which is probably the problem
<bob2> sploosh your new source tree all over it
<bob2> bzr add .
<fullermd> It's not hard in concept to remake a history with arbitrary id's.  I don't know if anybody's written an automated process for it, and the hard part is it means you have to throw away and forget completely the "old" version, which is hard in an open-source world (easier, though not necessarily easy, in a closed env)
<bob2> bah
<bob2> that's insane
<bob2> full solution:
<bob2> clone previous dump of crap
<bob2> mkdir ../keep
<bob2> mv .bzr* ../keep
<bob2> rm -r *
<bob2> mv ../keep/.b* .
<bob2> sploosh new pile of code into current dir
<bob2> bzr add .
<bob2> bzr commit -m "update to SOME VERSION IDENTIFIER OF THIS THING"
<bob2> then you're done
<fullermd> What previous dump?  The world is full of real cases of parallel imports.  You're kinda flirting with the line between "amusing" and "insulting"...
<fullermd> If there's no history on one side or the other, it's easy.  If there is, life gets a lot harder.
<bob2> ?
<bob2> I'm 99% sure mgrandi is saying "we get dumps of some binary crap from some people on a regular basis, then decompile it, and we'd like each version to be in bzr"
<mgrandi> yeah
<bob2> which the above works for
<fullermd> I read it more as "we've got two different sets of working on the same dumps that started independently, and now we're trying to combine them"
<fullermd> (FSVO "same")
<mgrandi> its the "vendor branches" concept pretty much, looking into whatever_load_dirs scripts that bob2 referenced
<bob2> all bzr-load-dirs does is the above
<bob2> the above is the complete set of steps required
<mgrandi> do you have a link to that? i cannot find that on google
<mgrandi> only svn/git/tla load-dirs
<bob2> nope
<bob2> but seriously, it's 10 commands to run
<mgrandi> ok
<jelmer> hi
<mgrandi> hi
<mgz> morning
<foobaz> What's the best way to include external dependencies in a bzr project? (e.g. like svn:externals)
<foobaz> I'm presently scripting bzr checkout...
<foobaz> maybe there's a better way.  Thanks.
<jelmer> foobaz: there's bzr-externals, or bzr-scmproj I guess
<foobaz> jelmer: thanks!  I'm evaluating those two
<tbf> am i just biased, or does "bzr merge" sometimes just overwrite local changes instead of creating conflicts?
<tbf> no. i just caught that guy
<tbf> have a merge commit where bzr cleary overwrote a local change
<tbf> junk scm
<lifeless> tbf: by local change, do you mean uncommitted change, or change only on your branch ?
<tbf> lifeless, a change commited to a local branch
<lifeless> tbf: the former should conflict unless identical to incoming changes; the latter likewise, but if someone has merged you, then reverted that change, and then you merge them, the change will go away.
<tbf> lifeless, ok. checking commit history
<tbf> (and i please want git style rebasing)
<tbf> lifeless, no. there is only once commit where a team mate change the line above the lost line
<tbf> branching the current state for backup, uncommiting, redoing the merge
<tbf> double checking i didn't do a mistake
<tbf> ok. it's late and i am overworked.
<tbf> ...and biased.
<fullermd> ENOTENOUGHCOFFEE   8-}
<tbf> lifeless, sorry for confusion.
<tbf> fullermd :-)
<lifeless> tbf: np
#bzr 2012-10-12
<mark06> why the same branch is 7MB fresh new from Launchpad and 30MB in the copy where I've recommitted whole branch?
<mark06> I thought uncommit mean it
<spiv> Uncommit doesn't delete the commit from the repository
<spiv> It just changes the branch to no longer refer to it.
<bob2> did 'bzr gc' ever get implemented?
<mark06> annoying
<mark06> how to really uncommit it? or delete from repository if you prefer
<spiv> Also, you will probably find 'bzr pack --clean-obsolete-packs' reduces the size of the bzr directory (note that bzr will do that housekeeping automatically from time to time without you needing to do it manually)
<mark06> does it delete uncommitted commits?
<spiv> Until someone implements the hypothetical 'bzr gc' command bob2 mentions, you have to do it manually: create a new repo, and branch into that (omitting any branches and thus revisions that you don't want).
<bob2> no
<bob2> you can reclone if you really care
<lifeless> didn't someone implement gc in a plugin ?
<spiv> (If you only have one branch, then this is simply 'bzr branch original-dir new-dir')
<spiv> (and are using standalone branches, I should add)
<mark06> well I only create branches with bzr init, does that qualify?
<spiv> If you never used bzr init-repo, sure.
<mark06> so it's basically bzr branch $each $each.new && rm -r $each?
<mark06> right I never used bzr init-repo
<mark06> btw, I was thinking of gathering together some scripts of mine which currently have their own branches, but if I use a single branch I'll lose individualized history for each script
<spiv> Right.
<spiv> There are ways to merge unrelated branches without losing history.
<mark06> so I wondered if I could create some sort of "multi-branch", is that what repos are about?
<spiv> Search the mailing list archives, IIRC the 'bzr merge-into' plugin may help
<spiv> (Also "bzr merge -r0..-1 $unrelated_other" for simple cases)
<spiv> No, shared repos are simply about efficiency.
<spiv> (If you have N branches of a project, the vast majority of history will be exist in more than 1 branch, but if they share a repo each revision is only stored once.  This unsurprisingly saves a heap of disk space and makes things faster.)
<spiv> Ugh, pardon the mangled grammar :)
<fullermd> I think jam wrote a gc plugin.  A very long time ago.  Like pre-2a ago, if not earlier...
<mark06> ok, but your suggestion will only work for past commits not new ones, right
<fullermd> You can merge multiple unrelated branches together; I do it all the time.  Can't work with them independently after that though.
<fullermd> (well, you can, on the original unjoined bits, but post-join work is all somewhat irrevocably joined)
<mark06> well, actually I can bzr [q]log filename, then I'll see individual histories separately
<fullermd> Yes, but I mean you can't turn that one joined branch back into N separate branches.
<mark06> ok I mean about the whole idea of multi-branches, not needed at all... the only inconvenience is need to specify component in commit messages for global log not being confusing, but it's ok
<mark06> either way, I think you can hack into uncommit and revert to unmerge separate branches... original commit dates could be kept with --commit-time in the new branch...
<mark06> which I just found out after recommitting all my problematic branches :(
<fullermd> Only by backing up to before they're merged together (which kinda beats the dolphin).
<mark06> btw I have recommitted some branches due to a bug between MSVCRT and MSYS, but in the meanwhile I found out what seems a bug with qlog...
<mark06> commit times were being kept 1 hour forward (timezone -2) but even after fixing that (timezone -3) qlog seems to still be confused...
<mark06> maybe still referencing replaced  commits? I haven't found a pattern to reproduce and file a bug though
 * fullermd waves at vila.
<jelmer> mgz!
<mgz> morning
<mgz> how are you today jelmer?
<jelmer> in need of coffee
<jelmer> mgz: how are you?
<mgz> not quite arrived at coffee yet :)
<vila> fullermd: \o
<vila> hi jelmer, mgz ;)
<mgz> hey vila!
<vila> lifeless: happy EOJ ;) Have fun !
<lifeless> vila: thanks
<Limit_> hi!
<Limit_> I am unable to connect to launchpad using bzr
<Limit_> It shows connection reset and I wanted to know if I could ask bzr to make requests at specific ports. Any help?
<Limit_> SSH in my college is blocked. Can anyone suggest an alternative way to connect to Launchpad using bzr ?
<vila> Limit_: then no write access for you :-/ http should be fine to read though
<Limit_> vila: so I would atleast be able to fetch code??
<mgz> Limit_: yup, you need to remove your launchpad login from your config and ignore bzr telling you you've not logged into launchpad
<mgz> that means removing 'launchpad_username' from bazaar.conf and deleting the launchpad.net section of authentication.conf
<Limit_> mgz: oh! that would atleast partly solve my problem! thanks :)
<mgz> running `bzr version` will tell you where to find those
<mgz> then when you branch lp:PROJECT it'll use the http link (which your college probably don't filter)
<Limit_> mgz: new doubt. When  I try to upload code the next time, I'll have to add the launchpad_username and add info in authentication.conf, right?
<mgz> Limit_: just `bzr launchpad-login YOURLPNAME` would be enough, but if this is a laptop and you're going on and off networks with ssh support that would still get annoying
<mgz> what I had for a long time, was a pristine copy of trunk that was linked to the http location of the branch on launchpad
<mgz> but then when I did feature branches that needed pushing rather than just pull, had my lp name in so push lp: used ssh
<Limit_> mgz: yes i have a laptop and that was the reason I asked you :)
<vila> interesting use case, worth a bug, this screams: configure me !
<Limit_> vila: I don't understand what configuration changes would be useful in this case
<vila> a way to switch from places with ssh and the others
<vila> *ssh access
<vila> did you try asking your admins to allow ssh access by the way ?
<Limit_> Yes I did
<Limit_> They simply denied.
<Limit_> vila: about the configuration, we just need to write a script that swaps 2 configurations :) I have already created one for home and one for college. The script would name the required one as bazaar.conf or authentication.conf :)
<vila> they denied blocking ssh ?
<Limit_> no, they denied unblocking SSH
<vila> oh, as in they refused (sorry, not a native) ?
<Limit_> vila: Yes. we are not having SSH connection which stops me from pulling/pushing code.
<vila> Limit_: otherwise, you're right, a simple script can do. You'll have to remember modifying the two copies in sync though
<Limit_> vila: yes
<fullermd> Well, the usual solution to such blocking is "just tunnel it over ssh"...   ;>
<Limit_> fullermd: I could tunnel SSH over HTTP but, I don't think launchpad would accept the code that is pushed over HTTP
<fullermd> Oh, well, you could just encode those as DNS TXT packets for the transfer.
<Limit_> fullermd: I am sorry I didn't get you. Can you explain DNS TXT?
 * fullermd is being a little facetious  ;p
<fullermd> Isn't there a way you can make arbitrary location aliases on a branch?  There's also the bookmarks plugin.
<fullermd> (you'd still have to spec the location when you're on whichever network you consider the special case, but it'd save you typing out the full deals)
<mgz> just having the http link as the parent worked suprisingly well for me
<mgz> wasn't often I wanted to do more than pull trunk and hack locally
<Limit_> mgz: yes it will let me work on my code. It's just that for the time I am in college I'll have to submit patches.
<janos__> in bzr explorer, is there a way to remove the [Toolbox] somehow?
<janos__> i mean permanently, with configuration or something
<janos__> the thing is, every time i click refresh it comes back
<janos__> maybe that's not clear enough
<janos__> here's what i mean:
<janos__> create a branch: bzr init tmpbranch
<janos__> open bzr explorer on it: bzr explorer tmpbranch
<janos__> the top-right part is the "Toolbox"
<janos__> it's something you hardly ever use (me, never)
<janos__> you can click the [x] button, it will go away, but only until you hit refresh
<janos__> a workaround that helps a bit: snap the Toolbox out of the frame, and then snap it back in -> this creates some sort of tabbed window, with the Toolbox and the Working Tree as tabs. This is better, because I can just switch to the Working Tree tab, the Toolbox will not be visible that way, and this layout is preserved even if I refresh
<janos__> but i have to do this every time i launch bzr explorer
<w7z> janos__: don't know off hand, but one way or another should be possible to remove it
<janos__> w7z: so there is hope!
<w7z> if nothing else, you can probably comment it out in the python
<janos__> w7z: probably
<janos__> w7z: i need this for some non-programmer friends, it won't look very good if i have to tell them to go into the python code and comment out line X
<janos__> well if there is no other way it's better than nothing
<w7z> janos__: try line 205 in explorer.py
<w7z> http://bazaar.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk/view/head:/lib/explorer.py#L205
<w7z> comment out that in your local copy
<w7z> or poke this function:
<w7z> http://bazaar.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk/view/head:/lib/explorer.py#L708
<w7z> that looks like it has preferences you can set
<janos__> ok hang on
<w7z> so try setting those preferences to false
<janos__> thanks w7z, this is gooood!
<w7z> you found the preferences and that did the right thing?
<janos__> L205 just made the toolbox displayed popped out, the other one around L708 does what I want, I just set tbox_applicable = False ignoring all the ifs
<janos__> w7z: i'm having the impression that i could set preferences somewhere, that way my friends don't have to edit python code
<janos__> w7z: any ideas where that might be? maybe somewhere under ~/.bazaar ?
<janos__> uhm, it's the DEFAULT_PREFERENCES['toolbox-on-status-view'] what i want to override to False, wonder if the setting is exposed somewhere in the UI or config file
<janos__> w7z: got it! it's in ~/.bazaar/explorer/explorer.conf
<janos__> i can set there the toolbox-on-* to false
<janos__> thanks a lot w7z this is great!
<janos__> gotta go now, bye all
#bzr 2012-10-13
<delinquentme> bzr commit -m "yadda" /path/to/only/files/I/want/committed.rb
<delinquentme> right?
<jelmer> delinquentme: yes
<janos> delinquentme: you might like this too: bzr ci -m 'yadda' -x /path/to/dir/i/want/to/EXCLUDE
<delinquentme> janos, Ohh cool! TIL bzr has an exclude option
<janos> ...and if you made a mistake with the list of files, you can "bzr uncommit" and try again. but prob you did know that
<janos> (unless you're in a central workflow, in which case you should not uncommit...)
<mnn> I'm getting an error while shelving changes
<mnn> Was this fixed or not? https://bugs.launchpad.net/bzr/+bug/660125
<ubot5> Ubuntu bug 660125 in Bazaar "shelve crashes with "Tree transform is malformed" when renamed file already exists" [Medium,Confirmed]
<mnn> http://pastebin.com/vHeu7J7R
<mnn> I don't know if it's same issue
<jelmer> mnn: that bug isn't fixed going by the bug status
<mnn> so, is there a workaround?
<mnn> will commit work?
<vila> wild guess: move the existing file out of the way before shelving (from the bug report the issue is about that existing file not being known by bzr)
<mnn> well, I don't have any pending renames - only added files and modified
<vila> ha, be looking at your paste, it may be a different issue
<mnn> I've been shelving/unshelving stuff for long time now without any issues
<vila> the pita with 'mzrlformed transform' is that, while it's clearly a bug in bzr, the error reported is so cryptic there is no way to diagnose without being able to debug locally :-/
<vila> so either you're able to 1) publish your branch and working tree 2) isolate a reproducible recipe
<vila> 1) may not even be a good solution if too many files are involved (I've lost myself in several attempts already)
<vila> mnn: yeah, that's what make bugs of this family so painful, there are less and less corner cases left unaddressed which make them harder to understand and fix :-/
<vila> mnn: I think there is another bug about pending adds causing trouble
<vila> 'bzr st' would be a good start to check whether you still have unknowns or not or...
<vila> mnn: 'will commit work?' It should !
<vila> hmm
<vila> mnn1: what's the last message you read ?
<mnn1> "mnn: I think there is another bug about pending adds causing trouble"
<mnn1> got disconnected
<vila> ok
<vila> <vila> 'bzr st' would be a good start to check whether you still have unknowns or not or...
<vila> <vila> mnn: 'will commit work?' It should !
<vila> in fact, I think it's a very good idea to start with 'bzr commit',
<vila> from there it's possible that 'bzr uncommit; bzr shelve' *will* work
<mnn1> well this is even more weird - I have 3 modified files, 7 added files and 1 added folder
<mnn1> I can shelve all files without any problem and then separately shelve added folder - no crash
<vila> shudder
<mnn> well but after that qshelve crashes whenever I try to show contents of those shelves
<mnn> well, I got something new - "bzr: ERROR: No final name for trans_id 'new-2'"
<mnn> this error pops up when I try to unshelve added files
<vila> at that point, trying to diagnose whether this a genuine bug or a fallout from the original one is... not worth it IMHO
<vila> start by doing a backup of your whole working tree (*including* the '.bzr' directory)
<vila> and try to get back to the point where the whole shelve was failing and try 'commit/uncommit/unshelve' instead
<mnn> damn, I knew this would happen when I start using VCS
<vila> jelmer: python-docutils-0.9.1 ? quantal ?
<jelmer> vila: debian experimental
<vila> jelmer: hmm, can you try just removing the leading space on that line 161 ?
<vila> jelmer: (I know I suck for not having a debian experimental chroot ;)
<vila> jelmer: the guess above is because emacs doesn't fontify this line like the other similar ones, cheap enough to try...
<jelmer> vila: I'll try
<vila> jelmer: wait, wrong guess, *adding* a space *after `fcgi` seem to to fontiry correctly
<vila> i.e. a space after the closing `
<vila> I don't speak japanese but a space there shouldn't hurt ;)
<jelmer> vila: that works \o/
<vila> jelmer: \o/ feels good :)
<vila> jelmer: approved
<lduros> hi, I have Contents conflict on directories that existed but don't exist anymore, and I actually don't have the files themselves in the tree anymore, but the Contents conflict are still there and I'm not sure how to resolve them when the files are gone? Any idea? Thanks!
<mark06> about my earlier question on uncommit, is it the same thing for push --overwrite in Launchpad?
<mark06> I mean, that push will overwrite the branch but previous versions will still remain in the repository (either local or in Launchpad) just like uncommitted commits?
<fullermd> Yes.
<mark06> ok, thanks
<fullermd> (though I have to scoff at the phrasing "uncomitted commit".  It's thinking about things like that that get people committed  :p)
<mark06> I've heard about some gc plugin but couldn't find it to test
<mark06> is there some bug to make uncommit, push --overwrite and the like to really do what they say?
<fullermd> They do what they say; they make changes to branches.
<fullermd> They just don't remove stuff from repositories.
<mark06> I knew you would disagree
<mark06> why not tweet my uncommits as well
<fullermd> I'm sure someone has implemented `bzr push twitter://....`  ;>
<mark06> :P
<lduros> any idea how to remove "contents" conflicts for files that have now been physically removed?
<jelmer> lduros: use "bzr resolved"
<lduros> jelmer: with the d at the end? Hmm
<lduros> jelmer: it tells me 0 conflicts auto-resolved.
<jelmer> lduros: does "bzr conflicts" still report any conflicts?
<lduros> jelmer: yes, it still mentions those files that are not present physically
<lduros> jelmer: there are also some other text conflicts
<lduros> which I need to work on
<jelmer> lduros: have you tried "bzr resolved" with a filename?
<lduros> jelmer: hmm let me try :-)
<lduros> jelmer: ok looks like it's doing the trick! Thanks! :-)
#bzr 2012-10-14
<vedic> I have added ppa for my ubuntu 10.04. How to install bzr 2.5.1 the latest stable release?
<lduros> hi, if I want to revert a file to the way it was in a previous revision, how can I do that? I only know how to revert everything to a previous revision
<lduros> hmm, looks like giving a file to it will only revert the given file :-)
#bzr 2013-10-07
<mark06> help! http://bazaar.launchpad.net/~renatosilva/+junk/scripts/view/head:/check-brst-commits.sh
#bzr 2013-10-08
<HappyClappy> hi
#bzr 2013-10-09
<Flohack_> Hello there!
<Flohack_> I have a strange/serious issues with Bazaar GUI in Windows (bzr 2.5 or 2.6 beta, Win seerver 2003 R2) - the Bazaar Explorer does not open at all, no error messages... cmdline seems to work
<Flohack_> If anyone knows were to look or what to check please ;)
<Flohack_> will  be AFK sor some time now (30mins)
<mgz> Flohack_: try running `bzr explorer` on the command line and see if it gives any informative output
<Flohack_> Ok I will
<Flohack_> Hello mgz again,
<Flohack_> found the trouble, plugins were missing: Qbzr and one other
<Flohack_> is there a chance to show a popup message with these errors? Its a bit like fishing in the dark otherwise ;)
<philsf> hello, I created a versioned dir for a project with "bzr init", but didn't create a shared repo ("bzr init-repo") before-hand. Is there a way to link the dir (branch?) to a repo, or is it too late now?
<mwhudson> philsf: you are aware that shared repos are just a space/time optimization right?
<mwhudson> i think bzr reconfigure can do that though
<philsf> yes, but I'm at the stage of pushing the project to lp, and AIUI it's a best practice to use a repo. is this wrong?
<fullermd> The one doesn't have anything to do with the other; repos are a purely local construct.
<philsf> fullermd, oh, thanks for clarifying that
<philsf> I'm having a little problem pushing to lp, but I'm not sure if it's a problem with my bzr config, or my lp profile. The error I'm getting is the same as: https://answers.launchpad.net/bzr/+question/190008 can you guys help, or should I ask in #launchpad?
<philsf> basically, bzr is not authenticating via ssh to lp. I already configured an RSA key in lp, but am getting a "permission denied (publickey)" error
<mwhudson> philsf: what does "ssh bazaar.launchpad.net" say
<philsf> I followed the steps from http://doc.bazaar.canonical.com/beta/en/mini-tutorial/index.html
<philsf> mwhudson, Permission denied (publickey).
<mwhudson> philsf: wrong username possibly?
<philsf> mwhudson, both local and lp usernames are "philsf".
<mwhudson> philsf: then i don't know :/
<mwhudson> you can try running ssh -vv bazaar.launchpad.net and seeing if that says anything useful
<mwhudson> (like maybe it's not offering the key you expect for some reason)
<philsf> I looked, but it just checks both my DSA and RSA keys (the RSA is the one I uploaded to lp). thanks, I'll ask in #launchpad
#bzr 2013-10-10
<dsmythies> The revision date and time details seem to be based on the changelog entry and not on when the package import robot actually executed. Is there a way to determine when the import actually occurred and what upstream revision it imported?
<dsmythies> Reference 1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntu-docs/saucy/revision/113
<dsmythies> Reference 2: https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntu-docs/saucy  (where rev 113 actually appeared on or about October 4th, not September 16th)
<dsmythies> Reference 3: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/saucy  (where, as best as I can determine, rev 113 above seems to be based on upstream rev 274, but should have been rev 275)
#bzr 2013-10-11
<jmo> hi, could somone please help me a bit regarding running hooks on the remote bzr server when using bzr+ssh to commit?
<jmo> I wrote the question in so yesterday but I'm not sure that's a good place for a bzr question http://stackoverflow.com/questions/19297347/bazaar-hook-to-check-commit-message-on-server
<jmo> basically what i'm trying to do is to have a hook on pre_commit but it seems to be ignored when checking in remotely
<jmo> everyone asleep or was my question severly broken?
<vila> jmo: probably both ;) Joke aside, I'm not sure I understand your question. commits happen locally, so a pre_commit hook on the remote host does not make a lot of sense
<vila> jmo: if your local branch is bound then a push is performed after the local commit
<vila> jmo: so if you do a commit, the remote host only sees a push
#bzr 2013-10-13
<Waka_Flocka> anyone know how i can get my password for bzr?
<Waka_Flocka> its a key thingy
#bzr 2014-10-08
<sophomore> Hello
<sophomore> Where to get the bzr viz command on Debian?
<smoser> wasn't obvious to me where this came from
<smoser> but
<smoser>  https://bugs.launchpad.net/ubuntu/+source/bzr-fastimport/+bug/1378921
<ubot5> Ubuntu bug 1378921 in bzr-fastimport (Ubuntu) "bzr fastexport stacktraces" [High,Confirmed]
<smoser> ah. i see. dupe of bug 1295833, but unforutnately still not fixed in ubuntu :-(
<ubot5> bug 1295833 in bzr-fastimport (Ubuntu) "Import error in exporter.py - fastimport.helpers" [High,Triaged] https://launchpad.net/bugs/1295833
<smoser> jelmer, is that fixed in debian ?
<smoser> oh. i see your comment. wonder why no longer present in debian.
#bzr 2014-10-11
<LeoNerd> bzr up -r46; (works). bzr revno => prints 51, because that's the most recent commit in the branch. How do I see what revno my actual workdir is on?
<LeoNerd> I'm manually bisecting
<fullermd> revno --tree
<LeoNerd> Ah! lovely
