#bzr 2008-03-17
<moebius_> (btw, the error is when doing a "bzr branch" using any bzr+http:// URL scheme)
<nxvl> is someone already working on git2bzr convertion??
<poolie> nxvl: yes, there's a fastimport reader, see list
<poolie> moebius_: i don't recall it
<poolie> can i suggest trying 1.3rc1 though
<james_w> moebius_: it seems like a bug to me, so please file it with the full traceback. If you can test with 1.3rc1 that would be great.
<james_w> nxvl: hi
<nxvl> james_w: hi!
<james_w> nxvl: how are you?
<nxvl> james_w: fine, finishing with all my papers for attending to UDS and looking for a python project to work on :P
<nxvl> james_w: also waiting for the mentors list for GSOC being published tomorrow :P
<james_w> nxvl: you're going to UDS? Great!
<james_w> you know bzr is a python project?
<nxvl> james_w: yep, that's why i'm here :D
<james_w> ah, great!
<nxvl> just starting to read the documentation and browsing the code
<james_w> nxvl: are you interested in git->bzr conversion?
<nxvl> james_w: yep
<james_w> I think it would make a great project.
<nxvl> james_w: i find it a nice and not so hard feature to start with
<james_w> well, a few parts will be a bit tricky in terms of learning the bzr API.
<nxvl> btw, is bzr going to be part of GSCO?
<nxvl> james_w: yep, but is easier that learn the bzr code ;)
<poolie> nxvl: no, we're going to do our own student projects through canonical
<nxvl> than*
<poolie> are you interested
<james_w> the rest will just be coming up with ways to not store the 300MB source repository in memory as you go.
<nxvl> poolie: yes of course
<nxvl> poolie: is there already a wiki or web where i can look for those?
<james_w> poolie: nxvl is a cool Peruvian LoCo team member for Ubuntu.
<james_w> He's also involved in MOTU.
<james_w> and loads of other stuff I'm sure :)
 * nxvl HUGS james_w 
 * james_w hugs nxvl back
<poolie> :)
<moebius_> james_w: I will test 1.3rc1 and fill the bug, thanks
<james_w> moebius_: great, thanks.
<james_w> nxvl: I don't think there's any sort of list or anything yet, I'm not sure how far along the planning is.
<james_w> nxvl: I'm sure there is a bunch of project ideas lurking around somewhere.
<nxvl> james_w: on the bzr list there is some info, i have just found it, but is more on fastimport on windows :S
<james_w> that's just one problem someone bought up, we're keen to have it work on every platform.
<nxvl> james_w: isn't so hard with python
<nxvl> :P
<james_w> that's the idea.
<james_w> I can't find a list of project ideas on the wiki, if you are keen for others I'm sure we can generate some.
<nxvl> mm
<nxvl> i have just had it open
<nxvl> let me check my history
<poolie> the SummerOfCode page is old, I just renamed it
<james_w> though I think the fast-import one is great, as it is a useful tool, not too involved with the core, but would possibly involve adding some changes to core code to make it more efficient.
<nxvl> james_w: http://bazaar-vcs.org/SummerOfCode2007
<james_w> ah, I only looked at the top, so I didn't realise the list was there.
<moebius_> james_w: 1.3rc1 works for me doing exactly the same operation as before
<poolie> moebius_: meaning it reproduces the bug, or it works?
<moebius_> it works
<poolie> great
<moebius_> no error with 1.3rc1
<moebius_> the branch op gets done ok
<james_w> moebius_: great, thanks for testing.
<lifeless> dato: bzr-hookless-email is quite slow for me; I'll look at it in my copious spare time
<lifeless> abentley: ping
<nxvl> james_w: that happends here also, but when i was looking for what has been done last year i found the list :D
<moebius_> no problem, i like to help with those things
<moebius_> and bzr is so good it deserves some love :D
<james_w> moebius_: bzr loves you too :-)
<moebius_> should I report the bug in the 1.2 series?
<james_w> I don't think it's likely to get fixed as 1.3 is so close, so the only reason would be documentation in case anyone else fixes it.
<james_w> moebius_: if you want to report it I would be happy to mark it fixed in 1.3 with an explanation.
<poolie> moebius_: generally once we've made a new release we don't worry about older bugs
<poolie> as james says
<moebius_> ok, I will report it, just for documentation
<moebius_> also, if someone hits the same bug, will know he can use 1.3
<nxvl> what is bzrk?
<james_w> I think it means bzr-gtk
<nxvl> oh! ok
<lifeless> bzrk is 'bzr viz'
<james_w> hi lifeless
<nxvl> james_w: thx
<james_w> lifeless: I have both the bzr and git emacs trees here and guess which is smaller?
<james_w> you rock!
<poolie> way to go
<james_w> apparently the git one has some merge information added, so I don't know how much that will have added
<james_w> although the git log >/dev/null time is pretty amazing.
<lifeless> james_w: which ?
<james_w> lifeless: bzr of course :)
<nxvl> lifeless: thnx
<lifeless> james_w: thats pretty surprising
<lifeless> nice, but suprising
<poolie> if they've recorded merges from other branches and we have not that might be part of it
<james_w> 292M/333M
<lifeless> we are rather bad with merges today
<poolie> well, that may be down to the way the import was done
<james_w> although there are perhaps more branches in git, so I may not be being fair.
<james_w> I didn't look properly last time, so I thought there was only one.
<awmcclain> james_w: Remember yesterday when I was asking you about bzr configuration values? Seems like branch.conf doesn't work for bzr-email either.
<james_w> awmcclain: hmm, sorry about that.
<lifeless> awmcclain: hum, I consider that a bug. Can you please file a bug on bzr-email about that
<awmcclain> Either that or it DOES work and I'm don't have it configured somewhere else.
<awmcclain> s/I'm/I
<lifeless> lets assume you've done it right
<awmcclain> I'm going to try a conf var in a user directory next
<lifeless> I'll gather debugging stuff as needed via the bug
<james_w> poolie: thanks for the tips on that debugging.
<awmcclain> Is there any documentation about bzr configuration stuff?
<lifeless> the user guide
<james_w> poolie: did you see John's bug about upgrading bzr.dev to -subtree? It looks like it may be the same thing.
<poolie> not yet
<james_w> awmcclain: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#configuring-bazaar
<moebius_> I believe the bug report should be ok: https://bugs.edge.launchpad.net/bzr/+bug/203031
<ubotu> Launchpad bug 203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New]
<moebius_> haha, the bot catched me
<moebius_> xD
<moebius_> it is my first bug report, so please do not spank me if it is not well done
<poolie> moebius_: you can mark it fixreleased if you like
<james_w> I'll do it.
<ubotu> New bug: #203031 in bzr "Branching over bzr+http fails with AttributeError" [Undecided,New] https://launchpad.net/bugs/203031
<james_w> moebius_: thanks
<james_w> moebius_: and it was a good bug report, make them all like that and you won't have any problems :-)
<moebius_> james_w: great! now time to sleep... it's somewhat late here in europe :D
<james_w> moebius_: indeed it is. I must sleep too, thanks for the reminder.
<james_w> night all.
<moebius_> i could say the same, good night and be happy.
<poolie> james_w, nxvl: i posted http://bazaar-vcs.org/StudentProjects
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing |
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3rc1 available for testing | http://launchpad.net/bzr/1.3/1.3rc1
 * poolie looks at bzr ssh locking bugs with jml
<lifeless> in soviet russia ssh lock bugs you
<poolie> it does bug me
<lifeless> are you in soviet russia?
<lifeless> knit proposal sent to list for rfc
<Odd_Bloke> james_w: Could you push your branch implementing the workaround option for bug 172657 to LP and link it to the bug?
<ubotu> Launchpad bug 172657 in bzr "bzr status after merge slower with packs" [Medium,Fix committed] https://launchpad.net/bugs/172657
<lifeless> poolie: branch made
<poolie> thank
<poolie> lifeless: i'm suggesting we should fix the bzr+ssh leftover locks bug by making the client control polling for the lock, rather than the server
<poolie> what do you think?
<lifeless> what happens today?
<lifeless> Does the smart server verb not disable polling ?
<lifeless> how often do we poll ?
<poolie> i believe the server does the polling, from what jml tells me
<poolie> will check
<lifeless> so
<lifeless> if we poll 1/sec
<lifeless> then I think its ok for the client to do it, but not optimal resource wise
<lifeless> if we poll 5/sec, then server load will be even more significant
<lifeless> I don't see why the client should do network traffic to ask the server 'are we there yet'
<poolie> it's less than once per second
<lifeless> is the root problem 'client disconnections are not noticed' ?
<jml> no.
<jml> interrupting a bazaar client that's waiting for a lock does not cause a client disconnection
<jml> because it doesn't interrupt the ssh process.
<lifeless> jml: well, sounds like its the same thing at the top level - the bzr client has gone away, but the server doesn't know this
<lifeless> jml: and the client has gone before the lock was acquired
<jml> yes, that's right.
<poolie> lifeless: it's partly that, and partly that at the moment the client gets no indication that anything is happening
<poolie> so, we can't display progress to the user for example
<lifeless> so the race condition is the window between 'rpc_send obtain_lock' and 'rpc_reply lock_obtained' being sufficient for the client to go away.
<poolie> nor can it cancel the request once it's sent for that matter
<poolie> lifeless: that's ok; it's comparable to a dangling lock over another protocol
<lifeless> poolie: sure, I'm just making sure I have a clear understanding
<lifeless> poolie: if I said what I think about some imaginary situation, it wouldn't help much :)
<jml> (user runs bzr push, bzr push waits for lock, user hits control-c, bzr dies, ssh keeps running, user runs break-lock, stale ssh acquires the lock)
<lifeless> jml: (user runs bzr push, push gets lock, user hits contorl-c, bzr dies, ssh keeps running ?) ?
<jml> that's the use-case that I'm particularly interested in
<lifeless> jml: I'm postulating that actually there is a significantly broader group hitting this than you realise
<jml> lifeless: not sure what happens in that situation. easy to find out though.
<lifeless> jml: e.g. what is special about lock waiting that stops bzr cleaning up ssh
<jml> lifeless: maybe. what's the significance if that's so?
<lifeless> jml: it means that the folk seeing the problem are not people waiting on lock contention
<lifeless> jml: but rather folk seeing little/no progress on push, or interrupting push
<jml> lifeless: that's not the reported bug.
 * jml does an experiment or two
<lifeless> jml: I know its not the reported bug. But imagine for a second that everyone that reports the bug has actually hit it first on push on the branch, and then when they try to diagnose they have their own stale lock already present.
<lifeless> poolie: so, what do I think. I think several things.
<lifeless> poolie: I think that bzr's client code is already correct re: lock cleanup, so really fixing this ssh handling is the most important thing to do, as it smells like the end of a thread of related issues to me.
<lifeless> poolie: I think that repeated network round trips to poll is rather ugly, as event based operations are so much cleaner, requests to the server have a cost, and polling designs are well known to scale poorly.
<lifeless> poolie: I think the lack of UI feedback is fixable without restoring to network polling; just displaying the progress bar immediately with 'obtaining lock' would do it for instance.
<lifeless> and only doing that on non-local urls seems reasonable to me.
<jml> hitting ctrl-c during push kills the ssh process
<jml> at least, it does when I hit it :)
<lifeless> so, I consider the ssh not being killed during lock obtaining a severe bug
<lifeless> its got all sorts of implications
<poolie> killing the ssh client is not a reliable way to avoid this
<lifeless> poolie: indeed; removing the network is the only way :)
 * jml starts hacking on the ansible
<jml> (imagine the TF2 ping times!)
<lifeless> poolie: you could as an immediate quick fix just set the poll time to 0 on the smart server verb
<lifeless> poolie: I think this is not really a good idea, but it would stop the polling on the server side
<lifeless> e.g. just doing this on launchpad, today, would prevent the situation probably
<lifeless> I realise that this is roughly what you were suggesting.
<poolie> for me the ssh client being killed or not, while good to fix, is not essential, because the same bug can occur withotu it
<poolie> the problem is that the server is polling on its own account, and that should be controlled by the client
<lifeless> poolie: well, I disagree that it should be controlled by the client.
<poolie> perhaps in the medium term we want to avoid lock operations going across the network at all?
<lifeless> we only lock branches today
<lifeless> and locking a branch is a human level action, not a bzr level one
<lifeless> if that makes sense
<lifeless> we could do some fancy nonce based stuff to detect collisions during a branch level operation
<lifeless> yay loggerhead, you go greedy thing
<lifeless> 930M
<lifeless> mwhudson: can we get some patch to loggerhead to dump objet allocation stats to the log once an hour or some such ?
<lifeless> also
<lifeless> its running python2.4
<lifeless> IIRC 2.5 has the ability to free() memory
<lifeless> which might be useful.
<poolie> that will probably cause some complaints from IS - it may need a distro upgrade
<poolie> probably worth it though
<lifeless> they would love not having to stab loggerhead routinely
<poolie> sigacly
<lifeless> its running 6.01.1
<lifeless> 2.5 is not installed, we can likely get a backport though
<poolie> that's dapper?
<poolie> they say it is infeasibly hard to backport it
<lifeless> oh
<lifeless> meh, we can surely get a > dapper VM, or a distro upgrade
<lifeless> SEP :)
<poolie> will send mail
<lifeless> lunching
<mwhudson> lifeless: that sounds like a good idea
<lifeless> mwhudson: which, the patch or 2.5 ? ;)
<mwhudson> lifeless: the patch
<mwhudson> i'd be a little surprised if 2.5 made much difference
<lifeless> mwhudson: when did python start calling free()?
<mwhudson> lifeless: probably 2.5, i don't really remember
<mwhudson> but i don't think this will make much difference to the loggerhead situation
<mwhudson> if entire arenas are free, python <2.5 will still reuse them
<lifeless> mwhudson: it will make peak/current memory usage clearer to the os
<mwhudson> and if they're not free, python >=2.5 will not free them
<lifeless> how big is an area ?
<lifeless> arena
<mwhudson> well, it's possible it will make things clearer, i guess
<mwhudson> i would offer money that it would not really help much though
<mwhudson> er, 256k i think, not sure though
<lifeless> so
<lifeless> I think it unlikely that in 930M of vss
<lifeless> that a majority of 256k regions are not empty, unless there is a genuine leak
<mwhudson> eh
<poolie> iirc 2.5 had more allocator improvements beyond just using free
<mwhudson> if they are empty, then when loggerhead needs to allocate more objects, it will use an empty arena
<lifeless> mwhudson: sure, I get that
<lifeless> mwhudson: anyhow, 2.5 won't harm.
<mwhudson> this is extremely likely
<poolie> lifeless: i got "Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.3"
<lifeless> poolie: doh. one sec
<lifeless> poolie: fixed
<poolie> thx
<lifeless> yay nm borked
<lifeless> now have to run iwconfig
<lifeless> remind me why we have a gui ?
<poolie> lifeless: just as you said that my network collapsed :/
<lifeless> ha!
<lifeless> poolie: I'm out; ciao.
<awilkins> jelmer: Did you manage to solve that pyrex issue you had? I had a go at building the branch you had on Win32 ; it's not fun (and I've not succeeded yet).
<awilkins> ls
<Odd_Bloke> .   ..   .bzr
<fullermd> Eek!  It's a nekkid branch!  Avert your eyes!
<awilkins> Arse, our decent HTTP proxy is down (ie, the one that doesn't demand NTLM auth to get out)
<awilkins> Meh, you know when you've been using vi to much when you try to quit every text editor with :wq
<fullermd> Oh, that's nothing.  Wait 'till you get stuck in front of Word one day, and see how it reacts to Esc getting smacked all the time...
<bob2> disturbingly deals ok ctrl-x ctrl-s every few seconds
<jelmer> awilkins: I've just pushed the branch I'm currnetly using
<jelmer> that should at least build ok
<jelmer> you may have to fix the include dir detetion code in setup.py
<awilkins> jelmer: Judging by the fun I had on Friday with it, definitely
<awilkins> jelmer: Although I think I may have been overzealous with includes and libs, I might have been increasing my dependency nightmare
<awilkins> jelmer: Was trying with both MS 7.1 compiler and MinGW
<awilkins> Both have different issues
<jelmer> you
<jelmer> 'd need both the apr and svn libraries
<awilkins> I got the "deps pack" for svn 1.4.6 win32
<awilkins> But I'm not sure it has enough .lib files in it :-)
<awilkins> Anyway, I think it wil lhave to wait until later, my build environment is at home
<awilkins> APR builds easily on Win32, I wish SVN would take a leaf out of their book.
<awilkins> The best help they had to offer in #svn-dev was "good luck with that"
<Peng> Wait a minute.
<Peng> bzr-svn creating thousands of packs and instantly repacking them on a mostly-full file system can't be healthy for it.
<jelmer> re
<jelmer> Peng: well, a part of the problem is that the API provides no way to indicate that you're going to write a bunch of revisions
<Peng> I wasn't complaining about the repacking, just thinking "augh, my poor hard drives".
<jelmer> instead of just one
<Peng> How does something like "bzr pull" only write one pack then?
<james_w> well, that's pull not commit.
<james_w> currently when you do a commit it writes one pack.
<Peng> Yeah..
<james_w> jelmer: we need to get bzr-svn in hardy sorted.
<Peng> So what would be useful is being able to tell commit "don't save it yet, I'm about to commit again!"?
<james_w> I don't know if bzr 1.3 will get in to hardy, so we may have to instead put some bzr-svn package in.
<jelmer> james_w: ah, ouch
<jelmer> james_w: what is going to determine whether 1.3 will make it into hardy?
<james_w> jelmer: whether the release team allow it.
<jelmer> james_w: ah, ok
<james_w> the general rule is bug fix only releases.
<jelmer> bzr-svn 0.4.7 works with bzr 1.2
<jelmer> it just warns you
<james_w> so we should just disable the warning?
<jelmer> so I guess one option would be to simply upload a new ubuntu package that adds (1,2) to the list of supported bzr versions
<jelmer> or I could release 0.4.8, which would also help debian
<james_w> I thought 0.4.8 would be 1.3 compatible
<james_w> or is it both?
<jelmer> well, I was planning on making 0.4.8 1.3 compatible
<james_w> Solving it in Debian is obviously important as well, but hardy is a little more pressing.
<james_w> I think for Debian dato will upload the 1.3rc1 soon, so a bzr-svn release for 1.3 would work fine.
<jelmer> k
<jelmer> james_w: I guess just adding (1,2) to the list of supported bzr versions in the bzr-svn ubuntu package should fix things then
<jelmer> afaik Martin Pitt already loosened the dependencies of the package itself
<james_w> ah, ok.
<james_w> I'll try and do that this week.
<ubotu> New bug: #203152 in bzr ""bzr merge --pull" does not list changes" [Undecided,New] https://launchpad.net/bugs/203152
<dato> james_w: uploaded
<james_w> dato: great, thanks.
<james_w> spiv: did you see that Toshio says he is at pycon? Maybe you guys should try and catch up with him.
<james_w> I think good relationships with distro packagers are very beneficial
<james_w> isn't that right dato :)
<dato> heh
<ubotu> New bug: #119265 in trac-bzr "branch w/o commits produce traceback" [Medium,Fix released] https://launchpad.net/bugs/119265
<elmargol> Hi, is there a way to resume a svn branch import?
<igc> morning
<james_w> elmargol: with bzr-svn?
<elmargol> james_w: :( i try to import a 4000r svn repository
<james_w> elmargol: if you have a partial branch on disk then you can bzr pull, if not I think you may have to start over.
<james_w> elmargol: what error did it fail with?
<elmargol> I retry it...
<elmargol> don't have the errormessage anymore
<spiv> elmargol: with bzr-svn, it's best to do the branch inside a repo made with "bzr init-repo --rich-root-pack", because then you can resume very easily.
<jetsaredim> can someone explain the following error??  http://dpaste.com/39805/
<jelmer> jetsaredim: you didn't specify a branch name
<dato> jetsaredim: ~jetsaredim/mplayerplug-in is an area to put branches related to mplayerplug-in
<dato> it can't itself be a branch
<jetsaredim> ahh
<spiv> That message from Launchpad could be clearer.  I'll file a bug.
<jetsaredim> so i need to call it something after that
<elmargol> spiv: how do I resume?
<dato> jetsaredim: yes. e.g. ~jetsaredim/mplayerplug-in/bug-123 or ~jetsaredim/mplayerplug-in/mine, or whatever
<jetsaredim> gotcha
<jetsaredim> thanks
<jetsaredim> and yes, that could be a little clearer
<spiv> jetsaredim: bug 203178 filed.  Thanks for the report.
<ubotu> Launchpad bug 203178 in launchpad-bazaar "Unclear error when pushing over bzr+ssh: "This method is only for creating branches:"" [Undecided,New] https://launchpad.net/bugs/203178
<spiv> elmargol: If the branch is inside a repo, then you can just delete the branch and re-run the bzr branch command.  The already converted revisions will be stored in the repo, so it won't need to convert them again.
<jetsaredim> spiv: that was fast
<elmargol> http://dpaste.com/39808/
<elmargol> james_w:
<james_w> elmargol: can you do "svn ls https://svn.participatoryculture.org/svn/dtv" ?
<elmargol> http://dpaste.com/39811/
<ubotu> New bug: #203186 in bzr "authentication.conf isn't used with openssh" [Undecided,New] https://launchpad.net/bugs/203186
<james_w> so yes.
<james_w> I'm not sure I'm afraid.
<james_w> jelmer: do you have any ideas about this.
<elmargol> this happened after 600-700 revisions
<james_w> these propfind errors seem familiar.
<spiv> I think it's probably an intermittent error.
<james_w> maybe that's just how a lot of errors manifest themselves
<spiv> i.e. a temporary network glitch causing a request to fail at random.
<james_w> elmargol: can you "bzr branch  https://svn.participatoryculture.org/svn/dtv/trunk" ?
<elmargol> yes
<james_w> elmargol: is that sufficient for your needs, or do you need the whole import?
<elmargol> its ok for me if it works...
<elmargol> i think it will crash... after some time
<james_w> ah, sorry, I thought you were saying that you could.
<elmargol> http://dpaste.com/39815/
<james_w> elmargol: I'm not sure I'm afraid.
<james_w> would you file a bug containing the trackebacks that you get please?
<elmargol> sure
<elmargol> https://bugs.launchpad.net/bzr/+bug/203190
<ubotu> Launchpad bug 203190 in bzr "bzr svn-import fails" [Undecided,New]
<ubotu> New bug: #203203 in bzr-loom "bzr nick breaks loom" [Undecided,New] https://launchpad.net/bugs/203203
<james_w> beuno: you'll never guess what, I just successfully build sid's baz in an up to date sid chroot.
<beuno> james_w, wha?  really?  how!?
<james_w> beuno: no idea. Just downloaded it and built it intending to get a shell with the failed build and it worked.
<james_w> I'm going to try it on hardy now.
<beuno> james_w, cool. Let me know if you want the files we worked on
<james_w> beuno: yeah, they would be useful.
<james_w> beuno: I think I can grab them from your PPA, let me look.
<james_w> ok, I can get the baz one.
<james_w> Did we do anything to bazaar-doc or bzr?
 * beuno checks
<beuno> james_w, we did bazaar-docs
<beuno> I can zip that up and send it over
<james_w> beuno: yes please.
<beuno> james_w, sent
<james_w> beuno: thanks.
<beuno> james_w, good luck, and let me know if I can help you
<james_w> thanks
<beuno> vila, you rock  ;)
<james_w> beuno: it fails in hardy still
<beuno> james_w, that's odd. Can you pinpoint it to the same library that failed before?
<james_w> beuno: what do you mean?
<beuno> james_w, there was a specific library that made it fail
<beuno> which we tried to track down what was the last version it built with
<beuno> lifeless pointed it out
<james_w> beuno: I thought that was just a hunch.
<beuno> he seemed pretty sure that they broke their ABI
<james_w> oh yeah, they definitely did that.
<jetsaredim> is it possible to see the progress in % for a push?
<james_w> igc: nice work with the fast-import fix
<igc> james_w: please test!!!! It was a **BAD** bug
<james_w> igc: did you see that the memcached guy confirmed that it worked for him?
<igc> no I hadn't - thanks for the update
<james_w> I've looked at that HACK before, it appears to be what makes the changed files not show up as modified: after in the log.
<igc> yep
<james_w> is that fixed by this change as well?
<igc> should be
<james_w> cool, I'll test that.
<jelmer> 'evening *
<jelmer> igc: using RevisionLoader seems to definitely help bzr-svn
<igc> hi jelmer - what sort of difference?
<ubotu> New bug: #203287 in bzr-loom "unable to create a new bottom thread" [Undecided,New] https://launchpad.net/bugs/203287
<ubotu> New bug: #203285 in bzr-loom "unable to "de-loom" a branch" [Undecided,New] https://launchpad.net/bugs/203285
<jelmer> igc: I haven't done any benchmarking yet
<spiv> jelmer: when's the 0.4.8 release btw?  People at PyCon keep asking :)
<lifeless> james_w: neon breaks that test; it was memory not a hunch
<james_w> lifeless: ah, sorry for doubting you.
<james_w> lifeless: however it works on sid now. I think the failure there was for a different reason originally though
<james_w> lifeless: I'm talking to a couple of people about bzr-loom on #vcs-pkg/freenode at the moment.
<unenough> hi, I have a shared repo with some repos inside
<unenough> can i somehow see the tree for the whole shared repo? that is showing merges between sub-repos
<unenough> ooooooops
<unenough> i mean: repo (instead of shared repo) and branches (instead of "repos")
<james_w> unenough: no, there's no tool to visualise a set of branches yet unfortunately.
<mpt> Hi, I've installed bzr-loom and it shows up in "bzr plugins", but when I branch a branch that's in loom format, I still get "bzr: ERROR: Could not understand response from smart server: ('error', "Unknown branch format: 'Bazaar-NG Loom branch format 1\\n'")"
<mpt> Is there something else I need to do?
<james_w> mpt: is loom installed on the server?
<james_w> hi mpt btw
<mpt> hi :-)
<mpt> I don't know whether loom is installed on the server, it's not my server
<mpt> How would I find out?
<james_w> ah, the message seems be suggesting that it isn't
<james_w> what protocol are you using to branch?
<mpt> Oh, so it's the server that's giving that "Unknown branch format" error, not my copy of bzr
<mpt> I don't know what protocol I'm using to branch, I'm just using "bzr branch"
 * mpt is a bear of very little brain
<mpt> Ok, so I SSHed to the server and its copy of bzr doesn't have bzr-loom installed
<mpt> thanks for the help
<james_w> mpt: the protocol would bzr bzr+ssh:// or something.
<mpt> oh, right
<mpt> yes, bzr+ssh
<mpt> oh, I could use sftp:// instead?
 * mpt tries
<mpt> then bzr on the server wouldn't need to get involved at all
<james_w> mpt: good idea
<nxvl> james_w: hi!
<james_w> I was asking to know if you had ssh access to the server
<james_w> hi nxvl. how are you?
<nxvl> good, working on some packages, and at work
<james_w> cool
<mpt> hurrah
<mpt> thanks james_w
<nxvl> this has been the first light day after a really hard week
<nxvl> james_w: did you know something about the canonical summer of code poolie mention last time
<james_w> mpt: glad it works
<nxvl> james_w: i have ask to dendrobates and dholbach, and non of them seems to know anything
<james_w> nxvl: I don't know anything, sorry.
<nxvl> mm, it seems that no one know, so it mustn't going to run this year :S
<james_w> nxvl: I don't know if Ubuntu is doing it as well, I just saw that they weren't on the GSoC list.
<james_w> I think it's a pretty recent idea, so it might be because people haven't heard yet.
<nxvl> james_w: yep, but last time i was here poolie mention something about a running a student program thru canonical
<james_w> nxvl: that's what I mean
<james_w> nxvl: I think that idea is quite new.
<nxvl> mm
<nxvl> ok, i will give a try to gsoc this year on a debian project, and next year maybe on canonical program
<nxvl> :P
<james_w> nxvl: if you are interested you could send an email to the list to say that.
<nxvl> james_w: the bzr list?
<james_w> yep
<nxvl> mm
<james_w> unless you're more interested in Ubuntu
<nxvl> actually yes
<nxvl> i'm more interested in ubuntu
<james_w> ok
<nxvl> but i'm also interested on bzr, but is still 2nd on my list
<nxvl> :S
<lifeless> james_w: still on vcs-pkg  ?
<james_w> lifeless: I am, but the discussion has petered out.
<lifeless> james_w: I dont see anyone in that channel
<lifeless> james_w: #vcs-pkg right ?
<lifeless> dato: bzr-hookless-email seems to set From and Sender
<lifeless> dato: is that deliberate?
<james_w> lifeless: did I say freenode?
<james_w> sorry, I meant OFTC.
<james_w> How do I force urllib?
<TFKyle> james_w: to do what?
<james_w> To force bzr to use urllib for http connections?
<Peng> http+urllib, I think
<TFKyle> ah, the http+urllib:// protocol iirc
<Peng> I think I've been using pycurl recently. No problems so far.
<james_w> https+urllib://
<james_w> I was trying to use my 0.14 client on my server to tell me, and wondered why it had so few help topics.
<TFKyle> Peng: used to be a problem with it branching from certain lighttpd instances, think it was related to lighttpd not doing certain range requests
<Peng> Huh.
<Peng> Also, there's stuff like it being bad about getting Ctrl+Ced or something.
<Peng> james_w: Heh, oops.
<james_w> It doesn't like SSL certificates it can't verify as they are self signed or it is missing the CA cert.
<Peng> Ah.
<Peng> Well, that's a good thing.
<Peng> Python will gain cert verification in 2.6.
<dwon> I created a project in bzr, and now I'm trying to svn-push it into a new svn repository, but I get "These branches have diverged. Use the merge command to reconcile them.".  With some fiddling, it looks like I can get it to merge my entire tree in one svn revision, but I'd like to get the revision history into subversion.  Is it possible?
<TFKyle> Peng: really? bug/commit link?
<Peng> TFKyle: There's an "ssl" module, AFAIK.
<Peng> dwon: Wait, what? Why not push it to, y'know, bzr?
<james_w> Peng: that is a good thing, except when the user can't override it.
<dwon> Peng: because everyone else at the company I work for uses svn
<Peng> james_w: Indeed.
<james_w> dwon: it should be possible. I'm not sure why you get that error.
<TFKyle> Peng: ah
<james_w> dwon: you could file a bug with as much information as you can.
<james_w> dwon: in particular an "svn ls URL_you_are_trying_to_push_to" might provide a hint.
<james_w> and svn log of that too.
<james_w> you can obscure filenames if that is a problem for you.
<TFKyle> Peng: hmm, from a quick look at the ssl module it looks like it's up to the person using it to validate the cert
 * TFKyle could be blind and wrong though
<Peng> TFKyle: Does urllib2 use it, though?
<TFKyle> or httplib rather, not sure :)
<TFKyle> (urllib uses httplib under the covers for http connections :))
<james_w> urllib ignores certificates, I know that much
<lifeless> poolie: /win 50
<lifeless> meh sorry
<lifeless> poolie: I'm going to be chasing knits today
<TFKyle> looks like httplib uses it if available, doesn't do checking itself though
<TFKyle> (in current svn trunk anyway, might be a bug adding checking if nothing does already)
<lifeless> dwon: for a new svn branch use 'svn-push'
<dwon> lifeless: Did that
<TFKyle> hmm, actually I'm probably blind and ssl/_ssl actually do do it
<TFKyle> (assuming you give it a proper ca_certs arg
<TFKyle> (and cert_reqs)
<poolie> lifeless: did you see jml around yet?
<poolie> he said he was still jetlagged...
<Peng> jelmer: Would your new svn Python bindings be useful to other projects?
<jelmer> Peng: yep, they're more python than the original bindings
<jelmer> *pythonic
<TFKyle> mm, they're in bzr-svn or?
<Peng> TFKyle: http://people.samba.org/bzr/jelmer/bzr-svn/pyrex/
<Peng> jelmer: Cool.
<jml> yes, I'm around
<jml> poolie: I said I was still very tired :)
<jml> I'm uncertain as to whether this constitutes jetlag.
<poolie> me too
<poolie> i want to go out to the vet
<poolie> (doctors can't help me anymore :-)
<poolie> but did not want to leave you standing outside
<poolie> if you were coming over
<jml> poolie: that's ok. I'm waiting for thumper to get back
<dwon> james_w: https://bugs.launchpad.net/bzr/+bug/203365
<ubotu> Launchpad bug 203365 in bzr "Can't create new svn branch from a bzr branch" [Undecided,New]
<spiv> jelmer: "bzr svn-push" does weird things if the branch has no new history (e.g. bzr branch svn://.../trunk new-branch; cd new-branch; bzr svn-push svn://.../branches/new-branch)
<ubotu> New bug: #203365 in bzr "Can't create new svn branch from a bzr branch" [Undecided,New] https://launchpad.net/bugs/203365
<lifeless> man npviewer.bin must die
<lifeless> keeps using 99% cpu
<RAOF> lifeless: I see you're another member of the x86-64 self-flageltion society :(
<lifeless> RAOF: users -> bug reports -> fixed software
<lifeless> or thats the theory
<lifeless> RAOF: have you filed a bug ?
<jml> poolie: so, when would be a good time to come over?
<slangasek> jelmer: so if I'm getting backtraces with bzr-svn trying to merge into the grub branch that was 'bzr join'ed, is this a bzr-svn bug, or a grade-A Fail of the unsupported join functionality? :)
<poolie> hm i still haven't left
<poolie> but if you plan to arrive at 12 that should be ifne
<poolie> jml, or even a bit earlier
<jml> poolie: ok.
<ubotu> New bug: #203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Undecided,New] https://launchpad.net/bugs/203368
<RAOF> lifeless: I've filed a number of bugs against nspluginwrapper.  Some have even been fixed!
<lifeless> slangasek: file a bug with the backtrace ?
<lifeless> RAOF: was one of them 'insane battery use' ?
<RAOF> No, I don't believe so.  The one I was particularly thinking of is "crashes when there's lots of flash"
<RAOF> I should probably follow that up.  The debian package has it fixed (by actually initialising glib's thread support before using threads, IIRC).
<slangasek> lifeless: if I'm not going to get glared at for using undocumented and unsupported features, ok ;)
<lifeless> slangasek: we want to make it supported
<lifeless> slangasek: as long as you don't expect it to be fixed, bug reports on this stuff are good
#bzr 2008-03-18
<Peng> Wait, what about plugins?
 * Peng wanders off.
<slangasek> lifeless: there you are then
<jelmer> spiv: Hmm, that's an interesting bug
<jelmer> slangasek: I can't think of a reason a by-value joined tree wouldn't work
<spiv> jelmer: something weird also happened when there were revisions
<spiv> jelmer: it pushed ok, but the merge to trunk caused some sort of property conflict
<jelmer> spiv: That's the bit I mean
<jelmer> spiv: bzr svn-push can't use a clean "svn cp"
<spiv> jelmer: hmm, why not?
<jelmer> spiv: if there is a branch A with tip revision 42 and you're trying to push a branch B that also has tip 42 it has to do a copy of r41 -> /B that replays the changes in r42
<jelmer> otherwise the two branches actually have a different revision history
<jelmer> A has tip 42 and B has tip 42+1 where rev 1 is en empty commit that changes the branch nick from A to B
<ubotu> New bug: #203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376
<jelmer> slangasek: thanks
<jelmer> spiv: ^
<spiv> jelmer: hmm, because you can't easily figure out that the tip 42 in B happens to be the same as 42 elsewhere in the repo?
<jelmer> spiv: I can figure that out, but the problem is that B has more revisions than A
<jelmer> the commit that contains the "svn cp" will show up as well
<spiv> Ah, the impedence mismatch, because making a branch in bzr doesn't make a revision.
<spiv> But in svn it does.
<spiv> I think I see.
<jelmer> yep, that's a clearer way of explaining it
<lifeless> so a cp that makes no alterations should not generate a revision in the mappings
<lifeless> :)
<jelmer> lifeless: yep, but there are performance considerations there
<radix> hay guise
<radix> sry for bzr-svn bgz
<spiv> jelmer: I think I'll recommend people like the Twisted guys should just keep using "svn cp" for the initial branch in the repo.
<ubotu> New bug: #203381 in bzr-svn "Error when pushing 0.4.8 to a branch that exists in svn." [Undecided,New] https://launchpad.net/bugs/203381
<lifeless> jelmer: btw, your versionedfile thunks in bzr-svn will need updating soon :)
<jelmer> spiv: Makes sense
<jelmer> spiv: We could potentially add a create-svn-branch command
<jelmer> lifeless: Which thunks? :-)
<spiv> jelmer: yeah, I was thinking about that.  I'm not sure if I like the idea or not :)
<lifeless> jelmer: do you not have an implementation of repo.text_store.get_weave ?
<mxpxpod> I'm trying to convert a git repo to a bzr repo and I'm running into the same problems described here: https://bugs.launchpad.net/bzr-git/+bug/181811
<ubotu> Launchpad bug 181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New]
<mxpxpod> the problem is that when I do the last instruction, it tells me that my converted directory isn't a branch
<lifeless> mxpxpod: I suggest you look into bzr fast-import
<mxpxpod> lifeless: hrmmm... the git in gutsy doesn't provide git-fast-export :(
<poolie> wow i had no idea of http://www.python.org/dev/peps/pep-0292/
<poolie> least of all that it was in 2.4
<jelmer> lifeless: nope, don't need it
<jelmer> lifeless: the only place where versionedfile is used is in the fetch code
<lifeless> jelmer: and annotate
<lifeless> jelmer: and repository stacking
<LeoNerd> Random thoughts.... a 'TODO counter' plugin... Keep a track of how many 'TODO' comments I still have in checked-in code
<LeoNerd> Plus maybe a daily email of "Here's some things left to do:" with a few lines of context
<jamesh> poolie: people never expect to find new functionality in the string module :)
<jelmer> lifeless: repository stacking isn't supported yet
<jelmer> lifeless: nor is annotate on remote svn files
<lifeless> jelmer: so, to stack we'll need this
<lifeless> yay internode, you go
<lifeless> jelmer: so, to stack we'll need this
<mxpxpod> lifeless: thanks for the tip... I just compiled git from hardy for gutsy and the fast-import worked flawlessly
<jelmer> lifeless: the main reason I haven't bothered to look at it yet is because performance on directories will suck badly
<lifeless> jelmer: I don't think that that is a good reason not to do it ;)
<lifeless> hmm bzrtools complaining
<jelmer> lifeless: well, in either case it's probably better to wait until the new vf api lands :-)
<lifeless> time to edit off the version check again
<jml> jelmer: should I be running released bzr-svn or trunk bzr-svn?
<jml> LeoNerd: I've thought about that.
<jml> LeoNerd: To do it right, that plugin would need to be language-aware.
<jml> poolie: finally heading to yours.
<jelmer> jml: Depends on what version of bzr you'r eusing :-)
<jelmer> jml: 1.2 -> released bzr-svn, bzr.dev -> bzr-svn's bzr branch
<lifeless> jelmer: btw, why would directories be slow ?
<jelmer> lifeless: there's no way to get all the interesting revisions for a directory
<jelmer> it is possible for a file
<lifeless> dir copies are not explicit ?
<jelmer> lifeless: they are, but there is no call in the svn smart server protocol to retrieve the interesting revisions for a particular dir
<lifeless> garh
<lifeless> about a page of deprecation warnings to go
<jml> ugh. bzr shelve uses __methods
<kgoetz> how can i unlock a repo? i had a commit message window open and my ssh link died
<poolie> kgoetz: bzr break-lock URL
<kgoetz> poolie: i get a reply of "bzr: ERROR: The lock for '/home/kgoetz/public_html/dansitev01' is in use and cannot be broken."
<poolie> hm
<poolie> is there still a bzr process running on that machine by any chance?
<kgoetz> let me check
<kgoetz> yes there is. theres a `bzr ci` running still
<kgoetz> poolie: thanks for pointing that out - killed the process and the break-lock worked
<poolie> you're welcome
<igc> night all
<lifeless> igc: night
<lifeless> igc: you jetlagged ?
<poolie> and i shold be here
<poolie> lifeless: symbol_versioning patch sent
<lifeless> thanks
<lifeless> poolie: k, I'm done for the day; this is I think the hardest of the apis to adjust, because of the ghost implications, and its nearly done.
<lifeless> poolie: couple of failing tests still
<lifeless> jml: whats wuhi ?
<jml> lifeless: We Haven't Used It
<jml> I could *swear* I've read it in some agile manifesto before.
<lifeless> ah
<TFKyle> hmm, wouldn't that be whui?
<jml> TFKyle: yes. there was a typo somewhere along the way.
<lifeless> I object to that, I'm not a typo. I'm a hoomarn bean
<i386> lifeless: have you seen this? http://code.google.com/p/python-safethread/
<bob2> "base (single-threaded) throughput is only around 60-65% that of normal CPython"
<lifeless> i386: no, I haven't
<bob2> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ermurri/vc-bzr/emacs22.1/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<luks> you can't push over http
<bob2> that was a pull
<luks> no idea then
<james_w> bob2: are you running the latest version?
<bob2> 3295
<bob2> ah, it was a heavy weight checkout
<james_w> ah, ok.
<siretart> does anyone know if a new bzrtools release is scheduled to appear 'soon'?
<james_w> hi siretart
<james_w> I haven't heard.
<james_w> Aaron is normally pretty prompt
<siretart> hi james_w
<siretart> I've now built a debian package for myself based on what's currently in bzrtools.dev
<siretart> however the testsuite (not run during package build) fails
<siretart> I've considered uploading it to debian to get bzrtools and bzr-builddeb installable again
<dky> i heard as part of emacs discussions, some performance improvements have been proposed or checked in?
<dky> I am interested in testing for performance, could someone give me extra information how to test bzr for performance
<bob2> 'bzr --profile command whatever' might be of use
<mbt> Is there some trick to being able to use bzr normally on an NFSv4 mounted home directory?
<james_w> mbt: what do you mean normally?
<mbt> Without errors... Nearly everything I do is accompanied by an "bzr: ERROR: [Errno 5] Input/output error" when using it on an NFSv4-mounted home, but when on the local filesystem, I do not get this error.
<mbt> For example, I get that error when I bzr diff
<mbt> or bzr status
<james_w> mbt: the error traceback would be useful to see.
<mbt> james_w: Is there a way to make it generate one?
<mbt> It just shows the Errno 5 message.
<james_w> mbt: bzr -Derror diff
<mbt> james_w: http://pastebin.com/d1561bfcd
<james_w> mbt: ok, so it's having some problems removing the lock.
<mbt> Should I go ahead and file a bug, then?  I would presume that it is supposed to work on an NFS-mounted home, right, or is that outside of what bzr is expected to do?
<james_w> mbt: is https://bugs.launchpad.net/bzr/+bug/137387 it?
<ubotu> Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged]
<igc> morning
<james_w> hi igc
<mbt> james_w: It might be, but I am not sure.
<mbt> james_w: Let me see if I can coax bzr into giving me more details
<igc> hi james_w
<james_w> igc: fast-import broke for me. I haven't had time to debug it yet.
<igc> james_w: just send me the traceback
<igc> I added tag support last night
<igc> well, lightweight tags at least
<igc> might be that?
<mbt> Is there a way to generate a log file as is shown in that bug report, james_w?  I can't seem to find it.
<james_w> igc: no, it was before that.
<james_w> mbt: ~/.bzr.log
<james_w> igc: it's bzr-fast-export | bzr fast-import on bzr.dev
<bratsche> Is it possible with bzr to work with multiple branches out of one directory and switch between them, similar to git?
<igc> james_w: ok, I'll try that. How far though was it previously?
<bratsche> Or actually, I should just state what my problem is first and see if there is any better way to do what I'm doing in bzr:
<james_w> igc: it did all bzr-fast-export could export.
<james_w> igc: let me upload the dump for you.
<bratsche> We have a pretty large codebase in bzr at work now, and each time I make a branch it takes a long time to branch the remote mainline to a local directory because it's pulling down all the source.
<igc> bratsche: are you using a shared repository locally?
<igc> it's highly recommended to do that
<bratsche> No, the shared repo is on the server.
<bratsche> Let me search for how to do a shared repo locally.
<igc> bratsche: you definitely want a shared repo locally as well
<mbt> it looks like that might be the bug... though the workaround in it does not work, and I still get problems... sigh
<james_w> bratsche: a shared repository is just a way of sharing data between branches so you can do it anywhere.
<igc> it's covered in the User Guide
<bratsche> igc: Right now I do: bzr branch <remote-mainline> <remote-branch-url> ; bzr checkout <remote-branch-url>
<james_w> bratsche: ouch
<bratsche> igc, james_w: Awesome, thanks very much!  I'll search for how to set that up.
<james_w> are remote-mainline and remote-branch-url sharing a shared repo?
<bratsche> james_w: Yes.
<james_w> igc: http://jameswestby.net/scratch/bzr-export.txt
<james_w> though it is about 20MB, so you may prefer to just generate it locally.
<igc> james_w: I'll generate it locally
<igc> It's just bzr-fast-export.py bzr.dev, right?
<james_w> yep.
<Odd_Bloke> Afternoon.
<bratsche> So I want to do like: bzr init-repo my-local-repo ; cd my-local-repo ; bzr branch <remote-mainline> ; bzr checkout <remote-mainline>
<bratsche> To setup my local shared repo?
<mbt> http://pastebin.com/d2f120d12 -- james_w, should I add that info to bug 137387?
<ubotu> Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] https://launchpad.net/bugs/137387
<bratsche> And then when I create new branches, I would branch from the local repo?
<james_w> hi Odd_Bloke
<Odd_Bloke> bratsche: You only need to do one of branch or checkout there.
<luks> bratsche: repositories are just an optimalization, you can ignore them and just use the workflow you had before
<james_w> mbt: yeah probably
<luks> but with a repo it won't download everything
<james_w> mbt: if you could debug why these errors occur that would be great.
<luks> because you already have the revisions
<bratsche> So I create my repo, and just checkout <remote-mainline>?
<Odd_Bloke> james_w: o/
<Odd_Bloke> bratsche: Within the repo, yeah.
<bratsche> Odd_Bloke: What about when someone else at work posts a branch on the server, and I want to switch over to view it?
<luks> bratsche: switch the existing checkout?
<luks> if so, 'bzr switch <other-remote-branch>'
<bratsche> Okay, thanks.
<Odd_Bloke> bratsche: Or you can checkout that branch into a different directory in the repository.
<bratsche> I'd better go read some more about repos rather than ask all of this here.
<bratsche> Sweet.
<bratsche> Thanks everyone.
<james_w> bratsche: there is also "bzr help repositories" that explains a little bit
<mbt> james_w: I would love to help debug it, but I am not sure where I would even start on it.  I know next to nothing about file locking and filesystems.  All I really know at this point is that bzr on local reiserfs works perfectly, on nfsv4, it doesn't.
<mb1> arrgh.
<mbt> Was my last msg about reiserfs/nfs/etc received?
<james_w> yeo
<james_w> well I'm not sure if it's a locking problem in terms of flock() etc., or just the way that we are creating lockdirs
<mbt> k wasn't sure if that actually got out before my client crashed lol
<james_w> I don't know the lock code at all though I'm afriad.
<mbt> Well, I can try to poke around it at some point this evening, but I have to finish setting up my network, because it's been restructured (which is actually how I found this issue lol).
<spiv> jelmer: when is the 0.4.8 release? :)
<awilkins> jelmer: Should be able to have another crack at building that binding on Friday
<awilkins> jelmer: A bit busy until then.
<jelmer> spiv: I'm trying to get it done before 1.3
<jelmer> spiv: I hope to get the pyrex stuff in before then
<ubotu> New bug: #203598 in bzr "Bzr should remember all locations and provide nicknames" [Undecided,New] https://launchpad.net/bugs/203598
<spiv> jelmer: ah, ok.
<spiv> jelmer: personally I'd probably release 0.4.8 without pyrex, and if you happen to make a 0.4.9 (or even 0.5.0...) with pyrex a week later, then that's fine.
<spiv> jelmer: but I do sympathise with wanting to minimise churn
<spiv> jelmer: would you like other people to test your pyrex branch, btw?
<jelmer> spiv: well, there is one bug which still needs fixing
<jelmer> spiv: do you have any pyrex experience?
<spiv> jelmer: a little bit
<jelmer> spiv: I'm trying to get pyrex to not return NULL from a cdef function when an exception is being raised
<hsn_> can someone please tell me again command for changing branch into lightweight checkout?
<james_w> hsn_: I think reconfigure can do it
<jelmer> spiv: that's the main bit that's preventing the pyrex branch from working
<hsn_> james_w: yes, thats right
<ubotu> New bug: #203607 in bzr "bzr unable to upgrade pack-0.92 to rich-root-pack format" [Undecided,New] https://launchpad.net/bugs/203607
 * lamont has a stupid-bzr question..
<lamont> hrm..
<lamont> nm
<awilkins> The stupid-bzr plugin isn't compatible with the current bzr version I'm afraid
<jam_> hmm.. that was a very long question
<jam_> I seem to have missed it completely :)
<dennda> Hey
<dennda> I am just trying to branch a remote svn repository (over https)
<dennda> bzr-svn is installed
<dennda> this is the result: http://paste.pocoo.org/show/34207/
<Odd_Bloke> jelmer: ^^^
<james_w> dennda: can you try bzr branch svn+https://svn.example.com/myrepo
<lifeless> moin
<dennda> james_w: thanks, that works
<dennda> james_w: but how to tell bzr how to push to that location?
<dennda> nevermind
<dennda> just figured it out
<dennda> thanks
<jelmer> dennda: see the FAQ
<jelmer> dennda: never mind, I was reading backlog
<ubotu> New bug: #203643 in bzr "'bzr status' crashes with MemoryError" [Undecided,New] https://launchpad.net/bugs/203643
<lopio> hi
<lopio> i'd like to propose bazaar instead of cvs but there are 2 question about it.Could you help me ?
<james_w> sure
<lopio> 1) it seems impossible to retag single files (example i need to create a package with old files labelled AAA and i want to add 2 files in HEAD)
<james_w> lopio: sorry, I don't understand the question, could you explain it a little more please?
<lopio> in CVS i'll extract old label AAA and i'll force a retag AAA on the 2 files
<lopio> ok
<luks> lopio: no, bzr doesn't have per-file tags
<luks> (or per-file revisions, like cvs)
<luks> in bzr you would normally branch of the tag AAA and then merge the changes to those 2 files from HEAD
<lopio> i see luks but in this case i'll have a new branch forever
<luks> is that a problem?
<lopio> it is a problem when you have a schema with central repository....
<james_w> lopio: if you want the old versions of two files then you can use revert to get them, and then commit to include them in your current HEAD
<luks> well, tag in bzr applies to the whole tree
<luks> so if you don't have such tree in your branch, you need to create it
<lopio> ok
<lopio> this is not a blocking problem -)
<lopio> Now a real problem -(
<luks> but generally you would have this problem with any VCS that isn't CVS
<luks> I don't know of any other VCS that works on file basis
<lopio> CVS is old but is able to manage CRLF
<lopio> and this is a real problem for us
<abentley> siretart: I'll try to have it out this evening.
<lopio> we have a central CVS repository and we are able to co and commit in XP and HP both
<lopio> this is because in CVS you have to specify -kb parameter when you add an exe file
<lopio> in this way when you checkout under  XP a CR is added to files different from exe (and removed during commit)
<james_w> lopio: we want to add support for line endings, but it is not done yet.
<lopio> this is a strong limitation i think -((((((((((
<lopio> It seems a marvellous versioning system so i hope some people could add this feature as soon as possible
<lopio> keep up the good work!!! Thank you very much...see you later..bye
<igc> james_w: fyi - fast-import is better now wrt renaming handling
<igc> a bug still exists though
<igc> it now gets a lot further on your bzr.dev export but not all the way through
<igc> I'm moving onto some other stuff now so it might be a day or so before I get back to this
<mamato_> anyone know of tool to completely remove files from my bzr history?
<james_w> mamato_: no such tool exists yet I'm afraid.
<mamato_> weird...
<mwhudson> bzr strongly discourages rewriting history
<mamato_> hmm... should have maybe sticked to rcs then :S
<mwhudson> you might be able to use rebase, especially if the file hasn't changed much over history
 * mamato_ strongly encourages cleaning up one's crap when needed
<mwhudson> i guess we could have an argument about that
<mwhudson> but i can't really be bothered
<nevans> mamato_: the only compelling use-case I can see for changing history in a good VCS is when "sensitive" data has accidentally gotten into the repo
<nevans> e.g. passwords
<mamato_> i need versioning for personal code... i'm the only user... for the first project i used it, i realized that i had accidentally checked in tons of images which dont need versionning... couldn't back up my branch to the internet like i wanted... had to loose all my change history weeks after... if a 'good VCS' doesn't allow it, maybe that's not what i need...
<mamato_> all i want is a 'useful vcs' that corresponds to my needs...
<nDuff> mamato_, fastexport + edit + fastimport?
<nDuff> mamato_, that's not entirely unlike the SVN methodology of dumping to XML to edit history.
<james_w> nDuff: I expect there will be a tool to filter a fast-export stream at some point.
<nevans> okay... wanting to trim disk usage in a personal-use only project... that's another compelling use-case.  ;-)
<nevans> (I don't deal with personal-use projects much... except for /etc and ~/ )
 * mamato_ can't find fastexport info on google :S
 * mamato_ found fastimport!
<nDuff> mamato_, https://lists.ubuntu.com/archives/bazaar/2008q1/038391.html
<nDuff> mamato_, ...not saying that's the most current location.
<nevans> it looks like git already has a tool for filtering fast-export streams: http://www.kernel.org/pub/software/scm/git-core/docs/git-filter-branch.html
<nDuff> nevans, looks to me like you'd need to actually import the stream into a git repository to use that. Which, granted, wouldn't be the end of the world.
<mamato_> nevans: thx for the info...
<mamato_> i hear git is quite nice too... will look into it more closely... except for this, have had good experience with bzr though :(
<mamato_> how do you .bzrignore some sub-directories?
<spiv> mamato_: have you seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#ignoring-files ?
<mamato_> yep
<mamato_> but didn't find info
<mamato_> spiv? it only deals with ignoring files... not directories... and specifying directory doesn't seem to work
<spiv> mamato_: hmm, I'd expect ingoring a directory to work
<spiv> mamato_: it seems to work as I'd expect for me: http://rafb.net/p/nyFWyY31.html
<spiv> mamato_: perhaps you've already added the file?  "bzr ignore" won't ignore a file that's already versioned.
<NfNitLoop> I regularly ignore directories.
<spiv> mamato_: so you may need to use "bzr rm --keep" on those files.
<mwhudson> damn, i wish i had a spare time machine so i could work on bzr's graph operations
 * spiv -> afk
<mamato_> weird... your test case works but doesnt work with my branch... and not already versioned... going back to figuring it out...
<mamato_> ah... parent dir (whihc i want to ignore) IS versionned... makes sense...
<spiv> jelmer: I think for the exceptions returning NULL issue you want "cdef int spam() except -1:" (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/basics.html#ExceptionValues)
<ubotu> New bug: #198092 in bzr "Should tell the user to run bzr launchpad-login before push lp:" [High,Triaged] https://launchpad.net/bugs/198092
<jelmer> spiv: that doesn't work, since an SVN error is a pointer
<jelmer> spiv: pyrex only supports "except NULL" but NULL in this case actually is the only return value that means there's no error
<AfC> jelmer: got a sec
<AfC> ?
<james_w> hi AfC
 * AfC waves
<lifeless> jelmer: don't try to use the same function for two different protocols then :)
<lifeless> jelmer: the one directly exposed to python _must_ use the python conventions - return NULL -> there is an error set
<lifeless> jelmer: you probably need to wrap the svn_ra functions with ones that invert the return code to do what you need
<jelmer> AfC: hi
<jelmer> lifeless: hi
<jelmer> I already have one level of indirection - I register a pyrex callback that can calls a python function
<AfC> jelmer: I know we almost talked about this the other day, but I was wondering if you have any [further] specific insight into whether or not two different people with different Subversion account names could use a bzr-svn branch once created?
<AfC> jelmer: ie, it took me the better part of 9 days to create a bzr-svn branch of GTK. I'd like to share that with someone else to save that being (through no fault of bzr-svn's) someone's first impression of Bazaar
<lifeless> AfC: you can share that just fine
<lifeless> AfC: the svn account name is not part of the created bzr branch
<AfC> but obviouly they have a different [ssh] account to talk to GNOME's Subversion repository, so if I either a) publish the resultant Bazaar branch, or b) tarball the branch + repository
<AfC> and pass it to someone, whether or not it would work
<jelmer> AfC: Yes, two people with the same name could share a bzr-svn branch
<AfC> jelmer: different usernames
<jelmer> AfC: yes, no problemo
<AfC> jelmer: ah. AWESOME
<AfC> Then I shall get us hosting a series of such branches as a community service.
<poolie> good morning
<AfC> jelmer: so I assume all that will have to happen is that when it comes time for them to commit and push back to the upstream Subversion repo is to do
<AfC> jelmer: bzr push --remember svn+ssh://their_user_name@svn.gnome.org/svn/gtk+/trunk
<AfC> jelmer: and they'll be all set
<jelmer> AfC: yep
<AfC> Beautiful
<jelmer> AfC: Hopefully shallow branches can help avoid the long time it takes to get an initial branch
<jelmer> lifeless: What's the status on shallow branches?
<AfC> It was interesting to hear Carl report his experience that:
<AfC> "The *moment* I see a Subversion URL from someone, even before I think I might want to hack on it, I just feed it to git-svn and let it run on a server, because I know it'll take forever, but eventually it'll be done and I'll have a branch to use from Git if I want to"
<AfC> (And they do then share those around, which also gave me the idea of seeing if we could too. Awesome)
<jelmer> AfC: 9 days seems like a lot of time, btw
<hsn_> what kind of storage is more resistent to corruption? packs or knits and what kind of storage has better recovery tools?
<jelmer> I also have a gtk+ trunk import here, and afaik it took less than a day
<AfC> (well, I had intermittent network access and a not-svn-HEAD to deal with)
<lifeless> hsn_: packs
<lifeless> jelmer: they work but not with the smart server
<lifeless> jelmer: I'm fixing the root issue preventing them working with the smart server at the moment
<awilkins> Go-go shallow branches!
<awilkins> Also go go pyrex bindings
<jelmer> lifeless: ah, cool
<lifeless> jelmer: which is the versionedfiles rework
<lifeless> jelmer: because you need to be able to stack on historical data
<lifeless> poolie: status for me -> versionedfiles at full steam
<poolie> toot toot!
<poolie> enjoy
<jml> I just tried to branch a Subversion branch into a pack repo and got this: bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/Pimlico/jana/.bzr/repository/') is not compatible with repository SvnRepository('http://svn.o-hand.com/repos/jana')
<jml> I'm using bzr-svn trunk and Bazaar 1.2
<awilkins> jml: You need rich-root-pack
<jml> awilkins: that in 1.2?
<awilkins> jml: Was in .092 AFAIK
<awilkins> 0.92
 * jml tries
<jml> OK. Now I'm getting SubversionException: ("PROPFIND request failed on '/repos/jana/branches/jana'", 175002). This is odd, because I can check it out just fine with the svn client
<awilkins> jml: Is it a password protected repo?
<jml> awilkins: no.
<jml> awilkins: or, at least, it's not protected for reading.
<awilkins> Are you using a release or the tip of a branch (of bzr-svn)
<jml> awilkins: tip of http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/
<awilkins> I've never used that..... try the 0.4.8 branch
<awilkins> I presume you've installed patched bindings, etc?
<jml> I'm fairly sure I have.
<jml> maybe I'll try the packaged version.
<jelmer> bzr-svn will give you a warning if you're not using the patched bindings
<jml> jelmer: so, any ideas?
<lifeless> jml: whats a jana?
<jelmer> jml: have you tried the 0.4.8 branch?
<jml> jelmer: no, I'll have a look at that.
<jml> lifeless: it's apparently a japanese word. the project is the openedhand guys' new calendar thingummy
 * awilkins thinks of Jana of the Jungle
<lifeless> fingers crossed, step 1 may be done. whew.
<poolie> lifeless: call me sometime today, at your convenience
#bzr 2008-03-19
<lifeless> poolie: it rang out, trying again
<lifeless> 68 failing now
<lifeless> 8
<poolie> heads down on ssh locking
<lifeless> woo
<lifeless> full test time, think its finally hammered into submission
<lifeless> lunch time too
<thatch> lifeless: when you get some free time, can I harass you about the get_parent_map/old-server reauthenticate-over-ssh issue again?
<jml> why doesn't this work: $ bzr log -r date:2008-03-14..
<jml> bzr: ERROR: Requested revision: u'date:2008-03-14' does not exist in branch: BzrBranch6(...)
<poolie> note it is the first one _after_ that date according to the source
<jml> still, it seems a strange error
<poolie> you'd rather "no revisions after xxx"?
<poolie> anyhow is it in fact true there are no revisions on or after that date?
<poolie> or did you expect it to just log nothing?
 * Odd_Bloke would expect it to log nothing.
<jelmer> Logging nothing or saying "no revisions after xxx" both make sense to me
<Odd_Bloke> Logging nothing is more consistent with what we do in an empty branch.
<jelmer> printing the error message avoids the user wondering why there was nothing logged though
<jelmer> similarly, I wouldn't be opposed to printing "Empty branch" when running bzr log in an empty branch
<Odd_Bloke> Nor I, I was just commenting on current behaviour.
<Odd_Bloke> I can't say I'm massively bothered either way.
<jml> poolie: there are no revisions after that date
<jml> what jelmer said is what I think (<jelmer> Logging nothing or saying "no revisions after xxx" both make sense to me)
<awilkins> I also find the default silence of bzr to be a little eerie sometimes
<jml> remind me how to do this: I've made some changes in a working tree, I haven't committed, and now I realise I want them in a new branch.
<mwhudson> jml: make a new branch
<mwhudson> cd into it
<mwhudson> bzr merge --uncommitted ../old-branch
<bob2> bzr reconfigure --checkout ; bzr branch . wherever ; bzr switch ../wherver
<jml> mwhudson: thanks.
<lifeless> ok really the last time. fingers crossed
<abentley> lifeless: why do you not want the inventory_validator_type in Revision objects?
<lifeless> I think its making an abstraction violation worse
<abentley> I would be quite happy to ditch the validator entirely, but if we're keeping it, I think we need to know what it means.
<lifeless> I think it is happily hidden behind Repository/Revision themselves.
<abentley> The validator?
<lifeless> yes
<lifeless> its exposed at the moment, and only well defined some of the time, but all the uses for it are things that should be methods on either Revision or (probably better given our current object use style) Repository
<abentley> So if I were to introduce a new repo format whose revisions didn't have validators in their serialization, that would be fine with you?
<lifeless> if we can somehow validate the revisions without that, in principle, yes.
<abentley> You mean "validate the inventories"?
<lifeless> no, I mean the revision - which is a transitive validation of all the stored data
<abentley> The inventory_sha1 does not validate the revision.
<lifeless> thats true
<lifeless> I was making a more general statement. I really precise one would be 'if it is no less capable of validating the inventory for that revision', but thats much more awkward
<abentley> lifeless: It sounds like you're significantly increasing the difficulty level.
<abentley> Validating the inventory is one thing-- validating the whole revision is another.
<lifeless> right now we get revision validation via the revision signature
<lifeless> clearly if thats not there we only have validation of the data the revision references
<lifeless> and I did not intend to raise the barrier higher than that
<abentley> I don't really get your second statement.
<lifeless> ok, well lets start over
<lifeless> are you planning on removing inventory validation?
<lifeless> (aka not reenabling it)
<abentley> No.  I was planning to ignore it until you started saying this was a blocker for rich-root-pack
<lifeless> I think its a pretty severe defect in the current code
<abentley> Now I want to do the minimum necessary to keep you happy and ensure we don't have this problem again.
<lifeless> I will be happy if: pack-rich-root repositories validate their inventory
<lifeless> during 'check'
<abentley> If I simply introduce a new revision serialization just to indicate the inventory serialization, that's going to be wasteful.
<lifeless> such that an edited inventory causes a check failure
<abentley> Because I'll have to introduce at least two, and possibly many more as time goes on.
<lifeless> I don't think you need to introduce a new serialisation, but you were adamant that you needed to
<abentley> If we don't know what a validator is, we can't hope to use it correctly.
<lifeless> erm
<lifeless> clearly that statement is true, but we know what validators we have
<lifeless> I wrote the code to fix things so that I would be happy
<abentley> I think that sticking the validator in the revision is horrid.  It's local data; it doesn't belong there.
<lifeless> its very simple: change repository.get_inventory_sha to actually use the text, and change fetch to update the sha1 during rich root tree root addition
<lifeless> those two changes, in total, made me happy.
<abentley> At the cost of making me tremendously unhappy.
<abentley> Because bazaar is a distributed system, and values should really be write-once.
<lifeless> which is not an acceptable cost
<lifeless> well given that the inventory is being rewritten *already*
<lifeless> the inventory validator being updated is a consequence of the rewrite being done by the plain->rich root fetcher
<abentley> lifeless: it is being rewritten, true, but in a deterministic way.  The new values are implied by the existing values.
<lifeless> the same holds for the inventory sha change
<lifeless> in the format under discussion the new inventory serialisation is deterministic, as is the resulting sha
<abentley> The problem with the inventory sha change is that it is tied to the inventory format, but affects the revision format.
<abentley> If the revision format implied that validator, that would be acceptable to me.
<lifeless> uhm, those two things are part of a repository format though; they can't be used in isolation or arbitrary combinations
<lifeless> you can't use an original format revision serialiser today
<abentley> You can shove anything in a bundle, and it will translate as necessary into the target serializers.
<lifeless> directly? or via install_revisions? bundles should not be serialising, they should be using the object model
<abentley> I would have to check.
<lifeless> if they use serializers directly they are profoundly hostile to e.g. bzr-svn
<lifeless> serialisers are private on a repository
<abentley> Well, it looks like it only handles inventory, not revisions.
<abentley> If the repository doesn't use the same inventory serializer as the bundle, then it converts it to an object and calls Repository.add_inventory
<lifeless> so the basic thing here seems to be - we have individually versioned formats for code reuse and to catch some cases of bugs; There are dependencies between our formats such that changing anything about e.g. inventory changes the value of fields in e.g. revision
<lifeless> so yes, I think you need a new revision format to be strictly correct; the new format needs no changes other than a version string bump IMO.
<lifeless> and I think every inventory change will do that if you want to be able to analyse serialised revisions outside of the repository that owns them. (I think that being able to do that is of questionable value FWIW).
<abentley> And as you can imagine, I don't want that kind of churn.
<abentley> I'd rather specify what the validator means.
<lifeless> maybe I don't understand what you mean
<lifeless> but unless you define the validator as being an arbitrary datatype (and thus needing a format bump _anyway_ when it changes), I don't see it preventing any churn
<j1mc> hello, i've kind of goofed up my bzr history on the bzr repository/server.  i didn't do a bzr bind, and several other people committed changes that i just merged in, and then pushed up a few of my changes.  the content is accurate, but the history is fscked.  is there a way to fix/correct the history?
<poolie> what do you want it to look like?
<j1mc> i want the prior history to be shown.  108 revisions were removed from the branch, and replaced by my generic 'a bunch of updates' commit messages.
<j1mc> :(
<lifeless> j1mc: sure thing, what you need to do is do 'bzr branch -r revid:XXX trunk local; cd local; bzr merge -r revid:YYYY ../trunk; bzr commit; bzr push --overwrite ../trunk'
<j1mc> lifeless, can you please explain to me what that will do?
<lifeless> j1mc: where XXX is the revision id (not revision number) of the last commit that should have been on the mainline before you pushed
<j1mc> (thanks, btw)
<lifeless> j1mc: and YYY is the revision id of the tip of your branch (possibly even the current mainline tip)
<lifeless> j1mc: what it will do is do the merge that bind would have done via 'bzr update'
<lifeless> j1mc: you can get revision ids via bzr log --show-ids
<j1mc> lifeless: this is on launchpad, will it cause 108 emails to be sent out with the updated revision history
<j1mc> s/updated/corrected
<lifeless> j1mc: presumably :(. thumper ^
<j1mc> haha
<lifeless> after you ahve done this
<lifeless> there is an option you can turn on in your branch to prevent this mistake
<lifeless> its in the manual I believe
<kgoetz> Kamping_Kaiser: look at that ^^
<j1mc> thanks...
<abentley> lifeless: If we have different types of inventories, we can just specify the validator type, e.g. "inventory6sha1"
<abentley> That means we don't need a different format for every inventory format.
<lifeless> abentley: so the validator becomes a tuple essentially - (type, validator)
<abentley> Sure.
<lifeless> abentley: this seems redundant to me, because the repository already knows the type. Which is why I don't think we need a new revision format in the first place.
<abentley> The bundle does not know the type.  It is not in a repository format.
<lifeless> abentley: but if you feel its essential in the disk format, go ahead I guess. I really think its wrong, but we seem to be at an impasse
<lifeless> I think bundles are buggy then (grin-joke)
<lifeless> well, play on words. I really do think that a bundle has the same duty of integrity as any other revision storage format
<abentley> A few minutes ago, you said "I think you need a new revision format to be strictly correct"
<lifeless> I can see the logic for why you want one; I don't think its needed because its conflating two different things
<abentley> lifeless: Bundles have very good integrity checking.
<lifeless> good; so they _must_ know whether they came from a rich root or non rich root repository
<lifeless> and if they know that, they know whether the sha in their revision is for a rich root or plain inventory
<lifeless> sha for the inventory in their revision
<abentley> The one does not follow from the other.
<lifeless> given our data model I think it does
<abentley> They store a sha1 of the expected text output.
<abentley> The sha1 of the fulltext.
<abentley> But this is stored in private data-- the text of the revision is completely ignored.
<lifeless> which clearly will differ if the source and target repository differ
<abentley> If the source and target differ in format, it generates the fulltext of the source, verifies it, and then convert it into the target format.
<lifeless> where you mean 'serialisation of a single object type' by format
<lifeless> and when I talk formats I mean 'entire repository'
<abentley> Right.
<lifeless> if bundles had the repository format there would be no problem, you wouldn't try to use a fast path that doesn't fit
<abentley> Or alternatively, if inventory format didn't affect revision contents, there would also be no problem-- we could mix and match.
<lifeless> anyhow, we agreed on a compromise in London, which was a new revision format, so lets do that. I'm really unkeen on inventory_validator being (type, opaque_data), because you have to have a new bzr to read new types and validate them anyway
<lifeless> so I don't see that we gain anything over just revving the revision serialiser itself; which is trivial and tiny amount of code
<abentley> lifeless: Okay, fine.   I'll implement two revision formats, one for each inventory format.
<abentley> But *you* get to implement the new revision format when you do journalled inventories.
<lifeless> surely its
<lifeless> class SubX(parent):
<lifeless>     revision_version = 7
<lifeless> class SubY(parent):
<lifeless>     revision_version = 8
<abentley> I have no idea.
<abentley> I suspect it's a bit more than that.
<abentley> Once you've implemented the serializers, you've got to update the places they're used.
<lifeless> assuming you ditch knit based rich root and subtrees
<lifeless> which I recommend
<lifeless> then its just a new subclass of the two Pack repo formats, with a single line override in the same manner
<j1mc> lifeless: you responded pretty quickly to my "history" issue above.  is that a common situation?
<lifeless> j1mc: no
<j1mc> you just know bzr well.  and other people bind their branches.... so it doesn't happen to them?
<abentley> lifeless: And registering the formats in xml_serializer.format_registry, and I'm pretty sure they pop up in some other places.
<lifeless> abentley: ok, so 10 lines then ? :]
<lifeless> j1mc: I'm one of the old hands yeah :)
<lifeless> ok
<j1mc> :)  thanks so much for your help, lifeless
<lifeless> I've nuked VersionedFile.get_parents, now to make the implementation within knit.py smooth. Then a patch we shall see.
<j1mc> btw, i'm in the general vicinity of john meinel (sp?).  i've met him once before... he's a good guy.
<lifeless> j1mc: cool, yes he is
<lifeless> abentley: btw, export-loom, am I expecting a new patch, or should I remove the default and commit myself?
<abentley> Please go ahead.
<lifeless> abentley: will do
<abentley> I'm for bed.
<lifeless> wow
<lifeless> must be very late now
<jelmer> hmm, I think I forgot something..
<abentley> Eh, not even 1:00am
<lifeless> jelmer: hah!
<Odd_Bloke> jelmer: Was it 'going to bed'?  Because I've done exactly the same...
<jelmer> Odd_Bloke: :-)
<Symgeosis> I'm new to Bazaar and I'm having problems figuring out how to pull an older revision of a branch. Could somebody help me out with the command?
<lifeless> Symgeosis: bzr pull -r revno --overwrite
<Symgeosis> Thanks Lifeless.
<j1mc> lifeless: i have an additional question about your prior suggestion.
<thumper> lifeless: I lost the context, can you explain (launchpad emails)?
<j1mc> you wrote, "and YYY is the revision id of the tip of your branch (possibly even the current mainline tip)"
<j1mc> would that be a revid of one of the earlier revisions?
<j1mc> i don't know what a branch "tip" is
<j1mc> thumper: http://pastebin.ca/948485  (context)
<Odd_Bloke> j1mc: The branch tip is the revision that the branch points to.  The head, in git terminology (I think).
<j1mc> Odd_Bloke: thanks, but i still don't quite understand.
<thumper> j1mc: you could set you subscription level to "No email" for the change and then edit it back afterwards to avoid the email
<poolie> hm, so should i do this locking change by passing a parameter down saying "don't wait", or by having the smartserver set a global option not to wait for locks?
<poolie> relying on global state is undesirable, certainly
<poolie> otoh it really should not normally be waiting
<j1mc> lifeless: sorry to keep bugging you (if you are even still around), but i'm having a hard time knowing what i should be selecting as the second (XXX) revid.
<j1mc> would it be a recent revid (from just before i goofed up the history)?  or one of the ones from earlier in the history?
<bob2> do you mean second (YYY)?
<j1mc> bob2: yes, the second YYY
<poolie> j1mc: it's the last one that had what you consider "good" history
<poolie> probably the one just before your merge
<bob2> YYY should be the revid of the top of your branch (second part of the output of bzr revision-info)
<j1mc> maybe it would help if i posted the last good revision to pastebin
<j1mc> http://pastebin.ca/948518
<j1mc> 3651.1.108 is the last good revno
<j1mc> i think i would use that for the XXX part
<bob2> (that's a revision number, not a revision id)
<j1mc> bob2: correct
<j1mc> revision-id:asommer70...
<j1mc> that's the revid
<j1mc> i'm hesitant to use the "asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa" as both XXX and YYY, but that's what i think is being suggested.
<bob2> XXX is supposed to be the last revision id before things went wrong, YYY is the tip of your currently wrong branch (which, as lifeless said, might still be the tip of the lp trunk)
<bob2> afaict
<j1mc> so in that example, my "incorrec" push has a revid of "jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp"  that would be YYY
<j1mc> (it is the most recent push to the branch"
<j1mc> (sorry for the typos, it's late)
<j1mc> bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk
<bob2> does "bzr log" in trunk show what you want it to show?
<lifeless> hi soerry
<lifeless> been on phone
<j1mc> bob2: yes.
<j1mc> on my local copy
<j1mc> lifeless: np
<lifeless> j1mc: so
<lifeless> j1mc: to find XXX, run bzr log --show-ids
<lifeless> j1mc: somewhere amongst your merged revisions will be a commit to the trunk that *should* be on the mainline (that is have a whole number revision number, with no dots), but that is shown nested
<lifeless> j1mc: the first one of those, is the one you want as XXX
<j1mc> http://pastebin.ca/948518
<j1mc> the first one listed is the most recent commit and push to the branch.  it's the one that screwed everything up.  the one after that is the last good one
<j1mc> based on that, i think this is correct:
<j1mc> bzr branch -r revid:asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa trunk local; cd local; bzr merge -r revid:jwcampbell@gmail.com-20080319032336-pyefchhxbdwyrsjp ../trunk; bzr commit; bzr push --overwrite ../trunk
<j1mc> where "asomer..." is the last good one
<lifeless> j1mc: ok, then use asommer70@gmail.com-20080318135647-hbbpj5bl819nu1oa as XXX
<j1mc> and where "jwcampbell..." is the tip, or most recent commit
<lifeless> and whatever revision id revno 3666 has for YYYY
<j1mc> lifeless: in my log, there is no 3666
<lifeless> uhm
<lifeless> 3667 and after a while 3666 and so on
<lifeless> what command are ou running
<lifeless> to get the log
<lifeless> do you have an alias set overriding revision selection
<j1mc> bzr log --show-ids > ~/Desktop/ids
<j1mc> no
<lifeless> then look further down the file :)
<j1mc> :)  got it
<poolie> lifeless: i see the smart server locking tests specifically ask for knit repositories
<poolie> do you suppose that is an accident, or because they want one that has more locking than packs?
<poolie> hm
<lifeless> the former I believe
<poolie> i'll mail spiv
<lifeless> annotate doesn't blame me ?
 * poolie looks
<poolie> btw did you know gannotate supports Ctrl+F
<lifeless> yes
<poolie> ah yes, it is you
<poolie> > Make test_smart use specific formats as needed to exercise locked and unlocked repositories.
<poolie> so do you still want it?
<lifeless> yes thanks
<lifeless> running against packs may be interesting too, but running against knits is essential until we stop using them.
<poolie> i'm confused
<poolie> you said it was an accident
<poolie> but you still want it?
<lifeless> oh
<lifeless> I meant deliberate;)
<lifeless> gee look at the time, gotta go :P
<lifeless> (seriously, I woke at 4am, I am rather shattered - getting former and latter confused is not good. I'm going to go have a cat nap)
<kgoetz> hehehe
<poolie> sure
<lifeless> actually, going to call it a work-day
<lifeless> I need to dig up the python C api and turn a list to a tuple to finish this patch
<j1mc> lifeless: you rock.  your command helped me to fix it.
<kgoetz> \o/
<jml_> hi ho
<poolie> hi
<Odd_Bloke> So many jmls!
<j1mc> Odd_Bloke: ... I'm j1mc  :)
<j1mc> but yeah... kind of strange
<jml> I'm on a crippled system atm.
<Odd_Bloke> jml: :(
<Odd_Bloke> Night!
<siretart> is 'bzr selftest' supposed to work using the 1.3rc1 debian package?
<james_w> siretart: are you seeing failures?
<siretart> james_w: http://paste.debian.net/51435
<james_w> siretart: wow. you're not in a directory with a directory named "tests" or a "tests.py" are you?
<siretart> james_w: no, I'm not
<siretart> bzr & bzrtools seemed to work anyways, so I've decided to just upload bzrtools 1.3.0 to sid
<james_w> I saw that, thanks.
<siretart> is that perhaps because of python 2.4 instead of python 2.5?
<siretart> no, doesn't seem so
<james_w> is tests/* shipped in the binary package?
<siretart> ha, it seems that builddeb is breaking selftest
<siretart> after removing bzr-builddeb, the 'selftest' command works fine again
<james_w> ah, you're not doing bzr --no-plugins selftest
<siretart> well, I wanted to run the selftests on bzrtools
<james_w> ok. I want to prepare a builddeb upload today, and it should fix all of this nonsense.
<siretart> great!
<james_w> sorry for breaking it.
<siretart> just drop me a note, I'll sponsor it
<siretart> no worries
<james_w> great, thanks.
<siretart> btw, are you DM or was that just jelmer?
<james_w> that was just jelmer
<siretart> ok
<VSpike> I use cygwin on Windows.  Am I generally better using the cygwin supplied bzr or the windows version?
<luks> cygwin's python is usually slower
<VSpike> I'm currently using the Windows version which mostly seems OK but I am having problems with the sftp protocol.
<james_w> VSpike: would you like to describe the problems?
<VSpike> I've found this https://lists.ubuntu.com/archives/bazaar/2008q1/036410.html
<VSpike> commit to sftp repo freezes
<VSpike> works from dos box, freezes in cygwin bash
<james_w> so you have exported that variable?
<VSpike> I tried export BZR_SSH="paramiko" and that makes it output an extra line "Connected (version 2.0, client OpenSSH_4.6p1)" before freezing
<VSpike> I have not set up keys, so in DOS it prompts for password.  I was basically wondering as next step, either try to set up keys or try out a full cygwin stack instead
<VSpike> I can install Cygwin paramiko, but I think I will have to use cygwin bzr to take advantage of it?
<VSpike> In the DOS box, it outputs exactly the same line and then prompts for a password
<VSpike> I thought paramiko linked to putty/pageant not openssh?
<VSpike> my windows bzr is 1.2 and the cygwin version is 1.1 ... will i have any problems if i downgrade?
<awilkins> Due to the fuss from the emacs camp, does 1.3 have any speedups for trees with large file counts?
<awilkins> cd ..
<awilkins> oops
<james_w> awilkins: I think it was all a bit late for much stuff to go in to 1.3
<james_w> and it's not the large file count that the operations they are discussing are having problems with, it's the depth of history
<james_w> which is >87000 revisions
<awilkins> Ah, ok then
<awilkins> My problems are the opposite :-) - 8000-ish revisions, about 30,000 files
<awilkins> But it's still worlds faster than SVN
<awilkins> (except the branching-from-svn part :-)   )
<james_w> awilkins: that should hopefully be sped up soon. (if you are using bzr-svn)
<awilkins> awilkins: Yes, I hear those new pyrex bindings are the bees knees
<james_w> awilkins: if you are having trouble with large trees posting to the list with the operations and profile data may help.
 * awilkins is talking to himself again
<james_w> :-)
<awilkins> james_w: I think my problems are less to do with bzr and more to do with filesystem performance on Win32
<james_w> it's more the "don't pack after every commit" that will make a difference, that's a separate issue to the bindings
<awilkins> james_w: I'll consider it, but as I said, it kicks the pants off SVN
<awilkins> james_w: Yes, that too
<james_w> awilkins: ah, well you're on your own then :-)
<james_w> seriously though, there may be ways to speed it up, so consider it
<james_w> I can help you collect the profile data if you like.
<awilkins> james_w: Yup, after thursday I'll have some time ; I want to have a crack at building those pyrex bindings on Win32 (I have MinGW AND the MS 2003 compiler sitting in the wings wiating)
<james_w> that would be very valuable, thanks.
<awilkins> Big Feature Push on at the moment (ie, meeting the consumers for an iteration meeting tomorrow :-)  )
<awilkins> james_w: I had a try at building them last week ; it's a TOTAL pain in the arse
<james_w> I can imagine.
<awilkins> It's mostly SVNs fault ; APR is a breeze to build on Win32
<awilkins> "Load the Visual Studio project we provide and as long as you have the SDK it works"
 * awilkins rolls on the drum for Vista SP1
<awilkins> "Your computer will reboot several times during installation" (you could write that on Bill GAtes grave....)
<awilkins> james_w: Are pack repos reverse-delta or forward-delta?
<james_w> awilkins: they are based on knits
 * awilkins is ignorant of what a knit is
<james_w> hang on, which way round is reverse-delta?
<awilkins> You keep the current revision verbatim and store the deltas to get back to the previous revision
<awilkins> (at least, that's what I mean when I say it)
<awilkins> What RCS does
<james_w> awilkins: no, it's forward-delta then I think.
<awilkins> I was thinking maybe if you had checkpointed verbatim revisions in there it might make the emacs deep-history thing better
<awilkins> But I am a novice :-)
<luks> it's graph/index operations that are slow, not the delta decompression of actual files
<james_w> oh, I think it does store full texts when the delta chain is too long or an individual delta is too large.
<awilkins> Jolly good, I'm glad something so obvious as to occur to me wasn't overlooked :-)
<james_w> but as luks says, operations like log etc. are what they are talking about, which doesn't access the texts
<awilkins> Are per-file logs slow?
<awilkins> (as opposed to whole-tree logs)?
<luks> any log
 * awilkins is surprised
<luks> log in bzr needs to sort the graph in many ways, in git just dumps the (almost) raw index
<luks> which is one reason why it's slower
<awilkins> Fair enough.... time to reboot for me, back in a mo
<james_w> luks: git does need to sort the revisions, it just has less constraints on the sort.
<james_w> in particular it needs to load all revisions with pointers to their parents, and then traverse the graph once before it can output any revisions.
<james_w> it still takes bzr about 10s to do even that on the emacs repo
<luks> james_w: if I'm not mistaken, git doesn't even topologically sort them by default
<james_w> luks: true, sorry, it date sorts them.
<james_w> However it can still topo sort them very quickly.
<luks> but I was surpsised that with my toy repository format I was playing with a few months ago, I had log faster than in hg
<luks> and hg does much less work on sorting there
<james_w> git log --date-order > /dev/null  2.76s user 0.09s system 98% cpu 2.900 total
<james_w> luks: that's good to hear. How did your repository format differ?
<luks> getting rid of the xml revision format would also help bzr
<james_w> --date-order is the strictest git log format, and the above is warm cache.
<luks> different indexes, bulk reads, no xml, ...
<james_w> luks: that sounds good.
<fullermd> Well, you can say almost anything, and as long as you include "no XML" it sounds good   :p
<fullermd> "I like to eat babies with mustard, relish, and no XML."   "Wow, really?  That sounds great!"
<Peng> luks: What became of your toy format?
<luks> empty disk space, I think :)
<luks> or maybe it's still somewhere on the laptop
<Peng> It sounds like it was good work.
<luks> well, in my experience with submitting patches to bzr, something like that would never be accepted
<awilkins> SVN working copies used to use XML, they traded "down" to a KV format instead and got large perfomance increases
<luks> I had a few more interesting private branches here, but almost never finished them because I realized I'm just wasting my time
<awilkins> I'm surprised that BZA is using XML in any of it's disk formats, to be honest
<luks> it's legacy thing, I guess
<luks> XML is not a serious bottleneck and if it works, why replace it
<james_w> luks: why do you think they wouldn't be accepted
<awilkins> I mean, what, just loading those enormous libraries must account for a substantial fraction of startup time :-)
<luks> james_w: because even trivial patches sit in BB for months
<james_w> awilkins: it doesn't use the large libraries I don't think.
<james_w> luks: but if it has benefits I'm sure it will be appreciated, and I think it would get people looking at it pretty quickly.
<awilkins> james_w: Hmmph, I wrote a toy library for parsing XML in VB3 once ; I was amazed by the speed you can get when you just walk a pointer through a string buffer on it.
<luks> james_w: as an example, see the ML discusion about the revno patch
<james_w> luks: If you still have it at least I would like to have a look.
<luks> james_w: I sent two mails to the mailing list, it improves performance significantly, and I got no responses
<james_w> luks: true, that one has been overly long.
<james_w> luks: with code?
<luks> mails? yes with working code
<james_w> awilkins: yeah, bzr uses a very basic XML, so it's not hard to parse.
<james_w> luks: ok, let me dig them out.
<luks> in my experience, patches by non-Canonical people are reviewed only if it touches somebody's favorite code
<luks> james_w: no need, I'm not going to finish that patch :)
<luks> and if it touches somebody's favorite code, they will nickpick on unimportant details
<james_w> luks: I'd still like to look.
<luks> I really see bzr development as "closed" and that's why I somehow stopped being interested in it
<james_w> luks: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/35667 <- that one?
<luks> no
<luks> see jam's "[MERGE] lookup revno by iterating history" thread
<james_w> luks: that's not the repository format one though?
<luks> ah, no
<james_w> luks: I agree that should have been looked at though.
<james_w> hopefully jam will pick it up and work on it.
<luks> the repository format was never really finished
<james_w> yeah, but it would still be interesting to look at it to find the good ideas.
<luks> http://bundlebuggy.aaronbentley.com/request/%3C64ab70ac0802041811u61752e66l3a04f025336390ae@mail.gmail.com%3E is another nice example
<james_w> yeah, I was just looking at that one, it's a real shame there's been no real review.
<luks> it's not really about real reviews, but at least telling the person that "the patch is completely wrong" or "it looks good but we don't have time right now" would help
<luks> also I think there are people on the mailing list capable of reviewing patches like this, but their vote wouldn't count anyway, so they just don't
<luks> anyway, enough ranting from me :)
<VSpike> bah
<james_w> luks: I agree.
<VSpike> swapped to cygwin version and now bzr status shows everything as modified or conflicting
<james_w> I realised the other day that apparently anyone can BB:comment, so at least that allows non-reviewer reviewers to have their comments given some status.
<VSpike> even in a just committed tree
<james_w> VSpike: that's not good.
<james_w> luks: thanks for your comments.
<VSpike> james_w: heh. nope
<VSpike> what does it mean when a file has a * after it? not seen that before
<james_w> VSpike: so you're using the same tree as you just were with the native version, but now with the cygwin version.
<VSpike> yes
<james_w> I've no idea actually.
<luks> VSpike: executable bit change
<james_w> were you using the native through cygwin before?
<VSpike> james_w: i was executing it from a cygwin shell
<VSpike> luks: that could be the problem
<james_w> ok, so it might be the jump of going from windows->posix.
<VSpike> how does the windows version comprehend executable bits?
<james_w> I don't know if native via cygwin behaves as windows or posix.
<james_w> VSpike: it doesn't
<james_w> there's a plugin you can use to change the execute bit if you need to.
<luks> VSpike: I think it's just that the dirstate is confused
<james_w> could you pastebin the output of bzr status?
<VSpike> james_w: it would be windows, would be my guess.  Running a windows program from cygwin doesn't change it's environment afaik
<luks> if you don't have any uncommitted changes, try branching it again off the existing one
<james_w> ok, thanks.
<james_w> VSpike: yes, try branching, or bzr remove-tree, bzr checkout may also work.
<jelmer> hi Zindar
<Zindar> hey Jelmer... how's things?
<VSpike> pastebin.com/m7a81b1ef
<jelmer> quite well.. fighting with pyrex
<VSpike> that's bzr diff and bzr status
<Zindar> jelmer: :)
<Zindar> I'm enjoying the emacs bzr mailing threads :)
<Zindar> jelmer: I'm writing support for apple Mail.app in bzr send btw... almost done...
<james_w> VSpike: ah yeah, that's the problem, the windows version has made everything appear executable to cygwin.
<james_w> VSpike: a branch should save you. Otherwise install the xbit plugin and remove the executable status of them all.
<james_w> VSpike: or just chmod in cygwin should work and be less effort.
<jelmer> Zindar: ah, nice
<VSpike> james_w: I'm just trying to recall, but I think cygwin shows everything +x
<VSpike> james_w: I don't think you can remove with chmod
<Zindar> appletalk is not like other languages :)
<jelmer> Zindar: the emacs thread is interesting indeed. It would be nice if we could get them onboard
<jelmer> Zindar: their requirements would probably drive some more performance work, and would be good pr
<VSpike> james_w: oh, ok i lied.  you can
<Zindar> yeah.. but I understand the performance problems... it's almost too slow for me.. and I'm working with a smaller project than emacs
<james_w> Zindar: that would be cool, thanks. Especially when jelmer's child_submit_to patch lands bzr send will be great, so having it work everywhere will be cool.
<Zindar> james_w:  just scratching my own itch :)
 * awilkins is infuriated that Branch.rename_one isn't implemented
<jelmer> james_w: it has already landed :-)
<VSpike> ah, that's better.  find -type f -exec chmod a-x "{}" \;
<james_w> jelmer: ah, cool, I'll start setting it everywhere, thanks.
<awilkins> Dammit, how do you move files from a python console
<awilkins> (in bzr, not the plain os)
<luks> WorkingTree.rename_something
<james_w> awilkins: Tree.rename() I think
<james_w> rename_one() maybe
<awilkins> Branch.rename_on() isn't implemented.... can you gte a Tree from a branch?
<james_w> There's also move() I think, but it has slightly different semantics.
<luks> you can't, the other way around
<luks> you get a branch from a tree
<james_w> tree.bzrdir.open_workingtree()
<luks> (that means, open the working tree, not the branch)
<james_w> branch.bzrdir sorry
<luks> oh
<awilkins> I did "frombzrlib.workingtree import WorkingTree ; tree = WorkingTree.open('.')
<james_w> awilkins: perfect.
<awilkins> I'm walking my tree renaming all my .xml files to .pxml
<awilkins> It was taking forever from a shell with all the process spawning
<awilkins> It's taking a while from the console....
<fullermd> Just proves the earlier point about XML being bad for performance   ;>
<awilkins> Yeah, they'll be much faster when they are pxml files
<awilkins> :-P
<awilkins> It's just so my diff tool can use a custom rule on the without applying it to other xml files
<dato> siretart: are you going to fix your bzrtools upload? it is uninstallable against 1.3. (hint: `bzr diff -c -1` vs `bzr diff -c -2`)
<Peng> Someone should set child_submit_to on bzr.dev (and all the other branches too)
<awilkins> Damn, this rename is still going
<awilkins> 'tis only 3500 files
<awilkins> http://pastebin.ca/948729  << anyone see anything wrong with this in terms of performance ?
<awilkins> Is it rewriting my 6 MB dirstate file after each call, for example?
<james_w> awilkins: nothing specifically.
<james_w> I may be missing something though
<awilkins> I have a feeling it's because I'm using rename_one and the tree has 18,000 files in it
<luks> seems so
<awilkins> It's only done 1300 / 3500 files
<luks> there is a flush call, which seems to save the dirstate
<awilkins> The dirstate is definitely increasing
<awilkins> I'll have a crack with .move()
<Peng> jelmer: bzr-svn (latest 0.4 branch and bzr.dev) fails at branching http://codespeak.net/svn/pypy/dist/: Failed PROPFIND on /svn/!svn/bc/45181/pypy/dist
<jelmer> Peng: One sec, I'll see if I can reproduce it here
<Peng> Thanks.
<awilkins> Bah, I don't think move() can rename the file, just moves the folder it's in
<awilkins> (from reading code)
<fullermd> Brings back memories of when 'mv' and 'move' and 'rename' were separate commands.
<awilkins> I don't think theres an API call that can do bulk renames :-( *sulk*
<awilkins> Well, not a "public" one, I think
<jelmer> Peng: this is a server side issue
<jelmer> svn ls -r45181 http://codespeak.net/svn/pypy/dist fails as well
<jelmer> (or a svn client library issue, depending on how you want to look at it)
<Peng> jelmer: Ok. That sucks.
<Peng> "trivial commit to test pushing from bzr"
<jelmer> wow, ok
<jelmer> that's either a very big coincidence or there's something funky happening here
<jelmer> ah, 45182 fails too
<Peng> (45181 is probably related to https://code.launchpad.net/~mwhudson/pypy/bzr-svn)
<Peng> s/probably//
<dato> siretart: ok, I'll fix
<awilkins> Oh you have to be frickin' kidding me
<awilkins> Seems the new Vista SP1 has some "security" fixes in it
<awilkins> I can no longer change the permissions on "notepad.exe" so that I can overrwrite it with something non-crap
<fullermd> Friend of mine once had a Win2k machine that did something like that.  It would reappear every time it was deleted.
<awilkins> Oh, that's not too hard to get around.
<awilkins> No, this is different ; I'm an admin user but I can't change the file permissions
<awilkins> I could before
<fullermd> Obviously, anybody trying to harm notepad is a hax0r and must be stopped.
<awilkins> I wonder if I reboot in Ubuntu and copy over it it will notice / moan ?
<awilkins> Bah
<siretart> dato: BAH, sorry, I was in the wrong branch :(
<dato> siretart: no worries, fixed now.
<siretart> dato: thanks!
<dato> np
<siretart> I experimented in a private branch for the snapshotting, and botched the merge for the 'offical' branch
<siretart> :/
 * awilkins has remembered the fix for his "notepad nazi-ism" problem
<jelmer> dato,siretart: hi
<jelmer> Would either of you be able to sponsor the first upload of bzr-dbus these days?
<jelmer> *one of
<siretart> jelmer: There is no debian/watch file, so can't use that to retrieve upstream tarball
<siretart> (message from bzr bd) :)
<siretart> jelmer: any reason to not use debhelper 5?
<jelmer> siretart: it should get a snapshot from launchpad
<jelmer> siretart: No, that's a mistake on my part
<jelmer> siretart: should be fixed now
<siretart> would you care to commit a watchfile?
<siretart> see the bzrtools package for an example
<dato> well, I don't think bzr-dbus has released tarballs?
<jelmer> yeah, that's the problem at the moment
<siretart> oh, I see. bzr-builddeb is in export-upstream mode
<siretart> bzr: ERROR: No such tag: bzr-dbus-0.1~bzr34
<jelmer> siretart: what version of bzr-builddeb are you running?
<siretart> ii  bzr-builddeb             0.92                     bzr plugin for Debian package management
<siretart> perhaps http://bzr.debian.org/pkg-bazaar/bzr-dbus/unstable/ doesn't have the necessary tags?
<jelmer> newer versions will interpret ~bzr34 and export revision 34
<siretart> aah, I see
<jelmer> you can also override it manually by specifying --export-revision=34 (IIRC)
<jelmer> looks like it's actually --export-upstream-revision=34
<siretart> yes, that seems to do the trick
<james_w> I'm going to get all those fixes together later.
<siretart> jelmer: the selftests are failing
<siretart> Ran 37 tests in 1.039s
<siretart> FAILED (failures=2, errors=1)
<siretart> are you aware of that?
<jelmer> siretart: ouch, no
 * jelmer fix0rs
<jelmer> siretart: fixed
<siretart> did you push to http://bzr.debian.org/pkg-bazaar/bzr-dbus/unstable/?
<jelmer> argh, wrong remembered push location
<jelmer> should be fixed now
<siretart> jelmer: the testsuite seems to assume a running and working dbus, right?
<siretart> http://paste.ubuntu.com/5872/
<jelmer> siretart: yes
<jelmer> siretart: the plugin should however cause no trouble if dbus is not available
<jetsaredim> is there a "proper" way to do a merge on a file that has conflicts?
<james_w> jetsaredim: sorry, can you explain please?
<jetsaredim> lets say I have two completely different versions of a file
<abentley> awilkins: A public API that can do bulk renames is TreeTransform.
<jetsaredim> I know I want all of one and none of the other
<jetsaredim> if I just plaster the one I want over the one that's there - is that going to screw up any sort of vcs tracking?
<awilkins> abentley: Thanks for the pointer
<abentley> It can do anything to a working tree, which is why its API is rather ugly.
<abentley> There should probably be a "renames" method on WorkingTree.
 * awilkins thought the same ; was thinking about refactoring "rename_one" into "rename_many" and getting "rename_one" to call it
<abentley> I'd implement rename_many on TreeTransform, not refactor rename_one.
<abentley> Because TT will always do what you ask it to.
<jetsaredim> so - is that a "it doesn't matter"?
<abentley> A naÃ¯ve implementation of rename_many will rename files on top of one another.
<fullermd> jetsaredim: Overwriting a file with 'cp' isn't any different from the VCS's POV than editing it to remove the conflicts, so I can't think how it would.
<jetsaredim> ok cool
<abadger1999> jelmer: ping
<jetsaredim> thanks all
<abadger1999> Hey guys, brandon_rhodes has some questions about bzr-svn.
<abadger1999> Can anyone here comment on a few end user questions?
<jelmer> abadger1999: pong
<jelmer> abadger1999: sure
<jelmer> brandon_rhodes: hi
<brandon_rhodes> jelmer: Hey!
<brandon_rhodes> If I use bzr locally and then commit back to svn, then it can't of course do the merge back to svn with the separate changes I've made listed under the merge change.
<brandon_rhodes> But ... does it at least make a cool commit comment or something that lists the local changes that were included in the merge?
<siretart> jelmer: uploaded
<jelmer> brandon_rhodes: Not sure I understand what you mean. bzr merges are tracked in svn
<jelmer> siretart: tahnks!
<brandon_rhodes> jelmer: In subversion, if I make 10 changes on a branch then merge to trunk, subversion just says "here's brandon's Big Change To Trunk", and it looses the info that the merge is of ten separate little changes.  Linus complains about this.
<jelmer> brandon_rhodes: So, bzr-svn stores information about the merge in svn properties
<jelmer> so bzr will be able to see where the changes were merged from
<brandon_rhodes> jelmer: I'd heard a rumor that, in bzr, the "4031 Brandon merges his stuff" change to trunk has, listed underneath it / inside it, the 10 changes I made that then got put together in the merge...
<brandon_rhodes> Whoa!
<brandon_rhodes> It uses svn properties?
<brandon_rhodes> That's heavy!
<jelmer> brandon_rhodes: However, you won't be able to see what was merged from svn
<jelmer> there is no way to adjust the commit message - it would break referential integrity in bzr
<jelmer> at least until we do a format upgrade
<brandon_rhodes> Oh ... huh.
<jelmer> brandon_rhodes: You can include information about the merges in the commit message yourself though
<brandon_rhodes> So you couldn't have the message, beneath my own comment, auto-include a bit of text that says "this merge included 9 separate changes: ..." and maybe list one-line summaries of them or something?
<brandon_rhodes> It would just be cool to see that info when other developers were browsing svn normally
<jelmer> brandon_rhodes: bzr push to svn does the same thing as bzr push to any other bzr branch - it preserves the exact revision
<jelmer> one of the core ideas behind most dvcses is that a specific revision id can only refer to exactly one unique revision
<jelmer> (referential integrity)
<jelmer> changing the commit message would violate that basic rule
<jelmer> there are two possible ways around this:
<jelmer> - we could set two revision properties in svn: one that svn sees and one that bzr sees. This however can't happen until the next mapping upgrade of bzr-svn
<jelmer> - it should be fairly easy to write a plugin that edits the bzr commit message and inserts the merge info there
<jelmer> brandon_rhodes: still there?
<brandon_rhodes> Yes.
<brandon_rhodes> Sorry, writing up 2nd day sprint report :-)
<brandon_rhodes> jelmer: I think I'd better play with bzr and subversion some myself, and then I'll understand what's going on with merging. :-)
<brandon_rhodes> All I know right now is what someone drew for me while talking
<jelmer> brandon_rhodes: ah :-)
<jelmer> brandon_rhodes: A better way of describing it is probably to consider what "bzr push" should do
<jelmer> brandon_rhodes: you would expect it to make sure that the branch on the remote side contains the exact same contents as your local branch
<brandon_rhodes> jelmer: Um.
<brandon_rhodes> jelmer: Oh. You're talking about a situation where the branch actually exists in Subversion?
<jelmer> brandon_rhodes: Not necessarily - it is also push to push a new branch into subversion
<brandon_rhodes> jelmer: I thought I'd heard a guy talking about just copying svn /trunk into a bzr of his own, then merging right back into svn /trunk.  I'd missed the fact bzr was creating a branch in svn.
<brandon_rhodes> Then it makes sense that you'd copy the changes 1-for-1.
<brandon_rhodes> But it still seems subversion couldn't "see" what the merge included like bzr can "see" that the merge to /trunk is the sum of lots of little changes in the branch ... is that true?
<jelmer> brandon_rhodes: well, if you use "bzr push svn://.../trunk" you're telling bzr to add the extra revisions you have locally to /trunk
<jelmer> brandon_rhodes: yes, that's correct
<brandon_rhodes> jelmer: As separate revisions? Gotchya.
<jelmer> brandon_rhodes: Only the mainline revisions
<brandon_rhodes> Roger.
<jelmer> brandon_rhodes: Since subversion doesn't support merge tracking
<brandon_rhodes> Right.
<brandon_rhodes> It just mushes them all together.
<jelmer> right
<ubotu> New bug: #203941 in bzr "Bzr -r ancestor:badbranch signals errors too late" [Undecided,New] https://launchpad.net/bugs/203941
<jelmer> Peng: any chance you can file a bug about that bug in bzr-svn you hit with codespeak?
<Peng> jelmer: Ok.
<Verterok> moin
<intellectronica> hya, i'm getting the following error when trying to push to a server: ShortReadvError: readv() read 3451 bytes rather than 3640 bytes at 1997614 for ...
<intellectronica> any ideas what could that be? bzr 1.2 both locally and on the sever
<brandon_rhodes> Can bazaar do svn:externals-like stuff?
<brandon_rhodes> And can it do it on files instead of svn which can only do directories (eww!)
<Peng> brandon_rhodes: Not yet.
<brandon_rhodes> It would be cool to have a VC that could easily version control something like /etc/ or my homedir, where some stuff needs to be checked out from a common repo (so my .bashrc might look the same on all my systems), but pull other stuff from a per-homedir or per-system repo
<brandon_rhodes> So that /etc/sysctl.conf could pull from a "debian-common" repo and be the same on my machines, but "/etc/hostname" be per-machine
<fullermd> I doubt nested-files will ever be around.
<fullermd> That calls more for symlinks, or maybe just merges.
<brandon_rhodes> Drat. :-)
<brandon_rhodes> And it would be neat if the first part of /etc/sysctl.conf could pull from "debian-common" but then have the file end with stuff from a machine-specific repository :-)
 * fullermd will hold out for a pony instead.
 * brandon_rhodes grins :-)
<LarstiQ> fullermd: what do you mean with nested-files?
<LarstiQ> oh eek
<ubotu> New bug: #203975 in bzr-svn "PROPFIND failed branching http://codespeak.net/svn/pypy/dist/" [Undecided,New] https://launchpad.net/bugs/203975
<fullermd> LarstiQ: Egads!  Don't look; you'll go blind.
<jelmer> Peng: thanks
<jelmer> curl is the http library that is going away, no?
<Peng> I'm using curl, aren't I?
<Peng> Well, I am, but how would you know?
<Peng> Yes, it is.
<ubotu> New bug: #203979 in bzr "ShortReadvError trying to push to a server" [Undecided,New] https://launchpad.net/bugs/203979
<LeoNerd> Has anyone here ever played with the Python CPAN module..? Module for constructing/interacting with Python objects from Perl code...
<LeoNerd> I'd like to instantiate a 'bzrlib' object from Python, so as to call various methods on it
<fullermd> Funny, I've thought passingly about that very thing...
<dato> *g*
<barry> hi folks, quick question: we're setting up bzr serve via ssh in an authorized_keys file command="" section.  having some problems and we're wondering if bzr serve logs anywhere?
<LeoNerd> So.. Not being a python programmer, could someone suggest me a nice simple line to demonstrate that bzrlib is working..? I now have a shiney Inline::Python perl module here ;)
<barry> we're using: command="/usr/bin/bzr serve --allow-writes --inet --directory=/foo"
<barry> and we're getting an error -1 when we try to bzr push bzr+ssh://
<LeoNerd> Are you sure you need that --inet there?
<dato> no idea, but I guess you checked ~/.bzr.log already?
<LeoNerd> Oh.. heh. so you do. Never mind :)
<barry> dato: we're not getting a .bzr.log file
<barry> LeoNerd: yeah ;)
<dato> ok
<barry> btw, we're using bzr 1.1rc1 on the server
<barry> we figured it out
<luks> LeoNerd: I think it would be easiest to write most of what you need in python and use only simple functions from perl
<LeoNerd> Hrm... Technically I guess it would work either way around
<luks> because the bzrlib API is full of classes and I'm not sure how well does Inline::Python handles that
<LeoNerd> Inline::Python does classes
<LeoNerd> It wraps them in a trampoline object, that supports the same methods
<luks> yeah, but to what extent
<luks> http://bazaar-vcs.org/Integrating_with_Bazaar has some examples of simple bzrlib usage
<LeoNerd> .oO( How annoying.. vim can't highlight python in heredocs in perl code.. booo )
<LeoNerd> Hmm....   repo = branch.repository    <== that's an attribute rather than a method call, yes?
<luks> yes
<luks> method calls have (), this is not perl :)
<LeoNerd> Hm... OK
<dato> luks: well, it could be a property
<dato> (no idea if that'd be relevant for what LeoNerd is doing)
<luks> right
<luks> but that's the same for Inline::Python, I think
<luks> since the method call is handled by python automatically
<scode> Hmm. I was under the impression 'bzr serve' would produce a browseable web interface, in addition to the optimize bzr synch protocol. What is the idiomatic way to provide a web browsable copy of a repository?
<scode> (bzr serve does not seem to speak HTTP when I try it)
<radix> scode: loggerhead I think
<dato> scode: there is no built-in capability in bzr for that
<LeoNerd> Hrm.... It seems Inline::Python only supports method calls on wrapped objects, not attribute access
<luks> that's why I mentioned implementing "wrappers" in python
<scode> radix/dato: Ok - thanks.
<LeoNerd> Can I add new methods to an existing class.? Are all classes open?
<luks> yes
<LeoNerd> Woo :) I've just opened a branch, queried top revision, and printed its log summary. From perl ;)
<james_w> scode: there's bzr-webserve  as well that provides a "webserve" command to give a HTTP interface
<dato> and there is even a third one nobody ever remembers
<ubotu> New bug: #204025 in bzr "Concurrent updates of separate threads in a shared repository fails" [Undecided,New] https://launchpad.net/bugs/204025
<LeoNerd> Hm.. So.. how much of the core simple stuff in bzrlib is going to use attrs rather than methods?
<LeoNerd> .oO( Also I can't see documentation on these attrs on the docs pages - do they not come out? )
<LarstiQ> LeoNerd: in what sense?
<LeoNerd> LarstiQ: Well.. the examples use   branch.repository   to get the repo. for a branch... I couldn't see that on the branch docs page
<LarstiQ> LeoNerd: there are lots of non-methods like that, yes
<LeoNerd> Hmm.. :/
<LarstiQ> LeoNerd: a method wouldn't really make sense
 * LeoNerd ponders improving Inline::Python so it can do that
<LarstiQ> ?
<LarstiQ> LeoNerd: yay :)
<LeoNerd> Simply implementing hash lookup ought to be sufficient
<LeoNerd> Hmm.. though.. dunno what Python's API might make it look like
<LeoNerd> I could tie STOREHASH and RETRIEVEHASH so that  $branch->{repository}  is rvalue and lvalue
<LeoNerd> But.. more interesting things like enumerating all the keys...  keys %$branch   ... would python allow that?
<luks> keys %$branch would be similar to dir(branch)
<LarstiQ> LeoNerd: there is no iteration on the object itself for it's members, but you can do that on object.__dict__ (which is a dictionary)
<LarstiQ> luks: thanks, now I know what keys does ;)
<LeoNerd> Hmm.. Is every object backed by just a dictionary?
<luks> LarstiQ: d.keys()
<LarstiQ> LeoNerd: not in theory, though most won't play funny games on you
<scode> james_w: thanks!
<LeoNerd> Hm.. OK.. So would it be reasonable to represent an object as a hashref, to allow the usual sorts of things with its keys?
<LarstiQ> LeoNerd: if properties are used, or __getatrr__ is overriden, the answer would be no
<LarstiQ> LeoNerd: I don't know perl nor it's idioms
<luks> LarstiQ: not really
<luks> properties don't really translate well to that
<luks> because the value can change in any "call"
 * LarstiQ thought he just said that?
<LarstiQ> though I confess in a roundabout way
<luks> yeah :)
<luks> I think best would be to treat them all as functions
<LeoNerd> Well.. a real native hash allows getting/setting of arbitrary named elements, and enumeration of the keys
<luks> but then you can't easily assign to them, so you would have to use e.g. branch->repository($new_repo)
<LeoNerd> Would it be sensible to make a python object look like that?
<LeoNerd> Yah.. plus.. I wasn't sure if they live in different namespaces
<LeoNerd> object.foo() vs. object.foo
<luks> no, they are in the same namespace
<luks> object.foo() just takes object.foo and calls it
<LeoNerd> Ah OK.. Though.. Looking at how the Inline::Python works, it just throws (pl) method calls into (py) method calls. If I did the attrs. like that as well, it would have to know which one to do
<LeoNerd> Plus, your point about assignment... I suspect a hash is the way to go here
<luks> maybe implement something like getattr, setattr?
<luks> (that is, separate functions)
<LarstiQ> LeoNerd: everything on an object is an attribute lookup first
<LarstiQ> wow, that's sloppily worded
<luks> actually, it probably allows you to use the native ones from python
<LeoNerd> branch.getattr("repository")   or something?
<luks> gettattr($branch, "repository")
<LeoNerd> Hrm... That seems not to be exported to perl :/
<LeoNerd> I suspect this probably requires more poking at Inline::Python's internals...
<LeoNerd> Ooh.. but methods are just code refs as attributes, yes? I wonder if breakage would happen if you try to pull one of those out directly
<mxpxpod> besides bzr-hg (which doesn't work with bzr 1.2), is there a hg->bzr converter?
<Odd_Bloke> mxpxpod: There's fast-export/import which might work.
<mxpxpod> oh, cool
<mxpxpod> I didn't realize that fastimport came with exporters
<dato> mxpxpod: well, you'll need an exporter for hg
<dato> mxpxpod: I think there is one in... sec
<mxpxpod> dato: fast-import comes with one in the exporters directory
<dato> oh
<dato> well, they've made a copy from the canonical location then
<mxpxpod> dato: from where?
<dato> http://repo.or.cz/w/fast-export.git
<mxpxpod> no no, I was talking about the fast-import bzr plugin coming with exporters
<dato> mxpxpod: though maybe bzr-fastimport is its new home, not sure
<dato> yes
<dato> I said they made a copy
<dato> you said from where
<mxpxpod> oh, gotcha
<dato> I gave you the "from"
<dato> :)
<mxpxpod> ;)
<weigon> what to do when I get:
<weigon> bzr: ERROR: Pack '2765b027c9b99141c06eeabd2ca628ac' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x0151EF90>
<weigon> ... on a push
<weigon> if it already has it, why does it try to apply it ?
<james_w> dato: yeah, I think we've taken over fast-export.git
<james_w> or rather incorporated it.
<weigon> ... and why does it work at a second try ? locking ?
<james_w> weigon: it probably pushes a different pack, or doesn't bother as it already exists. I don't know why you would have got the first one.
<dato> james_w: oh, I see :)
<fullermd> It's not the first time the error has come up.  Nobody's made it reproducible yet, though.
<fullermd> I think it's considered to be a manifestation of some weird bug.
<james_w> weigon: a bug filed with the relevant chunk of your ~/.bzr.log may start the ball rolling.
<james_w> siretart: hi. I realise it's late, so it's fine if you're not able to do it today. I have pushed what I think is a working package to the launchpad branch. If you could check it and upload that would be great, thanks.
<siretart> james_w: not alioth?
<james_w> siretart: http://bazaar.launchpad.net/~james-w/bzr-builddeb/trunk in case you lost the URL.
<james_w> siretart: no, launchpad, I can push to alioth if you would like.
<james_w> in fact I'll do that anyway.
<siretart> ok
<siretart> I just wouldn't expect a branch named 'trunk' to be suitable for publishing in a distribution :)
<siretart> at least not without further comments about that
<james_w> ah, ok.
<siretart> ok, I've updated the branch info, so lp:bzr-builddeb *should* point to the up-to-date branch
<james_w> thanks
<siretart> seems to work
<james_w> do you know if they run denyhosts on alioth?
<dato> denyhosts?
<siretart> the package does not seem to be installed
<siretart> so I'd assume no
<james_w> one of the "block ip addresses that guess passwords on ssh" scripts
<dato> oh
<dato> they use fail2ban afaik
<james_w> I guess there are many, I don't even know if denyhosts is the right name
<james_w> ah, that's it then. That's why I always have trouble connecting to alioth.
<dato> really? what do you do for it to hate you? :)
<mxpxpod> has there been any recent work to get svn:externals working in bzr-svn?
<james_w> I forgot to set a user in ~/.ssh/config, so I always try and log in first with my local username, and then obviously get blocked about the same time that I realise.
<dato> ah, heh
<james_w> I've rectified that now, so I should be able to do it properly next time.
<dato> james_w: that has an easy solution
<dato> james_w: become a DD
<james_w> mxpxpod: I haven't heard of any.
<dato> :-P
<james_w> dato: or that...
<james_w> :)
<mxpxpod> james_w: are nested bzr trees supported?
<james_w> though I don't use my local username anywhere else.
<james_w> mxpxpod: sort of.
<james_w> mxpxpod: vague answer I know
<mxpxpod> :D
<james_w> mxpxpod: there is some support for storing the necessary data, but actually using them will typically fail as there are plenty of bugs to shake out.
<mxpxpod> for instance: https://bugs.launchpad.net/bzr-svn/+bug/82863 mentions that development is blocked by support for by-reference nested trees
<ubotu> Launchpad bug 82863 in bzr-svn "svn:externals is not supported" [Wishlist,In progress]
<siretart> james_w: http://paste.ubuntu-nl.org/60220/ :(
<james_w> siretart: is there a line missing from the end of that?
<siretart> ImportError: cannot import name tests
<siretart> make: *** [build-python2.5] Error 1
<siretart> these were missing
<james_w> ah, stupid stupid me.
<siretart> hey, I even did a stupid upload today ;)
<james_w> I can't seem to find a reliable way to run the tests during the build
<james_w> siretart: I'm too tired to really think about this any more tonight. Do you want to wait until another day, or just upload with the tests disabled?
<siretart> james_w: I've just tried to do that. package builds fine, but `bzr selftest builddeb` still fails. are you aware of that?
<james_w> siretart: can I see the errors please?
<james_w> it works fine for me.
<james_w> though I'm python2.5 based, are you on a 2.4 machine?
<siretart> http://paste.ubuntu-nl.org/60224/
<siretart> I'm on a pretty freshly installed debian/sid system
<siretart> which has /usr/bin/python still pointing to python2.4
<james_w> oh, what? Why does that not work for you?
<james_w> it's not a python2.4 issue.
<siretart> there doesn't seem to be any tests installed into the package.. hmm
<james_w> that might be it :)
<james_w> siretart: thanks :) We should be able to enable the tests now.
<james_w> packages=['bzrlib.plugins.builddeb'],
<james_w>       package_dir={'bzrlib.plugins.builddeb': '.'},
<james_w> that doesn't seem to be enough in setup.py to build and install the tests.
<hacklberry> is it possible to make bzr work with mingw ssh on windoze (or does bzr work only with putty)?
<james_w> hacklberry: as I understand it there are several options for ssh on windows.
<james_w> e.g. plinj
<james_w> plink sorry
<james_w> and it can/does use paramiko, so anything that can use is ok.
<james_w> I don't know if it can use the mingw one though, sorry.
<siretart> I think I fixed it now
<siretart> james_w: are you okay with this patch: http://paste.ubuntu-nl.org/60226/
<james_w> siretart: that would be fine. If you have a couple of minutes I think I may have a better one.
<siretart> ah, sure
<hacklberry> james_w: it looks like it does not work with mingw ssh, i just tried a little test, first on my slackware laptop:
<hacklberry> martin@yobbo:~/test_bzr$ bzr branch sftp://martin@192.168.130.143/home/martin/bzr/rlm_ftress
<hacklberry> Branched 109 revision(s).
<hacklberry>  and here is the result from my windoze workstation (when trying to do the same from a mingw/msys terminal):
<hacklberry> $ bzr branch sftp://martin@192.168.130.143/home/martin/bzr/rlm_ftress
<hacklberry> command-line: line 0: Bad configuration option: ClearAllForwardings
<hacklberry> bzr: ERROR: Unable to connect to SSH host 192.168.130.143; EOF during negotiation
<james_w> siretart: if you pull I think that should work.
<james_w> siretart: if not, please upload your change.
<james_w> hmm, I wonder where that "ClearAllForwardings" comes from.
<james_w> hacklberry: it looks like it is could work, if you can work out what that means then you may be able to fix it, or work out how bzr can support it.
<siretart> well, you incorporated my change to setup.py :)
<hacklberry> has something to do with how bzr uses the mingw ssh i guess, the ssh on its own works fine, ie. i can do slogin martin@192.168.130.143 without any problems
<lifeless> yawn link, good morning
<mwhudson> hello lifeless
<james_w> hi lifeless
<james_w> hacklberry: ok, so it would be great if you could find out what bzr is doing wrong and file a bug.
<hacklberry> james_w: i m playing with it now
<james_w> hacklberry: great, thanks.
<siretart> james_w: the test-builddeb command seems to run all tests just fine, but reports exit code 1 instead of 0, which fails the build. huh?
<james_w> siretart: sorry, stupidity again.
<james_w> siretart: it returns result.wasSuccessful()
<james_w> so it wants a return not result in __init__.py
<james_w> siretart: fix pushed, sorry.
<siretart> heh. I'm learning more and more about bzr :)
<siretart> 'not result'?
<siretart> that looks weird..
<james_w> siretart: true, I'll fix it.
<siretart> but works! :)
<james_w> correction pushed if you care, otherwise it can wait.
<james_w> readable good. working better.
<poolie> hi
<james_w> hi poolie
<siretart> james_w: ah, thanks for clarifying that. I'll upload in a sek
<james_w> siretart: brilliant, thanks.
<james_w> thanks siretart
<siretart> you're welcome!
<hacklberry> excuse my naivite, but i think the following message is (perhaps) incorrect (as i do not run a bzr server):
<hacklberry> C:\test>bzr branch bzr+ssh://martin@192.168.130.143/home/martin/bzr/rlm_ftress
<hacklberry> Connected (version 2.0, client OpenSSH_4.3p2)
<hacklberry> Adding ssh-rsa host key for 192.168.130.143: 07AA7C20C76E8D87F84EBB7E1FCD07F6
<hacklberry> Authentication (publickey) successful!
<hacklberry> Secsh channel 1 opened.
<hacklberry> Server is too old for fast get_parent_map, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<hacklberry> Connected (version 2.0, client OpenSSH_4.3p2)
<hacklberry> Authentication (publickey) successful!
<hacklberry> Secsh channel 1 opened.
<hacklberry> Branched 109 revision(s).
<siretart> hacklberry: bzr+ssh:// uses the smart server on the remote side, starting it on demand
<hacklberry> siretart: thanks
<hacklberry> siretart: just out of interest - does bzr need to be installed on the remote box where i store my branches? (it didn't use to)
<asabil> hacklberry: no, but if you have it it is better
<asabil> it allows you to use the bzr:// transport (actually bzr+ssh://)
#bzr 2008-03-20
<ubotu> New bug: #111826 in bzr-gtk "Broken menu items in nautilus integration " [Low,Fix committed] https://launchpad.net/bugs/111826
<ubotu> New bug: #149061 in bzr-gtk "Cannot view diff of first revision" [Medium,Fix committed] https://launchpad.net/bugs/149061
<radix> PenguinOfDoom: bzr branch lp:~subol-hackers/subol/shared.dev
<radix> oops, mischan
<poolie> hi radix!
<radix> yo poolie :-)
<RAOF> Heya radix!
<radix> wow, it's a party
<radix> Hi RAOF :)
<RAOF> :)
<poolie> lifeless: what are your thoughts on rich-root-pack conversion bugs and 1.3?
 * Odd_Bloke pumps out the beats.
 * TFKyle pumps out the beasts
 * j1mc jumps to the pumped out beats
<TFKyle> (aka. party-goers)
<lifeless> poolie: 1.3 is time based, I don't think those things are related
<lifeless> poolie: as the conversion issues are not regressions
<j1mc> lifeless: just wanted to say thank you for your explanations yesterday.  you were very helpful.  the history is now correct, and i've used bzr bind to ensure i won't have the same problem again.
<poolie> in other words go ahead without it
<lifeless> j1mc: cool
<j1mc> :)
<lifeless> poolie: yah
<lifeless> poolie: what do you think
<poolie> it does seem to have been present for a while
<lifeless> bbiab food ftw
<lifeless> squid folk are liking bzr fwiw
<lifeless> need to do some tweaks to bb for them
<lifeless> use the right bugtracker
<lifeless> and allow anonymous email voting
<hunmonk> anybody have a sec to help me w/ an rspush error i'm getting?
<lifeless> sure
<hunmonk> lifeless: 504 colossus$~/Sites/apartmentlines.com/www: bzr rspush watchdog:bzr/apartmentlines.com
<hunmonk> bzr: ERROR: Rsync could not use the specified location.  Please ensure that "watchdog:bzr/apartmentlines.com/" is of the form "machine:/path"
<hunmonk> lifeless: if i run scp foo watchdog:bzr/apartmentlines.com
<hunmonk> lifeless: works perfectly
<hunmonk> lifeless: so i'm a bit confused what the issue is
<lifeless> hmm
<Odd_Bloke> hunmonk: The path you're giving isn't absolute, which the error message would suggest is required.
<lifeless> well spotted
<hunmonk> Odd_Bloke: full path doens't work, either
<lifeless> also, are you aware of push-and-update ? its a plugin
<lifeless> I would look in .bzr.log and see if anyting interesting is there
<lifeless> also perhaps try strace and snarf the actual rsync command line being tried
<hunmonk> lifeless: where is .bzr.log?
<hunmonk> home dir?
 * hunmonk looks
<hunmonk> yup
<hunmonk> lifeless: http://pastebin.ca/949874
<lifeless> rsync is erroring
<lifeless> strace is your friend
<hunmonk> lifeless: lol.  no strace on my mac
<hunmonk> lifeless: guess it's time to hit fink...
<lifeless> truss perhaps ?
<hunmonk> nope
<lifeless> got to me some equivalent
<bob2> dtrace11
<lifeless> anyhow, rsync is existing with status 12
<hunmonk> lifeless: doesn't scp use rsync as well?
<bob2> no, scp is like cat over ssh
<lifeless> hunmonk: no
<hunmonk> oh
<mwhudson> 'ktrace'
<mwhudson> i think
<fullermd> I'd expect rsync is spitting an error somewhere.  Try just running it manually.
<hunmonk> fullermd: yeah, that was my next thought as well
<hunmonk> lifeless: rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359)
<hunmonk> lifeless: i've never seen that before  :|
<fullermd> Why, of course!  You forget to giblinetch the huntra in the config file.  Duh
<bob2> could any of your login scripts on the remote machine be printing something out?
<hunmonk> bob2: maybe
<hunmonk> lol
<hunmonk> lifeless: found the problem
<hunmonk> lifeless: no rsync installed on destination server  :)
<abentley> lifeless: Do you want to preserve the code style differences between the loom plugin and bazaar?
<jml> I sense some restrained frustration there :)
<jml> poolie: how's the release going?
<jml> poolie: also, where's the branch for it?
<lifeless> abentley: which ones?
<abentley> The imports are the main thing I'm noticing.
<poolie> jml, http://bazaar-vcs.org/bzr/bzr.1.3
<abentley> In bazaar proper, we hardly ever do "import bzrlib.merge", for example.
<abentley> It would be "from bzrlib import merge as _mod_merge"
<lifeless> abentley: oh, its because loom is old code
<abentley> Or possibly a direct object import.
<lifeless> abentley: it was written in the same style as bzr of the time
 * jml registers
<abentley> By which I take it it's fine to use current Bazaar style in it?
<lifeless> totally
<abentley> Cool.
<abentley> I'm running into a test case failure because we can't represent a tree whose last_revision is NULL_REVISION that has pending merges.  I think I'm going to drop it, but we should really fix that in Bazaar.
<lifeless> uhm
<lifeless> whats the reason for it ?
<lifeless> like is it an existing test
<lifeless> or a new one, and if new whats the use case?
<abentley> No, I'm writing a new test, and I got an unexpected error.
<abentley> I'm doing up_thread(); up_thread()
<abentley> The second up_thread raises cannot switch threads with anout of date tree. Please run bzr update.
<abentley> The underlying cause is that when last_revision is NULL_REVISION, tree.get_parents() is []
<abentley> So adding a pending merge sets the lefthand parent.
<lifeless> right, thats currently by design
<lifeless> its consistent with our history storage too
<abentley> Well, intentional or not, it's a limitation on what Bazaar can do, and it's occasionally reported as a bug.
<lifeless> so I'm guessing your use case looks like
<abentley> And in this case, it's causing looms to give an error that doesn't make a lot of sense.
<lifeless> loomify, create-thread, down-thread, commit, up-thread
<abentley> And then up-thread again.
<lifeless> I would say in this case that up-thread leaving the new-thread the same as the bottom thread is actually fine
<abentley> So you're saying that if up-thread changes the last_revision, it should change it on the branch also?
<lifeless> uhm
<abentley> The bottom thread has a new revision.
<abentley> Call it X
<abentley> bzr up-thread will set X as the tree's last revision, but will set the branch's last_revision to NULL_REVISION
<abentley> You are saying it should set the branch's last_revision to X as well?
<lifeless> I think it should set X as the threads last revision in this specific case; which will change the branch's last-revision as teh branch is just reflecting the thread state.
<abentley> lifeless: What mechanism sets a thread's last revision?  All I see being set is the branch and tree.
<lifeless> set_threads & _set_last_loom
<lifeless> see for instance LoomSupport.record_thread
<lifeless> thats the api you probably want to use here
<abentley> lifeless: up_thread is currently doing Branch.generate_revision_history.  Swapping Branch.record_thread in breaks things horribly
<abentley> I'll leave it generating revision history, and update it so it sets it to X when appropriate.
<lifeless> abentley: you need both
<lifeless> abentley: here's why.
<lifeless> there is some duplicate data in the current loom branches, because of lazy-robert.
<lifeless> the duplicate data is the current branch tip in .bzr/branch/last-revision, and the current thread version of the same data in .bzr/branch/current-loom[branch.nick]
<lifeless> up-thread is normally just setting the last-revision to match the thread, but now it has to (sometimes) update the thread too
<abentley> But hardly anything updates the thread copy, right?
<abentley> Why isn't that calamitous?
<lifeless> abentley: with a last-loom format update to record the revno in each thread, we could drop last-revision from disk and remove the duplication
<lifeless> abentley: its not alamitous because looms hook in very lightly, and try to preserve regular branch behaviour as much as possible.
<abentley> But commit doesn't update the thread copy, so why should up-thread update the thread copy?
<lifeless> commit updates it
<lifeless> now I need to remember how
<lifeless> or if it doesn't then thats an interesting bug
<abentley> I was just assuming that the behavior was lazy enough that it didn't matter.
<lifeless> unlock does it
<lifeless> read the unlock code
<lifeless> so yes, you can be lazy here.
<lifeless> and just set branch.last_revision
<lifeless> as long as you'll be on the right thread when the branch is unlocked
 * poolie starts 1.3 packaging
<poolie> lifeless, abentley: any opinions on my mail about testing for unreleased locks?
<abentley> As long as we do it, I don't care how.
<poolie> i think i will keep a list of held locks
<poolie> which is essentially what we're getting python to do for us, but in a flaky way
<lifeless> poolie: did we not plan this at allhands?
<lifeless> poolie: I thought the plan was to - provide a global event anyone can subscribe to which fires on lock and unlock
<poolie> it rings a bell, i can't recall what was decided though? i think we said what i just said
<lifeless> poolie: then add to the root TestCase a subscriber to that which accumulates lock/unlock events. And finally an addCleanup that asserts they are all matched.
<lifeless> this is better than a global list of locks
<poolie> k
<lifeless> its better because we can then write tests that test the number of locks actually taken/released by a command
<lifeless> and things like that
<poolie> right, that sounds good
<lifeless> it also doesn't depend on gc() having been run before the test finishes, or no-loops, and other such implementation details
<poolie> sure
<poolie> it's a strict superset
<poolie> of what i was proposing
<poolie> i'll send a patch for it
<lifeless> sweet
<lifeless> stab stab stab get_revision_graph
<poolie> "that, and a pair of testicles"
<poolie> makes me smile every time i make a release
<poolie> vale jdub
<poolie> welcome back tim
<poolie> it turns out jam's renvo code has some bugs.
<abentley> At least it doesn't have a pair of testicles.
<lifeless> who knows
<lifeless> hno in squid called bb bundlebunny the other day
<abentley> hehe.
<Odd_Bloke> jml: I'm struggling to get ``bzr merged-branches`` working at all.  If I have a 'bzr' directory with 'bzr.dev' and my topic branches under it, how can I get it to tell me which of those topic branches have been merged?
<bob2> that wasn't supported according to the release announcement
<lifeless> k, time to call it a week.
<lifeless> shee you folk tuesday; except for poolie of course :)
<bob2> don't od on eggs
<Odd_Bloke> bob2: Right, but I can't work out what _was_ supported.
<lifeless> bob2: *blink*
<Odd_Bloke> lifeless: Happy Easter!
<bob2> Odd_Bloke: ~/repository/bazaar/bzr/{trunk,fix-bug-41921921,make-foo-baz}, afaict
<poolie> hello bob, odd
<Odd_Bloke> bob2: Right, so I have a symlink from trunk to bzr.dev now, but am still getting odd errors.
<bob2> Odd_Bloke: ah, sorry, I imagined a comma (with 'bzr.dev', and my topic branches under it)
<abentley> lifeless: Okay, I've merged in the up-thread stuff.  Shall I do export-loom (with no default) too?
<lifeless> abentley: yes please; please be sure to do a merge into the trunk, or use a bound branch - I'd like the mainline to be like bzr's with only the result of feature branches, now that loom is released
<poolie> gack
<abentley> lifeless: Sure, I understand.
<abentley> To be safe, you should set append_revisions_only
<lifeless> how do I do that
<lifeless> is there an api call?
<lifeless> also, append_revisions_only doesn't enforce all that I want ;)
<poolie> bug 202778 killed my 1.3 merge
<ubotu> Launchpad bug 202778 in bzr "false test failure when run in a directory containing the version name" [High,Confirmed] https://launchpad.net/bugs/202778
<poolie> oh well
<abentley> lifeless: Branch.set_append_revisions_only
<lifeless> it only prevents pivots; it doesn't prevent push as opposed to merge + commit
<abentley> Oh.  Perhaps that's another flag we should support.
<abentley> Branch.set_commit_only_merges ?
<lifeless> abentley: something like that would represent want I want yes
<lifeless> abentley: but anyhoo I'm off
 * lifeless waves
<abentley> Happy bunny time.
<peteshinners> Anyone have luck getting the eclipse plugin up? The updates site has no files according to eclipse?
<poolie> i'm going to trivial in http://pastebin.ubuntu.com/5915/
<abentley> r=abentley
<poolie> thanks
<abentley> I think that could give a false success, though.
<poolie> that's true though
<abentley> If there was a file, but the version number was wrong.
<poolie> particularly on the directory name
<poolie> exactly
<poolie> maybe i should check it's in the first line
<poolie> or indeed the exact format of the first line
<poolie> hm
<abentley> Either one sounds good.  I lean towards the second.
<poolie> good point, thanks
<poolie> are you in an unusual timezone or sleep pattern?
<poolie> http://pastebin.ubuntu.com/5916/ instead then
<Odd_Bloke> The comment seems superfluous now.
<poolie> you're right, thanks
<abentley> poolie: sleep pattern.
<Odd_Bloke> jml: I've done some work on the merged-branches plugin that's at https://code.launchpad.net/~daniel-thewatkins/+junk/merged-branches
<Odd_Bloke> It now takes a target branch and a directory (which defaults to '.'), uses a transport and has some better user feedback.
<jml> Odd_Bloke: thanks.
 * jml looks
<Odd_Bloke> jml: I'm writing some tests ATM. :)
<jml> Odd_Bloke: thanks!
<poolie> ok i'm done, good nightall
<poolie> jml, 1.3 is out
<jml> poolie: thanks-
<poolie> jml, the tarball is up but the merge has not completed yet
<poolie> :/
<jml> poolie: no worries
<jml> poolie: I'll probably submit it tomorrow anyway
<Odd_Bloke> poolie: Congrats! :)
<poolie> oh one more thing
<jml> yes?
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.3 is out 20 Mar | http://launchpad.net/bzr/1.3/1.3
<poolie> that.
<poolie> cheers
<jml> heh heh
<poolie> actually i'm going to visit Oksh briefly
<poolie> see you
<Odd_Bloke> jml: Some rudimentary tests have been pushed.
 * awilkins yawns
<awilkins> Dammit, 0400 hackathons do not suit me in my old age
<ubotu> New bug: #204211 in bzr-svn (universe) "Displays a version warning on every operation" [Undecided,New] https://launchpad.net/bugs/204211
<nekohayo> mmmh, is there a way to use bzr-svn without the breakalot rich-root-format? or convert rich-root into pack-92 or something?
<dato> nekohayo: no, bzr-svn needs rich-root. what's your problem with it?
<nekohayo> well, the fact that it seems to break :) https://bugs.launchpad.net/bzr/+bug/177874
<ubotu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed]
<nekohayo> so I was wondering if there was a way around it
<nekohayo> more precisely I am the one who reported https://bugs.launchpad.net/bzr/+bug/202884
<ubotu> Launchpad bug 202884 in bzr "can't merge (dup-of: 177874)" [Undecided,New]
<ubotu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Medium,Confirmed]
<abentley> nekohayo: There are some problems with upgrading to it.  I'm not aware of any problems for branches that are already in it.
<nekohayo> abentley: well merging dirstate into rich-root fails
<Qhestion> why is the description of a command in the output of "bzr help" indented to column 19 (starting with 1)?? shouldnt that be 20 ??
<Qhestion> http://en.wikipedia.org/wiki/Off-by-one_error ??
<abentley> nekohayo: Are you talking about the general case, or about the Bazaar source tree?
<nekohayo> what do you mean?
<abentley> The Bazaar source tree has some weirdness in it that is going to require extra care to upgrade.
<abentley> The bug you referenced is an upgrade of the source tree to Bazaar itself.
<abentley> Now you're talking about merge of dirstate failing.
<abentley> But I don't know if you're talking about the Bazaar source base in particular, or some other source base.
<nekohayo> abentley: yeah, my bug is #202884, but it was marked a duplicate
<abentley> nekohayo: Is this a really old branch?
<nekohayo> abentley: the one in rich-root is a freshly made one from svn, and the other one is dating back from the summer I think
<abentley> So the revision in the example is from 2007-05-17.  At that time, we supported unique root ids in our development version, for a while.  I don't believe it was in any released version.
<nekohayo> abentley: that is what makes things break?
<nekohayo> any way to have bzr convert that?
<abentley> That's what's been diagnosed so far.
<abentley> I haven't looked at your particular branch.
<abentley> Though I was going to.
<abentley> To answer your original question, rich-root is mandatory for bzr-svn.  It was created especially for bzr-svn.
<nekohayo> aah, that explains. the fact that there are multiple formats kind of puzzled me
<abentley> nekohayo: I have inspected your branch, and it does have a unique id for the tree root.  So it's the same *root* cause :-)
<nekohayo> what is that unique id thing?
<nekohayo> isn't an "ID" unique by definition ?_?
<abentley> In pre-2007 trees, the root directory always has an ID of "TREE_ROOT"
<abentley> Trees created in the rich-root format always have unique IDs.
<abentley> We're working on making a rich-root format the default.  It will be a slight tweak of rich-root-pack.
<nekohayo> abentley: so can this be converted or salvaged without using the method "create a giant patch and lose history"?
<abentley> We haven't yet got a solid patch that fixes it.  You might be able to re-generate the history using rebase.
<abentley> This would preserve metadata such as your comments, but would generate new revision-ids.
<nekohayo> oh, but once such a patch comes in bzr, it should heal itself ?
<abentley> Yes, we'll support that conversion one way or another.
<ubotu> New bug: #125751 in bzr-svn "Push raises exception about invalid property changes" [Medium,Fix released] https://launchpad.net/bugs/125751
<lnxtech> Which repository format has the best performance (or will be the new standard in future releases)? I will be the only developer using the repo so I'm not concerned about backwards compatibility.
<dato> lnxtech: the current default, pack-0.92
<lnxtech> thanks
<stammi> hi
<statik> poolie: i don't see any ops in this channel, i suspect announcer is still banned. i've fixed it now, know what I should do to get the ban lifted?
 * jdong taps jelmer's shoulder...
<jdong> bzr co on bzr-svn doesn't exactly create a "bound branch" , does it?
<ubotu> New bug: #204320 in bzr ""bzr patch" internal error" [Undecided,New] https://launchpad.net/bugs/204320
<jdong> I tried a bzr co svn+file:///some/svn/repo on system foo, then on bar I did bzr co sftp://foo/bzr/checkout
<jdong> then when on bar I tried to ci, I got some sort of svn assertion error
<jdong> then I checked bzr info and apparently everything was some sort of svn format, not standard rich-root-pack bzr branches
<abentley> staik: The ops don't usually fly their flag.  Hmm, how do I get ops again?
<dato> /msg ChanServ op #bzr abentley
<dato> I think
<jam> abentley: well /op user is used to give ops to 'user', but I think you have to be op first :)
<abentley> Anyone know the syntax for listing/altering bans?
<abentley> help /op
<jam> abentley: looking at plain help, I only see /kick, and no /ban
<abentley> I think it's a mode you set on a wildcard.
<jam> abentley: then '/help mode'
<abentley> something like /mode +b *announcer*
<jam> So /mode -b nick
<jam> something like that
<Parker-> /mode -b *!*announce@*
<stammi> is there any chance to check out a svn repository with bzr via https?
<stammi> it seems to fail, while svn works
<stammi> i tried  bzr svn-import https://subversion..... as well as bzr co
<stammi> it responds with 401 Auth required
<james_w> stammi: try svn+https://...
<abentley> statik: How you like it now?
<Parker-> /mode -b *!announce@165.198.204.68.cfl.res.rr.com
<Parker-> ;)
<stammi> it says "No Repository found at ... use bzr branch" if i do so there comes a legthy error which essentially says SubversionException: ("Undefined tunnel scheme 'https'"
<Parker-> abentley, after that there is no bans
<statik> abentley: thank you, we should see it work when the next PQM commit mail comes through
<dato> statik: shouldn't it join the channel first?
<dato> or will it auto-join by then?
<statik> dato: it is supposed to auto-join when it has something to announce
<dato> ok
<abentley> statik: Okay, holler if it doesn't work.
 * stammi just recently noticesd to be out of vcs for the next two weeks
<statik> but, I don't really have a good way to see the response from the IRC server to the IRC-talking part of the bot, I'm just re-using radix's publish-bot
<statik> abentley: thanks for the help
<j^> hi, is it possible to import tags from svn?
<jelmer> j^: yes, but only as branches not as bzr tags yet
<jelmer> stammi: Looks like your subversion library wasn't built with http support
<jelmer> jdong: still there?
<jdong> jelmer: yeppers
<jelmer> jdong: you can't make a checkout of a checkout in bzr
<j^> jelmer, i was hoping for bzr tags, getting the revision numbers and creating the tags should not be to hard
<jdong> jelmer: oh.
<jelmer> (which if I understand correctly, is what you're trying to do)
<jdong> jelmer: I didn't know that :) well that explains a lot
<stammi> jelmer, have ubuntu 7.10 and installed bzr-svn
<stammi> and its https not http
<jelmer> stammi: the svn+https:// / svn+http:// syntax was broken in bzr-svn 0.4.1, which is what is in gutsy
<stammi> jelmer, so i should just manually install bzr from the homepage?
<j^> there is a newer version in guty-backports
<stammi> ahh ok
<stammi> thx jelmer
<jelmer> j^: it's not trivial since tags may be in different locations across svn repositories
<j^> true, is there a way to map svn revision to the one used in bzr, that way one could collect the revision numbers and run a script to apply the tags, right now i would have to look up the commit message, find the one in bzr and map the revision that way
<jelmer> j^: just taking the revision in which the tag was created in svn won't help
<jelmer> since that will be a revision that's not actually in your bzr branch
<jelmer> you would have to take the revision from which the tag was created
<jelmer> but that's not going to be correct in a lot of cases either, since the revision that created the tag could also have slightly modified it
<j^> what could cause
<j^> SubversionException: ("PROPFIND request failed on '/!svn/bc/12853/trunk/foobar'", 175007)
<jelmer> does "svn log -r12853 <repos-url>" work?
<j^> ------------------------------------------------------------------------
<j^> is all i get
<jelmer> j^: is this a public branch?
<j^> at that revision there is nothing in svn log, its one before the trunk was moved from a branch
<j^> https://svn.xiph.org/trunk/theora
<jam> statik: you should have a new pqm email
<jam> I just had a patch merged
<statik> jam: cool, i hope we see an announcement in a couple of minutes
<grutte_pier> Does anyone know what happened to the webserve plug-in?
<james_w> grutte_pier: it's still going
<grutte_pier> So which url should i branch from then? on the webpage there is a 'download' link and an 'URL to branch' link
<grutte_pier> the former gets me an 500-error (Internal Error)
<grutte_pier> the latter gets me the source-code of some webpage
<james_w> https://code.launchpad.net/~bzr/bzr-webserve/webserve-dev
<grutte_pier> thanks a lot! Is there a way that I could or should have found this link myself?
<james_w> grutte_pier: I'm not sure, maybe we should contact the author to update his webpage.
<james_w> Note that launchpad is just mirroring his branch, so I imagine that he has reorganised things at some point and not updated the webpage.
<grutte_pier> sounds like something that could easily happen.....
<blueyed> What's the reason that e.g. "bzr status" does not list the files relative to the current working directory, but to the branch root?
<blueyed> It's not as easy to select filenames for further actions then, e.g. by doubleclicking them.
<LeoNerd> Because there might be more files modified than just within cwd
<LeoNerd> So how do you display those?
<blueyed> LeoNerd: well, good point for commands on the branch, but with e.g. "bzr st ." there's a path given..
<blueyed> otherwise they could get prepended with "../" anyway.
<yacc> What's the recommened way to push a local bzr branch to a fresh (not yet existing) SVN url?
<ubotu> New bug: #204370 in bzr "bzr bombs during push to svn" [Undecided,New] https://launchpad.net/bugs/204370
<yacc> nice ubotu detected my bug report ;)
<fbond> Hi, using bzr-svn I get "CHECKOUT of ...: authorization failed" when trying to push to the repository...
<fbond> bzr-svn 0.4.7
<fbond> bzr 1.2.0
<fbond> What do I need to do?
<fbond> svn has my credentials cached already.
<fbond> I'm pushing over http
<yacc> ahhh, the newest version of bzr-svn works for bzr 1.1 *weep*
<fbond> yacc: but not for 1.2.0?
<yacc> Well, the wiki page shows only versions for up to 1.1 ;(
<yacc> Please anybody tell me that there is svn support for current bzr versions?
<nekohayo> hm, is there people working primarily on bzr-gtk?
<ubotu> New bug: #151825 in bzr-gtk "jumping progressbars" [Undecided,New] https://launchpad.net/bugs/151825
<ubotu> New bug: #125144 in bzr-gtk "Crashes when directory contains broken symlink" [Undecided,Confirmed] https://launchpad.net/bugs/125144
<jelmer> nekohayo: yeah
<nekohayo> ok, so I assume my pile of bugs (a few of them with patches) were not seen
<nekohayo> so I'm changing them all to be assigned to bzr-gtk
<yacc> fbond: ok, the branch seems to be maintained :) => but the current head seems to work only with bzr >= 1.3 ;)
<yacc> It still bombs :(
<awmcclain> Is it possible to import a single file into my repo?
<awmcclain> Or do I have to import the containing directory like SVN?
<yacc> awmcclain: any repo is a directory so logically speaking your question does not make much sense ;)
<awmcclain> yacc: s/repo/branch
<awmcclain> :P
<yacc> Yeah, still your question makes no sense ;)
<awmcclain> Is it possible to commit a single file which does not live under an existing branch into a branch. I'm pretty sure the answer is no.
<awmcclain> Hrm. Can you check out or branch a subset of a working tree?
<dato> those are two different questions?
<awmcclain> yes
<dato> ok
<dato> (b) you can't do partial checkouts
<awmcclain> hrm
<awmcclain> Okee doke.
<dato> (a) I'm failing to see your question, how's what you ask different to `bzr add $FILE` ?
<awmcclain> dato: Becauase I'm guess bzr add $FILE will only work if the containing directory is in a working tree
<awmcclain> I'm trying to collect a bunch of conf files scattered about into source control
<dato> well
<dato> the file has to be underneath the branch, of course
<awmcclain> I'll just put them in a directory and then move from there
<yacc> bzr: ERROR: Revision {('andreas@andi-lap-20080318110425-b4uvstmj62j90z2s',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb6c6a30c>".
<yacc> on upgrade --rich-root-pack
<Peng> yacc: Known issue.
<yacc> Yeah, but what do I do, considering that I should deliver my stuff today?
<yacc> Trying to do a svn-push I'm getting an error too :(
<Peng> yacc: I don't know of a solution.
<yacc> Well, I can try to revert to bzr 1.1, and see if that helps, ...
<Peng> I dunno.
<kiko> abentley, ping?
<abentley> kiko: pong
<kiko> abentley, do you have any advice for yacc's problem above?
<abentley> At this point, we don't have a fix for that.
<kiko> abentley, what's the source of the problem?
<yacc> abentley: basically bzr svn-push craps out with the "SubversionException: ('At least one property change failed; repository is unchanged', 175008)" problem ;(
 * yacc had such high hopes to have escaped svk, ...
<abentley> Wait, which is your bug?  SubversionException or Revision not present?
<yacc> abentley: SubversionException. README in bzr-svn (I think, might been google) suggested that an upgrade --rich-root-pack might be useful, ...
<abentley> Which version of bzr-svn have you been using?
<yacc> head of stable with bzr 1.3
<yacc> Now I'm downgrading to bzr 1.1rc1 in Debian, that include bzr-svn 0.4.7 I think.
<yacc> Well, bzr1.1 gives me the "at least one property changed" traceback too :(
<abentley> bzr plugins should tell you the version number
<yacc> 0.4.7
<yacc> and bzr 1.1
<yacc> Same error as it was with bzr 1.3/stable-head
<abentley> So "stable-head" doesn't help me understand what's going on.
<abentley> There was a major change at 0.4, and if you're using something earlier, the scenario is completely different.
<yacc> stable head == an hour old pull from the branchurl on the plugins wiki page.
<yacc> No it's the newest one.
<dato> yacc: trunk, or the bzr-0.4 branch?
<yacc> http://people.samba.org/bzr/jelmer/bzr-svn/stable/
<abentley> Okay, so if you do bzr info -v in your branch, what does it say about formats?
<yacc> dato: no idea which branch is stored at that url.
<yacc> you mean the one that I try to push to svn?
<abentley> yacc: yes
<yacc>        control: Meta directory format 1
<yacc>   working tree: Working tree format 4
<yacc>         branch: Branch format 6
<yacc>     repository: Packs containing knits without subtree support
<abentley> So is this a branch that you originated in Bazaar?
<yacc> Yes, it orginated from a bzr init (with bzr 1.1rc1)
<yacc> I wonder if it would help to push an empty bzr branch first to the SVN url, ...
<yacc> any ideas how to get the stuff into svn?
<abentley> Could you run this and tell me what the output is?
<abentley> python -c 'from bzrlib.workingtree import WorkingTree; wt=WorkingTree.open("."); wt.lock_read(); print wt.inventory.root.file_id; wt.unlock()'
<abentley> You need to run it in your working tree.
<yacc> TREE_ROOT
<abentley> Well, that's normal.  I don't know why upgrade would be a problem.
<abentley> I don't think you'll be able to push into svn until you change your format.
<yacc> Well, it complains that a version does not exist where it expects it. but technically speaking the upgrade is less of an issue for me, bzr-svn is :(
<yacc> To which format?
<abentley> I would recomment rich-root-pack.
<yacc> Well, rich-root-pack and rich-root both complain about non-existing versions, and it seems to be a known bug :(
<dato> abentley: fwiw pushing from !rich-root to svn works just fine. I use it in one of my projects.
<abentley> dato: Ah, okay.  It's been a while since I used bzr-svn.
<yacc> Any hints that I can try?
<abentley> We probably need Jelmer to debug the SubversionException.
<abentley> jelmer: ping
<abentley> It sounds like the upgrade's not necessary, and we're planning to fix it for branches like yours.
<yacc> Which timezone jelmer is in?
<dato> CET
<james_w> UTC+1 I think.
<james_w> hi dato
<abentley> yacc: One thing you could try is running "reconcile".
<yacc> reconcile?
<abentley> ie "bzr reconcile".
<dato> hi james_w. I meant to ask you the other day, were you in dc7?
<james_w> dato: nope.
<yacc> abentley: what does reconcile do?
<dato> ok. then no regrets I didn't meet you :-P
<yacc> abentley: same SubversionError :(
<james_w> dato: :-)
<james_w> dato: are you going to dc8?
<abentley> yacc: Running reconcile in your repository gives you a SubversionError?
<yacc> no, but doing a svn+push after the reconcile.
<yacc> the reconcile did fine.
<abentley> bzr reconcile corrects some kinds of data inconsistency.
<yacc> Whatever it did.
<dato> james_w: it's going to be a bit complicated, but so has been the previous 3 times and I always managed. but maybe I'm overconfident this time. :-)
<abentley> Does the upgrade work?
<yacc> abentley: but the upgrade to rich root pack did work :)
<yacc> The question is if that will help the svn+push or not.
<yacc> Nope, same thing as before.
<abentley> I don't know enough about bzr-svn to understand that error.
<abentley> I'm glad the upgrade worked, but you may want to go back.
<abentley> It depends on whether you're expecting to pull/merge from bzr-svn.
<yacc> Well, for the moment I'm the only one that will be commiting around that svn path ;)
<yacc> I might try it out if pushing to my private svn repo works.
<abentley> Probably you should stick with it.
<abentley> Existing projects shouldn't convert to rich-root-pack unless all their members are willing to upgrade.
<abentley> But yours is a new project, so it doesn't matter.
<yacc> abentley: basically, I'm having a high level of aversion against svn, svk and git-svn, that doesn't leave many options when you need to work with a svn repo ;(
<yacc> abentley: mine is a project where nobody but me will see the bzr branch, because all other will be pulling it from svn.
<abentley> What's the command you're running?  push or svn-push?
<yacc> svn-push
<yacc> push gives an IndexError.
<yacc> Googling the error returns basically only the bzr-svn problems and one old svn error which was fixed back then by upgrading the svn client version, ...
<abentley> yacc: Do the permissions on your SVN repo forbid changing revision properties?
<yacc> abentley: as this is a public svn repo server, I have no idea.
<yacc> abentley: but that's an interesting theory.
<abentley> I know it's a configurable option.
<yacc> abentley: It will most probably forbid changing revprop.
<dato> both for SVN and bzr-svn
<dato> i.e. bzr-svn does not do it by default
<yacc> abentley: Actually it's a hook that decides which properties you are allowed to change.
<yacc> dato: What?
<dato> my understanding is that bzr-svn uses properties in a way that is allowed by default in SVN repositories
<dato> and then it has a switch to override svn:date and svn:author, but I don't know if this was abentley meant or not
<yacc> dato: which switches.
<dato> or maybe your repo is forbiding even the kind of safe properties bzr-svn needs, though it sounds unlikely
<yacc> svn:date won't be overrideable in that repo for sure.
<dato> % grep override ~/.bazaar/bazaar.conf
<dato> override-svn-revprops = True
<yacc> dato: I have no bazaar.conf ;)
<dato> k
<abentley> yacc: You are allowed to create one :-)
<yacc> abentley: yeah, but where do I learn about the options/sections (assuming that it's a ConfigParser thing)
<abentley> It's ini format.  There are no mandatory sections.
<abentley> bzr help configuration will tell you about Bazaar's options, but not bzr-svn's.
<yacc> Yeah, but where does that override-svn--revprops belong to?
<dato> I have in [DEFAULT]
<abentley> But DEFAULT is optional.
<yacc> Now, it would be highly interesting what the default for it is.
<dato> aha
<dato> I'm sure it defaults to False
<abentley> You can just have a single-line file with "override-svn-revprops = True"
<yacc> Well, technically it defaults to None, but yes that's false too *g*
<yacc> Ok, the SubversionError is raised in something that looks like a decorator that catches SVN exceptions.
<yacc> How does one set the debug.debug_flags in bzr?
<abentley> With -Dfoo
<abentley> where foo is the flag you want to set.
<yacc> So let's see what bzr-svn is doing before it the bad thing happens :)
<yacc> abentley: see you are bad. You made me start debugging myself,
<yacc> ;)
<abentley> You could also try doing import pdb; pdb.set_trace() in the final else clause of convert_error
<yacc> Well, it's one of these then:
<yacc> setting revision property 'bzr:file-ids' to '\tTREE_ROOT\n.bzrignore\tbzrignore-20080314001943-npoqulq31axmxa8g-1\nez_setup.py\tez_setup.py-20080314002020-4ktxnl1abormwysn-1\nsetup.py\tsetup.py-20080314002020-4ktxnl1abormwysn-2\nlookery\tlookery-20080314002159-q2mdytaryo7wbdcf-1\nlookery/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-1\nlookery/lib\tlib-20080314002211-5qqxrkuk0wqqoyvi-2\nlookery/lib/apachelog.py\tapachelog.py-200803140022
<yacc> 11-5qqxrkuk0wqqoyvi-4\nlookery/lib/__init__.py\t__init__.py-20080314002211-5qqxrkuk0wqqoyvi-3\nlookery/scripts\tscripts-20080314011426-ok2xe2a2a4am6oot-1\nlookery/scripts/llfp.py\tllfp.py-20080314011426-ok2xe2a2a4am6oot-3\nlookery/scripts/__init__.py\t__init__.py-20080314011426-ok2xe2a2a4am6oot-2\n'
<yacc> setting revision property 'bzr:revision-info' to 'timestamp: 2008-03-14 02:15:10.638999939 +0100\ncommitter: Andreas Kostyrka <andreas@andi-lap>\nproperties: \n\tbranch-nick: lookery\n'
<yacc> setting revision property 'bzr:revision-id:v3-single-trunk/logs/Lookery-Base' to '1 andreas@andi-lap-20080314011510-z091afzyx1t7i3gq\n'
<yacc> abentley: I'm not big on pdb style debugging. Lucky for me bzr-svn is not in an egg, so adding prints is not exactly hard.
<abentley> Acutally, it would be better if convert_error just did "raise" when it couldn't convert.
<abentley> That would give a more useful traceback.
<rindolf> Hi all.
<rindolf> I'm trying to do {{{ bzr export http://www.gnome.org/~jdub/bzr/planet/2.0/ }}} but it tells me "not a branch".
<rindolf> What's the equivalent of svn export URL in bzr?
<abentley> rindolf: I don't know svn.  In bazaar, it creates a copy of the working tree files, optionally gzipped, tarred, zipped, etc.
<dato> abentley: but does it work over remote?
<dato> oh, you'd need to give it a second arg
<rindolf> dato: thanks.
<james_w> rindolf: bzr export target http://www.gnome.org/~jdub/bzr/planet/2.0/
<dato> rindolf: personally I'd recommend you just clone instead of export, for easy updating
<rindolf> james_w: thanks.
<dato> rindolf: but your choice :)
<rindolf> OK, it's making slow progress.
<rindolf> dato: problem is that at the moment, my Internet connectivity sucks.
<yacc> Now I wonder if there is a doc on the SVN API somewhere ;)
<rindolf> blame my ISP.
<james_w> yacc: I have found API docs
<abentley> rindolf: Also, it's in an older, less-efficient format.
<james_w> I found them to be under-documented, but at least better than un-documented
<yacc> james_w: me too ;)
<rindolf> abentley: what is?
<abentley> http://www.gnome.org/~jdub/bzr/planet/2.0/ is in a slower format.
<yacc> That's cool, http://svn.collab.net/svn-doxygen/search.php?query=change_dir_prop gives me the HTML source including PHP ;)
<yacc> Well, at least there is google ;)
<abentley> http://svn.collab.net/svn-doxygen/structsvn__delta__editor__t.html#o11
<awmcclain> Is 1.2 in gutsy yet?
<abentley> awmcclain: No idea, but packages.ubuntu.com should know.  Or you can use our gutsy APT repository.
<awmcclain> abentley: Yeah, it's only at 0.9. Thanks!
<abentley> awmcclain: If you mean *our* repository is at 0.9, that is unlikely.  0.9 was released in 2006
<awmcclain> No no gutsy. I'm using 1.2 from your repository now.
<abentley> Gutsy includes 0.90, not 0.9
<abentley> gutsy-backports has 1.0
<jdong> I will update backports to bzr 1.3 if Hardy is going to get it plus bzr-svn and friends.
 * abentley is completely disconnected from the Ubuntu release cycle.
<jdong> who typically takes care of Ubuntu packaging for bzr?
<dato> jdong: package just migrates from debian
<dato> (fwiw I'll upload 1.3 to debian tomorrow; rc1 is in atm)
<james_w> jdong: I can't remember who did the last sync, someone just pinged me on IRC one day to confirm that they had all the necessary bits together.
<james_w> I wasn't going to FFe for 1.3 in Hardy. I've just submitted a patch to get bzr-svn to stop complaining about version mismatch.
<jdong> james_w / dato: Ok, I'll take some time later tonight to look into this; I'd like to ensure we freeze Hardy with the latest bzr release in there.
<dato> james_w: are the syncs manual at this point?
<jdong> dato: have been for a long time
<james_w> dato: yes, and they have been for a while.
<james_w> dato: thanks to your work it's just a quick test and a manual sync though.
<jdong> james_w: unless bzr devs have any objection/hesitation, I'd have no problem FFe'ing bzr. I don't think any of the folks will complain
<jdong> everyone in Ubuntu-land loves bzr anyway :)
<james_w> *almost* everyone :-)
<dato> *g*
<james_w> jdong: I don't think anyone will mind. I was just wary as it will be post-beta.
<james_w> jdong: but I haven't got a feel for the Ubuntu release cycle yet, so that may be quite common.
<jdong> james_w: normally I would be too, but you guys have such a solid track record
<james_w> jdong: that's true. And there will probably be a boat load of fixes in there.
<jdong> james_w: indeed
<james_w> well the 1.3 NEWS is a little smaller than usual due to all the sprints/conferences etc. this month.
<jdong> james_w: I'd rather not have a LTS kick off with outdated bzr :)
<james_w> jdong: yeah, let's go for it. Anything you would like me to do?
<jdong> well I think I'll have time later tonight to research the bits; just poke me when the Debian package is uploaded :)
<james_w> jdong: sure. Though I will be online for limited periods this weekend.
<jdong> ok
<james_w> dato: would you mind poking jdong when you upload 1.3?
<dato> sure
<james_w> The only other thing I haven't seen an upload for is bzr-gtk, is there a new release available?
<james_w> dato: great, thanks.
<james_w> jdong: you'll need bzr-svn as well I think, and I'd like it if you took bzr-builddeb as well.
<dato> and bzrtools
<james_w> oh, of course.
#bzr 2008-03-21
<jdong> james_w: yeah, certainly the tricky part will be coordinating all plugins to be compatible with bzr 1.3 and I will have to look into that the most.
<james_w> well bzrtools and bzr-builddeb have just had releases, so should be fine.
<james_w> bzr-svn just had an upload that jelmer acked as being compatible, so it's only bzr-gtk that I am unsure about.
<thekorn> hi, I try to integrate bzr in some of my scripts, is there an easy way to find out wheather a file/dir is in a bzr-branch or not?
<thekorn> and return the related branch object?
<nekohayo> hmm, any reason why bzr-gtk in ubuntu hardy only seems to provide olive, no nautilus integration?
<james_w> thekorn: 'from bzrlib import branch; b = branch.Branch.open(dir)' Does that do what you want?
<james_w> thekorn: something like "errors.NotBranchError" is thrown if it's not a branch.
<james_w> there's also open_containing if you may be given a path below a branch, this returns a tuple (branch, relpath).
<james_w> thekorn: or do you have a branch and want to know if the given path is versioned in that branch?
<yacc> abentley: still there? It seems to be dependant on the svn repo too, a push to a local file:// url worked fine.
<abentley> yacc: kinda here.
<thekorn> james_w, yes, lets say I'm somewhere, and I want to now if this location is in a branch, and if so, get the branch root
<abentley> I would expect it even works with more permissive SVN repos.
<yacc> abentley: well, I'll be checking that now, gonna switch back first to bzr 1.3/bzr-svn stable for the experimenting.
<abentley> thekorn: The branch root is Branch.base
<james_w> thekorn: so you don't care what branch it's in, just that it is in one?
<thekorn> james_w, I would like to have a similar behaviour than 'bzr info' - if i call this somewhere in a branch i get the branch root, if I call this command outside a branch I get "Not a branch Error ...."
<james_w> thekorn: do branch.Branch.open_containing(path)[0] then
<james_w> that gets you the branch, if any, that contains path. You can then get the base.
<james_w> If you want you can catch the NotBranchError.
<james_w> do you also want to ensure that the path you were given is versioned by the branch that you get returned?
<thekorn> james_w, abentley , thanks alot this works
<thekorn> no i only need the branch root
<james_w> thekorn: cool, you should be all set then.
<james_w> thekorn: how are you finding it transitioning to use the API?
<thekorn> james_w, well I just started using bzrlib,
<thekorn> to be honest: it's hard without a real public API reference
<thekorn> but ipython does a good job
<james_w> yeah, that's understandable.
<james_w> #bzr is the API reference that I tend to reach for.
<yacc> Ahhhh, how do I make bzr not check SSL certificates?
<james_w> yacc: use urllib+ as a prefix for the URL.
<james_w> yacc: although is this connecting to svn?
<thekorn> james_w, http://bazaar-vcs.org/Integrating_with_Bazaar is a good starting point to understand the general workflow, but needs some improvements
<yacc> Oh, don't you curl is the solution :)
<yacc> james_w: yeah, but I guess bzr checks the url first for a bzr target?
<james_w> thekorn: yeah, I think it's quite new. It would be great to improve it.
<james_w> yacc: yes I think so.
<james_w> yacc: if you prefix the URL with svn+ then bzr doesn't probe it first.
<thekorn> for example the last part is switsching between 'branch' as a modul and 'branch' as a Branch-object
<james_w> ah, that should be avoided.
<yacc> Ok, it fails with my private https host too :(
<james_w> thekorn: thanks, fixed.
<yacc> james_w: what's the prefix for svn over ssh?
<thekorn> james_w, thanks, but same in "Getting a Revision object from a revision id"
<james_w> yacc: svn+ssh:// I think
<yacc> james_w: found it already ;)
<yacc> abentley: svn+ssh:// does work against the same host where https:// does not work :(
<james_w> thekorn: thanks again.
<abentley> yacc: so you've actually got a solution, then?
<yacc> No.
<yacc> The svn repo I need to push to is hosted by a provider, so no ssh access ;(
<yacc> But it might help figuring out why it does not work.
<abentley> "the same host" as what?
<yacc> abentley: I've tried it against a repo hosted on my private colo server, and it fails as usual against the https url, but works fine when doing the access over ssh.
<yacc> Which suggests all kind of interesting things.
<abentley> Seems quite strange.  Maybe the security settings are different on ssh?
<yacc> abentley: probably not. I have fine grained access controls on https, OTOH, svn+ssh has no access controls at all.
<yacc> abentley: well, unix permissions, but if you don't have full write access to the whole repo, well, then usually even read-only operations break against that repo.
<jelmer> abentley: pong
<jelmer> yacc: hi
<abentley> jelmer: yacc is running into some problems with bzr-svn and properties.
<yacc> jelmer: I'm trying to track down the svn push problem.
<yacc> I'm just pasting the apache logs from my server for the failing svn-push
<yacc> jelmer: #190568
<yacc> The funny thing is that it's depending upon the transport layer.
<yacc> Pushing to exactly the same repository via svn+ssh works fine.
<yacc> Pushing via https breaks.
<jelmer> bug 190568
<ubotu> Launchpad bug 190568 in bzr-svn "bzr-svn exception plugin error in commit" [Undecided,Incomplete] https://launchpad.net/bugs/190568
<jelmer> yacc: interesting
<jelmer> yacc: do you have wireshark handy?
<yacc> ethereal?
<yacc> but it's https.
<jelmer> ah, ouch
<yacc> I can install the repo on http too.
<yacc> No sure, you are in the same timezone, how fresh are you.
<yacc> btw, I've done the last tests with 1.3rc1 + tip of bzr-svn stable
<yacc> but bzr 1.1rc1 + bzr-svn 0.4.7 has basically shown exactly the same behaviour through the day.
<asabil> yacc: on windows ?
<asabil> if so, you could use oSpy (and API level sniffer) to sniff https traffic
<jelmer> yacc: please update your bzr-svn checkout
<jelmer> yacc: and add -Dcommit during push
<yacc> It's 2 hours or so old.
<yacc> I've already done the -Dcommit.
<yacc> It just produces the files + 3 properties.
<yacc> jelmer: email address?
<jelmer> yacc: I just added the -Dcommit bit 5 seconds ago :-)
<yacc> Well, def mutter checked for commit already in the old code?
<jelmer> yeah, but I just added some extra output for it
<yacc> Ok, pulling the stuff.
<yacc> I've changed the repo to http, so I can also run ethereal. :)
<yacc> asabil: Technically, I've written an API level sniffer for Linux myself, but I don't like to use it, as I've written it for a customer so I cannot really distribute it, nor should I officially use it ;)
<asabil> oh oki
<yacc> asabil: well, at least the code generator for the intercepting stubs was written in Python ;)
<yacc> jelmer: paste is ok for you?
<jelmer> yacc: yeah
<yacc> http://rafb.net/p/Yy0yfm50.html
<yacc> asabil: and guess what, the main usage was intercepting OpenSSL calls ;)
<yacc> SSL can make debugging webstuff quite a PITA.
<jelmer> yacc: Ah, think I figured it out
<yacc> jelmer: really? :))))))
<jelmer> / is invalid in a file property
<yacc> property name?
<jelmer> yeah
<jelmer> bzr-svn is using it
<yacc> Why did it work via svn+ssh then?
<yacc> *wonder*
<jelmer> subversion doesn't do validation
<yacc> Oh, apache does ;)
<yacc> probably because the name gets embedded somewhere in the URL ;)
<yacc> And one / to much can break stuff.
<jelmer> but a / in a xml tag name messes with the subversion apache module
<yacc> Anyway, any chance for a quick fix?
<yacc> Just throwing a .encode("base64") would solve it in a completely incompatible way I guess ;(
<jelmer> I'm looking at it
<jelmer> yacc: it's not as simple as that
<jelmer> yacc: that will break older bzr-svn implementations
<yacc> Yeah, I said incompatible.
<yacc> but there is basically no way you can keep it compatible, because you cannot address these properties via http. So that calls probably for an config.ini option?
<jelmer> hmm, actually
<jelmer> this should be fixable without any changes
<yacc> How so?
<yacc> entity encoding in the XML? *wonder*
 * yacc burns to test it out, I have four branches to deliver today ;)
<yacc> jelmer?
<yacc> Just curious what's your solution idea is.
<jelmer> yacc: trying to debug this, give me a few minutes
<yacc> no problem :)
<yacc> Anyway I can help?
<asabil> jelmer: is there any bzr-svn to be used with 1.2 ?
<jelmer> yacc: not really atm
<jelmer> asabil: 0.4.7
<asabil> 0.4.8 you mean ?
<asabil> jelmer: shall I also update the wiki page to add a link to 0.4.8 ?
<jelmer> asabil: 0.4.8 isn't out yet
<jelmer> asabil: I really mean 0.4.7
<asabil> http://samba.org/~jelmer/bzr/bzr-svn-0.4.8.tar.gz ?
<yacc> Despite the fact that the wiki claims it's for 1.1 only?
<jelmer> asabil: Ah, crap
<jelmer> asabil: that should be gone now
<jelmer> asabil: It shouldn't be up there because it doesn't pass a few tests
<jelmer> yacc: yes, 0.4.7 works with 1.2 although it will warn you it may be out of date
<asabil> :/
<jelmer> asabil: you should be able to just use 0.4.7 though
<asabil> jelmer: then the ppa package should be installable
<jelmer> asabil: I haven't had time for that, instead focussing on releasing a bzr-svn compatible with bzr 1.3
<asabil> okidoki
<yacc> jelmer: as you are the source of all bzr-svn knowledge, is it useable for the daily usage as svn replacement?
<yacc> When working against svn repos?
<yacc> I think I've seen even support for svk:merge properties in the code :)
<jelmer> yacc: yeah, I use it for that
<yacc> jelmer :)
<yacc> jelmer: just wondering, on what time zone are you?
<jelmer> yacc: CET
<jelmer> I'll look into this further tomorrow
<rindolf> Hi all.
<rindolf> I'm trying to do bzr export planet http://www.gnome.org/~jdub/bzr/planet/2.0/
<rindolf> But it dies with {{{ bzr: ERROR: Connection error: Couldn't resolve host 'www.gnome.org' (-2, 'Name or service not known') }}} after downloading a few files.
<rindolf> Why does it do another hostname lookup?
<rindolf> And it's very slow.
<nubbun> in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output.  Can someone explain that?  Is that unexpected?
<nubbun> which only has patches approved by the PQM:  bzr.dev or lp:bzr?
<nubbun> i386: in bzr.dev lightweight checkout, I did "bzr --version" and it output "Bazaar (bzr) 1.4dev" then stalled and did much network access and then continued output.  Can someone explain that?  Is that unexpected?
<nubbun> i386: which only has patches approved by the PQM: bzr.dev or lp:bzr?
<i386> huh?
<i386> I dont know
<nubbun> i386: "huh?"  did you not understand the first question?
<i386> dude, I dont know who you were talking to before
<i386> but it was not me
<i386> and I have jack idea about what your saying
<nubbun> I wasn't talking to anyone before.  You're the first person to write anything to this channel since I 've been here.
<i386> right
<i386> I joined the room
<dato> nubbun: PQM is bzr.dev
<i386> And im not necessarily qualified
<nubbun> thanks dato
<i386> Perhaps ask your question of the mailing list?
<nubbun> dato: and lp:bzr is?
<dato> nubbun: and lightweight checkouts are not designed to be useful over network; mostly, to save space locally
<dato> nubbun: a mirror, I guess
<nubbun> I did a lightweight checkout of bzr.dev .   When I do any operation using it, it accesses the network.
<luks> nubbun: dev versions of bzr always print some debugging info about the branch it's from
<nubbun> bzr version          does a lot of network activity.
<luks> and to get that info from a lighweight checkout, it needs to ask the remote branch
<luks> it shouldn't do that much traffic, though
<nubbun> luks: do you know how I shut off network access from the dev branch?  I'm usually offline.
<luks> don't use a lighweight checkout
<luks> or don't use bzr --version :)
<dato> or don't use the .dev branch :)
<nubbun> other operations also do network access, but not so much.  bzr info also does network.
<nubbun> I think   bzr version takes over a minute over dialup
<luks> only if you use a checkout of _your_ branch
<luks> bzr version is the same as bzr --version, which is about the bzr branch
<nubbun> I'm anticipating  bzr branch lp:bzr  will take forever.
<luks> really, if you are mostly offline, don't use checkouts
<nubbun> So I guess I just can't do it.  I'll archive the .bzr directory, remove it and put it back when I wish to update.
<luks> nubbun: the dev branch talks to it's remote branch only on bzr --version
<luks> I guess you don't really need bzr --version for your work, do you?
<nubbun> bzr info also does net access.
<luks> for other comm
<luks> er
<nubbun> but that's expected
<luks> but that's not bzr.dev net access
<nubbun> well not really expected, but not surprizing.
<luks> that's network access for your branch
<nubbun> yes.
<luks> if you use lightweight checkouts, basically all commands will require network access
<luks> (not talking about bzr.dev and bzr --version here)
<nubbun> Thanks for your help, luks, nato!  I'm going for now.
<awilkins> jelmer: Which version of pyrex are you using?
<awilkins> Hmph, obviously not 0.9.3, 0.9.6 works much better
<jelmer> awilkins: probably the most recent one
<awilkins> Yes, the most recent one actually manages to get to the hug elist of compiler errors
<awilkins> strings are immutable in python, so you can't adjust an array of them by doins for thing in array: sthing = sthing + 'stuff' no?
<dato> you can't modify an existing string (value)
<dato> but you can assign to a name a new value
<dato> so sthing = sthing + 'stuff'  is legal
<awilkins> FOudn what I want, enumerate()
<Lo-lan-do> Hi all
<Lo-lan-do> I'm stuck with bzr 1.1~rc1-1...
<ubotu> New bug: #204607 in bzr "crash in 'bzr pull' when the network connection breaks" [Undecided,New] https://launchpad.net/bugs/204607
<Lo-lan-do> (Due to more recent versions being incompatible with bzr-svn)
<dato> Lo-lan-do: guess who you have to prod :-P
<Lo-lan-do> I know, but I figure he's tired of being prodded.
 * yacc wonders if jelmer is a nightowl.
 * grutte_pier has been wondering the same for some time
<clarby> hmm, I'm experiencing some trouble with push, is there any way to increase the level of verbosity?
<luks> ~/.bzr.log might have more info
<clarby> Only thing I'm seeing in the log is "45.348  not updating child fraction", but that's probably not what's causing my problems.
<clarby> It's always like this: I push, have to ssh to my repository, break-lock and then push again and it works.
<clarby> And I'm not getting any feedback that something's awry.
<chadmiller> clarby: Those "-Dxxxx" parameters may be of use.
<chadmiller> clarby: -Dlock -Devil -Dfetch
<chadmiller> clarby: They're all listed in bzrlib/debug.py .
<clarby> Ah, great
<clarby> Thank you chad
<james_w> (and bzr help global-options)
<jelmer> abentley: ping
<mib_v2v62hnc> Unable to load plugin 'multiparent' from 'bzrlib/plugins'
<ashyg> anyone ever see that? the bytecode file is in there
<dato> ashyg: the multiparent plugin was dropped a while ago
<ashyg> then why is it trying to load it/why did it pull it when i rsynces
<ashyg> rsynced
<ashyg> rsync -av --delete bazaar-vcs.org::bazaar-ng/bzr/bzr.dev bzr.dev
<ashyg> ls bzr.dev/bzrlib/plugins shows__init__.py  __init__.pyc  launchpad  multiparent.pyc
<ashyg> running bzr whoami "myname <my@email.com>" results in multiparent error
<ashyg> also can't bzr merge, says unable to load plugin multiparent
<nubbun> If I have a
<nubbun> bzr checkout http://bazaar-vcs.org/bzr/bzr.dev
<nubbun> why can't I do a
<nubbun> bzr pull lp:bzr
<nubbun> I get the error message
<nubbun> bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/"
<nubbun> ashyg: are you specifically trying to use the multiparent plugin?
<ashyg> no
<ashyg> i just rsynced the latest version
<nubbun> do you have that plugin in the plugins directory?
<ashyg> yeah it came when i rsynced
<ashyg> should i rm it
<nubbun> the bzr.dev or 1.3?
<ashyg> i'm seeing usage of it other places though build/lib.linux-i686-2.5/bzrlib/versionedfile.py:        mpvf = multiparent.MultiMemoryVersionedFile()
<ashyg> bzr.dev
<ashyg> i'll try 1.3
<nubbun> ashyg: I think all the plugins have corresponding code in bzr even if they aren't shipped together.
<nubbun> as much as that is not what one would expect.
<ashyg> hey cool 1.3 works
<ashyg> alright thanks
<nubbun> ashyg: are you new to bzr?
<fullermd> The multiparent plugin has been gone for a long time.
<fullermd> (well, FSVO; a couple months, I think)
<nubbun> perhaps someone ( ashyg ) should file a bug?
<ashyg> yes i am new to bzr as of this morning, and yes perhaps a bug should be filed to have that pyc removed
<fullermd> I dunno.  The bug might equally be that we still publish rsync instructions for it (if we do).
<fullermd> It's not standalone anymore.
<ashyg> ah. yes there are rsync instructions on the install wiki page
<fullermd> That's probably historical.  Pull should be faster than rsync (at least, if the tree were still standalone, which is the main case where rsync made sense to begin with)
<nubbun> http://bazaar-vcs.org/Download
<nubbun> has instructions for rsync. Seems to be current use.
<nubbun> fullermd: pull not faster, but checkout --lightweight faster, right?
<nubbun> pull would get history info.
<fullermd> No, pull is faster than rsync on pack trees, because rsync ends up retransferring huge chunks of the history on a regular basis.
<nubbun> I guess it could still be faster if rsync also gets history inf.
<fullermd> bzr.dev used to be a standalone tree precisely SO that rsync would get the history down.
<ashyg> i don't have bzr on my system yet :)
<nubbun> oh, you mean for updates.
<ashyg> so i wget'd the tarball
<fullermd> Urf.  Those rsync instructions SHOULD be dumped.  The WT there is really, really, really old.
<nubbun> fullermd: do you know the answer to my question about pulling for a checkout?
<fullermd> Well, lightweight checkouts via a dumb server conceptually still require significant data transfer.  Less than a full branch, but still a fair hunk.
<nubbun> If I have a
<nubbun> bzr checkout http://bazaar-vcs.org/bzr/bzr.dev
<nubbun> why can't I do a
<nubbun> bzr pull lp:bzr
<nubbun> ?  I get the error message
<nubbun> bzr: ERROR: Not a branch: "/path/bzr.dev/lp:/bzr/"
<fullermd> A smart server can conceptually do it straight, but that cap isn't in place.
<nubbun> I wish to update my checkout from lp:bzr
<luks> because you hit a bug, that has been fixed in 1.3
<fullermd> Well, pulling into a checkout is the wrong answer anyway.  Even if it worked, it would fail.
<luks> but you really don't want pull in a checkout
<luks> just run "bzr update"
<fullermd> Why would you want to pull from the LP mirror in this case anyway?
<nubbun> luks: I just got the checkout of bzr.dev .  Shouldn't it have the bugfix?
<luks> are you running bzr.dev?
<nubbun> yes.
<luks> hm, then yes
<luks> weird
<luks> I though the directory service stuff was added specifically to fix this
<luks> thought
<nubbun> in a checkout of bzr.dev, what _should_ a pull of lp:dev do?
<nubbun> I mean pull of lp:bzr
<dato> you shouldn't be pulling on a checkout
<fullermd> It would try to pull into the bzr.dev branch, which you can't write to, and so blow up.
<dato> but alas, you shouldn't have a checkout over a read-only transport in the first place
<nubbun> can't pull into because there is no working tree?
<fullermd> Oh, there are lots of good reasont to pull on a checkout; just none of them apply in this case   :)
<dato> fullermd: yes
<nubbun> no, there is a working tree, but no history data
<nubbun> Why should one not do a checkout from a readonly transport?
<nubbun> (like https?)
<fullermd> One could.  There's just rarely a particularly compelling case for it; the main use of checkouts implies writing.
<nubbun> I think the compelling case is that when you update, you don't need to re-download all files
 * fullermd blinks.
<fullermd> That's like saying "We need pickles so that you don't die when falling out of an airplane"
<nubbun> There is a relation.  To describe update from ro transport:  read checksums or version identifiers or changesets or whatever.  Compare with local archive to see what needs updating.  Download what changed.
<fullermd> Er.  pull doesn't "re-download" anything (well, nearly); it DOES grab just the updates since your last sync.
<nubbun> yes.  That's what I said.
<fullermd> 'update' != 'pull'
<nubbun> pull affects versioning info & working tree, update only working tree, right?
<fullermd> Roughly, yah.
<nubbun> so a bzr update over http reduces data transfer compared to downloading a new version as an archive via http.  That's the compelling reason to do a checkout over a readonly transport rather than other download via the readonly transport.
<fullermd> In that sense, maybe.  But the usual question isn't "checkout vs. wget", it's "checkout vs. branch".
<fullermd> I'd lay odds the majority of published repos don't have WT's (or have wildly out of date WT's, like bzr.dev) in the first place.
<nubbun> to quote dato: but alas, you shouldn't have a checkout over a read-only transport in the first place
<nubbun> and I don't know why he would say that.
<fullermd> Because there's little point in using a checkout in that case; you'd just use branch.
<nubbun> the branch requires more downloading.
<fullermd> Oh, you're talking about a _lightweight_ checkout?
<nubbun> yes.
<nubbun> sorry
<fullermd> Doing that across the internet over a dumb server is suicide.  You'll probably end up with MORE downloading over the long term.
<nubbun> Why?  Wouldn't it mainly just retransfer changed files?
<fullermd> It has to read a potentially huge amoung of history information to find the changes.
<fullermd> (and even a huge amount, if ere khan tipe)
<nubbun> unfortunate.  Not what I'd expect.
<nubbun> and there's no RO smart server?  None is listed on the download page.
<fullermd> The smart server exists, but I don't know that any of the extant verbs help all that much in the lightweight checkout case.
<fullermd> Where they do, it's probably more fallout than intent; I don't think anybody's bothered trying to add to it for that use-case.
<abentley> nubbun: The smart server is part of bzr and can be run in read-only mode
<nubbun> abentley: will updating a lightweight checkout via smart server reduce data transfer compared to downloading the next tar.gz?
<nubbun> For that matter will updating via HTTP?
<jelmer> abentley: hi
<jelmer> abentley: is there anything blocking Repository.get_revision_graph() from being deprecated in favor of Repository.get_graph() ?
<abentley> nubbun: No one's run any tests on that.
<abentley> jelmer: I don't know.
<abentley> It get_revision_graph doesn't seem to be used in very many places.
<nubbun> If I have a lightweight checkout (say from bzr.dev) and I wish to update from another source, which may be another branch, is rebasing the right and only way to do that?
<fullermd> nubbun: Rebasing has nothing to do with checkouts or working trees.  You want more like 'switch'.
<nubbun> fullermd: thank you.
<abentley> nubbun: lightweight checkouts are intended to be used when you have local (LAN or hard disk) access to the source branch.  Using them over the internet is going to be a world of pain.
<yacc> jelmer: :)
<yacc> jelmer: any hints how you plan to solve the / property problem?
<yacc> Ah, something got commited to bzr-svn :)
<yacc> The suspense is unbearable, ...
<yacc> :( still an assert error :(
<ubotu> New bug: #183824 in bzr-svn "Use only one connection simultaneously to a Subversion repository" [Wishlist,Triaged] https://launchpad.net/bugs/183824
<thekorn> hi all, I try to write sme scripts using bzrlib and i've got one question:
<thekorn> when should I /do i have to lock_read() a tree?
<thekorn> what's the reason behind this locks?
<yacc> jelmer: could you please explain your ideas how to solve the bug in a compatible manner? This way I'd be able to quick&dirty code up something.
<james_w> thekorn: I think they are to make sure that no-one messes the tree while you are reading it.
<james_w> thekorn: I can't remember the current state of the lock infrastructure, but certainly at one point some of the lock_read() calls were no-ops.
<thekorn> james_w, whenever I do 'tree.get_file_text()' without the lock I get an Exception, so i added it there,
<james_w> thekorn: it's probably a good idea to just grab the tree, and then lock it and try: finally: the rest of the code with the unlock in the finally block.
<james_w> that should avoid you any problems.
<thekorn> right
<Qhestion> ehm, i am reading bazaars sourcecode, and in msgeditor.py line 70 (in _run_editor), there is a check for an exit code of 127 (results in a continue statement, so that the next editor is tried). what does that code mean? as far as i know exit codes are not standardized, so --?
<james_w> $ does-not-exist
<james_w> $ echo $?
<james_w> 127
<Qhestion> ah
<james_w> I don't know if it's part of POSIX or something.
<Qhestion> anyway, now it makes sense
<Qhestion> bazaars source code is better than any book :)
<Qhestion> oh and why does it else:break? shouldnt that be else:continue?
<Qhestion> no it should not
<Qhestion> nevermind
<james_w> no, that's for the case when your editor runs but dies for some reason.
<Qhestion> yeah, i had the weird idea of just trying another editor in that case. not a good idea...
<james_w> nope
<walters> hi, can someone point me to the bits of the bzrlib API I'd need to extract metadata from a working directory?  In particular, say to parse the log stream
<luks> http://bazaar-vcs.org/Integrating_with_Bazaar
<james_w> walters: sorry, can you clarify what you mean by the log stream?
<walters> luks: that looks really useful, thanks!
<walters> james_w: output of "bzr log"
<luks> but if you have any specific questions, just ask
<luks> bzr log has fairly complex code behind it
<dato> james_w, Qhestion: I don't think "x == 127" is going to happen, call() would raise ENOENT instead
<james_w> walters: so you can follow the revision pointers to get each individual revision and then read the message etc, or you can use show_log if you just want a formatted output like "bzr log".
<james_w> walters: I'd be happy to give you pointers to help with either
<james_w> hi dato
<james_w> dato: it seems to check for ENOENT as well, so that's a little odd.
<dato> (well, it could happen if your editor is (as script that is) then exec'ing something which does not exist)
<dato> s/as/a/
<james_w> ah, thanks.
<walters> hm, how do i get the revision number from a Revision object?
<james_w> walters: ah, that's harder, as a revision number is only defined relative to a particular mainline.
<james_w> are you walking the mainline?
<walters> i have a working directory
<james_w> anyway, give me one second and I should have a more helpful answer.
<luks> branch.revision_id_to_revno(r.revision_id)
<walters> i need to operate in terms of that, because my code is trying to generate statistics over the working tree for each revision
<walters> conceptually:  for revision in reversed(revisions): bzr_revert(revision); generate_statistics()
<walters> luks: cool, thanks
<luks> where is "revisions" comming from?
<james_w> walters: that's not the best way.
<walters> branch.revision_history()
<luks> then you don't need it at all
<luks> revision_history is linear
<luks> for revno, revision in enumerate(reversed(revisions))
<walters> ah, that makes sense
<fredreichbier> hello
<luks> (or reversed, I'm not sure right now)
<james_w> there's also iter_reverse_revision_history
<james_w> which will return the first one to you quicker.
<james_w> luks: did you see that jam put a version of your patch up for review?
<luks> yes
<james_w> are you happy with how it ended up?
<luks> heh, no I was unhappy for very different reasons
<luks> the patch was there since december last year, completely ignored
<james_w> yeah, I just wondered if you had any opinions on the final version.
<luks> now emacs developers complained how slow it is
<luks> and things happen...
<james_w> yeah
<luks> but yeah, the patch looks much better than mine version
<james_w> cool, at least we get a good improvement in the end, so it's not all bad.
<awilkins> jelmer: I got those pyrex bindings to build
<awilkins> Now to test the buggers.....
<james_w> awilkins: nice work.
<awilkins> james_w: You have to hold it's hand and feed it all the library includes manually because Win32 doesn't have LOADLIB or whatever it is Linux uses
<james_w> 403 Forbidden - Reading tree failed
<james_w> there's still a pristine-tar branch there though, is that just old?
<james_w> oops, sorry, wrong channel.
<walters> james_w, luks: thanks for the help, got my script working
<james_w> walters: great.
<james_w> jdong: bzr 1.3 just got ACCEPTED.
<dato> jdong: bzr 1.3-1 in Debian (currently in incoming.d.o). you'll have to check with james_w/jelmer what's up with bzr-svn
<james_w> thanks dato
<dato> james_w: gaah, I was typing :-P
<james_w> :-)
<jelmer> awilkins: ah, cool
<james_w> jelmer: hi. Would you be happy for the latest bzr-svn in Debian to go in to Hardy?
<awilkins> jelmer: Alas, it doesn't complete the selftest
<awilkins> jelmer: It seems to have a deadlock in bzrlib.plugins.svn.tests.test_commit.RevpropTests.test_change_revprops
<dato> james_w: hardy has sid's
<jelmer> james_w: Yeah, that'd be fine
<dato> james_w: 0.4.8 hasn't been uploaded yet
<james_w> jelmer: this is with 1.3 btw.
<jelmer> james_w: oh, there is nothing compatible with 1.3 out yet
<jelmer> james_w: 0.4.7 does not work with 1.3
<jelmer> it breaks in quite a few cases
<james_w> ah, ok, sorry.
<jelmer> 1.2 should be fine though
<james_w> we'll wait for you then.
<jelmer> awilkins: oh, I'm not aware of any deadlocks
<jelmer> awilkins: it just segfaults here at the moment
<james_w> I've got a patch waiting to be sponsored that removes the warning when used with 1.2, so either way hardy will end up with a working set.
<jelmer> james_w: yeah, I noticed. thanks for taking care of that
<james_w> jelmer: no problem. It would be good to get this round of updates in, but if it doesn't at least it should all work well together.
<jdong> dato / james_w: thanks for the update. Let me know how the plugins go :)
<jdong> I know bzrtools is ready
<james_w> jdong: yeah, we'll wait a few days to see if a 1.3 compatible bzr-svn arrives in time for it to be reasonable for hardy.
<jdong> that sounds like a plan.
<awilkins> jelmer: That's odd, if you run just the test on it's own, it breaks into the debugger, but it just locks solid as part of the suite
<awilkins> Is it supposed to break into the debugger?
<awilkins> Or is that the CPython Win32 equivalent of a SEGFAULT
<jelmer> I may've left a "import pdb; pdb.set_trace()" statement somewhere
<awilkins> Aha, yes
<awilkins> Is that why the suite locks solid?
 * awilkins starts suite again
<ubotu> New bug: #204759 in bzr-svn "AssertionError when committing" [Undecided,New] https://launchpad.net/bugs/204759
<awilkins> jelmer: Are tests run sequentially from the source?
<jelmer> awilkins: yes
<awilkins> Just hit a segfault (or whatever causes a process to die)
<jelmer> that's a known issue
<awilkins> But I can't seem to reproduce it - would something that causes a "WindowsError" exception do that?
<jelmer> I actually also know what is causing it but I haven't found a way around it yet
<jelmer> awilkins: Not sure, I don't have too much experience with python on windows
<awilkins> And do the test names show up before or after they execute? Because the test named on STDERR passes if you run it solo
<awilkins> The one after causes a WindowsError
<jelmer> test names show up before they execute
<awilkins> That's weird then
<jelmer> it may not have printed all test names yet though
<jelmer> are you running with -v ?
<awilkins> no
<awilkins> I'm just running the whole of TestFetchWorks now
<awilkins> Ok, it seems to be test_fetch_trunk1 but it passes fine when run on it's own
<ubotu> New bug: #160335 in bzr-svn "--prefix could be determined from specified url" [Wishlist,Fix committed] https://launchpad.net/bugs/160335
<awilkins> jelmer: It passes on its own but dies when you run it with the others
<awilkins> test_fetch_trunk1
<jelmer> re
<awilkins> Ok, question ; Python2.5 sources have a "VS2005" build folder, if I use that to run python in debug mode, will it work with my extensions built on the 2003 compiler?
<awilkins> (probably not, eh?)
<jelmer> Not sure, sorry
<jelmer> Ah, I think I finally found the bug that was blocking 0.4.8
<asabil> awilkins: I don't think so, unless you manage to get them to link against the same C Runtime (which is damn hard to do)
<yacc> jelmer: ping
<jelmer> yacc: pong
<yacc> Any progress?
<yacc> Or a description of your clever idea?
<yacc> I just pulled stable, and I'm getting still the assert exception.
<yacc> jelmer: I'd be happy to help, but you claimed last night that you have a cool idea how to fix it in a backwards compatible way, ...
<jelmer> yacc: not really in a backwards compatible way but in a way that makes older clients not able to retrieve the revision but not corrupt them either
<jelmer> yacc: this problem only occurs for the single- branching scheme, which not a lot of people appear to be using
<yacc> How can I switch the schema?
<jelmer> yacc: see "bzr help svn-branching-scheme"
<yacc> So by switching the schema I could avoid this AssertionError?
<jelmer> yacc: the idea would be to start base64-ing the path in the single path branching scheme
<jelmer> and look at for both the base64-encoded name and the non-base64 encoded name to be able to deal with older revisions
<yacc> yeah, assuming that one does not work through http.
<yacc> I'd presume that one cannot get at the non-base64 property through http anyway ;(
<jelmer> yacc: yeah, that's correct
<jelmer> it seemed possible at some point to set / in properties over http but not possible to retrieve them later
<yacc> but to help prioritize my work, switching the schema would make the assert go away?
<jelmer> Switching the scheme makes it impossible to push to your current branch in svn
<yacc> jelmer: well, yeah, checking the "old" property name and converting it to the "new" property name would make sense to me.
<yacc> Well, I have no current branch in svn ;)
<jelmer> yacc: in that case, using a different branching scheme should be fine
<yacc> That's stuff that has started it's life in bzr, I just need to push it so the rest of the devels working with svn see it.
<yacc> So what other branching schema can I switch to?
<jelmer> see "bzr help svn-branching-scheme" for details
<yacc> Yeah, but I'm not completely grasping what options I do have. (I grasp the basic problem/idea, but I have no idea what over kind of schemes might make sense for me.
<yacc> none/dir1/dir2/PackagePathWhereIPush
<yacc> ?
<jelmer> yacc: not sure I understand what you mean
<yacc> Well, I've got a path something like that: trunk/logs/LookeryBase <= LookeryBase does not exist yet. Nobody is using branches inside svn (that would not make much sense you know, branches and svn in one sentence evoke pain)
<jelmer> yacc: so, the branching scheme is basically list of branches inside the repository
<yacc> No, actually, there are no branches, just trunk in the repository.
<yacc> Now the bzr branch that I created locally, is "logically" part of the overall trunk of the svn repo.
<jelmer> yacc: In that case, just put "trunk" as single line in the branching scheme
<yacc> thanks.
<jelmer> yacc: You can only push branches, you can't push into branches
<yacc> Can I edit subversion.conf directly?
<jelmer> yeah, sure
<yacc> What do you mean by " You can only push branches, you can't push into branches"?
<yacc> I fear we have a term-overloading going on here between svn branches and bzr branches.
<jelmer> well, you can't push a bzr branch into /trunk/foo if you have /trunk as a branch
<jelmer> you can only push it into /trunk
<yacc> Well, I want to push my local bzr branch that has not yet any representation in the svn world, to /trunk/logs/LookeryBase ?
<james_w> why don't you push to /branches/whatever?
<yacc> james_w: because my bzr is logically not a branch, just a new package inside the logical svn trunk.
<yacc> My whole bzr branch are basically "files to add to the svn trunk, in some subdirectory".
<jelmer> yacc: in that case, /trnk/logs/LookeryBase is your branch in svn
<yacc> Yeah, but where do I put that in subversion.conf?
<yacc> Well, let me try it out.
 * yacc was clever and created a complete throwaway https repo just for playing.
<yacc> jelmer: http://rafb.net/p/ixuk7u60.html
<yacc> Ok, setting the schema to None does not help either.
<yacc> jelmer: list-xxxx does not help either :(
<jelmer> re
<jelmer> yacc: please try again with new 0.4
<yacc> I just pulled from stable? Or do you mean something else?
<yacc> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/stable/
<jelmer> yacc: yeah, stable
<jelmer> stable is a symlink to 0.4
<jelmer> I loosened the assertion a little bit
<yacc> Should list-XXXX include paths like /test, /test/, test or test/?
<yacc> Basically do I need slashes at the start/end?
<yacc> jelmer: still the assert error, with no scheme selected in subversion.conf
<yacc> :(
<jelmer> yacc: what version of the 0.4 branch are you using?
<jelmer> yacc: No scheme selected?
<jelmer> yacc: that probably means it's going to use the same scheme you were using earlier
<jelmer> there is no such thing as no scheme..
<yacc> jelmer:
<yacc> Tree is up to date at revision 969.
<yacc> no scheme:
<yacc> [40f52546-0a3c-0410-aace-d8ec0cfe4f10]
<yacc> locations = svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo
<yacc> I just removed the repo completely from subversion.conf, and bzr-svn did not enter a scheme when it detected the repo.
<jelmer> yacc: It still uses a branching scheme though
<jelmer> yacc: try "bzr svn-branching-scheme <repo-url>"
<yacc> andreas@andi-lap:~/lookery/lookery> bzr svn-branching-scheme svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo
<yacc> andreas@andi-lap:~/lookery/lookery>
<yacc> Funny thing, got lost in the paste.
<yacc> the above outputs exactly two empty lines.
<jelmer> yacc: in that case it will probably refuse to push anywhere
<yacc> jelmer: yeah, but what should I do?
<jelmer> yacc: You can change the branching scheme using the svn-branching-scheme subcommand
<yacc> I've do I need to set the scheme myself?
<yacc> To what?
<yacc> trunk => would make only /krit/repo/ a branch that I can push to, which is wrong.
<yacc> list-XXXX? I don't think it's meant this way, importing scheme.py and str(ListBranchingScheme(["path1", "path2"]))?
<jelmer> yacc: Use bzr svn-branching-scheme --set <url>
<yacc> What url should I provide?
<yacc> http://host/repopath/pathinrepo?
<jelmer> no, just the repo url
<jelmer> in the editor that then opens you can list the paths in the repo bzr-svn should consider branches
<Peng> Oh no!
<jelmer> Peng: ?
<Peng> Python has an official mirror of some of their svn branches in bzr two days after I do it myself.
<Peng> http://www.python.org/dev/bazaar
<jelmer> ooh, nice
<yacc> jelmer: should I also list paths that I plan to use as a branch that do not exist yet?
<jelmer> yacc: yes
<yacc> jelmer: ok, new try ;(
<yacc> still the assert error.
<jelmer> yacc: what's the revno of stable you have?
<Peng> Hmmm.
<Peng> If those were done with bzr-svn, they have the same revids as my local conversion, right?
<yacc> It updated to 970 now, before it was 969
<yacc> jelmer: still the same.
<yacc> :(
<jelmer> Peng: Yep, should be
<yacc> 7.861  adding branch dir 'testB'
<yacc> 8.898  open dir 'lookery'
<yacc> 8.898  open dir 'lookery/scripts'
<yacc> 8.899  open file 'lookery/scripts/llfp.py'
<yacc> 9.082  Traceback (most recent call last):
<jelmer> yacc: Please try with 971
<jelmer> that should print the property name that failed
<yacc> :)
<yacc> jelmer: I'm using a fresh path on each test, ...
<yacc> you forgot %s
<yacc> Now I get a TypeError:
<yacc>     assert is_valid_property_name(prop), "Invalid property name" % prop
<yacc> TypeError: not all arguments converted during string formatting
<jelmer> ah, crap
<jelmer> r972 :-)
<yacc> AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery'
<jelmer> yacc: Looks like you're still using a branching scheme with a single branch, i.e. the bit that's failing
<yacc> Which is funny, because lookery is not even there in the path I'm trying to push to, guess it's a branch nick or something.
<jelmer> yacc: please specify more than one path so it uses the list- one
<yacc> I've specified 5 paths.
<yacc> test9 .. testD
<yacc> on seperate lines.
<Peng> Yep, they do seem to have the same revids. Yay.
<jelmer> yacc: and you're pushing to one of those?
<yacc> branching-scheme = list-QlpoOTFBWSZTWdCduU8AAAzNgAAQACA8AAIADAAgACEkA0IMmIyavGI5DQ0eLuSKcKEhoTtyng..
<yacc> yes.
<Peng> I don't have to download the whole repo again then.
<jelmer> yacc: what url are you pushing to?
<jelmer> you're runinng something like "bzr push <repo-url>/test9" ?
<yacc> I've put in testD and I'm pushing to: 'svn+https://andreas:qwertz@heaven.kostyrka.org/krit/repo/testD/'
<yacc> svn-push
<yacc> but yes.
<yacc> leaving off the last slash does not help either.
<jelmer> right, that shouldn't matter
<yacc> AssertionError: Invalid property name 'bzr:revision-id:v3-single-test/lookery'
<yacc> running bzr svn-branching-scheme on the URL gives the test9-testD lines, and one empty line at the end.
<yacc> jelmer: would the Apache log help?
<jelmer> yacc: no, that's not at all relevant
<yacc> Well, bzr-svn did set branching-scheme-mandatory = True this time, ...
<jelmer> yacc: I wonder what is setting that property since it doesn't appear to be related to your branching scheme
<yacc> It looks like the nick of my bzr branch?
<yacc> How can I check that?
<yacc> The branch is in a directory named lookery.
<yacc> jelmer, let's see what properties get added.
<jelmer> yacc: it looks like it's thinking you're trying to push to test/lookery inside of the svn repository
<yacc> http://rafb.net/p/l3S2si25.html
<yacc> jelmer no such thing.
<jelmer> yacc: I mean, in svn
<jelmer> yacc: There doesn't happen to be a branch in svn with that name?
<yacc> Yes there is.
<yacc> But it's not a branch afaik.
<yacc> andreas@andi-lap:~/lookery/lookery> svn ls https://heaven.kostyrka.org/krit/repo/test/lookery/
<yacc> svn: PROPFIND Anfrage fehlgeschlagen auf Â»/krit/repo/!svn/bc/9/test/lookeryÂ«
<yacc> svn: PROPFIND von Â»/krit/repo/!svn/bc/9/test/lookeryÂ«: 207 Multi-Status (https://heaven.kostyrka.org)
<yacc> Now isn't that peachy?
<yacc> Guess a svnadmin create would be now a good idea?
<jelmer> yacc: right, that happens if a property is set once with a bad character in it
<yacc> jelmer: yeah, but I'm not refering to /test/lookery at all.
<yacc> I'm trying to push to /test?
<yacc> Should I nuke the repo?
<jelmer> yacc: it may still remember you had a revision there
<yacc> Who would remember that?
<jelmer> yacc: Yeah, I would recommend recreating it
<yacc> bzr-svn?
<jelmer> yacc: ~/.bazaar/svn-cache/
<yacc> Well, I can try to nuke svn-cache first?
<jelmer> sure
<yacc> <philosophical-rant>svn must be really quite fast. svk has an internal hidden cache too.</rant>
<yacc> It pushes, it seems ;)
<yacc> revision 2/6
<yacc> 3/6
<yacc> 4/6
<Peng> Haha, bzr missing between two copies of Python's bzr branch took several minutes.
<yacc> 5/6
<yacc> Cool it worked :)
<jelmer> Peng: yeah, I don't think it has been performance tuned yet
<yacc> jelmer: btw, do I need to specify a password on the push URL, or does bzr-svn use the svn "password caching" mechanisms?
<jelmer> yacc: it uses the svn password caching
<Peng> jelmer: Wait, when bzr-svn switches to Pyrex, what will the build dependencies be?
<jelmer> Peng: A C compiler and libsvn-dev
<yacc> jelmer: what are you planning to use Pyrex (or probably Cython) for?
<jelmer> yacc: for bzr-svn own python bindings of subversion
<jelmer> yacc: rather than using python-subversion
<yacc> jelmer: :)
<yacc> jelmer: my experience suggests that you should probably prefer Cython over Pyrex, but beside that sounds like a plausible idea ;)
<jelmer> yacc: cython generates larger files, which is why I prefer pyrexc as long as I don't need any of the features pyrex lacks
<jelmer> so far it looks like both should work with the bzr-svn .pyx files though
<yacc> jelmer: like a nice package support?
#bzr 2008-03-22
<jelmer> yacc: package support?
<yacc> Well, if you want to make bzrlib.plugins.svn.lowlevel a module, you need to store that path in the filename of the .pyx for Pyrex. Cython automatically detects the package path.
<jelmer> ah
<yacc> In theory it works with Pyrex too, and you might get by my making the module thing it's something else that it is (as long as you do not need introspection about what module you are), ...
<Peng> Also, isn't Cython supposed to have more optimizations?
<yacc> Peng: it is.
<Peng> Yeah, but I mean is more more than 3% faster?
<Peng> Bzr is kind of laughably slow on Python's branches...
<yacc> Peng: that depends on your code. For a C-library binding to Python it should make no real difference.
<yacc> Peng: that's kind of because Python is a huge svn repo. Importing python into an svk depot is beyond laughable, it's more like crying from pain.
<jelmer> yacc: ah, ok. I have no use for that right now though, so I'll try to keep the .pyx file usable by both as long as I can
<Peng> yacc: Heh. Like I said, "missing" took a couple minutes, and "diff -c" is quite slow too.
<jelmer> the C file generated by pyrex is 6500 lines, the one from cython is almost 11000 lines
<yacc> missing?
<yacc> jelmer: why do you care?
<Peng> Woah.
<Peng> yacc: "bzr missing".
<yacc> jelmer: I mean how big is the difference in compiled size?
<jelmer> yacc: It makes reading the source harder
<yacc> jelmer: C is whitespacy language.
<Peng> I was gonna say "who cares" assuming it was a small difference, but that is kinda significant.
<yacc> jelmer: you don't want to read the source. Not as long as you don't want to debug or help debug Cython/Pyrex.
<yacc> jelmer: kind of like me ended up peeking at your code :-P
<jelmer> yacc: you end up having to
<jelmer> yacc: pyrex catches a lot more errors in the .pyx file than swig does in its .i files
<jelmer> but it still occasionally generates .c files that dont compile because of incorrect .pyx files
<jelmer> and then you actually have to check the c file to see what is going wrong
<yacc> jelmer: I was lucky with Pyrex (back then there was no Cython) that I did not need to debug the generated code :)
<jelmer> or in the case of segfaults
<yacc> jelmer: In my case back then in '03/'04, swig and the C++ core app where the usual culprits for "problems" ;)
<jelmer> :-)
<jelmer> if you guys have experience with pyrex, you may actually have a clue how to work around the issue I'm facing at the moment
<yacc> jelmer: and well, nobody cared about all my little problems. The bad guys (as curious that sounds that was the sister company in NL) kept us busy with trying to decipher the file format ;)
<jelmer> I've got a callback function in pyrex that needs to return a pointer to an error whenever an exception occurs
<yacc> jelmer: tell, perhaps I can help.
<yacc> paste?
<yacc> Or branch url?
<yacc> error being what data type?
<jelmer> http://paste.ubuntu-nl.org/60476/
<jelmer> the error is a pointer to a structure
<jelmer> or NULL in the case no error occurrs
<yacc> And what is your problem then?
<jelmer> if an exception occurs in     self.set_target_revision(target_revision) I need to return a pointer to an error rather than NULL
<yacc> try: except:
<jelmer> I haven't figured out a way to do that yet though
<yacc> put a try: except: as in Python around the call.
<jelmer> yacc: I need to retain the exception as well
<yacc> Well, in any chance to piggy pack it onto svn_error_t?
<yacc> If not, you will probably need to keep it in a dictionary keyed by pointer address?
<jelmer> ieuw
<jelmer> yeah, I guess that would work
<yacc> nobody said that it's cool to wrap a C API, especially one that uses callbacks and other stuff for a language like Python.
<yacc> One of the better things about the Gnome Project was that it realized that from the beginning, and despite some flames, they managed to make their APIs "wrapping-friendly" ;)
<jelmer> the svn API is pretty good overall
<jelmer> pyrex is a little less powerful than swig though (which is used for python-subversion)
<jelmer> the language is a lot saner though
 * Peng gets a traceback using bzr-svn on Lighttpd's repo.
<Peng> Somebody forgot to import "errors" in svk.py.
<Peng> Well, I guess it'd just error out anyway for a different reason if it weren't for that. :P
<yacc> less powerful?
<yacc> I wouldn't say so. It's just way less automatic. OTOH, when you wrap something, you get usually a better designed wrapping, and potentially a faster one.
 * Peng notices that his copy of bzr-svn is out-of-date.
<radix> Peng: oh yeah, I've been noticing that like 100 times a day lately
<Peng> Ok, updating didn't help.
<jelmer> Peng: What branch are you using?
<Peng> jelmer: Hold on.
<Peng> jelmer: .bzr.log http://paste.pocoo.org/show/34862/
<Peng> jelmer: svn://svn.lighttpd.net/lighttpd/trunk/
<Peng> jelmer: svn import on the repo did it too
<Peng> jelmer: Latest bzr-svn 0.4 and bzr.dev as of five minutes ago.
<jelmer> Peng: You shouldn't get a out-of-date error with bzr-svn 0.4 though
<jelmer> Peng: I've fixed the import error
<Peng> Thanks.
<Peng> Responsive developers are awesome.
<Peng> jelmer: Um, yeah, now it works. Thanks. :)
<jml> jelmer: that reminds me, the 0.4.8 branches works really well with the o-hand.com repos.
<jelmer> cool :-)
<ubotu> New bug: #145171 in bzr-svn "Invariant break on bzr missing in bzr-svn" [Medium,Incomplete] https://launchpad.net/bugs/145171
<ubotu> New bug: #94316 in bzr-svn "Traceback doing log -v" [Low,Triaged] https://launchpad.net/bugs/94316
<awmcclain> Where does bazaar.conf live? In site-packages?
<abentley> awmcclain: in ~/.bazaar
<jholman> I want to install bazaar on an ubuntu box.  I am pretty much an ubuntu noob, I confess.  I followed the link to the bazaar launchpad site, and added the 2 gutsy lines to my sources.list, and did apt-cache show bzr...
<jholman> and I get 2 entries, first of all (one out of the main ubuntu package repository, I guess?)... and they're both old versions
<jholman> 1.2-1 and 0.90-1
<fullermd> Well, 1.2 is only old as of, like, 12 hours ago or something.
<jholman> fair enough.
<jholman> so the reasonable thing to do is to trust apt, remember that I should do an update/upgrade in a day or three, and go from there?
<fullermd> With the caveat that I don't really know anything about Ubuntu packaging (or package using), that sounds right.
<jholman> hmn, significant caveat, but fair enough
 * fullermd is all about ambiguity, except when he's not   :)
<jholman> =]
<abentley> "We demand rigidly defined areas of doubt and uncertainty!"
 * fullermd demands that he may or may not know about a bzr release.
<abentley> Well, we haven't been quite punctual about getting the debs out in the past.
<abentley> Yes, it does look like 1.3 hasn't hit our repo yet.  It should in the next few days.
<jholman> ok
<Odd_Bloke> Morning.
<rusty> Hi all: I'm struggling to find out if there is an answer to the question of setting up multiple committers to a (remote) repository.
<jml> rusty: hi.
<jml> rusty: you mean multiple people pushing to the same branch?
<rusty> jml: yes.
<jml> rusty: that should pretty much work out of the box. what problems are you having?
<rusty> jml: well, currently I'm using rsync to send to server, but that won't work for the second committer.
<rusty> jml: so I wondered what the "correct" way to do this is.
<jml> rusty: well, the "correct" thing is both people should be using 'bzr push bzr+ssh://..."
<jml> but let me do an experiment
<rusty> jml: for mercurial, I have an acct on the server with write access to the repo and put their ssh key in the authorized_keys with command=
<jml> rusty: is the issue is that the push overwrites permissions / ownership?
<jml> you could do that with bzr, I think
<rusty> jml: no, sorry, the issue is that I haven't tried it, was looking for advice :)
<jml> oh :)
<jml> so, I think you don't have to do that, if you wanted you could have an account per user.
<jml> (that's what I'd do, if I weren't using something like PQM)
<rusty> jml: I really don't want to hand out accounts on the server.
<jml> rusty: you could also do what you just described -- a special account with authorized_keys
<jml> rusty: alternatively, you could use Launchpad (but I'm guessing you want to host this yourself).
<jml> rusty: what do you know about PQM?
<rusty> jml: nothing, I just googled it when you mentioned it :_
<jml> rusty: ok. PQM acts like an automated gatekeeper. You send it signed emails and it does the merge.
<jml> rusty: Bazaar itself uses PQM to make sure that the test suite passes before it lands anything.
<jml> rusty: I haven't set it up myself, but if that sort of thing appeals to you then you might want to check it out.
<jml> (is this for libantithread, perchance?)
<rusty> jml: ccan :)
<jml> heh.
<rusty> jml: OK, I think I'll try adapting the "hg-ssh" wrapper for bzr.  Looks like it'll be fairly easy.
 * jml thinks
<jml> rusty: why do you need a wrapper?
<rusty> jml: you use "command=wrapper <repos>" and it restricts that key to only running bzr, and what repositories it can access.
<rusty> jml: it's a cute ssh feature (the command they wanted to run is in $ORIG_SSH_COMMAND)
<Odd_Bloke> jml: http://bazaar.launchpad.net/~daniel-thewatkins/+junk/merged-branches now has working shelved changes logic, and a test to go with it.
<jml> Odd_Bloke: you mean my previous logic was not working? inconceivable!
<jml> rusty: it'd be cool if you could post it to the Bazaar ML once your done. That is, if there's anything interesting and not site-specific :)
<rusty> jml: sure!
<Odd_Bloke> jml: It wasn't so much that the logic wasn't working as that you weren't actually referencing bzrtools and you were getting hit by double-underscore munging. :p
<jml> Odd_Bloke: I guess now that I've got more than one user and more than one contributor I should register a project for it.
<jml> Odd_Bloke: can you suggest a name better than "merged-branches"?
<Odd_Bloke> jml: The little thought I've given it didn't produce anything better, sadly.
<jml> Odd_Bloke: merged-unchanged-unshelved-branches doesn't have quite the same _energy_.
<jml> Odd_Bloke: what do you think of 'boring-branches'?
<Odd_Bloke> jml: I'm not sure it conveys enough of what it actually means.  How about 'redundant-branches'?  Or 'removable-branches'?
<Odd_Bloke> Perhaps 'excess-branches'?
<jml> luxury-branches :)
<fullermd> this-is-an-ex-branch
<Odd_Bloke> gratuitous-branches :p
<jml> ok. As benevolent dictator for today, I am going to call the project bzr-removable
<jml> Odd_Bloke: OK w/ MIT license?
<Odd_Bloke> jml: I'd prefer GPL, but I'm easy.
<jml> fine by me.
<rusty> jml: Erk, hit a snag.  bzr push bzr+ssh runs 'bzr serve --inet --directory=/ --allow-writes' on the remote end, indep. of what repo it's trying to access.
<rusty> jml: Makes it hard to restrict the repo by looking at command line.
<rusty> jml: (0.9 does this as well as 1.3)
<jml> *nod*
<jml> I should have foreseen that, sorry.
 * jml has a look around
<jml> rusty: ok, so I have a crummy workaround.
<jml> rusty: but it's pretty terrible.
<rusty> jml: well, I was going to ignore it for the moment, so I doubt yours will be worse :)
<jml> (Bazaar should change to let you specify a directory)
<jml> rusty: you were warned
<jml> rusty: you can tell it which bzr executable to run using BZR_REMOTE_PATH.
<jml> and then you could dispatch off that.
<rusty> Erk, I was thinking to change --directory=/ to --directory=<acct home dir> so they can only access stuff in their home?
<jml> rusty: yeah, that would be better if you could do that :)
<jml> rusty: but if you have a wrapper script that's parsing the contents of SSH_ORIGINAL_COMMAND then you could do something horrible based on the specified location of the bzr executable.
<jml> ugh.
<jml> that's a bad idea, forget I said anything.
<jml> Odd_Bloke: with bzr plugins, is there a convention for the team that owns trunk?
<rusty> jml: hmm, want to give me a hint on how to s,--directory=/,--directory=sys.argv[1], in python?  And then exec it?
<jml> rusty: sure
<jml> os.system(command_string.replace('/', sys.argv[1], count=1)) should do the trick.
 * AfC waves to rusty
<rusty> jml: don't I want .exec to avoid quoting troubles?
<AfC> rusty: I've been through a lot of the hosting pain; if you're still stuck next week I can totally try to help you out when I get back.
<rusty> AfC: this is self-inflicted... bzr is the one distributed vc system I hadn't tried yet.
<jml> rusty: was being quick and dirty
<AfC> rusty: I've had some nice results, though... things like http://research.operationaldynamics.com/bzr/java-gnome/mainline/ instead of an empty directory
 * jml always has to look this stuff up
<rusty> jml: I think I'm almost there...
 * AfC really needs to move that server from Europe to western North America somewhere :)
<jml> rusty: using exec would work fine too.
<jml> Odd_Bloke: I'm getting hungry and kind of bored of sitting at a computer. I'll have a play with your branch tomorrow.
<jml> Odd_Bloke: the bzrtools fix is obviously right :)
<fullermd> Erk.  You wanna be careful playing with that --directory...
<fullermd> You get too smart, you'll wind up giving yourself big headaches down the road.
<rusty> jml: woot: $ bzr push bzr+ssh://ccan@ozlabs.org/ccanThis transport does not update the working tree of: bzr+ssh://ccan@ozlabs.org/ccan/. See 'bzr help working-trees' for more information.- [==                                                        ] Transferring 0/4
<rusty> jml: I ended up with babytalk python: if orig_cmd == 'bzr serve --inet --directory=/ --allow-writes':    os.execlp('bzr', 'bzr', 'serve', '--inet', '--directory=' + sys.argv[1], '--allow-writes')
<jml> rusty: nothing wrong with simple.
<rusty> jml: no doubt it will break if bzr changes cmdline, but it should be obvious.
<jml> right.
<jml> rusty: I look forward to reading your email. :)
 * jml is really gone now
<Odd_Bloke> jml: Sorry, I was playing Peggle.  I don't know about convention, enjoy your food and have a good Easter. :)
<thekorn> hi all, In a script I would like to get all revision numbers of a branch,
<Odd_Bloke> thekorn: What do you mean by "all revision numbers of a branch"?
<thekorn> is it save to do something like    range(1, number_of_last_rev +1) ?
<thekorn> Odd_Bloke, a list of all revision numbers of a branch
<Odd_Bloke> I can't immediately see why not, but that will obviously exclude merged revisions (i.e. dotted revision numbers).
<thekorn> are this rev numbers continuous and linear?
<Odd_Bloke> The mainline revision numbers are, but merged revisions use dotted revnos.
<thekorn> Odd_Bloke, that's fine I'm only intrested in the "main-line"
<Odd_Bloke> Then you should be fine. :)
<thekorn> thanks
<Odd_Bloke> What are you using all the revision numbers for?
<thekorn> Odd_Bloke, well I started to play around with bzrlib yesterday and I ended in writing a fuse-file-system for bzr
<Odd_Bloke> thekorn: Ah, interesting.  Someone at the sprint was looking at that, though I can't remember who.
<thekorn> within the filesystem there are two main directorys "revisions" and "tags"
<Odd_Bloke> thekorn: I think enough people would be interested in looking at that to make it worth sending something about it to the mailing list.
<thekorn> Odd_Bloke, sure, will push the code to launchpad project soon and can also write a mail to the ML
<Odd_Bloke> Awesome, thanks. :)
<nubbun> In bzr 1.3, I have an error loading bzrlib .  It recommends setting PYTHONPATH.  Setting PYTHONPATH has no effect.
<nubbun> on this error.  The error is still reported.
<nubbun> Running bzr from the top of its directory tree, works.
<Odd_Bloke> nubbun: Could you pastebin the error?
<nubbun> http://www.pastebin.org/24836
<Odd_Bloke> nubbun: Just having a look now. :)
<Odd_Bloke> nubbun: How did you install bzr?
<Odd_Bloke> And what type of sustem are you on?
<Odd_Bloke> *system
<nubbun> extracting a tarbal
<nubbun> linux
<nubbun> Debian Etch
<dato> nubbun: did you cp bzr to your ~/bin?
<Odd_Bloke> nubbun: So you did 'tar zxvf bzr-1.3.tar.gz' (or equivalent)?  Did you take any further steps?
<nubbun> no did ln
<dato> nubbun: if so, I recommend that you symlink it instead
<dato> nubbun: ln -s?
<dato> or ln alone
<nubbun> Trying now.
<nubbun> Now it works as symlink.
<ubotu> New bug: #205112 in bzr "bzrlib in PYTHONPATH not found" [Undecided,New] https://launchpad.net/bugs/205112
<ubotu> New bug: #161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830
<radix> Am I the only person that often runs into problems using bzr-svn on a project that already uses lots of branch-based SVN development?
<radix> like, trying to merge stuff with SVN often results in a conflict on "."
<jelmer> radix: Haven't seen that issue before
<jelmer> radix: conflict on . ?
<radix> jelmer: properties, presumably
<jelmer> radix: Ah, svn merging bzr branches in svn?
<radix> jelmer: svn merging SVN branches that happened to have bzr commit to them in svn
<radix> to be precise :)
<jelmer> That's basically unsupported by bzr-svn at the moment
<radix> it seems bzr-svn would be great if I were only trying to integrate with projects that mostly do trunk-cowboy hacking
<jelmer> until the ability in bzr-svn to use revision properties (as opposed to file properties) lands
<radix> jelmer: ah, that sounds exciting
<ubotu> New bug: #205156 in bzr "KnitRepository.insert_data_stream() copies data in improper order" [Critical,Triaged] https://launchpad.net/bugs/205156
<arnetheduck> hi, I'm about to migrate from svn to bzr and I noticed that there are several options available - does anyone have any tips on which one to choose?
<arnetheduck> bzr-svn seems nices to me, but it seems like it doesn't keep the tags for example...
<arnetheduck> (I have a classic trunk/branches/tags type of svn repo)
<jelmer> arnetheduck: it will keep the tags (if you use "bzr svn-import") but as branches
<arnetheduck> jelmer, so I noticed - does that make sense? I usually tag my releases (and I don't touch them any more after tagging) so it seemed like real tags were more suitable
<jelmer> arnetheduck: yes, but there are certain issues that have to be addressed first for that to be supported
<jelmer> bug 81102
<ubotu> Launchpad bug 81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102
<arnetheduck> jelmer, assuming that there were no changes from the tag to it's source revision (which is verifiable via log), it shouldn't be too hard, right?
<arnetheduck> I poked around in the bzr-svn code a few weeks ago and saw that there are at least some functions for detecting tags / tag dirs
<jelmer> arnetheduck: tags and branches are considered equally at the moment
<jelmer> furthermore, you have to make sure the revision that created the tag didn't introduce any other changes to it
<jelmer> there can be multiple tags directories in a repository, possibly not related to the branch you're checking out
<ubotu> New bug: #81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102
<dato> arnetheduck: I think you could easily script converting the resulting tag-branches to real tags after bzr-svn did its
<dato> arnetheduck: job?
<arnetheduck> dato, that's crossed my mind but would leave some cruft in the repo...
<dato> arnetheduck: cruft?, what cruft?
<arnetheduck> dato, the branches
<dato> arnetheduck: uh, you'd just rm -rf them after converting them to real tags
<arnetheduck> dato, well, not if they're imported too (they'd show up in logs etc)
<dato> ok, maybe you're still not fully familiar with bzr and that's why we're not understanding each other :)
<dato> arnetheduck: each branch is mostly independent from each other, there is no such think as "log for the repository as a whole"
<dato> does your SVN repo contain many projects, or only one (with its tags, and maybe some branches of it as well)
<arnetheduck> dato, yep, I'm a 100% noob, as green as they come =)
<dato> ok. I think the user guide has some parts explaining this stuff, but as a crash course:
<arnetheduck> dato, it's a single project, no branches, one trunk, tags every now and then
<dato> - each branch is
<dato> ok, scratch that
<arnetheduck> I think get your point though
<dato> great
<arnetheduck> I'm kind of used to the svn/cvs mindset after a few years
<dato> each tag-branch will be like a "cp -r" from the original branch *at some point of its history*
<dato> so, as svn does "copies", but in its svn-filesystem, you do copies here, but in the real filesystem
<arnetheduck> dato, yeah, in my mind the branches remained in the .bzr folder thus created cruft, but then it your point sunk in =)
<dato> ok
<ubotu> New bug: #205181 in bzr-svn "importing https://svn.xiph.org/trunk/theora fails" [Undecided,New] https://launchpad.net/bugs/205181
<arnetheduck> dato, so conceptually, the script would read each branch created by the importer, find out which revision of the trunk branch it was copied from and add a tag to the trunk
<dato> more or less. if the tag-branches created by bzr-svn contain no additional commits, which I don't think they do but jelmer can confirm, it's just a matter of:
<dato> for each tag-branch:
<dato>   r=second word of `bzr revision-info`
<dato>   in trunk: bzr tag -r revid:$r $tagname
<jelmer> they always contain at least one extra revision (the one in which the tag was created)
<dato> oh, ok
<dato> then `bzr revision-info -r -2`, with manual supervision, I guess
<arnetheduck> thanks, brb, gotta feed the kid =)
<AfC> How many tests in the Bazaar test suite, roughly?
 * AfC refers to this in our HACKING document as a point in bzr's favour
<dato> AfC: the other day 10,000 was reached
<AfC> dato: nice. 10K it is.
<AfC> dato: thanks!
<jelmer> and that's just in bzrlib.. with a couple of plugins installed it's closer to 15k here
<AfC> jelmer: wow
<AfC> jelmer: that's amazing
<AfC> [not that you really care, but what me write about this is at: http://java-gnome.sourceforge.net/4.0/HACKING.html under "Why bzr?"]
<AfC> yikes
<AfC> what I have written*
<jelmer> AfC: nice
<jelmer> AfC: btw, "bzr send" should now Do The Right Thing[tm] if you have the child_submit_to setting set to an email address in your main branch
<jelmer> as alternative to running "bzr bundle" and then manually attaching the bundle and specifying the email address
<AfC> jelmer: yeah, I'll work out the wording for that down the track.
<AfC> (is that something that will propagate? No, I believe? Only if someone creates a new branch, right?)
<AfC> (Will it "remember"?)
<AfC> (that'd be nice)
<jelmer> AfC: It retrieves it from the submit branch so there shouldn't be a need to propagate it
<jelmer> for example:
<AfC> ah
<jelmer> bzr branch lp:bzr-gtk; hack-hack; bzr commit -m "foo"; bzr send
<jelmer> will do the right thing and retrieve the email address from the branch configuration of lp:bzr-gtk
<AfC> That's what I meant about it working for a new branch; people who have existing repository/branch structures will need to twiddle something manually I expect.
<AfC> (is what I was asking, that's all)
<jelmer> AfC: in the scenario I just mentioned, no extra twiddling would be required
 * Rhamphoryncus checks to see just how well bzr handles merging without known common bases
<Rhamphoryncus> I was using a svn checkout initialized as a bzr repository (without the bzr-svn plugin!).  Now upstream has an official bzr mirror, so I'm trying to switch to that and eliminate svn..
<Rhamphoryncus> aha, it gave up.  bzr: ERROR: Revision {('rhamph@base-two-20071105225603-16zlps51e17ghkzl',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x106d8f2c>".
<Rhamphoryncus> So, can anybody think of an option that gets me most of the history?
<Rhamphoryncus> assuming my initial checkin had no changes over upstream I should be able to do a patch set and reapply them somehow, right?
<awilkins> AfC: btw, bzr merge won't let you merge if your tree has diffs from -r -1
<awilkins> Hence "do the merge after you.ve finished anything you might happen to be doing" is redundant.
<AfC> awilkins: Did I imply that it would somwhere?
<AfC> awilkins: ah.\
<AfC> awilkins: well, I'm not really a big fan of Bazaar's error messages.
<awilkins> Although you could use the point as an opportunity to mention shelve
<AfC> awilkins: so while you are indeed correct that it is redundant, it doesn't hurt to be attempt to set newbies on the right track habit wise.
<AfC> awilkins: that in core yet?
<awilkins> shelve is still in bzrtools AFAIK
 * AfC only just grabbed 1.3, so I'm not current with the latest state-of-play
<awilkins> I switched back to 1.2 from 1.3 on the chance that it might be futzing with the pyrex version of the bzr-svn branch
<jelmer> Rhamphoryncus: you may be able to use rebase or replay to replay the changes your local branch has on top of the new upstream branch
<jelmer> awilkins: It would be awesome if we could get that exception handling fixed so 0.4.9 can be released with the pyrex bindings
<awilkins> jelmer: I was thinking of running the test in Python running attached to a debugger, but I've not got Python 2.5.2 building on Win32 yet ; and I don't have a full 7.1 toolkit
<awilkins> My best chance so far seems to be using the 9.0 toolkit because you can at least download it as part of the PSDK
<jelmer> awilkins: Running the tests doesn't make a lot of sense until this problem is resolved
<jelmer> until then, you'll probably keep getting segfaults
<awilkins> jelmer: What is so frustrating is that it only segfaults if you run the test suite - the test on it's own passes
<awilkins> Running the host class is enough to trip the fault
<awilkins> Sounds memory-flavoured
<awilkins> something being initialized wrong or a pool going bad or something
<jelmer> awilkins: that's probably related to it not reporting the test that's segfaulting properly
<awilkins> So it could be the following test?
<awilkins> Which DOES throw an exception
<jelmer> if it prints "ignored exception ..." that's probably a test that's causing a segfault
<awilkins> WindowsError, as I recall
<awilkins> Not got my desktop fired up ATM though
<jelmer> Ignored Exception "WindowsError ..." ?
<awilkins> Possible
<awilkins> Give me a few minutes, I'll boot my desktop and run it again
<arnetheduck> returning to my repo move, once I have my repository converted I'll be keeping a main development branch that I'd like to sync the old svn to, one-way, so that commits to the bzr branch are merged to the svn branch...this should be doable with the bzr-svn plugin, right?
<awilkins> jelmer: It's an "Access is denied"
<jelmer> awilkins: hmm, ok
<jelmer> awilkins: what happens if you run selftest with --one ?
<awilkins> jelmer: On just that test, or the whole bzr-svn tree?
<jelmer> awilkins: all of bzr-svn
<jelmer> it should then quit and print the backtrace as soon as it hits a single exception
<awilkins> jelmer: fails on test_branch.WorkingSubversionBranch.test_create_checkout
<awilkins> SubversionException: ('Unable to open an ra_local session to URL', 180001)
<awilkins> jelmer: This is bzr 1.2, that right?
<jelmer> awilkins: should be 1.3
<jelmer> or bzr.dev
<awilkins> http://pastebin.ca/953008
<jelmer> awilkins: I think that one is probably specific to your environment
<awilkins> Are these bindings SVN 1.5 specific or are they still 1.4.6 compatible?
<awilkins> Well, I've built them against the 1.4.6 deps packs, so I guess they should work, eh?
<jelmer> awilkins: yeah, 1.4 and 1.5 should both work
<awilkins> jelmer: Arrgh, it works from Eclipse/PyDev but not from my shell
<awilkins> I HATE Heisenbugs
<awilkins> Hmm
 * awilkins diffs plugins tree and source
<ubotu> New bug: #205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Undecided,New] https://launchpad.net/bugs/205230
<j1mc> hi there.  a group i work with was interested in upgrading our repository to the new pack format, but don't know if it's possible with bzr-svn (which we use)
<j1mc> here's what i get when i do a bzr info: Checkout (format: dirstate-with-subtree)
<jelmer> you could upgrade to --pack-0.92-subtree
<j1mc> jelmer: thanks... i will check into that.
<j1mc> jelmer: per this page ( http://doc.bazaar-vcs.org/latest/developers/packrepo.html#testing-packs-for-bzr-svn-users ) it says that this kind of subtree support is bleeding edge.  is that still accurate?
<jelmer> j1mc: the format is not experimental but some of the functionality it enables is
<j1mc> jelmer: could you recommend a page that would detail some of this advanced functionality?  i think we use bzr in a pretty straight-forward manner, but it would be good to know what options are more experimental, and what options are better supported.
<nubbun> Odd_Bloke: thank you for the response to the first PYTHONPATH bug report.
<jelmer> j1mc: it's fairly simple actually; it enables by reference nested trees
<jelmer> j1mc: created using "bzr join --reference". If you avoid using that command you should be fine
<j1mc> jelmer: thanks.
<TheMonkey> hola
<TheMonkey> what is the recommended way of setting up a read-only bzr repo over http?
<james_w> TheMonkey: there should be no setup needed, just serve the branch over HTTP.
<awilkins> jelmer: Mutters should be showing up in the test log?
<TheMonkey> so just copy the folder to the server?
<james_w> TheMonkey: yes, bzr push can do that.
<TheMonkey> james_w bzr push over http?
<james_w> TheMonkey: no, bzr push over ssh or something.
<TheMonkey> ah, yes
<TheMonkey> is there webDAV support or similar planned to support http for writing, too?
<TheMonkey> just curious, being a long time svn user
<james_w> TheMonkey: there is a webdav plugin, but it is marked experimental.
<jelmer> awilkins: yep
<TheMonkey> james_w, i see. thanks for the info, i can wait :)
<awilkins> jelmer: This stack dump lists a line that occurs after a mutter, but the mutter output isn't showing
<jelmer> awilkins: it may not have been flushed to disk
<awilkins> jelmer: can you force it, because knowing the value would really help :-)
<awilkins> jelmer: It's to STDOUT anyway, why would disk flush be a problem?
<jelmer> mutter doesn't print anything to stdout
<awilkins> Oh, so the test routine is reading the log file then
<awilkins> Might it be in the log?
<jelmer> awilkins: no, it's not reading the log file either
<jelmer> mutter writes to the log file
<awilkins> I'm seeing text that is in mutters in my output when I run this test
<awilkins> Or maybe I'm not
 * awilkins is going mad
<awilkins> Nope, there it is "Guessed branching scheme" - the only place I can find it is in a mutter and it shows in the output
<jelmer> awilkins: it will remember the mutters for a particular test in memory and output that when the test fails
<jelmer> after all tests have run
<awilkins> jelmer: Which is what's puzzling me because the stack dump says line 94, the mutter is on line 93
<awilkins> Just before it enters the pyx code
<jelmer> it should never be printing any of the mutters data to stdout during the test run, only afterwards
<awilkins> This is afterwards on a --one run
<jelmer> awilkins: But that one's not crashing then?
<awilkins> jelmer: No, but it's weird ; if I run it from Eclipse it passes, from the shell it fails
<jelmer> have you tried running it inside a debugger?
<awilkins> jelmer: Does "debug as python unit-test" from Pydev in eclipse count?
<awilkins> jel
<awilkins> jelmer: I presume the debugging is just calling pyunit
<jelmer> awilkins: Not really - I mean a C/C++ debugger
<awilkins> jelmer: I'd have to run it from a python console and attach it, yes?
<james_w> dato: hi, I think taking the first line of the commit message as special has something to do with it.
<dato> james_w: sorry?
<james_w> dato: also the fact that the commit messages are shown much more prominently with git's usual submit message.
<james_w> dato: re: your blog, sorry.
<dato> aah, for the "good" part?
<james_w> yeah,
<dato> possibly, yeah
<james_w> I do agree that it is a good thing that is much more common there.
<jelmer> awilkins: You should be able to start the python debugger in visual studio or sometihng
<awilkins> jelmer: I have python.exe attached ... now I'm having a hard time running the test from the console
<awilkins> jelmer: tried "commands.run_bzr(["selftest", "svn", "--one"])    but it stops in __init__ for tests because theres no log file
<jelmer> awilkins: can't you just attach to "python.exe c:\path\to\bzr.exe selftest svn" ?
<awilkins> jelmer: Yes, I think so ... C dev is not my usual domain, I'm a Java / VB6 / CSharp coder by trade
 * awilkins energises
<mw-home_> I've got a question.  I use SVN right now, on a remote server.  I'm going on vacation and bringing my laptop.  Can I make a local bazaar repository based on my svn repository, then do lots of local commits, then when i come back, push it all into the svn repository?
<awilkins> mw-home_: YEs
<mw-home_> thanks!
<awilkins> jelmer: That test still fails and throws no unhandled exceptions that a debugger catches
<awilkins> mw-home_: You need the bzr-svn plugin
<awilkins> jelmer: If you have VS on windows it tends to allow you to attach a debugger JIT just before the process drops dead anyway
<arnetheduck> awilkins, when recommitting those changes, will each local commit become a svn revision or will all changes go into one svn rev?
<mw-home_> awilkins: ok.  i'll try to get that plugin.
<awilkins> arnetheduck: Each mainline revision becomes a single SVN revision
<arnetheduck> awilkins, nice - that means that I can keep a read-only svn repo in sync with a particular bzr branch with very little effort
<mw-home_> i installed bazaar, but i don't have a bzr in my path.  i have a baz in my path.  are these the same?
<LeoNerd> No... baz is the arch reimplementation; a totally differnet program
<james_w> mw-home_: if you are Debian/Ubuntu install bzr instead of bazaar.
<mw-home_> thanks
<jelmer> awilkins: It should be possible to start a process in the debugger
<awilkins> jelmer: Yes, I've managed that, but it didn't trap anything
<awilkins> jelmer: For this bug, the default branch_implementations.test_branch.TestBranch.test_create_checkout tests are failing the same way
<jelmer> awilkins: how do you mean? Running "bzr selftest svn" inside the debugger doesn't make it crash?
<awilkins> jelmer: No, I was just running with --one and the first fail isn't scary
<awilkins> jelmer: Running without --one now ; it was attaching to the process before
<awilkins> jelmer: One problem is I don't think my Python has debug symbols (the Windows build is a bit short of them)
<awilkins> jelmer: Can Pyrex build with DEBUG on ?
<awilkins> jelmer: That wasy the extensions at least would have symbols
<awilkins> jelmer: Well, the debugger traps it, it's in libapr.dll
<arnetheduck> dato, managed to make a little bash script that creates tags based on the tags
<awilkins> jelmer: I'll load APR sources into VS and try againb
<arnetheduck> there are some problems though - it seems that when one does svn copy, it doesn't always note the correct revision that the copy came from - sometimes it uses an old revision + changes made since that revision
<arnetheduck> or rather, that the revision of the directory isn't always the revision of the entire copy, but older, so if I tag that revision in bzr, it doesn't get all changes...
<mw-home_> subversion does checkout, mercurial does clone; what do i do to get a working copy of somebody else's project in bzr?
<awilkins> jelmer: bzr-svn needs sqlite, yes?
<james_w> mw-home_: branch (or clone) if you want a proper branch like mercurial, checkout if you just want a working copy for their branch like subversion
<jelmer> awilkins: yep
<awilkins> jelmer: I'm having success building the python 2.5.2 sources from scratch, few deps like sqlite missing ATM though
<awilkins> Also running that APR project in DEBUG now (doh)
<arnetheduck> jelmer, found a place where bzr-svn loses history when doing svn-import
<mw-home_> i'm going to read the bzr for subversion users guide, then try to figure out what I need to do to use both a remote SVN repository and a local bzr repository.
<james_w> mw-home_: you will want "bzr branch" for the use case that you described above.
<james_w> you can then take that on holiday, commit as you like, and the when you come back "bzr push" to update subversion.
<arnetheduck> jelmer, here are the two log entries if you have a second to take a look: http://pastebin.ca/953159
<mw-home_> james_w: i thought I wanted to do a bzr checkout of my svn repository.  I should use bzr branch instead?
<awilkins> mw-home_: Yes, you do. Or even better, create an empty branch (--pack0.92-subtree) and pull into it (if it's a big SVn repo)
<james_w> mw-home_: if you do checkout then it will update subversion on every commit, if you do branch then it only does it when you push.
<james_w> so you need network access to the svn server to commit in a checkout, and if you are on holiday this may be
<james_w> difficult, so I would say branch is better.
<jelmer> arnetheduck: ?
<jelmer> arnetheduck: where?
<james_w> You can switch between them as you like with the "bind" and "unbind" commands though, so the decision is not too big now.
<arnetheduck> jelmer, the files, those that are added & removed
<jelmer> arnetheduck: what would you expect it to do? bzr doesn't have a "replace" operation
<arnetheduck> if you look at the svn log, you'll see they've been replaced (R), but that that new versions came from trunk
<jelmer> arnetheduck: you'd expect them to be M ?
<mw-home_> james_w: thanks!  That makes a lot of sense.  So, bzr push sounds sort of like merging.
<arnetheduck> jelmer, I'm not sure what I'd expect them to be...I would expect having full logs for those files though...if you look at the svn log you'll see that the files come from trunk
<arnetheduck> jelmer, so doing svn log you get the full history...doing bzr log on the same files gives just one revision
<jelmer> arnetheduck: R in this case is an alias for delete existing file + copy from somewhere else
<jelmer> arnetheduck: bzr doesn't support copy tracking (yet)
<jelmer> so there's nothing sane bzr-svn could map this to
<jelmer> it could do extra processing to infer that there are no other ancestors of those particular files in the current tree, but that would be very expensive performance-wise
<jelmer> arnetheduck: I would rather instead wait for copy tracking support in bzr to land
<james_w> mw-home_: merging in bzr is a bit different, you can only push if the two branches haven't diverged.
<james_w> if you both have commited some revisions then you need to merge in one branch and then push to the other.
<mw-home_> james_w: I really should just read the docs.
<james_w> mw-home_: that would probably help. Also just playing with a couple of branches for a minute might help
<james_w> mw-home_: just create a throwaway branch with "bzr init foo" then add some files, commit and then branch, push, pull, merge etc. to see what is possible.
<james_w> then "bzr log" can show you what you did.
<james_w> Also "bzr viz" from bzr-gtk can show you a graph that may help you to visualise what is going on.
<arnetheduck> jelmer, but it does track the copy for the directory (and the unchanged files...)?
<mw-home_> I installed the bzr-svn package; is there a separate bzr-svn executable, or does it augment the bzr executable?
<jelmer> arnetheduck: The branch root copy is tracked yes, but that is not a copy in the bzr sense
<jelmer> mw-home_: You should be able to use most bzr subcommands with subversion urls now
<jelmer> just like you would with bzr urls
<mw-home_> jelmer: my svn repository requires http authentication.  the bzr-svn FAQ says that it will use cached userIDs and passwords.  but it ain't working for me right now.
<mw-home_> I'm doing bzr branch http://myrepository/myproj
<mw-home_> And I get a 401 reply (of course).
<arnetheduck> jelmer, ah, ok...because I guess it's a fairly common situation for svn repos - the above probably happened because if you do a commit, the revision of the directory won't be updated until you do an update (directories generally get the same revision as the revision of the newest sub-entry), so if you do svn copy from a working copy that hasn't been updated, you end up with logs like mine above
<jelmer> mw-home_: have you forced subversion to cache the password for you?
<jelmer> mw-home_: what os are you on?
<jelmer> arnetheduck: I agree it's not as nice as it could be
<jelmer> arnetheduck: it leads to confusing logs in svn itself as well though
<mw-home_> jelmer: yeah, i have a cached password.  I can do svn info http://myrepos/myproj and I get data back, and I don't get prompted.  I'm using ubuntu gutsy.
<jelmer> mw-home_: you may have to use svn+http:// rather than http://
<arnetheduck> jelmer, indeed - although I must admit it's the first time I look at the log entry of a branch in svn =) I didn't expect it either...
<mw-home_> jelmer: yeah, that seems to be working.  Thanks!
<mw-home_> Will I now have my entire svn repository, history and all, inside bzr now?
<mw-home_> or do I only get the most recent (HEAD) revision?
<arnetheduck> jelmer, in any case, I have a bash script now that reads the revision of the directory and makes a tag for that revision in the trunk so that tags are tagged...let me know if you think it could be useful...
<arnetheduck> *the tag directory
<jelmer> mw-home_: you'll get the full history of that particular branch
<jelmer> mw-home_: I'll update the FAQ
<mw-home_> jelmer: wow.
<jelmer> mw-home_: assuming you used "bzr branch" and not something like "bzr co --lightweight"
<mw-home_> jelmer: I did bzr branch.
<mw-home_> And so now, can I use bzr commit to do local commits, and bzr push to put stuff into SVN?
<jelmer> mw-home_: yep
<mw-home_> I wish there weren't so many competiting source-control projects.  it's intimidating for people that don't want to do a lot of research.
<arnetheduck> jelmer, dato, thanks for the help! (In my case, I can make it tag correctly by not using the revision of the first common tag/trunk ancestor but the revision that matches the svn revsion of the tag -1)
<jelmer> arnetheduck: cool
<jelmer> arnetheduck: Any chance you can link to your script on the wiki
<jelmer> arnetheduck: It may be useful to others (although hopefully we'll have a more structural solution soon)
<arnetheduck> jelmer, I can paste it on the wiki if that's ok? I have no good web host to put it on...
<arnetheduck> jelmer, it's pretty crude too, I really don't like bash scripting and consequently I suck at it...
<arnetheduck> jelmer, last questing, is there a good way of finding the bzr revid of the last revision on trunk that preceded the revision of a branch?
<arnetheduck> jelmer, in other words, if I made a tag on svn revision 501, is there a good way of finding the last revision on trunk before 501 (500 in my case since I only commit to trunk)?)?
<mw-home_> To pull in from svn into bzr, since I did a bzr branch, do I need to do a bzr pull?
<james_w> yep
<mw-home_> ignore me.  i'm trying it out.
<mw-home_> it worked!
<mw-home_> bzr seems great so far.
<Manu_> I would like to know how to specify the drive letter with the file:// protocol under windows
<mw-home_> Thanks to everyone that has helped me out.  I now know how to use bzr to make local commits and to still use svn.  This is a really nice set up.
<awilkins> jelmer: I now have a working debug build of Python, but joy of joy, it can't seem to load Pyrex modules
<awilkins> jelmer: Maybe I should rebuild them with the compiler I used to build the python
<james_w> Manu_: I don't know I'm afraid, have you tried file:///c:/whatever?
<jelmer> awilkins: Ouch
<awilkins> jelmer: Par for the course, I fear
<jelmer> awilkins: Is the difference so big between the code generated by differnet compilers on windows?
<awilkins> jelmer: Well, the distutils build_ext stuff refuses to build unless you have the same compiler that Python was built on, so I presume there is a good reason
<Manu_> james_w: yes it works i forget to add an extra /
<awilkins> jelmer: Damn, damn, damn. The modules built with VC8 (after inserting enough into the registry to convince distutils that I had it installed...) but they still don't load
<awilkins> jelmer: Maybe if I put the plugin folder on the pythonpath
<tca> When I install bzr in my home dir on line with  "--home ~", is it only bin/bzr and python/bzrlib that needs to be deleted to uninstall?
<tca> I'm having seeing this (http://www.pastebin.org/24908) when running bzr log with bzr 1.3, and want to completely reinstall before bugging people more.
<tca> "bzr log --long" fails with the error mentioned above, but with --line or --short it works ok.
#bzr 2008-03-23
<Rhamphoryncus> oi, busy day
<Rhamphoryncus> <jelmer> Rhamphoryncus: you may be able to use rebase or replay to replay the changes your local branch has on top of the new upstream branch
<Rhamphoryncus> no rebase or replay commands.. newer version only perhaps?
<jelmer> Rhamphoryncus: plugin
<Rhamphoryncus> ah
<Rhamphoryncus> rebase --help hurts my brain.. and makes me paranoid that it'll mess with my original tree, not just my new tree
<Rhamphoryncus> hrm.  Make a new branch of my old tree, cd into that, then rebase to my new upstream source?
<jelmer> Rhamphoryncus: yeah
<jelmer> you would have to specify what to rebase exactly and onto what revision
<threeve> Is there any documentation for the cbranch feature of bzrtools other than `bzr help cbranch`?
<ubotu> New bug: #201609 in paramiko "python-paramiko should support a shell alias for "ssh"" [Undecided,Invalid] https://launchpad.net/bugs/201609
<Rhamphoryncus> jelmer: it's saying the knit repositories are not compatible
<Rhamphoryncus> I should probably accept the loss of the history and just do a diff
<jelmer> Rhamphoryncus: You probably need to upgrade one of the repositories to a newer format
<jelmer> Rhamphoryncus: Probably your old one - try "bzr upgrade --rich-root-pack"
<Rhamphoryncus> given that I only updated bzr a few days ago, that's quite possible :)
<Rhamphoryncus> that failed too.  http://rafb.net/p/JSdbyl15.html
<jelmer> Rhamphoryncus: Hmm, I'm not sure what could be causing that
<jelmer> Rhamphoryncus: please file a bug
<Rhamphoryncus> hum.. top of the list of most frequently reported bugs.. "upgrading to rich-root-pack fails"
<Rhamphoryncus> heh, although that bug report has been idle for months, one of the bug reports has a link to a thread from 2 days ago
<ubotu> New bug: #205416 in bzr "bzr del is missing.  Alias bzr del to bzr remove." [Undecided,New] https://launchpad.net/bugs/205416
<NfNitLoop> del?  bah. :p
<arnetheduck> hi, I just pushed a bzr branch I created with svn-import to launchpad, and now I wanted to branch it, but doing "bzr checkout bzr+ssh://arnetheduck@bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk dcplusplus -v" gives me bzr: ERROR: Repository KnitPackRepository('file:///home/arnetheduck/src/dcplusplus/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://arnetheduck@bazaar.launchpad.net/%7Edcplusplus-team/dcplusplus/trun
<arnetheduck> k/.bzr/), any ideas?
<Peng> arnetheduck: You're probably trying to branch it into a non-rich-root repo.
<arnetheduck> Peng, I'm trying to branch it into a fresh directory
<Peng> arnetheduck: Run "bzr info".
<arnetheduck> bzr: ERROR: Not a branch: "/home/arnetheduck/src/".
<bob2> bzr co of rich root branches is borked
<Peng> Oh.
<bob2> since it uses the bzr default branch format, which is non-rich-root-comparible
<arnetheduck> Peng, and afaict, there's no way to specify repo format with co
<bob2> bzr init-repo repo ; bzr co bzr+ssh://arnetheduck@bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk repo dcplusplus -v
<bob2> er, bzr init-repo --rich-root-pack repo
<arnetheduck> bob2, any way of avoiding the extra level of directories and avoid having a shared .bzr in /src/?
<bob2> well, you could branch it then bzr reconfigure --checkout
<arnetheduck> bob2, a checkout, that's a branch + bind, right?
<bob2> think so
<Peng> Yeah.
<arnetheduck> should I report a bug?
<bob2> if no one else has, but it is pretty well known
<Peng> Nice, "bzr missing" doesn't use lots of RAM when the branch is missing 6000 revisions. :)
<ubotu> New bug: #180128 in bzr-svn "Cannot push to a branch `svn cp'ied` (dup-of: 145171)" [Undecided,New] https://launchpad.net/bugs/180128
<thekorn> hi, if any moderator of the bazaar ML is around today, can you please moderate my last mail, thank you!
<tca> New bug: https://bugs.launchpad.net/bzr/+bug/205564  Do you think it is safe to use bzr 1.3 on my repo?
<ubotu> Launchpad bug 205564 in bzr "bzr log fails with KeyError: 'null:'" [Undecided,New]
<ubotu> New bug: #205564 in bzr "bzr log fails with KeyError: 'null:'" [Undecided,New] https://launchpad.net/bugs/205564
<andrea-bs> tca: it only fails to show the log, why shouldn't be safe?
<tca> just asking :-)
<andrea-bs> tca: it was to know if I was missing something ;)
<ubotu> New bug: #205579 in bzr "bzr checkout doesn't work with rich-root-pack" [Undecided,New] https://launchpad.net/bugs/205579
<grubber> anyone have any advice (beyond whats already in wiki) on getting bzr-svn working for Mac?
<Odd_Bloke> grubber: Describing the problems you're having would probably help focus any such advice. :)
<grubber> Odd_Bloke: well, i tried the instructions on the wiki (but had to change libtool to glibtool in the Makefile to get swig-py to compile), but when i ran 'bzr plugins', it crashed hard. killed my terminal session.
<Odd_Bloke> grubber: Is there anything in ~/.bzr.log?
<grubber> Odd_Bloke: No. 'bzr plugins' got to the svn plugin and tried to load it, and then killed my terminal session. it gave a message that suggested the python library was mismatched
<grubber> im not really sure where to even begin on that
 * Odd_Bloke doesn't know, sorry.
<Odd_Bloke> jelmer might be able to help...
<grubber> Odd_Bloke: Alright. Thanks anyway! im really excited about trying out bzr but i'll just have to wait until i get to my windows machine at work.
<awilkins> grubber: You might want to grab the pyrex branch and see if you can get the bindings to build on Mac
<awilkins> They aren't complete yet but they have promise
<grubber> awilkins: ok. im not sure where that is, but i can try that next. im using fink to build the svn 1.4.3 bindings... and ill try the plugin against that. maybe that will work.
<awilkins> grubber: you go into the plugin folder and execute setup.py with the build_ext argumnet
<awilkins> On windows it's a pain in the butt :-)
<awilkins> You have to really fiddle to get them building
<awilkins> But I think posix style platforms are probably better off
<grubber> the plugin folder of which source?
<awilkins> The svn plugin
<awilkins> Let me hunt out the branch
<awilkins> Note that they arent finished but they will probably be better than the SWiG binding when they work
<awilkins> http://people.samba.org/bzr/jelmer/bzr-svn/pyrex/
<awilkins> Seeing how they build on Mac would be instructive
<grubber> ok... im checking them out now
<jelmer> awilkins,grubber: The pyrex bindings don't work yet
<jelmer> So unless you're interested in bzr-svn development there's no point in trying them out at this point
<grubber> jelmer: ok. well, ill try the svn 1.4.4 bindings. you think those will work with bzr-svn?
<jelmer> grubber: Only if you apply the patches linked from the wiki
<grubber> jelmer: I'll give them another shot. I tried the Mac instructions on the wiki, and it didnt work for me (for one, I had to change 'libtool' to 'glibtool' in the Makefile), but when i finally ran 'bzr plugins', it crashed the whole terminal session
<arnetheduck> hi, assuming I have a shared repo with some branches under it, if I rm -rf the branch, will the shared repo be cleaned at some point? when?
<james_w> arnetheduck: only when you branch the branches in to a new shared repo and then nuke the old one.
<arnetheduck> james_w, so if I for example branch a remote repo, do some modifications, push them and remove the branch, my shared repo will grow and never recover?
<james_w> arnetheduck: correct, unless you do some cleaning up.
<arnetheduck> what I'm thinking about is whether to keep a single shared repo in my $HOME/src folder, or keep each project separately...
<james_w> I keep each project separately, but I know that some people just have one.
<arnetheduck> and there's no bzr zap equivalent that kills a branch and removes it from the storage (something like zap but for heavy branches)?
<james_w> I think there was an experimental one written at some point.
<james_w> it's a dangerous operation though.
<arnetheduck> james_w, I have to similar projects that both keep a copy of boost (large c++ lib) so it would be beneficial to share the two, but I'm not sure how long the benefit would last space-wise...
<arnetheduck> james_w, thanks for the help  anyway, I'll keep them separate until I learn the quirks of bzr better =)
<james_w> no problem
<grubber> jelmer: here is the exact error i get (after following the instructions on the wiki): "Fatal Python error: Interpreter not initialized (version mismatch?)
<grubber> "Abort trap"
<jelmer> grubber: I guess that could mean the python subversion bindings were linked against the wrong version of python
<grubber> jelmer: ok.. ill see if i can narrow down which python it linked against. i installed 2.5.2 recently, and maybe its not resolving consistently
<grubber> jelmer: well, i cant find it. thanks for your help. ill try again in the next version!
<luislavena> does anyone have problems branching svn branch?
<ubotu> New bug: #205636 in bzr "Can't add file in subdir if changing subdir from file to dir (traceback if entry.name in parent.children) " [Undecided,New] https://launchpad.net/bugs/205636
<jelmer> luislavena: what problems are you seeing?
<luislavena> jelmer: sorry for the noise, is a 1.3 vs bzr-svn 'hardlink' issue...
<luislavena> (found that after looking at lauchpad).
<jelmer> luislavena: bzr-svn should already be warning you it is out of date
<luislavena> jelmer: yep, didn't noticed since was switching windows... it is fixed in trunk?
<jelmer> luislavena: in the 0.4 branch
<luislavena> jelmer: is safe to branch from it now? or is on state of flux? :)
<jelmer> luislavena: it's always in flux - it may be safer to check out the 0.4.9 branch
<luislavena> jelmer: wow, 0.4.9, and just installed 0.4.8 :-P
<luislavena> ;-)
<luislavena> just kidding, let me try.
<luislavena> jelmer: bzr: ERROR: No such file: 'http://people.samba.org/bzr/jelmer/bzr-svn/.bzr/repository/packs/6fb82431054b11a5d628eeca64a8542c.pack'
<jelmer> luislavena: please try again
<jelmer> I was pushing to the repository
<luislavena> oh, over dumb protocol or running bzr+ssh?
<jelmer> bzr+ssh
<luislavena> in case I want to create a shared repository for a svn branch, which format the repo must be?
<dato> luislavena: rich-root or rich-root-pack
<luislavena> dato: thank you, was thinking on it but wasn't sure.
<wjl> In cvs, svn, and hg, if I want to update my working tree to a specific revision, I use 'cvs up -r REV' or 'svn up -rREV' or 'hg up -rREV'. In bzr, there is no way to do 'bzr up' to a specific revision (that I know of), so I have to do something much more awkward, like 'cd ..; bzr branch -rREV a b' plus manual copying files around, etc. I am I missing something? Is there a easy way to do the equivalent of 'up -rREV' in other VCSs in bzr?
<dato> wjl: if you just want the working tree updated, revert -r REV
<wjl> dato: well, that will work well most of the time, I suppose. One problem is that it then marks everything as modified. I'm used to being able to use 'up -rREV' from most other VCSs, and having it know the difference between files that are up-to-date to a specific revision, vs. local modifications...
<dato> in that case, I think there's a bug about update not supporting -r
<dato> there is also pull --overwrite ., but you can make revisions inaccessible for that, so be very very careful
<wjl> dato: hmmm... just played with pull --overwrite and I don't think that's what I want. Maybe I will go ahead and file a wishlist bug about update -r. I think revert will work well enough in the meantime, and branch -r still has the right semantics, it just is harder to use
<wjl> looks like it's already filed as #45719
<wjl> although, according to the bug report, it was slated for inclusion for 0.13 (yikes!) but got dropped. =(
<dato> ubotu: #45719
<ubotu> Sorry, I don't know anything about 45719 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<james_w> bug #45719
<ubotu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719
<dato> ah, thanks james_w
<james_w> np
<wjl> (the fix is only committed to an abandoned branch, unfortunately)
<wjl> thanks for the discussion. I'll be content for now that it's a known bug and I have two workarounds (revert -r and branch -r).
<arnetheduck> hi, anyone recognises why I'd get "  File "/usr/lib64/python2.5/site-packages/bzrlib/plugins/svn/commit.py", line 510, in commit
<arnetheduck>     assert self._new_revision_id is None or self._new_revision_id == revid
<arnetheduck> " when pushing a change to an svn repo after importing that repo to bzr, making a bzr commit and then bzr push to the svn repo?
<Peng> arnetheduck: Up-to-date bzr and bzr-svn?
<arnetheduck> bzr 1.3, bzr-svn 0.4.8
<arnetheduck> here's the full log: http://pastebin.ca/954209
<Peng> jelmer: bzr-svn problem ^
<arnetheduck> Peng, jelmer: more info: I imported the svn repository using svn-import, made a single commit to the bzr branch, made a single push back to the svn repository. looking at the svn repo, it seems that the push succeeded (at least partially) because the contents of the bzr commit are present in svn
 * Peng shrugs.
<Peng> I don't know bzr-svn.
<Peng> Hopefully sorry-for-pinging-you-jelmer will be here soon.
<arnetheduck> Peng, hehe, I've been on to him ever since I started my little experiment with bzr-svn yesterday =)
<Peng> Me too, since I started importing random projects with bzr-svn last week. :P
<awilkins> I also pester him a great deal
<awilkins> Maybe we should club together and buy him a cake :-)
<Peng> Sounds good to me. :)
<mw-home> Hi -- I just started using olive and I really like it.  However, is there any way to get it to show side-by-side diffs?
<mw-home> Is there some other visual diff program for linux that people like?
<Peng> I think I found KDiff3 tolerable.
<abentley> There's also Meld
<mw-home> abentley: Meld?
<Peng> Oh, right, Meld. I don't think I tried that.
<abentley> mw-home: Yes.  Most distributions have it.
<mw-home> anyone in here use anything but the command-line bzr tool?
<mtaylor> nope
 * mtaylor is helpful
<mw-home> I don't really understand my options for sharing my branch with other people on the internet.  Is there a way to offer my repository over HTTP?
<rexbron> hello, I am trying to work with a branch, but am getting this (http://pastebin.ca/954268) error. The thing that confuses me is that the branch is not in a repo
<radix> rexbron: all bzr branches have a repository. you're probably thinking of *shared* repositories
<rexbron> radix: ok, I suppose then I need to do what it says and lock the branch
<radix> rexbron: if you don't create a branch inside of a shared repository, then the repository is just right next to the branch
<radix> rexbron: I don't really know anything about that particular error. what operation are you trying to perform?
<rexbron> I am using bzr-builddeb to automate the creation of debian source packages
<andrea-bs> rexbron: could you please give the complete traceback and the command you used?
<rexbron> andrea-bs: sure
<Peng> mw-home: Push it to some web server (over sftp or bzr+ssh if bzr is installed on the server)?
<Peng> mw-home: If it's an open source project, you could also host it in Launchpad. https://launchpad.net/
<rexbron> andrea-bs: http://pastebin.ca/954275
<andrea-bs> thanks rexbron
<yacc> mw-home: just push it to a place that is accessible via http
<rexbron> andrea-bs: It might be worth while to mention that I am using bzr 1.0
<mw-home> Peng, yacc: I can't use launchpad.  I do have a webserver that I can make an ssh connection to.  Do I just run a checkout on the webserver?
<Peng> mw-home: Just push to it.
<andrea-bs> rexbron: are you sure the script is well formed?
<Peng> mw-home: "bzr push --remember sftp://me@myserver/var/www/bzr/repo/branch" or whatever.
<rexbron> andrea-bs: It was working several weeks ago
<mw-home> Peng: am going to try this out
<rexbron> and I have not made and significant changes to the code
<Peng> mw-home: Why can't you use LP?
<yacc> mw-home: No, you push via ssh to some place that happens to be accessible per http too.
<andrea-bs> rexbron: maybe the output of `ls .bzr/repository/lock` would help
<mw-home> I can't use LP because I'm not working on free software (GASP).
<rexbron> andrea-bs: the lock dir is empty
<rexbron> (which might make sense
<andrea-bs> rexbron: hehe, right :)
<Peng> mw-home: Oh, ok.
<Peng> mw-home: (You traitor!) :P
<rexbron> andrea-bs: I can try just running bd from the dir itself and see if I get the same traceback
<mw-home> Peng: I'm running that push now.  Looks good so far.  Now will others be able to run a checkout by pointing to that http:// location?
<Peng> mw-home: Yes.
<Peng> mw-home: I hope you created a shared repo.
<mw-home> Peng: what is a shared repo?
<andrea-bs> rexbron: ok, could you tell me also when exactly is "blender-svn.py" called?
<Peng> mw-home: All of a branch's data is stored in a repository (repo), in the same directory as the branch. But when you have two related branches, having two copies of the data wastes a lot of space. If you run "bzr init-repo" in the parent directory to create a shared repo, all of the branches below it will hold their data their, to prevent duplication and wasted space.
<rexbron> andrea-bs: If I do not explicetly set the orig-dir option it will crash with the same traceback, therefore I must not be passing that option correctly in the script
<radix> Peng: oh, cool, does "init-repo" now automatically relocate and merge data from branches in existing subdirectories
<radix> ?
<Peng> radix: No.
<radix> oh, woops.
<Peng> Yeah, I should've said *new* branches will put their data there.
<Peng> Someone should add support for that to "bzr reconfigure" or something.
<mw-home> Peng: OK, thanks for that explanation.  The time to make a shared repo would be way before I did the bzr push sftp:, right?  It would have been when I had set up my original repo?
<Peng> mw-home: Yeah, it would've been before the push.
<mw-home> So, since I probably didn't make a shared repo, both my local repo and the copy on the webserver have 100% of the history.
<andrea-bs> rexbron: can you try using an absolute path?
<Peng> mw-home: A shared repo is useful for multiple branches on the same machine, not different machines.
<rexbron> andrea-bs: It was ulimately my fault, I was specifying the wrong dir. I am still intrgued as to why it crashes with that rather (Imo) non-obvous traceback
<mw-home> Peng: so, why did you say you hoped I made a shared repo?
<Peng> mw-home: In case you have multiple branches on the server in the future.
<mw-home> 10-4
<andrea-bs> rexbron: if you think the error can be improved (I think so), you can report a bug ;)
<rexbron> Sure :)
<andrea-bs> rexbron: when you have done, could you please give me its number so I'll try to make a patch for it, please?
<rexbron> sure
<lamalex> Hi, is there a way to see patches that have been submitted to a branch if you're not the branch owner?
<andrea-bs> rexbron: thanks ;)
<andrea-bs> lamalex: is it a question about launchpad?
<lamalex> about bazaar
<lamalex> I pushed a patch up to a bazaar branch
<lamalex> but I reformatted my hd and didn't save the patch I wrote
<lamalex> Can I pull that patch back down to apply it to the code on my pc
<lamalex> The code is hosted from launchpad, so sort of
<andrea-bs> lamalex: sorry but I can't understand: in bzr you can send commits (there are not distinctions with patches) and there are not branch owners
<lamalex> sorry, I'm new to bzr, used to svn
<lamalex> I did a brz push of a patch to a bzr mirror on launchpad
<lamalex> I lost my local copy of the patch I pushed
<lamalex> can I pull down what was pushed somehow?
<lamalex> the .patch file I pushed
<andrea-bs> there's "bzr pull"
<lamalex> will that pull down patches and whatnot?
<mw-home> when to use bzr checkout vs bzr branch when making a new working copy of a project?
<andrea-bs> lamalex: I didn't understand well your situation so I'm not sure this will help you
<radix> mw-home: use checkout when you want commits to immediately be sent to the remote branch.
<andrea-bs> lamalex: you can try with this command, if it doesn't work, give me some links ;)
<radix> lamalex: "bzr pull" will pull revisions to another branch into your branch. It only works if the branches haven't diverged in development.
<radix> erg, I meant "pull revisions *from* another branch"
<mw-home> radix: that makes sense.  so, bzr branch will let me commit locally, and then use bzr push to commit to the remote repo?
<radix> mw-home: right.
<thekorn> hi, if any moderator of the bazaar ML is around today, can you please moderate my last mail (send yesterday), thank you!
<mw-home> I just ran a bzr checkout, and I want to know the revision number of the branch.  bzr info doesn't show it.  How do I find that out?  bzr log --limit 1?
<radix> mw-home: bzr revno
<mw-home> by the way, i just read about bzr aliases.  Those are a really nice trick that are sorely missing from svn.
<mw-home> radix: thanks for the tip.
<rexbron> andrea-bs: small point that I just encountered. builddeb should raise an exception (during the run() method) when there are changes to the working tree. It prints an error message to stdout but that is not useful for if one is trying to use it in a script
<mw-home> can anyone tell me how to use vimdiff with bzr diff?
<jelmer> re
<jelmer> arnetheduck: still there?
<mw-home> How do I push stuff back into my parent branch without having to type out the whole URL?
<rexbron> mw-home: if you have pushed to it before, you do not need a url
<Peng> mw-home: You use "push --remember $url", then you won't have to supply it in the future.
<mw-home> Peng, rexbron: thanks.
<mw-home> So, anyone in here running ubuntu?  I can't find the 1.3 bzr package for ubuntu on that LP site.
<Peng> mw-home: Yeah, the PPA takes a few days to get updated.
<mw-home> anybody in here use bzr-svn? it seems that after putting a bzr tag on my bzr repository, i can't push it back into svn.  I'm using bzr 1.0, though, so maybe this is old news.
<jelmer> mw-home: bzr-svn won't set tags in svn yet, if that's what you mean
<jelmer> mw-home: bzr-svn 0.5 will hopefully support this
<mw-home> jelmer: bzr-svn is a really useful tool though.
<arnetheduck> jelmer, I'm here for a minute now...
<jelmer> mw-home: thanks
<jelmer> arnetheduck: you were having trouble with bzr-svn earlier?
<mw-home> when should I use bzr merge to update my branch and when should I use bzr pull to update my local branch?
<Peng> mw-home: Use merge when the branches have diverged.
<arnetheduck> jelmer, yes, did you see my posts?
<Peng> mw-home: Don't worry, bzr will do the right thing when you try the wrong one.
<Peng> mw-home: (Say the history of your branch is A -> B -> C, and the remote branch committed something new, so it's A -> B -> C -> D. You'd use "pull" to get D.)
<mw-home> Peng: thanks!
<Peng> mw-home: (But if you've both committed things, so you have A -> B -> C and the remote has A -> B -> D, the branches have diverges, and you'll need to merge.)
<Peng> diverged*
<jelmer> arnetheduck: looking at them now
<jelmer> arnetheduck: this may be a timing issue
<jelmer> arnetheduck: please file a bug
<arnetheduck> jelmer, I will...sf.net servers are notoriously slow, for the record
<arnetheduck> jelmer, should I worry about the consistency of either of my repositories (svn, bzr)?
<jelmer> arnetheduck: sf.net? You mean launchpad?
<jelmer> arnetheduck: no, this should have no consequences for the consistency
<arnetheduck> jelmer, no, I was pushing my changes from my bzr branch to an svn repo on sf.net
<arnetheduck> jelmer, the bzr branch being on my hard drive, no launchpad involved...
<Peng> jelmer: (Out-of-date by a day or two, but..) if I try to do an svn-import and a branch of the same svn repo at the same time, SQLite tracebacks with an OperationalError about the database being locked. That could be handled better..
<Peng> jelmer: Traceback: http://paste.pocoo.org/show/35178/
<arnetheduck> jelmer, bug 159538
<ubotu> Launchpad bug 159538 in bzr-svn "crashes when pushing changes on top of base revision that's present twice" [Undecided,Incomplete] https://launchpad.net/bugs/159538
<jelmer> Peng: There's an open bug about that
<Peng> jelmer: Ok.
<jelmer> Peng: There's not much we can do about other than not use sqlite I think
<Peng> jelmer: Yeah, it could happen at any time, right?
 * Peng notices that he's like 30 revisions behind on bzr-svn.
<jelmer> Peng: if you have two processes using the same svn repository it's very likely to happen, yes
<Peng> Oops, traceback.
<Peng> jelmer: Yeah, I was hoping it would wait for a bzr lock.
<Peng> Maybe I shouldn't update bzr-svn's source code while it's running, eh?
<jelmer> Peng: There is no bzr lock that could be used here
<jelmer> Peng: you could be pulling from a subversion repository into two independent bzr branch
<Peng> This time it was the same bzr repo, so I was hoping that would kick in first.
<Peng> You could implement your own locking, I suppose.
<Peng> But I guess SQLite's works well enough; it's just ugly.
<Peng> jelmer: Wait, if you removed the on-disk branch property cache, that means there's useless data in the database now, right?
<jelmer> Peng: yep
<Peng> ...Ok. :)
<ubotu> New bug: #159538 in bzr-svn "crashes when pushing changes on top of base revision that's present twice" [Undecided,New] https://launchpad.net/bugs/159538
#bzr 2009-03-16
<yacoob_> Hello there. Any information about 1.13 packages for osx coming soon?
<lifeless> yacoob_: the mac folk are pretty responsive, so I'd expect something within a day or two
<yacoob_> hit #335528:
<yacoob_> This report is public
<yacoob_> erp.
<yacoob_> hit bug#335528, looked for any other version out there available.
<lifeless> bug 335528
<ubottu> Launchpad bug 335528 in bzr "bzr status: TypeError: run() got an unexpected keyword argument 'verbose' (dup-of: 334202)" [Undecided,New] https://launchpad.net/bugs/335528
<ubottu> Launchpad bug 334202 in bzr "internal error occured on bzr status" [Undecided,Fix released] https://launchpad.net/bugs/334202
<lifeless> yacoob_: upgrade your loom package
<lifeless> yacoob_: you can also run 'bzr --builtin status' or 'bzr --no-plugins status'
<yacoob_> ha, let's see.
<thumper> bzr shelve rocks!
<yacoob_> btw, I must be tired, I haven't noticed the 'dup-of' line describing the problem in detail... :)
<yacoob_> hehe. Good thing: bzr gives you many possible models of development, to pick one that suit your needs. Bad thing: bzr gives you many possible models of development, and you need to worry which one to choose, if you don't have that much experience in the area... :)
<Peng_> At least it's easy to switch models.
<yacoob>  True... I think. :)
<yacoob> for the moment I'm playing with a small pet projec, that only I work on... but I don't like that much idea of keeping my source in just working dir
<yacoob> so I've just pushed whole branch to external drive... and now if something happens to my copy, I'll just pull from there
<yacoob> hm, assuming I'm working with a centralized model and do some local commits - would later commit push everything as a single change, or will I have whole history pushed together?
<lifeless> yacoob: it has all the history
<yacoob>  any way to "crunch" it down to single change?
<lifeless> yes - its in the user guide. May I ask why though?
<yacoob> no real reason, just looking at the possibilities
<lifeless> ok
<lifeless> so our log shows it crunched down
<lifeless> even while the full detail is preserved under the covers
<yacoob> I wonder how painful a checkout is, when the history is large... assuming we do want the history
<lifeless> jml: so, we can do push of a revision in 18 seconds now
<lifeless> jml: which makes 11seconds a rather large fraction :P
<Peng_> It takes 18 seconds to push 1 revision? What are we talking about?
<lifeless> Peng_: its not 36 for two, if thats concerning you :P
<jml> lifeless: I was looking at our data on this today
<lifeless> Peng_: 'bzr push' in an existing branch with one new commit on it
<lifeless> Peng_: via bzr+ssh
<spiv> Peng_: pushing 1 new revision to an existing branch in a shared repo via bzr+ssh, including SSH handshake, from Sydney->London.
<spiv> 18s, but also 18 HPSS calls, co-incidentally.
<Peng_> Oh, from Sydney to London.
<spiv> Yeah, that part is rather key :)
<mwhudson> spiv: 18s includes ssh set up time?
<spiv> Also, there are actually two SSH handshakes there, it was a push to people.ubuntu.com.
<spiv> mwhudson: yes.
<mwhudson> spiv: oh good :)
<spiv> mwhudson: if launchpad had 1.13 I'd use it ;)
<mwhudson> spiv: bazaar.staging.launchpad.net will soon enough
<mwhudson> staging can be really slow for other reasons though
<spiv> mwhudson: that would be lovely.
 * fullermd frowns.
<fullermd> Is this redirect of distfiles to launchpadlibrarian new?
<lifeless> fullermd: I don't think so; its to prevent XSS
<jml> is there a builtin command that does 1 hpss call?
<lifeless> jam has one in a plugin I think
<jml> 1 r/o call preferably
<fullermd> Hm.
<lifeless> https://code.edge.launchpad.net/~bzr/bzr-hello/trunk
<jml> lifeless: thanks
<fullermd> It's breaking the port download, which explicitly doesn't follow redirects   :|
<fullermd> Never did that before, even earlier this week.
<lifeless> oh. have ports changed then ? ::P
<jml> whomp!
<lifeless> ?
<fullermd> I don't think so...   I'm checking as fast as I can swallow the bile from running cvs ann...
<jml> lifeless: bzr hello stacktraces
<lifeless> ouch
<spiv> I have one too, https://launchpad.net/bzr-ping :P
<fullermd> Not in a couple years at least...   the line setting that arg hasn't been touched since 07.
<spiv> jml: and mine doesn't backtrace ;)
<fullermd> And it worked earlier this week when I tested the RC.
<lifeless> AFAIK there hasn't been a rollout this week
<lifeless> spm: ^
<lifeless> fullermd: given today is monday and all
<jml> spiv: thanks.
<fullermd> Are the librarian links stable (or stable enough 'till the next release)
<fullermd> It was probably Wed or Thur when I did it...
<fullermd> mtimes say Thurs.
<spiv> jml: FWIW I just got 6.477s to bzr ping bzr+ssh://bazaar.launchpad.net/
<jml> spiv: that's roughly what I get.
<jml> (5.6, 5.8, 6.2)
<lifeless> jml: how long do you get for 'bzr ping lp:bzr'
<spiv> fullermd: which librarian links?
<jml> using the lp: url takes it up to 7.6, 7.8, 8.0
 * igc lunch
<fullermd> The 302 to launchpadlibrarian.net for the release tarball.
<spiv> Which 302?
<spiv> (I think I'm missing some context)
<jml> lifeless: so, uhh, I guess that means that launchpad page loads are expensive :P
<lifeless> fullermd: what url are you giving ports today
<lifeless> jml: but but but these are not full pages, they are ajaxy, they must be faster right?
<lifeless> oh damn, there goes my sarcastic side again. Meep
<fullermd> http://pastebin.ca/1361926
<fullermd> (does the same with code.launchpad, which is what bzrtools is using; it's failing now too)
<spiv> fullermd: ah, on Launchpad, as opposed to bazaar-vcs.org or something
 * jml files a bug on bzr-ping
<fullermd> Well, last I heard release tarballs weren't going on b-v.o anymore anyway   :)
<jml> oh, it doesn't use lp as its bug tracker
 * jml uses IRC instead
<jml> spiv: ping should also be able to send N hpss requests
<lifeless> jml: thats just a bad default, assume  it uses it
<spm> lifeless: we did have a rollout to crowberry on friday. Was a CP for jml/mwh's bzr connections fix. Is possibly related?
<lifeless> spm: what else was included though? the main app is at issue, not code hosting per se
<poolie> hi all
<spiv> fullermd: AFAIK /bzr/1.13/1.13/+download/bzr-1.13.tar.gz should be a stable URL.  Also, the target of that redirect should exist for as long as the Launchpad web UI offers bzr-1.13.tar.gz for download.
<spiv> fullermd: does that tell you what you want to know?
<lifeless> jml: ping 'fixed' to use lp
<fullermd> I guess...   I'll just have to resolve it manually and use the librarian links.
<fullermd> Port fetch explicitly disables redirect-following.
<lifeless> fullermd: how does port fetch handle sf?
<spiv> It would be nice if Launchpad served that data to you directly rather than giving a redirect.
<fullermd> It just lists the mirror explicitly.
 * fullermd grabs a random example.
<lifeless> fullermd: can you just turn it on for this, I mean, sha1 isn't trivially broken [yet]
<fullermd> Not really, no.
<spiv> Then using the librarian URL directly seems about the same.
<fullermd> I mean, I probably COULD override the fetch args in the port Makefile, but that's REALLY unfriendly to the layering.
<spiv> But ideally I think port fetch would rely on the checksum rather than lack of HTTP redirect...
<lifeless> fullermd: args = echo $args | sed -e ....
<lifeless> :P :] :>
<fullermd> Too late, due to make's makeage  :p
<fullermd> It does use a checksum to verify the file after download.  The comments suggest one reason redirects are flat disabled is because of sides that use a 302 to implement their 404's.
<lifeless> fullermd: ugh, breaking a standard to deal with broken sites
<lifeless> FAIL
<lifeless> turn it on, sites with 404 as 302 will get a sha fail, everyone wins
<fullermd> That's slightly above my paygrade   :p
<lifeless> [I appreciate its not trivial to do this, but really. HTTP Nazi hat on now]
<fullermd> Ah, there's where it started.  1.306, 1999-03-08.
<fullermd> Now I can avoid touching cvs ann for another 5 years, hopefully...
<AfC> I have today discovered that in Red Hat land they use the term "re-base" to mean upgrading the version of a package they are shipping to a newer (sometimes even latest!) release.
<AfC> This is exciting.
<lifeless> its analagous at least
<AfC> Well, seeing as how I never figured out what Git rebase did, nor how Bazaar's implementation of same worked, really, it's all the same to me :)
<AfC> I'm just pleased to hear that they do, from time to time, upgrade their packages.
<fullermd> Sounds like a scurrilous rumor to put you off your guard.
<AfC> fullermd: very likely
<AfC> fullermd: but still, given that it looks like I'm going to be building, deploying, and maintaining a largish enterprise installation on RHEL over the next few months, I'll happily take false hopes.
<Peng_> The more hope you have, the more you can be disappointed.
<AfC> I know. Isn't the universe a wonderful place?
<fullermd> Yeah.  I've tried crushing the spirit of a pessimist before.  It just has no flavor.
<lifeless> fullermd: did you add all-spice?
<fullermd> Nah, that's a little coarse for the usage.  Cumin and paprika, more like.
<fullermd> Ah, found What Changed to cause the redirect issue.  Pfeh.
<lifeless> fullermd: ...
 * lifeless shakes his mind reading gizmo, its bust
<fullermd> Upgraded by system over the weekend.
<fullermd> Which fixed a bug in fetch(1) that cause the "don't-follow-redirects" arg to have no affect on http_s_
<fullermd> And no effect, either.
<fullermd> Just goes to show, fixing bugs always screws things up...
<lifeless> :)
<lifeless> it also shows that the don't-follow-redirects setting wasn't affecting you :P
<fullermd> Yah.  It was only working on http.
<fullermd> Which didn't have any effect on grabbing bzr{,tools}, so it was masked.
<lifeless> I know
<lifeless> just saying, delete the setting entirely, it'll be fine :)
<fullermd> That promises a very long discussion.  I'm not sure I have the gumption to try and ram that through...
<BasicOSX> Looks like release announcement did not make it to -announce, someone needs to approve it?
<BasicOSX> sleep
<Kamping_Kaiser> Would this be enough information to file a bug with? its me trying to commit using bzr in an svn repo http://paste.debian.net/30664/
<Kamping_Kaiser>  /seems/ to be reproduceable - cd into svn dir -> try and commit -> segfault.
<lifeless> Kamping_Kaiser: sure, on bzr-svn please
<Kamping_Kaiser> lifeless, ok, thanks.
<lifeless> Kamping_Kaiser: jelmer will want your subvertpy version, platform (i386/adm64 etc) and libsvn versions I suspect
<Kamping_Kaiser> lifeless, ok, i'll be sure to include them. are bugs filed 'announced' here or should i link after filing it?
<lifeless> they aren't, because folk get mailed
<lifeless> spiv: LOL I broke the retry-tests by making packs much more efficient :P
<spiv> lifeless: :)
<spiv> lifeless: I was wondering what happened to your merge...
<lifeless> specifically I got rid of a reset() call in _refresh_data
<lifeless> so now it merges. hmm
<Kamping_Kaiser> lifeless, thanks for the help, bug is now filed.
<lifeless> Kamping_Kaiser: my pleasure
<lifeless> spiv: so, fixed by 'reset; refresh_data()' :P
<lifeless> spiv: hate this too-good code.
<lifeless> spiv:   File "/home/robertc/source/baz/integration/bzrlib/tests/test_remote.py", line 1934, in test_ok_with_real_repo
<lifeless>     client._calls)
<lifeless> AssertionError: not equal:
<lifeless> a = [('call', 'PackRepository.autopack', ('quack/',)),
<lifeless>  ('pack collection reload_pack_names',)]
<lifeless> b = [('call', 'PackRepository.autopack', ('quack/',))]
<lifeless> from bzrlib.tests.test_remote.TestRemotePackRepositoryAutoPack.test_ok_with_real_repo
<Peng_> That eliminated a round-trip?
<lifeless> Peng_: changed from a private interface to a public one, round trips are the same
<lifeless> Peng_: this is test fallout I fear
<lifeless> mock objects, your best friend, your worst enemy
<lifeless> spiv: do you want to see these test changes?
<lifeless> :!bzr diff | diffstat
<lifeless>  test_knit.py       |   34 ++++++++++++++++------------------
<lifeless>  test_remote.py     |   10 +++++++---
<lifeless>  test_repository.py |    1 +
<lifeless>  test_smart.py      |    4 ++++
<lifeless>  4 files changed, 28 insertions(+), 21 deletions(-)
<lifeless> spiv: no answer == land it :P so am
<spiv> lifeless: sorry, was busy thinking about pork like a tyrant day... :P
<spiv> lifeless: if it's just adjusting tests in obvious ways (e.g. I imagine that the test_remote fix was pretty trivial), then +1
<lifeless> spiv: mmm bacon explosion mmm
<lifeless> spiv: not entirely, let me pastebin the deed
<lifeless> http://paste.ubuntu.com/131855/
<spiv> lifeless: hmm, please adjust the test_remote change to append something like 'pack repository refresh_data' rather than reload_pack_names.  It's just an arbitrary string, but I'd rather it more-or-less described the direct action...
<lifeless> spiv: yeah. I'll have to land that later though
<spiv> lifeless: but otherwise it looks ok to me.
<CaMason> hi guys. Is there any nice way to do a visual diff on Windows? I have BeyondCompare installed, but using `bzr diff --using=BCompare.exe` gives me 1 file at a time
<SuperMMX> Hi, guys, I just upgraded to 1.13 to try the filtered view, but it seems that it has no effect at all. In my understanding, filtered view will only generated some part of the working tree, right ?
<SuperMMX> Will it only show the the contents in a directory DIR if I do "bzr view --name MyView DIR" ?
<lifeless> CaMason: I thought bzr had visual diffing builtin on windows
<CaMason> via the tortoisebzr thing? That doesn't work for me (64-bit)
<lifeless> SuperMMX: it currently only affects what the commands *do* not what is put on disk; also make sure you have followed ian's notes about it as it needs a in-development tree format
<lifeless> CaMason: oh :(
<CaMason> although bizarely, the icons do show up if I use a file browser within an application :o
<SuperMMX> lifeless: sure, the working tree format is upgraded to development-wt5.
<SuperMMX> lifeless: ... it seems that I misunderstand the feature totally  at first
<sabdfl> what's the best format for brisbane-core tests?
<SuperMMX> I thougth it will reduce the diskspace which is with very hight priority in my feature wishlist for bzr.
<lifeless> sabdfl: we're currently looking at gc-chk255{,-big}, not that you need to set NO_LABELS in the code to avoid parsing a lookup table that we're going to either remove or have partial-parsing on soon
<lifeless> s/not/note/
<SuperMMX> But I think it should not be very hard to add that function. It will be great to only work with a small set of files in the same tree.
<lifeless> gnight all
<spiv> lifeless: g'night
<spiv> lifeless: btw, with my patch landed, tests all pass with InterOtherToRemote removed
<Peng_> lifeless: Good night.
<mwhudson> Peng_: do you ever sleep?
<fullermd> Sleep is for wimps.
<fullermd> Happy, healthy, well-rested wimps, but wimps nonetheless.
<jml> so, my flatmate got a cold the day I got back from travel
<jml> I may well be cursed.
<Peng_> mwhudson: Disturbingly frequently.
<fullermd> Oh blah, merge --force is still broken.
<thrope> i have a bzr-svn co of a svn repo which contains a move (everything was moved into a sub directory). now bzr log on a file only gives entries up to the move, but svn log on the same file in a svn checkout shows the full history (including before the move)
<thrope> is there a way to get bzr to track the full history?
<thrope> (i thought bzr should handle renames well - git shows the full log correctly in a git-svn branch if i give it the --follow option, is there something similar for bzr?
 * SamB would suggest that thrope file a bug -- if only he were still here
<SamB> thrope: ah!
<SamB> file a bug, maybe?
<thrope> hi - sorry having some computer issues
<SamB> I'm pretty sure bzr-svn is supposed to handle that fine
<thrope> i thought so - but I thought i'd check first
<SamB> well, oh, but does SVN give the full log?
<thrope> yep
<SamB> good
<SamB> git isn't really an indication since it doesn't track renames ...
<SamB> ... it just figures them out after the fact
<Peng_> thrope: Is the repo public?
<thrope> yep
<thrope> http://pyentropy.googlecode.com/svn/trunk/
<Peng_> thrope: Ask jelmer (when he comes online) and/or file a bug.
<thrope> ok
<thrope> i'll wait for jelmer
<thrope> the file is trunk/pyentropy/pyentropy/pyentropy.py (I am just learning about python packages - it hink this will change)
<SamB> hehehe
<SamB> pyentropy.pyentropy.pyentropy?
<thrope> first one is just a dir
<thrope> because I keep something else in the repository
<thrope> guess it should be pyentropy/trunk/pyentropy/pyentropy.py
<wgrant> I don't think bzr-svn does do svn 'renames' at the moment.
<wgrant> As svn doesn't do renames.
<SamB> what else (besides the wiki) do you keep in the repository?
<wgrant> It copies and deletes.
<thrope> wgrant: it was a svn move
<thrope> another small module call femaxent
<wgrant> svn move is copy + delete.
<thrope> it is related
<Peng_> bzr-svn could detect copy+delete as a rename.
<wgrant> And bzr can't track copies.
<wgrant> It could.
<wgrant> There's a bug about it.
<SamB> I guess you should subscribe?
<thrope> yep trying to find it
<thrope> got it
 * SamB personally errs on the side of reporting Invalid bugs, on the theory that most Invalid bugs are actually problems with the documentation ;-)
<SamB> (or other code)
<SamB> thankfully, jelmer seems to agree with me so far
<thrope> also I was wondering if I can push two related bzr native branches into svn in such a way that they share history properly
<thrope> (ie donthave doubled up commits)
<SamB> thrope: did you try?
<thrope> I figured it would involve pushing up to where they diverged to one place is svn, doing an svn copy, rebasing the branches to that copy
<thrope> or something like that
<thrope> I tried the naive way - pushing them both to different dirs, but there was no shared history (all the common commits appeared twice in svn)
<Peng_> "bzr native branches"? Why deal with svn at all then?
<SamB> oh
<SamB> Peng: well ... is that any reason for it not to work?
<thrope> I thought you could store bzr branches in svn with bzr-svn
<thrope> started as a seperate thing, but now I want to put it in the main repo (which is svn)
<thrope> I guess it doesn't really matter about the repeated commits - I will just push the two branches
<thrope> but I wondered if it would be possible
<SamB> file a bug?
<thrope> its a question really
<thrope> i dont think it should work the naive way -  i think i have to push the common bits, then do a rebase or something
<SamB> I think maybe there should be a command for that?
<SamB> or at least commands to help
 * Peng_ goes to bed.
<Leonidas> bzr log --format gnu-changelog
<Leonidas> bzr log --format gnu-changelog
<Leonidas> bzr: ERROR: no such option: --format
<Leonidas> Well, something's broken with 1.13
<fullermd> Has log ever had a --format?  It's got a --log-format...
<spiv> fullermd: Not AFAIK.
<spiv> Leonidas: I think that's a typo in the NEWS file :(
<spiv> ISTR a patch on the list about it, but I guess it didn't make it in.
<Leonidas> ok.
<spiv> Leonidas: Leonidas it's bzr log --log-format gnu-changelog, as fullermd says.
<spiv> Leonidas: "bzr log --gnu-changelog" works too, as "bzr help log" says.
<spiv> lifeless: http://people.ubuntu.com/~andrew/bzr/simplify-interrepo-stack removes InterRemoteToOther and InterOtherToRemote and has all tests passing.
<spiv> lifeless:  2 files changed, 4 insertions(+), 78 deletions(-)
<spiv> lifeless:  :)
<Leonidas> spiv: yes, indeed.
<vadi2> How can I make it so when I merge and commit, the commit(s) message from the merged branch show up in the main one?
<jpds> vadi2: It does, as subcommits.
<vadi2> Where?
<vadi2> Ah, just lp is not displaying it
<vadi2> okay thanks
<jpds> eg, http://paste.ubuntu.com/131965/ - but yeah, LP doesn't show it.
<newz2000> Hi, can I add a bzr branch inside another project I'm working on which is also version controlled?
<newz2000> (bzr add seems to do nothing in this case)
<beuno> newz2000, right, it ignores any branches inside branches
<newz2000> is there a way around that?
<beuno> no, abentley is going to work on nested trees soon
<beuno> which is what you want
<newz2000> :-(
<newz2000> That'll be a cool feature when it's done.
<abentley> beuno: I've already started work, in fact.
<beuno> ah, that's even better!
<beuno> hi abentley
<abentley> beuno: hi
<lamont> when will https://edge.launchpad.net/~bzr/+archive/ppa have 1.13 (bzr and bzrtools)?
<Kobaz> you're killing me
<Kobaz> er
<Kobaz> wrong channel
<Kobaz> what's the recommended commit/push emailer plugin
<jam> vila: good evening
<vila> jam: hi ! How do you know I'm jetlagging :-)
<jam> I'm doing pretty good, all things considered
<jam> I managed to sleep on the plane at an appropriate time, and then stay up to ~9pm my first day back
<jam> So I'm probably 95% transitioned by now.
<jam> vila: I just remembered that we had talked about doing a phone call everyday
<jam> of course we missed the original time by about 3hrs, but I  wondered if you were still interested today
<vila> I couldn't resist and slept 16hours yesterday, yet, I fall sleeping looking the perfmeter while toying with parallelized selftest (truth is watching the 8 curves is pretty hypnotic)
<jam> :)
<vila> jam: not today, I'm abot to stop, but tomorrow certainly
<jam> ok
<vila> jam: regarding parallel selftest, lifeless sketch is working, some rough edges (unavailable feature and know failures are missed and the test suite doesn't seem to end)
<jam> wow....
<jam> good news for LP folks
<jam> I just did a test conversion of LP branch to CHK255-big
<jam> Orig source was 861MB, right after conversion, it dropped to 248MB, after doing "bzr pack" I'm down to 133MB
<vila> jam: wow, now *that* is significant  :-)
<jam> I'm running 'repo-details' to make sure it is all accurate, but yeah, nice results
<rockstar> jam, that's awesome.
<NfNitLoop> what's chk255-big?  :)
<jam> NfNitLoop: the 'brisbane-core' work we've been working on for the past 6-8 months
<jam> split-inventory + groupcompress delta compression + a specific page layout
<NfNitLoop> aah, cool.
<NfNitLoop> sorry, just eavesdropping and was curious. :)
<jam> yeah
<jam> Its something we'll probably be moving into a 'development' format in bzr.dev in the next month or two
<NfNitLoop> cool. :)
<jam> bzr.dev itself packed from something like 100MB down to ~25MB, IIRC
<jam> not quite as impressive, though still nice
<Tak> if I have credentials stored in authentication.conf, shouldn't bzr automagically use them when I try to branch or whatever?
<zsakr> I need to write a hook script that will notify me by email every time someone commits a file in /trunk. I already have the email part working, but I'm not sure how to make the conditional statement to check if the commit is in /trunk.
<jam> Tak: there may be times when using a user in a URL triggers the code that tries to use a password
<jam> I certainly agree it is a bug if you need user@, but it may be a workaround you can use
<Tak> I can't get it to use it with or without user@
<Tak> this is for sftp transport
<Tak> at least, I'm testing with sftp transport
<jam> Tak: well, if you are using openssh as your ssh provider (the common case), we have no way to pass it a password
<jam> you might try "BZR_SSH=paramiko"
<jam> for security, openssh uses a direct connection to your terminal to prompt for a password
<zsakr> jam: any idea?
<jam> zsakr: Can you just check the branch url?
<jam> if thebranch.base.endswith('/trunk') ?
<Tak> interesting
<jam> Tak: I would certainly recommend using ssh keys and an ssh-agent under those circumstances, rather than paramiko
<jam> but you can use a password if you prefer
<Tak> well, I'm attempting to use the authentication api generically - I just happen to be testing with an sftp transport because that's what I have on hand that's passworded
<Tak> it appears to fail with paramiko as well
<jam> Tak: did you use "export BZR_SSH" ?
<Tak> yeah, and the console output is different, signifying that it's not using openssh
<jam> Tak: I don't use it myself, so I'm not 100% sure how to configure everything. Though I know that http and ftp get more testing, since there aren't many alternatives there
<jam> I would have you chat with vila, since he implemented most of the auth work, but I think he stopped for today
 * Tak nods
<Tak> vila: ping ;-)
<rockstar> Is there a branch format register somewhere that will let me get all the current formats?
<beuno> man, bzr's progress bar is so awesome now
<LarstiQ> rockstar: bzrlib.bzrdir.format_registry?
<LarstiQ> rockstar: or specifcally branch formats?
<jelmer> 'evening beuno, larsitq
<jelmer> *larstiq
<rockstar> LarstiQ, anything I can iterate over will do.
<beuno> hey hey jelmer
<beuno> how's it going?
<LarstiQ> rockstar: [] ;P
<LarstiQ> hey jelmer, beuno :)
<LarstiQ> jelmer: I started an identi.ca account!
<beuno> jml, thank you again for lp-open
<beuno> hola LarstiQ!
<LarstiQ> beuno: and indeed, mbp deserves much kudos for the progress bars
<LarstiQ> rockstar: the thing is, every domain object (the big three) has it's own formats, and then a combination of those is also known as a format
<jelmer> beuno: pretty good, looking at finally putting that first bzr-git release out
<jelmer> LarstiQ: whoa
<beuno> jelmer, a lot of excitement around that
<LarstiQ> rockstar: so, for formats in that registry, bzrlib.bzrdir.format_registry.get('default').get_branch_format()
<LarstiQ> rockstar: but you might miss non-bundled branch formats
<rockstar> LarstiQ, is 'default' a format string?
<LarstiQ> rockstar: yeah, from the format_registry.keys() list
<LarstiQ> rockstar: if you are sure it is branch formats, and not repository or workingtree ones, I think only 6 and possibly 5 are 'current'
<LarstiQ> ie, bzrlib.branch.BzrBranchFormat{6,5}
<rockstar> LarstiQ, so I need to be able to specify a format string, and determine whether a branch with that format string needs upgrading.  Maybe that'll help you give me clues.
<mwhudson> LarstiQ: isn't it branch7 that adds stacking?
<rockstar> mwhudson, the source would say so
<LarstiQ> mwhudson: if it does, it's hiding
<LarstiQ> hmm, maybe import didn't get to it properly
<rockstar> LarstiQ, bzrlib.branch.BranchFormat7 is the first that overrides supports_stacking to return True
 * LarstiQ quizzicaly looks at ipython
<rockstar> LarstiQ, so you see my dilemma.
<LarstiQ> rockstar: I sit corrected.
<LarstiQ> rockstar: ok, I'd look at the code in bzrlib that detects when things need upgrading.
<rockstar> LarstiQ, yeah, looking at BzrDir.needs_format_conversion right now
 * LarstiQ assmebles dinner
<mwhudson> abentley: good morning, bundlebuggy seems to be down
<abentley> mwhudson: restarted
<mwhudson> abentley: thanks
<schmichael> hm, committed a 45MB json file, pulled it into another repo & its empty
<schmichael> the second repo is 1.13rc is that makes a difference
<Peng_> schmichael: What's empty? The entire repo?
<Peng_> schmichael: Maybe the branch doesn't have a working tree? Run "bzr checkout".
<schmichael> Peng_: oh sorry, turns out i'm crazy
<schmichael> turns out piping nothing to a file overwrites it ;)
<schmichael> so um... bzr is fine
<Peng_> Ah.
<schmichael> better than fine really
<schmichael> the .bzr directory is only 6.7MB!!!
<Peng_> mwhudson: ping?
<mwhudson> Peng_: hi
<mwhudson> Peng_: what's broken in launchpad trunk now? :)
<Peng_> mwhudson: The changelog page. :)
<mwhudson> Peng_: how so?
<Peng_> (You meant Loggerhead, right?)
<mwhudson> er, yeah
<Peng_> mwhudson: When I click the down arrow, it doesn't display anything. +revlog gives back an error page.
<mwhudson> hm
<mwhudson> saying what?
<Peng_> List index out of range on changes[0].
<Peng_> mwhudson: http://paste.pocoo.org/show/jE4QV4sihEBPkHGle9p2/
<mwhudson> that means the revid is wrong
<mwhudson> oh god, is this a bzr-svn branch or something?
<mwhudson> i wonder if there are quoting issues
<Peng_> mwhudson: Yeah, it is.
<mwhudson> bing!
<mwhudson> ok, should be easy to fix
<mwhudson> Peng_: http://pastebin.ubuntu.com/132182/ <- try this?
<Peng_> Hold on.
<Peng_> mwhudson: Didn't help.
<mwhudson> Peng_: did you reload the changelog page before trying again?
<Peng_> mwhudson: I should have.
 * mwhudson goes hunting for a bzr-svn branch
<mwhudson> Peng_: it works for me :/
<Peng_> Yes, I did reloa.d
<mwhudson> Peng_: i guess it's going to be long and painful, but can you paste the +revlog url that lh is trying to access?
<Peng_> mwhudson: /loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/%2Brevlog/svn-v4%3A152afb58-edef-0310-8abb-c4023f1b3aa9%3Abranches/lighttpd-1.4.x%3A2418
<Kobaz> what's the recommended commit/push email plugin
<Peng_> Wait.
<Peng_> mwhudson: Well, that was the original bad URL from before I patched it.
<mwhudson> Peng_: the patch definitely fixes browsing a bzr-svn branch for me
<Peng_> Hum.
<mwhudson> (even proxied through apache)
<Kobaz> noone has a favorite commit emailer?
<LarstiQ> Kobaz: bzr-email if mail from the location where you work is fine
<Kobaz> what about when someone does a push to a central repo
<LarstiQ> Kobaz: bzr-email if that's done via a smartserver
<Kobaz> k
<Kobaz> i have bzr going to apache with some funky python somethingorother module
<Kobaz> i think it's smartserver
<LarstiQ> Kobaz: bzr-hookless-email if not. Nicholas Allen has recently been doing work in this area too (I still have to read and reply to those threads..)
<LarstiQ> Kobaz: right, that then should be able to execute server side hooks
<Kobaz> PythonHandler bzr-smart::handler
<Kobaz> so anyways
<Kobaz> i've never installed a plugin
<Kobaz> there's a bazillion files when you click on 'code' on launchpad
<LarstiQ> Kobaz: two approaches:
<LarstiQ> Kobaz: 1) an OS provided bzr-email 2) cd ~/.bazaar/plugins; bzr branch bzr-email email; bzr plugins | grep email
<Kobaz> are there debian packages?
<LarstiQ> Kobaz: basically, if you installed bzr via a package management system, do the same for bzr-email
<LarstiQ> Kobaz: yes
<Kobaz> k
<Kobaz> bzr-email - Notification email plugin for Bazaar
<Kobaz> oooOooOoo
<Kobaz> okay, installed
<Kobaz> now what
<Kobaz> how would i configur eit
<Kobaz> heh
<Peng_> mwhudson: Oddly enough, another bzr-svn branch works even without your patch.
<LarstiQ> Kobaz: `bzr help email` should be a start
<Peng_> mwhudson: (It works with the patch, too.)
<mwhudson> Peng: which is the one that fails?
<LarstiQ> Kobaz: or /usr/share/doc/bzr-email/README
 * mwhudson hopes it's fairly small
<Kobaz> k
<LarstiQ> Kobaz: either set the options in the branch.conf you care about, or the ~/.bazaar/{bazaar,locations}.conf of the user the smartserver runs as
<Peng_> mwhudson: http://bzr.mattnordhoff.com/loggerhead/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/ (but I reverted that Loggerhead install to an older version to work around this)
<Kobaz> k
<Peng_> mwhudson: Is 2100 revisions small?
<mwhudson> Peng: if i bzr branch from that url, will i be talking to loggerhead?
<mwhudson> Peng_: small enough i guess
<Peng_> mwhudson: You can "bzr branch" from it, though Bazaar will warn about some wacky redirects.
<mwhudson> Peng_: i guessed http://bzr.mattnordhoff.com/bzr/imports/lighttpd/bzr-svn-0.5/lighttpd-1.4.x/, seems to work
<Peng_> mwhudson: fwiw, the branch passes "bzr check"
<Peng_> mwhudson: Both should work.
<mwhudson> ok
<Kobaz> i broke it
<Kobaz> http://pastebin.com/m2b818964
<LarstiQ> Kobaz: that's very weird
<mwhudson> Peng_: ok, can reproduce
<LarstiQ> Kobaz: you branch, commit, push, and they're not compatible?
<Kobaz> apparently
<Peng_> mwhudson: Oh, cool.
<LarstiQ> Kobaz: /tmp isn't secretly in a shared repository?
<Kobaz> nope
<LarstiQ> Kobaz: relevant ~/.bzr.log entries?
<Kobaz> nothing interesting that i can see
<Kobaz> i'll paste it
<Peng_> mwhudson: So does that mean your escaping patch is unnecessary?
<mwhudson> Peng: no, it's wrong :)
<Kobaz> http://pastebin.com/m4970ae9a
<Peng_> Wait, no it's not necessary or no it is necessary?
<mwhudson> >>> bzrlib.urlutils.escape('/')
<mwhudson> '/'
<mwhudson> Peng_: a different patch is necessary
<Peng_> mwhudson: Ah.
<mwhudson> that ^ surprises me
<Kobaz> LarstiQ: both are Repository branch (format: pack-0.92)
<LarstiQ> Kobaz: what version of bzr and the apache foo?
<Kobaz> Bazaar (bzr) 1.10 Python interpreter: /usr/bin/python 2.5.2
<Kobaz> on both
<Kobaz> apache 2.2.9
<Kobaz> using bzr-smart.py and modpywsgi.py
<Peng_> mwhudson: So escaping / as well would fix it?
 * LarstiQ looks at bug reports
<mwhudson> yes
<mwhudson> i think so
<Peng_> mwhudson: urllib.quote(s, safe='')
<mwhudson> except that freaking 404s
<mwhudson> what's going on
<mwhudson> !?
<mwhudson> apache is 404ing me
<Kobaz> [Mon Mar 16 17:33:31 2009] [error] [client 207.255.24.91] File does not exist: /home/web/bzr/playground/.bzr/checkout
<Kobaz> i'm getting that in my apache logs
<Kobaz> maybe that's bad?
<LarstiQ> Kobaz: it's not bad per se
<LarstiQ> Kobaz: does -Dhpss reveal anything?
<Kobaz> what am i giving that to?
<Kobaz> bzr?
<LarstiQ> Kobaz: yeah, with the push
<Kobaz> KnitPackRepository('file:///usr/home/tmp/playground/.bzr/repository/')
<Kobaz> (no details)
<Kobaz> HPSS calls: 9 <bzrlib.transport.http.SmartClientHTTPMedium object at 0x84f9eec>
<LarstiQ> Kobaz: (from `bzr help debug-flags`)
<Kobaz> ah
<LarstiQ> Kobaz: the details should be in ~/.bzr.log
<mwhudson> Peng_: i think i hate paste
<Kobaz> oh
<Kobaz> whoops
<Kobaz> i was using https://
<Kobaz> i need to use bzr+https://
<Kobaz> maybe there should be a note about that in the error output
<Kobaz> Pushed up to revision 18.
<LarstiQ> Kobaz: that, or fix it so that isn't necessary
<Kobaz> i forgot i needed to use bzr+https... i haven't played with a new repo in a while
<Kobaz> true
<Peng_> mwhudson: You could switch back to CherryPy. :D
 * Peng_ hides
<LarstiQ> Kobaz: if that is still in the case in 1.13, please file a bug
 * LarstiQ falls asleep
<mwhudson> Peng_: maybe cherrypy3 would induce less homicidal rage
<mwhudson> but also apache is screwing me over here
<mwhudson> http://localhost:10101/bzr/lighttpd-1.4.x%2Fchanges gets me the same page as http://localhost:10101/bzr/lighttpd-1.4.x/changes
<mwhudson> which is annoyting
<mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x/changes proxies to the above just fine
<mwhudson> but http://localcode.dev/bzr/lighttpd-1.4.x%2Fchanges gets me an apache 404 page
<mwhudson> despite
<mwhudson> <Location "/bzr/">
<mwhudson>         ProxyPass http://127.0.0.1:10101/bzr/
<mwhudson> being in my apache config
<Kobaz> okay
<Kobaz> 1.13 is okay with https://
<Kobaz> oh wait
<Kobaz> no
<Kobaz> it died
<Kobaz> it looked like it was going
<Peng_> mwhudson: Apache isn't even proxying it back? That's strange..
<Kobaz> so bzr-email isn't fireing off when i do a commit
<mwhudson> Peng_: http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes !!
<mwhudson> (what the heck!?)
<lifeless> Kobaz: have you configured it?
<Peng_> mwhudson: Does it explain why it does that?
<mwhudson> Peng: no
<mwhudson> i guess it's some harebrained security thing
<Peng_> Yeah, probably.
<mwhudson> maybe i'll just urlencode everything twice :)
<Peng_> Or tell people to turn it off. :D
<Kobaz> lifeless: yeah i set up the branch/branch.conf with some of the options
<Peng_> I wonder if Lighttpd does the same thing?
<Kobaz> lifeless: i added: post_commit_sender and post_commit_to
<Kobaz> is there anytnig else i need
<mwhudson> that works
 * mwhudson sighs
<Kobaz> would i have to reload apache?
<yacoob> hm... I can't checkout/branch/pull part of the tree, can I?
<mwhudson> Peng: try this barrel of fun: http://pastebin.ubuntu.com/132206/
<Kobaz> lifeless: are there any other config files i need to monkey with other than branch.conf
<mwhudson> Peng_: yeah, it's some lame security thing, as predicted http://mail-archives.apache.org/mod_mbox/httpd-users/200312.mbox/%3CPine.WNT.4.58.0312041453240.1444@Poste3947.hec.ca%3E
<lifeless> Kobaz: are  you using it locally or ona server? On a server bzr-email doesn't see 'commit' as such, rather it seespushes
<Peng_> mwhudson: Why is this only impacting +revlog, not anything else? Luck?
<mwhudson> Peng_: we don't stick revids in urls very often any more
<Kobaz> lifeless: server
<igc> morning all
<Kobaz> i push to the server and nothing happens except the push
<Peng_> mwhudson: Sure, but you used to do it all the time.
<Peng_> mwhudson: This patch works for me (just over localhost, no web server)
<mwhudson> Peng_: yes, but now bzr-svn changed the way it does revids
<lifeless> Kobaz: you need to set post_commit_push_pull=True as well
<Peng_> mwhudson: Ah.
<lifeless> Kobaz: run 'bzr help email' - if it does not document the post_commit_push_pull setting then you need a newer bzr-email plugin
<Kobaz> do i need to put it under a specific section?
 * Peng_ notes that Lighttpd doesn't do this security thing.
<Kobaz> i dont have post_commit_push_pull in the help
<lifeless> Kobaz: lastly, you need to be using the native bzr protocol - bzr:// or bzr+ssh:// or bzr+http:// for this to work
<Kobaz> yeah, i a
<Kobaz> m
<Kobaz> okay, i upgraded bzr-email
<Kobaz> still no workey
<lifeless> did you add post_commit_push_pull=True ? (you put that where your other settings are)
<Kobaz> yea
<lifeless> hmm, odd
<Kobaz> post_commit_sender, post_commit_to, post_commit_push_pull
<lifeless> hi igc
<Kobaz> are the only things i have in branch.conf
<Kobaz> do they need to be under a specific section?
<Kobaz> or just anywhere in the file
<lifeless> top level, no sections at all
<Kobaz> any kind of debugging on the server i can turn on?
<Kobaz> to make sure it's actually loading the plugin, and etc
<lifeless> the ~/.bzr.log file will have some info
<lifeless> (on the server)
<lifeless> hmm, looks like we don't list all the found plugins
<lifeless> well, you can ssh to the server - "ssh <server> bzr plugins"
<Kobaz> nothing in the log
<Kobaz> k
<Kobaz> email is listed in plugins
<lifeless> ok, its finding it
<Kobaz> i'm using apache with smartserver... if that makes a difference
<lifeless> Kobaz: ah; hmm
<lifeless> Kobaz: johnf-inodes did the same config as you a week or so ago
<lifeless> he came up with this patch: https://code.edge.launchpad.net/~johnf-inodes/bzr-email/server_support
<lifeless> I haven't reviewed it yet, but as he's using it at his organisation, I'm fairly sure it works :P
<Kobaz> mm
<Kobaz> okay so, i have that in now
<Kobaz> still doesn't do anything :(
<lifeless> uhm
<lifeless> you're running under apache
<lifeless> does the account apache is runnign bzr as, have the plugin installed (or did you install it globally?)
<Kobaz> globally
<Kobaz> i backed up the original one
<Kobaz> oooo
<Kobaz> i restarted apache
<Kobaz> there it goes
<lifeless> yay
<poolie> lifeless, spiv, igc, for myself, i'm going to send the sprint report, finish the ui-related branches i did while travelling and on friday and generally pick up pieces
<Kobaz> i'm a gonna have to go and learn python now
<Kobaz> the bzr-email output isn't as purty as svnmailer
<igc> poolie: can you re-review my/jam's dirstate patch please?
<poolie> sure
<lifeless> Kobaz: yes, thats true, there is probably a patch in https://code.edge.launchpad.net/bzr-email somewhere
<lifeless> I didn't realise how many branches had collected :P
<lifeless> igc: have you considered changing ls instead ?
<lifeless> so that it does non-recursive by default
<Kobaz> i should update my loggerhead too, i broke it somehow
<igc> lifeless: ?
<lifeless> igc: re: 'ls is slow'
<igc> lifeless: my goal is a faster iter_entries() and ...
<igc> to find places where iter_entries() could be replaced by a faster method, e.g. one not calculating paths if the path is never used
<lifeless> igc: both iter_entries and iter_entries by dir can do partial tree as well as full tree
<lifeless> igc: via the from_dir and specific_file_ids parameters; it may need more work than just paging the full thing in
<igc> lifeless, but they have explicit constraints on order
<igc> lifeless: sure
<lifeless> also, I'm confused, because I would have thought its the same amount of work either way - or are the pages being read multiple times?
<igc> lifeless: iter_changes explicitly walks from the root down - it's the children calculations that are the slow bit
<igc> lifeless: I'm yet to look at jam's code but I'm not surprised he got much faster results by calculating children in one pass rather than each time
<lifeless> igc: All I'm saying, is its surprising that .children is slow, its meant to be fast, and that iter_entries is not just-full-tree.
<lifeless> igc: beyond that its in your court :)
<lifeless> separately, I'm sorry, but I had to bb:resubmit your check patch
<lifeless> it removes a downwards sha1 validation
<igc> lifeless: I didn't see that and just submitted it to pqm. Can you cancel it for me.
<igc> please?
<CardinalFang> Er, what am i doing wrong?  make new project. ... "bzr init .; bzr add .; bzr commit -m 'Initial import.';"
<lifeless> I've wanted to make check faster too, but I stopped at that point; it needs something like a text_key->sha1 mapping held open
<lifeless> igc: stopped it
<CardinalFang> -> bzr: ERROR: No such file: ('TREE_ROOT', 'foo@bar-1234-1234blahblah')
<lifeless> then we can get all the texts, get their sha1, and make sure it matches
<igc> lifeless: I'm confused. I didn't take out the call to ie.check()
<lifeless> CardinalFang: get rid of the '.'s, you don't need them
<CardinalFang> Huh.  I do for "add", I think.  Okay.  Retrying.
<lifeless> igc: oh. I may have misread, let me read again
<lifeless> CardinalFang: you don't for add, or for init
<lifeless> CardinalFang: in general bzr assumes ., or $(bzr root) for any command that takes a path
<lifeless> CardinalFang: with a few key exceptions
<CardinalFang> ("revert")
<lifeless> CardinalFang: and in fact, 'bzr revert .' is != 'bzr revert' because the '.' says the tree only, and that means we don't revert metadata
<CardinalFang> :)
<lifeless> igc: oh totally my bad
<igc> lifeless: if you prefer, I could walk the inventory via "entry in inv" and use id2path() to find paths. That might be safer?
<lifeless> igc: go for it, its good. I was indulging in wishful thinking it appears
<igc> in check_revision_tree
<igc> lifeless: np. I'll resubmit
<CardinalFang> lifeless: Hrm, could my problem be a shared repo I have in the parent?
<lifeless> igc: I was hoping you'd removed the key issue I have
<lifeless> CardinalFang: possibly, is it a rich root format by chance?
<lifeless> CardinalFang: you tried with no '.''s?
<CardinalFang> lifeless: Yes, same thing.
<lifeless> CardinalFang: please run with -Derror, you'll get a backtrace
<CardinalFang> /usr/local/lib/python2.5/site-packages/bzrlib/revisiontree.py(82)iter_files_bytes()
<CardinalFang> -> raise errors.NoSuchFile(e.revision_id)
<CardinalFang> top of stack.
<lifeless> CardinalFang: thats all?
<CardinalFang> (I have BZR_PDB set -- assuming that does the same.)
<lifeless> CardinalFang: no, it doesn't
<CardinalFang> Er, no.
<lifeless> BZR_PDB puts you into a debugger
<lifeless> hit bt
<lifeless> and you'll get the full stack
<CardinalFang> Ah, okay.  Not your fault.  It's in my stuff.  Thanks, lifeless.  Sorry for the noise.
<lifeless> CardinalFang: you have a plugin or some such ?
<CardinalFang> Yes.  It lacks the special case for first revision in some diff code.
<lifeless> heh
<thrope_> is launchpad supposed to be open for public use?
<lifeless> thrope_: it is
<thrope_> I tried to create a project there to mirror a google code svn repo but it just says 'pending review'
<lifeless> thrope_: anyone can use it for open source projects
<thrope_> who reviews it and when?
<lifeless> code imports require a review
<CardinalFang> All after I updated bzr on two machines at once, and horrors! one of my first operations broke!  Silly me.
<lifeless> the code import team
<thrope_> lifeless: but if I push it from a bzr branch no review is needed?
<lifeless> thrope_: right; when we import we do a lot of traffic to other sites, and we're the ones grabbing the code - we need to confirm the details, check the licence etc
<thrope_> ok
<lifeless> if you push you are required to meet the terms of service
<lifeless> which include only pushing code you legally can etc etc
<thrope_> but the import will track the svn repo automatically, so I guess its better to wait
<lifeless> anyhow, if you ask a question on answers.launchpad.net/launchpad-bazaar, one of the guys will get to it soon
<Peng_> mwhudson: Thanks for figuring out and fixing my Loggerhead issue. :)
<mwhudson> Peng_: thanks for being the loggerhead canary :)
<mwhudson> Peng_: i don't suppose you want to test the new trunk with IE?
<Peng_> mwhudson: Sorry, no Windows boxes, and I'm not installing WINE. :P
<mwhudson> Peng_: fair enough :)
<rockstar> mwhudson, later today I can try it with the Windows VM.
<mwhudson> rockstar: cool, don't stress about it
<mwhudson> but if you have time, neat!
<Peng_> mwhudson: I suppose I could break into my father's place and steal his laptop... :)
<mwhudson> i can usually use my other half's work laptop
<mwhudson> but she's not here this week
<mwhudson> um what
<mwhudson> xchat just fell over :(
<Peng_> Well, you didn't miss anything.
<lifeless> 10:29 < mwhudson> but she's not here this week
<lifeless> 10:29 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has quit [Remote closed the connection]
<lifeless> 10:30 -!- mwhudson [n=mwh@canonical/launchpad/mwhudson] has joined #bzr
<lifeless> 10:30 < mwhudson> um what
<mwhudson> cool
<mwhudson> do you have to give Repository.iter_files_bytes a revision id that touched the file you're asking for?
<lifeless> yes
<lifeless> generally, don't use iter_files_bytes
<lifeless> use RevisionTree.iter_files_bytes
<mwhudson> fair enough
<lifeless> because RevisionTree knows what you need :P
<mwhudson> i was hoping to avoid loading the inventory
<mwhudson> but yes, working first
<lifeless> well
<lifeless> how would you figure out the text you want without the inventory
<lifeless> develop on chk formats, you'll get a much better picture
<mwhudson> yeah, fair enough
<jml> so, I'm pulling down bzr.
<jml> err, launchpad.
<jml> and the progress bar says 6MB (& it's around 50% complete). what does this number mean?
<jml> I find it strange to think that ten hours worth of changes to trunk could total more than 12MB
<lifeless> jml: well, there's nearly 50% overhead in the plain vfs methods
<jml> lifeless: it ended up being ~25MB
<jml> lifeless: I guess that'll go down once Launchpad upgrades its bzr
<lifeless> yes
<jml> lifeless: is the number total throughput or just downloaded bytes?
<lifeless> total
<lifeless> up + down for-all transports
<lifeless> so total IO except local-disk isn't reported
<jml> *nod*
#bzr 2009-03-17
<poolie> i'm going to merge Proposal to merge branch <https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/4088> as trivial
<lifeless> poolie: +1
<lifeless> poolie: are you starting to use merge proposals rather than BB ?
<poolie> i'm in kind of toe in the water mode
<poolie> having two todo lists is obviously not so desirable
<lifeless> indeed
<lifeless> I think lp is close
<poolie> yeah i'd say they have roughly equal good and bad points atm
<lifeless> lp crashes less :P BB is way faster
<poolie> lp lets people comment without prior permission
<poolie> and kindof has the proposals linked to bugs etc
<lifeless> BB has bug links
<poolie> do you know this snoxracer337 guy?
<poolie> that's true but only unidirectionally unless you manually create them
<poolie> as i generally do
<lifeless> the nick isn't known to me; context?
<poolie> wants to join bzr-core
<lifeless> looking
<lifeless> not clearly bzr related
<lifeless> https://edge.launchpad.net/%7Emike337/+participation
<lifeless> I'd say your normal 'please get involved in the community first' message is appropriate
<lifeless> It might be nice to have that as a template somewhere :P
<poolie> yeah
<poolie> i just wondered if it was a case like johnf
<poolie> cf bug 4976
<ubottu> Launchpad bug 4976 in launchpad-registry "When trying to join a team, user should be able to give comment" [Low,Triaged] https://launchpad.net/bugs/4976
<poolie> speaking of slow i think i saw the subscriber portlet load asynchronously
<poolie> that's nice
<lifeless> well
<bob2> lifeless: be nice
<lifeless> bob2: awwww
<luke-jr> jelmer: is it known problem that you can't branch a svn repo root?
<igc> lifeless,poolie: Are we expecting chk formats to have both an inventories index and a chk_bytes one? Long term?
<igc> I'm tracking down why send is slower on chk formats
<lifeless> igc: either they will, or we'll inline  the inventory root into the inventory
<luke-jr> actually, might just be this repo: http://repos.labjack.com/public/
<igc> and it seems get_parent_map() has more indices to walk
<lifeless> s/inventory$/revision/
<igc> lifeless: do we have a nice way now of finding uncommon history?
<igc> the send code does 2 X repo.get_ancestory() and then diffs the answers
<lifeless> igc: get_parent_map should have identical index behaviour because parents of chk nodes are not asked for - or shouldn't be during bzr send
<lifeless> yes, there is stuff in graph
<lifeless> but it may still have a bug
<igc> lifeless: can you take a look at BundleWriteOperation.__init__() - line 267 of bzrlib/bundle/serializer/v4.py?
<igc> abentley: ^^^
<lifeless> igc: as you say it does a full graph op
<lifeless> igc: but thats on the revision graph, chk doesn't alter this
<lifeless> igc: its more likely, IMO, that the gc cache is being thrashed
<igc> lifeless: if I'm reading the profiling info right, get_parent_map is running on a combined index?
<lifeless> yes, always
<igc> in 1.9 format, index.iter_entries() gets called 25K times while it's 49K under brisbane-core
<lifeless> .revisions is a KnitVersionedFiles, which has a KnitGraphIndex which holds a single GraphIndex, and that GraphIndex is a CombinedIndex with a list of the backing BTreeGraphIndices from the repo
<lifeless> igc: from get_parent_map? or overall
<igc> from get_parent_map()
<lifeless> thats...odd
<igc> I thought so too
<lifeless> I suspect a hidden cause
<igc> you explanations makes me even more curious
<igc> I'll go digging a bit more now I understand what's happening better
<lifeless> ok
<igc> lifeless: but before I do, what graph calls should I look at to improve BundleWriteOperation.__init__()?
<lifeless> something on Graph, I don't recall the names
<lifeless> there is one that looks perfect but is buggy. Beware.
<igc> ok
<lifeless> anyhow, I'd expect send to be slower due to inventory stuff, not index load from ancestry checks :P
<igc> lifeless: right. I've never looked hard at the send code before so I'm just going from what the profiling data is telling me
<igc> lifeless: graph.find_difference() looks like the obvious method?
<igc> lifeless: can you recall how it's buggy?
<lifeless> igc: it doesn't return accurate results under some cases
<lifeless> its documented in tests and the docs I think
<lifeless> igc: in short - you're welcome to fix it :P
<igc> lifeless: thanks :-)
<jfroy> hey
<jfroy> Is it just me or the 1.13 distribution archive doesn't have the pre-generated .c extension modules?
<jfroy> INSTALL clearly states that they should be bundled.
<jelmer> luke-jr: you can branch a svn root
<jelmer> luke-jr: how is it failing?
<luke-jr> jelmer: nm, they rearranged stuff
<lifeless> jfroy: I haven't checked, if they are missing then thats more serious than the wrong NEWS entry, so we may want to spin a 1.13.1 with the .c files and the NEWS teaks
<jfroy> lifeless: they are missing, except _patiencediff_c.c
<jfroy> just checked the tar.gz and the zip
<wbyoung> hey, i was wondering if there was anyone who could help with trying to set something up similar to svn:externals
<tedg> So, I really want this bug fixed, bug 336749.  How do I run with BZR_PDB ?
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749
<wbyoung> it seems i can get join --refernece to work with a pack-0.92-subtree, but when trying to commit the join, I get the following error: bzr: ERROR: already in a write group
<spiv> Hooray, all Inter*Remote* are now gone, and so repository.py no longer imports bzrlib.remote :)
<spiv> (Well, once my next patch is accepted by PQM.)
<poolie> spiv way to go
<poolie> tedg, do
<poolie> export BZR_PDB=1
<poolie> then run it
<spiv> It's nice to be deleting >100 lines of code for once...
<poolie> pah
<poolie> i've just sent a deletion of many more :)
<poolie> but yes i agree
<poolie> https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/4432 -- look at all that red
<poolie> tedg: i guess actually you need to get lifeless's attention
<tedg> poolie: Thanks, I realized I deleted the data, so I'm regrabbing it for the PDB.
<spiv> poolie: that is pretty nice :)
<tedg> Also, I'll note that it's quite annoying to get a crash dialog everytime I log in from bug 283294
<ubottu> Launchpad bug 283294 in bzr-gtk "bzr-notify crashed with RuntimeError in add_signal_receiver()" [Undecided,New] https://launchpad.net/bugs/283294
<lifeless> jfroy: please file a bug
<lifeless> tedg: BZR_PDB=1 bzr foo
<lifeless> tedg: then you use your knowledge of bzr internals to explore
<tedg> lifeless: Does this dump something, or give me a command line?
<SamB> lifeless: where do you get one of those?
<SamB> is there one I can download somewhere?
<lifeless> SamB: one of what?
<lifeless> tedg: it drops you into pdb, the python debugger
<SamB> lifeless: knowledge of bzr internals
<lifeless> tedg: its almost certainly a waste of time for you to do this; jelmer needs to, or I need a test repo that has the issue I can do it on
<lifeless> SamB: reading the internals :P
<SamB> hmm.
<tedg> lifeless: It happens on the Inkscape repository.  Basically check it out and then do any action on it.  You can see the commands and the log file in the duplicate bug 332582.
<SamB> there isn't some kind of direct NNTP-feed-to-my-brain or something?
<ubottu> Launchpad bug 332582 in bzr "BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0xa42ec6c> has delta references to items not in its repository (dup-of: 336749)" [Undecided,New] https://launchpad.net/bugs/332582
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749
<tedg> Unfortunately the log isn't that clear as I was doing several things in different instances of Bazaar while it was running.
<lifeless> tedg: I want a copy of the failing data, for various reasons
<lifeless> SamB: sorry no :(
<lifeless> tedg: rather than instructions for possibly recreating it anew
<tedg> lifeless: I'm downloading it now, I'll make a tarball and attach it to the bug.  Will that work?
<lifeless> tedg: yes
<SamB> lifeless: I suppose that's just as well, as I lack the necessary hookups in any case
<lifeless> tedg: note that its not high on my stack at the moment; AFAIK jelmer is looking at it
<tedg> lifeless: Oh, it was my understanding from the comments that he'd given up.
<lifeless> jelmer: ^
<tedg> Ah, getting that data together is going to take a bit... I deleted the branch, and the old SVN branches don't seem to be compatible with the new ones.
<jelmer> lifeless, tedg: I'm not working on that bug at the moment
<jelmer> lifeless: I tried storing only the parents that were present
<jelmer> but that caused bzrlib to blow up when I fetched again with more parents
<lifeless> jelmer: hmm
<lifeless> lunching
<gotgenes> bzr doesn't have to be installed on a server to host the repository, does it?
<jam> lifeless: .children() is slow because the lookup key by prefix code has to walk the entire _items dict for every lookup
<jam> so if you have 1 prefix
<jam> put another way
<jam> looking up 100 children 1 at a time takes forever
<jam> as it is 100x100 prefix comparisons
<jam> At least,from what I could tell from 'iteritems()' returning 20k entries
<jam> but having 600k calls to set()
<jam> igc ^^
<SamB> lifeless: you eat lunch at odd times!
<lifeless> jam: that sounds like a bug to me
<lifeless> jam: its meant to be stored by hash(item[0]) + hash(item[1])
<lifeless> SamB: not odd for me :P
<lifeless> gotgenes: no, it doesn't. If it is you can get better performance though
<jam> lifeless: iteritems(key_filter=[file_id1]), iter_items(key_filter=[file_id2])
<jam> has to do iteritems N times for N file ids
<jam> and inside it iterates over the full items dict
<jam> so N^2 behavior
<jam> I didn't see an obvious reason why in  def children()
<gotgenes> lifeless: Thanks.
<jam> since it does seem to grab all the child_keys based on a single parent_id prefix in the container
<lifeless> jam: huh, should be one iteritems per directory entry
<jam> Well, I see 20k calls to iteritems() (as a generator it yeilds 20k entries)
<jam> and I see 654,845 calls to set()
<lifeless> jam: (to get the children ids), and one to populate the children entries, or perhaps one per child, which is still only 2N
<jam> so that is about 32:1
<lifeless> jam: so, see under bug
<jam> which is probably the 32 keys in each leaf node
<jam> 255 leaf nodes to check
<jam> not sure
<lifeless> I should rephrase I guess
<jam> 6k calls to items(), + 6k calls to iteritems...
<lifeless> we have a datastructure which should allow children to be cheap, if its not there is definitely an issue
<lifeless> I agree that it may not 'be cheap'
<lifeless> I'm asserting that it should be possible for it to be cheap
<jam> I do see "718" calls to LeafNode.deserialise, which is a bit more than I think we should see....
<jam> hmm... maybe with p_id + id_to_entry?
<jam> lifeless: so if you have hash(file_id), and a given directory has 43 items, isn't that likely to go to 43 different pages?
<jam> which means that we have a 43*num_entries_on_leaf
<lifeless> jam: no, because its a tuple key - its pid + basename
<jam> lifeless: not in that one
<jam> in the one that gets the bytes for the entry
<jam> the parent_id_basename_to_file_id is cheap, yes
<jam> it is about 3x faster than the id_to_entry lookupps
<lifeless> oh yes, but because we're using the main object, it should be parsing and caching all of those pages
<jam> lifeless: I would guess the pages themselves are cached
<jam> but it still is a double loop
<jam> of for key, bytes in items: for lookup in lookups:
<jam> where the outer is N entries on a page
<jam> and the inner is the M children of a directory
<lifeless> possibly iterentries isn't skipping enough pages?
<jam> now... maybe we are making the mistake of not filtering our keyfilter
<jam> as in
<jam> we find the N pages underneath that match
<jam> but we don't know which keyfilter matched which  subpage
<jam> so for all M children of a directory that match in one of M leaf nodes
<lifeless> right, we should only be inspecting the filter items that matched
<jam> we then compare all N leaf entries against all M keys
<jam> when we should be only matching against the one of M keys that hits that leaf node
<jam> I still feel like we are doing a prefix match against all items in a dict
<jam> when we *should* be doing a simple self._items[key] lookup
<jam> but I'm not sure if that can be adequately expressed yet
<jam> lifeless: Am I wrong in saying that id_to_entry.iteritems([(file_id,)]) should always match exactly 1 entry?
<jam> (consider you could have file_id1 = 'foo', and file_id2 = 'foo-bar')
<jam> hmm... the code really isn't set up for what I want to do... which is to split up the key_filter based on which part of the filter matched which child page
<jam> iter_nodes is done very independently of iteritems(), not to mention it shortcuts the comparison, so we wouldn't know all the keys which would have matched. Though we could remove that shortcut
<lifeless> jam: tuple keys should only ever match once in id_to_entry
<lifeless> jam: parent_to_basename they can multimatch - [('parent',)] -> list of children
<jam> I'm pretty sure with the current construct that doesn't end up holding true
<jam> as you just look at 'prefix[:length]'of the serialized from
<jam> form
<lifeless> perhaps this just needs updating like you did the rest to handle hashed keys better?
<jam> we can certainly change that
<jam> well, it sounds like prefix[:] should only really be splitting on end-of-internal width or NULL
<lifeless> poolie: so progress
<lifeless> poolie: I filed a bug today/yesterday about it showing inappropriately
<lifeless> andrew and I have ensured that setUp() is being called everywhere and it still shows during selftest.
 * igc lunch
<mattdoran> Typically, how long after a release do the windows builds get posted?
<BasicOSX> The generic answer (not to be rude) is when the windows people have time :-)
<mattdoran> I understand completely ... I didn't mean to sound impatient either.
<mattdoran> was just wondering whether there was a ballpark.  e.g. typically within a week.   No big deal though
<lifeless> mattdoran: within a week yes
<lifeless> its sometimes longer, the windows build process is ... fragile
<mattdoran> :) gotcha ... thanks
<igc> poolie: if you have time soon, can you please re-review the dirstate patch jam & I worked on last week?
<lifeless> spiv has headed off, I'm going to land one more branch [I hope] and be gone myself
<fullermd> Hm.
<fullermd> bzr-1.13.tar.gz doesn't include the pyrexified .c files.
 * fullermd frowns.
<fullermd> Or a couple others either.
<fullermd> The only one in it is _patiencediff_c.c.
<lifeless> ok, streaming pull from stacked branches submitted
<lifeless> -> done, modulo sheparding it though
<lifeless> *through*
<bob2> spiffy
<lifeless> and I'm done for the day
<igc> seeya lifeless
<mwhudson> <lifeless> ok, streaming pull from stacked branches submitted
<mwhudson> yay!
<poolie> igc, i'll read it now, promise
<poolie> lifeless: if you're talking about activity coming up during selftest
<poolie> then yes, i've seen it and i know why it's happening
<poolie> basically because nothing turns it off :)
<lifeless> poolie: but it should be controlled by the SilentUI surely
<lifeless> poolie: and that is installed by setUp
<lifeless> poolie: also, streaming-from-stacked has landed
<lifeless> say 'hallelujah'
<lifeless> anyhoo, gone
<vila> hi all
<igc> hi vila
<vila> Hi Ian :)
<poolie> lifeless: the problem is that the overall testrunner uses a progress bar
<poolie> at least in non-verbose mode
<poolie> actually it is a bit interesting that the lower level transports aren't talking to the silentui
<Peng_> With the streaming-from-stacked stuff, is it just me, or is is_empty's docstring wrong? It says it returns true if it's *not* empty.
<poolie> hi vila
<vila> hi poolie !
 * igc dinner
<lifeless> poolie: the silent ui should have its own pb stack, so they should not interact
<lifeless> Peng_: probably :P
<poolie> so that suggests either the silent ui is passing notifications through to the higher level progress view
<poolie> or, the transports are somehow talking to the real ui object
<poolie> either is possibly
<poolie> possible*
<poolie> should not be very hard
<lifeless> sure;I'm hoping you'll find time to track it down, asyou know the new stuff best :)
<lifeless> the test improvements today should make it easier; test_remote is a small test regex that will trigger the behaviour
 * lifeless goes again
<lifeless> chat with you tomorrow
<poolie> oh thanks for the tip
<sabdfl1> hi folks
<sabdfl> anybody building bzr.dev on jaunty?
<RAOF> sabdfl: Isn't there a bzr nightly PPA?
<RAOF> https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa would be it, yes.
 * eMBee needs to find out where it is
<eMBee> ooops
<stub> Does the smartserver benefit from running over a compressed link, or should I disable SSH compression to bazaar.launchpad.net?
<stub> Hmm... 1.13 released but no packages in either https://launchpad.net/~bzr/+archive/ppa or https://launchpad.net/~bzr-beta-ppa/+archive/ppa
<poolie> stub:  it will benefit a bit
<poolie> sabdfl: i use it on jaunty all the time
<poolie> to the vast amusement of those with working laptops :)
 * AfC assumes poolie is referring to some kind of inside joke
<poolie> just that people who install alpha releases get what they expect/deserve :)
<poolie> it's all part of the fun
<poolie> and the point of testing it
<stub> poolie: I wonder. I just checked the CPU utilization graphs and CPU is running at capacity.
<stub> poolie: Oops... misread
<poolie> in that case compression may be slowing you down
<stub> Lots of capacity :-)
<poolie> it's probably within \epsilon either way: it won't compress much, probably, but zlib is cheap too
<poolie> stub there should be rc1 packages and the final should be up in a bit
<stub> Yer - had to downgrade from rc1 due to being unable to my push not using stacking.
<poolie> and you're told this is fixed in final?
<stub> Yes - lifeless said it had been fixed and would be in final.
<Lieven1> hi
<Lieven1> I'm trying to pull from an svn repo, that requires authorization, and that gives an error that authorization is required (obviously:))
<Lieven1> but I tried to google on how to specify your authorization, but couldn't find anything
<Lieven1> so does anyone know how to do that/
<bob2> include the username in the url
<Lieven1> thx, trying it out now:)
<Lieven1> hmm.. my original url is sth like:   http://subversion.company.local/svn/HEAD
<Lieven1> so then it should become this, right: http://username@subversion.company.local/svn/HEAD
<igc> poolie: did you want the class or methods renamed to use SHA? I'm pretty sure the methods in osutils are 'sha' - all in lowercase
<igc> s/methods/functions/
<sabdfl> poolie: i'm getting an error on make:
<sabdfl>   Cannot build extension "bzrlib._groupcompress_pyx".
<sabdfl>   Use "build_ext --allow-python-fallback" to use slower python implementations instead.
<sabdfl> not sure what's causing that
<fullermd> Oh, nice.
 * fullermd does his first push to a 1.13 smart server.
<bob2> nice progress dealy
<Tak> vila: reping
<vila> Tak: pong
<Tak> hi! is there any way to get the sftp transport to use authentication.conf for user/pass credentials?
<vila> Tak: only for user, trying to use it for passwords should issue a warning
<vila> Tak: the rationale being that ssh provides better means for passwords/keys and is more secure than whatever we can come with
<Tak> ok
<Tak> it doesn't seem to be issuing a warning for me on 1.13rc1
<vila> Tak: and also .ssh/config is already more powerful
<vila> Tak: try using -Dauth and look into .bzr.log
<vila> there should be messages regarding which sections are used (or not)
<Tak> -Dauth as a bzr arg?
<vila> Tak: yup. as in 'bzr push -Dauth'
<vila> or whatever command needing credentials from authentication.conf
<Tak> hmm, it tries public key, then it prompts for password on stdout, but no warning on stdout or in log
<jam> sabdfl: if you are still around, it might be an issue with pyrex versions. We might be doing something like "+=" which isn't supported by pyrex 0.9.6 (you need 0.9.8+, IIRC).
<jam> I'll try to check
<jam> vila: good morning
<vila> Tak: who is prompting for password ?
<vila> jam: hi !
<jam> sabdfl: alternatively, you may need to install 'zlib1g-dev' since we now directly access some zlib functions.
<jam> vila: my guess is openssh
<sabdfl> thanks jam
<Tak> it's paramiko
<vila> Tak: what is your problem exactly ?
<jam> vila: he's trying to use authentication.conf for sftp
<vila> jam: I got that, but for which part ? user (should work) ? password (will never work) ?
<Tak> ok
<Tak> I /was/ asking if/how it worked for password
<jam> vila: I thought password might work with paramiko, since we were controlling things there
<Tak> you told me it won't, ok
<jam> it certainly would never work for openssh
<Tak> you also said it would print a warning, which it is not
<vila> Tak: if it doesn't show a warning, most probably the section doesn't match
<Tak> so then you asked me to run with -Dauth and look at the log, which still doesn't
<vila> scheme should be 'ssh' not 'sftp' ?
<Tak> what does it...ahh
<Tak> ok, with 'ssh' scheme, the warning prints
<vila> Tak: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
<Tak> yeah, I was parsing the url and dumping the transport in as the scheme
<vila> Tak: both caveats are documented there (use 'ssh' as scheme, no password handling for ssh)
<Tak> ok
<Tak> now I need to set up a different scheme for testing
<vila> Tak: testing as in 'writing unit tests' or as in 'setting up some bzr server' ?
<Tak> heh, testing as in 'connecting using my auth-populating mechanism to make sure I'm doing it right'
<vila> Tak: if you populate authentication.conf by programmatic means, I'd very interested as the actual mechanism will certainly evolve in the future.
<Tak> right now, I'm using AuthenticationConfig.set_credentials()
<thrope> hi - how can I add a filename with spaces to .bzrignore? I tried quoting or backslash escape but it doesnt seem to work
<thrope> ah nothing
<thrope> no quotes, escape... guess I should hav etried that first
<phinze> okay so i have a coworker who did Something Bad to one of our shared project branches .. and the Bad Thing is in one of his subcommits
<phinze> do i have the information to revert a subcommit from the shared branch or does the delta only reside on his local work branch
<fullermd> The rev is there.
<fullermd> "subcommit" is a UI fiction; a revision is a revision underneath.
<phinze> ahh good
<beuno> user interface fiction?
<phinze> but... $ bzr diff -r2320.1.12..2120.1.13
<phinze> bzr: ERROR: Requested revision: u'2120.1.13' does not exist in branch:
<phinze> oh jeez
<phinze> it was just a typo
<fullermd> You sure you don't mean 2130.1.13?  ;)
<phinze> there it is
<fullermd> `bzr diff -c2130.1.13` is shorter to type.
<fullermd> Wow, 2320.  Obviously neither of us can type   8-}
<phinze> hehe
<phinze> ah that -c is nice
<phinze> so i can reverse merge that guy with no problems then
<phinze> cool
<fullermd> Note that you can use 'merge' for that too, though it doesn't do anything you can't do with diff.
<fullermd> Though it's easier than manually handling renames etc if there are any in that particular rev.
<phinze> yeah i was just doing diff to see what i would be doing with merge
<phinze> i always think of it as bzr merge *does* what bzr diff *shows*
<fullermd> Me, I often just diff | patch -R.  I usually don't undo things far enough back that patch's fuzz-handling won't keep up.
<fullermd> And I'm lazy.
<phinze> that works too :)
<phinze> fullermd: so do you have a fancy short way to reverse the merge or am i doing bzr merge -r 1234..1233
<phinze> ahh nm
<phinze> you use patch -R
<Odd_Bloke> phinze: You can 'bzr merge -r 1234..1233 .'.
<phinze> Odd_Bloke: yeah that's what i'm doing... didn't know if there was a shorthand for that
<phinze> like bzr merge -R1234 . or something... the other way is short enough though :)
<fullermd> Well, -c123 does it 'forward'.  So if you type in -c123 upside-down, it does it backward.
<fullermd> Most keyboards don't handle that, though...
<Odd_Bloke> "bzr É¯ÇÉ¹ÆÇ -c123"
<gnomefreak> what does the following error mean and how to i get past it when trying to pull a branch? bzr: ERROR: Server sent an unexpected error: ('error', 'iteration over non-sequence')
<jelmer> gnomefreak: sounds like an exception happened in the server
<jelmer> gnomefreak: most likely a bug
<gnomefreak> jelmer: so its not me
<jelmer> gnomefreak: no, it really is something wrong happening server-side
<jelmer> gnomefreak: using sftp:// should fix it, if you're able to (but it'll be slower, obviously)
<jelmer> gnomefreak: a bug report would be much appreciated, particularly if this can be reproduced with public branchres
<gnomefreak> jelmer: jelmer ok will test more and file one or find one
<flacoste> i upgraded bzr-svn and now i'm having problems with my existing branches
<jelmer> flacoste: see UPGRADING
<flacoste> jelmer: i did and I ran bzr svn-upgrade
<flacoste> but after that, i had to use a push --overwrite to update the LP version of the branch
<flacoste> and now all branch that were merging that one cannot merge anymore
<flacoste> and I don't know how to fix these, since bzr svn-upgrade doesn't do anything on them
<jelmer> flacoste: yes, you'd have to upgrade those other branches as well
<flacoste> how?
<jelmer> running bzr svn-upgrade in those branches
<flacoste> bzr: ERROR: Repository at bzr+ssh://bazaar.launchpad.net/%7Eflacoste/windmill/windmill-launchpad/.bzr/ is not a foreign repository.a
<jelmer> flacoste: you have to specify the URL of the svn repository
<flacoste> ok
<flacoste> bzr: ERROR: No repository present: "http://svn.getwindmill.com/trunk/"
<flacoste> but this is the URL used on the main branch
<jelmer> flacoste: the repository root, so probably http://svn.getwindmill.com/
<flacoste> ok, seems to work :-)
<flacoste> jelmer: all good, thanks a lot!
<flacoste> i was able to merge now!
<jelmer> flacoste: np
<fm_> how is user managment done with a bazaar server?
<vila> fm_: so far with what the protocol after the '+' offers, be it ssh or http
<fm_> vila: ok, so suppose i am running "bzr serve --port=localhost:1234 --directory=/srv/bzr/repo" on server example.com, how do i access this by bzr+ssh?
<vila> fm_: you don't, you're using the only form of bzr server that doesn't have user management so far :)
<fm_> hm that's sad
<fm_> so what is the suggested configration, i did not want to create shell accounts for the users ...
<vila> there is a bug filed for that, but I can't find it right now
<vila> fm_: you can either use ssh keys and bzr+ssh or bzr+http and use whatever authentication your web server already propose
<fm_> but bzr+http is readonly i suppose, and for bzr+ssh i need to create system accounts ...
<vila> bzr+http is not read-only it can perfectly do write operations
<vila> fm_: subscribe to bug #126911 in the long term
<ubottu> Launchpad bug 126911 in bzr "Smart server has no built in authentication" [Medium,Triaged] https://launchpad.net/bugs/126911
<vila> fm_: And you don't need to create system accountS, you can create a single one for bzr usage and add whatever keys you want in its .ssh/authorized_keys
<fm_> vila: and how do i identify the commiter?
<fm_> i guess bzr whoami is used, but then every name could be set there ...
<fullermd> The commit process sets that; the bzr+ssh or whatever account is just used for the uploading.
<fm_> and i'd like to give special pernmission for dfferent directories. i.e some people have just read access and others are allowed to write ...
<vila> fm_: You can server via pure http for read-only access and use bzr+ssh for write access
<vila> fm_: You can serve via pure http for read-only access and use bzr+ssh for write access
<fm_> but not on per directory basis ;)
<vila> fm_: you may also have a look in the contrib directory where various attempts have produced various scripts
 * vila handwaves a bit to mask its incomplete knowledge of contrib content :-)
<vila> fm_: bzr_access may be what you're after
<vila> fm_: yup, sounds like a solution with a single system account and rights defined based on authorized keys
<fm_> vila: https://bugs.launchpad.net/bzr/+bug/290887
<ubottu> Ubuntu bug 290887 in bzr "Docs should cover how to use bzr_access (or similar?) with OpenSSH to make a bzr-only SSH account." [Undecided,New]
<fm_> that is exacly my bug i guess
<vila> fm_: ? Did you *read* the doc string ?
<vila> fm_: sorry, I thought you just filed the bug
<vila> you're perfectly right, we still miss the link that should help you find that script
<fm_> and may ask where to find the documentation? ;)
<vila> The script itself contains some, if you're able to address your needs with it, feedback on how you did that on what could have made it easier will be greatly appreciated ;-)
<vila> s/on/and/
<vila> s/on what/and what/ grr
<cody-somerville> Is it possible to merge in a single revision from another branch?
<fullermd> Yes and no.
<fullermd> Which is to say, merge will do the work of merging that single rev in.
<fullermd> But it doesn't do any recording of what you do (presuming the rev doesn't fully connect in anyway), so historically speaking it's no different than diff | patch.
<zooko> Hey folks: a project of mine is applying for Google Summer of Code, and one of our ideas for what a student could do this summer is to integrate with a distributed revision control too: http://allmydata.org/trac/tahoe/wiki/GSoCIdeas
<Tak> hm, that's pretty cool
<luke-jr> "No module named foreign"  "Unable to load plugin 'svn' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'"
<zooko> Tak: you mean bzr on top of a secure, distributed p2p disk-sharing thing?  :-)
<Tak> well, both the secure, distributed p2p disk-sharing thing; and bzr on top of it
<Tak> of course, if somebody implemented the FUSE integration, that would kind of make it a moot point wrt linux ;-)
<Odd_Bloke> luke-jr: Sounds like you're using an old version of bzr.
<luke-jr> Odd_Bloke: I'm using probabyl the minimum version bzr-svn depends on
<Odd_Bloke> luke-jr: What version of bzr and what version of bzr-svn?
<luke-jr> bzr 1.10
<luke-jr> 1.9, sorry
<luke-jr> bzr-svn 0.5.3
<jelmer> luke-jr: you need bzr 1.13 for bzr-svn 0.5.3
<jelmer> it will give a proper error message as long as you're running 1.10 or higher I think
<luke-jr> jelmer: it should depend on that
 * Odd_Bloke just made the mistake of trying to answer a bzr-svn question without just pinging jelmer. :p
<jelmer> luke-jr: it depends on that
<Odd_Bloke> luke-jr: How did you install it?
<jelmer> luke-jr: well, the Debian/Ubuntu package does at least
<luke-jr> Odd_Bloke: emerge -vauDN world
<Odd_Bloke> Who does the Gentoo packaging?
<luke-jr> whoever maintains the bazaar overlay?
<Odd_Bloke> luke-jr: https://edge.launchpad.net/bzr-gentoo-overlay ?
<Tak> anyone seen segfault when interacting with a svn repo using bzrlib via libpython?
<luke-jr> I think
<zooko> Tak: I'm not sure about that.  I'll think about it while writing some notes about the project ideas.
<Tak> well, if you get a fuse frontend, then to bzr (or anything using it), it'll just look like a filesystem ...
<jelmer> Tak: do you have a (C) backtrace with debugging symbols?
<zooko> That is true, but there might be advantages in terms of distributed security if the revision control tool is more aware of the Tahoe namespace.  I'm not sure yet.
<Tak> I have a mono backtrace with no debugging symbols... ;-)
<zooko> Tak: writing this Project Idea, I realized that Tahoe already has a working command-line which accomplishes the same thing, in batch mode.
<zooko> Tak: http://allmydata.org/trac/tahoe/ticket/663 # integrate a distributed revision control tool with Tahoe
<dash> hi. trying to understand version dependencies for bzr-svn -- i've created a repo from the Twisted svn repo using the latest revisions of bzr and bzr-svn (using svn-import); will this interoperate ok with clients using bzr 1.12 and bzr-svn 0.5?
<jelmer> dash: yes
<jelmer> dash: 0.5.x interoperates with 0.5.x
<dash> ok, great.
<mwhudson> Peng_: ping?
<jfroy> lifeless: https://bugs.launchpad.net/bzr/+bug/344465
<ubottu> Ubuntu bug 344465 in bzr "Distribution archives for 1.13 do not contain generated C extension modules" [Undecided,New]
<jfroy> jelmer: any idea about https://bugs.launchpad.net/bzr-svn/+bug/342065/? It's kind of crippling not being able to get diffs :/
<ubottu> Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,Incomplete]
<mwhudson> abentley: hi
<abentley> mwhudson: hi
<jelmer> jfroy: no, not yet
<mwhudson> abentley: i have this memory that ages and ages ago you complained about not liking the way loggerhead split the list of files changed in a revision into added/renamed/removed/modified
<scgtrp> i'd like to have my own branch of my project, available on the same server as the main branch, but i'd also like to be able to commit to it when i'm offline. is there any way to do that besides branching to another dir on the server then branching again locally?
<jelmer> jfroy: It'd require some analysis of the repository again, and I don't have time for that atm
<jelmer> jfroy: maybe later this week, sorry
<abentley> mwhudson: Yes, I prefer status --short output.
<jfroy> jelmer: interestingly, I just updated bzr-svn, wiped the svn cache, re-checked out from svn, and I haven't hit the exception again. Will continue testing...
<mwhudson> abentley: what i don't remember is what you would have preferred to see
<jfroy> jelmer: no worries
<abentley> mwhudson: ^^
<mwhudson> ah
 * mwhudson doesn't know what status --short looks like
<mwhudson> oh
<mwhudson> M file
<abentley> Yes, that kind of thing.
<mwhudson> RM old_path => new_path
<abentley> In loggerhead, it could be graphical of course.
<mwhudson> yeah
 * mwhudson does wonder slightly how loggerhead would cope with e.g. a kind change at the moment
<mwhudson> not well, i suspect
<mwhudson> abentley: i'm not really sure what 'being graphical' would mean here
<mwhudson> if you could come up with nice icons for each of the letters status can spit out that would be cool
<mwhudson> but i'm not even sure what icon "M" would need
<abentley> mwhudson: That's what I meant by being graphical.
<mwhudson> abentley: in other news, i'm thinking of moving away from tree.changes_from and so TreeDelta
<abentley> mwhudson: I don't know what all the icons would be, but tools such as Meld have tried to show this kind of thing-- might be interesting to investigate.
<mwhudson> abentley: probably to iter_changes() -- does that sound sane?
<abentley> mwhudson: Yes, and very amenable to status --short output.
<abentley> I think "new" is usually signified by a gleam, and deleted by an X or trash can.
<mwhudson> abentley: cool
<mwhudson> the fact that TreeDelta has an "unchanged" attribute just seems gratuitously silly for my usage
<abentley> mwhudson: I wrote the original iter_changes, so I'm all about that.
<abentley> mwhudson: You'll probably want to just implement your own ChangeReporter, which is a pretty simple interface.
<mwhudson> ok, i was wondering if there was something like that
<Peng_> mwhudson: Pong, if it's quick.
<mwhudson> Peng_: just wondering if you wanted me to land your branch or if you would
<Peng_> mwhudson: Which one?
<Peng_> Oh.
<mwhudson> get_apparent_authors
<Peng_> mwhudson: I dunno. I can do it right now.
<mwhudson> Peng_: go for it
<Peng_> mwhudson: Alright. Thanks for the review. :)
<mwhudson> abentley: the _ChangeReporter.report interface looks pretty nice, thanks for the hint
<abentley> mwhudson: np
<mwhudson> Peng_: np, it took me a while to get to it
<Peng_> mwhudson: Done.
<Peng_> Boy, pushing to an old pack repo feels slow. Btrees have really spoiled me.
<mwhudson> i guess we should update to 1.9 at some point
<beuno> that would be nice
<beuno> I'm a big fan of 1.9
<mwhudson> Peng_, beuno: done
<beuno> awesome
<exarkun> `bzr svn-import --incrementalÂ´ takes 8 or 9 seconds on this repository.  Any chance it will be faster soon?
<mwhudson> i wonder if the # of branches in the twisted repo is the problem
<exarkun> Do you think it would be the number of branches at HEAD or the number of branches ever?
<mwhudson> at HEAD i hope
<exarkun> There's 541 branches at head
<exarkun> I could probably delete a few hundred of them :)
<mwhudson> just wildly speculating of course
<mwhudson> that's probably more than jelmer expected :)
 * exarkun nods
<exarkun> I haven't written the program that automatically finds branches associated with closed tickets and deletes them, yet, though.
<exarkun> Maybe I'll try that now.
<exarkun> And then compare the times
<Peng_> mwhudson: Oh, cool.
<Peng_> mwhudson: Thanks. :)
<mwhudson> np
<mwhudson> there certainly is some O(branch count) stuff in svn-import
<mwhudson> no idea how expensive it is for the no-change case
<Peng_> mwhudson: You said the pretty-url branch is ready to land, aside from the merge conflicts, right? I just fixed them. What do you want me to do?
<mwhudson> Peng_: where is your branch?
<Peng_> mwhudson: Ehh, didn't register it on LP yet, but http://bzr.mattnordhoff.com/loggerhead/loggerhead/pretty-url/
<bignose> where do I set a user-specific ignore pattern that should apply for every branch that user works in?
<bignose> I expected to find this in the documentation for âconfigurationâ and âignoreâ, but it's not in either of those.
<LarstiQ> bignose: ~/.bazaar/ignore
<bignose> LarstiQ: thanks. Where would I have found that documented?
<LarstiQ> bignose: I agree those two should mention it.
<LarstiQ> bignose: unfortunately, I know too much.
<LarstiQ> bignose: I was curious, how did you write the rst for the builddeb Debian manpage, entirely from scratch?
<Peng_> mwhudson: Hmm, pretty-url seems to break +revlog. Hold on.
<bignose> LarstiQ: no, I wrote it in reStructuredText
<bignose> LarstiQ: or do you mean, how did I write the reST?
<bignose> the reST I wrote mainly by copy-and-paste.
<LarstiQ> bignose: that's what I meant
<mwhudson> Peng_: it seems to break rather a lot
<LarstiQ> bignose: ah :)
<LarstiQ> bignose: I'm still impressed though ;)
<Peng_> mwhudson: Indeed.
<mwhudson> Peng_: like "all links"
<mwhudson> http://localhost:8080/http%3A//localhost%3A8080/revision/1243 don't look right to me
<bignose> LarstiQ: but generating reST would be (I presume, with the confidence of the ignorant) simple for someone who understands the Bazaar help system
<Peng_> mwhudson: Yeah.
<Peng_> Um.
<LarstiQ> bignose: reST itself is no problem.
<bignose> (just realised that your original question did ask about the reST and I missed it)
 * LarstiQ looks at it again to recall what he was impressed about
<bignose> yay for IRC encouraging rapid response over careful reading :-)
 * LarstiQ grins
<mwhudson> Peng_: has the branch always done this, i wonder?
<LarstiQ> bignose: I think it's a combination of it seeming like a clear document to me, and clearing my backlog making it appear like it appeared instantly.
<Peng_> mwhudson: Dunno.
<bignose> :-)
<Peng_> mwhudson: Yes, it has.
<bignose> I'm happy to leave that illusion unchallenged
<mwhudson> Peng_: oops
<LarstiQ> bignose: thank you :)
<Peng_> mwhudson: Stupid question: What's static_url used for?
<Peng_> Oh, duh.
<mwhudson> Peng_: images, css, javascript
<Peng_> mwhudson: OK, if you stop it from escaping BranchWSGIApp.url, it seems to work, but I don't know if all of the other changes make sense, or if I'm just lucky because I have simple URLs.
<trondn> I have heard that the bzr revno may go up and down.. is there another id i can get and use to get a log of everything I just pulled?
<mwhudson> Peng_: i think perhaps rejection is in order
<LarstiQ> trondn: revision ids are stable, revnos are indeed derived.
<mwhudson> i don't hate %7E in urls _that_ much
<trondn> (ex. I just pulled lp:drizzle/mordred and had rev 942.. after a pull I got revno 939.. the bzr log -v -r 942..939 fails)
<LarstiQ> trondn: for looking at what I just pulled, I usually use `bzr pull -v`, does that help?
<trondn> LarstiQ: how do I get the revision id?
<LarstiQ> trondn: bzr log --show-ids outputs them for example
<mwhudson> trondn: ugh, tell people to not do things like that do their branches :)
<mwhudson> if it's an 'integration branch' you should integrate by merging in new things and committing
<trondn> is there a shorthand for the latest revision??? on mercurial I may use -r tip ???
<mwhudson> trondn: -r -1
<Peng_> mwhudson: I think at least some of the changes are probably a good idea -- like using urlutils instead of urllib, and maybe running unescape_for_display over served_url.
<trondn> mwhudson: I'm modifying a hudson plugin ;)
<mwhudson> trondn: haha
<Peng_> trondn: Alternately -r head:
<mwhudson> threads about hudson always weird me out
<trondn> mwhudson: well, the bazaar plugin for hudson didn't work in a "master-slave" configuration, so I'm rewriting it... right now I'm trying to get the log there...
<mwhudson> Peng_: if you say so :-p
<Peng_> mwhudson: I'm just saying, if it didn't completely break everything, this branch might be worth merging. :D
<phinze> sigh, so i just had the bazaar-hookless-email script bring one of my group's dev servers to its knees
<LarstiQ> phinze: eek
<LarstiQ> phinze: how so?
<phinze> i had foolishly set it to crontab every 5 minutes
<LarstiQ> and it didn't complete within 5 minutes?
<phinze> and apparently an instance of it started spinning off longer than 5
<phinze> and the next one started
<LarstiQ> right
<phinze> and the next one
<LarstiQ> phinze: any reason you're not running it in daemon mode?
<phinze> LarstiQ: mostly because it was the fastest solution to the problem at hand (i wanted to keep an eye on the commit stream of several branches, as i'm usually the guy called in to resolve bzr problems)
<phinze> LarstiQ: do you think daemon mode would prevent it from eating up all the server's resources?
<phinze> i'm trying to think of what would cause it to spin off at 100% like it's doing
<LarstiQ> phinze: I'm not going to guarantee that :)
<phinze> just chugging through a big diff maybe?
<LarstiQ> phinze: but it's what we run
<Peng_> mwhudson: Mind if I vote resubmit?
<LarstiQ> phinze: also, you're not fork bombing
<LarstiQ> phinze: although for cron it should check if there is a previous instance and bail out if that is the case
<phinze> LarstiQ: right that is what i should have done from the get-go
<LarstiQ> phinze: 5 minutes running time sounds like a lot evenso, so if you can figure out where that time went that would be great
<phinze> LarstiQ: yeah i'm looking into it -- running it in foreground and it just chugs at 100% until i get scared and kill it
<phinze> LarstiQ: trying to figure out how to get it to give me some better output
<Peng_> mwhudson: Well, I just did. :P
<LarstiQ> phinze: it has a log output option, though not overly verbose
<LarstiQ> phinze: strace?
<phinze> LarstiQ: not installed on the server :(
 * LarstiQ blinks
<mwhudson> Peng_: thanks
<LarstiQ> phinze: other diagnostic tools?
<phinze> LarstiQ: it's an old crufty box that is long overdue for a rebuild
<phinze> LarstiQ: i might be able to get strace on there though
<phinze> hmm wait
<phinze> i can just tar up the repo
<phinze> only 115M
<LarstiQ> phinze: smart thinking :)
<LarstiQ> evening jfroy_
<jfroy_> LarstiQ: yo
<phinze> alllright, here comes strace and here goes my local machine's performance
<phinze> :)
<LarstiQ> phinze: it's for the greater good, godspeed! :)
<phinze> LarstiQ: okay 1m41s running time locally w/ strace
<phinze> 100% during, but it does stop
<phinze> what's this about "The program doesn't like to watch empty branches.
<LarstiQ> I don't recall that string.
<phinze> README:111
<LarstiQ> oh
<phinze> it's a rather vague and ominous statement
<LarstiQ> yeah, makes sense.
<LarstiQ> phinze: sorry :)
<phinze> ahh did you write it?
<LarstiQ> phinze: when there are zero revisions in a branch, you get into corner cases.
<LarstiQ> phinze: I didn't touch the README, but my fingers are over some of the code, yes.
<BasicOSX> Submitted [merge], bundle buggy did it's job, 2 core developers approved, do I need to ask someone to merge or can I submit to PQM?
<phinze> ahh cool, well thanks for your work on it; it fills a very important need
<phinze> i don't think we have any branches with zero revisions
<phinze> well i've got to run
<phinze> i'll continue to look into this
<phinze> LarstiQ: thanks for your help; i'll keep you posted
<LarstiQ> BasicOSX: without more context, you could submit it, if I'm still up to date on the process.
<LarstiQ> phinze: cool
<BasicOSX> LarstiQ:  Bundle Buggy is just a communication tool, has nothing to do with PQM ?
<LarstiQ> BasicOSX: there is some judgement involved, say with possibly contentious patches and not everyone has had a chance to vote yet
<LarstiQ> BasicOSX: right
<BasicOSX> Mine is a simple documentation change :-)
<LarstiQ> BasicOSX: that sounds relatively safe :)
<LarstiQ> BasicOSX: which one is it?
<BasicOSX> Bug #343928 gnu changelog was documented incorrectly
<ubottu> Launchpad bug 343928 in bzr "GNU ChangeLog output can now be produced by bzr log --format gnu-changelog is incorrect" [Undecided,Fix committed] https://launchpad.net/bugs/343928
<LarstiQ> BasicOSX: yeah, I'd go ahead
<BasicOSX> LarstiQ:  first PQM to bzr.dev, what's the location.conf's submit_branch? http://bazaar-vcs.org/bzr/bzr.dev/ ?
<lifeless> http://bazaar-vcs.org/bzr/bzr.dev
<Kobaz> trying to start the latest version of loggerhead: ImportError: No module named simplejson
<Kobaz> where would i get simplejson?
<mwhudson> Kobaz: oh oops
<BasicOSX> Kobaz:  pypi?
<mwhudson> it's included with python2.5, but under a different name i think
<mwhudson> Kobaz: what version of python are you running?
<Kobaz> 2.5
<mwhudson> Kobaz: one moment
<Kobaz> ii  python2.5                        2.5.2-14
<mwhudson> ah, nuts, json is only in 2.5
<mwhudson> Kobaz: oh, if it's debian/ubuntu "apt-get install python-simplejson'
<mwhudson> ah, nuts, json is only in 2.6
<mwhudson> is what i meant to say...
<Kobaz> python-simplejson - Simple, fast, extensible JSON encoder/decoder for Python
<Kobaz> i guess i need that?
<mwhudson> yes
<Kobaz> heh
<Kobaz> i <3 debian
<Peng_> mwhudson: The new dependency should be added to the documentation.
<mwhudson> Peng_: good point
<Peng_> Not that I'm volunteering. ;-)
<Kobaz> okay so
<Kobaz> i have https://bzr.local/webbzr/
<Kobaz> i have a few directories in the base (not repo's)
<Kobaz> and then i click on one... and the link goes to /webbzr/directory
<Kobaz> but then it redirects to /directory
<Kobaz> which isn't found... of course... since the base directory of loggerhead is /webbzr
<mwhudson> do we think easy_install simplejson will work?
<Kobaz> why is it doing the redirect?
<mwhudson> Kobaz: did you start loggerhead with the --prefix option?
<Kobaz> nope
<Peng_> mwhudson: Well, it's on PyPI, so it should...
<mwhudson> Peng_: good enough for me :)
<mwhudson> Kobaz: well you should :)
<Kobaz> heh
<Kobaz> k
<mwhudson> ./serve-branches --prefix webbzr
<Kobaz> ooo
<Kobaz> yeah
<Kobaz> that worked
<Kobaz> oh that works much better
<Kobaz> To get this branch, use:
<Kobaz> bzr branch http://bzr.local/webbzr/project/base/trunk
<Peng_> mwhudson: You're updating the README, then?
<Kobaz> that's not my branch url
<Kobaz> how would i set that?
<mwhudson> Peng_: just did yeat
<Kobaz> the branch url is http://bzr.local/bzr/project/base/trunk
<mwhudson> Kobaz: you need to hack sourcecode at the moment :/
<Kobaz> aww
<Kobaz> i have auto_publish_folder set
<Kobaz> i guess it doesn't use that?
<mwhudson> um
<mwhudson> if you're using serve-branches
<mwhudson> loggerhead.conf is entirely ignored
<Kobaz> yeah i'm using serve-branches
<Kobaz> oh
<mwhudson> mmm
<mwhudson> i guess loggerhead really should use the public location of the branch, if that's set
<Kobaz> hmm
<Peng_> Hmm, I don't think I set the public location of my branches.
<Kobaz> but the only way to serve multiple branches is via serve-branches right?
<Peng_> Kobaz: start-loggerhead can serve multiple branches, but you should use serve-branches.
<Kobaz> heh
<Kobaz> mm, i broke it
<Kobaz> as soon as i view a directory containing versioned files... it completely dies
<mwhudson> as in, exits?
<Kobaz> trunk/files
<Kobaz> that works
<Kobaz> and then..
<Kobaz> Though the site seems valid, the browser was unable to establish a connection.
<Kobaz> * Could the site be temporarily unavailable? Try again later.
 * mwhudson wonders if http://pastebin.ubuntu.com/132731/ makes sense
<Kobaz> etc etc
<Peng_> mwhudson: Mind if I change it to import json if simplejson isn't available?
<mwhudson> Peng_: not at all, does loggerhead work at all with 2.6 though?
<lifeless> jam: mail for you re: bbc
<Peng_> mwhudson: ...I have no idea, but it won't hurt.
<lifeless> we really must stop PackRepository being a subclass of KnitRepository some day
<Kobaz> ooooh
<Kobaz> it's redirecting to http://
<Kobaz> my loggerhead is on https
<Kobaz> and the links are going to http
<mwhudson> Kobaz: oh right
<mwhudson> Kobaz: there's a bug about that
<Kobaz> hehe
<Kobaz> anyways
<mwhudson> basically there's no way for serve-branches to know it's being run behind https
<Kobaz> dinner time
<Kobaz> time to bust out of the orfice
<Kobaz> well. maybe make a setting to either prefix http or https
<mwhudson> Kobaz: right
<Peng_> mwhudson: So do you mind if I push trivial changes like this straight to lp:loggerhead without review?
<Kobaz> well
<Kobaz> actually
<Kobaz> you shouldn't do the full url
<mwhudson> Peng_: go for it
<Kobaz> do relative urls... and that would fix it
<mwhudson> Kobaz: probably that too
<Kobaz> don't make links with http://servername
<Kobaz> do /prefix/dir/file
<Kobaz> that's what i always do and https/http is never an issue
<Peng_> mwhudson: Alrighty.
<mwhudson> Kobaz: i believe redirects need to be absolute urls
<Kobaz> they dont
<Kobaz> atg least in firefox
<Kobaz> anyways
<Kobaz> bustin out
<mwhudson> they do in rfc2616 though
 * igc breakfast
<lifeless> breakfast
<lifeless> and then commit for a bit
<lifeless> igc: talk with zooko: re gsoc, may be something in common
<igc> zooko: I've added http://allmydata.org/trac/tahoe/ticket/663 to http://bazaar-vcs.org/SummerOfCode2009
#bzr 2009-03-18
<zooko> igc: cool!
<igc> zooko: please let us know if you have more ideas or anyone interested in being a GSoC student
<zooko> Will do.
<lifeless> igc: you have a present
<arjenAU> ok, got a merge/rename issue
<arjenAU> just trying to figure out how to make it jive
<arjenAU> trying to pull a branch (including all its revisions)  into another tree. now this has been done before (drizzle plugins) so I know it can be done.
<arjenAU> I branch off the original, create a subdir of choice, then move files from the branch into that subdir, then commit (so the commit contains the creation of hte dir plus the renames).
<arjenAU> branch off the mainline I want to pull in to. bzr merge -r1..-1 from the branch where I just did the rename foo
<arjenAU> then it goes weird.
<arjenAU> the subdir doesn' exist yet but its parent does, so the parent of the mainline gets renamed to .moved. but also the files inside the newly merged dir get shows as base/other. this makes no sense as there is no conflict
<arjenAU> thoughts anyone? lifeless poolie
<poolie> i think you want -r0..-1 there not -r1
<poolie> otherwise it will try to merge everything but the first revision
<lifeless> arjenAU: I suggest the merge-into plugin
<lifeless> arjenAU: it automates all of this
<arjenAU> poolie: ah was stewart trying to confuse me ;-) this is what he wrote earlier
<arjenAU> lifeless: oh does it!
<igc> lifeless: ? in email?
<igc> lifeless: fast commit maybe?
<lifeless> igc: yes indeed
<lifeless> jelmer: you too may be interested in CommitBuilder.record_iter_changes
<lifeless> igc: btw
<lifeless> +            parents = graph.get_parent_map(revision_ids)
<lifeless> +            self.revision_ids = [r for r in revision_ids if r in parents]
<lifeless> if you don't need the ordering
<lifeless> self.revision_ids = list(parents)
<lifeless> will be faster
<arjenAU> poolie: ok your hint gets me a fair way there. apart from the plugin, how to resolve the .moved thing; which things do I move where to resolve it properly?
<igc> lifeless: right. I haven't thought of that. I'm not sure if the ordering is important in send. abentley?
<lifeless> igc: I suspect it topo sorts lower down tbh
<igc> lifeless: and well done on record_iter_changes()
<lifeless> igc: so you're likely causing multiple index reads with the current code; I'd suggest combining the filtering and topo sorting steps
<lifeless> igc: thanks; proof will be in the pudding
<igc> lifeless: I won't get it reviewed today sorry. I'm off in an hour
<lifeless> igc: oh, I wasn't asking for you to review; just that you can merge it and use it in fastexport
<lifeless> :)
 * spiv just sent a patch for https://bugs.edge.launchpad.net/bzr/+bug/109143
<ubottu> Ubuntu bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,Fix committed]
<poolie> arjenAU: something like this
<poolie> bzr mv parent parent.new
<poolie> bzr mv parent.moved parent
<poolie> bzr mv parent.new/subdir pante
<poolie> (should be) bzr mv parent.new/subdir parent
<poolie> then parent.new should be empty so
<poolie> rmdir parent.new
<poolie> also you could file a bug because we shoudl be able to do better
<arjenAU> poolie: well the merge-into plugin apparently does it? says lifeless
<arjenAU> just trying to do it without so I know hwat's going on
<arjenAU> i'll try what you wrote. I did something similar but got something wrong along the way
<lifeless> igc: send uses a set there
<lifeless> igc: so its definitely not order sensitive
<arjenAU> poolie: I think your method did the trick, thanks.
<jml> spiv: re: Support bzr+ssh://host/~/path: thanks! now we're going to have to fix Launchpad :)
<mwhudson> jml: you mean to make push bzr+ssh://bazaar.launchpad.net/~/launchpad/foo work?
<jml> yeah.
<mwhudson> well
<mwhudson> Low
<jml> :D
<jfroy> spiv: awesome!
<spiv> jml: easy to do, though
<lifeless> orthogonal even
<spiv> jml: set the initial working dir in your server to /~foo rather than /
<spiv> jml: oh, and teach the server to accept --directory=/ in the bzr serve invocation
<spiv> er,
<spiv> jml: oh, and teach the server to accept --directory=. in the bzr serve invocation
<lifeless> I hear VFS's are good at changing things
<poolie> hm
<spiv> as lifeless says, you could treat the path /~/ specially already for clients that don't interpret it specially.
<poolie> i want to rethink almost always having the username in the branch url
<poolie> many things that are not series are still project wide
<jml> poolie: for Launchpad?
<poolie> mm
<poolie> but not this month :)
 * lifeless breathes out
<lifeless> poolie: did my reply about your changes to test_remote make sense
<poolie> yes i think so
<lifeless> cool
<poolie> i'll revisit it after lunch
<poolie> was too tired to work out the right thing last night
<poolie> heh, and ironically enough jml was distracting me by talking about whether anything is objectively right or not :)
<jml> poolie: *I* was distracting *you*?!
<poolie> very much :)
<jml> see. that's subjectivism for you.
<Peng_> How much more efficient will BBC be over dumb protocols like http than btrees?
<Peng_> I've gotten really spoiled by the hpss streaming stuff, so now http feels slow. :P
<Peng_> You're planning to start versioning the Pyrex .c files? Why? So users won't need it?
<BasicOSX> Because testsuite passed on 1.13final but the Pyrex stuff isn't in the tarball
<Peng_> That's a different issue.
<Peng_> Well, versioning the .c files is a way to solve it, I guess.
<BasicOSX> Since I caused the problem, I'll beg to differ, ...exactly :-)
<BasicOSX> I did open a bug about a warning that pyrex wasn't installed when I ran the test suite, but everything passed and a discussion between several developers presented versioning the .c as a way to prevent this sort of thing
<spiv> Peng_: there was a brief discussion about it on the list about a week ago, IIRC.
<Peng_> spiv: Oh. I must've missed that.
<BasicOSX> Bug #340209
<ubottu> Launchpad bug 340209 in bzr "The python package 'Pyrex' is not available under ubuntu when python-pyrex is installed" [Undecided,New] https://launchpad.net/bugs/340209
<spiv> Or perhaps in a bug?
<Peng_> It'll make for uglier diffs on the rare occasion they're changed.
<BasicOSX> I got a tweak status on Bungle Buggy, I read the HACKING doc, still don't know what it means exactly, any more info?
<spiv> It'll make tracking bzr.dev easier and the release process a bit simpler too.  My main worry is that we wouldn't want the versioned .c files to get out of sync with their source .pyx files.
<spiv> Peng_: bug 336933
<ubottu> Launchpad bug 336933 in bzr "version control the pyrex output files" [Wishlist,Triaged] https://launchpad.net/bugs/336933
<spiv> (hey cool, that bug number almost has rotational symmetry)
 * spiv looks forward to bug number 886988 ;)
<Peng_> spiv: Oh, thanks for the link.
 * igc lunch and medical stuff for the rest of the day
<lifeless> spiv: I want pqm to update them, and noone else to
<lifeless> BasicOSX: there is an older bug vis-a-vis the .c files, your incident is just meat for the grinder reinforcing it :)
<lifeless> BasicOSX: it means 'make the recommended changes please [ unless you disagree in which case discuss ] and then submit it to pqm'
<spiv> BasicOSX: http://bundlebuggy.aaronbentley.com/help describes the meaning of the different votse.
<spiv> "votes", rather
<adelie42> Ok, I screwed up. My initial commit was of the wrong package. How do I start over?
<adelie42> sorry in advance for the "save the noob" question"
<lifeless> adelie42: uncommit or delete
<lifeless> adelie42: e.g. rm -rf bad-branch :P
<adelie42> ok, that is what I ended up doing. deleted everything, did an uncommit, pulled the right trunk (well, source which wasn't bzr), bzr add, bzr commit, bzr push
<adelie42> guess that more or less took care of it
<mwhudson> hey, do you know something
<mwhudson> lazy inventories would be a really good idea
<lifeless> mwhudson: we have them
<lifeless> mwhudson: see --gc-chk255
<mwhudson> lifeless: yes i know
<mwhudson> sadly, not every branch on launchpad is going to have them for a goodly while
<lifeless> mwhudson: once we have a production format, we can nagware on them :)
<Peng_> What, you can't force everyone to upgrade or delete their branches? ;-)
<lifeless> mwhudson: anyhoo; you're facing 'fast on xml' vs 'fast on chk' ?
<mwhudson> Peng_: well, 'can' is a vague concept
<mwhudson> lifeless: well, i think i can avoid loading inventories at all in quite a large number of cases, but it requires vague contortions
<mwhudson> lifeless: it's 'fast on everything' vs 'fast on chk'
<mwhudson> (well, text extraction is faster on chk right?  so it will still be faster there)
 * mwhudson goes to fix more obvious sillinesses
<lifeless> mwhudson: fast on everything is good; but I don't see how you can avoid inventories except when only showing revisions
<mwhudson> lifeless: by slightly extending the information loggerhead already caches
<lifeless> mwhudson: mmmmm if this is fileid,revid pairs, then its not a slight extension
<mwhudson> i can avoid loading inventories on revision pages when the revision's been seen by the cache
<mwhudson> lifeless: something like that
<lifeless> mwhudson: I'd be happier hearing that your moving closer to the bzr metal, not further;)
<mwhudson> yeah
<mwhudson> i don't know whether it's worth it
<lifeless> how many things in CS cannot be solved by adding a layer
<mwhudson> anyway, let me go for sane use of bzr api first off, indeed
 * mwhudson finds a todo in the bzr source from version 0.0.6
<lifeless> mwhudson: which one
<mwhudson> lifeless: unifying get_revision_inventory with get_inventory
<mwhudson> lifeless: how evil is constructing revisiontrees directly?
<mwhudson> eh, maybe i can just cache them somewhere (per request)
<lifeless> mwhudson: repo.revision_trees([list]) should be very fast
<mwhudson> lifeless: .25s per revision for launchpad
<adelie42> I got a new project I want to work on, but there is no bazaar trunk. There are three brances of the packaging information, but not for the osurce (https://launchpad.net/ubuntu/+source/kdegames). Is the best thing to do just to start a branch, call it source, and branch off of that? What is the way to be doing this?
<pygi> adelie42, https://code.launchpad.net/kdegames
<pygi> jelmer's branch doesn't seem to be packaging
 * mwhudson wants bzr 1.13 on launchpad
 * pygi looks
<Peng_> mwhudson: Why? Streaming?
<pygi> yup, it seems code
<mwhudson> Peng_: yes
<mwhudson> Peng_: i feel fairly confident that roundtrips affect me more than you :)
<adelie42> https://code.launchpad.net/kdegames is only the code for the installation data, not kdegames source
<lifeless> mwhudson: .25s for repo.revisions_trees(50 items), or .25s*50, or .25s for repo.revision_trees([1 item]) ?
<Peng_> mwhudson: Heh, good point.
<Peng_> The bad thing about all these performance improvements is that it makes old versions feel so slow. :(
<pygi> adelie42, https://code.launchpad.net/~jelmer/kdegames/trunk
<pygi> ?
<mwhudson> lifeless: well, futzing with timeit, it's .25 for one revid, and .45s for two
<adelie42> ah
<mwhudson> lifeless: i don't care about more than 2 :)
<lifeless> mwhudson: oh, I'd assumed you'd care about the full page
<pygi> adelie42, not sure it's most recent obviously :p
<mwhudson> lifeless: ?
<lifeless> Peng_: are you noticing improvements?
<adelie42> pygi: ok, it looks like that was what I was about to make
<adelie42> thanks
<lifeless> mwhudson: revision_trees does one batch IO to read all the deltas, and then composes them separately, its _way_ faster than doing separate calls- N rather than N^2 roughly
<lifeless> modulo constants etc
<mwhudson> lifeless: no request in loggerhead (now, anyway) considers more than two revisions
<mwhudson> uh
<mwhudson> revisiontrees
<lifeless> mwhudson: ok
<lifeless> mwhudson: how do you populate the 'files changed' then, for the history view
<mwhudson> lifeless: ajax
<mwhudson> one revision at a time
<lifeless> mwhudson: oh right; isn't that slow?
<johnf> Can anyone test bzr 1.13 from the beta-ppa before I roll it out to the main ppa?
<lifeless> johnf: does your build have the .so's ?
<mwhudson> lifeless: if everyone who loads a changelog page clicks 'expand all', it's a pessimisation overall yes
<johnf> lifeless: hmm let me check
<Peng_> lifeless: Pushing a handful of revisions to my bzr.dev server takes 11 seconds at the most (and that's including push-and-update). I pushed to LP today, and it took 28. So, yes, major improvements. :)
<lifeless> Peng_: sweet.
<lifeless> Peng_: how does that compare to hg now? still quite a bit slower I imagine
 * mwhudson wonders when his commit to lp:loggerhead is going to complete
<Peng_> lifeless: I have no clue at all. I haven't done any small pushes with hg recently.
<spiv> Peng_: hooray
<johnf> lifeless: _patiencediff_c.so ?
<Peng_> lifeless: Pushing ~17 revisions in hg took 3.41 seconds, so there's still a ways to go, I guess.
<lifeless> johnf: should be 5 or so
<lifeless> johnf: the 1.3 tarball failed to include many .c files - see the list
<johnf> ok
<lifeless> johnf: running 'setup.py build_ext -i' will generate the .c files
<lifeless> as long as you have pyrex installed
<lifeless> uhm
<johnf> ahh that could be the problem I had earlier
<lifeless> do this - read the release notes for release managers
<lifeless> these tell you how to get the .c files
<lifeless> then stash them into a patch for your 1.13 build
<lifeless> and you can use your normal build procedure to do that
<johnf> is that something new? or has it always been the case?
<johnf> I'll update debian/rules to do it
<lifeless> johnf: its a 1.13.tar.gz special
<lifeless> won't be needed for 1.13.1
<johnf> lifeless: before I spend time on this is 1.13.1 coming out in the next few hours or next few days?
<johnf> short on time at the moment. vquence product launch is tomorrow
<johnf> actuallty I've worked it out so doesn't matter
<lifeless> johnf: :P
<poolie> johnf: congratulations :)
<poolie> re the launch
<johnf> poolie: thanks!
<lifeless> johnf: indeed, grats
<johnf> lifeless: what are your thoughts on the old packages for unsupported releases in the ppa. eg 1.12 package for feisty. Should we delete them?
 * fullermd notes that he just shrugged and added a pyrex dependancy to building the 1.13 port.
<fullermd> It's so tiny, 's hardly worth even questioning about.
<lifeless> johnf: no thoughts offhand - mail the list?
<lifeless> spiv has headed off
<lifeless> I'm halt()ing
<lifeless> we got the smart server not making third party requests today, but that will land tomorrowish - some polish needed
<lifeless> it reveals that branching from a stacked branch is actually only 23 hpss client calls
<lifeless> poolie: ^
<poolie> lifeless: nice
<poolie> johnf: is there any benefit in deleting them?
<poolie> i wouldn't
<johnf> poolie: nah just that they are hanging around and will be fairly old in a few months.
<johnf> ok new bzr packages with .so files in. Could someone pease give beta-ppa a quick test?
<poolie> oh i see and they're not being replaced by new ones
<poolie> still, i probably wouldn't worry
<poolie> maybe add a note to the ppa description that they're not being updated?
<poolie> it might be better than nothing though...
<johnf> ok good idea
<johnf> ok on the basis that no one has complained or cares to check I'm going to release the 1.13 packages to ~bzr ppa
<lifeless> mwhudson: where in python are files implemented?
<lifeless> johnf: you've given it a spin ?
<johnf> yup
<lifeless> then its been tested :P
<johnf> well an update, commit and bzr bd anyway :)
<johnf> I haven't used copy between PPAs before. Should I just reuse existing binaries or rebuild
<johnf> done
<sabdfl> hi folks
<sabdfl> bzr: ERROR: Specified file "arch/ppc/mm/Makefile" is outside the current view
<sabdfl> how do i fix that?
<sabdfl> all i'm doing is init and add of a large tree
<lifeless> sabdfl: that looks like a bug in views; views only apply to the development tree format, so I'm assuming you are experimenting with brisbane-core
<mwhudson> lifeless: Objects/fileobject.py
<sabdfl> yup
<lifeless> sabdfl: uhm to fix it, you could bzr remove-tree, bzr reconfigure --(looking)
<lifeless> sabdfl: and please do file a bug that this happened, it suggests an issue with the default heaviour of views)
<lifeless> bzr remove-tree && bzr reconfigure --tree
<lifeless> doing that immediately after 'init' before add should fix it, I hope
<lifeless> or perhaps 'bzr view --delete --all'
<sabdfl> view --delete --all doesn't help
<sabdfl> view --switch off doesn't help either
<lifeless> sabdfl: we're mainly testing with large imports not fresh trees. I'll file a bug for you as it sounds like its generally borking in some respect
<lifeless> sabdfl: what specific format is this with, and how are you invoking add - 'bzr add', 'bzr add .', 'bzr add *', something else?
<lifeless> sabdfl: I'm sorry that I can't dig deeper right now, social event kicking off around me
<lifeless> mwhudson: I was trying to figure out why my parallel test runner was buffering 90 odd lines (from a child process)
<sabdfl> lifeless: am init'ing as follows
<sabdfl> bzr init --format=gc-chk255-big
<sabdfl> find [a-z]* -type f -exec $bzr --no-plugins add \{\} \+
<lifeless> sabdfl: I'd try just 'bzr --no-plugins add', as we scan for paths ourselves. Filing bug and am gone. (sorry!)
<mwhudson> lifeless: good luck with that
<sabdfl> ok thanks
<sabdfl> bzr add Just Worked (nice!) but there are still problems with views later, when I try to add a specific file it fails
<sabdfl> even if i switch views off
<sabdfl> igc: ^^
<j^> is it possible to merge two bzr repositories into one, keeping the history from both repos?
<bob2> j^: branch? yes
<igc> sabdfl: I'll take a look
<sabdfl> thanks igc
<j^> bob2, no not branch, guess it somewhat works with join/split
<bob2> j^: are you sure you don't mean branches?
<bob2> j^: "merging" repositories is just a matter of branching all the branches from one to another
<igc> sabdfl: try rev 3889 of brisbane-core now
<spiv> bob2: j^ thought you meant the command, "bzr branch"
<bob2> oh right
<spiv> j^: your question doesn't quite make sense in bzr terms; perhaps you meant to ask "is it possible to merge two branches with unrelated history?".  Yes; use "bzr merge -r0..-1 url/of/other/branch"
 * igc afk - might be back later
<d-b> hi i'm trying to use bzr, i want to look at revisions not diffs and grab one... any guis ?
<d-b> i get a float division if i put . for branch location
<j^> spiv, ah so i can merge branches with unrelated history, thats what i was looking for yes, have to projects that turned out to be one now. so wanted to get them in one branch
<lamont> bzrlib/_dirstate_helpers_c.c:330: warning: cast from pointer to integer of different size
<lamont> sigh
 * lamont goes to see if the bug is filed already
<d-b> nm found olive
<d-b> wait a second
<d-b> can i have a branch within a branch ?
<sabdfl> igc: that fixed it - thanks!
<sabdfl> d-b: sure you can
<sabdfl> you mean, you have your branch in ./ and then say a branch of zlib in ./libraries/zlib/ ?
<d-b> well my gui isn't working for it and its really really annoying
<d-b> mmm how about getting a certain revision ?
<d-b> bzr pull is it ?
<sabdfl> yup
<sabdfl>  -r revisionspec
<sabdfl> try bzr help revisionspec
<jelmer> lifeless: hi
<jelmer> lifeless: your last reply to me about progress bars was empty, was that intentional ? :-)
<clbry> hello, are nested trees supposed to work currently (in 1.13) or should I just move along?
<clbry> I'm looking for a way to have external (referenced) branches inside a main branch, where I can work on them locally in the branch but also can push/merge/pull external changes
<clbry> here's what I do: http://dpaste.com/16007/
<LarstiQ> clbry: if you only need that at one spot, and don't need operations to work on the entire collection, you could just use seperate branches
<LarstiQ> clbry: http://launchpad.net/bzr-scmproj is another option (just like config-manager)
<clbry> LarstiQ: I'd like to reuse the bar project without having to worry about crashing different projects if I modifiy the bar project inside the foo project (but beeing able to pull external changes and to push local changes in a controlled way). and I'd like to have a single checkout of the foo project, automatically including the bar project. perhaps I should give up the latter
<LarstiQ> clbry: the former needs no exra support, the latter can be done with scmproj, and for bzr native worked on http://bazaar-vcs.org/NestedTreeProgress
<clbry> thx, I'll look into scmproj
<Kobaz> Peng_: poke
<jam> hey vila, how's it going?
<vila> jam: I'm writing code so ugly I prefer to hide :)
<vila> jam: quick call ?
<jam> sure
<adelie42> is it necessary to register an ssh key for each machine that is going to connect to bazaar? Virtual or otherwise?
<beuno> adelie42, only for write operations
<adelie42> So if I have 2 computers I use and each got 2 test environments and I want to be able to push from all of them, I need to register 6 individual keys?
<beuno> yes, or use the same ssh key
<adelie42> I can just copy ~/.ssh/id_rsa* to whatever machine I want to use?
<adelie42> and set the email address to the local user?
<LarstiQ> adelie42: yes
<adelie42> ok, thanks (This really makes me wish I just kept all my data on usb)
<LarstiQ> adelie42: eh
<LarstiQ> adelie42: now I'm not sure I said yes to what I said yes to :)
<adelie42> oh? with what regard?
<LarstiQ> adelie42: you only need to have 1 key.
<Ng> would it be reasonable to file a bug for more things (specifically I care about log) take -c?
<Ng> +to
<LarstiQ> adelie42: assuming you're talking about Launchpad interaction
<Ng> I dislike having to remember different options to get info about a single revision :)
<adelie42> LarstiQ: yes
<LarstiQ> Ng: that's reasonable. There has at least been discussion about it. log and diff have different inclusion rules
<fullermd> Er?
<fullermd> Somebody already added -c to log.
<adelie42> I have a computer at home, and a computer at work. Each computer has a test environment. Fhe best thing to do, it seems to me, is copy my private and public key from each of the hosts to the guests and just have the two registered
<fullermd> More broken, IMO, since -c now means DIFFERENT things in the different commands.
<LarstiQ> Ng: your desire is reasonable, I now hand you over to fullermd to settle the issue ;)
<Ng> fullermd: ah, that could be my fault, the machine I was on only has 1.5
<LarstiQ> adelie42: push to where exactly?
<fullermd> NEWS lists it for 1.8.
<Ng> win, thanks :)
<LarstiQ> while we're on -c, is there an invocation to svn for -1? It doesn't like HEAD for -c either :/
<adelie42> pushing to launchpad
<LarstiQ> adelie42: then you'll need 1 or more keys. More than one if they give access to other things than launchpad and/or have different security considerations.
<LarstiQ> adelie42: you can live with just 1 if you don't care for seperation
<adelie42> The virtual machines in question are ONLY for patch testing
<LarstiQ> adelie42: do they need to be able to push to launchpad themselves then?
<LarstiQ> seems like they don't
<Kobaz> mm
<Kobaz> maybe you guys know
<Kobaz> how wouldi change the http links in loggerhead to https
<Kobaz> i've been digging through the code and i haven't found where that part in constructed yet
<adelie42> technically, I guess not. Though I don't see why it wouldn't just be easiest to have the machine saved clean with the hodt key, and when testing is good and done, push before resetting for next test
<LarstiQ> Kobaz: are you using loggerhead behing apache proxying?
<Kobaz> yeah
<LarstiQ> Kobaz: https://bugs.edge.launchpad.net/loggerhead/+bug/260547
<ubottu> Ubuntu bug 260547 in loggerhead "start-loggerhead script doesn't properly set the wsgi.url_scheme from the server.webpath option" [Medium,Fix committed]
<LarstiQ> Kobaz: though really a different bug should be filed for the issue you and I are seeing
<jelmer> is there some way to enter the debugger when a test raises an (unhandled) exception?
<jelmer> BZR_PDB doesn't work in that case at least
<awilkins> Meh, I was just considering resurrecting my enhanced stack trace code, but I can't find it anywhere
<awilkins> It wasn't much though, just changed the code that prints the stack trace so it listed the values of variables and parameters
<LarstiQ> jelmer: it works, you just don't see what you're doing ;)
<LarstiQ> jelmer: nose has -s for that, don't know offhand how to so for bzr
<jelmer> LarstiQ: nose doesn
<jelmer> 't work very well for bzr plugins yet though
<LarstiQ> jelmer: ah, I hadn't tried it on bzr yet.
<Lo-lan-do> Hi all
<Lo-lan-do> jelmer: I seem to be running problems when rebasing a bound branch, is that expected?
<vila> fullermd: that should be me, a couple of years ago :) Or at least many months
<Lo-lan-do> (running *into* problems)
<vila> fullermd: search bug number and see comments there
<vila> fullermd: bug #248427
<ubottu> Launchpad bug 248427 in bzr "bzr log -r REVNO does what bzr log -c should do" [Wishlist,Fix released] https://launchpad.net/bugs/248427
<jelmer> Lo-lan-do: hi!
<jelmer> Lo-lan-do: no, that's certainly not expected
<jelmer> Lo-lan-do: unless you were expecting it to rebase between the local copy and the master branch
<Lo-lan-do> Not really
<Lo-lan-do> http://pastebin.com/f643767bf
<Lo-lan-do> If I unbind, then rebase seems to work (in progress, but it's committed a few revs already)
<Lo-lan-do> But then of course I need to push --overwrite afterwards :-/
<Lo-lan-do> It may (or may not) be relevant that "bound=True" is specified in my ~/.bazaar/locations.conf and that this setting seems to override any setting in the branch's branch.conf.
<jelmer> Lo-lan-do: so where would it get the master branch?
<Lo-lan-do> jelmer: Er, what?
<jelmer> Lo-lan-do: the local of the master branch a branch on your machine is bound to
<Lo-lan-do> Sorry, I didn't mean to sound rude.
<jelmer> where would it get that?
<jelmer> as I assume not all of your branches are bound to the same location..
<Lo-lan-do> I'm confused
<Lo-lan-do> Could we reuse the terminology in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520302 ?
<ubottu> Debian bug 520302 in bzr-rebase "bzr-rebase: Can't rebase a bound branch" [Normal,Open]
<Lo-lan-do> Unrelated: I've seen quite a few commits on bzr-git recently, some of them mentioning file ids and sha checksums... does that imply that roundtripping is being worked on?
<rockstar> jam, hi
<jam> hi rockstar
<rockstar> jam, could I call you?
<jelmer> Lo-lan-do: I'll reply to the bug
<jelmer> Lo-lan-do: no, roundtripping is not something I intend to work on soon
<jelmer> Lo-lan-do: it's also a lot trickier with git since it doesn't have proper custom revision properties where we could stash bzr metadata
<jam> rockstar: sure, can you give me about 5 minutes?
<rockstar> jam, yeah.  Skype?
<Lo-lan-do> jelmer: Thanks, and thanks.
<jelmer> Lo-lan-do: dpush already works to some degree though
<jelmer> Lo-lan-do: well, it *works* but it breaks on some branches
<mwhudson> Peng_: so i didn't break anything for you with yesterday's landing? :)
<lifeless> jelmer: probably needs a flag added to bzr's test runner, its the debug() method in the test suite, and we should support it ok
<lifeless> jelmer: you pinged last night too?
<mwhudson> i suppose it was inevitable that a thread about kB and KB and KiB would end up being not worth reading
<jelmer> lifeless: I might have
<jelmer> lifeless: but about something different then, can't remember what abour exactly
<lifeless> lamont: its pyrex :(
<lifeless> lamont: so the bug should be upstream with the code fragment that causes it
<mwhudson> lifeless: did you and spiv work on the "server opens the branch" bug yesterday>
<mwhudson> ?
<fullermd> mwhudson: "end up"?   :p
<mwhudson> fullermd: well, if it was short, it might not be too painful :)
<lifeless> mwhudson: yes
<mwhudson> lifeless: successfully?
<lifeless> mwhudson: yes
<mwhudson> lifeless: awesome
<mwhudson> lifeless: did patches get sent to the list?
<lifeless> mwhudson: though we are not agreed on how to enforce the jail that drives the test
<lifeless> mwhudson: no
<mwhudson> ah, ok
<mwhudson> but; awesome
<lifeless> mwhudson: or rather, the jail is fine, but something somewhere needs to check 'if in jail, don't open references'
<lifeless> we did a cheap hack to see the fallout, it passed tests
<lifeless> spiv was going to work on a different approach
<jelmer> SamB_irssi/SamB: Hi
<lifeless> mwhudson: http://people.ubuntu.com/~andrew/bzr/bzrdir-open-gaol/
<mwhudson> lifeless: i don't really want to try the code, sorry, just interested in status :)
<lifeless> heh
<d-b> yay for cat
<jelmer> spiv: You rock
<jelmer> spiv: That ~ patch has been my no1 wishlist bug for ages :-)
<spiv> jelmer: :)
<lifeless> jml: http://paste.ubuntu.com/133303/
<lifeless> jml: is that something you could live to have in testtools?
<jml> lifeless: in theory, yes.
<jml> lifeless: in practice, I'd like to know that someone's using it for a non-small project and not hating it :)
<lifeless> 30% faster bzr tests locally using it
<jml> (with some grammar fixes, obviously :))
<lifeless> shes in the kitchen
<jml> lifeless: did they confiscate all your apostrophes at the border?
<lifeless> fell out over the ocean
<lifeless> now they are all ,'s.
<lifeless> :>
<lifeless> jml: you could use it for launchpad, if only there was a way to run a) some tests and b) somewhere else
<poolie> i sometimes think one should have an intentionally bike-sheddy thread every so often, or even almost contiuously
<poolie> to keep that energy away from other topics
<elmo> poolie: you do realise you just pointed ben at a launchpad list to continue discussing this on right?
<poolie> do you mean "and now he's going to repeat everything there" or "and to subscribe he needs an account"?
<poolie> :)
<elmo> poolie: to _post_ he needs an account
<elmo> I thought?
<elmo> oh, clearly not, I'm on crack
<poolie> oh i thought it was non-subscribers are moderated
<poolie> as bazaar is
<elmo> but still, to subscribe
<poolie> apparently he is not subscribed to the bazaar list and reads it through some other way
<elmo> ah, ok
<poolie> like gmane or the web archive
<poolie> so presumably he can do the same
<elmo> presumably because our non-LP mailman doesn't implement openid ID either :-P
<igc> is pushing to lp overly slow today?
<igc> I kicked off a push of a brisbane-core derived branch 3+ hours ago now and it's *still* going
<jml> igc: I wonder if there's a stacking format thing going on.
<jml> igc: LP itself is not overly slow today.
<igc> jml: my command was ...
<igc>  bzr push lp:~bzr/bzr/bris.faster-children
<jml> igc: are you using -Dhpss perchance?
<igc> It said "Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/"
<lifeless> igc: if that branch isn't stackable, it won't stack
<lifeless> however, trunk is 1.9 now
<lifeless> so... it should be
<jml> igc: what's the format of your local branch for lp:~bzr/bzr/bris.faster-children?
<jml> and repo
<lifeless> jml: local isn't checked, stacked-on is
<jml> lifeless: I'm still curious.
<lifeless> jml: sure
<lifeless> poolie: got more activity ui...
<jml> lifeless: I've found that people who experience this often have old formats of the things they are pushing up
<igc> jml,lifeless: my local repo looks like it's still packs ...
<igc> Repository tree (format: pack-0.92)
<lifeless> poolie: http://paste.ubuntu.com/133315/
<poolie> elmo: are you content with what was worked out re an edge codehost?
<elmo> poolie: yeah
<jml> elmo: cool.
<elmo> I was very happy mwhudson fixed codehost
<jml> igc: so, I bet if you upgrade, it will push much faster.
<elmo> I just wish I was convinced codebrowse would be so easy ;-)
<jml> elmo: me too.
<poolie> elmo: oh the disconnect timeout had a big effect? that's good
<jml> elmo: codebrowse won't be that easy, sadly.
<poolie> i'd really like to try a forking wsgi process model
<poolie> lifeless: i know, i'll probably work on it today
<igc> jml: it's up to 32+M on the status bar for data transferred. The rate is 1-2 kB/s
<mwhudson> elmo: codebrowse is my #1 priority, i have some changes brewing that i hope will help
<mwhudson> elmo: but it's not going to be a "bing it's done" thing like codehost turned out to be
<poolie> igc: you should put debug_flags = hpss in bazaar.conf
<poolie> mwhudson: way to go!
<poolie> which change was this exactly?
<poolie> sending term rather than HUP?
<mwhudson> no
<mwhudson> killing idle connections after an hour
<elmo> mwhudson: sure.  I'm just happy y'all have been allowed to devote time to it is all
<jml> igc: yeah, I've seen this bug before.
<jml> igc: I haven't filed it since it's hard to reproduce once you've upgraded your repository.
<mwhudson> speaking of loggerhead
<mwhudson> anyone want to review a branch?
#bzr 2009-03-19
<jml> igc: I think it's very much worth fixing, because it regularly trips up bzr users, no matter how experienced they are.
<igc> jml: do we have logs showing how often users are pushing pack-0.92 branches vs 0.9 branches?
<jml> hahaha
<jml> no.
<igc> jml: do you think it's related to trying to stack on the far end?
<jml> igc: I don't know. What I do know is that stacking isn't behaving as I'm told it should.
<igc> jml: if this is the performance users are seeing out-of-the-box, it's scary.
<jml> igc: if they use old formats, that's what they see when pushing to LP.
<jml> igc: incidentally, do you have -Dhpss enabled?
<igc> jml: just added 'debug_flags=hpss' to bazaar.conf now
<jml> igc: cool. it's worth having for situations like this.
<igc> poolie: were you planning to make 1.9 the default early in the 1.14 release cycle?
<poolie> i'd ilke to
<igc> poolie: or did jelmer still have issues we need to sort first?
<poolie> it may be getting a bit close to 2.0 but we should still do it
<poolie> that branch still doesn't pass
<poolie> i think i understand what to do but i haven't done it yet
<jml> igc: I'd very much appreciate if you could take the time to file a good bug about this.
<jml> hmm. or I can "upgrade" to pack-0.92 and do it myself.
<lifeless> igc: it hasn't stacked. I was sure we had this fixed - what bzr are you using
<igc> lifeless: bzr.dev r4163
<lifeless> ok
<lifeless> buggering a file
<lifeless> igc: whats your local branch format
<lifeless> igc: can you do bzr info -v on the branch you pushed from please
<lifeless> igc: I want the branch format line
<jml> lifeless: I *think* I'm reproducing the bug w/ bzr.dev r4164, pack-0.92 repo, branch7 format. getting lots of hpss calls like http://paste.ubuntu.com/133325/
<lifeless> jml: lp will do lots of hpss calls full stop
<jml> lifeless: bzr info -v output http://paste.ubuntu.com/133326/
<jml> lifeless: it doesn't normally take five minutes to push up a stacked branch that is identical to the stacked-on branch.
<lifeless> so my guess is
<jml> lifeless: but I can wait an hour or so and see if this is really the same behaviour
<lifeless> a stackable source branch
<lifeless> shortcutting the check for can-stack
<lifeless> when actually it can't
<lifeless> and thus we don't upgrade-on-the-fly
<jml> sounds plausible.
<lifeless> no jml, thats enough to go on I think
<jml> lifeless: if I file a bug, what should I put in it? (or do you want to file it instead?)
<lifeless> I've filed
<jml> lifeless: thanks. I'll look out for it.
<lifeless> spiv: how did you go assessing alternatives for 'I'm in a gaol'
<spiv> lifeless: I'm pretty happy with adding an ignore_fallbacks param to open_branch et al.  But we have a problem with the cloning_metadir RPC, which currently *depends* on following a branch reference to determine the repo format, and the client depends on server to tell it the repo format.
<lifeless> spiv: oh, ugh.
<lifeless> I think branch references on servers are fugly
<lifeless> so I propose that on a server we do something different; e.g. return the current default
<spiv> So there's no way to have the gaol and preserve the behaviour of the cloning_metadir RPC.  I think probably we should add a new RPC, and make the old one just guess at the default format for branch refs.  1.13 clients might be confused sometimes, everyone else should be ok.
<spiv> Hmm, we don't even need a new RPC, really.
<lifeless> no, we don't :)
<spiv> We can just make the 1.14 client ask the referenced branch for the source format and ignore whatever the first server reckoned.
<lifeless> spiv: I was proposing that we just behave differently
<mwhudson> oh btw
<spiv> It sounds like we're agreeing?
<mwhudson> if you want to change the ignore_fallback parameter to some kind of callback
<mwhudson> i will buy you alcohol
<spiv> mwhudson: oh?
<lifeless> spiv: broadly; I think you're saying the client can get the old behaviour by working differently, I'm saying the old behaviour is simply undesirable with servers in the loop
<mwhudson> it would let me stop using the transform_fallback_location hook, which is basically a bad idea
<lifeless> spiv: and we should just change it
<lifeless> mwhudson: you use it to get a properly loaded branch, yes?
<mwhudson> lifeless: yes
<lifeless> mwhudson: AFAICT you'll still need it
<lifeless> mwhudson: not in the server process, but in the scanner etc
<mwhudson> well, if this ignore_fallback parameter became a callback that allowed me to open a different branch instead (or no branch, your use case)
<mwhudson> then i wouldn't
<mwhudson> we'd just say open('...', fallback_hook=)
<mwhudson> lifeless: it's only the puller that really really needs it
<lifeless> mwhudson: how is that better for you that the transform hook
<lifeless> *than*
<mwhudson> lifeless: i don't have to worry about uninstalling it
<lifeless> mwhudson: why would you worry about that?
 * mwhudson pages in furiously
<lifeless> mwhudson: last I heard you uninstall it in your test suite which isn't needed as TestCase in bzrlib does that
<mwhudson> lifeless: one of the awkwardnesses is that the 'hook' wants to have state per my invocation of branch.open
<mwhudson> lifeless: i can make the hook work
<mwhudson> lifeless: but it's not natural
<lifeless> mwhudson: perhaps it should be given the branch url too?
<mwhudson> well it is, in effect
<mwhudson> (it gets the passed half-open branch)
<lifeless> mwhudson: the thing is, Branch.open is Branch.open_containing which is bzrdir.open_branch which is WorkingTree.open_containing which is ...
<mwhudson> lifeless: i know
<lifeless> I'm not happy about adding a parameter to it as it is (this is what spiv and I disagreed on yesterday)
<mwhudson> i'll let you fight it out then :)
<lifeless> I'd really rather not have to scatter lambda:None around to use it
<mwhudson> yeah, i can see that
<lifeless> also I think there is a difference between
<lifeless> 'globally, I'm running in a funky space', and 'right here I do not want to open it'
<lifeless> specifically,
<lifeless> the first case is servers, the puller, etc
<lifeless> the second is reading data from an unupgraded stacked branch
<lifeless> which requires a heck of a lot of other work done anyhow
<igc> lifeless: branch: Branch format 6
<lifeless> thanks
<SamB> jelmer: yeah?
<glyph> Did bzr and bzrtools make it to the ppa without bzr-svn, or is something wrong with my package configuration?
 * SamB wishes the PPAs could do Debian packages too ...
<johnf> glyph: I didn't get a chance let me sort that out now. I though jelmer might do it as he has done in the past
<glyph> johnf: Thanks.  Just wanted to know if it was everybody's system or just mine :)
<jelmer> SamB: never mind, I misread 345067
<jelmer> SamB: bug 345067 I mean
<ubottu> Launchpad bug 345067 in bzr-svn "bzr-svn doesn't relay messages from subvertpy ImportErrors" [Undecided,Fix released] https://launchpad.net/bugs/345067
<SamB> jelmer: I still haven't figured out what the REAL problem is
<jelmer> SamB: well, did you actually build subvertpy?
<SamB> yeah
<SamB> the .so is there
<SamB> can't seem to find libneon
<jelmer> SamB: please try the latest subvertpy
<jelmer> SamB: it should give a clearer error message
<SamB> oh
<SamB> huh
<SamB> I just tried running SVN ...
<SamB> guess what!
<SamB> it can't find libneon on this box either ...
<lifeless> fail?
<jelmer> one day I'll find time to implement WebDAV+DeltaV in Python
<SamB> (actually, I typed "svn pull" by mistake when I was trying to pull subvertpy ;-)
<SamB> damn you, slackware, and your lack of dependencies!
<lifeless> jml: bug 345169
<ubottu> Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169
<jml> lifeless: thanks.
<pohutukawa> jelmer: Hi jelmer, thumper has just directed me to you with a request
<pohutukawa> jelmer: just filed this: https://bugs.launchpad.net/bzr/+bug/345198
<ubottu> Ubuntu bug 345198 in bzr "error trying to "bzr push" to an SVN repository" [Undecided,New]
<thumper> pohutukawa: jelmer was active 15 min ago but is in europe
<jelmer> pohutukawa: hi
<pohutukawa> thumper: thx. Bad time for someone in EU to be alive/awake
<mwhudson> it's also the last version of bzr-svn
<pohutukawa> jelmer: oh, you are. late worker ...
<mwhudson> pohutukawa: fortunately for us, jelmer is insane
<mwhudson> :)
<jml> hey
<pohutukawa> where'd we be without insane people?
<jml> has anyone hooked up emacs rgrep or similar to bzr ls
<jelmer> mwhudson: I prefer saying I'm a student :-)
<jelmer> pohutukawa: 0.4.13 is quite old
<mwhudson> jelmer: ok, i'll remember that for next time :)
<mwhudson> jml: you can just say
<mwhudson> M-x grep
<mwhudson> and type bzr ls --versioned --null | xargs -0 grep -ne whatever
<mwhudson> jml: but it's not superduper convenient
<jml> mwhudson: that simple, eh?
<mwhudson> yeah
<pohutukawa> jelmer: hmmm, OK. It's the one in Intrepid ... and it used to work until yesterday or the day before that ...
<jml> mwhudson: I'd like an interface similar to rgrep
<jml> I guess it's not that hard to knock up in elisp
<pohutukawa> jelmer: what's the preferred way to upgrade it in this case?
<mwhudson> jml: M-x customize-variable grep-find-template
<mwhudson> (!)
<pohutukawa> always have a bit of a bad feeling when circumventing the package management ...
<jelmer> pohutukawa: You'd have to upgrade bzr itself as well when upgrading bzr-svn
<jelmer> pohutukawa: the bzr PPA has the latest bzr-svn built for intrepid fwiw
<pohutukawa> :-/
<jelmer> pohutukawa: anyway, the problem seems to be in the tags, did you change any recently/
<pohutukawa> ah, if there's a PPA, that sounds a lot more promising towards succeeding without a domino effect of upgrade dependencies
<jelmer> ?
<pohutukawa> jelmer: what tags?
<pohutukawa> I didn't add tags recently, neither in bzr, nor in svn
<pohutukawa> but maybe someone else did. let's see
<jelmer> pohutukawa: for upgrading, see the UPGRADING file included with bzr-svn
<jelmer> you may also find the "bzr svn-upgrade" command useful
<pohutukawa> jelmer: bzr: ERROR: Unable to import bzr-rebase (required for svn-upgrade support): Version (0, 3, 0, 'final', 0) present, at least (0, 4) required
<jelmer> pohutukawa: yeah, you need at least 0.4.4
<jelmer> it might not be in the PPA
<pohutukawa> looking at it, I haven't even checked out tags from SVN to the bzr branch
<pohutukawa> just the trunk
<pohutukawa> so it can't be SVN tags
<pohutukawa> and I haven't (knowingly) added bzr tags
<jelmer> pohutukawa: try running "bzr tags" in your bzr branch
<jelmer> it will import tags from svn
<pohutukawa> got 8 lines with names followed by a column of "?"
<pohutukawa> most of these lines correspond with directories within the repo, but one is a tag from "way back" when I used SVN directly, and not through bzr
<jelmer> pohutukawa: so one of the workarounds you can try is removing all tags in your local bzr branch
<jelmer> and then pulling from the remote branch again
<jelmer> and then pushing
<pohutukawa> OK, first of all getting new bzr stuff from PPA for intrepid
<pohutukawa> incl. bzr-svn 0.5.3
<pohutukawa> jelmer: OK, with the new bzr the push worked, but ...
<pohutukawa> ... it tells me about "Conflicting tags"
<pohutukawa> which is a first good step. Now "cleanup" some tag mess
 * jelmer gets some sleep
<pohutukawa> jelmer: thanx for the help! everything seems clean now
<jelmer> pohutukawa: push works again?
<pohutukawa> don't even know where those tags came from, to be hones
<pohutukawa> yes
<jelmer> great
<jelmer> pohutukawa: they should match the directories in tags/
<pohutukawa> jelmer: thx, and have a good night. Bedankt!!!
<jelmer> in the svn repo
<pohutukawa> hmmm, OK
<pohutukawa> how would I get those down now?
<jelmer> pohutukawa: why is it that all newzealanders seem to speak a few words of Dutch? :-)
<pohutukawa> 'Cause I'm German ;-)
<jelmer> pohutukawa: bzr pull from the svn branch should import them
<pohutukawa> and been to the netherlands quite often for playing Honkball and SCUBA diving
<jelmer> ahh
<pohutukawa> did a bzr pull, and they're back. Hpe they're consistent now
<pohutukawa> jelmer: good night, then.
<jelmer> gnight
<lifeless> spiv: I don't think Remote*Format should have a network_name, but I can't remember if I added them or you did :P
<Peng_> Kobaz: pong?
<SamB> jelmer: you also aren't propagating import error messages from the import of sqlite3 ... assuming that you try to import it
<poolie> igc, hi
<poolie> what on earth is that push doing that it's taking so long?
<lifeless> poolie: its not stacking
<lifeless> bug 345169
<ubottu> Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169
<poolie> oh ok
<lifeless> I have a fix, running the full test suite now
<igc> poolie: it's still going btw - up to 73M at a leisurely 1-2 kB/s
<igc> lifeless: well done and thank-you
 * SamB notes down the software he's noticed missing so far so he can tell the sysadmin about it ...
<poolie> lifeless: are the development2 formats now obsoleted by 1.9?
<lifeless> poolie: we don't have a development format thats newer than 1.9 in trunk at the moment, but I figured it was better to keep them and the alias live until we do have a newer one.
<lifeless> lol its so easy to trigger the lp bug on notifications
<poolie> of the connection staying open
<lifeless> http://people.ubuntu.com/~robertc/LP%20Notification%20bug-Bazaar.png
<lifeless> I can see ajax making this worse :P
<lifeless> or better
<lifeless> depending
<lifeless> spiv: hola, we should coordinate
<jamesh> lifeless: there used to be a real solution for that, but people complained about the URLs being ugly
<poolie> possibly having ugly urls is better than looking like you don't know what's happening
<poolie> esp if there's a 'close' button that strips off the notification bits
<BasicOSX> Bug#345232 help?
<BasicOSX> #345232
<BasicOSX> uncharted territory for me I don't know where to start, when PQM fails to merge
<lifeless> jamesh: I know
<poolie> bug 345232
<ubottu> Launchpad bug 345232 in bzr "1.13.1 regression: PQM failure to merge" [High,In progress] https://launchpad.net/bugs/345232
<poolie> BasicOSX: i answered it
<lifeless> jamesh: I was there :P
<poolie> it's an easy fix
<BasicOSX> ok
<poolie> hth
<poolie> ping me if it doesn't
<poolie> but i'm going out to the shops for a bit first
<BasicOSX> I guess I need to update the releasing doc? I do not see anything about changing _script_version in bzr
<poolie> i think it's in there but if it's unclear please fix it
<lifeless> BasicOSX: _script_version only needs the major version
<lifeless> BasicOSX: oh, I'm wrong
<lifeless> uhm
<lifeless> BasicOSX: it does need changing :(
<BasicOSX> np, I stumble you catch me, it's ok :-)
<lifeless> BasicOSX: thank you for doing this
<lifeless> rm is non trivial
<BasicOSX> heh, I was going to thank you guys for being patient and helpful
<thumper> lifeless: is there a bug about the notifications with examples on reproducability?
<poolie> lifeless: re bug 330494, i propose to just remove the options
<ubottu> Launchpad bug 330494 in bzr "Remove list of formats from bzr init and bzr init-repo" [Medium,Confirmed] https://launchpad.net/bugs/330494
<poolie> and tell people to use --format 1.9
<poolie> and then, for the --format parameter, say see `help formats'
<lifeless> thumper: notifications?
<lifeless> poolie: well, I'm not against that per se, but as I commented in the bug, the list will be undiscoverable if we do that
<poolie> even if we say 'see also'?
<lifeless> poolie: help formats doesn't list all the formats
<poolie> iiuc all of them are listed in other help topics?
<lifeless> its now static text
<lifeless> because help formats used to be the full list from the options and it was too long :P - same issue
<poolie> ok
<poolie> so i thought they were all included in either current-formats or other-formats
<lifeless> I'd rather, TBH, have the option list short and detailless - hand crafted, and help formats be the full dynamic list it used to be
<poolie> and that those were dynamic
<poolie> just including the common ones?
<lifeless> well, the filtered logic we have - hide hidden etc already exists
<lifeless> hmm
<lifeless> current-formats is sane, and other-formats has rest
<lifeless> perhaps thats enough
<lifeless> ok
<lifeless> its a little long winded though
<poolie> i agree
<poolie> nm for now
<poolie> the annoying thing about trying to fix one of these bugs is how it makes you notice more
<jml> :)
<poolie> igc, are you still here?
<BasicOSX> What quick check can I do on the .tar.gz to confirm the pyrex-ifed files are in there?
<lifeless> tar tzf | grep \\.c
<lifeless> there should be about 4-5 files
<lifeless> poolie, there is a fix up for bug 345169 if you want to do a review
<ubottu> Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169
<BasicOSX> lifeless:  http://www.nopaste.org/p/apmIZgncK
<poolie> k
<lifeless> BasicOSX: looks fine to me
<BasicOSX> k, "ignore" my post to the ML :-)
<BasicOSX> 1:45am, sleepy, watching check-dist-tarball scroll makes my eyes heavy! will push and announce things in the morning.
 * lifeless is gone
<igc> poolie: yes
<vila> hi all
<poolie> hi vila
<vila> lifeless: ping. working on parallel selftest. KnownFailure and UnavailableFeature deserialized, with 8 procs, selftest for ~17500 tests is down to 2/3 minutes
<lifeless> vila: cool
<lifeless> vila: I'm working on ec2parallel now
<lifeless> vila: most of that code should not land in bzr itself, I only committed it there to get it to you
<vila> lifeless: right, so where do you plan to land it ?
<vila> lifeless: should I make bzr pluggable and go for plugin instead ?
<lifeless> subunit [done], testtools [part of it is up for review already]
<vila> lifeless: or do you target testtools/subunit ?
<lifeless> and a small strategy bit in bzr itself
<vila> subunit landed ? I saw a merge request for it yersterday but didn't check today
<igc> poolie: see http://bazaar-vcs.org/SummerOfCode2009
<lifeless> vila: done not landed
<poolie> vila i'm reviewing your ftp server thing
<vila> I modified ThreadsafeForwardingResult to add  wnFailure and UnavailableFeature deserialization, should I subclass instead ?
<vila> poolie: thanks !
<vila> poolie: I think I forgot to add a NEWS entry
<lifeless> well, there aren't unittest standards for those aspects yet
<vila> lifeless: but
<vila> lol
<lifeless> no but
<lifeless> look in the subunit and testtools log
<lifeless> you'll see addSkip
<vila> lifeless: but TAP2SubUnit handles xfail it seems, but not TestProtocolServer
<lifeless> we need to do something similar for all the custom things in bzr
<vila> lifeless: I saw that, but couldn't decide if *some*things should stay bzr specific or not
<lifeless> vila: on indeed, where te subunit wire protocol decides that X is already handledand subunit can't deserialise thats a plain ol bug
<lifeless> so definitely -> fixes to subunit for that
<lifeless> it would be clearer if I described my goals I think
<lifeless> I want:
<lifeless>  - a couple of small functions in bzr that specify how to turn a bzr test suite into an externally run suite
<lifeless> vila: like http://paste.ubuntu.com/133468/
<lifeless> vila: thats bzr specific
<lifeless> vila: that, option parsing to enable this, is all that should be in bzr itself for this, IMO
<lifeless> vila: and even that should be a helper bzr chooses to use rather than inaccessible in bzrlib
<vila> lifeless: sounds reasonable, when asked to parallelize (-j n ?) do we want a warning and fallback to serialized selftest or just abort ? The idea is that selftest should still return coherent return codes
<lifeless> vila: expand on that, I suspect you are missing an assumption
<vila> if I run 'selftest -j n' and miss the dependencies, I want selftest to either abort (sorry, couldn't verify your tests ran) or just fallback to normal behavior (I couldn't parallelize, but I ran the tests anyway)
<lifeless> either is fine; I'd abort myself
<lifeless> vila: for now, just schlep plain diffs to me
<vila> I slightly prefer that too, deal.
<lifeless> I have a bunch of untangling of my sketch to do :P
<lifeless> jml: which reminds me - could you please review my subunit merge request, its trivial
<jml> lifeless: your _subunit_ one?
 * jml looks
 * vila mumbles: bundle when I send diffs and now diffs when I want bounded branches :)
<vila> rats bound branches
<jml> lifeless: one question: do you want to stop reading when there's a blank line?
<vila> lifeless: oh, any idea why a 'bzr serve --port localhost:0' is coming from ? It stays alive and blocks the whole thing with zombies
<vila> s/why/where/
<lifeless> jml: end of file
<jml> hmm. maybe readline() includes the terminating line char
 * jml experiments
<lifeless> mwhudson: so the answer is
<lifeless> mwhudson: readlines buffers regardless of the buffer size
<lifeless> mwhudson: readline doesn't
<mwhudson> lifeless: ah, ok
<vila> lifeless: once killed, everything terminate gracefully
<jml> >>> news.readline()
<jml> '--------------------\n'
<lifeless> vila: not specifically, no
<mwhudson> jml: yes, it does
<mwhudson> it returns '' for end of file
<jml> so bool(line) <=> EOF
<jml> yay.
<mwhudson> and '\n' for intermediate empty lines
<mwhudson> right
<vila> vila: well gracefully with still failures=1, errors=9, which I intend to address first
<lifeless> the subunit fix is what gives us graceful concurrentp progress
<jml> lifeless: approved.
<mwhudson> for i in file: === for i in iter(file.readline, ''):
<lifeless> jml: thanks
<jml> iter takes a second parameter?!
<mwhudson> or something like that
 * jml keeps learning Pythno
<lifeless> mwhudson: meep
<mwhudson> yep
<lifeless> mwhudson: also, for i in file: == for i in file.readlines() :( -- buffers 1K or so suckage
<mwhudson> well
<mwhudson> different implementations i think
<lifeless> mwhudson: so I argue ~=
<mwhudson> yes, ok
<lifeless> mwhudson: no, I started with for i in file
<lifeless> mm, may need to checkt he C code
<lifeless> regardless, it suckaged
<mwhudson> lifeless: i'm not disagreeing with your observations, just your deductions
<mwhudson> the code implementing readlines and iteration for files is entirely disjoint
<mwhudson> i can believe both buffer though
<mwhudson> and yes, looks like readline() is yet another case
 * mwhudson reads code, gets confused
<mwhudson> too late in the day to be thinking anyway
<vila> lifeless: also, from a high level, splitting by concurrency only once doesn't give the best results here with 8 procs, some processes finish far quicker than others. IMO, once things stabilize enough, we should look at making each process handles *several* test slices instead of just one
<vila> lifeless: roughly, the actual 200 seconds can go down to 120 or something I think
<lifeless> mwhudson: :P
<lifeless> vila: well
<lifeless> vila: I appreciate that
<lifeless> vila: ideally it streams (say) 30 seconds worth at a time
<lifeless> or we annotate each test with a cost and make the partitions have equal cost
<vila> Could be, I don't strive for perfection there though, if I can just feed the processes a bit more, I'd be happy (and end up with a simpler code I think). Evaluating test cost upfront or based on previous execution sounds a bit fragile/hard
<vila> but as I said, not something I want to decide on without a first version running smoothly
<vila> lifeless: by the way, any idea when you could have a look a loom tests, I still have failures and no enough understanding to fix them :-/
<poolie> yay activity bars
<AfC> And yet *another* person burned by Ubuntu only shipping bzr version 1.3!
 * AfC scratches another chalk mark on the wall...
<poolie> it should be fixed soon
<poolie> at least in backports
<poolie> lifeless: i'm reading your patch then i'm going to go
<lifeless> AfC: btw, with 1.13 shipped you should be seeing better network behaviour already
<AfC> lifeless: I'll keep an eye out - the bzr package on my distro is upgraded already, but I haven't done anything demanding software wise this week so I haven't had a chance to form a subjective view yet.
<vila> lifeless: no more zombies no 'bzr serve' hanging processes, WNOHANG is *not* your friend :)
<lifeless> vila: its not the parallel suite causing it
<lifeless> vila: it happens on pqm too
<vila> lifeless: you mean the 'bzr serve' one ?
<lifeless> yes
<vila> well, at least I got read of the zombies... or not, I'll keep an eye on it but WNOHANG and calling waitpid *before* joining the thread didn't sound right
<vila> lifeless: right, its' back, but indeed, far less zombies as expected
 * vila acquires target
<lifeless> so
<lifeless> I have BZR_PARALLEL=subprocess working
<lifeless> but fugly batched output again
<vila> lifeless: send diffs :-)
<lifeless> yes dear
<vila> :-)
<lifeless> http://paste.ubuntu.com/133493/
<vila> lifeless: thanks
<AfC> lifeless: first impression: I have no idea whether it's faster or not, but you're giving more (and cleaner) feedback in progress & bytes transfered etc so it *seems* more responsive. Well done
<AfC> although I wish there was a way to kill off the silly progress bar and thereby have more room to report the actual information
<poolie> afc: are you talking about testing or in general?
<AfC> poolie: Robert wanted to know if I subjectively experienced 1.13 as faster since we're one of the few communities who publicly uses the bzr: protocol (have adopted it WAY to early)
<poolie> ok
<AfC> poolie: and, of course, I push over bzr+ssh like everyone else but do a fair bit of it (none of this firing an email off to bug buddy nonsense)
<poolie> just wasn't sure which irc thread you were on
<jamesh> the new progress reporting rocks, irrespective of actual speed improvements
<poolie> jamesh: thanks; i thought it might
<poolie> also it makes silly slow or wasteful bits obivous
<jamesh> actual speed improvements welcomed too
<poolie> which is good
<Guest7068> amen
<poolie> 1.14 should have both
<AfC> Like I said, just need to kill of the [###      ] from appearing half way into an operation.
<poolie> hm
<vila> poolie: regarding pb/ui, we definitely need a way to override them unconditionally with ENV variables (until we get a *perfect* auto-detection, which could take some time :-)
<AfC> [That's half :) and half :( ]
<poolie> so you just want the text progress not the [######] bit?
<poolie> and not the activity?
<AfC> poolie: I think so
<poolie> vila: i agree, it's high on my list
<vila> poolie: great !
<poolie> by activity i mean not the network speed?
<AfC> A single cell / - \ | / - spinner would be fine, whereas all the numbers and status and such is great.
<AfC> It's a bit weird that there are two status fields (and in 80 chars, both are truncated to the point where you can't read anything) but at least it gives the impression that its doing something.
<AfC> Which is what Git has done all along, so people thought it was "fast" whereas Bazaar was 0/5 forever.
<jamesh> if bzr said "1/5" they'd probably think it was faster
<AfC> poolie: (to be clear, bzr's idea of network speed is great)
<AfC> jamesh: perhaps, but the problem is it being camped out on 0/5 or 1/5 for 30 minutes. That wasn't so cool.
<jamesh> true.
<AfC> "hung"
<poolie> exactly
<poolie> that's why i did it
<poolie> so, um
<poolie> opinions seem to vary about the progress bar bit
<poolie> robert wants it to be bigger
<poolie> i guess so he can see it in peripheral vision
<poolie> personally i think a spinner to say "something's happening" and then a numeric count may be better...
<poolie> i was going to try making them fractions of your terminal width
<poolie> this stuff is hard to judge until people see it
<poolie> for interest, what is your terminal? 80 cols? and a real xterm, or something inside an ide?
<poolie> (by which i include emacs :)
<jamesh> I like the smaller progress bar
<jamesh> it is large enough to get an idea of overall progress, while leaving enough room for the other info
<poolie> also we should cut out some of the less useful text bits
<poolie> which will make the right side less crampde
<poolie> cramped*
<vila> I'd love to see more "semantic" info in the pb, yet, the network speed is a must, the  [######] didn't carry understandable info  so far, I prefer the xx/nn part myself, all of this being *totally* subjective of course
<poolie> agree
<poolie> it requires some kind of audit of code that's generating pb events
<poolie> which i've started
<vila> and obeying SIGWINCH is of course a must so that I can resize my window when I want more info :)
<poolie> :)
<poolie> soon, that too
<vila> woohoo
<AfC> poolie: 80 chars, in a gnome-terminal
<poolie> that search got a bit hung up on what to do about generators
<poolie> afc ok thanks
<vila> poolie: 80 chars should be the default when deciding how to split the info in the pb IMHO
<poolie> yes
 * vila uses a 24" display so that 3 emacs windows can be shown
<vila> each of which are 80 chars wide of course
<lifeless> poolie: I want it bigger, and doing stuff :P
<poolie> you sound like a spam mail :)
<poolie> anyhow it will be
<poolie> but good night
 * igc dinner
<mwhudson> this doesn't make a great deal of sense to me: http://pastebin.ubuntu.com/133536/
<lifeless> hmm, yes, patch needed
<mwhudson> it's even documented
<lifeless> mwhudson: well,it can be changed
<AfC> Well, surprise. After being told the GNOME vcs survey wouldn't be used as evidence, it was used to drive the migration to Git after all. Another cause lost.
<AfC> and that's going to make me even more unpopular in that crowd. {sigh} what else is new
 * AfC is tired of fighting
<lifeless> AfC: :(
<AfC> I guess I should blog pointing out all the issues I raised in January, but that wouldn't really help anything.
<Stavros> hello
<Stavros> how can i check out a repository but not include the .bzr dir?
<LeoNerd> You mean like   bzr export   ?
<Stavros> i want to have a production static site but i don't want people to be able to check out the history
<Stavros> hmm
<Stavros> probably, let me look
<lifeless> or get the bzr-upload plugin
<Stavros> oh, bzr export looks like it
<Stavros> let me check to see what bzr-upload does
<Stavros> is that automatic?
<Stavros> hmm, i ran setup.py for bzr-upload but don't see it in the list of available plugins...
<Peng_> Stavros: Just put it in ~/.bazaar/plugins or bzrlib/plugins.
<Peng_> Stavros: (But name it "upload" instead of "bzr-upload" or "trunk" or whatever.)
<SamB> the other option would be to just disallow fetching of the .bzr dir ;-)
<Peng_> SamB: Yeah, I do that, but it's less safe, in case you screw up the web server config or permissions or whatever.
<Stavros> agreed
<Stavros> let me check it out again
<Stavros> ah great, it works now, thanks
<Stavros> this is brilliant
<Stavros> hmm, it breaks
<Stavros> http://dpaste.com/16433/
<Stavros> how is "contact.html" an invalid relative url for the transport?
<Stavros> any idea what relpath should be, for put_bytes?
<Stavros> wow, it doesn't support utf8
<jelmer> SamB: sqlite3 is included with Python >= 2.5
<SamB> jelmer: I know! it must have gotten deleted or something?
<SamB> in fact, it's the _sqlite3 module that seems to be missing ...
<SamB> jelmer: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2599#a2599
<Peng_> SamB: Maybe you didn't have sqlite's headers installed when compiling Python?
<SamB> it wasn't me!
<SamB> I'm not the sysadmin
<Peng_> Well, still.
 * Peng_ goes /away again
<SamB> does it still install the .py files for sqlite3 even when it can't build the extension?
<Peng_> Hmm, I would be surprised if it did, but it's possible.
 * Peng_ really goes away again
<Stavros> i did a bzr add * and it added ignored files, how can i undo that?
<SamB> hmm. this issue is documented on http://www.linuxquestions.org/questions/slackware-14/python-bug-in-current-633384/
<SamB> jelmer: apparantly slackware doesn't build the _sqlite3 module :-(
<jelmer> SamB: it's included with python..
<SamB> ... because it doesn't include sqlite
<jelmer> SamB: python includes sqlite afiak
<SamB> the whole library ?
<SamB> mine, at least, is dynamicly linked
<jelmer> SamB: yes, it includes the sqlite library itself as well IIRC
<jelmer> SamB: it can probably use the system sqlite as well
 * SamB prints a copy of http://trac.edgewall.org/wiki/TracOnSlackware12 to show to his sysadmin
 * SamB wishes it was easier to kill an ssh session whose connection has been dropped by a router ...
<jam> SamB: <enter> ~ .
<jam> One of the magic commands for ssh
<jam> <enter> ~
<jam> is the give meta-commands
<jam> like ^[ for telnet
<jam> and "." is kill the connection
<jam> morning vila
<vila> jam: hi ! Quick call (but beware it's *really* nisy here :)
<vila> s/nisy/noisy/
<jam> sure
<jam> we'll make it quick
<mcasadevall> Does bzr-svn limit the formats a bazaar repo can be?
<beuno> mcasadevall, AIUI, it has to be rich-root
<beuno> but jelmer is the expert
<mcasadevall> Well, I'm having stacking issues which makes things annoying :-/
<pygi> folks
<pygi> download page links to wrong release for windows platform
<pygi> (1.12, outdated)
<sidnei> pygi: i can fix that
<pygi> sidnei, thanks :)
<sidnei> in fact, anyone can, its a wiki
<pygi> well ... that's true xD
<pygi> sidnei, but I feel lazy atm, so would you? :)
<pygi> please? :)
<sidnei> if i remember my password :)
<sidnei> pygi: done, thanks for noticing!
<pygi> haha, np, thank yuo sidnei :)
<jelmer> mcasadevall: hi
<jelmer> mcasadevall: it has to be some rich root format
<mcasadevall> :-/
<jelmer> mcasadevall: but stacking shouldn't be a problem
<mcasadevall> can you convert an existing repo to rich root format?
<jelmer> mcasadevall: what's not working exasctly, and what format are you using?
<mcasadevall> I have a KnitPack
 * mcasadevall is not a bazaar gurur
<jelmer> mcasadevall: KnitPack isn't really a format. What does "bzr info" report?
<mcasadevall> Standalone tree (format: unnamed)
<mcasadevall> Nothing useful.
<mcasadevall> jelmer, what do I type to convert it?
<jelmer> mcasadevall: what format did you upgrade to ?
<mcasadevall> I didn't upgrade anything
<jelmer> mcasadevall: "bzr upgade --1.9-rich-root"
<mcasadevall> I just did a bzr pull
<jelmer> mcasadevall: in both the branch and the shared repository
<mcasadevall> seems to be working :-)
<mcasadevall> I don't have commit rights to where I pulled.
<mcasadevall> jelmer, this is what I pulled https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu
<jelmer> mcasadevall: what are you trying to do exactly?
<mcasadevall> push to Launchpad without spending two days waiting for it to push
<jelmer> mcasadevall: but where is bzr-svn involved?
<mcasadevall> jelmer, the repo I pulled with was made with it
<jelmer> https://code.edge.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu
<jelmer> you mean?
<mcasadevall> yeah
<jelmer> mcasadevall: that seems to already support stacking though
<jelmer> mcasadevall: from the lp page: Packs 5 rich-root (adds stacking support, requires bzr 1.6.1)
<mcasadevall> No, I know
<mcasadevall> but try pulling, then pushing to launchpad
<mcasadevall> it won't work.
<jelmer> mcasadevall: so I'm not quite sure what's not working
<jelmer> mcasadevall: so pushing a new branch to launchpad based on that branch doesn't stack? or it doesn't work at all?
<mcasadevall> Doesn't stack at all
<jelmer> mcasadevall: it would try to stack on lp:~cjwatson/debian-installer/main, which has no shared history
<jelmer> mcasadevall: as that is the development focus
<mcasadevall> argh
<mcasadevall> so what do I do ?
<jelmer> mcasadevall: ask the debian-installer team to change the development focus, or alternatively you can ask for support for stacking on arbitrary branches in launchpad
<mcasadevall> ..............
<zooko> Anybody going to PyCon?
<jelmer> mcasadevall: Bazaar supports stacking on arbitrary branches just fine, this is (as I understand it) an issue specific to launchpad
<mcasadevall> ...................................................................
<mcasadevall> ARGH
<eferraiuolo> Looking for some help on setting up the bzr-email plugin
<eferraiuolo> Where do I set the configuration? and can I set it globally for all users?
<jelmer> mcasadevall: so you might want to ask in #launchpad instead
<jelmer> mcasadevall: hmm
<jelmer> mcasadevall: maybe "bzr push --stacked-on" works, have you tried that yet?
<jelmer> eferraiuolo: in .bzr/branch/branch.conf or ~/.bazaar/locations.conf
<jelmer> eferraiuolo: global configuration in ~/.bazaar/bazaar.conf
<eferraiuolo> the global then is per user
<eferraiuolo> which I think that's what I want, since I have a smart server setup with a dedicated bzr shh user...
<mcasadevall> jelmer, nope
<mcasadevall> (doesn't work that is)
<eferraiuolo> I'm getting (when pushing to a remote smart-server): bzr: ERROR: Server sent an unexpected error: ('error', "cannot concatenate 'str' and 'NoneType' objects")
<eferraiuolo> on 1.13 both the server and my local machine
<NfNitLoop> eferraiuolo: sounds like a bug.  Does ~/bzr.log have any more detail?
<eferraiuolo> NfNitLoop: I'll check now on both my machine and the server
<eferraiuolo> NfNitLoop: I have stacks on both my server and local machine
<mwhudson> beuno: um yes, loggerhead's test suite, mumble
<beuno> mwhudson, :)
<beuno> you can ignore that safely
<beuno> I had no comments on the code, so I threw that in!
<mwhudson> hrumpf!
 * mwhudson uncommits from launchpad trunk :/
<beuno> ew
<mwhudson> beuno: did you see the other branch?
<beuno> mwhudson, I don't think so, no
<mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
<beuno> mwhudson, freenode and my ISP hate eachother
<beuno> last I said was that I hadn't seen any other branch
<mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
<mwhudson> (that's the only message you missed)
<beuno> sorry-rob?  :)
<beuno> it's odd that there aren't any requested reviews on that branch
<beuno> mwhudson, in line 74 of the diff
<beuno> why are you importing errors?
<mwhudson> it's called sorry-rob because it does things to the bzrlib api lifeless probably won't be super pleased to see
<mwhudson> beuno: ah, because it was needed at one point :)
<alevine> i'm trying to use the latest bzr-svn and I get "unable to load plugin 'svn'" . In .bzr.log I am getting ImportError: No module named foreign
<alevine> anyone have an idea?
<jelmer> alevine, you need a newer version of bzr
<alevine> jelmer, ok thanks. any recommendations on the best way to do this on ubuntu? at the moment I have just compiled subvertpy myself, should I do the same with bzr?
<jelmer> alevine, you can retrieve all packages from the PPA
<alevine> jelmer, the bzr ppa?
<jelmer> alevine, yep
<alevine> thanks
<LarstiQ> though bzr-svn still needs uploading for !intrepid
<LarstiQ> jelmer: is the svn credential store supposed to work set from authentication.conf? I got StopIteration on creds.next(), and python -c 'from subvertpy import ra; ra.Auth(ra.get_simple_provider())' segfaults
<alevine> I'm ok with manually installing bzr-svn, but I can't seem to get subvertpy to install properly
<alevine> I get  subprocess post-installation script returned error exit status 1
<jelmer> alevine, you might have to remove the files that got installed when you built subvertpy yourself
<jelmer> LarstiQ, latest subvertpy?
<LarstiQ> jelmer: I think so, I'll recheck after I clean the fridge
<LarstiQ> alevine: yeah, apt-get remove subvertpy; rm -rf /usr/lib/python2.5/site-packages/subvertpy; apt-get install bzr-svn; did the job for me
<alevine> ahh, thanks, that seemed to work
<mwhudson> beuno: hello again
<mwhudson> beuno: i talked to jml the other day about the annotate page
<mwhudson> beuno: and we came up with the idea that the default view of a file should be just a view
<beuno> no annotation?
<mwhudson> and that the annotate information should be on a separate page/loaded with ajaz
<mwhudson> ajax
<beuno> hm
<beuno> or
<beuno> the annotation information could be fetched through ajax on that same page
<beuno> I'm thinking if we loose a lot or not really
<beuno> mwhudson, if you request a review for: https://code.edge.launchpad.net/~mwhudson/loggerhead/sorry-rob/+merge/4648
<beuno> I'll review it  :)
<beuno> can't otherwise
<beuno> as for annotate view..
<beuno> is it that much slower?
<mwhudson> for, say, sql_select.cc, yes
<mwhudson> beuno: requested :)
<beuno> mwhudson, ok, so, we could not provide it by default, and bring in that information via ajax on request
<beuno> how does that sound?
<mwhudson> yes
<beuno> instead of havinf 2 different pages
<mwhudson> i was only going to keep the separate page for the noscripters
<beuno> ah
<beuno> I guess that sounds good then
<mwhudson> beuno: thanks for the reviews :)
<mwhudson> i've actually been trying quite (pointlessly?) hard to cater to the noscript case for lh
<beuno_> I hate irc
<beuno_> well, my ISP at least
<beuno> mwhudson, did the canonical IRC die for you as well?
<mwhudson> beuno: nope, but i see you ping-timeouting
<beuno> ok
<beuno> so it's argentina
<beuno> no access to *canonical.com
<beuno> fun
<jam> igc: ping
<igc> hi jam
<jam> hi igc, I was wondering where you got to with the iteritems() code?
<jam> If my last message helped point you towards what I was thinking
<spiffytech> How can I create a branch of my program? All I can find on Google is branching from random online repos.
<igc> jam: I spent nearly all of yesterday on GSoC stuff so no progress since my email, sorry
<igc> jam: your reply looked really helpful but I'm yet to apply it
<igc> jam: I have some other things still ahead of that in my queue: tweaking the add-view patch & landing content filtering
<jam> igc: k. I ended up finding 2 or 3 other things to work on today...
<igc> jam: I did push through those minor tweaks to Node __repr__ though
<jam> got a bit sidetracked seeing that btree overhead was very high for large repos
<jam> and still have some gc.make_delta() tweaks I want to look at
<jam> igc: so if you could leave me a message before you stop tonight with where you get to. as I'm likely to poke at it if you can't finish it by tomorrow
<igc> jam: yeah, I was seeing additional overhead in the btree layer profiling send on bzr.dev vs brisbane core
<jam> igc: that is something different, and is probably just because we have 5x more items to read now
<igc> I couldn't explain it though and the profiler wasn't helping with weird count #s for some iterators
<jam> in the past, at most we had 200 deltas for an inventory, now we have 255 chk pages + root + inv node
<jam> not to mention the chk index is much larger than the old .iix
<jam> oh, and looking closer, the fact that .cix don't have a size entry in pack-names is probably hurting a lot
<jam> as we call "transport.get_bytes()" in that case
<jam> which means we page in the *whole thing*
<jam> which probably destroys the existing page-cache, etc.
<jam> :(
<igc> jam: I'm back up the hospital today after lunch for chemo so I'm not confident I'll get the iteritems stuff completed before then
<jam> np
<igc> jam: on the bright side, you latest patch sounds sweet
<igc> s/you/your/
<jam> The one I'm working on now for btree code, seems to drop "bzr pack lp" another minute or so (~12 -> ~10.5)
<igc> I gather that will help branch (out of a shared repo) time?
<jam> hmm... maybe I'm wrong, as it seems to have a size now
<jam> igc: it shouldn't help branch anymore
<jam> as the streaming code changed it
<jam> so that 'bzr branch in out' doesn't do a full repack anymore
<jam> but it *does* have implications for "time to insert" "autopack" and the infrequent "bzr pack" times
<jam> Oh, and it might help bzr branch
<jam> as the btrees end up writing 400k entries
<jam> which is what i'm fixing up
<thumper> morning
 * igc breakfast
<mwhudson> beuno_: so you know the way i removed all the "get multiple file changes at once" code from LH?
<mwhudson> i probably should put it back :)
<mwhudson> at least i can do it more sanely this time
<beuno_> mwhudson, what's the use case for it?
<mwhudson> beuno_: when you click expand all on the changelog page
<mwhudson> and maybe something similar for the revision page
<mwhudson> not so sure about that
<beuno> ah, right
<beuno> so you would make two different tyoe of calls depending on if the user expanded all or just one?
<beuno> some rad optimizing you're doing
<mwhudson> yeah
<mwhudson> maybe i won't care for now
<beuno> YUI has some nice chaining methods
<beuno> you could chain the requests
<mwhudson> oh, interesting
<LarstiQ> does anyway here have a hardy system around?
<LarstiQ> s/way/one/
<beuno> LarstiQ, I do
<LarstiQ> beuno: ok, I'm merging the bzr-svn 0.5.3 unstable packaging into the hardy-ppa packaging, but I'm not certain of all of it
<LarstiQ> beuno: could you give the package a testspin before I upload to the ppa?
<beuno> LarstiQ, sure
<LarstiQ> sweet :)
<beuno> regular bzr ppa?
<shikibu> I'm a new user of bzr, and I just renamed a symbolic link whose content was under version control. (cp -pr the content of src@ to src2/, then rm src@, then mv src2 src). Now bzr figures all my source code is gone. How can I recover?
<shikibu> verterok: perhaps you'll give me a hint?
<LarstiQ> beuno: yes
<LarstiQ> beuno: I'll ping you when I've got the source/dsc built
<beuno> LarstiQ, cool
<verterok> shikibu: you should do: rm src@; bzr mv <src-symlink-dest> src
<verterok> shikibu: if that was the only change, do a bzr revert, and start over :)
<shikibu> ah, i see. but perhaps I must do this for each element that was beneath src@?
<shikibu> i think it's the only change, but I wanted bzr to help me feel confident of that before live deploy!
<LarstiQ> shikibu: could you pastebin `bzr status` output?
<shikibu> sure
<verterok> shikibu: do you want to  remove the symlink, and replace it with a real dir?
<shikibu> yes, that's what I want.
<shikibu> It was a symlink because I was working partly in eclipse workspace
<verterok> shikibu: what's the target of the symlink?
<shikibu> https://pastebin.canonical.com/15214/
<shikibu> Oh, I see; src@ links to eclipse-workspace/src. so yes, I need to do what you said first "bzr mv eclipse-workspace/src src"
<shikibu> i think part of what I wanted was to get bzr to tell me exactly what it now thought was missing
<mwhudson> beuno, rockstar: another loggerhead branch up for review :)
<rockstar> mwhudson, does this fix all the problems?
<shikibu> bzr: ERROR: Not a branch: "/...../workspace-eclipse/3874 CD Distributor form/src/".
<verterok> shikibu: seems like the symlink target isn't under the same branch
<shikibu> can I get bzr to give me an inventory of what is in the branch?
<mwhudson> rockstar: no, not really
<rockstar> mwhudson, :)
<verterok> shikibu: bzr ls
<verterok> shikibu: if that's the case, you need to cp/mv and then bzr add
<LarstiQ> shikibu: it doesn't like my identiy url or something
<shikibu> got it. thanks for your help (again)
<verterok> shikibu: np :)
<shikibu> LarstiQ: hmm. that's funny. and it's my group that would like you to post a bug about it ; )
<shikibu> can you tell me LarstiQ what it looks like?
<shikibu> hay LarstiQ nevermind; I just realized that i used the wrong pastebin.
<shikibu> I think i'm good now tho, thanks for offering to look.
 * LarstiQ frowns at the ppa builder
<LarstiQ> aha
<LarstiQ> mbp, jam: could one of you approve me for bzr-beta-ppa team so I can upload the bzr-svn hardy package there before uploading it to bzr-ppa?
 * LarstiQ falls asleep
<LarstiQ> beuno: I'll check back with you tomorrow
<beuno> LarstiQ, whenever you like. The server isn't going anywhere
<LarstiQ> I hope so :)
<jam> LarstiQ: approved
<beuno> hey hey poolie
<poolie> hi beuno
<beuno> poolie, how are you?
<poolie> good thanks
<lifeless> moin
<poolie> lifeless: want to join us?
<poolie> even if not you're welcome to come today
<lifeless> poolie: :P yes, was honouring natrures callw when you rang
<lifeless> can you hear me
<mwhudson> lifeless: no
<BasicOSX> Generating doc/developers/performance.png
<BasicOSX> Dot not installed; skipping generation of doc/developers/performance.png
<BasicOSX> I assume that is dot2tex?
<thumper> abentley: ping
<lifeless> BasicOSX: graphviz is the package
<BasicOSX> ty
<glyph> is the hardy ppa still missing bzr-gtk?  When I asked yesterday johnf said he'd fix it.
#bzr 2009-03-20
<poolie> glyph: i don't see it  there
<poolie> igc, hi
<lifeless> jam: I think you should land your gc change
<lifeless> jam: I haven't fully reviewed, but its definitely conceptually fine
<RaceCondition> is there a way to, instead of unshelved changes, commit shelved changes only?
<lifeless> RaceCondition: shelve you current changes, unsehlve the ones you want to commit, commit. ?
<RaceCondition> lifeless: um, yeah, but you didn't answer my questio
<RaceCondition> is it possible or not to commit shelved changes
<RaceCondition> smth like bzr commit -m "msg" --shelved
<RaceCondition> apparently not, though, google gives me nothing on this
<lifeless> no there is no direct way to do this today
<spiv> Random observation: bzrlib.errors.AmbiguousBase has been deprecated since 0.8
<spiv> We should delete it...
<poolie> spiv, i have a branch outstanding that removes lots of old code
<poolie> i have review comments from robert still to do
<jam> lifeless: streaming or the change to the delta_index code?
<abentley> thumper: pong
<thumper> abentley: I was wanting to talk to you about the bzr sprint at uds
<abentley> thumper: sure thing.
<abentley> thumper: did you mean on skype?
<thumper> abentley: :) yes
 * igc lunch
<lifeless> jam: both
<thumper> poolie: what do we need to do to kick the backport effort in ubuntu?
<poolie> james_w said something in bne about driving it
<poolie> but he's on holiday until monday
<thumper> bne?
<thumper> nm
<thumper> friday afternoon and I'm knackered
<igc> content filtering patch submitted to pqm
 * igc off to hospital for the rest of the day
<igc> have a good weekend all
<lifeless> igc: good luck
<maco> bzr push needs some better error messages
<maco> "bzr push lp:~maco.m/seahorse-plugins" tells me that ~maco.m isnt a valid project name instead of telling me i need a branch name on the end of it
<maco> maybe this is launchpad-specific though....? should i bug them instead?
<lifeless> maco: its launchpad specific
<maco> ok ill go bug them
<lifeless> :)
<poolie> idea:
<poolie> maybe we could take all these people who like bikeshedding
<poolie> and rent them out to actual power plants that need their bikesheds painted?
<poolie> strictly one per shed
<lifeless> hopefully with big bikesheds
<poolie> mm
<poolie> kfogel: don't you sleep? :)
<kfogel> poolie: long story :-)
<kfogel> poolie: I'm actually an early-to-bed person, but... sigh, something came up, so here I ma.
<kfogel> am
<vila> hi all
<kfogel> hi vila
<poolie> hello vila
<poolie> readjusted to europe?
<vila> poolie: fully :-)
<vila> I even add a ~2hours protest under my windows yesterday :)
<vila> s/add/had/
<vila> not specifically targeted at me of course...
<poolie> heh
<poolie> not even at slow push to 1.13? :)
<vila> not even :-) But some wanted a faster selftest though... :-P
<lifeless> vila: you begged :P
<lifeless> vila: and we have now
<vila> lifeless: it rocks ! I toyed a bit yesterday evening trying to spawn 256/2048 processes instead of just 8 and obvisouly the kernel just can't handle that (I have plenty of memory so no problem from that side)
<lifeless> vila: :P
<lifeless> vila: its fixable
<vila> lol
<Peng_> Possibly stupid question: How does doing BzrDir.find_branches() on a local transport wind up returning remote branches?
<lifeless> its just in the wrong spot, the ec2 version has it moved to run()
<lifeless> Peng_: branch references
<vila> lifeless: spawning the processes you mean ?
<lifeless> yes
<Peng_> lifeless: Okay.
<Peng_> I wonder where I have one of those?
<Peng_> Oh, I remember.
<vila> lifeless: diff available somewhere ?
<lifeless> vila: no :P but the branch I put up has a new snapshot
<lifeless> vila: remember that none of this history will be merged, its all noise - I'm cutting and pasting bits for the relevant projects
<lifeless> poolie: 7m30 or so with 5 instances
<lifeless> though there are still, uhm, glitches
<vila> lifeless: branch url ? And yes, I understand we don't care about history (though I'm a bit surprised we make an exception there ;-P)
<lifeless> tests.parallel
<vila> lifeless: got it
<poolie> Peng_, would you be interested in coming to this bzr sprint at all?
<poolie> robert suggested at least putting you on the list
<vila> lifeless: wow, of course I should ignore all that ec2 related stuff
<vila> lifeless: I'll manage, back to test_breakin
<poolie> ok, i think that's enough
<lifeless> ciao
<vila> have a nice week-end !
<Coke> Hi! Odd question perhaps, are there any free project hosting for free projects (like launchpad) that use bzr?
<Coke> (except launchpad, ofcourse)
<cody-somerville> Sourceforge.net
<luks> sourceforge, savannah, any web hosting
<Coke> They do?
<Coke> Savannah is using bzr these days?
<mrooney> hmm is this an important error? bzr: ERROR (ignored): The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x9d71d2c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<mrooney> I can't seem to get through this push, it just stalls at walking content, though if I control+c that is what I get
<poolie> mrooney: it's typically a knock-on effect of some other error
<poolie> it's better in later versions
<poolie> cheerio
<mrooney> poolie: how many later versions are there than 1.13~rc1-1build1 ?!
<poolie> not many :)
<mrooney> hm I can't seem to push, alas
<mrooney> it just sticks on walking content
<poolie> mrooney: if it's reproducible please do control-backslash
<poolie> which should put you in a debugger then type 'bt'
<mrooney> yes it does seem to be
<poolie> and then put that in a bug and show vila :)
<poolie> cause unfortunately i have to go
<mrooney> hm okay well here it is for any other eyes http://paste2.org/p/167921
<mrooney> I really need to go also
<mrooney> I just wanted to push this code so someone else could work on it
<mrooney> I guess not :/
<vila> poolie: lol
<vila> mrooney: looking
<mrooney> vila: thanks :)
<vila> mrooney: ok, so, hpss requests shouldn't interrupted as they don't know how to restart, instead you should use -Dhpss and look at .bzr.log
<vila> you can even add 'debug_flags = hpss' in bazaar.conf
<mrooney> it will always just get stuck at some random walking content number
<vila> mrooney: we need to look at that 'random' :-)
<vila> but first,
<mrooney> so where should that log be?
<vila> where are you pushing to ? What format is used there, are you stacking ?
<mrooney> I have no idea :) I just tried to push to a fresh branch
<mrooney> "bzr push lp:~mrooney/do-plugins/skreemr-plugin"
<vila> mrooney: 'bzr version' will tell you where the .bzr.log file resides
<Coke> Hey, I can't find any evidence at all that sourceforge or savannah is using bazaar, any link to docs explaining how to use it?
<mrooney> vila: http://paste2.org/p/167923
<mrooney> the top part is the .bzr.log part, the bottom is where I am stuck
<bob2> http://bzr.savannah.gnu.org/
<vila> mrooney: wow, wow, what bzr version are you using ?
<bob2> for small values of using
<mrooney> yes indeed
<mrooney> 1.13~rc1-1build1
<Coke> There's nothing in the user guide nor http://savannah.gnu.org/userguide/
<mrooney> jaunty
<Coke> and the faq is lacking bzr commentary
<Peng_> You think it's a good idea to set public_branch on all of your, well, public branches on the server?
<vila> mrooney: What 'bzr info -v' shows in your local branch ?
<Coke> The menus include git, cvs, svn and arch, no bzr
<Peng_> It's a bit redundant..
<mrooney> vila: http://paste2.org/p/167924
<mrooney> vila: thanks for helping me with this by the way :)
<mrooney> hopefully I can get this up
<vila> mrooney: hmm, assuming you put 'debug_flags = hpss' in bazaar.conf, can you try deleting the branch and pushing again ?
<mrooney> oh I didn't let me do that
<vila> mrooney: I suspect a stacking problem but upgrading all do-plugins branches to 1.9 may not be an option :-/
<vila> mrooney: I can't parse "I didn't let me do that", surely you can be gentle with you and authorize yourself to delete a branch no ? ;-P
<mrooney> haha
<mrooney> "I didn't, let me do that"
<mrooney> now I am getting tons of output in the log
<mrooney> after doing that
<mrooney> vila: http://paste2.org/p/167927
<mrooney> it does that forever on and on
<vila> mrooney: on purpose, that's a known bug, you're using a slow code path :-(
<vila> for excessive values of slow :(
<mrooney> vila: how long will it take?
<vila> mrooney: the main factor is your ping time for lp,  with ~20ms I found it hardly tolerable, above that, well, it depends on whether you are patient or very patient :-/
<mrooney> ~170 on average here
<mrooney> (bazaaar.launchpad.net)
<vila> I think lifeless just posted a patch against bzr.dev to address situations like yours (and spiv already posted one for some of them last week), it's definitively high on the list to have that bug fixed
<mrooney> so what is my situation though
<mrooney> all I did was branch from lp and push
<mrooney> what is special about it?
<vila> mrooney: nothing, that's the bug :)
<mrooney> hm okay haha
<mrooney> I'll guess I'll burn through some kilowatts and leave my computer on overnight
<vila> mrooney: hmm, just checked, lifeless patch hasn't landed yet
<vila> mrooney: if that's an option, go for it and let us know how it ends up :-/
<mrooney> eh I guess I will try pushing tomorrow at work on a better connection
<vila> mrooney: the laternative will be to update all the do-plugins branches to format 1.9 which doesn't suffer from this bug
<mrooney> but I have 1Mb up, I guess the ping is bad
<mrooney> how do I do that?
<vila> 'bzr upgrade lp:do-plugins --format 1.9' for all branches
<mrooney> can I do it on just mine?
<vila> mrooney: possibly, but if stacking is enabled on lp for do-plugins, I'm not sure this will avoid the bug... It may be faster to try though
<mrooney> it will be faster to give up and sleep
<mrooney> :)
<mrooney> thanks for your help though
<vila> mrooney: sure, sorry about that :-/
<mrooney> I will hope this magically works tomorrow or something
<vila> mrooney: things should be better once the initial push suceeds...
<mrooney> all I need is the initial push :)
<mrooney> it is only for review so it can be merged haha
<mrooney> as I don't have permission to push elsewhere
<vila> mrooney: hmm, looks like lifeless patch landed after all (BB didn't acknowledged it yet, but it's in bzr.dev), so you may want to try that too (please report if you do)
<mrooney> bzr: 1 me: 0
<mrooney> I'll try to even the score tomorrow :)
<mrooney> good night thanks for your help!
<vila> mrooney: you're welcome
<mrooney> ps I upgraded the remote branch and my local although it didn't seem to fix it, I suppose your stacking suspicion was correct
<vila> mrooney: which remote one ?
<mrooney> ~mrooney/do-plugins/skreemr-plugin
<mrooney> the unpushed to one
<mrooney> I don't know if that actually does anything but it took about 10 minutes so I presume it does
<vila> I'm surprised you can update it if it's not pushed to yet... what does .bzr.log says ?
<mrooney> vila: http://paste2.org/p/167940
<mrooney> apparently it took only 3 minutes
<vila> mrooney: hmm, sounds good, what does bzr push reports now ?
<mrooney> still hanging out at walking content
<mrooney> last thing in the log there is 8.569  fetch up to rev {mrooney@ubuntu.com-20090320073443-2g8kssdqgnwhyfnw}
<vila> well, so indeed, you may need bzr.dev (sorry about the trials, I don't have all the combinations clearly in head)
<Peng_> Another possibly-stupid question: What if I want to read from a branch and conditionally write to it? Should I always take out a write lock? Can I take out a read lock and "upgrade" it to a write lock if necessary?
 * Peng_ wonders why downloading the most recent revision of bzr.dev over http took 1.5 minutes and ~3.7 MB of bandwidth
<Peng_> It's 14 lines of changes!
<LarstiQ> beuno: https://edge.launchpad.net/%7Ebzr-beta-ppa/+archive/ppa/+sourcepub/530792/+listing-archive-extra
<LarstiQ> jam: thanks, uploaded
<beuno> LarstiQ, hi. So I should install bzr-svn from that PPA?
<pygi> hi hi
<LarstiQ> beuno: either that or download the deb from there
<beuno> LarstiQ, installing bzr-svn works great
<beuno> would you like me to use it in any way?
<mxpxpod> I just shelved some changes using bzr 1.13 which included adding some files and now when it goes to unshelve them it gives me this error: bzr: ERROR: No such file: None
<mxpxpod> any way to fix that?
<LarstiQ> beuno: I wouldn't object to that :) I'm reasonably sure that if it gets through the phase where debian/control matters, that the actual code itself works.
<beuno> LarstiQ, so I should just try and check out an svn branch with bzr?
<beuno> got any handy?  :)
<mxpxpod> beuno: http://svn.dojotoolkit.org/src/dojo/trunk
<LarstiQ> beuno: stolen from subvertpy examples: svn://svn.gnome.org/svn/gnome-specimen/trunk
<beuno> fetching....
<mxpxpod> so, does anyone know what's going on with bzr unshelve?
<beuno> malbisetti@pentaserv:~$ bzr co svn://svn.gnome.org/svn/gnome-specimen/trunk test_svn
<beuno> Initialising Subversion metadata cache in /home/malbisetti/.bazaar/svn-cache/203ae883-c723-44c9-aabd-cb56e4f81c9a
<beuno> Upgrade to Subversion 1.5 or higher for faster retrieving of revision properties.
<beuno> mxpxpod, maybe you're mixing shelve and shelve2?
<LarstiQ> mxpxpod: in what sense?
<LarstiQ> ah, you pasted something above
<mxpxpod> :)
<mxpxpod> beuno: nope, I did bzr shelve and then bzr unshelve
<LarstiQ> mxpxpod: doesn't look familiar to me, did you check the bugs page in launchpad?
<mxpxpod> yeah, looking now
<mxpxpod> I could swear I've seen this before... but I don't remember the fix
<LarstiQ> mxpxpod: there have been various shelve fixes the past releases
<mxpxpod> LarstiQ: yeah, I figured... I'm using 1.13
<mxpxpod> and I need these files :(
<LarstiQ> mxpxpod: so if you trigger something in 1.13, either it's something new, something regressed, or newly exposed
<mxpxpod> frick
<LarstiQ> mxpxpod: we should be able to help you get your files back
<LarstiQ> mxpxpod: but it would be easier if this was a known problem
<mxpxpod> LarstiQ: fun ;)
<mxpxpod> the other problem is that I can't give out the shelf file because the files are internal to my company
<LarstiQ> that's fine
<mxpxpod> do you want me to paste the bzr log somewhere?
<beuno> LarstiQ, worked like a charm
<mxpxpod> LarstiQ: oh, the other thing is that I added a new directory to the shelf too
<mxpxpod> and there was a file in that directory
<mxpxpod> LarstiQ: hmm, it might be trying to add the file in the directory before adding the directory back
<jam> morning vila (I have a conference call right now, but we can chat after if you want)
<vila> jam: chat sounds good
<mxpxpod> LarstiQ: it's dying in line 546 of bzrlib/transform.py
<mxpxpod> LarstiQ: any clues?
<LarstiQ> mxpxpod: sorry, irl sidetracked me for a moment there
<LarstiQ> mxpxpod: your analysis sounds plausible
<LarstiQ> mxpxpod: with that sequence I get a different message
<LarstiQ> mxpxpod: could you cp -a your branch so we can look at the state as it was later again?
<mxpxpod> LarstiQ: huh?
<LarstiQ> mxpxpod: .bzr/checkout/shelf is where shelf has stored your files
<LarstiQ> mxpxpod: I'm intending to get your file out first, and do bugreporting later
<jam> vila: call has completed if you want to chat
<mxpxpod> LarstiQ: ok, so do you want a copy of my branch?
<vila> jam: sure
<LarstiQ> mxpxpod: no, I just want to make sure you have an extra copy that we're not going to touch
<mxpxpod> LarstiQ: or, just for me to make a copy for later
<mxpxpod> LarstiQ: gotcha
<mxpxpod> LarstiQ: making the copy now
<mxpxpod> LarstiQ: ok, done
<LarstiQ> mxpxpod: ok, `bzr shelve --list` only shows 1 shelve?
<mxpxpod> LarstiQ: yessir
<mxpxpod> and there's only one file in .bzr/checkout/shelf
<LarstiQ> mxpxpod: if you open that with an editor, do you see the contents of your file clearly?
<mxpxpod> LarstiQ: yeah
<mxpxpod> LarstiQ: but there are other changes in the file
<durin42> jelmer: ping, can we bug you in #mercurial briefly?
<mthaddon> has bzr merge --force changed somehow in 1.13?
<mxpxpod> LarstiQ: I guess I'll just have to apply all of those changes manually
<LarstiQ> mxpxpod: ok, let me try a couple of things
<jelmer> durin42: sure
<jam> BasicOSX: ping
<BasicOSX> jam:  hiyah
<jam> hey, just checking the 1.13.1 release
<jam> It looks like you don't have the fix for the "bzr merge --force" regressino
<jam> which was an issue for some other people
<jam> Do you might getting that into 1.13.1 before we make it finalized?
<BasicOSX> sec
<jpds> Anyone else having troulbe pushing to lp?
<jam> BasicOSX: "bzr.dev 4146" I'm happy to create a cherrypick and submit it to PQM as long as you are signed off on it
<BasicOSX> jam: I can squeeze it in :-) Looks like Vincent fixed my bzrtools bug
<BasicOSX> so I was going to re-start the release as well
<BasicOSX> cherry pick and PQM to the branch, I'll sign off on it
<jam> k
<BasicOSX> Eeep! I missed 1.14rc1 -and- 1.14final according to mbp post!
<jam> jpds: it seems to be working for me
<jam> did you try again?
<jam> BasicOSX: yep. though if you read further he really did mean April :)
<BasicOSX> I know, was just putting it in irc to tease
<fullermd> Shucks.  There I was thinking I'd finally gotten a good, long sleep...
<jpds> jam: Just made it.
<jam> BasicOSX: change is on its way to PQM now
<jam> Shall I ping you when I get the confirmation?
<BasicOSX> My lunch hour almost over, drop me email on it?
<BasicOSX> since I'm going to loose wifi when I leave the cafe and drop back to the office :-) (yes, I bring my laptop to lunch)
<Tak> can an uncommit be pushed to other branches?
<jam> Tak: with 'bzr push --overwrite'
<vila> jam, BasicOSX : SHouldn't revno 4174 (bug #345169) be included in 1.13.1, it seems to address some pushing-to-lp-is-slooow bugs that some early 1.13.1 are experiencing
<ubottu> Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169
<Tak> then what happens if I pull from a branch that already has the revision as well?
<jam> vila: it isn't a regression
<jam> "source is 0.92 branch 7"
<BasicOSX> vila:  I asked on the ... nm, jam answering
<vila> I know :-/
<jam> vila: not worthy of a 1.13.1 release
<jam> they would get the same from 1.12
<jam> Tak: uncommit just rolls the pointer back, it doesn't mark it as rejected
<jam> so pulling from a branch that had it will bring it back
<Tak> so what I really want is to unmerge that revision
<jam> Tak: bzr revert -r -2; bzr commit
<jam> bzr merge -r X..X-1 ; bzr commit
<jam> sorry
<jam> bzr merge . -r X..X-1 ; bzr commit
<jam> depending on whether you want to reject the last commit, or something older
<jam> (merge works in both cases, but revert is more obvious, IMO)
 * Tak nods
<Tak> thanks
<d6g> hello, i have some problem to push to a branch today, it stops at
<d6g> [|                   ] Transferring:Walking content. 1294/1423
<d6g> and when i stop it using ctrl-c, i got this error: http://paste.pocoo.org/show/108824/
<jam> d6g: I don't think it stopped, it is still transferring, just not giving progress messages.
<jam> This would be with at least bzr1.13 to another bzr.1.13 host, right?
<d6g> it's 1.3 and push to launchpad
<d6g> 1.13
<jam> bzr.dev is a little better in that you still get 'activity' indications on the bytes sent/received.
<d6g> but how long am i supposed to wait, it seems just stuck in there
<d6g> and the number 1294 seems random, sometimes larger/smaller
<d6g> jam: i think you are right, i saw the upload speed now, it still is around 50kb/s, so i will probably have to wait, thx.
<mrooney> vila: no more apparent luck today, hm
<awilkins> So, if I used --stacked on a branch that doesn't support stacking, how well does it work?
<awilkins> It's currently telling me it's using 1.6, inside a 1.9 repo, and it's doing stuff that I presume is stacking (building tree")
<nekohayo> hey there, I'm getting a "Permission denied (publickey)." when trying to "bzr pull lp:~kiddo/specto/specto-jeff" .... what's up?
<nekohayo> using bazaar 1.6 "bundled with intrepid"
<smoothice> Does anyone know if bazaar version 1.5.0 supports Launchpad?
<asabil> nekohayo: probably logged in, and bzr pull lp:... tries to use bzr+ssh
<nekohayo> for a pull?
<nekohayo> but then I still have no idea what to do in that case
<asabil> bzr launchpad-login
<jelmer> abentley: hi
<abentley> jelmer: hi
<jelmer> abentley: What could cause a "Revision incompatible" error while merging a bundle?
<abentley> jelmer: I guess going from rich-root to non-rich-root?
<jelmer> abentley: that was it, thanks!
<nekohayo> asabil: returns "kiddo"
<nekohayo> asabil: nevermind, I upgraded to bzr 1.13 and that fixed it
<hsn_> how can i get around error message from apt-get public key is not available when i am trying to access bzr repos?
<beuno> hsn_,
<beuno> https://edge.launchpad.net/~bzr/+archive/ppa
<beuno> https://help.launchpad.net/Packaging/PPA#Adding%20a%20PPA%20to%20your%20Ubuntu%20repositories
<hsn_> beuno: thank you it works now
<exarkun> How do I change the push branch of a working copy that already has one?
<fullermd> push --remember
<exarkun> With version 1.3.1 that doesn't seem to do it
<exarkun> Oh :(
<exarkun> Yes it does, I just have a comprehension problem.
<exarkun> Thanks
<fullermd> Coffee helps with that   ;)
<exarkun> Hmm yea....
<lifeless> vila: hi
<lifeless> vila: do you have a copy of tests.parallel with both our stuff in it?
#bzr 2009-03-21
<johnf> jelmer: you about?
<jelmer> johnf: hi
<johnf> jelmer: don't worry I was wondering why the packaging process was so different for bzr-svn than for bzr and bzrtools and then realised your managing it yourself upstream
<jelmer> johnf: it's different choices wrt how the packaging is done
<jelmer> johnf: Debian/Ubuntu use the same style for bzr and bzrtools as bzr-svn
<jelmer> johnf: LarstIQ was looking at providing updated packages for bzr-svn in the PPA
<johnf> jelmer: yes he it for hardy. I'm about to do it for everything else. I meant to do it a few days ago when I did bzr and bzr-svn but ran short on time in setting up my end for the different process
<jelmer> johnf: I think he wouldn't mind if you uploaded for bzr-svn as well
<johnf> jelmer: is there a reason for lp:~bzr/bzr-svn/beta-ppa-hardy vs lp:~bzr/bzr-svn/hardy-ppa ?
<jelmer> johnf: not really
<jelmer> well, one is probably more up to date than the other :-)
<johnf> ok I'll remove one of them
<johnf> hmm I can't check them out. Something weird with the stacking
<jelmer> johnf: what's the error?
<johnf> when checking out  lp:~bzr/bzr-svn/beta-ppa-gutsy
<johnf> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~jelmer/bzr-svn/0.5/"
<johnf> launchpad says it's stacked on lp:~jelmer/bzr-svn/0.5-mirrored
<jelmer> hmm, that's because lp:~jelmer/bzr-svn/0.5/ is now a "remote branch"
<jelmer> it used to be a "mirror branch", mirrorring the URL that's now mirrorred by  lp:~jelmer/bzr-svn/0.5-mirrored
<jelmer> not sure if there's much that can be done about that
<jelmer> abentley: are you still there?
<yeonhoo> hello
<johnf> heh trying to look at the revisions gices Internal Server error
<jelmer> johnf: looks like a launchpad bug then :-)
<jelmer> johnf: you might be able to fetch it over http
<johnf> hmm don't think so. I think it is very unhappy because the parent has disappeared
<lifeless> johnf: hi
<lifeless> johnf: do the following
<lifeless> bzr branch --stacked lp:~jelmer/bzr-svn/0.5/ local
<lifeless> python
<lifeless> import bzrlib.repository
<lifeless> l = bzrlib.repository.Repository.open('local')
<yeonhoo> hi..! i forgot my ssh password. is possible to register another ssh public key in launchpad?
<lifeless> r = bzrlib.repository.Repository.open('sftp://bazaar.launchpad.net/~bzr/bzr-svn/beta-ppa-gutsy
<yeonhoo> i don't understand well about it
<lifeless> l.fetch(r)
<lifeless> then run bzr heads and do a pull . -r revid:real-head
<lifeless> yeonhoo: yes, in the web ui you can do that
<yeonhoo> 3 weeks ago i learn about bzr to upload and fetch... but now im totally new...
<yeonhoo> the things in my head gone !!
<lifeless> yeonhoo: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<yeonhoo> lifeless: thank you very much...! i was looking for this page...
<yeonhoo> i have to up my search skill....
<johnf> lifeless: http://pastie.org/422536
<johnf> I'm very tempted at this stage to just create branches with debian directories similar to bzr and bzrtools. That way the scripts can just build all of them automatically
<jelmer> johnf: if you do that, please also update the instructions in bzr.dev for building bzr-svn for the PPA
<lifeless> johnf: oh, my bad
<lifeless> johnf: o = Repository.open('lp:~jelmer/bzr-svn/0.5/')
<lifeless> johnf: l.add_fallback_repository(o)
<lifeless> johnf: then do the fetch again
<johnf> jelmer: yep already have a patch with other changes so I can do that
<jelmer> johnf: and please realise that that means it will no longer be possible to import changes from the Debian/Ubuntu package
<jelmer> (as they won't have any shared history)
<johnf> jelmer: yeah I would need to do that manually
<lifeless> jelmer: if you could make that branch be mirrored again, at least until 1.14 hits lp, that would fix this
<jelmer> lifeless: hmmok
<lifeless> jelmer: its the gaol patch spiv put up that will fix this
<jelmer> ok, should be fixed now
<jelmer> johnf: please try again
<jelmer> lifeless: ah
<lifeless> which hasn't landed - but you can see that its a third-party site issue
<johnf> jelmer: looks good, thanks
<yeonhoo> hummmm
<yeonhoo> i have want to commit whole directory but it's uploading not sub directories
<yeonhoo> is there some flag to include subdirectories?
<johnf> jelmer: I think I will change the way bzr-svn packages are built. The problem in doing it this way is there will be conflicts in changelog every single time.
<johnf> At the moment with bzr and bzrtools I can run 5 scripts and I'm done. Would be easier if bzr-svn worked the same way with just a quick check if any changes were made to debian dir since last time
<johnf> alternatively I'm happy to leave it to you or someon else to update bzr-svn in the PPA
<yeonhoo> humm
<yeonhoo> bzr add <--- it's not adding subdirectories
<yeonhoo> how to include subdirectories?
<yeonhoo> bzr add . has same effect...
<yeonhoo> hm
<yeonhoo> ah....
<yeonhoo> help
<johnf> yeonhoo: what's the problem?
<yeonhoo> it is not adding subdirectories automatically
<yeonhoo> bzr add .
<johnf> hmm it normally does
<yeonhoo> or bzr add
<johnf> does "bzr ignored" indicate that it is ignoring them?
<lifeless> are they ignored?
<yeonhoo> and i tried on --no-recurse
<lifeless> or are they subtrees?
<yeonhoo> no..
<yeonhoo> subtrees?
<lifeless> or do you have analias that makes add do no-recurse ?
<yeonhoo> it prints nothing with bzr ignored
<yeonhoo> nop..
<yeonhoo> its doing recursively (as normal)
<yeonhoo> but if it is subtrees i dont know
<yeonhoo> how can i verify this?
<yeonhoo> i have a directory ..with many subdirectories...
<yeonhoo> is there simple command that does this?
<yeonhoo> when "bzr status"
<yeonhoo> it lists a lot of file not-versioned
<yeonhoo> it lists as unknown
<NaCl> Th/part
<lifeless> if bzr status lists the files as unknown
<lifeless> 'bzr add' should add them
<yeonhoo> i already try this
<lifeless> can you capture the output of 'bzr status' and then 'bzr add' and pastebin it for us ?
<yeonhoo> ok..
<yeonhoo> wait!
<yeonhoo> http://pastebin.com/d29ec14ee
<yeonhoo> here..
<johnf> yeonhoo: what happens if you bar add rdfapi-php?
<yeonhoo> sorry i didn't got what you said
<yeonhoo> if i bar?
<yeonhoo> ah
<yeonhoo> ?
<johnf> sorry bzr add rdfapi-php
<yeonhoo> nothing happens
<yeonhoo> just one more blank line
<lifeless> ok
<yeonhoo> is it bzr internal problem?
<lifeless> please run 'bzr --version'
<yeonhoo> i should reinstall ?
<lifeless> look for the line that says 'Bazaar log file:'
<lifeless> rename that file on your disk
<yeonhoo> ok
<lifeless> then run 'bzr info -v', 'bzr st', 'bzr add'
<lifeless> these will put data into th elog
<lifeless> upload the log somewhere
<lifeless> and also, what version of bzr do you have
<yeonhoo> ok
<yeonhoo> 1.11 version..
<yeonhoo> lifeless : unknown is persisting ..
<yeonhoo> bug!?
<yeonhoo> according to info -v : i have 100 unknown files..
<yeonhoo> well im going to switch to 1.3
<johnf> yeonhoo: did you upload the log file some where we can look at it?
<yeonhoo> hum
<yeonhoo> switched to 1.3 but not solved problem
<yeonhoo> what i think is the project has in each directory .svn folder
<yeonhoo> i think it is affecting the add command.. or not -_-...
<lifeless> yeonhoo: have you uploaded the log for us yet?
<lifeless> also 1.3 is much older than 1.11
<yeonhoo> ah sorry i didn't
<yeonhoo> i saw now
<yeonhoo> well the last log you mean?
<yeonhoo> http://pastebin.com/m4638006e
<yeonhoo> well its the last log file after changing log file's name
<lifeless> yeonhoo: ok, you are using bzr on a svn project, which is fine
<lifeless> yeonhoo: but I guess you don't have commit access to the svn repository>
<lifeless> ?
<lifeless> actually.. .
<lifeless> Unable to open <bzrlib.transport.local.LocalTransport url=file:///C:/Users/yeonhoo/yeonhoo-serv/rdfapi-php/rap-pubby/templ/> with Subversion: Unable to open an ra_local session to URL
<lifeless> jelmer: ^ why isn't this showing an error for yeonhoo
<lifeless> yeonhoo: so whats happening is that:
<lifeless> C:/Users/yeonhoo/yeonhoo-serv is a bzr project
<yeonhoo> hum..
<lifeless> yeonhoo: and all the folders under it are in svn
<yeonhoo> yes
<lifeless> yeonhoo: bzr looks at them, can see they are in svn, and ignores them because they count as nested trees
<lifeless> you can either work with them directly, or branch from svn to get your own bzr branch of the svn project, or remove the .svn directories, if you want to just copy the stuff on your disk into bzr
<johnf> lifeless: does bzr have a concept similar to svn-externals?
<lifeless> johnf: nested trees
<yeonhoo> yes... then i stated to delete .svn folder in each directory manually
<lifeless> johnf: incomplete, being worked on
<johnf> cool
<yeonhoo> but there are much..then i gave up
<lifeless> yeonhoo: as I don't know your overall goal, I can't recommend which course of action is best for you
<yeonhoo> ok..!
<Peng_> Did something change in bzr.dev or http://bazaar-vcs.org/bzr/bzr.dev/ this week? I swear pulling it is slower and uses more bandwidth.
<yeonhoo> thank you very much!!
 * Peng_ should be unlazy and do a test.
<yeonhoo> i really apreciate your attention and help!! thank you guys!
<lifeless> Peng_: nothing that should affect that, no
<yeonhoo> well now im going to sleep then...bye!
<Peng_> It took 35-45 seconds to pull bzr.dev on the 16th and 17th, and 75 seconds yesterday and today.
<Peng_> http://bazaar-vcs.org/bzr/.bzr/repository/ got autopacked on the 20th, but that probably happens a lot.
<lifeless> Peng_: interesting; if you roll back your bzr.dev?
<Peng_> Hold on.
<Peng_> Plus I have bzr-search and the revgraph cache slowing things down a bit.
<lifeless> :P
<lifeless> it could be just more commits
<Peng_> I can't say about the commits, but on the 16th and 17th, pulling changed a lot more files than yesterday and today.
<Peng_> Yesterday and today, I think there were only 2-3 mainline revisions and maybe 6 merged revisions.
<lifeless> and you pull with bzr.dev itself yes?
<Peng_> Yes.
<jelmer> lifeless: sorry, just got back
<Peng_> Just took 41 seconds doing it with current bzr.dev in a new repo. Eh.
<Peng_> (No bzr-search indexes.)
<jelmer> lifeless: Did yeonhoo's problem get solved? If not, can you summarize it?
<Peng_> Maybe the layout of my repo is just hitting some bad case.
<lifeless> jelmer: have a look at the last pastebin
<lifeless> Peng_: perhaps your local repo autopacked
<lifeless> Peng_: some large power of 2
<lifeless> jelmer: http://pastebin.com/m4638006e
<lifeless> jelmer: partly confusion, but he had a bzr tree with svn dirs in subdirectories
<jelmer> lifeless: what exactly didn't work?
<jelmer> (looking at the pastebin now)
<lifeless> jelmer: well, all the subdirs were detecte as nested trees
<lifeless> and thus ignored by bzr add
<Peng_> lifeless: Shouldn't autopacking make it faster?
<lifeless> thats the confusion bit
<lifeless> but the lack of errors is what I was noting, his RA connections were all failing, but nothing was said
<lifeless> Peng_: oh is it still slow?
<jelmer> lifeless: it's correct the RA connections are failing, since these were working trees not repositories
<lifeless> jelmer: ah
<lifeless> jelmer: do we need to log it in that case?
<Peng_> lifeless: This was on a fresh, fully packed repo.
<lifeless> [it confused me]
<Peng_> It took 43 seconds with bzr.dev -r date:2009-03-15. Maybe I'm just crazy.
<lifeless> Peng_: I'm confused by this :P
<jelmer> lifeless: Yeah, we probably shouldn't
<lifeless> jelmer: knowing its a svn tree is useful, seeing what looks like an error but is expected isn't :)
<Peng_> lifeless: Using the latest bzr.dev of the time, on the 16th and 17th, it took 35-45 seconds to pull the latest revisions of bzr.dev. Yesterday and today, it's taken 75. On a test repo missing the latest 2-3 revisions, it takes 40-45 seconds with both the latest bzr.dev and a week-old version, but that's without bzr-search indexes or a working tree, which could potentially take close to 30 seconds.
<Peng_> Oh, plus that it's better-packed.
<lifeless> Peng_: what happens if you use the bzr of the 15th to pull those 2-3 revs
<Peng_> lifeless: Err, you're right. This is confusing. I did do that: it was about the same pulling in the test repo.
<Peng_> I can't exactly test in my main repo since it already has the latest bzr.dev.
<lifeless> so, if bzr.dev and older-.dev are the same in the new repo
<lifeless> it suggests either the network changed, server changed, or your older repo changed
<lifeless> how many packs does your main repo have
<lifeless> there was that new theme put up
<lifeless> kfogel: ping
<Peng_> lifeless: 14 at the moment.
<lifeless> I suppose its possible some rewrite rule got botchified
<kfogel> oh
<kfogel> lifeless: hey, just responding to your mail
<kfogel> I wrote "takes" when I should have written "already has" in the opening of my mail, which probably led you to think that I had much less understanding of the bzr commit process than I do :-).
<lifeless> kfogel: cool
<lifeless> kfogel: :)
<Peng_> Hmm, I pull brisbane-core in the same repo, and it hasn't gotten slow.
<lifeless> Peng_: bbc is on lp
<lifeless> so
<Peng_> lifeless: Yeah, I know. But if something was wrong on my end, it should be affected (effected?).
<lifeless> indeed
<kfogel> lifeless: I'm not sold on my proposal -- fixing the root cause would be much better.  But the bug's been open for two years with this user-visible manifestation :-).  Nothing in the commit process conflicts with grabbing a commit message earlier and calculating a checksum -- they can be done before the commit is even *started* if we want.
<lifeless> kfogel: checksum of what
<kfogel> lifeless: the overall change.  a change fingerprint.
<lifeless> kfogel: (and yes, it does - we show the diff in the commit message for people)
<lifeless> kfogel: how would we get the overall change without calculating the result?
<Peng_> Is it possible to check which revisions are in a specific .pack? "dump-btree" on the index?
<lifeless> Peng_: yes exactly, the .rix
<kfogel> lifeless: ?  not sure I understand that question.  We can calculate anything we want; it's a read operation... ?
<kfogel> lifeless: the current arrangement and sequence of code is not written in stone, I guess is what I mean.  There definitely _is_ a performance implication here, of doing work twice, I see that.
<lifeless> kfogel: we're going to have to be much more specific, assume _no_ common ground or something
<kfogel> hmmmm
<kfogel> lifeless: so, as part of the commit process, bzr currently calculates an overall change fingerprint, right?
<Peng_> lifeless: I swear something odd is happening in my repo. Should a 15-line diff lead to a 2.5 MB .pack?
<lifeless> kfogel: no
<lifeless> it doesn't
<lifeless> Peng_: fulltexts can do that
<kfogel> lifeless: but ... here is the level of detail I'm not sure you want to go into.  There is such a thing as "calculating a fingerprint for a VC change": there are known algorithms, they always produce the same fingerprint for the "same" change, etc.  right?
<lifeless> kfogel: no, we don't do that
<lifeless> we fingerprint whole trees, not deltas, today.
<kfogel> lifeless: yes, I get that :-).  I'm just asking a general algorithmic question.  HOWEVER, I think it is really academic
<kfogel> the perf implications of my proposal are frightening even to me, I agree it's a no go on those grounds alone.
<lifeless> sure, one could define an algorithm to fingerprint a delta
<kfogel> lifeless: that's all I was ever talking about in my proposal.
<kfogel> I think I probably wrote it up in too few words, causing needless head-scratching.  Oh well.
<lifeless> or perhaps too many :P
<kfogel> Well, only in the sense that the proposal itself might be too many :-).
<lifeless> I would have said something like ... 'can we just temporarily release the OS-lock on dirstate while we wait for the commit message'
<kfogel> But ... so what do we do?  blocking read operations is a serious lose.
<kfogel> lifeless: but then the change could change under you
<kfogel> lifeless: then there *is* a race condition
<Peng_> lifeless: Oh, good point. It was probably a fulltext. Or 10?
<kfogel> because you couldn't necessarily detect it, right?
<lifeless> kfogel: uhm, you have skupe?
<lifeless> I want more bandwidth, to get you across these internals
<kfogel> lifeless: heh.  I have two boxen; one at an office, where I *just* got skype working today, and one at home, where I haven't yet debugged my microphone sound problems.
<kfogel> I'm at home right now.
<lifeless> I did sketch it in my mail, but it seems lacking
<lifeless> ok
<kfogel> lifeless: where are you?
<lifeless> so..
<lifeless> .au
<kfogel> hmmmm
<kfogel> what phone #?
<kfogel> (priv msg is fine)
<Peng_> Moving a working tree to another partition will change all the inodes and make "bzr st" need to rescan everything, right?
<lifeless> yes
<Peng_> \o/
<lifeless> thats pretty fast though
<lifeless> its just read the file once
<lifeless> if you have just copied it, its in cache etc
<Peng_> Yeah, I know.
<Peng_> lifeless: FWIW, I just pulled the latest 2 revisions of bzr.dev (with bzr.dev) in 32 seconds, on my original repo and branch. This was after moving it from a small, nearly-full ext3 partition to a much larger ReiserFS partition, though. :\
<lifeless> Peng_: do you think that has anything to do with it?
<Peng_> lifeless: Probably. At the very least, it was rather unscientific of me to do.
<lifeless> :P
<Peng_> s/Probably/I don't know/
<Peng_> That ext3 fs is probably fragmented badly.
<lifeless> fsck can tell you
<Peng_> Sorry, moving all of that data was terrifying enough. I'm afraid of doing something wrong with fsck and destroying my fs. :P
<lifeless> oh, you don't need to umount it
<lifeless> fsck -n
<Peng_> But accidentally fscking a mounted fs could ruin it.
<lifeless> not with -n
<Peng_> What if I forget -n?
<lifeless> Peng_: don't forget
<Peng_> Err, what the hell? bzr.dev's push location changed.
<Peng_> Oh, I bet I need to update locations.conf.
 * Peng_ stops panicking.
<lifeless> vila: ping
<lifeless> jml: yo
<vila> lifeless: pong
<lifeless> vila: do you have a copy of tests.parallel with both our stuff in it?
<vila> lifeless: no, I have a loom with a lifeless thread where I import your modifications
<vila> It's at lp:~vila/bzr/parallel-selftest but it doesn't contain your latest ec2 changes
<lifeless> k
<lifeless> I would like the patches you promised me :P
<vila> and at that location it should be a simple branch
<lifeless> I'm shuffling stuff around lots still :)
<vila> oops, I didn't push
<vila> done
<vila> revno 4175 should contain the stuff I use here
<lifeless> vila: could you arrange for some patches?
<lifeless> vila: there are three projects involvled..
<vila> AFAICT I have changes against bzr.dev only so far, let me see
<lifeless> vila: I know you do, I'm noting that this is what we need to split out
<lifeless> which is why I want to deal in patches rather than in branches
<vila> Agree, I'd want to be able to use it on any bzr branch
<vila> but using branches instead of patches is easier for me when applying :)
<vila> lifeless: bundle sent, check your mail
<vila> it contains some trivial fixes for bzr.dev irrelevant here so just ignore the noise :)
 * vila goes back to its late breakfast 
<lifeless> :P
<lifeless> ok, ec2 polished a tad more..., 3m36 to do a test run
<LarstiQ> moin
<LarstiQ> johnf: I suppose at this time you are not awake?
<LarstiQ> johnf: anyway, I had troubles pushing the hard-ppa bzr-svn branch up to launchpad, intrepid-ppa is already pushed, packages for intrepid and hardy are in bzr-ppa and bzr-beta-ppa
<LarstiQ> johnf: I'll get to the rest today
<LarstiQ> johnf: as to the future, I'm open for suggestions.
<CMooney> Hi
<CMooney> Can bzr work with avahi?
<jelmer> CMooney: yes, there is a plugin
<CMooney> brilliant!
<CMooney> jelmer, How reliable is it?
<CMooney> Also if I am using bzr on one computer on my network, how to do pull across a current version to another machine on that network (hence me asking about avahi)? Seems the guide assumes you connect to a server via http
<jelmer> CMooney: which guide?
<CMooney> Ah right, just read the official guide rather than the "Bzr in five minutes" and I think it has the information I need
<CMooney> got it. I can use stfp because I have ssh installed
<jelmer> the avahi plugin mainly allows you to announce and browse branches on the local network
<CMooney> I am having a bit of trouble again.
<CMooney> I am able to checkout a version from one machine. I edit it on my laptop, commit the change, then try and merge. The merge doesnt work and I get "Nothing to do." from bzr
<LarstiQ> CMooney: merge what into what? Bzr thinks all the revisions of the <merge-from> branch are already in the <merge-into> branch.
<CMooney> LarstiQ, I thought you had to merge your changes into the main repo. eg merge the changes from my laptop to my main machine.
<CMooney> Do I need something else?
<LarstiQ> CMooney: if you have a checkout, and not a standalone branch, then when you commit in the checkout both locations will have the same set of revisions.
<LarstiQ> CMooney: if you don't have a checkout, and your branches haven't diverged (true so far), push/pull make more sense than merge.
<CMooney> So I have an edited (updated) document on my laptop, that I now want to send to my desktop. How would I do that?
<CMooney> LarstiQ, Ooops. Reading the documentation, I realise the word "Checkout" had a specific meaning, which I did not intend to use. I meant to say I have a branch on my laptop. (I think that's the correct terminology)
<LarstiQ> CMooney: how did you get the branch on your laptop?
<CMooney> bzr branch sftp://.../Writeup/
<LarstiQ> CMooney: cool
<LarstiQ> CMooney: so, after you committed, do `bzr push :parent`
<LarstiQ> CMooney: after that first push, bzr will remember your push location. Also see `bzr info`
<CMooney> So if I open that file on the main computer (parent) now, it should be the version that I made on the laptop?
<CMooney> LarstiQ, So if I open that file on the main computer (parent) now, it should be the version that I made on the laptop?
<LarstiQ> CMooney: push doens't update the working tree, so you'd need to `bzr up` on the main computer
<LarstiQ> CMooney: but all the data in .bzr/ is as it should be.
<CMooney> so push put the updated file into .bzr and then "bzr up" accept the changes.
<NfNitLoop> push will update the working tree for a filesystem-local push, though, right?
<NfNitLoop> cmoomey: yep
<CMooney> Thanks for your help, LarstiQ
<LarstiQ> NfNitLoop: true
<meoblast001> hi
<meoblast001> i upgraded to jaunty and now my passphrase won't work
<meoblast001> wait
<meoblast001> nvm i think i know the problem
<ronny> lifeless: what are the plans for porting bzr to python3?
<jelmer> moin ronny
<SamB> ronny: why would there be plans like that?
<ronny> trying to get a psf umbrella for a gsoc project, they have push python3 politics
<SamB> silly peoples
<LarstiQ> SamB: for the unicode/bytestring seperation
<LarstiQ> evening ronny
<ronny> yo LarstiQ
<LarstiQ> ronny: I'm not aware of any plans, dependencies like pycrypto and paramiko need to be tackled too
<ronny> isnt paramiko from bzr people, too?
<LarstiQ> ronny: no, the paramiko author has contributed to bzr a bit, and vice versa, but it's a seperate project
<ronny> ah, i see
<SamB> wouldn't you also need to get plugin writers to switch at the same time?
<LarstiQ> SamB: we're not going to leave 2.x for a long while
<jelmer> SamB: I think (hope) the idea would be to support both Python2 and Python3 for a while
<LarstiQ> SamB: you're right you'd want plugins to work with 3, but luckily it doesn't have to happen all at once
<SamB> what? both 2 and 3?
<SamB> how?
<Peng_> Bazaar is terribly complicated. Concurrent 2 and 3 support would be difficult.
<jelmer> Peng_: Separate code bases perhaps
<SamB> jelmer: very funny!
<jelmer> SamB: ?
<jelmer> I don't think that's *that* unreasonable
<LarstiQ> SamB: the recommended py3k support route is having it be generated from the 2.x codebase, no hand editing
<SamB> oh
<LarstiQ> SamB: up to the point you drop 2.x support
<LarstiQ> Peng_: that could be true
<Peng_> LarstiQ: Yeah, but 2to3 isn't perfect. And you have to ditch 2.5 and 2.6 support.
<Peng_> Don't you?
<LarstiQ> Peng_: let's try it! :)
<LarstiQ> Peng_: no
<jelmer> Peng_: s/2.5 and 2.6/2.4 and 2.5/ ?
<LarstiQ> Peng_: 2.5 possibly
<LarstiQ> Peng_: depending on how you write it
<Peng_> jelmer: Err, yes.
<LarstiQ> Peng_: 2.6 is explicitly supported
 * Peng_ has been up a while now
<Peng_> Yeah, typo. I meant 2.4 and 2.5.
 * SamB doesn't *have* anything newer than 2.5
<davidstrauss> abentley: ping
<LarstiQ> SamB: nor do I on Lenny
<SamB> does bzr have excellent unit tests with close to full coverage?
<SamB> doesn't the approach outlined in PEP 3000 wreak havoc on the file history in version control?
<LarstiQ> SamB: I don't know where coverage is at now, `bzr selftest` runs the suite.
<LarstiQ> SamB: which parts wreaks havoc?
<LarstiQ> SamB: if possible, the v3 code would be generated in the build step prior to rolling a tarball.
<LarstiQ> SamB: if you replace your current code with it, then it will screw with your annotations in the same sense as any other large mechanical change.
<LarstiQ> SamB: is that what you meant?
<SamB> well, yeah, I guess
<Peng_> Making it ready for 2to3 would probably mess up annotate enough.
<LarstiQ> Peng_: we'll have to try and see
<lifeless> ronny: our main criteria is keeping python2.4 working, at this point
<lifeless> vila: btw
<lifeless> vila: using runner.stream was deliberate :P
<ronny> lifeless: ah, i see
<lifeless> ronny: if we can get a python3 version of bzr, with all our external dependencies (medusa, paramiko, subvertpy etc etc etc etc), thats cool, but it doesn't help people who want to install bzr on current released distro's
<lifeless> We're *starting* to talk about moving the minimum version up to 2.5.
<mathrick> hiya
<mathrick> the PPA package for 1.13 seems to be broken
<mathrick> it installs bzrlib versioned for 1.11
<mathrick> which occasionally (but strangely, not always) explodes in my face
<mathrick> mathrick@hatsumi:~/Dev/Lisp/kabinett$ bzr add bugs.org
<mathrick> bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 11, 0)". It supports versions "(1, 13, 0)" to "(1, 13, 0)".
<mathrick> I made sure to purge and re-install the package, and the error persists
<jelmer> mathrick: looks like you have a plugin installed that is outdated
<mathrick> oh, hmm
<jelmer> mathrick: perhaps in ~/.bazaar/plugins?
<mathrick> possible
<LarstiQ> mathrick: which distro ppa is this btw?
<mathrick> but the error isn't particularly lucid if that's the case
<mathrick> LarstiQ: ubuntu intrepid
<jelmer> mathrick: yeah, the error isn't very clear
<LarstiQ> mathrick: `bzr plugins` output?
<mathrick> http://pastebin.com/m49cb7401
 * mathrick starts with bzr-svn 0.4
<mathrick> yup
<LarstiQ> mathrick: right, the ppa should provide you with bzr-svn 0.5.3
<mathrick> yeah, I have it
<mathrick> I just didn't disable the locally installed 0.4
<LarstiQ> right
<mathrick> it works now
<mathrick> thanks
<LarstiQ> mathrick: np
<cody-somerville> BjornT, jml: The particular file is The particular file is .bzr/branch-format
<jml> cody-somerville: Branch.open requires read permissions to, roughly speaking, everything inside .bzr.
<cody-somerville> jml, weird. I did bzr -R +r .bzr
<cody-somerville> disclaimer: trying to do it from within a django app
<jml> cody-somerville: opening a bzrdir from a django app?
<lifeless> hi jml
<cody-somerville> Yea
<jml> oh right.
<jml> lifeless: hi
<cody-somerville> I'm trying to get it to print the revno of the branch the codebase runs out of
<lifeless> jml: 3m36 on ec2 with a hot intance
<jml> lifeless: nice.
<lifeless> well, 2 hot instances but yeah
<fullermd> For what?
<lifeless> BZR_PARALLEL=ec2=2 ./bzr selftest --no-plugins
<fullermd> Dear $DEITY.
<lifeless> fullermd: runs on ec2 reports on my laptop
<lifeless> brought to you by the letters subunit, testtools and bzr
<fullermd> Man, if it took that long, I might run it once in a while...
<lifeless> fullermd: indeed :P
<LarstiQ> sooo, faster pqm?
<lifeless> LarstiQ: once its all landed, I'll start asking about budget to do that
<lifeless> pqm will probably want to keep some warmed up instances, or use the ec2-alike facility internally
<lifeless> a cheap approach though would be to get a second core for pqm
 * fullermd guesses he needs to upgrade hardware...
<LarstiQ> lifeless: how much does the ec2 run cost then?
<lifeless> I've accrued 23USD developing this
<lifeless> $0.80 per High-CPU Extra Large Instance (c1.xlarge) instance-hour (or partial hour)   27 Hrs
<LarstiQ> ok
<lifeless> thats a 8-way machine
<lifeless> the charge is not cpu time, its commissioned-time
<lifeless> so if we brought up 5 of those, its 2 dollars an hour
<lifeless> there are lots of hours in a month ;P
<lifeless> http://aws.amazon.com/ec2/instance-types/
<lifeless> we get <roughly> linear per core
<lifeless> some tests are more expensive, and this isn't trying to make all the cores stop simultaneously
<lifeless> so in the highcpu flavours, its 10c/hour/cpu
<lifeless> and in standard ones its 10 or 20c/hour/cpu which is why I went highcpu
<LarstiQ> ight
<lifeless> anyhoo, back in a bit
#bzr 2009-03-22
<Spaz> hmm
<Spaz> i'm using bzr_access to grant multipule users access to the same repository, any way i can make it play nice with bzr?
<Spaz> er
<Spaz> s/bzr\?/CIA/g
<Spaz> wow i'm a failhouse tonight
<Spaz> actually
<Spaz> let me rephrase that
<Spaz> any way to get bzr-cia working when using bzr_access?
<lifeless> Spaz: I don't see why they would be related or interact at all
<Spaz> lifeless, basically, i want to report commits to the main repo
<lifeless> sure, I'm just saying I don't see the correlation with bzr-cia
<lifeless> and bzr_access
<lifeless> did you have it working with bzr-cia and not bzr_access?
<emmajane> abentley: pokpokpoke you know william witteman?!
 * emmajane also has a random bzr question about this thing called "redhat"?
<lifeless> just ask :P
<emmajane> for the gitvsbzr thingy someone was complaining that tests are breaking in redhat? Other than, "stop using redhat" is there an answer for that or someone who is somewhat responsible for that?
 * emmajane had to phrase it, lifeless :)
<emmajane> or figure out how to phrase it rather. :)
<lifeless> I don't think any of the high-volume contributors to bzr itself develop on redhat
<emmajane> hrm.
<emmajane> so the answer is sort of switch to ubuntu? ;)
 * davidstrauss still has 11 failures from selftest on CentOS 5 with bzr + BzrTools
<emmajane> davidstrauss: dude. ouch.
<lifeless> emmajane: no, its more - file bugs
 * emmajane nods. kay. thanks, lifeless 
<lifeless> on any platform we would expect
<lifeless> 'make check' to pass
<lifeless> win32 has some known issues
<lifeless> so make that any foss platform :P
<emmajane> heheh
<lifeless> bzrtools is part of the ecosystem, but we don't require zero-failures from it at any point in time like we do for bzr itself
<davidstrauss> The one that concerns me most is this: FAIL: per_lock.test_lock.TestLock.test_readonly_file(fcntl)                    IOError not raised
<lifeless> davidstrauss: don't run the tests as root
 * emmajane blinks.
<lifeless> all mainline commits to bzr since it moved to pqm are done by pqm only after the test suite passes
<davidstrauss> lifeless: very nice :-)
<davidstrauss> lifeless: Indeed, the "root" issue makes sense.
<davidstrauss> lifeless: This is on my package building VM
<emmajane> what is pqm? sorry. :/
<lifeless> emmajane: its a robot that takes a branch and merges it to the mainline for us
<lifeless> it enforces the tests-pass policy for us
<emmajane> lifeless: ah, cool.
 * emmajane nods
<emmajane> makes sense.
<lifeless> without requiring every developer to remember, or be trusted to always remember
<lifeless> or have the reference platform (python 2.4, all dependencies, etc)
 * emmajane nods.
<lifeless> davidstrauss: so if you can run the test suite (make check) as non-root, I'd love to know about failures
<emmajane> lifeless: for the bzrvsgit is it then, 'we love you all, but please submit bugs'?
<lifeless> emmajane: yes
<davidstrauss> lifeless: Trying now
<emmajane> lifeless: cool :)
<emmajane> lifeless: I was a little bit like, 'redhat? RLY?'
<lifeless> I'm reasonably sure the redhat packagers run the test suite w/o errors
<lifeless> and we'd certainly pay attention to any issue
<lifeless> I will note though, that I can only really check fedora to reproduce things, RHEL being proprietarish and all
 * emmajane nods. kay. I'll check back if I have more useful information, but this is cool
<lifeless> reason #34 to be fully open source; people can debug on your platform
<lifeless> I'm heading off for a bit, ciao
<emmajane> lifeless: thanks muchly, as always. :)
<davidstrauss> lifeless: I'm using CentOS
 * emmajane tries poking abentley again.
<thumper> are there any pages on the bzr wiki about google summer of code?
 * thumper waves at emmajane
<emmajane> thumper: are you doing gsoc?
 * emmajane waves to thumper 
<thumper> heh
<thumper> I think that is a little unlikely
<thumper> I'm not a student any more
<emmajane> nonnono Imean "you" not "you"
<thumper> however I know someone who knows students, and I'm trying to pass on details
<thumper> emmajane: yes bzr is trying to organise gsoc
<emmajane> thumper: the org alread has to be approved...
<thumper> emmajane: I believe igc is handling it
<Spaz> lifeless, ah, i got it all working with a ghetto script
<emmajane> thumper: are you doing it under ubuntu? I think i read that they got in?
<Spaz> it basically cd's to where the repo is and does bzr cia-submit for all new revisions
<thumper> emmajane: I don't know that much about it other than poking people to make sure bzr gets involved
<emmajane> thumper: I think you might have missed it if you're still poking peoople. :)
<thumper> :(
<thumper> emmajane: is there a definitive list of approved projects?
<emmajane> thumper: clearly poking is not so productive. less of the poking, more of the doing.
<thumper> emmajane: I know that someone is doing
<emmajane> yay
<thumper> emmajane: and I think that someone is igc
 * emmajane checks the site.
<emmajane> http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
<emmajane> thumper:  idon't see bzr there :(
<emmajane> I lied, Ubuntu isn't there either.
<emmajane> maybe that was an application, but not acceptance.
<thumper> oh FFS
<emmajane> :(
<thumper> emmajane: I'm at a loss for words
<emmajane> thumper: that's sad. :(
<wgrant> Ubuntu was unaccepted, I think
<wgrant> It was there for a while.
 * emmajane nods to wgrant 
 * emmajane tries to figure out how to use irssi.
<emmajane> which is completely unrelated to anything.
 * thumper uses konversation
<thumper> I tried irssi for about two days
<emmajane> heh
 * wgrant was tempted to move to Quassel, but has been using irssi for almost three years now.
<wgrant> Originally I used XChat.
<emmajane> I'm on an EEE and don't have any in-depth trust that it will still be xandros tomorrow so is on her server using irssi.
<emmajane> and apparently I'm tired and can't figure out which person to speak in.
<emmajane> or something.
<emmajane> wgrant: what does [Act: 1,2,4] mean?
<thumper> gah
<thumper> network manager is running amok
<emmajane> thumper: did you figure out your adsl stuff?
<emmajane> thumper: I always have problems with my network dropping my irc connections at home.
<thumper> emmajane: yeah, I got a clean cat-5 cable from where the telephone line enters the house, and now goes through a main filter there, all the way to my router
<emmajane> thumper: nice.
<thumper> emmajane: not had any adsl problems since then
<emmajane> thumper: maybe just generally the internet hates you?
<thumper> emmajane: my hardware hates me more than the internet does
<emmajane> heh
<emmajane> thumper: also: my wireless card causes kernel panics as of a couple of weeks ago. that was handy while on the road.
<thumper> heh
<thumper> :(
<emmajane> hence the eee
<thumper> I'm going to make some cookies now
<thumper> peanut brownies
<emmajane> mmmcookies
<emmajane> thumper: enjoy :)
<thumper> emmajane: I will
<emmajane> Â´
<emmajane> hrm. /me spams the channel while she messses up her meta keys
<emmajane> brb
<lifeless> there is some confusion re: gsoc and ubuntu
<lifeless> wait a few days
<emmajane> yay! control-n control-p is your friend.
<wgrant> emmajane: [Act: 1,2,4] shows the windows that have activity.
<wgrant> Bold white means there's some new line of conversation.
 * emmajane nods to wgrant 
<emmajane> my alt key wasn't mapped corectly but someone at the sprint just toldme about control-n control-p
<jelmer> from what I've heard (on the GSoC list) Ubuntu has withdrawn from GSoC
<lifeless> jelmer: 'there is some confusion'
<lifeless> jelmer: 'wait a few days'
<jelmer> lifeless: that's different from "Ubuntu has withdrawn"
<lifeless> jelmer: yes
<jelmer> lifeless: The source here is Leslie, who is in charge of GSoC
<lifeless> jelmer: I know
<lifeless> jelmer: And yet, I'm saying that there is some confusion and you should wait a few days.
<lifeless> not being the ubuntu gsoc contact myself, or leslie, I can't really say more
 * emmajane really ought to read some of the backlog of the gsoc list.
<lifeless> s/say more/know more/
<emmajane> hrm.
<emmajane> on the list from lh "Lime Survey has replaced Ubuntu."
<lifeless> yes
<emmajane> lifeless: but that is not necessarily the case?
<lifeless> well clearly it is from LH's perspective, I have *no* idea on the Ubuntu front, other than people thinking we're in
<lifeless> at the least there is confusion, at worst there is utter confusion and things will change
<lifeless> its the weekend for doko, he's probably skiing or something
 * emmajane nods.
<lifeless> the only thing I would bet on right now is that there is a lot of confusion
<emmajane> lifeless: which is often not a good way to start a projec.t ;)
<lifeless> there's nothing on ubuntu-devel, ubuntu-soc etc indicating a pull-out
 * emmajane nods. confusion.
<igc> emmajane: as best I know, ubuntu was accepted
<igc> otoh, I screwed up getting an application for bzr in on time, so we not, at least as a stand-alone project
<igc> s/we/we're/
<emmajane> igc: aww :(
<igc> it's very likely we'll do something though - either as part of ubuntu or just separately
<emmajane> igc: but we don't know how many slots yet, do we?
 * emmajane is helping out with the drupal one too very very peripherally.
<igc> emmajane: we do have a good list of project ideas put together - see http://bazaar-vcs.org/SummerOfCode2009
<igc> emmajane: so if you know anyone interested in doing those, students or otherwise, ask them to get in contact with me
 * emmajane reads.
<emmajane> igc: drupal also has a VCS proposal, but I'm not sure what its status is.
<emmajane> igc: have you been talking with any students yet?
<emmajane> (regardless of ubuntu/bzr acceptance)
<abentley> emmajane: That name doesn't ring a bell...
<emmajane> abentley: formerly william o'higgins; friend of mike audet
<emmajane> abentley: not sure on the spelling of mike's last name.
<abentley> Oh, sure.  He's good people.
<emmajane> abentley: we went to uni together.
<abentley> Cool.
<abentley> Which uni?
<emmajane> abentley: I'm actually in TO this weekend for a sprint.
<emmajane> abentley: UofT.
<abentley> Yeah, I went there too, that's how I met Mike, and therefore William.
<emmajane> abentley: small. world. :)
<emmajane> abentley: I was there 95-99.
<abentley> emmajane: So how'd you find out I know William?
<emmajane> abentley: he left a comment on my bzrvsgit post
<emmajane> abentley: he likes bzr because of you
<emmajane> abentley: and also because bzr is awesome
<abentley> Ah.
<abentley> Cool.
<emmajane> yah
<emmajane> and then someone else almost at the same time did one of those, You're both in canada do you know each other? things and... well..almost. :)
<davidstrauss> Just posted fresh RHEL/CentOS packages for 1.13: http://fourkitchens.com/blog/2009/03/22/bazaar-113-rpms-rhel-5-centos-5
<lifeless> davidstrauss: did the tests pass then?
<davidstrauss> lifeless: Still getting the file size mismatch failures
<davidstrauss> lifeless: The scarier fails went away when running as non-root
<lifeless> file size mismatch -> please do file a bug
<emmajane> night all!
<lamalex> So everything i read about bzr says that it handles file renames with mv, but that does not seem to be the case in my branches
<lifeless> lamalex: what do you mean by 'handles file renames with mv'
<lamalex> lifeless: as in say foo.c is in my bzr tree, and i rename it to bar.c, if I do bzr stat the file is missing
<lamalex> but the bzr docs, and things people tell me, say that bzr should reconizze the rename
<lamalex> and i should see foo.c => bar.c
<lifeless> lamalex: bzr doesn't do that; either do 'bzr mv foo.c bar.c' to do the move, or do 'bzr mv --after foo.c bar.c' to tell it afterwards
<lifeless> the docs definitely don't claim a heuristic to figure that out
<lamalex> what does it mean in http://bazaar-vcs.org/BzrFeatures
<lamalex> first bullet in Intuitive
<lifeless> lamalex: it means if you have a _branch_ you can rename the branch with mv
<lamalex> ahh
<lamalex> ok
<lifeless> and cp will make a new branch
<lamalex> right
<lifeless> and rm will remove a branch
<lamalex> i knew that
<lamalex> thanks
<lifeless> there is a plugin that will apply a rename-detecting heuristic
<lifeless> abentley has been working on it, I don't know what its called or where to get it though :P
<lamalex> oh yeah?
<lamalex> ill google
<lamalex> thanks
<lifeless> he was doing it for the tarball import stuff;
<lamalex> also, has there been some LP weirdness recently?
<lamalex> its been getting stuck on "Transfering:Walking Content"
<lamalex> a bunch of people in my project have seen it
<lifeless> in bzr 1.13 we changed the pull/push logic to allow streaming which is much faster
<lifeless> when bzr 1.13 is rolled out on the server you'll experience this
<lamalex> but with 1.6(?) on the server pushes take forever?
<lamalex> is the solution to just wait for the push to finish?
<lifeless> 1.11 on the server, and yes
<lamalex> ok
<lamalex> thanks for your help
<lifeless> the rollout is next week
<lamalex> awesome
<m3ga> give a file X in mu current directory, how do I tell if its under revision control  or not?
<lifeless> bzr status X?
<lifeless> or bzr inventory | grep X if you want a brute force approach, or st X doesn't do what you want
<m3ga> status says nothing, just returns
<m3ga> "bzr inventory | grep X" just prints out X which I assume means that it is under revision control
<lifeless> yes
<m3ga> where do  i lodge feature requests?
<lifeless> bugs.launchpad.net/bzr
<Peng_> m3ga: If X is versioned and unchanged, "bzr status X" will print nothing and return.
<m3ga> exactly  which is why i submitted this feature request: https://bugs.launchpad.net/bzr/+bug/346624
<ubottu> Ubuntu bug 346624 in bzr "Feature request : fileinfo command" [Undecided,New]
<m3ga> ah there it is
<Peng_> Well, actually, "bzr st ignored_file.pyc" will also exit with no output. Soo..
<m3ga> exactly. in the fetuare request I asked for four different catefories of output. there may be more.
<m3ga> why does the lp: transport need my launchpad login?
<m3ga> and then it goes ahead  and does what i want anyway?
<wgrant> m3ga: It needs your Launchpad username so that you can write to Launchpad, and also to use bzr+ssh to make things much faster.
<wgrant> But it will fall back to read-only HTTP if you don't tell it your username.
<lifeless> m3ga: because we haven't made every ui command indicate to the directory service if it needs a writable transport
<lifeless> m3ga: and launchpads http mirrors are read only
<m3ga> lifeless: i'm just a dumb-fsck user and you're telling me about lowlevel implementation details?  :-)
<lifeless> m3ga: asif :P
<m3ga> i think this is actually a real failing of all dvcs. the problem is very hard and that difficulty ends up leaking into the user interface
<lifeless> m3ga: We can do better here, but ETIME.
<lifeless> this part isn't particularly hard - merge (for instance) never needs a writable remote transport, push does, branch's target does etc
<m3ga> you're already doing well but i'm gonna keep beating you up about it, because too many people (esp git users) don't even realise that this problem exists
<lifeless> oh sure
<lifeless> long as you keep using bzr you can keep beating me up :)
<m3ga> i  did a fast-import into git today. a whole fscking world of surprises :-)
<lifeless> indeed
<lifeless> but it gives them to you fast
<lifeless> ciao
<vila> lifeless: I think I fixed that roughly by the time you mentioned it and laughed a bit doing that thinking about *you* laugh seeing my mistake :-P (The less funny part was realizing this wasn't covered by a test...)
<vila> lifeless: next step as I see it: add a test runner registry to bzr and register subunit/forked/subprocess there from a plugin that could die when each runner find its natural home, that left the problem of additional parameters to these runners open though.
<lifeless> vila: I've pushed new stuff; I don't see subunit/forked/subprocess as runners...
<alf> Hello, I have been experiencing some strange slowness (that wasn't present before) when trying to push a branch to lp.
<alf> I am using bzr-1.13rc1 (from debian unstable).
<alf> The local branch is in a shared repository with rich-root-pack format.
<lifeless> alf: there is new streaming code in 1.13
<alf> When trying to push a branch to lp which includes small changes (eg two added 100-line files) the push takes about 2:30 minutes with constant ~50 kb/s upload
<lifeless> alf: which lp hasn't deployed yet, but bzr gets too far down the code path to use the local-filesystem optimised path
<lifeless> alf: on thursday there is a rollout of 1.13 to lp, it will get massively faster for you then
<lifeless> <gone again>
<alf> lifeless: ok, thanks! I will just be patient then :)
<vila> <lifeless> I don't see subunit/forked/subprocess as runners...
<vila> Why ?
<vila> lifeless: nm, just got you rmail
<LarstiQ> arrr
<jelmer> LarstiQ: yarrrrrr
<LarstiQ> jelmer: what identi.ca client do you use?
 * LarstiQ tried TwitterVim
<jelmer> LarstiQ: I use the haskell one and gwibber
<jelmer> twidge
<LarstiQ> jelmer: ooh, twidge is actually in lenny
<Leon_Nardella> leon@bespin:~/Desktop/bzrtools$ bzr shell
<Leon_Nardella> bzr: ERROR: [Errno 2] No such file or directory
<Leon_Nardella> What am I doing wrong?
<Leon_Nardella> ( Er.. It works in my home Â¬Â¬ )
<LarstiQ> Leon_Nardella: does ~/.bzr.log provide a hint?
<Leon_Nardella> LarstiQ: I went to my home then back to the folder I was and now it's working.. Really weird.
<LarstiQ> Leon_Nardella: did the directory still exist?
<Leon_Nardella> Yes.
<LarstiQ> Leon_Nardella: ie, did you delete or mv it between cd'ing there and starting bzr shell?
<LarstiQ> (so, inode, not path)
<Leon_Nardella> No, no.
<LarstiQ> hmkay
<Leon_Nardella> http://paste.ubuntu.com/135571/
<Leon_Nardella> The interesting part from the log.
<Leon_Nardella> http://paste.ubuntu.com/135572/
<Leon_Nardella> Now it's like this.
<LarstiQ> as I thought, it's the 'get current working directory' call that returns 'No such file or directory'
<Turl> hi
<Turl> I had a typo on a commit message, can I fix it somehow?
<Turl> I still didn't push the message
<Turl> s/message/revision/
<LarstiQ> Turl: bzr uncommit; bzr commit
<Turl> thanks LarstiQ
<Turl> LarstiQ: it doesn't change the code, does it?
<LarstiQ> Turl: no, it leaves the tree state the same, but sets the branch to point at a prior revision
<LarstiQ> Turl: so if you then commit, you end up with a revision where only the commit message is different (well ok, the timestamp, revision id, maybe committer name if you changed that inbetween)
<LarstiQ> Turl: basically, you can fix mistakes like that :)
<Turl> ok LarstiQ, thanks :)
<mwhudson> so for my development version of loggerhead, viewing a revision page that adds 9000 files doesn't stress loggerhead too much
<mwhudson> ff, on the other hand...
<LarstiQ> mwhudson: yeah. I ditched ff(3) because it made my entire system unusable (sloow ssd + sqlite fsync + ext3 = hsd)
<mwhudson> LarstiQ: what do you use instead?
<LarstiQ> mwhudson: opera for now, since I have two colleagues idolizing it.
<LarstiQ> I don't care too much for the browser, but at least the rest of my system is usable.
<Turl> LarstiQ: believe it or not, opera is real slow in here :p
<mwhudson> LarstiQ: how does it do on the "fills one with burning rage" metric?
<Turl> that's why I use firefox
<LarstiQ> mwhudson: it scores a 3. But I haven't been using it very long.
<mwhudson> the first versions of ff3 were so fast
<mwhudson> what happened?
<LarstiQ> mwhudson: let me look up two urls that hit me
<LarstiQ> meh, logging
<LarstiQ> mwhudson: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 I believe
<ubottu> Ubuntu bug 317781 in linux "Ext4 data loss" [High,Fix released]
<LarstiQ> mwhudson: and from there a mozilla person blogpost
<LarstiQ> mwhudson: http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
<mwhudson> LarstiQ: that doesn't really explain why ff3 has gotten worse IME
<mwhudson> maybe it's just that my awesomebar.db or whatever is larger now
<LarstiQ> mwhudson: I don't know what got introduced when.
<LarstiQ> mwhudson: for me, I've only been using this Acer Aspire One since the second half of January
<LarstiQ> and I think I know why Acer ships FF2 by default..
<wgrant> mwhudson: I was able to speed things up a lot of trimming and vacuuming the SQLite DBs.
<wgrant> s/of/by/
<wgrant> I wonder if Firefox can be taught to use a RDBMS that doesn't suck.
<LarstiQ> wgrant: hmmm
<mwhudson> wgrant: i think an oracle license for every ff user would get a bit expensive!
 * mwhudson runs away, terribly fast
 * wgrant trips mwhudson.
 * LarstiQ dumps 'no we don't store support vectors for linear kernels' on mwhudson 
<garyvdm> I think they have been working on the performance of the awessomebar for ff3.5
<wgrant> At least Firefox never gets as slow as OOo.
<CBro2007> hi all, if I wanted to use bzr to create a trunk and some branches.. would I have to physically copy files to a directory like "myRepository/trunk" and then issue bzr init?
<CBro2007> is that how it works?
<CBro2007> also you think its a good idea to setup a "bzr" user on my CentOS machine so people with different accounts and userids can access it?
<CBro2007> anyone? :)
<CBro2007> wow no one helps out in this channel eh?
<CBro2007> silence is the key
<mwhudson> CBro2007: um
<mwhudson> for the first, yes, i think you're right
<CBro2007> ok
<mwhudson> for the second, well, it depends what you're trying to acheive
<CBro2007> well this is what I want...
<CBro2007> I got a bunch of project files on a shared server that I want to share with 3 other developers
<CBro2007> they all have their own unix accounts on this machine
<mwhudson> with you so far
<CBro2007> am wondering if there will be any problems if I am the owner of the trunk etc
<mwhudson> ah
<CBro2007> like the file ownerships would be in my name because I did an init-repo or something
<mwhudson> i think you could probably use a unix group for this
<CBro2007> so I want to give some thought to the dir sructure before I launch off
<CBro2007> I have setup a UNIX group to which we all belong
<CBro2007> :)
<CBro2007> so if I was to do this...
<mwhudson> then, so long as you use g+s or whatever the chmod thing is, i think it'll work alright
<CBro2007> bzr init-repo myRepository
<CBro2007> then create a dir for my project under there
<CBro2007> and then under that project create a dir called TRUNK to which I copy all the original project code
<CBro2007> ?
<CBro2007> right so far?
<mwhudson> yes
<CBro2007> ok...
<mwhudson> often times people create a repo per user, rather than all sharing the same repo
<mwhudson> and in addition have a central repo from where releases/rollouts are made
<CBro2007> mwhudson: is this recommended?
<mwhudson> it depends on your workflow really
<CBro2007> mwhudson: I suppose I am not super sure as to how we will MERGE our changes etc
<CBro2007> mwhudson: just don't want people stuffing up the GOLD COPY you know
<CBro2007> :)
<mwhudson> CBro2007: one of the nice things about bzr is that it makes many decisions that are technical with, say, svn, social
<CBro2007> how do you mean sorry?
<mwhudson> CBro2007: unfortunately this means that the answers to many questions become "um, well, it depends" :-p
<CBro2007> you mean it supports a lot of kind of workflows?
<mwhudson> CBro2007: what version control do you use now?
<mwhudson> CBro2007: yes
<CBro2007> used SVN and CVS in the past
<mwhudson> CBro2007: for "protecting the gold copy", there is PQM, which is a robot that merges branches for you
<CBro2007> want to move away from it to the distributed version control and enforce it amongst other developers alike
<mwhudson> and it can be configured to run tests before it accepts a branch
<CBro2007> Nah I would like to do that manually
<mwhudson> hang on, there must be a wiki page about this stuff
<CBro2007> myself
<CBro2007> ok
<CBro2007> I think I remember reading that in the user guide.. where you have a gateway keeper or something that can automate the merges
<CBro2007> I just want it a bit simpler where developers let me know when they think their branch is ready for a merge to the trunk
<mwhudson> CBro2007: http://bazaar-vcs.org/Workflows
<CBro2007> and then I can do it
<mwhudson> CBro2007: sounds like http://bazaar-vcs.org/Workflows#head-f5c9069eb3a6991f31e6b909dbb3fb12a45f34a5
<CBro2007> you mean centralized?
<CBro2007> I think I want the decentralized with human gatekeeper
<CBro2007> I like that workflow best
<mwhudson> CBro2007: no, "decentralized with human gatekeeper"
<mwhudson> right
<garyvdm> From what you said - I think Decentralized with human gatekeeper
<mwhudson> that seems to be basically exactly what you're describing
<CBro2007> Yeah :)
<garyvdm> haha
<CBro2007> thats what I want
<mwhudson> :)
<CBro2007> wow now how do I set this model up
<CBro2007> this is exactly what I want to do
<CBro2007> but the model doesn't show me a step by step scenario of how to do it :)
<CBro2007> was wondering if I need to even use launchpad or can I just merge stuff locally
<CBro2007> as it will all really just be UNIX accounts on the same machine
<mwhudson> you certainly don't need to use launchpad
<mwhudson> the docs are probably tilted towards open source-y things
<CBro2007> so is there a link that runs you through a scenario of how to setup that model?
<CBro2007> I mean how do I setup a "read-only" access to the MAIN branch
<CBro2007> and how do developers REQUEST MERGE?
<CBro2007> mwhudson: cmon man don't leave me hanging there? :)
<mwhudson> CBro2007: well, if you make the trunk branch rwxr--r--
<CBro2007> ah with UNIX permissions
<mwhudson> that's good enough for read only
<mwhudson> <CBro2007> and how do developers REQUEST MERGE?
<mwhudson> this is what i meant by a social question :)
<mwhudson> they can email you a merge request using bzr send
<CBro2007> whats the social qn part?
<CBro2007> hmm so there is no formal process of requesting a merge?
<mwhudson> CBro2007: it depends on how you interact as a team
<CBro2007> really well :)
<mwhudson> CBro2007: not in bazaar, no
<mwhudson> CBro2007: you can use launchpad merge proposals, if you use launchpad
<CBro2007> so if they did say ... well I just completed a feature and it looks great in my branch... ready to merge... what do I do next?
<mwhudson> if you aren't using launchpad, why not just use email?
<CBro2007> yeah we can e-mail
<mwhudson> bundlebuggy can make using email a bit more structured
<CBro2007> ok I can look into that
<CBro2007> but what I meant was that how do we keep the branches and the MAIN trunk/branch in synch?
<CBro2007> once I have reviewed their changes I want to merge their stuff into the GOLD COPY.. but then I am sure they want to be able to UPDATE their copies as well
<CBro2007> so they would probably also want to SHARE code between OUR branches... not necessarily having to merge into TRUNK
<CBro2007> does that make sense? :)
<lifeless> CBro2007: these are all things bzr supports
<lifeless> CBro2007: I have a suggestion for you: simulate this yourself, just make a toy branch, like 'hello world' or something, an dplay with merging committing branching pushing etc
<CBro2007> lifeless: yeah just wasn't sure how a command like "bzr merge" would do the trick... as it doesn't seem to have a source or a target mentioned in it
<lifeless> don't worry about server setup or anything else until you have a feel for how the tool is for a user
<lifeless> CBro2007: have you read the quickstart guide ?
<CBro2007> ;Yeah I was going to do that tomorrow
<CBro2007> Yep
<lifeless> so have a look at 'bzr help merge'
<CBro2007> you ar right... let me fiddle with it
<lifeless> it has examples of merging :)
<CBro2007> yep reading
<CBro2007> anyway got to go now
<CBro2007> thanks for the help guys
<CBro2007> take care!
<CBro2007> bye
<ToyKeeper> toy branches ++
 * ToyKeeper got a blue tab on 'toy'
<jml> lifeless: re bug 345169 -- did I see a patch for that on the list?
<ubottu> Launchpad bug 345169 in bzr "bzr push to a new lp branch of bzr from a local copy fails to stack" [Critical,New] https://launchpad.net/bugs/345169
<lifeless> jml: yes
<lifeless> jml: and is in bzr.dev already
<jml> lifeless: cool.
<jml> lifeless: shall I mark it as Fix Released?
<lifeless> r3174
<lifeless> 4174
<lifeless> yes
<jml> thanks.
<poolie> hello jml, lifeless
<lifeless> hi poolie
<jml> poolie: good morning
<lifeless> kfogel: ping
<lifeless> spiv: if you want to get together at my place today, that would be cool; if so just pop on over anytime
<spiv> lifeless: ok, will let you know
<spiv> Hmm, caffiene time.
<igc> morning all
 * garyvdm fights with qt to get QComboBox to do what I need it to do.
#bzr 2010-03-22
 * igc back in a few hours
<spm> *** FYI. Launchpad Codehost will be going down shortly for a code update. ~ 5-10 mins before I'll be doing so; ETA of outage < 30 secs, all going well. ***
<spm> *** About to restart Launchpad codehost for a code update ***
<spm> *** all done ***
<TimMiao> hello, I'm a newbie on bzr, I have an issue when I'm going to bzr launchpad-login with my id, it always tells me:
<TimMiao> bzr: ERROR: Connection error: curl connection error (error setting certificate verify locations:
<TimMiao>   CAfile: /etc/curl/curlCA
<TimMiao>   CApath: none
<TimMiao> )
<TimMiao> on https://launchpad.net/~tim-miao/%2Bsshkeys
<TimMiao> I'm sure I've uploaded my public rsa key, what's the problem?
<bob2> heh curl
<TimMiao> I'm using the bzr on OpenSolaris 2010.03 release
<TimMiao> bob2: excuse me?
<TimMiao> bob2: would you please give me some clue in detail? thanks! :)
<bob2> no, sorry
<igc> back
<poolie> bob2, that was kind of harsh
<bob2> sorry :| I misread it as being from get, so was going to suggest http+urllib
<bob2> but then realised I had no idea
<bob2> s/get/branch/
<poolie> i would guess he was trying to lp-login and it's trying to send xmlrpc over ssl
<poolie> and that's failing
<poolie> k, sprint stuff sent
<vila> hi all !
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0 is out
<poolie> hi vila
<vila> hey poolie !
<vila> poolie: I'll submit a fix shortly for bug #474807 and I did apply for patch piloting this week
<ubottu> Launchpad bug 474807 in bzr "MYSQL/BZR P3: Incomprehensible results of "bzr log -rX..Y"" [High,In progress] https://launchpad.net/bugs/474807
<vila> poolie: since the active review list is mainly from core, I plan to dig the wip queue and maybe have  a look at the bugs with patches
<poolie> hey, that's pretty good
<poolie> i barely saw you last week, being away and then having some activities in the evening
<vila> I paused a bit on the merge stuff, concentrating on some plugin paths and log bugs, thanks for the past reviews and even more thanks for the coming ones ;-)
<poolie> that's ok
<poolie> i spent today mostly doing some clerical things, including getting organized for Belgium
<poolie> i'm planning to take a holiday in the week after easter
<vila> there are two merges (well conflicts really) submissions waiting for review anyway
<vila> coll
<vila> cool
<dcoles> Anyone got an idea why `bzr serve --git` is currently hard coded to localhost?
<poolie> in what sense?
<dcoles> poolie: The serve_git function in server.py (of the bzr-git plugin) calls "server = TCPGitServer(backend, 'localhost')"
<dcoles> (At the very bottom of the file)
<dcoles> I'm just checking if trunk is the same
<dcoles> Yup. In trunk too
 * dcoles opens a bug
<vila> gah, there are days....
<vila> I read the above 'In trunk too' as '"I'm drunk too" and then 'opens a bug' as 'opens a mug'....
 * vila get more coffeee
<dcoles> Hahaha
<dcoles> bug 543998
<ubottu> Launchpad bug 543998 in bzr-git "bzr serve --git is hardcoded to localhost" [Undecided,New] https://launchpad.net/bugs/543998
<dcoles> Looks pretty simple. I might try and write up a patch on the train home.
 * igc dinner
<bialix> Heya GaryvdM
<GaryvdM> Hi bialix
<bialix> I'm thinking about starting packaging 0.18.4
<GaryvdM> I've just committed some tests for treewidget select all.
<GaryvdM> bialix: Cool. Let me know If I can help at all.
<GaryvdM> bialix: I'll do 0.19b1 on Wednesday (24th) evening.
<bialix> GaryvdM: you can help, yes. Can you confirm I can start 0.18.4 or you have some plans?
<GaryvdM> bialix: Yes you can start on 0.18.4.
<bialix> GaryvdM: ok, I've let the 0.19b1 for you then
<GaryvdM> bialix: I'm working on some stuff for trunk. So I want to leave 0.19b1 for the last minute.
<bialix> ok
<bialix> in the end it's b1
<GaryvdM> Yes :-)
<bialix> GaryvdM: I have last revno 1227 in 0.18 branch. (Restore test removed by rev 1225.) That's correct?
 * GaryvdM looks
<bialix> GaryvdM: can you skim through NEWS?
<bialix> GaryvdM: and one more thing: do you have a tree name for this release ;-) ?
<dcoles> jelmer: Have you seen bug 543998
<ubottu> Launchpad bug 543998 in bzr-git "bzr serve --git is hardcoded to localhost" [Undecided,New] https://launchpad.net/bugs/543998
<bialix> GaryvdM: what about bug #533837?
<ubottu> Launchpad bug 533837 in qbzr "Trying to show the log of a file causes a crash" [High,Confirmed] https://launchpad.net/bugs/533837
<GaryvdM> bialix: The revision is correct. NEWS has every thing. (Except test improvements, which I don't think should be in NEWS)
<bialix> GaryvdM: do you have objections for codename "pussy-willow"?
<GaryvdM> Sounds good: http://en.wikipedia.org/wiki/Pussy_willow
<bialix> yes, it is
<GaryvdM> bialix: I'm looking at bug 533837.
<ubottu> Launchpad bug 533837 in qbzr "Trying to show the log of a file causes a crash" [High,Confirmed] https://launchpad.net/bugs/533837
<GaryvdM> I did not target that bug btw.
<bialix> GaryvdM: it seems igc has assigned it to you and to 0.18.4. I've removed milestone assignment
<GaryvdM> bialix: Ok - I'm not going to look at it now. I'm going to stay focused on what I'm doing (treewidget stuff)
<bialix> GaryvdM: that's great
<vila> bialix, GaryvdM : Hi guys !
<bialix> bonjour vila!
<vila> GaryvdM: Test improvements in NEWS give *me* a warm feeling of confidence ;-)
<GaryvdM> Hi vila
<bialix> qbzr 0.18.4 released. w00t!
<jelmer> dcoles: yep
<jelmer> dcoles: I'd consider that a low-priority bug, we need more testing of the server first
<dcoles> Ah. OK.
<dcoles> Wasn't quite sure of it's status, though it's been mighty handy of late :)
<bialix> it seems vila enjoyed piloting :-)
<jelmer> dcoles: so it's working ok for you?
<dcoles> jelmer: For a very trivial repository, yes. I might just try something more complex
<dcoles> jelmer: Though it appears to be serving the wrong branch...
 * bialix finishes the qbzr release
<dcoles> jelmer: It seems to be a tad confused in a shared repository. Regardless of how I try and clone, it grabs the first branch I pulled
<dcoles> (I have 2 branches in this directory)
<jelmer> bialix: \o/
<bialix> hi jelmer, thank you!
<jelmer> dcoles: how are you cloning from it, git clone ?
<dcoles> Yup
<jelmer> IIRC it should just grab all branches in that case
<dcoles> I tried git clone git://localhost/nonexistantfoo and I still get the same branch
<dcoles> This is even if I try and serve from the other branch (rather than the shared repo)
<dcoles> Though I notice that `bzr serve --proto=bzr` refuses to branch when it's not run from the shared repo
<mobby> Hi, I wonder if anyone would be able to help me please? I'm doing a lightweight checkout of an svn repo and it is failing with an "Unable to find old fileid for..." for a file in the svn repo. Any ideas what would cause this?
<vila> fullermd: quick check on FreeBSD8, is /var/crash the right and only place to search for left over dumps after a hard crash ? (One that required running fsck and then some)
 * vila shudders, rats, crashing again :(
<jelmer> dcoles: hmm, that's probably a bug :-(
<dcoles> jelmer: Ok. I'll see if I can reproduce the circumstances and file it
<gioele> hello
<gioele> is there a public installation of the current trac-bzr?
<bialix> gioele: do you mean: to see it in action?
<gioele> bialix: yes
<bialix> I'm not sure about "current"
<bialix> but there was some open-source project using it
<bialix> what exactly you want to see?
<bialix> jelmer: do you know any existing public server with trac-bzr?
<gioele> bialix: I would like to see how it looks like: how branches are managed, whether relationships between branches are shows, how the timeline looks like, etc.
<bialix> branches are not managed
<bialix> relations between branches is not shown
<bialix> I'm using it at my work
<bialix> timeline shows revisions on;y for the mainline
<bialix> *only
<gioele> bialix: "how branches are managed" as in "how multiple branches in the same shared repo are shown"
<bialix> gioele: as directories
<bialix> lemme show you some images
<gioele> bialix: so basically it still looks like http://bugs.bitlbee.org/bitlbee/browser
<bialix> gioele: here http://imagebin.ca/view/ZrY9m2.html
<bialix> gioele: yes
<bialix> gioele: do you know do they're using trac-bzr or ?
<gioele> bialix: they = bitlbee? Yes, I think so: that page is linked from the old wiki page of TracBzr
<bialix> yes, bitlbee
<tenchi> hello
<tenchi> I'm using bzr in ubuntu with Bazaar Explorer. is there any way to export my projects log history (in html format)?
<bialix> gioele: there is also [[Branches]] macro to use in wiki pages
<bialix> tenchi: no, we don't have such feature yet
<bialix> tenchi: but there is special plugin to do so
<bialix> check htmllog
<bialix> also there is xmloutput plugin do support xml output of some commands
<tenchi> thx, will google it
<tenchi> also: using hungarian characters in the commit text provided some errors
<tenchi> are you working on utf8-ing it?
<gioele> tenchi: is should be unicode/utf8 clean
<gioele> tenchi: what did you use to read the commit log?
<bialix> tenchi: I'm working with Russian and it's fine (on Windows)
<tenchi> hmmm
<bialix> tenchi: make sure you have correct LANG settings
<tenchi> just checked it and it works
<tenchi> strange
<tenchi> will tray again at next commit
<tenchi> typed all texts in english because of this
<gioele> tenchi: I have been using Italian accents and German vowels for quite a long time and everything seems fine
<bialix> tenchi: http://michael.ellerman.id.au/bzr/plugins/htmllog
<tenchi> ok, will not whine if it works :-D
<tenchi> When I first tried there was some error but I can't remamber what...
<bialix> tenchi: ghosts
<tenchi> I just tried the gnulog plugin and it works fine for me :-D
<bialix> omg
<LeoNerd> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572109  <== anyone know if this bzr-svn bug is going to be fixed any time soon?
<ubottu> Debian bug 572109 in bzr-svn "AttributeError during 'bzr shelve'" [Normal,Open]
<LeoNerd> I'm sure it can't be that hard, and I'd really appreciate being able to 'bzr shelve' in my svn checkouts again
<jelmer> LeoNerd: it's already fixed upstream
<LeoNerd> Ah excellent
<LeoNerd> Hmm.. if I bzr co a later copy of bzr-svn would that do it?
<jelmer> LeoNerd: yeah
<LeoNerd> OK thanks
<aburch> Is it possible to use "bzr send" (or something else) to send only specific changes?
<jelmer> aburch: you can give it a revision range
<aburch> jelmer: "bzr send -r 1961..1962" still bundles two revisions (the same with -r 1962..1962, -r 1962) when the remote has rev 1960
<LeoNerd> jelmer: Thanks; that fixes it. Have commented on the debian bug to this effect too; hopefully they'll pull it
<jelmer> LeoNerd: they == me :-)
<LeoNerd> Ah. :)
<jelmer> aburch: What are you trying to do exactly ? Sending a bundle without those revisions seems pointless since the remote side won't be able to apply it.
<jelmer> s/side/site/
<aburch> jelmer: I fixed a bug and used "bzr send" to send the patch, now I fixed something else and wanted to send only the second commit upstream.
<aburch> jelmer: Git could do this with "git format-patch -1".  As long as the patches do not depend on each other, upstream should be able to apply them seperately.
<jelmer> aburch: bzr bundles in their current form are intended to keep history (e.g. revision ids stay the same), that's not necessarily the case for "git format-patch"
<jelmer> aburch: I guess to answer your question: it's not possible at the moment, but please file a bug report about it.
<aburch> jelmer: Hmm, ok.  Then I will either look into how Bzr handles branches or just use "bzr diff". (And file the report.)
<dvheumen> hey lifeless, got time for a question about the high(er) level lock hooks?
<jelmer> dvheumen: I think he's asleep, being in .au
<dvheumen> ah right okay
<dvheumen> are you up for a (simple) question by any chance?
<jelmer> For certain values of "simple", sure :-)
<dvheumen> jelmer, maybe you already caught on to that, the idea was that I'd implement a slightly "higher" level of lock hooks. I've been browsing around the code for a good location (or locations) and I think that, for the working trees, I could best implement it in the MutableTree class. But the MutableTree class only "implements" lock_write and lock_tree_write but no lock_read.
<dvheumen> So I was wondering, was lock_read just forgotten, or should I take the implementation up to MemoryTree and WorkingTree classes
<dvheumen> because lock_write and lock_tree_write only raise NotImplementedException and nothing more
<dvheumen> I personally think I could best implement it in MutableTree, but I wanted to wait for some confirmation :)
<dvheumen> ow w8, not it's not, it's stupid, because the actual locking implementation isn't there
<dvheumen> nevermind
<jelmer> dvheumen: MutableTree seems like the best place to me
<jelmer> WorkingTree could be thought of as OnDiskMutableTree
<dvheumen> jelmer, but then I could only do the implementation partially, right
<jelmer> dvheumen: yes, but the interface would be on MutableTree
<jelmer> dvheumen: how the subclasses of MutableTree call the hook is up to them
<dvheumen> okay, that's exactly what I was thinking. okay tnx
<dvheumen> in that case I also know what (approximate) level to choose for the branch and repository hooks :)
<dark_soul> how can i use bzr to delete a branch?
<mgedmin> is it difficult to define a custom location scheme a la lp:projectname?
<mgedmin> it gets tiring to type bzr+ssh://servername/prefix/for/all/my/bzr/repos/ all the time
<maxb> No, it's pretty simple, I suggest looking at how the launchpad plugin defines lp:
<maxb> (which is slightly complicated only because it goes and hits an xml-rpc server to resolve the name)
<jpds> mgedmin: http://pastebin.ubuntu.com/399436/
<mgedmin> jpds, thanks, but it's a bit cryptic
<mgedmin> is it ~/.bazaar/config?
<jpds> mgedmin: ~/.bazaar/locations.conf
<mgedmin> and what does it do?  lets be do cd ~/someproject/devell && bzr branch X  where X gets translated to prefix/X ?
<jpds> mgedmin: You'll then be able to do: bzr push - from a branch and it will automatically go to lp~you/someproject/branchname
 * mgedmin googles for locations.conf
<mgedmin> thanks for the pointer
<mgedmin> from what I see I'm not sure it's what I want, but I'll read
<mgedmin> http://wiki.bazaar-vcs.org/ConfiguringBzr was not useful
<mgedmin> no useful matches in wiki search
<mgedmin> no matches at all in http://doc.bazaar.canonical.com/latest
 * mgedmin searches for appendpath
<mgedmin> that works better
<beuno> gar
<beuno> I have a newbie question  :)
<beuno> I have a revno that removed stuff
<beuno> I want to revert only those changes
<beuno> revert seems to not be what I want
<beuno> and merging in that revision, or 111..112 (assuming 112 is the revno I that I want to revert) doesn't work either
<james_w> merge -r 156..155 will undo the changes that you see with diff -c 156
<beuno> of course, the other way around
<beuno> *sigh*
<beuno> thank you james_w   :)
<NfNitLoop> hehe.
<codygman> If I create a branch, then merge the changes, would I be able to revert back to that at any time?
<codygman> or should I say... could I create a branch, commit, then revert back to what it was before that, while keeping the branch
<GaryvdM> codygman: Yes.
<codygman> alright cool
<GaryvdM> codygman: You can do bzr uncommit
<codygman> well here's what i'm trying to do
<codygman> i'm experimenting with different facebook connect solutions on my django site.. and i'd like to keep note of each one
<codygman> and be able to revert to the one i like
<GaryvdM> codygman: for that, I would make a branch for each solution.
<GaryvdM> codygman: And merge the one you want.
<codygman> the branches stay until i delete them right?
<GaryvdM> codygman: Yes
<GaryvdM> codygman: or pull the one you want if you have no other commits in your main branch.
<codygman> Thanks!
<codygman> I have quite a few other commits lol
<poolie> hi jam?
<codygman> bzr branch "name of my branch" isn't the right syntax huh
<codygman> is their anything similiar to that?
<codygman> similar*
<poolie> codygman: it's "branch FROM TO"
<poolie> what do you want to do?
<codygman> I just want to test out different facebook connect solutions on my django website
<codygman> then be able to revert to the one I like most
<poolie> ok, and they're already in different bzr branches? or you're going to write things in different branches?
<codygman> there is currently only the master branch
<codygman> basically.. I want to be able to revert to my website without the facebook connect plugins.. code the solution.. then do it for the other 2 possible solutions
<codygman> and be able to revert to the one I like best
<GaryvdM> codygman: (in the dir above master) bzr branch master solution1
<GaryvdM> Hi poolie
<codygman> then when I want to test.. I just merge right?
<codygman> bzr merge solution1 master ?
<GaryvdM> codygman: Run mange.py runserver in the branch
<codygman> well.. this is actually on an apache server.. that's why i'm trying to get everything working in that directory
<GaryvdM> Ok, 2 options:
<GaryvdM> 1. use the bzr-colo plugin
<GaryvdM> that allows you to have more than one branch in the same dir.
<GaryvdM> 2. step 1: branch apache-dir ~/proj/master
<poolie> hi gary
<GaryvdM> step 2: edit  apache-dir, commit, push ~/proj/solution1
<GaryvdM> step 3: (in apache-dir) bzr pull ~/proj/master
<GaryvdM> go back to step 2 repeat
<GaryvdM> when you chose, pull master, then merge concision solution.
<GaryvdM> codygman: ^
<codygman> I'm reading! Thanks for that. I think i'm going to try the bzr-colo plugin
<codygman> if i can't do it with that, i'll use option 2
<GaryvdM> codygman: I would recomend trying: branch into your home dir, and run with ./manage.py runserver
<fullermd> vila: Yes, that's where crashdumps get copied to on boot, unless you change it.
<GaryvdM> codygman: I had good mileage with that when I was working with django.
<codygman> you mean runserver?
<GaryvdM> codygman: Yes, runserver, and working with branches in my home dir.
<GaryvdM> night all
<humphreybc> hi
<humphreybc> we have a pretty big problem
<humphreybc> our branch has randomly jumped back about 30 revisions and we're not sure why
<humphreybc> we may have lost a crapload of work but not sure
<humphreybc> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes
<humphreybc> it was on 565, but then we think it got screwed when Sayantan pushed something and merged
<humphreybc> no we have people sitting on 554 testing it all over the palce
<bob2> pushing can do that
<humphreybc> so we've got a tonne of people (hundreds) who are testing an older version, but on a newer revision number
<humphreybc> what happens now?
<bob2> bzr log -n0
<humphreybc> that command gives me 0 - 65
<humphreybc> we've got 500+ revisions
<bob2> it should give you a long and complicated nested log
<humphreybc> i might need to turn up my line count in terminal
<bob2> run it through less
<humphreybc> it looks like we've lost about 30 revisions, 2 days worth of work
<bob2> really?
<humphreybc> yes
<humphreybc> which isn't particularly cool
<humphreybc> do you mind jumping in to #ubuntu-manual ?
<bob2> ok, two thinsg: push can change rev order, so look carefully at the output of bzr log -n0
<bob2> also, those revs still exist on the computers of whoever committed them, so even if someone broke launchpad, you can recover them
<bob2> (msot likely)
<bob2> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes/525.1.17 < -s that the work you think is gone?
<humphreybc> http://paste.ubuntu.com/399564/
<humphreybc> and there is more, under rev 529.xx
<humphreybc> but i'm presuming that stuff has been preserved?
<humphreybc> http://bazaar.launchpad.net/~ubuntu-manual/ubuntu-manual/main/changes/525.4.25
<humphreybc> that's more stuff that we had
<humphreybc> is that stuff preserved, or is it gone?
<mrooney> hey all! I've been searching around, is there something like a rebase, but that collapses your commits into just one?
<mrooney> such as, I've made a bunch of commits , now I want to push it somewhere else as one
<lifeless> bzr merge; bzr revert --forget-merges; bzr commit - that will discard the history of where the changes came from
<lifeless> or if you just merge and commit, bzr log will, by default, show it as one change, and keeps the little details available if desired via log -n0
<mrooney> lifeless: doesn't a simple merge squash the remote history, not the local history?
<mrooney> or do I rebase and then merge, or something interesting
<maxb> mrooney: You realize you could just uncommit multiple commits, then commit once?
<mrooney> yeah certainly
<mrooney> but as a workflow item, that's tedious and annoying
<maxb> That's probably because squashing commits isn't a common workflow :-)
<maxb> Why do you want to do it anyway?
<lifeless> multiple uncommits + commit == merge ; revert --forget-merges, commit
<maxb> yes, just depends whether you're already in a branch with the commits to be squashed
<mwhudson> jelmer: ayt?
<jelmer> mwhudson: otp
<mrooney> maxb: I don't really, some people want to wrap our svn workflow and don't want all their local commits to end up as individual commits on the svn end
<mwhudson> mkanat: https://bugs.edge.launchpad.net/loggerhead/+bug/513044/comments/6
<ubottu> Ubuntu bug 513044 in loggerhead "loggerhead (codebrowse) hangs occasionally on launchpad" [Critical,Triaged]
<jelmer> mwhudson: hello
<mwhudson> jelmer: well, i have to admit i'm otp now too :)
<mrooney> I'm hoping to convince them to just rebase and enjoy all the history being in svn
<mwhudson> jelmer: but did you have time/brain energy to talk about incremental bzr-hg imports?
<jelmer> mwhudson: I'm always excited to talk about bzr-hg imports!
<mwhudson> jelmer: heh heh
<mrooney> okay so if I can do a bzr branch of an svn repos
<mrooney> and then someone else branches my branch, can they bzr push $SVN_REPOS without issue
<mwhudson> jelmer: last time we talked, i think we decided that limiting in findmissing() would be too hard?
<jelmer> mrooney: yes.
<jelmer> mwhudson: yep
<lifeless> yay, my new machine has shipped
<mrooney> okay great
<mrooney> and a silly question I think but one I've had a hard time googling an answer for
<mrooney> if I've got a branch on my machine, what do I need to set up to have someone else be able to branch from it
<mwhudson> jelmer: so where can you limit?
<mwhudson> i guess i need to figure out what
<mwhudson>         cg = self.source._hgrepo.changegroup(missing, 'pull')
<mwhudson> is doing
<mrooney> we're all on a LAN here, I've never figured out how to push and pull from another LAN machine
<jelmer> mwhudson: you can't really limit what the server will send you, but you can limit how much you process
<jelmer> mwhudson: cg is a unpacked hg bundle
<mwhudson> oh ok, so addchangegroup needs to change?
<jelmer> mwhudson: it contains three chunks of data in order - from memory: revisions, inventories and texts. We basically loop over all three and you'd need to limit how much processing you do in the first then skip irrelevant stuff in the second two loops.
<mwhudson> jelmer: that sounds about right
<mwhudson> i don't know what "skip irrelevant stuff" means in concrete terms
<jelmer> mwhudson: inventories (manifests in mercurial jargon) that aren't referenced by any revisions that you're importing should be skipped as well as texts that aren't referenced by any of those manifests.
<mwhudson> jelmer: sorry :-p
<mwhudson> jelmer: i understood that much
<jelmer> mwhudson: the revisions have references to the manifest ids
<jelmer> and the manifests have references to the text ids
<mwhudson> jelmer: ahh
<mwhudson> so i'll need to keep track of some set()s i guess
<jelmer> you might be able to leverage the existing datastructures
<mwhudson> "referenced manifest ids" and so on
<jelmer> since they try to keep track of what manifest is for what revision
<RAOF> mrooney: SSH access should be sufficient for people to push/pull to/from you.
<jelmer> and what mercurial file rev is for what bzr fileid/revid
<mwhudson> jelmer: ok, that should be enough to keep me going until i have some more questions i guess
<igc> morning
<mrooney> RAOF: but would every user that wants to pull from me need a user on my machine?
<jelmer> mwhudson: awesome
<mrooney> is there any documentation I can read for this? I'm reading through http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_branches.html and such, but I can't find anything that tells you how to actually set up the sharing
<jelmer> hi Ian
<mrooney> jelmer: okay one more question for you, I can't create a --stacked branch of an svn branch, correct?
<mrooney> but what happens if someone branches --stacked my branch, and then tries to push to svn?
<jelmer> mrooney: no
<jelmer> mrooney: If they --stacked your branch, that would work and they would be able to push
<jelmer> you just can't stack on a svn branch
<mrooney> okay so I can branch an svn branch, serve it with bzr serve, and people can branch --stacked and push back to svn all they like? that seems good!
<mwhudson> jelmer: grar
<mwhudson> jelmer: the unpack_chunk_iter makes live a little awkward to do this, maybe
<mwhudson> ^ interface
#bzr 2010-03-23
<jelmer> mwhudson: there isn't really an alternative, you can't seek in the mercurial bundle files
<mwhudson> jelmer: fair enough
<jelmer> in other news, now that lp:django is upgraded I've asked the whygitisbetterthanx folks to update their info: http://github.com/schacon/whygitisbetter/issues#issue/4
<mwhudson> hm
<mwhudson> jelmer: it seems a bit like when revision_id is passed to FromHgRepository.fetch, some extra revisions are imported
<mwhudson> beyond the one requested
<mwhudson> jelmer: does this sound possible to you?
<mwhudson> i guess this means source._hgrepo.changegroup is returning more than we're asking for
<jelmer> mwhudson: hmm
<mwhudson> heads() returns a 1 element set, missing is a 1-element set but we go around the loop in _unpack_changesets twice
<jelmer> mwhudson: I guess when we ask for a branch containing a revision we shouldn't assume that the tip of that branch is our revision
<jelmer> mwhudson: can you file a bug?
<mwhudson>  jelmer ok
<mwhudson> jelmer: https://bugs.edge.launchpad.net/bzr-hg/+bug/544701
<ubottu> Ubuntu bug 544701 in bzr-hg "pull -r $rev doesn't limit revisions converted" [Undecided,New]
<micahg> what's the proper way to retag a branch
<RAOF> bzr tag -d $MYTAG; bzr tag -r$I_WANT_TO_TAG_THIS_REVISION $MYTAG, from memory.
<micahg> RAOF: right, but when I push I get a conflicting tag errro
<micahg> do I have to push --overwrite?
<RAOF> I remember just pushing, but maybe I'd also added some revisions.
<RAOF> I'm unsure here; I only remember it Just Working.
<micahg> RAOF: ok, thanks we worked around it anyways
<GungaDin> How can I branch off a revision that was already branch off my branch?
<GungaDin> or rather, how do I check out a branch by one of its revision ids?
<lifeless> GungaDin: branch -r XXXXX source
<mkanat> mwhudson: Thanks! We're waiting on Francis for some administrative details before I continue, FYI.
<mwhudson> mkanat: i'm not sure the latest info is very useful :/
<mkanat> mwhudson: Okay. I'll take a look at it once we handle the administrative stuff.
<poolie> GungaDin: still here? did you get an answer?
<poolie> you can do 'bzr branch -rN FROM TO'
<GungaDin> yeah, managed already
<GungaDin> thx
<dcoles> Hmm... You think that there's any chance LP would support access to Bazaar repos with a git client?
<RAOF> It's technically possible, but ...uuurgh :)
<dcoles> bzr-git almost makes this look feasible, and the bazaar repositoires are rich enough to be a backend for git
<RAOF> Right; they store more info than git does.
<dcoles> RAOF: I agree. I'm a bazaar fan myself
<RAOF> It's possible to do this locally; bzr serve --git, for example.
<dcoles> I just think it would a technically "cool" thing to be able to do on a LP level
<dcoles> Heh. Well, mostly (it crashes at the moment for me)
<RAOF> There are at least two problems that I know of, one technical, one social.  The technical one being that it would hammer the server, the social one being that I think launchpad would like to promote the use of bzr and make it possible to use bzr to access everything.
<mwhudson> i think the performance would be pretty terrible currently
<dcoles> Going to try and work out why when I get a spare couple of hours
<dcoles> mwhudson: That being the performance of bzr-upload-pack and bzr-receive-pack when emulating a git repo?
 * mkanat knows that pack-to-2a conversion is slooooow.
<mwhudson> dcoles: basically yes
<mwhudson> maybe going bzr->git will be faster than t'other way around
 * dcoles relises he's late for class - runs
<poolie> igc, hi
<poolie> igc, i'm going to make 2.0.5 and 2.1.1 tarballs
<echo-area> hi, a question about tags.  If the revision of a tag is changed, it can't be pushed/pulled because of tag conflicts.  Is the following the right thing to do: 1) Ensure all changes have been merged, i.e. make two branches converged; 2) bzr push --overwrite or bzr pull --overwrite
<echo-area> in fact, I'm using tags to point some revisions in history.  Is this even the right usage of tags?  Should I use branches for this purpose, instead of tags?
<echo-area> an advantage of using branches over using tags, imho, is that later changes can be merged into branches, but for tags this is impossible.  So tags appear to be better, right?
<echo-area> :( That's a typo.  I mean, So branches appear to be better
<igc> poolie: sounds good
<poolie> echo-area: if you expect it to continue changing, a branch is better
<poolie> if it's "this is 2.0.5" and it won't normally change, that's better
<poolie> if you need to change it in another branch, use 'bzr tag -d PLACE "
<poolie> igc, so your packaging changes only apply to 2.2 right?
<poolie> we couldn't run them kind of externally against 2.0?
<igc> polie: right
<poolie> i suppose it would be risky even if it worked
<igc> too risky IMO
<echo-area> poolie: thanks.
<echo-area> deletion of tags doesn't get propagated, is this intentional?
<fullermd> Sorta.  Any change to tags doesn't propogate unless you force it, since there's no way to know what changed.
<echo-area> fullermd: By "force it", do you mean --overwrite?  That seems to only work for revision changes of tags.
<echo-area> fullermd: But I got your idea.  Changes to tags are not recorded as much as changes to files/directories, so I think I'll avoid using tags
<fullermd> Oh, tags are very useful.  And the shortcomings here in their behavior are bugs in a broad sense.
<fullermd> But the usual use-cases for tags don't involve very much touching after their laid, so the pain level impelling fixes is very low.
<echo-area> fullermd: the usual use-case for tags is as a more friendly way of refering tags, right?
<echo-area> refering revisions, I mean
 * igc dinner
<fullermd> echo-area: Well...   that's what they _are_.
<echo-area> fullermd: So what are the use case you refered to :)
<echo-area> use cases
<fullermd> Oh, things like tagging releases, or before/after tags on big reorganizations.
<fullermd> They tend to be set, and that's it; they don't move or get removed or anything after the fact.
<fullermd> Contrasted to tags of the LATEST_STABLE_VERSION sort, which do, on a regular basis.
<fullermd> The latter don't tend to get used much, so the pain they trigger isn't a high enough level to have thrust anybody toward implementing versioned tags.
<echo-area> oh, so bzr tag --force tag-name is really only used when a typo happens, right?
<fullermd> Generally, yah.
<fullermd> Having versioned tags would make the more dynamic cases work better.  I don't think there's any movement _against_ adding them, but it's a fair bit of work.
<fullermd> So since the boundaries of the current system don't get hit very often...
 * bialix waves at fullermd
<fullermd> Hey bialix   :)
<bialix> Ð-)
<bialix> :-)
<bialix> it was a smilie
<fullermd> Smilies are delicate.  It's easy for them to be damaged in transit when they have to cover 10k miles or so.
<tumbleweed> is there any neat way to rebase a branch onto an older revision? i.e. to convert a bug fix against trunk into a suitable branch for merging into a previous release by rebasing against the common ancestor?
<fullermd> If it's just one or a few revs, I'd probably just cherrypick it; it would probably work as well as trying to rebase, and it'd be simpler.
<tumbleweed> yes, that's the only solution I have
<wgrant> I've done that before, IIRC.
<wgrant> But you have to specify all the rebase args manually.
<tumbleweed> rebase --onto seems to indicate that it will do the right thing, but it says "No revisions to rebase."
<wgrant> tumbleweed: bzr rebase --onto ONTO_REV -rFROM_REV..?
<tumbleweed> wgrant: nope
<wgrant> tumbleweed: What does it not do?
<tumbleweed> wgrant: it doesn't do anything. "Rebasing on ...\nNo revisions to rebase"
<wgrant> tumbleweed: Works fine for me.
<echo-area> fullermd: got it. I was trying to understand the current policy on tag propagation, it was a bit strange to me.
<fullermd> echo-area: Yeah.  Since there's no history, any time the two ends differ we can't know why.  The only thing we can non-destructively do is add a tag that the 'far' side is missing.
<tumbleweed> wgrant: http://paste.pocoo.org/show/192816/
<wgrant> tumbleweed: Try '-r4..'
<tumbleweed> oh, I tried 3..4 but not 4..
<echo-area> fullermd: thanks :)
<tumbleweed> wgrant: thanks, that should do the trick
<wgrant> tumbleweed: Excellent.
<flawrence> hi, it appears that the last few OS X 10.6 releases of bzr have been compiled for 64-bit only. is that correct? If so, which version should I download for my 32-bit intel mac running 10.6?
<GaryvdM> Hi. I want to hack on a project that is in hg. Is bzr-hg usable yet. Should I use it?
<jelmer> GaryvdM: doesn't roundtrip yet
<jelmer> GaryvdM: and dpush is.. unstable
<GaryvdM> jelmer: Ok. I would want roundtrip, so I'll use hg for now :-(
<bialix> heya GaryvdM, jelmer
<jelmer> 'lo bialix
<bialix> 'lo ?
<bialix> hello?
<bialix> jelmer: ^
<jelmer> yep :-)
<bialix> will know now
<GaryvdM> Hi bialix
<bialix> GaryvdM: there is regressions in the qbzr trunk
<bialix> you already saw perhaps
<GaryvdM> https://bugs.launchpad.net/bugs/545016 ?
<ubottu> Ubuntu bug 545016 in qbzr "qrevert selection doesn't get picked up" [Critical,Confirmed]
<bialix> yep
<GaryvdM> bialix: I will look into it a little later
<bialix> that's ok,
<Morbus> g'day. i'm using emailer.py and i'd like to add the branch to the subject line. would that just be self.branch(), you think?
<guilhembi> vila: ping
<vila> guilhembi: pong
<Morbus> self.branch.nick, to answer my own question.
 * Morbus waves.
<GaryvdM> Hi jam.
<GaryvdM> jam: If I recall correctly, the stumbling block with storing gdfo for revisions was knowing if ghosts have been fetched.
<GaryvdM> jam
<GaryvdM> jam: Why not store the known ghosts?
<jam> GaryvdM: the current issues that I know of are:
<jam> 1) You have to figure out how we want to store it
<jam> (in an existing index, in a new index, etc, etc.)
<jam> 2) When fetching you have to check to see if any ghosts are fetched
<jam> which means (as you mention) recording them
<jam> and in such a fashion that there is low overhead to query
<jam> all stuff that can be done
<jam> but *doing* it :)
<GaryvdM> jam: Ah - I see
<jam> you could probably live without (2) for the short term, and expect users to explicitly address it when they think it is wrong
<jam> (bzr rebuild-gdfo)
<jelmer> gdfo ?
<jam> jelmer: greatest-distance-from-origin
<jam> simplifies a lot of stuff like 'heads' checking
<jelmer> ahh
<jam> might make it possible to improve revno generation
<jam> but that is a bit unclear atm
<fullermd> Godzilla Destruction For Oneiromancy?
<jelmer> fwiw heads checking is important for bzr-git / bzr-hg
<jam> jelmer: put another way, the primary benefit of KnownGraph.heads() is that it has gdfo, while Graph.heads() does not
<jam> secondary is that it is done in C, but the first is an O() change, the latter is a constant factor change
<jam> Graphs.heads() is O(N^2) in some edge cases I believe, KG.heads() is O(delta) (I think always)
<jam> gdfo gives you a hint if rev X could possibly be a parent or child of Y, since a child gdfo is *always* > a parents
<jam> GaryvdM: last I talked to vila about it, he wanted to experiment in a plugin, and see where it got to. However, I think there have been enough things to work on, that he hasn't done much
<vila> KnownGraph loads the whole graph and *then* calculate gdfos, when we start *storing* gdfo, then we'll be able to incrementally load the graph for several operations (a different revno scheme can also be used and not require loading the whole graph as we do today)
<vila> welcome back jam :)
<GaryvdM> jam: When you say that it is unclear atm whether gdfo will improve  revno generation, is that uncertainty coming form the reading of index?
<vila> Yeah, no time to work on this
<fullermd> vila: You got my response overnight?
<vila> fullermd: no
<GaryvdM> Hi vila
<fullermd> Oh.  Hm.  I don't even remember what it was about...
 * fullermd digs.
<vila> fullermd: where FreeBSD put its crash files
<vila> ?
<fullermd> 16:16 <fullermd> vila: Yes, that's where crashdumps get copied to on boot, unless you change it.
<vila> fullermd: ok, I figured that \,
<jelmer> jam: Thanks
<vila> fullermd: there weren't enough space left for the last one so I didn't understood at first what was going on, and once I cleaned up, I got, of course, no more crash
<jam> GaryvdM: no, more how to compute the revnos given a limited scope of ancestry
<jam> I've done some work on it in the past, and it didn't show a huge gain
<jam> but that was without gdfo
 * fullermd takes credit for fixing it   :)
<vila> jam:
<vila> bah
<jam> however, the current revno *system* is also at fault
<jam> numbering from merge point versus branch point could improve it
<jam> etc
<jam> hi vila
<jam> long time no see :)
<vila> numbering from branch point can be trivially solved if people accept to number backwards :-)
<vila> jam: glad to see you back, I wasn't sure how long were your vacations
<vila> err, I meant numbering from merge point of course
<jam> vila: well 'trivially' is one way to put it
<vila> well, almost trivially, there is still the problem of the branch merged several times :)
<GaryvdM> jam, vila: hmm - backward numbering would cause some issues with qlog because it uses the revision numbers to group merge lines together.
<GaryvdM> That would break in the case where a branch is merged several times.
<jam> GaryvdM: right, though there is always the question of which view is more useful :)
<vila> GaryvdM: Well, if you had cheap ancestry checks you could them instead of relying on revnos which reflect them
<jam> vila: though if it becomes a combinatorial problem, it will never be cheap
<jam> even if checking ancestry is O(1), doing NxN comparisons is still N^2
<jam> it is just is better than N^2 * N^2 :)
<jam> the really good thing about the current merge_sorted code is that it really is close to O(N)
<jam> it just happens to be N when you really want O(local)
<vila> jam: sure but N being size(history) doesn't help :)
<vila> yup
<jam> certainly
<jam> though I wonder if caching the merge-sorted graph would be a better use than *just* gdfo
<jam> IIRC, igc experimented with this with pretty good results
<jam> because of stability guarantees, you could see some benefit by caching based on current tip
<jam> etc
<jam> (so cache every 100th rev, based on that rev tip, etc)
<jam> Again, I'm not sure about how mysql benefits, because of their push policy
<jam> but you could certainly find cases that would benefit
<jam> going back 1000 revs is better than 65k
<vila> the big problem with revno-cache is that it isn't invalidated when it should (AIUI)
<jam> though again, you need a partial algorithm that can build on an existing one
<jam> vila: I thought it was invalidated whenever the head changed
<jam> or are you meaning ghosts?
<vila> jam: I'm not sure all head changes are taken into account (pull --overwrite for example)
<jam> I thought when it read the cache it just said "if cur_tip != cacched_tip: rebuild"
<GaryvdM> Some people had issues with it because it would write the cache when a read operation.
<vila> may be, I also seem to remember that loading the cache for big histories became the bottleneck at one point, but I didn't closely follow
<vila> jam:  I'm working on bug #375898 and could use some help, I'm a bit unclear about what TreeTransform._new_root is used for
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898
<jam> vila: ugh, me no likey that code
<vila> hehe
<jam> but I did work on it recently, let me see if I can restore from memory dump
<vila> :-/
<GaryvdM> One of the things I wanted to do is integrate qlog with igc's history cache. Vila: At Barcelona, you convinced me to wait on that as there was something better coming in the core (which I later assumed to be gdfo caching.) If gdfo caching is not happening atm, maybe I should maybe relook at qlog history cache integration?
<vila> jam: I know, want bzr revno to assist ? :)
<vila> jam: 4954
<vila> jam: fixed bug #494269
<ubottu> Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269
<jam> _new_root is the transaction id representing the '/' in the directory
<jam> (in the working tree, etc)
<vila> GaryvdM: shudder
<jam> GaryvdM: well, if you are using the "get_known_graph" stuff, then you *are* using our current gdfo code
<jam> (which is also under the covers wrt Branch.get_revision_id_to_dotted_revno())
<jam> however, that doesn't do partial loading
<vila> GaryvdM: summary: If you think that's critical for qlog, then go for it, but starting using KnownGraph may be a bett... what jam says :)
<jam> it *does* to semi-optimized full loading
<jam> s/to/do
<jam> vila: so one thing about bug #375898 and bug #494269... transform actions often have to call a new function when they are almost ready to be finished
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898
<ubottu> Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269
<jam> transform.fixup_new_roots()
<jam> added to _alter_files()
<GaryvdM> vila: qlog is not using KnownGraph, and it should be, but I'm really looking for a solution that does not have to load the whole graph, so gdfa *caching*.
<vila> the traceback I've got here is from do_merge() :-/
<GaryvdM> *gdfo
<jam> sure
<jam> my point is that the merge code should probably be calling that
<jam> if it is poking at the transform object directly
<vila> GaryvdM: sure, then my remarks from Barcelona still stand, now, it's up to you to decide what you want and when :-/
<jam> vila: somewhere near the end of _compute_transform
<jam> I'm not sure before/after resolve_conflicts
<jam> it *does* have a 'self.fix_root()' call
<GaryvdM> vila: Ok, got you.
<jam> It *might* be better to replace that with a different call to tt.fixup_new_roots() ?
<jam> I'm just trying to give hints, though.
<jam> GaryvdM: you need dotted revno caching
<jam> not just gdfo caching
<jam> aka, build a dotted revno from less than all ancesry
<jam> ancestry
<jam> and my initial point
<jam> is that given the current numbering scheme
<jam> that isn't always possible
<jam> long-lived integration branches require you to go back far enough to the initial branch point
<jam> the "branch merged several times" issue
<jam> I *do* have code for lazily computing dotted revnos
<mgedmin> bound branches + bzr gui notification daemon (which is installed by default apparently) == my every commit issues *two* notifications with the same text
<jam> it does not take into account gdfo
<jam> and so suffers from race conditions while tracking ancestry stuff, and is O(N^2)
<jam> gdfo *would* help there
<vila> GaryvdM: and note that jam's remarks are for branches with append_revisions_only or similar workflows, in the mysql workflow were this isn't true, there is just nothing worth to cache (or too hard to define)
<jam> however, the revno numbering scheme still has the 'go back to branch point' issues
<jam> vila: there is always eventually a level that could be cached
<GaryvdM> jam: I see.
<jam> it may be 1000 revisions ago
<jam> but that is << 65k
<jam> GaryvdM: also, you can have 'multiple paths to NULL' issues
<jam> bzr certainly has that
<vila> jam: certainly, but which ? the tip revno itself is going up and down with a significant amplitude....
<jam> with merging several plugins
<jam> if you find one of those revs
<jam> you have to walk the whole graph back to 0
<jam> to be sure none of those revs were ever merged earlier
<jam> (gdfo is 1 for all the plugin rev0 that were merged)
<jam> *rev1
<jam> vila: 'significant' relative to the 2000 already there?
<jam> +- 100 is still <10% of 2000
<jam> if you are saying it is going 1000 to 3000
<jam> then that is different
<jam> my point is that if the cache were at stages
<GaryvdM> vila, jam: I think I'm going to have a look at igc's plugin then.
<jam> 0 => 100 here, 100 => 200 here, etc
<jam> GaryvdM: though the other argument is that these are all edge cases, versus the common 'small feature branch'
<jam> it does depend on what you are benchmarking
<jam> the main reason I didn't push harder for the lazy revno stuff
<jam> is that merge_sorted is O(N), while lazy_revno was O(N^2)
<jam> and had the chance to make N still go to all_revs
<jam> so it made common cases faster
<GaryvdM> jam: I'm looking at big branches like mysql, OOo
<jam> but made edge cases *much* worse
<jam> OOo is a very special case, though, since it is (IIRC) almost completely linear
<jam> same with emacs
<jam> I guess not that special, since it does happen repeatedly :)
<vila> GaryvdM: qlog is usable on mysql branches, *I* use it at least for diagnosis (and it helps me a lot)
<GaryvdM> vila: I would like it to show you the main line in < 1 sec.
<vila> GaryvdM: don't display revnos in the initial display then :-P
<vila> GaryvdM: Or just cheat starting from last_revision_info() and decrementing, but that will work only if you display a single branch
<jam> GaryvdM: well, "time b.get_revision_id_to_revno_map()" for me for a mysql tree is 2.6s
<GaryvdM> vila: yes, I have thought about the second option.
<jam> you could pretty easily change the code to just show the mainline quickly
<jam> and load that in the background
<jam> sorry, TIMEIT says it is 1.29s to load the whole graph and produce the merge_sorted result on my machine
<jam> that is for 68k total revs and 2778 mainline
<jam> GaryvdM: I think cheating is actually pretty sensible
<jam> so I'll call it "cheating"
<jam> it also gives you a great opportunity to only load the last N revisions, which is whatever fits on the first page
<jam> but still load them 'in bulk'
 * GaryvdM runs bzr qlog mysql --lsprof
<jam> GaryvdM: just to mention that IME, --lsprof gives you ~accurate timing of C functions, but python functions are slower by ~2x
<GaryvdM> jam: That sort of cheet would also help with OOo.
<jam> so the issue with OOo and emacs is that they are soon not going to be perfectly linear in the new revs
<jam> but you still end up paying to load 100k old revs
<jam> oh, and loading the whole graph for emacs is slower than the equivalent of mysql
<jam> for whatever reason 68k 'bushy' revs load a lot faster than 68k 'linear' ones
<jam> my guess is because you only have 1 rev that you can look for at any given time
<jam> and you may/may not have very good clustering
<jam> the fast-load code path exploits facts like 'john@arbash-meinel' tends to commit many times in a row
<jam> which probably doesn't happen as often in the emacs case
<jam> since people wait to commit to cvs because it disrupts other people
<jam> so you have more 'big' patches, and more author cycling
<jam> at least, that is my guess
<fullermd> So...   the solution is for john@a-m to do more emacs dev?   O8-}
<jam> fullermd: the solution is to rebase the whole ancestry of emacs, sorting it by author :)
<fullermd> Ah!  Makes perfect sense.  Easy to handle copyright issues then!
<bialix> jam: hi, do you know how the rss feeds get updated on bazaar.canonical.com site?
<jam> bialix: cron script, IIRC
<bialix> our latest qbzr release still not shown on the main page
<jam> bialix: what is the latest? 0.18.4?
<bialix> jam: it seems cron does not work
<bialix> yep, 0.18.4
<jam> the newest entry on that page that I see is: 04-Mar-2010
<jam> it is certainly possible the updater has failed
<jam> I don't maintain it personally, I think poolie would have a better idea
<jam> vila: what Time is it in France now? (Other than being past EOD for you :)
<bialix> ok, I will try to ping poolie
<jam> We hit daylight savings time, so I have to adjust my "vincent should be working now" clock
<vila> 17:27, so not past EOD yet :)
<jam> vila: when do you hit daylight savings?
<vila> You first have to adjust it for *you* DST and then later on you'll have to do it for my DST :)
<vila> jam: No idea :)
<jam> I think the standard is in a couple weeks, closer to april 1st
<bialix> usually last sunday of march? no?
<vila> I actually enjoy sunny days and that's good enough :)
<vila> 28 march as per bialix and confirmed at http://www.timeanddate.com/worldclock/timezone.html?n=195
<vila> :-D
 * GaryvdM going home. Will be back on line in 30 min.
 * GaryvdM going home a little later
<vila> GaryvdM: :)
<bialix> going home is for wimps?
<bialix> real geeks send yourself to home via e-mail
<fullermd> You don't need to send yourself home, you just create a symbol table alias of yourself in Home.
<GaryvdM> vila: Are mysql still using 0.14?
<vila> GaryvdM: bzr ? format ? They use --1.9 AFAIK, migration to 2a pending but in the pipe
<bialix> qbzr 0.14
<GaryvdM> Sorry - I ment format 1.14
<GaryvdM> I shall upgrade my local branch from 1.14 to 1.19
 * bialix wants to talk about scmproj, snapshots and nested trees
<bialix> vila: can I ask your advice?
<vila> bialix: Don't ask to ask :) I'll do my best
<bialix> that EOD thing scaries me
<bialix> ok, so I have a problem I don't decide how to handle yet
<bialix> I've implemented snapshots for scmproj
<bialix> it means now I can record the state of all nested branches (components) in the project and then later get the exact copy of the project
<vila> great
<bialix> I can even go from older state to newer state
<bialix> but not in the reverse direction
<bialix> because I'm using pull under the hood
<jam> GaryvdM: one smal issue, I'm not sure how --lsprof-file works wrt threads...
<bialix> vila: so I can use pull --overwrite perhaps, but I have doubts
<GaryvdM> jam: We don't have any threads in qbzr yet.
<jam> GaryvdM: 1.9, not 1.14
<jam> there is no 1.19
<jam> just a 1.14 is a wt thing
<GaryvdM> Bla, so confused
<GaryvdM> 1.9 introduced btree?
<bialix> vila: if some component has tip revision which is not the same as recorded in the snapshot
<bialix> vila: I don't feel safe to simply overwrite it
<vila> bialix: you need some sort of check against that like we do in commit
<bialix> vila: is it correct assumption to check every component is it "clean" , i.e. component's tip revision is the same as in the snapshot, and only then do pull --overwrite
<bialix> vila: what you do in commit?
<vila> bialix: add a check that there is no uncommitted changes
<bialix> vila: right, I forgot about uncommitted changes
<dark_soul> why do some files take so long to show up via launchpad after a commit?...i pushed a bunch of file and its obviously there cause i can download it but when i click to view it, there's nothing
<vila> bialix: wt.has_changes()
<bialix> vila: so this one more check
<vila> dark_soul: what do you call 'so long', I generally see updates done in less than 5 minutes (even 2 minutes)
<dark_soul> vila: well its update and its there...but some when you click on it to view the source code via the web interface, it shows nothing. some have it some dont
<dark_soul> not sure if its because other files take longer to populate?
<vila> dark_soul: also, it depends whether or not you have write access because lp use a mirror internally for read-only operations and that's the mirroring that can be delayed
<bialix> vila: more precisely about snapshots and components: if I have component alpha and his current snapshotted revision is 9, but in the reality on the disk it has revision 10, and I want to update project to the state where alpha was at 7.
<vila> dark_soul: if you mean that for the *same* commit some files show the update and some don't then file a bug
<bialix> vila: I don't know is the rev 10 already pushed somewhere
<bialix> vila: I don't feel safe to pull --over -r7 in that case
<GaryvdM> jam: please can we look at qlog together at uds and help me see if there are any performance improvement that can be made (other than the above mentioned cheat.) I'm think that some pyrex code may help.
<dark_soul> vila: it is the same commit..to clarify, it is updated..you can download the file and everything is there. it's only when you click to view the file via the web, some show and some dont
<vila> bialix: yup
<bialix> vila: I wonder if this case somehow addressed in the real nested trees
<GaryvdM> dark_soul: url?
<vila> bialix: no idea, I didn't look at the actual implementation, but it should
<bialix> abentley: ping, I have question about bzrtools: clean-tree --ignored: I need to make it aware of ignored nested branches. What the best way for me to address this problem? Introduce new command-line option?
<dark_soul> okay..odd now all of them are showing.  weird
<abentley> bialix, it's now in core, not bzrtools.
<bialix> abentley: clean-tree?
<abentley> bialix, yes.
<jam> GaryvdM: I'd be happy to
<bialix> abentley: somehow I've missed this
<GaryvdM> jam: Thanks.
<bialix> abentley: anyway, the question remains the same
<abentley> bialix, right.  Could you explain a little more?  These are nested trees that you've included in .bzrignore, but don't want to delete?
<dark_soul> oh..i think i know what i did wrong...or it could be a bug
<bialix> vila: so, what is your advice here: do only safety check for revno, and allow user to force pull via command-line flag?
<bialix> abentley: I have scmproj plugin which emulates nested trees
<jam> GaryvdM: a trivial run seems to indicate it takes 2+s to load PyQt
<bialix> abentley: it doing some just by keeping collection of nested branches
<dark_soul> you know the website where you browse your file.  you got two url which is divided by the ":" (slice) ..
<jam> though I guess it is faster the second time
<dark_soul> if i click anything to the left..it shows the code..if i click anything to the right, it will not show the code
<abentley> bialix, I don't think you would need to ignore those branches.  bzr should just skip them anyway.
<bialix> abentley: those nested branches are ignored usually from root branch, otherwise they become visible in the status
<GaryvdM> jam: I would so like to try fix that!
<vila> bialix: yup --force
<bialix> abentley: if I don't ignore them I see them every time, and it's irritate
<jam> GaryvdM: what is the "exec_" loop?
<GaryvdM> Qt main event loop
<jam> and why "exec_" and not "exec()" ?
<abentley> bialix, I agree.  I don't think status should show them, since add won't add them.
<bialix> vila: ok, thanks for the help :-)
<GaryvdM> jam: I think exec is a python keyword?
<jam> it is, but I thought it had to be standalone
<vila> dark_soul: do you have some url for us ? Tt could help understanding you
<bialix> abentley: yes, you're right. but as short term solution I think I can just teach clean-tree to not delete them without special permission from user. Is is sounds reasonable?
<dark_soul> vila: yes..give me a sec..i got a meeting. brb
<jam> hmm.. I guess I'm wrong, or at least they changed the name. I would have sworn I used to call .exec()...
<jam> no biggie
<jam> I guess I just thought it was something new
<Boingo-OSI> Hello all.  I am trying to figure out the correct setup for bzr in the following senario...  There is a central development server that multiple users would access and commit to.  The central server needs to have a working copy running (PHP based website).  At certain intervals, the code will be uploaded (using bzr upload) to the production server.  I can figure it all out except the working copy on the server so that when a person commits, those change
<abentley> bialix, I think it's reasonable to skip ignored trees by default, but I think it would be better to just fix status.
<jam> GaryvdM: http://paste.ubuntu.com/400075/
<jam> so this seems to be the bulk of it
<jam> which is taking 15s to "load_graph_all_revisions"
<jam> 7s for 'process_graph_parents' and 8s in 'compute_loaded_graph'
<bialix> abentley: re fixing status: to do so bzr should check every unknown directory for the presence of tree/branch. is not this will be performance penalty?
<jam> note, as far as --lsprof issues
<jam> running with --lsprof takes 18s
<jam> without takes 6
<jam> so there is some significant overhead associated with profiling
<GaryvdM> load_graph_all_revisions and process_graph_parents should be made faster with KnownGraph
<jam> ah, and the other problem is that you are directly using MergeSorter?
<jam> hmm... maybe not
<jam> it seems that tsort.merge_sort does
<jam> though we made tsort.topo_sort() use KnownGraph
<abentley> bialix, I suppose it could be, but unless it's a significant penalty, I think the UI improvement justifies it.
<jam> GaryvdM: I think I remember why... the api is different
<bialix> abentley: ok
<jam> KnownGraph.merge_sort() returns objects
<GaryvdM> jam: If you look at compute_loaded_graph, alot of time is spent in various __init__ calls. Would pyrex speed this up?
<jam> tsort.merge_sort() returns a list
<bialix> abentley: oh, clean-tree moved to core in 1.13. Now I recall this change, but somehow I forgot it later
<jam> GaryvdM: potentially, though also that is probably one of those lsprof fallicies
<jam> __init__ seems to be *much* more expensive under lsprof
<GaryvdM> jam: oh
<jam> I won't guarantee it
 * GaryvdM started on using knowngraph. Digs that out.
<jam> but I've had some real-world experience that tells me that pyrex code looks *tremendously* better under lsprof, but isn't always as much better in real-world
<jam> ah, the other reason that tsort.merge_sort isn't implemented in terms of KnownGraph is because the pure-python implementation of KG uses the tsort implementation of merge_sort ... :)
 * bialix licks stamp and send oneself away via mail
<GaryvdM> jam: I hope I'll get knowngraph used in qlog before then.
 * GaryvdM really of home now.
<jam> GaryvdM: are you back now?
<jam> I just sent an update to qbzr which you might find interesting
<jam> mostly I wish python's gc didn't get in the way so often...
<vila> jam: so reagrding bug #375898, the idea is to merge a whole subtree into the trunk *and* still allowing additional merges
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898
<jam> vila: sure. I'm guessing there are 2 possible issues
<jam> 1) not handling different root ids getting moved around
<jam> 2) having TREE_ROOT in both trees, and not knowing what to do
<vila> jam: ISTM that's exactly the job of bzr-merge-into since bzr core seems to delete the old root-id
<vila> jam: I'm looking at what happens at the first merge right now
<GaryvdM> Hi jam
<vila> jam: I tried using bzr-merge-into but it fails with ERROR: The file id "xxxxxx" is not present in the tree None.
<jam> tree None sounds funny
<vila> yeah, I'm so laughing :)
<jam> so, my initial guess is that both branches are going to have TREE_ROOT as their root id
<vila> no
<jam> which means we have to move the files over, but don't have a good place to put them
<vila> err, let me re0check that
<vila> get_root_id() returns different values for this_tree and other_tree during the merge
<vila> and neither is TREE_ROOT
<GaryvdM> jam: Thanks alot. It will probably take me a while to work through that.
<vila> jam: to summarize before I EOD : 1) doing 'bzr -r0.. ../other' will not keep track of the root id (AFAICS)
<vila> jam: that doesn't sound like a good way to make future merges working
<vila> so 2) bzr merge-into sounds like the right way to do that, from there, will the future merges just work ?
<vila> jam: does the above sound correct ?
<jam> GaryvdM: short answer, KnownGraph is about a 2x improvement, gc.disable() is also a 2x improvement, combined you get 4x
<jam> vila: (1) is probably true, as the old root id gets thrown away, and everything is dumped into '.'
<jam> (2) is probably also true, but IIRC there were some bugs in it wrt root-ids
<jam> GaryvdM: oh and without gc.disable() KG is actually a performance loss...
<jam> (so gc.disable() when using KG is actually a 4x shift..., because KG allocates more objects)
<jam> the primary difference
<jam> is that if the merged-into tree adds a file at the root of the layout
<jam> then it should work transparently to merge that into the combined branch
<jam> vila: ^^
<jam> which may also be why it is breaking
<jam> (adding a file at the root, but there is nowhere to put it in the target tree)
 * fullermd wishes bug 374734 were moving   :(
<ubottu> Launchpad bug 374734 in bzr "upgrading many branches is tricky" [High,Confirmed] https://launchpad.net/bugs/374734
<GaryvdM> jam: How come you wraped this in it's own function?
<GaryvdM>             def make_kg():                return KnownGraph(self.graph_parents)
<GaryvdM>             kg = make_kg()
<jam> just so it would show up in lsprof
<jam> pyrex constructors don't otherwise
<GaryvdM> Oh - ok
<Gnx> I'd need some help, I still can't figure out bzr/sftp is not working at all for this client
<GaryvdM> Gnx: error message?
<Gnx> Connected (version 2.0, client OpenSSH_4.3p2)
<Gnx> Disconnect (code 2): Protocol error: packet 5 in interactive
<Gnx> thats all
<Gnx> I've tried sftp and ssh with other programs, no problems
<Gnx> also this just started one day for no apparent reason
<Gnx> reinstalled bzr too
<dwt> Hi there, I'm trying to get bzr to remember multple push locations (preferably as default)
<dwt> but I don't get from the documentation how to do this
<dwt> is this actually possible?
<dwt> (what I want is to push to both my private public repo on my webpage as well as to the google code repo at the same time when I say push)
<dwt> or if that is not possible, have an easy way to say something like bzr push upstream
<dwt> or something like that
<dwt> (to further complicate matters, upstream is actually a svn repo :)
<fullermd> No, there's only one push location.
<fullermd> You could use something like the bookmarks plugin to get shortcuts for multiple locations.
<dwt> fullermd: well, woth a try
<dwt> thanks
<dwt> it says it only works on linux/windows
<dwt> leets see if that's true (I'm on mac)
<fullermd> The plugin?
 * fullermd would be surprised.
<dwt> yes
<dwt> me too
<dwt> :)
<fullermd> (if it had such restrictions, that is)
<dwt> http://wiki.bazaar-vcs.org/BzrPlugins however is quite explicit
<dwt> :)
<dwt> is there a process to update that page
<dwt> or could you just update it?
<fullermd> Oh, well, it only counts platforms that matter.  Who cares about Mac?   :p
<dwt> ;) me me me!
<dwt> Wasn't there a law somewhere that stated something like
<dwt> "Though shalt not make fun of your loyal users"?
<dwt> I seem to remember that... ;)
<fullermd> ...  what would be the fun of THAT?
<dwt> ;)
<fullermd> If you can confirm it works, I can add the thingy.
<GaryvdM> Gnx: Sorry, I'm not sure.
<dark_soul> okay guys..remember me with the source code not showing up when i click on it via web?
<dark_soul> i was caught in a looong meeting
<dark_soul> so in bazaar.launchpad.net... when i click on anything after the "viewing" and select a source code file to view, it shows nothing
<dark_soul> but if i click any path before the "viewing" and select a source code file it shows
<dark_soul> not sure if its a bug or if its by design
<dwt> fullermd: still tryingâ¦ :)
<dark_soul> if thats the case, then anything after the "viewing" should be unclickable.
<GaryvdM> dark_soul: May be better to ask this in #launchpad
<dwt> fullermd: seems to be working fine so far
<dwt> I wonder, can I get bzr to remember my username and password there too?
<dwt> (preferably in the keychain like the default push location does)
<dark_soul> okay
<mwhudson> hm
<mwhudson> which ppa do i need to get a new bzr on lucid?
<GaryvdM> mwhudson
<GaryvdM> mwhudson: lucid has the latest
<mwhudson> hmm
<mwhudson> what's going on then, i only have bzr 2.1.0dev5
<mwhudson> time to fight apt a bit i guess
<GaryvdM> according to https://edge.launchpad.net/ubuntu/lucid/+package/bzr , it should be 2.1.0
<GaryvdM> and http://packages.ubuntu.com/lucid/bzr
<mwhudson> GaryvdM: bzr.dev is well onto 2.2.0dev$foo by now though, surely?
<GaryvdM> mwhudson: no 2.2 release yet (due this week), so maybe daily ppa
<mwhudson> the daily ppa seems to have ground to a halt
<mwhudson> or i'm looking in the wrong place
<mwhudson> james_w: do you know why https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa hasn't had any uploads for months?
<james_w> mwhudson: I broke the script and never got round to fixing it
<james_w> I could do that now if you would like to use it
<mwhudson> it would make my life slightly easier, if it's not too much work
<james_w> sure
<mwhudson> thanks
<james_w> the reason you don't have lucid's package is that the wherever you got 2.1.0dev5 is doing there versioning wrong
<mwhudson> i think it's from the ~bzr-nightly-ppa :)
<mwhudson> the debian version is 2.1.0+b1+4961+129~8.10
<james_w> oops
<GaryvdM> jam: test_kg + further changes merged. :-) Thanks
<Boingo-OSI> Hopefully somebody can help me.... I am trying to get a working tree in a shared repository.  It seems that no matter what I do I cannot get the working tree to show up in the repository.  Or is this even possible?
<bob2> it is easy to do on repository creation (and is the default iirc)
<Boingo-OSI> Then I am doing something wrong.
<Boingo-OSI> I have tried it via command line and explorer and both times, when I commit from a checkout, the repository is updated, but no working tree is visible.
<bob2> well, you didn't say if you made the repo with working trees or not
<bob2> no idea what explorer does, but bzr init-repo seems to default to having them
<Boingo-OSI> I am fairly sure I did.  I did init-repo and init-repo --trees
<Boingo-OSI> Am I crazy?  Is is possible for the repo to have visible, on the file system, the working tree from any commits?
<Boingo-OSI> Or am I asking something that it can't do?
<bob2> that's the default
<bob2> (note that 'bzr push' won't update the working trees, unless you're running bzr locally)
<Boingo-OSI> But "remote" repo in this canse can be local correct?
<GaryvdM> Boingo-OSI: run bzr checkout to get wt in existing treeless branch
<Boingo-OSI> I want the working tree both localy and in the remote shared repository.
<GaryvdM> Boingo-OSI: Ah *remote shared repository*
<Boingo-OSI> Hopefully I am explaining myself correctly.
<bob2> if remote means "accessed via anything other than file:///", then bzr push will not update it
<poolie> hi
<GaryvdM> Boingo-OSI: maybe https://launchpad.net/bzr-push-and-update will help (needs ssh access)
<Boingo-OSI> Am I looking for push?
<Boingo-OSI> I was thinking of update->work->commit
<Boingo-OSI> And bind.
<Boingo-OSI> Or am I way off base?
<GaryvdM> Boingo-OSI: similar problem to push
<Boingo-OSI> Oh.
<GaryvdM> Boingo-OSI: bzr can't update a remote working tree
<Boingo-OSI> So is it possible at all to have a working tree on a remote shared repo?
<Boingo-OSI> Oh.
<Boingo-OSI> Maybe I am appoaching this all wrong?
<GaryvdM> Boingo-OSI: Either run update on the remote machine (that is what bzr-push-and-update does)
<GaryvdM> Boingo-OSI: Or use bzr-upload
<Boingo-OSI> Well, bzr-upload is also being used.
<Boingo-OSI> At least how I was thinking.
<Boingo-OSI> I have a distributed team working on a PHP web project.
<Boingo-OSI> I was thinking of having everyone use a central repo.
<Boingo-OSI> When you commit it shows up "live" on the development server.
<Boingo-OSI> Then, eventually, we use bzrupload to send the stable version to the production server.
<GaryvdM> Boingo-OSI: You can set bzr-upload to automaticly upload when someone commit/pushes to the central branch
<Boingo-OSI> So in my thinking, the working tree on the remote shared repo would be used to serve the actual dev enviroment.
<GaryvdM> Boingo-OSI: have a central dev branch, and a central live branch
<Boingo-OSI> GaryvdM: COuld you elaborate?
<GaryvdM> Boingo-OSI: set bzr-upload to auto upload to their respective Locations.
<Boingo-OSI> I thought bzr-upload was one way?
<GaryvdM> bzr upload --auto -d central_dev_branch devserver   and...
<Boingo-OSI> Or do you mean have the branch with no working tree and then bzr-upload to the dev server's http folder?
<GaryvdM> bzr upload --auto -d central_live_branch liveserver
<GaryvdM> yes
<Boingo-OSI> Ah, so separate them.
<Boingo-OSI> I was trying to combine them.
<GaryvdM> when you are happy with dev, push dev to live
<Boingo-OSI> Interesting.
<Boingo-OSI> That could work.
<GaryvdM> Or in my case, I merge dev in to live, because my live has changes to config files.
<Boingo-OSI> Yes, as would mine.
<GaryvdM> Hi poolie
<Boingo-OSI> So, to summarize and make sure I have it straight.... the remote shared repo is not web accessible.  In it there are at least 2 branches, dev and live.  Work is done on the dev branch, with an auto bzr-upload to the dev server's web accessible folder.  When ready, the dev branch is merged into the live branch which is then auto uploaded to the live server.
<Boingo-OSI> GaryvdM: I am still a bit new at doing it all this way, so pardon the newb question, but how do you keep your config files from clobering eachother.
<GaryvdM> Boingo-OSI: sounds like you have got it
<Boingo-OSI> My experience with bzr, up until now, so far is a single developer working from a shared ftp with a single branch.
<Boingo-OSI> So I am still getting my head wrapped around multiple branches.
<GaryvdM> Boingo-OSI: re: handling the config files: in the live branch, change the config files, and then commit. From then on, you will need to merge the dev branch in to the live branch (you won't be able to pull because it will give you a message about the branches been diverged)
<GaryvdM> Boingo-OSI: tip: If you have qbzr, run bzr qlog path_to_dev path_to_live
<GaryvdM> Boingo-OSI: screen shot on the way
<GaryvdM> Boingo-OSI: Sorry, cancel the screenshots, I don't have those branches on this pc.
<Boingo-OSI> lol, thanks anyway.
<Boingo-OSI> GaryvdM: Can I bug you with a few more questions?
<Kilroo> I should probably stop trying to come up with convoluted ideas for how to get bzr to work with the svn repositories that my coworkers have shot all to hell and just be glad that my ideas for using it with our raw ftp sites work.
<GaryvdM> sure
<jam> GaryvdM: so the final use of KnownGraph you'll probably want to change, just because you'll probably want to use it *more*
<jam> however, it is a bit of an improvement to start with
<GaryvdM> jam: The loading of the graph?
<jam> that would be one
<Boingo-OSI> Ultimately, there will be lots of devs and lots of live servers, one for each client that the software is being customized for.  A lot of the code between the different clients will be shared.  What would you see as an ideal initial layout for the repo/projects/branches?
<jam> the other would be using it for stuff like your "fixups" of the graph, etc
<jam> basically, I would see it replacing your "graph_parents" if we can make that work
<GaryvdM> "fixups"?
<Boingo-OSI> i.e.:  ClientA and ClientB are both using customized versions of the base project.  But even the base project has a dev and live server.
<GaryvdM> Boingo-OSI: Wow. Sounds complicated. You can say, have a branch called custom1 that clientA and clientB merge from, but not client C
<jam> GaryvdM: you call something that iterates over the graph and plays with a  bit
<GaryvdM> Boingo-OSI: If you run bzr qlog in the shared repo, you will see how the branches relate, and it should help you to understand what is going on.
<Boingo-OSI> GaryvdM:  Not sure if it is or not.  A lot of the code is the same.  For instance, ClientA and B are just modifying CSS and config files from the base project.
<Boingo-OSI> GaryvdM: Well, there are no branches yet, I am trying to figure out the best way to lay them out.
<Boingo-OSI> GaryvdM: Then again, ClientC might have an entire add-on to the base that A and B don't have.
<GaryvdM> jam: yes
<GaryvdM> Boingo-OSI: It's difficult for me to say, not knowing your code. Play with it a bit. May be have a branch for each client. qlog is your friend.
<meoblast001> hi, in the commit information that appears when i make a commit, it has some "unknown:"s
<meoblast001> are those completely disregarded?
<maxb> ?
<maxb> oh, you mean file status
<meoblast001> yeah
<maxb> It's just reminding you that they exist, in case you forgot to add them
<maxb> Other than that, they are disregarded
<meoblast001> i find myself deleting a ton of files before every commit, and if Bazaar doesn't even do anything with those, i can leave them there
<bob2> 'bzr log -v' shows you waht was committed
<meoblast001> i just don't want them going into the repository
<meoblast001> all the auto-generated files, such as configure
<bob2> bzr only commits things you ask it to
<meoblast001> ok, thanks
<maxb> You should explicitly tell bzr to ignore known autogenerated stuff
<meoblast001> how can that be done?
<maxb> bzr ignore :-)
<meoblast001> ah
<meoblast001> thanks
<maxb> Do read 'bzr help ignore' carefully
<meoblast001> ok
<igc> morning
<meoblast001> good morning igc
<poolie> hi higc
<poolie> igc, what's new?
<igc> hi poolie
<Boingo-OSI> Thanks everyone for all the help.
<igc> poolie: building chms for 2.x and reviewing some of vila's patches today
<poolie> cool
<poolie> if we do 2.2b1 tomorrow can we use your scripts to package it?
<igc> poolie: that's the plan. I'll give them a dry run today
<igc> and fix up any rough edges
<poolie> ok,
<poolie> do they need to be merged in or is it entirely external?
<igc> poolie: nothing needs to be merged to bzr
<poolie> jam, i didn't totally understand your reservations about lazy-commands
<igc> poolie: I'm still deciding whether to merge the new code into the windows-installers trunk or put it into a fresh project
<poolie> is it just that you want more of the same, or do you think it's wrong?
<jam> just wondering if we could be even lazier
<igc> hi jam!
<jam> so you don't have the runtime overhead of registering
<poolie> what do you mean?
#bzr 2010-03-24
<poolie> like having no register_command() call, just looking up bzrlib.commands.$foo?
<jam> that sort of thing
<jam> and then falling back to some other place
<jam> but honestly, it doesn't really matter
<jam> and this is better than what we have today
<GaryvdM> Hi igc
<GaryvdM> Night all
<igc> hi garyvdm
<GaryvdM> Must get some sleep...
<poolie> hello spiv
<poolie> jam, that might be nice, but it seems to hit some snags with aliases etc
<poolie> i'll try to keep going on it
<poolie> being able to actually test that it's working and does not regress is very nice
<poolie> if i say so myself
<poolie> jam, spiv, don't forget to organize your travel btw
<spiv> *nod*
<codebloc> I'm consistently getting "out of memory" errors migrating my huge svn repos to bzr.  Any way to get 64-bit bzr on windows?
<poolie> codebloc: if you install a 64-bit python and then install from source that should do it
<codebloc> poolie: thanks, and I almost got that going, but failed when zlib was missing
<poolie> hm
<poolie> i would have thought that would be included with python
<codebloc> "bzrlib/_chk_map_pyx.c(32) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory" is the error
<codebloc> i read it's statically linked with python
<poolie> ah ok, you're trying to compile it?
<codebloc> but even if it's included, the header file isn't
<codebloc> don't I have to compile it, to install from sources?
<poolie> you can run the pure python version
<poolie> but that will be slower, which might be bad if you have a huge project
<poolie> igc is working on windows build stuff
<codebloc> I tried adding "--allow-python-fallback", as an option to setup.py build, but that wasn't recognized as a valid option
<poolie> it may ring a bell with him
<codebloc> i'm absolutely willing to use the slower pure python option if it gets me over this hump
<codebloc> i'm trying to convince executives to switch to bzr from svn
<poolie> hm
<poolie> what happens if you just run 'bzr' from the source directory?
<codebloc> hmm.  it seems to run at least well enough to display usage
<codebloc> let me try to run the convert command line from here
<igc> codebloc: are you converting using svn-ipmort or fastimport?
<codebloc> I read svn-import was faster, so that's what I'm trying
<igc> codebloc: you might want to try the --incremental option and convert the repository in batches
<codebloc> ok, so I tried what poolie suggested, and did a 'python bzr svn-import', but it reports the svn-import command is unknown, which I imagine is due to the warning it also issues saying some compiled extensions could not be loaded
<codebloc> i'm willing to try batches as a one-time thing if that'll work
<codebloc> but here's my concern
<codebloc> some of the revisions in this repos include changes to a ~100MB binary file
<codebloc> when I tried converting those revisions with mercurial, which I realize is somewhat different, the process jumped to nearly 2GB of memory and crashed almost right away
<poolie> that will probably fit
<codebloc> is it realistic to expect 32-bit windows bzr binaries to handle a few hundred MB files?
<poolie> especially if you're using bzr 2.1 and going to a 2a repository
<poolie> imbw
<codebloc> i am
<codebloc> ok, I'll try to do it incrementally
<poolie> i'd try it
<lifeless> codebloc: memory overhead for a X MB file is ~ 3X
<lifeless> codebloc: some operations are a lot better, some few are worse.
<poolie> there is a
<poolie> bug, https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/331342 that you can subscribe to/vote for
<ubottu> Ubuntu bug 331342 in bzr "bzr python-based installer requires 32-bit python on windows; unclear message" [Medium,Confirmed]
<codebloc> yeah, i saw that bug.  i'll definitely subscribe to it
<codebloc> i'll try the incremental approach
<codebloc> thanks for the help
<codebloc> if I run into more trouble i'll be back
<poolie> codebloc: oh also https://bugs.edge.launchpad.net/bzr/+bug/545637 thanks for pointing that out
<ubottu> Ubuntu bug 545637 in bzr ""setup.py build --allow-python-fallback" doesn't work; need build_ext" [Medium,Confirmed]
<codebloc> poolie: no problem.  I'll subscribe to/vote for that one too
<fullermd> Speaking of bugs, which we weren't, am I somehow missing the blindingly obvious way to see the list of affects-me-too bugs?
<poolie>  https://bugs.edge.launchpad.net/malone/+bug/283539 does claim to be fixed...
<ubottu> Ubuntu bug 283539 in malone "Make it possible to search for bugs affecting me" [Medium,Fix released]
<poolie> fullermd: there is an option hidden 3 pages down in the advanced bug search page :/
<fullermd> Yes, but it doesn't show me all the bugs that I set affect on.
<poolie> !
<poolie> i think you're right
<fullermd> I search for any status, affects me, and I get 7 results, but bug 374734 (which I hit Affects on) doesn't show up.
<ubottu> Launchpad bug 374734 in bzr "upgrading many branches is tricky" [High,Confirmed] https://launchpad.net/bugs/374734
<fullermd> And the list it does give is kinda weird.  Some of them I filed, but it's not all the ones I filed.  I'm pretty sure I didn't click affects on at least some of them...
<fullermd> Owell.  Just wondered.  If I'm gonna be puzzled, I might as well be puzzled in company   8-}
<poolie> i commented
<poolie> you can too :)
<fullermd> I would, but I set that it affects me, and now I can't find it again  O:->
<mwhudson> james_w: now what's happening? http://pastebin.ubuntu.com/400307/
<igc> poolie ping
<poolie> hi
<igc> I need to run in a few minutes
<igc> while I'm gone ...
<igc> is there any chance we can rebuild the desolution instance?
<igc> or whatever the term is
<igc> there's new windows updates and some new software (sphinx) installed there
<igc> poolie: it keep asking me to reboot but I'm not sure if we need to rebundle first or not?
<poolie> on phone, we'll do it when you get back?
<poolie> we can rebuild it but i don't want to rush
<igc> poolie: sure
<igc> poolie: it may reboot itself (thanks to Windows updates) while I'm gone anyway
<igc> ok - got to go
 * igc back in a few hours
<fullermd> Oh bother.
<meoblast001> fullermd: looks like someone's having client issues?
<SamB_XP> or is an evil bot
<naoki^> fmm... zlib124dll.zip doesn't contain zlib.h
<naoki^> Windows installer fails.
<james_w> mwhudson: I think the package hadn't built yet
<wgrant> How do I resolve a 'path conflict'?
<wgrant> Ah, looks like if I just resolve the target it works.
<igc> back
<poolie> hi igc
<igc> hi poolie
<GaryvdM> Morning all.
<GaryvdM> I'm trying to use lazy imports in qbzr more.
<GaryvdM> I've run in to a problem I'm not sure how to solve.
<GaryvdM> I get this error on all os.path.xxx calls:
<GaryvdM> bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'path' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory
<GaryvdM> But no where am I lazy importing os or os.path
<GaryvdM> Any ideas ?
<igc> hi GaryvdM - no ideas from me sorry
 * GaryvdM smacks forhead
<GaryvdM> did have a lazy import of os.path - sorry all
<lifeless> :)
<lifeless> EODing
<bjacques> When I commit a bunch of changes to my local branch, and then I 'bzr push' to a remote branch, which of the commit messages will be shown primarily?
<bob2> all of them
<bob2> since push will only work if the remote branch has no new commits
<bjacques> ah, I thought that
<bjacques> bzr would show a "tree of commits", like what you see when you look at the output of bzr log --include-merges
<poolie> are you talking about push -v or something?
<bjacques> sorry, I should have been clearer
<bjacques> what I was thinking of was the commit notification emails that other people receive. (I might be incorrectly using the word "commit" here.)
<bjacques> but it also shows in the output of 'bzr log', without --include-merges, it shows sort of a "parent" commit summary, and if you specify --enable-merges you see the individual commits that happend before the person merged and, presumably, subsequently pushed their branch.
<bjacques> s/--enable-merges/--include-merges/
<bjacques> so, basically, what I'm trying to do is this. bzr branch remote local; (make change); bzr commit -m "minor change 1"; (make change); bzr commit -m "minor change 2"; bzr push -m "Summary of changes: ..." remote
<bjacques> at least, it is my understanding that is roughly how a bzr workflow should look...
<RAOF> bjacques: There is no message on the push.
<RAOF> If you want something like that, you can do it.
<bjacques> Well, obviously I also want to show people the big picture rather than a long list of incremental changes.
<bjacques> So how would I do something like that?
<RAOF> So, what you want to do is make a merge commit.
<RAOF> You can't do that remotely, but that's ok.
<RAOF> You'd do something like bzr branch remote trunk; bzr branch trunk mychanges; ... hack in mychanges, committing as much as you like ...; cd trunk ; bzr merge ../mychanges ; bzr ci -m "Summary of what the mychanges merge does" ; bzr push remote
<bjacques> ah, cool, will try that
<poolie> spiv, you might like to update hydrazine to get a fix for bug 541586
<ubottu> Launchpad bug 541586 in hydrazine "feed-pqm should match subject to avoid breaking threads in gmail" [Medium,Fix released] https://launchpad.net/bugs/541586
<poolie> or to tell me it's not fixed :)
<spiv> poolie: hmm, I did run 'bzr pull' just before using it
<spiv> Oh, the fix is very new, ok :)
<spiv> poolie: FWIW, mutt already threaded them just fine :P
<bjacques> RAOF: that did the trick, thanks!
<spiv> poolie: (I think because Launchpad automatically sets the In-Reply-To header for those messages?)
<GaryvdM> poolie: with --profile-imports, can I turn it off at a certin check point. I want it show me all the imports before a gui window shows, not after
<poolie> spiv, i know, it's really a gpg bug
<GaryvdM> poolie: Figured it out.
<poolie> GaryvdM: what did you do?
<poolie> spiv: s/gpg/gmail
<GaryvdM> I insert this at the point that I want to view:
<GaryvdM> import profile_imports; import sys; profile_imports.log_stack_info(sys.stderr)
<GaryvdM> (it assumes that profileing is on)
<GaryvdM> poolie ^
<poolie> ok
<vila> hi all
<vila> GaryvdM: still there !!! Hi !
<poolie> hi vila
<poolie> how are things
<GaryvdM> hi vila, at work
<vila> GaryvdM: pfew, so you had some sleep, good :)
<vila> poolie: pretty well, I'm working on bug #375898
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898
<vila> I think I roughly understand what is happening and will try to write a small enough test for it,
<vila> but ISTM that what is really wanted is nested trees and I don't expect to fix that :-( :-) :-?
<vila> So I'll try to see if a simple fix can be devised and investigate possible workarounds (including fixing bzr-merge-into)
<vila> And I'll try to keep up with the patch pilot stuff but I've lowered  my expectations there :-/
 * vila afk
<poolie> vlia, thanks for looking at that one
<poolie> and for telling me
<poolie> night all
<spiv> vila: review sent your way
 * spiv is done for the night
<igc> night poolie, spiv
<igc> hi vila
 * igc dinner
<mvo> hello! is there a known problem with upgrading branches from the LP ui? I'm trying to upgrade https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu so that I can merge my changes from trunk into that branch but it does not work, upgrading via cmdline downloads ~30mb and then tells me backup.bzr is already there. deleting that via sftp (I'm sure it was gone) does not help, got the same error again. I'm on lucid, bzr 2.1
 * vila back
<parthm> mvo: maybe you can upgrade via web ui. the branch owner will see an "upgrade" link on the page https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu
<vila> hi spiv, igc
<mvo> parthm: thanks, I tried that first, I see a "upgrade in progress" box then for some minutes and when it vanishes the branch format has not changed (both on the web-ui info and from bzr info -v bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu/)
<mvo> I wouldn't bother much, but it prevents me from merging from my other branches because the formats are not compatible :/
<vila> spiv: hehe, the test scenarios went through multiplesss iterations, I'll check your remarks and will try to explain why I went this route,
<vila> spiv: the principal intent was to be able to define the scenarios right before the tests instead of in load_tests()
<vila> spiv: these tests are unusual in that their setup is far more complex than our usual tests
<vila> spiv: but as always when focused on a given task, and exploring various ways, reviews are usually raising interesting points so I'll look into that carefully
<vila> spiv: thanks for the review anyway
<spiv> vila: I don't have much time right now, but part of my concern is that hopefully we don't need multiple ways of defining scenarios
<vila> spiv: there is one reason here: each scenario needs to be mirrored so that merges are tried in both directions *and* resolutions are tried for both sides
<spiv> vila: the APIs for it are already a bit esoteric
<vila> yeah, it was hard to get there so there is certainly ways to improve that
<spiv> I don't understand why the mirroring requires special support
<spiv> As opposed to e.g. scenarios = scenarios + mirror_scenarios(scenarios)
<vila> spiv: may be I missed a simplification at one point, but when I introduced mirror_scenarios, multiply_scenarios wasn't doing the right thing
<spiv> My gut reaction is that it can be simpler.
<vila> spiv: hehe, you should look at some previous versions :-D
<spiv> But if you need a more advanced scenario-construction API, then TestCases aren't the tool for it.
<vila> spiv: but I'm all for simpler tests :)
<spiv> I can take a stab at simplifying tomorrow if you like.
<vila> TestCases allowed me to keep some locality which make tests simpler to understand
<vila> spiv: if I don't find the time to push anything until tomorrow, you're warmly welcome !
<vila> spiv: I'll try to answer your review at least
<spiv> I seems to me you have a base set of scenarios, and then you wish extrapolate a bunch of other scenarios from that basis.
<spiv> And that's something you ought to be able to express directly with the scenarios themselves.
<spiv> Maybe the scenarios should have less keys but richer objects in them?
<spiv> Not sure, I have a few rough ideas I can explore.
<spiv> Maybe inspiration will strike while I sleep :)
<spiv> Actually, I'm not sure I get the point about locality either.
<vila> spiv: I'm not confident I've found the right hooks yet (not the right infra for that matter), I've discovered many details why translating the test (from back to white boxes)
<vila> spiv: have a look at the history, things may be clearer that way
<spiv> AFAICT, you're essentially just keeping the components of a scenario local with itself?
<spiv> I don't see why inheriting from TestCase helps there.
<vila> err, by TestCase you mean TestParametrizedResolveConflicts ?
<spiv> I know you want to define custom methods like assertion methods, but that can be done pretty easily in a plain scenario dict without grouping the scenario parts in a TestCase definition.
<spiv> Er, right.
<spiv> That's not a TestCase?
<vila> oh wait ! You need to look at  lp:~vila/bzr/537956-parent-loop-incomplete !
<vila> spiv: I've changed many things in the test infra there !
<spiv> I see no prerequisite-branch on the merge proposal :P
<vila> that's because I changed things *after* this branch and this branch is a pre-requisite of the following one :)
<vila> spiv: https://code.edge.launchpad.net/~vila/bzr/537956-parent-loop-incomplete/+merge/21224
<spiv> Well, a comment about this would have been handy, at least :)
<spiv> Feel free to tell me if I missed one, of course! :)
<vila> spiv: sorry about that :(
<spiv> Ok, I'll take a look at that tomorrow.  Thanks for the pointer. :)
<vila> spiv: I didn't realize this when we started this discussion :(
<spiv> Me either ;)
<parthm> mvo: i tried the upgrade locally and it worked. http://pastebin.com/8iZrsJGb
<parthm> mvo: i am using bzr 2.1 on karmic
<spiv> vila: so, a final thought before I go for the night
<vila> spiv: And I don't remember exactly what I backported from one branch to the other, I'll re-read everything carefully
<spiv> vila: I can see the attraction of using the class statement to construct a complex scenario
<spiv> vila: but does that class actually need to inherit from TestCase -- or anything else?
<parthm> i get a large set of "can't start new thread" error on 'bzr --no-plugins selftest --parallel=fork' http://pastebin.com/AbQ8G0Ge is this expected?
<spiv> Also, I wonder if a hugely complex scenario is a smell.  I think probably they are unavoidable for genuinely complex situations, but I'm not sure...
<spiv> vila: anyhow, good night, and thanks for fixing bugs and improving the test coverage :)
<vila> spiv: one final remark before you go to sleep too :) : I consider this a work in progress, there are still tests that needs to be translated and there are still *no* tests involving several conflicts... So I'm definitely open to enhancements but I don't want to to delay landing fixes either
<parthm> mvo: i am not too sure how launchpad branches work but you branch seems upgradable to me :)
<mvo> parthm: thanks, locally I can upgrade too, its the remote end I want to upgrade. what is the most efficient way? or some reason bzr+ssh errors out with "backup.bzr" already exists (even if I delete it with nautilus on the server). and the LP webui upgrade does nothing for me. I'm trying sftp:// upgrde now, but it appears to be really slow
<mvo> (locally I have upgraded already :)
<vila> spiv: yeah, the complex setup allows to use pdb with the right simple context in the right place, that's the goal, this smells, but I don't want to cheat too much either, building the conflicts "manually" with their associated wt.... yells "brittle" far too loud to my ears :)
<vila> spiv: thanks for feedback anyway, this is hard stuff and I'm glad to be able to discuss it
<parthm> mvo: fwiw, bzr 2.2dev allows multiple backup.bzr folders as backup.bzr.~N~ so that particular error will go away. you could try using lp:bzr
<parthm> mvo: https://bugs.launchpad.net/bzr/+bug/300001 i am not sure how that plays with launchpad though.
<ubottu> Ubuntu bug 300001 in bzr "existence of backup.bzr blocks running upgrade a second time" [High,Fix released]
<mvo> parthm: thanks, I check the new bzr out now and will try that
<mvo> parthm: thanks for your help (much appreciated). I solved it now the cheap way by renaming the lp branch and pushing my local upgraded one as a new branch
<parthm> mvo: that sounds good to me :)
 * mvo is *so* happy to be able to commit again
<panta> hi everyone
<panta> I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging
<bialix> hello all
<panta> I've read "Contributing to Bazaar", but I'd like to know if they could be considered interesting
<bialix> they?
<parthm> bialix: ^ quote "I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging"
<parthm> from panta
<bialix> ah, ok
<jelmer> panta: Please send an email to the list about them
<jelmer> panta: If they're generic enough I think we'd be interested in them.
<panta> jelmer: ok, thanks. Should I include a preliminary patch?
<jelmer> panta: yeah, please do
<panta> jelmer: ok, thanks for the info.
<shane_> Hey, im getting a strange error when committing http://pastebin.ubuntu.com/400482/
<fagan> I got it when I did a bzr commit
<fagan> I have my ssh and pgp key set up but I only did it an hour ago. (I did a fresh install so I made new keys)
<bob2> shane_: you can't commit via http
<fagan> Why is it trying that then?
<bob2> presumably you have bound your branch to another branch via http
<bob2> 'bzr info' oughta show you
<fagan> bob2: can I change it to https?
<bob2> you probably can't commit via https either
<bob2> is this an lp project?
<fagan> Yep its planet-ubuntu
<fagan> Im just updating my hackergotchi :)
<bob2> well, bind to the bzr+ssh url
<fagan> bob2: I figured out what was wrong
<fagan> It hadnt logged me into bzr yet :)
<bob2> that you had bound to a http url
<bob2> and you can't commit via http :)
<bob2> ah, launchpad-login
<fagan> bob2: yep I have it working now
<bob2> excellent
<fagan> Thanks
<fagan> Got to run
<u-foka> hy! i'm get this: "ERROR: exceptions.IndexError: list index out of range" when I try to bzr fast-import my.fi new-repo/trunk
<u-foka> what I doing wrong?
<u-foka> new-repo is created with init-repo before, and it's empty, using bzr 2.1.0
<bialix> u-foka: use just `bzr fast-import my.fi new-repo`
<bialix> if it does not work you need to file a bug
<u-foka> same error :S
<bialix> u-foka: pastebin output of `bzr -Derror fast-import my.fi new-repo`
<u-foka> 1 sec
<bialix> how you have created my.fi?
<u-foka> bzr fast-export old_repo my.fi
<u-foka> old repo need to be altered
<u-foka> but the unaltered fi makes the same error
<bialix> pretty odd
<bialix> are you on windows?
<u-foka> http://pastebin.com/hCy75EpM
<u-foka> I'm on lucid
<bialix> u-foka: I don't know what the version of fastimport you have. You may want to try to use the latest version from trunk
<bialix> but there is definitely error in fastimport plugin
<bialix> please, file a bug, and specify the version of the plugin
<u-foka> okay, thanks!
<u-foka> the same fi imported on the karmic machine fine
<bialix> definitely the bug
<bialix> use fastimport as of version on karmic then
<u-foka> fastimport 0.9.0dev
<u-foka> it seems to me that this already reported as bug #287767
<ubottu> Launchpad bug 287767 in bzr-fastimport "fastimport from git fails" [Undecided,Fix released] https://launchpad.net/bugs/287767
<mgedmin> bzr rm file1; bzr ci file1 -> "paths are not versioned: file1"
<mgedmin> huh?
<mgedmin> sorry, my bad
<mgedmin> bzr st prints filenames relative to branch root, not to my $PWD :( :( :(
<spiv> mgedmin: https://bugs.edge.launchpad.net/bzr/+bug/520662
<ubottu> Ubuntu bug 520662 in bzr "Add option to output relative paths" [Medium,Confirmed]
<igc> night all
<nlisgo> why is sftp so slow. I tried bzr+ssh and I was worried when it had finished so quickly. I thought perhaps it didn't send the commits to the repo. But it had!!
<NfNitLoop> sftp has to do everything via file reads over the network.
<NfNitLoop> bzr+ssh spawns a remote bzr instance that can do those file reads on the server.
<NfNitLoop> so it's faster.
<NfNitLoop> but sftp works even if you don't have bzr installed remotely.
<vila> jelmer: ping
<jelmer> vila: 'lo!
<vila> jelmer: hi !
<vila> bzr-loom is currently broken because BranchFormat.open got a new 'name' keyword arg, rings a bell ?
<jelmer> vila: ah, yep
<jelmer> vila: It's documented under "API CHANGES" in NEWS ;-)
<vila> jelmer: long story short, that means bzrlib API needs to be bumped :-/
<jelmer> vila: I'll submit a aptch to bzr-loom
<vila> jelmer: thanks ! Not a big deal for loom (I just added the name arg in a hurry as I couldn't use my loom anymore), but bumping the API will have more consequences...
<vila> (for other plugins that is)
<vila> jelmer: the related patch in only in bzr.dev right ?
<jelmer> vila: yep
 * vila checks 2.2 release date
<jelmer> vila: this is all work done towards colocated branches
<vila> jelmer: I know, I know, good work ! :D
<vila> rats, 2.2b1 expected in 8 hours
<vila> jelmer: could you propose a patch with the API bump so that poolie wont miss it ?
<jelmer> vila: ok
<jelmer> vila: Whoa, I wasn't aware 2.2 was already that close
<vila> jelmer: thanks a ton !
<vila> jelmer: well, that's what https://edge.launchpad.net/bzr/2.2 says (I have a bit of mail backlog but I'm pretty sure poolie announced it)
<jelmer> vila: Thanks
<dash> hmm. no jelmer... guess i won't talk about my bzr-svn bug yet. :)
<MvG> Hi! What's the easiest way to find the first mainline revision integrating a given revision using the command line? In other words, how do I find out when a given revision actually got merged?
<vila> MvG: bzr log <revno>.. -l<max_merge_depth>
<dash> -l? or -n
<vila> -l == --limit
<dash> oh i see what you mean now
<MvG> Missing -r.
<vila> The idea is to start log at the revision you're interested in until the tip limiting the output to at least the merge depth of the revision
<vila> MvG: argh, yeah, sorry
<MvG> Otherwise it gives me "bzr: ERROR: Start revision not found in left-hand history of end revision."
<vila> MvG: double-argh, yes add -n0
<MvG> No luck either: "bzr log -r 4056.2.1.. -l3 -n0" for the bzr.dev branch prints the same as "bzr log -l3 -n0". No indication of the merge point for 4056.2.1
<MvG> vila: by max_merge_depth, what number did you have in mind there?
<vila> MvG: meh, that's a bug
<MvG> vila: i still don't see how your approach is supposed to work either.
<MvG> I understand the -r part, and I see I'd like the last mainline rev printed by that output. I don't see the role of the -l there.
<MvG> vila: Oh, a --forward does help.
<vila> MvG: it's to avoid displaying all the revisions you don't care about, ha rats, yeah, damn, 2 args good out of.. 5 ? :-/
<MvG> "bzr log -r 4056.2.1.. --forward -l1 -n0" looks pretty good. I guess I'll define an alias.
<vila> yeah, the result is correct, no bug here, sorry
<rellis> Is there a way to merge two distinct revisions from one branch into another branch?
<rellis> Trying to do it in one command, and it is not a range of commits.
<beuno> rellis, no, not in one command if they are not sequential
<rellis> gotcha, thanks
<mwhudson> Peng: have you looked at https://code.launchpad.net/~tseaver/loggerhead/sphinxify/+merge/21948 at all?
<jelmer> mwhudson: thanks for the review of my pygpgme branch
<jelmer> mwhudson: do you know if there's any eta on mirrored branches/vcs imports for packaging branches?
<mwhudson> jelmer: i think it's mostly a matter of having a ui to be able to create them now
<jelmer> mwhudson: does that mean there's already a API to create them ? >-)
<mwhudson> jelmer: ah, no, probably not
<mwhudson> the internal apis probably need to be cleaned up a bit
<mwhudson> but mostly around creation i think
<mwhudson> if you could magic one into existence it would mostly work i think
<codebloc> the windows installer version of bzr 2.1.0 runs out of memory doing "bzr svn-import"  on my repository due to the presence of a single change to a 250MB file
<codebloc> this on a 64-bit windows machine with 12GB of RAM
<codebloc> I have created a test SVN repository that can reproduce this problem
<codebloc> I'd like guidance as to whether this should be a separate bug, or just another manifestation of https://bugs.launchpad.net/bzr/+bug/109114
<ubottu> Ubuntu bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Wishlist,Confirmed]
<codebloc> if it is another instance of 109114, is there any hope of this bug getting a higher importance?  I can't use bzr as long as it has this limitation
<jelmer> mwhudson: hmm, I might then :-)
<jelmer> codebloc: it's just another manifestation of that bug
<jelmer> codebloc: I'd recommend asking for a higher priority on that bug report
<andreasheintze> Hi! Is there anybody here?
<jelmer> hi andreasheintze
<andreasheintze> Hi there! I'm having a question about bazaar and I thought maybe someone here can help me?
<dash> andreasheintze: usually :)
<andreasheintze> I'm new to bazaar so... anyway. I have set up a repository of our intranet at work, wich I'm developing in PHP and javascript.
<andreasheintze> I have access to the whole site, but I got another developer that is responsible for everything under one folder in this site.
<andreasheintze> How can I limit him to just be able to update the files and folders inside that folder?
<andreasheintze> I don't want him to able to commit and merge changes of files outside of that folder. Can I do this?
<andreasheintze> If anyone has a link or can guide me in the right direction, it would be great!
<thumper> andreasheintze: normally this would be done by having separate branches
<thumper> I'm pretty sure that bzr doesn't have a restriction like this for a single branch
<Peng> mwhudson: Um, probably not. I've been AFK. :D
<andreasheintze> Ok, I thought so, but how? If I make a new branch of my main branch it will create the whole site, not just that folder.
<Peng> mwhudson: I'll get to it later -- no guarantees I'll do any more than think "hmm, that looks complicated -- I'll let mwhudson handle it". :P
<bmm> I've posted a bug for bazaar hookless-mail, but I'm not sure anybody will read it as I'm the only one who is subscribed: https://bugs.launchpad.net/bzr-hookless-email/+bug/546431 Is this bug going to just die?
<ubottu> Ubuntu bug 546431 in bzr-hookless-email "[whishlist] Support for multiple e-mail adresses" [Undecided,New]
<jelmer> mwhudson: another thing, newer versions of bzr-svn should be able to handle the KDE repository - it'd be nice if we can get a newer version on Launchpad before the rollout
<mwhudson> jelmer: i think that got integrated when i did the incremental import thing
<mwhudson> Peng: well fair enough
<jelmer> ah, nice
<thumper> bmm: appropriate prodding here should get some bzr developers to at least look :)
<lifeless> thumper: perhaps
<thumper> andreasheintze: you could split out the subfolder - look at the split command
<lifeless> hookless-email - best to send something to the list I think
<lifeless> bmm: ^
<andreasheintze> split, ok I'll take a look at it. Thanks!
<bmm> I have small projects with friends and I have like two to three people per project I want to mail.. so I would like to be able to add just a single address in most cases :)
<bmm> lifeless: ^
<lifeless> bmm: sure, but I don't think anyone here as seen the code for the hookless-email at all
<lifeless> I think the developer is on the bzr mailing list though
<lifeless> anyone else see'Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<lifeless> '
<lifeless> running the test suite ?
<bmm> lifeless: Thanks for the tip!
<jelmer> lifeless: no - is this with or without plugins?
<lifeless> jelmer: without
<jelmer> moin poolie
<poolie> hi jelmer
<mtaylor> lifeless: hey - wanna see something purty? http://hudson.drizzle.org/job/drizzle-build-spare-macos/84/console
<lifeless> purty
<lifeless> bug filing time
<mtaylor> lifeless: (I'm going to upgrade bzr there right now - I just thought I'd paste it in...)
<lifeless> its a dupe
<mtaylor> lifeless: that's running bzr 1.18
<lifeless> oh
<lifeless> hm
<mtaylor> :)
<codebloc> assuming i somehow work around the memory issues with importing my svn repository, i have an issue with access control that i'd need to solve with bzr
<lifeless> thats an issue mtaylor - we didn't intend to break compat like that
<mtaylor> lifeless: oh good!
 * mtaylor is helpful
<codebloc> let's say my company has a product with two bits of code.  one is '/boring', and another is '/cool'.  we can't build the product without both /boring and /cool, and /boring depends upon the output of the build of /cool
<codebloc> we have overseas developers working on /boring
<codebloc> but our onshore dev team works on /cool
<codebloc> with svn it's pretty easy to limit access for some devs to just /boring, and let the rest access everything
<codebloc> what is the idiomatic way(s) in bzr to solve this problem?
<mtaylor> codebloc: ssh
<bob2> separate repositories, ssh, unix groups
<mtaylor> what bob2 said
<codebloc> but if the repositories are separate, that complicates building and branching, doesn't it?
<codebloc> let's say I want to do a build
<bob2> no
<bob2> it is unrelated to building
<codebloc> i need /boring and /cool
<codebloc> and I want to create a label for that build
<codebloc> or see a unified history for prepping release notes
<codebloc> maybe this is my svn mindset, thinking in terms of a monolithic repository
<bob2> yes
<mtaylor> lifeless: do you need any of the .bzr.log from me / want me to file/update anything?
<codebloc> if so, do you know of any (preferably large scale) projects that use multiple repositories i could look at to try to understand
<bob2> you're conflating "repositories" and "projects"
<codebloc> yes, i suspect I am
<codebloc> i'm trying to imagine how my team would work if we had one svn repos for our driver code, another for our daemons, another for our UI, etc
<codebloc> it would be a mess
<codebloc> i guess that's not so with dvcs's like bzr?
<bob2> well, I can only think of two cases where it matters:  you need to do more than one check out, and your build process needs to remember more than one rev no
<codebloc> well, in our particular case our build numbers correspond to the svn revision number of the working copy used to do that build, so obviously that assumes a unified repository
<codebloc> but we also have some code in, say, 'libraries', that code in, say, 'gui' depends on.  With one big checkout, we can assume the 'libraries' project has a certain path relative to 'gui' so the project file can specify that relative path explicitly
<codebloc> with multiple repositories the developer would have to make sure to arrange his working copies so as to preserve this relationship
<codebloc> and if he did the equivalent of an 'svn switch', he'd need to do so for every working copy
<codebloc> not the end of the world, but also not what any of them are used to.
<codebloc> is that just something teams using bzr or git or hg are used to doing?
<mtaylor> codebloc: you may want to check out bzr-builder
<mtaylor> codebloc: it allows you to create "recipes" for how you pull stuff from different bzr branches
<codebloc> interesting
<mtaylor> codebloc: a lot of the dvcs world is modeled around how open source stuff works anyway - as in, I might depend on libgcrypt, but those guys aren't part of my project - so I either grab a tarball release from them, install a deb or I pull from their bzr repo
<codebloc> hmm
<codebloc> let's take canonical for example
<codebloc> each ubuntu release is obviously a huge build process
<codebloc> even though most of it is probably packages from other projects, there's still got to be a fair bit of ubuntu artifacts
<codebloc> how to they use bzr to manage that?
<mtaylor> so - all of that is much easier when you don't add the "make this bit private" element :)
<codebloc> hehe, yeah, presumably
<mtaylor> and ubuntu doesn't solve all of that problem with bzr
<codebloc> but at the same time that's pretty common in commercial software shops like mine
<mtaylor> large portions of it are solved inside of the debian repository and the debian packaging
<codebloc> hmm
<mtaylor> but that's what I'm saying - if you draw organizationally from how that's done, right?
<codebloc> yeah, I get what you're saying
<mtaylor> have the display-driver folks actually cut and release a lib that you can install and other groups can consume
<codebloc> that's how large-ish software companies tend to work
<codebloc> perhaps it's time we start working that way too
<codebloc> maybe then we wouldn't have this massive svn repos that bzr can't seem to ingest ;)
<mtaylor> it's a bit of an uphill the first time ... but it has nice payoffs
<mtaylor> codebloc: :)
<mtaylor> codebloc: also - check your versions of svn and python-svn
<mtaylor> codebloc: I know there was a memory leak bug in python-svn at one point
<mtaylor> which I believe has since been fixed
<mtaylor> codebloc: heck - if you wanna get really crazy- have each component actually release and install debs :)
<codebloc> mtaylor: whoa!  let's not get carried away ;)
<jelmer> mtaylor: to add to the confusion, we never actually used python-svn, only python-subversion (yes, they're two different things)
<codebloc> mtaylor: libsvn is 1.6.5.  python-svn is not installed, which is making me wonder how it works
<jelmer> and we're now using python-subvertpy, which should not have any memory leaks
<codebloc> jelmer: aha, that explains it.
<mtaylor> codebloc: sweet! listen to jelmer - he knows all
<codebloc> i'm running python-subvertpy 0.6.9-1 on my 64-bit ubuntu box
 * jelmer fails to make a bad pun about subversion or somesuch
<codebloc> neither python-svn nor python-subversion are even installed
<codebloc> so sounds like I don't have the memory leak bug
<jelmer> codebloc: you shouldn't need either, just subvertpy
<codebloc> just the 'feature' whereby memory is consumed until it is exhausted ;)
<jelmer> codebloc: you just posted that link to the example repo on the bug right?
<codebloc> yes, that was me
<poolie> hi
<poolie> thanks for giving an example there
<codebloc> poolie: no problem.  believe me when I say, I WANT bzr to work for us.  if I have to do another svn merge I'll very likely pop a blood vessel
<jelmer> codebloc: I'll have a look at it once I figure out how to unpack a 7zip file :-)
<lifeless> jelmer: install the package ;P
<codebloc> jelmer: 7zip is the future!  :)
<codebloc> jelmer: the deb package is p7zip, iirc
 * jelmer growls
<jelmer> in my time we used arj on floppies and it worked just fine
<hazmat> jelmer, i thought all the leaks in py svn bindings were fixed as of 1.6
<mtaylor> 7zip?
<mtaylor> "Open source Windows utility for manipulating archives"
<codebloc> jelmer: when I was coming up you paid for a pkzip license like a good little prole.  Thankfully time marches on
<mtaylor> ewwww
 * mtaylor == apt-get install tar gzip 
<codebloc> i used it because it usually gets better compression ratios than zip, rar, or gzip
<codebloc> in this particular case my test data are random byte sequences so there was obviously not much compressing going on
<codebloc> i may as well have just tar'd it for all the space savings I got
<jelmer> hazmat: possibly - we switched to subvertpy before 1.6
<lifeless> so
<lifeless> tar + xz ~= 7zip
<jelmer> rzip ftw!
<jelmer> codebloc: so, it looks like the memory usage isn't particularly related to the fact that you're importing from svn
<jelmer> Bazaar deals with full files in a couple of places at the moment, so I guess it's a nontrivial amount of work to fix that bug.
<codebloc> jelmer: that was my suspicion, especially since I can repro it with a repos that only has a few revisions
<codebloc> jelmer: i get that, but what I couldn't understand was why a 250MB file can exhaust available memory
<codebloc> even if it stores 4 whole copies in mem, that's only 1GB
<codebloc> a 32-bit process under 64-bit windows has 4GB of addressable memory to work with
<jelmer> codebloc: Importing that test repo uses max 1.8 Gb here
<jelmer> and I'm on 64bit
<codebloc> jelmer: yeah, why do you suppose that is?  Doesn't that seem high given the relatively small quantity of data involved?
<jelmer> codebloc: probably needless memory duplication
<jelmer> when generating delta's serializing to disk, etc
<codebloc> jelmer: i see.  meaning it's probably not an easy or forthcoming fix...
<spiv> We currently expect to hold up to 3 copies of file in memory.
<spiv> (which is still rather bad for large files, obviously)
<codebloc> jelmer: is that to say all the teams using bzr simply never deal with binary files even as small as 250MB?
<spiv> I'm not sure why you're seeing even worse than that, but it's probably a bug :)
<jelmer> codebloc: probably, I don't think I've personally ever dealt with a file larger than 10Mb in a VCS
<codebloc> jelmer: so if I'm to use bzr I'll need to exclude from revision control any binary files over, let's say, 100MB in size, and version them some other way
<codebloc> back on the subject of how large teams use dvcs, here's another scenario i'm puzzling over
<codebloc> let's say I want to use the best practice of feature branches to isolate my work on a new feature while maintaining sync with trunk
<codebloc> what do teams do when the feature they're working on spans multiple repositories?
<codebloc> eg, you're adding a feature that involves a change to a web service, and also a change to a couple of GUI projects to expose this new feature to users
<codebloc> does bzr have any features that allow you to somehow maintain one feature branch with changes to both repositories, and merge that back in to the respective repositories when the time comes?
<codebloc> or do you just create two separate feature branches in two separate repositories and try to remember to merge them both back at the same time?
<spiv> codebloc: yes (separate branches)
<codebloc> spiv: in practice doesn't that get a bit confusing?  particularly if it's not two repositories but three or four or five?
<spiv> codebloc: I think some of the tools like bzr-builder that help assemble a group of related branches also have some facility to update that collection in synchrony (by assembling a new recipe at least)
<codebloc> spiv: ah, interesting.
<jelmer> codebloc: if you have a couple of branches like that that are very closely related,are you sure you don't just want one branch?
<codebloc> jelmer: actually I do, but remember I need some code to be accessible only to onshore teams, while other code is also accessible to offshore developers, so based on my earlier irc conversation i got the message that the way to do that was separate repositories with ssh and unix groups to control access
<spiv> codebloc: yes, it gets confusing sometimes, but usually not very.  i.e. just "that's a funny failure -- oh, I need to update branch Y as well, duh"
<spiv> codebloc: how confusing it will be for you will depend on how often you need to do it, and how tightly/loosely coupled your different components are, etc.
<codebloc> spiv: i see
#bzr 2010-03-25
<beuno> mwhudson, someday, we'll need to clear out all those merge proposals for loggerhead
<beuno> I feel very bad for all the unused code  :(
<igc> morning
<hazmat> is it possible (via bzr-svn) to set a file property
<mwhudson> beuno: yeah, me too
 * hazmat wonders if a web browser on a bzr repository can be fast
<lifeless> I feel so fumble fingered on this new keyboard
<RAOF> lifeless: Is that your new envy-inducing laptop of supreme power?
<lifeless> yes
<lifeless> its not actually /that/ fast
<lifeless> as its a mobile edition, its relatively slow clock rate (2.13Ghz, idling at 1.2Ghz)
<lifeless> but the memory is really nice
<lifeless> and the SSD is pretty zippy
<RAOF> And it's quad-core, isn't it?
<lifeless> bzr selftest --parallel=fork took 6 minutes
<lifeless> 2 core, with threads so linux sees 4 cpus
<RAOF> Aaah.  Still, 8gb of ram must be all sorts of fun.
<lifeless> yes
<lifeless> once i finish bugfixing ubuntu-vm-builder I'm going to make a lucid VM for lp patches
<lifeless> I've got 20G free, which is strange
<lifeless> I had a 60GB disk in my old laptop
<lifeless> rsynced across, and I have 86G used
<lifeless> there is 5 GB in a recovery partition I didn't have the heart to blow away, and 1GB in swap, just in case it really wants it
<Meths> What laptop is this?
<lifeless> Meths: my new one
<Meths> make/model?
<lifeless> x201s
<lifeless> i7 640, 8G ram, 128G samsung SSD
<Meths> pretty sweet
<lifeless> yeah :)
<poolie> a separate vm so that it doesn't mess with your general system configuration?
<lifeless> yeah
<lifeless> I dont' want pgsql and apache running when I'm flying to $destination
<lifeless> and i'd forget to shut em all off if I had them installed-and-running by default
<poolie> mm me too
<hazmat> is it possible (via bzr-svn) to set a file property
<jelmer> hazmat: no
<poolie> james_w, we'd especially like to get it in for https://bugs.edge.launchpad.net/bzr/+bug/521989
<ubottu> Ubuntu bug 521989 in bzr "errors when importing WorkingTree on a thread due to signals" [Undecided,Confirmed]
<james_w> ah, hi
<james_w> is it bugfix only?
<poolie> our x.y.z, z>0 releases will always be bugfix only
<james_w> poolie: could you send me a mail and I will look tomorrow? IRC is too easy to forget.
<poolie> fsvo 'always' i guess :)
<james_w> should be a 2 minute job for me in that case
<poolie> thanks, i will
<james_w> yeah, there's bugfix an there's bugfix :-)
<poolie> sent
<hazmat> loggerhead needs alot of love
<mwhudson> hazmat: yeah
<hazmat> mwhudson, is there anyone with dedicated time on loggerhead?
<mwhudson> hazmat: as much as anyone, it's me, but i've been doing other things lately
<poolie> doesn't max?
<lifeless> doesn't max what?
<mwhudson> poolie: true
<poolie> have some time on loggerhead
<poolie> i don't know if that's still true
<hazmat> a couple things worth looking at.. switching out to chamelon for page templates, use an aggregate js file, slimming down the html by using css.
<Peng> Another new templating language? Sounds fun.
<mwhudson> Peng: it's another implementation of the same one
<hazmat> its a page template engine, almost entirely compatible with the existing templates
<Peng> Oooh. Neato.
<mwhudson> god knows simpletal isn't very nice
<hazmat> its mostly faster because it compiles out to python code, instead of a using a template engine interpreter
<Peng> FWIW, I wrote code to use Yahoo!'s aggregate JS file for YUI. Nothin' for Loggerhead's JS, though.
<hazmat> it would be nice if loggerhead didn't have to scan the repo and (re)build a cache to serve, but its not clear if that can be worked around, i assume that's mostly to avoid xml parse
<lifeless> hazmat: we don't use xml these days
<Peng> hazmat: Patches welcome. :P
<hazmat> hmm.. so perhaps the loggerhead whole history cache is uneeded
<Peng> Seriously, though, re-evaluating that is on the to-do list.
<hazmat> i notice trac-bzr doesn't bother with it.. it actually seems reasonably fast on a small repo
<Peng> Not all repos are small.
<hazmat> Peng, i no.. i'm using the launchpad repo as my test case for performance analysis of loggerhead.
<hazmat> s/no/know
<Peng> <3
<hazmat> is there a way i can see what a pull will bring in without actually doing it
<Peng> hazmat: "bzr missing"
<hazmat> Peng, thanks
<Peng> hazmat: That shows what both pull and push would do. See "bzr help missing" for the arguments to pass if you only want to see one or the other.
<Peng> poolie: pm?
<Peng> Eep.
<Peng> I broke poolie. :(
<fullermd> Now you have to take his place.
<parthm> i looking at bug #304320 seems easy enough to add --clean-obsolete-packs option
<ubottu> Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/304320
<parthm> in order to actually delete the dir contents i am thinking of adding an additional parameter to transport.delete_tree that allows skipping delete for container
<parthm> http://pastebin.com/JbaQhzxD
<parthm> this should ensure that if the operation is terminated for some reason .bzr/repository/obsolete_packs folder is still there. is this a reasonable approach?
<spiv> parthm: I think that's reasonable.  You should add a per_transport test for the new param.
<lifeless> mm
<parthm> spiv: thanks for the pointer. i will add the per_transport tests.
<lifeless> there is functionality to delete the contents of obsolete_packs already
<lifeless> Please don't use the transport api to get at the private functionality of the repository - use that existing code instead.
<xnox> Hello. How to use keywords plugin? I can't understand where do i need to place rules file
<parthm> lifeless: where can I find this function? bzrlib.repository?
<lifeless> parthm: bzrlib.repository.repofmt/pack_repo.py - somewhere in there
<lifeless> obsolete packs is cleaned out when we do a pack - right before we do the pack.
<parthm> lifeless: i see a private method, repofmt.pack_repo._clear_obsolete_packs.
<lifeless> yup
<lifeless> its a private task :)
<lifeless> add a parameter to the pack() call - something like 'assume_disk_will_write_immediately' or the like - its very risky deleting obsolete_packs folder, we really don't want people using this in API code in a casual manner
<lifeless> its particularly unsafe to use over SFTP/HTTP/NFS
<parthm> lifeless: i agree, i have added this to the pack command help.
<parthm> http://pastebin.com/JbaQhzxD
<parthm> assume_immediate_write sounds like a good way to do it.
<lifeless> parthm: on the transport change, which might be nice in and of itself, how about 'children_only' rather than 'skip_container'
<lifeless> container isn't used elsewhere in the docs for transports
<parthm> yes. children_only sounds good. maybe i should file it as a bug so it can be tracked separately.
<lifeless> sure
<parthm> i was wondering if it makes sense to have a --clean-obsolete-packs-only option. pack can sometimes be time consuming. this would give the user to just remove obsolete packs without going through pack process.
<lifeless> sure
<lifeless> there may be a bug on that even
<parthm> I notice that only RepositoryPackCollection has a _clean_obsolete_packs method and not KnitPackRepository. both have the pack method. whats the different between the two?
<spiv> RepositoryPackCollection is not an implementation of the Repository interface
<spiv> It's an implementation of ._pack_collection of (pack format) repositories.
<spiv> So, the difference is different layers.
<parthm> spiv: ah. i get it. so repository.pack internally maintains _pack_collection which it calls pack on. thanks.
<AfC> Anyone know off hand the Subversion equivalent of `bzr revert`? Is there one?
<mwhudson> AfC: svn revert -R . ?
<AfC> hm
<AfC> oh
<AfC> how did I not see that. Grrr
<AfC> sorry. Thanks mwhudson
<lifeless> mwhudson: 'bzr revert'
<Peng> Yeah, use bzr-svn. :D
<parthm> i am planning to add tests for bug #304320 to tests.blackbox.test_pack http://pastebin.com/C51qWKUH
<ubottu> Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,In progress] https://launchpad.net/bugs/304320
<parthm> is the pack operation guaranteed to generate packs?
<parthm> i am thinking of doing a transport.list_dir() and making sure its len is 0
<parthm> with --clean-obsolete-packs
<lifeless> parthm: its not guaranteed, no - but pragmatically thats fine
<lifeless> just do two commits, then a pack.
<lifeless> (because one commit would be fully packed already)
<lifeless> if, in future, we change bzr to auto clean when we can tell things have hit disk or whatever, we can change the test.
<parthm> lifeless: right now when are the obsolete packs cleared?
<lifeless> parthm: when bzr packs
<parthm> lifeless: ok. i will go with the two commits approach. thanks.
<vila> hi all!
<parthm> vila: hi
<parthm> is there a way to put a print in a test case and view it? selftest -v doesn't seem to do it.
<vila> parthm: if you're running blackbox tests, keep in mind that stdin/stdout/stderr are redirected....
<vila> parthm: which also means you can't put pdb breakpoints in the code run by the inner run_bzr
<parthm> vila: yes. i am using the blackbox tests. right now i just dump the info i need into a temp file but i think that a very crude way.
<vila> parthm: try to write whitebox tests instead :)
<parthm> vila: ok. thanks :)
<vila> parthm: they are generally far more precise and easier to debug too :)
<dcoles> jelmer_: Just to check I'm understanding you correctly with that bug, bzr serve --git _can't_ serve bzr branches? Only bzr-git ones?
<igc> hi vila
<vila> hi Ian
 * igc dinner
<jelmer_> dcoles: yes
<dcoles> jelmer_: Ah. OK.
<dcoles> Then my other bug was when you try and serve git branches in a shared repo
<dcoles> I'll make a working test and then report that.
<MvG> lifeless: I just read your comment about the news_merge plugin in https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045
<MvG> Hadn't known there was such a plugin. Does pqm make use of it? I assume it does.
<MvG> What got me worried was the fact that the launchpad merge preview reported conflicts. I guess this is difficult to avoid right now, because the per-branch configuration isn't versioned. So launchpad users would have to configure each of their branches, which requires a lot of UI and work.
<MvG> I think it would be better if one could configure the plugin in such a way that it works on all branches. To me that sounds like an application of the proposed .bzrmeta directory. Has this been discussed before?
<MvG> BTW: That config issue makes me think of another thing I've been repeatedly thinking about recently: handling of ZIP files.
<MvG> There is quite a number of file formats out there that are ZIP under the hood, but handled as a single document by some application, and usually have a file name extension other than ZIP. Examples are Microsoft OOXML, Google KMZ, Apple iWork formats, JAR files, and so on.
<MvG> I often would have wished for a plugin to handle these things as a single ZIP in a working tree, but as a directory of members inside the branch. I guess I'd wish for morege conflicts to cause directory layout in the working tree as well, until those conflicts are resolved.
<MvG> I don't have the time to implement this, but I'd still be interested in your opinion. Do you think this useful? Feasible? How would you want to configure such a plugin? Can you think of use cases likely to cause trouble I haven't thought of yet? Do you know of any efforts in that direction?
 * igc night
<dipnlik> hello, anyone here using zsh?
<MvG> dipnlik: not me, but I'm still curious why you're asking.
<dipnlik> MvG: i'm having autocomplete issues when i'm on a repository folder
<MvG> I'm the one maintaining bash-completion-plugin.
<dipnlik> cd ~/my-repo ; bzr st <tab> gives me an error
<MvG> I haven't looked at how zsh completion works, but I would assume that it should be possible to extens my plugin for zsh if there is need and some help.
<dipnlik> bzr: ERROR: Not a branch: "/Users/dip/my-repo/.bzr/branch/": location is a repository
 * MvG is looking at the zsh completion script right now.
<MvG> OK, the zsh completion works on file names, not only command arguments. In that case, sensible autocompletion is harder, and also slower because it usually requires a call to bzr.
<MvG> dipnlik: If the path only contains a repo and no branch or working tree, then running the status command, the only completion to "st" that I can see, doesn't make too much sense, does it?
<MvG> dipnlik: zsh does execute "bzr ls --versioned", which should give you the same error message.
<MvG> Of course, if you want to print the status of some file in some subdir, that would be a different thing...
<dipnlik> i'm on a repo with some branches on it
<dipnlik> i only wanted to autocomplete the branch name for the bzr ls command
<MvG> In my opinion, the zsh completion is either too clever, or not clever enough.
<dipnlik> that's what I think too
<MvG> For bash for example, I only complete command arguments, but not file and directory names, as for the latter the built-in completion tends to be better. Therefore this kind of problem doesn't occur with my bash completion.
<MvG> s/command arguments/command options/
<dipnlik> that's nice
<dipnlik> so, I think it's more a zsh problem than a bzr problem, right?
<MvG> I think it's a problem of whoever wrote the zsh completion script.
<MvG> Which seems to be Steve Borho in 2005.
<dipnlik> ouch >.<
<MvG> Judging from the log, the script is unmaintained since then.
<luks> isn't Steve Borho a TortoiseHG developer? :)
<MvG> The bash script shipped with bzr is in an equally bad shape, which caused me to write the bash plugin in the first place.
<MvG> luks: There is some evidence to that fact on the web, yes. Can't say I know, though.
<luks> yes, he is
<luks> so there is probably little interest in fixing the script :)
<dipnlik> MvG: any chance of a simple hack to at least avoid the error message?
<MvG> dipnlik: Sure: redirect errors to null in _versionedFiles: fileList=(${(ps:\0:)"$(bzr ls --null --versioned 2>/dev/null)"})
<dipnlik> MvG: i think I'll need more details to use that :(
<MvG> OK, dipnlik. All I have is a bzr source tree checkout, which contains a file contrib/zsh/_bzr which in turn contains the completion instructions.
<MvG> You should have a copy of that file somewhere on your system, probably in a path mentioned in $fpath.
<MvG> You need to find and edit that file.
<MvG> Lines 48-53 of that file describe a function _versionedFiles, where line 50 does a bzr ls invocation.
<MvG> After the --versioned but before the )"}) you insert a space and 2>/dev/null
<MvG> Then you restart your zsh, and see if things work.
<dipnlik> will try that, thanks a lot
<MvG> Out of curiosity: what makes you use zsh?
<dipnlik> trying it out of curiosity and because it fixes my main problem with bash: the command history
<dipnlik> let's say i have two bash tabs on terminal, one with tail something and other where I type all the commands I use
<dipnlik> if I exit the "main tab" then exit the "tail tab", all history on the main tab is gone
<MvG> dipnlik: "shopt -s histappend" should fix this for bash.
<dipnlik> zsh promises to do other things better, but for now it isn't really THAT better
<dipnlik> oh-my-zsh also makes some promises
<luks> MvG: oh, thank you for that!
<MvG> The histappend? I think it should be standard on any system. It is on Gentoo.
<luks> yeah
<luks> I always hated that it overwrote the file, but I just accepted it as a fact
<edakiri> I have a 'parent' directory magically appearing.  Is it from bzr?
<luks> appearing after what action?
<luks> it's not any stadnard bzr directory
<edakiri> i don't know.  i just made another new repo and it did not happen.  init add commit : are candidates.  You answered my question, I think.
<dipnlik> are bzr vs. git discussions allowed here? i'm still not that into any of these but git seems to be overly complicated
<jelmer> dipnlik: as long as they're discussions not flamewars :-)
<jelmer> dipnlik: we'd be happy to discuss the differences in features of both systems and the advantages/disadvantages
<dipnlik> jelmer: yay
<edakiri> has someone published/posted comparisons of efficiency scaling with history depth and repository size?  I know git did have trouble scaling to large repository sizes within a module
<dipnlik> i've seen comparisons and maybe git is technically better, but bzr is targeted for users, and that's a GREAT advantage
<dipnlik> problem is: "everyone" is using git :(
<dipnlik> so I don't know if I learn both or if I go with the flow
<MvG> dipnlik: There is a bzr completion script shipped with zsh (4.3.10 in my case) which seems to be different and slightly more up to date than that shipped with bzr itself. So maybe you should file a bug report with zsh, after ensuring your script actually comes from a plain zsh setup.
<MvG> lifeless: wrt my messages somewhere up there: just filed https://bugs.launchpad.net/bzr/+bug/546899
<ubottu> Ubuntu bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Undecided,New]
<dipnlik> MvG: i'm on zsh 4.3.9, which comes with OSX. edited /usr/share/zsh/4.3.9/functions/_zsh as you told me and it at least doesn't show the errors anymore, it helped a lot :)
<edakiri> dipnlik: have you seen comparisons of the scaling behaviour?  I'm thinking of a graph that shows how memory consumption and processing time vary with varying code size or history.
<luks> dipnlik: from my experience, most people from "everyone" that are using git don't *really* know how to use git
<dipnlik> edakiri: no I didn't, not really into which is better on the long run but since I'm only starting with version control and don't have big projects, that's not an issue for me (at least for now)
<dipnlik> luks: what do you mean? I think I want to *really* know how to use either git or bzr, just not sure which i'll definitely use
<dipnlik> also, github looks really great, maybe that is why "everyone" uses git
<luks> dipnlik: I mean that most people using git are using git just because it's popular
<luks> no any other reason
<dipnlik> luks: i'm using bzr because it seems it's easier but still not sure if I try to get used to git or not. what do you think?
<dipnlik> it's nice to use popular tools sometimes
<MvG> My biased experience on git vs. bzr: 1. git pickaxe approach for history examination is nice. 2. git having to add stuff before committing is annoying, but commit -a helps. 3. bzr commands are much closer to svn and therefore easier for newbies, I think. 4. bzr send feels much easier than git patch formatting stuff. 5. I like the clear distinction between repo, branch and working tree bzr offers, to each its own dir. That way you can have multiple bran
<luks> dipnlik: git allows you to very easily screw things up
<luks> dipnlik: other than that, it's not that bad
<dipnlik> MvG: 1 and 4. i've no idea /o\ 2. here on bzr i have to add new files before commiting 3 and 5. agreed
<luks> dipnlik: after you fully understand bzr, it should be easy to use git
<MvG> 2. only if they are new, not if they are just edited. The latter is much more frequent in most cases.
<dipnlik> MvG: ouch, adding edited files is weird. is there a good reason for that?
<luks> dipnlik: git uses a thing called 'index'
<luks> it contains changes that are meant to be committed
<luks> you can change a file, git add it, change it again but only the first version will be committed unless you add it again
<luks> git add is really very different from bzr add
<MvG> and diff compares indexed state to working tree by default, so after the add but before the commit, a diff without options shows you nothing.
<oly> hi, can someone explain this error / how i can fix it ?
<oly> bzr: ERROR: Revision {('filehandler.py-20100312144733-dlv7tjsgt7fubqdc-1', 'om@om-20100319173025-gugcm11qrsdlksij')} not present in "CHKInventoryRepository('file:///home/om/Ubuntu%20One/reprap/software/pyreplicator/.bzr/repository/')"
<MvG> oly: What command did you execute?
<oly> i well i tried a merge it said my tree was out of date so i tried a bzr update
<oly> and got that message
<MvG> oly: can you pastebin your whole session, starting at the first command causing the out of date error message?
<oly> http://pastebin.com/dKfL6323
<oly> theres not really anything to it though
<oly> is there a way i can force a merge it may overwrite what ever is causing the issue then
<MvG> oly: Can you also add the output of "bzr info"?
<MvG> oly: As far as I can tell, you are on a lightweight checkout, and the branch associated with that checkout was modified in some incomatible way since you created the checkout.
<oly> http://pastebin.com/LGzyJrch
<oly> could be, i do move between ubuntu lucid and karmic so the versions of bzr are likely different
<MvG> OK, my assumption was wrong.
<MvG> oly: I guess I'd first make a copy of that whole directory, just to be safe. Then I'd try to create a lightweight checkout of the branch head: "bzr co --lightweight . prhead" or similar. If that succeeds, I'd diff those two.
<MvG> oly: The diff should show you both differences in the working tree format, possibly caused by different bzr versions, as well as the differences you'd wish to commit.
<oly> hum it checked out okay
<MvG> oly: Passing -Derror to commit will print a back trace, which might give us additional information as to what revision it expects and why it isn't there.
<oly> diff pyreplicator/ /home/om/Ubuntu\ One/reprap/software/pyreplicator/
<oly> is that how i should do the diff ?
<oly> i usually use meld and am only comparing individual files
<MvG> diff -ur pyreplicator pyhead
<MvG> or prhead, or whatever you have named it.
<MvG> I'd be particularly interested in anything mentioning the .bzr/checkout subdirectory
<oly> is that on the new checkout
<MvG> It should exist in both places.
<MvG> And differences might be an indication of what's causing your error.
<bialix> jelmer: ping
<jelmer> bialix: hey
<bialix> heya
<oly> http://pastebin.com/M9RCxdAD
<bialix> jelmer: does bzr-svn supports tags a-la bzr tags?
<oly> does not look like theres anything noticably different other than the source files
<oly> which is why i am trying to commit them :p
<bialix> jelmer: see Bug 546906
<ubottu> Launchpad bug 546906 in bzr-scmproj "crash for svn branches" [Undecided,New] https://launchpad.net/bugs/546906
<bialix> jelmer: any suggestion how I should fix this in scmproj?
<jelmer> bialix: yep, it does
<bialix> jelmer: apparently other_branch.tags.get_tag_dict() where other_branch is svn://xxx does not
<dipnlik> well, i'm leaving, thanks a lot for the help everyone, i'll stick with bzr and bzr-svn :)
<jelmer> bialix: only if you have a branch layout for which it is not known where the tags should be
<bialix> jelmer: oh
<bialix> jelmer: cause Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['trunk/libavcodec'],[])
<bialix> that's it?
<jelmer> bialix: TrunkLayout(0) puts all tags in tags/
<jelmer> bialix: for a custom layout it's not known where to put the tags
<bialix> jelmer: so... maybe I just should catch that error and suppress it?
<MvG> oly: Those u1conflict files look suspicious to me.
<MvG> Any idea where they might come from? How do they differ from those without the .u1conflict extension?
<oly> okay, i dont think there in the repository at leat they should not be
<oly> there cause when there is a sync error between my two computers
<oly> they are generally the same file but a different version that did not sync
<MvG> oly: I guess some such sync error garbled your working tree or branch.
<jelmer> bialix: it depends on what you're trying to do :-)
<oly> ah, i did wonder if it could be todo with the file sync
<jelmer> bialix: if you're pulling from that branch, I would just ignore the tags
<MvG> oly: Safe thing would be, clone your branch and apply the source tree diff manually, without touching the .bzr dir.
<bialix> jelmer: I'm checking if I need to pull first
<oly> okay or maybe easier, can i just revert to the online copy ?
<oly> and hit save in my editor again for the newer versions and then commit ?
 * bialix waves at amanica
<amanica> hi bialix :-)
<bialix> hi dude
<MvG> oly: Revert to online using "pull --overwrite" might work, but I'd not feel as sure with that.
<oly> okay, will have a play see what else i can break :)
<MvG> oly: In my experience, synchronization of bzr branches using other sync tools is a bad idea. Didn't work out for me with unison either. Sooner or later you happen to modify things at one end but forget the other, and then a file-based sync easily breaks stuff. I'd suggest synking using bzr pull instead.
<MvG> I meant modify at both ends and forget to sync in between.
<oly> okay,
<oly> yeah i asked some one about it a while ago if it was likely to cause problem they suggest it would be okay
<oly> but apparently not :p
<MvG> is should be if you keep things strictly sequential, but that's hard.
<oly> yeah, anyway fixed
<oly> i had a better idea
<oly> move the .bzr folder to tmp, then copy the .bzr from a newely checked out copy
<oly> then run the commit :)
<MvG> That's fine.
<oly> simple and seems to work which is what i like :)
<MvG> When a merge proposal into bzr.dev was reviewed "Needs Fixing" by one person and has status "Needs review", do I have to resubmit the proposal after fixing the issue, or should I simply wait?
<MvG> https://code.launchpad.net/~gagern/bzr/bug513322-first/+merge/22045 in particular.
<oly> Thanks for the help by the way MvG :)
<MvG> np
<Peng> Um...I'm not sure. You can push again and the merge proposal will be magically updated.
<Peng> You can also file a new merge proposal, and that will magically handle everything too.
<MvG> Peng: thx. I noticed the magic update. I guess I'll wait a while, see if waiting is enough. After all, "Needs Fixing" sounds less problematic than "Resubmit", which is a possible review comment as well.
<Peng> Is it a bug that urlutils.local_path_from_url barfs on a "readonly+file://" URL?
<bialix> Peng: I don't think it's the correct URL to use in local_path_from_url
<bialix> readonly+ is the prefix for bzr transport
<Peng> Ohh?
<Peng> Hmm.
<Peng> Do readonly transports have a copy of the URL without that prefix, then?
<Peng> Plus, IIRC the prefix is kept in Branch.base.
<bialix> Peng: IIRC readonly transport is the wrapper for plain transport
<bialix> so yes, there should be copy of URL w/o readonly+ somewhere inside
<MvG> jam: Do you think I should mark bug 546899 as affecting PQM as well?
<ubottu> Launchpad bug 546899 in launchpad-code "Use news_merge plugin for launchpad merge preview" [Wishlist,Triaged] https://launchpad.net/bugs/546899
<jam> MvG: reasonable to do so, I'm not really sure what would be done about it
<jam> it is more that bzr's pqm setu
<jam> it doesn't really affect bzr-pqm itself
<jam> so on second thought
<jam> maybe add bzr
<jam> but don't add bzr-pqm
<MvG> Hmmm... hadn't known there was a bzr-pqm in addition to "plain" pqm... :-)
<jam> ah, sorry
<jam> pqm is the robot
<jam> bzr-pqm is a plugin to submit to the robot
<MvG> And the robot should be the more likely one to complain about broken news, right?
<MvG> s/broken/conflicting/
<jam> regardless, adding 'bzr' might be reasonable, but it is probably more of a sysadmin thing than a bug in the program itself
<MvG> There is no sysadmin subproject, is there?
<MvG> Come to think of it, it already DOES affect bzr, because news_merge is part of the bzr.dev source tree.
<jelmer> jam: hi
<jelmer> jam: So, BtreeIndex seems very slow adding new entries after ~200k entries
<Peng> 200k entries? Are you doing something evil? :D
<jelmer> I would never do evil things.
<Peng> You use libsvn. :P
<jelmer> So does Google.
<jelmer> And Google doesn't do evil.
<jelmer> Ergo, I don't do evil.
<jelmer> QED :_P
<Peng> Ah! Your logic is flawless.
<hazmat> hmm.. trac-bzr performs just as poorly as loggerhead on large repos
<hazmat> worse actually
<mwhudson> the cache isn't just there because i'm an idiot :)
<hazmat> mwhudson, its interesting to see how performant bzr can be for a web ui without building a complete secondary index
<mwhudson> hazmat: the biggest problem is revision numbering
<hazmat> mwhudson, i've disabled the dir ancestry stuff (dir rev appears as latest of contents), and  i'm running it through repoze.profiler atm...
<hazmat> mwhudson, yeah.. i think thats what i'm seeing now.. still not 100% though
<MvG> hazmat: what version of trac-bzr?
<hazmat> MvG, trunk, with trac 0.11.7
<hazmat> trying it out on the launchpad repo
<hazmat> 110k revs it looks like
<hazmat> page loads are about 10s when it touches bzr
<jam> jelmer: the code dumps data to disk
<jam> you can look at the builder parameter "dump keys at"
<MvG> hazmat: OK, thats a large number of revisions for sure. What page are you referring to?
<mwhudson> hazmat: there is this bzr-historycache plugin that might help
<hazmat> MvG, mostly any browser pages below the root.. but the timeline also but thats mostly because theirs a few k changesets in the last 30 days.
<hazmat> mwhudson, my end goal is to see if bzr can do a fast web interface, the first thing i'm trying to reason is if a cache is required for that
<MvG> hazmat: OK, in browser my first bet would be dir revision calculating, but assuming you deactivated all effects of that, conversion of revids to dotted revnos is my next best bet.
<mwhudson> hazmat: ok, i can tell you that you will have a problem with revision numbering for off-mainline revisions without some kind of cache
<MvG> hazmat: My current belief is that it is, but in many scenarios a in-memory cache would suffice.
<lifeless> igc has a plugin for that
<hazmat> MvG, yeah.. mwhudson mentioned that as well.. it does appear to be that (revid->revno mapping)
<MvG> lifeless: caching those revs?
<jelmer> jam: Thanks
<jelmer> jam: I tried to reproduce it with a trivial script but I can't for some reason :-/
<MvG> hazmat: If you want to dig closer into improving trac-bzr using caches, we should have a longer talk.
<MvG> I've spent some time already thinking about how I'd do this, what kind of info I'd whish to cache, and what kind of features that'd allow for trac-bzr.
<hazmat> MvG, if it can't work without caches, i'm going to try and spend time on improving loggerhead, i'm definitely up for the discussion though
<jelmer> jam: Also, I'm interested in looking at using bzr-based formats for bzr-svn
<jelmer> jam: basically something like the revisions VF together with some bzr-svn specific indexes, how would I go about doing that?
<lifeless> MvG: yes
<jam> so, it depends
<jam> I'm working on refactoring the code to do something like that for annotations
<jam> so if you're willing to wait, it should be easier
<hazmat> mwhudson, MvG as you both suggested, its definitely the string_rev (6s, 2.5s on two of the calls), although one of the calls to get_changeset also takes 2.5s.
<jelmer> jam: I'm happy to wait
<jelmer> jam: This is intended for 2.3 ?
<MvG> My current idea is three caches, most easily explained in terms of relational database tables.
<MvG> One would be for the whole shared repo, and contain one line per revision. With date, revid, maybe some internal primary key, parents.
<MvG> Second would be per branch, with dotted revno, merge point, next rev on path to that merge point, index in the order "bzr log -n0" would print it.
<MvG> Third would be for dirs, in order to determine svn-style last modifying revisions. For this I'd order revisions in a tree, with full fileid to revid mapping only for power of two history length, and relative information for others, to keep the amount of data down.
<MvG> Both the well-defined "next" (child) revision and the "dir last modified" revision info are highly svn-like, but I think it useful nevertheless.
<jam> probably in the 2.2 series
<jam> b1 is only this week
<lifeless> MvG: 'what revs a fileid is present in' should be answerable pretty fast from 2a repos
<MvG> lifeless: using what API?
<lifeless> the chk maps; probably not well exposed today.
<MvG> Because what trac-bzr does right now already looks painfully slow
<hazmat> so just using revid, and sans the svn:style dir revs,  the performance is passable.. genshi floats to the top in the profiler now ;-)
<MvG> lifeless: can you give me a fully qualified name pydoc will accept?
<lifeless> MvG: bzrlib.inventory.CHKInventory
<MvG> hazmat: So there is hope still. :-)
<lifeless> MvG: its not a trivial thing; I'm saying that our core db format should be ok at this point
<lifeless> so there will be somethinking needed
<lifeless> and api improvements to show it 'publically'
<Peng> MvG: Loggerhead could use the same thing.
<MvG> Peng: Loggerhead is already making massive use of caching.
<mwhudson> <MvG> One would be for the whole shared repo, and contain one line per revision. With date, revid, maybe some internal primary key, parents.
<mwhudson> MvG: no point caching that, get_revision is plenty fast
<Peng> MvG: Yes but it sucks. :D
<MvG> And I found the implementation there so unreadable that I decided not to copy it to trac-bzr.
<Peng> MvG: Exactly!
<MvG> mwhudson: The initial string-based lookup already feels wrong, I'd have expected faster access using e.g. a 64bit internal identifier. But maybe I'm wrong here.
<mwhudson> MvG: bzr has pretty efficent code for mapping strings to "stuff"
<MvG> Another thing to note is that for the dir to rev cache, I'd need to store for every revision the appropriate ancestor relative to which differences are noted.
<mwhudson> sure, some kind of hyperoptimized binary data type key value store might be faster
<mwhudson> but not much and not enough to be worth the pain of keeping the cache up to date imho
<MvG> So that's one more item to store with each rev, not branch-dependant, and not suitable for the main bzr repo.
<MvG> Or do you know of an efficient API to 1. tell me the history length of a given rev and 2. find a preceding history element with a given history length?
<MvG> lifeless: Looking at CHKInventory, I realize that 'what revs a fileid is present in' is not the question I'm asking.
<lifeless> MvG: what quewstion are you asking?
<MvG> Rather this: Given revision r, what's the latest element in the history of r where the dir d looks like it does at revision r, i.e. all files had the same contents, names and so on. And for that mainline revision, is there a sideline revision where it already looked the same as well, and if so, recurse down that sideline, until I get to the earliest revision that made the dir what it is today.
<MvG> s/latest/earliest/
<MvG> and "today" only if r is the tip, otherwise "what it is in r".
<MvG> The problem is that I have to deal with multiple revisons of multiple files, which scales badly.
<hazmat> basically you want the latest rev of the children of a directory at a given rev
<MvG> One solution is walking history, looking at deltas, see when things were last modified. The other is looking at last modifications of files and trying to relate them via the graph. Neither is really cheap.
<lifeless> MvG: you can paraphrase that as 'find the end of the subgraph with the closest (topologically speaking) changes to any fileid under (d,r)'
<MvG> lifeless: To get the semantics clear: do you mean the "subgraph of changes" and the "end which is topologically closest"?
<lifeless> subgraph of the revision graph
<lifeless> bzr doesn't store changes
<lifeless> and yes to the second question
<lifeless> anyhow, I've speculated in the past about having a 'subtree revisionid' as well as the 'this item changed' revisionid on directories.
<MvG> lifeless: Still, it's not it. If I branch, modify one file on one graph and another file on another graph, then merge the two, then I want the merge, even as it touches neither file, because only the merge makes the dir what it is.
<lifeless> we don't have one today; such a thing would be a) constant, b) derivable
<lifeless> MvG: you would get the merge under the definition I offered
<MvG> The I still misunderstood the definition... let me have another look, it's getting late here...
<MvG> With "subgraph of changes" I meant the subgraph by taking only the nodes that contain changes to a subtree. Was that your intention?
<lifeless> no
<lifeless> subgraph of the fullgraph
<MvG> Restricted on what criterion?
<lifeless> having the same contents of the subtree
<MvG> Ah!
<lifeless> conversely, the adjacent revisions must change the subtree
<lifeless> Anyhow, this is something that you could cache.
<lifeless> but I'd try to build a fast implementation of it first; if only so that your cache loading will be efficient :P
<jelmer> jam: ah, cool
<MvG> I know how to derive this informations by walking all deltas. That's the incremental way to do things, in contrast to recursing on directory tree structure from files to the root.
<jelmer> jam: Is there anything I could play with yet?
<MvG> But deltas feel more expensive than I would like. How expensive are they, when I don't actually calculate text differences, but just request the list of touched files?
<jam> jelmer: it is still pretty early, but the code is up at lp:~jameinel/bzr/2.2.0b2-pack-collection
<jam> and eventually lp:~jameinel/bzr/2.2.0b2-contained-pack
<jam> It is pulling the "PackCollection" out of "RepositoryPackCollection"
<MvG> What has me worried is the amount of data. Every commit would change the revid of the root. In most projects most commits would touch the src subdir. That's a lot of modifications, which made me think of this tree organization.
<Mez> btw, I'll be (as long as it's approved) doing an "introduction to bzr" in a future Linux Format :D
<lifeless> MvG: deltas are very fast
<lifeless> MvG: we can walk 30K in a few seconds
<MvG> Glad to hear that, then I'll be using those.
<lifeless> specifically iter_changes
<lifeless> there is a repository api to do iter_changes of many revisions
<MvG> I plan to make the trac-bzr caching highly modular, to separate data generation from data access from data storage, and all of these from the rest of trac-bzr. Maybe that way parts of it can be useful to others as well, in a plugin to be shared with loggerhead or who else might be interested.
<meoblast001> hi
<MvG> The only thing I now need is a lot of free time to implement this, which I don't currently have.
<meoblast001> with fast-export, how does one string a file/directory from a tree?
<lifeless> MvG: make the bits bzr plugins then, IMO
<lifeless> AfC: btw, 'bzr revert' in an svn checkout does what 'bzr revert' in a bzr branch would do
<lifeless> AfC: you signed off too fast the other day, but I was about to answer your question with 'bzr revert' :P
<AfC> lifeless: sure. I'm not using bzr-svn though, but thanks
<MvG> lifeless: dunno. AT least for trac-bzr development, having them as part of that code base is easier, and avoids having to deal with a possibly misisng plugin. But I'll keep a bzr plugin future in mind, to ensure it can be moved one day.
<millun> hi, just wondering... first time with Bazar explorer.... initiated a project... for a php thing in ~/work/bzr/tr. should i move there content of /var/www/tr/ or ../www/tr/* ?
<dvheumen> hey lifeless, got a question for you for the high level locking hooks
<lifeless> dvheumen: shoot
<dvheumen> well, I'm wondering if there's any way to find out if a lock that's already active is a read or write lock. I'm kind of lost in the lockable_files/lock_dir and all the locking mechanism directly or via transport
<lifeless> dvheumen: so lockable_files are always write locks
<lifeless> dvheumen: read locks don't have a lock object
<dvheumen> okay ... let me have a look at the code to see if that's all I needed ...
<lifeless> but most importantly
<lifeless> Branch etc always know what sort of lock they have
<lifeless> queryable via e.g. is_read_locked() and is_write_locked()
<dvheumen> I cannot find is_read_locked anywhere, and is_write_locked is only available for repository ... (or I'm grepping the wrong way ...)
<dvheumen> anyways, maybe it's good to give you some context: I'm trying an initial implementation of the hooks in classes MutableTree, Branch and Repository. And I was working on triggering the callbacks on lock_{read, write, tree_write} and that's not too difficult. But for unlock and break I need to know whether I am breaking a read or a write lock, so how would you go about this?
<dvheumen> lifeless: ^
<lifeless> dvheumen: why do you need to know ?
<lifeless> dvheumen: and secondly, you know, in unlock, what the lock type was
<lifeless> dvheumen: within each object type,t hat is.
<lifeless> dvheumen: as for break, you can't break a high-level locked object anyhow, it always refers to a stale disk lock
<dvheumen> lifeless: I was planning on reporting the type of lock during the triggering of the callbacks
<dvheumen> okay, so there's no (sensible) thing as a broken lock hook for high level locks?
<lifeless> well, there may be, but its not part of the lock/unlock sequence
<lifeless> in aprticular there isn't a break-lock for read locks.
<poolie> hello all
<dvheumen> okay, so I'll scratch that.
<dvheumen> hi
<lifeless> dvheumen: as for the type - check the details of e.g. RemoteRepository.unlock
<lifeless> dvheumen: you can see it knows the lock type
<GaryvdM> Hi all
<dvheumen> yeah I've seen the _lock_mode for repository before. And I now discover that there is peek_lock_mode for Branch
<GaryvdM> I'm looking for info on the different exit status that bzr returns.
<GaryvdM> I've greped the docs, and googled, but not found any thing.
<GaryvdM> From testing: 0 = success
<dvheumen> lifeless: okay, I think it's clear. Do you think there's any value in returning the LockResult instance that is used for the low-level lock hooks? (At least, I think it's still available, but I don't think it makes much sense.)
<lifeless> no
<lifeless> a) SvnRepository etc won't have them
<GaryvdM> 1 = has diff (from diff)
<lifeless> b) not all Bzr repos have them either
<dvheumen> aha okay
<lifeless> dvheumen: peek_lock_mode probably isn't what you want
<GaryvdM> 2 = result has conflicts
<GaryvdM> 3 = error
<GaryvdM> Any thing I'm missing?
<dvheumen> lifeless: isn't it? What's wrong with peek_lock_mode? I have seen that sometimes control_files are shared with the repository, but then the locking mechanism is shared too right?
<lifeless> dvheumen: they don't track read locks
<lifeless> dvheumen: in the general case
<lifeless> dvheumen: uhm, that said - whatever works
<lifeless> we haven't managed to delete self.control_files yet.
<verterok> lifeless: hi, I'm tetsing xmloutput with latest bzr.dev, and I'm getting a bunch of this errors: http://pastebin.ubuntu.com/401439/ any ideas?
<GaryvdM> bla - I was looking in the wrong place. Found some of what I was looking for @ bzr help diff
<verterok> *testing
<dvheumen> okay, well, I think that's enough info for me to continue with (some) implementation of the hooks. Is there any documentation on locking? (because I couldn't find much)
<lifeless> verterok: thats fun
<lifeless> verterok: I haven't been tracking bzr closely recently, so I can't really comment. poolie ^ ?
<verterok> lifeless: :)
<lifeless> verterok: AFAIK there is still only one branch reference around
<verterok> lifeless: ok, I can poke vila, as this is tests stuff ;)
<lifeless> so its got to be some sort of bug/regression in the way you're using bzrlib - unintentional I presume.
<verterok> thanks
<verterok> lifeless: found the problem, target_branch is now a kwarg :)
<lifeless> did we move its position ?
<lifeless> if so thats an api break, if we haven't done a stable release with the change we can fix it
<dash> oh jelmer
<dash> a checkout made using bzr-svn is exhibiting the behaviour described in #380069
<dash> would you like me to do things to figure out what happened? :)
<dash> i'm using bzr 2.1 and bzr-svn 1.0.2
<dash> hup! too late. I did bzr up in another branch in the same repo and the problem went away.
<verterok> lifeless: looks like it was moved. revno 5085
<dash> that's really annoying.
<verterok> lifeless: hmmm, sorry it was a kwarg, but now a new kwarg is before it
 * verterok brb
<lifeless> verterok: yes thats a move
<lifeless> verterok: file a bug, and a patch please!
#bzr 2010-03-26
<dOxxx> good evening
<poolie> lifeless, could you please aswer https://answers.edge.launchpad.net/bzr/+question/105503
<poolie> spiv, hi
<poolie> spiv, is there a bug tag for per-file merge configuration? maybe there should be
<igc> morning
<poolie> hi igc
<dOxxx> poolie: any idea why bzrlib.urlutils doesn't use python's urlparse.urljoin but rather rolls its own?
<poolie> not off hand
<poolie> but most likely is that the python one is buggy, or was buggy in python2.4
<poolie> second most likely is that it should but doesn't
<poolie> should use it but doesn't
<poolie> there should be a comment either way
<poolie> all, lifeless: what do you think of, in the context of <https://answers.edge.launchpad.net/bzr/+question/102562> just not repacking pack files that are already fairly large (say 500MB)
<Peng> Maybe have an option for it? :D
 * Peng ducks.
<poolie> yes, it would make sense to have an option with a default
<poolie> igc do we still need to talk about the windows installer-building vm?
<igc> poolie: yes
<poolie> here or the phone?
<igc> here's fine
<poolie> so basically i suggest you make a snapshot using their web console
<igc> poolie: I'd like to try building a 2.0.1 installer this morning
<poolie> that would be great
<igc> I still need to fix bug 534548 first
<ubottu> Launchpad bug 534548 in bzr-windows-installers "Bzr Error: missing sqlite library" [Undecided,New] https://launchpad.net/bugs/534548
<igc> I'm working on that now
<poolie> ok
<poolie> so you were asking the other day if it's ok to reboot it
<poolie> and aiui it's fine to reboot, but if you halt that instance will go away
<poolie> and you will lose its state
<igc> poolie: "halt?"
<poolie> shutdow
<poolie> shutdown*
<igc> poolie: ok
<dOxxx> poolie: re urlutils and why it doesn't use urlparse.urljoin, it seems that the python module doesn't throw errors and doesn't make it easy to detect when updir segments ('..') go above the root
<dOxxx> for instance, urljoin('.', '..') produces '/'
<dOxxx> sorry I meant urljoin('/', '..')
<poolie> right
<dOxxx> I'm wondering how important it is to detect that particular case
<dOxxx> and apparently it doesn't like joining 'lp:foo' with 'bar'... it just produces 'bar', which breaks the appendpath stuff :P
<dOxxx> perhaps I could use urlsplit and do my own join logic...
<spiv> dOxxx: the chroot functionality at least depends on those errors
<spiv> dOxxx: what are you trying to do, btw? :)
<dOxxx> spiv: trying to fix bug 534787
<ubottu> Launchpad bug 534787 in bzr "pull does not understand lp: URLs in branch.conf" [Medium,In progress] https://launchpad.net/bugs/534787
<dOxxx> I already have a somewhat crude fix for it
<dOxxx> but poolie suggested I fix the url joining instead
<poolie> so i do think urljoin('lp:foo', 'bar') should give lp:foo/bar
<spiv> Yeah, that would be good.
<dOxxx> poolie: oh for sure. it just means I can't cop out just calling urlparse.urljoin ;)
<spiv> I wonder if for this particular bug we ought to be doing the directory-service lookup before joining the relative dir to it?
<spiv> Oh, btw, urlutils.join('lp:foo', 'bar') already gives lp:foo/bar
<dOxxx> spiv: yes, I was referring to the python urljoin
<spiv> Although by accident, I suspect :)
<spiv> (Yep, by accident, compare urlutils.join('lp:foo', '../bar'))
<dOxxx> ouch
<dOxxx> yeah there are some pretty magical expectations of this function :P
<spiv> The directory service concept hasn't really been fully integrated yet.
<dOxxx> when I run bzr selftest, I get the errors and failures printed out twice...
<dOxxx> the second time in a slightly different format
<lifeless> poolie: we should repack large packs
<poolie> in constant memory
<SamB_XP_> poolie: at most linear, anyways
<poolie> um
<SamB_XP_> but yeah, constant is nice too
<poolie> it's easy for people to get bigger pack files than will comfortably fit in ram
<SamB_XP_> true
<poolie> so ok, it can be linear as long as a<1
<lifeless> poolie: thats fine, we don't buffer the pack on a repack
<lifeless> memory use to repack is made up of:
<SamB_XP_> just ignore me
<lifeless>  - index data
<lifeless>  - current gc compressor state
<lifeless>  - read-cache from the source packs
<lifeless> if someone is seeing a memory spike during a repack, its most like that they committed an ISO
<lifeless> because of the forth element:
<lifeless>  - current object being inserted
<SamB_XP_> forth uses very little memory!
<lifeless> oh, there is also a 1MB write buffer, but its approx constnat
<lifeless> we expect packs to grow to many multiples of main memory
<SamB_XP_> so, yeah, that probably *is* linear with a<<1
<lifeless> that said, the main thing we want to do is combine packs to reduce linear lookup growth, a big pack with one commit in it is certainly something we could leave for a while, but thats a matter of tuning the 'what packs should we combine' to choose them a little later, rather than excluding large packs from that algorithm
<poolie> lifeless: there have been a spate of out-of-memory during commit of small things
<poolie> at least some are due to repacking
<lifeless> poolie: due to, or occuring during
<lifeless> ?
<lifeless> poolie: because I don't think that that is the same thing at all
<poolie> occurring during
<lifeless> what that primarily says to me is that they probably don't have enough memory on their machine to work on that project - I'd expect random 'diff', 'log' and other commands to fail on that repository too
<lifeless> though there may be a bug in the slab cache
<lifeless> we may want to investigate that
<lifeless> and related to that we might want to handle an OOM error by dropping all related caches and retryinh
<poolie> yes, but that isn't what seems to be happening
<poolie> (*) i have not systematically checked all the reports
<lifeless> what seems to be happening then ?
<lifeless> should we do voice for this; sems to be quite a drawn out conversation
<dOxxx> seeya guys
<poolie> lifeless: let's not bother until we actually start on it; it was just a random thought
<quotemstr> Is there anything wrong with running, in a branch, bzr log -r ../trunk ?
<quotemstr> Ah, I want bzr log -rancestor:../trunk right?
<spiv> quotemstr: yeah, probably
<spiv> Or perhaps "bzr missing --mine ../trunk"
<quotemstr> Thanks!
<spiv> Or maybe "bzr log -rsubmit:" will do the same thing for you with less typing :)
<spiv> (if ../trunk is the submit branch)
<quotemstr> Ah, I see. Is it normal for that to print out just one commit?
<spiv> Well, if there's just one commit in your branch that isn't in ../trunk, then yes.
<quotemstr> Ah! .. :-)
<fullermd> Yes, because you're only asking for one rev.  If you want a range, you want to say a range (e.g., "-rsubmit:..")
<quotemstr> -rsubmit.., that is.
<spiv> Oh, right.
<spiv> My bad :)
<fullermd> (which is short for -rsubmit:..-1)
<quotemstr> Hrm, it's still running.
<quotemstr> Okay, this is getting more complicated than I thought. I have a branch that's a little stale with respect to the trunk. I've done some feature development on it, but also backed out a change from the trunk that was causing a bug. In the log, that backing-out is marked as a merge. To merge from the latest trunk, I need to undo that backing-out of the bug so the trunk's bugfix will apply correctly.
<quotemstr> So how do I undo that particular entry? I don't see any functionality in bzr merge for unmerging, as it were.
<spiv> quotemstr: you can pass a backwards revisionspec to merge
<quotemstr> Right, but the revisions are with respect to the trunk I'm trying to merge from.
<spiv> quotemstr: e.g. "bzr merge -r 101..100 ." will reverse the changes in revision 101
<Peng> If you merged revisions, they're in the local branch too, even if "bzr log" collapses them by default.
<spiv> quotemstr: so the situation is that at some point you did "bzr merge ../trunk; bzr revert [some files]; bzr commit" on this branch?
<quotemstr> spiv: Exactly. The changelog for the commit after the revert is "revert cc-mode breakage from revision 98938" :-)
<quotemstr> spiv: But there are lots of changes I made after that revert.
<spiv> Right.
<quotemstr> Should I just manually grab a diff from the trunk, apply it with patch(1), then commit that?
<spiv> Hmm, perhaps a second branch would be easiest:
<quotemstr> (For revision 98938, that is.)
<spiv> bzr branch -r [just-before-back-out] . ../before-back-out; cd ../before-back-out; bzr merge ../trunk; bzr commit -m 'merge trunk'; bzr merge -r [back-out-rev] ../feature; bzr revert .; bzr ci -m "Undo backout"; cd ../feature; bzr merge ../before-back-out; bzr ci -m "Un-revert cc-mode breakage from revision 98938."
<spiv> There's probably a less convoluted way to do that. :)
<fullermd> First, you fast-export and import it into monotone...
<spiv> fullermd: hah
<fullermd> Having update -r in base now, it's probably conceivable that a commit-daggy could be implemented as a plugin.  Would only really work for single-commit fixes, but...
<spiv> Hmm, maybe could use shelve rather than a second branch, something like "bzr up -r [before-back-out]; bzr merge ../trunk; bzr shelve --all; bzr up; bzr unshelve"
<quotemstr> Wouldn't that re-apply the backing-out of revision 98938?
<spiv> Maybe I'm being overly general...
<spiv> Is it literally that you wish to reapply the changes in trunk -r98938?
<spiv> If so, just "bzr merge -c98938 ../trunk" would work, I think.
<verterok> hi! I would really appreaciate some help with a 'log' (actually a xmllog) test :)
<quotemstr> Ideally in a way that will make the revision disappear from history, but that works too.
<spiv> To make revisions disappear from history you'd need to generate a new history (e.g. using the bzr-rewrite plugin)
<quotemstr> Scratch that then. I'll try merge -c. :-)
<spiv> verterok: tell us more! :)
<verterok> spiv: :) I would like to create the history specified in this bug: https://bugs.edge.launchpad.net/bzr-xmloutput/+bug/517937
<ubottu> Ubuntu bug 517937 in bzr-xmloutput "bad XML in fringe case" [High,Confirmed]
<lifeless> branch builder
<quotemstr> Hrm, all that does is say that it modified a ChangeLog, and even that is an empty diff.
<quotemstr> I'll try the separate branch approach.
<verterok> lifeless: ooh, nice! (xmloutput log tests are quite outdated)
<poolie> igc, so is everything good on desolation now?
<quotemstr> Anyway, merge -c worked fine.
<quotemstr> I just had to specify [backout-revision] instead of the original revision from the trunk.
<igc> hi poolie
<poolie> hi there
<igc> poolie: I've build a 2.1.1 installer that I'm downloading and testing
<igc> built
<igc> poolie: next on the list is to build a 2.0.5 installer set
<igc> poolie: then it's back to sorting out the new build scripts and working out why buildout is grumbling about stuff
<vila> hi all !
<MvG> Are help topics expected to be restructured text?
<lifeless> MvG: yes
<MvG> I found out that the command line output has plain=True unconditionally, which might cause some reformatting, which might explain why "bzr help configuration | rst2html.py" may result in errors, I guess.
<lifeless> I wouldn't expect bzr help configuration | rst2html.py to work
<MvG> I did, because the thing looked close enough to rst, but seeing that there is a a plain argument to the help text formatting method, I'm not surprised any more.
<MvG> I wonder whether a --rst option to bzr help might be a good thing, though.
<MvG> And a "export to temporary html and open in browser" as well, while we are at it.
<MvG> The latter could be a plugin, though.
 * xnox gcc svn trunk import on launchpad 98077 out of 99076 revisions done =) can't wait
<ubottu> Launchpad bug 98077 in zope3 "No title ?fixme?" [Medium,Invalid] https://launchpad.net/bugs/98077
<xnox> ubottu, you are being silly =)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<meoblast001> hi
<meoblast001> how do you use fast-export to strip a directory and its files from a tree?
<meoblast001> i tried bzr fast-export ./ | bzr fast-import-filter -x plugins/ > ../cnitrobot.fi but i got a broken pipe error
<edgimar> can someone explain the pull --remember option?  I tried doing 'bzr pull' recently from a repo which I had previously checked out via 'bzr checkout --lightweight URL', and I was given an error "Not a branch: PATH" where PATH was something I had not set.  Doesn't it make sense to use URL as the path automatically?
<edgimar> (PATH pointed to some local directory on another person's computer)
<fullermd> If you're in a checkout, pull probably isn't what you want to do.
<edgimar> So my question:  how does it all work?  what is the logic behind requiring --remember?
<edgimar> fullermd, what should I have done?
<fullermd> You probably want 'update'.
<edgimar> and update will pull the latest changes from the remote repository?
<fullermd> Pull is for updating the branch.  The branch in this case is that thing you checked out, so 'pull' is using the saved parent from it, which probably doesn't make sense when interpreted from your machine.
<edgimar> I think it might just be a terminology problem for me -- in mercurial, "update" is just a local operation which changes the revision of the working directory -- what is the equiv in bzr?
<fullermd> Same thing.
<fullermd> That's what you're trying to do; update your working directory to match the branch.
<edgimar> What I mean by 'local operation' is that there is no network activity required at all.
<fullermd> There would be if the branch were across the network.
<fullermd> But mercurial doesn't swing that way.  bzr can, when you ask it to (which you did)
<edgimar> Ok -- so the branch in bzr can be stored locally or remotely, I take it?
<fullermd> In bzr, your working tree, branch, and repository can each be in [at least somewhat] arbitrary locations relative to each other.
<fullermd> In your case, you did a checkout, so all you have locally is a working tree; you don't have a local branch.
<edgimar> So, working tree= a directory corresponding to 1 revision.
<fullermd> I guess that would be one way of saying it.  Working tree == the files you fiddle with.
<edgimar> But I'm confused if branches and repositories are somehow distinct from each other -- I figured that after you've specified a repository, then that intrinsically includes the branches associated with that repository ?
<edgimar> (specified the location of a repo)
<fullermd> Not really.  You almost never talk about a repo directly; you talk about a branch.
<edgimar> then what technically is a repository (or how does it differ from a branch)?
<edgimar> (or relate to a branch)
<fullermd> A repository is what stores revisions.  A branch defines a set of revisions interesting in a particular context (i.e., a "line of development")
<fullermd> It's useful to separate the two concepts because you often have multiple branches that share [some,most,all] history, and if the repo couldn't be considered independently, you'd be storing multiple copies of that.
 * fullermd really needs to knuckle down and polish his docs on the matter   :(
<fullermd> <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/core_concepts.html>  gives some overview.
<edgimar> right- from mercurial, I get the concept of branches.  While it is possible to clone a specific branch of a hg repository, oftentimes one clones the entire repository and can then work on whatever branch one pleases.
<edgimar> But in bzr, it's not possible to clone an entire repo?  Or people usually just clone / checkout branches?
<fullermd> I'm fuzzy on mercurial.  It seems like they sorta use clones as branches, except when they use named heads as branches, except...
<fullermd> But no, aside from making them and occasional special things, you never address or talk about repositories directly in bzr.
<fullermd> You just talk about branches, and a branch finds its repository (either internally private, or externally shared) as necessary.
<fullermd> bzr's "clone" command is just an alias of "branch".
<edgimar> fullermd, ok- so when you do 'bzr branch' it duplicates a branch (the associated history of a branch).  But when you do 'bzr checkout', it just gets a specific revision, and an associated branch-name/source is somehow connected with the checkout?
<fullermd> Mmm.  That's...   that's probably not _wrong_ per se, but I think it's a wildly confusing way of thinking about it.
<fullermd> To compile your program and read files and make changes and make new commits, you need a working tree to do that in.  Checkout creates a working tree for a given branch.
<fullermd> bzr makes no inherent distinction between that working tree being colocated with the branch (as you get after a 'hg clone'), and the WT being somewhere completely different, on teh same system, or across a network.
<fullermd> (this also implies you can have multiple WT's on a single branch at once, leading to a setup and workflow much like using CVS/SVN)
<fullermd> The WT, among its metadata, has a pointer saying "hey, that there is the branch I'm a WT of".
<fullermd> So when you do operations that touch the branch, like commit, or log, etc, it knows to go look there.
<fullermd> (the branch in turn knows where its repository is, and goes there to save or retrieve revisions)
<fullermd> When you phrase it as "just gets a specific revision", it can be read as if you were talking about a shallow branch/clone, which is off the rails.
<vds> hello, anyone can help with this trace back: http://paste.ubuntu.com/401898/   ?
<jelmer> MvG: hi
<MvG> jelmer: hi there
<jelmer> MvG: Good, you're still here :-)
<jelmer> MvG: Are you still interested in having a cache of last-modified data for directories?
<jelmer> MvG: bzr-git needs something like that as well
<jelmer> MvG: If that'd be useful, I'm happy to talk about it later.
<MvG> jelmer: Yes, I'm interested.
<MvG> Busy just now, I guess I'll have time in 30-60 min or so.
<jelmer> mvg: same here
<jelmer> just wanted to catch up before you ran off for the weekend :-)
<meoblast001> ok, i just did `bzr init --format=1.9` and got "Created a repository tree (format: 2a)"
<jelmer> meoblast001: you're creating it inside of a shared repository which is already in the 2a format
<meoblast001> ooh
<jelmer> though I'm the first to admit that ignoring what you asked for is a bad idea, it should instead tell you
<l0nwlf> does bazaae supports installing branch behind a proxy with authentication ?
<l0nwlf> my system time out while running "bzr branch lp:repo-name"
<MvG> jelmer: you available now?
<jelmer> MvG: hi
<jelmer> MvG: yep
<MvG> jelmer: OK, so where do we start?
<jelmer> I think we should figure out whether what we need is actually the same thing
<MvG> jelmer: We want a map from (d, r), a tuple between directory fileid and revision id, to a specific revision id, either the same or an ancestor of the r requested.
<MvG> So let's say (d, r1) -> r2 for clarity.
<MvG> We want the path and contents of d in r2 to be exactly the same as in r1.
<jelmer> right, so the last revision id that touched a particular part of a repo ?
<MvG> And we can judge this from deltas.
<MvG> Starting from r1, we can compare parents and descend into a parent where the delta doesn't mention the path of d in any form, until we end up in a revision with no such parent, which will be r2.
<jelmer> I'm not sure I follow
<MvG> OK, so we look at revision r1, the one requested. It has a list of parents, p[0] ... p[n].
<MvG> We can compute the delta between r1 and p[i], and see what files are modified, what paths renamed, and so on.
<MvG> For every such file, we can find out the paths, both old and new, and if either is equal to or lies within the path of our dir d, then the delta does touch the dir.
<jelmer> ah, right
<MvG> Come to think of it, if d lies within a dir touched by a rename, we should consider the delta to touch d as well.
<jelmer> I was actually thinking of keeping a cache with this information
<jelmer> rather than having a API that found it
<MvG> Yes, well, that's point 2 on the agenda.
<MvG> I'm still at the phase of finding out whether we want the same thing.
<MvG> So now we should have a working definition of the info we want, and an idea how to obtain it in the first place.
<MvG> Possible next steps are how do we obtain it efficiently, how do we store it from a data organization point of view, and how do we store it from a file format point of view.
<MvG> It's the data organization I have given the most thought so far.
<MvG> Seeing as the set of keys (d, r1) scales with both the number of dirs and the number of revisions, storing all these kees seems terribly inefficient.
<MvG> Might be there is a way to tie the information efficiently to what bzr already does, but I know too little of the internal workings of bzr to decide this.
<MvG> So what I have in mind is a tree. For every revision r1, determine a base revision b(r1) by clearing the least significant bit set in the history length (or gdfo if you convince me that's better) and choosing an ancestor with that history length (resp. gdfo) as the base. For r1, only record changes relative to its base.
<MvG> As an effect, the vast majority of revisions have a base pretty close to them, with few changes. On the other hand, the tree ensures logarithmic path lengths, so for any revision you can find the last modified revisions in at most O(log histlen) steps.
<MvG> You follow me so far?
<MvG> jelmer: So much text you're still reading, or so boring stuff you fell asleep?
<jelmer> MvG: Sorry, got distracted into coding :-)
<MvG> Coding this, or coding something else?
<jelmer> something related
 * jelmer reads
<jelmer> MvG: right, so how would we go about implementing this - and where?
<MvG> jelmer: Originally I had planned to implement this in trac-bzr, test and use it there, and move it somewhere else if there is need.
<MvG> But now that you say you'd need something similar, maybe we should start out with a plugin.
<MvG> I've just read how the bzr-revnocache plugin is organized, maybe we can crib some parts from there.
<MvG> If I see things correctly, there is no way apps can benefit from this plugin unless they know about it, right?
<jelmer> yeah
<jelmer> that'
<jelmer> s the problematic bit
<jelmer> bzr-git needs this to operate properly
<jelmer> so I'm a bit reluctant of having this code in a plugin
<jelmer> ideally it would be copied into bzr-git or live in bzrlib
<MvG> We could sync code between bzr-git and trac-bzr, but I guess sooner or later loggerhead or others would want it, too.
<jelmer> yeah, ideally it'd be in bzrlib.
<MvG> bzrlib would be ideal from a user point of view, but would impose much severe restrictions on robustness, testing, documentation, and so on.
<jelmer> or perhaps the cache can be a plugin but we could have the API in bzrlib?
<MvG> You read my thoughts.
<MvG> By the way: do we need the same for files? I.e. if two branches modify a file, does bzr give the merge point as last modification revision?
<jelmer> MvG: it gives the merge point if the revision was changed there
<MvG> Changed by either maunal or automatic means?
<jelmer> MvG: If you just take the version present in one of the parents it'll record the revision of that parent
<MvG> OK. That's consistent then.
<jelmer> I don't need that info though
<MvG> Well, if we do this, we should do it right, so files and dirs should provide the same info.
<jelmer> MvG: Should we provide any info for files at all ?
<MvG> Yes, I think so. No need to cache anything there, but the API should give that info for dirs and files using a single method name, I believe.
<MvG> jelmer: Seems to me that InventoryEntry would be the appropriate place for this API.
<MvG> Is it justified to introduce an API into core although we know it will be slow?
<MvG> jelmer: How would you store stuff? sqlite? pickled python? handwritten format?
<MvG> Keep in mind that we have to store that b function I proposed as well, as calculating it the way I described might be too expensive.
<jelmer> MvG: It should be the same API
<jelmer> MvG: but we could have a hook that allowed you to provide a different mechanism to retrieve that info, that a plugin could use
<jelmer> MvG: Yeah, InventoryEntry seems like the most appropriate place, indeed
<MvG> So how do we go about this? 1. set up some shared branch, 2. implement fallback mechanism, 3. start plugin project?
<MvG> Do you have time for this? I probably won't have much time till mid may or so.
<jelmer> MvG: I don't have much time at the moment either
<jelmer> we might have a look at UDS
<MvG> ?
<jelmer> there's a Bazaar sprint during the Ubuntu Developer Summit in Brussels in May
<MvG> Dunno if I can afford going to Brussels, money-wise but more importantly time-wise.
<MvG> Haven't given all that sprint stuff a closer look yet, as I mostly got the impression it's targeted at canonical staff.
<jelmer> MvG: Sorry, I meant we as-in the attendees of the sprint :
<MvG> I see.
<jelmer> MvG: You're more than welcome to attend, I think more than half of the people there will be community
<MvG> So you could try working on this there, maybe find some cooperation?
<jelmer> MvG: Yeah, at least discussing the API bits
<MvG> Should we write a few lines of blueprint or whatever to ensure this isn't forgotten?
<jelmer> we don't really use blueprints for bazaar anymore
<jelmer> I guess we should send a [RFC] to the list
<MvG> I had started writing a mail while you were away coding, but it seems my thunderbird crashed on me. And in any case, I hadn't gotten much beyond the subject.
<jelmer> perhaps we should put something up on the wiki?
<MvG> Fine with me.
<MvG> http://wiki.bazaar.canonical.com/LastModified ?
<MvG> Or is there some naming convention we should follow?
<jelmer> A lot of the specs are under Specs/
<jelmer> I think we need a clearer name though
<MvG> Specs seems empty to me, I only find DraftSpecs...
<MvG> Specs/DirLastModified might be better. Should we be more verbose than that?
<MvG> jelmer: Unless you object (soon), I'll create http://wiki.bazaar.canonical.com/DraftSpecs/DirLastModified from SpecTemplate
<MvG> jemer: Can you explain the rationale for bzr-git?
<jelmer> MvG: That sounds fine
<jelmer> MvG: bzr-git needs to create Git Tree objects
<jelmer> which are roughly equivalent to subinventories
<MvG> jelmer: Do you know if there is any "last modified" UI for files right now?
<MvG> jelmer: http://wiki.bazaar.canonical.com/DraftSpecs/DirLastModified saved. Edit at will.
<adiroiban> hi , any idea what is causing this error http://paste.ubuntu.com/402059/ ?
<Peng> adiroiban: Most likely, .bzr/checkout/dirstate is corrupt, like it says.
<Peng> adiroiban: Uhh, it's not a critical file, so it's easy enough to work around, but I forget how exactly...
<adiroiban> Peng: I will try to search about how can I fix the dirstate
<adiroiban> but I was expecting from bzr to hint a sollution in the error message
<Peng> adiroiban: Is this a lightweight checkout or a full branch?
<adiroiban> a full branch
<Peng> adiroiban: Have any uncommitted changes in the branch or anything?
<adiroiban> yes, but I have alreade created a new branch and copied the changed files
<adiroiban> I was just wondering what is the user-friendly way of solving this problem
<Peng> Bahhh, I don't remember.
<Peng> BTW, please do keep a copy of .bzr/checkout/dirstate so someone can investigate what went wrong, if they want to.
<Peng> Did anything interesting happen, like a power outage or computer crash? Or awful network file system?
<Peng> You could try renaming .bzr/checkout out of the way and running "bzr co", but it might get mad and produce a massive number of conflicts, which would be a pain to clean up.
<adiroiban> there was a power failure
<adiroiban> that caused this mess
<Peng> You could also "bzr remove-tree && bzr checkout", but it'll delete and re-create the working tree, causing a lot of I/O, and probably conflict horribly.
<abk> hello
<abk> any one there
<abk> echo
<Peng> abk: Perhaps not, but you should ask your question.
<Peng> Also: Are you really IRCing as root? D:
<abk> :D
<abk> noop
<Peng> Some channels ban root, you know.
<Peng> ....
<Peng> Anyway, I'm certainly not here.
<Meths> Anyone looking at bzr on OpenSolaris?
#bzr 2010-03-27
<mithro> is there a command like gitk for bzr?
<Peng> Um...what does gitk do? qbzr or bzr-gtk or bzr-explorer probably have something.
<mithro> gitk lets you browse the revision history in an easy manner
<maxb> mithro: 'bzr qlog' is excellent (install qbzr)
<pobran_> May I ask a newbie question here?
<pobran_> I have a bunch of versions of a project which are not under source control and I am curious what the right way would be in bzr to make these into branches and merge them
<pobran_> Representing that they are all versions of the same project rather than completely different things, and being able to use merge commands across them
<magcius> arrgh.. is the best solution for repo web browsing really loggerhead? it stinks
<jelmer> it could use some improvements, yes :-)
<Peng> It stinks? That's a bit harsh.
<johnjosephbachir> howdy
<johnjosephbachir> when trying to do a rebase on a branch and a checkout in the same local repo, i'm told that a revision is missing from the repo
<moldy> hi
<moldy> i have a respository containing symlinks that i need to branch on windows. what is the best solution here?
<johnjosephbachir> here's a bug report describing the problem i mentioned this morning https://bugs.launchpad.net/bzr/+bug/549676
<ubottu> Ubuntu bug 549676 in bzr "revision missing from repo, causes merge, rebase, etc. to fail" [Undecided,New]
<Gnx> I seem to be experiencing large problems with using bzr client on an openssh server
<lfaraone> Hey, I'm getting an error when using bzr on Fedora 11: "bzr does not support python -O0"
<lfaraone> Does that sound familiar to anybody?
<hazmat> lfaraone, not familiar but it would suggest that the python optimization level was raised.. was this bzr installed from rpm or manually?
<lfaraone> hazmat: from rpm
<Adys> I got a repo on my server without a working tree; how do i get the working tree back?
<Adys> oh just need to checkout
<hazmat> lfaraone, sounds like a packaging error, from the source, it sounds like the package was done with optimized python compiled and with stripped the documentation strings (python -OO), which bzr needs, so it complains on startup, i'd file an issue with the package maintainer, they can just use python -O which does the optimized files without the doc strip
<hazmat> lfaraone, if you'd like to just use bzr, your probably better of in the short term it seems by removing the rpm, and doing a manual installation with easy_install
<mwhudson> jelmer: some interesting bzr-git commits :)
#bzr 2010-03-28
<jelmer> mwhudson: hey
<jelmer> mwhudson: yep (-:
<wgrant> Is there a way to invoke the 'bzr up' with local commits semantics without being bound?
<wgrant> ie. pull trunk and merge your current branch into it, in the one branch.
<Peng> I'm sure you could do something involving "bzr log -r -1 --show-ids", "bzr pull --overwrite" and "bzr merge . -r revid:...", but...
<wgrant> Right, that's what it would have to do.
<idnar> bzr rebase?
<idnar> maybe not
<james_w> wgrant: I often want the same thing, but haven't wanted it enough to write the plugin to do it yet
<wgrant> It'd be a trivial plugin, but it would be nice to have it easily available for everyone. Since Git people tend to do the 'merge trunk into branch, push branch over trunk' thing, because AIUI git parents are unordered.
<wgrant> And it would be nice to have a very similar bzr workflow which works unbound, and doesn't replace the mainline history.
<NfNitLoop> wgrant: Yeah, I do that workflow, but I do it by always having a clean mirror of upstream handy to merge onto.
<wgrant> So do I.
<wgrant> But others don't like that requirement.
<jelmer> wgrant: git parents are ordered
<jelmer> wgrant: that'd be roughly equivalent to just bzr merge .../trunk  && bzr ci -m "Merge trunk" && bzr push .../trunk, no?
<wgrant> jelmer: But that changes the LHS history.
<wgrant> If I bzr up on a bound branch, trunk's tip replaces mine, and my local commits show up as a pending merg.re
<Kraln> So I have a crazy question. Why does a 150 line change cause more than 360mb of transfer? (repacking texts)
<Kraln> (- 371561KB   114KB/s | Fetching revisions:Inserting stream:repacking texts:texts 6235/7200)
<jelmer> wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history..
<jelmer> Kraln: it would only take so much data every so often (bzr was repacking your repository apparnetly)
<Kraln> this was a tiny commit!
<Kraln> it's up to 400mb of transfer for 100 lines of changes, if that
<wgrant> jelmer: Ah, I see.
<jelmer> Kraln: Repacking happens every X commits or so
<Kraln> can I disable that? this is a *large* repo
<jelmer> Kraln: another 100line change right now won't require that much data to be transferred
<jelmer> Kraln I think you can disable it but it'll slow down your repository access in the long run
<Kraln> 400mb of transfer on a dsl line means it's been hours to make this commit
<jelmer> Kraln: an alternative is to use the smart server rather than sftp, in which case the repacking will happen on the server side
<Kraln> how do I set that up?
<jelmer> use bzr+ssh rather than sftp
<Kraln> that's it?
<jelmer> Kraln: I think so
<wgrant> As long as you have a recent bzr on the server.
<Kraln> it's 2.1 or whatever
<jelmer> wgrant: that said, I'm sure we'd welcome a patch to use the merge revision as the first parent rather than the previous local head
<wgrant> jelmer: Oh, so we could just switch the parents at commit time?
<jelmer> wgrant: yeah
<wgrant> jelmer: True. That sounds much easier.
<Kraln> http://dpb.pastebin.com/LaiDv5U1
<Kraln> :|
<Kraln> hmm, the folder on the server is empty
<Kraln> not feeling too peachy-keen happy with bzr at the moment
<NfNitLoop> try pushing with just sftp?
<mgiuca> Hello,
<mgiuca> wgrant just sent me a recent chat snippet from here, about replacing the LHS history with bzr merge / push
<mgiuca> Versus Git.
<wgrant> Hi mgiuca.
<mgiuca> "< jelmer> wgrant: it also changes the LHS history in Git, except Git folks don't seem to care about LHS history.."
<mgiuca> I didn't know Git had LHS history at all.
<mgiuca> Just thinking that in Bzr, if you have a local mirror of a branch, which has diverged, there's no simple way to 1. Merge, then 2. Push your changes up to the branch (eg on Launchpad) without reordering the LHS history on Launchpad.
<mgiuca> Except if you were bound, you could do an update.
<mgiuca> Maybe wgrant already discussed this before.
<A4Tech> All greetings. A bit strange question: I can host on the local machine to deploy the system bzr only without web?
<bendj> Hi.  I'm trying to get my head around repos-in-repos ...  Iiuc, I can pull an external branch into my local repo, e.g.: bzr init myrepo; bzr branch myrepo/extrepo.
<bendj> Am i then supposed to 'ignore' the extrepo dir, managing it separately?
<Kilroo> That sounds like it would work, but I've never done it.
<Kilroo> Inside the extrepo directory it will find the extrepo/.bzr directory first and go by that, and outside that directory it's been told to ignore it so it doesn't care that it's there.
<bendj> Kilroo: Ok, sounds reasonable.  Now, can it be further extended to 'nest' another branch under /myrepo/extrepo/YArepo, and manage *it* from the top/parent, myrepo?  I'm pretty sure I'm confused by this ;-)
<bendj> Kilroo:  More context might help ... what I'm trying to do it this -> https://lists.ubuntu.com/archives/bazaar/2010q1/067904.html
<bendj> Has to do with, eventually, managing/staging Drupal sites ...
<bendj> Kilroo: I suspect that I maybe approaching this wrong in the first place :-/
<Kilroo> Ah.
<Kilroo> Step 1: avoid Drupal.
<bendj> :-p
<Kilroo> That's just my personal experience.
<bendj> Kilroo: Actually, I'm using Pressflow ... that anybetter?
<Kilroo> No idea.
<bendj> Kilroo: Fair enough.  Ignore that fact, then ....back to the bzr question :-)
<Kilroo> right, reading
<bendj> hehe ...
<Kilroo> item the first: I think it's .bzrignore, you seem to have omitted the r
<Kilroo> not sure I've ever ignored anything without doing it through bzreclipse though so I may be wrong
<Kilroo> Ah.
<bendj> Kilroo: sure, just a typo on my part for the post ... good catch
<Kilroo> I'm pretty sure the answer is no.
<Kilroo> I am not sure what would happen if you explicitly said to bzr add core/data/test.txt from /repos/site, but I'm fairly certain that once you've ignored core from in site, it never bothers to look at core or anything in it unless you specifically tell it otherwise.
<Kilroo> I guess I'd just test it, if I were you.
<bendj> Kilroo: Sound reasonable, too. So, likely that /myrepo/extrepo/YArepo would have to be 'bzr init'-ed as it's OWN standalon repo, and managed separately?
<Kilroo> I honestly don't know. You're beyond my level of experience here. I haven't ever needed to deal with a nested repository or a nested tree or anything...I usually have something along the lines of /foo/bar as a no-trees shared repository, containing /foor/bar/trunk and /foo/bar/feature/{baz,wiz,woz}
<Kilroo> and then /foo/checkouts/bar, which I switch among the relevant branches
<bendj> Kilroo: Thanks, then. This all mostly (made) sense to me, until I was faced with this nesting bit ... then got a bit murky.  Like you said, testing/monkeying probably a good-thing.
<Kilroo> Good luck.
<bendj> ta!
<mwhudson> hazmat: yay for https://code.edge.launchpad.net/~hazmat/loggerhead/speed-rules
<rniamo> hi
<rniamo> is there a web interface for bzr which is better than loggerhead and lighter than redmine or trac ?
<rniamo> (better = you can download folder for example and having color syntax)
<mwhudson> rniamo: loggerhead has coloured syntax if you have pygments installed
<mwhudson> and there's a patch for downloading a folder somewhere i think
<rniamo> mwhudson : ok ill try, thanks,
<rniamo> i didn't succeed to install the patch correctly
<mwhudson> ah :/
<rniamo> when i click on download i had an error, something like loggerhead/static/projectxxx.tgz doesn't exist
<Peng> ..../static/? That sounds totally wrong.
<rniamo> mwhudson : i've installed pigments and i have no coloured syntax, where should i have to active it ?
<rniamo> Peng : yes, totally but i merge manually so i can have forgotten something. I installed loggerhead from ubuntu packages
<Peng> rniamo: You don't have to activate it. Um, what version of Loggerhead?
<rniamo> Peng : 1.17
<Peng> Yeah, that should support it.
<rniamo> :(
<rniamo> do i have to set language somewhere ?
<Peng> It auto-detects it, which usually succeeds, unless the file is non-tiny, but the alternative would be risking exponential runtime by Pygments, so...
<rniamo> Peng : ok, coloured syntax is ok, maybe the file was too tiny
<rniamo> or maybe i had to restart loggerhead
<rniamo> is there a simple solution to download a folder as tar/zip or anything else from loggerhead ?
<rniamo> how to install the "download" patch on loggerhead ?
<rniamo> i have this erreor when i want to install the download as tar patch : http://www.friendpaste.com/28UailBMDogGgC6q9AHuFm
<Peng> rniamo: Yes, you had to restart Loggerhead.
<rniamo> Peng : it's ok for coloured syntax, thanks
<jelmer> how do I recursively ignore everything under a directory?
<mwhudson> jelmer: hello
<Meths> Something like this I believe: 'bzr ignore "dir/**/*"'
<jelmer> mwhudson: moin
<mwhudson> jelmer: some interesting seeming bzr-git commits over the weekend :)
<mwhudson> jelmer: did you basically drop the trees table from the git.db file?
<jelmer> mwhudson: yeah
<mwhudson> (bah)
<mwhudson> jelmer: cool
<mwhudson> jelmer: have you tested it with the kernel?
<jelmer> mwhudson: not yet, there's still some issues to work out
<mwhudson> jelmer: what's the migration plan?  is the file still called 'git.db'?
<mwhudson> ah ok
<mwhudson> i guess we shouldn't try to sneak a bzr-git update into the next launchpad release then :)
<mwhudson> grr^2
<jelmer> mwhudson: the file is still called git.db, but I've also worked on a BTreeIndex-based map
<jelmer> which is significantly faster
<mwhudson> jelmer: ah ok
<jelmer> mwhudson: do you know the pydoctor maintainer for Debian/Ubuntu?
<jelmer> it seems it's out of date for python2.6..
<mwhudson> jelmer: no
<mwhudson> i guess i could make a release or something and try and sneak that into lucid
<jelmer> mwhudson: that'd be great
<mwhudson> jelmer: can you upload it to debian, or do we need to try to find the maintainer?
<jelmer> mwhudson: we need to find the maintainer, but it seems it's team maintained and I know the maintainer who's done most of the uploads so far
<jelmer> mwhudson: if you can get a proper release out I'd be happy to take care of getting it packaged and into debian
<mwhudson> jelmer: http://people.canonical.com/~mwh/pydoctor-0.3.tgz ?
<mwhudson> -?
<mwhudson> sha1 5fb79e1d84cc729e5731ff5a69275e5087b3e59c fwiw
<Tak> is there a quick way to determine at what bzr version a method got added? (specifically diff.get_trees_and_branches_to_diff)
<jelmer> mwhudson: wow, that was quick :-)
<Tak> also, is anyone seeing issues using bzr with python2.6? (I'm seeing what appears to be filehandle leaks)
<mwhudson> sdist doesn't take too long
#bzr 2011-03-21
<poolie> hi all
<mgz> hey poolie.
<poolie> hi there
<poolie> i'm working a bit today on a plan to bring bzr-colo into core
<jelmer> 'morning spiv, poolie
<jelmer> 'evening maxb, mgz
 * jelmer wonders what part of the day fullermd is in
<mgz> jelmer, have you filed a bug against launchpad yet to enable projects to remove certain states from the drop down box yet? :)
<jelmer> mgz: I think it'd be closed as "Won't Fix" :)
<poolie> hi jelmer
<poolie> mgz: certain bug states?
<poolie> which ones do you want to remove?
 * fullermd doesn't know himself anymore   :|
<mgz> poolie: I'm winding jelmer up a little, he's forgotten bzr doesn't use 'Triaged' a few times. :)
<mgz> okay, now I need sleep.
<poolie> ah
<poolie> in that particular case i think we'd be better off removing triaged altogether
<maxb> On the other hand, the distinction between confirmed and triaged is rather vital if a project wants to separate user confirmations and "has had developer attention"
<aroman> how can bzr have a conflict with a file that doesn't exist?
<mwhudson> if you delete a file, and the branch you merge from changes it, that sounds like a conflict to me
<poolie> that's right
<leo2007> If I have 2 commits in my local bzr branch and the parent has new commits, what happens if I do a 'bzr up'?
<spiv> The 2 local commits become a pending merge.
<spiv> Which you then need to commit.
<poolie> hi spiv
<poolie> spiv, have you used bzr-colo yet?
<leo2007> spiv: thanks.
<leo2007> why 'bzr up' always report I am up-to-date when in fact there are 9 new commits from parent?
<poolie> leo2007, if it's a separate branch you may need to pull or merge them.
<spiv> poolie: no, I haven't
<leo2007> poolie: pull says conflicts. But merge will not place my local revs on top of the remote parents, right?
<poolie> leo2007, are these separate branches, or is your local branch a checkout of trunk?
<poolie> spiv, how do you manage your branches?
<poolie> just separate trees within a shared repo?
<leo2007> poolie: a checkout.
<poolie> leo2007, what does 'bzr info' show?
<leo2007> poolie: http://paste.pocoo.org/show/lGSnxK33ZSi6vAKxlWmq
<poolie> when you say '9 new commits from parent' where do you see that? by separately running 'bzr log' on the parent?
<leo2007> poolie: from 'bzr missing'
<poolie> leo2007, this looks like just a regular standalone branch then
<poolie> you're trying to bring the latest stuff from trunk into your branch, and then continue with development of your branch?
<leo2007> yeah, and my branch has two commits.
<leo2007> two extra*
<poolie> ok, so you should probably just merge trunk
<poolie> your own revisions will still be visible in history, but they won't be on top of it
<spiv> poolie: yes, exactly that layout
<poolie> if you want to rewrite history so it looks like they were done after what is now on trunk, use bzr-rewrite
<leo2007> poolie: I also need to push my commits to trunk at some time later.
<poolie> ok
<poolie> but not right now?
<leo2007> poolie: no, not right now.
<leo2007> I basically want to pull from upstream compile and submit my commits.
<leo2007> I am familiar with git but not bzr.
<poolie> spiv, when you get a chance could you install it and have a play
<poolie> leo2007, ok, the typical bzr thing would just be to merge from trunk, resolve any conflicts, compile and test, then send up your changes
<leo2007> would that mean my branch having different history than upstream?
<poolie> well, your branch is going to show you did some work, then you merged trunk and resolved conflicts
<poolie> which is accuarte
<poolie> when trunk merges from you, all the history will be accurate
<leo2007> Is it possible to push an individual commit to upstream? In my case, I have two new commits locally, one is more mature and the other is waiting for confirmation before submitting.
<poolie> when you say 'push' do you mean actual bzr push direct into trunk?
<poolie> do you have access to write to trunk?
<poolie> or just to submit for someone else to review?
<leo2007> poolie: I have write access.
<lifeless> spiv: hi, re bug 739144 - making it critical is fine; please don't set to confirmed though - if you've triaged it, set it to triaged.
<ubot5> Launchpad bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged] https://launchpad.net/bugs/739144
<poolie> leo2007, perhaps the cleanest/easiest thing is to make a new branch off trunk to integrate your work
<poolie> do a 'bzr merge -r whatever' from your branch into that
<poolie> then push that back up
<leo2007> poolie: is it possible to export a commit to a file which I can then put back in easily? something like git format-patch and am?
<leo2007> I am thinking since I have only two commits for now. I could save them to a file and drop them in my local branch. Sync my branch and put them back.
<poolie> 'bzr send -o FILE'
<leo2007> that would appear solve all my questions.
<poolie> or perhaps 'bzr shelve' is a better idea
<poolie> or, if you have only two, just uncommit, shelve, pull, then unshelve
<leo2007> poolie: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/Users/Shared/sources/EmacsBZR/trunk/".
<spiv> lifeless: ah, ok.  Thanks for the correction.
<poolie> leo2007, ok, in that case you will need to make a new checkout of trunk trunk, merge your work, then commit
<lifeless> spiv: you may not have read https://dev.launchpad.net/BugTriage in a while - its been refreshed
<spiv> lifeless: I haven't read it in detail, no, although I did skim it to check that I wasn't being too outrageous in choosing Critical
<spiv> lifeless: I just didn't think at all about Confirmed vs. Triaged because I'm totally out of the habit of ever considering Triaged :)
<lifeless> :)
<spiv> jelmer of course is having the opposite problem these days :)
<leo2007> poolie: I changed branch.conf and go ahead with uncommit.
<poolie> just curious, what change did you make?
<leo2007> poolie: append_revisions_only = False
<poolie> lifeless, how about you, did you ever use bzr-colo
<poolie> oh, for the real emacs trunk?
<poolie> that might make other people unhappy
<leo2007> poolie: my branch
<leo2007> poolie: could you recommend some good docs for using bzr?
<poolie> well, mostly the current version under doc.bazaar.canonical.com
<poolie> i know emacs also have some special conventions that i think are on their wiki
<poolie> i would also really recommend using bzr-colo with bzr
<poolie> from
<poolie> http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
<wgrant> spiv: :(
<leo2007> ok, i'll take a look after reading http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
<leo2007> poolie: thanks for your help.
<wgrant> spiv: Processing that same email locally works fine.;
<spiv> wgrant: whee
<wgrant> spiv: So I wonder if an MTA ate it... or something.
<wgrant> I guess we should check that jam's copy is intact.
<spiv> wgrant: yeah, that's a good idea
<wgrant> If it's intact, we might need to go through MTA logs and find where the size drops...
<lifeless> poolie: no, I have used looms, and pipelines, and for non-distro work I just use a lightweight checkout of branches in a shared treeless repo
<poolie> ok
<poolie> you might like to try this as an alternative to the latter
<poolie> i would appreciate your feedback if you do so
<lifeless> it will be a bit tricky right now -  my lp dev environment is down to 200MB free :( (and my host os 2GB free :( :( )
<lifeless> I need to get a larger SSD
<lifeless> I've been looking at getting a larger desktop box in fact - but the price for ones with 48GB of memory is ridiculous ;)
<poolie> hm, it shouldn't use any more space than what you do now
<wgrant> poolie: Is colo fairly usable these days?
<poolie> it might take more than 200MB to convert into it
<poolie> i think it's really good
<wgrant> I haven't tried it since the week it was announced.
<poolie> i'm just drafting a mail proposing we should bless it as the standard way to use bzr
<poolie> and ship it by default etc
<stylesen> poolie: ping
<wgrant> IIRC the main problem I had with it was shelf.
<poolie> it gives people a less manual way to set up the single-tree multiple brancehs thing
<poolie> hi stylesen
<stylesen> poolie: Hi poolie, would like to have a private chat with you!
<lifeless> poolie: yeah, converting is what I was thinking might be an issue
<poolie> sure, see pm
<poolie> lifeless, i think the default conversion does copy all your histoyr
<poolie> this could be optimized of course
<poolie> for the common case of turning a repo + branches into a colo workspace, just moving the directories ought to be enough
<poolie> lifeless, i just bought a 750GB magnetic disk to go into my laptop base
<poolie> to store (my own) photos
<poolie> lifeless, it's kind of ironic that you just converted me to the convenience of not having separate laptops/desktop machines :)
<lifeless> poolie: nice!
<lifeless> poolie: thats in an expansion bay, or the main unit?
<poolie> in the sata bay of the ultrabase
<poolie> the base does work pretty well for using it as a desktop replacement
<lifeless> ah, nice.
<lifeless> poolie: I'm finding my biggest limit is RAM
<lifeless> the disk is a bit annoying, but I can juggle tolerably (though 128GB is quite constraining)
<lifeless> but I can barely use all 4 cores with 8GB
<poolie> i probably will ssh into my desktop box again if i'm doing something on lp and don't anticipate travelling soon
<poolie> it seems like i touch dkim infrequently enough that every time i do, i spend 30 mins trying to get all the dependencies going again :/
<lifeless> poolie: so if I do get a new desktop, I'll setup testr to run tests on the desktop from my laptop
<wgrant> lifeless: Are new ThinkPad motherboards still limited to 8GB? :/
<lifeless> probably set that up locally too so that I edit in a local vim session, and the lp-dev VM runs the tests
<lifeless> wgrant: the W something or other can do (IIRC) 12
<lifeless> wgrant: need 4GB for a lp test run end to end last time I tried to put a figure on it
<lifeless> wgrant: (4GB in a VM)
<lifeless> wgrant: so to parallelise robustly-before-we-fix-the-test-suite, I'm thinking we want 4GB*cores.
<wgrant> lifeless: It's a lot less if you run i386.
<lifeless> wgrant: but then I'd be running i386.
<wgrant> In the VM :)
<wgrant> How do I grab a remote branch into an existing colo workspace?
<lifeless> I
<lifeless> I'd expect 'make a branch, pull --overwrite'
<wgrant> 'bzr branch lp:launchpad colo:devel' seems to work.
<poolie> or bzr colo-fetch lp:launchpad
<wgrant> colo-fetch says it creates a new workspace.
<poolie> sorry, i misread
<poolie> yes, i think your command is correct then
<wgrant> Thanks.
<wgrant> :(
<wgrant> I wish bzr switch had an option to shelve changes into the branch or something.
<poolie> wgrant, that was just requested
<poolie> it shouldn't be too hard to add
<wgrant> poolie: Except that shelves are in the WT, right?
<spiv> wgrant: right
<wgrant> :(
<wgrant> Hmm.
<wgrant> I guess it's useful to have them visible in all, but it would be nice if I could tell where each shelf came from.
<wgrant> Since I use shelve a *lot*.
<spiv> wgrant: hmm!
<wgrant> (and I just about never give a message... perhaps I should)
<spiv> wgrant: bzr-colo could perhaps auto-fill the --message option of 'bzr shelve' with the branch nick?
<wgrant> Right.
<wgrant> That would help.
<poolie> wgrant, well, what i meant is that it seems like it would be a small code change to put them in the branch dir
<poolie> giving better identities would be good
<poolie> i'd like if they showed a diff stat or a snippet of the change more easily
<vila> hi all !
<poolie> hi vila
<vila> poolie: hey !
<poolie> hi vila
<poolie> vila, did you try bzr-colo yet?
<poolie> s//at all?
<vila> not at all
<vila> I still favor using a different working tree for each branch and looms for more involved feature dev
<vila> I also use bound branches for specific needs (so multiple working trees but on different hosts)
<poolie> ok
<poolie> rfc sent
<poolie> vila, like multiple machines all on the same network, bound to branches on one of them?
<poolie> for fixing failures inside vms, or something?
<vila> well, the branches are called my/setup and my/admin and they centralize/share all tweaks/setups I do on all my hosts
<vila> that includes VMs
<vila> but I still haven't a good story for fixing failures in VMs, partly because I keep encountering corruptions due to hard crashes and partly because I don't want to put valid auth tokens in VMs
<vila> (thought I cheat a bit with the later ;)
<vila> I work around corruptions by using mounted file systems for most of the VMs
<vila> I'd prefer a bzr-based workflow but each time I need it, I'm already in bugfix mode and procrastinate
<vila> s/proca*/punt/
<vila> urg, one more random kill of a VM as a write this :(
<vila> hmm, death may be more appropriate in fact, *2* VMs died (out of 3 running) and only the 3rd one should have shut down...
<poolie> wow
<poolie> died in the vm infrastructure, or in the guest os?
<vila> the vm just vanished
<vila> n ologs, no core, no nothing
<poolie> this is with virtualbox?
<vila> most annoying "babune" bug for months, no idea how to progress, last attempt was configuring core dumps but none ever appeared
<vila> yup, and vbox is my first suspect, I keep hoping that the next version will address the issue :-/
<poolie> maybe some of these things could run under kvm, vmware desktop, or something else?
<vila> I chatted in #vbox several times but no one has any idea about what is going on nor how to collect useful infos to help debug it
<vila> and since most of the time it happens during my sleep it's very hard to even caracterize it (hence my kill/death remark above)
<magcius> gah
<magcius> This is the most annoying thing.
<fullermd> vila: Really, it's your own fault for sleeping   :p
<vila> aaaaaaah, of course !
<poolie> hi vila,
<poolie> would you like a quick chat
<vila> sure
* jelmer changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer | 2.3.1 is officially out, 2.4b1 has been frozen
<leo2007> how to show what's in a commit?
<jelmer> leo2007: do you mean the tree contents, the changes in that commit, the commit message / committer information?
<leo2007> the diff, the message, etc
<jelmer> leo2007: bzr log -p -rREV
<leo2007> thanks.
<spiv> jam1: LP appears to have mangled an email I sent to it: https://launchpad.net/bugs/739144.  You were CC'd, did you receive it intact?
<ubot5> Ubuntu bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged]
<spiv> jam1: probably best to reply on the bug, it's zzz time here :)
<jam1> spiv: I got the email in-tact
<jam1> and broken from lp
<spiv> jam: I'm not sure if I feel relieved to hear that or not!
<jam> spiv: sleep well. But yes, you sent the email correctly to me, LP messed something up
<jam> or LP's mailhost did :)
<Sp4rKy> hi
<Sp4rKy> I get an error when trying bzr update :
<Sp4rKy> bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 85: ordinal not in range(128)
<CaMason> hi guys. In our current team workflow, we occasionally have a 'merge session' where we merge in all changes prior to a release. After that, I get the team to `bzr pull` from the master branch, so we're all now working from the same code
<CaMason> is that last bit sensible?
<CaMason> it seems to work OK, as all team members then get everyone elses changes in their own branches
<maxb> Sp4rKy: See if there is a traceback in ~/.bzr.log, and pastebin it
<jelmer> CaMason: that seems perfectly sensible
<Sp4rKy> maxb: http://paste.dunnewind.net/show/eVa29Aq8XkZ8ySIA0Xrt/
<mgz> Sp4rKy: set you LANG/LC_ALL env vars to something sensible.
<mgz> *your
<maxb> Sp4rKy: to expand slightly on mgz's answer - you're trying to check out code with non-ascii file names. To do this, you need to be configured to use a locale which uses a character encoding which can represent them, so that Bazaar knows how to write the filenames to disk
<maxb> Nowadays, everyone ought to be using a utf8 locale, really
<Sp4rKy> maxb: in fact I am using utf-8 locale
<Sp4rKy> but for some strange reason puppet (I manage the bzr repo with it) reset it ;)
<Sp4rKy> so nothing bzr-related I think
<maxb> line 56 of your pastebin says you are not
<Sp4rKy> I am :)
<Sp4rKy> but puppet reset it
<santagada> is there any benchmarks comparing bzr 2.1+ to mercurial and git?
<santagada> I've only seem really old ones and people told me bzr improved a lot in the 2.x line
<jelmer> santagada: I haven't seen any recent benchmarks
<jam> jelmer: care to finish your review of https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
<jam> ?
<ubot5> Error: Launchpad bug 2 not found
<jelmer> jam: Sure
<CaMason> what's the easiest way to output all files that have changed between revisions? Sometimes we get a customer that needs a 'patch', and we want to send only the PHP files that have changed
<jam> CaMason: "bzr status -r X..Y" ?
<CaMason> we might be talking a few hundred files :) Any way to `bzr cat` based on the revisions?
<CaMason> if not, I could set up a script
<jam> CaMason: so you want the complete contents of all files that changed recently (that end in .php)?
<CaMason> between specified revisions, yes
<jam> CaMason: "bzr status --short" is quite scriptable
<jam> my 'cut' experience is limited
<jam> but
<CaMason> ah, hadn't seen that :D
<jam> bzr status --short -r X..Y | grep ".*\.php"
<jam> gets you a sart
<jam> start
<jam> I would use sed to get just the filenames, but that's because I don't know cut
<CaMason> no sweat, that output is great, I'll get that scripted
<CaMason> thanks
<CaMason> bzr st --short -r last:4 | cut -c 5-
<jam> CaMason: still need 'grep .php'
<jam> but yeah
<jam> bzr st --short -r last:4 | cut -c 5- | grep '.php' | xargs -n1 bzr cat -r -1
<CaMason> ah that's no bother, I actually want all files. I just said 'php' so people didn't worry about a build script :P
<jam> CaMason: though you could probably just pass the list to tar so that it will include only those files in a tarball
<CaMason> `bzr st --short -r last:4 | cut -c 5- | xargs zip ../patch.zip` worked great
<CaMason> its for windows clients unfortunately :)
<jam> jelmer, vila: ping about https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
<ubot5> Error: Launchpad bug 2 not found
<vila> ubot5: where do you find a bug 2 ?
 * mgz eyes ubot5 suspiciously
<ubot5> Error: Launchpad bug 2 could not be found
<vila> mgz: ;)
<jam> mgz: it *really* likes bug 2
<ubot5> Error: Launchpad bug 2 could not be found
<jam> mgz: currently reviewing  https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
<ubot5> Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid]
<jam> why do you return the Error class rather than just raising it?
<mgz> okay, someone just borked poor ubotu5.
<vila> gee, unplug that bot !
<jam> mgz: at least it didn't mention "that bug" again
<mgz> jam: I don't really like helpers appearing in the stack, and to raise I need to return object from the cdef anyway
<jam> mgz: well,there are other ways, and you don't have to explicitly list object (it is the default if you say nothing)
<mgz> so it's either helper than raises or returns None, or returns exception instances
<jam> cdef foo() returns None
<jam> same as regular python
<vila> jam: oh, and pong https://code.launchpad.net/~vila/udd/735477-kill-harder/+merge/53837 ;)
<ubot5> Ubuntu bug 735477 in Ubuntu Distributed Development "some imports survive a kill -SIGTERM leading to massive log output and no kill" [High,In progress]
<mgz> I picked the way that gave me a shorter path in the common case, and one less level of stack when something goes wrong. but I'm open to all suggestions of this kind, made various stylistic judgement calls.
<jam> vila: you didn't respond to my comment on that proposal
<jam> I don't usually like hard-coded constants in the middle of code, can you bring it to a module/class level constant?
<vila> jam: it wasn't related to the proposal but to another script :)
<jam> otherwise seems good to me
<jam> vila: though isn't that script broken by any grace period that isn't 0?
<jam> since it only waits 1 second before starting the next process
<vila> jam: no, as explained in the cover letter (updated before asking for re-review) during the grace period no kills are issued but the mass_import script doesn't wait either
<jam> vila: I saw the update, but probably missed the details in the 5-pages-of-text
<vila> the discussion then went about how long it takes for the mass_import to stop
<jam> vila: so only ImportDriver is using the new kill_with_escalation, and mass-import is doing?
<vila> 61 lines == 5 pages ? a page = 12 lines ?
<jam> anyway, it isn't very clear how your first comment how it ties in with the last comment. since you seem to say it should switch, but then say it doesn't
<vila> jam: sorry I don't understand your question
<jam> or maybe just doesn't fast enough?
<jam> vila: I'll try to start at the top
<jam> "For the first case, we don't really care about what is currently
<jam> going on since this denotes a bug"
<jam> that sounds exactly like the case we care about
<jam> s/the case/a case/
<vila> except we can't any data from a process that doesn't respond to SIGTERM (as shown with nexuiz-data)
<jam> vila: certainly
<vila> and we *currently* generate log files 1GB/day with attempts to kill it
<jam> I think martin and my point is that under load, 2s is actually pretty short for something to even generate a backtrace
<jam> I'm happy to have the SIGTERM end up with SIGKILl
<vila> well, not *currently* because it's seen as failing but still
<jam> after a reasonable time
<jam> 10s seems good to me
<jam> a bit long for "die now please"
<jam> but good for most situations
<vila> jam: which is what the proposal implements hence asking for a re-review
<jam> vila: which is the part I've certainly approved already
<vila> meh, there are currently 2 NeedsFixing vote and no Approve
<jam> vila: reload
<jam> mgz: why is "delta_data" a "void **" rather than a "delta_index **" ?
<jam> (in the pyrex header)
<mgz> it was a straight change from returning void* to taking void**, but it could be unsigned char** instead given the actual value
<jam> mgz: and in the docs, I would say "when DELTA_OK "fresh" contains a struct ..."
<mgz> was it some cython being to clever with strings workaround thing?
<jam> rather than "outparam" which isn't defined
<jam> mgz: the actual value is a delta_index pointer
<jam> at least from what I'm reading in delta.h
<mgz> possibly the header is misleading?
<mgz>     unsigned char *out;
<mgz> ...
<jam> https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
<mgz>     *delta_data = out;
<ubot5> Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid]
<jam> line 285
<jam> you added a new parameter, it should be called "fresh" not "delta_data", or whatever you want to do with it
<mgz> create_delta and create_delta_index have different signatures.
<jam> mgz: ah, just misreading it
<mgz> 282 in diff-delta.c is 197 in delta.h
<mgz> adding to the function descriptions in the header might help things, the similar names are confusing to start with.
<jam> mgz: overall approve, just needs a news entry
<jam> something about getting better error messages when things fail
<jam> is probably enough
<mgz> I'll do that and take another pass at the comments.
<mgz> which news heading should it be under? :)
<jam> mgz: probably either internals or bugfixes
<mgz> I'm just having a closer look at your tar export branch now, the push fixed the broken tests clearly.
<vila> jelmer: what do you mean in bug #739481 ? Repository has too many methods - iter_reverse_revision_history " ... "in favor of Repository.iter_reverse_revision_history" ?
<ubot5> Launchpad bug 739481 in Bazaar "deprecate Repostory.iter_reverse_revision_history" [Low,Confirmed] https://launchpad.net/bugs/739481
<fullermd> Obviously, he means there's madness in its methods   ;)
<gypsymauro> hi
<gypsymauro> suppose my shared repository is offline, can I commits locally and then when I can reach my serve again move all changes to the shared repository?
<maxb> gypsymauro: Yes, but a little advice on terminology - a "shared repository" in bzr terms usually refers to a location on disk created with "bzr init-repo" which exists to share one copy of history between multiple branches within it.
<maxb> Whereas I assume you are talking about a remote server hosting branches.
<gypsymauro> maxb: no I'm talking about a shared repository in bzr terms :)
<maxb> How can a directory on disk be offline?
<sidnei> vila, is anyone running the bzr benchmarks that ian was running?
<sidnei> or jam ^^
<jelmer> g'morning poolie
<santagada> sidnei: I think you will have to run them
<santagada> :D
<sidnei> santagada, yeah, why not
<sidnei> santagada, you could too :)
<santagada> sidnei: if you can get the scripts used, I can try
<sidnei> santagada, yay!
<sidnei> jelmer, would you know anything about ian's benchmark scripts?
<santagada> if it is a simple shell or python we could run it on my mac on windows and osx, you could do it on ubuntu
<jelmer> sidnei: I think it's on Launchpad as lp:bzr-usertest
<santagada> jelmer: yep it is in there but the docs http://people.canonical.com/~ianc/plugins/usertest/doc/ are 404
<jelmer> santagada: I think the docs are probably in the branch too
<sidnei> yeah, looks like it
<sidnei> santagada, see http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/view/head:/scripts/script_network.py for example
<cody-somerville> jelmer, Hey.
<cody-somerville> jelmer, I got that information you requested: https://pastebin.canonical.com/44973/
<cody-somerville> jelmer, It... looks like a bigger issue at hand. And the fact that someone else also reported this is rather concerning.
<jelmer> cody-somerville: who did?
<jelmer> cody-somerville: that all looks reasonable
<cody-somerville> jelmer, Why is the group owner of somethings users and not jagosta?
<cody-somerville> jelmer, LP #661678
<ubot5> Launchpad bug 661678 in bzr (Ubuntu) "bzr whoami: unable to copy ownership from '$HOME/.bazaar' to '$HOME/.bazaar/bazaar.conf'" [Undecided,Invalid] https://launchpad.net/bugs/661678
<jelmer> cody-somerville: I don't know, but that shouldn't really be an issue
<jelmer> cody-somerville: or maybe that breaks the ownership copying
<jelmer> cody-somerville: what groups is he in ? is he in both jagosta and users?
<cody-somerville> jelmer, weird... no. users but not jagosta
<jelmer> That would explain why bzr is errorring out - as it probably can't set the group for that file
 * jelmer reopens the bug
<cody-somerville> I think this might be a regression in Ubuntu.
<jelmer> cody-somerville: yeah, looks like it
<Pilky> does anyone have any experience pushing a bzr branch to a new github repository?
<Pilky> I'm trying to do a dpush but it's giving a respository not found error
<rockstar> abentley, you around?
<AfC> Shame about bzr-git only using 1 CPU
 * jelmer waves to AfC
<AfC> Hi jelmer
<jelmer> AfC: It could very well use more in theory, we just haven't put the work in yet and I imagine the GIL would be problematic in this case.
<AfC> jelmer: I've been trying to get a checkout of Cairo. It's been 20 minutes so far. Might be a good test repository for you (especially seeing as how it's probably the third oldest Git respository out there).
<AfC> jelmer: $ bzr checkout git://anongit.freedesktop.org/git/cairo
<AfC> jelmer: is the command I ran...
<AfC> Perhaps one to add to the "large foreign repos we performance test" collection.
<jelmer> AfC: ENOSUCHCOLLECTION ;-)
<jelmer> AfC: There probably should be one, though..
<AfC> heh
<jelmer> Among other things I'm currently working on getting all the Bazaar interface tests passing against the foreign formats. After that, I hope to take a look at further improvements, including performance.
<AfC> jelmer: doesn't John maintain some large family of test repos, ie Open Office?
<AfC> jelmer: but anyway
<AfC> jelmer: yeah, I saw you remark about that. Very cool indeed.
<jelmer> AfC: Yeah, I think he has something like that, but he tests the converted trees, not the conversion itself.
<IceGuest_77> hi, quick question, hoping someone can help me. I am having a look at the stats plugin, and trying to understand how it works. Why are the numbers of revisions it reports more than from bzr log -rsomerev -n0 | grep revno | wc -l. What revisions is log not showing, and why?
<kingos> stats gets the revisions by doing : ancestry = a_repo.get_ancestry(revision)[1:]
<jelmer> hi kingos
<spiv> kingos: off the top of my head I'd expect the ancestry of a revision to match the log -n0
<jelmer> spiv beat me to it, that's what I'd say as well
<jelmer> get_ancestry() is a bit weird as the first entry it returns is always None, hence the "[1:]" bit.
<spiv> ('bzr ancestry' is a simpler way to see the revisions in the ancestry of a branch)
<spiv> kingos: "bzr ancestry" and "bzr log -n0 --line" give the same number of lines for me.
<spiv> (on the two branches I tried, one with 34k revs the other with 688 revs)
<kingos> hmmm
<spiv> (the stats plugin is not working for me atm)
<jelmer> spiv: hmm?
<spiv> jelmer: AttributeError: 'ProgressTask' object has no attribute 'note'
<spiv> jelmer: with trunk lp:bzr and trunk lp:bzr-stats
<kingos> spiv: yeah you can't specify an initial range I htink
<spiv> kingos: to bzr ancestry?  No, unfortunately.  You could always do 'bzr branch --no-tree -rSOMEREV' (maybe add '--stacked' if you aren't using a shared repo) to work around that :/
<kingos> spiv: I meant with stats
<spiv> Oh ok.
<kingos> spiv: bzr stats -r2..5 fails, where as bzr stats -r5 works
<jelmer> kingos: please file a bug about that
<jelmer> kingos: does it simply ignore the range or does it crash?
<kingos> jelmer: It fails with that progress note error
<kingos> jelmer: do I file it under bzr, or is there a plugin specific bug page?
<spiv> kingos: oh, I'm not passing any args to bzr-stats at all
<spiv> kingos: bugs.launchpad.net/bzr-stats I expect
<jelmer> it works happily here with both trunks afaik
<spiv> jelmer: a puzzle!
<jelmer> spiv: I'm only getting that error when I specify a range
<spiv> jelmer: ah, hmm, pebkac in my ~/.bazaar/plugins symlinks
<jelmer> kingos: can you try with trunk?
<spiv> Whee, 'ln -s ~/code/bzr-stats/trunk stats' does something confusingly different if you already have a 'stats' directory...
<jelmer> spiv: heh
<kingos> jelmer: still fails
<jelmer> kingos: do you have r46?
<jelmer> can you pastebin the backtrace?
<kingos> jelmer: backtrace on the ticket
<kingos> Bug #739823
<ubot5> Launchpad bug 739823 in bzr-stats "bzr stats cannot handle revision ranges like -r2..5" [Undecided,New] https://launchpad.net/bugs/739823
<spiv> kingos: By 'r46' he means "the revision I committed 3 minutes ago
<kingos> of stats?
<spiv> kingos: yes
<spiv> jelmer: thanks, r46 fixes the -r2..5 bug for me
<kingos> jelmer: no I didn't, that fixes it :(
<kingos> jelmer: what should I close the bug report with?
<kingos> jelmer: fix committed, or something else?
<jelmer> kingos: yeah, fix committed
<jelmer> it'll be fix released after the next bzr-stats release
<poolie> hi spiv, jelmer, all
<spiv> Hi poolie
<jelmer> hi poolie
#bzr 2011-03-22
<poolie> looks like i got some interesting feedback about colo
<jelmer> poolie: indeed.. almost all enthusiastic too
<jelmer> poolie: when you say bring bzr-colo into core, did you mean as-is or in some form or another?
<sidnei> hi poolie
<poolie> oh, definitely with changes
<poolie> apparently i should have been more clear about that
<mgz> hm, how clean does pqm make things before trying a build?
<mgz> ...I'd better just give up for the night I think.
<lifeless> mgz: rm -rf clean
<mgz> out of clever ideas as to what's wrong then, will fall back to blaming cython. shame I can't actually get at the generated C file.
<mgz> if someone has the same version pqm does and want to try compiling my branch while I sleep, that'd be great.
<poolie> mgz, i'll see what i can doo; sleep well
<poolie> biab
<ScottK> How do I remove a remote brach?  Not on LP, in this case on alioth.
<lifeless> rm -rf
<lifeless> uhm thats not helpful
<lifeless> what I mean is, that just deleting the directory is the way
<lifeless> and we don't have an API in bzrlib to do that at the *branch* level, but if you don't have sftp access to the branch, bzrlib's VFS can let you do the delete remotely with a few lines opython.
<lifeless> probably a bug report would be good too
<ScottK> I do have sftp access, so I can do it that way, but I was hoping for bzr rm -rf && bzr push or something.
<ScottK> I'll file a bug against bzr.
<spiv> I think there may already be a bug report.
<ScottK> I didn't find it.
<spiv> Ok, probably not then. :)
<vila> hi all !
<jam1> morning all
<vila> hey jam :)
<jam> sidnei: afaik, nobody is regularly running those benchmarks.
<sidnei> hi jam
<jam> morning sidnei
<jam> well, morning here at least
<sidnei> jam, here too, 6:45 to be more precise
<sidnei> jam, we might have a volunteer for setting up the benchmarks. let's see if he sticks around :)
<jam> sidnei: are you usually up that early?
<sidnei> jam, i usually go back to bed for a few more hours, but decided not to today. my kids wake up around 6am. the good news is that they go to bed around 10pm. and they're just 5mo old.
<jam> jelmer: so it certainly seems that python2.7 has yet-again changed the size of python objects
<jam> sigh, I already had 2.5 vs 2.6 code, now I need to add 2.7 into the mix
<jam> I can reproduce 3 failures here
<jam> at least the failure for 'string' sizes
<jelmer> jam: ah, urgh :-/
<jam> jelmer: I just committed a change which handles the String cases. which are all that were failing here
<jam> I think the other bits are probably a 64 vs 32-bit difference.
<jam> Care to help me work them out?
<jam> do you have a python2.6 on your machine to work with?
<jelmer> yep, I have 2.6 installed here
<jelmer> 3 of my 9 errors are gone with the latest trunk
<jelmer> what can I do ?
<jam> jelmer: can you run it w/ python2.6 and see if they all pass?
<jam> I'm wondering if I'm just failing on 64-bit always
<jam> I have a gut-feeling that I'm rounding to 4-byte precision, and on 64-bit it always rounds to 8-byte precision
<jam> (a struct will always be a multiple of 8-bytes rather than 4-bytes, but that might also be a python-2.6 vs 2.7 ism)
<jelmer> jam: fails on python2.6 too
<jelmer> same 6 tests
<jam> jelmer: k. Yeah, I think I'm just off on how 'packed' the struct will be.
<jam> I'll poke at it differently, just a sec
<jam> jelmer: try again with trunk revno 188
<jelmer> jam: one left now with both 2.6 and 2.7
<jelmer> test__sizeof__with_dummy (meliae.tests.test__loader.TestMemObjectCollection)
<jelmer> AssertionError: 8340 != 8344
<jam> jelmer: done in 189, I just missed the fix for that test.
<jelmer> jam: I can confirm it works now
<jam> jelmer: what brought it to your attention?
<jelmer> jam: There's a transition going on in Debian (dh_pycentral/dh_pysupport -> dh_python2) so I had to upload a new meliae anyway and was looking at running the test suite at build time, just to be sure.
<jelmer> jam: It looks like the exit code of run_tests.py doesn't change if any tests failed btw
<BlankVer1e> how to find the last three logs , bzr log | head shows only 1
<jam> jelmer: patches welcome, I've never needed the return code, because I didn't script it. I'm not entirely sure how to
<jam> BlankVer1e: bzr log --last 3 ?
<jam> sorry, "bzr log -r last:3"
<jam> bzr log -r -3..-1 is what I would use, though
<leo2007> How to resolve this error http://paste.pocoo.org/show/7CYpcX5yqrzmNUAVubHG?
<jelmer> leo2007: run "bzr break-lock bzr+ssh://leoliu@bzr.savannah.gnu.org/emacs/trunk"
<leo2007> that only break locks by me right?
<leo2007> I basically C-c interrupt a 'bzr push' and now this problem.
<jam> leo2007: bzr break-lock will only break the lock you ask it to, but it will break anyones lock. Which is why we give you the preview of who is claiming the current lock
<jam> in your traceback, you can see your name
<jam> "held by leoliu@vcs-noshell"
<leo2007> ok breaking in process.
<happyaron> where to find bzr-fast-export.py?
<jelmer> happyaron: it's a part of the bzr-fastimport plugin
<happyaron> thanks
<jml> vila: hello
<vila> jml: hey ! . o O (In what TZ is he ?!?!)
<jml> vila: I can report that when I pull Launchpad branches that delete directories, Bazaar still gives me conflicts about not being able to remove those directories
<jml> vila: I'm in the UK
<jml> I am in *the* timezone.
<vila> :)
<vila> weird
<jml> yeah.
<jml> how about I make a minimal example
<vila> yeah, that would help :-/ Orphans are still pretty rare so it's not that obvious to catch errors in edge cases
<vila> jml: but you *do* have 'bzr.transform.orphan_policy=move' in your bazaar.conf right ?
<jml> bzrlib.transform.orphan_policy=move
<vila> (carefully copy/pasted from mine to avoid typos)
<jml> ahh... bzr not bzrlib
<vila> argh, 'bzr' not ... yeah
<jml> ok.
<jml> trying that
<jml> yay
<jml> directory/module.pyc has been orphaned in bzr-orphans
<vila> \o/
<vila> now, you have several options:
<vila> - rm -fr bzr-orphans each time it appears
<vila> - add it to .bzrignore
<jml> oops
<vila> - keep it intact to test that adding cruft there works ;)
<jml> vila: were there any options between "rm -fr" and "keep it"?
<vila>  - add it to .bzrignore
<vila> jml: feel free to mix them ;)
<jml> vila: ok, thanks.
<jml> vila: is there a way I can customize the directory name / location?
<vila> jml: and keep the feedback coming, I'm happy with it myself but I hit it so rarely I don't give myself useful feedback ;)
<vila> jml: not really, one constraint of the implementation is that it should be *inside* the working tree
<jml> vila: hmm ok.
<jml> launchpad has a funny .bzrignore such that anything beginning with '+' is ignored. Hoped I could take advantage of that and save a commit
<elmo> vila: http://package-import.ubuntu.com/status/udev.html#2011-03-15%2021:02:25.173640 <-- is that class of failure mode known?
<vila> elmo: I think so, at least it's not the first time I've seen similar backtraces
<elmo> vila: ok
<vila> elmo: and the link at the bottom of the page is a good way to check that too, in this case... there are far too many >-/
<jam> vila: isn't this http://package-import.ubuntu.com/status/adduser.html#2011-03-15%2022:54:36.634617
<jam> the bug Andrew fixed about sharing transports?
<james_w> yes, but it's not rolled out on jubany
<jam> james_w: ok
<jam> just checking, since it is currently the #1 failure
<vila> jam: needs to be... as james_w said
<vila> james_w: does this sounds reasonable: http://paste.ubuntu.com/583920/ ?
<vila> james_w: AIUI, there are 3 kinds of files involved there
<vila> james_w: 1) the logs (for the mass_import and the packages, bug #719888 asking for them to be grouped)
<ubot5> Launchpad bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,In progress] https://launchpad.net/bugs/719888
<vila> james_w: 2) the status files for the web site
<vila> james_w: 3) the diffs and merges (for debug ?)
<vila> james_w: so putting them in different directories should be a problem (as long as no imports are running when deploying the new scripts)
<vila> james_w: the additional question is: are diff/merges ever re-read by the scripts  (I'm 90% sure they aren't but I'd like confirmation) ?
<james_w> the diffs and merges are the start of replacing merges.ubuntu.com, so need to be served over http
<james_w> they are not re-read
<vila> ohhh
<vila> james_w: so just http://paste.ubuntu.com/583921/ would be fine then ?
<james_w> well
<vila> james_w: the bit I can't find is where the link is made between this directory and the web server itself
<james_w> maybe, depends how apache is configured :-)
<vila> :-D
<vila> james_w: what I'd like to do is separate the logs from the www
<james_w>         DocumentRoot /srv/package-import.canonical.com/new/logs/
<vila> james_w: right, so that could be s/logs/www/ right ?
<james_w> it could be
<vila> james_w: ok, thanks
<james_w> if we don't want to make the logs accessible over http
<vila> james_w: well, if we want to publish relevant data the logs would need to be filtered anyway IMHO
<james_w> why?
<vila> james_w: well, I imagine that users won't be interested by all the details ?
<vila> james_w: or because the raw content won't be pretty enough ?
<james_w> right, but they aren't even linked
<james_w> I don't have a strong preference fwiw
<vila> james_w: indeed, and I understood that the bug was filed because the admins wanted to put the log files elsewhere to better track space consumption ?
<james_w> I don't know
<vila> or did I went too far by considering that the mass_import log files and the import_package log files where in the same category ?
<james_w> I never spoke to Tom about this
<vila> james_w: ok, thanks for the input anyway
<lifeless> for jam/poolie - http://code.google.com/p/snappy/ - we were talking lzo etc back when looking at entropy coding in packs
<bob2> is that the same as zippy?
<bob2> ah, it is
<mgz> finally through most of the interminable python-dev vcs threads and reading poolie's colo post from the other day
#bzr 2011-03-23
<ScottK> poolie: I didn't know about bzr remove-branch when I filed the bug.  Apparently lifeless didn't either as he didn't suggest it ...
<ScottK> So if that had worked, I'd have been happy.
<ScottK> It may just be that bzr on alioth is too old (2.1.5.)
<ScottK> poolie: Does that clarify it?
<poolie> yep
<poolie> actually i answered, and i had forgotten it was now built in
<poolie> maybe robert did too
<poolie> given all this i think it's not an upstream bug
<poolie> do you agree?
<poolie> it's probably not something we would put back into the 2.1 series
<ScottK> I agree it shouldn't be backported.
<lifeless> poolie: hi, https://bugs.launchpad.net/launchpad/+bug/717094 - may benefit from a bzr person eyeballing it
<ubot5> Ubuntu bug 717094 in Launchpad itself "InvalidURL OOPS in translatePath because of URL containing non-ascii chars, again" [Critical,Triaged]
<poolie> hi lifeless
<lifeless> poolie: hi :)
<mgz> that bug description sounds like it's my kind of thing.
<lifeless> mgz: its in the lp bzr codehosting stack
<mwhudson> oh what, i thought i fixed all of them
<lifeless> tada
<mwhudson> oh
 * mwhudson preemptively hates mod_rewrite a bit
<poolie> i'm happy to hand it to either of you
<mgz> ...maybe I'll get a copy of launchpad in may, I've never succeeded in branching it.
<mwhudson> poolie: i think you can keep it :)
<mgz> the bzrlib side seems too strict for urls that might just get entered by hand, I don't see a mod_rewrite fix unless you do something like surrogate-escape does.
<jam> mwhudson, lifeless: sorry I didn't make it back before. Fell asleep while putting my son to sleep.
<jam> Note that the fix for loggerhead (mentioned elsewhere) should probably be using urllib.quote(path.encode('utf-8'))
<mwhudson> poolie: strange that clicking download on the file with chinese characters on http://bazaar.launchpad.net/~czhedu/+junk/hi_baidu_com_xxai/files works though
<jam> rather than cgi.escape()
<jam> since it is URL stuff, rather than HTML content stuff.
<jam> and I wonder if this isn't something similar
<jam> where we are generating a url and escaping it via the wrong transformation
<lifeless> jam: mwhudson: ECHANNEL
<poolie> go to bed jam! :)
<jam> poolie: well, I slept a little bit already
<mr-russ> spiv: are you online?
<spiv> mr-russ: I am
<mr-russ> cool.  I'm the bzr as single user doc patch guy.
<spiv> I just figured that out :)
<spiv> Did my review make sense?
<mr-russ> The reason I wrote the doc is I was one of the users you mention and I couldn't find how to do it.
<mr-russ> Your review makes sense.  However my bzr doc skillz are basically zero.
<spiv> Apparently better than that!
<mr-russ> I get the idea, but I don't know how to build the docs, or view the tags.
<mr-russ> and the :: type stuff, I don't know where I might find out more about that.
<mr-russ> So I'm happy to give it a try, but I feel like I might need a bit of formatting help.
<spiv> 'make docs-sphinx'
<spiv> That should build the docs, you probably need to install some dependencies to have that work
<mr-russ> package hunting now.
<poolie> thanks for adding that mr-russ
<spiv> The format is called restructured text
<mr-russ> It's probably the biggest barrier to switching from svn.  How to do an svn type setup easily on bzr.
<mr-russ> I tried apache route but too hard, danger.  But it was documented mostly :)
<spiv> http://sphinx.pocoo.org/rest.html is a good intro, and http://sphinx.pocoo.org/contents.html in general for the overall documentation tool we're using (sphinx)
<mr-russ> my question/concern about the bzr_ssh_path_limiter is that it's not installed by default.  So it's more work to make it all go.
<mr-russ> I don't even know how to install it under ubuntu.
<spiv> mr-russ: fwiw, the only svn repo I interact with regularly is via a regular ssh account with a real user and home dir etc :)
<spiv> Yeah, that's a good point.
<spiv> I guess the obvious question is where should it be installed?  I suppose /usr/bin would be reasonable
<spiv> (for the Ubuntu package at least)
<mr-russ> /usr/bin is obvious.  lots of debian packages just put contrib in a /usr/share/bzr/contrib type area.
<spiv> But you could install it anywhere, really
<spiv> And just adjust the command="..." config to give the full path to it
<mr-russ> But for this kind of documentation, having it easy for a new user is key from my perspective.
<mr-russ> so if it gets installed by default for 2.4.x, then we can change the command.
<spiv> /usr/share/doc/bzr/contrib would be better than nothing, but not great.
<spiv> I'm happy to avoid mentioning bzr_ssh_path_limiter for now until it genuinely becomes easy
<spiv> (i.e. have it installed somewhere by default)
<spiv> You should definitely fix the missing --inet though :)
<mr-russ> yeah, waiting for doc build to finish.
<mr-russ> My 5 year old laptop is okay, not brilliant.
<mr-russ> how can I improve my markup knowledge?
<mr-russ> :: is an example, is there a reference file, or anything else basic to know.
<mr-russ> spiv: thanks for the review though.  Very helpful.  As you can see I'd like to get this completed :)
<spiv> The links to sphinx.pocoo.org I gave above are probably the best source for docs about the doc system
<spiv> Heh, although their ReST primer doesn't mention ::
<spiv> http://docutils.sourceforge.net/docs/user/rst/cheatsheet.txt, http://docutils.sourceforge.net/docs/user/rst/quickstart.html
<spiv> Specifically for preformatted text with :: -> http://docutils.sourceforge.net/docs/user/rst/quickstart.html#preformatting-code-samples
<spiv> Ok, I'm off for a little bit
<poolie> cheerio spiv, see you in a bit
<vila> hi all !
<mr-russ> my bzr newbieness has got me again.
<mr-russ> I bzr pulled from the bzr branch.
<mr-russ> It says I've diverged and need to merge.  I ran bzr merge and there are all these files for me to commit.
<mr-russ> Should I commit them, but what message do I put?  is there a default merged commit message?
<spiv> mr-russ: "Merge trunk." or similar
<spiv> A commit message is generally used to describe what you did, and that's what you did :)
<mr-russ> thanks.
<mr-russ> my first use of shelving my changes, merge and unshelve.
<poolie> spiv, jam, vila, want to chat in a couple of minutes?
<vila> sure
<jam> poolie: sure
<spiv> Yes, let's :)
<vila> here or mumble ?
<poolie> let's mumble?
<jam> I'm on mumble with spiv
<vila> <shudder>
<jam> vila: same problems today?
<jam> vila: can you hear us at least?
<vila> yup
<mr-russ> okay, my next attempt is up, I'll leave it for you all to review.
<spiv> mr-russ: thanks!
<jam> jelmer: if you're up, we're on mumble
<jam> spiv: your' mic is locking "on" with background noise
<poolie> spiv?
<spiv> poolie: X crashed and apparently took my whole system with it
<poolie> wow
<poolie> insert xkcd joke about '2003 called'
<jam> poolie: did you warn them?
<spiv> (I'm back)
<xarinatan> May i ask a silly simple question? How do i set the remote username in the windows bzr interface? It keeps using my workstation's username, like so http://j.mp/enNaNX
<jam> xarinatan: you can do it in the URL, "http://myuser@host/"
<xarinatan> Ah, thanks, i vaguely heard of that before, but i did user@bzr+ssh://hostname instead ^^; thanks again
<jam> anyone care to second review: https://code.launchpad.net/~mgiuca/bzr/test-log-show-ids/+merge/54199
<ubot5> Ubuntu bug 54199 in zsnes (Ubuntu) "zsnes segfault on startup" [Medium,Fix released]
<jam> I'm actually going to be afk for a while, taking my son to the doctor.
<jelmer> jam: I'll have a look
<xarinatan> is it normal that bzr stays a while in the background after committing, seeming to do a lot of processing?
<xarinatan> http://j.mp/h4CpWR (taskmanager screenshot)
<jelmer> xarinatan: "bzr commit" (the command) should exit right after it's finished
<jelmer> perhaps something else has started it in this case though (e.g. tortoisebzr?)
<xarinatan> jelmer: I used tortoisebzr to commit data to my server, but after that finished and the window closed, that process stayed for a while, 2 processes at first, now they're both gone, just wondering if it's normal
<xarinatan> I gotta say though, i just switched from SVN to BZR and i like it a lot better, SVN simply wasn't usable for my needs (versioned backup for my project/school data sticks) and bloated my data a lot, especially clientside made that unusable for me
<bob2> to be fair, most things are better than svn :)
<xarinatan> Heh, true i suppose, but SVN is sort of the 'standard' these days. Kind of like how IPv4 is still the standard for internet communication :P
<xarinatan> But that could be me
<jelmer> xarinatan: I suspect it's got something to do with how tortoisebzr works, but I'm not sure.
<jam> anyone care to give a second review to: https://code.launchpad.net/~mgiuca/bzr/log-not-in-branch/+merge/53955
<ubot5> Ubuntu bug 53955 in Ubuntu "System time wrong" [Undecided,Invalid]
<Peng> Nice, ubot5.
<jelmer> jam: I'm on it
<jam> jelmer: thanks
<jam> thanks for the earlier one, too
<jelmer> jam: least I could do after all the reviews two weeks ago :)
<jelmer> jam: Did you see the bug I filed about get_revisions / revision_trees / get_deltas ?
<jam> jelmer: sounds hazy
<jelmer> jam: Basically, "bzr log" uses those methods underneath but if one of the specified revids is a ghost the entire method will fail.
<jelmer> the simple solution is to use the singular fetch functions so when we get a NoSuchRevision exception we know which revision is missing
<jelmer> but that obviously has performance consequences
<jam> jelmer: can we do X and then fall back to Y if there is a problem?
<jam> or not easily?
<jam> it shouldn't have the same implications it used to
<jam> we used to be spending all our times deserializing the inventories
<jam> which should be much better now
<jam> jelmer: you're the one packaging meliae, right?
<jelmer> jam: We can't fall back easily as far as I can tell
<jam> have you seen bug #735284
<ubot5> Launchpad bug 735284 in Meliae "Installs from source distributions fail" [Undecided,New] https://launchpad.net/bugs/735284
<jam> i'm just trying to understand who is running 'sdist' and why
<jam> rather than, say, running 'setup.py install'
<jam> I know *I* build the tarball using "bzr export ../foo.tar"
<jelmer> jam: Yep, I'm packaging it for Debian and Ubuntu.
<jelmer> jam: I don't use sdist, the packaging magic simply runs "setup.py install" directly from the packaging branch (which is derived from your trunk with an extra debian/ dir)
<spiv> jelmer: just briefly
<spiv> jelmer: some of the new fetch_spec stuff has a if_present_ids param (or something like that)
<spiv> jelmer: because e.g. when fetching revisions named by tags we want to fetch them if they exist, but not fail if they turn out to be not present in that repo
<spiv> jelmer: perhaps that concept is what that "bzr log" issue needs
 * spiv -> zzz
<jelmer> spiv: We do want to know about missing revisions, since they should still be mentioned in log as being missing
<jelmer> spiv: anyway,  perhaps we can discuss that later. G'night!
<jam> jelmer: we could have 'revision_trees' return None rather than raising an exception, as an example
<jam> possibly by adding a flag so that current users of the api aren't surprised
<jelmer> jam: Yeah, it's the current callers I'm worried about. A flag would work.
<jelmer> jam: Perhaps returning an AbsentTree rather than None, so we can still access the relevant revision id?
<jam> jelmer: something like that seems fine to me
<jam> I thought revision_trees always returned in order
<jam> and most callers zip the input list with the returned values
<jam> I could be wrong
<xarinatan> Hey guys, i'm getting a weird error when trying to commit a lot of data with tortoise bzr http://pastebin.com/XMtwzW0r can someone help me?
<jam> xarinatan: so usually "TooManyConcurrentConnections" is actually a failure somewhere else, that is then covered up by us getting an error while running the cleanup code to handle the original error.
<jam> I'm very surprised to see this happening during the "_rpc_open_2_1"
<jam> since it indicates it is happening before we've even connected to the other branch.
<xarinatan> Weird, i am currently SSH'd into that server with said username and everything seems fine
<xarinatan> I had the same error earlier and i couldn't find out why it did, so i recreated the repository and first checked in a small bit of data, that worked fine
<xarinatan> Small bits of data seem to go fine
<xarinatan> the 'big' commit was ~340MB, 25756 files
<xarinatan> oh wait, apparently the 'small' commit was bigger then i thought, about 720MB
<xarinatan> but only 250 files
<xarinatan> Maybe i'm overfilling some buffers or my RAM if i commit that much files..
<dOxxx> good morning
<vila> hey dOxxx !
<dOxxx> vila: quick question re plugin versions
<vila> yup, fire it :)
<dOxxx> vila: should I be using trunk for all plugins or just the two that didn't work with bzr 2.4b1?
<dOxxx> didn't load*
<vila> hehe, tricky one ;)
<dOxxx> I was thinking I should only do it for hte plugins which didn't load
<vila> the conservative answer would be: switch to trunk when something bad happen
<dOxxx> I don't want to distirbute tip for all plugins and then have to switch back for final release because the author never made a stable release
<vila> the aggressive one would be: always use trunk until we approach the .0 release
<vila> exactly
<vila> plus some trunks may be bogus
<dOxxx> yeah
<vila> on the other hand, we have beta releases to *expose* the latest and greatest
<dOxxx> bleh
<vila> ?
<dOxxx> just an annoying situation
<vila> yeah
<dOxxx> I don't have time to test all the plugins
<vila> I think it's a balance between packagers and plugin authors being pro-active or not
<vila> yup, the installer focused test suite...
<dOxxx> it would be nice
<vila> ... which still doesn't exist :-/
<dOxxx> something that exercises all the bundled plugins to see that nothing blows up
<vila> but indeed would help
<vila> yeah, so, what we currently have is the daily builds which help decide which plugin versions should be distributed
<dOxxx> we do?
<vila> but the ppas imply that *some* version is defined and tracked in a branch
<vila> dOxxx: for Ubuntu yes
<vila> dOxxx: for 2.4b1, I'd say just switch bzr-pipeline to tip
<dOxxx> and svn
<vila> jelmer: is there a 2.4-compatible release for bzr-svn ?
<vila> jelmer: or is the trunk tip good enough to embed in the 2.4b1 OSX installers ?
<xarinatan> Can someone point me to what i should change or how i can fix this error: http://pastebin.com/XMtwzW0r ? small commits are fine (<1000 files) but large commits seem to give that error
<maxb> The implication is a bug in bzr, but that's not something I've ever seen.
<vila> xarinatan: there nothing obvious there, file a bug at http:/pad.lv/fb/bzr
<vila> xarinatan: that would be easier to track progress and ask you for more details
<xarinatan> vila: Okay, i'll do that then.
<vila> xarinatan: the weird thing is that the *size* of the commit shouldn't matter...
<vila> xarinatan: the only vaguely similar issue I can think of was one related to ssh key renegotiation when reaching a 1GB threshold (on transmitted data) but 1) I'm pretty sure launchpad has some specific config that was exhibiting it 2) the symptom was different
<vila> xarinatan: did you look at the .bzr.log on the server ?
<xarinatan> Well it's only 70MB of data, but nearly 10,000 files
<xarinatan> 'small' commits of 720MB with only 250 files go through just fine
<xarinatan> So i'm suspecting some buffer overflow maybe?
<vila> xarinatan: add the relevant parts of the .bzr.log from client and server to the bug report, there may be something there
<vila> xarinatan: there are bigger projects (in terms of # files), but 720MB for 250 files sounds big, any binaries there ? (Shouldn't matter either..)
<xarinatan> Some archive(zip) files and images, i was planning on using bazaar as 'versioned backup system' for my School and work project data sticks, which both hold about 5 gigs of data, of which most is 100% original content created by me, so for that this system would be perfect if it works ^^;
<xarinatan> I have a lightweight ubuntu virtual machine setup at home for the data storage
<vila> xarinatan: hmm, there was a report recently about some weird ssh issues when using NAT for a VM
<xarinatan> Where can i find the .bzr.log file btw?
<vila> what virtualization software are you using ?
<xarinatan> It's not NATted
<xarinatan> I'm using KVM
<xarinatan> I'm logging in through OpenVPN..
<dOxxx> `bzr version` will tell you where your log file is
<vila> xarinatan: like dOxxx said, but make sure you run it on the server with the same settings as the user connecting there
<xarinatan> what do you mean by 'same settings'?
<vila> xarinatan: just do 'ssh user@host  bzr version' and you should be fine
<xarinatan> Oh! That could be it, i'm using the default ubuntu repos for the bzr installation, those might be a bit behind on the actual version
<xarinatan> Hah, yes, stupid me, the server is running 2.2.1 and i'm running 2.3.1 on the client ^^;..
<xarinatan> Weird that it works with smaller commits though
<vila> xarinatan: still worth reporting as a bug mentioning the client/server versions involved
<xarinatan> villa: Will do
<vila> xarinatan: this should be supported, servers can't always be upgraded as fast as clients and they are supposed to be compatible
<vila> xarinatan: it's not even sure that upgrading the server will address the issue
<vila> good afternoon mgz ;)
<xarinatan> I'll check if it fixes it =p
<vila> hmmm, how much memory does your VM server has ?
<vila> mgz: before your patch, can you remember me how memory errors were reported from a smart server ?
<vila> xarinatan: hmmm, how much memory does your VM server has ?
<vila> bleh, 'how much memory on the VM server' is probably better english :-/
<Peng> I'd go with "how much memory does it have".
<vila> rats, thanks Peng ;)
<fullermd> "does it have the geebees?"
<dOxxx> hmmm just thinking about it now... the rules on when to use 'has' vs 'have' are not clear
<dOxxx> I have. You have. They have. It has. vila has. the server has. how much does it have?
<dOxxx> really not predictable
<fullermd> 'has' is third person...
<vila> fullermd: geebees like the shaddoks friends ?
<fullermd> I have.  You have.  He/she/it has.
<dOxxx> so why then is "how much does it have?" correct?
<vila> fullermd: http://en.wikipedia.org/wiki/Les_Shadoks says it's spelled Gibis (even in english) so probably not ;)
<dOxxx> I guess there are exceptions.
<fullermd> Ugh, I've forgotten too much linguistics to explain it.  It's not a subject verb there...
<dOxxx> oh hmm I see
<dOxxx> the ver is 'does' in the sentence
<dOxxx> verb*
<vila> and when should it be "does it had" vs "does it have" ?
<dOxxx> never
<fullermd> It's not a participle, it's something related.
<dOxxx> it would "did it have" for past tense
<dOxxx> be^
<fullermd> I'll go with "languages are all stupid" for $300, Alex.
<xarinatan> Sorry, back, upgraded BZR on the server in question
<xarinatan> And the VM has 1GB RAM and 1GB Swap, previously had 256MB RAM but that was obviously not enough when i committed large files :P
<fullermd> Also related: http://www.qwantz.com/index.php?comic=1915   :p
<jam> anyone in the US or AU that can run a script for me? I'm trying to see how long interactions take with Launchpad from various locations
<xarinatan> Also, isn't it "How much does your server have?"? I'm dutch, i don't remember exactly how the rules were taught back in highschool, but surely it had some correlation to what form was used
<beuno> jam, Argentina any good?
<jam> http://paste.ubuntu.com/584285/
<jam> beuno: would be good for me
<jam> beuno: can you run the above paste ?
<dOxxx> xarinatan: yes 'have' would be correct, we were just trying to figure out why :)
<beuno> jam, running
<jam> beuno: I'm seeing 300+ms from Netherlands, which seems pretty crazy long.
<vila> 10 loops, best of 3: 330 msec per loop from here
<fullermd> Maybe it is a [present] participle...
<vila> fullermd: hehe nice comic ;)
<fullermd> 10 loops, best of 3: 897 msec per loop
<beuno> jam, 10 loops, best of 3: 1.87 sec per loop
<jam> beuno, fullermd, vila: that is the time to resolve "lp:bzr" into a bzr+ssh url
<xarinatan> dOxxx: your ____ have, it's a property of someone else. . oh well, i'm not linguist :P I'll leave that upto people who actually study the language
<vila> jam: I'm sure you've know found a great way to stress test the forking server ;-D
<vila> s/know/now/ :-(
<jam> vila: no, that is the XMLRPC server
<jam> vila: https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523
<ubot5> Error: Launchpad bug 2 not found
<jam> if you want that time to go away
<vila> jam: nm, the joke was lost
<dOxxx> xarinatan: yeah something like that. possessive.
<jam> vila: it would have been better if we actually logged in
<beuno> jam, that's pretty crazy
<fullermd> (LP being ~125ms from here)
<fullermd> So a mere 7 round trips...
<xarinatan> vila: I'm currently doing a commit with the upgraded version on my server, see if it makes a difference
<xarinatan> vila: It looks like it's working this time, with about 12,000 files
<fullermd> vila: Everybody loves Dinosaur Comics, don't they?   :p
<jelmer> hmm, something is eating PQM emails again for me :(
<xarinatan> jam: Are you from holland btw? Since you mentioned the netherlands
<jam> xarinatan: I'm actually from the US, but I'm living in Netherlands for a couple years.
<jelmer> jam: I thought launchpad supported short names for http as well these days. Certainly bzr log http://code.launchpad.net/bzr works for me.
<jam> my wife got a promotion and temporary training here
<jam> jelmer: it works for Loggerhead, but not for 'bzr branch'
<fullermd> I had to kick jam out of my $TZ; he was making me look bad with all that "getting up at a reasonable hour" stuff   :p
<xarinatan> jam: How's the language for you? :P I heard some people who tried to move over to here complain about it a lot
<jam> xarinatan: I know almost no dutch. It happens that we live in Eindhoven, where 90% of the people work for Philips, who mandates English on campus
<jam> I'm exaggerating slightly, but I haven't had a problem getting people to talk to me in English
<jam> except for the ones that stop asking for directions while I'm walking down the street.
<jam> why are they picking me? :)
<xarinatan> jam: Aha, well that's nice too, though most of the 'dutchies' speak english anyway ^^;
<vila> jam: cos' you're walking and not using a car ? :-D
<jam> vila: so are they
<jelmer> jam: Hah, so I guyess you already make the impression you look like you belong ? :-P
<jam> but I'm also walking with my son
<jam> so maybe I'm safe
<xarinatan> jam: You must be secretly dutch! :P
<jam> jelmer: It happened to happen 2 times over the weekend
<jam> xarinatan: german descent...
<jelmer> jam: it works for bzr branch for me too ("bzr branch http://code.launchpad.net/bzr ~/tmp/bzr")
<xarinatan> jam: Same difference, except everything sounds like a curse there, i love german xD
<vila> jam: yes, that's why they can stop you ;-D
<vila> jam: but, jokes aside, the kid part is probably the trigger
<jam> vila: yeah, that was my guess
<jam> you don't look much like a tourist when you have a kid with you
<jam> though if you hear him chattering away, they would know better
<vila> hehe
<dOxxx> jelmer: I may have missed your reply but should I be using bzr-svn trunk tip for bzr.2.4b1?
<jelmer> dOxxx: ah
<jelmer> dOxxx: yes
<dOxxx> ok
<jelmer> two more bugs to fix before 1.1.0
<jam> jelmer: speaking of which, new development in the dutch saga. We just found out that Customs won't actually let our goods through until April 1st. And our lease for short-term apartment ends on the 31st. Just silly given that they arrived before we did a month ago.
<vila> jam: regarding https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523
<ubot5> Error: Launchpad bug 2 not found
<vila> jam: nice one :) But one question:
<vila> what are the risks that we diverge from lp ? (0 ? We were already making assumptions about the lp implementation ?)
<jelmer> jam: wtf? This is the Dutch customs?
<jam> jelmer: yep.
<jam> I guess part of the issue is they can't start the paperwork until we get here and get BSN numbers, etc
<jam> which takes a wek
<jam> week
<fullermd> I told you trying to smuggle in those kidneys would be trouble...
<vila> jam: how tasty for an April 1st hoax...
<jam> vila: you can follow the bug
<jam> but LP explicitly implemented "+branch/foo" so that we could use it
<jelmer> jam: And I thought moving to the US was hard (a friend of mine is moving from Eindhoven to CA)
<jam> very low chance we'll diverge
<jam> especially since it will start breaking for people once we stop using xmlrpc :)
<jam> jelmer: well, there are quite a few things that could have made it smoother. Having my bank in the US allow scheduling international wires without being physically present.
<jam> What's funny is that most of the Expat stuff from Eindhoven was very fast
<jam> and they have a huge Expat center in the middle of town
<jam> so its something they supposedly care a lot about
<jelmer> jam: Ah :-/ How's that going, is the bank still holding up your cheques?
<jam> (30% tax free income for my wife, etc)
<jam> jelmer: yep
<jam> we have confirmation that it made it to Amsterdam, a *week* after we gave it to the local bank
<jam> apparently they operate by carrier pidgeon
<jelmer> heh
<jelmer> a courier walked to Amsterdam perhaps?
<fullermd> It went by boat.  For security reasons, y'know.
<briandealwis> Hi everybody.  I have a private branch that I want to amend a couple of commit messages before pushing to a public branch.  I should know this, but is there a plugin for rewriting a commit message â knowing that it'll destroy history?  Or is there an alternative beyond merging each commit one at a time?
<jelmer> briandealwis: you should be able to fastexport the commits, edit the stream and reimport
<maxb> jelmer: "I'm able to branch from https://code.launchpad.net/bzr-svn ." ..... really!?!? Does not work for me and I cannot see how it would.
<jelmer> maxb:
<jelmer> charis:~/src/hydrazine/trunk% BZR_PDB=1 bzr branch --no-plugins https://code.launchpad.net/bzr-svn ~/tmp/bsa
<briandealwis> jelmer: hmm, there's 16000-odd commits...
<jelmer> Branched 3647 revision(s).
<dOxxx> briandealwis: you can also, with some effort, combine uncommit and shelve to reverse your commits and recommit them with updated messages.
<briandealwis> dOxxx: that's a good idea.  thx
<jam> maxb: code.launchpad.net/bz-svn has a 'BranchReference' pointer at
<jam> ttps://code.launchpad.net/bzr-svn/.bzr/branch/location
<jam> https://code.launchpad.net/bzr-svn/.bzr/branch/location
<maxb> ahh! (And it is probably being broken by one of the foreign bzr plugins, then)
<jam> maxb, jelmer: that was how we implemented lp:foo before the XMLRPC was added
<jelmer> maxb: Yeah, bzr-hg breaks it
<jam> jelmer: because it inserts itself earlier in the stack?
<jelmer> jam: ah, I wasn't aware of that
<jelmer> jam: yep
<maxb> Is there a reason why we don't always probe for bzr-native formats first?
<jelmer> jam: is there any reason to prefer XMLRPC over the branch references? It seems in case of the branch references it's possible to keep the same HTTP connection
<jam> jelmer: I mentioned on the bug, it also involves an SSL request in what would otherwise be pure-HTTP
<jam> jelmer: not possible
<jam> different top-level domain, and HTTPS vs HTTP
<jelmer> maxb: the bzr smart server does a POST request and that blows up on several foreign servers (e.g. google code errors with a 401)
<jam> so you can't re-use the connection
<jelmer> jam: ah, argh :-(
<vila> jam: just re-read the bug (bunch of pages ;) and it mentions the http urls too, may be you should clarify the situation in a bug comment before closing the bug
<maxb> It seems like it would be nice to allow foreign plugins to attach fallback probing after such a failure
<jelmer> maxb: that's been discussed a couple of times on the list
<jelmer> maxb: and there's a bug about it
<jam> jelmer: yeah, I think the issue is that there are *valid* cases where a server would issue 401 (that is Auth required, right?) in response to POST
<vila> jam: or may be just file a new bug so your proposal is not blocked on the http discussion
<jelmer> jam: right
<jam> jelmer: seems like it would be nicest to have a whitelist/blacklist of known sites that use X format.
<jam> or just remember the last one to succeed and use it first next time
<jelmer> jam: I think we should try to avoid the POST unless we know there is bzr at that site
<jelmer> jam: e.g. check for .bzr/branch-format, then try the POST and if that fails fall back to use with the format directly
<jam> jelmer: but how do we *find out* (and arguably, it adds a round-trip overhead for what we want to be the fast case)
<maxb> Encourage people to use bzr+http, hg+http etc?
<jam> maxb: we had svn+ and I guess people really didn't like it
<jelmer> maxb: I think a single very small HTTP request is worthwhile overhead to not have to type foo+
<vila> jam: the issue that was discussed made it clear that POSt was also forcing an additional round-trip (and led to failures)
<jelmer> it is still always possible for people to use bzr+http://.... if they care about that roundtrip
<vila> jam: the situation today is that people that install foreign plugins *do* an additional round-trip *before* trying the POST
<jelmer> right now we do one extra roundtrip per foreign VCS plugin that's loaded before we probe for bzr formats
<vila> yeah, per plugin even ;)
<maxb> I think we should do the POST .bzr/smart, and if it fails, give plugins a chance to try things, and if none succeed, continue raising the original error
<jelmer> maxb: that doesn't work, as the POST can trigger a username/password prompt
<maxb> gah
<vila> and that's without mentioning walking up the url to find the format ?
<vila> or is it only after we successfully found the branch format ?
<jelmer> vila: yes, though generally people don't specify inside-branch paths for remote URLs
<jelmer> vila: that's something we could make better though - there's no need to walk down for SVN branches for example
 * vila nods
<dOxxx> looks like bzr 2.4b1 is happy with trunk versions of svn and pipeline
<dOxxx> or at least they pass the `bzr plugins` smoketest
<dOxxx> uploading...
<vila> dOxxx: \o/
<jelmer> jam,vila: Actually, if a user specifies a URL that doesn't contain a .bzr dir it's quicker to check for .bzr/format first because then we can skip the dumb format check before descending one level
<jelmer> though I'm not sure how much we care about that use case
<dOxxx> it's murdering my remote desktop connection to work though XD
<jam> jelmer: there is no .bzr/format, there is .bzr/branch/format and .bzr/branch-format
<xarinatan> Just submitted the bug report regarding the large amount of file issue from 2.3.1 clients to 2.2.1 servers https://bugs.launchpad.net/bzr/+bug/741015
<ubot5> Ubuntu bug 741015 in Bazaar "BZR crashes when large amounts of files are committed through TortoiseBZR over bzr+ssh from 2.3.1 client to 2.2.1 server." [Undecided,New]
<jelmer> jam: Sorry, I mean .bzr/branch-format
<jelmer> I still think that's an odd name for something that actually describes the control dir format, but I guess that's for historical reasons?
<jam> jelmer: ideally we would have a proper probe to .bzr/smart to get the full branch + repository at any given level. It is certainly one of my pet-peeves that we have about 10 round trips just to say "yes you have a Branch"
<jam> jelmer: yeah, we had it before we did the split out
<jam> and by keeping the name, old clients can say "I don't know what branch format this is" rather than saying "I don't see a branch"
<jam> of course, it has been 4 years since we had clients that didn't know about MetaDir :)
<jam> but also no push to actually change it
<jam> vila: is there any way to instrument the XMLRPC stuff? It looks like the current lp: resolving code is going to an https server
<jam> which is where all the overhead is
<jam>            1            0      1.1641      1.1641   <built-in method do_handshake>
<jam> which is part of the ssl module
<jam> the stack goes through our _urllib2_wrappers
<dOxxx> I must revisit my qbzr branch for the mergetool stuff so that it can be bundled into bzr 2.4
<vila> jam: -Dhttp from command-line, for more stuff see DEBUG in _u2_wrappers 1 for basic stuff 9 for all
<jelmer> jam: It would be nice if we could do that without a POST request..
<jam> jelmer: "do that without" ?
<jam> probe for whether there is a smart server?
<jelmer> jam: Probing to .bzr/smart
<vila> jam: but I don't think you'll get timings from that
<jam> vila: I have -Dhttp set, and it doesn't seem to see the XMLRPC stuff
<jam> vila: I'm wrong, it is in the log
<jam> just hard to find
<vila> may be because it use a cutom Request ?
<jam> it looks like we explicitly only make the request to xmlrpc.launchpad.net:443
<jam> vila:         LAUNCHPAD_INSTANCE[instance] = 'https://xmlrpc.%s/bazaar/' % domain
<jam> it looks like at some point we recently updated the launchpad lp_registration plugin to make its requests via SSL
<jam> which adds a rather significant amount of overhead
<jam> in my lsprof timing, it is 1.2s
<jam> which is far worse than the 300ms or so if you do it in a loop
<jam> vila: do you automatically get connection sharing via our urllib2  enhancements?
<jam> or do you have to save some object to get that?
<vila> from what layer ?
<dOxxx> vila: osx installer uploaded and changes on trunk committed. I haven't branched for 2.4 yet.
<vila> dOxxx: ok, I was wondering about that, do you plan to create 2.4 branch or should we wait for the 2.4.0 release instead ?
<dOxxx> I think I'll wait
<vila> ok
<jam> vila: I was just wondering if my looping xmlrpc stuff was connection sharing
<jam> which would explain why it looks like 1.2s real world time, but the loop shows it as 300ms
<vila> haaa, well, I looked briefly at the lp_directory stuf but I'm not even sure it uses _u2_wrappers there...
<vila> and you need to poke hard at urllib2 to use persistent connections (unless things have changed in recent python versions but I really doubt it)
<vila> jam: you can copy httplib.py and patch it (that's what I did pas then), there should be a debug or DEBUG variable or attribute somewhere
<vila> s/pas/past/
<jam> vila: then it most likely isn't a persistent connection thing
<jam> we create a new LaunchpadRequest object, etc. each time
<jam> there isn't any cache state in LaunchpadDirectory
<jam> and I'm not trying to make it faster, I'm trying to skip the ssl handshake entirely :)
<vila> use http :)
<jam> jelmer: your first report about bzr-git not allowing --excludes :)
<jam> lucky you (bug 403811) why is it showing up as NEW for me
<ubot5> Launchpad bug 403811 in Bazaar "commit with record_iter_changes should support exclude" [Medium,Confirmed] https://launchpad.net/bugs/403811
<jam> ah, it is just connecting it to the debian bug
<jelmer> yep
<jelmer> hmm, I wonder if the cleanup.OperationWithCleanup could be useful as a decorator
<jelmer> vila: I'm getting test failures during 2.4b1
<jelmer> 3 instances of IllegalUseOfScopeReplacer and a remote upgrade command that takes fewer requests than expected
<vila> O_o context ?
<jelmer> vila: I'm trying to build the 2.4b1 packages, currently trying to figure out what we're doing differently in the packaging to trigger those errors
<vila> ha, at least you don't get the failures locally ?
<jelmer> well, I get them locally but only when run in my debian sid chroot using the packaging arguments (disabling the launchpad plugin, for example)
<vila> with --no-plugins ?
 * vila running B_P_P=-site to see
<vila> jelmer: right, can't reproduce here :-/ Any more hints ?
<briandealwis> jelmer: I'm doing a dpush to push up 4 small revisions with bzr-svn to a server (first time ever dpushing here).  There's a message: "Storing Bazaar metadata in file properties. Use `bzr dpush` for lossfull push without file properties.Upgrade the server to Subversion 1.5 or later to use (less visible) revision properties.", and it seems to be transferring the world: almost 300MB so far.
<briandealwis> jelmer: is this expected?  It's a big deep tree (16k revisions).
<briandealwis> jelmer:  and I don't know what version it's running remotely, and can't see how to find out
<vila> jelmer: got the one failure in bb bzr info you fixed lately with --no-plugins
<vila> jelmer: are you trying to run with --parallel ? (just checking, I did my run with --parallel=fork anyway)
<jelmer> vila: yes, this is with --parallel
<jelmer> I haven't reproduced it outside of the package scripts yet
<vila> jelmer: any idea of the number of processes involved ?
<jelmer> vila: it'd be 4 processes. The env variables we set include: BZR_HOME=debian/bzrhome \
<jelmer> 	BZR_PLUGIN_PATH=-site:-user \
<jelmer> 	BZR_DISABLE_PLUGINS=launchpad \
<jelmer> briandealwis: what version of bzr-svn?
<briandealwis> jelmer: 1.0.4
<vila> jelmer: I always run with 8, but there was failures loooong ago when using different numbers (because it slices tests in different ways, this may trigger different isolation test bugs)
<briandealwis> It sounds very much like the problem described here: http://web.archiveorange.com/archive/v/mvjb49H5gqOiXreQjtmn
<vila> jelmer: -user is useless here ;) Why do you disable launchpad /
<vila> ?
<jelmer> vila: the launchpad plugin tests connect with launchpad
<vila> grrr, sorry, forgot it again :-/
<briandealwis> jelmer: I interrupted it after 500mb; it pushed 3 revisions up.  Pushing the final revision was very quick.  Very bizarre.
<jelmer> briandealwis: there's a bug about that, fixed in trunk
<briandealwis> jelmer: ah great!
<jelmer> vila: http://pastebin.ubuntu.com/584355/
<vila> jelmer: right, so 'ui' is involved in all cases so probably the same root cause
<jelmer> vila: ui? I thought it was branch
<vila> well, not in the pastebin you just paste AFAICS
<vila> errr, except for the first failure >-/
<vila> s/failure/error/
<jelmer> and the last
<jelmer> I hate how we catch all exceptions during upgrade :-/
<jelmer> I'm not entirely sure how to deal with these scope exceptions though - these imports seems perfectly reasonable to me
<vila> old == _mod_branch.BzrBranchFormat5 ... I'm not sure you're allowed to do that with lazy objects (jam ?)
<jelmer> it's been like that forever though, we haven't touched it in the last few cycles
<vila> jelmer: unfortunately, that's irrelevant :-/ There could be side-effects with lazy loading
<jelmer> ah, I see
<vila> jelmer: the bright side is that you're exposing genuine bugs in our imports here :-/
<vila> jelmer: as generally fixing these bugs is adding the right import in the right place.... :-}
<jelmer> vila: what worries me is that these are hard to reproduce :-/
<vila> jelmer: I know :-( Not using --parallel may work around the issue in the mean time
<sidnei_> uhm, is there any change with plugins in bzr trunk? i installed the daily build and now my custom plugins don't seem to be registered anymore
<sidnei_> oh, maybe they are not compatible with the api version and didn't get loaded or something
<vila> sidnei_: probably, but this didn't happen yesterday, more like several weeks ago (unless the daily build has been failing for some time ?)
<sidnei_> vila, i installed the daily build today to check out jam's fixes
<vila> sidnei_: right, but when was your previous install ?
<sidnei_> vila, i haven't used daily builds, not since i reinstalled from scratch several weeks ago. i was running 2.3.0 before.
<vila> ha ok, then yes, the API have changed
<vila> well, if your plugins *test* the compatible API that is
<briandealwis> I'm in a situation where I have a codebase where I need to make some patches for the code to work locally within my IDE.  These patches shouldn't be committed.  But shelving and unshelving them before a commit is a bit painful.  Pipeline/loom doesn't seem the right fitâ¦  Any suggestions?
<briandealwis> mm, I guess I want something like Darcs' ability to reorder patches
<ryan_scott> I have to use a different VCS for work reasons, but am really missing the bzr visual diff tool.
<ryan_scott> Does anyone know if it can be called by itself?
<beuno> ryan_scott, which one is that?
<beuno> meld?
<ryan_scott> Whatever is the default for bzr on the windows client.
 * beuno doesn't do windows
 * ryan_scott used to not do windows and was happier about it.
<ryan_scott> Specifically I miss doing development on Linux
<jam> lifeless: sometime I'd like you to take a look at a possible race issue for concurrent fetching into a pack repository.
<jam> My bug comment is here: https://bugs.launchpad.net/bzr/+bug/709349/comments/13
<jam> but the basic summary
<ubot5> Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,Incomplete]
<jam> 2 bzr processes are run concurrenty to fetch from the same branch into the same repository.
<jam> Both of them are thus fetching exactly the same content, but since they start concurrently, neither one sees that the other is doing the work
<jam> when one finishes, it adds the pack to the repo
<jam> (renames it into packs, updates pack-names)
<jam> it then goes to autopack, and sees that this new pack needs to be moved to obsolete packs
<jam> so it removes it from pack-namse, but has not renamed it to obsolete yet
<jam> the second process then sees "ok, I'm done fetching, let me put this new content into the repo"
<jam> "oh look, it isn't already presenT"
<jam> renames it *over top* of the existing pack file
<jam> updates pack-names to add the new file
<jam> process 1 finishes and renames the newly re-added file to obsolete_packs
<lifeless> jam: kk; I just got off a call; I'll look right after breakfast
<jam> lifeless: no problem. I'm heading out.
<jam> I just wanted a second opinion since you did a lot of the pack danec
<jam> dance
<jam> lifeless: the key is 2 fetches doing identical content concurrently, I think
<lifeless> nice
<lifeless> sounds plausible
<lifeless> damn concurrency is hard
<LeoNerd> Someone remind me... having accidentally killed a branch by overwriting a pull... how do I get it back? I can see it in  bzr heads --dead
<soren> LeoNerd: bzr pull . -r revid:your_rev_id
<LeoNerd> Hrmmmm.. it claims it's diverged...
#bzr 2011-03-24
<soren> --overwrite :)
<spiv> Woah, jam's change to resolve lp:foo locally stops automatic stacking from working
<spiv> https://bugs.launchpad.net/bzr/+bug/741375 filed
<ubot5> Ubuntu bug 741375 in Bazaar "r5736 to resolve lp:foo URLs locally prevents automatic stacking of new branches pushed to Launchpad" [Critical,Confirmed]
<lifeless> is lp bug I think
<lifeless> spiv: ^
<spiv> lifeless: maybe!  I agree it's a server-side bug, but not sure if it's in bzr or lp
<lifeless> spiv: if lp isn't sending the hint to bzr, its lp
<spiv> Perhaps that's enough reason to add lp to the bug, I certainly don't mind if you do
<lifeless> done :)
<spiv> Ta :)
<mwhudson> er
<mwhudson> oh right, i bet we don't do the magic we need to at +branch/~user/product, just at ~user/product
 * mwhudson looks at launchpad's translatePath, grumbles
<mwhudson> oh no, it's not as silly as i feared
<mr-russ-work> What the deal with the patch manager spelling my name wrong.
<mr-russ-work> spiv: can you correct the spelling of my name?
<poolie> thanks for the bug love spiv
<poolie> i think i got us to 0 new yesterday
<spiv> mr-russ-work: oop!
<spiv> mr-russ-work: oops!
<spiv> mr-russ-work: that would be my fault :(
<spiv> mr-russ-work: I can add a new commit on top with a message like "Correction: r5739 was contributed by Russell Smith."  Hmm, I should add a release-notes entry about the change too, I could do that in the same commit
<mr-russ-work> thanks.
<mr-russ-work> Otherwise, I'm happy that landed merged for 2.4.
<spiv> mr-russ-work: ok, new commit on its way to PQM
<spiv> Me too!
<jam> spiv: did you track down anything with the bug?
<jam> I have some ideas, but I don't want to overlap too much
<spiv> jam: not yet
<poolie> hi jam
<poolie> jam do you know off hand if we include the inum in the dirstate hash?
<lifeless> inode? pretty sure not
<lifeless> poolie:         return _encode(_pack('>LLLLLL', st.st_size, int(st.st_mtime),
<lifeless>             int(st.st_ctime), st.st_dev, st.st_ino & 0xFFFFFFFF,
<lifeless>             st.st_mode))[:-1]
<poolie> so yes
<vila> hi all !
<jam> poolie: if you mean inode, then yes
<jam> st.st_ino
<jam> poolie: we've talked about not including st_dev or st_ino
<jam> we just never changed anything
<poolie> yep
<poolie> hi vila
<vila> hey poolie ;)
<jam> poolie: I think a lot of that was stuck in the "next dirstate revamp"
<jam> where we also wanted to get away from base64
<jam> in favor of just %X, etc.
<poolie> right
<poolie> some of them, like ctime, could be done incrementally
<jam> poolie: I think we wanted to switch to max(ctime, mtime)
<jam> partially because ctime means something completely different on Windows
<jam> and partially because it seemed silly to always check 2 times, when of course only one will ever win
<poolie> i think ctime there is creation time
<poolie> using the latest would still be invalidated by hardlinking
<poolie> which updates the ctime
<jam> poolie: on Windows ctime == creation, on Linux ctime == last time metadata was updated.
<poolie> right :)
<jam> anyway, the point is that our check is (if mtime > X or ctime > X)
<jam> we can just do (if max(mtime, ctime) > X)
<jam> and then we can store 1 less field per file
<poolie> yes, that would be equivalent, but it wouldn't fix the bug abentley just mentioned
<jam> poolie: it isn't in my traceback here, is it on a different channel?
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/741515
<ubot5> Ubuntu bug 741515 in Bazaar "dirstate validator includes ctime" [Medium,Confirmed]
<jam> poolie: so certainly there is the idea of do we need "mtime != old_mtime or ctime != old_ctime", it is a question of worth, though.
<jam> If someone does tricks with hard-linking, we can ask them to do "touch" as well
<jam> I though hard-linking updated ctime
<jam> and I should correct myself. ATM I believe we do check if mtime == cached_mtime, and just have a (if now - mtime < 1s, don't cache)
<jam> certainly we expect a change today to be noticed by 'bzr status' tomorrow
<poolie> one of us is confused
<poolie> hard linking does update ctime
<jam> #1, I don't know the bug you are mentioning
<jam> you said "yes, that would be equivalent, but it wouldn't fix the bug abentley just mentioned"
<poolie> ah ok
<jam> I don't know what that bug is
<poolie> i just filed it based on aaron's comment in the big colo thread
<poolie> which was essentially that 'bzr branch --hardlink' has the substantial drawback that
<poolie> the next operation in each of the trees will need to rescan them
<poolie> since making the hardlinks invalidates the dirstate
<jam> poolie: well, there is already a bug, that the "bzr branch" target already needs to rescan the tree. But I see your point. You only created a new hardlink on the source, and now it needs to be rescanned.
<jam> I don't think we can ignore ctime, though
<jam> because that is how you see 'chmod' changes.
<jam> you could say "only look at ctime for mode info, and only mtime for content'
<jam> but I think that is just getting spun around
<jam> too many rules makes it hard to predict behavior
<poolie> well
<poolie> checking the mode is as cheap as checking the timestamp
<poolie> there is no point cachingi t
<poolie> i agree we don't want too many rules though
<jam> poolie: the issue is how much stuff do you want to put into the "is this changed" function
<jam> I think we do some filtering at a fairly low level
<jam> but yes, we don't need to use ctime to check mode
<poolie> i think it would be sufficient to just cut ctime out, which would make it simpler
<poolie> but, i only marked it Medium importance
<poolie> thanks for grabbing the lpurl thing
<poolie> even if it hit a snag
<poolie> i'd been meaning to try that forever
<jam> poolie: well, since it isn't on our side, it is tricky :)
<jam> but yes
<jam> I was surprised to see it be >1s on my machine here
<jam> because of the ssl handshake now
<poolie> >1s going to lp.dev?
<jam> I'm not sure when we switched to https://xmlrpc
<jam> but it certainly shows up in the logs
<jam> doing "bzr push lp:" has *2* handshakes
<poolie> why?
<jam> poolie: we ssl handshake to https://xmlrpc then SSH handshake with bzr+ssh
<poolie> oh, ssl and ssh
<poolie> i thought you meant two on ssl
<jam> no, just 2 handshakes that each take 1+s to complete before we can send a few bytes of actual content
<jam> poolie: are you going to be around? It seems you should be off frolicking in the sunshine right now?
<jam> Just some thoughts about the lp: stuff I wanted to run by you
<poolie> not much 9pm suntime at this time of year
<poolie> indeed not at any time of year in sydney
<poolie> so go for it
<poolie> S is away this week and next
<poolie> i was trying to decide if i was hungry
<jam> poolie: :) I know the feeling
<jam> poolie: I'm trying to work out how much validation we should do in the local resolution
<jam> right now, I'm thinking that if the url doesn't conform to exactly what I think it should, then I just punt and tell it to resolve against LP to give a proper error
<poolie> that sounds pretty good
<poolie> you mean you fall back to the existing behaviour?
<poolie> i think it would be good to make sure eventually that the exact same behaviour the xml service gives you is also available over ssh
<poolie> but obviously that requires server changes
<poolie> i'm just writing to elliot about who should do bfbip and when
<poolie> it seems like lp is pretty queued up; we _could_ but i don't know if that would be a good idea
<jam> poolie: yeah, lp teams do seem pretty "fully booked"
<poolie> yeah, and even for the things they have taken on, they seem to run long
<jam> poolie: Right now I'm doing some validation of what I get from XMLRPC vs what I get doing it myself
<poolie> as does everybody, probably
<jam> poolie: projects generally scale to the time you have allotted them, + some percent :)
<jam> It is rare that there isn't *something* more that you could do if given the time
<jam> poolie: so for lp: resolution, the only thing I see right now, is that XMLRPC validates the 'distribution' part
<jam> for "~jameinel/ubuntu/XXX/bzr/foo"  Iget "No such distribution series" from XMLRPC
<poolie> oh, the distroseries, not the distribution
<jam> If I do a bunch of other permutations, I get errors that are obvious
<poolie> so if you just mechanically map it, you'll just get 'not found' or 'permission denied' from ssh?
<jam> poolie: probably, I haven't actually tried on all of them
<jam> note that you can do (today)
<jam> bzr info lp:ubuntu/foo/bar/baz/bing/blah
<jam> and it will resolve to +branch...
<jam> and then give "no such branch"
<jam> it is only if you add a ~user that it tries to validate the URL as much
<poolie> so, i would be inclined to just mechanically locally transform them to bzr+ssh://..../+branch/$1
<poolie> and then treat anything where that does not behave well as an lp bug in lp-serve
<poolie> unless it goes horribly wrong
<jam> lp:~jameinel/ubuntu/natty/bzr/foo/bar
<jam> also resolves
<poolie> validation at the xml server is redundant
<poolie> what was the bug about stacking?
<jam> poolie: sure, I think it meant to be about giving the user nicer error messages
<jam> poolie: the stacking bug is that there isn't a bzr control dir in +branch/~user/project/.bzr
<jam> so it dosen't tell +branch/~user/project/branch/ to stack
<jam> there *is* one in the virtual ~user/project/.bzr
<poolie> huh
<poolie> what is there?
<poolie> is it more like a redirect, or an alias?
<jam> poolie: just a .bzr/config I think, with a message "you should stack on DEV_FOCUS"
<jam> poolie: so when bzr searches up to see if there is a containing repo/etc, it sees the config telling it "this is how you want to act"
<maxb> A control.conf, no?
<jam> I'm sure it is a virtual folder as well, and could just be added to +branch/~user/project/
<jam> maxb: probably
<jam> poolie: but *we* should be careful and compatible with the existing code for now (IMO)
<maxb> found error:Internal check failed: revno does not match len(mainline) 48 != -1
<maxb> Um, yay, I seem to have managed a branch with a ghost on the mainline, though some stacking weirdness
<jam> poolie: from what I can tell with XMLRPC, if you have ~user, then it tries to map to bzr+ssh://bazaar.launchpad.net/~user... and if you don't, then it maps to bzr+ssh://bazaar.launchpad.net/+branch/$1
<maxb> Anything starting with ~user should be the full unique name of a branch. Anything not starting with a ~ starts with a pillar name and goes via the aliasing rules
<poolie> no, i mean, how does +branch work
<poolie> does it redirect you to the canonical name, or does it just present that content?
<iqpi> hi guys, i am wondering about with is a greater solution for a project developement git or bzr? I think they are very similar in their basics.
<iqpi> wich*
<vila> iqpi: bzr. (Though if you ask in #git they may have a different opinion ;)
<iqpi> vila: yes i know, but i want to know why, i don't find any complete information.
<poolie> tell us a bit about your project
<maxb> Your question is unanswerable due to being hopelessly broad
<jam> poolie: it pretends it is the real branch
<jam> poolie: it doesn't redirect, it is done in the VirtualFS mapping
<jam> poolie: just as ~jameinel/bzr/branch actually maps somewhere on /host/00/12/34/56/
<jam> poolie: +branch/bzr maps to a similar /host/00/12/34/66 sort of real-world dir
<iqpi> well my project is about to let use ffmpeg to linux users. Multimedia file codification under linux is a pain due we have very powerful tools such ffmpeg or mencoder, but they are fucking hard to use, even, with the frontends it is very difficult because you need to have a lot of knowledge about codecs, formats aspects ... so i am writting a program | script that allow linux users to do some common things with multimedia files, like convert from
<iqpi>         --title="LEEncoder"\
<iqpi>         --text="Selecciona quÃ© vÃ­deo quieres silenciar"
<iqpi>         zenity --info \
<iqpi>         --title="LEEncoder"\
<iqpi>         --text="Selecciona quÃ© vÃ­deo quieres silenciar"
<iqpi> sorry for the flood :S
<iqpi> ...without any knowledge about codecs, bitrates formats, and so on.
<vila> iqpi: there are many differences between git and bzr that may be relevant to give you a meaningful answer: number/size of dir/files, number of revisions, number of devs involved, shared server availability, control over the software used on the server, preferred workflows, etc
<iqpi> size is just few kb, dir... in current branch just one dir with tree files.
<vila> iqpi: then I think bzr will be easier to start with than git (based on feedback *we* hear, this-is-not-a-metric usual disclaimer applies)
<poolie> agree
<poolie> thanks for pushing the package importer vila
<poolie> btw spm is working on the bzr upgrade there
<poolie> i think the package is rebuilding
<poolie> and i expect he will install it tomorrow
 * vila humbly bows
<vila> poolie: \o/ 2.3.1 ?
<poolie> not at all, thanks for the reminder
<poolie> yes
<poolie> so, generally speaking, we should still go through the ppa
<iqpi> thank you vila =) I have already set up a svn repo, but i don't like the way that svn works, with just a branch
<vila> poolie: ok, no worries, I have a backup plan 8)
<iqpi> only just another question, could i set up a bzr repo with sourceforge?
 * vila cp ~/src/bzr/trunk/bzrlib/config.py ~/src/udd/trunk/bzrconfig.py :-D
<vila> iqpi: http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar
<vila> iqpi: they mention 1.10 though which is an oooooooold version (2.3.1 is the current stable)
<iqpi> vila: i was just surfering that web, sorry for asking here before searching :S
<vila> iqpi: alternatively if your project is FLOSS, launchpad.net is said to be very nice too ;)
<iqpi> thank you vila for the advice, i will read about it, and yes it is a FLOSS project :D
<vila> iqpi: https://launchpad.net/+tour
<fullermd> That SF doc is oold.  ping says they're running 2.0.3 (which is still oooold, but...)
<poolie> ok
<poolie> getting things done, yay
<iqpi> wow, launchpad seems to be awesome 0.0
<jam> iqpi: we like it :)
<jam> vila: care to do a quick review on: https://code.launchpad.net/~jameinel/bzr/2.3-three-part-resolution-stacking-741375/+merge/54677
<ubot5> Error: Launchpad bug 2 not found
<jam> ubot5: not every launchpad URL is a bug, you know
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<jam> I know you aren't :)
<iqpi> I think this afternoon i will migrate my project from sourceforge to launchpad. Thanks for the info!
<jam> vila: I'd like to plug the "lp:" urls don't stack bug quickly.
<vila> jam: yeah, got that, but I first thought: Wtf, what kind of merge issue is he working on ?
<vila> jam: the tests seem nicely extensive !
<jam> vila: after having the fallout, I made sure to expand test coverage a bit
<jam> it is unfortunate that the real validation is only against LP itself
<vila> jam: I can't say from reading the code, but: Are you  reaching the real lp server there ?
<jam> vila: in the tests? no
<jam> Intentionally not (FakeResolution)
<jam> -Dlaunchpad does
<vila> jam: we already have issues with tests that reach lp, so you *could* add more as long as we have a feature (and even maybe some config/cmd-line option to control it)
<vila> wow !
<vila> We do ?
<jam> vila: you seem to be confusing yourself (and me)
<vila> jam: what does '-Dlaunchpad' ?
<jam> vila: bzr COMMAND -Dlaunchpad adds a debug flag
<jam> one thing it does (now) is to always query the XMLRPC server, and print out the results
<jam> vila: I wonder if I should also make it use the XMLRPC's response instead of the local one?
<vila> oh, didn't notice you added it (should be documented in debug.py with the others then)
<jam> vila: true
<jam> will do now
<vila> jam: ok, so my suggestion was to add a control flag so we can control whether or not the tests hits the real lp server (jelmer mentioned having to disable the lp plugin during builds otherwise)
<jam> '-Dlaunchpad' already existed, but maybe not as documented?
<jam> It is in a "plugin"
<jam> so I imagine those don't usually get documented
<jam> vila: do you want it anyway
<jam> ?
<vila> jam: then you can safely add more tests relying on that to make sure you correctly assert the lp behavior
<vila> jam: your call, doesn't have to be part of this submission
<jam> vila: they are going to be *slooow* like 1s for each XMLRPC call
<jam> (which is why I wrote the code in the first place)
<vila> AIUI we already have some
<vila> jam: if we control them we can decide whether or not we want them on or off by default too, babune won't care to wait some more seconds
<jam> vila: how about I submit a low-priority bug that we could add tests like that?
<vila> trace.note is for both .bzr.log and display on stdout/stderr (can't remember) ?
<jam> vila: yes
<jam>  mutter => only .bzr.log
<jam> note => screen and log
<vila> jam: wfm (bug), jelmer can then comment about the build issue
<jam> warning => adds more warning info?
<vila> hmm, isn't screen a bit too much there ? ... well, only once by resolution I guess so generally only one by bzr command ?
<vila> jam: as long as you land on trunk, we'll have time to refine anyway, approved
<jam> vila: if you are doing -Dlaunchpad to see if the resolution is correct, I assumed you wanted  to *see* it.
<vila> jam: there may be another bug against lp about the weird behavior there (I didn't follow closely your discussion with poolie, maybe you already filed one)
<jam> I certainly should update NEWS about that, though
<jam> vila: I think there is a bug in lp codehosting
<vila> jam: meh, of course, sorry
<jam> but at least we can have it lower priority
<jam> since bzr won't be provoking it
<vila> jam: just make sure to remove the duplicate qastaging entry
<vila> jam: sorting them will wfm too (dunno how you ended it up with the dupe, but sorting may help in the future)
<jam> vila: 2.3 doesn't have qastaging
<jam> 2.4 does
<jam> hence the dupe
<vila> ha, hmm :-/
<jam> It seemed reasonable to land in 2.3
<jam> if we decide the rest of the patch can land in 2.3
<jam> so I went with it
<jam> I also *really* wanted to test it
<vila> good job there
<jam> vila: bug #741633 fyi
<ubot5> Launchpad bug 741633 in Bazaar "Local lp: resolution could be tested against Launchpad" [Low,Confirmed] https://launchpad.net/bugs/741633
<jam> back in a bit, heading out for lunch
<rhlee> hi guys, how do I use bzr shelve destroy ?
<briandealwis> rhlee: I believe it just wipes out the changes rather than saving them as a shelf
<rhlee> briandealwis: but how do I invoke it?
<briandealwis> rhlee: so it's equiv to 'bzr shelve && bzr unshelve âdelete-only'
<briandealwis> rhlee: bzr shelve âdestroy
<briandealwis> ?
<briandealwis> it'll prompt you just as a normal 'bzr shelve'
<briandealwis> at least that was my experience using it yesterday :)
<rhlee> oh I see now, it essentially does a revert
<briandealwis> yeah, but a more selective revert â you can revert portions of a file
<rhlee> briandealwis: ok got that now, I see the use case now, thanks
<ScottK> Is it a bug or a feature that if you push after tagging, but no new revisions are present the only feedback is "No new revisions to push" and there's no indications that tags got pushed?
<jam> ScottK: known bug, I believe
<ScottK> OK.
<jelmer> jam: is ~mgiuca/bzr/log-not-in-branch ready to land?
<jam> jelmer: if it has a second approve, I think so
<jelmer> jam: that can be arranged :)
<vila> james_w: I think I addressed your comments on https://code.launchpad.net/~vila/udd/719888-log-config/+merge/54572 , can you review again (pretty please ;) ?
<ubot5> Ubuntu bug 719888 in Ubuntu Distributed Development "package import on jubany/pepo should write logs to a dedicated and configurable log directory" [Medium,In progress]
<james_w> sure
<james_w> vila, 150	+# FIXME: We don't inherit from LockableConfig because we don't want to create a
<james_w> is that really a FIXME?
<vila> james_w: it's at least unclear what will be done in the long run so I prefer to have a FIXME deleted later than a bad design forgotten
<james_w> vila, approved, thanks
<vila> james_w: maybe it's too esoteric in this context, but the issue is that all *current* config files rely on having a .bzr handy to create a 'lock' dir there and I did realize that when creating this p-i specific config file
<vila> james_w: thanks to you  !
<vila> james_w: nothing wrong in the deployment plan from your pov ?
<james_w> vila, nope
<vila> cool. Now I need a losa to torture ;)
<jelmer> jam, vila: do you know where the architecture guide lives?
<vila> not precisely, I'd start searching in doc/developers
<vila> jelmer: not sure it's a document per se, may be more about concepts spread across several files and referred to as such
<vila> jelmer: in other words, you may have to start your own document on the topic ;)
<jelmer> heh, ok
<vila> jelmer: it's about the foreign stuff right ?
<jelmer> vila: about colocated branches
<vila> bah, forget me
<jelmer> vila: with the work I've been doing recently, foreign branches are not a bad guess though ;)
<jelmer> vila: it has some overlap, John Barstow was asking about colocated branches and bzr-tfs
<vila> yeah, I'm sure you can even make a proposal with just documenting all the stuff you did there :-)
<vila> jelmer: you know, mentioning it briefly in the what's new, a bit more in release notes and a big explanation in doc/developers ;)
<vila> jelmer: semi-seriously, a brain dump *now* would be better than a more elaborate prose... in 6 months ;)
 * vila will be well advised to the same for the package importer no ?
<vila> s/to/to do/
<jelmer> vila: you've never seen my prose. :-P
<jelmer> but yeah, writing something up is probably a good idea
<vila> jelmer: what ?? Isn't your name on at least one book ? :D
<jelmer> vila: Heh, true. It's non-fiction though (or at least, it should be...)
 * jelmer discovers he did write developer docs for his colocated branch work and forgot about it
<jelmer> jam: Any chance you could have another look at https://code.launchpad.net/~jelmer/bzr-gtk/vertical-layout/+merge/50446 ?
<ubot5> Ubuntu bug 50446 in ubiquity (Ubuntu) "GRUB not installed because of some reading error (dup-of: 47194)" [Undecided,New]
<ubot5> Ubuntu bug 47194 in ubiquity (Ubuntu) "qtparted seems to crash on some setups; deal with this better?" [Medium,Fix released]
<jam> jelmer: I can look at it, but I can't say I fully understand what I'm looking for
<jam> jelmer: looks broken
<jam> it does move everything to the side as requested
<jam> and that looks ok
<jam> except after I do so
<jam> I no longer see the actual information for a Revision
<jam> when I select a new rev
<jam> jelmer: If I change the setting, and restart, everything works ok
<jam> but changing the setting breaks data updates
<jelmer> jam: I'll have another look - thanks
<jam> jelmer: what ubuntu mirror do you use?
<jam> (I guess I get max bandwidth from archive.ubuntu.org directly, but figure I should play nice)
<jelmer> jam: I'm using the trick mvo just published about
<jelmer> deb mirror://mirrors.ubuntu.com/mirrors.txt natty-backports main restricted universe multiverse
<jelmer> that's supposed to pick a local mirror
<jam> jelmer: so it pics a random mirror?
<jelmer> jam: yeah, though a random dutch mirror in my case
<jam> jelmer: looks like it grabs your ip address and then builds it custom for you
<jelmer> jam: yeah, it uses geoip
<jam> the first entry is, indeed, a .nl
<jam> from vila's machine, the first entry is a .fr
<jam> nice trick
<vila> I always use the main server at it seems to provide the most bandwidth ;)
<jelmer> all of the .nl machines I have seen so far do up to 2Mb/s, which is the maximum I can get out of my internet connection too
<jam>  jelmer: 2Mb or 2 MB ?
<jam> big difference
<jam> I get 870kB/s from archive.ubuntu.com, which is all the bandwidth the apartment has
<jam> the new place is supposed to have 40Mb/s
<jelmer> hmm, my sound card driver is playing russian roulette with me :-/
<jxself> www.gnu.org is currently mantained under CVS, and we'd like to move to Bazaar. This is my first attempt at the CVS -> Bazaar migration: http://dpaste.com/525282/ Suggestions?
<jelmer> jxself: looks like bzr-cvsps-import wasn't updated for the latest version of bzrlib
<jelmer> jxself: try lp:~jelmer/bzr-cvsps-import/avoid-note
<jelmer> jxself: there's also cvs2bzr, which I guess is more commonly used
<jxself> jelmer: Thank you. Will look into that shortly.
<jxself> jelmer: I've applied that. It now outputs Creating cvsps dump file: /home/jason/Desktop/www-bzr/staging/ROOT.dump. Should I expect that file to be growing?
<jxself> It's not.
<jxself> And current system load is reporting load average: 0.00, 0.02, 0.05 so I'm not sure that anything's actually happening..
<vila> jelmer: you probably should unload it, russian roulette is dangerous with loaded things ;)
<fullermd> vila: Yeah, but it's _boring_ if it's unloaded   :p
<knighthawk> there doesn't seem to be a rpm of bzr-svn for fedora. so I attempted to do a manual install
<knighthawk> branched from lp find then ran make and make install
<knighthawk> no errors.
<knighthawk> but now when I try to run the testsuite I get
<knighthawk> Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib64/python2.4/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1)
<lifeless> you've grabbed trunk
<lifeless> but trunk wants bzr 2.4
<lifeless> you either need to grab the bzr svn for bzr 2.1
<lifeless> or also grab bzr 2.4
<knighthawk> I'm thinking my life will be easier if I go with the bzr-svn for 2.1 but how do I get that?
<knighthawk> bzr branch lp:bzr-svn2.1 ?
<lifeless> I'm not sure offhand
<lifeless> jelmer: ^?
<knighthawk> 1.0.2 (works with Bazaar 2.0, 2.1)
<knighthawk> so I'm thinking bzr branch bzr-svn1.0.2
<lifeless> there may be a 1.0.2 tag in your curremt bramcj
<lifeless> *current branch*
<lifeless> 'bzr revert 1.0.2'
<lifeless> bah revert -r 1.0.2
<lifeless> knighthawk: what does 'bzr tags' show you /
<lifeless> ?
<AfC> -r tag:
<lifeless> AfC: not needed
<lifeless> AfC: if the rev isn't found, different providers are searched
<lifeless> AfC: and a branch on rev 1 is very unlikely ;)
<AfC> oh you're talking about revnos. I thought you were talking about a tag called 1.0.2
<AfC> lifeless: really?
<lifeless> I am
<AfC> oh
<lifeless> might not be in bzr 2.1, but it was added quite a while ago
<AfC> That's not very good. It means if you mistakenly type something that just happens to be a tag, you're going to get a successful operation that [unwittingly] does something vastly different that you expect
<AfC> BAD
<knighthawk> nice. I'll try that lifeless
<AfC> [admittedly, it never occurred to me that someone would create tags that look like revnos]
<knighthawk> okay I see a upstream-1.0.2
<knighthawk> a lot of release (but nothing that says 1.0.2)
<lifeless> upstream-1.0.2 sounds good :)
<knighthawk> and several bzr-svn (including one that says bzr-svn-1.0.2)
<knighthawk> so 'bzr revert upstream-1.0.2' ?
<knighthawk> bzr: ERROR: Path(s) are not versioned: upstream-1.0.2
<knighthawk> bzr revert -r bzr-svn-1.0.2
<knighthawk> worked
<lifeless> knighthawk: bzr revert -r upstream-1.0.2 should have worked
<lifeless> without the -r it thinks you're reverting a file/directory name
<knighthawk> make and make install worked.
<knighthawk> trying the testsuite now.
<knighthawk> bzr: ERROR: No module named testtools
<knighthawk> You may need to install this Python library separately.
<knighthawk> no clue what the name of that package would be in Fedora
<poolie> knighthawk, is there a search function?
<poolie> if not you can get it from 'bzr branch lp:testtools'
<poolie> hi all btw
<knighthawk> I just googled and I think its called python-tools btw
<knighthawk> hey poolie
<knighthawk> no python-tools didn't help me any.
<poolie> python-testtools maybe?
<poolie> that's what it's called in debian/ubunut
<poolie> *ubuntu
<lifeless> knighthawk: http://pypi.python.org/pypi/testtools
<poolie> that too
<poolie> hi lifeless
<knighthawk> thanks lifeless
<jxself> www.gnu.org is currently mantained under CVS, and we'd like to move to Bazaar. This is my first attempt at the CVS -> Bazaar migration: http://dpaste.com/525282/. Applied patch suggested by jelmer: lp:~jelmer/bzr-cvsps-import/avoid-note. Appears to be hung. No CPU usage, and the staging/ROOT.dump file is empty. strace if anyone's interested: http://aws.bluehome.net/strace. Suggestions?
<jelmer> lifeless, knighthawk: bzr-svn trunk works with bzr 2.3 and bzr.dev
<knighthawk> okay until I can get the python test tools running if I can do a bzr svn-import would that be reasonable prof that its installed correctly?
<poolie> knighthawk, yes
<poolie> bzr selftest is intended more for developers than for proving it's installed correctly
<poolie> hi jxself
<poolie> jxself, your strace shows it's waiting for the cvsps subprocess, which is not itself traced
<poolie> you can use strace -ff
<poolie> please file a bug though, tagged affects-gnu
<wgrant> Can someone please moderate my email to bazaar@?
 * jelmer waves to wgrant, poolie
<wgrant> Morning jelmer.
<jelmer> wgrant: IIRC at least jam and poolie are list moderators. Of course, you could always just subscribe :)
<wgrant> jelmer: I probably should.
<wgrant> Resent. Maybe it will work.
<jelmer> wgrant: yep, it's shown up here
<wgrant> Great, thanks.
#bzr 2011-03-25
<jxself> poolie: Will do, thanks. There's more than a decade of history in CVS and I don't want to lose that.
<jelmer> wgrant: Is it no longer possible for me to change Fix Released Ubuntu bugs back to any other status?
<jelmer> I accidentally changed a bug to Fix Released, now I can't change it back.
<wgrant> jelmer: You can't reopen a bug unless you are a bug supervisor or the reporter.
<wgrant> jelmer: Which bug?
<jelmer> wgrant: the ubuntu bit of https://bugs.launchpad.net/ubuntu/+source/loggerhead/+bug/586611
<ubot5> Ubuntu bug 586611 in loggerhead "loggerhead needs a hard dependency on simplejson" [Medium,Fix committed]
<poolie> is that new?
<wgrant> poolie: Yes :(
<wgrant> More misfeatures.
<poolie> i don't suppose it's documented other than in the source?
<wgrant> jelmer: What should it be?
<wgrant> poolie: lol
<jelmer> wgrant: In Progress I guess (there's an upload going into Debian that fixes it that'll request a sync for)
<jelmer> s/that'll/that I'll/
<wgrant> Fixed.
<jelmer> wgrant: thanks
<mr-russ-work> what's the best windows bzr client?
<poolie> bzr explorer
<mr-russ-work> does it need bazaar installed?
<poolie> mr-russ-work, yes
<poolie> but i think they're both included in the default windows installer?
<poolie> hi spiv?
<knighthawk> thanks poolie
<spiv> Hi poolie
<spm> poolie: jubany now has: ii  bzr 2.3.1-0~0.IS.8.04; will update the RT shortly
<spiv> spm: thanks!
<spiv> I'll give those imports a kick then
<spm> sweet
<poolie> hey spiv
<poolie> i missed you before :)
<spiv> Hmm, the package importer is getting lots of âlazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Errorâ, e.g. http://package-import.ubuntu.com/status/ceph.html#2011-03-25%2002:08:19.181741
<poolie> there should be an oops header
<poolie> gah
<poolie> i filed a bug asking for lplib to pull that into the exception
<poolie> you could fix that
<lifeless> timeout bug I suspect
<lifeless> fix is in trunk, pending deploy due to these security issues
<spiv> I've told the package-importer that it's a transient issue, so it'll automatically retry those failures after 24(?) hours I think
<lifeless> well
<lifeless> the problem is that filing a merge proposal loads /all/ the branch history for both sides into cache
<lifeless> so if you want to retry
<lifeless> do it right away
<lifeless> while you're still slightly hot
<achiang> hello, i noticed that debcommit has some magic to make a bzr branch automatically link up with a launchpad bug. how can i do that manually? bzr help commit doesn't really tell me much
<poolie> bzr help mark-uploaded
<poolie> i think
<lifeless> mark-uploaded says when something has been uploaded to the archive
<poolie> ah gah
<poolie> misread
<poolie> you want bzr ci --fixes lp:BUGNUM
<achiang> ooh
<achiang> ok
<achiang> huh, --fixes not documented in maverick's bzr?
<achiang> yes it is
<achiang> i just can't read
<achiang> poolie: thanks!
<poolie> in 'bzr help launchpad' too
<poolie> you're welcome
<jderose> how do i print a summary of commits per person/ lines of change per person?  looked at bzr stats, but it doesn't seem able (or maybe is sort of broken on bzr 2.3.0/natty)
<poolie> i thought it did that sort of thing
<achiang> is there a way to do a bzr commit interactive? i only want to commit one hunk
<poolie> install bzr-interactive i think
<achiang> nothing shows up in apt-cache search?
<poolie> jderose, what happens from 'bzr stats'?
<achiang> oh, it's a plugin
<poolie> yep, bzr branch lp:bzr-interactive ~/.bazaar/plugins/interactive
<achiang> interesting, i'll try that
<poolie> jderose, that seems to work for me
<jderose> poolie: turns out, something totally awesome! i've been up hacking too long at this point... was in the wrong branch! http://paste.ubuntu.com/585230/
<poolie> haha :)
<jderose> poolie: sorry for the dumb question, thanks for the smart answer :)
<poolie> np, glad it worked
<poolie> don't know if it can count slocs
<poolie> which obviously are highly useful in awarding bonuses
<jderose> ah, gotcha... that would be cool
<jderose> poolie: np, i work for this crappy startup that doesn't pay anyone anything!
 * jderose is CEO :)
<poolie> congrats / good luck :)
<jderose> poolie: thanks. :) while i have you... out of curiosity, is there any timeline for addressing the submodules issue with bzr? - https://bugs.launchpad.net/bzr-git/+bug/402814
<ubot5> Ubuntu bug 402814 in Launchpad itself "Importing revisions with submodules is not supported" [Wishlist,Triaged]
<poolie> hm it should go up from wishlist
<jderose> poolie: i keep telling everyone how awesome daily builds are, help them set them up, to find i can't import into bzr... i'm personally very interesting in see daily builds for gstreamer and pitivi
<poolie> yeah, it's a big blocker for that
<poolie> it's not close enough i could give a very reliable estimate but it's definitely in our target area
<jderose> poolie: i know there are always too many things to do and it's hard to pick priorities --- no judgments! -- but just wondering :P
<poolie> maybe in the next few months
<jderose> so this requires a pretty big change in bzr? new storage format big?
<jderose> poolie: anyway, bzr and launchpad are fantastic - that's for tools that have made my live easier! :)
<poolie> just a bug
<poolie> fighting with all the others to be born
<jderose> poolie: gotcha.  thanks again!
<poolie> hi jam!
<vila> hi all !
<poolie> hi there vial
<poolie> *vila
<vila> I can't find back the reference, but someone mentioned that reviews can gain a 'Agreed' vote instead of an 'Approved' one
<poolie> really?
<vila> It makes a lot of sense to me
<vila> It gives a very different meaning and implies a different relationship which I think is far more appropriate
<poolie> i just haven't heard of it
<vila> Most of the time I "agree" with the proposal as a peer instead of "approving" it as a semi-god :-D
<vila> ha, got it: http://micknelson.wordpress.com/2011/03/22/code-reviews-as-relationship-builders/
<poolie> https://lpstats.canonical.com/graphs/BzrProjectBugActivity/ -- everyone came back from holidays :)
<poolie> nice idea
<vila> lol
<poolie> personally i would rather get 'tweak'
<poolie> http://en.wikipedia.org/wiki/I_approve_this_message
<vila> yeah, it's needed more often
<poolie> i think 'approval' is quite a positive sentiment though
<vila> poolie: granted there are positive values in approval but I think they are also there in agreement ;)
<poolie> haha :) indeed
 * vila back to losa hunting
<jam> morning all
<vila> morning jam :)
<poolie> jam, vila: should i add a mechanism to deprecate commands, or just delete them?
<poolie> i guess the former
<jam> poolie: so you get "bzr clone is going to be removed in the next release" messages?
<poolie> yeah
<jam> We've loosened the deprecation stuff for api, but I think we probably want to do that for command  line.
<poolie> suppressable messages
<vila> configurable as we did for warnings
<jam> side note: "safe and easy web browser from Mozilla" (firefox)
<poolie> ?
<jam> just very funny to read the "helpful descriptions" rather than the name of the program
<jam> Update Manager
<poolie> oh, yeah, that is strange
<jam> They also have a very strange (and inconsistent) Capitalization
<jam> poolie: I'm tempted to go so many different ways.
<jam> I would tend to say... if it is hard to do, punt
<jam> but if it is easy, please deprecate
<poolie> agree
<poolie> it's not _that_ hard
<jam> That said
<poolie> some of the command framework stuff could do with some love
<jam> if people are using "bzr clone" are they going to notice it tell them it will be changing?
<poolie> why wouldn't they?
<jam> poolie: because of all the other stuff that they ignore. They could.
<jam> I just want to make sure that messages we send are relevant
<jam> That people who *want* to see them are doing so.
<poolie> so i can think of two ways to do this
<poolie> one is, to put it into the Command object
<poolie> we could just refuse it
<poolie> and make them update
<poolie> their muscle memory or scripts
<poolie> i guess some scripts may be hard to update
<jam> poolie: There was a recent discussion in python-dev about deprecation
<jam> In py, they always do PendingDeprecation in X, Deprecation in X+1, Removed in X+2
<poolie> ok
<jam> People were complaining
<poolie> what's pending deprecation?
<poolie> just in the docs?
<jam> poolie: I think it is a by-default suppressed warning
<jam> versus a vocal warning
<jam> versus gone
<jam> the complaint was because they were trying to go from 2.X to 3, and running afoul of
<jam> Well it was deprecated in 3.1, so removed in 3.2
<poolie> :)
<jam> but 2.7 still had something
<jam> so there was no way to support 2.7 *and* 3.3
<jam> or whatever
<jam> poolie: but that also highlights something
<jam> people really care about Deprecation as a way to transition
<jam> if we are just removing aliases to commands that already exist
<jam> they can switch to the existing command, and be supported across all versions
<poolie> right
<poolie> and, they should be able to use bzr aliases if for some reason they can't change
<jam> I think people have trouble if it was "foo" in 2.0, and "bar" in 2.4, and they don't have an easy way to support the versions they want
<jam> poolie: My experience in the past, was that DeprecationWarning wasn't helping people
<jam> Developers tend to use crack-of-the-day
<jam> and so never see them, because they are using the new apis
<jam> Users see them a lot, but don't have anything they can *do* about it
<poolie> yes
<poolie> and yes
<poolie> showing deprecationwarning to users is nuts
<jam> poolie: I *think* we can do this for commands in a tasteful way
<jam> because there it is much more likely that a user is invoking the command that needs to be changed
<jam> There are scripts that don't apply
<jam> (if I'm using, eg, etckeeper, then don't give me deprecations cause Upstream needs to fix it)
<poolie> also, it's probably unusual that someone chose to use these at all
<jam> poolie: then my recommendation is to troll through bzr docs, especially ones not written by us
<jam> I don't know of any particularly popular ones
<jam> but I'm pretty sure I've seen wiki-like docs
<jam> that said "bzr clone ..."
<jam> or maybe "bzr get ..."
<poolie> maybe
<poolie> those docs may have bigger problems
<poolie> anyhow, fair enough
<jam> anyway, that's the only place where I've seen recommendations for people to use non-official names
<poolie> adding a command deprecation layer just for this does not feel like the most direct route possible
<poolie> k
<poolie> thanks
<jam> And I think some people like "bzr get" because it was shorter to type
<poolie> i'm happy to add 'bzr br' or similar
<poolie> once we sort this out
<spiv> jam: yes, I know of at least user that prefers "bzr get"
<spiv> I don't recall hearing anyone use or advocate using our current "bzr clone" alias.
<jam> spiv: I think I've seen it in something like "bzr-for-git" discussion
<poolie> spiv, bialix mentioned in the bug he prefers it
<poolie> or was it someone else too?
<jam> (because the command is more like 'git clone' than 'git branch')
<jam> poolie: I'm pretty sure the one I remember is bialix
<poolie> well, they might say 'bzr clone' too then
<poolie> but it's not all that much like it
<spiv> I'm mainly thinking of glyph, but presumably these aren't the only people :)
<poolie> well, 'bzr alias get=branch' will restore it
<jam> poolie: so I think you bring up a reasonable statement
<jam> fail
<jam> but give them advice on what to do
<jam> "bzr get" --- "bzr get was removed in bzr 2.4. The recommended name is "bzr branch", to restore "bzr get" as an alias, use ..."
<jam> (bzr get was removed as an alias in bzr 2.4)
<jam> poolie: sort of inbetween "deprecated and I still work", and "where did the command go that I've been using for 3 years"
<poolie> yep
<poolie> i might implement that by adding a new command that prints the message, and binding them to that
<jam> poolie: a few ways to do it. You could add "old_aliases = [...]" to Command objects
<jam> if there are a lot of them
<poolie> i was going to do that originally
<jam> I think it depends how hard it is to get the appropriate text
<poolie> it seems a bit inelegant to put it inline with the regular command stuff
<jam> but I guess that is what https://code.launchpad.net/~mbp/bzr/506265-command-deprecation/+merge/54828 is about?
<ubot5> Ubuntu bug 506265 in Bazaar "deprecate old command names" [High,In progress]
<jam> So the "cmd_I_was_removed_in_24" knows what it is aliased to now?
<poolie> right
<poolie> i think i might stop for today though
<jam> spiv: You mentioned you could use "lp:~/project/branch" and we'll expand ~ to ~user. When you said that, I thought "really, since when".
<jam> I just looked through the logs, and *I* implemented it
<jam> (2.3b1)
<spiv> jam: :)
<lifeless> spiv: should be able to retry those timeouts now
<jam> bbiab, lunch
<spiv> lifeless: I think they retry every hour actually
<spiv> Oh, hmm, maybe not.
<spiv> I'll give it a kick anyway
<spiv> lifeless: still failing
<james_w> erk
<james_w> I don't like the look of http://package-import.ubuntu.com/status/7ae30b44f1f904e04bbae6700b7181dd.html
<james_w> and http://package-import.ubuntu.com/status/3321c5cfcfcf74249b92f963453f4701.html is pretty worrying
<james_w> as is http://package-import.ubuntu.com/status/ttf-arphic-gkai00mp.html
<james_w> http://package-import.ubuntu.com/status/ttf-arphic-uming.html
<james_w> http://package-import.ubuntu.com/status/ttf-arphic-ukai.html
<vila> james_w: I think that's what lifeless and spiv were just talking about
<james_w> though I guess those are transient with the upgrade of bzr?
<vila> eerk, the no module named revisiontree is different and indeed very worrying
<vila> james_w: 'no module ...' requeued
<vila> james_w: and they seem to be passing now, ttf-arphic-uming requeued too
<james_w> vila, great, thanks
<james_w> it would be great to have a packaging system that didn't break python on upgrades
<vila> thanks for noticing, I think.. yeah :)
<vila> james_w: in the mean time, stopping the importer may help...
<james_w> yeah
<spiv> james_w: in principle the packaging system could do "mv bzrlib .old.bzrlib; mv .new.bzrlib bzrlib; rm -r bzrlib" I suppose, but I can just imagine how that would actually be pretty hairy to actually implement
<spiv> james_w: (and of course even that approach has a small window of brokenness)
<james_w> spiv, my guess is that dpkg is fine, it's the Python-specific stuff on top that isn't, and hopefully that can go away in a few years when Barry's stuff is widely available
<spiv> Although I guess it's hard to avoid the risk of breaking running processes
<spiv> Even firefox wants a restart after its package is upgraded ;)
<spiv> james_w: clearly bzr should not use lazy_import so that it gets all its imports done in as short a window as possible ;)
<james_w> yeah :-)
<james_w> if we can't even import bzrlib sometimes though... :-)
<spiv> Or just have the old processes keep running against an older btrfs snapshot of the system, or something handwavy like that...
<spiv> Anyway, zzz time!
<james_w> night
<jam> jelmer: you landed the bzr-hg change faster than Launchpad built the merge proposal for it. so there isn't a diff to read.
<jam> also, weren't we wanting to pair on some changes?
<jam> I don't remember which ones off-hand
<jam> but maybe we could do that early next week?
<jelmer> jam: I've mostly been using merge proposals as a way to track individual changes, but self-reviewing as I always have
<jelmer> jam: Yeah, some pair programming would be nice
<jam> jelmer: sure. Just mentioning that tracking the changes isn't possible when you land faster than they get tracked :)
<jelmer> jam: heh, fair enough :)
<achiang_> hello, how do i resolve a merge conflict? i get a foo.BASE and a foo.THIS, not sure which one is which
<achiang_> but the base file foo doesn't seem to exist at all
<achiang_> ah, i think that means my merge source rm'ed foo
<wgrant> maxb: Hi.
<ablmf> How to automatically "push" after every commit?
<bouncingzip> use a bound branch.
<ablmf> bouncingzip: do u mean use a "checkout"?
<bouncingzip> actually, depends what you're trying to do exactly
<bouncingzip> maybe relevant: http://stackoverflow.com/questions/460632/bazaar-bound-branch-commit-and-update
<bouncingzip> if you want the tree somewhere remote, those are suggestions on how to do it, if you want a remote branch automatically mirrored each commit, binding to it (which yes, is the same as using checkout originally) is probably what you want.
<ablmf> bouncingzip: I think the plugin helps, thx!
#bzr 2011-03-26
<sili> hi. how can I show a diff between two branches in terms of commits, not code?
<james_w> sili, try bzr missing in one branch, pointing to the other
<Kamping_Kaiser> first of all, i found a bug in the bzr shipped in squeeze :(
<Kamping_Kaiser> second, curse you for having fixed it in head already :p
<Kamping_Kaiser> thanks all \o/
<poolie> :)
<maxb> wgrant: Hello back
<poolie> hi maxb, and goodbye
<wgrant> maxb: Hi. You seem to do all the ~bzr PPA uploads... could you please upload loggerhead 1.18.1?
<maxb> sure
<wgrant> maxb: Thanks.
<magcius> maxb, thanks so much
<Stavros> hello
<Stavros> is there a way to export one of my repos as a git repo?
<jelmer> hi Stavros
<Stavros> oh hey jelmer
<jelmer> Stavros: you can use "bzr dpush --no-rebase" from the bzr-git plugin to create a git repo
<Stavros> jelmer: does it work with file://?
<Stavros> or do i have to push over ssh?
<jelmer> Stavros: locally should work
<jelmer> you can only push to an existing git branch at the moment
<Stavros> hmm, i can't get it to recognise the syntax, can you give me an example?
<Stavros> oh, i don't have a branch
<Stavros> should i do git init and push there?
<jelmer> Stavros: yeah, that should work
<Stavros> i'm doing git:///tmp/myrepo/ and it says connection refused :/
<Stavros> oh, pushing to ssh worked, thank you
<Stavros> hmm no, i can't reset
<Stavros> aw :/
<jelmer> reset?
<jelmer> you should just specify the local location of the git repository, git:// is a remote protocol that requires a separate git server to run
<Stavros> oh
<Stavros> hmm, if i specify bzr dpush /tml/myrepo/ --no-rebase"
<Stavros> then it says /tmp/myrepo/ isn't a repo (which it isn't, because it's not a git repo)
<Stavros> err, it's not a bzr repo, it's a git repo
<Stavros> bah
<jelmer> re
<jelmer> Stavros: how did you create the thing in /tmp/myrepo ?
<Stavros> mkdir /tmp/myrepo/; cd /tmp/myrepo/; git init
<jelmer> Stavros: that just creates a new repository, not a new branch
<Stavros> oh
<Stavros> hmm, how do i create a new branch? i'm not very good with git
<jelmer> Stavros: one way is "bzr init", I'm not sure how to do it using native git tools
<Stavros> hmm, wait, i already have a bzr repo and want to convert it to git
<Stavros> bzr init will just create a new bzr repo
<jelmer> no, it'll use the existing repo if one is present
<jelmer> I realize it's a bit weird
<Stavros> oh
<Stavros> ah yes
<Stavros> it said format: git
<jelmer> "bzr init-repo" creates a new repository, "bzr init" creates a branch
<jelmer> whereas "git init" creates a repository
<Stavros> ah, i see
<Stavros> that seems to have worked, thank you very much!
<jelmer> np
#bzr 2012-03-19
<mgz> morning all
<mgrandi> heya
<mgrandi> hey mgz, i'm available for said debugging stuff that we have been putting off forever
<mgrandi> haha
<mgz> hm, okay, where did we leave off?
<mgz> with some meliae bugs to fix?
<mgrandi> haha, good question, ill look at the logs
<mgrandi> i believe i got the win7 sdk
<mgrandi> and i had to recompile something cause it was not using the same version
<mgrandi> and that was causing the meliae dumps to be incorrect
<mgz> so, to start with, reproducing with 2.5.0 which is 32bit would be fine
<mgz> which avoids the 64bit specific issues we had and the need to recompile things
<mgrandi> so, just go back to the beginning and try to fast-import linux again?
<mgz> yep, though you could pick a smaller branch and force the memory dump too
<mgrandi> how do i do that?
<mgz> well, manually, run the operation, wait till progress indication says it's near the end (or reaches max mem usage seen on a previous run),
<mgz> then ctrl+break to get in with pdb
<mgz> import sys, bzrlib.trace; bzrlib.trace._dump_memory_usage(sys.stderr)
<mgrandi> k
<mgz> then load the file that generates with meliae
<mgrandi> should it be a fairly large branch but not a huge one like linux? =P
<mgz> yup, something like that
<mgz> just so the dump file isn't insane to try and understand
<mgrandi> i'll try rails, big but not huge
<mgrandi> well
<mgrandi> things are off to a good start
<mgrandi> bzr: ERROR: 36508955: Parse error: line 36508955: Timezone '+051800' could not be converted.
<jelmer> is this importing a fastimport file ?
<mgrandi> yeah
<mgrandi> git fast-export --all --signed-tags=strip --progress=1000
<mgrandi> the line in the file seems to be
<mgrandi> author Vijay Dev <vijaydev.cse@gmail.com> 1312735823 +051800
<jelmer> which repo is that?
<jelmer> that definitely looks like an invalid timezone line
<mgrandi> git://github.com/rails/rails.git
<mgrandi> lets see if i can find the commit
<mgz> mgrandi: maybe just try linux again while trying to work out why rails doesn't export?
<mgrandi> yeah
<mgrandi> jelmer, it seems that its listed in git as an invalid timezone too: , git  commit 4cf94979c9f4d6683c9338d694d5eb3106a4e734
<jelmer> ah, interesting
<mgrandi> https://github.com/rails/rails/commit/4cf94979c9f4d6683c9338d694d5eb3106a4e734
<jelmer> I've requested an import on Launchpad, wondering what that will yield
<mgrandi> yeah, a git log --grep <wahtever. says the date is Mon Aug 29 06:50:23 2011 +51800
<jelmer> so I guess one of the options is to make bzr-fastimport just warn on invalid timezones and fall back to UTC
<mgrandi> is that a valid timezone?
<mgrandi> github seems to make something out of it
<mgrandi> i'll start the linux one while we wait haha
<jelmer> it is definitely an invalid timezone
<jelmer> anything over 12 hours would be invalid
<jelmer> this is 518 hours
<jelmer> actually, anything over 14 or something I guess
<mgrandi> wonder if thats a git bug, heh
<mgrandi> either way , bzr should probably handle invalid timezones. should i file a bug for this?
<jelmer> s/bzr/bzr-fastimport/ but yeah
<mgrandi> well i meant that git accepted an invalid timezone
<mgrandi> what should i file it under
<jelmer> mgrandi: bzr-fastimport
<mgrandi> and jelmer , https://bugs.launchpad.net/bzr-fastimport/+bug/959154
<ubot5> Ubuntu bug 959154 in Bazaar Fast Import "fast-import fails on invalid timezones" [Undecided,New]
<jelmer> mgrandi: where do you see the date/timezone on the github page?
<mgrandi> if you hover over "authored 8 months ago" next to his username under the blue box title thingy
<mgrandi> im assuming that is converted to your timezone (from your github account)
<jelmer> mgrandi: ah, I see
<jelmer> urgh, that is 22 days off.. they simply seem to interpret the timezone as an offset
<mgrandi> yeah
<mgrandi> weird o.o
<mgrandi> finding bugs all over the place haha
<jelmer> mgrandi: I wouldn't really consider this a defect in bzr-fastimport, rather a bug in git we can be more tolerant of.
<mgrandi> true
 * mgrandi waits for the stupid fast-export to finish
<jh> is there an elegant way to create multiple patches from a bzr-repo and them to apply them to a avn-repo? conserving the commit-messages in any way?
<jelmer> jh: the reverse is possible with "bzr svn-import", but there's no way to push a set of bzr branches into a svn repository, just one at a time
<jh> ok
<jh> then the best way seems to be to do multiple "bzr diff -c <rev> --format=svn > <rev>.diff" and copy the commit messages manually...
<jelmer> jh: once we polish the UI for colocated branches a bit more this would be one of the things that would automatically be supported
<jelmer> jh: that shouldn't be necessary, you can "bzr push" from the branches
<jelmer> you just have to do it one branch at a time
<jh> iirc, bzr push said something about no common ancestors
<jelmer> jh: the bzr branches you're using aren't derived from the svn branches you're pushing to?
<jh> right... some automatism replicates every svn commit into the bzr-repo
<jh> so they are identical, but the bzr-repo is not derived from the svn-repo
<jelmer> ah, in that case bzr indeed can't help you
<jh> ok
<mgrandi> well, now that i have a 22.7 gb fastexport file, time to import it
<mgrandi> should i just leave it on for a couple of hours and then do the pdb thing mgz?
 * mgrandi whines
<mgrandi> bzr: ERROR: 881736312: Parse error: line 881736312: Command tag is missing section tagger
<mgz> mgrandi: you want to do `bzr -Dmem_dump ...` on the import
<mgz> and maybe induce it to run out of memory a little early by leaving it less than your full amount
<mgz> but the export does need tobe loadable..
<mgrandi> trying to print out the line in question
<jelmer> mgrandi: I suspect you're hitting another case where stricly speaking fastimport requires a tagger for exported tags
<jelmer> but there's an entry in the kernel repo where there's no tagger
<mgrandi> is it because i did --signed-tags=strip?
<jelmer> I'm not sure
<mgrandi> well
<mgrandi> its late here, i'll have to continue this later, i'll get to a point where i can pdb into some semi large git repo
<mgrandi> for now, night~
<Riddell> what could this mean?
<Riddell> 11:56 <apol> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~cyberspace/cyberspace/muon-packaging": no supported schemes
<jelmer> Riddell: perhaps paramiko not installed?
<Riddell> jelmer: he says it is
<mgz> ugh, that's generally something specific but I'm failing to remember what
<apol> hi Riddell
<Riddell> mgz: it means bzr doesn't know about bzr+ssh for some reason?
<jelmer> apol, Riddell: is that while pushing to that branch, because it doesn't seem to exist.
<Riddell> apol: can you pastebin the last chunk in ~/.bzr.log ?
<Riddell> jelmer: right, first time of pushing (he also just added his ssh key to launchpad)
<mgz> do the normal ssh debugging steps just to check that
<Riddell> apol: can you ssh bazaar.launchpad.net ?
<mgz> `ssh your_launchpad_username@bazaar.launchpad.net`
<mgz> which should connect then say there are no shells
<mgz> and I'll grep logs and mail to see if I can remember the context this came up before
<apol> let's see...
<apol> Riddell, mgz: http://paste.kde.org/442808
<Riddell> apol: got a ~/.bazaar/bazaar.conf with the right username?
<Riddell> [DEFAULT]
<Riddell> launchpad_username = jr
<apol> Riddell: oh, there's none
<apol> I'll add it
<apol> Riddell: now it worked
<wgz> bug 854713
<ubot5> Launchpad bug 854713 in Bazaar "Unable to resolve "lp:bzr-rewrite"" [Medium,Confirmed] https://launchpad.net/bugs/854713
<wgz> so, it's not having done launchpad-login plus some oddness
<Riddell> apol: great, mgz: that error message could do with being improved :)
<wgz> should be able to say the branch doesn't exist in that case, rather than getting confusing follow-on error
<apol> :)
<ams_cs> jelmer: hi, any news on my lp:gcc/4.7 problem from last week?
<lamalex> is it possible to shelve changes from a branch, and unshelve them into a different branch?
<mgz> lamalex: not trivially
<lamalex> well diff > into a patch
<mgz> okay, you can do that trivially, but it's not exactly the same
<mgz> `bzr unshelve --preview -d FROM|patch ...`
<jelmer> lamalex: 'bzr merge --uncommitted' is perhaps whaqt you're looking for?
<jelmer> ams_cs: not really, I'm still investigating but it's a nontrivial problem :-/
<lamalex> jelmer, ah perhaps
<lamalex> indeed
<lamalex> thanks jelmer
<ams_cs> jelmer: is there a work around?
<ams_cs> jelmer: a reimport, perhaps?
<jelmer> ams_cs: a reimport would fix the issue, but it's the data in lp:gcc-linaro that's problematic, not the data in lp:gcc/4.7
<ams_cs> jelmer: oh, so merge to lp:gcc/trunk would be ok, for example (not that that would be a sensible thing to do)
<ams_cs> jelmer: lp:gcc-linaro/4.7 (not lp:gcc-linaro, which is 4.6 based) is a very shallow branch, only recently merged from lp:gcc
<ams_cs> jelmer: the merge was before the 4.7 branch point, so logically, I'd expect everything to be ok
<jelmer> ams_cs: I'm not sure if a merge to lp:gcc/trunk would be ok
<jelmer> ams_cs: we could possibly fix the issue manually for just lp:gcc-linaro/4.7, if it's really urgent for you guys
<jelmer> that might be easier to do short term than to fix the underlying bug to recover from these situations
<ams_cs> jelmer: it's not urgent right now, but in about 3 weeks time it will be!
<jelmer> ok, that's good to know
<kirkland> howdy!  I'm working in bzr with a colleague who's more familiar with git.  he's asking me for the equivalent of 'git rebase' in bzr ... do we have anything like that?
<kirkland> uncommit -> shelve -> merge -> commit -> unshelve -> commit?
<mgz> kirkland: for people who make heavy use of staging in git and never actually merge for progress,
<mgz> just using shelve straight up is a near-ish match, provided you set an editor so 'e' works
<mgz> for actual uses of rebase to do fancy things, can either use uncommit, or the rebase plugin, or quite often branching from an older revision then cherrypick merges
<kirkland> mgz: cool, thanks!
<kirkland> mgz: I'll check out the rebase plugin
<kirkland> cmars232: ^
<cmars232> kirkland mgz: thanks!
<mgrandi> hey mgz, jelmer if you are there
<wgz> hey
<mgrandi> i tried like 4 different git repos and they are all are failing on fastimport
<mgrandi> due to the error i posted last night, forget what it is exactly
<wgz> on the import, or the export?
 * wgz scrolls up
<mgrandi> git fast-export works fine
<mgrandi> but then i do bzr fast-import <something.fe> <bzr_repo> and it fails due to something about tagger
<mgrandi> so im not sure what happened
<mgrandi> but it seems that fast-import-from-git is broken
<wgz> okay, I can't find an existing bug report for that
<wgz> report it... against whichever of bzr-fastimport or python-fastimport is raising the exception
<mgrandi> ok,
<mgrandi> ill do it on my mac real fast since im at werk
<wgz> :)
<mgrandi> i really like how
<mgrandi> this bug refuses to get fixed
<mgrandi> cause we keep getting on tangents >.>
<jelmer> mgrandi: try --fake-missing-tagger as argument to 'git fast-export'
<mgrandi> i'll try
<mgrandi> what is this missing tagger thing that its complaining about though?
<jelmer> mgrandi: see the git-fast-export manpage
<jelmer> to quote:
<jelmer> Some old repositories have tags without a tagger. The fast-import protocol was pretty strict about that, and did not allow that. So fake a tagger to be able to fast-import the output.
<mgrandi> yeah i read that, but what is a 'tagger'?
<jelmer> somebody who created an annotated tag (in git)
<mgrandi> ah
<mgrandi> interesting how it worked the first time when i first reported the bug
<mgrandi> but now it doesn't work
<mgrandi> without the fake-tagger
<jelmer> mgrandi: I think I miss some context - what do you mean with how it worked the first time you reported the bug?
<mgrandi> like, first time i tried this just for fun, fast-importing the linux kernel git repo
<mgrandi> it worked fine, it didn't complain about missing taggers or anything
<mgrandi> like, late 2011
<mgrandi> now i did it again and it complains
<mgrandi> when you think that it would of not imported correctly because of missing taggers when i first did it
<jelmer> mgrandi: is it actually bzr-fastimport that complains about the missing tagger? What's the exact message?
<mgrandi> one sec, exporting a git repo on my computer since im on a diff comp
<mgrandi> why does the mac version of bzrnot have fastimport >.>
<mgrandi> jelmer: exact error: http://bpaste.net/show/25494/
<mgrandi> but with --fake-missing-tagger it works.
<jelmer> mgrandi: I'm pretty sure that code hasn't changed in a long time
<mgrandi> yeah, i just remember not ever knowing about --fake-missing-tagger or any of the other arguments to git fast-export when i did it months ago
<jelmer> mgrandi: did you perhaps use 'bzr fast-export-from-git' rather than git-fast-export?
<mgrandi> thats probably what i did
<mgrandi> im assuming fast-export-from-git makes sure that it uses --fake-misisng-taggers?
<jelmer> mgrandi: that might explain it; I think it specified a few funky options
<jelmer> it seems it specified --signed-tags=warn
<mgrandi> i had to add that, but that doesn't seem to be the same problem
<mgrandi> git's fast-export won't finish if you don't say --signed-tags=warn/drop/whatever
<mgrandi> and wgz, i seemingly can't import 'loader' from meliae, it gives me: ImportError: cannot import name _intset
<jelmer> mgrandi: did you compile meliae?
<mgrandi> i ran setup.py install
<mgrandi> llvm-gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 build/temp.macosx-10.7-intel-2.6/meliae/_intset.o -o build/lib.macosx-10.7-intel-2.6/meliae/_intset.so
<mgrandi> i assume it compiled it from the output there ^
<jelmer> ah, hmm
<mgrandi> how can i tell why its unable to import it?
<jelmer> 'python -c import meliae._intset'
<jelmer> ehm
<jelmer> python -c 'import meliae._intset'
<mgrandi> ImportError: No module named _intset
<jelmer> mgrandi: did it install that file properly?
<mgrandi> yet i see _intset.so in the meliae directory in site-packages
<jelmer> mgrandi: are you still in the meliae source while you're running this perhaps?
<mgrandi> well im on a mac so i shouldn't be getting access errors
<mgrandi> i think its because of the different versions of python on my mac haha
<mgrandi> one sec
<mgrandi> im so confused, it doesn't wnat to import that file >.>
<mgrandi> annnd i'm stupid. i think i was running it on the desktop where the meliae source was so it was trying to import that
<mgrandi> so now i have the memory dump, on mac at least, if wgz or anyone else wants to look at it now
<jelmer> I think murphys law dictates that wgz now will have disappeared.
<mgrandi> haha
<wgz> K
<wgz> ..I was having dinner, even
<wgz> so, the import stage was completed, the boss defeated, and we're on to the dump understanding stage?
<mgrandi> haha
<mgrandi> yes, on my mac, not windows but close enough i guess
<mgrandi> even though ive noticed the same trend, with the import getting slower and slower
<mgrandi> but here is the summary: http://bpaste.net/show/25499/
<wgz> that's not too bad looking, what was the total repo size?
<mgrandi> 47.7 MB
<mgrandi> its the 'git' git repo haha
<mgrandi> i can try it with something bigger now that i know why its failing
<mgrandi> why it was failing*
<wgz> hm, that's not quite so good then.
<mgrandi> any ideas?
<wgz> well, 100MB or so is probably uncompressed bytes cache
<wgz> if you bzip the dump file, is it small enough to upload somewhere?
<mgrandi> yeah, let me do that
<mgrandi> wgz, http://kramidnarg.com/tmp/dump.tgz
<wgz> getting
<mgrandi> let me know if you need anything, i still have the pdb session running
<wgz> most of my little scripts are on the box upstairs so I'll probably leave poking till tomorrow morning
<mgrandi> ok.
<mgrandi> i'll be on sometime tommrow so let me know what you find i guess!
<wgz> will do.
<Omega_> Hey all.  I'm looking to start a project using bzr, however some of the initial boilerplates are done using git projects.
<lifeless> go on...
<Omega_> Is there a way I can have the git and bzr projects coexist?  I'm dealing only with dependencies, so I won't ever be committing my code to them.
<lifeless> I don't see why not
<lifeless> what happens when you try
<Omega_> It would be nice if I could update those dependencies using git (as new stuff comes out), but have my own project and the surrounding structure tracked with bzr
<mgrandi> you can, you can branch git repos
<Omega_> I haven't yet as I'm being a little cautious about how I start this.
<lifeless> is this your first use of bzr?
<lifeless> if so, dive in - if you get it wrong you can always rearrange things
<mgrandi> it sounds like you want a nested tree
<mgrandi> which i dont think bzr supports yet
<lifeless> and you won't have the experience yet to predict issues / non-issues yet.
<mgrandi> having a bzr tree, with nested bzr-git trees
<lifeless> mgrandi: there is a plugin that does nested trees
<lifeless> scmproj I think its called
<mgrandi> but, do you need to push to a git repo?
<mgrandi> or are you just using bzr, but using git to get the other code
<Omega_> No, I'm only consuming their code.
<mgrandi> ok
<mgrandi> then you can branch git repos
<mgrandi> and if you want to set up the nested trees, then you can try that plugin
<mgrandi> and things should be fine~
<Omega_> I'm only getting started with bzr so I'd like to keep the curve down
<mgrandi> its pretty simple, you will just need bzr-git, which you can get from launchpad
<mgrandi> if its not included in bzr already
<Omega_> I'm on Ubuntu, maybe it's already available.
<fullermd> If all they are is "things in git I stick in particular places in my branch", you can just ignore it totally and just leave them independent pieces you git.
<fullermd> Drawback is you'd have to set them in place manually when duplicating your setup, but...
<fullermd> I'd eat that and stick with the conceptually trivial.  Worry about it when it's worth worrying about.
<mgrandi> yeah
<Omega_> Would be nice if bzr had a way to blend in git submodules.
<mgrandi> or you can just
<mgrandi> download a zip of the git code
<mgrandi> and stick it in, and not worry about git at all
<Omega_> The thought has crossed my mind.
<mgrandi> also, wgz, it seems fast import failed at the end
<mgrandi> http://bpaste.net/show/25508/
<mgrandi> Omega_: and then just updated it when stable releases come out, thats usually what i do
<fullermd> Well, that probably would follow after bzr has a way to blend in bzr submodules  8-}
<mgrandi> im not sure what you mean by blend in
<Omega_> The project includes some git submodule dependencies as well
<fullermd> You could always just use a bzr-git bridge or something to get the code into bzr, then just merge it in like a vendor branch from there.
<fullermd> Whether you care about carrying around the weight of that history would bear on it.
<Omega_> So my first step would be to initialize my bzr repo and then use bzr-git to "clone" in that repo.
<Omega_> Then start doing git operations on it to resolve its dependencies?
<fullermd> If it were me, my first step would be to initialize your bzr repo, then use git (or mv or cp or whatever) to stick git repos contianing the git bits in the right places in the tree, and ignore them from bzr.
<fullermd> If you wind up needing bzr to somehow manage them anyway down the line, you'd have a better feel for bzr and just what you need then, and 'll wind up with a better decision on details then anyway.
<mgrandi> anyway, going home, laters all
<Omega_> fullermd: I'm thinking I'm just going to get the whole git repo set up and then lift it into a bzr
<Omega_> I'm getting a feeling that there's a flaw in the git-side's distribution model.
<Omega_> Too much code living everywhere.
<Omega_> Mixed together.
<Omega_> What does bzr do when it sees a .git dir?
<lifeless> nothing, unless you have bzr-git installed
<Omega_> Is there a way I could get on with things and have the two pretend like the other just doesn't exist?
<fullermd> That's what I was aiming at there.
<Omega_> fullermd: Solid.
<fullermd> Just stick a git repo inside your bzr branch in the filesystem.  Use 'bzr ignore $GITDIR' to make bzr not bother looking at it.
<Omega_> Neat, I'll play away.  I've been using git to good effect although I like some of the community/launchpad aspects of bzr.  So I want to become proficient with it.
<Omega_> From everything I'm hearing, it's fairly simple.  Thanks for the help, I'm sure I'll be back with more questions.
<maxb> bzr is kind of like git, except with a UI that mere mortals can understand without a headache, and an awesome plugin infrastructure
<Omega_> maxb: Being approachable with good cross platform and a creat collaboration tool like launchpad really puts all the points where they count.
<Omega_> *great
<poolie> hi all
<lifeless> morning poolie
<poolie> hi there
#bzr 2012-03-20
<mgrandi> so, for some reason the 'git' git repo won't fast-import into bzr, but other smaller ones will
<poolie> mgrandi, there have been bugs in the past where git wouldn't import because it has strange historical artifacts
<poolie> due to buggy versions of git being used on it
<poolie> bzr has similar things
<poolie> i thought it was fixed
<poolie> so you could file a bug
<mgrandi> yeah
<poolie> if there's not already one
<mgrandi> i'll look, its pretty vague
<mgrandi> just a 'keyerror'
<mgrandi> gonna see if i can trace it out~
<mgrandi> so it seems that the reason the fastimport is failing is because the commit a certain tag is referencing is not there...
<mgrandi> so, not sure what bzr is supposed to do in that circumstance
<vila> hi all
<poolie> hi there vila
<vila> poolie: hey !
<jelmer_> hello
<mgz> morning all!
<poolie> hi there
<poolie> let's hang out
<jelmer_> :-(
 * mgrandi is awake
<mgrandi> fastimport is hard.
<mgz> let's go shopping?
<jelmer> heh
<jelmer> mgrandi: what about it, specifically?
<mgrandi> one sec , let me play the 'which tab is playing music' game
<mgrandi> well, i tried importing the 'git' git repo again, and it failed at the end because of a key error
<mgrandi> http://bpaste.net/show/25513/
<mgrandi> i made it drop into pdb, it seems that there is no 'mark' for '2', so im guessing that means a tag is referring to a commit that no longer exists?
<mgz> ...I was just going to suggest BZR_PDB
<mgrandi> well it happened at a specific spot so i just made it drop into pdb when it caught a keyerror exception
<mgz> and you already did it. you're almost and expert now :)
<mgrandi> the "command" its on, is this: http://bpaste.net/show/25520/
<mgrandi> yay!
<mgz> okay, running my cache summary script on your dump from last night
<mgz> ...MemoryError
<mgrandi> wat
<mgrandi> you ran into a memory error running the script?
<mgz> I probably just ran out of memory :)
<mgrandi> you should post that script, it sounds useful :o
<mgz> it's a bit of a hack from before I had a neater way of doing it, but will put up for you to have a go
<wgz> http://float.endofinternet.org/temp/cache_summary.py
<wgz> will try it on this box too... after building meliae
<wgz> ...keyerror
<mgrandi> fun never ends!
<mgrandi> although key error was what i was getting hwen i let it finish, maybe related?
<mgrandi> also do you have a link to my dump? i cant login to my ftp server for some reason
<wgz> no, just an error in how the script pokes around with the objects
<wgz> I had a better way of doing some of this...
<wgz> mgrandi: http://float.endofinternet.org/temp/dump.json.gz
<wgz> okay, three bugs in short succession, should just fix meliae first
<mgrandi> 3 bugs you just found in meliae?
<wgz> well, I probably already filed them
<mgrandi> hmm
<wgz> bug 871450 is particularly annoying but probably easy to work around, every attribute has '"' stuck on the end
<ubot5> Launchpad bug 871450 in Meliae "Test failures from incorrect json string escaping" [Undecided,New] https://launchpad.net/bugs/871450
<mgrandi> hmm
<mgrandi> any easy fix we can do right now?
<wgz> yeah, fiddle with the json import which there's also a bug for
<mgrandi> so it just not doing it right because simplejson is not there and therefore its not using anything to encode json?
<wgz> right.
<wgz> okay, let's try this update...
<mgrandi> doesn't python have a json api?
<mgrandi> built in?
<wgz> indeed it does these days, and based on the module that meliae is using
<wgz> so a little import dance is enough
<wgz> bug 871451
<ubot5> Launchpad bug 871451 in Meliae "Use json module from stdlib as simplejson fallback" [Undecided,New] https://launchpad.net/bugs/871451
<mgrandi> they both use the same api, so i can just say simplejson=json ?
<mgrandi> import json as simplejson?
<wgz> well, the reverse makes more sense, but that's what I did, yeah
<wgz> now just working out some other changes
<mgrandi> ok
<wgz> IndexError: _LRUNode(4423523216 80B 5refs 2par) has only 5 (not 5) references
<wgz> funny.
<mgrandi> o.o
<wgz> it's just the error forgetting to compensate for 0-based indexing :)
<mgrandi> hehe
<mgrandi> how are you supposed to run the unit tests? i can never remember the one liner to do that
<mgrandi> for meliae (and most other python projects)
<wgz> okay, this looks like it mostly works now, just the id type issue left...
<jelmer> mgrandi: usually something like 'make check' or 'trial meliae'
<wgz> mgrandi: there's a script called run_tests.py in the root dir :)
<mgrandi> yeah, but those don't get copied to the site-packages dir =P
<mgrandi> or don't get built, so i was wondering if i just had to copy them and then run them or something easier
<jelmer> wgz: you're still having weekend ? :-P
<jelmer> vila, wgz: I wonder if I could tempt one of you into doing some reviews some time this week
<jelmer> I was about to say I would code for reviews, but that seems kindof pointless...
<vila> jelmer: :)
<vila> jelmer: will do my best
<wgz> mgrandi: http://paste.ubuntu.com/892105/
<wgz> and the script in my temp folder is updated to produce that
<wgz> so, there's 100mb just in decompressed string caches
<mgrandi> did you fix up meliae in the process?
<wgz> some of it, I worked around a few things too
<mgrandi> and i remember python using around 500 mb total when i stopped it
<mgrandi> so 1/5th isn't good
<mgrandi> and what you told me about the meliae test suite, this is what i was looking for =P Oct 02 04:57:14 <wgz>	can do that with... `cd meliae` `Python27\python setup.py build_ext -i` `Python27\python -m unittest meliae.tests.test_suite`
<mgrandi> but now i sleep for another hour
<mgz> vila vila
<vila> something is burning ?
<mgz> when you froze at the end of the hang out this morning
<mgz> I was about to ask if you would help me write some test case things
<vila> oh, hopefully ;)
<mgz> if I commit what I have, can you look over it and make suggestions on how to solve my problems?
<vila> sure
<mgz> okay, will split this file up into several bits
<Pikkachu> hey, I have a few patches for pidgin I need to maintain, and I wonder what's a good way to manage them
<Pikkachu> people from #ubuntu-motu said it's hard
<Pikkachu> I'm slightly thinking of something with Bazaar branches though, anyone has some experience?
<vila> Pikkachu: the best way is to submit them upstream ;)
<vila> Failing that, you should probably do it the debian/ubuntu way and even better the udd way
<vila> googling for udd should give you the pointers to the existing docs
<Pikkachu> thanks for trying
<mgrandi> hello
<mgz> wello
<mgrandi> so
<mgrandi> there are like 5 bugs related to fast import that are preventing us from actually solving said memory problem
<mgz> well, it doesn't help, but it's not a complete stop
<mgz> have you filed all of 'em yet?
<mgrandi> well
<mgrandi> one was the json thing which i think you said was filed
<mgrandi> and might of fixed when i was in class/sleeping haha
<mgrandi> the timezone one is filed, the memory one is filed, and im not 100% sure what is wrong with the one i ran into yesterday
<mgrandi> from what i can tell from the git fast-import man page and the fast-import code, this bug: http://bpaste.net/show/25508/ is caused by a tag referring to a "mark", ( a commit i think) not existing anymore
<mgrandi> i want to make sure thats right before i go reporting it
<wgz> seems possible
<wgz> ideally you'd just make a minimal repo that had the problem
<wgz> but what you've got is enough for a reasonable
<wgz> ...bug report
<wgz> right, just going into the garden briefly
<mgrandi> thing is i dunno how to create a repo with that problem
<mgrandi> or rather, know enough about git
<wgz> that was easier than it could have been
<wgz> had not buried himself anywhere obscure
<mgrandi> like, how do you just delete a commit? ovo
<mgrandi> without deleting the tag that references it
<mgrandi> or, this could like the case with the invalid timezone, that this is a git bug and fastimport just needs to be tolerant of it
<mgrandi> so i have no idea if you know much about the fast import format, i think jelmer does though
<jelmer> I'm reasonably familiar with it
<jelmer> it's all relative
<mgrandi> what is?
<jelmer> how much somebody knows about fastimport
<mgrandi> ah
<mgrandi> well i just meant
<mgrandi> i dunno if you saw the stack trace i pasted above, but basically its just saying that a mark (2) is not found in the dict of marks
<mgrandi> marks -> bzr revision ids
<mgrandi> im assuming that means that bzr did not find a revision with mark 2, and thats why its not there -> why it throws a key error
<jelmer> I haven't looked at the traceback, but that sounds plausible..
<mgrandi> http://bpaste.net/show/25508/ if you didnt see it
<mgrandi> my question is before i look silly on the bug report, is can you do this in git? just remove commits? or is this just another possible bug with git that fastimport needs to be tolerant of
<poolie> hi all
<jelmer> 'mÃÂ¸rning poolie
<wgz> UnicodeDecodeError
<jelmer> wgz.decode('wgz')
<poolie> hi jelmer, wgz
<poolie> :)
<wgz> poolie, am I understanding google plus correctly in that it's actually impossible to do any fixed-width/code formatting?
<wgz> so, it's not really possible to do a post with snippets or diffs or console output such like?
<poolie> i think that's correct
#bzr 2012-03-21
<mgz> morning
<LarstiQ> hi mgz
<jml> mgz: can you do me a favour and sanity check the unicode approach taken in this patch? https://code.launchpad.net/~frankban/testrepository/encoding-error/+merge/98207
<mgz> sure
<jml> mgz: thanks.
<jml> it's to address https://bugs.launchpad.net/testrepository/+bug/955006 (causes http://pastebin.ubuntu.com/881772/)
<ubot5> Ubuntu bug 955006 in Testrepository "Unicode issues can crash testrepository" [Undecided,New]
<mgz> the test probably wants making explicit
<mgz> a statement using a literal bytestring that raises an exception doesn't have consistent behaviour across python versions
<mgz> jml: so, I'd be tempted to wrap stream instead of messing with _format_error, I'll have a quick look at the test repository code
<jml> mgz: oh yeah, good thought. thanks.
<mgz> will put some suggestions in the mp.
<jml> mgz: thank you
<mgz> bah, DocTestMatches is made of hate
<mgz> ....need to pass ELLIPSIS
<mgz> maybe? the mismatch output looks like a match, as always
<mgz> yup, that worked.
<jml> udd.scripts.mass_import - WARNING - Error accessing max threads file /srv/package-import.canonical.com/new/max_threads: [Errno 2] No such file or directory: u'/srv/package-import.canonical.com/new/max_threads'
<jml> what should I do with that warning?
<mgrandi> hallo.
<mgrandi> if anyone is here!
<mgrandi> i probably found the reason behind the 'keyerror' error that you get with some git repos and bzr fast-import
<jelmer> hey mgrandi
<mgrandi> heya
<mgrandi> however it requires some specific command line arguments to git fast-export to fix, and even when i did that, im getting another error related to bencoding
<mgrandi> so gonna have to look into it further
<mgrandi> (im not even sure why bzr is using bencoding, isn't that used for torrents?)
<jelmer> mgrandi: bzr is using bencode to serialize some of its data
<mgrandi> ok
<poolie> hi all
<jelmer> 'morning poolie
<KombuchaKip> https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
<mgrandi> that article is pretty silly
<bob2> those are pretty lame complaints, aside from 3 (as far as it goes)
<bob2> 10 is just stupid and a complaint about github
<bob2> which is not to say there aren't reasonable complaints about git
<mgrandi> its not even a complaint about github
<mgrandi> its usually how launchpad, bitbucket or anything works
<mgrandi> and then someone sas bzr complicates things more, which i dont understand =P
<bob2> holy crap, (someone purporting to be) larry mcvoy commented
<mgrandi> who is that
<jelmer> bitkeeper's author
<bob2> bitkeeper is/was a non-free dvcs that the linux kernel used for a few years, until larry told everyone to go away, leading linus to write git
<mgrandi> ah yeah, they wanted linux to pay money or something?
<mgrandi> or linux foundation*
 * jelmer still recalls lca2005 as ground zero for the current generation of DVCSes
<bob2> no, they refused to sell licenses
<bob2> jelmer, haha indeed
<jelmer> where tridge gave his talk about the bitkeeper protocol, and poolie talked about "Bazaar-NG" for the first time
 * mgrandi reads up on wikipedia
<bob2> wow, 7 years ago
<bob2> bzr-ng did exist pre-lca though
#bzr 2012-03-22
<jelmer> not all that much before though, I think?
<bob2> maybe a couple of months
<bob2> feb iirc
<bob2>  2005-03-09 04:08:15 UTC <- selfhosting as of then
<jelmer> ah, cool.. so about a month before LCA
<bob2> was in baz until then
 * jelmer remembers meeting some baz developers back in the day.. :-)
<kbulgrien> So I used bzr to control files in my home dir... so I could save config for when I reload.
<kbulgrien> I loaded a new system, now I'd like to use bzr to update files.
<kbulgrien> what's the proper way to set connect to the repo?
<mgrandi> update the
<mgrandi> files on your new system?
<bob2> do you mean "check it out"
<bob2> bzr get someurl
<bob2> note that bzr doesn't version perms, so at least your .ssh needs fixing
<kbulgrien> I guess, though in cvs land, checkout would tell me things "are in the way"
<kbulgrien> I would imagine the already existing files are conflicted with what is in bzr
<bob2> what do you want it to do then
<mgrandi> i thought it does version perms
<mgrandi> or is that jsut attributes?
<lifeless> it versions executability
<bob2> +x and that's it
<mgrandi> ah
<mgrandi> interesting
<kbulgrien> well, I want the files to not be conflicted... so I can merge or whatever.
<mgrandi> why only that?
<mgrandi> well, you only want what is in the bzr repo right
<mgrandi> you can just overwrite the old ones
<kbulgrien> I want to compare with what is in bzr and maybe merge or replace.
<mgrandi> you can check your repo to some tmp directory
<mgrandi> run a diff
<kbulgrien> So probably I should just checkout and then figure out from there.
<mgrandi> yeah
<mgrandi> checkout to ~/Desktop/tmp  or whatever
<mgrandi> diff the two directories, then merge if you want to
<kbulgrien> I guess the thing is, I want to carry on version control ... so I want the actual directory linked to bzr
<mgrandi> then you can branch the directory into your home folder
<mgrandi> if they conflict, then bzr will make you resolve it
<kbulgrien> still trying to wrap my head around "distributed" vcs
<mgrandi> this part is still the same as a non distributed vcs
<kbulgrien> well, now it moved existing stuff to .moved... not what I wanted.
<kbulgrien> Conflict adding file blah.  Moved existing file to blah.moved.
<kbulgrien> That's a lot of busted stuff.
<mgrandi> thats probably because the directory wasn't empty, hmm
<mgrandi> but you want the files that you checked out anyway?
<mgrandi> the only stuff in .moved are the things that it tried to add buty already existed
<kbulgrien> well, I guess what I'm after is that I kind of want this virtual configuration that several different machines can reference.
<kbulgrien> I
<mgrandi> well, if you ever update the config
<mgrandi> files you are keeping versioned
<mgrandi> you simply commit that, and all the other machines will get it when they do bzr update
<kbulgrien> well not really, I think I want each machine to be separate, but able to merge with others selectively... don't know if that makes sense or not
<mgrandi> you can have a shared repo on a server, and a branch for each machine.
<kbulgrien> I do have a shared repo set up.
<mgrandi> so, make a branch for each machine
<kbulgrien> I have a branch for this system, but now I want to re-associate these files with that repo and I'd rather it didn't do all the .moved stuff.
<mgrandi> you checked out the files from that branch into your home dir right?
<kbulgrien> I wiped the system and now am trying to reconnect to the repo.
<kbulgrien> yes
<mgrandi> so yeah, its already assosciated, you can do 'bzr bind <url>"
<mgrandi> and that way when you commit, it will commit to the repo branch as well
<kbulgrien> I guess it is a technicality that it made a mess by creating all those .moved files.
<mgrandi> whats in the .moved files, the files that you are versioning?
<mgrandi> (or the copies that were there hwen you checked out)
<kbulgrien> find . -name "*.moved" -exec rm -f {} \;
<mgrandi> yeah, you can just delete that folder or not version it, your choice
<mgrandi> bzr doesn't want to wipe out files that exist when you check out, so its just being safe!
<kbulgrien> but then I sort of think it would have made sense to be able to keep local create a conflict without renaming all the files.
<kbulgrien> That's how cvs would have done it.
<mgrandi> well it would of conflicted, but you checked out for the first time
<mgrandi> into a directory that had non versioned files in it, so thats why it did  that
<mgrandi> now, if you update in the future, if it conflicts it will make you resolve the conflicts
<kbulgrien> I think that's not friendly at all because that can make a big mess.
<mgrandi> i mean, would you rather have it overwrite the files losing data?
<kbulgrien> but maybe that is just me not being in the bzr mindset.
<mgrandi> its just because you checked out data for the first time in a non empty directory
<kbulgrien> No, I think it should decline to put them there and when I bzr status, it tells me that there is a conflict
<kbulgrien> then I have to do something on a file by file basis to clear the conflict.  As it is, it moved perfectly good files out of the way.
<kbulgrien> I think I should be able to say, don't go moving my crap for me.
<mgrandi> well, thats true, but all of those files were files that were in the branch that you checked out, you wanted ones from the repo anyway right?
<mgrandi> i see your point
<kbulgrien> not necessarily.
<kbulgrien> This is a new install.
<mgrandi> im not an expert, but either way, you have the original and the branch version, you can manually move them back, which is almost the same as resolving a conflict
<kbulgrien> The repo might not match the new install.  I'd rather deal with them one by one than the whole mess.
<mgrandi> true
<kbulgrien> sure, I know I can deal with it... I'd just rather not have a bazillion .moved files. I'd rather have some virtual indication of a conflict.
<mgrandi> there might be a way to do that
<mgrandi> im not a super expert at bzr
<kbulgrien> So I guess, my question should have been... can I checkout without it moving all the preexisting files that will conflict when I checkout.
<mgrandi> im not sure, maybe, maybe not, if someone else can weigh in
<kbulgrien> I see I'm not the first to ask this question... stackoverflow has a post... someone said the poster could file a bug if he wanted to.
<mgrandi> i can for you if you don't want to
<mgrandi> link to the stackoverflow post would be good
<kbulgrien> ah... was googling to see other people's threads that had more substance.
<kbulgrien> http://stackoverflow.com/questions/2663846/stop-bazaar-bzr-from-making-moved-files
<kbulgrien> Well, I don't want to come in a newbie and say bzr is broke without trying to think about it more.
<kbulgrien> Its just I do not get amused when something renames dozens of files and I had no say about it.
<spiv> kbulgrien: I think it's a legitimite gripe, bzr could probably do better here
<spiv> Although judging from past discussions on the topic finding a strategy that always works well for everyone is probably impossible.
<spiv> Scattering the .moved files everywhere without warning wouldn't be so bad if there were an easy way to get bzr to undo it
<kbulgrien> well, even an option would help... newb is probably going to bzr help checkout... and then something in help could say or deal with that, but it doesn't
<kbulgrien> There is no warning at all that if you do this, potentially hundreds of files will get renamed.
<kbulgrien> I did that in a source tree a couple of weeks ago... not realizing.  What a freaking mess
<spiv> Right.
<spiv> It's tedious at best to fix (whether by hand or writing some sort of script)
<kbulgrien> I realize once I have experience hopefully I will know better, but then I also know even when I am experienced I make mistakes.
<spiv> Indeed!
<kbulgrien> and sometimes, the mistakes made by an experienced person are more huge than the ones made by newbies.
<kbulgrien> :-)
<spiv> Which is why ideally mistakes either shouldn't cost too much, and/or be easy to undo.
<spiv> Hehe
<spiv> And lots of version control features are great: you can revert, uncommit, in general look at old history etc
<spiv> But the .moved behaviour really breaks you out of that
<spiv> Because while in principle all your precious bytes are still intact somewhere it's a PITA to get them back in the shape you want them.
<kbulgrien> cvs screams at me... there is a file in the way... and it does nothing except scream about a conflict until I resolve it.  I kind of like that.
<kbulgrien> but I suppose there will be people who feel the reverse.
<spiv> So I find that fear of .moved really slows me down because I have to anticipate when it might happen so I can avoid it :(
<mgrandi> well you can't really revert it becuase those files arn't in version control, but yeah
<mgrandi> i feel bzr should warn, like the --use-existing-dir
<spiv> "slows down" might be a bit of a strong claim, but it does feel like some sort of mental drag.
<spiv> mgrandi: well, as a hypothetical, bzr could version them if it's worried you might lose them!
<kbulgrien> maybe, but then that means it automatically creats a branch, right, and I'm not sure about that either.
<spiv> (Perhaps in a separate temp repo to avoid polluting your main one if you want to be finicky etc, my point is the tool could be better)
<spiv> I mean, here we have a tool that's all about saving history, that you can rely on to not lose old revisions
<spiv> And has all sorts of clever code to do that nicely
<kbulgrien> I wonder how etckeeper works.
<spiv> And then for this case it's like you're dropped into the stone age of version control again
<kbulgrien> I am also trying to version OS files.
<spiv> Where people manually rename foo.txt to foo.txt.bak, or foo.txt.bak.bak.bak ;)
<kbulgrien> perms saved me, but it did try to move boot to boot.moved.
<spiv> IIRC etckeeper writes out the extra metadata about perms to a file and gets bzr to version that, and probably has a bunch of policy layered on top to give nicer merge defaults for config files
<spiv> I expect its docs would explain :)
<kbulgrien> yeah, just haven't got as far as installing it.
<mgrandi> what is etckeeper?
<kbulgrien> didn't realize it was a front end to vcs until just the other day.
<kbulgrien> http://joey.kitenet.net/code/etckeeper/
<kbulgrien> I wish more distributions packaged it.
<kbulgrien> more being more than fedora
<kbulgrien> oh, i see debian and ubuntu package it but they are .deb.  I think there are repackagers that can convert to .rpm and the like.
<mgrandi> ah interesting.
<kbulgrien> ( I tried to rebuild the rpm from el/fedora and it wouldn't due to .spec problem I didn't figure out)
<mgrandi> ah
<mgrandi> debs and rpms are black magic
<kbulgrien> https://www.linux.com/learn/tutorials/512306-weekend-project-control-your-configuration-with-etckeeper
<kbulgrien> anyway, etckeeper was a bit of a rabbit trail, but .moved is related because .moved in version controlled OS files is bad.
<mgrandi> you can try posting on the mailing list about it
<mgrandi> im curious on what other people say about it
<wgz> pre morning all
<mgrandi> hey wgz
<mgrandi> it is technically morning i guess
<mgrandi> i figured out one of the problems i was having with fastimport
<vila> hi all !
<mgrandi> hi
<vila> kbulgrien: I think what is you're after is getting your branch in some tmp dir *then* moving the '.bzr' directory (and only it) to '~' and *finally* do a 'bzr status'
<poolie> hi vila, hi vgz,
<poolie> mgrandi
<mgrandi> still
<mgrandi> vila, that seem slike a really hackish workaround =P
<vila> mgrandi: it is :) But the point is to avoid generating '.moved' files ;)
<mgrandi> i guess, i still think the workaround he said, where the files are just marked as conflicting if that happens
<mgrandi> would be better
 * vila nods
<vila> But how would you call such operation ?
<vila> poolie: hey !
<mgrandi> what do you mean?
<vila> checkout-in-an-existing-dir-but-please-dont-mess-it-up is a bit long ;)
<vila> I mean bzr has no idea what the status of the existing file is
<mgrandi> well it obviously knows if there is an existing file
<mgrandi> cause it moves it
<vila> but it cannot complete the checkout without moving it
<vila> and merging  requires some knowledge about the actual tree
<vila> that knowledge is missing in this particular case
<mgrandi> hmm
<mgrandi> would it be possible to do a merge once it moved it to .moved?
<vila> Note that I'm explaining what is happening, not denying the usefulness of the feature
<vila> I have the same use case myself (maintaining config files across several machines), but I use a different workflow
<mgrandi> that way it can complete the checkout
<vila> short answer: no
<vila> a checkout is a pristine copy of a given revision
<vila> bzr *does* a merge when pulling if you have uncommitted changes but in this case it knows what have been changed
<vila> s/have/has/ ?
<mgrandi> yeah
<mgrandi> here it doesn't because it moved the files
<vila> yeah, I didn't check the code but roughly I suspect it consider them unknown and as such cannot merge their content with the ones that are checked out
<mgrandi> in any case, id make the case for a option to warn before it moves the files
<mgrandi> like --use-existing-dir
<vila> Note that a 'bzr resolve --take-this' should restore some sanity by getting the .moved files back but will record a deletion of the versioned files (which is not what kbulgrien want I'm pretty sure)
<vila> yup, worth a bug
<mgrandi> cause i got bitten by that
<mgrandi> sometime in the past
<vila> yeah, I suspect most of bzr users don't fall into the trap which is why no bugs (that I know of) was ever filed
<mgrandi> but like you said, i dunno how one would fix the problem other then having an option
<vila> Also note that the actual behavior is a legitimate use case
<mgrandi> someone mentioned creating a temporary repository
<mgrandi> yeah, having an option to either move files, merge them or abort seems like the ideal case
<vila> yup, warns if files are in the way an requires an option to complete sounds fine
<mgrandi> would a temporary branch work, in some temp directry?
<mgrandi> add the original files and then try to merge the ones that are incoming from the real branch operation?
<vila> ha, you'll run into the 'parallel import' issues I think (I can never remember which command allows one to use existing file-ids...)
<vila> right, 'bzr add'
<mgrandi> parallel import issues?
<vila> bzr internally use file-ids to track renames
<vila> a file-id is associated to a relative path in the tree when the file is added, then the file can be renamed but keeps its file-id
<mgrandi> ah
<vila> if the same relative path is added in a different branch, it receives a different file-id
<mgrandi> and that confuses things?
<vila> when both branches are merged, the file-ids conflict: parallel import
<vila> it's the weak point in the rename tracking and we haven't fixed it yet :-/
<mgrandi> how would it ideally be fixed?
<vila> roughly by keeping track of aliases between file-ids so when looking at the history of a given file bzr an decide how to join/split the histories of different file-ids
<vila> s/an/can/
<mgrandi> so it would be able to tell that two different file-ids came from the same path? (aka same file)
<vila> yes
<mgrandi> ah
<mgrandi> sounds like a lot of internal hacking to get that to work, but it would pay off if just to fixed the first issue
<vila> mgrandi: 'first issue' means ?
<vila> parallel import of kbulgrien use case ?
<mgrandi> yeah
<mgrandi> was gonna say moving files when checking out and files conflict
<vila> sort of, in this case, the existing files probably have *no* file-ids at all so using the existing ones should do
<mgrandi> true
<mgrandi> its 1 am, not thinking straight haha
<vila> doing a tmp branch and 'bzr add --file-ids-from <tmp branch>'  and then 'bzr merge' should also give better results but is almost as hackish as moving the '.bzr' directory and probably even scarier ;)
<vila> mgrandi: well, parallel import is not something you want to think about without the clearest mind and a good understanding of the bzr merge internals ;-)
<mgrandi> heh i guess not
<mgrandi> on that note i head to bed. night
<mgz> morning all!
 * jelmer sees a fairly scary patch to bzrlib/win32utils.py
<mgz> hm, it's not really as bad as it looks, but I'm not sure Alexander's suggestion to add specific detection for argument skew was really the right thing
<kbulgrien> vila: I don't mind hearing your workflow.  I am just doing things the way I do them with the other vcs I use a lot.
<kbulgrien> I also am not entirely opposed to idea given regarding moving of .bzr folder.  It's not like I didnt do hackish stuff at times with the other vcs.
<kbulgrien> I still think, however, that the .moved behavior is unpleasant.
<kbulgrien> Anyway, work beckons and I have to go use my old vcs for a while until I get them to jump over to bzr (which I intend to do).
<vila> my workflow involves a script that creates a bunch of symlinks (based on a textual description mapping a tree kept under version control  ans symlinks under my home directory). The script makes backups when it encounters files or directories where it want to install the symlinks
<vila> I agree the .moved behavior is unpleasant in your use case ;)
<kbulgrien> I created a big script called os2cvs a long time ago.  i have a very short os2bzr script that deals only with perms.  I was hoping to not write my own big front end again.
<vila> but really checkout doesn't expect anything in its way so what you may do is cheat: create a clean branch and working tree somewhere, move the '.bzr' and do 'bzr st' and/or 'bzr diff'
<vila> s/the '.bzr'/& directory where you want it to live/
<kbulgrien> I will try that on for size.  Thanks.
<vila> kbulgrien: but are you interested in keeping your home directory under vc or /etc ? There are different issues for each
<vila> my remarks above are for ~
<kbulgrien> both, but I deal with both differently.
<kbulgrien> Part of my concern is for the day I switch over at work.
<kbulgrien> When I convert the big giant repositories to bzr... everyone will have workspaces that are not in bzr, but are current works in progress
<vila> right, etckeeper is probably what you want for etc (I have a completely different workflow for /etc myself coping with all OSes I had to admin and etckeeper didn't exist when I started)
<kbulgrien> When they try to switch them over from old VCS to new VCS, bam.
<vila> right
<kbulgrien> Now I realize we probably have to checkout to different sandbox and manually merge, but that seems an unnecessary pain.
<kbulgrien> Sure, re etckeeper.  I only just realized a few days ago it was a front end that used bzr underneath.
<vila> right, what you want is a way to say: here is a non-versioned tree, how does it compare to some versioned tree and how can I converge. Right ?
<kbulgrien> I just had already started using my own process and haven't d/l and looked at it yet.
<kbulgrien> That's right.
<kbulgrien> I want to keep the pain factor low.  My coworkers are going to hate moving as it is.
<vila> but their trees are not under vc right now right ?
<kbulgrien> another vc, not bzr, but I would convert the old vc repo to bzr.  I tested that already.
<vila> oh, things may be a bit different in this case
<kbulgrien> I realize having used old vc, I may have a different world view that I am willing to adjust, except that one reason bzr made the cut was because of all the new vc, it let me change my worldview the least.
<kbulgrien> I'm not really sure how they would be different.
<vila> right, that's nice to say, and yes, some things are the same, others are different or new, so indeed your have some work/experiments to do to feel at ease
<vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief have a good definition of some basic concepts
<kbulgrien> ok.  will look at it.  right now I am late for work... too bad because this discussion is helful for work too.
<kbulgrien> and I am not allowed to use resources like this there.
<vila> :-/
<vila> Try the mailing list may be ?
<kbulgrien> yeah, I need to do that.  Besides, its more friendly that things worked out are then archived for others use.
<kbulgrien> nothing like instant gratification though, eh?
<kbulgrien> :-)
<kbulgrien> anyway... later... and thanks.
<vila> have a nice day ;)
<dakira> hi. i'm new to collaborating so I have a question. I just pulled a project (which I'm not a member of) from launchpad and fixed a bug. Is there an automatic way to get my fix to the dev or do I have to manually create a patch, file a bugreport and attach the patch to the bugreport?
<dakira> What is the proposed way to handle such things?
<mgz> you push your branch up to your namespace, and propose a merge, generally
<mgz> so, `bzr branch lp:foo` `cd foo` ...fix stuff in foo and commit... `bzr push lp:~/foo/name_for_your_changes`
<mgz> then can do a merge proposal via the website, or `bzr lp-propose`
<dakira> mgz: okay thanks!
<mgz> working on ubuntu packaging rather than directly upstream with launchpad is a little different, but same general idea
<mgrandi> hallo
<m4n1sh> using bzrlib how can I find out the files changed for a particular commit if i have the revision number?
<mgrandi> not sure, i dont know bzrlib that well, maybe someone else can answer
<m4n1sh> jelmer: ping
<bzrperson> If I bzr shelve something, does it get saved on the server with bzr push?
<bzrperson> I'm moving HDs and don't want to commit the current things, but do want them saved
<wgz> bzrperson: nope, it's local to the tree, not the branch
<bzrperson> OK
<wgz> bzrperson: just commit and push to another branch
<wgz> leaving your main branch as is
<bzrperson> Oh
<bzrperson> Alright
<wgz> you can cherrypick merge it back to your main branch later if you like :)
<poolie> hi all
#bzr 2012-03-23
<jelmer> hi poolie, wgz
<jelmer> m4n1sh: pong
<mgz> morning all
<vila> morning mgz !
<jelmer> hah, mgz beats me in replying to erik's mail
<mgz> :)
<mgz> I normally lose that race
<mgz> I'm used to hitting reply and seeing a response from jelmer 4 minutes before
 * jelmer is having a slow day
<mgz> hm, vila left just when I was going to bother him with some questions
<vila> mgz: (gentle nudge) bzr-2.6b1 windows installers ?
<vila> maxb: beta ppa update for 2.6b1 ?
<fullermd> vila: 2.6.0 release?   :p
<vila> hehe, I'm already late for 2.5.1, but I'm really ahead of schedule for 2.6.0 :-D
<mgz> vila, things are pretty borked right now
<vila> mgz: can you elaborate ? :-)
<mgz> well, explorer won't start without the mp jelmer submitted this morning
<mgz> gordon needed to backport your change from post-2.6b1?
<mgz> the installer work for translations still needs doing
<mgz> there's not much point doing release stuff without fixing the code problems
<fullermd> For Windows?  Why not?  Microsoft has been doing it for years...
<vila> Can you summarize in a mail to the list ?
<vila> gordong did release an osx installer, which change are you referring to ?
<vila> oh, right, sry
<vila> let me check
<vila> yeah, it did include the fix for building the docs,
<vila> no comma, just read it as a period ;0)
<vila> oh crap, my printer is borked...
<m4n1sh> is there a code snippet using which I can find the list of files changed for a bzr working tree using bzrlib?
<mgz> m4n1sh: something like...
<m4n1sh> like if I have a WorkTree
<m4n1sh> I used open to open a repository
<m4n1sh> and then want to goto a specific commit number
<m4n1sh> mgz: and fetch the list of files changed/added/deleted in that commit
<mgz> >>> from bzrlib.workingtree import WorkingTree
<mgz> >>> tree = WorkingTree.open(".")
<mgz> >>> lock = tree.lock_read()
<mgz> >>> list(tree.iter_changes(tree.basis_tree()))
<mgz> see the docstring in the code for what the bits of the tuple mean
<m4n1sh> how do I pinpoint to a specific commit?
<m4n1sh> I know iter_changes, but the name of that argument it takes was sort of cryptic
<mgz> pass something other than basis_tree
<m4n1sh> like?
<m4n1sh> say I have a commit number 343
<m4n1sh> then how do I use that method
<m4n1sh> I was stuck on iter_changed method for an hour becuase I did not figure out  how to use it for a specific revision number
<mgz> you turn the number into a revid, then pass the revid to revision_tree()
<mgz> that's using branch and repository respectively
<mgz> eg:
<mgz> >>> branch = tree.branch
<mgz> >>> prev_tree = branch.repository.revision_tree(branch.get_rev_id(728))
<mgz> >>> list(tree.iter_changes(prev_tree))
<mgz> iterates over changes between r728 and the current tree state
<mgz> same principle if you want the differences between r728 and r729, you just get two prev trees (and can open and lock the branch rather than the working tree in the first place)
<mgz> m4n1sh: does that help?
<m4n1sh> mgz: trying it out
<m4n1sh> mgz: works
<m4n1sh> I get
<m4n1sh> ('configure.ac-20110725232344-gqsb35ufn2i0pf3g-9', (u'configure.ac', u'configure.ac'), True, (True, True), ('tree_root-20110725232341-3el21lx99g2juau0-1', 'tree_root-20110725232341-3el21lx99g2juau0-1'), (u'configure.ac', u'configure.ac'
<m4n1sh> ), ('file', 'file'), (False, False))
<m4n1sh> now how do I make out if this file configure.ac is added/removed/edited?
<mgz> as I said, see the docstring (in bzrlib/tree.py InterTree.iter_changes)
<mgz> the (source, target) tuple at [1] tells if you it where added, removed, or renamed
<mgz> the changed_content marker at [2] tells you if it was edited
<mgz> so, your example the file was changed that rev
<mgz> see the code in bzrlib/delta.py for code doing this kind of thing
<mgz> report_changes there takes a tuple in that form and makes pretty output
<caliboy> hello
<mgrandi> hey
<caliboy> can you help me with my wireless network
<mgrandi> uhh sure, does this have anything to do with bzr though? :o
<caliboy> no
<mgrandi> then why ask here? =P
<caliboy> idk i didnt know there was a categories thing
<kbulgrien> ok, well, it is on ml now
#bzr 2012-03-24
<kbulgrien> so here's the thing, about the checkout into an existing workspace.
<kbulgrien> Now it is telling me all the stuff is removed.
<kbulgrien> all I did, to my knowledge is bzr resolve conflict.
<kbulgrien> what am I supposed to do to clear a conflict without it assuming it should now remove the stuff?
<kbulgrien> If I re-add the removed stuff, it is both removed and added.
<kbulgrien> It should be just modified
<LarstiQ> kbulgrien: --take-other/--take-this?
<kbulgrien> Problematic not being able to status without recurse.
<jelmer> kbulgrien: isn't there --no-recurse?
#bzr 2012-03-25
<kbulgrien> $ bzr status --no-recurse
<kbulgrien> bzr: ERROR: no such option: --no-recurse
<kbulgrien> $ bzr status --no-recurse
<kbulgrien> bzr: ERROR: no such option: --no-recurse
<kbulgrien> jelmer: no
<kbulgrien> $ bzr status --no-recurse
<kbulgrien> bzr: ERROR: no such option: --no-recurse
<jelmer> kbulgrien: I get the point, no need to repeat it three times :)
<kbulgrien> mistake
<kbulgrien> sorry
<jelmer> kbulgrien: I must be mistaken, I thought bzr status had a --no-recurse option too
<kbulgrien> was scrolled up and thought middle click wasn't pasting.
<kbulgrien> well, it gets annoyed when there is read-only stuff... haven't figured out if it bails or simply reports problem, but --no-recurse would avoid that.
<jelmer> kbulgrien: what kind of read-only stuff? bzr status shouldn't write to any files in the working tree
<kbulgrien> weigon sure comes and goes a lot
<jelmer> yeah
<jelmer> weigon: ayt?
<kbulgrien> well, again, regarding ro stuff, its stuff that is probably atypical of what most people do.
<kbulgrien> I'm just changing what I used to do with another vcs over to bzr.
<jelmer> kbulgrien: how is bzr complaining though/
<kbulgrien> $ bzr status *
<kbulgrien> bzr: ERROR: [Errno 13] Permission denied: '/etc/shorewall/hosts'
<jelmer> kbulgrien: ah, not readable at all
<jelmer> that's different from readonly :)
<kbulgrien> probably another reason I need to look at etc keeper if I am going to use bzr for this
<kbulgrien> yeah, punchy. sorry.  been working in the yard all day. am beat.
<jelmer> kbulgrien: and .bzr/ is readable?
<kbulgrien> yes
<jelmer> kbulgrien: why isn't /etc/shorewall/hosts not openable in tha tcase?
<jelmer> presumably it has the same data as /etc/shorewall/hosts
<kbulgrien> because I am not root
<jelmer> kbulgrien: but why is .bzr/ readable for non-root in that case?
<jelmer> kbulgrien: presumably that would allow you to get at data that is otherwise only accessible for root
<kbulgrien> sudo
<kbulgrien> I only use it when absolutely necessary
<kbulgrien> so for controlling those files I sudo, otherwise I work as sysadmin user.
<kbulgrien> That's fine for everything else, but a pain when checking status.
<kbulgrien> It's ok... as long as it isn'
<kbulgrien> t bailing out.
<kbulgrien> But then I'd guess if it wasn't bailing out it would have showed all the stuff.
<jelmer> kbulgrien: why is that file not readable then though?
<kbulgrien> all /etc/shorewall is rw root.
<kbulgrien> I was wanting status in /etc, not etc/shorewall.
<kbulgrien> I didn't need sudo in /etc
<kbulgrien> So I didn't use it, but then it recursed and apparently is bailing out on the unreadable.
<jelmer> kbulgrien: why is it not readable for regular users I mean? Presumably they can get at its contents from .bzr/ anyway.
<jelmer> lifeless: ping
<lifeless> hmm?
<kbulgrien> bzr is operator.root 770, so no, regular users can't get to it.
<jelmer> lifeless: can you perhaps ban weigon, he isn't responding and has been reconnecting every two or three minutes for the last day or so
<jelmer> kbulgrien: then how do you expect 'bzr status' to work as regular user? It needs to access .bzr/
<kbulgrien> I'm tempted to say forget it, but, I expect to have to do some magic to check status of /etc/shorewall.
<kbulgrien> I have a little bitty front-end script that does the magic - when I need it.
<kbulgrien> My point was that all I wanted to do was check status of /etc, not everything underneath etc.
<kbulgrien> There is no way to limit bzr status to what I want to do so I don't have to use the magic unnecessasrily
<jelmer> kbulgrien: that's bug 287880
<ubot5> Launchpad bug 287880 in Bazaar "bzr status: add non-recursive option" [Medium,Confirmed] https://launchpad.net/bugs/287880
<kbulgrien> ok
<kbulgrien> I need to get more acquainted with launchpad
<jelmer> I think the permissions is a different issue though, but I don't really understand what you're trying to do
<kbulgrien> I'm version controlling "my" edits in an OS.  someone told me I should use etckeeper for that, but I've been doing things this way for years with CVS.
<kbulgrien> So that's what I tried doing when I decided to jump over to bzr.
<kbulgrien> The frontend for bzr is tiny compared to the frontend for cvs.
<kbulgrien> It was also giving me a practical at-home experience with bzr to learn it.
<kbulgrien> I have to get comfortable with it on my own before I push it up at work.
<kbulgrien> I don' t have an bzr projects at home at the moment, other than minor server stuff.
<kbulgrien> I realize my usecase is very odd.
<jelmer> kbulgrien: I don't think your usecase is very odd - I'm using etckeeper too
<kbulgrien> I just haven't tried etckeeper.
<jelmer> kbulgrien: my /etc/.bzr/ is (intentionally) not accessible by non-root, since it versions some files that I don't want non-root users on my system to be able to access
<kbulgrien> I fell into doing things the way I had always done them with cvs.
<kbulgrien> I didn't even realize etckeeper was a vcs frontend until someone on here told me to look at it.
<jelmer> kbulgrien: I think one of the differences with CVS is that CVS has a single file with the data on each versioned file. Bazaar stores information on multiple files together in single files (a pack)
<kbulgrien> yes.  when I am doing os stuff, I have user is special.
<kbulgrien> I never do os config as my regular user.
<kbulgrien> I cannot even sudo with my regular user.
<jelmer> kbulgrien: can that os config user access /etc/shorewall/hosts ?
<kbulgrien> So this user is non-root, so his repo and sandboxes are not accessible to anyone else.
<kbulgrien> only by sudo
<kbulgrien> my front end script stats the file, gets perms, saves them, tweaks perms so bzr can do what it wants, then puts everything back, so bzr can run non-root too.
<jelmer> kbulgrien: that sounds like a race condition waiting to happen?
<kbulgrien> not when I am the only admin, eh?
<fullermd> Waiting?   :p
<kbulgrien> sure, its technically an exposure as it lowers perm tightness, but again, this user is not normal.
<kbulgrien> all it needs is group root accessible.  other users aren't group root.
<jelmer> kbulgrien: in that case, why doesn't your script tweak the permissions of /etc/shorewall/hosts?
<kbulgrien> If I was working on etc/shorewall I would have used it.
<kbulgrien> but I was trying to get status of say /etc/* for changes, so didn't need the frontend.
<kbulgrien> It would get very messy to recurse and tweak perms for stuff like that when I didn't want to do it.
<kbulgrien> That would be a disaster waiting to happen.
<kbulgrien> The only problem is that I cannot avoid recurse.
<jelmer> kbulgrien: unlike CVS, bzr versions directories too though. so if you run 'bzr status shorewall' it will recurse into that directory
<jelmer> kbulgrien: I think (but am not sure) if you 'bzr status FILE'  it won't access the other files in the directory
<kbulgrien> sure.
<kbulgrien> agreed
<kbulgrien> so I tried bzr status .
<kbulgrien> I guess I could go find . -type f -maxdepth 1 -exec bzr status, but that seems unreasonable.
<fullermd> Well, since bzr versions directories, I'd half expect a non-recursive status of '.' to have to touch shorewall too (not shorewall/foo necessary, but the inode of the dir at least)
<jelmer> kbulgrien: if you give it a directory it will report the status for that directory recursively
<kbulgrien> yes
<kbulgrien> I was grasping at straws and am new to bzr
<kbulgrien> I was amazed that there was no limit recursion option.
<kbulgrien> ie. cvs recurses. but cvs has a limit recursion option.  its not the recursion that I mind.
<kbulgrien> It would be odd for it not to recurse.
<kbulgrien> I limit recursion a lot when I use cvs.
<kbulgrien> Probably because I use partial checkouts a lot.  something else that I guess bzr doesn't support.
<kbulgrien> Not being able to do partial checkouts is something I am not sure how to work around at work.
<jelmer> kbulgrien: there are 'views', which give you some of the properties of partial checkouts
 * jelmer gets some sleep.. clock just went from 1:59 to 3 here :)
<kbulgrien> ok
<kbulgrien> thanks, btw
 * kbulgrien thinks it would be nice to be able to define a view in a "reverse" mode.  By specifying things that are NOT wanted.
<kbulgrien> Some times the list of things you do not want to see is a lot smaller than what you do want to see.
<fullermd> Mmph.  Views are totally not a useful substitute for partial checkouts.
<kbulgrien> well, that is a given IMO
<kbulgrien> I am having a hard time thinking about using a vcs without partial checkouts.
<kbulgrien> At work, we use a big repo for a product.  S/W guys don't want to see the massive VHDL area, Tool 1 guys don't want to have to deal with Tool x stuff, but we want to be able to tag the whole project easily.
<kbulgrien> Tool n has source files that can be 100's mb XML.  one guy works with that.  the other 10 shouldn't have to have that checked out and updated, status'd, etc.
<kbulgrien> I wanted to convert over to bzr, but that looks daunting without partial checkouts.
<kbulgrien> I think I heard something about externals... might have to look into that as a possibility
<fullermd> There are not ungood reasons why 80% of the time, you don't really want partial checkouts.  And other as-good-or-better solutions to the remaining 10%.
<fullermd> So that completely covers the...   uh...  wait.  It's been a long time since I took math, but..
<kbulgrien> :-)
<kbulgrien> I think it is a bug that bzr status doesn't return status just because it cannot read a file it tries to return status on.  It should report the problem and keep going IMO.
<fullermd> That does open up the possibility of a tidal wave of spam.
<fullermd> Of course, that could probably equally well be labelled as giving a silly answer to a silly question...
 * kbulgrien thinks bzr status IS a tidal wave of SPAM.  I see no good reason for bzr status to give status for the WHOLE branch by default.
<lifeless> kbulgrien: what should be the default ?
<kbulgrien> I never (actually I suppose almost never) want status on the whole branch when I ask for status below the top of the branch.
<kbulgrien> default should be status at current dir and below... a NORMAL recurse
<kbulgrien> when I bzr commit a low level, it does not commit the WHOLE branch.
<kbulgrien> (does it?)
 * kbulgrien is a newb.  I might not have actually tried that.
<kbulgrien> I guess bzr status . is a reasonable habit to get into, but I still don't like the default.
<kbulgrien> I guess I can see some people might like the default in some sense.
<kbulgrien> I say normal, like rm -rf doesn't wipe out / unless I am in root.
<kbulgrien> This is a default that differs from the norm of most command line tools.
<j605> hi
<j605> i was trying to checkout a project, but i get an error. Permission denied(Public Key). I am running the command as an administrator(using sudo). Is there a way around it?
<j605> figured it out, had to copy my .ssh directory to /root :)
<fullermd> kbulgrien: Actually, it _does_ commit the whole tree...
<fullermd> kbulgrien: 's a change that took me a while to get used to coming from CVS, but I was happy for it.
<Peng> /1/14
<poolie> hi all
#bzr 2013-03-19
<marcoceppi> Is this the best place to ask questions about bzrlib?
<LarstiQ> marcoceppi: or possibly the mailing list
<marcoceppi> Well, I guess I'll just ask, is there any way to "close" a RemoteBranch in bzrlib? I keep getting Connection Timeout messages after opening a RemoteBranch
#bzr 2013-03-20
<Ratchett> hello everyone
 * thumper waves
<Ratchett> :)
<Ratchett> I just thought I should let the world know that I managed to get a key and completely link Bazaar to launchpad with no help
 * Ratchett feels on top of the world
 * jelmer waves
<cheney> when you checkout a bzr branch at a certain revision how do you find out the number later on? bzr log shows future commits as well
<LeoNerd> revno  maybe?
<cheney> ah nm i finally figured it out, surprised bzr info didn't show it though
<cheney> bzr revno --tree
<LeoNerd> .. what he said
<cheney> having to track down an old bug fix, going through ~ 1500 commits to do it
#bzr 2013-03-21
<mahendra> using bzr 2.5.1 when doing $bzr pull lp:postorius. Getting this error : ssh: connect to host bazaar.launchpad.net port 22: Connection refused ConnectionReset reading response for 'get', retrying ssh: connect to host bazaar.launchpad.net port 22: Connection refused bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persis
<mahendra> I'm using http proxy.
<mgz> mahendra: not over ssh you're not
<mgz> `bzr pull http://launchpad.net/postorius` will work for fetching the code only
<mgz> http proxies do not tunnel ssh by default
<mgz> if you have a launchpad login set, bzr uses ssh so you can have write access to branches
<mahendra> solved. Thanks a lot martin.
<mgz> you can use the --remember flag to pull in that branch if you're always behind that proxy and only ever need read only access
<mahendra> getting stuck during push using command : $bzr push https://launchpad.net/~mahendra007-s/postorius/inline-help-improve/ .it gives error in between bzr: ERROR: Transport operation not possible: http does not support mkdir()
<jelmer> mahendra: you can't push over HTTP, you will need to use SSH for that
<mgz> mahendra: this is what I was talking about with read only vs write access earlier
<mahendra> okay but i get same error connection refused when usiong ssh.
<jelmer> mahendra: your computer has trouble connecting to Launchpad using SSH; if you're using a proxy for HTTP then you might have to setup one for SSH too
<mgz> ideally you need your network admins to permit you ssh, otherwise you need some tunnelling magc
<mahendra> then how to configure ssh proxy server:port?
<mgz> mahendra: eg, read the various answers on https://stackoverflow.com/questions/181341
<mgz> proxytunnel or corkscrew should work for you
<mahendra> thats fine. But i just came to know that there is different socks proxy server which allows ssh connection from our institute. so i there any way to configure it with bzr like specifying in bazaar.conf or anything else?
<mgz> yes, you can do that.
<mgz> generally you just put the details in your .ssh/config
<mgz> but read whatever documentation your institute has on using ssh and follow that
<mgz> bzr just uses ssh, whatever works for ssh will work for bzr
<mgz> mahendra: debug ssh connection issues by doing `ssh -vv bazaar.launchpad.net`
<mahendra> OpenSSH_5.3p1 Debian-3ubuntu3, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /home/mahendra/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ssh: Could not resolve hostname bazaar.launchapd.net: Name or service not known
<mgz> will give you a big log and say roughly where it fails (this is assuming you have your launchpad username as User in ~/.ssh/config)
<mgz> you tyoped the domain :)
<mahendra> OpenSSH_5.3p1 Debian-3ubuntu3, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /home/mahendra/.ssh/config debug1: Applying options for bazaar.launchpad.net debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Executing proxy command: exec /usr/local/bin/corkscrew 10.3.100.209 8080 bazaar.launchpad.net 22 debug1: identity file /home/mahendra/.ssh/id_
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mahendra> http://paste.ubuntu.com/5634489/
<mahendra> after 20-30 seconds it shows ssh_exchange_identification: Connection closed by remote host
<mgz> is that the host/port for the http proxy or https proxy?
<mgz> you can try running the corkscrew line in the terminal to see if it givs you more details
<mgz> ie, just `/usr/local/bin/corkscrew 10.3.100.209 8080 bazaar.launchpad.net 22`
<mgz> ah... and there's no user details
<mahendra> yes thats a http proxy host/port
<mgz> you probably wanttry the https one
<mahendra> i thinks it allows both
<mgz> it should, but one may work where the other does not
<mahendra> running corkscrew doesn't show anything.
<mgz> did swapping in the https proxy in .ssh/config change the ssh debug output at all?
<mahendra> no
<mgz> really you just need to bug your own network admins to help you get set up here, this is all just down to getting a working ssh connection out
<mgz> do they have a support desk you can drop into for help?
<mahendra> no but i will try to get support from other devs if they know about this issue.
<mahendra> mgz: is this problem is also happening with my system http://ubuntuforums.org/showthread.php?t=1905581
<mgz> mahendra: again, debug ssh issues with `ssh -vv bazaar.launchpad.net`
<mgz> you should only get publickey denied if you're actually connecting though, so that's progress
<mahendra> mgz: it still gives same thing http://paste.ubuntu.com/5634787/
<kolbe> i am trying to branch a pretty large project (mysql-server/5.5) from launchpad on a spotty internet connection... occasionally bzr stalls. there doesn't seem to be any way to resume. i seem to have to manually remove the local branch and start over. am i missing something here? is there some trick to get this to work?
<bob2> pretty sure you can resume if you branch into a shared repository
#bzr 2013-03-22
<jelmer> kolbe: what bob2 said
<kolbe> How do I go about branching into a shared repository and resuming such a thing?
<bob2> make repository
<bob2> cd to it
<bob2> branch
<bob2> success
<marcoceppi> Where is the bazaar.conf on Windows 7 installs?
<LarstiQ> marcoceppi: `bzr --version` has a line with 'Bazaar configuriation:'
<marcoceppi> LarstiQ I try overriding ssl.ca_certs in a bazaar.conf file in the "configuration directory" but it doesn't seem to take effect
<marcoceppi> Nevermind, I've gotten past that problem, Now whenever I try to Branch on windows with bzrlib I get invalid url supplied to transport when using lp: addresses
<LarstiQ> marcoceppi: is that with bzr straight, or using some of your own code?
<marcoceppi> LarstiQ It's using bzrlib in a light python wrapper I wrote, that does a Branch.open('lp:charms/ubuntu') which produces this error:
<LarstiQ> marcoceppi: you'll need to load plugins
<LarstiQ> let me check
<marcoceppi> LarstiQ I do already, this code currently works on Ubuntu
<LarstiQ> marcoceppi: ah hmm
<marcoceppi> http://paste.ubuntu.com/5637024/
<LarstiQ> marcoceppi: pastebin the error?
<LarstiQ> cheers :)
<LarstiQ> marcoceppi: ah, that looks like an ssh problem
<marcoceppi> Nothing in the .bzr.log other than the "Launchpad login" thing
<marcoceppi> Yes, which Windows handles so well :) So, any way to work around that on Windows?
<LarstiQ> marcoceppi: it is possible to set up ssh on windows, I believe putty works
<LarstiQ> marcoceppi: or if you don't mind, you can use http instead of bzr+ssh
<marcoceppi> LarstiQ I wouldn't mind too terribly, to be honest, how would I force load_plugins to translate lp: urls to use HTTP instead?
<marcoceppi> And does the bzr+http scheme allow for pushing?
<LarstiQ> marcoceppi: it should use http already if you don't have launchpad-login set, afaik
<LarstiQ> marcoceppi: no
<LarstiQ> so I'm a bit confused by the error log
<LarstiQ> marcoceppi: http://wiki.bazaar.canonical.com/Bzr_and_SSH has some instructions
<marcoceppi> Well, I guess I need bzr+ssh to work then. I know PuTTY doesn't actually do anything but make software available, so I'm not sure how Bazaar would know to use it for SSH connections
<LarstiQ> marcoceppi: bzr has some support for putty/pageant
<marcoceppi> Ah, interesting
<marcoceppi> I'll give that a shot, thanks LarstiQ
<LarstiQ> marcoceppi: I hope it is enough
 * LarstiQ back to math
<marcoceppi> Well, I'll be back soon enough if it's not ;)
<marcoceppi> LarstiQ still not working, I wonder if it's because of the %5C in the URL, it's having some weird issue with URL decoding
<marcoceppi> OH, I know what I did wrong
<marcoceppi> I'm using os.path.join to build the lp: url
<kolbe> bob2: "bzr branch lp:mysql-server/5.5 ." gives me "bzr: ERROR: Target directory "." already exists"
<kolbe> well i managed to get that pretty easily by using --use-existing-dir but i have to say this workflow is pretty perplexing to me
<kolbe> oh nope, that didn't work either
<kolbe> "bzr: ERROR: Already a branch: "."."
<mgz> kolbe: you want to branch it into a fresh directory
<mgz> possibly without the tree, or possibly colocated, but you can't just branch over the top of an existing branch
<kolbe> mgz: some time yesterday bob2 had told me "make repository; cd to it; branch; success"
<kolbe> but that doesn't really seem to work out so well
<kolbe> i guessed that "make repository" meant "bzr init" but perhaps that wasn't right
<mgz> indeed not
<mgz> you want `bzr init-repo`
<kolbe> huh
<mgz> try reading the introduction section of the user guide
<kolbe> mgz: the main goal of all of this was to try to find a way for "bzr branch" to allow me to resume if my connection dies part way through
<kolbe> i already have a shared repository and i was just doing "bzr branch lp:mysql-server/5.5 5.5" from the directory that holds the shared repository
<mgz> http://doc.bazaar.canonical.com/beta/en/user-guide/
<kolbe> but if my connection dies and bzr branch stalls, i couldn't figure out any way to get it to resume
<mgz> right, the general work around for that is do a manually pull in a sequence of revision ranges
<kolbe> that guide doesn't seem to address resuming a branch operation, i looked there at some point
<kolbe> oh my
<mgz> so, `bzr branch -r..100 FROM` then cd into the branch and `bzr pull -r100..200` and so on, can shell script that reasonably easily
<mgz> you probably want to make sure you're using bzr+ssh, so give bzr your launchpad login and upload your ssh key to your user account if you've not done it already
<kolbe> does bzr+ssh have some particular benefit when just branching some public project?
<mgz> faster for subsequent operations, so, useful in this case
<kolbe> ok, thanks
 * kolbe wonders what bzr+ssh is doing that makes it faster than whatever happens when not using it
<mgz> it does operations server-side
<mgz> so, pulling in changes when you already have some is handled by your client saying what it has then the server packing up the missing bits and sending them
<mgz> rather than the client looking at the data files directly and trying to pull out the bits it needs
<kolbe> an initial branch seems to take an extremely long time, no matter how fast my connection is
<kolbe> is bzr manually grabbing each revision since the dawn of time?
<mgz> no, but it is the whole project history
<mgz> it's packed up in a sane manner, but for big old projects it's still a lot of data
<kolbe> yeah
<SamB> kolbe: bzr-svn is the one that has to grab revisions one-by-one
<kolbe> blah, this is horrible
#bzr 2013-03-23
<PatrickDickey> Hi everyone. I've got a quick question. I've created a script that sets up my bzr branch, and am running into an issue with the whoami command. Since the command is bzr whoami "My Name <myemail>", and I'm passing it a string value in my script, would I need quotes at all? In other words, would I use bzr whoami $name ?
<maxb> PatrickDickey: You would need quotes to protect the spaces and < > characters from being interpreted as splitting the string into multiple arguments and redirection operators by the shell
<PatrickDickey> Thank you maxb, would I want to do something like bzr whoami '"' $name '"' then?
<maxb> erm, no
<maxb> bzr whoami "$name"
<maxb> (I'm assuming we're talking about Bourne shell here)
 * maxb thanks the absent mbp to super-fast hydrazine code review
<PatrickDickey> maxb, yes we are. And thank you. I'll put that in. :)
#bzr 2014-03-19
<mgrandi> hello, i'm starting to use bzr's colocated branches for stuff at work, but is there a way to make it so it does not delete unversioned files when switching branches?
<jelmer> mgrandi: do you mean bzr-colo or the builtin support for colocated branches?
<mgrandi> i think its the built in support
<mgrandi> i dont remember installing any plugins
<mgrandi> and its using the UI in bzr explorer
<jelmer> mgrandi: how do you interact with it on the command-line?
<mgrandi> i haven't interacted with the branches at all in the command line, although the branches are stored in .bzr/branches/trunk
<mgrandi> 'colo' plugin is installed however..
<jelmer> mgrandi: yeah, that's the colo plugin
<mgrandi> does the latest version of bzr have the full colocated support without the colo plugin?
<jelmer> mgrandi: no, the colocated support in core is incomplete
<LeoNerd> jelmer: Ah, hi :)
<jelmer> I think the bzr-colo plugin is more mature at this point
<jelmer> hey LeoNerd :)
<mgrandi> ah =(
<mgrandi> so any idea on how it to preserve unversioned files? i thought that was the point of the colocated idea anyway
<LeoNerd> jelmer: LTNS.. While you're here - have you seen the bug in the bzr-git plugin? The one that reports something about not being able to find a graph-walker? (I forget quite the details, I can find a link if you like)
<jelmer> LeoNerd: yeah, that's related to Dulwich API changes for which bzr-git hasn't been updated
<jelmer> downgrading dulwich should work around it
<LeoNerd> jelmer: Ah OK.. Is that something someone is looking into? It's sortof biting me at the moment.. Fortunately it seems the code dies late enough that the actual pushing to github has happened, so it may just be cosmetic
<LeoNerd> Ah Isee
 * mgrandi curses jelmer slightly for removing tags from python-fastimport repo >.>
<jelmer> mgrandi: I don't recall removing them
<mgrandi> i'm trying to run the bzr-windows-installers script so i can finally get a bzr 2.6 version out there, and it complained that there is no 'fastimport-0.9.0' tag in the python-fastimport repo on bzr, and there isn't =P
<mgrandi> (when i checked it out to check at least)
<jelmer> mgrandi: I'm pretty sure I haven't removed them, haven't touched the bzr repo
<mgrandi> the last (and only) tag in python-fastimport is 'fastimport-0.9.3' on your commit on march 1st
<mgrandi> wonder how they got removed then...
<mgrandi> jelmer: do you know what 'make chm-sphinx' is? i cant find that and it doesn't seem to be a python package or anything
<jelmer> mgrandi: the main python-fastimport repository is on github
<jelmer> mgrandi: I'm no longer using the bzr branch
<jelmer> mgrandi: chm is a windows help file thingy
<mgrandi> ah, well the script downloads it from launchpad
<mgrandi> yeah, but the build windows installers script is calling 'make chm-sphinx' and i dunno what that is haha
<jelmer> mgrandi: yeah, chm would be the windows help file that you can open and view with the regular windows help viewer
<jelmer> mgrandi: so it makes sense it's building that
<jelmer> mgrandi: Sounds like the script needs to be updated :)
<mgrandi> yeah im working on it =P
#bzr 2014-03-20
<mgrandi> man, this installer script for windows is...buggy
<mgrandi> is there a way to see what extensions bzr is complaining about that were not built?
<fullermd_> Does it say in .bzr.log (or whatever it's called on benighted platforms)?
<mgrandi> well there is a log for compiling the extensions, there are a bunch of warnings but i dont see it saying that compilation failed anywhere
<fullermd_> I'm half sure (a clever dodge, since it means I can't be wrong) the runtime log says what it can't load, which would at least tell you what failed compiling.  Why, well, that's a whole different W word...
<mgrandi> well its not being run yet, so i guess ill wait until then
<fullermd> Ooh, I thought you were already seeing the runtime.  Hm.
<fullermd> Hm.  Well, on *nix it just outputs all the compiling stuff like any other program.
<fullermd> Only compiler warning I see (clang 3.3) is about an unhandled enum value.  Plus a little grumble from cython about unreachable code.
<mgrandi> its running like a bunch of different scripts, maybe its like, the bzr itself trying to compile the extensions? haha
<mgrandi> i wish i had clang on windows, they say they are trying to bring it to windows
<mgrandi> should shaken up the C compiler monopoly that microsoft has
<mgrandi> shake*
<mgrandi> maybe even mean every open source project that is multi platform can support something other then c89 =P
<fullermd> I'm given to understand that they actually have a middling decent compiler under there, it's just all the surrounding build stuff is so horrifically bad you never get to see it.
<fullermd> I think recent VS actually does handle most of the interesting bits of c99.
<fullermd> Almost in time for c11   :p
<mgrandi> but its not in microsoft's business plan to support C anymore
<mgrandi> they want c++, but that is of course bad for python ruby anything that is written in C
<fullermd> There's always the chance that C++ will acidentally slip and fall some day.  Into a vat of acid.  On fire.  With a shiv in its back.  Accidentally.
<fullermd> I mean, that's what I hear.  I never think such things myself.
<mgrandi> looking at the horrible c++ code at work, i can only hoep
<mgrandi> hope
<mgrandi> it would be better if they used boost or qt or anything that tries to ease the pain, but they stick with the stdlib, which...is awful
<fullermd> Well, at least it's consisten...  oh, wait.
<mgrandi> my favorite is std::thread::hardware_concurrency()
<mgrandi> returns 0 if it can't tell how many cpu's your computer has
<mgrandi> which i guess sorta makes sense, but also why not just return 1, since you are...going to have at least 1 cpu in your computer!
<fullermd> That sounds like a challenge   :)
<fullermd> Available responses include "No, it has an Atom".
<mgrandi> maybe its a potato
<mgrandi> hardest part about this script is waiting for it to checkout the bzr source from another local directory, haha
<mgrandi> GREAT
<mgrandi> apparently the wonderful message "msginit:lib/gettext/project-id subprocess failed: bad file descriptor is a completely fine error message
<mgrandi> and should be ignored
<fullermd> File descriptors go bad all the time.  That's why they come in 2**N-packs.
<mgrandi> haha
#bzr 2014-03-22
<mgrandi> ohmmmygggodddd
<mgrandi> i finally built the windows installer for bzr2.6
<mgrandi> took 33 tries
<mgrandi> but i did it
<lifeless> mgrandi: congrats!
<mgrandi> you dont even wnat to know
<mgrandi> the horrors i have seen
<mgrandi> getting this to work
<fullermd> C compilers glitter in the dark near the Tannhauser Gate?
<mgrandi> unless its a 64bit build
<mgrandi> in which visual studio 2008 express decides it doesn't like it
<mgrandi> Ill post on the mailing list about my adventures and some problems i had,
<mgrandi> talk to you guize later
#bzr 2015-03-17
 * jelmer waves
#bzr 2016-03-26
<GnuYawk> What are the advantages of bzr over git?
#bzr 2017-03-26
<cfoch-always> hi
<cfoch-always> how do I know what is the current branch?
<cfoch-always> (I am a git user)
<cfoch-always> the current branch is the current directory?
<cfoch-always> hi
<cfoch-always> ?
<mgz> cfoch-always: `bzr info` tells you, as does pwd generally as you note (branch layout dependent)
#bzr 2018-03-23
<Durgeoble> hi
<Durgeoble> i have a question, can bazaar lower disk ussage deleting parts of history? for example excel files that only spell changes done for them so olders versions no longer need for nothing
<jelmer> hi Durgeoble
<jelmer> Durgeoble: in theory it could remove historical data (but leave references in place)
<jelmer> but there are no commands that can currently do that AFAIK
<Durgeoble> is for space economy, maybe i am wrong, but seems to me if i want to edit a little file, need to download all the repository
<jelmer> Durgeoble: if you don't want to download the history, you could use a lightweight checkout or a stacked branch?
<Durgeoble> jelmer:  dont know, just viewing how vcs works, seeing bewteen bazaar and git, just for feactures such mail and local offline work
<mgz> one of the dvcs shifts was that it's more important to make history generally available than have each operation on a central repo be cheap
<mgz> this does tend to break down for binary files which aren't sensibly diffable (like excel files without a filter) because there's basically no useful content in the history, each change is a essentially a whole new zip file
<jelmer> Durgeoble: if you're interested in keeping the full history the server but having just the latest few revisions locally, then a stacked branch should be a nice fit
<jelmer> any operations that needs to access older history will still require a network connection
<jelmer> but e.g. changes that involve recent history won't
<Durgeoble> thanks jelmer
#bzr 2018-03-24
<jelmer> mgz: https://code.launchpad.net/~jelmer/brz/check-ci/+merge/342027
<mgz> jelmer: https://code.launchpad.net/~gz/brz/paramiko_code_hack/+merge/342028
<mgz> https://wiki.debian.org/Qt4Removal
<mgz> https://bugs.launchpad.net/bugs/1757320
<ubot5> Ubuntu bug 1757320 in qt4-x11 (Ubuntu) "Remove Qt 4 from the archive" [Medium,New]
