#bzr 2007-09-03
<BrianB04> I'm already liking bazaar...it's so simple.
<lifeless> cool
<lifeless> I like to hear such things
<igc> morning all
<lifeless> hi
<lifeless> jelmer: ping
<lifeless> jelmer: your code.launchpad.net/~jelmer/bzr-svn/trunk is borked
<jelmer> lifeless: thanks, I'll have a look
<abentley> lifeless: the new annotation stuff is in.
<lifeless> jelmer: I think you renamed something and didn't tell launchpad
<lifeless> jelmer: also you should tell launchpad what branch is used for each release series
<poolie> helol
<lifeless> hi
<igc> hi poolie
<igc> poolie: w.r.t. your partial review, did you want the -D options in a separate 'debug-options' topic, in a separate "table" or just all together in the existing table separated by a newline say?
<igc> abentley: if you're happy with Nam's tweak to the hook doc in his pre-commit patch, let me know and I'll merge the change today
<poolie> igc,just in the same thing separated by a newline
<poolie> would be fen
<poolie> fine
<igc> thanks
<lifeless> igc: abentley is not here
<igc> ok
<poolie> spiv, ping?
<spiv> pong
<poolie> lifeless, should we be using ppas at all for bazaar packaging?
<poolie> spiv, can i call?
<spiv> Sure.
<lifeless> poolie: no advantage at this point
<igc> poolie: just confirming, the indentation of NEWS items was explicitly reduced by 1 char in 2773. Any reason for that?
<poolie> igc, because i noticed that the rest rendering had them at different bulletpoint levels
<poolie> in different sections of the file
<poolie> i think i got it right
<igc> np - just impacting merging of course.
<poolie> yes http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#in-development
<poolie> it's better but there are still some that are a bit worng
<igc> ok - I'll clean it up now as a trivial change. I need to fix some other ReST formatting anyhow in developers/update.txt so I'll do both while I'm at it
<poolie> jml, hi?
<jml> poolie: hi
<lifeless> igc: just sent a commit patch up that you might like to review
<igc> lifeless: got the email re memory but no patch thru yet
<igc> lifeless: I have 4G on my main benchmarking machine of which 1G is given to a VM btw
<igc> lifeless: ok, patch thru now - will review today
<lifeless> are you able to benchmark outside the vm ?
<igc> I'm doing that - in the other 3G
<lifeless> cool
<igc> the VM is Windows
<lifeless> we still spend 13% in libz
<igc> but I'm not surprised that compression is an overall win - thanks to reduced IO
<lifeless> oh yes
<lifeless> raw pack is 990MB when annotations are used
* jdong has just sinned....
* jdong rewrote his own tailor, tailored for svn
<jdong> tailor config files have just been more painful than swallowing needles for me...
<lifeless> why not use bzr-svn ?
<lifeless> 'pull' is about as simple as it gets :)
<jdong> lifeless: because I only need a -20-revision horizon....
<jdong> also, for my KTorrent needs.... bzr-svn would have to mirror the *entire* KDE xD
<jdong> but for smaller trees, bzr-svn is bliss
<lifeless> jdong: why would it mirror everything ?
<jdong> lifeless: because KTorrent is a subdirectory of the entire KDE subversion repository....
<jdong> lifeless: at least from what I understand, I would have to branch the entire KDE svn, not just a subdirectory
<lifeless> if its structured well bzr-svn can treat them as nested trees
<ubotu> New bug: #136890 in bzr "merge --uncommitted ignores specific file" [Undecided,New]  https://launchpad.net/bugs/136890
<jdong> lifeless: hmm I'll have to look more into that then
* igc lunch
<lifeless> igc: another one up
<igc> lifeless: got it - will review now
<igc> lifeless: what's our policy w.r.t. changing return values on public methods? Should we use another name like add_lines_get_details() instead of just changing what add_lines returns?
<lifeless> igc: we aim for compatability where the tradeoffs are worth it
<lifeless> this is very much an internal aspect of implementation, I don't think compatability is worth it
<igc> I'm ok with that.
<igc> still, might be worth putting it in the API breaks part of NEWS for completeness, yes?
<lifeless> I did
<lifeless> :)
<igc> /wishes he looked at the diff for NEWS in meld and not just bzr cdiff :-)
<poolie> spiv, hi?
<poolie> igc: "Can we get this change through as an incremental improvement and have
<poolie> this discussion separately?" yes, in principle, i'll read the code
<igc> cool
<lifeless> spiv: pack patch you may be interested in up
<poolie> spiv, how's the format doc?
<spiv> poolie: Will have it mailed in a few minutes.
<igc> lifeless: can you quickly explain the changes to test_weave.py? StoreText and StoreTwo are redundant tests I gather so deleting them is fine, yes?
<lifeless> poolie: I'm done for the day; started at 6am. 3 patches up, user time is now 3m5seconds
<lifeless> igc: thats right. The other change was to use the new return value api
<igc> ok - all approved. I'll mark it in BB as such.
<lifeless> thanks
<thumper> poolie: ping
<igc> lifeless: if you're still there, that change might be breaking sefltest test_bundle. I'll dig a bit deeper
<lifeless> igc: it does. I'll fix and submit tomorrow morning
<lifeless> ciao
<igc> bye
<bialix> lifeless: hi
<igc> bialix: lifeless has wrapped up for the day after an early start
<poolie> spiv, thanks for your thorough review of C patience diff
<bialix> poolie: hi
<poolie> hi bialix
<igc> thanks for the review poolie
<davidmccabe> Sorry, this seems like a dumb question, but I couldn't find with google:
<davidmccabe> I have two branches here; how do I see the diffs between them?
<beuno> davidmccabe, bzr missing would be one way
<davidmccabe> never mind, that was too easy :)
<davidmccabe> it *looks like* I can just do, bzr diff wc-1 wc-2
<beuno> yeap, that would output a diff
<beuno> missing tells you the difference on the commit level
<davidmccabe> ah, I was looking for a diff.
<davidmccabe> to recollect all my changes at the end of a feature branch.
<davidmccabe> actually, I am comparing VCSs on speed here.
<davidmccabe> My actual VCS for work is SVN. It took fifteen minutes.
<davidmccabe> git does it in under a second.
<davidmccabe> bzr does just fine at 1.29 seconds.
<beuno> ah, right, bzr isn't focused too much on performance at the moment, although a lot of work is being done on it
<davidmccabe> It performs great!
<davidmccabe> git is written in C with a bit of assembly, and it's only a few times faster for this operation.
<davidmccabe> (must be IO-bound?)
<beuno> well, it'll be fun to watch when they do focus on performance  :D
<poolie> davidmccabe, beuno, we are very focussed on performance in our current work
<poolie> we were not so much in the past
<poolie> but look at all the performance patches on the list in the last week
<beuno> poolie, right, I've seen all the working going on, I just still have in my head the so much repeated phrase "we are not focusing on performance"  :D
* beuno removes the "not" part from his head
<beuno> poolie, would that mainly be the "pack" feature?
<poolie> pack, commit performance, hpss, inventory changes
<poolie> iter merge
<beuno> that just got in, so it's not in 0.90, right?   I have a few <1gb branches at the office I would like a performance boost on  :D
<poolie> pack will be in 0.92, not the last release or this one
<poolie> but if you want to try it from robert's branch that would be enormously useful
<vila> hi all
<poolie> hi vila
<beuno> poolie, sure, I could run some tests if that would help, they mainly contain a lot of binaries (PSDs, PNGs and all that)
<vila> poolie: sorry for the delay in coming back, huge backlog :-/
<poolie> vila, np
<vila> poolie: not sure I get all the details right, but it looks like I will be most helpful to bzr by: 1) looking at the FTP password bug, 2) multiple connections for update, 3) auth-ring spec, 4) recursive hash on directories
<vila> in that order of priority
<vila> any comment ?
<poolie> that sounds great
<poolie> i'm working on 45
<poolie> 4
<vila> poolie: I re-read your directory-fingerprints.txt yesterday, nice work, I'd try to comment on it asap
<poolie> is Lukas here?
<vila> poolie: do you except your work to land in 0.91 or later ?
<poolie> later, it's based on packs and they will likely be in the next release
<vila> ok
<ubotu> New bug: #136942 in bzr "What's in the trash" [Wishlist,Triaged]  https://launchpad.net/bugs/136942
<poolie> vila, interesting suggestion
<fullermd> I claim royalty rights on the name when somebody writes "bzrchaeology".
<vila> poolie: Just had the need for it :)
<vila> fullermd: I will argue that I use the name archeology for years ! Whether for VCS purposes or just trying to understand code :)
<fullermd> Yes, but you didn't pun it with 'bee zee arr'.
* fullermd files a trademark.
<vila> fullermd: and don't start me about explaining young developers that, no, people are not stupid, even if their code looks so. Once, with the help of archeology, you understand why they wrote it this way *at the time* their code was not stupid, nor them :)
<fullermd> Oh, you're whistling in the dark, there.  I stand by my conviction that pretty much everybody in the world _is_ stupid   :)
<vila> fullermd: this may be true but is unrelated :)
<vila> or is it in a self-referring way ???
<ne1uno> commits/developers=iq
<fullermd> Oh, no.  I'm a genius.  Everybody else is a moron.  The fact that you don't immediately recognize my brilliance simply proves the point   ;)
<vila> fullermd: ooops, just realized my remark was ambiguous :) I meant: are you calling people stupid by looking at their code ?
<fullermd> Oh, no.  I don't have to look at code.  I assume _everybody_ is stupid.
<vila> fullermd: hmmm, you remind me of someone...just can't remember who...
<fullermd> What, somebody else has attained my exhalted level??  Never!  We'll joust for the title!
* igc dinner
<poolie> spiv, can i read about the protocol yet?
<spiv> poolie: Yeah, I sent a merge/rfc about it.
<poolie> oh great, thanks
<poolie> spiv, can you look at http://bundlebuggy.aaronbentley.com/request/%3C46D86283.4080602@utoronto.ca%3E
<poolie> actually, i see a bug, but if you can say if the basic intent is right that'd be good
<spiv> Yeah, that's high on my mental todo list.  Like Robert I'll need to page in a little bit too, but not as much as Robert...
<poolie> ok, don't worry til your stuff is up
<poolie> i can read it
<ubotu> New bug: #136952 in bzr "Bzr doesn't merge the most recent revision" [Undecided,New]  https://launchpad.net/bugs/136952
<poolie> spiv, is http://bundlebuggy.aaronbentley.com/request/%3C20070826091222.GC11127@steerpike.home.puzzling.org%3E
<poolie> the most current fix for that bug?
<poolie> for trunk
<spiv> poolie: yes
<poolie> thanks
<poolie> igc, thanks for all the reviews
<igc> np
<BrianB04> Morning all.
<gabe_> morning BrianB04
<grimboy> Morning, Bri. Doing a checkout or branch of a branch I've just pushed I get the error bzr: ERROR: No such file: 'http://code.discussium.org/discussium/.bzr/repository/knits/8f/models.py.old-20070902211246-zblkha1c6hz8yag7-30.kndx'. The file is available where I pushed from put not where I pushed to. I've tried using both sftp and bzr+ssh but both do the same thing. Any idea what I'm doing wrong?
<grimboy> s/put/but/
<Kamping_Kaiser> is bzr <current releases> still compatible with the 0.8.2 in Ubuntu 6.06?
<gabe_> seems fine for me
<gabe_> i'm on dapper
<Kamping_Kaiser> i was just making sure there hasnt been any storage format breaks
<dato> Kamping_Kaiser: how do you mean, "compatible". whether branches created with current versions can be read by 0.8?
<Kamping_Kaiser> dato, and vica versa
<Kamping_Kaiser> as will be the case
<dato> vice versa, yes, always.
<dato> branches created by the default format up to 0.90 can be read by 0.8 as well.
<dato> however 0.15 and onwards have a newer format that is incompatible with 0.8, but it has to be enabled by hand.
<dato> finally, 0.91 will make that new format the default.
<dato> (but you can still create branches in the old format with 0.91 and upwards; you just need to pass the appropriate flag to bzr init)
<Kamping_Kaiser> would the version of bzr in debian 4.0 or ubuntu 7.04 be compatible? i'm asuming so
<dato> the very same comments apply.
<Kamping_Kaiser> sweet
<Kamping_Kaiser> *goes to find out versions in said distro releases*
<dato> debian 4.0 has 0.11
<BrianB04> I'm back, sorry about that, quick shower. Ya know, I offically love Bazaar...it's so simple once you get an idea of how things work.
<dato> Kamping_Kaiser: in any case, there are backports for both debian (in backports.org) and for ubuntu (in bazaar-vcs.org/releases/debs)
<dato> Kamping_Kaiser: in case you're interested
<Kamping_Kaiser> 0.15 in feisty
<Kamping_Kaiser> dato, i'll bear it in mind, thanks
<BrianB04> Otherwise Kamping_Kaiser: Why not just grab the source from the bazaar site?
<Kamping_Kaiser> i just init'd a project before i came and asked here
<Kamping_Kaiser> BrianB04, what, build it myself?
<BrianB04> Kamping_Kaiser: Yea, not that difficult. And, you can do a quick google search for something like 'build bzr in x distro' and usually will find (Especially for debian/ubuntu) howtos of exactly what you need to apt-get to make it build properly.
<dato> BrianB04: well, why build yourself if both distros provide updated backports??
<Kamping_Kaiser> BrianB04, i prefer not to build (esp. if thers backporst)
<BrianB04> dato: Unfortunetly, they are not always updated, that's the big problem. You know what I always found a little weird, when I was first looking into bazaar, that Ubuntu does not keep the most up to date in repos...and they are 'owned' by Canonical who does Bazaar.
<dato> BrianB04: what "repos"?
<BrianB04> In one of the main not like Backports, ya know?
<dato> BrianB04: latest versions have always been in bazaar-vcs.org/releases/debs, ttbomk
<dato> you'd have to ask some ubuntu person why they are in bazaar-vcs.org instead of feisty-backports, eg.
<BrianB04> Ah, I haven't been in Ubuntu in awhile...stupid computer now doesn't like Ubuntu, in the least.
<Kamping_Kaiser> the -backports repos are pulled from a later release, by someone in the backports team with motivation
<Kamping_Kaiser> i asume the bzr-cvs ones are done as a mater of course
<BrianB04> But, I'm happy that finally launchpad mirrored my bazaar repo after the race condition yesterday. Hey, I have a trivia question regarding bazaar/drcs if someone knows, when did the whole DRCS thing start? Back when Bitkeeper came in to being to 'help' out the kernel team, or did DRCS start before then?
<grimboy_uk> When doing a checkout or branch of a branch I've just pushed I get the error bzr: ERROR: No such file: '*blah*/.bzr/repository/knits/8f/models.py.old-20070902211246-zblkha1c6hz8yag7-30.kndx'. The file is available where I pushed from but not where I pushed to. I've tried using both sftp and bzr+ssh but both do the same thing. Any ideas what I'm doing wrong?
<markvandenborre> I'm setting up a central bzr repository for two people
<markvandenborre> how do I avoid having to fiddle with that repo as root?
<markvandenborre> we are two people, each with our own ssh account on this machine
<gabe_> markvandenborre: ensure both people are the members of a same group
<markvandenborre> gabe_, yes, of course,...
<gabe_> and that group has write permissions on the repository
<markvandenborre> but then you still need to set the default group for newly created files
<markvandenborre> with umask-ish stuff
<markvandenborre> I don't see if that is possible on a directory basis
<markvandenborre> or rather: how that is possible
<dato> ensure that the directory is mode g+s and g+w
<dato> (numeric mode 2775)
<dato> bzr *should* take care of the rest, or so I hear
<gabe_> works for me with the users being in the same group
<AfC> 02755 and umask 0002 worked for us
<lifeless> grimboy_uk: are you using http to pull from ?
<BrianB04> Hey, are bzr branches cheap?
<AfC> Short answer: yes
<matkor> BrianB04: Even cheaper if you have them in one repo
<AfC> Of course, more to the point, they're real branches :)
<BrianB04> God, I hate going outside of stories when developing in rails, but...blech I have to for this.
<markvandenborre> dato, bzr commit -m "Test met gebruiker Onno"
<markvandenborre> Password:
<markvandenborre> bzr: ERROR: Permission denied: u'/srv/bzr/.bzr/repository/lock/pending.62hc7mnjpa6jcyrq91v1.tmp': [Errno 13]  Permission denied
<markvandenborre> I'm still locked to this one user "mark"
<markvandenborre> I know I could chgrp -R admin ./ in /srv/bzr
<markvandenborre> (both users are in the admin group-
<markvandenborre> )
<markvandenborre> but that would not be the cleanest way to do it, would it
<markvandenborre> what is the cleanest way when it comes to permissions
<dato> markvandenborre: find /srv/bzr -type d -print0 | xargs -r0 chmod 2755
<dato> markvandenborre: find /srv/bzr -not -type d -print0 | xargs -r0 chmod 664
<dato> do that and try
<markvandenborre> you make me change all directory rights g+ws, and all file rights ug=rw,o=r
<dato> aha
<markvandenborre> would that be the cleanest way?
<markvandenborre> I wonder if this is such an uncommon setup
<markvandenborre> that I have to fiddle with it like this...
<markvandenborre> (btw, thx for your help, dato!)
<dato> well, maybe the permissions were bad, to this should be a one time thing
<markvandenborre> dato, the problem is that mark.mark is still the user/group rights on many files, so onno can't touch them
<markvandenborre> (after setting up the repo with g+ws as you first suggested)
<dato> ah, then if you don't have root there, you will need mark to fix
<markvandenborre> I have root here
<markvandenborre> but I was wondering how to fix this in a sustainable way
<markvandenborre> so that mark and onno can work together without touching anything at the shell level once it is set up well
<markvandenborre> presuming they stay within an existing repository, that is
<dato> as I understand it, the starting point is (1) all files and directories g+w; (2) all directories g+s; (3) all files and directories group "admin"
<dato> AfC mentioned something about the umask, but I've hear jam say bzr preserves the g+w bit, so it should not be needed
<markvandenborre> ok
<markvandenborre> how documented is this?
<dato> I don't know.
<AfC> (group whatever-you-want-it-to-be)
<grimboy_uk> lifeless, Yes.
<grimboy_uk> But I've looked at it on the server through the file system and the file that's on my computer that it's complaining about not having (*blah*/.bzr/repository/knits/8f/models.py.old-20070902211246-zblkha1c6hz8yag7-30.kndx) isn't there.
<markvandenborre> I have this bzr with central workflow running now, as described at http://doc.bazaar-vcs.org/latest/en/user-guide/centralized_workflow.html
<markvandenborre> thx, step 1 is complete
<BleSS> niemeyer: hi! I contacted with you ago 2 weeks about issues on python-mcrypt and python-mhash, and I sent you an email but withou answer
<BleSS> and you said me that you were to looking/working about them on past week, I would to know if you aren't maintain those projects netiher upload to PyPi
<BleSS> because I started to built a python wrapper over your programs for nothing
<niemeyer> BleSS: First, this isn't the right channel to talk about it..
<niemeyer> BleSS: Second, I said I wouldn't be able to look at these projects before the sprint was over.. it didn't mean I would look at them immediately after the sprint was over
<BleSS> niemeyer: yes, it's true, sorry, but as I was not answered by email after of 3 emails ...
<niemeyer> BleSS: I have dozens of things to look at, literally, and these projects aren't at the top of my list.
<BleSS> niemeyer: excuse me but you said me that you were to looking them on the last week
<niemeyer> BleSS: I appreciate your effort on them, and don't want you to feel frustrated because I'm not giving you attention
<BleSS> niemeyer: then, for the next time you must say the truth and answer the emails
<markvandenborre> a strange beginner question:
<markvandenborre> I want to use bzr for web development
<radix> generally one uses it to manage revisions ;-)
<niemeyer> ...
<niemeyer> Aug 21 11:02:02 <niemeyer>      So I apologize for the lack of response
<niemeyer> Aug 21 11:02:08 <BleSS> no problem
<niemeyer> Aug 21 11:02:19 <niemeyer>      Ok.. I'll try to look at these issues next week
<niemeyer> Aug 21 11:02:23 <BleSS> if you're busy i don't disturb
<niemeyer> Harsh.. harsh..
<radix> !?
<markvandenborre> radix, for managing revisions of web development files of course
<niemeyer> radix: Discussion above..
<radix> wow
<radix> markvandenborre: oh, ok :-)
<markvandenborre> but how do I get the clean source tree
<markvandenborre> without any .bzr stuff
<markvandenborre> so that I can use a checkout directly in my web tree?
<markvandenborre> I'm probably not expressing myself too correctly here
<mwhudson> well, 'bzr export' will do that
<mwhudson> but i'm not sure that's what you actually want
<markvandenborre> ah, thx
<markvandenborre> mwhudson, now I can at least look things up
<abentley> export is a one-time operation, so you won't be able to use "pull" or "update" in that directory.
<abentley> But "pull" and "update" require a .bzr directory, even if it doesn't have a lot in it.
<abentley> I'm not sure why you want to avoid ".bzr".
<gabe_> ls
<BrianB04> I don't think that a webserver could even see a .bzr directory.
<markvandenborre> abentley, I wonder if this has any security implications
<abentley> BrianB04: They typically don't show it on directory listings, but yes, you can access a .bzr over http.  If not, most public branches wouldn't work.
<BrianB04> abentley: Yes, that's true but how many people are just going to try that?
<abentley> markvandenborre: Well, you can always make .bzr/* a forbidden URL in your server config.  But you certainly don't need to store all the version history there, anyhow.  You can make a lightweight checkout instead.
<markvandenborre> abentley, ahh... another good thing you bring up
<markvandenborre> a lightweight checkout
<markvandenborre> what is the fastest operation: lightweight checkout, or export?
<markvandenborre> think of a web site in development that needs to be updated quite frequently from a bzr repository
<markvandenborre> maybe there is a better/faster way?
<markvandenborre> ... any good doc pointers pertaining to this also welcome
<markvandenborre> !
<ubotu> New bug: #137044 in bzr "Saved FTP passwords not used, password not prompted" [Undecided,New]  https://launchpad.net/bugs/137044
<ubotu> New bug: #137045 in bzr "bzr push hangs some minutes if server data quote is exceeded" [Undecided,New]  https://launchpad.net/bugs/137045
<markvandenborre> a bzr update from a remote sftp server (pubkey auth) where nothing has changed consistently takes about nine seconds
<markvandenborre> is that normal?
<markvandenborre> this is on bzr 0.15-0ubuntu2
<AfC> markvandenborre: Step 1: upgrade to the current release, 0.90
<AfC> markvandenborre: you are using code that is more than 4 releases old.
<markvandenborre> AfC, or from another perspective, I'm using the latest ubuntu on a production server...
<AfC> markvandenborre: well. then that's an Ubuntu bug, then.
<markvandenborre> maybe there is something more recent in a backports repo somewhere
<radix> markvandenborre: yes, the latest bzr packages for ubuntu are made available
<markvandenborre> oh, nice
<radix> you'll find info in the download section of bazaar-vcs.org
<markvandenborre> thx!
<markvandenborre> radix, brilliant!
<sits> I seem to be getting KeyError errors trying to do
<sits> bzr branch 'https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac'
<sits> on Gutsy. Any ideas?
<markvandenborre> AfC, regarding performance
<markvandenborre> I have just upgraded to the latest .90 release (thx again for the suggestion!)
<markvandenborre> averages for a bzr update from a central repo with one very short text file and three revisions is just below 6 seconds on average now
<markvandenborre> is there anything else I should check regarding performance?
<markvandenborre> oh, I still need to bzr upgrade, apparently
<markvandenborre> any other suggestions
<markvandenborre> ?
<abentley> markvandenborre: I expect that updating a checkout is faster than updating an export, because updating a checkout will only affect modified files.  But updating an export requires outputting all files each time.
<markvandenborre> abentley, this is a checkout already, but thanks for the suggestion
<abentley> You asked for a comparison earlier.  I was responding to that.
<markvandenborre> ah, thx!
<abentley> sits: Please pastebin your traceback.
<abentley> ubtotu: paste
<abentley> ubotu: paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<abentley> markvandenborre: The repository is remote?
<sits> http://paste.ubuntu-nl.org/36208/
<markvandenborre> abentley, yes, the repo is remote
<markvandenborre> oh... too late
<yml> hello
<yml> I am still trying to get my complete workflow of development flowing with launchpad.
<yml> I beleive I reach one of the final step of the loop. I am trying to push my branch from a remote host to launchpad.net.I am getting this error message:yml@ssh1:~/workspace$ bzr push "sftp://yml-nospam@bazaar.launchpad.net/~yml-nospam/survey/main-yui"Could not create directory '/home/yml/.ssh'.Permission denied (publickey).bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net;
<yml> Does this make sense to someone?
<luks> "sftp yml-nospam@bazaar.launchpad.net" works for you?
<luks> I think it's something wrong without your local ssh key setup
<markvandenborre> yml, I'm not a bzr expert, but you should probably get your pubkey auth fixed first
<markvandenborre> make sure .to add the contents of your local ~/.ssh/id_dsa.pub to the remote ssh/authorized_keys2
<yml> lucks you want me to type this: sftp yml-nospam@bazaar.launchpad.net
<markvandenborre> make sure to have pubkey auth switched on in the remote sshd configuration
<luks> yml: yes
<luks> I think you don't have your private ssh key installed correctly
<yml> luks : all the problems come from that my key are not in /home/yml/.ssh but in /home/yml/www/.ssh
<yml> luks : same kind of error:
<yml> yml@ssh1:~/workspace$ sftp yml-nospam@bazaar.launchpad.netConnecting to bazaar.launchpad.net...Could not create directory '/home/yml/.ssh'.Permission denied (publickey).Couldn't read packet: Connection reset by peer
<markvandenborre> what would be the best way to backup a central bazaar repository?
<yml> when I do a ssh-add -l I can see my key
<james_w> markvandenborre: with multiple branches?
<luks> yml: it probably needs to write to known_hosts in ~/.ssh
<yml> luks: :)
<james_w> yml: ssh -v can be helpful sometimes.
<luks> hm?
<markvandenborre> james_w, I'm really a beginner when it comes to bzr, but...
<markvandenborre> we're two users working on one central repository from different computers
<yml> This took me a day to set up ssh to write known_hosts in the correct directory
<markvandenborre> with several branches in this same repository
<markvandenborre> one for each web project
<yml> http://forum.alwaysdata.com/viewtopic.php?id=93
<markvandenborre> at least, that's the layout that was suggested to me as the most logical one
<james_w> markvandenborre: ok, so for backup, either use bzr and pull each branch in turn, to a repo on another machine. Or just rsync the whole repo over or similar.
<yml> luks: here it is the output of sftp -v => http://dpaste.com/18500/
<markvandenborre> james_w, which one would be most bandwidth efficient?
<luks> well, it obviously doesn't try to use ~/www/.ssh
<markvandenborre> not that it's such a big problem right now, but I want things to be scalable
<luks> but I really don't know how to fix that
<james_w> markvandenborre: rsync, unless you have masses of unreferenced revisions in the repository (you often uncommit revsions that are stored there or similar).
<yml> luks  : thank you, I am like you but me I searching the solution for the last 2 days
<yml> :[
<markvandenborre> james_w, thx!
<luks> why not just use ~/.ssh?
<james_w> if the latter then you are probably better off just cleaning up and using rsync anyway.
<yml> luks : because I do not have access to it
<yml> for some reason my internet provider give me access in read only to that folder
<Peng> ~/www? As in people can download the contents of .ssh on the web? That isn't exactly good.
<yml> and read write in /www
<markvandenborre> Peng, if it's like that, it's even _awfully_ bad, insecure, irresponsible
<markvandenborre> yml, but surely it's not like that, is it?
<BrianB04> How do you merge a branch in with full log file included?
<Peng> BrianB04: bzr merge $branch?
<yml> Peng: It not that bad because I can configure folders in ~/www that are accessible
<BrianB04> Peng: Didn't pull in the full log
<luks> yml: you can probably change the location using IdentityFile in your ssh configuration
<Peng> BrianB04: Yes it did.
<BrianB04> Peng: Didn't show in bzr log...or...do I have to commit...nevermind.
<Peng> Oh.
<yml> luks : what is this IdentityFile?
<luks> man ssh_config :)
<luks> but I have no idea where to put the file, because I have it in ~/.ssh/config
<yml> thank you nicely said  lol
<luks> you will probably need to use command line options
<luks> and convince bzr to use the ssh with your options
<yml> luks: it look like an endless loop => chiken, egg
<luks> ssh -i /home/yml/.ssh/id_dsa
<luks> it seems to use BZR_SSH environment variable
<yml> luks you mean ssh -i /home/yml/www/.ssh/id_dsa
<luks> right
<luks> so `BZR_SSH="ssh -i /home/yml/www/.ssh/id_dsa" bzr push ...` might work
<yml> BZR_SSH is an environment variable that I have to set before your bzr
<luks> actually, not BZR_SSH seems to do something different
<yml> luks  : yes I believe it is use to specify ssh engine
<luks> yep, but I'm obviously bored, so here you have a simple plugin - http://rafb.net/p/5qLlgx54.html :)
<yml> beuno save me after 13 hours of unsuccesfull search
<luks> put this to ~/.bazaar/plugins/ymlssh.py
<luks> and then `BZR_SSH=yml-openssh bzr push ...`
<luks> oh, wait, do you have access to ~/.bazaar?
<luks> if not, you need to point BZR_PLUGIN_PATH to the plugin part
<luks> *path
<yml> luks   : what is that?
<luks> what is what?
<luks> the plugin?
<yml> I start to understand
<luks> it will call ssh with the arguments needed to load private key from where you have it
<yml> You have created a plug in
<yml> luks: I have copied your plugin in a file called ymlssh.py. This file is now in /home/yml/www/.bazaar/plugins.
<luks> do you see it in `bzr plugins`?
<yml> I have set BZR_SSH=yml-openssh
<yml> luks: yes I can see it
<yml> yml@ssh1:~/workspace$ bzr plugins/usr/lib/python2.4/site-packages/bzrlib/plugins/launchpad        Launchpad.net integration plugin for Bazaar/home/yml/www/.bazaar/plugins/ymlssh.pyc/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools        Various useful plugins for working with bzr.
<yml> luks: it does not work
<luks> what's the error?
<yml> I have exactly the same result yml@ssh1:~/workspace$ bzr push "sftp://yml-nospam@bazaar.launchpad.net/~yml-nospam/survey/main-yui"Could not create directory '/home/yml/.ssh'.Permission denied (publickey).bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net;
<luks> and do you really have the private key in ~/www/.ssh/id_dsa?
<yml> I have a key called id_rsa
<luks> then you need to change it in the plugin
<luks> and then, I hope, it should work
<yml> stupid me I have just change your plugin
<yml> and
<yml> it does not work  :(
<yml> same error message:
<yml> yml@ssh1:~/workspace$ bzr push "sftp://yml-nospam@bazaar.launchpad.net/~yml-nospam/survey/main-yui"Could not create directory '/home/yml/.ssh'.Permission denied (publickey).bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net;
<luks> what about `sftp -oIdentityFile=~/www/.ssh/id_rsa yml-nospam@bazaar.launchpad.net` ?
<yml> same kind of pb:
<yml> yml@ssh1:~/workspace$ sftp -oIdentityFile=~/www/.ssh/id_rsa yml-nospam@bazaar.launchpad.netConnecting to bazaar.launchpad.net...Could not create directory '/home/yml/.ssh'.Permission denied (publickey).Couldn't read packet: Connection reset by peer
<luks> well, it looks like the private key is not the right one
<yml> even with the complete path : yml@ssh1:~/workspace$ sftp -oIdentityFile=/home/yml/www/.ssh/id_rsa yml-nospam@bazaar.launchpad.netConnecting to bazaar.launchpad.net...Could not create directory '/home/yml/.ssh'.Permission denied (publickey).Couldn't read packet: Connection reset by peer
<yml> ssh try to write in /home/yml/.ssh
<luks> that shouldn't be a problem
<yml> in addition:
<yml> yml@ssh1:~/workspace$ echo ~/home/yml/www
<luks> hm?
<yml> yes it is a pb because I do not have write access to /home/yml
<luks> not even to /home/yml/www?
<luks> try this: sftp -oUserKnownHostsFile=~/www/.ssh/known_hosts -oIdentityFile=~/www/.ssh/id_rsa yml-nospam@bazaar.launchpad.net
<yml> yes I have write access to /home/yml/www
<yml> luks in your path I don't need the www
<yml> because ~ = /home/yml/www
<yml> Am I understanding it correctly?
<luks> well, try it with absolute paths
<luks> but I don't think your home is /home/yml/www if ssh tries to write to /home/yml/.ssh
<yml> could you believe this:
<yml> yml@ssh1:~/workspace$ sftp -oUserKnownHostsFile=/home/yml/www/.ssh/known_hosts -oIdentityFile=/home/yml/www/.ssh/id_rsa yml-nospam@bazaar.launchpad.netConnecting to bazaar.launchpad.net...Could not create directory '/home/yml/.ssh'.Permission denied (publickey).Couldn't read packet: Connection reset by peer
<yml> ssh you are DUMB STUPID!!!!!
<yml> lol
<luks> try with -v and pastebin the log
<yml> ok I will do
<yml> http://dpaste.com/18504/
<yml> luks here it is
<luks> well, I don't think the private key in www/.ssh/id_rsa and the one on launchpad match
<yml> I can regenerate a key with ssh-keygen and upload the public key to launchpad
<yml> would that help?
<luks> no idea :/
<luks> probably yes, but you need to find somebody who actually knows how ssh works
<luks> I'm just guessing
<yml> do you thing that I will have more chance on #launchpad
<luks> most likely yes
<yml> Because it does not seem to be a bzr bug
<yml> luks thank you very much for your great help
<yml> and also for my first plugins
<yml> :-)
<luks> no problem :)
<yml> This is something that I would realy like to do write a bzr plugin to do some cherypick before my commit
<yml> bzr seems to be very open
<luks> cherrypick as in `bzr merge -r X..Y`?
<yml> nope cherrypick as in a commit select to take the modification you have done on file A,B and not the one of the file D,F
<yml> like darcs is doing
<luks> ah
<luks> I think there already is something like that
<Peng> "bzr commit a b"
<luks> there is shelve, which does the reverse
<yml> what do you mean the reverse?
<luks> it lets you to take selected changes aside
<yml> in fact I am missing some interactivity
<luks> http://projects.collabora.co.uk/~asabil/bzr/bzr_record/
<yml> like a bzr commit -i
<luks> I think it's based on the shelve plugin
<yml> will ask me file by file if I want to commit the modification done on this file in the current changeset.
<luks> change by change
<asabil> yml, luks: it doesn't commit right now
<luks> oh
<asabil> it will create a patch for you in the patches/ subfolder
<luks> I just noticed it on the plugins page some time ago
<luks> so I assumed it works like darcs record
<yml> luks the link is dead, empty folder
<luks> you better get used to empty folders with bzr :)
<yml> lol
<asabil> yml: bzr get http://projects.collabora.co.uk/~asabil/bzr/bzr_record/
<asabil> luks: I maybe should rename it
<asabil> but it works exactly like bzr record
<asabil> it just doesn't commit
<yml> asabil the folder is empty
<luks> it isn't, there is a .bzr folder inside it
<yml> ???
<luks> http://projects.collabora.co.uk/~asabil/bzr/bzr_record/.bzr/
<luks> simply run: bzr branch http://projects.collabora.co.uk/~asabil/bzr/bzr_record/
<yml> bzr branch http://projects.collabora.co.uk/~asabil/bzr/bzr_record/
<yml> does that work?
<yml> ok
<yml> This is why I have considered most of the plugins as dead
<yml> stupid me again
<vaidhy> I am trying to set up bzr with webdav and I could not push my changes using webdav.. Does webdav support pushing the changes or am I struck with ssh?
<lifeless> grimeboy: that strange
<lifeless> grimeboy: I would run bzr check locally
<lifeless> on the server
<vaidhy> vila you around?
<grimeboy> Oh wait, it's a server problem.
<grimeboy> Now to find the character it doesn't like in "models.py.old-20070902211246-zblkha1c6hz8yag7-30.kn"
<grimeboy> Multiple dots?
<grimeboy> No wait, most have at least two.
<vaidhy> Anyone successfully pushed data using webdav here?
<lifeless> grimeboy: '.py' probably
<Peng> Ohh, right.
<Peng> Apache likes executing anything with ".py" anywhere in the name. :)
<grimeboy> Ah, but other files with .py seem to be alright. Oh well, time to fiddle about with .htaccess
<fullermd> It seems semi-random.  I've seen it with .php's.
<fullermd> I just slammed .kndx/.knit to MIME-type a/o-s in my configs to force it to leave 'em alone.
<grimeboy> Ah har
<Peng> Oh, that's a good idea.
<Peng> I guess that's a benefit of Mercurial always using a smart server: that Apache doesn't get a chance to screw around like that.
<lifeless> packs don't have this problem
<Peng> Oops, bzr doesn't like it when I edit .bzr/branch/location and leave a trailing newline.
<ryanakca> Hmm. On some branches, (ssh+bzr/sftp methinks), when I commit, it get's uploaded to a remote branch, without 'push'... is there a way to tell if my local checkout is that type or not?
<lifeless> info
<lifeless> and its whether its a checkout or not
<ryanakca> ok... so, 'Checkout (format: dirstate)
<ryanakca> ' means it's local? (along with '       checkout root: file:///home/ryan/deb/debian/
<ryanakca> ') ?
<lifeless> local has nothing to do with it ;)
<lifeless> its a checkout
<lifeless> so when you commit it will go to the master branch
<ryanakca> shucks... is there a way to make a 'local' commit, just so I can check, before 'pushing'?
<lifeless> yes you can turn it into a regular branch or you can commit offline
<lifeless> to do the former run unbind
<lifeless> to commit offline do 'commit --offline'
* ryanakca nods... and... shouldn't you merge /before/ commiting?
<lifeless> uhhh
<lifeless> don't see how merge is related
<ryanakca> completely seperate
<lifeless> if you haven't committed, then merging will conflate your changes and the changes you are merging
<lifeless> so you should commit your work then merge then commit the merge.
* ryanakca is trying to commit his changes to the debian/ dir for kdebase ... (hosted on launchpad... the changes being a merge between the bzr branch, and the source package's debian/ dir)
<ryanakca> Ok, thanks
<ryanakca> lifeless: bzr: ERROR: unknown command "--offline"
<lifeless> ryanakca: you forgot the word commit
<ryanakca>  bzr commit --offline -m "LP: #106718, #136560, dropping libgtk and 9902_nspluginviewer patch"         ?
<lifeless> why do you need to commit to test things?
<Lo-lan-do> Hi all
<Lo-lan-do> Still having problems with bzr-svn :-(
<lifeless> ryanakca: you might find --fixes lp:106718 --fixes lp:136560 are useful to add to that
<Lo-lan-do> http://paste.debian.net/36162
<ryanakca> lifeless: ah, thanks :)
<Lo-lan-do> jelmer: ^^^ if you have a few moments
<ryanakca> I don't need to commit to test
<lifeless> ryanakca: you should not need to commit to test your work though so something isn't adding up for me
<ryanakca> ^^
<jelmer> Lo-lan-do: the quick fix is to make _is_http_transport() in transport.py return False
<jelmer> I'm working on a real fix
<lifeless> ryanakca: so why do you need to do offline commits? They are a useful feature but isn't it simpler for you to just commit normally ?
<ryanakca> lifeless: would commiting not cause some merge things in the files?
<ryanakca> oh well, I'll just commit normally and then merge normally. I guess I don't have anything to worry about :)
<lifeless> 'merge things' ? I don't know what you mean
<lifeless> commit does not alter your files
<Lo-lan-do> jelmer: Thanks, I'll do that.
<lifeless> jelmer: did you see my version_info bug for svn ?
<ryanakca> lifeless: herm. *tries to find the old bug* just a sec
<Lo-lan-do> Yay, it works :-)
* Lo-lan-do  jelmer
<jelmer> Lo-lan-do: cool, 0.4.2 should have a proper fix
<jelmer> lifeless: yes, hope to have a look at it somewhere this week
<lifeless> jelmer: should be trivial - just add 'dev', 0
<lifeless> to the end of your version tuple
<jelmer> lifeless: is there a bundle included in the bug report ? (-:
<lifeless> nah
<lifeless> fire n forget
<jelmer> heh, ok
<lifeless> yay
<lifeless> one patch in
<james_w> isn't it bzr commit --local?
<lifeless> back shortly, breakkie
<jelmer> lifeless: hmm, where did you file that bug? I can't find it?
<ubotu> New bug: #137157 in bzr "Cannot lock: transport is read only" [Undecided,New]  https://launchpad.net/bugs/137157
#bzr 2007-09-04
<Odd_Bloke> Is there a way to convert bzr -> SVN?
<Odd_Bloke> It only need be a one-off conversion, I just want to run some metrics.
<lifeless> bzr push
<lifeless> jelmer: ^
<lifeless> Odd_Bloke: or perhaps bzr svnserve
<keir> when testing out 'bzr send', and mailing to myself, why is the subject  '[MERGE]  (Nam Nguyen) Pre-commit hook' ? i didn't specify that subject, or the name 'nam nguyen' anywhere
<keir> (this is in a clean branch of bzr.dev)
<lifeless> keir: do 'bzr log -r -1'
<keir> hmm, ok
<jelmer> Odd_Bloke: bzr svn-push from bzr-svn 0.4 should be able to do that
<jelmer> lifeless: bzr svnserve is pretty much nonexistant
<lifeless> jelmer: ok
<keir> ok. so it uses the last commit message as the subject?
<keir> i'm trying to figure out how to get bzr send to work nicely with gmail, and then write a wiki page about it
<keir> (gmail has smtp)
<lifeless> keir: normally you have two branches
<lifeless> your branch
<lifeless> and the target
<lifeless> testing with your branch == target is unusual
<Odd_Bloke> jelmer: "bzr: ERROR: Invalid http response for http://svn.uwcs.co.uk/repos/gryle/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jelmer> Odd_Bloke: does the repository require authentication?
<keir> lifeless, as i understand it bzr send is intended for the following use case:
<Odd_Bloke> jelmer: Yeah, I was wondering if I need to put that in a config file somewhere?
<keir> 1) bzr branch 2) hack hack 3) commit 4) repeat 2&3 5) bzr send --mail-to=somelist@someproj.org
<lifeless> keir: thats right
<jelmer> Odd_Bloke: bzr-svn uses the credentials stored in ~/.subversion/auth/
<jelmer> Odd_Bloke: the easiest way is to force svn to store those credentials first before using bzr-svn
<keir> lifeless, and by default it uses the parent branch as the target
<lifeless> keir: send --help
<lifeless> :)
<lifeless> I'm not familiar with send really
<igc> morning
<Odd_Bloke> jelmer: I've finally sorted out the auth'ing problems, but I'm now being told the branches have diverged and I need to merge them.  Running 'bzr merge <SVN repo location>' gives me an error about incompatible repositories.  What should I be doing now?
<jelmer> Odd_Bloke: the location you're trying to push to, does that already exist?
<Odd_Bloke> jelmer: Yeah.
<poolie> hi all
<igc> morning poolie
<poolie> hi ian
<jelmer> Odd_Bloke: that doesn't work yet :-( pushing to /trunk if it doesn't exist yet should work
<lifeless> whats with the NEWS indenting changes
<Odd_Bloke> jelmer: Ah OK.
<Odd_Bloke> I'll do that then. :D
<lifeless> I don't recall seeing anything on-list
<lifeless> and all my branches are conflicting heinously
<poolie> lifeless, different sections were inconsistent, it looks bad in rest
<poolie> i am sorry for all the conflicts
<keir> i see there is support for thunderbird in mail_client.py; how do i tell bzr to use it?
<lifeless> I think you should announce the right indent on list
<poolie> probably should have done it during freeze
<lifeless> everyone who has outstanding branches will need to review their new sections
<igc> lifeless: I mentioned it yesterday on IRC - it's a pain :-(
<lifeless> igc: btw pqm submit standard is (submitter) MESSAGE (authors)   (as far as I know)
<Odd_Bloke> jelmer: I got http://pastebin.com/m47fed230 when pushing to the uncreated /trunk.
<Odd_Bloke> jelmer: Both with and without --overwrite.
<lifeless> igc: did you profile the pre commit hook changes on big trees or do I need to ?
<poolie> it would be nice to patch pqm to use the signer or email sender
<poolie> or indeed to just read a merge directive...
<jelmer> Odd_Bloke: please use the svn-push command
<igc> lifeless: I'm happy to do it
<keir> nm!
<lifeless> poolie: indeed, patches considered gratefully
<lifeless> :)
<jelmer> Odd_Bloke: you're hitting bug 127945
<ubotu> Launchpad bug 127945 in bzr-svn "Integrate creating new branch functionality into standard push" [Low,Triaged]  https://launchpad.net/bugs/127945
<Odd_Bloke> jelmer: OK, I've tried with svn-push and hit http://pastebin.com/m4a239e0d
<Odd_Bloke> jelmer: Thanks for helping me with this, by the way. :)
<jelmer> argh
<igc> lifeless: checking bzr log --short on bzr.dev shows both forms in equal amounts :-)
<jelmer> Odd_Bloke: please change _is_http_transport() in transport.py to return False
<jelmer> Odd_Bloke: you've hit pretty much all known bugs in bzr-svn :-/
<lifeless> igc: we should choose one on list
<igc> I'm happy either way - but we should all the same as you suggest
<poolie> lifeless, did you see my PM?
<Odd_Bloke> jelmer: A progress bar! \o/
<lifeless> poolie: ah yes
<lifeless> jelmer: I'm not sure where the bug is
<lifeless> igc: I don't feel confident enough in your delta based code for recommend it for 0.91
<lifeless> not that I think its actually wrong, just its changing something rather core
<igc> lifeless: do you mean delta-based code or the iter-changes change? The delta-based code is certainly not going into to 0.91
<lifeless> the iter changes change
<igc> fair enough - it's a risky area ....
<igc> which is why I asked the Q re benefit/risk in the submission
<igc> lifeless: I felt it was useful to get out there in any case ...
<igc> it's a clean patch you can apply to your stuff while benchmarking initial commit for example
<igc> it's also a "better" routine to move to your iterator from than the existing one I suspect
<lifeless> 48% of time is in record_revision at the moment
<lifeless> thata 1m30
<lifeless> we know that the whole commit can be done in 1m
<lifeless> so there should be about 50% fat there
<jelmer> lifeless: ok, version info is fixed now. if you find the bug, please let me know so we can close it + mention the bug # in NEWS
<lifeless> :)
<lifeless> danke
<keir> lifeless, you mentioned in a list email sometime ago that you wanted to write a high-speed index layer
<keir> lifeless, is that done yet?
<keir> lifeless, and if not, where do i start?
<lifeless> hi
<lifeless> its not done yet
<lifeless> the index layer thats needed is currently implemented as bzrlib.index
<keir> basically, i'd love to help, but i'm not familiar with the innards of bzr
<lifeless> I have a branch up at http://people.ubuntu.com/~robertc/baz2.0/index
<lifeless> if you look inside bzrlib/index.py
<lifeless> and bzrlib/tests/test_index.py
<keir> however i love writing high speed c code :)
<lifeless> you can see the current layer
<keir> which ops would this speed up?
<lifeless> the python code is performing quite well
<lifeless> what needs changing is the disk format primarily
<lifeless> after that is made efficient doing a C version becomes a discussion point
<keir> ok
<keir> i buy that
<lifeless> the current disk format is bisectable but I haven't written bisection code yet
<lifeless> however it could be better
<keir> so i should focus on 1) understanding current format
<keir> 2) make new format
<lifeless> e.g. a 4K node size b*tree would give something like 20-way fan out compared to 2-way for bisection
<lifeless> I'd suggest
<lifeless> 1) understand the index API
<lifeless> 2) discuss with me on the list your ideas for a new format
<keir> ok
<lifeless> I'll probably remember/realise constraints that are not documented that will impact your design
<lifeless> 3) go do it :)
<keir> what i'd like to do is make a very compact format  which needs to be rebuilt occasionally
<lifeless> there is no need to keep the current format code - you can replace it in-place
<lifeless> (its documented as being unstable)
<keir> we did some super cool hacking on our project (astrometry.net) to make 1gb trees which have to pointers and other coolness. they can be mmaped directly from disk!
<lifeless> ok this suggests a couple of immediate things to highlight
<lifeless> the index layer has write-once indices
<keir> *have no pointetrs*
<keir> cool
<lifeless> each pack transaction adds a new pack, and new indices for that one pack
<lifeless> we don't modify existing files because that is problematic - permissions, and appending and data integrity
<keir> ok
<lifeless> we can't rely on mmap because indices may be on sftp/ftp/http servers
<keir> of course, but if it's local, then you can do that.
<lifeless> indices can be big - mozilla's text index is 200MB
<keir> is there a 'bzr for computer scientists' link somewhere?
<lifeless> well mmap has portability issues. So mmap might be an optimisation, but we need to avoid full-index access regardless because of the size indices grow too
<keir> of course; mmap'ing has the very desirable property that only the necessary parts are read
<lifeless> doc/developers/repository.txt has some notes about indexing, and the comments and docstrings and source text have more
<keir> your OS handles smart caching and even sharing previously read pages between processes
<lifeless> except that read errors show up as segfaults
<lifeless> which can make diagnosis rather hard.
<keir> true
<keir> well, first a new disk format then speeding it up
<lifeless> I'm not saying 'dont use mmap at all', I'm saying that mmap would be a 4), like a C version.
<keir> :)
<lifeless> something that we should not design-in, but its not harmful if its possible for mmap to be used in future.
<keir> the other thing i've come to appreciate, that makes me feel sooo 1980, is fixed-width file formats like FITS.
<Peng> Huh. I tried to branch baz2.0/index with 0.90, and it errored out about not supporting the format (duh), and then I tried with the pack branch, and it branched 0 revisions. I had to rm -rf the index dir and try again.
* Peng wanders off.
<lifeless> Peng: it waspushing
<keir> anyway, i'll think about it
<lifeless> Peng: try now
<lifeless> keir: yah, we have variale length keys
<lifeless> keir: oh, and we don't have a seek() interface to files, only readv
<Peng> lifeless: Oh.
<Peng> lifeless: Okies.
<Peng> lifeless: yeah, it did work when I tried it again.
<keir> lifeless, this is because of transports?
<lifeless> keir: also forward-only IO is faster than random access, and a single readv() is much faster than 10 readv() covering the same data due to reduced roundtrips
<lifeless> keir: its because of the internet:)
<keir> how do pack-based repos fit into this?
<lifeless> pack based repos are the only user of the index layer
<keir> would a superfast index speed much up? or would it be optimizing 10%?
<lifeless> oh
<lifeless> well depends on the case
<lifeless> 'bzr cat http://mozila.org/bzr/trunk/ChangeLog' (as a hypothetical)
<lifeless> should go from downloading > 200MB of index data
<lifeless> to downloading (say) 64K
<keir> heh, ok
<lifeless> there are also common query patterns to consider
<lifeless> these indices have graphs embedded in them
<lifeless> At the moment graph walking is done by repeated queries to the index
<keir> ok
<keir> why are the graph keys variable-length?
<lifeless> probably the index wants to cache data it has accessed in some manner
<lifeless> the keys are tuples with a fixed number of byte-strings; but each byte-string is variable length
<lifeless> revision ids are variable length
<lifeless> file ids likewise
<keir> ok.
<keir> i have to run now but i'll be back
<lifeless> ok
<lifeless> anyhow graph walking is kindof pathological
<lifeless> many queries in a row going from parent to child each time
<lifeless> only a topological sort can give locality of reference on such things
<lifeless> and we also have the combining of separate index files to accommodate
<Peng> Woah. One 56 MB pack and one 55 MB one. Not super disk-efficient.
<lifeless> Peng: you are using an old pack branch I bet
<lifeless> Peng: that was fixed way back
<lifeless> spiv: when you so 'selftest Remote' do you see unlock errors?
<keir> i sent a merge message to the list, but it hasn't shown up
<keir> might it be caught in moderator limbo? i did subscribe.
<keir> from mierle@gmail.com
<spiv> lifeless: I'll check
<spiv> lifeless: but I didn't last night.
<lifeless> keir: I haven't seen one
<lifeless> [5484/8093 in 432s, 296 skipped, 4 missing features]  branch_implementations.test_locking.TestBranchLocking.test_unlock_after_lock_write_with_token(RemoteBranchFormat)                                             /
<lifeless> home/robertc/source/baz/commit/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:52245/b/.bzr/repository/>) was not explicitly unlocked
<lifeless>   warn("file group %r was not explicitly unlocked" % self)
<spiv> lifeless: it passes for me.  I see unlock warnings though.
<lifeless> could you fix please :)
<spiv> Right.  Those have been there for ages.
<lifeless> I blame you with reason
<lifeless> but perhaps not accuracy
<spiv> I took a quick look a few days ago, actually, but it's messy.
<spiv> I think it may require untangling some of the mess in Remote{Repository,Branch}._ensure_real
<lifeless> surely not
<lifeless> surely its just a bug that something is wrong in nlock() ?
<spiv> That test does:
<spiv>             # We only want to test the relocking abilities of branch, so use the
<spiv>             # existing repository object which is already locked.
<spiv>             new_branch.repository = branch.repository
<spiv>             new_branch.lock_write(token=token)
<spiv>             new_branch.unlock()
<vaidhy> I am trying to push my changes in bzr using webdav and it fails everytime.. Has anyone used webdav to push successfully?
<spiv> which seems to cause confusion when branch.unlock happens.
<spiv> Because the repository's lock state has been twiddled in some way.
<lifeless> vaidhy: I don't know; perhaps you could mail the list or file a bug on the webdav plugin ?
<vaidhy> that is my next step.. I was hoping to catch vila so that I can ask him :)
<lifeless> hes in franch
<lifeless> so this is not a good time for catching him
<vaidhy> ok.. let me email the list..
<poolie_> lifeless, re special casing initial commit
<poolie_> i'm kind of sympathetic
<lifeless> your _ is showing
<poolie_> i know
<poolie_> irc sucks
<poolie_> or maybe i'm a member variable
<poolie_> anyhow, it does seem a bit arbitrary
<lifeless> yup
<poolie_> maybe we should just say 'commit is faster if you do -q'
<lifeless> I think thats fine too
<poolie_> and ask people to do that for bulk imports or benchmarking
<lifeless> I'd like us to not change the default verbosity level
<poolie_> ok
<lifeless> I'm happy with special casing initial commit
<lifeless> because though it is arbitrary, its the least useful time for commit output whent here are k's of files.
<vaidhy> can I specify a port for sftp in bzr?
<poolie_> so would -v still show them?
<lifeless> poolie_: that is what I was proposing
<lifeless> vaidhy: sftp://host:port/ should work
<vaidhy> ok. thanks
* keir votes for special casing initial commit
<poolie_> lifeless, as long as the help text makes it clear, it's ok with me
<keir> actually i think we should have a single command to do init, add *, commit  too :)
<Peng> lifeless: One of the packs was last modified 2007-08-25 and the other 2007-08-30. I've been keeping pretty up-to-date.
<keir> bazaar@lists.canonical.com
<keir> is that the right place to 'bzr send' to?
<lifeless> Peng: check the branch you used, not the date of the packs :)
<lifeless> Peng: it definately doesn't do that for me
<lifeless> keir: yes
<keir> weird
<keir> it's there in my sent mail on gmail, to that address
<Peng> lifeless: I would've been using the latest version of the branch from those days.
<Peng> lifeless: Or possibly the knit version of it.
<lifeless> poolie_: I was thinking something like the builtins.py code doing 'Initial commit - setting default verbosity to -q. You can can interrupt the commit, or run bzr uncommit, then commit again with -v to see the files being added.'
<keir> where should i send my patch? for whatever reason the list isn't getting through
<keir> the irony is not lost on me (my patch is for bzr send)
<lifeless> Peng: check bzr st and bzr revno in the branch you ran bzr from :)
<poolie_> keir, i'll check the mail feature
<lifeless> keir: perhaps file a bug and attach the branch ?
<poolie_> lifeless, what is that quoted string? the news entry? the help?
<lifeless> poolie_: output
<lifeless> poolie_: I don't think help really needs to mention it
<lifeless> but it could
<poolie_> that would be printed to stdout?
<Peng> lifeless: I updated it today.
<poolie_> i don't like that so much
<Peng> Huh.
<lifeless> poolie_: ok it was a thought
<poolie_> i'd rather add to the help message
<Peng> I ran "bzr pack", and now there's the 56 MB one and a new 56.6 MB one.
<Peng> And some small ones.
<Peng> But not as many as there were before.
<lifeless> Peng: oh hmm.. can you check th epack files against pack-names ?
<keir> lifeless, the branch is not public
<poolie_> 'for the initial commit in a branch, which typically adds many files, the filenames are not printed unless -v is given.  in every other case, the changes are shown unless -q is given.'
<poolie_> keir, i don't see it in mailman
<lifeless> Peng: there is a small race condition where the pack is added to the dir then the pack-names index is updated
<poolie_> can you please forward your message to me mbp@canonical.com, including the original message-id, if you have ti
<lifeless> Peng: a crash at the wrong time will leave an unreferenced .pack file
<Peng> lifeless: pack-names seems to only list the new 56.6 MB one.
<keir> poolie_, i just re-sent it to bazaar@lists.canonical.com, this time manually (rather than via gmail SMTP)
<lifeless> there you go
<Peng> lifeless: I don't think I've crashed it.
<lifeless> ctrl-C'd it ?
<Peng> Nevar!
<Peng> Hold on. TV is more fun than packs.
<poolie_> lifeless, i agree about watching for the performance impact of changes
<igc> poolie_: I like that wording. I'll grab some lunch then resubmit my patch to be 'initial commit less verbose'
* igc lunch
<keir> weird, it must be my gmail send that is broken.
<poolie_> speaking of which
<poolie_> http://benchmark.bazaar-vcs.org/usertest/usertest.log
<keir> i'm trying to setup a bzr send + gmail tutorial
<poolie_> shows good results, except that script_common.AddTask:status is three times slower than 0.17
<poolie_> can this really be true?
<poolie_> keir, that'd be good
<lifeless> I think it can be true
<poolie_> or maybe we can have gmail as a mail_client?
<keir> there are all these complicated ways to send mail via gmail
<keir> but you can do it in 10 lines of python (including tls) via smtplib
<poolie_> keir, i got your patch about python
<poolie_> i mean, mutt
<keir> poolie_, yeah, i sent it a 2nd time manually rather than via bzr send
<keir> gmail as a mail client would be really nice, but i don't see how we can automatically add attachments
<keir> so the next closest thing i came up with is to use mutt + gmail smtp backend
<keir> but i really feel good gmail integration is a killer feature
<poolie_> mm
<poolie_> i would like that, as i use gmail myself
<lifeless> keir: file a bug on gmail:)
<keir> exactly
<poolie_> i typically just write to a file then paste that into the compose window
<poolie_> so it's a bit manual
<keir> that's too annoying for me :) i'm a usability snob
<poolie_> i'm very happy you're looking at it
<poolie_> i agree it would be a great feature
<keir> what i have now is pretty decent; bzr send pops up mutt, then i 'set sendmail=~/bin/gmail_send.py" which uses python's smtplib to send
<keir> then your mail shows up in gmail outbox
<keir> poolie_, would that be good enough for you? or do you really want the web interface too?
<poolie_> i'm going for a bit
<poolie_> keir, that would be ok
<Peng> lifeless: So bzr forgot about the one pack in the past, and left it there this time? Or did it forget about it just now?
<poolie_> it might be cleaner if it just got a message from $EDITOR then sent the mail directly
<poolie_> as not everyone has mutt
<keir> poolie_, true, but bzr send as editor botches the filename and mime stuff
<keir> besides, edit-headers is super handy
<lifeless> Peng: probably some time ago
<lifeless> Peng: whats the date on it
<keir> one issue is: i have to store gmail pw somewhere
<keir> should i store it rot13'd?
<poolie_> actually you should look at vila's auth ring spec
<poolie_> it's not implemented yet but he wants to add a standard store for these things
<Peng> lifeless: It's the 2007-08-25 one.
<lifeless> I still think netrc is the right place ;)
<Peng> lifeless: The mtime, you mean?
<lifeless> yah
<lifeless> we never modify packs
<Peng> Right.
* Peng wanders off.
<keir> regarding auth, can we use a ssh key?
<keir> everyone has pub/priv ssh keys; i figure it'd be neat if we could use those to store the pw's
<lifeless> uhm
<lifeless> some people get obsessive about such things, having unaudited code access passphrases is generally bad
<keir> possibly.
<lifeless> I'm one of those people :)
<keir> heh, ok
<keir> where is the right place to put a 'bzr with gmail' page?
<lifeless> I'd be putting it in the bzr send help, or a help topic in a seealso from that
<keir> ok
<keir> i wonder how hard it would be to have bzr notice recent bundles floating around on the ML, then just pick one and merge it
<keir> rather than dl'ing them
<AfC> [I'm a bit vague about why you're wondering about keyrings, but as of 2.18 or so we have a good one built in; bzr should probably consider just talking to it] 
<keir> 2.18?
<keir> gnome you mean?
<AfC> Of course
<keir> python api?
<AfC> I imagine so
<keir> cool
<keir> ok, maybe i'll do that now
<lifeless> I think making the backend pluggable might be good
<lifeless> but we need to support
<lifeless> windows
<lifeless> console unix
<lifeless> gnome
<lifeless> kde
<keir> well, for sending to gmail, it's kinda specific
<keir> i just need a sendmail work-alike
<lifeless> fluxbox and other such things
<keir> my python script is 10 lines right now, but has my pw in the clear
<lifeless> keir: just prompt for the password ?
<lifeless> bzrlib has a password prompt routine
<AfC> I find that so frustrating. Who gives a hoot about the rest of them? This project is paid for by Canonical, whose primary product is a GNOME desktop. Why would we give up a better user experience in our environment to support the platforms of non-free vendors?
<keir> if others want to do that, sure, but all i want is a super slick bzr send for my env of choice, ubuntu :)
<AfC> keir: exactly.
<lifeless> AfC: Wow, lets address a few points there. Its only partly paid for by Canonical. Its primarily an open source project.
<lifeless> AfC: secondly, Kubuntu and Xubuntu are both primary products along with Ubuntu.
<lifeless> AfC: thirdly Windows is a strategic user base for us because many open source projects - including chunks of Gnome - build or otherwise target windows. Not supporting windows for infratructure like VCS is bad.
<lifeless> AfC: Lastly no one talked about giving up user experience.
<lifeless> so that minirant was IMO entirely aimed at a strawman
<AfC> I didn't say not supporting Windows. I said to treat them like the second class citizens they deserve yo be, and  not crippling or giving up a potentially better desktop integration in _our_ environments. Taking today's example, GNOME has a desktop wide keyring agent facility; it would be tremendous to integrate cleanly with it, rather than being yet another stand-alone program that doesn't integrate with anything.
<lifeless> AfC: You are clearly arguing with some position you *think* I've taken, rather than what I have said or proposed.
<lifeless> so I'm going to go back to making commit faster
* AfC files this away for use at his next conference.
<keir> in the meantime, i figured out how to use gnome keyring from python :)
<AfC> keir: which library was it in?
<fullermd> Gnome?  What is this 'gnome' of which you speak?   :p
<keir> afc: http://www.rittau.org/blog/20070726-01
<lifeless> I'm popping out for a walk, thinking through therestructuring
<lifeless> poolie_: if you are idle and wanted to ring my mobile to be an idea bouncer that might be useful
<igc> so lifeless, poolie_: less verbose on initial commit only is agreed yes?
<lifeless> hi abentley
<lifeless> igc: I think so
<abentley> Hi.
<igc> hi abentley
<lifeless> abentley: what are your thoughts on defaulting commit to -q for first-commit only
<abentley> lifeless: I'd prefer to use -q all the time-- don't like inconsistency.
<lifeless> abentley: I don't either; AFAICT the use case for this is benchmarking folk that don't take terminal overhead into account
<lifeless> I like the current output
<lifeless> I don't want regular commits to lose that
<igc> lifeless: that not quite true ...
<igc> it's not terminal overhead
<igc> it's the overhead of deciding on the nature of a change
<lifeless> well
<lifeless> on first commit that should be nearly zero
<lifeless> it can be special cased to have everything new
<igc> sounds right
<lifeless> so why do you want to change the default verbosity to -q then? That was never answered to my satisfaction I guess
<igc> it's also the UI question of just how useful listing 100s of files is on initial commit
<abentley> igc: That's one case of initial commit.
<abentley> The other case has two or three files.
<igc> please don't use -q  -that's separate again
<lifeless> you've lost me
<igc> -q is no output
<igc> the proposal was for ocmmit to just show the "Commited revision n" msg
* igc digs ...
<igc> https://lists.ubuntu.com/archives/bazaar/2007q2/027044.html
<igc> the change was a better UI
<igc> the performance gain was a side benefit
<abentley> Oy, so it's not even consistent with -q.
<lifeless> garh
<lifeless> igc: I don't think hiding the changed paths list is better
<lifeless> I'd tolerate it for first-commit only, when there are many files, if that was trivial to detect performance wise
<igc> I understand
<abentley> It's especially not better for new projects, where there's only a few files to commit, and the inconsistency will be surprising.
<lifeless> or for first-commit only, though as abentley says that has higher surprise factor
<igc> the theory was that most other VCSs don't show the info unless -v was specified
<lifeless> and we're better than them.
<lifeless> thats our raison d'etre
<igc> sure ...
<lifeless> anytime we look at what another VCS does in terms of behaviour we have to get the rationale
<igc> but that's not what everyone said in the mailing list thread above :-)
<abentley> What mailing list thread?  Something that happened in the last 12 hours?
<igc> https://lists.ubuntu.com/archives/bazaar/2007q2/027044.html
<igc> in the last 12-15 hrs, I've put up a patch - which was consistent
<igc> it was then suggested we special case it for initial commit only
<igc> which I just started doing but haven't done
<lifeless> igc: I am planning a new method on mutable tree
<lifeless> 'path_content_summary'
<igc> sounds nice
<igc> what does it return?
<lifeless> igc: this will return a tuple: (kind, size or None, executable, sha or None)
<lifeless> size is None for things that have no Size
<igc> that will help
<lifeless> same for exec
<lifeless> sha is returned if it can be got from hash cache only
<lifeless> I plan to use this to delete _read_tree_state
<igc> dirstate is fast but one lookup is better than multiple
<igc> hooray for _read_tree_state being nuked ...
<igc> it's not like I haven't been trying to do that :-)
<lifeless> I did suggest how to get to it when you started on commit :)
<keir> is there an easy way to query a pw and not show it in python?
<lifeless> pydoc bzrlib.ui
<keir> my gmail send util is independent of bzr
<lifeless> and ?
<lifeless> :)
<lifeless> bzrlib is a library
<keir> heh
<lifeless> also
<lifeless> you can look at the code we have
<lifeless> to see how to do it
<keir> true :)
<jml> also 'pydoc getpass'
<lifeless> tooeasy.com
<lifeless> abentley: ping
<abentley> lifeless: muh?
<lifeless> tree._comparison_data
<lifeless> there's no docstring, I'm trying to figure out why it returns the raw stat, and never the sha
<lifeless> I guess that what I'm working on is basically in the same api space and don't want to duplicate unnecessarily
<lifeless> I was going to write path_content_summary that would take just a path and return (kind, size-or-none, exec-or-none, sha-or-none)
<abentley> Well, I suppose it *could* pass the sha1, when needed.  But what actually happens is that the stat value is examined, and if it needs the sha1, it uses the stat value to get it.
<lifeless> ah
<lifeless> whats entry there for - win32 ?
<abentley> It's quite possible that there are cleaner ways to do this.
<abentley> The entry's for revision trees.
<lifeless> ok
<abentley> G'night.
<lifeless> I think I'll my little API up and ask you to comment on it's usefulness
<lifeless> I want it for commit, and don't want 'entry' there
<lifeless> but I can look at moving _iter_changes onto my api, or reusing _comparison_data if that makes more sense
<lifeless> gnight, sleep well
<lifeless> ciaoish
<keir> well, i have a nice gmail sendmail replacement which uses gnome keyring to store pw's now
<keir> what is the default bzr url for trunk when you register a new project on launchpad?
<poolie_> keir?
<poolie_> oh, typically something like
<poolie_> sftp://bazaar.launchpad.net/~keir/bzr-gmail/trunk
<poolie_> you can use any branch name you like for the last component
<keir> poolie_, yup, i got it
<keir> poolie_, can you try something for me?
<poolie_> sure
<keir> poolie_, http://bazaar-vcs.org/BzrSendWithGmail
<keir> see if you can get it to work
<keir> sadly this is rather gnome/unix specific
<keir> i really believe we need slick all-platform gmail support, but this is better than nothing
<keir> poolie_, i'm sleepy (in EST) so let me know if you have any success. mierle@gmail.com
<poolie_> ok
<keir> poolie_, also i'd like to write tests for gsendmail.py, but i'm not sure how/what to test because it's all API!
<poolie_> Password:
<poolie_> Traceback (most recent call last):
<poolie_>   File "gsendmail.py", line 137, in <module>
<poolie_>     sys.exit(main(options, args))
<poolie_>   File "gsendmail.py", line 108, in main
<poolie_>     gmail_key_ring.set_credentials((gmail_addr, pw))
<poolie_>   File "gsendmail.py", line 75, in set_credentials
<poolie_>     gkey.ITEM_NETWORK_PASSWORD, self._name, attrs, pw, True)
<poolie_> gnomekeyring.DeniedError
<poolie_> it asked me for an initial keyring password, then this.
<AfC> poolie_: credential not [yet]  stored, maybe?
<poolie_> keir, when i tried a second time it seemed to work
<AfC> What timezone is Jelmer in?
<poolie_> +1 or +2
<AfC> poolie_: thanks
<mwhudson> +2 right now
<AfC> poolie_: got a sec?
<poolie_> yes
<AfC> poolie_: using the bzr bundle command (as recently amended to be bzr send, really), the command line is now (and perhaps for some time) has "submit branch" and "public branch" as arguments.
<AfC> poolie_: trying to figure out what these mean, I ran help, and was somewhat lost after reading the description there
<AfC> poolie_: so I poked around
<AfC> and have the following [as ever, from an "outsider"'s perspective] 
<AfC> poolie_: http://rafb.net/p/imxMEp87.html
<AfC> which is bzr info on three different branches here
<igc> latest commit reporting patch/proposal send to the list
<AfC> The first one makes sense (although I'm not entirely sure how ../primary is the parent of mainline)
<igc> time for some food & time with the kids
<igc> night all
<AfC> The second one (where I have run bzr bundle (send) at least once since 0.90), is a bit more confusing
<AfC> indeed, my thought was that it was all a bit repetitive.
<poolie_> it's not so obvious how these locations match up to other operations
<poolie_> i have been wondering if we should perhaps say
<AfC> Then the third one, from one of the contributors whom I've given access to create branches on our server, is really confusing.
<poolie_> defaults for:
<AfC> Yeah
<poolie_>   push: ...
<poolie_>   merge source: ...
<poolie_>   public location:
<AfC> So I can sorta guess where each might have come from, but it's all inference and, as you say, its not clear how it aligns
<AfC> [and .bazaar/locations.conf also confuses me - at one point I was wondering if I was supposed to edit THAT. Ick. Classic case of just enough knowledge to be dangerous to oneself] 
<AfC> End of first impression
<poolie_> so do you think just making it more clear how they map to commands or operations would be enough?
<poolie_> ideally in both info and the configuration
<poolie_> or is it more than that?
<AfC> poolie_: I suspect so
<AfC> poolie_: combination of more specific help text, less noise about version this and tagstate-dir that, and what you suggest about where those come from and what they're used for when running info would seem to more than cover it.
<rotty`> how does one list bzr repos in config-manager "configs"?
<AfC> [alternately, you could make these public, submit, parent, etc the first class items, and change the text of `push`, `pull`, etc to state that they use "the public branch" or "this command will diff by default from the submit branch" or whatever
<poolie_> rotty`, i think just by the url?
<poolie_> for the branch?
<rotty`> (it always tells me "Unknown url type")
<poolie_> there's an example in the configmanager source
<poolie_> i don't have it on this machine...
<poolie_> rotty`, maybe you have a really old configmanagere version
<thumper> are there any Solaris 10 packages for bzr somewhere?
<poolie_> thumper, i don't know of current packages
<thumper> are they easy to make?
<thumper> or do you need a Solaris person?
<rotty`> poolie_: where do I get the newest config-manager?
<poolie_> rotty`, that's a really good question
<poolie_> i was sure it was on launchpad but i can't find it
<poolie_> rotty`, i suggest you mail bazaar@lists.canonical.com
<poolie_> i'm going to call it a night
<alla> is the submit-by-mail plugin still supported? or is there a better way to email and apply patches?
<luks> not sure what does the plugin do, but there is 'bzr send --mail-to XXX' in bzr 0.90
<alla> ooh
<alla> bzr: ERROR: unknown command "send"
<alla> Using 0.17.0
<spiv> alla: yeah, it's a pretty new command.
<spiv> alla: upgrade to 0.90
<alla> ooh, I need to upgrade, thanks!
<luks> oh, wait
<luks> --mail-to is only in not-yet-released 0.91
<alla> hmph. Well how do people normally email patches?
<luks> 0.90 has only 'send -o'
<luks> with older versions `bzr bundle >mypatch.diff` and then mail the patch manually
<luks> with 0.90, `bzr send -o mypatch.diff`
<alla> I'm upgrading now.. what's -o?
<luks> --output, it will save the patch to a file
<AfC> thumper: I must admit that on the one Solaris machine we have, we just installed bzr manually rather than attempting to package it; since Solaris packaging is brain dead anyway. and this machine is not under a proper infrastructure management regime, we didn't worry about it too much.
<luks> then you can use `bzr merge` or `bzr pull` to apply it
<alla> luks: surely you cannot `bzr merge` a .diff file ..?
<alla> oh it's a patch file?
<luks> it's not a traditional patch file
<luks> but it's patch-compatible
<alla> exciting
<luks> it has all the revision data needed to merge/pull it
<AfC> [.patch ( .diff ) is a good extension to use for bundles because then mail clients get the MIME type right, so a wise man once told me] 
<alla> AfC: Your syntax does not compute. Are you saying .diff is preferred?
<AfC> .patch, actually
<alla> Ok, thanks.
<AfC> Where does the --author option live? (Or is that not released yet?)
<AfC> [I expected it on commit, but it wasn't there] 
<dato> if you don't see it on commit, then it's not released yet
* AfC rather wishes that it just worked automatically, ie, I am cherry picking from someone else's code [branch] , so clearly they [those revisions]  are the author
<AfC> What _is_ the difference between "submit branch" and "public branch" in the arguments to bzr bundle|send?
<luks> submit branch is the target
<fullermd> I believe 'submit' is "The branch these changes are to be applied to, so the one used to determine the base"
<luks> public branch is the public location if your branch
<AfC> Right. So I just did
<AfC> bzr bundle ../mainline http://research.operationaldynamics.com/bzr/java-gnome/mainline/
<AfC> (as I am creating a cherry pick for someone)
<fullermd> Public would reallyonly be _required_ if you were sending a directive without a built-in bundle.
<AfC> and, by inspection, the first argument is the branch it "diffs against" (sic), as before
<fullermd> (it's just informative if there is a bundle)
<luks> AfC: yes, because that's the branch you want to merge it to
<AfC> whereas the second conveys "public branch" along which ... well, not sure what that's for, but it seems a nice touch.
<AfC> but I'm not quite clear on why the bundle needs to record the submit (-> "target") in the bundle.
<AfC> as ../mainline has no relevance for the recipient.
<luks> but you can have a merge-directive without bundle
<AfC> [so maybe I should only do bundles against a connected repo and not against local branches, convenient as that seems?] 
<luks> and use a public location of the target branch
<AfC> fullermd: er, huh? "sending a directive without a built-in bundle"? How can you send a bundle without its attached patch?
<AfC> fullermd: it sounds like I've got it backwards, and public branch is something the person is suppose to pull the bundlerevisions from
<AfC> ?
<fullermd> Other way around (and you don't send a bundle, you send a merge directive)
<AfC> (Yikes, but this is confusing)
<fullermd> You can send a merge directive that contains no revision information, which is just an instruction "Merge rev[s]  X[,Y,Z]  from $PUBLIC_LOCATION"
<AfC> fullermd: call it what you will, we're sending that-which-people-send-to-submit-code-for-consideration-for-inclusion-in-the-upstream-project
<fullermd> Well, it's not a rose.  By any other name, it's something different.
<AfC> fullermd: ah. It is "from $public-branch"
<fullermd> "bundle" doesn't refer to "The whole output", it's just that part of the output containing the revisions to apply.
<AfC> hm. So little point in me the upstream maintainer using that
<AfC> fullermd: the patch in bzr from, sure.
<fullermd> If you send a directive with a bundle, it's got all that information, and can be used directly to apply to the target branch.
<AfC> s/from/form as committed revisions/
<fullermd> If you send a directive _without_ a bundle, it needs that public branch location since it doesn't have any info internally, and just says "go there".
<AfC> H
<AfC> Hm
<AfC> I guess. Not sure what we'd use that for, but I'm sure you use it for something.
<luks> AfC: btw, regarding cherry picking and the author info, I wrote this simple hack for it - https://code.launchpad.net/~luks/+junk/bzr-pick
<fullermd> If you're merging a lot of code from a long-lived branch, say.  You don't want to send many 5 meg emails, when you have a existing public location for this previously-experimental-now-landing code.
<AfC> fullermd: ok, sure.
<fullermd> For little stuff, 'traditional' directives with the bundle are probably a lot simpler.
<AfC> fullermd: [assuming such a place exists and the receiving party, by the grace of god, actually has global network access at the time they attempt to use the received email lacking revisions, implying a high level of communication between the parties involved. Fair enough] 
<fullermd> And in those cases, the 'public' info is pretty cosmetic (may be interesting for human reviewers, but it's not needed)
<fullermd> Well, it's also aimed at being used for automated processes, like PQM.  Merge directive is a standard formal format, so it can be used to tell a robot "Go merge this in this way".
<AfC> fullermd: so we've dispensed with public branch as a needed argument since the revisions in question I'm sending to someone are not, in fact, in mainline (yet, which is the whole point). Fine. From there, I wonder
<AfC> fullermd: what the value of having the branch I diffed against ("../mainline") included in the bundle with the label "TARGET"?
<fullermd> Mostly cosmetic, probably.  Informative to you, and assuming you have known reasonable-ish local branch naming, informative to your target.
<fullermd> e.g., if it says "../v1_legacy", the person you send it to could assume that there's a branch for old v1 code that you're making this against, if you fail to mention such.
<AfC> fullermd: [re PQM, yes, I know, but since mere mortals and other medium size projects with humans rather than robots doing the work need the means to ship revisions around, and bundles (in the old sense of the word) were preserved (thank god) in 0.90 even though merge-directive happens to be the encoding] 
<fullermd> You certainly should mention, though.
<fullermd> It's probably more a matter of "This info was supplied, so shouldn't be discarded" than "This info will have direct application at the target".
<AfC> fullermd: re cosmetic - yeah, I suppose, but it has near zero relevance to the receiver and I have to therefore worry not to use anything offencive in my local branch directory names because these names leak. Not super thrilled about htat.
<fullermd> Sure, if you're sending to humans, a bundle-less directive is probably less interesting than just bashing out an email saying "Hey, look at revs X-Y of my branch at http://...".
<AfC> fullermd: let me put it this way: bundle-full revisions are a feature we're using and that humans are looking at.
<fullermd> Oh, well, I think of it as an opportunity to use extra offensivity in my local branch naming, to help thin the herd   ;)
<AfC> fullermd: uh huh :)
* AfC adds some notes to the bug he's going to file about this.
<fullermd> In that situation, bundle-less directives are probably pretty uninteresting to you (at least, except for occasional cases of really large suggestions that you don't want to waste tons of email bandwidth on)
<lifeless> night all
<matkor> Can I do branch checkout having only r-o access to repo via ssh/sftp ? I get error bzr: ERROR: Permission denied: u'/srv/bzr/abbon/admin/.bzr/branch-format': [Errno 13]  Permission denied ?
<matkor> http manages somehow to work without such locks ?
<matkor> seems http: must be special ;)  bzr: ERROR: Transport error: Server refuses to fullfil the request for: http://appserver.ant.vpn/bzr/abbon/admin/.bzr/branch-format
<luks> maybe you really don't have access to the file?
<luks> and neither does apache?
<matkor> luks: Should I have r/w access inside bzr repo using sftp: transport or read only is enough ?
<luks> read only should be enough
<mwhudson> hm
<mwhudson> the smart server isn't too happy with branch names that contain newlines methinks :)
<AfC> newlines in branch names. Nice.
<matkor> OK. one not only neads r but also rX to get access ...
<spiv> mwhudson: in theory it should be ok, it should just url-escape the offending byte...
<spiv> mwhudson: I wouldn't be shocked if that's not true though.
<mkanat> Is "log -v" any faster in 0.90 than in 0.18?
<mkanat> Because man, it's slow. :-)
<mkanat> Something like 60-90x slower than just plain "log".
<mkanat> (In 0.18, that is.)
<mwhudson> spiv: hm
<mwhudson> spiv: theery and praxis seem to differ here
<mwhudson> spiv: is there a way i can make the smart server more verbose on the server side?
<mwhudson> mwh@mithril-inside:aa$ bzr push 'bzr+ssh://bazaar.launchpad.dev/~sabdfl/+junk/aaa
<mwhudson> > bbb'
<mwhudson> bzr: ERROR: Generic bzr smart protocol error: Generic bzr smart protocol error: bad request 'bbb/'
<mwhudson> hmmmm
<mwhudson> something screwy here
<rburton> afternoon all
<rburton> is there a way to update a bzr checkout (not a branch) to a particular revision?
<rburton> bzr update -r [revno]  doesn't appear to exist, which is a shame
<matkor> rburton: I would use branch if need particular revision
<ubotu> New bug: #137283 in bzr "oddness in smart server with paths containing newlines" [Undecided,New]  https://launchpad.net/bugs/137283
<rburton> matkor: so how do i switch to a particular revision with a branch then?
<spiv> rburton: bzr revert -r
<rburton> spiv: does that go forwards too?
<rburton> https://bugs.launchpad.net/bzr/+bug/45719 contains a patch for update, marked "fix committed" but the comments imply its waiting review
<spiv> rburton: I'm not sure, but I expect that in a checkout it would.
<ubotu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] 
<spiv> We use "fix committed" to mean "the fix is committed in a branch somewhere" (vs. "fix released" == "the fix is committed to bzr.dev.")
<rburton> ah
<spiv> (http://bazaar-vcs.org/BugGuidelines)
<rburton> bzr: ERROR: Requested revision: u'10' does not exist in branch: BzrBranch5('file:///home/ross/Local/mess/36/flickrpc/')
<rburton> you can't revert to a newer revision with a checkout
<rburton> same error with a branch
<mwhudson> yes, i would somehow expect revert to not go outside the branch looking for revisions
<rburton> yeah me too
<rburton> ah well, we'll delete the tree and rebuild it then
<mwhudson> rburton: you could comment on that bug, it may kick it into life...
<rburton> doing now
<mwhudson> cool
<Lo-lan-do> Guess who?
<fullermd> Elizabeth Taylor?
<Lo-lan-do> Also, guess what :-)
<Lo-lan-do> It's me, coming back to haunt jelmer with a problem I have with bzr-svn!
<Lo-lan-do> http://paste.debian.net/36211
<jelmer> hey Lo-lan-do
<Lo-lan-do> Hey mate, sorry for the repeated nagging :-)
<jelmer> Lo-lan-do: sorry for the bugs !
<jelmer> Lo-lan-do: can you paste the 'bzr missing -v ' output ?
<Lo-lan-do> http://paste.debian.net/36213
<fullermd> Hm, whaddaya know...   .so's build on Python 2.4 don't get along with 2.5  Whoda thunkit?
<mwhudson> fullermd: they probably sorta mostly work, actually
<mwhudson> unless there were more pervasive changes than i remember in the version bump
<fullermd> Well, I dunno if they worked, or just refused to load and bzr fell back to the .py version.
<fullermd> I just blew 'em away (and got annoyed again at how 'make clean' doesn't actually clean 'em up) and remade 'em.
<jelmer> Lo-lan-do: can you perhaps also paste the output of 'bzr log -v -r -6..-1' ? I'm mainly
<mwhudson> oh, or in a 64 bit environment
<jelmer> interested in the parents of those revisions, was hoping 'bzr missing -v' would print those
<mwhudson> fullermd: but yeah, definitely not recommended or supported
<Lo-lan-do> jelmer: http://paste.debian.net/36214
<jelmer> mwhudson: hi! Can you still reproduce bug 125751 ?
<ubotu> Launchpad bug 125751 in bzr-svn "yet another failing push" [Undecided,New]  https://launchpad.net/bugs/125751
<jelmer> Lo-lan-do: thanks
<mwhudson> jelmer: good question
<jelmer> Lo-lan-do: bug 131692 :-(
<ubotu> Launchpad bug 131692 in bzr-svn "pushing on top of non-lhs parent fails" [High,Triaged]  https://launchpad.net/bugs/131692
<Lo-lan-do> "Non-lhs" referring to the order in which the branches have diverged, or something similar?
<jelmer> to the relation of the revisions
<jelmer> 4864.1.1 in that log output is a subversion revision I guess?
<Lo-lan-do> Yes
<jelmer> non-lhs is a non-left hand side revision
<Lo-lan-do> Is that hard to fix?
<Lo-lan-do> I can wait for a few weeks before pushing, but if it takes a few months instead, I'll find workarounds.
<jelmer> Lo-lan-do: Hopefully less than a week
<jelmer> I badly need to do a 0.4.3 because there are a couple of other issues that need to be fixed urgently
<jelmer> s/0.4.3/0.4.2/
<Lo-lan-do> Oh, that's ample soon enough.  As long as I can pull/merge from SVN, I can postpone my pushing for a while.
<Lo-lan-do> Thanks for the hard work :-)
<mwhudson> jelmer: http://rafb.net/p/nloZz560.html
<mwhudson> which is different, and possibly related to my branching scheme hacks
<jelmer> mwhudson: that one is fixable by making _is_http_transport() return False in transport.py
<mwhudson> jelmer: then i get the same traceback as is already in the bug report
<asabil> hi all
<asabil> is there a way to specify a default push path directly after a bzr get ?
<Lo-lan-do> push --remember?
<jelmer> mwhudson: ok - thanks
<mthaddon> is there a way to undo a bzr pull --overwrite? can I do bzr uncommit?
<asabil> Lo-lan-do: without doing a push
<jelmer> asabil: you can edit .bzr/branch/branch.conf
<jelmer> not sure if there's a way to do so via the command line
<asabil> hmmm ok
<mwhudson> jelmer: i can execute other commands if you want
<mwhudson> jelmer: just not right now :)
<sumdeus> I can't seem to find an answer to this and hope someone can point me in the right direction: I have two separate trees which have no common ancestry.  I would like to apply a patch from tree A to tree B. What is the best way to accomplish this?
<beuno> sumdeus, probably using "bzr bundle"
<beuno> checkout "bzr help bundle"
<beuno> *check out
<beuno> that would create a patch you can apply as revisions
<sumdeus> beuno, cheers, I shall have a look
<james_w> that wont work I'm afraid, as a bundle requires the base revision to be present.
<james_w> you can do diff + patch at best I think.
<james_w> ah no, you can use merge I belive if you specify a start revision.
<james_w> which you can do when merging from a bundle.
<beuno> oh, sumdeus, listen to james_w  :D
<james_w> however there will be conflicts if the two branches have files of the same names (filename conflicts, so bzr wont even try to merge contents).
<james_w> if that is the case then diff + patch might be the best way to go.
<james_w> mthaddon: if you know the revision id of where you were before you can pull --overwrite back to where you were.
<sumdeus> Hmm... what looks like it will work, since I'm using old school baz (1.x) is to do "baz delta --diffs > patch.patch" and then patch -p1 in the new tree.
<mthaddon> james_w, went with restore from backup - thx in any case
<sumdeus> of course after diffs put in the two trees
<sumdeus> Which is what james_w suggested, so perfect!
<james_w> mthaddon: no problem.
* keir is fishing for people to test his mutt+gmail+bzr send tutorial
<keir> see if you can get the following to work: http://bazaar-vcs.org/BzrSendWithGmail
<keir> anyone?
<keir> abentley, i still think alphabetizing is the right thing to do
<james_w> could you alphebetise in two sections, clients first, and then others second?
<keir> yeah, that's what i'm doing now
<keir> it's really unclear what the ordering means unless is specifically mention that it's clients then generic options
<keir> ok, i'm doing that
<corehosting> hello, stupid question: what is the name of the package (suse 10.1), if i want to use "bze get"?
<bwinton> bzr?
<corehosting> 0 result(s)
<BasicOSX> Anyone running osx+python2.5 and bzr? Any problems?
<bwinton> What's in your Development/Tools/Version Control directory?  (Assuming you have one.)
<james_w> corehosting: http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=bzr
<corehosting> ohhhh, coool
<corehosting> this looks good
<bwinton> Basic, I'm on OSX/Python 2.4/bzr 0.90.0 candidate 0, and haven't run into any problems yet.
<BasicOSX> wondering if the problem is python-2.5
<bwinton> Well, that's not entirely true.  The GTK extra stuff didn't work, because I haven't installed X-Windows, but I expected that to not work.
<BasicOSX> that is the tread related to my problem with bzr on osx http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/30469/focus=30555
<BasicOSX> bwinton: could I ask you to bzr get http://bazaar.eqenchanters.org/WoW/AddOns
<bwinton> Sure.
<BasicOSX> Also, is there a way to "check" the sanity of your remote repo?
<bwinton> Getting...
<james_w> bzr check http://... should work I guess.
<bwinton> Basic: Fetch phase 1/4...
<fullermd> It won't.
<BasicOSX> I have local access to the "remote" repo as well
<BasicOSX> on the local machine doing a bzr check /path/to/repo, seems to be working
<corehosting> no I tried "python setup.py install" (bzr-0.90.tar.gz)
<corehosting> >> ImportError: No module named distutils.core
<corehosting> whats my fault?
<bwinton> Basic:  You still there?  It finally finished with a "bzr: ERROR: [Errno 66]  Directory not empty"
<james_w> corehosting: you don't have distutils installed at a guess.
<dato> but distutils come with python itself
<keir> i don't understand the difference between merge-directive and send; do they both generate exactly the same output?
<corehosting> phyton 2.4.2 is installed
<james_w> keir: a merge-directive is what bzr send sends.
<james_w> the merge-directive command just creates a merge-directive. I think send -o is equal to merge-directive
<jelmer> corehosting: looks like it isn't included in the default python package on suse, maybe it's in python-dev or python-devel
<jelmer> corehosting: or perhaps you need to run 'python2.4 setup.py install'
<jelmer> (there may be an older version of python installed as well)
<corehosting> hello jelmer   *g*
<keir> james_w, ok. it's a bit weird because merge-directive has a --mail-to, which appears exactly the same as send
<james_w> keir: I don't know if Aaron made it the same as send now, but it used to work differently.
<dato> keir: merge-directive predates send. bundle and merge-directive have been combined into send.
<dato> keir: and anyway, I don't know if you noticed, but merge-directive is a *hidden* command
<keir> aaah, ok
<keir> great
<keir> i was about to suggest merge-directive should be deprecated
<corehosting> jelmer: python-dev installed, now install bzr runs
<corehosting> thanks @all
<BasicOSX> bwinton: interesting, same problem with python 2.5
<dato> how... strange/inconvinient/lame
<dato> (not having distutils installed with python)
<ubotu> New bug: #137335 in bzr "End configuration files with newline" [Undecided,New]  https://launchpad.net/bugs/137335
<bwinton> Basic: Well, at least you know it's not a 2.4/2.5 thing...
<asabil> hmm, anyone managed to use the bzr visual studio plugin ?
<BasicOSX> bwinton: yep, testing with windoze now as well
<corehosting> bye @all
<ubotu> New bug: #137348 in bzr "transport.ensure_base() fails for c: on windows" [Undecided,New]  https://launchpad.net/bugs/137348
<lifeless> moin
<james_w> morning lifeless
<keir> lifeless, morning
<keir> lifeless, i've been reading index.py
<keir> lifeless, so a 'key' is a tuple of bytestrings
<keir> and for a given index, the length of that tuple is fixed, but the bytestrings may have differing length, correct?
<lifeless> keir: right
<james_w> is there a way to find out the executability of a tree entry without using _iter_changes to locate it?
<lifeless> keir: if you browse to http://people.ubuntu.com/~robertc/baz2.0/.bzr/repository/indices/
<lifeless> keir: you can see a number of live indices
<lifeless> james_w: yes, there's an API on tree to query for that
<james_w> lifeless: I can't find it, any hints on the name?
<lifeless> **executab
<lifeless> *executab*
<james_w> _comparison_data
<lifeless> thats somewhat internal
<lifeless> but it will answer you
<lifeless> is_executable()
<keir> lifeless, these are only used for fast lookup, correct?
<keir> is hashing the keys insane?
<james_w> lifeless: I cannot find that for the life of me.
<james_w> ah, it's on working tree.
<lifeless> james_w: pydoc bzrlib.workingtree.WorkingTree
<james_w> that seems wrong to me. Is it a Windows thing?
<lifeless> thats the interface of working tree
<lifeless> james_w: windows support makes it more complex
<lifeless> keir: not necessarily, but you would want to detect collisions
<lifeless> keir: also
<lifeless> keir: you want to be able to iterate the keys
<lifeless> keir: iter_all_entries()
<keir> lifeless, yes, i see that
<lifeless> keir: so you can definately use hashing internally if that makes sense and you do it defensively and support the current public interface
<shirish> guys I'm a simple checkout guy, I have used svn before this, just like in svn is there a way to find info. about a copy one downloads
<keir> just brainstorming, i realize this may not work: first bit is a linear list of keys
<james_w> lifeless: it's on revisiontree as well, which I think should work for me. Thanks for the pointer.
<shirish> like one does svn info. something & it gives everything in nice order.
<keir> nothing else
<lifeless> shirish: 'bzr info'
<keir> lifeless, then second part is similar to current format, but with fixed-length md5's to refer
<james_w> shirish: there is bzr info, I'm not sure how the information compares though.
<shirish> lifeless: I did try bzr info, but it doesn't give me full info.
<keir> lifeless, depending on connectedness of the graphs, this could be faster/slower bigger/smaller
<lifeless> shirish: I think you need to be more precise about what you want to know about
<james_w> shirish: try info -v if you have a recent bzr.
<keir> shirsh, what information from svn are you looking for?
<lifeless> keir: wouldn't it cause considerable double-dereference latency, and nearly double the index size ?
<shirish> james_w: that bzr info -v is cooler than svn info
<shirish> keir: I was looking for revision nos. & stuff like that.
<keir> lifeless, i bet it would shrink it for most of the indexes i've looked at
<keir> lifeless, with a 128 bit hash, you're looking at 16 bytes per reference
<keir> lifeless, right now those keys are much longer than 16 chars
<shirish> guys, another issue, like svn up is there, there is also bzr up, what is the difference between the two, simple language please.
<keir> lifeless, and depending on the index size you may be able to get away with 64 bit hash if it's only one file
<keir> er smaller
<lifeless> keir: current references are about 7 bytes
<keir> lifeless, you are right about double deref
<lifeless> for a 4.5MB index
<keir> ah, right
<james_w> shirish: there is also bzr revno for that information quickly.
<shirish> james_w: thanx for the heads up
<james_w> shirish: as for bzr up I believe that it works in the same way on checkouts.
<lifeless> for a 200MB index - the largest I've seen, its 9 bytes
<james_w> shirish: but I can't remeber svn very well.
<lifeless> keir: I can see you are starting to think through things - this is great
<shirish> james_w: as far as bzr updates to whatever the latest on repository, its good
<shirish> btw can you guys have a look at http://paste.ubuntu-nl.org/36374/
<shirish> look at line 12, it says Branch is out of date: missing 1 revision.
<lifeless> shirish: if you used 'bzr checkout' to get the code, 'bzr update' will do what you want
<keir> lifeless, ok. so if we can't seek (only readv on transports) how is there any way we can do better than now?
<james_w> shirish: I think that means a bzr up is in order. I don't know though.
<lifeless> shirish: if you use 'bzr branch', then 'bzr pull' or 'bzr merge' is what you will want to respectively mirror and merge other peoples code
<lifeless> shirish: yes, you need to bzr up
<keir> lifeless, what was the usecase you mentioned before where it required reading 200mb of index but should only need 64k?
<lifeless> keir: sure, consider a 16-way B-tree for example
<shirish> lifeless: this is main, so no need of bzr pull, its needed only when one is taking stuff from branches.
<lifeless> with the node packing on disk having the root node at the front of the file
<keir> lifeless, i guess it depends on what you need to access
<shirish> guys, when I did bzr info -v how did it come to know I was missing one revision, does it do a compare between me & the remote repository to know the details?
<lifeless> shirish: if you are grabbing someting from a branch for your trunk you should never use pull only merge
<lifeless> shirish: yes
<lifeless> keir: well this is why it needs time and thought to do a great index layer
<shirish> lifeless: I'm not contributing anything to that project other than checking out the build, seeing what's new, seeing if it breaks while building & reporting if any issues happen.
<keir> lifeless, ok :) interesting stuff.
<lifeless> shirish: then just bzr up is fine for you
<keir> lifeless, 64k vs 200mb use case?
<lifeless> keir: righto - cosnider the mozilla full-history text index
<lifeless> keir: its a 200MB .tix
<shirish> lifeless: thanx, btw there is bzr 0.90 out but why isn't it on gutsy?
<lifeless> shirish: hasn't propogated yet
<lifeless> keir: .tix's are length-2 keys, with 2 key reference lists per node
<lifeless> keir: the way they are used is (fileid, revisionid) for the keys
<shirish> lifeless: 0.90 seems to be out more than few days right?
<lifeless> shirish: I presume thats rhetorical
* shirish goes to find out the meaning of rhetorical
<lifeless> its a question to which you know the answer already and are asking in order to make a point to the person you ask it
<lifeless> its rather annoying
<shirish> lifeless: I didn't know, honest
<james_w> shirish: 0.90 was released a week ago.
<keir> lifeless, ok, so they are (fileid, revid) -> (fileid1, revid1), (fileid2, revid2)
<lifeless> keir: more
<shirish> james_w: oh wow, so what's stopping it, any critical bugs or something?
<lifeless> key -> VALUE, [key_list1, key_list2] 
<shirish> james_w: I meant some major regressions or something new, which makes it unsuitable to release?
<lifeless> keir: key_list1 contains the per-file graph parents for key. Thats the graph that log FILENAME follows
<lifeless> keir: key_list2 is always either empty or has a single entry
<lifeless> keir: so []  - the text has not been delta compressed
<lifeless> keir: or [(fileid, revisionid)]  of the full text that the text has been delta compressed against
<james_w> shirish: I believe it is that gutsy has frozen, so the process takes a little longer.
<keir> lifeless, ok
<keir> lifeless, i'm going to think about this for a minute
<lifeless> ok, I'm ready to give you the use case now :)
<shirish> james_w: right, but can't something like bzr have a freeze exception, this is kinda stuff that all developers would be looking forward to. a better tool.
<james_w> shirish: I believe it might have a freeze exception, check launchpad. It doesn't mean that it goes in straight-away though.
<lifeless> keir: oh, and VALUE contains the byte offset and length in the .pack file of the record (whether it is full text or delta)
<lifeless> shirish: #ubuntu-motu please at this point. This is the upstream development channel.
<keir> lifeless, ok
<shirish> lifeless, cool :)
<lifeless> keir: now the use case is 'bzr cat http://mozilla.org/bzr/trunk/ChangeLog'. This will need to do a number of index operations, starting with looking up the text for the inventory, which I'm going to gloss over
<lifeless> keir: and once it has that it reads the inventory data to get the fileid and revision id of the text it wants to construct - the fileid of 'ChangeLog' and the revisionid of the lsat change made to it.
<lifeless> keir: so then we query the .tix and follow the compression-tree upwards:
<lifeless> nodes = [] 
<keir> aah, ok
<lifeless> node = list(index.iter_entries([(changelog-id, last-modified-revid)] ))[0] 
<lifeless> nodes.append(node)
<lifeless> while len(node[3] [1] ):
<lifeless>     node = list(index.iter_entries([node[3] [1] ] ))[0] 
<lifeless>     nodes.append(node)
<lifeless> # now nodes is a sorted list of compressed texts finishing with a fulltext
<lifeless> and then we use the values in the nodes to calculate a readv (perhaps across multiple .packs - so perhaps multiple readvs), to get the fulltext and each delta and apply them to get the content of ChangeLog
<keir> lifeless, i see. so it actually finds a series of diffs, then applys them
<lifeless> right
<lifeless> and thats using the second node-reference-list from the index
<lifeless> which is where we cache that information for cheap access
<keir> and what is in the packs?
<lifeless> the deltas and full texts
<lifeless> so
<keir> yes, i see
<lifeless> the mozilla .tix index, when its fully packed into a single pack, is 200MB
<lifeless> but the data we need to decide what to readv from that pack is probably < 10K
<lifeless> (say 200 bytes * 50 delta hunks in a run)
<lifeless> and on average < 5K
<keir> but if you know what parts to readv, don't you still have to linear scan from the start?
<keir> from what i see with readv, you'd still have to read 100mb if one of the hunks was 100mb down the pack file (not the tix)
<lifeless> keir: linear scan from the start of what ?
<keir> i am a bit confused about terminology
<lifeless> keir: readv only transfers the byte ranges asked for over the wire
<keir> "the mozilla .tix index, when its fully packed into a single pack, is 200MB" <- are .tix files pack files? i thought packs were separate
<lifeless> you supply a vector of (offset, length) pairs and you get back an iterator of (offset, bytes)
<lifeless> keir: have a look at http://people.ubuntu.com/~robertc/baz2.0/repository
<keir> lifeless, aah, right. i didn't read the readv manpage enough :)
<lifeless> keir: the pack-names file there lists the packs
<lifeless> keir: for each pack there are 4 indices: .six, .tix, .iix, .rix
<lifeless> thats for signatures, texts, inventories and revisions
<lifeless> each commit adds a single pack.
<yml> Hello,
<keir> lifeless, and 4 new indicies, ok.
<lifeless> every l0 commits 10 single-commit packs are combined to 1 10-commit pack
<lifeless> every 100 commits 10 10-commit packs are combined to 1 100-commit pack
<lifeless> and so on
<keir> ok
<lifeless> and 4 new indices are written every time a new pack is added, and the indices are removed when the pack is
<yml> bzr is dumping some very strange lines each time I run a command on the computer hosted by my provider.
<lifeless> so for a given repository the 'text index' is the combination of all the .tix indices for all the packs listed in pack-names
<lifeless> I think the CombinedGraphIndex is probably about right at the moment (but am completely open to being wrong on that).
<lifeless> yml: pastebin or something please
<yml> Here it is an example: http://dpaste.com/18596/
<yml> goodevning lifeless
<keir> lifeless, thanks for the explanation. i am going to digest this a bit more
<lifeless> yml: look in ~/.bzr.log
<lifeless> yml: you are getting an IO error of some sort
<yml> should I pastebin also?
<lifeless> the NotImplementedError is strange
<lifeless> keir: no probs
<yml> here it is: http://dpaste.com/18597/
<lifeless> keir: but can you see now - there is a 200MB .tix, but we only want a tiny fraction of the total data
<keir> lifeless, yes
<keir> lifeless, we only want to extract the relevant ranges in the packs
<lifeless> yml: file a bug please with that 18597 paste
<lifeless> keir: yes, the goal of the index is to tell us what bytes in the packs are interesting for various use cases
<yml> I will do this . what should be the title?
<lifeless> yml: make one up
<yml> ok thank you lifeless
<lifeless> ok, deep hack time
#bzr 2007-09-05
<ubotu> New bug: #137387 in bzr "Strange error message decorating the output of bzr status" [Undecided,New]  https://launchpad.net/bugs/137387
<keir> lifeless: sorry to interrupt your deep hacking. it seems all that's stored in the index layer (the values) are integers. do we actually want to store arbitrary strings?
<lifeless> keir: there is a layering concern here
<lifeless> right now there is a boolean and two ints stored in the product values
<keir> lifeless, i see
<lifeless> I would be ok with making them into structured data rather than strings if there is a tangible win; otoh it makes the index less able to be reused - e.g. the pack-names index will need to be different
<keir> lifeless,  i am just wondering, because it is potentially useful if there is a fixed-size-data case
<lifeless> (it currently stores 4 ints)
<keir> in my attempts to compress data structures, i've been known to reuse the lower bits of pointer addresses to store booleans :)
<keir> my other question: are most uses repeated traversals?
<keir> and why is it in the code you posted above, that it only traverses the first one?
<lifeless> our knit deltas are deltas against one parent
<lifeless> there are two parent-lists per node in the .tix
<lifeless> one parent-list is the per-file graph, which is unrelated to compression
<lifeless> the other parent-list is for the compression code
<keir> what does tix stand for?
<lifeless> and the compression code forms a tree, not a graph, so there is only ever 0 or 1 nodes
<lifeless> 'text index'
<keir> ok
<lifeless> I don't know what the most common traversal is
<keir> so there is an index for the compression code?
<lifeless> or most common query pattern I should say
<lifeless> for .rix its probably breadth first repeated queries on the first node-reference list
<lifeless> for .iix it will probably be compression-sequence lookups - repeated queries following the compression parent
<lifeless> for .six it will simply be large set queries for (all revisions being pulled at once)
<Odd_Bloke> I'm trying to modify my bundle for bug #52479 to work on local branches as well as remote ones.  However, I'm struggling to find a way of working out where an unbound branch is committing to (with a bound branch I just use Branch.get_bound_location()).  What's the best way to do this?
<ubotu> Launchpad bug 52479 in bzr "Message at the end of commit for bound branches" [Wishlist,In progress]  https://launchpad.net/bugs/52479
<lifeless> for .tix it could be compression-sequence lookups, or it might be file-graph searches
<lifeless> Odd_Bloke: branch.base ?
<keir> aaaag! i just hit ctrl-L and logging is off in my xchat
<keir> does someone have a log of the last few hours?
<lifeless> Odd_Bloke: in commit it should simply be 'committed to %s' % master_branch.base
<lifeless> Odd_Bloke: you shouldn't need to make any calls about bound branches
* keir stomps on xchat for not having logging on by default.
<lifeless> keir: there is one on the web I believe
<keir> no one else has logging on?
<keir> i was going to paste our chats into my notes and tidy it up
<lifeless> keir: there is not a separate index for compression; the compression code uses the second node-reference list to form the compression-tree
<Odd_Bloke> lifeless: Yeah, my one year of CompSci Java had me only looking at methods. :/  I'll modify it as such.
<lifeless> keir: its layering - the index layer is agnostic for the exact use its put to, which has allowed me to use it about 3 different ways so far
<keir> lifeless, i don't know what a compression-tree is
<keir> lifeless, yes, i understand.
<keir> lifeless, however i think it is reasonable to add a 'my values are 8 bytes' flag to the graph builder
<lifeless> keir: I don't know how to describe it differently. I've tried twice
<lifeless> We store a given byte-sequence as either a full copy or as a line based deltas against another byte sequence
<keir> lifeless, ok, so that is a compression tree. i understood that, just not that it was named 'compression tree'
<lifeless> well we don't have a ideal name for it
<lifeless> its not a graph
<lifeless> though a graph can store it
<lifeless> which is how I fit it into the GraphIndex structure
<keir> and i imagine the compression tree, in typical use cases, has a very low branching factor
<lifeless> given that the index builder only has to output data when the index has all its entries added to it, I don't see why you add a flag telling it how long the values are: you can determine that by inspection during finish()
<lifeless> keir: the compression tree for inventory is about 4 for every one
<lifeless> erm
<lifeless> thats wrong,t ahts the ratio of non-mainline to mainline
<lifeless> best thing to do is to query it yourself and see for a live repository :)
<keir> true!
<lifeless> you could report on this for inventories and texts - .iix and .tix
<lifeless> now
<lifeless> byte-sequence reconstruction is performance critical for many operations
<keir> what does that mean?
<keir> byte-sequence reconstruction
<lifeless> I've been referring to 'texts' in an ambiguous way
<lifeless> texts can mean 'something in the .tix index' or it can mean 'any sequence of bytes we have stored in the repostiory' which is a superset of the first meaning
<lifeless> so I'm disambiguating now to be clear
<keir> ok
<lifeless> reconstructing things like the contents of an inventory or the contents of a given file version is a common operation
<lifeless> and when its slow it multiplies in effect
<lifeless> 'bzr checkout mozilla' for instance constructs 55K byte sequences which are delta compressed
<keir> ah! so i imagine that's slow
<lifeless> so that will be following the compression tree for 55K texts in the .tix and 1 inventory from the .iix
<keir> but ideally, there is a pack with a fulltext only a few deltas behind, correct?
<lifeless> so for .tix and .iix getting the nodes from the compression tree for a single node is a very common operation
<lifeless> well fulltexts are put in when the deltas add to about the size of the full text
<lifeless> so a big text gets more fulltexts between deltas than a small text
<lifeless> erm switch the words there
<keir> yes, i understand.
<lifeless> ok
<keir> is it often that many files are queried?
<lifeless> lets see
<keir> for one of my projects, astrometry.net, we use some very clever branch-and-bound algorithms to compare two trees; one is our index, and one is constructed at query time
<lifeless> branch and checkout will queries size-of-tree nodes for the compression graph
<lifeless> merge will query size-of-difference * two
<keir> so in  those cases it may be possible to do better than N * (index lookup)
<lifeless> pull does a merge under the hood
<keir> so the only time branch is not equivalent to cp -R is when there's a shared repo, and you are only branching one of the branches?
<lifeless> same with update
<lifeless> branch is never equivalent to cp -R
<keir> ok. i fail to see why
<lifeless> if there is no shared repo we do a clone, which spiders all the data and verifies
<keir> in cases where it's not a shared repo
<keir> so just cp -R + md5check
<lifeless> you as a user can do that
<lifeless> we dont
<lifeless> you might be mounting sftp over fuse for instance
<keir> ok. just because of portability?
<lifeless> being on a file:// url doesn't guarantee data integrity
<lifeless> you might have a lot of unreferenced data
<keir> ok, right. my question is more one of what is the fundamental operation, and in non-shared branching, it is just copying raw bytes.
<lifeless> and we don't copy that - if you make a new branch it only contains the data referenced
<lifeless> ok
<lifeless> to make a new branch we:
<keir> exactly, which is why it is not the case for shared repos, because you only branch one of the severa branches, and the shared repo contains all revs
<lifeless>  - ensure there is a repository that can be used at the branch. In the shared repo case we find that up the containing directories. In the non shared repo case we create it.
<lifeless>  - we perform a data fetch from the source branch's repository for the revisions referenced by the branch
<lifeless>  - we create a working tree of the tip of the branch
<lifeless> for a shared repository the fetch operation fast-paths and just asserts that the data requested is in fact present
<keir> ok
<lifeless> If you have more questions ping; I suggest getting some of the live indices and exmaining them playing with them etc, perhaps instrument to record the sequence of calls or something then use bzrlib and see what's asked for
<keir> yeah
<keir> where can i get a big pile of live indicies?
<lifeless> my repo that I have pointed you at
<keir> ok
<keir> those are all the uses for the index right now?
<lifeless> or follow my dogfooding instructions from the list
<lifeless> and make your own pack based repo
<lifeless> yes, they are all the uses
<lifeless> course, we aren't finished
<lifeless> so as a client let me be clear - the scope is-a-changing :)
<lifeless> (but not much I hope)
<lifeless> poolie: still on the phone ?
<poolie> now serving #72
<keir> lifeless: can we exploit that most of the keys have large common prefixes?
<keir> because of what we are storing, a radix tree for the keys might not be crazy
<ddaa> poolie: got a patch for you
<abentley> The form of the keys is not guaranteed.  imports from git, for example, may have revision ids of "git:%(hash)s".
<ddaa> http://paste.ubuntu-nl.org/36388/
<keir> also, i'm not sold that we want multiple adjacency lists for each node; why not use multiple graphs, with a seperate key/value index?
<keir> abentley, ok.
<ddaa> Make bzrlib.tests.TestCase use super() in setUp and tearDown, and fix a small typo that fucks up emacs syntax highlighting.
<ddaa> poolie: poolie need anything else for this patch? It's fairly trivial.
<ddaa> (the super stuff is needed now for some Launchpad test case)
<abentley> keir: Gnu Arch imports have a common prefix.  bzr-svn 3 does.  Dunno about bzr-svn 4.
<keir> what's a reasonable size for a preamble?
<keir> i figure there's going to be no way to avoid reading at least a few hundred bytes from the start of each index
<abentley> I think lifeless has been talking about reading 64K at a time.
<keir> it seems to me that you can shrink down the size of the index if you separate the key/value part from the key->(key)* part
<abentley> (for remote access, that is)
<keir> yes, of course
<abentley> So you would want that 64K to include the preamble and a sizeable number of recent keys.
<poolie> ddaa, did you post it to the list?
<ddaa> ahem
<ddaa> no
<ddaa> I do not plan to
<ddaa> I do not have time to read the bzr list really.
<ddaa> spiv is looking at it now
<poolie> hrm
<ddaa> I'll have him get through the hoops.
<spiv> ddaa: hmm.
<keir> hmm, so after a pull, locally an index gets built from the data that got pulled? (for pack repos anyway)
<spiv> ddaa: the problem is it's an incompatible API change.  Other people might have subclasses with multiple-inheritance involving bzrlib.tests.TestCase already.
* spiv thinks
<ddaa> if they do, then they're bust
<spiv> ddaa: not at all
<ddaa> because all the other test classes that derive from TestCase use super() already
<lifeless> keir: thats a possibility, consider benchmarking on live data
<ddaa> As far as I can tell, there is no way to look at it and not see it as a bug, because TestCase clearly is the one breaking the rules.
<spiv> Well, bzrlib doesn't multiply inherit from TestCase via different routes.
<lifeless> keir: you can use my dgofooding insutrctyions to convert repos like thepython import on launchpad to packs
<poolie> ddaa, posting a patch to the list does not require that you read everything on the list
<lifeless> ddaa: python's TestCase doesn't use super FWIW
<poolie> it's enough to just say 'please cc me on replies', or pick out that one thread from the list
<abentley> ddaa: There are at least a few places we use MI in the test suite: the bundle tests and the versionedfile tests come to mind.
<ddaa> lifeless: if that's a problem, then all the classes that derive from bzrlib.tests.TestCase should be changed not to use super()
<keir> lifeless, ok. it seems reasonable that there may be multiple indexes with the same keyspace, and possibly differerent or same data
<lifeless> ddaa: is this impacking you in some way ?
<poolie> what specific problem does it cause?
<spiv> ddaa: what lifeless said.  Using super in bzrlib.tests.TestCase isn't going to solve all uses of inheriting from two different unittest.TestCase classes.
<ddaa> lifeless: yes, I want to MI from a TestCaseWithTransport and one existing test class in the Launchpad test suite that derives from unittest.TestCase.
<thumper> ddaa: best to state what you actually want it to do and why it doesn't currently work
* lifeless bows out there are enough eyeballs on this
<lifeless> -->commit performance
<spiv> ddaa: I don't think that can work reliably, sadly.
<spiv> ddaa: because you have diamond inheritance
<poolie> i wish i'd inherited diamonds :)
<spiv> ddaa: but part of the inheritance graph is unittest.TestCase, which doesn't use super.
<ddaa> spiv: it is not a problem because there is no diamond above unittest.TestCase
<spiv> I *think* the fact that unittest.TestCase is the notional common root might be enough to make it work with current Python.
<keir> lifeless, actually, i have a crazy idea. what about having a mapping var length keys -> fixed size id's. then we can support key tuples as (id1, id2) rather than the full string
<spiv> But they've changed the MRO before and could easily do it again.
<spiv> In general though, I think inheriting from multiple TestCases isn't a good thing to do.
<keir> lifeless, then we get to have 1 place that lists all the file id's and one place that lists the rev id's
<ddaa> spiv: I find it unlikely that a MRO change would affect a simple case like this one.
<spiv> Because you'
<lifeless> keir: thats roughly what the current index does, the fixed size ids are byte offsets in this case
<lifeless> keir: so its a reasonable thing to do
<spiv> re likely to get difficult interactions even without super.
<ddaa> spiv: okay, I give up on this patch and just somehow refactor my code.
<keir> lifeless, ok. it looks like the file id's and rev id's are used in multiple idx's; so this would be a big win on large indexes
<poolie> ddaa, i'd suggest instead
<ddaa> I see too much reviewer argument ahead.
<poolie> well, to back up
<poolie> you need some bzr-related setup and some lp-related setup done for a single test?
<ryanakca> for bzr commit, it's 'bzr commit -m "commit message" --fixes:lp:bugnumber' ?
<ddaa> poolie: in a nutshell, yess
<poolie> i'd be inclined to do it by
<poolie> refactoring the parent classes so that all the setup methods are individually callable
<poolie> which should generally be the case already for bzr
<poolie> then having your setUp just do what it wants
<poolie> i think relying on super to do all this is confusing/problematic
<ddaa> yes, that what I meant by "refactor my code"
<poolie> spiv, do you agree
<ddaa> I it just mildly disappointing because MI would have been the natural way to do it IMO.
<spiv> Yes, I think that would probably work.
<spiv> A hackish way to do that is simply:
<spiv> def setUp(self): self.borrowedTest = OtherTestCase('foo'); self.borrowedTest.setUp()
<keir> hah, i am redesigning berkely db
<ddaa> poolie: BTW, you probably want to clean out the uses of super() in setup() and tearDown() methods of bzrlib.tests.TestCase descendants then.
<poolie> :)
<spiv> Which doesn't save you from conflicts in the setup (e.g. if both tests want to tweak global state like logging, os.environ, or the cwd).
<spiv> But that would be a problem with MI anyway.
<ddaa> poolie: either use it everywhere, or use it nowhere. The current situation is just a problem waiting to happen IMO.
<spiv> Also, you don't get easy access to custom assertion methods on the OtherTestCase.
<ddaa> spiv: which would be an annoyance in this case.
<poolie> google says "authentic python handbag" :)
<poolie> ddaa, if you want to remove them in fixing this that's ok with me,
<poolie> or file a bug
<poolie> ddaa, please use the regular review mechanism if you want bazaar changes
<lifeless> keir: bdb doesn't have graph awareness; thats a key part of this index logic
<poolie> and we will try to make it work efficiently for you
<ddaa> poolie: ack
<lifeless> ryanakca: what are you asking ? have you read the help?
<poolie> if you try it and you think it is eg taking too much time, raise that with one of us or on a company list
<keir> lifeless, i know :)
<ryanakca> lifeless:   --fixes=ARG           mark a bug as being fixed by this revision.
<ryanakca> lifeless: ARG being something. Anyways, I don't need to anymore, since the Ubuntu upload closed them
<keir> do we want indexes to scale > 4gb?
<keir> or  rather, is it reasonable to expect to be able to fit the entire index in memory? or should i design assuming you can't do that
<lifeless> ryanakca: at the end of 'bzr help commit'
<lifeless> See also: bugs, uncommit
<lifeless> ryanakca: so 'bzr help bugs'
<ryanakca> lifeless: thanks
<abentley> lifeless: shall I merge Watkins' patch without test case refactorings?
<ubotu> New bug: #137407 in bzr "messy error if BZR_HOME does not exist" [Low,Triaged]  https://launchpad.net/bugs/137407
<poolie> we seem to have a lot of reviews bounced recently
<poolie>  because of disagreements about indenting
<poolie> but there is no clear statement in either hacking or pep8 about just what is allowed
<lifeless> abentley: sure, that was speculation or I wouldn't have done bb:approve
<igc> morning
<abentley> poolie: clearly, the reviewer gets to choose the indenting style >:-)
<poolie> ok, that works :)
<abentley> Well, I'm not sure about double-indenting when doing line-wrapping.  Because you're already down to 67 characters if you're in a method body, 63 if you're in a try block, 59 if there's a loop inside the try block.
<keir> lifeless, what is the 'absent' field used for?
<ubotu> New bug: #137412 in bzr "Code duplication in tests.blackbox.test_commit" [Undecided,New]  https://launchpad.net/bugs/137412
<lifeless> keir: it records keys which are not in the index but are referred to by a key reference
<lifeless> I don't line 8-indents on line wraps
<poolie> here are the possibilities as i see them:
<poolie> a- indent under the delimiter (opening brace or whatever)
<poolie> b- indent 4 spaces
<poolie> c- indent 8 spaces
<keir> lifeless, hmm, what is it used for? in the next layer up?
<poolie> d- indent 0 spaces
<abentley> I would prefer a where practical, otherwise b.
<poolie> a is nice
<poolie> a bit more laborious to maintain
<poolie> well, for non-emacs users
<jml> :)
<lifeless> keir: no, consider an index with one entry and one key-reference list:  ('key1',), 'value', [('anotherkey',)] 
<lifeless> keir: iter_all_entries() needs to yield ('key1',), 'value', [('anotherkey',)] 
<lifeless> keir: iter_entries([('anotherkey',)] ) needs to yield nothing
<lifeless> anotherkey is not present in the index
<lifeless> it is absent
<keir> ok
<lifeless> have a look at the serialisation tests
<keir> but aren't keys listed by their position in the file?
<lifeless> have a look at the serialisation tests
<poolie> lifeless, how about allowing a/b?
<poolie>  spiv ^^
<lifeless> c?
<lifeless> poolie: we currentl use a or b as people feel comfortable
<poolie> i thought you didn't like c?
<lifeless> I don't like c
<poolie> i sometimes use c as that's what vim seems to like
<poolie> i am happy to change though
<lifeless> vim is on crack
<keir> vim rocks!
<poolie> i just want it settled rather than being rehashed in every review
<lifeless> sure
<poolie> it is probably configurable in vim
<lifeless> can I ring to bounce an idea
<abentley> lifeless, keir: Maybe you can compromise: vim is on crack rocks!
<poolie> lol
<keir> abentley, heh
<abentley> keir: I speak as a vim user.
<keir> ok, i just came up with a nice unified way of storing these graphindexes, and i realize it just bakes down to the same thing as a berkely db
<spiv> I use a or b.
<keir> how does knowing we're storing a graph help again?
<keir> i mean, i can make the format amenable to readv() wire access, but it's still just storing k,v pairs
<lifeless> keir: you can group data topologically
<lifeless> keir: you can reduce latency by adding apis for common graph/tree walking operations where the index layer is able to predict and readahead in the graph order
<lifeless> and you can dictionary compress key references because we have 'k,v,r' rather than 'k,v' where the key references would be opaque
<keir> alright. time for graphviz
<abentley> keir: I don't know if you'll find it useful, but bzrtools includes "graph-ancestry", which uses dot.
<keir> abentley, ok, thanks
<lifeless> -> poolie
* igc food
<poolie_> jml_, hi?
<AfC> Weird. Someone submits a branch to us, including about new 50 files making up something that we decide not to accept (and so revert|delete). We work further on the branch, then merge it to 'mainline'. We then push to the public repo, and bzr does the endless-small-round-trips thing.
<AfC> After thinking about it, I realized that it must be creating new knit files server side for each of those files, because they were in revisions that are in the branch even though the files involved were subsequently deleted.
<poolie_> yes, because it's still carrying the history for those files
<ubotu> New bug: #137449 in bzr "status performance regression compared to 0.17" [Undecided,New]  https://launchpad.net/bugs/137449
* igc food
<dato> uhm, bzr upgrade is not supported over bzr+ssh?
<dato> % b upgrade --dirstate-tags bzr+ssh://bzr.debian.org/bzr/pkg-python-debian/trunk
<dato> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<dato> % b upgrade --dirstate-tags sftp://bzr.debian.org/bzr/pkg-python-debian/trunk
<dato> ... finished
<mwhudson> https://bugs.launchpad.net/bzr/+bug/125166
<ubotu> Launchpad bug 125166 in bzr "Smart server doesn't suppport upgrading" [Low,Confirmed] 
<pygi> morning
<mwhudson> with no knowledge at all, it seems like it should be fairly easy to fix...
<dato> mwhudson: ah, thanks.
<lifeless> dato: thats right
<rschuster> hi bzr-folks
<rschuster> i am trying to implement a bzr-fetcher for OpenEmbedded and need your help
<rschuster> how can I find out the latest revision number of a certain (remote) branch?
<rschuster> something like 'svn info <remote-url>' which will contain the line: "Revision: 8404" (for example)
<dato> rschuster: as a command (that is, not using the Python API): bzr revno http://...
<rschuster> dato: thanks alot thats it!
<dato> rschuster: you're welcome
<abentley> rschuster, note that the revision number is not the most accurate indicator of whether a branch has changed.
<dato> he left already.
<igc> night all
* Starting logfile irclogs/bzr.log
<asabil> anyone knows how to make the visual studio integration working ?
<Ng> hey folks. If I push a bzr tree to an sftp:// I obviously just get a .bzr directory there. What magic can I do on the remote end to make it generate the working files too (not automatically, just manually is fine)
<mwhudson> Ng: 'bzr update'
<Ng> mwhudson: that's what I thought, but it said "No WorkingTree exists for file:///blah/branch/.bzr/checkout/."
<Ng> (fwiw, the local bzr is 0.18 and the remote is 0.17)
<mwhudson> oh
<mwhudson> 'bzr co'
<Ng> spot on, thanks :)
<jelmer> Lo-lan-do: The non-lhs push issue has been fixed in the 0.4 branch of bzr-svn
<Lo-lan-do> jelmer: Excellent, thanks.
<keir> how difficult would it be to implement git-style branch switching?
<keir> so that you only have 1 working tree, which you can switch between branches with a bzr command
<jelmer> keir: that should be possible to implement using a plugin
<keir> wow, really!
<jelmer> and wouldn't be too hard I think
<keir> ok, that is high on my list after writing a new index layer
<keir> i definitely prefer git's way of working regarding branches
<Lo-lan-do> There's already a bzr switch command...
<jelmer> bzr switch takes a to_location though
<keir> is in not in the main bzr?
<jelmer> no, it's in bzrtools
<keir> bzr help commands | grep switch -> empty
<keir> aah, ok
<jelmer> you'd want it to take a tag I guess
<keir> no, a branch name
<jelmer> right, so you'd want to write a plugin that:
<jelmer> keeps a list of branch names in a file somewhere under .bzr/
<jelmer> the file would simply contain a dictionary with "branch name -> revid" mappings
<keir> how is a branch represented in a shared repo now?
<jelmer> and the plugin would have a ocmmand to list the branches, one to add a branch to the file and one to change the active branch
<jelmer> keir: there's a .bzr/branch/last-revision file that contains the tip of the branch
<jelmer> that's all there is to a branch
<keir> ok
<dato> or a .bzr/branch/revision-history for v5 branches
<keir> so in a shared repo, it's .bzr/branch_name_here/revision-history?
<jelmer> keir: you can simply call Branch.set_last_revision(revid) to change the tip of a branch
<luks> keir: no, in the branch's .bzr dir
<keir> aah, ok
<luks> repository doesn't know about it's branches
<keir> right, i understand
<keir> so i'd basically have to make a new branch format
<keir> and by format, i mean placement of branches
<jelmer> no, you should be able to use the current branch format
<jelmer> the only bit of data that is missing atm is the list of branches
<jelmer> the active branch can still be in .bzr/branch
<Herodes> I get this :
<Herodes> "working tree is out of date, run 'bzr update'
<Herodes> bzr: ERROR: exceptions.AssertionError: 257 != 1"
<Herodes> how can I fix it ?
<Herodes> it is a new branch that I have ,...
<Herodes> and I am merging a branch with 257 revisions,..
<Herodes> so I suppose I need to push up the revision I have to 257...
<james_w> keir: my plugin does stuff like that, so I can give you pointers as well when you do it if you like.
<Herodes> I found the problem..
<Herodes> I was using the "bzr merge", where I needed to use "bzr branch". Sorry for spaming..
<relix> Heya
<relix> I'm trying to version my whole /home directory
<relix> so I was in my home dir, and used "bzr init"
<relix> then I tried "bzr add" and after changing a couple of filenames that made it crash, it said "(amount) files ignored. Add them by name to version them"
<relix> I can't go over these thousands of files to add them "by name"
<relix> how can I add them?
<relix> I tried bzr add *; bzr add /david/home/; bzr add ./; bzr add;
<relix> none works
<james_w> what files are they? dot files? (bzr ignored would tell you)
<yml> hello
<yml> good evening
<relix> ah thanks james_w
<relix> apparantly one of my ignored settings filters a couple of thousand files
<relix> so it's entirely my fault and I feel pretty dumb now having wasted your time :s
<james_w> relix: no problem.
<yml> what is the easiest way to remove some of the revisions of a project hosted on launchpad?
<yml> if this is not possible. how can I delete a branch?
<james_w> yml: remove completely, or just rewind a branch?
<yml> remove
<james_w> you have to delete the branch. However if launchpad use shared repositories even doing that might not get rid of it completely.
<yml> or remove all the revision below revno60
<yml> I mean remove the revision  from 1..59
<yml> or is it possible to create a branch from an exiting repository for all the revno>60 and the this new branch to do bzr push --overwrite
<Peng> relix: I don't recommend doing that in bzr, if you're going to include dot directories like .opera. I did, and committing got really slow after a few months. OTOH, the bzr guys are working on improving that, so maybe it won't be so bad in the future.
<mwhudson> yml: i don't think you can do what you suggest even locally can you?
<yml> mwhudson  : I don't know I am trying many combination but so far I have not found anything that do what I would like to do.
<mwhudson> bzr pretty firmly assumes that if you have revision X you have all of revision X's parents
<yml> I would like to dump the last 2 revsion and build a new rep with this.
<mwhudson> you can drop the latest two revisions with 'bzr uncommit' (twice) and then push --overwrite
<yml> Ideally I would also like to delete branch on launchpad or at least remove all the content
<mwhudson> you can use lftp to rm -rf the .bzr in your branch
<mwhudson> (via sftp)
<yml> mwhudson  I want to do the oposite keep ONLY the latest 2 revision
<mwhudson> yml: that's not what you said :)
<mwhudson> yml: and you can't do that
<yml> that is clear  :-)
<yml> sftp> rm -rf .bzrCouldn't stat remote file: No such file or directoryRemoving /~yml-nospam/django-survey/main-yui/-rfCouldn't delete file: No such file or directory
<mwhudson> *lftp*
<yml> mwhudson  : unfortunatly I am not able to do this
<yml> I am sorry what is lftp?
<mwhudson> the default sftp client is surprisingly horrible
<mwhudson> http://lftp.yar.ru/
<Peng> lftp isn't that great, either. No globbing. :(
<mwhudson> actuall
<mwhudson> y
<mwhudson> bzr uncommit -r 0 --force; bzr push --overwrite
<mwhudson> may be sufficient
<yml> mwhudson so back to my original question bzr branch --revision=last:2 my path
<yml> keep only the history of the file of the last 2 revisions
<yml> even if when I do bzr log I can retrieve the complete history?
<yml> that mya sound strange on this channel I want to destroy all the information in the revisions 1..59
<mwhudson> you can probably create a new branch that has the same content
<mwhudson> but they won't be connected in the revision graph
<yml> This is fine
<brmassa> guys, i did some changes on my working tree but i changed my mind. how can i reset it and restore my last revision?
<Lo-lan-do> bzr revert?
<brmassa> thanks
<yml> mwhudson slap my forehead,your solution of creating a new rep seems to work
<yml> I wait that launchpad refresh its history
<luks> "bzr uncommit -r 0 --force; bzr push --overwrite" will not actually remove the data from launchpad
<relix> peng yeah I'm getting memory errors right now :(
<relix> I ignored .opera's cache4 directory though so it shouldn't be much of a problem
<yml> luks  : GRRRR!!! I was happy that bzr didn't raise any error message :-)
<yml> too easy
<luks> it will remove the branch, but the repository with all the data is still there
<yml> How can I remove the content of a branch?
<luks> use a sftp client that remove remove directories recursively and remove the .bzr directory
<luks> er, that can remove
<yml> I have an error message when I try to do that
<luks> the 'sftp' client can't do that
<yml> sftp> rm -rf .bzrCouldn't stat remote file: No such file or directoryRemoving /~yml-nospam/django-survey/main-yui/-rfCouldn't delete file: No such file or directory
<yml> luks I do not understand? can I do that with sftp or not?
<luks> yml: "<mwhudson> you can use lftp to rm -rf the .bzr in your branch"
<yml> I try lftp a couple of minute ago
<yml> lftp yml-nospam@bazaar.launchpad.net:~> ls`ls' at 0 [Connecting...] 
<yml> and for the last 5 minutes it is displaying this error message
<yml> Interesting it seems that my history is gone thanks to
<yml> http://codebrowse.launchpad.net/~yml-nospam/django-survey/main-yui/changes
<yml> bzr uncommit -r 0 --force; bzr push --overwrite
<yml> is that possible?
<Peng> relix: Ignore opcache/, opthumb.dat, thumbnails/ and widgets/*/ too.
<yml> I had 62revisions before
<jelmer> well, the data is not easily accessible, but it's still there
<relix> good idea Peng
<relix> had thumbnails ignored already
<relix> but it's crashing on something different: the .incomplete dir of dc++
<Peng> relix: I dunno anything about that. Large files or anything?
<relix> yeah possibly
<Peng> relix: It'll have to hold entire files in RAM occasionally.
<Peng> s/have to// ;)
<yml> jelmer: does that mean that people without a write access to this rep cannot see them
<relix> ah, righ
<jelmer> yml: no, they will be able to access it if they try very hard
<jelmer> wel, not *very* hard perhaps, but it's not trivial to access
<yml> Is there a way to get anything better
<yml> I mean more radical
<yml> :-)
<jelmer> yml: yes, remove the entire .bzr directory
<yml> could you guide me to do this ?
<jelmer> yml: but I'm not entirely sure how to do that on launchpad, maybe the folks in #launchpad can better tell you
<yml> 2 peoples mention lftp
<jelmer> "rm -rf .bzr" will work if it's on a local system
<yml> but I do not manage to get that far
<yml> ok jelmer
<yml>  I am going to ask on #launchpad
<yml> Thank you very much all
<brmassa> guys, i have a project on my pc and also on launchpad.net. how can i have the same branch on my office pc? if i merge with my launchpad, all revisions becomes one.
<jelmer> brmassa: you'd want 'bzr branch <launchpad-url>'
<brmassa> and for the second time, when i have a branch already? can i do it again?
<Lo-lan-do> How about a checkout?
<brmassa> hmmm really really
<dato> brmassa: bzr pull
<brmassa> im gonna check both.
<brmassa> the windows version available on site has the python lib for criptography?
<brmassa> parakiko or something...?
<beuno> who can help me fin out why I'm getting this error on a 500mb branch?   bzr: ERROR: exceptions.MemoryError:
<beuno> I'm branching it through sftp
<brmassa> 500mb? jezz!
<jelmer> beuno: please sent an email to the list
<jelmer> beuno: that should work, but the people most likely to be able to help aren't here atm
<beuno> jelmer, will do, thanks
<lifeless> abentley: yo
<james_w> dato: are you around?
<dato> james_w, yes
<james_w> hi.
<james_w> I'm working on the bug with builddeb where it fails when the tarball contains multiple files in the root. #440069. Do you remember it?
<dato> yes
<james_w> you said that dpkg-source supports it by unpacking to a temporary directory.
<dato> I believe it does that
<james_w> I already do that, but I need to source directory to copy the debian/ in to.
<brmassa> lifeless... will 0.90 be on gutsy repository?
<james_w> so I currently rename the contents of the extracted tarball to the package-version that I want, assuming there is one entry and it is a directory.
<james_w> do you think checking for a single directory and erroring if there is more that one is a good approach, or will I find even wierder tarballs out there?
<dato> the thing is you unpack in a temporary directory. if there's only one item, you move it out of the temp directory, into the name you want. if there's more than one, you rename the *temporary directory* to the name you want.
<dato> if you are *building* in a temporary directory, then you need two temporary directories, one under the another
<dato> toplevel for building, other one for the unpack steop
<james_w> ah, rename the tempdir. Thanks, I'll no that.
<dato> right, np
<dato> james_w: I have an unpack-in-subdir script that does that, here it is: http://rafb.net/p/GhPw3485.html
<dato> but it's pretty much straightforward
<dato> though now I notice, that does not do renaming, but other stuff, dunno why
<james_w> dato: you rock. thanks.
<lifeless> abentley: ping
<dato> james_w: you're welcome :)
<NfNitLoop> Anyone here have experience with svk and bzr-svn?   I'm looking for a comparison.
<NfNitLoop> I've got a svn repo here in the states and developers down in Argentina.   The poor connection between here and there is becoming a headache.
<arjenAU> NfNitLoop: well svk is not quite a distributed system. it's a distributed trick bolted onto a very centralised system. if you can choose, I'd go for the pure design, bzr or hg
<arjenAU> NfNitLoop: using the svn plugin for bzr does not quite make it distributed either, but it's a good way to migrate to bzr.
<NfNitLoop> Well, it was a giant pain to get them to switch to svn.  I don't see us migrating away from it any time soon.
<lifeless> AFAICT bzr-svn has more fidelity
<NfNitLoop> So I'm looking at a way of "bolting on" a solution to give the remote devs. a more distributed environment.
<lifeless> and you can wrk with bzr native as soon as one user has done the conversion
#bzr 2007-09-06
<NfNitLoop> Yeah, IIRC bzr-svn will create consistent changeset IDs.
<NfNitLoop> so you could even each do your own checkout from the svn source.
<NfNitLoop> (Not sure how one handles sharing between svk instances... but that's probably just due to ignorance on my part.)
<NfNitLoop> Hmm.  It looks like bzr-svn can't handle HTTP authentication for a svn repo.
<NfNitLoop> Unless I'm missing something.    Why do I always have to be the corner case?  :p
<pygi> :D
<NfNitLoop> Ooh, nope, found a bzr bug.
<beuno> NfNitLoop, 0.90 has that problem, 0.18 should work fine
<beuno> at least I've used http auth since 0.12
<NfNitLoop> Hmm, 0.90 was using urllib, so I installed pycurl.
<NfNitLoop> Now it's complaining that my cert is invalid.  :p
<NfNitLoop> (self-signed)
<lifeless> urllib is fine
<lifeless> NfNitLoop: for svn
<lifeless> NfNitLoop: use the svn client to authenticate
<lifeless> NfNitLoop: then it will work, nothing to do with urllib/pycurl
<lifeless> beuno: ^ FYI
<NfNitLoop> Hmm.   how so?
<NfNitLoop> I'm doing bzr branch, how would I use the svn client to auth?
<beuno> aaah, right, I use http auth directly to bzr, don't use svn at all  :D    thanks lifeless for the info though
<NfNitLoop> beuno: do you know what he's talking about?
<NfNitLoop> How do I auth with the client?
<NfNitLoop> lifeless: or do you mean do 'svn co', then use bzr on the checked-out copy?
<NfNitLoop> that's not really what I want.  I want a native bzr branch. :)
<lifeless> NfNitLoop: right
<lifeless> NfNitLoop: 'svn ls URLYOUWANTTOUSEWITHBZR'
<NfNitLoop> still not quite following.
<NfNitLoop> svn list isn't going to get me a checkout. :p
<NfNitLoop> (or branch)
<lifeless> NfNitLoop: it will cause svn to authenticate
<lifeless> and cache the credentials for libsvn to use
<lifeless> which bzr-svn uses
<lifeless> you could actually try doing what I suggest you know
<lifeless> hmm, I'm grumpy today; excuse me and I'll get breakfast - blood sugar++
* beuno hands lifeless a donut
<beuno> irc is so cheap...  :p
<NfNitLoop> lifeless: aah.  well I suspect it still wouldn't work since it's barfing on my SSL cert at the moment.
<NfNitLoop> but if authentication fails I'll give that a try, thanks.
<NfNitLoop> lifeless: Hmm.  svn ls <url> works and has saved my auth.   bzr branch <url>  still fails saying:  Unable to handle http code 401: expected 200 or 404 for full response.
<NfNitLoop> Oh, 401.  *doh*
<NfNitLoop> No, yeah, that's authentication failed.
<NfNitLoop> I thought it was 404 for a sec.  :p
<lifeless> jelmer: ^
<jelmer> NfNitLoop: please try prefixing with svn+
<jelmer> bzr branch svn+<URL>
<NfNitLoop> I did that and got the same error...
<NfNitLoop> though I jsut tried  bzr svn-imoprt svn+https://...
<NfNitLoop> and it's... doing something.
<NfNitLoop> Oh, nope, failed.  "Undefined tunnel scheme: https"
<NfNitLoop> (This is all with bzr 0.90 and bzr-svn 0.41, btw.)
<jelmer> please try the current 0.4 brancxh
<jelmer> is this a public svn repository?
<NfNitLoop> No.
<NfNitLoop> It's using HTTP Auth & SSL.
<jelmer> that should work ok in current 0.4
<NfNitLoop> 0.41?  Or the dev branch?
<jelmer> the dev branch
<NfNitLoop> ok, I'll download that and give it a shot.
<jelmer> I've fixed the handling of svn+https://
<NfNitLoop> aaah.
<NfNitLoop> cool. Thanks!
<NfNitLoop> jelmer: It's doing something now.  It didn't like that I had it in a shared repo directory, so I'm doing it outside of there.
<NfNitLoop> Is it not able to use shared repos?
<lifeless> it uses an unsupported repository format
<lifeless> the nested trees one
<lifeless> if your repo format is in that format it will work, but you can't interoperate with most bzr trees
<NfNitLoop> ah, I could create a shared repo in that format?
<NfNitLoop> That's good.  This could get large.  :)
<jelmer> yes, 'bzr init-repo --dirstate-with-subtree'
<jelmer> hey, looks like tortoisehg is based on tortoisebzr
<spiv> Good morning.
<jelmer> 'morning
<NfNitLoop> Hmmm.  I use the typical svn trunk/ branches/ tags/ root.  Should I be branching the root, or trunk?
<lifeless> igc: morning
<lifeless> spiv: morning
<lifeless> spiv: visiting?
<lifeless> igc: ring my mobile if you would, lets talk commit
<igc> shall do - give me a few more minutes to scan emails
<jelmer> NfNitLoop: You should be branching /trunk or use svn-import to import the repository (which will splitup into multiple branches)
<spiv> lifeless: yeah, I'll head off fairly soon.
<NfNitLoop> Ooooh.  *lightbulb*    :)
<NfNitLoop> So it's plugging away at my very large svn repo.   and in the meantime, in another dir, I'm trying to check out a tiny test repository.
<NfNitLoop> if I try to branch /trunk, I get ...
<NfNitLoop> KeyError: 'readme.txt'
<NfNitLoop> and if I try to svn-import the root, I get ...
<NfNitLoop> bzr: ERROR: Invalid revision-id {None} in SvnRepository(my repo URL)
<jelmer> which bzr-svn branch are you using?
<NfNitLoop> the 0.4 branch.
<NfNitLoop>   parent branch: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
<jelmer> hmm, that should be ok
* jelmer runs bzr-svn selftest just to make sure nothing is broken atm
<jelmer> hey, find_previous_heads() has been deprecated?
<NfNitLoop> I wonder if my little test repo is somehow a "special" (ie: foobar'd) case.
<jelmer> bzr-svn has worked ok against a large number of repositories with all sorts of weird changes in them
<jelmer> it's been a while since I've come across a pull bug
<NfNitLoop> the 'readme.txt' it's complaining about was checked in in the first revision, along with the dirs trunk/ branches/ and tags/
<NfNitLoop> (I notice that is not the case in my larger... seemingly working repo)
<poolie> hi jelmer
<poolie> lifeless, i have no objection to removing get_deltas
<jelmer> NfNitLoop: if the test repo doesn't contain any private data, can you perhaps send me a svn dump of it?
<jelmer> 'morning poolie
<igc> morning poolie
<NfNitLoop> jelmer: Sure.
<NfNitLoop> better yet, I'll try to reproduce it.
<NfNitLoop> and send you that, for a smaller case.
<poolie> igc, hi
<jelmer> NfNitLoop: cool, thanks! My address is jelmer@samba.org
<lifeless> poolie: then send a bb:approve :)
<poolie> i thought i read an rfc about it not a patch
<lifeless> keep reading
<lifeless> :)
<poolie> this is your thread about knits and get_deltas()?_
<poolie> i see
<poolie> i'm reading it
<wedderburn> hello all, i have a rather cryptic message spat out when i pushed a new revision of something - "ERROR: Can't rename /srv/sm-ng/push-branches/00/00/0c/bf/.bzr/repository/lock/wbei8a3n94.tmp to /srv/sm-ng/push-branches/00/00/0c/bf/.bzr/repository/lock/held: /srv/sm-ng/push-branches/00/00/0c/bf/.bzr/repository/lock/held already exists" does anyone have a idea what it means, thanks
<poolie> wedderburn, it's failing to acquire a lock
<poolie> um, it's strange that you're getting this rather than just 'waiting for  lock'
<poolie> jml, spiv: ping?
<jml> poolie: hi
<jml> poolie: wassup?
<poolie> jml, can you look on the sm at the directory wedderburn talks about
<wedderburn> thanks
<poolie> wedderburn, did bzr just stop after giving that error?
<poolie> can you try it again with
<poolie> bzr -Derror push .....
<jml> poolie: alas no, I don' t have access to that yet.
<poolie> really
<wedderburn> poolie: yes bzr stopped after the erro
<wedderburn> r
<wedderburn> i'll try the command now and tell you what it spits out
<jml> poolie: yeah, it's in the works though.
<wedderburn> poolie: heres what it spat out http://andrew.wedderburn.googlepages.com/bzr-error.txt
<poolie> thanks
<poolie> spiv, the traceback shows we're raising this because we don't understand what the sftp error means
<poolie> did anything change with the sftp server there?
<jml> yes.
<poolie> jml, does that error message look like something you wrote?
<jml> poolie: it could well be.
<spiv> I guess bzr+ssh:// instead of sftp:// might dodge this error.
<spiv> That error message comes straight out of twisted.vfs.backends.osfs I think.
<spiv> Where it raises AlreadyExistsError
<spiv> Which the sftp adapter should turn into a FX_FILE_ALREADY_EXISTS in the SFTP protocol.
<poolie> wedderburn, could you try substituting bzr+ssh for sftp in the url please
<lifeless> I thought we had acceptance tests for bzr's treatmnet of the sftp behaviour
<lifeless> in lp
<poolie> yes, but apparently the lp behaviour has changed
<poolie> this is a different misbehaviour to the one you might be thinking of
<jml> lifeless: we do.
<wedderburn> poolie: i'll do that now
<lifeless> poolie: the ExistingContent review comment
<lifeless> poolie: I'm confused, when I look at the patch without the trimming the fmt string is quite clear to me
<lifeless> poolie: so I'm not sure - are you asking me to duplicate the format string into the doctstring?
<jml> poolie: the lp behaviour changing should be caught by lp acceptance tests.
<lifeless> poolie: I mean, what comes to mind is 'This is an exception raised when the content being inserted is already present'
<lifeless> poolie: and that doesn't seem helpful.
<poolie> you could change the docstring to just a comment
<poolie> it seems like a very strange docstring at presentt
<wedderburn> poolie: Unable to obtain lock lp--1216787156:///lock
<wedderburn> held by andrew.wederburn@gmail.com on host andrew-laptop [process #10620] 
<wedderburn> locked 22 hours, 50 minutes ago
<wedderburn> Will continue to try until 02:47:26
<poolie> wedderburn, thanks
<poolie> assuming that process is not still running
<poolie> just use bzr break-lock $url
<wedderburn> ok
<lifeless> poolie: I'll make it a comment then. Though I thought you wanted introductory-api notes in docstrings, which is why I added it (most exceptions dont have docstrings at all)
<poolie> on either sftp or bzr+ssh
<poolie> iirc the thing i said we should document the introduction of was rpcs
<lifeless> oh, I took it to be all api's
<wedderburn> poolie: and now?
<poolie> now you should be fine to push
<wedderburn> k
<wedderburn> poolie: using the sfpt://... ?
<poolie> either way
<poolie> bzr+ssh will be a bit faster
<wedderburn> poolie: :) it works now thanks
<poolie> thanks for reporting it
<wedderburn> :)
<wedderburn> well im off thanks for all the help everyone
<spiv> poolie: is it ok with you if I merge http://bundlebuggy.aaronbentley.com/request/%3C20070903164726.GA22003@steerpike.home.puzzling.org%3E ?
<lifeless> does it fix the bugs with tag branhces on initial pull
<lifeless> that is does it stop using the tarball hack ?
<spiv> It stops using the tarball hack.
<lifeless> then I'm pro it going in noweth
<lifeless> but today would be the latest I think
<spiv> I don't know about the tags issue; should there be an automated test written for that?
<spiv> (It stops using the tarball hack on the client entirely; it will fallback to VFS operations)
<mkanat> Is there a machine-readable output that would consistently allow me to tell that a plugin is installed?
<lifeless> bug 129717 I think
<ubotu> Launchpad bug 129717 in bzr "Bizarre error when checking out from bzr server mode" [High,Triaged]  https://launchpad.net/bugs/129717
<mkanat> I don't necessarily want to rely on "bzr plugins" since that text could change.
<lifeless> mkanat: python -c 'import bzrlib.plugins.pluginname'
<mkanat> lifeless: Thank you. :-)
<poolie> spiv, thanks for that
<igc> lifeless: looking at http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n, have the manually tracked ones been merged yet? If not, do we want them in 0.91?
<lifeless> igc: we're in freeze
<lifeless> igc: so everything needs poolies magic pixie dust
<NfNitLoop> jelmer: Hmmm.  checking out my big repository fails.   It locks up my box for a while, while the HD thrashes, then it just says "Killed" and stops.   The box only has 512M RAM.  How RAM intensive is it?
<lifeless> poolie: can I merge the one you approved for 0.91 ?
<poolie> i approved a few...
<igc> sure. I'll take that as a "no" to not yet merged.
<igc> all up, we have 10 changes approved or conditionally approved
<jelmer> NfNitLoop: yes, there's a leak in the python-subversion bindings (see bug 54253)
<ubotu> Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed]  https://launchpad.net/bugs/54253
<jelmer> NfNitLoop: but you can restart the process if you're importing to a shared repository
<mkanat> lifeless: And is there a way to get from bzr the path to its default python interpreter?
<poolie> for http://bundlebuggy.aaronbentley.com/request/%3C1187769804.17572.104.camel@localhost.localdomain%3E,
<lifeless> mkanat: I think bzr --version will show that
<poolie> i agree with john's comments
<mkanat> lifeless: Yes, it does! :-)
<mkanat> lifeless: Thank you. :-)
<poolie> i guess there is no small way to address them?
<igc> poolie: fyi, one change I had hoped we'd see in 0.91 is this one: http://bundlebuggy.aaronbentley.com/request/%3Cfaekm0$qvu$1@sea.gmane.org%3E
<lifeless> poolie: I will fix that one, haven't yet.
<ubotu> New bug: #137668 in bzr "bzr doesn't understand new 'directory already exists' message from codehosting sftp server" [Undecided,New]  https://launchpad.net/bugs/137668
<NfNitLoop> jelmer: is there any way to do it in small chunks?
<poolie> http://bundlebuggy.aaronbentley.com/request/%3C1187769900.17572.106.camel@localhost.localdomain%3E
<poolie> same, ok to merge with john's change
<NfNitLoop> jelmer: instead of waiting for it to get killed?  :p
<igc> abentley approved it but I wanted some changes ...
<igc> we haven't heard back from Fabio though and it would be a shame to see it fall into limbo because no one was driving it
<igc> poolie: any thoughts?
<lifeless> igc: that patch is broken
<lifeless> +                filtered_list.append(f)
<lifeless> +        except:
<lifeless> +            invalid_filenames.append(f)
<lifeless> bare except: it will stop ctrl-C
<igc> lifeless: can you explain further?
<lifeless> ctrl-C at the right time will make the path being sorted into an invalid path, even if its valid, and bzr will continue rather than exiting
<lifeless> 'except:' is verboten
<igc> Ahhh
<lifeless> its only *ever* ok when there is a 'raise' immediately after it.
<poolie> interesting:
<poolie> mbp@grace% bzr merge http://bundlebuggy.aaronbentley.com/download_patch/%3C1188888611.6248.3.camel@nemo%3E
<poolie>  M  NEWS
<poolie> All changes applied successfully.
<poolie> bzr merge   1.08s user 0.09s system 35% cpu 3.282 total
<poolie> mbp@grace% bzr di
<lifeless> poolie: can I merge http://bundlebuggy.aaronbentley.com/request/%3C1189031297.27465.2.camel@lifeless-64%3E for 0.91
<poolie> with those doc changes
<poolie> yes
<lifeless> thanks
<poolie> thanks for writing it :)
<mkanat> lifeless: Ah, I have a proooooblem. :-)
<mkanat> lifeless: I need to know if a plugin is installed by the functionality it offers, not by its name.
<mkanat> lifeless: That is, because the name can be anything the directory is called, and I need some reliably way of determining if the functionality is available.
<mkanat> *reliable
<lifeless> mkanat: no
<lifeless> mkanat: plugins have canonical names
<lifeless> plugins depend on other plugins by name
<lifeless> its not installed if its not under its official name
<mkanat> lifeless: Hrm.
<mkanat> lifeless: And that's true for xmloutput?
<mkanat> lifeless: bzrtools I have no problem with. :-)
<mkanat> That will always be called bzrtools. There's almost always a distro package for it, too.
<lifeless> mkanat: this is the contract for bzr pluigns
<lifeless> if someone does something different they haven't isntalled the plugin correctly
<mkanat> lifeless: Okay.
<lifeless> I mean, if I put bzr on my path as 'bzr-temp-copy'
<lifeless> you can't be expected to figure that out
<lifeless> this is the same problem basically
<mkanat> Hahaha. :-) Okay. :-)
<lifeless> given you want to be able to use a command
<lifeless> just run 'bzr xmloutput'
<lifeless> and if you get an error show the user the output from bzr
<mkanat> Well, that particular plugin doesn't provide a command.
<lifeless> it provides options though
<mkanat> But I'm using the import method, that works fine. :-)
<mkanat> Yeah, it does.
<lifeless> and if its not installed the option will error
<mkanat> Just so you know what I'm doing, I'm writing tests that I have to skip if bzrtools and xmloutput aren't installed.
<mkanat> (But from another language.)
<lifeless> ok
<mkanat> BTW, <3 bzr, guys. :-)
<mkanat> Every time I have to use CVS or some other crazy VCS, I wish it was just bzr.
<NfNitLoop> mkanat: y'know, bzr can act as a front-end to other VCSes.  :)
<NfNitLoop> (I'm playing with bzr-svn this evening.)
<mkanat> NfNitLoop: Cool. :-)
<mkanat> NfNitLoop: Well, see...I'm the author of a library that interfaces with VCSes. :-)
<mkanat> So I have to actually *use* them. :-)
<NfNitLoop> Doh.  :p
<mkanat> I thought bzr was kind of hard to understand for newbies, until I tried git. :-)
<NfNitLoop> mkanat: Yeah...  I tried out several DVCSes a while back...
<NfNitLoop> I think I started with gnu arch.
<NfNitLoop> it seemed...  tedious.
<mkanat> Wow. :-)
<mkanat> Yeah, I'd imagine.
<mkanat> I don't anybody really uses Arch anymore.
<NfNitLoop> Yeah.  It was just the one I'd heard of.
<NfNitLoop> so I started with it.
<mkanat> Yeah, as far as ease of use and sensible, complete implementation of features, bzr is the best one I've used.
<NfNitLoop> anyone:  How do I remove a lock on a shared repository if the process that created the lock has died?   is it safe to rm -r .bzr/repository/lock/  ?
<jml> NfNitLoop: bzr break-lock
<NfNitLoop> jml: thanks.  I figured there'd be some command.  :)
<NfNitLoop> jelmer: Doh.   Yeah, resuming from a shared repo didn't work too well.   :p
<NfNitLoop> jelmer: bzr: ERROR: exceptions.KeyError: 'design'  (the name of a folder in the repo)
<abentley> lifeless: pong
<abentley> spiv: I'd prefer to merge the reconcile fix first.  I don't want to break fetch without providing a way to fix fetch.
<lifeless> abentley: ok, I will do a revision-index cross check patch
<abentley> Wow, you really have a hate on for RevisionParentsProvider.
<lifeless> heh, I don't think I would have put it that way
<lifeless> but I don't think we should add additional code to work around other code that we should have being absent
<lifeless> and for things like check/reconcile on a remote repository this is clearly going to be doing much more work than we want
<lifeless> a$ rm -rf .bzr && bzr --no-plugins  init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins  commit -m "Initial commit"  -q
<lifeless> 
<lifeless> real    2m12.203s
<lifeless> thats annotation-less packs
<lifeless> user    1m58.647s
<lifeless> sys     0m6.256s
<lifeless> I'm aiming for 1m12
<lifeless> so 60 seconds to go
<abentley> This is for moz?
<lifeless> yup
<lifeless> 550MB of source, 55K files
<abentley> I suppose delta generation time doesn't come into play at all for the initial commit?
<lifeless> not at all
<lifeless> unless we were to do deltas-against-NULL
<abentley> Which should be fast-pathed.
<lifeless> so initial commit is great for finding constant factors that will affect all commits
<lifeless> like zip overhead
<lifeless> and api friction
<lifeless> in should be only slightly slower than for path in paths: compress(path)
<keir> lifeless, i'm pretty sure i know how to build a graphindex nicely now. compressed and tightly encoded and spatially coherent.
<lifeless> s/in/it/
<lifeless> keir: thats excellent news. Care to describe it in a mail to me/the list ?
<keir> yes
<abentley> Yeah, I was a little worried about your earlier talk of removing get_deltas, but then I realized it's not what I'm using to get matching blocks.
<lifeless> abentley: yah, that why I was pinging in fact, but Ifigured it out
<keir> lifeless, it's going to take me some time to write up, but absolutely. there are a couple little things i have to think about, but hopefully i'll have a description ready before tmrw night
<lifeless> keir: cool. Don;t worry about those things- I mean do worry, but don't block on documenting your thoughts, because perhaps I can offer some feedback that will help you with them
<abentley> I was expecting Xdelta was going to go into pack repos, but I haven't heard anything on that front for some time.
<lifeless> keir: also tomorrow is a public holiday for me, so you may not hear back till my monday - but it won't be me ignoring you :)
<lifeless> abentley: IIRC there was some performance issue there.
<abentley> Oreilly?
<lifeless> abentley: and open questions about bytes vs lines as the delta form
<lifeless> didn't john say xdelta application was slower due to bytecode interpretation or something?
<abentley> I thought it was creaming MPdelta, which was creaming knit in turn.
<lifeless> anyhow, I'm happy to support a few pack repository versions if we can deliver something moderately high performing in the short term and rev it - getting past the current 'you are too slow kthxbye' is the immediate priority
<lifeless> not that I want to do that
<lifeless> just that I think its ok
<abentley> I am okay with that also.
<abentley> But I would rather have Xdelta or MPdiff than knit.
<abentley> I'll talk to John.
<lifeless> why is mpdiff faster than knits ?
<lifeless> is it faster in both directions, and does it need more or less data on average to construct a text (how do full-texts fit in etc)
<lifeless> if this is already on-list thats fine
<abentley> lifeless: the mpdiff text reconstruction algorithm doesn't generate intermediate texts, and never inserts in the line list, only appends.
<abentley> I don't know whether it's faster or slower for creating the mpdiff.
<abentley> "more or less data" is tricky to answer.  More revisions, less data in each revision.
<poolie> lifeless, i'm confused - the 'implement chunked encoding' patch is not yet approved
<lifeless> poolie: thats not he patch under discussion
<lifeless> poolie: so indeed, you are confused :)
<lifeless> abentley: ok; and presumably this no-insertion behviour is hard to do for knits
<keir> lifeless, ok so here's the short version of what i'm thinking
<abentley> lifeless: You just have to massage the offsets more.
<ubotu> New bug: #137681 in bzr "bzr: ERROR: Unable to delete transform temporary directory" [Undecided,New]  https://launchpad.net/bugs/137681
<keir> lifeless, there are three parts to a graphindex. 1) index preamble (an index to the index) 2) the index, which lets you map from string key -> integer hash, and also contains the values 3) the graph store, which is just like the current storage scheme, but the keys are entirely ommitted.
<abentley> But what I really dislike about knits is they don't properly delta the final newline, and screw up attempts to extract matching blocks.
<abentley> You have to extract the fulltext to get the matching blocks out.
<keir> 1) is a lzw'd or other streaming compressed index (just like in a book) into the 'chunks' of the index.
<abentley> They also don't provide an indication of the number of lines in the file.
<keir> 2) is a series of 'chunks' each indepently lzw'd,  which contain key->hash,val_len,val ...
<keir> each 'chunk' in 2) is the same size. because of how lzw works, we can still make each chunk mostly the same size
<keir> then 3) is just a list of the edges as straight up offsets; the id of a key is just the byte offset in section 3) of that node
<keir> section 3 is toposorted, such that the enumeration of the hashes corresponds to the toposort of the keys
<keir> this has a variety of nice properties for traversing the graph
<lifeless> abentley: these are all good points.
<keir> there is some debate on whether to include the values in 2) or 3). in 2), the keys will be compressed; but if they are in 3), then if you only care about the values it traversal, you get them for free without having to re-query the index for each key
<lifeless> abentley: I'd be happy to see packs using mpdiffs given them. Its not top of my priority list (my time on bzr at the moment is really focused on helping out with perf - I'm not in the bzr department @ canonical these days)
<abentley> lifeless: I am happy to ride my hobbyhorse into pack land :-)
<lifeless> abentley: and while they will clearly help with performance, I'm currently tackling things surrounding the delta layer rather than the deltas themselves :)
<keir> then there is the debate on how big to make the chunks.
<abentley> lifeless: is revno 2744 current?
<lifeless> keir: this is sounding very interesting; An email would be much easier for me to digest as I'm deep in commit's guts at the moment and I'll need to look at this later
<keir> lifeless, sure
<lifeless> abentley: pushing
<keir> lifeless, there is some measurements i need to do regarding lzw tradeoffs; i'll do those now then write it all up
<lifeless> abentley: (its not, but the changes are mainly merges of other branches)
<lifeless>  rm -rf .bzr && bzr --no-plugins  init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins  commit -m "Initial commit"  -q
<lifeless> real    2m2.092s
<lifeless> user    1m48.035s
<lifeless> sys     0m5.564s
<keir> lifeless, one last question: how big do you think it's reasonable to make the 'minimum size read chunk'?
<lifeless> 4K? thats a disk cluster isn't it ?
<keir> ok, but if you're roundtripping, is't something like 32k more reasonable? if we assume people are on broadband...
<lifeless> well
<lifeless> transport.get_recommended_page_size() might be your friend :)
<keir> hmm, but the indexes will have a block structure which is independent of the transport
<keir> so we'll need to find a reasonable middleground.
<lifeless> so
<lifeless> more data -> more processing
<lifeless> less latency impact
<lifeless> so when there is low latency you want low processing
<lifeless> and when there is huge latency we're willing to spend more cpu
<lifeless> if you were to (say) have a 4K page in the index, which must be entirely read if read at all
<lifeless> then you can do ceiling(recommended_page_size/4k) * 4k
<lifeless> to get the amount to read
<keir> yeah, ok
<keir> the problem is that if you're compressing blocks, you don't win much on 4k
<keir> you really want > 16k
<lifeless> we win plenty on 200 bytes in knits
<keir> really!
<keir> ok
<keir> nevermind then, i'll make it a knob
<lifeless> 44 bytes is the break-even for libz
<keir> and libz is lzw?
<lifeless> lzw78 IIRC
<lifeless> might be 77. I dunno offhand, check the library :)
<lifeless> so for compression we win on entropy in the data
<keir> ok. i need the following thing for implementation: given a large string, compress until your compressed size is N bytes, then terminate and tell me how much of the source string you chomped, and give me the compressed string
<keir> lifeless, you mean we win on lack of entropy
<lifeless> the amount we win and the entropy are lnked :)
<lifeless> anyhow, that API is a problem for all compressors I can think of
<keir> because i'm a C loser, i want to go off and code it in C by using an existing lzw algo
<lifeless> every compressor API I've seen has internal state for the current symbols that have not yet selected a terminal representation
<lifeless> this state is cleared by calling flush()
<lifeless> which in pathological cases can output 1/2 the already processed input IIRC
<lifeless> (as the longest match-to-date)
<lifeless> particularly for dictionary compressors
<keir> wait, but doesn't lzw's dictionary get built implicitcly?
<keir> so it's never put directly in the output stream?
<keir> so you can just 'stop' compressing at any stage?
<keir> (i haven't implemented it for some years...)
<lifeless> well. It would be really nice not to require C; that keeps us more portable. C as optimisation - Great!. C as requirement - if we have too we have too, but do we have too ?
<lifeless> keir: the dictionary is built from the symbols processed
<lifeless> keir: say we compress AAAAAA
<lifeless> first symbol A - its a terminal, output it
<abentley> keir: We were all C losers at one point or another.  Remember tla, lifeless?
<lifeless> next symbol A - its a hit for A, keep it, next symbol A, output reference-to-first A, then A.
<lifeless> next symbol A, hit for A, next symbol A, hit for AA, next symbol A, output reference to AA, then A
<lifeless> this ummary is wrong, I'm just demonstrating that there are things that are not yet output, and the number of bits that have tobe output to represent them is determined by the compressor state
<lifeless> that is - its eaten the input, but not output it yet.
<keir> ah yes
<lifeless> abentley: oh yes.
<lifeless> abentley: 2753 is pushed btw
<keir> ok, so if i hack lzw itself, it's fine because i can estimate the current compressed size if we were to terminate
<abentley> lifeless: tx
<keir> libz is zlib? i'm not sure how to get at a lzw compressor in python
<abentley> Um, is it pushed to the packs version of your branch?
<lifeless> abentley: yes, not to the knits version yet
<lifeless> I'll ssh in and clone it across to knits, one sec
<spiv> keir: Yes. http://docs.python.org/lib/module-zlib.html.
<lifeless> keir: yes, but see above - requiring C is undesirable. You can achieve a version of this without requiring C though, (just add until a page size is within some figure, then flush, and accept slack space)
<keir> yeah, that's the plan
<keir> so it looks like you get smack on 0.2 compression ratio for 4k, 16k, 32k blocks
<keir> at least for rev id's
<keir> i'm out for tonight but i'll write this up tmrw morning
<lifeless> http://www.smh.com.au/news/national/chaser-duo-held-over-motorcade-stunt/2007/09/06/1188783378804.html
<lifeless> keir: thanks!
<igc> lifeless: re your changes to test_versionedfile.py just merged, it looks like you have a duplicate routine name - test_add_lines_nostoresha. I gather that's the one test and it got duplicated by a merge maybe?
<igc> my merge of your 0.92 patch has the routine name 4 times. :-)
<lifeless> abentley: oh I've pulled it to the knit copy of packs
<spiv> The current version of pyflakes notices that sort of mistake.
<lifeless> igc: .dev$ grep test_add_lines_nostoresha bzrlib/*/*.py
<lifeless> bzrlib/tests/test_versionedfile.py:    def test_add_lines_nostoresha(self):
<lifeless> bzrlib/tests/test_versionedfile.py:    def test_add_lines_nostoresha(self):
<lifeless> I see it twice
<igc> yup - twice in bzr.dev
<igc> when I merge your patch, I get it 4 times
<lifeless> igc: and it should be twice with a slight change to the name
<lifeless> fixed and sent to pqm
<igc> thanks
<lifeless> igc: I am down to m48
<igc> neat
<lifeless> 1m48 I mean lol
<igc> i knew that :-)
<lifeless> 2m2 wall clock
<igc> lifeless: does merging my "improved commit reporting" patch help as well?
<lifeless> I'm running with -q
<lifeless> so I'd hope not :)
<igc> even with -q, show_change (or whatever it's called) is still being called unnecessarily without my patch
<igc> in bzr.dev at least
<lifeless> igc: ok
<lifeless> igc: did you see my /query?
<igc> I saw the times, yes
<lifeless> hard to tell when you dont reply :)
<igc> I did
<lifeless> I bet you are not logged in
<igc> hmm
<lifeless> tomorrow I'm going to make clean patches for several of these things for bzr.dev
<igc> cool. I've got a quick review if you want it ..
<lifeless> on bb ?
<igc> just on paper here so far :-)
<lifeless> :)
<igc> want a quick email now or a more complete one
<lifeless> I'm calling it a day, or really a week
<igc> ok - I'll go with the complete one in the next few hours
<igc> gotta luv APEC :-)
<igc> lifeless: do you have a branch I can pull?
<igc> lifeless: just emailed you my gaim session - not sure why you didn't see my times
<lifeless> heh
<lifeless> no, I don't have everything committed, I'm do sketch-tests
<lifeless> then I take the uncommitted change and test in isolation to make a real branch for it
<lifeless> then submit that
<igc> ok
<lifeless> if you merge all my pending bundles
<lifeless> and disable annotations as previously documented
<lifeless> and disable the _check_lines and _check_present_parents in knit.py's _add_lines method
<lifeless> then I think you will have my tree
<igc> so your times are with packs, not knits, right
<lifeless> rm -rf .bzr && bzr --no-plugins  init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins  commit -m "Initial commit"  -q
<igc> cool
<igc> enjoy your day off
<lifeless> okies :)
<sabdfl> hey guys, when last was lifeless around?
<pygi> 3:07 my time
<pygi> was the last time he said something :)
<dato> sabdfl: 1h45m ago
* pygi wasn't here then o.O
* pygi hides
<sabdfl> thanks dato
<Peng> Woah. _patiencediff_c.c is real C, not Pyrex.
<Peng> Hmm, easy way to run patiencediff on a directory? python -m bzrlib.patiencediff only accepts files.
<Peng> (as of 0.90, at least)
<Ng> are there ubuntu packages of 0.18 for dapper lurking anywhere?
<Peng> What about 0.90?
<Ng> oh yeah, I'd forgotten that was out. 0.90 then :)
<Peng> Well, I don't know.
<mwhudson> http://bazaar-vcs.org/releases/debs/feisty/
<mwhudson> oh sorry
<mwhudson> bazaar-vcs.org only seems to have 0.17
<Ng> yeah and the feisty debs for 0.90 seem to be arch dependent and not happy with dapper's libc
* Peng points out that python setup.py install isn't too hard.
<mwhudson> Ng: i would _hope_ that the debs would build easily enough on dapper
<Ng> mwhudson: I expect so, I was just hoping someone was continuing the fine bazaar tradition of doing it for me :)
<mwhudson> unless the build-deps are hard to satisfy, e.g. missing a new enough pyrex
<mwhudson> Ng: fair enough
<mwhudson> i'm not the one to help here though :)
<lifeless> Ng: we will
<lifeless> Ng: need to backport the debs and python build rules
<lifeless> because dapper has that very different python setup
<Ng> lifeless: ok, thanks :)
<abentley> lifeless: up?
<fullermd> Hm.  How odd.
<fullermd> Where does 'info -v' get its "first revision" from?  'cuz it's wacky.
<fullermd> I've got a branch with 3 initial revs, and the one it picks for 'first' isn't the left-path initial.  Nor is it the oldest of the initials.
<jelmer> NfNitLoop: that appears to be a recent regression, working on it at the moment
<jelmer> NfNitLoop: looks like a http-specific bug
<effbiae> hi all, bzr's great.  how do i turn a local branch into a sftp branch, retaining all the history?
<gabe_> effbiae: it already is
<effbiae> so just sftp to the dir, yeah?
<luks> or `bzr push sftp://host/path/to/branch`
<gabe_> push doesn't work well for me via sftp
<gabe_> it doesn't update the trees
<effbiae> my branch is in ~/mysql.5.bak  ,  then bzr clone sftp://jack@192.168.0.4/mysql.5.bak results in ...
<gabe_> because it is too expensive via sftp
<effbiae> bzr: ERROR: bzrlib.errors.NotBranchError: Not a branch: sftp://jack@192.168.0.4/mysql.5.bak/
<gabe_> does   mysql.5.bak have   a  .bzr   directory?
<effbiae> yup
<effbiae> bzr check returns clean bill of health
<fullermd> effbiae: You probably mean "sftp://jack@192.168.0.4/~/mysql.5.bak
<effbiae> fullermd: brilliant.
<gabe_> fullermd: yeah
<effbiae> now is a local commit the same as an sftp commit?
<gabe_> didn't know you could do a sftp commit!
<fullermd> ETERMINOLOGY
<effbiae> EAGAIN?
<fullermd> It's hard to answer without knowing what you mean by 'local commit' and 'sftp commit'   :)
<effbiae> hmmm, i think i'm confused.   i want to run a server, like CVS.
<effbiae> well, i want a central repository that i can get and put revisions.  don't want more than one branch at this stage.  which man page should i look at?
<fullermd> Well, in that use case, you want to use checkouts of a single branch.
<fullermd> So you'd have a branch "somewhere" (whether it's local, or via sftp, or bzr+ssh, doesn't matter), and you'd "bzr co" it wherever you want to work.
<effbiae> so the key is to 'checkout' and then future commits will update the .bzr directory from where i checkedout, yeah?
<fullermd> Right.
<effbiae> thanks for all your help.  good night.
<joe99> Anyone have any suggestions for how to setup a repository on OS X that more than one person can commit to?
<bwinton> Give all the contributors accounts?
<bwinton> (That's what I did, but I trusted the other person with an account.)
<bwinton> (And set his shell to /bin/false just in case. ;) )
<joe99> Everyone has accounts.  But how do you handle the file permissions?
<fullermd> That rather cramps the ability to use bzr+ssh   :p
<fullermd> Group writable.
<bwinton> It does, but he could push over https.
<bwinton> Yeah, I did the group-writable thing.
<bwinton> Or I set them up to be owned by him, and sudo-ed everything I needed to.
<fullermd> Well, if you go over https (bzr+, I presume), you don't need accounts period.
<joe99> Yes, but new files created don't seem to keep the permissions.
<fullermd> They should.  I've tried a couple times, and bzr always DTRT.
<joe99> If I create something as root & make everything writable new files created by others are not compatible.   Is there a simple solution to this?
<mwhudson> do you need g=ws or however it's spelt?
<fullermd> How are the perms showing up wrong.
<fullermd> I'm pretty sure OS X doesn't have that SysV brain damage...
<fullermd> (Er, that first was supposed to have a '?' at the end...)
<joe99> New files reflect the ownership of the creator and -rw-r--r-- permissions.
<fullermd> The dir they're in is 77x?
<joe99> Yes.
<fullermd> Mmm.  Works for me.
<fullermd> dir is 770, files end up like -rw-rw----  1 fullermd  wheel   94 Sep  6 10:08 a-20070906150753-pzfx8evgly2b3tep-1.kndx
<joe99> Let me try again.
<fullermd> Make sure it's all set to start out.
<fullermd> find .bzr -type d -print | xargs chmod 770   ; find .bzr -type f -print | xargs chmod 660
<joe99> sudo chmod 770 foo;       cd foo;       touch bar;     ls -l;     results in -rw-r--r--
<fullermd> Yes, but that's touch, not bzr.
<joe99> Also,  I tried bzr serve --allow-writes as an alternative, but it didn't work, and I'm not sure of the security model for it.
<joe99> Sure, but why would bzr be different?
<fullermd> You only care about the files bzr makes.
<fullermd> Because bzr checks the perms and intentionally preserves g+w if it's around.
<joe99> But bzr is run by the users ssh-ing.
<joe99> Well, maybe my experiment is flawed.
<fullermd> touch just does an open().  bzr looks at the perm of the parent dir (I think; maybe the perm of the .bzr/ at the root) and uses that as a template for the new file.
<joe99> So as long as nobody actually does anything by hand in that directory it should work fine?
<fullermd> Well, anybody doing something in .bzr/ by hand needs a good thwapping just on general principles   :] 
<joe99> Not in .bzr,  I meant creating, adding, commiting, etc in the branch in the shared directory.
<fullermd> What, multiple people in one working tree?  That's a nightmare waiting to happen.
<fullermd> I wouldn't consider it except in very specialized cases (like /etc, where there's only one uid that's ever there)
<joe99> Doesn't somebody have to create the initial tree?
<fullermd> Yes, but everybody would have their own WT (either by having their own branches in a dist-like setup, or their own checkouts in a central-like setup)
<joe99> How do I put a tree there in the first place?
<joe99> I mean, I have one.   Can I branch it there and have that branch be the branch acts as the central branch that everyone can push to?
<fullermd> Yes, that'll work.  Push it there (one way or another), then do the chmod's on that "central" location, then have everybody else branch from and push to that, or checkout it, or whatever.
<joe99> And bzr will DTRT with respect to file permissions regardless of who is ssh-ing?
<fullermd> Should (and in all my testing, does), yah.
<joe99> I'll give it a try.  Thanks.
<fullermd> If OS X uses SysV filesystem semantics, you'd need g+S on the dirs to properly propogate the group ownership to new files.
<fullermd> I don't _think_ it does.  But if new .knit's and the like show up with the wrong group, that's the thing to try.
<joe99> How do you set g+S?
<joe99> Do you mean g+s?
<fullermd> Yah.
<cory> Hi, is there a way to cleanly remove a branch from a shared repository (and any cruft it might have left behind)?
<fullermd> Not really.
<cory> Ok, I suppose I can always just branch everything I want to a different shared repository and let it sort itself out if I really care.  I was just curious and having trouble searching, thanks.
<fullermd> Yeah, that's the usual way.
<fullermd> It's a fair bit of work, and it loses branch-local config (like parent/push/etc branches).
<fullermd> There was a proof-of-concept 'cleanup' plugin somewhere once.  It's certainly on the list to add, just nowhere near the top of anybody's todo list.
<fullermd> Mostly, disk space is cheap enough that we all just ignore it for now.
* cory nods.
<bwinton> Mental note: Don't put my video collection under bzr...  :)
<cory> Oh, we have lots of big binary files. :S
<Lo-lan-do> Disk space is rather cheap, but bandwidth (and time) isn't.
<fullermd> Well, most of any given branch will be common with other branches in the project, so it's not like you'd save much in most cases.
<fullermd> Sure, but if it's not referenced, it doesn't cost you any bandwidth.
<Lo-lan-do> So remote backups of obsolete data is less than optimal.
<fullermd> (well, maybe a little in throwing around inventories or something, but...)
<fullermd> Oh, non-bzr?  Yeah, it'll hit you there.
<Lo-lan-do> Yeah, like, you know, backups :-)  rsync, or amanda, or tar+scp, or whatever
<fullermd> Backups are for pessimists   ;)
<Lo-lan-do> Backups are also for fat-fingered people and (maybe more importantly) their sysadmins.
<cory> It was more a policy thing.  I'm trying to get some people to switch from p4, and I'm inclined to push lightweight checkouts and lots of branching in a centralized repo, and it was the difference of whether I say, "it mostly doesn't matter to leave it sitting around," or, "you can push this button to clean up an old branch, and it will be obliterated."
<fullermd> Unrelated to the issue at hand, but you probably want to look at something like bzrtools' 'cbranch' with that workflow, too.
<cory> Interesting, just to set the default branch root?
<fullermd> Well, it lets you remotely 'branch' and create a local checkout in one step (AIUI; I've never done more than glance at it)
<fullermd> I know that abentley uses the separate repo/checkout workflow more than most people here, so there are a few things (cbranch, switch, at least) in bzrtools aimed at supporting those workflows.
<cory> Yes, switch is key.  Thanks.
<NfNitLoop> jelmer: Hmm.  I just realized that the BzrForeignBranches/Subversion says that bzr-svn needs some fixes from svn 1.5 trunk.
<NfNitLoop> jelmer: Is that still the case?  I hope that's not the problem I've been having and pestering you about.  :p
<fullermd> Actually, last I heard, it still needed some fixes that weren't even in svn trunk...
<NfNitLoop> fullermd: Heh, well, there is that nasty memory leak...  :)
<samurai> morning all
<joe99> Is sftp access safe for concurrent users?  Or do you need to use bzr+ssh?
<mwhudson> both create lockfiles
<fullermd> sftp should be as safe.
<fullermd> (of course, if you can use bzr+ssh, it's probably better performing etc. anyway)
<joe99> I'm not sure how to setup bzr+ssh on OS X.   The instructions are for inet.d, which OS X apparently doesn't use anymore.   And I don't really have a handle on launchd.
<fullermd> bzr+ssh doesn't need any setup (other than having bzr in $PATH)
<fullermd> If you're looking at inetd stuff, that's for bzr://, not bzr+ssh://
<joe99> What's the difference between bzr & bzr+ssh?
<fullermd> bzr+ssh ssh's in and runs bzr, and chats with it over the ssh connection (like :ext: CVS does)
<joe99> So does that make it more secure?
<fullermd> bzr:// talks over TCP to a server talking the bzr protocol, either via 'bzr serve' (which runs it as a daemon), or through something like inetd (that accepts the connections and passes them to bzr)
<fullermd> Well, it means that ssh handles all the authentication and such.  With bzr://, you get no authentication (at least, not currently)
<joe99> Does anyone happen to remember which file on OS X is the right one for setting the path to bzr?
<fullermd> Depends on your shell, probably.  Something like /etc/profile or /etc/csh.cshrc or something else for zsh, etc.
<NfNitLoop> Heh, I'm reading the "svk book".   It looks like someone just took the subversion book and did s/svn/svk/g
<joe99> If I branch with sftp that seems to work.   If I use bzr+ssh I get an error that says bash: line 1: bzr: command not found  bzr: ERROR... and then this long traceback.
<NfNitLoop> joe99: That probably means that bzr isn't found on the remote path.
<joe99> Yes.  But wouldn't have been found by sftp?
<NfNitLoop> does the remote machine have bzr installed?   Is it accessable by ssh's default path?
<fullermd> sftp doesn't use bzr on the remote end.
<NfNitLoop> sftp does not use bzr on the remot...
<NfNitLoop> :)
<joe99> That may be it then.  I added /opt/local/bin to path in /etc/profile.  So it's there when I ssh in.   But maybe that's only for login shells.  It must be one of those other files I can't remember the name of.
<NfNitLoop> Yeah... I never remember either.   I'm glad bzr doesen't require a remote copy to function.  :)
<fullermd> Avoiding Bourne shells does the trick for me   ;p
<joe99> If the sftp command fails do bad things happen?
<NfNitLoop> God kills a kitten.
<NfNitLoop> (Though I'm not sure what happens to your branch.)
<joe99> Does it keep the kitten company?
<NfNitLoop> that or it just lands in intensive care.
<NfNitLoop> I've not had luck with partially-completed bzr-svn branches.
<NfNitLoop> Though that may be a special case.
<joe99> I'm not concerned that much about the branch as the push.
<NfNitLoop> Heh.  Good point.  I would hope they would be atomic.
<NfNitLoop> there are a couple commands:  bzr break-lock and bzr check, that would probably help with recovery.
<mwhudson> yeah, you'll often end up with dangling locks
<mwhudson> but that should be the worst of it, afaik
<jelmer> NfNitLoop: well, the python-subversion package in recent ubuntu and debian contains a backport of those changes from subversion 1.5
<NfNitLoop> jelmer: aah.  I'm running Debian etch.
<NfNitLoop> jelmer: you got my e-mail with the sample svn dump?
<joe99> sftp doesn't update the working tree of a remote branch.  Is this of any concern if nobody ever works on that branch directly?   Does it require any special considerations for conflicts or anything that are pushed to that remote branch?
<fullermd> Only if you want the files there and up to date for some reason.  bzr doesn't need them.
<fullermd> Unless you need 'em for some other reason (and thus go through other steps to keep them up to date), you can just as easily get rid of the working tree altogether.
<joe99> At some point I might want to run automated tests.  But for now I was hoping to use a remote branch as a central repository for things everyone was happy.
<joe99> ..with.
<fullermd> I'd probably run automated test in their own checkout anyway.
<joe99> Yes.  Assuming everybody actually runs them.   But some live by the motto "If it compiles, ship it."   And with interpreted code there are those who don't even compile.
<fullermd> No, I mean automated tests would run as an automated job, but with its own checkout that it updates and works with.
<joe99> That makes sense.
<silwol> somebody here who can help me about how to best package my piece software that is checked in to bzr?
<NfNitLoop> silwol: Just like you would package any other software.
<NfNitLoop> all of bazaar's files are in .bzr
<NfNitLoop> so just exclude that directory.
<silwol> NfNitLoop: i remember chatting with pitti (from ubuntu) and he told me it was best to keep a separate bzr branch for packaging
<silwol> so the main branch has no debian directory, and is always merged into the packaging branch where the debian directory is maintained
<silwol> but packaging requires a original .tar.gz so i can not directly pull from the main branch
<silwol> ...i hope you understand what i mean
<NfNitLoop> aah.   Yeah, I'm not that famailiar with Ubuntu's packging process.
<NfNitLoop> keeping a separate branch for debian/ sounds like a good idea, since that doesn't have much to do with the original source.
<NfNitLoop> I vaguely recall that debian sources are packaged as the original.tar.gz, plus a debian.diff.tgz or something like that.
<dato> diff.gz, yes
<NfNitLoop> so you would zip up the source repo.   then diff your 'debian' branch to create the diff.
<NfNitLoop> beyond that, I'm afraid I won't be much help.
<silwol> okay, but thanks anyway, NfNitLoop
<silwol> i think i'll try to catch pitti when he is online
<dato> silwol: so you are the upstream author of the software?
<silwol> dato: yes, but it is not very advanced yet.
<silwol> just trying to package in order to get some people to try it out
<dato> silwol: and you will be maintaining the packages as well? or you intend for a separate person to do that?
<silwol> actually, i don't mind if it is me or somebody else on the long term. for now i just wanted to create packages, but if somebody else wants to maintain them, why not
<silwol> although i think i will in future need the knowledge about how to more often
<dato> well, then my advice would be:
<silwol> should mean about how to package
<dato> (1) when you create the upstream tarball for a release, never include the debian/ directory in it, if one exists in your repository
<silwol> that's what pitti told me too
<dato> and for where to keep debian/, you have several options
<dato> (2a) keep debian/ out of trunk, and have a packaging branch; you `bzr branch trunk packaging`, and `bzr add debian/` in packaging. when an upstream release happens, you `bzr merge ../trunk` inside packaging, and make any packaging changes as well there
<dato> I think that's the one prefered in Ubuntu
<dato> another one, (2b) would be to keep the debian/ subdirectory in its own branch, one that is not a full branch of the whole source
<dato> and then there is (2c), the one I use for my projects (since I'm also the maintainer), keep debian/ in trunk, at release time build the package from trunk, and if there is another upload to make while trunk has diverged, make the debian packaging changes in a new branch created from the release tag, and merge that back to trunk. it may look a bit messier, but I like it.
<dato> silwol: I guess I recommend (2a). do you have any questions about it, or about something else?
<keir> anyone other than lifeless familiar with the uses of the graphindex code?
<keir> i'm wondering if there's cases where you need to do a DFS type search, where you only care about the values and the ordering, not the actual keys encountered on the way
<silwol> dato: until here it seems okay for me, and i would prefer the (2a) way.
<silwol> dato: what confuses me a little bit is that the ubuntu packaging guide talks about having the source in a package-x.y.z directory
<silwol> dato: this means that i would have to rename my packaging branch each time
<silwol> dato: well, the directory where it lives
<dato> well, the real truth is it doesn't need to be named srcname-x.y.z (you'll just get a warning from dpkg-source if not), but it's good practice
<dato> do you see a problem in renaming it?
<dato> (you can rename it, or do `bzr branch packaging srcname-x.y.z` instead, commit in srcname-x.y.z and then `bzr push ../packaging` when finished)
<dato> (the latter approach seems a bit cleaner, because you can throw away the directory you built the package on after pushing)
<silwol> okay, that seems to make more sense to me.
<silwol> ...here some of the real benefits of a distributen versioning system seem to open up
<jelmer> NfNitLoop: yep, thanks
<NfNitLoop> Heh.  playing with svk....   it's got one central store that's based on svn.   If you're done with a project, there's no way to get rid of just that project's data without blowing away data for other projects.
<NfNitLoop> (afaik)
<keir> aren't bzr shared repos no different?
<keir> or would 'repack-dropping-empty-refs' take care of that?
<keir> my graphindex is going to be sweeeeeet!
<Treeform> hey can any one help me!  Is there a difference they way bzr handles text and binary files?  I think it handling one of my 100mb files as a text file and cosing massive mem usage
<NfNitLoop> keir: with bzr, you can easily create a shared repo for each project, then delete the shared repo & project all at once, not affecting your other shared repos.
<keir> oh
<NfNitLoop> keir: and even if you just used one central shared repo, I think I've read in here that there are tools to prune unreferenced changesets.
<keir> NfNitLoop, what i mean is, if you have a shared repo, then you decide you don't care about 2 of the branches, deleting them  doesn't remove the stuff in the shared repos which was only ref'd by those branches.
<NfNitLoop> ^-- see my last comment. :)
<keir> i was 90% of the way through mine when i saw yours so i finished and hit enter anyway :P
<NfNitLoop> I forget what they are.... but in the worst case you can create a new shared repo and migrate into there, then delete the old shared repo.
<NfNitLoop> inefficient, but at least *possible*.
<NfNitLoop> I mean, disk space may be cheap, but endlessly growing files still aren't a good idea, IMO.  :p
<keir> yeah
<ubotu> New bug: #137823 in bzr "bzr selftest failures and haning unit tests?" [Undecided,New]  https://launchpad.net/bugs/137823
<dato> aw, this new 'Committing revision x to "/path"' line that commits outputs is unexplainably getting on my nerves.
<keir> lifeless, are you around?
<keir> i'm confident i can make repacking the GraphIndex's super fast because AFAICT, old nodes are never changed; new nodes only refer to old ones.
<keir> because my new format is toposorted, repacking sould be 2x linear in len(pack1 + pack2 + ...)
<fullermd> Mmph.  I think "ghost filling" is the usual answer to that sort of thing...
<keir> ghost filling?
<fullermd> If you've got revs referencing ghosts, the graph cuts off at that point, but if the ghosts get filled that leg suddenly gets extended.
<keir> yes, that's exactly the algorithm i imagined in my head
<keir> is the pack format described somewhere? the parts that aren't the graph index
* fullermd has no earthly idea.
<fullermd> lifeless would be your best source for that I imagine, and I think he's mostly afk until next week.
<keir> yeah, ok
<keir> i'm tempted to go ahead and implement my new format in C
<keir> mercurial is beating us in popularity, and they have C
<keir> besides, the code i'm going to write is very general; it stores highly packed DAG's which are k->v and k->k*
<keir> it so happens that it's a perfect format for the ways bzr uses it
#bzr 2007-09-07
<grimboy_uk> Hey, is there a way to get bzr branch to get the latest revision first, copy it out so it's a working copy *then* get the history.
<grimboy_uk> ?
<abentley> grimboy_uk: No.  That would mean fetching a bunch of data twice.
<grimboy_uk> But it would also mean starting quicker.
<grimboy_uk> Since sometimes history takes ages.
<NfNitLoop> grimboy_uk: the only way to get the latest revision is to build it from the entire history, afaik.
<NfNitLoop> so your first step would:  1) fetch all the history, 2) make a working copy from it.
<NfNitLoop> then your second step would:  3)  fetch all the history.
<NfNitLoop> It works as it currently does for a reason.  :)
<NfNitLoop> It may work differently if/when horizon branches/checkouts are implemented.
<NfNitLoop> But my guess is that that would require a smart server.
<abentley> grimboy_uk: Fetching partial history is something that jelmer's working on.  But fetching the working tree, and then fetching all history as one operation doesn't make sense.  It takes longer.
<NfNitLoop> abentley: plus, not all repositories will have a working tree.
<NfNitLoop> and you can't rely on the working tree being up to date.
<abentley> NfNitLoop: Oh, fetching from the remote working tree would be total crack.
<NfNitLoop> aah, ok.  :)
<NfNitLoop> abentley: any idea how you'll end up with a working tree with a partial history, then?
<NfNitLoop> abentley: am I right in assuming you'll either need a smart remote server, or you'll still have to fetch the whole history?
<abentley> I was talking about fetching only the data to build the working tree from the repoistory, and then fetching all the data.
<abentley> NfNitLoop: No, there's no reason you'd need a smart server.  You just fetch what you want.
<NfNitLoop> abentley: wouldn't you possibly need the whole history of a file to rebuilt it in its current state?
<NfNitLoop> Sorry if I'm way off... I don't actually program vcs back-ends.  :)
<abentley> No.  The storage format has periodic snapshots of the complete text.
<NfNitLoop> Oh really.   As it is now?  Or as it will be with horizon support?
<abentley> As it is now.
<abentley> It's a performance thing.  We must not scale with the length of history.
<NfNitLoop> Yeah, I wondered about that.
<NfNitLoop> Hmm.  What's the (rough) algorithm for deciding when a new snapshot should be stored?
<NfNitLoop> is it per file, or per the entire repo?
<abentley> I don't know the current status.  Originally, it was every 25 revisions, but it might be "every time the size of deltas exceeds the size of the fulltext".
<abentley> It is per file.
<abentley> As it turned out, we do scale with the length of history, due to the indexes.  Which is the problem keir is working on.
<NfNitLoop> Hmm.  How so?   because the entire index must be read for an operation?
<NfNitLoop> And that's O(n) and not O(log(n))?
<abentley> NfNitLoop: Yes.
<abentley> The new pack format is designed to make recent data fast, at the expense of making old data slow.
<marcus> hi.  when I use a shared repository, is there anything I need to pay attention to when removing branches?  or should I just use rm -fR branch?
<abentley> rm -R branch should do fine.
<abentley> No need for the -f.
<abentley> There aren't any caveats, except that removing the branch doesn't remove the revisions you've committed.
<abentley> Just a pointer to them.
<NfNitLoop> abentley: I was talking about this earlier with someone.   Isn't there a command that will prune your shared repo?
<NfNitLoop> or was it a plugin?
<abentley> Yeah, there's a plugin.
<NfNitLoop> marcus: worst case, though, you create a new shared repo, branch your remaining branches over there, and delete your old/bloated repo.  (if its size becomes too big.)
<NfNitLoop> but that should only happen if you're working with lots of patches that you're throwing away.  (ie: rarely)
<NfNitLoop> lots of *big* patches.  :p
<marcus> NfNitLoop: you mean that is semantically what the pruning plugin does?
<marcus> thanks, guys.  I didn't check out all plugins.  It makes sense for a pruning operation to exist.
<abentley> marcus: Yeah, it does, but only for security or if you've accidentally committed an ISO.
<marcus> abentley: maybe I was just confused because I don't have the right mental model about internal details.  from a newbie point of view, it's more comforting if the operation that removes a branch is available through bzr, or at least documented that rm -R is safe.
<marcus> irregardless of pruning.
<abentley> Yeah, we should probably make it clearer that rm -R is safe.
<marcus> while I am here.  I recently imported an SVN repository, but not via bzr-svn but using a different stand alone tool (svn2bzr.py).  Trying to push bzr changes back to svn failed with an "no merge base revision specified", but I couldn't figure out how to set a merge base revision.
<abentley> marcus: Because you didn't use bzr-svn, you can't push back.
<abentley> Oh, netsplit.  Haven't seen that for a while.
<Peng_> 24.2 second lag. Wheee.
<Peng_> Usually I'm not on the wrong end of one.
<Peng_> 46.1-second lag! 18.2.
<igc> morning
<lifeless> hi abentley
<lifeless> abentley: I'm not here today :) - just whipping past
<abentley> lifeless: Okay.  I may have a CommitBuilder.abort patch for you in a bit.
<Basic> my osx has even stumped the gurus (for now)
<Basic> was hoping it was something specific to my box
<abentley> Are you the guy with the WoW?
<Basic> no comment :-P ... yes
<Basic> all my guild osx people are poking fun at me and how this line-x thing doesn't "work" under osx
<Basic> will work through some of the ulimit things I saw today. will do the selftest and get with ulimit on open files at 4096 and see what happens.
<abentley> Well, I'm the TreeTransform guru and I'm hardly stumped.
<Basic> oh? What's John's guru-ness? :-)
<abentley> John's guruness?  The patience diff code  and checkouts are the first things to come to mind.
<abentley> But I am the principal creator of TreeTransform.
<abentley> Anyhow, the first thing to do is disable TreeTransform.finalize().  It's masking the real error.
<abentley> Just edit transform.py and make finalize return early.
<abentley> Then rerun the operation that usually fails.
<Basic> I'll give it a try, thank you for the advice, rid here, I'll work on it on the commute home.
<keir> lifeless, ping!
<Peng> Speaking of patiencediff, <Peng> Hmm, easy way to run patiencediff on a directory? python -m bzrlib.patiencediff only accepts files.
<Peng> :(
<igc> keir: lifeless may not be around (much) today - public holiday
<keir> oh, i thought that was yesterday
<keir> aah timezones
<abentley> keir: I am serious when I say if you implement your graph index in C, we will not merge it.  We write in python first, and optimize in pyrex if justified.  Look how long it's taking your patience diff to get merged.
<keir> i did not write patience diff
<keir> and i'm writing it in python
<keir> so please, chill!
<abentley> You said you were very tempted to write it in C.  I wanted to be clear about this, because I didn't want you to write it in C and then be upset when it didn't get merged.
<keir> there has to be a python version because of all the funky transports
<keir> but i will write a C version for local disk, just not immediately.
<abentley> For compiled code, I think we have a preference for Pyrex over C.
<keir> well, the issue is that i can see this bit of code useful outside of bzr
<abentley> And it may well be that only a small section is performance critical.
<keir> in which case pyrex is out
<keir> but whatever, python first
<abentley> Cool.  Thank you for working on this.
<keir> i'm writing this up for the ML as we speak
<keir> i have a few questions before i send though
<keir> which you can prob answer
<keir> in the pack-based repo, what is different graphs are stored?
<keir> and what is the size / type of each bit of data?
<keir> rather, average number of edges out from a node, in from a node
<keir> i'm not looking for exact numbers, just trying to get a feel
<abentley> Well, there are four things we store: revisions, inventories, signatures, and file texts.
<keir> i've been working on the graphindex without *really* understanding the rest of bzr, because i enjoy these types of fast compact data structure problems
<abentley> revisions and inventories have the same graph layout and revision-ids.
<keir> ok
<abentley> file-texts are subset of the revision graph.
<abentley> You have one for each file, and it only gets a new revision when the file is modified.
<abentley> So given two nodes in a file graph, they have the same relationship as their corresponding nodes in the revision graph.
<keir> hmm, ok
<abentley> Take the NEWS file for an example.
<abentley> If NEWS is modified in revision A and revision B, there will be entries in its graph for those revisions.
<keir> i see
<abentley> If B is descended from A in the file graph, B will descend from A in the revision graph.
<keir> ok, i understand. so file texts are the revision graph if you eliminate all other files from the revision graph
<keir> or rather, the subset of the revision graph in which that file was modified
<abentley> I don't follow you.  Many files may be altered in the same revision.
<keir> so in the rev graph, the storage is revID->???, and edges are more revID's
<abentley> There is a graph for NEWS, another for builtins.py, another for README, etc.
<abentley> Yes, revision ids are the same in all of our graphs.
<keir> abentley, as in, if you imagine a graph is k->v and k->k*, for the rev graph, what are the values?
<abentley> For the revision graph A -> B -> C, let's say NEWS is only modified in A and C.  This means that the NEWS graph will be A -> C.
<keir> yes, i understand
<keir> so the rev graph has no actual values in each node? just the references to other revids?
<abentley> What are the values associated with nodes in the revision graph?
<keir> yes
<abentley> They are the commit metadata.
<keir> basically, I think my current graphindex is so cool we may want to store more than just an index in it :)
<abentley> Commit message, timestamp, commiter, etc.
<abentley> The cat-revision command should show you exactly what is stored for a revision.
<abentley> e.g. bzr cat-revision -r -1
<keir> ah, neat
<keir> woah, xml
<keir> do you actually store XML internally?
<keir> or lzw'd xml or something?
<abentley> Yes, we do.
<abentley> Don't hate us for it :-)
<abentley> I should draw your attention to the properties list; this is arbitrary data.
<keir> i'm usually with jwz on the quote 'some people, when faced with a problem, think "I know, lets use xml.". Now you have two problems.'
<keir> but whatever, this is fine
<abentley> See the header of xml_serializer.py for a similar sentiment.
<keir> ok, then my next question is, how is the rev graph stored on disk?
<abentley> It is stored in kndx files.
<abentley> The specifics of the knit index format are outside my area of expertise.  But you're working on replacing it, so it can't be altogether perfect.
<abentley> The implementation is KnitIndex in knit.py
<keir> ok
<abentley> The particular kndx is  revisions.kndx
<abentley> So revisions.kndx serves dual purposes: describe how to extract the revision XML for a given revision, and describe the revision graph.
<keir> ok
<abentley> You can call repository.get_revision_vf() to get an object to play with.  Or you can call revision.get_revision_graph to get a dict-style graph.
<abentley> Another thing about the revision graph is that it applies to all projects in a shared repository.
<abentley> Whereas the per-file graphs are almost always for a single project.
<keir> even though they are stored in the same file
<abentley> The per-file graphs and revision graph are not stored in the same file.
<abentley> (I'm not sure what "they" referred to)
<abentley> keir: When you come back, just say "abentley: ping"
<keir> (on phone 3 mins)
<keir> ok, back
<keir> as in, there is one big file-text file, even when the per-file graphs are for a single project
<keir> in a shared repo
<keir> abently: ping!
<abentley> keir: oops.  Needs "ey" at the end.  Anyhow, I'm back.
<keir> ah, heh
<keir> now i see that knitindex and graphindex are parallel :)
<abentley> There is not one big file-text file.  There is one knit & knit index per file.
<keir> aaah, ok
<abentley> They are identified by their file-id, which is used elsewhere in bzr to uniquely identify files.
<abentley> And because the file-id is semirandom, two projects containing a file named README will have different ids and knits for it.
<keir> even with the same contents?
<abentley> Yes.  Bazaar doesn't care about content the same way git and hg do.
<keir> is this a weakness or a strength?
<abentley> We consider it a strength, because it allows us to import from other systems losslessly.
<keir> and why would it be considered a weakness?
<abentley> To an extent, other systems will identify some tree-shapes as "the same" even when they were produced separately, and so bzr would consider them different.  This approach also provides obvious ways to validate a tree.
<keir> ok
<abentley> Anyhow, our current systems stores revisions, inventories, signatures and file texts separately.  Packs centralizes them.
<abentley> We still need different indexes, because our code expects them to be separate.
<keir> ok
<keir> why?
<keir> more accurately, what does the code need that can't be put in one file?
<abentley> In theory, a single file could store all four indices.
<abentley> It's the in-memory representation that needs to treat them differently.
<keir> the way i'm writing my stuff, the in memory representation can be (almost) the same as the on disk format
<abentley> In the current pack format, there's an adaptor that converts the index into an index for just a particular file.
<abentley> GraphIndexPrefixAdapter
<abentley> I think one reason for splitting them up is that they have different access patterns.
<keir> that's reasonable
<keir> and relevant to me; are they mostly repeated traversals?
<keir> right now, my stuff optimizes for that
<keir> aka follow links repeatedly
<abentley> Following the same set of links?
<keir> because in the 'dumb' implementation, that's exactly what's slow
<keir> as in, you are on file ref A, then you want to go to its successor
<keir> then that nodes' successor, and so on and so forth
<keir> and yes, same 'set' of links
<keir> in my version, there is only one graph represented (aka not multiple adjacency lists)
<keir> because then you can't order things nicely for repeated traversals
<abentley> Well, there are two kinds of access patterns: tree-wide and history-deep.
<abentley> "bzr checkout" would be tree-wide.  We want one copy of the text, for each text in the tree.
<keir> which is repeated DFS type of thing?
<abentley> So we build each text by finding the all the deltas until we hit a fulltext.  Then we apply the deltas to the fulltext to get the version we need.
<abentley> I'm not sure what DFS is.
<keir> depth first search
<keir> in my current code, that should be _very_ fast
<keir> one question: how do you decide which link to follow if there are multiple links?
<abentley> Yes.  Really, it's depth-only search, because only the lefthand ancestry must be traversed.
<keir> ok, i don't quite understand that
<abentley> Okay, do you know that Bazaar treats node parents differently depending on their position?
<keir> no! good to know
<abentley> You get multiple parents in merge situations, right?
<keir> i apologize for not knowing all this stuff
<keir> yes
<keir> OH! i think i get it
<abentley> So the lefthand parent is always the revision you had before you did the merge.
<abentley> That's how Bazaar does it, anyhow.
<keir> you creat a new edge from before the 'branch' which contains the merge diff
<keir> or am i talking crazy
<abentley> No, we don't do it like that.
<keir> say there's a file that branches, then on each branch there's a few revs, then it merges
<abentley> Okay, let's draw a quick graph: A -> B, A-> C, A->D, [C, D]  -> E
<keir> when you go backwards, how do you know which edges to traverse?
<keir> ok, i drew the graph
<abentley> Oops.
<abentley> I goofed on it.
<keir> :)
<abentley> Ignore A->B
<keir> and B itself?
<abentley> Yes.
<abentley> So the story is I commited revision A.  You branched me, and committed revision D.  At the same time, I committed revision C.
<abentley> Then I merged your branch, and committed the result as E.
<abentley> Because I did the merge, C is the lefthand parent of E.
<abentley> If you had done the merge, D would be the lefthand parent.
<keir> i see
<keir> and if there was another branch, F, taking the same path A->F->E
<keir> and you _also_ merged F, then it would be the same
<abentley> Yes.
<keir> even though there are edges c->e and f->e
<keir> ok
<keir> that's really neat
<abentley> Yes, heads are ignored in the parent list.
<abentley> Sorry.
<abentley> Only heads are *listed* in the parents list.
<keir> and that's to prevent repeated merging
<abentley> So [C, F, E]  becomes [C, E] 
<abentley> Oh, repeated merging still happens.
<keir> ok
<abentley> Anyhow, deltas also follow the lefthand ancestry.
<keir> so, to be clear, the left hand edge c->e implicitly contains the deltas a-> and a->f
<abentley> So for my graph, there is no E -> D delta, only an E -> C delta.
<keir> yes, exactly
<keir> the link exists but there is no delta change
<abentley> Right.  We could record it, but don't.
<keir> so in a pack, why not store all this consecutively?
<keir> for a single node, you store refs to your children, and some arbitrary edge-value
<abentley> So if A is a fulltext, we get A, apply A -> C, apply C->E.
<keir> it sounds like the new packs store the deltas in a big list, and then those are indexed in the GraphIndex
<keir> abentley, yes, i understand now. i was confused about the merging.
<abentley> That's the only possible recipe to produce E.
<abentley> So that's why *for building texts*, it's a depth-only search.
<keir> great
<keir> and that search would happen in the fulltext graph, which is a subset of the revisions graph
<abentley> I would expect that packs do store entries topologically-sorted, but not necessarily ajacent.
<keir> i imagine in almost all cases, the number of edges is < 5
<keir> in which case toposort would do pretty well
<abentley> Yes.  about 75% have only 1 parent.  I would guess less than 2% have more than 2 parents.
<keir> ok. is there many cases where you want to traverse the graph _without_ also grabbing the related diffs?
<abentley> We would do that when running "log".
<abentley> i.e. log FILE
<abentley> That's pretty rare.
<keir> ok
<abentley> We are still just talking about files here.
<keir> yes
<abentley> For revisions, we use the graph quite differently.
<keir> i am starving, i'm going to go grab something to eat; will you be around in 15 mins?
<abentley> Sure.
<abentley> Ping me.
<keir> great! ttyi15
<keir> abentley, ping!
<abentley> Hey.
<keir> look at that, xchat can spell better than me
<keir> so: revision graph usage
<abentley> Right.
<abentley> We use the revision graph for log all the time.  I think breadth-first is the right term for the "log" access pattern.
<abentley> Because we show all parents of each revision.
<abentley> Sorted topologically.
<keir> ok
<keir> actually i think that's a DFS
<keir> rather than a left-child-traversal
<keir> err, hmm. nevermind, you are right
<abentley> Okay.  I never studied graph theory.
<abentley> We also use the revision graph for merge base selection.
<abentley> This is done by merge, pull, push, update.
<abentley> This is again breadth-first traversal, but we stop when we hit an LCA.
<keir> LCA?
<abentley> Least Common Ancestor.
<keir> ah, ok
<abentley> So for this access pattern, incremental reads are a big win.
<keir> yes
<abentley> Ideally, the data is topologically sorted with newest data first
<keir> yes
<keir> this is what i have now
<keir> however, topological sort is ambiguous
<keir> there are many topological sorts for a given graph
<keir> my current plan is to take the left-link when doing the topo sort
<abentley> We do already have a topo-sort routine.
<abentley> (tsort.py)
<abentley> But yes, there may be gains in favouring left-parent ancestry.
<keir> ok
<keir> so, the tradeoff if you store all the data (diffs, etc) in with these graphs
<keir> is that in the merge case, you only want ancestry
<keir> it looks my design still makes a bunch of sense.
<keir> i'm going to send it out to the list
<abentley> Okay.
<abentley> I was only describing part of the merge process.
<abentley> The other parts have the 'checkout' access pattern.
<abentley> Making checkout as fast as it can be is definitely a goal.
<keir> oh :)
<abentley> keir: The first part of merge is you find a base.  Then you get three inventories and compare them.
<keir> three?
<abentley> Then you get selected file texts from two of the inventories.
<abentley> Yes, three: My tree, the tree I am merging, and the merge base tree.
<keir> ok
<abentley> Oops, actually, you get selected file texts from *three* of the inventories.
<keir> and then you do a three-way merge?
<abentley> Right.
<abentley> Though if only one side changed the file, we take that side's version without doing the equivalent of diff3.
<keir> ok
<lifeless> abentley: note that I've already replaced knit indices with index.py; keir is working on a better implementation of index.py
<abentley> lifeless: I know, but good point.
<lifeless> keir: It's nice that the generalised interface I crafted for bzr may be useful elsewhere, thats a good property. But the important thing to note is that that we are doing the work for bzr, so bzr's needs and process are paramount.
<lifeless> keir: nothing stops you later rewriting it to your hearts content :)
<keir> lifeless, i'm about 5 mins from sending out my design
<lifeless> re topo sort grouping
<lifeless> I would wager breadth first grouping is most suitable
<abentley> keir: So in your version of the file graph, you will have different subgraphs, one for each file.
<lifeless> but if its parameterisable that would allow benchmarking
<keir> lifeless, well, it's easy to test different strategies; we just re-sort and benchmark
<keir> ok. back to the email. i'll be back in a sec
<lifeless> abentley: also are you aware that in packs the compression tree and the ancestry graph are decoupled ?
<abentley> lifeless: I wasn't sure whether that was exposed.
<lifeless> abentley: so we can without changing the index format have arbitrary compression parents
<lifeless> abentley: its not somthing that knit.py is yet able to take advantage of, no. But it is exposed for folk that want to work directly on e.g. text_all_index for operations
<lifeless> s/format/logic/ two lines up
<lifeless> ok, I'm off again, drive by commenting done :)
<keir> hmm
<abentley> keir: Because the checkout pattern requires fast access to a lot of recent versions of a lot of texts, you would probably want the sorting to pay attention to where snapshots happen.
<abentley> So that it can switch files when it hits a snapshot.
<keir> so the fulltexts link back to previous revisions even though a checkout would stop at the fulltext?
<abentley> Yes, AIUI.
<abentley> In fact, the revision knit is all fulltexts.
<abentley> Yet we can use its graph.
<keir> well, the revisions only store metadata not actual file content do they?
<abentley> The XML you saw earlier is stored in the revisions knit the same way file texts are stored in file knits.
<keir> ok
<keir> sent!
<keir> we require python 2.4 right?
<AfC> keir: impressive post about Graphs to the mailing list the other day.
<keir> AfC thanks!
<keir> that was just a couple hours ago
<Peng> keir: Some bits (maybe just tests) require 2.4.
<Peng> keir: I assume it's mostly 2.3.
<keir> ok
<dato> Peng: afraid not.
<dato> keir: 2.4 is a hard requirements.
<Peng> dato: Oh, really? Okay.
<igc> night all
<dato> Peng: yeah :)
<dato> running `bzr upgrade` in a lightweight checkout makes a backup of the light .bzr, not of the real .bzr. would that be considered a bug?
<lifeless> no, because its upgrading the lightweight checkout
<dato> but it changes the "remote" branch as well
<lifeless> ok thats a bu
<lifeless> bug
<lifeless> it should only alter the lightweight checkout
<dato> okay, I'll double-check it does that, and file one
<abentley> lifeless: It would be nice to have a bit more API for handing branch references.
<lifeless> yea
<abentley> "bzr switch" has some pretty gross aspects.
<joe99> Is the Cygwin client broken?
<ubotu> New bug: #137976 in bzr "`bzr upgrade` in a lightweight checkout upgrades the parent branch" [Undecided,New]  https://launchpad.net/bugs/137976
<mwhudson> er
<mwhudson> oh right
<pygi> hello folks
<lifeless> joe99: not AFAIK
<alfborge> I've been using bzr for my module of a project for some time now, and finally the project as a whole has adopted bzr.  Is there a way I can merge my existing bzr repos with the project repos so that I keep my history?
<alfborge> I've got an existing Products/Timeline/.bzr which is the one I've been using.
<alfborge> Now there's a .bzr in Products...
<radix> alfborge: yeah, there is, it might be in a plugin
* radix tries to remember the command
<radix> hrmph
<radix> I can't find it :\
<alfborge> Me neither.
<radix> I think jam wrote it, but I guess he's not around.
<alfborge> join                 Combine a subtree into its containing tree.'
<alfborge> Might be it.
<alfborge> I don't really understand the helptext to join.  Could someone take a look at it and help me out?
<alfborge> Seems I need to create a branch and then join into this branch.  But it's not really clear to me exactly how to go about it, and where I should run the commands from (the target tree or the source tree) and so on.
<radix> alfborge: I don't think join is the one I used
<radix> alfborge: to be clear, you have two branches and you want to merge them into one, such that all the files in one are in a directory of the other?
<alfborge> I'm not really very familiar with bzr.  I did "bzr init" on the part of a code tree that I've been working on.
<fullermd> Is there overlap between what you've got in bzr and what's in upstream bzr now?
<alfborge> no overlap.
<fullermd> You can just use merge, then.
<alfborge> Now the whole tree has been done "bzr init" on by some other people.  So, I can no longer push my stuff upstream since my .bzr in that tree has been removed.
<fullermd> Do a big 'mv' in your branch so that the files are in $BRANCH/sub/dir where they should be in the main branch, then you can just 'merge' them.
<radix> huh, ok
<radix> maybe that's why that command I used isn't there any more
<radix> because it's obsoleted by 'merge' handling the case?
<fullermd> Well, I think John had some plugin once that basically did that, just automated.
<fullermd> Can't remember what it was called.
<radix> yeah, I used it
<radix> I can't either :)
* radix wanders off
<fullermd> I think it's mostly set aside because the nested trees stuff will take over handling that case.
<alfborge> I'm confused by the word branch.
<fullermd> (of which 'join' is to be a part, but it's currently hidden because it's not really done)
<alfborge> I'm used to CVS, so I've learned to avoid branches like the plague.
<fullermd> And good training, in that environment   ;)
<alfborge> So, if I get things correctly, I've now got the root/Products/Timeline (upstream bzr) and I've got my Timeline (which is it's own root).
<alfborge> Should I remove the Timeline-dir from the upstream and replace it by my Timeline-dir and then do a merge, or did I misunderstand completely?
<fullermd> Mmm.  What's in the upstream Timeline dir, and what's in yours?
<alfborge> Only difference is that mine has a .bzr dir in it.
<alfborge> Oh, and I have a few local changes that wasn't commited when they made the repos.
<fullermd> Ah.  So you lied earlier   :)
<fullermd> There is overlap.
<fullermd> That makes things harder.
<fullermd> Your problem now is that you have two different branches that have the same files in them, but they're different files (See?  That's clear, right?)
<alfborge> Yeah, pretty much.
<fullermd> So, conceptually, what probably needs to happen is for your changes to get replayed against the upstream files.
<alfborge> fullermd: Let's keep this simple.  I can roll back my repos to match the version in the upstream.
<fullermd> You _could_ delete the upstream files, and stick yours in their place.  That's one solution.  You lose the upstream history though, and set up trouble if anybody else is working on them before merging your changes.
<alfborge> I'm the only one working on that part of the project.
<alfborge> And the upstream repos was created about an hour ago.
<fullermd> Hm.  Has anything changed in the upstream repo since then?
<alfborge> nope
<fullermd> Was that a conversion from an existing VCS, or just a fresh 'init ; add ; commit'?
<alfborge> I believe they did an init; add; commit
<fullermd> That has promise.  If we can arrange to throw away that new upstream repo and recreate it, we can probably slip by nicely.
<alfborge> upstream is at revno 7, I'm at revno 60
<fullermd> Mmm.  Harder.
<fullermd> Well, you can rm the files in the upstream and replace them with yours.  Not much history to lose there, if any.
<fullermd> Or you can manually apply your changes to those upstream files and commit it, then discard (or archive) your branch.
<fullermd> Hard to say which would be "better", really.
<alfborge> I don't see how I lied earlier.  If I uncommit my last commit, my files are identical to the upstream files.
<fullermd> Oh, it's just one commit?
<alfborge> So I can uncommit that, make a patch file and revert my repos to the state it was when the upstream made a snapshot of it.
<fullermd> Heck, I'd just redo that in the upstream then.  You can tar up your old branch somewhere for back-reference if you need it sometime, and otherwise just ignore it and move n in the upstream.
<alfborge> Yeah, throwing away my history is a solution.  But it's sad. :)
<fullermd> Well, the other option is the "rm those files upstream ; merge".  That keeps your history there.
<fullermd> If nobody else is editing those files now, it won't cause conflicts.
<alfborge> fullermd: Ah, there we go.  That's what I'll do then. :)
<fullermd> The only real downside is the kidna "uncleanliness" of having those files from the first 7 revs be different files than in the future.  Probably only of interest to archaeologists.
<fullermd> So, in your branch, make a commit with all the files moved into a throwaway temporary dir (myfiles.tmp/ or something), just to have them conveniently out of the root for the merge.  (you could skip that if it's just a few files, but it can make it easier if there's a lot)
<fullermd> Then rm away the files in the upstream, merge your branch in, and bzr mv them into place.
<alfborge> Is there a difference between bzr copy and bzr co?
<Odd_Bloke> alfborge: Yeah, 'co' is short for 'checkout'.
<alfborge> Which is not a branch?
<alfborge> Or rather, it doesn't create a branch?
<Odd_Bloke> alfborge: It creates a branch which is bound to the checkout location.
<Odd_Bloke> alfborge: That is to say, some operations will affect the checkout location (commit, for example), unless specifically directed not to.
<alfborge> Good to know.  I think I'll stick with branch. :)
<alfborge> And push my changes when I'm ready.
<Odd_Bloke> alfborge: The only difference between 'checkout' and 'branch' is that the former creates a bound branch and the latter an unbound one.
<Odd_Bloke> You can switch between the two using 'bzr bind' and 'bzr unbind'.
* fullermd has come to agree with the desire to stab the "bound branch" terminology right straight through the heart.
<mwhudson> fullermd: do you have better ideas?
<fullermd> Not referring to a checkout as a branch.
<mwhudson> it is, though
<fullermd> Not really relevant   :p
<Radtoo> Hi. I just installed bzr and used tailor to migrate my svn repository (contains many blobs) to bazaar. But that inflated the repository from 360MB to 1.5GB. Is that normal or did I do something wrong?
<NfNitLoop> Hmm, I'm not familiar with tailor.
<keir> Radtoo, have you tried bzr-svn?
<Radtoo> keir: that doesn't even compile here, so no :/
<Radtoo> tailor appears to pull from svn version by version and then commit it into bazaar... but I can't be entirely sure :D
<NfNitLoop> if bzr-svn works, it sounds like the ideal solution.  If you "import" (branch) with it, you can easily keep it in sync with the svn repo and even commit back to it.
<keir> we're working on pack repositories, which i believe will actually make bzr repos smaller than svn's
<keir> but they're not ready just yet
<Radtoo> I see, atm this is normal then?
<NfNitLoop> *shrug*
* NfNitLoop eyes keir. 
<fullermd> Probably, especially with big files getting changed a lot.
<jelmer> NfNitLoop: can you try the 0.4 branch again, I've fixed some http bugs.
<NfNitLoop> jelmer: *heart*
<NfNitLoop> trying now. :)
<NfNitLoop> If I get disconnected, it means my box is too busy thrashing to answer TCP packets.   (Whee, memory leaks!)
<jelmer> (-:
<jelmer> a --limit option to svn-import may be a good idea
<NfNitLoop> Yeah... I was looking for one.
<NfNitLoop> are you saying it's a good idea for me to use?
<NfNitLoop> or for someone to implement?  :)
<jelmer> rather for someone to implement, it's not there yet
<jelmer> ideally, I should just fix the memory leaks...
<jelmer> but tracking them down is hard and there's at least one in the python subversion bindings
<NfNitLoop> I need to get a job that doesn't suck my will to live (and program) so that when I get home I'll actually want to code on some of this.  :)
<Radtoo> I see. Well I'll love to try the packed variant once it's ready :D
<Radtoo> BTW, I have tried Git and it also doesn't get that part quite right ;)
<NfNitLoop> jelmer: I still get:  bzr: ERROR: Invalid revision-id {None} in SvnRepository(...)
<NfNitLoop> this branch?  http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
<NfNitLoop> It seems weird to me that using svn-import, I still have to do svn+https://     (wouldn't svn+ be implied?)
<keir> Radtoo, what do you mean? the packed repos don't work well for git?
<NfNitLoop> keir: I think he means that git repos are much larger than svn ones.
<dato> Radtoo: I guess the repository contains a fair amount of binary data?
<keir> whaa?
<keir> i hear that git repos were really tiny
<NfNitLoop> keir: maybe I guessed wrong, then. :)
<keir> that the entire gcc history was a 300mb git repo, but 17 gigs in svn
<dato> maybe he didn't repack
<Radtoo> keir: yep, as compared to svn.
<Radtoo> dato: yes. many (said that before tho :P)
<dato> Radtoo: ah, I missed it, sorry
<Radtoo> keir: I did run git-gc and stuff and nothing made it grow to 810MB, still a lot larger than the 360MB from SVN.
<Radtoo> I suppose such repositories are quite the challenge to handle :D
<keir> actually, they are not so hard, but the SCM must recognize and support binary deltas
<keir> old svn used to store entire copies of binary files with each rev
<keir> not sure if they fixed that now
<NfNitLoop> I'm pretty sure nowadays svn treats all files as binary and does binary diffs.
<Radtoo> I think they deltify almost everything against everything or something like that
<Radtoo> Otherwise I doubt that huge mess of a repository I have would be so small
<dato> NfNitLoop: yeah, I belive that's it
<NfNitLoop> which is one of the reasons we chose it for our current project.  (Lots of binary files that needed revision control.)
<keir> what is the 'signature index'?
<Radtoo> NfNitLoop: So SVN worked best for you out of all you tried?
<dato> keir: revisions can be gpg signed, so I guess it's that?
<keir> ok
<NfNitLoop> Radtoo: well, svn was really the only thing that met our needs.   Free, works well with binary files, supports file locking, has a friendly GUI for teh n00bs.
<keir> svn does have the benefit of 5+ years of robustness hacking
<Radtoo> NfNitLoop: I don't need the friendly part, but otherwise I guess I'll have that particular repos stay on svn.
<NfNitLoop> For personal projects I've migrated to bzr.
<Radtoo> True. I do expect bzr to be better in 5+ years tho. ;)
<keir> yes, i am quite confident the choice will be easy in 5 years :)
<keir> though i suspect bzr will never have lockign
<NfNitLoop> keir: heh.  I wouldn't expect it to.   Hard to do that w/ a distributed development model.
<keir> if bzr got really solid binary support, i could see someone building a locking plugin which would talk to some central server for lock status
<keir> the reality is, you NEED locking for working with binary files (photoshop files, etc)
<fullermd> And then I can see large hoards of people storming that someone's house in the night, and parading their intestines up main street   ;p
<NfNitLoop> not really.
<NfNitLoop> Good communication > locks.  :)
<Radtoo> I personally don't, tbh :D
<NfNitLoop> though, again... hard to do that in a distributed environment.
<fullermd> Well, that's a fundamental limit case.  If your environment is too distributed to manage the communication necessary for project management, then your environment is too distributed.
<Radtoo> What if it's not "a project"? ;)
<fullermd> Hard-coding the communication into the VCS tool doesn't help that.
<NfNitLoop> yeah, I'm thinking of some OSS tool that has a repo published via HTTP.
<NfNitLoop> Two new people just download it and implement changes that happen to touch the same file...  then there's no way to merge them back together.
<NfNitLoop> I guess there, your "communication" comes in at the upstream maintainer.  :)
<Radtoo> Ye if the content isn't known to anyone but a proprietary tool... then either that tool can, or no one?
<NfNitLoop> Radtoo: eh?
<fullermd> Locking wouldn't help that, though.  Even if magic occured and somehow it were all distributed locked...   all that would happen is that only one person could make their change.
<fullermd> Which is equivalent to the case that you only accept one of those person's changes (except that you get to choose the better one, rather than just the first   ;)
<NfNitLoop> fullermd: right.  I'm not the one proposing locking. :)
<NfNitLoop> I'm just saying that very distributed projects don't always have good communication, since anyone can take your code and start modifying it.
<NfNitLoop> it doesn't make the project bad.
<NfNitLoop> or "too distributed".
<fullermd> That's not quite what I meant...
<fullermd> My assertion is that if your project (for whatever real or imagined reason) needs tight coordination, you shouldn't be spreading it around like that.  By doing that spreading, you're asserting that you don't need lockstep among developers.
<fullermd> So, yes, a project _can_ be "too distributed", if the development environment they've set up isn't consistent with the constraints on the development.
<NfNitLoop> ah, yes. agreed.
<fullermd> (and of course, a project can be too centralized, if the development environment is twisted into lockstep when no real constraint requires that)
<NfNitLoop> which is what my current project feels like. :p
<NfNitLoop> (work project, that is.)
<NfNitLoop> the binary files require this very centralised development.    But we've got quite a bit of source code in there too.
<NfNitLoop> But I guess I should just be glad I got them away from VSS.  :p
<jelmer> re
<fullermd> I'm sorry, my mental gag filter blocked out that last line you sent...
<NfNitLoop> Yes.  That's right.  Until I arrived, they were using The VCS That Shall Not Be Named.
<jelmer> NfNitLoop: are you specifying any additional arguments to svn-import?
<NfNitLoop> and it took me *months* to convert them.
<NfNitLoop> jelmer: nope.   Though I am running it inside a shared repo.  Should I not?
<jelmer> NfNitLoop: did you rm -rf the target repository after updating today?
<fullermd> There once was a time when I held fast to the belief that using _any_ VCS, no matter how crap, was preferable to using none at all.  Said system (through second-hand experience, thankfully) showed me the error of my ways.
<NfNitLoop> the old, broken attempt at an import?  yes.  :)
<jelmer> NfNitLoop: what version of bzr are you using?
<NfNitLoop> fullermd: Yeah.  I love a VCS where users can *permanently* delete history from it.  :p
<NfNitLoop> Bazaar (bzr) 0.90.0
<dato> a
<dato> oops
<jelmer> NfNitLoop: trying to reproduce..
<jelmer> abentley: ayt?
<jelmer> NfNitLoop: this seems fixed in bzr.dev somehow, I'm currently trying to figure out why
<NfNitLoop> jelmer: This is against the repo that I sent you.
<NfNitLoop> jelmer: Hmmm.   but you reproduced it with 0.90?
<jelmer> NfNitLoop: I reproduced it with 0.90 against the repo mentioned in bug 137710 (which is the same issue you're seeing) but can import fine using bzr.dev
<NfNitLoop> jelmer: interesting.
<NfNitLoop> jelmer: well, how close is 0.91 to coming out?  Maybe you should just make it a requirement for bzr-svn if it's coming out soon.  :)
<jelmer> re
<jelmer> NfNitLoop: I don't think 0.91 is all that close yet. I'm trying to figure out if there is some way to work around the issue in bzr-svn itself.
<NfNitLoop> jelmer: aah, that would be cool.  :)
<dato> I thought the RC was next tuesday.
<asabil> hi all
<keir> wth? zlib only does 1mb/s on my laptop?
<keir> ahah
<keir> right, it's decompression speed that matters
<keir> on my laptop, which is a fairly moderate 1.7ghz centrino, i can decompress at 75mb/s
<asabil> is there any good bzr web interface out there ?
<sabdfl> asabil: i think the best one is loggerhead
<asabil> so there is nothing better ? and something maintained ?
<asabil> :/
<sabdfl> asabil: https://code.launchpad.net/loggerhead
<sabdfl> check it out, there's activity there as we speak :-)
<asabil> oh great
<asabil> the weblink in the list of 3rd party tools links to quite old stuff I think\
<asabil> thanks a lot :)
<sabdfl> sure
<sabdfl> nice way to see what's going on in a project, that
<asabil> which branch you suggest I check ?
<asabil> the devel or production ?
<keir> wow, your two names are impossible to disambiguate at a glance
<keir> i thought mark shuttleworth was talking to himself
<asabil> lol
<dato> there should be an irssi plugin that would use alternate colors for adjacent nicks with the same length
<Basic_py> When you do a bzr checkout --light-weight, does this mean you cannot go back to this local repository and do a bzr pull to get updates from a remote repository?
<dato> Basic_py: you can run `bzr pull` inside a lightweight checkout (in fact, you can run all operations there). it will update the "parent" branch, though.
<keir> phew, that was a long email
<mdke> hiya, I'm quite new to bzr and am feeling my way around still. I'm merging from a branch and there is a conflict, is there a good doc about how to resolve conflicts?
<beuno> mdke, the bzr docs has a good one, are you using 0.18?
<mdke> beuno: 0.90.0
<beuno> mdke, then in the bzrdir/doc/en/user-guide
<beuno> there's a file called conflicts.txt
<beuno> I'm sure it's on the bazaar webpage somewhere, but I can never find it
<dato> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<mdke> I'm reading http://doc.bazaar-vcs.org/latest/en/user-guide/tutorial.html at the moment, has something stuff
<beuno> that's it  :D
<beuno> http://doc.bazaar-vcs.org/bzr.0.90/en/user-guide/conflicts.html
<beuno> to be precise
<mdke> I was hoping bzr would do the merging for me, it looks like it doesn't from that page
<radix> mdke: it does do most merging for you
<beuno> it just needs a bit of help when to lines of code conflict
<radix> mdke: you have to resolve any *conflicts* that happen during merge
<beuno> dato, thanks btw  :D
<dato> mdke: if there are changes to the very same lines, bzr can't know how to solve such conflict
* beuno bookmarks it once and for all
<dato> short of reading your mind
<dato> beuno: you're welcome
<mdke> radix: I mean, I was hoping it would resolve conflicts for me, given a bit of input from me
<dato> ah, and that reminds me
<radix> not sure what that means
<dato> mdke: what kind of input?
<mdke> in this case it's a very simple file
<mdke> I want to keep both my changes and the changes in the branch
<dato> mdke: bzr tried to do that, but failed because your branch and the other branch *change the very same lines in different ways*
<mdke> ok, bzr knows best I guess. I am surprised because the file is so simple and I thought that the changes I made were just to add lines rather than change some. I may be misremembering though
<mdke> yeah, i did just add lines to the end of the file, annoying
<beuno> mdke, that's weird then, it shouldn't complain
<beuno> it's actually saying there are conflicts?
<beuno> "bzr conflicts"  complains?
<mdke> yeah
<beuno> mdke, did bzr generate a conflictedfile.BASE?
<mdke> yeah
<beuno> mdke, the conflicted text should be listed there
<mdke> yes
<beuno> does it make sense?
<beuno> :D
<mdke> well, no :) not to worry, I've resolved it manually
<beuno> heh, ok ok, bzr isn't that random normally
<mdke> :)
<entoll> Hello
<entoll> Is that normal that under Windows, bzr selftest fails on a few dozen tests?
<lifeless> keir: 1mb/s ? what were you using GzipFile ?
<lifeless> keir: also, I got your reply, but you didn't cc the list - do you mind if I forward it back to the list ?
<keir> lifeless, i just noticed that and sent it to the list
<keir> lifeless, let me know if it shows up for you
<keir> lifeless, any thoughts?
<keir> lifeless, also it was 10mb/s compression; i dropped a 0
<lifeless> heh
<lifeless> so
<lifeless> were you testing using python?
<keir> yes, with zlib
<lifeless> The GzipFile interface ?
<keir> import zlib; zlib.compress(big_100mb_string_here)
<keir> with a time set/check around it
<keir> not sure what GzipFile is
<lifeless> ok
<lifeless> have you seen the timeit module?
<lifeless> http://bazaar-vcs.org/RobertCollins has some examples showing its use
<lifeless> basically
<lifeless> python -m timeit -s 'one_hundred_million_bytes= "A"*1024*1024*100' -s 'import zlib' 'zlib.compress(one_hundred_million_bytes)'
#bzr 2007-09-08
<lifeless> GzipFile is a wrapper around zlib in python that does what gzip does
<keir> one sec on phone
<lifeless> robertc@lifeless-64:~$ python -m timeit -s 'one_hundred_million_bytes= "A"*1024*1024*100' -s 'import zlib' 'zlib.compress(one_hundred_million_bytes)'
<lifeless> 10 loops, best of 3: 2.64 sec per loop
<keir> cool
<keir> lifeless, what do you think? or you haven't finished your coffee :)
<keir> i have to run, i'll be back in ~5 hours
<keir> i'm going to be on a bus, i'll probably implement some stuff while i'm in transit
<lifeless> jbailey: long time no see!
<jbailey> lifeless: Yup, finally settling enough to visit.
<jbailey> I understand that I missed your wife here on my first day.
<lifeless> how's the babe?
<lifeless> oh shame
<jbailey> I couldn't get out of the orientation to sneak off and visit Leslie, though. =)
<jbailey> He's terribly cute.  Much happier to not be stuffed into a car seat every day, though. =)
<lifeless> you drove all the way?
<jbailey> Yeah.  We've put 3600 miles on the rental vehicle.
<jbailey> Mmm.  Civilized measurements that's.. mm
<lifeless> so thats what, 48 hours of driving ?
<jbailey> 5500km or so?
<jbailey> Probably a touch more.
<jbailey> It was about two weeks, most days about 4 hours of driving.  Some with none, some with 6 or 7.
<Odd_Bloke> lifeless: As someone who's not particularly familiar with the innards of bzr is the work that keir is doing ATM aimed at reducing disk usage, decreasing computational overhead or a combination of the two?
<BasicOSX> I did a bzr checkout --light-weight http://foo/bar/
<BasicOSX> no when I cd into bar and do a bzr pull I get issues about read-only?
<BasicOSX> bzr: ERROR: bzrlib.errors.UnlockableTransport: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.eqenchanters.org/WoW/AddOns/.bzr/repository/>
<thatch> BasicOSX: yeah, that's because it's trying to pull _into_ the thing you did a checkout of
<thatch> do you mean to 'bzr up' instead?
<Odd_Bloke> BasicOSX: You want 'bzr update'.
<Odd_Bloke> Too slow. :(
<thatch> mere seconds, Odd_Bloke...
<BasicOSX> Can you point me to a url where it explains diff between pull and update? I assume a checkout --light-weight means bzr expects no changes will happen in that area and it's more or less r/o?
<thatch> BasicOSX: if you have r/w access to the branch that it's bound to, doing a commit will write directly to that, and doing an update will read from it.  It's like push/pull but on a more svn-like scale.  I'm not sure if there's a good url... Odd_Bloke?
<Odd_Bloke> thatch: I've been looking around and there doesn't seem to be a brilliant explanation anywhere...
<thatch> halfway down http://bazaar-vcs.org/SharedRepositoryTutorial I find a decent set of steps
* fullermd considers his ML post on component description to be applicable   :p
<thatch> I tried googling and didn't come up with anything, is it linked from the bazaar-vcs wiki?
<BasicOSX> I'll take a look at that, thanks
<fullermd> Hm.  I think I'll steal that for a followup, actually, as a case in point.
<lifeless> Odd_Bloke: keir is working on the index for pack repositories
<lifeless> Odd_Bloke: I wrote a toy one, so that I could do some major restructuring vs knit repositories
<lifeless> Odd_Bloke: with the intent of a) finding a victim^Wvolunteer to write a better one, or b) coming back later and doing a better one myself.
<calvin_> hello, how do i set up bzr to use a proxy in ubuntu?
<calvin_> anyone?
<calvin_> anyone alive at all?
<fullermd> I think it checks a standard env variable, for HTTP at least...    HTTP_PROXY or http_proxy or something like that?
<calvin_> yes, i know that much, but don't i need to put it into a config file?
<fullermd> I'm pretty sure it'll read it out of the environment.
<fullermd> There may be a config file option for it as an alternate choice...  not sure.
<calvin_> what do you mean 'read it out of the environment?
<calvin_> do you mean it might detect my gnome proxy settings?
<fullermd> I mean read the env variable, if it exists.  I dunno if gnome works via that or not; that's pretty far off my path.
<NamNguyen> hi
<NamNguyen> is there a service wrapper for bzr on windows?
<Radtoo> You want to run bzr as windows service?
<NamNguyen> yes i do
<Radtoo> as in "bzr serve" or something else?
<NamNguyen> yes
<NamNguyen> as bzr serve
<Radtoo> Hmm, I haven't seen such a thing so far, tho I'm not doing this with windows either.
<Radtoo> I figure you could use srvany...
<hstuart> NamNguyen, you should be able to use this to run bzr serve as a service: http://agiletesting.blogspot.com/2005/09/running-python-script-as-windows.html  though I'm not running Windows so I haven't tested it. Caveat emptor and all that stuff.
<NamNguyen> thanks hstuart, i'll check it out
<Radtoo> oh you found a full howto. :D
<hstuart> amazing what a google for python windows service can turn up ;)
<Radtoo> I see. :p
<Radtoo> Tho looking at the tutorial, it's also amazing that you have to edit the registry, use one or many additional apps etc just to run a script as service :D
<hstuart> Windows does pretty much everything through the registry, so I'm not terribly surprised by that
<Radtoo> I guess it was expected that everything setup related is handled by installers... hehe
<keir> lifeless, around?
<abentley> keir: unlikely at this hour in Australia.
<abentley> He usually shows up in around four hours, but not very often on weekends.
<keir> yes, i just checked world clock :)
<abentley> keir: $ TZ=Australia/Sydney date
<mathbr> Hi. How can I tell bzr to ignore one or more files in a local branch no matter what happens? Those files should never ever be invoked in merge's and send's.
<abentley> mathbr: You should not "bzr add" files if you don't want bzr to merge or send them.
<abentley> You can use "bzr remove --keep" to un-add the files.
<mathbr> And then they won't get touched when, let's say, someone modifies those files in the original repo?
<abentley> Right.
<mathbr> I'll try that then, thanks.
<abentley> The first time you pull or merge, after the files have been removed, they will be deleted.
<mathbr> Hm... Just saw that the deletion is also visible in a send... I don't want it to appear there either...
<abentley> It's a one-time thing.
<mathbr> How to get to the second-time?
<abentley> copy the files before merging/pulling them.
<mathbr> I did changes to some local files and want to create a patchfile now but without the deletion of that other file
<abentley> Well, if you just want to create a patch, you can do "bzr diff".
<abentley> That lets you specify which files you want to include.
<mathbr> I know. But I was told to create a branch and to patches via send to make merging easier.
<abentley> So either create a patch with just the files you want, or do a send, and deal with the fact that these files are gonna be deleted.
<mathbr> I'll look into that, thanks.
<abentley> Or else, shelve the changes to the files, commit a new revision, send that, and unshelve.
<mathbr> I'd have to do that for each commit, right?
<abentley> Well, I'm assuming you've already committed these changes to the local files.
<abentley> In the future, you can avoid committing changes to those files.
<mathbr> Ah well, I'll just return to a normal checkout and drop my branch.
<mathbr> abentley: Thanks for your help and bye
<abentley> No problem.
<keir> is there a reason KeyboardInterrupt isn't caught at the top level?
<abentley> It would suck if you couldn't ^C out?
<keir> no, as in, i get a 5 page traceback
<abentley> That's not typical.
<keir> rather than 'bzr: interrupted'
<keir> it happens for all my tests when i hit C-c right away after hitting 'enter' on the command
<keir> also: my repository should never be broken if I do a ctrl-C partway through, correct?
<keir> on any operation?
<abentley> Well, you may be ^C-ing too early, but that's still surprising.
<abentley> It's always safe to ^C.  The worst case, if you do it while writing to the repository, is that you'll get some unreferenced data.
<keir> oh, but that won't get caught and cleaned up?
<abentley> No, repository operations are strictly append-only.  Cleanup would violate that and increase the risk of data corruption.
<jelmer> 'evening keir, abentley
<keir> morning!
<jelmer> abentley: has anything changed in the is_ancestor() code since 0.90 ?
<abentley> Hi jelmer.  Was there something you wanted to ask me?
<abentley> I'm not aware of any changes to is_ancestor.
<jelmer> abentley: It is trying to call get_revision(None).parent_ids in 0.90 but works fine in bzr.dev
<abentley> Are you passing None in as a parameter?
<jelmer> I'm pretty sure I don't, but let me check..
<abentley> 'cause we did do a whole bunch of changes where we stopped returning None for the null revision.
<abentley> So if you're passing in Branch.last_revision, or Tree.last_revision, that might have been None in 0.90
<jelmer> abentley: ah, you're right
<jelmer> Yes, I am passing in the result of Branch.last_revision()
<jelmer> thanks!
<abentley> You can use revision.ensure_null to fix it up.
<abentley> No problem.
<jelmer> I would expect Branch.last_revision() to return NULL_REVISION in this case though. Why is it still returning None?
<abentley> The NULL_REVISION changes landed in two batches.
<abentley> First was input, second was output.
<abentley> Because the output changes are API breaks.
<abentley> Branch.last_revision has returned None since the first release of Bazaar.
<jelmer> ah, makes sense
<keir> wow, is bzr share (aka zeroconf support) going to be targetted for upstream inclusion?
<mwh> oh crap, i meant to mention that in my talk
<mwh> oh well, i ran out of time anyway
<keir> bzr share is the type of polish that can make someone impressed enough to switch
<keir> has anyone considered build a 'branch registry' for umbrella projects with communities of developers?
<keir> s/build/building/
<keir> where bzr itself would know about the project (rather than just a branch or single repository)
<keir> and you could do things like bzr list-community-branches
<keir> bzr branch community://packs-refactor
<keir> or maybe bzr branch project://branch-name
<keir> is it possible for transports to be added as plugins?
<luks> with python it would be quite hard to _not_ make it possible :)
<abentley> Certainly: WebDAV is already implemented that way.  And see the lp: plugin
<keir> aah, ok
<keir> abentley, is there a page for the lp: plugin?
<abentley> No.  It comes with Bazaar.
<keir> i see register-branch, but that's it
<abentley> bzr help launchpad
<keir> neat
<nir> Some tests fail on Mac OS X
<nir> FAIL: test_sftp_transport.SFTPTransportTestRelative.test__remote_path
<nir>     not equal:
<nir> a = '/tmp/testbzr-xN4cVR.tmp/tmpRpl0nW/work/relative'
<nir> b = '/private/tmp/testbzr-xN4cVR.tmp/tmpRpl0nW/work/relative'
<nir> The test is broken - /tmp is symlink to /private/tmp :)
#bzr 2007-09-09
<keir> sweeeeet, got my compact dictionary building code to work
<NfNitLoop> Hmm, when I do 'bzr pull <http-location>' bzr is complaining that paramiko isn't complained, and shows me an sftp url.
<NfNitLoop> (a saved pull URL that I used long ago.)
<NfNitLoop> Shouldn't specifying a location argument to pull override that saved location?
<jelmer> NfNitLoop: hi
<jelmer> NfNitLoop: that bug that only appeared in 0.90 should be fixed now
<jelmer> NfNitLoop: no, it will only override if you specify --remember
<NfNitLoop> jelmer: not even for that run?
<NfNitLoop> I don't want it to remember... I just want it to pull from a different location.
<jelmer> yes, it should always use it for that run
<jelmer> isn't the branch you're pulling to bound by any chance?
<NfNitLoop> Hmmm.  possibly.
<jelmer> bound to that sftp url, that is
* NfNitLoop checks.
<NfNitLoop> I forget where bound info shows up, but I don't see the word "bound" in the results from "bzr info".
<NfNitLoop> Oh... it does say "checkout of branch sftp://"
<NfNitLoop> that would be bound, eh?
<jelmer> yup
<NfNitLoop> and you can only pull from a bound branch.   That should probably give you an error message then.  :)
<jelmer> NfNitLoop: no, you can pull from the http branch
<NfNitLoop> (er, rather, if you're working from a bound branch, you can only pull from that one.)
<jelmer> but it will update both the local branch and the branch it's bound to
<NfNitLoop> jelmer: Aaaaaah.
<NfNitLoop> so it wasn't failing on the pull... it was just failing on syncing back to the checkout.
<jelmer> if the error message is confusing, that'd definitely be a bug
<NfNitLoop> Hmm.  It makes sense now.  I just hadn't worked with this branch in so long that I didn't realize I'd bound it over sftp.
<NfNitLoop> jelmer: bzr: ERROR: Invalid revision-id {None} in SvnRepository
<NfNitLoop> :(
<NfNitLoop> Oh, DUH.
<NfNitLoop> it would help if I put the new version in my plugins directory.
<Peng> nir: Yeah, I've noticed the same thing on Linux. I guess it could use os.path.abspath('/tmp') or something?
<NfNitLoop> jelmer: yay, worked!  :)
<nir> Peng, maybe
<nir> The test also fail here with OSError - too many open files
<Peng> Heh.
<nir> unless I use ulimit to allow more than 256 open files
<NfNitLoop> jelmer: Though... I'm unable to push:  python: /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical(component, clen)' failed.
<Peng> My ulimit is set to 1024 files, and that freaks out Opera sometimes. Dunno if I can change it, though.
<nir> Is this the default?
<Peng> nir: Well, I didn't change it.
<Peng> Anyway, I'm not on OS X.
<jelmer> NfNitLoop: if you run with -Dtransport -Dcommit, what are the last few lines in ~/.bzr.log ?
<NfNitLoop> svn get-latest-revnum
<NfNitLoop> svn ls -r 0 ''''
<NfNitLoop> (the first one is repeated 5 times)
<NfNitLoop> need more?  I could e-mail it.
<jelmer> what url did it connect to ? I don't need the full URL but just the bits after the repository location
<jelmer> including trailing characters
<NfNitLoop> there are not bits after the repository location... just the closing '
<jelmer> NfNitLoop: is there a trailing slash after the repository location?
<jelmer> NfNitLoop: what location do you specify when you try to push?
<NfNitLoop> no trailing slash.   I'm pushing to 'svn+https://<repo>/trunk'
<NfNitLoop> 'bzr info' show that "push branch" and "parent branch" are identical.
<jelmer> NfNitLoop: and the ls -r0 is the last line  before the crash?
<NfNitLoop> yep.
<jelmer> NfNitLoop: please update the plugin and try again, I think I've fixed it
<NfNitLoop> jelmer: 'k. :)
<NfNitLoop> I hope it's OK to just leave a bzr repo in ~/.bazaar/plugins/svn.   It makes it easy to stay up to date. :)
<NfNitLoop> jelmer: Success!
<NfNitLoop> Thanks for all your help.  :)
<NfNitLoop> Now, all of that was on my test repo.    Any suggestions on checking out my large one that keeps crashing?  :p
<jelmer> NfNitLoop: is that still crashing?
<NfNitLoop> I haven't tried it with these latest changes.
<NfNitLoop> think I'd have better luck?
* NfNitLoop goes off to start it.
<jelmer> yes, I think it should work now
<jelmer> the http support in bzr-svn has been a bit unstable because there's no testsuite for it
<NfNitLoop> Hmm, let me shut down X first to give it a bit more room to play in. :)
<jelmer> in *theory* it should behave exactly the same way that the other transports do, but there are subtle differences
* fullermd can't believe somebody just said "no testsuite" on #bzr.
<jelmer> in theory, the abstraction in python-subversion should take care of it
<jelmer> fullermd: I don't really feel like bootstrapping apache, webdav and subversion as part of the bzr-svn testsuite.. :-)
<NfNitLoop> I also just learned that you can use checkout to create a wc in the repo directory.  (That just seemed... wrong, for some reason.)
<fullermd> Pfft.  As if that's an excuse.  You gotta be committed, man!
<fullermd> Think of it this way; if you bootstrapped svn in the test suite, we wouldn't need to worry about trying to get a patched version installed on our systems; just run the test suite, and it installs it!
<NfNitLoop> What was the issue with needing a patched version of svn, anyway?
<jelmer> the subverison python bindings are horribly broken in earlier versions of svn (< 1.5)
<fullermd> Does the trunk now have all of the fixes integrated?
<jelmer> fullermd: yep, that's where I originally fixed python-subversion
<NfNitLoop> Hmm... about 20% done and my computer's still responsive.  :)
<NfNitLoop> I should probably invest in more RAM for that machine anyway.  It's so old now I but whatever ram it uses is cheap. :p
<fullermd> The rate fabs are turning over, it's probably more expensive than the fastest new stuff  :p
<NfNitLoop> doh!
<fullermd> I've looked a couple of times at faster CPU's for this machine, but it would be cheaper to completely replace the motherboard, even including RAM.
<NfNitLoop> hehe, wow.
<NfNitLoop> aha!   I can ctrl-c, then go do a "bzr pull" to continue, before the leaky python-svn library eats up my ram. :)
<jelmer> yup
<NfNitLoop> Doh.   bzr: ERROR: exceptions.AssertionError:
<jelmer> where?
<NfNitLoop> .bazaar/plugins/svn/fetch.py", line 306, in close_file assert checksum is None or checksum == actual_checksum
<NfNitLoop> trying to resume.
<NfNitLoop> Hrmm, well, the resume hasn't failed yet.  Bad checksum it seems?  *shrug*
<jelmer> NfNitLoop: hmm, strange
<NfNitLoop> jelmer: seems to be working OK now.  :)
<NfNitLoop> jelmer: if a branch is created in the subversion repository at a later point in time...
<NfNitLoop> how would I go about checking out that branch in my bzr repo?
<NfNitLoop> just bzr branch svn+https://<repo>/branches/the-branch  in the shared repo directory?
<NfNitLoop> what I'm wondering is if it would be smart enough not to re-fetch all of the history in that case. :)
<jelmer> NfNitLoop: yep, just bzr branch will work
<jelmer> it won't refetch history it already has
<keir> anyone here familiar with the transport code?
<keir> i'm designing a stand-alone compact dictionary format
<keir> but i'm going to reuse it within the graph itself
<keir> so this serialization will be embedded
<keir> can i make a 'view' on a file with a transport?
<NamNguyen> hi abentley, is there a plan to let BundleBuggy support more than one branch locations?
<NamNguyen> i could imagine that detecting for which branch a merge request is will be a problem
<Odd_Bloke> NamNguyen: Do you mean have a single BundleBuggy instance pick up merge requests for, for example, bzr and bzrtools from the same mailing list?
<NamNguyen> that is correct
<NamNguyen> Odd_Bloke, and if you have looked at BB's code
<NamNguyen> there is a tool to automatically mark merge requests as "merged"
<NamNguyen> it would need to support multiple branches too
<abentley> NamNguyen: No immediate plans.  Merge directives do include a target branch, so the only problem is that people don't send merge directives with useful target branches.
<abentley> But for patches or plain bundles, there's no way to know.
<NamNguyen> the recommended practice is to make a local branch from bzr.dev, then branch from that local branch to make changes
<NamNguyen> in that case, isn't the target branch pointing to the local bzr.dev?
<abentley> If there is a public location for the target branch, the public branch is used in the merge directive.
<abentley> Have a look at any of my merge directives, and you'll see http://bazaar-vcs.org/bzr/bzr.dev as the target location, even though I used a local copy of bzr.dev
<Odd_Bloke> Can bzr nickname remote branches like git does with 'git remote add <name> <location>'?  For reference, you can then do 'git fetch <name>' which is equivalent to 'git fetch <location>' (or so is my understanding).
<gakster> hi all,   i have tried to learn the difference between DARCS distributed method and Subversions centralised.... but is there anyone who might like to try to explain it to me again. I am still confused
<gakster> all I understand is that with the distributed method, every copy of the files is a repository of an equal level, and patches are shared amongst users
<gakster> with subversions centralised method.... there is one MAIN repository,  and everyone works throug that
<gakster> is there more to it than that?
<Peng> gakster: With the centralized model, there's one repository, and only certain authorized people can commit to it. In the distributed model, everybody has his own repository and can commit to it and put it on a server for other people.
<Peng> gakster: One benefit of the distributed model is that since the VCS has to merge changes between different peoples' branches frequently, it has to be damn good at it.
<Peng> gakster: That's purely the technically differences. Socially, the distributed model is way better (IMO and with one or two exceptions, of course).
<pygi> distributed model also allows you to merge patches from people, and credit it to them. Where in svn if someone who doesn't have commit access and sends you a patch, you commit it, and therefore it looks like you did it
<pygi> s/merge/cherrypick
<gakster> in what social situations is centralised better than distributed?
<gakster> what if i want to use version control to just keep track of changes to my website..... I dont need multiple copies of my website... i just need one repository
<pygi> gakster, distributed is much easier as in most cases you don't need a special server
<pygi> bzr, git, mercurial ... distributed, without server
<pygi> svn, cvs, perforce ... centralized, need server
<gakster> I like the idea of not needing to install a server..... this is a positive of distrubted
<gakster> does anyone know why the http://darcs.net/ webpage has been crashed for a few days now?
<pygi> for bzr however there is smart server if you wish, that allows improvements in performance
<pygi> not really, this is bzr channel =)
<gakster> sorry, dont know who else to ask :-)
<gakster> i congratulate bazaar for having a webpage that doent look ugly.... it is important for people like me who are more graphical windows users... well done!
<gakster> also great that you have some NON technical documentation
<gakster> does anyone have a suggestion as to the best windows GUI.     I am looking for simplicity and ease of use. And nice pretty colours for diff reports
<pygi> gakster, Olive? :)
<pygi> well, there's this bzr-gtk that should work, and it includes Olive
<pygi> and all the other cool things
<gakster> what about http://bazaar-vcs.org/TortoiseBzr   how is this different from bzr-gtk
<pygi> it's something like tortoisesvn
<pygi> I'm not aware of it's staus
<pygi> status
<gakster> I have downloaded and installed the standalone windows install of bazaar.....    for me to be able to use olive and other br-gtk....  it says i need to have a python based install, and need a bunch of other dependencies? is this right?
<gakster> sounds too hard for me
<MaSch> Hi
<MaSch> maybe its a stuid question, but i never worked with svn-systems befor so, how i use this? So if i have a server, where all the files are stored and where bzr runs, how i edit them and upload them back to the server?
<MaSch> and sorry for my bad english
<MaSch> so with bzr branch <url> i get the files to my local machine, but how i upload them to the server?
<jelmer> bzr commit
<jelmer> followed by 'bzr push'
<jelmer> 'bzr commit' records the changes
<jelmer> 'bzr push' uploads the changes
<MaSch> okay thanks
<MaSch> its that easy.. nice..
<dirker> Hello :) How good is bazaar suited to host a project with source aswell as binary files? I'm minly thinking of merges and compression of the history.
<mdke> I'd like to try and create a patch which spans several revisions I've made to a branch, but not others; is that possible?
<pygi> mdke, cherrypicking?
<pygi> mdke, if that's what you think, then yes, you can do it
<mdke> pygi: how?
* pygi thinks
<pygi> cherrypicking needs to be improved in bzr, but :
<pygi> bzr merge -r 81..82 ../bzr.dev
<pygi> perhaps this should do the trick?
<pygi> just an example
<mdke> pygi: I need to create a patch though...
<pygi> mdke, well, do cherrypicking, and the do a diff against the original tree?
<mdke> ah, interesting.
<mdke> thanks, I'll look into that
<pygi> mdke, yw
<phanatic> mdke: maybe bzr diff -r X..Y ?
<Odd_Bloke> phanatic: That'll diff between the two revisions.
<mdke> phanatic: I'm going to try pygi's because it will help me get a patch that I can apply cleanly against the original branch (I've made quite a lot of other changes to the branch which I don't want to include in the patch)
<phanatic> mdke: sorry, i misunderstood you a bit :(
<mdke> np
<rents> hi, do i have to recompile everything after doing "bzr up"?
<rents> always
<pygi> o.O
<pygi> what do you want to recompile?
<rents> if i am updating something
<Odd_Bloke> rents: You always have to recompile a project if the source code changes.
<Odd_Bloke> rents: Assuming it's a project which requires compiling.
<Odd_Bloke> Whether this is through you editing a file or 'bzr update' modifying a file is immaterial.
<rents> then i should now figure out if this project really needs recompiling
<rents> exaile in this case
<pygi> rents, it doesn't
<pygi> exaile is written in python
<rents> and won't need it?
<rents> <- total newb
<Odd_Bloke> rents: Python doesn't require compilation, it's an interpreted language.
<pygi> why dont you ask adam?
<rents> ok, that's all i wanted to know
<rents> thank you guys
<rents> bye for now
<ubotu> New bug: #138437 in bzr "Cannot revert single files via olive" [Undecided,New]  https://launchpad.net/bugs/138437
<mdke> pygi: I'm trying your method, the first revision worked well, but now I'm trying to apply another revision and it won't let me without committing the changes
<mdke> pygi: is there any way around that?
<dato> no, but you can commit in a throwaway patch, which you can remove after generating the diff.
<luks> you can use --force
<dato> oh.
<mdke> I'll try; I can't commit anyway because I did a checkout
<luks> but it's probably better to have it as multiple commits and then generate diff over the range of new commits
<luks> oh
<mdke> wow, --force has done the trick
<pygi> ;)
<mdke> and the revisions have applied cleanly \o/
<pygi> mdke, see? :)
<mdke> that's pretty awesome
<mdke> shame the code doesn't work
<pygi> mdke, well, I'm off to dinner, but if you need anything poke
<mdke> pygi: thanks, I think I've got there, just have to fix the code
<pygi> mdke, kk, congrats ;)
<ubotu> New bug: #138439 in bzr "Cannot select multiple files and execute a command in olive" [Undecided,New]  https://launchpad.net/bugs/138439
<phanatic> heh
<phanatic> olive bugs filed under bzr, nice
<ubotu> New bug: #138446 in bzr "Cannot import from svn" [Undecided,New]  https://launchpad.net/bugs/138446
<luks> ... and bzr-svn bugs files under bzr :)
<luks> *filed
<pygi> phanatic, fix it =)
<MaSch> whats olive?
<Odd_Bloke> MaSch: A GTK frontend for bzr, I think.
<MaSch> okay thanks
<pygi> Odd_Bloke, you're right
<ACSpike[Home] > hello
<pygi> hi ho
<Odd_Bloke> If I'm branching into a shared repository (from a remote branch) is there any way to resume after interruption?
<dato> the fetched revisions will be present in the repository, so remove the branch and rebranch
<lifeless> moin
<lifeless> jelmer: ping
<lifeless> dato: ping
<dato> lifeless: pong
<lifeless> hi
<lifeless> bzr packages for gutsy are going to be updated real soon now
<jelmer> lifeless: pong
<lifeless> where you planning on a bzr-svn 0.4.2 upload to sid today ?
<jelmer> lifeless: the debian branch is up to date
<lifeless> jelmer: package not branch.
<lifeless> I use the terms advisedly because of the various processess involved
<jelmer> lifeless: ah, right
<lifeless> now, I can upload bzr-svn to debian if you are happy with the packaging.
<lifeless> thats kinda trivial :)
<jelmer> lifeless: yup, please do
<dato> lifeless: ok. you needed something or were just telling?
<lifeless> dato: if you were doing a bzr-svn upload I would not do one
<lifeless> dato: I was coordinating
<dato> ah, good. just fyi it'll prevent bzr 0.90 from getting to testing, but I don't think that's happening anytime soon either because of a failed mipsel build.
<lifeless> dato: I'm not worried about testing right now :) - why will it prevent it though ?
<dato> prevent in less that 10 days, I meant
<lifeless> jelmer: http://bzr.debian.org/pkg-bazaar/bzr-gtk/unstable ? seems out of date
<lifeless> oh crap
<lifeless> bzr-svn doh
<keir> lifeless, ping!
<lifeless> hi
<keir> i wrote the dictionary builder
<keir> and am 1/3 way through the reader
<keir> it's compressed btree
<keir> lifeless, do you have couple mins to chat about it?
<lifeless> sure
<keir> ok
<keir> i branched from bzr.dev instead of packs.knits
<keir> but the code is contained in two files, so it should be easy to switch
<GaryvdM> jelmer: I've been hacking away at viz. I've finish a proof of concept that loads the revisions incrementaly.
<GaryvdM> It's published here: http://bazaar.launchpad.net/~garyvdm/bzr-gtk/vizchanges
<keir> lifeless, so what i have is just like i described in the 2nd email regarding a separate dictionary
<keir> except that if the 'index' block is larger than the block size, it recurses
<GaryvdM> There are still some bugs in the code to work out where the lines need to be - Some of the lines are drawn on top of each other.
<lifeless> I think that makes it a b+ tree :)
<keir> lifeless, oh. heh
<keir> hmm, i'm lacking a webserver
<lifeless> you probably want to merge it with packs and do some adhoc testing yourself
<lifeless> (keeping your branch separate and unmerged is fine; I just mean have a copy that is integrated)
<siretart> hi lifeless
<siretart> lifeless: do you plan to update bzr in gutsy?
<keir> lifeless, ok
<lifeless> siretart: see above
<siretart> oh, sry
<lifeless> siretart: the answer is yes, but someone needs to do the uvfe dance for about 6 packages
<lifeless> bzr bzr-gtk bzrtools bzr-svn bzr-rebase bzr-builddeb all need updates IIRC
<siretart> lifeless: in past releases, there were no uvfe reports for bzr packages
<lifeless> in the past we were not updatng 3 days before beta
<siretart> ah, ok
<keir> lifeless, pushing my branch now. it's still based off bzr.dev until i have at least the dictionary functionally complete
<keir> we gotta fix that progress bar
<keir> it's so totally useless
<fullermd> If we just got all operations completing in under 5 seconds, we wouldn't need a progress bar.
<keir> working on it!
<lifeless> fullermd: the internets are slow
<lifeless> fullermd: pushing 2G of data >>>> 5 seconds
<fullermd> Well, can't we just rewrite the slow parts in C?
<keir> fullermd, the problem is the data formats (i think?)
<keir> push is going on 4 minutes now
<lifeless> keir: fullermd is our resident troll-resistance-tester
<lifeless> keir: initial push is slow for knits because of round trip latency on each knit
<lifeless> keir: if you are using sftp, its either 3 or 4 round trips per file, and 2 files per knit.
<keir> aaah!
<lifeless> packs are only 20% slower than rsync
<keir> sweet
<keir> does sftp do its own compression?
<keir> regardless of whether we speed things up, i still want nice progress bars
<jelmer> GaryvdM: cool
<jelmer> GaryvdM: I'll try it out this week!
<keir> aaaag only 2 modified files and push is still going
<keir> 8 minutes now
<keir> lifeless, i'm thinking of building a 1st version that does away with the separate storage for the graph
<keir> and just packs the keys (as dumb strings even!) into the dictionary
<keir> since it should be very easy to code, i figure it's a worthwhile experiment
<keir> is there a benchmark suite waiting for me to try out?
<lifeless> that sounds very close to the toy index, just with a B+ tree rather than bisectable array.  :)
<lifeless> some of the benchmarks may help, but really for this size data - no.
<keir> lifeless, sftp://mierle@bazaar.launchpad.net/~mierle/bzr/compactgraph; not done the push yet. i'll be back in 1/2 hr
<lifeless> to test it out I'd suggest converting bzrlib to packs using it
<lifeless> and then trying things like :
<lifeless> bzr cat
<lifeless> bzr log FILENAME
<lifeless> bzr merge
<keir> ok
<keir> i tried the dogfooding instructions, and it didn't work when i tried to branch the pack version
<keir> which is why i branched bzr.dev
<keir> brb in 15
<lifeless> we have a corrupt data item, which is noted in the followup mails about dogfooding
<lifeless> jelmer: where is the bzr-svn tarball ?
<jelmer> http://samba.org/~jelmer/bzr/bzr-svn-0.4.2.tar.gz
<lifeless> also, consider signing the targz please
<lifeless> I can quite easily construct a tar.gz which when piped through gunzip -c | gpg verifies
<lifeless> but when tar xzf'd does something different
<lifeless> jelmer: ^
<jelmer> I'd rather be consistent with the way I have to do other releases, but I'll consider it for 0.4.3
<lifeless> jelmer: what other releases require this?
<lifeless> oh, your debian branch has the packaging mixed with the code?
<jelmer> lifeless: it's the convention for samba projects
<lifeless> hmm
<lifeless> well, try creating a tar that overrides /boot/grub/menu.lst
<jelmer> lifeless: yep, makes it easier to diverge a bit from the main branch without having to use quilt or anything
<lifeless> and then cat that tar before your release tar as two gzip streams
<jelmer> well, I do suggest running gpg on the actual unpacked tarball rather than piping through gunzip but I see your point.
<lifeless> I encourage you to change the samba release process
<lifeless> create two tarballs
<lifeless> sha1sum *tar.* > listing
<lifeless> gpg --clearsign listing
<lifeless> or something like that
<lifeless> should be no harder
<lifeless> same number of gpg sigs
<lifeless> easier for users to validate the content (don't need to unbzip2 or whatever)
<jelmer> well, it does add an extra step running sha1sum for the user and comparing that to the sha1sum in the listing
<jelmer> The actual number of users downloading the signature is a bit disappointing
<fullermd> Just slip a trojan into a release.  That'll encourage them.
<keir> lifeless, did manage to get that branch?
<NfNitLoop> *sigh*  getting PyCrypto onto Windows w/ python 2.5 is turning out to be non-trivial.
<lifeless> keir: haven't tried yet
<lifeless> keir: I am focused on commit performance right now, I'll happily look at your branch when you're a bit further along, or if you would like specific feedback
<lifeless> jelmer: +1 step -1 step +security :)
<keir> lifeless, ok, cool. just looking for overall thoughts on my design before i get any further
<keir> i'd rather fix design issues early
<keir> see compact_graph.py
<lifeless> keir: I think you have those via the list :)
<lifeless> but sure, I'll do a pull later today
<keir> maybe it is better to wait until i have it running
<keir> ok, nevermind then, i'll make it go then mail it to the list.
<lifeless> hmm, I will pull and peek :)
<lifeless> but mailing the list is always good :)
<lifeless> damn missed abentley
<keir> lifeless, so for initial commit, are you speeding up the pack-based commit?
<lifeless> yes
<lifeless> I can commit a 550MB tree with 55K files in 1m48 user time
<lifeless> bzr.dev is about 10 minutes IIRC
<keir> sweet!
<keir> how long is git and hg?
<lifeless> hg is 1m user time
<lifeless> 1m30 wall clock, my test code is 2m2 wall clock
<lifeless> git I'm not sure right now
<keir> that's pretty decent
<keir> do you think we can beat hg?
<lifeless> dunno
<lifeless> I'm sure we can make the speed difference unimportant
<lifeless> we don't claim to be the fastest system, only the nicest.
<lifeless> 'only' :)
<keir> :)
<keir> i imagine we can get most ops to within 20% of hg and git
<lifeless> I'm aiming to be no slower than twice targz
<lifeless> for initial commit
<lifeless> which is incidentally faster than hg IIRC
<keir> cool
<keir> what approach are you taking to making the initial case so fast?
<keir> are you special casing it?
<lifeless> profile
<lifeless> analyse
<lifeless> change
<lifeless> test
<lifeless> repeat
<lifeless> not as such no
<keir> that's good
<keir> is the 1:48 figure with some pyrex?
<lifeless> nope
<keir> wow, nice
<lifeless> no pyrex, commit -q
<keir> would there be any benefit to combining add * and commit?
<lifeless> yes
<lifeless> though add is very fast
<keir> i still want a single command 'GO' which adds all non-hidden files and commits
<keir> init + add + commit
<lifeless> heh
<lifeless> you can do that trivially in a plugin
<keir> i know :) and i will, just not today
<keir> i'd like it to be upstream, rather than a plugin
<keir> so you can show peoplle how easy bzr is
<lifeless> well
<keir> right now it's as easy as 1) init 2) add 3) commit
<lifeless> thats an extremely special cased situation
<keir> but with go, it's as easy as 1) go :)
<lifeless> commit -A is something I think is agreed on
<lifeless> which is add/remove automatically during commit
<keir> perhaps init -A?
<lifeless> it would have to live on init I think if we were to do such a special case
<lifeless> btw, I dunno if you know but you can import tarballs directly
<keir> woah, i didn't know that
<lifeless> its in bzrtools
<lifeless> but I have been thinking its such a nice thing we could move it in
<keir> +1 on that
<keir> when i look at my use of bzr, it's always 'bzr init; bzr add .; bzr ci -m"Initial commit"'
<keir> so i don't see the point in not having that as a single command
<lifeless> you must start lots of projects :)
<keir> i version little stuff, because it's so easy with bzr
<keir> with svn it's annoying
<keir> ok, i'm out on the bus
<dato> I agree to that
<keir> we'll see if i can get dict reading working by the time i get back from TO
<dato> creating lots of independent branches for not-so-big stuff
<keir> lates
#bzr 2008-09-01
<lifeless> ok, no poolie yet
<lifeless> spiv: stand hup ?
<spiv> lifeless: sure
<spiv> skype or pots is fine.
<lifeless> you and I can skype, and I'll skype out to get poolie
<Odd_Bloke> Why do Canonical use Skype rather than a free VoiP solution?
<Odd_Bloke> Or is it just the case that everyone in Canonical uses Skype, without there being any sort of policy?
<lifeless> skype works
<lifeless> we have an asterix server
<jml> hi
<jml> (again)
<jml> I'd like to get the stacked-on url for a branch without opening a branch.
<jml> I'm guess I should open the bzrdir for the url and do something from there?
<Verterok> jelmer: I can't upload to bzr-svn, maybe need to be in the bzr-svn team?
<Verterok> jelmer: anyway, I uploaded both dmg's to: http://verterok.com.ar/bzr-svn
 * jml experiments
<jelmer> Verterok, you should now be in the team
<spiv> vila: great work on finding and fixing the pycurl select/poll bug.
<Verterok> jelmer: ok, uploading to launchpad :)
<jelmer> Verterok, thanks!
<Verterok> jelmer: np, now I need figure out hot to include both versions in the bzr dmg
<rocky> what is the typical way to control read/write access with bzr smart server?  perhaps proxy it with apache and use htpasswd based auth ?
<jearl> rocky: it depends on what you want to do.
<jearl> rocky: I think typically people use bzr+ssh if they have complicated requirements for who can read and write.
<rocky> i'm thinking more about replacing a svn+apache+dav setup
<rocky> is there more involved docs for serving up bzr (particularly with the smart server) than just the little section at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server ?
<jearl> I know I've seen something, but I can't remember where.
<jearl> one second
<jearl> OK, I can't find the docs I was looking for, but you can, of course, use htpasswd based authentication to control access to your smart server.
<rocky> right... atm tho i'm having trouble setting up the smart server, period ;)
<jearl> That's part of the reason that bzr+ssh is so popular.
<rocky> well, for this particular project, setting up shell users for each committer isn't an option ;)
<jml> rocky: at the moment, that's your only option if you want to provide write access to branches with the server.
<jml> well, not true.
<jearl> No, there are other options.
<rocky> --allow-writes
<jml> you could use Launchpad, or you could set up PQM.
<rocky> the smart server supports --allow-writes
<jearl> You could also do writes via FTP (assuming you can create FTP users)
<jml> rocky: but that 'allow writes' means that anyone who can access the port would have write access.
<rocky> jml: yes... that's what the apache htpasswd access is for
<jml> it's not a web service though.
<rocky> i thought it was a simple wsgi app
<rocky> the smart server, that is
<jml> no. the smart server is a custom server with a custom protocol.
<jml> well
<jml> you can get bzr+http access
<jml> but that's readonly, afaik
<rocky> ok google's broke, can't seem to find better bzr smart server / http serving docs
<jml> the ones on bazaar-vcs.org are the best there is, I think.
<jml> rocky: there's the possibility that I've said something wrong also :)
<rocky> ;)
<jml> rocky: you don't have to give people remote shell access in order to let them run 'bzr' via ssh, you know.
<jml> they still need an account on the machine, but you can deny them a shell
<lifeless> jml: spiv: mail for you
<markh> would it make sense to add a param to tree.auto_resolve() that tells it not to perform the actual resolution, meaning it would return what files it *could* auto-resolve?
<markh> (picture a GUI 'resolve' tool - ideally it would list all files in conflict, but put checkboxes (or otherwise distinguish) only the ones that can be auto-resolved)
<Peng_> lifeless: Someone else already wrote a different log --limit patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080831160826.GA28292%40mutt.xyzz.org%3E
<Peng_> He added a different test too.
<spiv> markh: a dry_run=False param?
<markh> spiv: yeah
<lifeless> Peng_: I prefer mine :P
<markh> spiv: how was the snow?
<spiv> markh: If there's no better way to discover the auto-resolvable files (and I'm guessing there isn't), then it makes sense to me.
<spiv> markh: slightly bruising :)
<markh> I can't see one - that function has a local regex and string literals it checks the 'conflict type' against.  Duplicating that would be fragile...
<markh> spiv: bruises are to be expected I expect :)
<lifeless> well
<spiv> markh: more bruising for my wife.  It turns out that knee pads mean that instead of vicious bruises covering most of the knee, you get mild bruise covering the *entire* shin.
<lifeless> its a bit of  LBYL thing
<lifeless> Why mark those you can autoresolve
<lifeless> why not autoresolve and show the remaining conflicts
<Peng_> lifeless: The other patch's unit test simply tests how many revisions were returned. What about adding that to your test and going with that?
<Peng_> Oh, i see.
<Peng_> Oh, i just noticed that you added a blackbox test, while the other patch didn't.
<markh> lifeless: I'm slightly concerned that is "too magic" - a user sees a file as 'conflicting' - they right-click and hit 'resolve' - but then the list of files presented doesn't include the one they selected!
<lifeless> Peng_: I didn't add any tests; I changed a insufficient test into a sufficient test :P
<lifeless> markh: 'resolve file' means 'mark it resolved no matter what' in the CLI
<markh> and presenting the remaining conflicting ones in the dialog isn't useful - they can't meaningfully resolve those that are left from that dialog anyway
<markh> lifeless: yeah, I understand that
<markh> lifeless: but the CLI has a terminal it can print meaningful messages to
<lifeless> markh: I don't understand the problem I guess
<markh> lifeless: I guess the question is about the user's expectation if they hit 'resolve conflict' on a file marked as being in conflict
<lifeless> markh: it should resolve it, always
<lifeless> markh: because they should only see the file being in conflict if it is
<markh> lifeless: ok - so they select that on the root of the working tree
<markh> you are saying "auto-resolve and list the remaining ones"
<markh> in effect saying "there is no resolve dialog - just a dialog with a result of what files were auto-conflicted"
<lifeless> no
<lifeless> there are broadly three sorts of conflicts
<lifeless> conflicts bzr can tell when they are resolved
<lifeless> conflicts bzr can't tell when they are resolved
<lifeless> conflicts that have been resolved but bzr hasn't checked yet
<lifeless> if you have a resolve dialog, which of these three sets are useful to show ?
<markh> phrased slightly differently: what does the user expect to happen when 'resolve conflicts' is selected from the menu?
<lifeless> right
<markh> my thought was "show all conflicts, which checkboxes against ones able to be auto resolved"
<lifeless> fugly :)
<markh> we have a similar concept now - eg "qbzr ci filename" shows *all* modifications, but only 'filename' checked
<markh> similarly for resolve
<lifeless> I think its ugly because it means the user has to think more about what the ui is telling it
<markh> yes, I agree it might not be obvious
<lifeless> is there ever going to be a different choice for the user than 'yes, the X boxes are right' ?
<markh> I'm not sure it will be obvious though to auto-resolve all conflicts before evein showing them the dialog, and then only showing them the rest.  It means 'cancel' won't actually cancel anything
<markh> for a file bzr can't auto-resolve but the user has resolved it, the user would check that specific item
<markh> I'm slightly uncomfortable with "well do some magic in the background before asking you to go further"
<lifeless> well
<lifeless> use cases
<lifeless> 'I want to resolve a conflict bzr can't auto-resolve'
<lifeless> 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder'
<markh> and the most common 'I want to resolve a conflict bzr can auto resolve'
<lifeless> why is that a use case?
<lifeless> I think its a use case because you have a different one you haven't articulated, which is 'I want to keep something that is conflicted, that auto-resolve would unconflict, marked as a conflict'
<markh> because the user edited a file to remove the conflict, but the item is still showing as being in conflict
<lifeless> that is covered by 12:52 < lifeless> 'I want to run 'bzr resolve' - resolve everything it can and show me the remainder'
<markh> the user wants to tell tbzr to show it correctly now please
<markh> IMO the user is specifically focused on a single source file
<lifeless> why wouldn't tbzr show it correctly automatically ?
<markh> I'm not sure the users will expect a conflict cycle of "fix one conflict, attempt to resolve entire tree, fix next conflict, repeat..."
<lifeless> I think this is like the status discussion
<markh> I personally work more like "fix one, resolve one, fix next, resolve next"
<lifeless> its a YAGNI driven by performance concerns
<markh> no - its user expectations and workflows
<markh> notihing about perf at all :)
<lifeless> ok
<lifeless> so you save the file
<lifeless> and tbzr marks it as unconflicted
<markh> we have one menu with scarce real-estate.
<lifeless> no need for a menu item so far
<markh> I think we are simply disagreeing on user expectations
<markh> I should probably take it to the tbzr and qbzr mailing lists and try to form a consensus :)
<lifeless> please keep bazaar@ in the loop
<markh> ok
<lifeless> I'm on neither of the GUI lists, and I'm not sure Martin or Aaron or others are either
<lifeless> I would say that if you want a single file resolve, do that; don't conflate that with tree wide auto resolve; you can refactor bzr's auto resolve to a per-file basis to use it there if you want as well
<lifeless> I certainly don't think that bringing up a tree wide menu if you are doing single-file workflow makes any sense, but that is what you seemed to be proposing
<markh> I'm proposing that like TSVN, any directory with conflicting items would have a 'resolve' item on its menu
<markh> and any file in conflict would similarly
<markh> beyond that, I'm still working things out :)
<lifeless> I would like:
<lifeless> well
<lifeless> I don't think doing a tree wide scan for auto-resolvable files without actually resolving them makes sense
<lifeless> if you need that, I think there is confusion about whats going on
<markh> think of it as warming the caches for the actual resolution that will happen any second now :)
<markh> but I see your concerns
<markh> I think broadening the discussion makes sense
 * spiv wonders which project http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C200809010242.m812g2p9078345%40harfy.jeamland.net%3E belongs to
<spiv> Ah, squid, judging from gmane.
<markh> lifeless: do you think it makes more sense for some of you guys to join the tbzr developers mailing list rather than forcing cross-posts to 3 lists when most of the bzr readers probably don't care?  John already is...
<lifeless> spiv: yes
<lifeless> markh: well, this is the price of having multiple lists
<spiv> Hmm, I thought abentley fixed the bug of broken merge directives on other lists being attributed to bzr?
<lifeless> if the submit field is set correctly
<markh> it doesn't seem helpful to introduce more noise on the bzr mailing list if the reality is that its only for the benefit of a couple of people
<markh> its no skin off my nose though :)
<jml> lifeless: mail regarding what?
<lifeless> jml: launchpad's sftp server
<jml> lifeless: I'll check my spam folder.
<mwhudson> jml: it was bug mail
<jml> mwhudson: I saw the thread, but didn't see lifeless's email.
<jml> there it is.
 * jml changes the bug's summary
<jml> where can I find the version of pyflakes that loves lazy_import?
<mwhudson> lp:~mwhudson/pyflakes/support-lazy-imports i think
<jml> yay branches
<mwhudson> i even used the ~vcs-import branch!
<jml> lifeless: so, I've got all my interface tests done and have an implementation that makes them all pass. thing is it still opens the branch.
<jml> lifeless: got ideas on how I can (or whether I should) write a test that shows that it doesn't open the branch?
<lifeless> well
<mwhudson> i guess you could delete .bzr/repository...
<lifeless> opening the branch would fail if
<lifeless> the stacked on branch was inaccessiblee or something
<jml> so set a made-up, definitely doesn't exist url?
<lifeless> or use a real url then delete the contents there
<LaserJock> jelmer: around?
<jml> lifeless: next question. I've got a test in bzrdir_implementation.test_bzrdir that looks like this: http://paste.ubuntu.com/42310/
<jml> lifeless: problem is, none of the implementations run with a stackable branch & repo format.
<jml> so the test never exercises the bit I'm primarily interested in.
<jml> what should I do about this?
<lifeless> change the meta one up to use 1.6
<jml> the actual scenario?
<jml> or just for this test?
<lifeless> the scenario
<jml> ok
<mwhudson> bzrlib has a lot of lint
 * AfC hands mwhudson a lint brush.
<jml> yes it does :)
<mwhudson> at least it's test suite is fairly fast
<mwhudson> though, otoh, said test suite contains this:
<mwhudson> reduce(getattr, (module).split('.')[1:], __import__(module))
<mwhudson> which is not a thing to make a man happy
 * jml stares
 * jml attains satori
 * mwhudson is not so lucky
 * mwhudson goes to mow the lawn before it gets too dark
<jml> lifeless: should I do something special for remote formats?
 * mwhudson writes a whiny email to the list
<jonnydee> lifeless: you said I should remember you if your fix for https://bugs.launchpad.net/bzr/+bug/255656 has not been merged into bzr.dev. Well hereby I remember you :)
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New]
<jonnydee> (sorry, it means "remind you"...)
<lifeless> jml: what do you mean?
<markh> Is it 'expected' that 'bzr rm dir' silently takes no action and prints no message if dir is the root of a working tree?
<Peng_> Whether or not it's expected, IMHO it should display an error.
<markh> yeah, that's why I used quotes around 'expected' :)  I guess the question is: should I report a bug?
<markh> no point wasting my time if lifeless or someone else can quickly say "nah, that's normal, don't bother reporting anything" :)
<lifeless> Peng_: why should it error?
<lifeless> Peng_: bzr add likewise doesn't error
<lifeless> markh: it has taken an action
<Peng_> Oh?
<markh> you know I'm going to ask what action it took ;)
<lifeless> its scanned for and removed any missing files
<markh> the only action I can see it took was to compare the abspath to an empty string and therefore skipped that entry in the file_list
<markh> doesn't 'bzr rm dir' normally removes versioned files in dir, and dir itself?
<lifeless> markh: delete a file, run 'bzr rm'
<markh> if 'dir' is the root of a wt, it doesn't take the same action it takes when dir is a subdirectory of a wt.
<Peng_> That's...convenient, but nonintuitive. It is explained in the help though. Huh.
<lifeless> markh: oh, I missed the exact quesiton; but I'm not sure its wrong anyhow
<lifeless> Peng_: same as 'bzr add' being nonintuitive that it will scan-and-add, if you're coming from somewhere where you had to be explicit
<markh> what about 'bzr rm .'?
<Peng_> lifeless: Ehh, perhaps.
<markh> (that gets a little upset trying to remove 'dir' on windows - or takes no action if the cwd is the root of a wt)
<lifeless> markh: if we say: the same as  'bzr add .', then the current behaviour is probably good; if we say that 'explicit parameters always cause explicit actions' probably bad
<markh> I'm more worried about the silence than the behaviour.  'bzr add .' at least tells you it does nothing :)
<lifeless> markh: sure, file a bug if you like
<markh> (although even then bzr seems confused:  added hello.txt\nadded new.txt\nignored 2 file(s).\nIf you wish to add some of these files, please add them by name.
<markh> why did it say 'added' on the first 2 lines?
<lifeless> markh: becase it added files
<markh> oh right!  so 'bzr add .' *does* work in the root of a wt exactly the same as it does in a subdir
<lifeless> note that 'bzr add .' won't print any output if there is nothing ignored and nothing added
<lifeless> I'd like bzr rm to behave the same at any depth too
<lifeless> I'm waiting to see if people become addicted to 'bzr rm' the way I have
<lifeless> anyhow, I'm calling it a day
<Peng_> Good night. :)
<markh> have a good one!  nearly beer-oclock for me too :)
<visik7> I can't get the difference between pull and update
<luks> pull downloads revisions from a remote branch and updates the working tree to the head revision
<luks> updates updates the working tree to the head revision of the bound branch
<luks> -s in the first "updates" :)
<luks> pull in a standalone branch, and update in a checkout are similar though
<luks> it all makes more sense if you understand the concept of branches and working trees in bzr
<markh> in some ways, having 'pull' default to also doing an update of the working tree isn't helpful to someone learning bzr concepts (although it certainly is useful in its own right)
<AfC> markh: you're not the first to remark that
<poco> hi
<poco> i have a repository but i want to move all its content in a subdirectory. should i simply use bzr mv? and if i want to merge 2 repositories in one parent repo, how should i do that?
<poco> maybe juste a bzr merge inside a subdir ?
<poco> if i simply do a merge inside current dir, i loose all the revisions of original repo
<poco> with a mkdir bla; cd bla; bzr merge foo; mkdir foo; bzr mv * foo
<poco> and if i do "bzr co" inside "bla" i'm gona have multiple repos
<poco> maybe "bla" should be init with init-repo? could i then use recursive "repositories" (init-repo)
<Odd_Bloke> poco: Using bzr mv for your first case is probably the best way to go about it.
<poco> Odd_Bloke, thanks
<Odd_Bloke> As for merging two branches (which is, I assume, what you mean), are you sure that the merge loses the revisions, or is it just not showing them in the left-hand ancestry?
<poco> i am not sure, what do you mean by left-hand ancestry?
<Odd_Bloke> poco: The mainline revisions, which don't have a dotted revision number.
<poco> ah!
<poco> i understand how to solve conflict with the .THIS, .BASE and .OTHER, but how am i suppose to resolve them with the 'moved existing file to ... .moved' ?
<james_w> if you want a particular copy then move that in to place
<james_w> if you want some hybrid then copy the bits you want from .moved in to the file
<poco> ah ok, i need to given explicitely the filename when resolving?
<james_w> I think so, yes
<poco> thanks
<jelmer> lifeless, ping
<Guest47733> jam, ping
<ignas> hi
<ignas> is there a way to "lift" my changes, merge from another branch and apply them back again without commiting?
<ignas> i have tried to use "shelve"
<ignas> but it did not help me, because it does not "shelve" added directories :/
<Odd_Bloke> ignas: Could you not add the directories/files back _after_ you've merged?
<ignas> i just thought that maybe there is a way that will not require me to play around with specific files/changes
<jam> jelmer: I saw you released 0.4.12, but I don't see the tag available from bzr.d.o
<jelmer> jam, I've pushed to http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental
<jam> jelmer: so should this go in "bzr-beta-ppa" then?
<jelmer> we're not uploading to unstable at the moment because of the freeze of lenny
<jam> k
<jelmer> jam: it's actually a stable release of bzr-svn, so probably ~bzr
<jelmer> jam, what's the easiest way to test for a deprecation warning?
<jelmer> I was looking for tests for ensure_null() but there don't appear to be any >-)
<james_w> jelmer: apply_deprecated I think
<jelmer> james_w: Thanks
<jam> james_w: it would be self.applyDeprecated, but that is only if the function you are calling is directly deprecated
<jam> you need callDeprecated
<jam> to pass in a custom deprecation string
<james_w> hi jam
<jam> I'm not really here
<jam> I'm on vacation today :)
<james_w> it's alright, I didn't see you.
 * awilkins curses Borland for writing batch scripts that call classes for which not even the fricking package exists
<awilkins> I hope the crotch of their testing manager gets savaged by a german giant rabbit
<jelmer> good morning to you too, awilkins :-)
<awilkins> Bah, time to go home
<awilkins> Back later :-)
 * jelmer files some more bzr-builddeb wishlist bugs
<jam> jelmer: packages should be uploaded
<jam> at least for gutsy/hardy/intrepid
<jelmer> jam: Thanks
<exarkun> Why does this happen?  http://rafb.net/p/UJo6VW65.html
<rocky> jelmer: you released bzr-svn 0.4.12 but the download link on pypi leads to a page that lists all releases up to 0.4.11 it looks like
<jelmer> rocky: Sorry, I forgot to update the wiki page. will do so now
 * rocky is in jelmer's shadow ;)
<Snaury> jelmer: while trying to checkout pugs with bzr-svn I noticed with -Dtransport that there are often multiple 'svn get-dir' lines for the same revision, why could it be so?
<Snaury> (this is during "determining revisions to fetch" phase)
<rocky> anyone have a favourite bzr mode for emacs? something preferably along the lines of psvn ?
<jelmer> Snaury, would need some looking into
<jelmer> Snaury, the direct return value of get_dir isn't cached but some of the values based on it are
<Snaury> http://kitsu.ru/bzr-log-partial.log - it's just the pattern looked strange to me.
<Snaury> And they look rather expensive too (unless there's something else eating time between the calls, haven't checked that yet). When there are 20000 revisions the overhead would turn out pretty bad. :)
<jelmer> it's only called if the branch directory changed in that revision
<Snaury> Well, judging from the fact that it was determining revisions to fetch for more than several hours it was called for every revision at least twice and for some revisions three or more times. And in the case of pugs trunk it's pretty expensive too:
<Snaury> 59.577  svn get-dir -r2043
<Snaury> 61.415  svn get-dir -r2043  (finished)
<Snaury> 61.415  svn get-dir -r2042
<Snaury> 63.680  svn get-dir -r2042  (finished)
<Snaury> Perhaps it could be cached as a whole somehow?
<Snaury> (as a proof of three or more times look at the bzr-log-partial.log above, which was a restart after yet another connection loss)
<Snaury> And url is http://svn.pugscode.org/pugs/ you can try it yourself, of course.
<jelmer> Snaury, I think I may know some way to skip the need to do those calls in a lot of cases
 * LarstiQ cheers jelmer on
<jelmer> hmm, bzr-svn trunk is freakishly quick now and it's still doing those get-dir requests
<LarstiQ> jelmer: what's the improvement?
<jelmer> fetches about 7 revisions per second from the pugs repository
<LarstiQ> instead of?
<jelmer> probably about 1 or 2
<LarstiQ> nice
<rocky> jelmer: so you've been working on increasing speed of bzr-svn further since the 0.4.12 release?
<jelmer> yeah
<jelmer> This is all happening in trunk, which will at some point become 0.5
<rocky> oh... doesn't 0.4 get released from trunk too or does it live on a special 0.4 branch?
<rocky> i was playing with the smart server wsgi setup yesterday until i ran out of steam... seems like it should be easier to setup ;)
<rocky> jelmer: don't suppose you have an example standalone py script server that uses wsgiref to serve up the bzr smart server?
<jelmer> 0.4 gets released from a separate branch, the 0.4 branch
<jelmer> rocky, no sorry, I don't have experience with the wsgi server
<luks> I had a plugin that does 'bzr serve --http' using wsgiref some time ago
<luks> bzr serve-http actually
<luks> http://rafb.net/p/guvLH649.html
<luks> dunno if that still works
<rocky> luks: oh thanks
<luks> rocky: you could fix it, make it configurable and release a proper plugin! :)
<rocky> seems kind of silly to me that bzr serve doesn't have something similar to this anyhow... i mean http based protocols are way more flexible ;)
<luks> what I wanted was to add per-branch HTTP auth to the WSGI server
<luks> but that failed due to lack of interest, and this code is just a leftover
<rocky> well atm i'm working on a project that manages multiple trac instances with their relative svn instances and such and i want to extend it for bzr... having my python wsgi app serve up the bzr directly instead of having to rely on apache (for svn) would give me a great deal of flexibility
<rocky> are repos that are served up by the bzr wsgi app browseable using a browser?
 * rocky tries to get it working to test for himself
<mwhudson> probably not, but that should be easy to add
<beuno> mwhudson, when you have time, can you take a peak at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806
<mwhudson> beuno: um, sure, merge it
<beuno> that was easy
<beuno> and release 1.6.1 to make lifeless happy?
<mwhudson> sounds good
<beuno> mwhudson, sweet, thanks
<beuno> lifeless, https://edge.launchpad.net/loggerhead/1.6/1.6.1
 * beuno goes off and leaves the announcement for later
<rocky> luks: don't suppose you know of better "serving bzr repos" docs than what's in the user's guide?
<rocky> is there anyway to pass in credentials for a basic auth protected url (say in a config file) so you don't have to include them on the command-line ?
<lifeless> moin
<mwhudson> hi lifeless
<beuno> howdy lifeless
<beuno> I've made a special Loggerhead release for you  :)
 * beuno -> home
<poolie> good morning
<jelmer> hi Poolie
<jelmer> How were your holidays?
<poolie> really great
<poolie> and you?
<jelmer> apart from a rough start (er visit and a leaking tent) very good
<poolie> lifeless, spiv, igc, jam, call in 2m?
<spiv> Good morning.
<spiv> poolie: yeah
<mwhudson> spiv: hi, have i talked to you about https://bugs.edge.launchpad.net/bzr/+bug/261315 yet?
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,Triaged]
<spiv> mwhudson: I don't think so
<mwhudson> ok
<mwhudson> i would really like someone to fix it fairly soon :)
#bzr 2008-09-02
<jml> is this the one causing all the oopses?
<mwhudson> no
<edencane> Hi.
<edencane> someone sent me a diff file to apply to my tree...
<edencane> they said use the 'patch' command, however there is no patch command in 1.6
<wgrant> edencane: The patch command is part of bzrtools.
<lifeless> pooliex: sorry, was in the zonr
<edencane> ok... (-:
<edencane> thanks wgrant
<pooliex> mwhudson, i'm going to look at #261315 today
<pooliex> lifeless, np
<mwhudson> pooliex: cool
<jelmer> hah, pushing the exact same branch from scratch over both bzr+ssh and svn+ssh to the same server is faster over svn+ssh now >-)
<jelmer> the difference is not very big, and the bzr server side is running bzr 1.0 (bzr.dev on the client)
<lifeless> spiv: how did you go with streams?
 * jml submits a patch
<lifeless> classic - http://steve-yegge.blogspot.com/2008/08/business-requirements-are-bullshit.html?showComment=1218561660000#c5713392683478153083
<warren>  hmmm, does bzr have anything like git where you can export checkins as diff files with metadata?
<poolie> warren, 'bzr help send'
<jml> poolie: hello
<abentley> poolie: wb
<poolie> we had it first i think
<warren> thx
<jml> poolie: welcome back.
<poolie> thanks, both of you
<warren> thx
<poolie> lifeless: hi
<poolie> nice rant if somewhat longwinded
<lifeless> ho
<poolie> is the comment directed at me though?
<lifeless> poolie: no
<lifeless> poolie: but it did make me smile
<poolie> i would say the main article is somewhat in the category of 'intentionally misconstruing the question'
<teratorn> anyone know of a way to interactively tweak where 'bzr shelve' decides to place hunk boundaries?
<teratorn> quite often I need to break up the changeset differently :/
<jml> teratorn: I think shelve gets it from diff.
<teratorn> you're probably right
<teratorn> one day when I'm rich I'm gonna hire someone to follow me around on IRC and implement all the stuff I complain about
<Hydrogen> you jus gotta complain to the right people!
<teratorn> complaining is hard work
<lifeless> abentley: ping
<lifeless> abentley: I want hunk-editing and stuff in bzr core
<lifeless> abentley: what do you think of the shelf editor code - is it lovely, and what you'd build for bzr core, or should I take the concepts and write something new?
<abentley> lifeless: I've never had much need to look at the shelf editor code.  So it must be good.
<teratorn> what is this shelf editor code of which you speak?
<abentley> (Originally written Michael Ellerman.  I just maintain it.)
<lifeless> abentley: I poked at it, I found it a little obstruse, but not terribly so; I don't know if it will scale to hunk splitting and so on, which I do want us to get to.
<lifeless> teratorn: its the hunk selector in 'bzr shelve'
<lifeless> teratorn: bzr shelve's hunks are those output by 'bzr diff'
<teratorn> *nod*
<teratorn> yeah that would be way cool
<abentley> lifeless: I've always figured that sub-hunk territory was best handled in an editor.
<lifeless> abentley: so fire up an editor with some markers, perhaps the basis & current text seperate, let them edit till it has what they want,then use that to do a new diff and shuffle stuff ?
<teratorn> basically all you need to do is to be able to split the hunks
<teratorn> a simple line editor that lets you add some "<<<<<" markers, or something
<teratorn> and move them around.. up or down
<abentley> lifeless: Currently, for that purpose, I stop using shelve, and start using bzr vimdiff
<jam> poolie, spiv: Good to have you guys back. Today is "Labor Day" in the US.
<lifeless> abentley: I'm sneaking up on tree marks. I want something that doesn't need specific things like vimdiff that may not be readily available for some users, or which will not bind well for IDE's and GUI's.
<abentley> poolie, spiv, jam: In Canada, today is "Labour Day" ;-)
<jam> abentley: I guess that means u work harder
<abentley> jam: lol
<lifeless> abentley: I guess I'll send a mail to the list about hunk editing/selection. Using a callback may be the right interface.
<jam> it seems like you could evolve the "shelve" interface if you really wanted to go that route
<jam> just have a "split hunk" option
<jam> though I agree, vimdiff (or an editor) is probably a more comfortable ui for it
<jam> anyway, I'm only just walking by, back to family time
<jam> oh, and poolie, spiv, igc, lifeless, abentley, vila, beuno, jelmer, LarstiQ, fullermd, etc, etc.... Feature freeze is tomorrow, so I encourage you to do some reviewing
<poolie> jam, oh, right
<poolie> re Labo[u]r Day
<lifeless> abentley: the other thing we should discuss - rich-root; *I* thought it was waiting on a patch from you, you're saying its blocked on me. Lets sync
<lifeless> oh damn
<fullermd> Reviewing?  You must have me confused with somebody who knows what they're doing   :p
<rocky> jelmer: best version of bzr to use with TracBzr is 1.5 ?
<jelmer> rocky, probably
<rocky> jelmer: does TracBzr support trac 0.11 ?
<jelmer> rocky, yeah
<rocky> latest release of TracBzr or do i need to grab a branch?
<jelmer> rocky, there are no releases, you'll have to grab a branch
<rocky> just grabbed trunk
<lifeless> jam: why does branch.get_revno_map use the old graph abstraction?
<rocky> jelmer: any particular reason you haven't merged over the trac0.11 branch into trunk?
<jelmer> rocky, it is merged into trunk
<rocky> oh... sorry i'm still getting familiar with launchpad's very very complicated interface
<rocky> seemed to indicate it hadn't been merged
<rocky> https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges seems to show it hasn't been merged
<jelmer> rocky: I'm not the maintainer of trac-bzr btw, I do the occasional merge when I need it myself though
<rocky> oh gotcha
<jelmer> rocky, since nobody appears to be particularly looking after it these days
<rocky> i might be interested in helping ... particularly if i integrate it with cluemapper
<jelmer> ah, cool
<jam> lifeless: because merge_sort doesn't allow ghosts
<poolie> lifeless: please use more contentful subject lines than 'review feedback' thx
<Hydrogen> yes
<Hydrogen> like
<lifeless> poolie: please patch bzr send to give me more contentful subject lines!
<Hydrogen> du du du
<poolie> lifeless: is this the bug about not being able to override the subject line if you use the builtin mail-sender?
<lifeless> poolie: actually, I didn't look at the subject at all
<lifeless> poolie: and as there is one, evo didn't bitch at me
<poolie> if you're sending through evo i think you can override it and i'm asking that you do
<lifeless> besides which, BB knows its a follow on patch, it can give extra content.
<lifeless> poolie: I normally do. I forgot, once.
<lifeless> and got jumped on.
<poolie> oh np
<poolie> no stomping was intended
<jelmer> lifeless, when you have time, any chance you can reply to the "[MERGE] Move install_revision(s) onto the Repository object." thread?
<jelmer> (http://news.gmane.org/find-root.php?message_id=%3C20080804032617.GA19075%40vernstok.nl%3E)
<lifeless> poolie: ok
<lifeless> jelmer: is it stuck?
<jelmer> lifeless: Sortof - you voted resubmit but I wasn't entirely sure what I had to change
<lifeless> jelmer: right found it.
<lifeless> jelmer: what was unclear?
<jelmer> lifeless: The tests for install_revisions() were already inside repository_implementations
<jelmer> even though install_revisions() didn't live on Repository but was generic
<lifeless> ah
<lifeless> wow
<lifeless> we have 1 test
<lifeless> and its bare bones
<lifeless> uhm
<lifeless> it really needs to obey the full protocol on per-file graph support etc
<lifeless> I hesistate to ask you to extend it to be sure of that, but I can think of so many ways it could be broken and pass the current test.
<lifeless> poolie: I've dropped you a mail, there is a little bit of administrivia needed fairly urgently
<jelmer> lifeless: Ok, so it just needs more tests?
<lifeless> jelmer: yeah, I think so
 * poolie chases indirections
<lifeless> jelmer: I think I'd structure them self-referentially - thusly
<poolie> lifeless: is this at google again?
<lifeless> jelmer: use the default format to build a branch with a file, dir, symlink (only where symlinks are present), that have the following occur to them
<lifeless> created
<lifeless> modified
<lifeless> modified in two branches and merged
<lifeless> modified in one branch merged to the other branch
<lifeless> these are the basic corner cases for last-modified revision assignment
<lifeless> then copy those revisions over to the repository format that is being tested
<lifeless> they should end up identical
<jelmer> thanks
<jelmer> I'll leave it alone for now though, it seems like too much trouble to avoid 20 lines of code duplication in bzr-svn
<lifeless> I'll note that the bugs in bzr-svn recently about last-changed etc will be avoided if you do this
<lifeless> its not a good idea to leave it alone and hope :(
<jelmer> lifeless, last-changed?
<jelmer> you mean the text revids? That would be the bit I would override in bzr-svn
<lifeless> its the bit you need to make sure the rules are absolutely in sync with bzr
<jelmer> Sure, but this is just code sharing, it's not test sharing
<lifeless> right
<lifeless> I'm looking for a review on http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219204485.31549.89.camel%40lifeless-64%3E
<jelmer> So I don't see how that would help here; I would override install_revisions() for bzr-svn anyway, but that would allow using an existing InterRepository implementation that uses install_revisions() rather than writing my own.
<lifeless> jelmer: so, I guess I'm thinking about test sharing more
<lifeless> I'm hesitant about install_revisions as it stands, there are still #XXX's in it
<lifeless> last I checked
<jelmer> sure, but it's already being used at the moment. I'm just moving it.
<lifeless> so my comment was, that by moving it we're making it be at higher risk - bugs in it will be more exposed
<lifeless> and anyone implementing Repository will be expected to implement it, so test coverage matters substantially more
<spiv> lifeless: I can review that
<spiv> lifeless: as a general comment, I'm in favour of bringing things in incrementally though, so don't share jam's concern there.
<jelmer> lifeless, ah, ok
<spiv> lifeless: review sent.
<lifeless> spiv: thanks
 * beuno -> sleep
<lifeless> spiv: replied
<beuno> g'night all
<lifeless> spiv: I'm not sure where the 'if in tests is a bad smell' meme is coming from, but its either too simplistically phrased, or wrong.
<lifeless> I've seen it a couple of times recently, I think its new.
<spiv> lifeless: well, I can elaborate why I think this particular if is bad; I agree they can be ok.  But by default treating with some suspicion is justified.
<lifeless> why is it justified?
<spiv> lifeless: as to the source of the meme, the xUnit Test Patterns book lists it ("Conditional Test Logic")
<lifeless> or, whats the justification
<spiv> In this case I think it's basically just that you're using the if statement to squeeze multiple tests into one test method.
<lifeless> you've seen my reply?
<spiv> Which isn't as clear at communicating intent as it would be as two separate tests.
<spiv> Not yet; I'll do that now.
<lifeless> because I'm not doing that
<lifeless> I'm testing the single behaviour of an interface with optional output
<spiv> Ok.
<lifeless> the first column must be either all None, or not None at all
<spiv> So I think you can express that intent more clearly.
<lifeless> as I've defined it
<spiv> (And without an if statement in the test method)
<spiv> By:
<spiv> names = sorted([result[1] for result in read_result])
<spiv> self.assertEqual(expected_names, names)
<spiv> # (so far, same as before)
<spiv> self.assertAllNoneOrAllNotNone([result[0] for result in read_result])
<lifeless> ugh
<spiv> There would be an if statement in the assertion method, obviously.
<lifeless> Thats less clear
<spiv> (The xUnit book points out that this is a good thing because you can write tests for your test helpers, whereas writing tests for test methods leads to madness)
<lifeless> I'll change the test around a bit, see if you like it
<spiv> I'll be interested to see what it looks like.
<lifeless> well, the xUnit book, frankly, should smoke less camel toenails. Its equally untested even with a helper test, because you may simply fail to call the right helper, or pass incorrect parameters in
<lifeless> at a certain point you have to assess the code in front of you on its own merits
<spiv> :)
<lifeless> I do write helper tests, for helpers that deserve it
<spiv> Right, I agree.
<lifeless> so its not a critique of doing that. Its a critique of using that facility to support an argument that 'if' is bad in test methods
<spiv> I nearly said so originally, but I felt like I was already waffling :)
<lifeless> bet you the authors don't like 'goto' either.
<spiv> Perhaps, but the index gives no clue either way :)
<lifeless> :>
<lifeless> (goto is very good practice in C for function cleanups)
<spiv> (agreed)
<spiv> Skimming the Conditional Test Logic section of the book, it is a touch vague but boils down to "conditional logic == complex code == harder to understand/trust == less confidence".
<lifeless> sounds like an indictment of both 'if' and 'objects' all at once
<spiv> Which I think is right.  It's a mild smell for me; it can be a sign that the test could be better, but I don't consider it to be a 100% reliable indicator of trouble.  Sometimes the test is clear enough even though it has conditional.
<spiv> Well, complexity sucks. :)
<lifeless> see, this is the bit where I think its process insanity
<lifeless> thats the sort of thing thats so inane, I'd never put it in a talk
<spiv> One of the neat thing about tests is that you can often write several simple tests that you individually trust to gain confidence in a larger, complex system.
<lifeless> "I find your test hard to read" >>>> "your test has if in it"
<lifeless> spiv: that ignores the potential for skew
<spiv> (Keeping in mind that you may have gaps between your simple bits...)
<lifeless> you have to be sure they are aligned right, and thats hard to test
<spiv> Right.
<spiv> I said it's a "neat thing", not a "magic bullet" :)
<spiv> Anyway, back to the case in hand... I *did* find the purpose of the test a little confusing.
<lifeless> which is fine, fixing.
<spiv> Partly because I worry a little that a casual reader might not pick up on the fact that that test is parameterised, which is helpful in figuring out why the "if" might matter.  I wonder if we should have some convention to flag parameterised tests that are outside the per_* and *_implementations directories?
<spiv> Perhaps the answer is just that a casual reader that gets confused should just read more closely :)
<lifeless> well, the test, when it runs, shows the parameters
<lifeless> spiv: mail sent to the list
<spiv> Yeah.  So people reading the test because of test failures will know.
<spiv> Which is probably most casual readers.
<spiv> lifeless: that tweak is better, thanks.
<lifeless> the difference from a helper function is that this is clearer
<lifeless> a non-reused helper is just a new function to remember, and the name would signal what it does, not why it does it
<lifeless> why is what matters
<spiv> Sure.
<spiv> I wasn't wedded to using a new function, but it was a lot easier to type into IRC :)
<poolie> wow
<poolie> i got sucked in too
<lifeless> poolie: ?
<poolie> to the 'if in tests' thing
<lifeless> hehe
<poolie> smell doesn't mean 'never do this'
<mwhudson> poolie: not sucked into wow, i hope
<poolie> i guess overall, why not hide the sorting by inodes inside the function you're testing
<poolie> nup
<lifeless> poolie: performance
<poolie> heh
<poolie> care to expand on that?
<lifeless> sure
<lifeless> sorting costs, its cheaper not to sort unless you need to
<poolie> so if a caller wants the directory without caring about sorting by inode, surely they'd like to also avoid consing and then removing all the tuples?
<lifeless> poolie: I'll be a second, buffer overflow
<lifeless> poolie: so, I think the thing about smells, is that if you bring them up in a comment, it muddies the actual discussion that should take place.
<poolie> the reviewer should keep inside their head the fact that it's a smell and just either give a concrete reason or say nothing?
<lifeless> yes
<lifeless> unless they want to just say 'it smelt to me, if it smells to you too please fix it'
<spiv> So I mentioned it as a shorthand way of explaining what I thought was problematic.
<spiv> Clearly this failed as a way to explain myself concisely :)
<lifeless> like pattern languages, unless its shared, it fails
<poolie> it may bifurcate the conversation into a discussion of whether it's a general problem or not, and what to do in this case
<poolie> as has happened here
<poolie> they may go in different directions
<poolie> anyhow, coming back to the specific thing here
<poolie> it seems to me that callers want either a directory listing in random order, or a listing sorted for optimal access to the files (if possible)
<lifeless> just waiting for a push to finish then I'll have the code up in front of me again
<poolie> dear lazyspiv: getattr won't be called if the attribute is defined in a base class?
<spiv> Heh.
<spiv> The __getattr__ hook?  Right.
<mwhudson> poolie: you mean __getattr__ right?  and yes, pretty sure
<poolie> i do
<poolie> thanks
<poolie> that was my reading of the docs, it just contradicts something jam said so i was checking
<poolie> lifeless: the other thing here, which is kind of mission creep, is that i think you can actually return the file file kind from readdir, which your comment waves towards
<lifeless> poolie: its not a win today
<lifeless> poolie: I ripped that code out
<poolie> but it might take a bit of code change to use it, and it probably isn't enough to avoid stat
 * spiv -> lunch
<lifeless> poolie: so, sometimes we want to sort, sometimes we don't care. Having multiple interfaces is less appealing than a single if its cheap
<lifeless> poolie: we would allocate inode, string tables to sort anyway, so there isn't <much> of a saving in hiding that
<poolie> my point is that if you care about avoiding the sort when the client doesn't care, shouldn't you want to avoid allocating all the data structures needed to sort too?
<lifeless> poolie: yes, I didn't disagree with your point
<lifeless> poolie: but we'll need another tested interface to implement it, and that has its own cost; I don't really want to duplicate the C code unnecessarily
<poolie> i think it would be clearest to have list_dir(..., sort_hint=None) or something
<lifeless> that will be quite tricky to test
<lifeless> poolie: so, spiv has given bb:approve, i'm blocked on a little clearer messaging from you
<poolie> lifeless: ok
<poolie> in what way is that trickier to test?
<poolie> at the moment you're not testing that it is sorted in any way at all
<poolie> i think if you do this it will address john's just-posted concern that this is not a good api for pyrex
<lifeless> he doesn't say its not a good api for pyrex; hes saying its not all-thats-needed-to-be-really-fast
<lifeless> because we need to fix the overhead of stat
<lifeless> and we may actually want a full pyrexed walkdirs implementation
<poolie> so is that clear or not?
<jml> so, I'm having a problem with this bzrdir patch.
<lifeless> so the change you propose is really unrelated to John's concern about pyrex, which I've replied to
<jml> If I add another BzrDirMetaFormat1 to the tested formats, I get this error: http://pastebin.ubuntu.com/42594/
<lifeless> jml: you shouldn't add another BzrDirMetaFormat1 to the tests
<lifeless> jml: as its already tested
<jml> lifeless: ok.
<lifeless> jml: like I said yesterday, just change the formats it tests with to be the latest ones, rather than the defaults
<jml> lifeless: changing the existing format to use stackable branches and repositories makes the 'does default work' tests fail
 * jml looks for the right shelf to get the test output
<lifeless> jml: give me a diff somewhere
<lifeless> poolie: so, I can do it, but I think we're polishing the knob a little early
<jml> http://pastebin.ubuntu.com/42595/
<jml> lifeless: ^^
<lifeless> poolie: what I have is the shrunken version of 'get the file kind from C's readdir()'
<lifeless> jml: what for are you fiddling around in there
<lifeless> jml: BzrDirFormat.known_formats() is the function to change
<lifeless> poolie: no its not really clear; I can't tell if you are voting comment: or tweak:
<jml> lifeless: I'm sorry, but I have no idea how to change that in a sane way
<jml> lifeless: what's a control format?
<lifeless> jml: BzrDir4/5/6/7/BzrDirMetaDir/RemoteBzrDir/SvnDir
<lifeless> HgDir
<lifeless> GitDir
<lifeless> etc
<jml> ok. I still don't get how to change known_formats.
<lifeless> so
<lifeless> I can paraphrase the problem differently I think.
<lifeless> the reason your tests did not fail after you wrote them is that the BzrDirMeta1 type supports stacking, even though the bzr 'default' format does not
 * jml nods
<lifeless> I am saying, change the default, for all these tests
<poolie> ok, i reviewed the new one
<jml> lifeless: how do I change the default for the tests without changing the default for bzr?
<lifeless> so, known_formats is only used for testing
<lifeless> if you look at the loop
<lifeless> its returning all the specific types known by each control type
<lifeless> so, all the flavours of BzrDir, all the Flavours of GitDir etc
<lifeless> you want the BzrDirMeta1 flavour returned to be parameterised with a branch and repo type
<lifeless> basically, I think you change
<lifeless> __default_format = BzrDirMetaFormat1
<lifeless> way down in the file
<jml> ok.
<lifeless> and check 'bzr init' doesn't break surprisingly. (I don't think it will)
<lifeless> oh, or upgrade
<lifeless> it shouldn't actually change the default, due to various things
<lifeless> poolie: where did you see the copyright thing?
<poolie> readdir.h
<lifeless> and whats wrong with it (other than it saying Bazaar-NG, which I've fixed)
<poolie> it's also 2008 now :)
<lifeless> that file has not changed since 2006
<poolie> ok
<poolie> it's newly added so i thought it was new
<lifeless> Am I misunderstanding (C) rules?
<poolie> but maybe it's been sitting on your disk since then
<poolie> in which case it's fine
<jml> import sucks
<lifeless> jml: ?
<jml> lifeless: would you expect http://pastebin.ubuntu.com/42600/ to cause http://pastebin.ubuntu.com/42601/
<jamesh> lifeless: usually copyright relates to publication date rather than creation date
<jamesh> so a 2008 copyright might be appropriate if that's when it first gets published
<lifeless> its been on the interwebs since london 2006
<lifeless> why is something so simple such a long process
<lifeless> 1/2 a day on one patch
<lifeless> jml: yes, I would
<jml> lifeless: for my part, it's because of a lack of familiarity :)
<lifeless> jml: I wasn't referring to your patch
<lifeless> this readdir one of mine
<lifeless> EFRUSTRATION
<jml> :)
<lifeless> I feel like saying, meh, I'll come back to it in another 2 years
<lifeless> (This patch was the reason I wrote the pyrex stuff for setup.py in the first place, way way way back - it was to enable bringing in such extensions)
<lifeless> jml: anyhow, your patch. bzrlib.branch is probably lazy importing bzrdir
<lifeless> and those default setting lines are too high up
<poolie> lifeless: i feel like that sometimes too
<lifeless> jml: try changing bzrlib.branch.BranchFormat.default
<lifeless> jml: instead, I think it delegates by default
<poolie> lifeless: want to talk? any ideas about what to do differently?
<lifeless> poolie: I'm feeling a tad time pressured. The idea of a process chat right now is not appealing
<poolie> lifeless: take 3 is ok with me if you really don't want to change it
<poolie> i guess i'd be more relaxed if it were marked private
<lifeless> poolie: it is now, its _read_dir
<poolie> am i one patch behind?
<lifeless> no
<lifeless> you're probably confused by the modules
<lifeless> _readdir_pyx.pyx -> thats a private module
<lifeless> it has read_dir() in it
<poolie> oh, you mean _readdir
<lifeless> bzrlib.osutils._readdir
 * jml looks into changing the repository default
<poolie> fairy nuf
<lifeless> is where it is exposed, and its exposed _ prefixed.
<poolie> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219204485.31549.89.camel%40lifeless-64%3E has osutils republishing it as read_dir
<lifeless> try:
<lifeless>     from bzrlib._readdir_pyx import read_dir as _read_dir
<lifeless> except ImportError:
<lifeless>     from bzrlib._readdir_py import read_dir as _read_dir
<poolie> ok
<poolie> wrong tab
<lifeless> so my view is - there is one user; it obvious that it is doing a sort, so the costs are visible to readers
<lifeless> we can triangulate when there are multiple users of the interface
<lifeless> jam: bug 262565
<ubottu> Launchpad bug 262565 in bzr "Old resolved conflicts resurrected" [Undecided,New] https://launchpad.net/bugs/262565
<lifeless> jam: I suspect you've spent the most time looking at that set of problems..
<lifeless> poolie: for squid patches, in the web ui you can retarget them rather then rejecting them
<lifeless> poolie: it would be nice if you could change your vote to comment
<lifeless> http://bundlebuggy.aaronbentley.com/project/squid/request/<1220137897.6703.4.camel%40henriknordstrom.net>
<poolie> sure
<lifeless> thanks
<poolie> out to the shops, biab
<lifeless> jonnydee: sorry that your patch wasn't merged. It was approved, just not sent to the gatekeeper
<philn> hi
<philn> i can't manage to checkout a bzr:// branch via a ssh tunnel.. is there something specific needed to setup that?
<philn> to setup the tunnel i do: ssh -nNL 4155:bling:4155 sshhost
<poolie> philn, hi, do you want to tunnel ssh over ssh, or have bzr listening on a tcp port on the other side of the tunnel
<spiv> I wouldn't think anything special would be needed.
<philn> i have bzr serve listening on the remote side
<poolie> try adding -v to ssh and see if it tries to connect?
<philn> when i do telnet localhost 4155 it wors
<poolie> potentially silly question, why not just use bzr+ssh?
<philn> ok
<lifeless> jonnydee: your bugfix has landed in bzr.dev
<philn> err, dunno ;) i should try that maybe ;)
<spiv> philn: and so you're trying to checkout using "bzr co bzr://localhost/..."?
<philn> yes
<spiv> philn: well, if telnet localhost 4155 works, then there's no reason why bzr://localhost shouldn't work.
<philn> debug1: Connection to port 4155 forwarding to bling port 4155 requested.
<philn> debug1: channel 2: new [direct-tcpip]
<spiv> (at least, no reason related to SSH tunnelling)
<philn> i'll try bzr+ssh
<philn> bzr+ssh works, fair enough..
<spiv> What error were you getting?
<philn> for bzr:// ?  well bzr was just hanging, nothing displayed, even with -v option
<spiv> You could try adding the -Dhpss option and then looking in ~/.bzr.log
<spiv> Or you could try
<spiv> echo 'hello' | nc localhost 4155
<spiv> (Which should get a reply)
<lifeless> spiv: did you see my query about streaming this morning ?
<philn> it displayed ok2
<spiv> philn: ok, then the SSH tunnelling is definitely working as intended, so if you wanted to know more, then -Dhpss & ~/.bzr.log option would be the next step.
<philn> i see no error in that file
<spiv> lifeless: oh right.  Slowly, but that's due to sinus congestion rather than code :)
<spiv> philn: pastebin the last 10 lines?
<spiv> It should indicate what part of the network conversation it is hanging on.
<philn> http://pastebin.com/m6c724273
<philn> if i interrupt i get a traceback in the file
<philn> http://pastebin.com/m26331e2d
<philn> this is bzr 1.6 from your ppa
<spiv> Huh, that is weird.
<poolie> lifeless: do you want to go to both uds and fosscamp?
<lifeless> poolie: yup
<spiv> philn: FWIW, random testing over an SSH tunnel works ok for me here.
<lifeless> calling it a day folk.
<lifeless> later
<spiv> philn: At this point, I'd probably start resorting to tcpdump :/
<spiv> philn: or, more pragmatically, use bzr+ssh://, seeing as that works already...
<philn> i'll just use bzr+ssh and work done ;)
<philn> have a good day
<Peng_> Shouldn't osutils.pump_string_file use xrange instead of range? It could potentially be a large range, right?
<poolie> Peng_: i can't find a method of that name...
<lifeless> poolie: pydoc xrange
<poolie> :)
<poolie> very funny
<poolie> i meant pump_string_file
<lifeless> Peng_: possibly, OTOH 5MB chunks from a string -> if its GB's in size, it will be a problem for other reasons
<lifeless> poolie: oh, pull bzr.dev then
<poolie> oh, merged since this morning?
<lifeless> yes
<lifeless> quite a few patches landed today
<poolie> spiv, are you still here?
<poolie> vila, hi/
<poolie> are you online?
<vila> poolie: Hi !
<poolie> could we talk in a bit?
<vila> sure
<poolie> need to go and pick up stephane at the moment
<vila> poolie: when you want
<stianse> Hi all. When I use "bzr branch", how should i configure the branches so that configuration (like the one you find in branch.conf) is copied to the new branch?
<stianse> Right now I'm using bzr-shell-hooks plugin and have a section of [hooks] in my branch.conf of which scripts to run. It would be nice if there was a way to copy such information. Or probably specify it somewhere else?
<Odd_Bloke> stianse: I think the accepted way to do that would be to have a plugin which installed the hooks that you would install wherever you wanted that stuff setup.
<Odd_Bloke> Though I don't know a great deal about shell hooks.
<stianse> Odd_Bloke, but using a plugin would affect all my bazaar branches, right? I only want these hooks on a few branches.
<Odd_Bloke> stianse: Yeah, I'm not sure how we handle this case.
<Odd_Bloke> I've never run into needing it, so have never looked at it.
<stianse> Odd_Bloke, ok no problem. Thanks anyway.
<hmeland> Would moving the [hooks] section from .bzr/branch/branch.conf into ~/.bazaar/locations.conf work?
<hmeland> Probably not, if the README of bzr-shell-hooks is accurate.
<poolie> vila, hi, still here?
<vila> sure
<vila> but if it's late for you we can talk tomorrow, your call
<loxs[]> folks, I'm having a problem... first I made a branch, then I checkout the branch... then I add some files to my checkout and then bzr add, bzr commit... it says everything is fine... then I go to the parent branch and the files are not there.... then I do a bzr log in the parent branch and surprise... the log is ok, as if the commit was successful. Do you have any idea what's going on?
<loxs[]> probably the problem is that the files are binary? they are doc files
<james_w> ;
<james_w> loxs[]: could you try running "bzr update" in the parent branch?
<loxs[]> ghm, strange james_w, now it adds the files there o_O
<loxs[]> can't it be done automatically?
<james_w> loxs[]: not really
<james_w> it's not easy to do that remotely, and really bad for performance
<loxs[]> it's not that remotely... it's inside a novell environment... I mean, both places are part of the filesystem
<james_w> hmm, maybe it doesn't do it locally either
<james_w> I'm more used to "push" than checkouts
<loxs[]> what is going to happen if someone edits something in the 'central' repo? without doing a bzr up before that?
<loxs[]> yeah, I must start thinking in bzr ways :)... the 'parent' and the 'child' are of equal priority... even the 'parent' can be 'out of date'
<uws> loxs[]: you can also use checkouts, in which case you can use the "centralized workflow" (a la svn, cvs)
<uws> loxs[]: then your "parent" cannot be out of date, only the "child"
<uws> loxs[]: since all commits are automatically pushed "upstream" to the parent
<uws> loxs[]: See "bzr help checkout" and "bzr help update"
<uws> loxs[]: and "bzr help bind"
<loxs[]> well, that was the problem.... see above :)
<loxs[]> the parent doesn't get automatically updated upon commits
<uws> loxs[]: it will if you use a checkout
<loxs[]> it doesn't
<uws> loxs[]: it should, and it does everywhere I use it.
<loxs[]>  first I made a branch, then I checkout the branch... then I add some files to my checkout and then bzr add, bzr commit... it says everything is fine... then I go to the parent branch and the files are not there.... then I do a bzr log in the parent branch and surprise... the log is ok, as if the commit was successful. Do you have any idea what's going on?
<uws> loxs[]: So it's likely something in your setup is not right
<uws> loxs[]: You need to "bzr update" the parent branch
<loxs[]> yeah, that's the thing :)
<uws> loxs[]: But usually you don't need a working tree in the parent branch (e.g. it's on a central, backed up server)
<loxs[]> in this case I need a working tree there
<uws> loxs[]: you can use "bzr remove-tree" if you don't need it.
<uws> loxs[]: Ok, then "bzr update"
<loxs[]> the problem is that i can't be sure that every developer will bzr update the parent every time
<uws> loxs[]: is this a website perhaps?
<loxs[]> and sometimes some of us make changes on the parent... and then we have a problem
<uws> there's a "bzr upload" plugin i think
<loxs[]> bzr automirror... I'm looking at it now
<uws> loxs[]: make changes on the parent branch, or on the parent working tree?
<loxs[]> I'm not very sure what's the difference
<loxs[]> working tree I suppose
<LarstiQ> loxs[]: the crux of the problem should be answered by finding out why you need the central branch to have a working tree?
<loxs[]> well, speaking strictly we don't...
<LarstiQ> ok, so why not nuke it then?
<loxs[]> because my colleagues will wonder what's happening :)
<LarstiQ> for publishing revisions you only need the branch part, not the working tree.
<LarstiQ> loxs[]: happenening in what case?
<LarstiQ> loxs[]: you can certainly have a workingtree present on your central branch, but it makes things more complex.
<LarstiQ> so unless you really really need it, I advise against doing that.
<loxs[]> well, if I get it right, the central repository will not contain the actual files, only the .bzr and the history...
<LarstiQ> loxs[]: right
<loxs[]> some of my colleagues, especially my boss, don't care much about bzr... they expect to be able to see what's going on by visiting the central directory (it's a Novell environment)
<loxs[]> it's central and it's being backuped and so on
<LarstiQ> so this is more of an education/workflow thing.
<LarstiQ> loxs[]: you could use a 'central' working tree that is in a different location than the 'central' branch, and have the former autoupdated.
<uws> loxs[]: You shuold setup something like Trac or Loggerhead
<loxs[]> yes, that exactly am I asking... how to do the autoupdating :)
<LarstiQ> loxs[]: cron :)
<uws> loxs[]: that is MUCH more useful for browsing the files and history
<loxs[]> cron... it's windows :(
<uws> loxs[]: how do you push to it? sftp?
<LarstiQ> loxs[]: other options are bzr push-and-update and bzr upload, but again probably not on windows.
<loxs[]> no uws, the central repo is part of the filesystem (it's Novell environment)... just simple directory path
<loxs[]> yeah, LarstiQ, these two commands are not present
<LarstiQ> loxs[]: they are plugins, but afaik both require ssh.
<loxs[]> yes, automirror also required ssh :/
<LarstiQ> loxs[]: see http://bazaar-vcs.org/BzrPlugins
<loxs[]> looking at ti
<loxs[]> *it
<LarstiQ> loxs[]: so, if you decide to keep your central working tree, when people make changes to it but don't commit, they will be merged when you run bzr update
<loxs[]> when I run bzr update on my checkout copy you mean?
<LarstiQ> loxs[]: if they try to commit when the working tree is out of date, bzr will tell you so and you have to update first.
<LarstiQ> loxs[]: no, this is all speaking about the central one
<loxs[]> yes, I tried it, I know... and its fair thing as far as I see
<LarstiQ> loxs[]: if people make uncommited changes to the central one, there is no new revision, and hence update on a different checkout will do nothing.
<loxs[]> I'll resolve the issues when they emerge
<LarstiQ> loxs[]: you will still have to run update on the central copy to bring it up to date.
<loxs[]> yes, there is probably no other way
<loxs[]> thanks
<LarstiQ> really, I do think you're best off without it.
<uws> yeah, loggerhead or trac will give much better information
<LarstiQ> and as uws said, loggerhead is a much better solution for seeing what the status is
<LarstiQ> loxs[]: and I would try to teach people how things might be different from what they expect.
<loxs[]> I will try that, for sure :)
<uws> just not having a central working tree means there can't be any confusion
<loxs[]> yeah, if everyone is familiar with bazaar :)
<LarstiQ> loxs[]: if they are not familiar with bazaar, they see an 'empty' directory, or one with just a .bzr/ dir beneath it.
<LarstiQ> loxs[]: I hope your colleagues aren't in the habit of randomly deleting things that look like empty directories to them.
<loxs[]> yeah, and they start to recover from the backups :)
<loxs[]> it happened today :)
<LarstiQ> doh.
<LarstiQ> loxs[]: but even if they do, you have a branch of your own and can easily recreate the central branch, there is nothing special about it perse.
<loxs[]> how, LarstiQ ?
<LarstiQ> loxs[]: if it so happens that they delete the central branch, from your copy just 'bzr push location/to/central'
<loxs[]> hmm... I start to understand how much Bazaar rocks :)
<LarstiQ> loxs[]: that will put the .bzr/ back in place. Won't give you a working tree (but since in this scenario the dir got deleted because your colleagues didn't see a working tree anyway, no problem)
 * LarstiQ heads off to visit his dentist.
<loxs[]> one more question.... let's say I checkout a branch.... then I checkout from the checkout.... What happens if I try to commit in the 'grandchild'?
<LarstiQ> loxs[]: bzr will complain that what you're trying to commit to is bound to something else in turn.
<jelmer> LarstiQ, your dentist has IRC ? :-P
<jelmer> james_w, do you think it would be possible to get bzr-svn 0.4.12 into Intrepid?
<uws> LarstiQ, loxs[]: what I do with branches on shared storage with empty directories (i.e. no working tree), is putting a README file in there explaining that ppl shouldn't removed the directory
<loxs[]> that's exactly what I'm doing at the moment uws :)
<uws> something like "This is a Bazaar branch without a working tree. All files are in the .bzr/ directory. Please do not delete it."
<LarstiQ> jelmer: it seems I failed at getting away.
<james_w> jelmer: possible yes, you'd have to ask
<vila> damn, is there a way to cancel a pqm-submission ?
<beuno> vila, move the submitted branch?  :p
<beuno> hi  :)
<jelmer> vila, get some canonical sysadmin to knock over the pqm machine? :-P
<vila> I just reviewed http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080712104527.GA16321%40mutt.xyzz.org%3E and after sending the submission I realized there was a related bug and in the comments it was decided to wait for other fixes
<vila> beuno, jelmer: yeah thanks for the support :)
<LarstiQ> hmm, iirc in the past I had the queue edited
<LarstiQ> vila: I don't recall any other support for it
<vila> I just commited on that branch some sabotage that should make the submission fail, hopefully
<vila> LarstiQ: Hi !
<vila> I know a lot of work has occurred on pqm but I think we still use an old version
<vila> but I'm not sure the queue handling has been developed anyway
 * LarstiQ nods
<LarstiQ> vila: hey :)
<vila> damn, pqm catch my branch to soon :-(
<vila> s/catch/merged from/
<vila> jam: any advice ?
<vila> me/ reads 'LarstiQ heads off to visit his dentist.' and wonders what the point is to visit a dentist without its head...
<vila> s/its/his/
<uws> vila: ever heard of handheld devices with an internet connection? ;)
<vila> uws: you mean Larstiq's head is hand held ?
<LarstiQ> vila: 'heads off (to)' is an idiom for going away/somewhere.
<LarstiQ> uws: nah, I'm still at home.
<LarstiQ> vila: earlier today a jawsurgeon removed two wisdomteeth, now I'd like to bring the OPG photos back to my dentist.
<uws> LarstiQ: dus je pwaat een beetje mwoeilijk?
<LarstiQ> uws: it's not that bad, it's surprisingly easy to talk through clenched teeth.
<vila> especially on IRC...
<LarstiQ> :)
<uws> only bad thing is that you only have half of your wisdom left.
<LarstiQ> they'll be gone the 8th of october.
<quicksilver> vila: I believe LarstiQ removed his head and sent *only* that to the doctor.
<quicksilver> vila: cheaper.
<quicksilver> dentist.
<quicksilver> whatevr.
<vila> quicksilver: aaah, I thought the dentist connected via internet or something
<vila> jam: should I re-submit with a reversed patch ?
<lifeless> vila: what happened ?
<vila> I just reviewed http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080712104527.GA16321%40mutt.xyzz.org%3E and after sending the submission I realized there was a related bug and in the comments it was decided to wait for other fixes
<vila> :-/
<lifeless> did you munge the branch ?
<lifeless> or has pqm landed it ?
<vila> pqm is currently running the tests, I tried modifying my branch but it was too late
<lifeless> ok
<vila> rats, pqm has already finished :-(
<lifeless> its not running anything :P
<lifeless> reset
<vila> lifeless: merged on  http://bazaar-vcs.org/bzr/bzr.dev, I just received the 'success' mail from pqm
<lifeless> yes
<lifeless> I just uncommitted
<vila> lifeless: thanks ! problem closed ?
<lifeless> should be :P
<vila> pfew
<vila> sorry for that :-/
<lifeless> jam: bug 262565 - I think its falling between us right now, please let me know if you need me to dive into it (though its a little daunting)
<ubottu> Launchpad bug 262565 in bzr "Old resolved conflicts resurrected" [Undecided,New] https://launchpad.net/bugs/262565
<alsuren> I have a project in bzr, and I would like to add 2 levels of directories above my current top level directory (for buildsystem and python namespace package support)
<alsuren> what's the best way to do this?
<sabdfl> alsuren: make the directory, then bzr add it
<alsuren> and then just move everything from my tree into that directory?
<alsuren> will that fuck up my bzr ignore rules?
<Peng_> alsuren: Sure, but you can edit .bzrignore.
<Peng_> If subtrees weren't all experimental, you could create a new branch and use "bzr join". Hm.
<alsuren> when are subtrees going to become mainstream?
<alsuren> I think I might just just keep the namespace package hierarchy out of version control for now
<Peng_> It's normal to have "build" and "mypackage" dirs in your source control.
<alsuren> I know. I will put them in once I have it working outside of version control. Right now, I'm adding a testing framework
<techtonik> Hmm.. Is it possible to change commit message in bazaar history without reverting and recommiting all changes?
<techtonik> Also, how can I delete one revision from repository in a convenient way?
<Jc2k> techtonik: bzr uncommit?
<Jc2k> uncommit deletes a revision
<Jc2k> uncommit is probably also the easiest way to chage a commit message, but does mean you are effectively reverting and recommitting..
<techtonik> df
<techtonik> I need to change log message deep in history
<SteveA> hi
<techtonik> uncommit reverts only last revision
<SteveA>  I have a branch, and I want to make a bundle of the last 2 committed revisions
<xif> Hi.
<SteveA> I tried to use bzr send and bzr bundle, with -r-2..
<SteveA> but, it gives me an error "bzr: ERROR: No submit branch known or specified"
<xif> Is there a way to set a bzr branch, so that `bzr st` would always imply `bzr st -V`?
<ajaksu> Ã§Ã§
<ajaksu> oops
<techtonik> xif: to hide unversioned files branchwide use "bzr ignore"
<xif> techtonik: hm, but then I'd need to `bzr ignore` any new file added to the branch, right?
<jam> SteveA: generally with send, you just want to keep 2 branches
<techtonik> xif: you need to ignore only files that you do not want to be added to branch, but still present in your working copy
<jam> one as a mirror of theirs
<jam> and the other as your working branch
<SteveA> jam: is 'send' the same as 'bundle' ?
<jam> SteveA: not entirely
<jam> they create the same kind of objects
<techtonik> xif: and you may use file masks
<jam> but have a slightly different ui
<jam> and "bzr bundle" itself is mostly deprecated
<SteveA> all I want really is a command which means "create a bundle out of revisions 9 and 10 of this branch"
<jam> SteveA: so unfortunately that is
<techtonik> me too.
<jam> bzr branch -r 8 . ../other_tip
<jam> bzr send ../other_tip -o ../outputfile.patch
<SteveA> why do I need ../other_tip?
<jam> SteveA: because abentley wants to make sure you include the right revisions in the request
<jam> he felt it was too easy to send the wrong ones
<SteveA> that's kinda confusing
<jam> so he requires another branch to reference
<jam> SteveA: If you try "bzr send -r 8..10 ."
<SteveA> I feel like I just made these revisions, and now I want to send them :-)
<jam> it would see that all revisions are in the branch
<jam> and send an empty bundle
<techtonik> confusing a lot
<SteveA> hmm, trailing dot
<SteveA> ok
<xif> techtonik: OK, is there a simple way to tell bzr to ignore everything except foo.py and bar.py?
<jam> SteveA: abentley basically feels that people make mistakes, so he wants you to use an explicit branch for reference
<SteveA> I think this is a UI mistake
<jam> SteveA: we've had a lot of discussions on it, I'm hoping to invoke him now :)
<SteveA> because I'm trying to explain to someone a really simple workflow of "you make revisions, then you send them to me"
<abentley> SteveA: Not requiring a branch was a bigger UI mistake.
<SteveA> and now I need to say "you track my branch and you do other stuff"
<jam> One suggestion was that a bundle should always include the explicitly referenced revisions
 * LarstiQ does agree with abentley that it's very easy to make bundles that won't apply
<abentley> Because people kept submitting bundles that were unusable.
<SteveA> I don't really mind if the bundles won't apply
<SteveA> I can just ask for more revisions
<SteveA> not a problem in my case
<SteveA> I can see it being a problem in the "a community of loosely collaborating people" case
<abentley> SteveA: The whole point of bundles is to be mergeable.  Perhaps you want patches instead.
<xif> techtonik: OK, looking at the bzr ignore docs, looks like there should be. thanks.
<SteveA> I don't think I want a normal patch
<SteveA> I want to be able to re-merge the other way too
<SteveA> so, I'm now confused as to what I need to do
<jam> SteveA: so Aaron's point is that if you don't mirror their branch
<jam> then you'll sometimes guess wrong
<abentley> SteveA: "bzr bundle" is a strict subset of "bzr send".  They use the same implementation.
<jam> and you'll actually need 7-9
<jam> rather than just 8-9
<techtonik> xif: only with regexps - i.e. "RE:(?!foo.py|bar.py)"
<jam> and the bundle won't actually be usable
<xif> techtonik: yup :)  thanks.
<jam> until they request again
<SteveA> if I've got the other branch, maybe I can just say "bundle what's missing" ?
<jam> *I* feel like that is ok
<jam> SteveA: If you do "bzr send ../other-branch" it will do the right thing
<SteveA> that would make it worth tracking the other branch
<jam> And once you've done a send
<SteveA> ok
<jam> I believe it will default to tracking the other branch
<jam> so you can just do "bzr send"
<SteveA> ok
<jam> (no arguments)
<jam> You need a shared repo, for efficiency at this point
<jam> which is a level of complexity...
<SteveA> oh, that means moving directory structures around
<abentley> jam: Or stacking :-)
<techtonik> abentley: I want patches. 10-15 patches - one for each revision to apply them carefully one by one.
<SteveA> this is a small project
<SteveA> so I think having 2 duplicated branches is okay
<techtonik> abentley: ..after I change my log message
<abentley> techtonik: Perhaps you should have a look at the "rebase" plugin.
<SteveA> thanks jam and abentley
<abentley> SteveA: np
<abentley> SteveA: We do get occasional complaints like yours.  My current plan is to add a "--base-revision" parameter.  That revision and all its decendents which are ancestors of the tip revision would then be included in the bundle.  If supplied, it would remove the need for a branch.
<Snaury> Hello, can I replay changes in one branch on another branch without doing merge? (the branches are unrelated, it's just that the same project was started from the same sources again, i.e. it's as if the old .bzr directory was removed and a new bzr init was done, now I'm trying to merge those histories)
<SteveA> abentley: ok.  I tried -r
<techtonik> abentley: sounds complicated.. and there is no windows version. I just need to fix one little revision (or better replace it with another revision) deep in history without reverting and recommiting all subsequent revisions manually.
<SteveA> abentley: I wouldn't have thought to try --base-revision
<xif> techtonik: looks like `bzr ignore 'RE:(?!foo.py|bar.py).*' works
<xif> though I wonder why `bzr ignore 'RE:(?!foo.py|bar.py)$'` did not.
<abentley> SteveA: Well, I agree that it should be *possible* to override the auto-determination of which branches to include.  I don't think it's the right default.  I'm open to other ideas of how to make it possible.
<abentley> SteveA: s/branches/revisions
<techtonik> xif: because former is assertion that says "ignore everything that does not have foo.py or bar.py at start" and latter says "ignore empty strings if they are not prepended by foo.py or bar.py"
<abentley> techtonik: what you are asking for is exactly what rebase was designed to do.  Are you sure that you need a windows-specific version?
<SteveA> abentley: how will the other guy keep his copy of my branch up to date, when I'm also sending him bundles?
<SteveA> abentley: does he have to know that he pulls every bundle I send him into his copy of my branch, and then merges my branch into his own branch?
<abentley> SteveA: If there's no public copy of your branch, that would make sense.
<SteveA> ok
<techtonik> well, I am on windows 2000 and virtualbox ceased support for this platform, so I am pretty sure I do not have any other systems at hand right now
<abentley> techtonik: Most bzr plugins work on all platforms.  Are you sure that rebase does not?
<techtonik> abentley: Oh, sorry. I've forgot the bzr is in Python. Usually windows stuff is not distributed in sources, so when I looked at page with variuos Linux packages I thought it is not there. Will check this tomorrow. Thanks. Unfortunately need to go.
<xif> OK, is there anything one should do, beyond deleting the .bzr directory, to turn a Bazaar branch into a regular directory of files?
<luks> `bzr export` can make a new directory
<Jc2k> you could also just do bzr export
<Jc2k> snap
<jam> vila: on the "make init-repo take '.'" did you read the ML thread?
<jam> I was pretty sure we decided *not* to merge it
<jam> because of problems with accidentally creating a repo at the wrong location.
<xif> right, but if I don't want to create a new copy of the directory, just stop versioning it, I should just remove .bzr, correct?
<vila> jam: yup, but I read it too late, AFAIK lifeless uncommit it from bzr.dev
<jam> vila: ok, I just saw it in the commit logs
<jam> bazaar-commits@
<vila> I tried sabotaging my integration branch when I realized but too late too :)
<SteveA> abentley: still having problems
<SteveA> bzr: ERROR: Your branch does not have all of the revisions required in order to merge this merge directive and the target location specified in the merge directive is not a branch: ../steve_branch
<vila> I also voted resubmit on the submission in to avoid further overzealous reviewers :-/
<SteveA> that was from trying this workflow where we both have a copy of each other's branch, and we pull bundles into that branch, then merge from our local copy of the other's branch
<SteveA> it worked for 0.75 of a cycle
<SteveA> then I got that error
<SteveA>  ../steve_branch is the name of the local copy of my branch on the other guy's machine
<SteveA> so I don't know why I'm seeing that in the error message on my machine
<jam> vila: I don't see it on "bzr log" though, so it sounds like he did uncommit it
<jam> and yeah, thanks for doing resubmit
<vila> jam: yup, same here
<LarstiQ> SteveA: 'the target location specified in the merge directive is not a branch' looks a bit suspect.
<SteveA> for some reason, when I do "bzr pull /tmp/bundle5.diff", it's looking at ../steve_branch as part of doing that
<SteveA> and sure enough, in bundle5.diff, there is the line
<SteveA>  target_branch: ../steve_branch
<SteveA> I don't understand what that means though
<SteveA> that's a local branch of the guy who sent me the bundle
<SteveA> and now I have the bundle, I obviously don't have that local branch
<SteveA> if he was going to send me that branch anyway, then I wouldn't need the bundle at all
<jam> LarstiQ, SteveA: That is the "fallback" code, which attempts to use a "public branch" to fill in any revisions you might be missing.
<jam> I believe it uses:
<jam> 1) Revisions in the target
<jam> 2) revisions in the bundle
<jam> 3) Revisions in the "public branch" of the submitted directive
<vila> SteveA: I used that exact workflow on a previous project, setting things up was a bit painful, but once we had correct mirrors of each other, it worked flawlessly
<jam> The idea being, if you've published your branch (as most people do *for bzr*)
<jam> then even if the MD isn't complete
<jam> we can still fill in the gaps
<jam> In this particular case, I'm not sure if the error message is helpful or just confusing.
<vila> The trick is to lie to bzr making it believe that one mirror is really the branch of the other guy
<SteveA> jam: this is not public code
<jam> SteveA: I understand that
<jam> I'm giving you the logic that is used when merging a bundle
<vila> May be I should have talked about it on the list so that *this* workflow is easier to setup, but I thought it was really an obsur edge case
<SteveA> jam: and I thought using bundles would be an easy way for us to exchange revisions
<jam> vila: It would be good to have it clearly documented
<jam> SteveA: I think it should work
<jam> we just need to figure out what steps you are doing
<vila> I have it clearly documented :-) In french but easy enough to translate
<abentley> jam: 3) is actually the target_branch in the directive.
<SteveA> I started off doing a bzr branch http://hismachine/thebranch
<SteveA> because we're in the same office
<SteveA> and I can do that now
<SteveA> from that point on, assume we're disconnected, and have only email
<abentley> SteveA: It is only trying to use the target branch because the bundle was incomplete.  It would otherwise just use the bundle.
<SteveA> I need to go now, unfortunately.  vila, if you get this online somewhere in english, please let me know, and I'll try it out
<jam> abentley: right, I'm trying to figure out how an incomplete bundle was generated.
<jam> My first guess is that the revisions are in "mybranch" but not in "mymirror"
<jam> because he isn't using a shared repo
<vila> jam: I didn't use a shared repo and it worked
<jam> vila: did you ever fetch the revisions between the two branches?
<jam> with a fake "bzr merge"
<jam> etc
<vila> No, but I had trouble at first because he didn't have an exact mirror of my branch
<jam> I know how I would set it up and expect it to work
<jam> but as I didn't actually test it
<jam> I'm hesitant to give exact details
<loxs> folks, I have a problem. I create a repo with bzr init-repo --no-tree sftp://bla. Then I push a branc: cd branch, bzr push sftp://bla/branch. After I checkout the branch from somewhere else with bzr co sftp://bla/branch I get the following structure /branch/branch/content instead of /brach/content
<vila> jam: The trick is that since there is no public branch to share, each site needs to keep a mirror of the other one and work in its own branch. Then each site needs to name its mirror as the branch of the other site and use *relative* paths to trick bzr.
<vila> then, the workflow is as SteveA said: pull in mirror, merge
<jam> vila: sounds like a bug in our code
<jam> if you have to do the naming trick
<jam> I would be happy for you to document it
<jam> write a bug
<jam> and have us fix it
<loxs> vila, jam, are you talking about my case? because I suppose so, but I am not very sure :)
<jam> loxs: no
<jam> I have the feeling you did your "init + add" incorrectly locally
<jam> specifically you should do:
<jam> mkdir local
<jam> cd local
<jam> copy content here
<jam> bzr init
<jam> bzr add content
<jam> bzr commit -m "content"
<jam> loxs: make sure that doing
<vila> jam: bug ? Because we don't expand the relative path into a full one in the bundle header ?
<jam> "bzr branch local_branch another_location"
<jam> vila: because pulling bundles into a local mirror fails to get things that it really does want
<jam> vila: you should be able to track someones branch
<jam> without having to play tricks with your local branch names
<jam> now, it *may* be that using a shared repo solves it well enough that we'll defer fixing the bug
<jam> but if someone does "bzr send ../my-mirror-of-them" I would expect them to be able to do
<jam> "cd the_real_other_branch; bzr pull the-patch"
<jam> sorry,
<jam> bad terminology
<loxs> yeah, still wondering are you talking about my case or not :)
<jam> User A has 2 branches: mirror-of-B, A
<jam> loxs: I'm talking to 'vila', not your use case, I did mention one thing, but I'll come back to you in a bit
<jam> User B has 2 branches: mirror-of-A, B
<jam> They *should* be able to collaborate with only doing:
<jam> cd B
<jam> bzr send -o ../mirror-of-A
<jam> and on the other side
<jam> cd A
<jam> sorry
<loxs> ok, jam... but please be so kind to tell me "loxs, now I'm talking about your case" :)
<jam> cd mirror-of-B
<jam> bzr pull
<jam> cd ../A
<jam> bzr merge ../mirror-of-B
<jam> bzr commit -m "merge in other user"
<jam> loxs: ok, back to you....
<jam> loxs: step 1) do "bzr branch my_branch other_location"
<jam> and see if that creates a subdirectory "branch" that you don't want
<jam> if so,
<jam> then you did your "init + add" in the wrong directories
<loxs> I didn't do init+add.. I did a push
<loxs> isn't it a good way to do it?
<jam> loxs: When you *started* you did init + add
<jam> or you would have *nothing* to push
<jam> (you also did 'commit')
<jam> I'm saying
<jam> create a new branch from what you've already done
<jam> *without* pushing to the remote machine
<jam> I believe you accidentally included the branch directory
<loxs> the thing is that I already have a nice repository that I was working with... and it is quite fine tuned... now I want to push it to a central server
<vila> jam: I see, what I did was setting up things so that people could do: 'cd mirror; bzr pull <path-to-patch>; cd ../branch ; bzr merge' and then 'hack; hack; commit; bzr send' without any parameter to type for 'bzr merge' nor 'bzr send' kind of bzr for dummies, I was in a hurry :)
<loxs> but yte, I'll inspect my repository
<loxs> *yes
<jam> vila: sure, and I want that to work without having to follow an exact formula with branch names.
<jam> "bzr send" defaults to the "submit_location"
<jam> which is used by "bzr merge"
<jam> so it *should* remember everything just fine
<jam> (after the first time)
<jam> At least, the default changed recently, not sure if that was 1.5 or 1.6
<vila> I think I made them work with bzr-1.3, but *I* was working with bzr.dev
 * vila coming from kitchen
<vila> jam: Isn't it possible for SteveA to use a private branch on lp ?
<vila> We should support this alternate workflow but using a private branch can be easier no ?
 * vila going back to kitchen
<jam> vila: well, using a semi-public (aka lp private) branch is certainly easier for this sort of thing
<jam> but I *would* really like to have pure email
<jam> as the transport between two branches
<jam> and have it work
<luks> hmm, 1.7 has feature freeze today, who can I bribe to get my register_lazy_command reviewed? :)
<abentley> luks: Do you think that the existing Registry.register_lazy wouldn't work, or did you just not want to do it?
<luks> abentley: the main problem are aliases, it would need a subclasses which stores also aliases and allows to look them up
<luks> as far as I can tell, registries are currently just key/value, key/lazy-value
<luks> s/subclasses/subclass/
<loxs> folks, is there a way to specify a user when using bazaar over sftp?
<abentley> luks: Registries are not just key/value, they are key/value + help +  info
<abentley> luks: info is meant to contain additional metadata, like aliases.
<luks> oh
<rocky> anyone here know of a web server component written that will serve loggerhead for browser access but serve actual smart server responses for direct bzr branch access?
<luks> abentley: ok, I see how it could work. but still I'd really like if 1.7 could get at least some register_lazy_command
<luks> it's probably too late for me to submit a patch that uses this approach
<luks> the current patch just extends the API, doesn't change anything so can't introduce any regressions
<abentley> luks: I have some sympathy, but on the other hand, I first suggested this approach on Aug 26, and there was lots of time then.
<abentley> So I suggest keeping it in your plugin, and doing it right in 1.8
<luks> abentley: well, lifeless suggested the LazyObjectGetter approach, and you voted just comment, so I assumed it's not ideal, but good enough
<luks> er, abstain
<abentley> luks: Abstain means I don't want it in, but if other people think it's a good idea, I won't stand in their way.
<luks> ah, I read it more like "I don't care enough about this"
<abentley> luks: Well, since lifeless suggested this approach, perhaps he'll review it for you.  He should be up in a couple hours.
<loxs> is there a way to make bzr write some 'standard' data in the beginning of every file? things like licensing information, last commiter of the file etc.?
<Odd_Bloke> jelmer: I'm getting http://paste.pocoo.org/show/84210/ when trying to pull bzr-svn trunk.
<jelmer> Odd_Bloke, are you pulling into a subtree repository by any chance?
<Odd_Bloke> Yes.
<Odd_Bloke> jelmer: Should I do a fresh branch of it?
<jelmer> Odd_Bloke, there was a bug open about this
<jelmer> Odd_Bloke, try branching into a rich-root-pack repo
<Odd_Bloke> jelmer: Cool, thanks. :)
<jelmer> Odd_Bloke, I'm pushing a lot more changes you probably want
<jelmer> hmm, this is getting ridiculous
<jelmer> pushing a new tree into my remote bzr repository now spends about half its time pushing signatures
<Jc2k> jelmer: is that a sign that bzr is getting faster at the vanilla pushing :P?
<jelmer> Jc2k, could be (-:
<Jc2k> :-)
<jelmer> imo pushing is still way too slow compared to e.g. git
<jelmer> with bzr, I find myself switching to a different terminal when I run bzr push
<jelmer> with git push, I just wait for it to finish
<Jc2k> i have a little bit of evolution weirdness
<jelmer> Jc2k, ?
<Jc2k> bzr info -v on the repository is shwoing 36889 revisions
<Jc2k> http://bzr-mirror.gnome.org/bzr/evolution/.bzr.log shows 36246 revisions
<jelmer> if a svn commit changes multiple branches in svn, it ends up being more than one revision in bzr
<jelmer> e.g. if somebody changes both /trunk and /branches/foo in the same commit
<Jc2k> i suppose 600 occurences of that isnt that often in evolution terms...
<jelmer> some svn commits don't result in bzr commits at all
<jelmer> e.g. if they change just the branches directory (nothing under it)
<jelmer> or if they add a tag (since tags aren't versioned in bzr)
<radix> Odd_Bloke: hi, did you work on merge directives for PQM?
<Odd_Bloke> radix: Yup.
<radix> Odd_Bloke: does it require use of PGP/MIME?
<radix> odd_bloke: the reason I ask is that I got this error: PQMException: 'Second part of multipart message must be application/pgp-signature'
<Odd_Bloke> radix: Nope, inline is fine.
<radix> hmm, then what's with the error?
<Odd_Bloke> radix: You can only send multipart messages if the first part is the content and the second part is application/pgp-signature.
<Odd_Bloke> And even that's not recommended.
<radix> oh, so if my message happens to be multipart it will assume it's going to be PGP/MIME?
<Odd_Bloke> Yeah, afraid so.
<radix> Hmm, I don't think I *tried* to send a multipart message, but who knows what evolution does
<radix> maybe thunderbird is less weird
<jbalint> hey
<Odd_Bloke> radix: Bug #264139.
<ubottu> Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Undecided,New] https://launchpad.net/bugs/264139
<radix> Odd_Bloke: cool, thanks. hopefully I won't need to wait for it to be resolved :)
<Odd_Bloke> No.
<Odd_Bloke> I've finished for the summer, so that could be a while. :p
<radix> :)
<LarstiQ> Odd_Bloke: move to the southern hemisphere!
<Odd_Bloke> radix: It occurs to me that you need to make sure that the merge directive is in the body of the message, rather than attached.  Which may be your problem...
<Odd_Bloke> LarstiQ: Commuting to Rugby is bad enough from Coventry, let alone south of the equator. :p
<radix> Odd_Bloke: the strange thing is that I tried using the "editor" email program and signed the message inline but got the same error
<radix> Odd_Bloke: I'm going to try again
<Odd_Bloke> radix: Try using 'bzr send -o <FILE>' and copying the contents of <FILE> directly into your email client.
<radix> Odd_Bloke: hmmm
<radix> Odd_Bloke: does it support base64-encoded data?
<radix> apparently "gpg --sign --armor" will encode stuff in base64 automatically if it's got "weird" stuff in the body
<Odd_Bloke> radix: What do you mean by 'base64-encoded data'?
<Odd_Bloke> Bundles are base64-encoded, and it obviously supports those. :p
<LarstiQ> Odd_Bloke: what does pqm do if the merge-directive is base64 encoded entirely?
<radix> Odd_Bloke: like this:
<radix> -----BEGIN PGP MESSAGE-----
<radix> Version: GnuPG v1.4.6 (GNU/Linux)
<radix> owGVUz1vFDEQPRIhoZUojoZ2EooApz28X3eblaIExAkKTgpJKpLo5LV9t0527Y3X
<radix> etc.
<Odd_Bloke> I expect it falls over.
<radix> If you sign "hello world" it just adds the usual header/footer, but if you sign "====\n----" it base64s it
<radix> presumably because that stuff could be misinterpreted as the header or footer for the pgp thing, so it's just encoding it to avoid misinterpretation
<radix> Odd_Bloke: it looks like you're also working on the XMLRPC interface... I'd so much rather use that :)
<Odd_Bloke> radix: I suggest passing '--no-patch' to 'bzr send'.
<radix> ah, I'll try it
<Odd_Bloke> Because PQM doesn't (or, at least, shouldn't) be using the patch.
<radix> hmm, it seems to base64 it anyway. I guess it's really conservative. There are things like the "--- this line and the following will be ignored", not to mention all the headers etc
<radix> well, I don't think I need to do it this way anyway
<radix> I was just trying to get it working in editor
<Odd_Bloke> radix: Isn't --armor _meant_ to base64 it?
<radix> Odd_Bloke: not always
<radix> --armor means "use ascii not binary", where binary output is the default
<radix> i.e. stuff which will require you to type "reset" in your terminal
<radix> oh, crap
<radix> I think I am wrong about that
<Odd_Bloke> 'echo "foo" | gpg --sign --armor' gives me base64 encoded stuff.
<radix> ok, I am on crack, sorry
<Odd_Bloke> radix: No worries.
<radix> I wonder how to get gpg to give me normal ascii output without base64ing
<Odd_Bloke> You probably want '--clearsign'.
<radix> Odd_Bloke: yes! thanks
<radix> Odd_Bloke: btw, does your XMLRPC/PQM support allow multi-line commit messages, or does it have the same problem that the usual email mechanism has?
<Odd_Bloke> radix: At the moment, it doesn't.
<Odd_Bloke> But it would be much easier to add than with email.
<radix> Odd_Bloke: sweet.
<radix> Odd_Bloke: ok, for future reference, it seems that using "bzr send" with mail_client set to "editor" can't work, because it sends the merge directive as an attachment
<Odd_Bloke> radix: Yeah, that's an issue.
<Odd_Bloke> radix: If you could mention that on Bug #264139 it'd be appreciated.
<ubottu> Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Medium,Confirmed] https://launchpad.net/bugs/264139
<radix> cool
<jam> Odd_Bloke: I posted a bunch of response questions to the "bzr speed" question.
<jam> radix: are you doing "gpg --clearsign" rather than "--sign" ?
<jam> sorry, you already got there :)
<radix> jam: I am now, odd_bloke suggested that to me already :)
<radix> :)
<jam> radix: well, you just need to teach pqm about attachments
<jam> considering that 90% of how you would send it
<jam> would be with an email program that would use an attachment, too
<radix> yeah
<radix> also, "bzr send" seems to totally not work with thunderbird, for what it's worth
<jam> and, I guess, that is bug #264139
<radix> it doesn't include the merge directive at all, somehow
<ubottu> Launchpad bug 264139 in pqm "PQM doesn't deal with multi-part messages well" [Medium,Confirmed] https://launchpad.net/bugs/264139
<jam> radix: bug in thunderbird when spawned via the debian "default mail client" scripts
<jam> we have a workaround, let me dig it up
<radix> ah
<jam> (you have to set the mail client to t-bird instead of default)
<radix> jam: I did that too, it still doesn't seem to work
<jam> radix: in bazaar.conf add the line
<jam> mail_client = thunderbird
<Odd_Bloke> jam: 'bzr pqm-submit' probably has a fair share of submissions.
<radix> ops wait
<radix> my bad
<jam> Odd_Bloke: "submissions" ?
 * radix had it commented out
<radix> hmm, it adds it as an attachment in thunderbird as well
<jam> Odd_Bloke: I'm not sure what you mean by that sentence
<radix> I predict this will break
<radix> hmm, unless I use PGP/MIME, and hope that thunderbird adds the signature as the second part.
<jam> radix: Mail.app, thunderbird, editor, etc, etc all use an attachment
<jam> radix: for T-bird you can select whether you want it to sign just the first part, or the whole thing
<jam> though I've encountered bugs with enigmime and signing attachments
<jam> where sending it to myself
<jam> it ends up thinking the signature is invalid... :(
<jam> So I only sign the text documents now
<jam> (not the attachments)
<Odd_Bloke> jam: Sorry, I meant to say that I guess a lot of submissions to PQM would be using 'bzr pqm-submit' rather than 'bzr send'.
<radix> so how do people use the merge directive support at all?
<radix> it seems there's no configuration which can possibly send stuff that it will accept
 * lifeless pops up
<radix> morning lifeless
<Odd_Bloke> radix: 'bzr send -o <FILE>' and copying the contents of <FILE> into the body of the email should work.
<radix> Odd_Bloke: ok, I'll try that one
<radix> Odd_Bloke: hmm, where do I put the commit message in that case?
<Odd_Bloke> radix: Subject line.
<radix> d'oh!
 * Spaz storms in
<radix> that defeats my reason for using merge directives :)
<jam> radix: I've never used it. AFAIK Odd_Bloke's changes didn't make it into PQM mainline
<radix> I want to have a multi-line commit message
<jam> hi Spaz
<radix> jam: oh, yeah, that's true, we're using the branch specifically
<Spaz> hello jam :)
<Odd_Bloke> radix: Yeah, that's not easily possible via email.
<radix> because we love odd_bloke's code
<Odd_Bloke> s/easily/trivially/
<jam> Odd_Bloke: well, it is easy to create multi-line subjects that PQM accepts
<jam> look at the bzr.dev mainline
<jam> it just does so by accident
<jam> more than by intention
<jam> (Subject lines are automatically wrapped by mail clients, and pqm just accepts them "as is")
<radix> jam: hmm
<radix> maybe we will resort to that :)
<radix> jam: and it actually maintains the newlines that the mail clients introduce in the header?
<jam> radix: "bzr log --short http://bazaar-vcs.org/bzr/bzr.dev -r 3679"
<jam> multi-line commit
<radix> great
<jam> radix: from what I can tell, it maintains the newlines *and* indentations
<radix> oh, which is a bit crappy :)
<Odd_Bloke> radix: Where would you have expected the commit message to go with a merge directive submission?
<radix> Odd_Bloke: when you run "bzr send" you get an area for typing a commit message before a "-- everything after this line will be ignored"
<jam> Odd_Bloke: well, *I* would have put it in the body, possibly with a custom header, and then had the MD as an attachment :)
<Odd_Bloke> Well, if your mail client doesn't include the indentations, then you're probably fine.
<jam> Odd_Bloke: email RFC requires the indentations
<jam> or it is not part of the previous line
<Odd_Bloke> Ah, OK.
<jam> lines starting with spaces are meant to be wrapped back into the previous line
<jam> PQM doesn't really follow a lot email RFC
<Odd_Bloke> Yeah, that's what I was just thinking. :p
<Odd_Bloke> Anyhow, I have to head to bed.
<lifeless> well
<radix> Odd_Bloke: thank you very much for the help
<Odd_Bloke> What with having a job and all. :o
<radix> even though it led to me giving up on PQM for a bit more :)
<lifeless> Odd_Bloke: gnight
<Odd_Bloke> radix: No worries, sorry I couldn't be of more help.
<Odd_Bloke> Night all!
<gigi-gigi> ciao
<gigi-gigi> !list
<ubottu> Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<pooliex> good morning
<beuno> mornin' pooliex
<beuno> how was your vacation?
<pooliex> great, thanks
#bzr 2008-09-03
<pooliex> spiv, jam, lifeless, call in a bit?
<pooliex> abentley, do you want to join too?
<spiv> Sure.
<jam> pooliex: I'm on linux tonight, but I'll listen in
<pooliex> i don't see you online yet
<jam> pooliex: check now
<abentley> pooliex: Sure.
<abentley> jam: I understand your frustration re: path-LCA.  But I have planned my evening around reviewing it.  And the pokes just make me irritable.
<jam> abentley: point taken, I'll try not to get in your face about it. It was meant more playfully anyway.
<jml> lifeless: hi
<jml> lifeless: I've figured out how to change the branch format for testing, but the repo format is giving me more problems.
<jml> lifeless: it looks like the default repo fmt for metadir is derived from the bzrdir format registry
<lifeless> oh
<zbrown> Anyone have a good resource or example for writing hooks in bzr? Most of what I've come across seems somewhat vague
<lifeless> zbrown: what sort of hooks?
<lifeless> [much of the code base is hookable; its a pretty broad question]
<zbrown> lifeless: would like to write a pre-commit hook for running a syntax checker and test suite
<zbrown> lifeless: so "make syntax-check" and "make check"
<lifeless> I believe spiv did work on this most recently
<lifeless> spiv: ^ your public awaits
 * zbrown awaits spiv eagerly
<lifeless> zbrown: I'm grabbing lunch, I'll give you a hand if spiv hasn't when I return
<zbrown> lifeless: ok, thanks
<spiv> I did start writing some docs on this, let me refresh my memory.
<spiv> zbrown: so you've already seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks ?
<spiv> Actually, I need to go grab some lunch now too.
<spiv> I'll be back in a while.
<zbrown> spiv: I saw it, I guess I was a bit confused when I was trying to figure out how to do the pre-commit hook
<jml> lifeless: any idea what to do about that?
<jml> (when you get back from lunch)
<zbrown> spiv: I might have figured it out :)
<zbrown> hrm
<lifeless> jml: hmm
<zbrown> lifeless: any idea if its possible to make a hook that can be distributed with a project? That is a hook that a user doesn't have to add to his/her ~/.bazaar/plugins
<zbrown> ?
<lifeless> zbrown: hooks are arbitrary code, so there is a clear security issue there
<lifeless> zbrown: generic hooks -  like the email one - allow them to be configured by a branch/proejct
<lifeless> zbrown: there is also the shell-hooks plugin jelmer wrote, which as a generic plugin can be configured per-branch [though it runs arbitrary code, again security concerns apply]
<zbrown> hmmm
<zbrown> Guess my dream of minimal developer intervention is a bust, thats okay, just means copying a file to a directory ;)
<zbrown> Thanks much :)
 * zbrown is off to bed
<lifeless> gnight
<splodge> Can anybody tell me the best way of splitting a branch in two? If I have a 'trunk' branch and have want to split it so that some files are in branch 1 (b1) and the rest are in branch 2 (b2).
<splodge> Is the preferred method (keeping the history and everything) to bzr branch it push it to a different place (on Launchpad) and then delete files in each branch that aren't required for it?
<lifeless> splodge: that works well
<splodge> This is actually part of a larger problem I'm solving: I have a project where some there are three parts - two separate and one shared. We figured that we would split the code across three branches and pull each one separately. Does anyone have any suggestions from experience on this or another layout to accomplish this?
<splodge> Thanks lifeless
<splodge> Sounds logical enough but thought it better to check ;)
<splodge> actually, can someone help me with a layout. i'm struggling to come up with something that will meet my needs. i need three branches, each containing a number of modules (each module consisting several individual files). branches b1 and b2 don't share code but both use the modules in the shared branch 'core'. i then want to allow releases to be made by taking a snapshot of all three branches and placing the in another location.
<AfC> Sounds like you just need a shell script
<splodge> i want to be able to group them, i guess then. so perhaps trunk/b1, trunk/b2 and trunk/core? with releases like r1/b1, r2/b2 and r2/core? hmm...
<splodge> AfC: can you elaborate?
<splodge> i suspect i'm overthinking this :(
<lifeless> splodge: why not, three branches; A, B, C
<lifeless> A has whatever including core
<lifeless> B has whatever including core
<lifeless> C is just core
<lifeless> and you merge from C to A and/or B as needed
<splodge> oh i see. that could work.
<splodge> there is duplication there though isn't there
<lifeless> how so ?
<splodge> with C's code being duplicated into both A and B's and relying on the devs remembering to merge in.
<splodge> we also only want one copy of C when checked out
<lifeless> well
<lifeless> either you have three projects
<lifeless> which are independent
<lifeless> or you have < 3.
<lifeless> decide :)
<splodge> ummm... :)
<lifeless> how big is C? GB's? TB's ?
<splodge> oh they're only small at the moment and we don't expect them to grow into GBs
<splodge> at the moment it's paltry: <100MB :)
<lifeless> so
<splodge> if it helps clarify a little: they are parts of the same project. it uses drupal and we have two sites (supplied by code in branches A and B) and a common lot of modules (C).
<splodge> so A is checked out to sites/site1/modules/A and B to sites/site2/modules/B, and C to sites/all/modules/C
<lifeless> what you want might strictly be nested trees, but that feature isn't finished yet.
<lifeless> what I describe is probably the cheapest and most robust thing available today.
<splodge> ok
<splodge> thanks
<AfC> splodge: if you can be flexible enough to maintain the different branches lifeless describes, I'd encourage you to follow that idea. It will work well if you keep it simple.
<splodge> thanks. i'm just doing more reading up on this and then i'll make a decision, but it looks like that's the way i'll probably go.
 * splodge still has a bit to learn :)
<AfC> It is indeed easy to overthink these things. Actually, that's a common problem in most software development and related activities.
 * fullermd thinks about that for a week or two.
<jml> lifeless: ok, now *I'm* back from lunch
<jml> lifeless: are we still stuck for ideas?
<lifeless> is it too broad to say 'we should fix it' ?
<lifeless> I mean, if someone asks for 'default' as a format, they get a fully specified BzrDirMeta format
<lifeless> if they do BzrDirMetaFormat(), does that need to be == ? I think not, which is why changing the branch was snesible
<lifeless> Repository can probably just stop asking for 'default' and ask for BzrDirMetaFormat9), IFF it has lost its old explicit default information
<jml> lifeless: can I call you about this stuff?
<lifeless> jml: yes
<jml> lifeless: skype ok?
<lifeless> yes
<Peng_> lifeless: bzrlib/readdir.h is copyright 2006?
<lifeless> Peng_: yes
<lifeless> Peng_: annotate it :P
<Peng_> Hmm, _ReadDirFeature.feature_name returns 'bzrlib._btree_serializer_c'?
<lifeless> heh, good catch
<lifeless> I'll fix in a minute
<Peng_> :)
<pooliex> lifeless, that book is pretty entertaining/interesting
<lifeless> good
<techtonik> About that "rebase" plugin..
<pooliex> vila, hi, are you up?
<vila> pooliex: sure, for nearly 2 hours
<pooliex> how's it going?
<techtonik> So, about that rebase plugin.. It would be good extremely helpfult to remove references to git from "rebase" documentation, because it fails to clearly explain any usage examples without sending adepts to enlightning by smoking git man.
<guilhembi> pooliex: hi! there? time of our phone call?
<pooliex> guilhembi, hi!
<vila> pooliex: summarizing how we show revisions in various commands to see how to fix bug #233817
<ubottu> Launchpad bug 233817 in bzr "missing doesn't show merged revisions" [High,Confirmed] https://launchpad.net/bugs/233817
<pooliex> techtonik, good point
<pooliex> vila, that sounds like a good place to start
<vila> I think the simplest way to fix it is to implement --show-merged or something first and then we can look at bringing more consistency between the various commands
<vila> I'll mail the list about that
<jelmer> hmm, the bzr-svn testsuite is now running out of file descriptors :-(
<jelmer> is there any way to force selftest to do garbage collection more often?
<uws> jelmer: import gc; gc.collect() ? ;)
<techtonik> from "rebase" documetation at http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html (well, bzr doesn't have such examples)
<techtonik> Home come that for the following branch     E---F---G---H---I---J  topicA
<techtonik> given the command    git rebase --onto topicA~5 topicA~3 topicA
<techtonik> the removed revisions are F and G ???
<Odd_Bloke> techtonik: It's saying rebase the revisions from revision 'HEAD minus 3' to the HEAD revision onto 'HEAD minus 5'.
<markh> jelmer: why do you ask about the gc?  ie, what symptoms you see without it?
<markh> I've a patch in the queue that adds a few try/finally blocks to ensure a few files etc are closed upon error, which avoids most problems that a gc.collect() happens to solve
<markh> on windows anyway ;)
<jelmer> ah, ok
<jelmer> could be that it helps then
<markh> jelmer:         ico_map = dict(map_items)
<markh> bugger :)
<markh> oh, why can't I copy/paste from my vm!
<markh> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C019a01c8fe73%2427a26f30%2476e74d90%24%40com.au%3E
<techtonik> Odd_Bloke: thanks, the idea of relative revisions is something I could not even imagine before =)
<Odd_Bloke> techtonik: No worries.
<techtonik> Just for interest I've run testcase with 1.6 standalone on Windows 2000
<techtonik> FAILED (failures=120, errors=267, known_failure_count=11)
<techtonik> 969 tests skipped
<techtonik> Is it really ok?
<awilkins> techtonik: It's not perceived as "OK" but it is the status quo
<awilkins> techtonik: Efforts are being made to reduce and eventually (?) eliminate windows failures
<techtonik> Cool. Seems like an interesting stuff to do.
<awilkins> techtonik: As a fairly heavy user on windows I can tell you that I only enounter one or two issues in daily use, and my usage pattern is pushing the envelope as far as the average user goes
<awilkins> Most of my frustration is with the IIS server support but that seems to be reasonably functional now, esp. from IIS 7
<markh> techtonik: yeah, its really OK
<awilkins> (and it's mostly the fault of IIS for being a rather inflexble webserver)
<markh> awilkins: I've done alot with IIS and ISAPI actually
<awilkins> markh: I've got HPSS working out of IIS with PyISAPIe
<markh> what problems did you have with iis6?
<awilkins> markh: https://bugs.launchpad.net/bzr/+bug/262366
<ubottu> Launchpad bug 262366 in bzr "Client uses mixed mode for HTTP URIs on smart server" [Wishlist,Triaged]
<markh> right - I've got to catch up on pyISAPI - IIUC, it leans in pywin32's isapi support, which I've only used "natively"
<markh> actually just released a 64bit isapi proxy server written in python :)
<techtonik> it seems to work here too, but i have to keep some settings in batch files and run local proxies and tunnels, which is complicated for other people in a team, esp. testers
<techtonik> i would say that bzr is extremely complicated in setup, but once it works it's a pleasure
<awilkins> techtonik: !
<awilkins> techtonik: The server infrastructure can be complex, but basic use is very simple once you understand a couple of things
<lifeless> awilkins: skips are not a problem
<techtonik> awilkins: so far I am using only client with launchpad
<awilkins> lifeless: skips?
<lifeless> awilkins: skips are normal - they relflect that not all things implement all interfaces; and other such status; this is what I alluded too recently on-list
<awilkins> Oh, yes, skipped tests
<lifeless> oh. I missed the lines before skipped :)
<lifeless> obviously the failures are status quo :P
 * awilkins thought briefly about KP Skips
<markh> awilkins: right - I think you need to trick IIS6.
<awilkins> markh: http://bazaar-vcs.org/ServerGuide/IIS
<markh> approach we took was to use a filter to "rewrite" the request to a virtual folder we own.  That virtual folder has an extension that maps to '*' - it 'unrewrites' the URL, then does what it does
<markh> that way it gets everything
<awilkins> markh: What I think needs to happen is that PyISAPIe needs to support a particular call to the ServerSupportFunction API
<markh> awilkins: which call is missing?
<markh> most are there
<awilkins> The one that "passes" the request to the next handler in the chain (in this case, IIS itself)
<markh> that is there...
 * markh looks
<Jc2k> .wg 16
<Jc2k> ;_;
<awilkins> markh: If you can tell me how to do it from the Python API, I'll fix my server script and IIS 6 will be golden
<markh> the filter just returns isapicon.SF_STATUS_REQ_NEXT_NOTIFICATION
<markh> I'm not sure pyISAPI supports filters
<markh> they are quite different than extensions
<awilkins> No, it's an extension
<awilkins> But if you use extensions as wildcard extensions in IIS6 you can apparently get them to pass on a particular request
<markh> yes - to do what I said you need a filter *and* an extension
<markh> see the 'redirector.py' sample in pywin32's isapi/samples directory
<markh> right
<awilkins> markh: I have it working through just the extension
<markh> yes, that avoids the need for a filter at all with iis7
<markh> I mean to get iis6 working
<awilkins> markh: It just breaks if you use plain http://
<markh> so - I can't recall exactly what is missing to do what you refer to for iis7 - but I do recall looking at it in the past :)
<awilkins> markh: David Wangs blog refers to this
<awilkins> http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_IIS_6_Request_Pro
<awilkins> cessing_Basics_Part_1.aspx
<awilkins> http://blogs.msdn.com/david.wang/archive/2005/10/14/HOWTO_IIS_6_Request_Processing_Basics_Part_1.aspx
<awilkins> sorry
<awilkins> It's not exactly clear about how you say "I'm handling this" or "I'm not"
<techtonik> "rebase" doesn't work as in git.
<techtonik> I would like to remove revision 5 from history using rebase using the command     bzr rebase --onto=5 -r 6 . --dry-run
<techtonik> It says No revisions to rebase.
<markh> awilkins: yeah - iis6 sucks that way - and the filter can be used to work around it (ie, to make it easier to say what you handle).  iis7 does add something new iirc to make the filter unnecessary.
<awilkins> markh: Yes, you can use proper wildcards to choose handlers, not that "file extension" crap
 * markh starts having inklings about SF_NOTIFY_PREPROC_HEADERS..
<markh> so - IIRC, the fact only filters can do what SF_NOTIFY_PREPROC_HEADERS does is the main "problem" that forces us to use a filter
<markh> and that later IIS versions allow extensions to perform that role
<awilkins> markh: The discussion in the posted blog would seem to indicate that you can get a wildcard extension to pass a request to the next handler though ; I just wish it was more explicit as to how
<markh> yeah - and SF_NOTIFY_PREPROC_HEADERS is where you can modify the URL variable to *force* the request to your extension
<markh> regardless of extension etc
<awilkins> markh: My working theory was that you call ServerSupportFunction with HDS_REQ_EXEC_URL
<awilkins> Meh. So you have a filter that remaps /.bzr/smart to a different virtual dir with the smart server on it?
<markh> iis7 can do that without a filter iiuc - but I can't recall if can yet ;)
<markh> if pywin32
<awilkins> markh: My working theory was that you call ServerSupportFunction with HDS_REQ_EXEC_URL
<awilkins> But I'm a little in the dark really - the documentation is a bit murky
<markh> awilkins: yes!  that's the one :)
<awilkins> http://msdn.microsoft.com/en-us/library/ms525758.aspx
<awilkins> So what I was wanting was a facility in PyISAPIe to call that and pass the request down the chain to the normal IIS handler
<markh> so yeah, I should add that to pywin32 and that redirector sample.  However, that doesn't help iis6 :(
<awilkins> That is an IIS6 function
<markh> oh right - 5 :(
<markh> I'm a version behind - no good in win2k
<markh> but we can ignore that these days ;)
<awilkins> It's not like it's hard, but my C is bad.
<markh> I think the idea is you call that function that the current request "restarts" using the new URL
<markh> anyway - dinner and g/f have arrived :)
<awilkins> Go smell the sweet scents of food and female, see you later :-)
<palango> do anybody have ever used the bzr-rebase plugin?
<jelmer> palango, yes :-)
<palango> great :)
<palango> I 've some problems using it
<jelmer> techtonik, rebase is evil, one of the main reasons bzr-rebase exists is for git refugees
<F_R_A_N_K> Hi All
<jelmer> hi F_R_A_N_K
<palango> please have a look at: http://paste.ubuntu.com/43043/
<palango> I'm creating a parent branch and and child branch
<palango> adding some revisions to the child
<palango> and as far as I understood the rebase command it will make one revision out of these two
<F_R_A_N_K> I have a quick simple question (I guess). If I upgrade a branch (bzr upgrade). Is there a risk that someone else with an older version of bzr can't work with this branch anymore/is getting problems?
<jelmer> F_R_A_N_K, Yes - users with older bzrs can't use an upgraded branch
<jelmer> F_R_A_N_K, see "bzr upgrade --help" for the list of minimum versions required
<techtonik> jelmer: when what is the true way of taking revision out of history? or better replacing it with somthing else?
<jelmer> palango, bzr rebase doesn't combine revisions
<F_R_A_N_K> Jelmer: What  will happen then, are they getting warned that they need to upgrade? Or do tthey get a weird error message?
<jelmer> F_R_A_N_K, They'll get a one-line error message like "Unknown branch format: Rich Root Pack (needs bzr 1.0)"
<F_R_A_N_K> ok
<palango> jelmer: what does it do then?
<jelmer> palango: it replays revisions on top of a different parent
<jelmer> techtonik, why would you want to take a revision out of history?
<F_R_A_N_K> Jelmer, as I read it you need minimum V0.92 of bazaar. Correct?
<jelmer> F_R_A_N_K, depends on what format you upgade to
<jelmer> packs-0.92 needs bzr 0.92
<techtonik> jelmer: well, because I've submitted wrong comment under wrong commit and I need either replace commit or edit comment
<palango> jelmer: I read http://www.gnome.org/~federico/news-2008-08.html#12 and thought bzr-rebase does the same!?
<jelmer> techtonik: Any reason for not uncommitting?
<jelmer> palango, bzr-rebase doesn't have --interactive
<F_R_A_N_K> I am facing reall speed problems. I also opened a ticket for it. Still having these repositoryFormatKnit1 formats. It was suggested to upgrade (bzr also gives this advice). So what version would be best to get much better performance?
<techtonik> jelmer: well, only one - history log afterwards
<palango> jelmer: is this planned?
<jelmer> F_R_A_N_K, pack-0.92 (the default) would be the best choice
<jelmer> techtonik, ah, ok
<jelmer> techtonik, in that case, rebase probably would be the best choice indeed
<F_R_A_N_K> Jelmer, thanks. I will. So everyone who has a newer version then 0.92 of bzr woundn't face any problems.
<jelmer> F_R_A_N_K, correct
<jelmer> 0.92 is almost a year old atm
<F_R_A_N_K> we started our project 7mnths ago
<F_R_A_N_K> most users started 5 mnths ago
<F_R_A_N_K> AFAIK all versions are >V1.2
<techtonik> jelmer: but it doesn't work. for example if I want to omit revision 5    bzr rebase --onto=5 -r 6 . --dry-run
<techtonik> It says No revisions to rebase.
<jelmer> techtonik: That command doesn't make sense, r6 already has r5 as parent
<F_R_A_N_K> Jelmer: bzr: ERROR: Revision {('arjan@iceshop.nl-20080422081505-59su2hfkrs8eguwc',)} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x8776fcc>".
<spiv> F_R_A_N_K: with 1.6?  I think that's fixed in 1.6.1rc1.
<jelmer> F_R_A_N_K, You may have to run "bzr reconcile" before upgrading
<F_R_A_N_K> yes with 1.6
<spiv> (Or I could be misremembering)
 * spiv -> bed
<F_R_A_N_K> reconcile I already tried yesterday, it takes more then 5 hours to run........... So I aborted it.
<techtonik> jelmer: Ok.   bzr rebase --onto=5 -r 7 . --dry-run   works the same
<jelmer> F_R_A_N_K, please try 1.6.1rc1 like spiv is suggesting
<jelmer> F_R_A_N_K, reconcile should be faster with packs, but that's a bit of a chicken/egg problem :-(
<F_R_A_N_K> Now it runs in 1 sec.
<F_R_A_N_K> all okay it says
<F_R_A_N_K> How do I do this? V1.6 is the latest if I upgrade.
<uws> may I suggest a less annoying nickname for F_R_A_N_K?
<pasky> I'm somewhat confused about the currently used merge methods in Bazaar - does Bazaar currently use the classic three-way merge or something else?
<pasky> wiki describes various things like knit merge but it's not clear what are the currently available methods and which one is the default
<uws> pasky: see "bzr help merge"
<uws> Frenzel: (thanks)
<Frenzel> uws: This better? :-)
<Frenzel> Jelmer: how do I check if all is okay now?
<pasky> uws: can i view that documentation somewhere online?
<luks> pasky: standard 3-way merge by default
<jelmer> Freaky: Sorry, what runs in one second now?
<uws> pasky: dunno, but it's included in your bzr installation
<luks> and it has two other optional merge modes
<pasky> i don't currently have any bzr installation handy :)
<luks> pasky: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#merge
<uws> pasky: http://pastebin.com/m6a5eacd  ;)
<pasky> thanks both! :)
<Frenzel> jelmer: bzr reconcile
<uws> though luks' suggestion is probably better
<jelmer> Frenzel, ah,ok
<jelmer> Frenzel, in orderto be ableto run upgrade correctly, I think you'll haveto downgradeto 1.5 or upgradeto 1.6.1rc1
<Frenzel>  bzr reconcile
<Frenzel> Reconciling branch file:///var/bzr/batavi/
<Frenzel> revision_history ok.
<Frenzel> Reconciling repository file:///var/bzr/batavi/
<Frenzel> Reconciliation complete.
<pasky> hmm, are the non-default merge algorithms used commonly?
<Frenzel> pasky: only normal merges are done
<Peng_> pasky: The LCA and weave merge algorithms handle criss-crossing better, so I use them sometimes.
<pasky> so the default is merge3? how does it handle multiple lcas?
<pasky> ah
<Frenzel> Jelmer: what to do now? Upgrade again?
<Frenzel> I have now version V1.6.1RC1 installed
<jelmer> Frenzel, yep
<Frenzel> Is there a risk that this goes wrong? becuase then I like to go back to the old version and test it before doing this live again.
<Frenzel>  bzr upgrade --default
<Frenzel> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<Frenzel> a checkout now gives:bzr: ERROR: Could not install revisions:
<Frenzel> dimitry@iceshop.nl-20080902143335-49g8v32pi88v1v14
<Frenzel> Jelmer: any ideas?
<jelmer> Frenzel, that's with 1.6.1rc1 ?
<jelmer> Frenzel, if so, I have no idea :-( Perhaps jam can comment when he wakes up
<Frenzel> local I have V1.6
<Frenzel> remote is V1.6.1RC1
<Frenzel> Jelmer, can we revert this upgrade? If I am correct the upgrade make a backup right?
<jelmer> Frenzel, yes, it keeps a copy of .bzr in backup.bzr
<Frenzel> how to revert it?
<Frenzel> is there a command for it?
<Peng_> Frenzel: Just rename the directories
<Frenzel> Peng_: tnx, it worked
<Frenzel> back to old version
<Frenzel> Will retry tonight again, when I have more time.
<Frenzel> Bye guys!
<strk> I found gnulog.py to generate ChangeLog , but doesn't work with bzr 1.6 looks like, can you confirm ?
<LarstiQ> strk: possibly.
<strk> http://telecom.inescporto.pt/%7Egjc/gnulog.py
<strk> is there a more up-to-date place for distribution of such plugins ?
<LarstiQ> strk: http://bazaar-vcs.org/BzrPlugins
<LarstiQ> but that url seems to be the current known location
<strk> yep, same url
 * LarstiQ downloads the plugin
<LarstiQ> strk: it shouldn't be too difficult to bring it up to date.
<strk> just sent a mail to the author
<LarstiQ> strk: what part of it doesn't work for you?
<LarstiQ> oh wait, I tried it with 1.5
<strk> bzr log -v --log-format 'gnu'
<strk> bzr: ERROR: Bad value "gnu" for option "log-format".
 * LarstiQ did bzr log --gnu
<strk> don't even know if the plugin is loaded actually
<strk> bzr: ERROR: no such option: --gnu
<strk> how can I tell if it's been loaded ?
<LarstiQ> strk: where did you leave the plugin? And see `bzr plugins` for a list of loaded ones
<strk> in ~/.bazaar/plugins
<strk> ops, indeed 'bzr plugins' doesn't find it
<LarstiQ> strk: correct location
<LarstiQ> strk: check ~/.bzr.log to see why it fails to load.
<strk> correct extension too ? *.py ?
<strk> there's no trace of it in .bzr.log
<strk> other plugin seems to be loaded from /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py
<LarstiQ> strk: yup, that's fine.
<strk> um
<strk> 0.049  looking for plugins in /home/strk/.bazaar/plugins
<strk> 0.049  looking for plugins in /usr/lib/python2.5/site-packages/bzrlib/plugins
<LarstiQ> strk: although the recommended way to do plugins is to have them in a dir
<strk> there's an ignore file under ~/.bazaar/plugins
<strk> containing a line: *.py[co]
<strk> shouldn't match .py though
<LarstiQ> I'm not aware of plugin loading using ignore files.
<strk> ah, I didn't have the 'plugins' subdir
<strk> seems to be working now
<LarstiQ> you had ~/.bazaar/gnulog.py instead of ~/.bazaar/plugins/gnulog.py?
<strk> yep
<LarstiQ> strk: ah :)
<strk> did anyone think about adding more verbosity to it ?
<strk> we mostly commit in branches, then merge, then commit to trunk
<strk> gnulog.py does NOT include commit logs from branches, which are the more interesting usually
<LarstiQ> strk: you'll have to find other users of it :)
<jam1> abentley: ping, I need a bit better understanding of the InterKnit1And2 definitions for bug #264321
<ubottu> Launchpad bug 264321 in bzr "KeyError in generate_root_texts during push" [Critical,Triaged] https://launchpad.net/bugs/264321
<jam1> I thought it was about subtree support
<jam1> but it seems to actually be about rich-root support
<abentley> jam: well, RepositoryFormatKnitPack5RichRoot uses a serializer that supports subtrees, even though it's only supposed to support rich roots.
<abentley> Your diff doesn't apply to bzr.dev
<abentley> jam: It's not about subtree support.  It's about rich-root support.
<abentley> jam: There's no fancy footwork needed to convert from rich-root to subtree.  You just deserialize and reserialize.
<jam> abentley: ok, so the basic patch is correct? That the variable names were wrong
<jam> so the ones in the "yes" column should support rich-root
<jam> and the ones in the "no" column should not
<abentley> jam: I guess.  It's hard to tell-- you've removed all lines and then added them again.
<jam> abentley: ah, the conflict is that robert got rid of "development0" in bzr.dev
<jam> so it needs to be "development1" in the various places
<abentley> jam: I thought development1 was in 1.6 also.
<jam> abentley: it wasn't expose to this location
<jam> people have really *not* been keeping this up-to-date
<jam> for 1.6.1 I added a bunch of them
<jam> but thought it was about subtree support
<jam> and obviously was wrong
<abentley> It's because we introduced rich-root formats after this.
<jam> abentley: http://rafb.net/p/3EoJiR97.html
<jam> That is the diff
<jam> without the extra comments
<jam> KnitPack4 is a subtree format
<jam> wait, it is rich-root-pack
<jam> Hence why I thought it should go in "nosubtrees"
<abentley> jam: It looks fine to me.
<jam> abentley: would it be better to just use:
<jam> if not source_format.rich_root_data and target_format.rich_root_data:
<jam> instead of manually tracking them a second time?
<abentley> jam: You also have to ensure that they are knit formats.
<jam> abentley: so (atm) everything > weave, right?
<jam> I guess I'll leave it alone for right now
<jam> But I know it was getting out-of-date before *I* touched it for 1.6.1rc1
<jam> I don't remember specifically what was missing, but new formats weren't in the lists
<abentley> jam: correct, everything since weaves.
<jam> abentley: I think this is a requirement to go into a possible 1.6.1, but I'm wondering at this point if we should just punt for 1.7rc1 which will be available on Monday
<jam> I suppose for people who care, 1.6.1 will be a smaller update than 1.7
<jam> james_w: what is the Intrepid status/policy ?
<abentley> jam: I thought Intrepid was a reason for 1.6.1
<abentley> jam: :-)
<jam> abentley: *severe* performance problems with 1.6 and not realizing 1.7 was just around the corner was 1.6.1
<james_w> jam: I was going to put 1.6.1 in, as it fixes an important bug, and then look at 1.7 when it comes out
<abentley> jam: I don't want 1.6 in Intrepid, but otherwise, I'm cool with just getting 1.7 out.
<jam> james_w: so what you are saying, is that if I "fail" to get this important bug-fix in for 1.6.1, then you'll be forced to include 1.7?
<jam> :)
<james_w> that could be one way to do it
<james_w> though if they don't want to risk 1.7 they'll just ask for patches to be backported to 1.6
<jam> james_w: I'll just make sure the patches won't apply to 1.6
<jam> O:-)
<jam> Eventually I think you just have to cut a release, though. And 1.6.1 seems to be pushed back farther and farther...
<Lea> Does anyone know how I can version control files that include timestamps, i.e. <entry name="idle_delay" mtime="1207992864" type="int" value="120"> - i don't want files which only differ in mtime to show up in diff/status, or be commited etc.
<EarthLion> hey how do you commit with a . number e.g. 9.56 ?
<CardinalFang> Lea, I don't think you can ignore changes to files based on very specific content changes.  It sounds like you're saving the wrong thing, or misusing version control.
<CardinalFang> Lea, Perhaps you should process the file into something new, and save that.
 * Lea is attempting to version his home directory. however some programs have very annoying config file formats, such as everything using gconf.
<CardinalFang> Lea, yep.  This shows a fundamental flaw in home-dir tracking.  Some files are often and automatically changed with opaque data.
<vila> gnight all
<LarstiQ> Lea: a more succesful approach might be to have a seperate directory under your homedir you track, with a facility to build symlinks to the files under that.
<Lea> LarstiQ, that is in fact what i have
<LarstiQ> Lea: ah, and there are files you _do_ want to track, but they get touched too often?
<Lea> yup. problem is the data in the file isn't changing - however gconf is deciding to rewrite said files and changes the timestamps *inside* the file
<LarstiQ> great.
<LarstiQ> Lea: can you tell gconf to not do that?
<Lea> i've been looking but i can't find anything about it. it seems to be the app rewriting all the settings back into gconf, even when they haven't changed
<LarstiQ> ok.
<LarstiQ> Lea: there isn't anything that immediately comes to mind, but it should be possible with some plugin work I guess.
<Lea> k. thanks
<fattymattyo> how do I specify the port when using bzr?
<luks> fattymattyo: hostname:port
<fattymattyo> simple enough :-)
<tacone> luks: how to do that with the lp: syntax ?
<luks> tacone: why would you want to?
<luks> you can't use launchpad on different ports
<tacone> luks: guess it's me that misunderstood the issue fattymattyo was having.
<fattymattyo> the issue I'm having is that my ssh_config has my port set to something other than 22 so it tries to connect on a different port
<fattymattyo> and obviously doesn't work.
<tacone> here's the command he used: bzr push lp:~fattymattyo/rapache/newguy_branch
<fattymattyo> so I get this error...
<fattymattyo> ssh: connect to host bazaar.launchpad.net port 1031: Connection timed out
<fattymattyo> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<LarstiQ> fattymattyo: I'd suggest an entry for launchpad.net in ~/.ssh/config
<luks> oh, so you have globally set the SSH port to 1031 for all clients?
<fattymattyo> yes
<luks> I've never seen such configuration
<fattymattyo> apparently most people haven't
<fattymattyo> 90% of my servers are set up on the same port so it was easier for me
<fattymattyo> looking up the .ssh/config file I've never played with that before.
<fattymattyo> luks that seems to have worked, thanks for the help guys
<guilhembi> jam: hello! one good thing:
<guilhembi> I tested
<guilhembi> https://bugs.launchpad.net/bzr/+bug/238895
<ubottu> Launchpad bug 238895 in bzr "'bzr merge --weave/--lca' does not conflict on permutated lines" [Medium,Triaged]
<guilhembi> with --weave of your merge_lca_multi,
<guilhembi> and it outpus a conflict as desired.
<guilhembi> outputs
<guilhembi> and same with bzr.dev
<jam> guilhembi: yeah, that should probably be marked as fixed in 1.6
<jam> the new --weave format fixes it.
<jam> "--weave code"
<jam> but I guess --lca still has the issue
<guilhembi> jam: to confirm what you wrote, I just tested with --weave of bzr 1.3 --weave and it didn't see a conflict.
<guilhembi> jam: yes, --lca still has the issue. Though for MySQL, we'll use --weave.
<jam> guilhembi: yeah, in <1.6 'bzr merge --weave' was still an "annotation" merge not a real --weave merge.
<jam> well, until you go back to 0.8 or so :)
<jelmer> spiv, do you have any experience with coroutines in Python?
<LarstiQ> jelmer: didn't stackless allow you to make those with generators?
<jelmer> 2.5 also has something
<radix> python doesn't have coroutines
<radix> (unless you're talking about greenlet, the crazy C extension module)
 * LarstiQ reads http://www.weightless.io/coroutines
<Jc2k> jelmer: are you thinking of yield..
<jelmer> radix, http://docs.python.org/whatsnew/pep-342.html claims it does
<radix> jelmer: yes, and it's lying
<radix> jelmer: the fundamental difference between 2.5 generators and coroutines is that you can't context switch multiple stack frames at a time
<jelmer> radix, ah, ok
<jelmer> radix, Do you have any experience with greenlet?
<LarstiQ> jelmer: actually, I think the people behind http://www.weightless.io/weightless wanted to give a talk about it at one of the PUN meetings
<radix> jelmer: yes
<jelmer> radix, Is it worth a shot?
<radix> jelmer: I also wrote a bunch of concurrency stuff with generators
<radix> jelmer: it is unclear whether greenlet is not horribly buggy
<radix> the author doesn't really maintain it
<jelmer> oh :-(
<LarstiQ> radix: any comments on weightless?
<jelmer> lua does this really well, I'm trying to get close to that with Python
<radix> jelmer: what are you trying to do?
<radix> LarstiQ: never heard of it
<radix> LarstiQ: URL?
<LarstiQ> radix: http://www.weightless.io/weightless
<radix> LarstiQ: is this a python thing?
<radix> I guess it doe
<jelmer> radix: Trying to see if there's some way winbind can be reimplemented in Python (basically a server handling fancy database queries for multiple clients, preferably using coroutines
<LarstiQ> radix: yes, it is
<LarstiQ> jelmer: http://mail.python.org/pipermail/python-nl/2008-July/000826.html
<radix> LarstiQ: you may be interested to know that I am a Twisted developer, before I start offering my opinions: )
<radix> I'm also the author of Corotwine, which is a twisted/greenlet integration library
<jelmer> LarstiQ, thanks!
<LarstiQ> radix: yes, I know that :)
<radix> LarstiQ: the first thing I notice about weightless is that it's not Twisted :)
 * LarstiQ nods at radix 
<radix> it does seem to have more advanced integration with generators
<LarstiQ> jelmer: oh, and the post Erik refers to: http://mail.python.org/pipermail/python-nl/2008-June/000791.html
<radix> Twisted has inlineCallbacks, which is a way to use generators to deal with Deferreds using serial code
<jelmer> radix: what do you mean by "it is not unclear whether it is not horribly buggy" ? It's unreliable/unstable or simply?
<radix> jelmer: I think there is some debate about whether it integrates with garbage collection in a fundamentally broken way
<radix> jelmer: it seems that it may be easy to have uncollectable objects live forever
<radix> I haven't done much research into it myself, but I think arigo has acknowledged the problem
<jelmer> ok, I guess I'll stay away from it for now then
<radix> also, practically nobody uses it in production, as far as I've seen
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test bzr-1.6.1rc2 |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<radix> so that's probably enough evidence to stay away from it for serious projects :)
<guilhembi> jam: I'm going through all issues I had noticed (scanning support issues 2412 and 2413), they are all gone with your custom bzr.
<jam> guilhembi: good to hear
<jam> Let's hope it gets landed :)
<jam> spiv:  when you get a chance, I'm just poking at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080714010508.GG9654%40steerpike.home.puzzling.org%3E
<jam> It is mostly approved, and just needs a couple more tests and merged.
<jam> and lifeless, you semi-approved this on IRC the other day, but I submitted an update:
<jam> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48B708ED.6020703%40arbash-meinel.com%3E
<jam> Can you look it over and approve it?
<jam> (you original voted resubmit, but then said approve-ish on IRC)
<uws> bzr 1.6.1~rc1-1 is in debian unstable/experimental
<uws> eh, sorry, wrong channel
<igc> morning all
<poolie> hello igc!
<igc> hi poolie!
<poolie> spiv, lifeless, jam, igc, abentley, call in 5m if you want
<spiv> poolie: Just sent mail (to a valid address this time...), I'm sick today.
<mwhudson> spiv, poolie, etc: are you bazaar guys coming to london for this launchpad thingy?
<poolie> the jamboree in october?
<poolie> i was thinking about whether it would be worth the travel
<poolie> are you going?
<mwhudson> i don't have a choice, i think :)
#bzr 2008-09-04
<poolie> spiv, hope you get well soon
<kgoetz> win 2
<abentley> poolie: Sure.
<kees> how long should doing a "bzr upgrade" on a bzr+ssh URL take?
<lifeless> time to pull fully, time to push fully, roughly
<lifeless> faster if there is an optimised case for it
<kees> lifeless: ah, so it pulls, does the work locally, then pushes?
<kees> okay, strace shows that now... the upstream bandwidth was so low I wasn't seeing it my monitors.  :P
<kees> the progress bar isn't very helpful.  :)
<nDuff> AttributeError: 'SvnWorkingTree' object has no attribute '_transport' (in bzrlib.workingtree.WorkingTree.read_basis_inventory) trying to branch from a svn repo into a bzr one.
<nDuff> bzr 1.6, bzr-svn 0.4.12
<nDuff> (ubuntu packages, with http://ppa.launchpad.net/bzr/ubuntu)
<nDuff> ...hrm; looks like the branch operation succeeded; no working tree generated, but "bzr update" in the target location fixes that...
<nDuff> ...and "bzr check" claims everything's in good shape.
<lifeless> nDuff: please file a bug
<lifeless> nDuff: I suspect you did branch <svntree> NEWPATH
<lifeless> and its probably not tested by bzr-svn's test suite
<nDuff> where NEWPATH was under a preexisting shared repository
<nDuff> ...but yes.
<markh> we need an appeals process for reviews! ;)
<lifeless> markh: we have one; Reply.
<jml> or more reviewers :)
<markh> yeah, but if the complaint is about stylistic issues, hitting reply will just start a huge debate about stylistic issues...
<lifeless> markh: a review is a dialog, no more no less
<markh> I guess I mean the vote then
<lifeless> if a particular reviewer feels that some stylistic issue is sufficiently important to make it a requirement to land...
<lifeless> then either a) they are right, or b) they are wrong - and either way we should discuss it
<lifeless> an 'appeals process' sounds like a formalised huge debate IMO :)
<markh> or I should just stop complining, submit to the request and re-re-submit
<markh> and sigh :)
<lifeless> I'm happy to give my opinion if you tell me the thread
<nDuff> ...filed as bug 264548
<ubottu> Launchpad bug 264548 in bzr "AttributeError: 'SvnWorkingTree' object has no attribute '_transport' during branch" [Undecided,New] https://launchpad.net/bugs/264548
<lifeless> nDuff: thanks
<jml> jam: still around?
<poolie> hello jml
<poolie> do you still have teeth? are you back in sydney?
<jml> poolie: some. no.
<jml> poolie: back late tomorrow
<poolie> robert and andrew were going to work here on friday and then maybe go to the pub, you're welcome to come if you want (to either part)
<jml> poolie: I'll be landing at about 10:30pm
<jml> but thanks for the invite :)
<poolie> maybe next time
<jml> internet!
<RAOF> Is yours?
<strk> know a trick to check history of a single file ?
<strk> with 'viz' preferably
<strk> to easily check actual diffs between revs
<lifeless> abentley: does bb match the /exact/ sender field, or only the email portion ?
<abentley> lifeless: The exact sender field.
<lifeless> strk: well, log -v FILE is probably close to what you want
<lifeless> strk: I don't think viz has a per-file mode at the moment
<lifeless> abentley: oh. can you tweak an email address in bb for me then? user adri
<lifeless> strk: folk generally use annotate though, to look at a file
<abentley> lifeless: Sure.
<lifeless> abentley: Adrian Chadd <adrian@squid-cache.org>
<lifeless> I had just put in the email component
<poolie> strk, with gannotate you can doubleclick lines to see the diff iirc
<poolie> it would be nice to get viz too
<strk> wow, annotate got to my conclusion in a shot
<poolie> great
<abentley> lifeless: Done.  Note that it is an exact match, so I used "Adrian Chadd" <adrian@squid-cache.org>
<lifeless> thanks
<lifeless> back soon, shopping run
<lifeless> poolie: hi, I've reviewed the locks hook patch john said resubmit: to; I'm also asking for resubmit.
<poolie> lifeless: my patch?
<lifeless> I wrote a patch to hook locks
<lifeless> you updated it
<lifeless> I needed it today, and realised it was still unmerged
<poolie> now you want me to update it again and resubmit it?
<lifeless> I'm happy to do the update
<lifeless> we need to agree on how it should look though
<poolie> ok, i'm just preparing to send something then will look at it
<poolie> so
<poolie> my patch makes these hooks inconsistent with the other ones
<poolie> i agree the inconsistency is bad, and um
<poolie> to some extent the lack of testing is bad, though iirc the way it was done in the old code was not tested either
<poolie> i think the existing interface is both a bit unsafe and longwinded, but
<lifeless> the old code doesn't try 'restore to pristine' or clone a hooks object
<lifeless> uhm, anyhow
<poolie> yeah, anyhow
<poolie> let's not block this on changing that
<poolie> so, i think at least having specific names for that behaviour lets you think about changing it
<poolie> s/changing/testing
<poolie> lifeless: mini review sought of http://pastebin.ubuntu.com/43261/
<lifeless> poolie: looks good
<poolie> great
<poolie> anything missing?
<poolie> well, before you start
<poolie> anything missing that people are likely to misunderstand
<lifeless> nothing comes to mind
<lifeless> bbiab
<poolie> kthx
<j00bar> howdy! I'm a total bzr n00b and really just want to accomplish one thing. i'd like to checkout only a subdirectory of the trunk. this is easy with other vcs' like svn -- can it be done with bzr?
<Spaz> j00bar, you can't do that yet
<Spaz> j00bar, it will be possible in a few versions or so
<Spaz> sorry
<Spaz> j00bar, if the subdirectory is a branch, however
<Spaz> then you can
<j00bar> bugger.
<j00bar> it's a python project where the subdir has the actual code and the branch root has INSTALL, README, etc that i don't really want -- with SVN or other systems, i just check out the subdir and update as needed...
<Spaz> j00bar, most DVCS's you'll find don't support partial checkouts yet
<j00bar> but if it can't be done, it can't be done -- no worries -- thanks!!!
<Spaz> np
<vila> Goood morning Bazaar
<lifeless> hi visik7
<lifeless> meh
<lifeless> hi vila
<vila> hi :)
<visik7> :P
<lifeless> brane is flied
 * lifeless halts()
<jdahlin> I'm having a problem with bzr-svn 0.4 and bzr 1.5 shipped with fedora
<jdahlin> This is written to my .bzr.log: AttributeError: 'module' object has no attribute 'properties_handler_registry'
<james_w> jdahlin: you have a mismatch between bzr-svn and bzr versions
<james_w> I think your bzr-svn is too new
<jdahlin> yeah, I reverted a few commits and it appears to work now
<awilkins> Hmm, strk has gone
<awilkins> qlog has a per-file mode
<awilkins> markh: Hi there, are you building the bzr-svn extensions for windows?
<awilkins> markh: I've got a build error, did you run into this - error LNK2019: unresolved external symbol _svn_auth_get_windows_ssl_server_trust_provider referenced in function _get_windows_ssl_server_trust_provider
<awilkins> Never mind, looks like it's a "no longer supports svn 1.4 libraries" thing
<AnMaster> I have two questions: 1) what is "subtree support" 2) what is "rich root". Both are mentioned in bzr help formats, but I have been unable to find anything more detailed, like what it actually means
<AnMaster> and yes I have tried google
<sabdfl> AnMaster: they are related, iirc
<sabdfl> subtrees are when you have a branch, which in turn incorporates another branch
<sabdfl> subtrees let you manage that better
<AnMaster> um you mean like svn:external?
<AnMaster> or something else?
<sabdfl> i think so, yes
<AnMaster> ah ok
<sabdfl> rich roots are where there is a unique ID associated with the branch root, iirc
<sabdfl> it's a watershed - once you move the branch to a rich root format, you can't go back
<sabdfl> and generally, it should only be done once across a community, iirc
<sabdfl> so we haven't yet made it the default
<sabdfl> abentley would know more
<AnMaster> hm ok
<abentley> sabdfl, AnMaster: The relationship is that rich roots are a prerequisite for subtrees support.  But it turns out they're also useful for bzr-svn, which is why we provide formats supporting them.
<AnMaster> hm ok
<AnMaster> abentley, so subtree is basically same as svn:externals?
<abentley> AnMaster: Yes, but that feature isn't finished yet.
<AnMaster> right
<AnMaster> anyway that is not a feature I need, features I need/want are: 1) cherrypicking like darcs 2) faster push/pull for huge repos (close to git's speed preferred, but with the usability of bzr) 2) something like svn:eol-style
<AnMaster> err make the last one 3) heh
<abentley> AnMaster: We want to improve cherrypicking support, but we don't want to implement it the way Darcs does.  Their approach to patch handling leads to performance and integrity problems.
<AnMaster> hm ok
<pickscrape> I'm having a problem with the trac-bzr source browser, and I'd like a little help in debugging it.
<abentley> The other two are currently in development.
<pickscrape> My trac install consists of a plain directory containing a number of shared repositories with branches beneath them.
<pickscrape> When browsing the root of one of the branches, I get an error like this: NoSuchRevision: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision (revision)
<pickscrape> Is there any way I can find out why the browser thinks it needs that revision? The repository and branch seem to be working fine in general use.
<AnMaster> abentley, basically I need to merge bugfixes back to a stable branch from trunk (and sometimes the other way too), bzr can't handle keeping track of what revisions have been merged and what ones haven't.
<AnMaster> not when you skip some non-bugfix revisions in the merging
<abentley> Right.  We do want to add that, though no one is currently working on it.
<AnMaster> well I would if I was a python programmer
 * awilkins wasn't a Python programmer before he started scratching his own issues on Bazaar, but appreciates not everyone has the time to take out on solving problems in other projects
<awilkins> For me the choice was - use SVN and implement my own merge tracking or - use Bazaar and resolve any other issues you might confront
<awilkins> So far I'm _very_ glad I chose Bazaar
<AnMaster> awilkins, at least I don't have time before next summer holidays
<awilkins> AnMaster: What you are wanting is the tracking of cherry-picks
<awilkins> AnMaster: Have you tried a different merge algorithm? You may get more joy with something like --weave
<radix> AnMaster: if you make the bug fixes in the stable branch first, you can continuously merge the stable to the trunk
 * awilkins was just about to say that too
<radix> there's a page about this somewhere
<radix> I can't remember what it's called
<radix> anmaster: here it is: http://www.venge.net/mtn-wiki/DaggyFixes
<awilkins> So a combination of "bisect" to test for the bug presence, a branch, and a forward-merge (to both the stable bugfixing branch and the trunk) might work more cleanly (but is obviously slightly more of a PITA)
<AnMaster> hm will try that
<awilkins> Thanks for asking, I like learning new ways of doing things :-)
<pickscrape> Is there a command to check for the presence of a revision ID is a shared repository (or something I can use to achieve the same)?
<awilkins> bzr revision-info -r revid:<myrevid>   ?
<awilkins> Hmm, not sure about the shared repo bit
<pickscrape> Yeah, it complains about it not being a branch
<fullermd> You could stat -c it.  revision-info will blow up if that rev isn't in the current branch.
<fullermd> (other similar things like diff or testament would work too)
<pickscrape> Thing is, I don't know which branch the revision was been created against :)
<pickscrape> was been?
<abentley> pickscrape: it doesn't matter.
<fullermd> (of course, revision-info should be a little more polite about failing, but that's neither here nor there)
<awilkins> If stat and diff work with revid: (regardless of branch) then so should revision-info IMHO
<pickscrape> Oh, so it will search the entire shared repo regardless of whether the revision in question is a part of the branch's history or not?
<abentley> pickscrape: Yes.
<pickscrape> Sweet, thanks.
<fullermd> awilkins: Well, but revision-info wants to show the revid.
<fullermd> awilkins: Er, I mean 'revno'.
<fullermd> That fares poorly when the revision isn't in the branch...
<awilkins> Ugh, yes
<pickscrape> Thanks all, that's confirmed my theory. The revision that trac-bzr is complaining about exists in one of the other shared repositories.
<pickscrape> So the next question would be, why would it be picking up that revision in the first place...
<EarthLion> how can you commit with sub revision numbers e.g. revision no 7.3
<EarthLion> if i do bzr commit -m "blah" it always gives me a whole number
<EarthLion> the help doesn't have any info on this
<awilkins> EarthLion: Sub numbers are always nested revisions of merges
<awilkins> EarthLion: Revisions committed on the branch you are on are always single integers
<EarthLion> awilkins:  "Sub numbers are always nested revisions of merges" can you explain what that means
<awilkins> EarthLion: revisions numbers with more than one component are used to identify the revisions that are part of merges from other branches
<awilkins> You cannot commit revisions with more than one number in the branch you are working on
<EarthLion> ah ok i see thanks for explaining
<jelmer> awilkins, ping
<ericvw> I am still a bit confused between bzr init and bzr init-repo for an initial project; can someone give me why I would use bzr init-repo to start a project vs bzr init?
<fullermd> Oh, well, that's easy.  You wouldn't   :)
<ericvw> haha
<fullermd> init creates a branch, that you have files in and work in.  init-repo creates a repository, that a set of branches can use to share common history.
<uws> ericvw: init-repo only makes sense if you plan to have multiple branches and want to use shared storage for them
<uws> ericvw: but you can always convert later (trivial)
<uws> ericvw: (just branch your branch into a repository and you're done)
<fullermd> uws: Or use reconfigure   :)
<ericvw> uws: So if I had a branch with bzr init, and I decided to create a repository and wanted to add that solo branch to the repository what command should I look into?
<ericvw> But for individual or small peer use, I could probably get away with a init-rep
<ericvw> init-repo*
<fullermd> ericvw: You'd need to init-repo in a parent dir of your branch (or alternately, init-repo somewhere and move that branch into a subdir of it), then use reconfigure --use-shared.
<ericvw> fullermd: ok, I will experiment with this, thanks!
<fullermd> ericvw: init-repo doesn't give you somewhere to work; it's not an alternative to init.  It's a potential enhancement for some use-cases.
<ericvw> so in contrast to svn, the definition of repo is something different, right?
<fullermd> If you only ever have one branch, it doesn't gain you anything.  If a project is tiny, you probably wouldn't be able to notice what it gains.
<fullermd> Well...   yes, and no, and totally, and kinda.
<ericvw> yeah, that is what threw me for a loop at first
<fullermd> init-repo doesn't [shouldn't] change anything about how any commands work.
<fullermd> There's no semantic difference between doing $SOMETHING among two branches that are in the same shared repo, doing $SOMETHING among two branches in different shared repos, doing $SOMETHING among two branches neither of which is in a shared repo, etc.
<ericvw> ok, i think i am getting the concept now,  I will have to re-read the guide again to get a better understanding
<fullermd> For the purposes of initial experimentation, you can forget init-repo even exists.
<fullermd> You can switch to using it (or away from using it) on a given project at the drop of a hat.
<ericvw> fullermd: thanks for the explanations and help!
<ericvw> uws: you too as well :D
<ericvw> I am a little confused in doc-guide section 4.2.2 It talks about creating a repo and then grabbing a branch from someone else...; so in a 2 person environment, you may each have your own repo with a branch within it?
<abentley> ericvw: It is possible to do that, but the whole point of a shared repo is to put branches in it.
<ericvw> abentley: ok, thanks
<jelmer> when did bzr branch including tree generation get so freakingly fast?
<zbrown> jelmer: I think in 1.5 or 1.6
<abentley> jelmer: That was a bit of a team effort with ianc.
<abentley> We're currently hamstrung by poor index performance, though.
<abentley> I would *like* to be competitive with cp, at least in a shared repo.
<zbrown> I was quite impressed
<zbrown> and still am ;)
<zbrown> I still shudder to think what managing wine's repo in bzr would be like though
<jelmer> abentley, Thanks, it's now at least quick enough to "feel" instantaneous on non-huge trees
<gour> any idea why attempt to push from laptop to desktop machine fails - see log http://rafb.net/p/okZ1bY72.html
<gour> zbrown: don't know about wine's repo, but from today my machines are m$ free - i was finally able to make some proprietary folio infobase running under wine - no need for Virtualbox & similar emulators any longer :-D
<abentley> gour: could you try bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/.bzr/repository/
<abentley> Sorry, skip the end.
<abentley> bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/
<gour> abentley: same - http://rafb.net/p/pwZZw175.html
<gour> let me check if i push to the right dir
<abentley> gour: cfgfiles looks like it already has a repository.  Is that intentional?
<gour> hmm, the gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/ has the following format - gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/
<gour> oops, http://rafb.net/p/3c0gT377.html
<gour> and bzr upgrade says: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
 * gour thinks that having less supported formats would be better
<abentley> gour: Right.  Rich-roots are not a default format.
<abentley> gour: Talk to Jelmer.
<gour> abentley: ok. explicit upgrade to --rich-root-pack solved it
<gour> anyone responsible for bzr-gtk here?
<gour> ohh, it seems we solved it...
<zbrown> gour: haha, well I'm glad to hear it :). We (the wine contributors) are pleased with how far wine has come in the last few months
<gour> zbrown: i was dreaming several years to become 100% free. used win4lin, vmware, vbox...all bloatware
<abentley> zbrown: Do you know offhand how well Wine supports Adobe Premiere?
<zbrown> abentley: can't say I do know
<zbrown> abentley: reports seem to indicate its not that great though
<zbrown> gour: Eh I hardly find vmware to be bloatware
<zbrown> gour: at least on my laptopt, its very responsive, not quite "real system" but its still better than most
<abentley> zbrown: Too bad.  I have a friend who wants to use Ubuntu, but must use Premiere.
<zbrown> abentley: its getting there, its just not all the way there yet
<zbrown> hard to hit a moving target like Microsoft :)
<gour> zbrown: bloatware in the sense that i required the whole OS to run single apps for which there is no native-linux replacement
<abentley> zbrown: But most applications are backwards-compatible with XP or 2000, no?
<Toksyuryel`> microsoft is a moving target? if anything they're moving backwards and making things constantly easier for us
<zbrown> Toksyuryel`: not when you're trying to emulate (sometimes broken) behaviors of the OS that applications depend on
<zbrown> abentley: What are you particularly referring to? As of right now, emulation in wine is targeted for NT 5 series
<zbrown> so 2000, XP and 2003 are the main goals
<zbrown> granted XP is the focus
<abentley> zbrown: So those targets haven't moved for 5 years.
<zbrown> abentley: API's change with service packs and security releases ;)
<zbrown> abentley: not to mention the api is just way huge
<Toksyuryel`> zbrown: oh, I get what you're saying now
<abentley> zbrown: That I can certainly agree with.
<zbrown> Its only hard because there's maybe 20-30 regular contributors, probably <20
<zbrown> and MS has thousands of people changing things on us ;)
<ericvw> Odd question, it doesn't make sense to have a repo with checkouts within it does it on a local development environment?
<ericvw> I understand the using shared storage for 2+ branches in a shared-repo in a development environment.
<jelmer> abentley, speaking of which..
<jelmer> abentley, What's the latest status in your discussion with Robert about rich-root-pack as default?
<abentley> jelmer: We haven't talked about it in months.
<jelmer> oh, ok. I thought I saw something about it recently
<jelmer> awilkins, ping
<ericvw> Did anyone happen to answer my question when I left temporarily?
<vila> jelmer: ping, did you see my mail about 'Re: transport implementation test scenarios and rabbit-holing' ?
<vila> jelmer: there are two questions for you (search for jelmer in the body :)
<jelmer> I only see the email from mwh
<LarstiQ> jmm, ericvw quit just a bit too early
<vila> jelmer: strange, I replied and added you in CC your email @samba.org is still valid ?
<LarstiQ> jelmer: maybe it's not in the bzr folder
<jelmer> vila, LarstiQ: nope
<ericvw> What is the primary difference between checkouts and branches?
<vila> jelmer: here is a digest just for you http://paste.ubuntu.com/43429/  :D
<jelmer> vila, which python-kerberos did you install?
<jelmer> you'll need at least 1.0+svn2455-1
<jelmer> vila, you have a kerberos environment?
<jjesse> good afternoon, i'm working on setting up a bzr branch of a subversion checkout, how do i go about ignoring all the .svn directories under the different folders?
<jjesse> i think i need to edit a .bzrignore file but not quite sure i need to do
<jam> jjesse: "bzr ignore .svn" should be sufficient
<Spaz> yeah
<jjesse> jam thanks
<ericvw> when doing a checkout, does the .bzr have the same characteristics as branch since i can bind/unbind?
<ericvw> In the 1.1 project/trunk layout design, are those 'container' directories branches or just folders?
<jelmer> vila, hi
<jelmer> vila, ?
<jam> just a reminder to beuno, jelmer, vila, et al. Today is bug day
<jam> please triage, fix, and otherwise do interesting stuff to the bug tracker
<jam> (I know Jelmer did work last weekend, but *today* is the official bug day)
<beuno> jam, cool!  bug day finally happened!  I like you as release manager  :)
<jam> oddly enough, I'll actually have released 3 versions in a row
<jam> I released 1.5
<jam> and then accidentally inherited 1.6
<jam> and now I'll be doing 1.7
<jam> :)
<beuno> jam, and doing a great job at it, really
<jam> I'll say I'm more comfortable with it now that I've done 7-ish actual releases :)
<jam> Peng: so if you count 1.6.1rc2 + 1.6rc5 you could claim rc7 :)
<LarstiQ> oh there is a bug day?
<LarstiQ> gah, why does ericvw keep disappearing!
<theuiguy> I'm doing some code cleanup in a source tree and I'm trying to understand the subtleties of bzr rm versus just rm.
<theuiguy> I want the code to still be available using bzr log / bzr diff / etc.
<theuiguy> Is there a difference between the two: bzr rm vs. rm?
<theuiguy> bzr status shows files as removed using either command.
<LarstiQ> theuiguy: you could bzr rm --keep and still have the actual file, but removed from a version control point of view.
<LarstiQ> theuiguy: bzr rm is explicit, just rm is implicit.
<theuiguy> LarstiQ: I think I want the opposite -- I want the file removed from my tree, but still have it in version control if I ever need to go back to it.
<LarstiQ> theuiguy: well, you still need to commit.
<theuiguy> It seems like just rm is what I should use.
<LarstiQ> theuiguy: with any (rm, bzr rm, bzr rm --keep), after you commit that file won't show up anymore, but still be present in historical revisions.
<theuiguy> LarstiQ: Are you sure? That's not what I'm seeing at the moment, admittedly before I commit
<theuiguy> If I do rm, I can still do bzr log FILENAME and see FILENAME's history
<LarstiQ> theuiguy: I'm very sure, but I could be more precise about "won't show up"
<theuiguy> but with bzr rm, it doesn't show the history anymore
<theuiguy> LarstiQ: Please do be more precise... I want to understand this
<LarstiQ> theuiguy: right, so the difference between bzr rm and rm *before commit* is that because the plain rm is implicit, the file will only not be in the inventory after you committed. Whilst bzr rm has a bit more info and can already do that.
<LarstiQ> theuiguy: they'll be exactly the same after you commit.
<Snaury__> jelmer: see my patch in https://bugs.launchpad.net/bzr-svn/+bug/263570
<ubottu> Launchpad bug 263570 in bzr-svn "bzr-svn cannot be compiled for Subversion 1.5.* without hand-editing setup.py" [Undecided,New]
<LarstiQ> theuiguy: all revisions henceforward will not have that file in their inventory. It might still be in your tree if you did bzr rm --keep, but status will say it is an unkown file.
<LarstiQ> theuiguy: if you do a fresh checkout, or remove the file and then revert to a revision, the file will not be recreated.
<theuiguy> LarstiQ: So after commit, how would I be able to look at the history of the file? I'd have to revert?
<LarstiQ> theuiguy: however, if you revert to a revision before it was removed, the file _will_ be created in your working tree.
<LarstiQ> theuiguy: hmm, it seems there might be a regression there.
<LarstiQ> theuiguy: you should be able to provide a file path that doesn't match the current state, but a historical one.
<LarstiQ> theuiguy: you could always revert, yes
<theuiguy> LarstiQ: It's probably just our older version of bzr
<LarstiQ> theuiguy: or say, use bzr cat -r rev to see how that file looked in a certain revision.
<LarstiQ> theuiguy: what part of the history of that file are you interested in seeing?
<theuiguy> LarstiQ: Well, I'm doing some code cleanup in our tree... files that I don't think we'll ever need again
<theuiguy> but I want to be sure I can get back to them if we ever need them
<theuiguy> bzr rm scared me because the behavior before commit makes it look like the files are completely gone.
<theuiguy> including all knowledge of what went on in prior revisions
<LarstiQ> theuiguy: I can see that, but I can reassure you that is not the case.
<LarstiQ> theuiguy: so I think that is a ui bug that needs to fixed to be less scary.
<theuiguy> Is it a recent addition that you should be able to provide a historic path to see history?
<theuiguy> as in bzr log -r OLDFILE
<theuiguy> with some revision information of course
<theuiguy> Or does that not currently work?
<LarstiQ> theuiguy: it doesn't do that on my recent copies. So either it used to be possible, or I misremeber wrong.
<LarstiQ> theuiguy: but it works for cat
<LarstiQ> theuiguy: I think I was confused with cat.
<theuiguy> hmm... so it does work for cat?
<LarstiQ> theuiguy: but I still think it might be a nice feature. Although I acknowledge it can be tricky to infer what the user means.
<LarstiQ> theuiguy: yes
<LarstiQ> theuiguy: bzr cat -r <rev with file> path/to/file
<LarstiQ> theuiguy: should work even with path/to/file not existing in the current revision.
<theuiguy> ah... it'd be nice if log could do something like it ending with "deleted in revsion X"
<LarstiQ> theuiguy: well, removed is relatively simple
<LarstiQ> theuiguy: but consider files that are moved around.
<LarstiQ> theuiguy: especially if you swap files a and b
<LarstiQ> theuiguy: what does 'bzr log -r rev a' mean?
<theuiguy> LarstiQ: So let me see if I understand: bzr rm or rm both say remove this file as soon as I commit this and don't track it any more
<theuiguy> but ...
<LarstiQ> theuiguy: give me the information for the file that is currently at path a, or the one that was at a in that revision?
<theuiguy> they are still in revision history for previous versions
<LarstiQ> theuiguy: exactly.
<LarstiQ> theuiguy: bzr very rarely destroys history
<theuiguy> LarstiQ: that's very reassuring. Thanks!
<LarstiQ> theuiguy: and if it does, always on explicit user request (bzr rebase for instance)
<theuiguy> LarstiQ: It doesn't seem like bzr handles the simple case where there's nothing there in the current revision
<theuiguy> Is rebase built in now? Or still a plugin?
<LarstiQ> theuiguy: you mean, bzr log foo when foo isn't present?
<LarstiQ> theuiguy: plugin
<theuiguy> LarstiQ: yes
<LarstiQ> theuiguy: right, it's relatively straightforward in the case where there only ever was one file with that name.
<LarstiQ> theuiguy: in the other case, maybe log should be more interactive, and present you with a list of different files that had that name, and ask which one you want.
<theuiguy> It could be helpful to know
<theuiguy> especially if there are file renames in there
<theuiguy> Or perhaps just show renames in and out of that filename...
<theuiguy> with the log only showing what was there at various revisions
<LarstiQ> renames would be the common case of that problem, it's also possible to just do serial adds and removes.
<theuiguy> LarstiQ: So the difference in behavior before commit between bzr rm and rm is accidental, right?
<LarstiQ> theuiguy: I don't know for sure, but the difference sounds logical to me. It's not of much significance though.
<chadmiller> Hi all.  On the server where my canonical trees are, I wish to have some code that marks bugs as updated when branches are pushed-to with revisions that mention those bugs.  My current idea involves cron, but I'm having trouble.
<LarstiQ> chadmiller: you're not using --fixes?
<chadmiller> It looks (I think) like merges can rearrange my trees so that merely keeping track of the last-seen revision-id and constucting a list from that to the end is not sufficient to know what to update.
<chadmiller> LarstiQ: No.  I perhaps could, but I don't think that solves my problem.
<LarstiQ> chadmiller: it doesn't, but makes the detecting of fixed bugs less iffy.
<LarstiQ> so, on to the actual problem.
<chadmiller> I don't have a problem with that.
<LarstiQ> chadmiller: you'll probably want to know if the last seen revision-id is in the ancestry of the tip, instead of in the revision-history of the branch.
<chadmiller> We're really good about the format.  [Bb]ug\s*#\s*\d+
<LarstiQ> chadmiller: and no one mentions them unless they're actually fixed?
<LarstiQ> chadmiller: are you averse to using bzrlib for this?
<chadmiller> LarstiQ: (yes.  The format is no problem.)
<chadmiller> LarstiQ: I'm not averse, but I am daunted.
<LarstiQ> chadmiller: I'm not sure how I'd do it otherwise. But I could be warped by knowing bzrlib ;)
<chadmiller> LarstiQ: So, to be clear.  When cron fires off some program every minute, I only need an updated tree and a revision id of the last-seen revision-id?
<LarstiQ> chadmiller: yes, I think that would be enough information to figure out the rest from.
<chadmiller> I don't need the structure of the last tree, or a list of previous revisions ever seen?
<chadmiller> Hmm, okay.
<LarstiQ> chadmiller: well.
<LarstiQ> chadmiller: unless people uncommit or push --overwrite.
<LarstiQ> chadmiller: but if they use merge, that would be ok.
<chadmiller> Eh, hm.  We can trust that no one will commit, push, uncommit, push.
<LarstiQ> good :)
<chadmiller> Or use --overwrite.
<vila> jelmer: sorry, I was away afk far longer than I thought, I just have 1.0-1 (hardy) so I think you answered my question
<LarstiQ> chadmiller: sorry, I've been dragged to do other things.
<chadmiller> LarstiQ: It's okay.  I'm still wrapping my head around the problem.  Of the solution, you suggest a new program that imports bzrlib.  It takes a parameter, the revision id, and inspects a branch.  It somehow (!?) emits the log messages of all revisions that were not present before the time when the given revision id was at the tip.  Right?
<LarstiQ> chadmiller: yes
<chadmiller> Wow.  I have to come up with a test case first.  Then I'll start on the Hard Party.
<chadmiller> Wow.  I have to come up with a test case first.  Then I'll start on the Hard Part.
<LarstiQ> chadmiller: it may not be enough, but you could try something like
<LarstiQ> chadmiller: well, basically bzrlib.log.show_changed_revisions as seen in cmd_pull
 * chadmiller looks.
<hgr3> I am having problems applying a patch with "bzr patch", I just keep getting bzr: ERROR: Error invoking patch: No such file or directory. What am I doing wrong? (I am on windows)
<Odd_Bloke> hgr3: How are you invoking it?
<hgr3> Odd_Bloke: bzr patch mypatch.patch
<LarstiQ> chadmiller: another builtin to look at is cmd_missing
<hgr3> Odd_Bloke: I have never done this before, is it something I am missing?
<LarstiQ> chadmiller: specifically bzrlib.missing.{iter_log_revisions,find_unmerged}
<hgr3> If I use bzr diff myfile.c > mypatch.patch, should I not be able to do bzr patch mypatch.patch in the same go? But if I try, I get Error, No such file or dir
<jam> hgr3: to run "bzr patch" you have to have the patch executable (from diffutils, etc) I don't think it is available on windows
<jam> well, it *is* available
<jam> just not by default
<jam> I could be wrong on that, though.
<hgr3> jam: ahh... I see :) where can I read more about this?
<jam> hgr3: 'bzr patch' is provided by bzrtools, which brings in other dependencies
<jam> I don't know for sure why it doesn't use some of the internal mechanics.
<chadmiller> LarstiQ:  bzrlib.missing.find_unmerged takes two branches as parameters.  I only have the one branch (unless I change my program to keep another branch to compare against; ugh).
<jam> hgr3: if you want something you can apply easily, I would suggest looking at "bzr send" though that doesn't do per-file.
<jam> chadmiller: 'bzrlib.missing._find_unmerged' is probably what you would really care about.
<jam> But regardless, those are both focused on mainline stuff
<hgr3> jam: I have a patch I desperately would like to apply to a file, but I don't find out how to do it... what do you suggest?
<jam> what you probably want is
<jam> b = branch.Branch.open('mybranch')
<jam> g = b.repository.get_graph()
<zbrown> hgr3: patch -p0 ?
<LarstiQ> hgr3: another problem might be relative paths in the branch.
<jam> g.find_unique_ancestors(b.last_revision(), [old_last_revision])
<jam> chadmiller: ^^
<LarstiQ> hgr3: what are the values of `pwd` and `bzr root` ?
<chadmiller> Ooo.
<LarstiQ> chadmiller: and jam saves the day again :)
<jam> hgr3: http://gnuwin32.sourceforge.net/packages/patch.htm
<jam> zbrown: He's on windows and doesn't have patch installed yet
<LarstiQ> jam: I knew there was a graph function like that, but I didn't find it yet :/
<jam> chadmiller: you probably want some "lock_read()" in there, too
<zbrown> jam: oooh ok, my mistae
<LarstiQ> jam: oh, but _find_unmerged does that
<jam> LarstiQ: yeah. _find_unmerged is where the real work is done
<hgr3> thank you!
<LarstiQ> hgr3: installing patch helped?
<jam> he probably needs to put it somewhere on his path, etc
<jam> but as he wants to apply a diff, patch is the go-to command :)
<LarstiQ> right :)
 * LarstiQ just would like confirmation it is not #30159
 * mwhudson wants bzr push --no-tree
<LarstiQ> mwhudson: for locla fs pushes?
<mwhudson> LarstiQ: yes
<LarstiQ> mwhudson: makes sense.
<jam> bug #30159
<ubottu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] https://launchpad.net/bugs/30159
<jam> LarstiQ: for what hgr3 needed, that was certainly the case. "bzr patch" uses bzrtools, which uses the patch executable
<jam> which is a bit of a shame, because we *do* have native ability to parse patch files
<jam> (bzrlib.patches)
<LarstiQ> jam: right, but if he didn't have patch, we wouldn't even get to 30159
<poolie> hello all
<jelmer> 'morning poolie
<igc> morning
<mwhudson> hi igc, poolie
<spiv> Good morning.
#bzr 2008-09-05
<jam> morning poolie
<poolie> hi spiv, feeling better?
<spiv> Yeah, I am.
<spiv> Sleeping lots seems to have helped.
<lifeless> hi igc
<igc> hi lifeless
<lifeless> igc: when you're up to it, we should talk about tree rules stuff
<lifeless> where talk is irc|email|voice
<rudylattae> spiv feeling better now?
<spiv> rudylattae: yeah, hopefully it lasts.
<rudylattae> spiv: good going
<igc> lifeless: that would be great. Monday morning/lunch on IRC and/or phone suits me best
<lifeless> ok, cool
<lifeless> jelmer: http://goran.krampe.se/blog/Squeak/BzrOnDebian.rdoc
<lifeless> jelmer: there is a issue with normalisation in there, from bzr-svn
<lifeless> jelmer: do you think its a bzr bug or bzr-svn bug?
<jelmer> lifeless, this is a blog post from december last year
<lifeless> yes
<jelmer> lifeless, My memory of what bugs I've fixed doesn't go back that far :-)
<lifeless> I don't think its necessarily fixed
 * jelmer tries
<jelmer> lifeless, we did fix some normalization-related issues a while ago
<poolie> lifeless: were you still planning to come over this arvo?
<lifeless> poolie: yah
<lifeless> poolie: I forgot about that, one minute
<lifeless> did spiv confirm dinner ?
<poolie> not yet
<poolie> depends how he's feeling today i guess
<alsuren> is there some way to make bzr automatically recognise when I've moved files around and done nothing else to them?
<lifeless> http://michael.ellerman.id.au/bzr/plugins/auto-rename
<lifeless> poolie: so its a bit of a miserable day outside
<lifeless> spiv: ping
<poolie> yes i'd just been noticing that :)
<jelmer> lifeless, just confirmed, that repo checks out fine here
<jelmer> well, *seems* to be
<lifeless> jelmer: cool
 * alsuren wonders whether there is a plugin installer plugin, or whether that would be a bit too meta :P
<poolie> alsuren: there should be :)
<poolie> there is a bit of a start towards it with the missing-plugin stuff
<poolie> lifeless, we can take a rain check (cheque?)
<lifeless> poolie: sure thing
<poolie> i would like to talk to you on the phone if not in person sometime
<lifeless> perhaps a rain CHK
<poolie> but preferably not til later to preserve my concentration
<poolie> such as it is
<alsuren> bzr branch http://michael.ellerman.id.au/bzr/plugins/auto-rename/ hangs for me
<alsuren> *goes to bed, and thinks about it tomorrow*
<poolie> alsuren, it may just be a slow-over-http format
<lifeless> alsuren: its an old format branch
<lifeless> poolie: sorry if I'm bad for concentration :P
<lifeless> poolie: later is fine
<abentley> jam: back now.
<lifeless> lol? http://linux.softpedia.com/get/Programming/Version-Control/bzr-search-40745.shtml
<mwhudson> lifeless: boggle
<bob2> hopefully they can certify it as virus free soon
<markh> lifeless: bug 264679 is suggesting that info about 'bzr help configuration' be listed in the output of 'bzr help'
<ubottu> Launchpad bug 264679 in bzr "expose configuration help in cli" [Undecided,New] https://launchpad.net/bugs/264679
<lifeless> god no
<markh> if it didn't have info about branch config etc it would make more sense.  'bzr help user-config' or similar...
<lifeless> markh: why?
<markh> to give a new user that they might want to run 'whoami', for example
<markh> well - a clue to follow to find that out ;)
<lifeless> uhm
<lifeless> I don't think this makes sense; users may not run help at all
<lifeless> they may assume they know how to use it
<markh> heh
<markh> so who is it for? ;)
<lifeless> or they might be on a new machine
<lifeless> 'bzr help' is not 'I am a new bzr user'
<markh> so you are against putting potentially useful information in "bzr help" because users may not run help?
<lifeless> no
<markh> someone who is not a new user to bzr doesn't need much of the info on the 'bzr help' screen at all
<markh> they already know 'bzr help commands'
<lifeless> I'm against making 'bzr help' which is already too long, longer, without actually solving the asserted root problem
<lifeless> a windows user won't run 'bzr help
<markh> of course they will!
<lifeless> someone following a guide someone else wrote probably won't run 'bzr help'
<markh> I do, and ofcourse its one of the first bzr commands I ever typed!
<lifeless> no they won't, they'll right click somewhere and start with the first popup screen
<markh> that is a gross generalization ;)
<markh> "linux users will never use the mouse" ;)
<lifeless> likewise an eclipse user
<poolie> are you saying the core change is that 'bzr help' top level output should point to 'help configuration' or is it something else?
<markh> but - I'm not avdocating for that - just trying to understand your reasoning
<poolie> markh, the mouse is used to choose the xterm to type in ;-)
<markh> that was the assertion a user made, and lifeless said he didn't understand the proposal.  I was just trying to help clarify it for lifeless.
<lifeless> markh: if the problem is that 'you have to run bzr whoami to be able to use bzr sensibly', then we should put effort into fixing that
<markh> I see it potentially has merit
<markh> and I assert a new user of bzr *will* type 'bzr help' very early on
<markh> but I really don't care ;)
<lifeless> well, I'm not against a pointer to the config in the top level help
<lifeless> I am against embedding al the content there
<markh> why?  Surely that's for the new user too?
<lifeless> markh: why not delete the top level help and point to the tutorial?
<markh> because IMO 'bzr help' is useful to the new user, and should be targetted at the new user.
<markh> ISTM you are the one saying otherwise?
<markh> I think bzr help is very good atm for exactly those reasons
<lifeless> from experience, people get scared off a first help screen that is more than ~ 1 page
<lifeless> the config documentation is many many pages
<markh> I think a single line 'bzr help config -  show info about how to customize bzr for your preferences" *might* be beneficial for new users
<lifeless> sure, I have no objection to that
<lifeless> we should remove 'bzr check' too
<markh> that is the proposal!!
<lifeless> markh: I though it was to copy the contents of bzr help configuration -> bzr help
<markh> god no ;)
<lifeless> markh: which is what I said
<markh> so, I hope I've help clarify the proposal in that bug you commented on ;)
<lifeless> abentley: we must be talking past each other or something, on the bug discussing rev specs
<markh> the 'whoami' question is interesting in its own right.  The default value will rarely be exactly what the user would choose to type for that value.  So the argument could be made that you *do* need to run whoami to have it work sensibly.  the first few bzr checkins I made had 'inappropriate' values for the user (certainly 'skip@eden
<markh> ') isn't that useful
<markh> poolie: how was the trip?  Your bum recovered?
<poolie> it was great thanks
 * markh hopes people don't take that the wrong way ;)
<poolie> heh
<markh> bike went well?
<poolie> actually it was more my neck that got sore from crosswinds
<lifeless> markh: better that poolie doesn't take it the wrong way either :P
<markh> :)
<poolie> markh, the front shock and forks started leaking after a day of fairly rough roads
<poolie> not catastrophically, and they'll be replaced soon under warranty
<markh> bugger - they lasted ok though?
<poolie> yes
<poolie> it was a bit disturbing to see oil all over the front of the bike
<poolie> but fine
<poolie> the mechanic said "if i'd been punished like that all day i'd be weeping too" :-)
<markh> yeah, I bet!  Did you notice the suspension suffer?
<markh> heh :)
<markh> I'd guess you'd lose dampening?
<poolie> no, i just put a bit more preload on to (possibly) make it easier on it
<poolie> i guess i would eventually but it probably has not lost enough oil to make a difference
<poolie> i actually got much more relaxed on that ride about rough surfaces, dirt, big trucks, wind, etc
<markh> yeah, I shit myself on dirt still :)
<poolie> http://flickr.com/photos/mbp_/2824615378/
<lifeless> markh: so, bzr design principles - we try to make mistakes easy to recover from; having to read more to be insulated from mistakes strongly suggests to me that we have a too-hard-to-recover-from situation
<markh> it would help if I had a bike designed to go off the tarmac though :)
<lifeless> markh: and I'm *much* more interested in fixing that that
<poolie> i saw two roos go across the road in front of me
<poolie> not close enough to be a problem but it does make you think
<markh> lifeless: I think we are agreeing in general.  However, I do see value in assuming a new user is likely to run 'bzr help' early on, and best I can tell, the existing help on that page is targetted at a new user.   further, pointing such a new user at config options early on may have value too.
<markh> poolie: how close?
<poolie> the first one, i braked at about 70% effort and had plenty of room
<poolie> the second i just backed off and watched him go
<markh> ack - I bet the first one worried you briefly!  You have abs though?
<lifeless> markh: well, like I said, I'm not against tweaking 'bzr help'. It doesn't enthuse me though - the shed is blue, mmk? (compared to reducing the curve by making mistakes more recoverable).
<poolie> i do
<poolie> i've never had it activate except when practicing braking
<poolie> which is probably good
<poolie> nice to know it's there
<poolie> so some people on the trip washed their bikes every night, then put covers over them
<poolie> each to their own but i found that kinda creepy :-)
<markh> heh - the ducati trips are very much like that ;)
<poolie> i bet
<markh> quite amazing
<markh> I admit I wiped the bugs from the front most nights though ;)
<markh> but left a streaky mess in its place :)
<poolie> i did wash the screen, lights, etc
<poolie> the rest of it looks better with some dirt
<lifeless> back soon
<markh> your enjoyment suffers when you are too anal about things like that
<poolie> so, about half our trip overall was just up and down the bruce hwy
<poolie> there is a lot of sugar cane
<poolie> there were some pretty amazing roads in between
<markh> I bet
<markh> poolie: back to those tests - how should we proceed on silencing the lock contention test failures?
<poolie> you're talking about the outright failures rather than xfail i presume
<markh> yeah
<markh> it seems xfail already catches some of those errors
<markh> we just try and arrange for xfail for all of them?
<poolie> so that would be the laziest way to do it
<poolie> at least then we'd detect if anything new breaks
<poolie> i think it would be worth trying to work out why they are failing
<poolie> for instance
<poolie> - is it just a bug in the test that eg it has two objects pointing at the same file
<poolie> in which case ideally we'd fix the test
<poolie> - or is it something that is kind of broken by design on windows
<poolie> - or is it something that we could fix but that'll be nontrivial
<poolie> that kind of thing
<poolie> i suspect there are some in the first category and it would be nearly as easy to fix them as to block out the tests
<markh> There are a couple of cases where we try and take a readlock and a writelock on the same directory
<markh> I'll try and find the thread - give me a few...
<markh> It was in IRC.  "[09:05] <markh> I'm tracking down LockContention on Windows and I don't understand how it is supposed to work.  I've instrumented 'do_merge' and can prove that in some cases, self.this_tree._dirstate._filename == self.base_tree._dirstate._filename"
<markh> so - many of the test failures stem from that.  It should be quite easy to instrument any platform to check for that condition
<poolie> ok, i recall that from before i left
<markh> on Linux, you *can* lock like that, on Windows you can not
<poolie> so i'd want to know - are the dirstate objects the same? if so, are the tree objects the same?
<markh> apparently yes
<markh> lifeless says there are a number of valid use cases for that
<poolie> hm
<lifeless> bzr merge . for instance
<lifeless> which is why I proposed a relatively trivial tweak to dirstate that avoids this
<lifeless> but it seems to be stalled
<lifeless> and it won't fix WT4 regardless
<poolie> so i want to avoid having "xfail os locks are not process-wide" when that is only the proximate cause
<markh> how about a "Feature"?
<markh> I'm not sure how these solutions would impact the output of the test run though
<fullermd> Hm.  There are some minor long-standing test failures on my system...
<markh> IIUC that would make them a "skip" or something though...
<lifeless> markh: skip isn't appropriate for something that can't be fixed
<fullermd> But I got a stack of others while trying to reproduce them.  Figures.
<markh> Features seems like the easiest implementation though ;)
<poolie> so
<poolie> if the object is already locked, why are we trying to lock the same file through a different file handle?
<markh> I think the answer is "because we can" :)
<poolie> it wasn't about feature vs xfail, rather that if we're going to say "it's not really a failure" i'd like to be clear about what is causing it
<markh> an option I proposed was simply to detect we already have a write lock and don't bother with the read lock.  lifeless suggested that wasn't really an appropriate fix and he had ideas for the correct fix
<lifeless> markh: I mailed my proposal to the list
<lifeless> markh: its not a good fix because its very incomplete
<markh> lifeless: understood, but there is a dependency issue
<poolie> lifeless, you're talking about the proposal to rename the file?
<poolie> i guess i just don't see why this would need any on-disk changes
<poolie> why can 'bzr merge .' not work with our current format?
<markh> do we want to wait for that fix before we try and make tests give reasonable output?  There is only one of you ;) , so doing something in the meantime makes some sense
<lifeless> markh: theres no need for me to do the deeper fix; and I haven't suggested waiting on addressing the tests issue
<markh> lifeless: understood - was just explaining myself :)
<lifeless> poolie: bzr merge . is something the test suite does; bzr diff while a bzr commit window is open is a more common occurence of the same defect
<poolie> they're different because in the first case there is only one process in play
<poolie> the second is a known bug, sure
<poolie> the first one seems to me to be accidentally failing
<markh> poolie: when you say "accidentally failing", you mean "bzr is accidentally taking more lock than it needs" or "test suite is in error"?
<poolie> it could be either
<markh> a one line hack to do_merge will reproduce the problems for you
<poolie> i mean 'accidentally' because the design limit that affects the second case should not be causing this to fail afaics
<markh> just fail whenever the 2 paths are the same and run the test suite
<lifeless> bug 114528
<ubottu> Launchpad bug 114528 in bzr "dirstate locks don't work on Apple AFP network mounts" [Medium,Confirmed] https://launchpad.net/bugs/114528
<lifeless> another example o f the same thing
<poolie> lifeless: to me it looks like that's just saying that file locks don't work at all in some environments
<lifeless> poolie: yes, and the ongoing problems with dirstate are due to that
<markh> poolie: the test related patch in the queue I referred to is at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C019a01c8fe73%2427a26f30%2476e74d90%24%40com.au%3E - John has already voted 'approve'
 * markh didn't think the patch was *that* scary...
<poolie_> i'll look
<mwhudson> who would be the person to ask about bzr's sftp transport?
<poolie_> anyone really
<mwhudson> in particular, is there any likelyhood it sends the "realpath" sftp command?
<lifeless> spiv, poolie, I, jam, vila, have all had sustantial interactions with it
<lifeless> unlikely I think
<mwhudson> that's what i thought too
<lifeless> which is why your server is bust :P
<mwhudson> yeah
<mwhudson> well
<mwhudson> it's why our server can be bust and still host bazaar branches without exploding
<mwhudson> (realpath returns url-encoded paths atm)
<poolie_> markh, it looks fine to me, i'll merge it
<markh> poolie_: thanks!
<lifeless> poolie_: call time ?
<poolie_>  woo, passing
<poolie_> what a great time for a call :)
<vila> goood morning bazaar
<gour> morning vila
<vila> mwhudson: I highly doubt we use the realpath command in our sftp client, paramiko may though
<spiv> poolie_, lifeless: I don't think I'll be doing dinner with you guys tonight, I'm still not quite 100%.
<poolie_> spiv, sure, we're not either
<spiv> poolie_: great ;)
<poolie_> spiv, can you look quickly at my partial patch on bug 261315
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315
 * spiv looks
<spiv> It looks like I have a fix for the ObjectNotLocked bug that affects 'bzr cat bzr://...' etc, just waiting for tests to pass.
<spiv> It *might* let me delete some cruft, too.
<spiv> poolie_: that looks ok to me
<poolie_> thanks
<poolie_> it'd be nice to eliminate these things of having two objects representing the same thing
<spiv> poolie_: the obvious way to avoid that forcing _ensure_real on every branch open would be by having a new Branch.open RPC that returns the stacked_on URL, I guess.
<poolie_> Branch does seem like a good place to start in removing real objects
<spiv> Yeah, keeping two different objects representing the same entity in sync is the source of lots of hpss bugs.
<spiv> Including the ObjectNotLocked one.
<poolie_> i might try that soon
<poolie_> maybe not tonight
<poolie_> i should finish off LockableFiles too...
<poolie_> i was also looking at the locking gc warning thing
<poolie_> it seems to me that every case we currently warn is in a test for lock-breaking or similar
<poolie_> where we really are meaning to have the lock object leak
<poolie_> so i guess we could explicitly mark them as abandoned or something, and then suppress the lock leak
<poolie_> but it seems like diminishing returns
<spiv> Ooh, it looks like I *can* finally delete some cruft from RemoteBranch.lock_write
<spiv> I think I just figured out part of the confusion that had stopped me doing that earlier: it was possible for the code to overwrite the _real_repository object sometimes.  Debugging hilarity ensues.
 * spiv goes on a XXX-deletion spree
<spiv> Among other things, RemoteBranch.lock_write doesn't force _ensure_real any more :)
<spiv> jam: RemoteBranch.lock_read fix sent to list
<spiv> jam: it includes some bonus extra sanity on top of just fixing the immediate bug :)
 * spiv wanders afk
<cjwatson> I'm trying to use bzr import-dsc on the history of a non-native Debian package, and running into some trouble: namely, it works if I just run it in an ordinary branch, but not if I create a repository first. What would you need in order to debug this?
<cjwatson> oh, I forgot James was on holiday, ok
<Odd_Bloke> cjwatson: I'd suggest pasting the appropriate part of your .bzr.log somewhere.
<cjwatson> http://paste.ubuntu.com/43603/
<Odd_Bloke> cjwatson: Hmm, yeah, that's something I can't really help with.
<Odd_Bloke> Doing it in a branch and then branching into your repository should work around it though.
<cjwatson> right, that's what I did
<cjwatson> it's perfectly reproducible, so I'll grab James about it when he gets back
<Odd_Bloke> cjwatson: File a bug?
<cjwatson> yeah
<LeoNerd> So.....
<LeoNerd> 'find -name .bzr \( -prune -printf "%h\n" \)'   runs in about 0.5seconds and uses hardly any memory while doing so. Whereas, 'bzr branches' eats looooads of memory and spends a great deal longer time finding out the same information...
<LeoNerd> Oh and it chews a great amount of CPU too
<Peng_> 'branches' is that bad? Hmmm.
<LeoNerd> real    0m0.022s <= 'find | sed'. real    0m13.015s <= 'bzr branches'
<Peng_> Jeepers, you're right. It hit 112 MB of RAM by the time it was done.
<LeoNerd> Mhm :)
<Peng_> I'm running it on a VPS, so I think I just dumped the entire disk cache, but at least I didn't swap.
<LeoNerd> Perhaps I should post to the mailinglist?
<Peng_> Sure.
<Peng_> Oh, I just realized that my little script doesn't use "bzr branches" anyway.
<Peng_> It uses subprocess.Popen(['find']). Cough.
<LeoNerd> Hehe
<LeoNerd> Ya.. I use:
<LeoNerd> find -name '.bzr' \( -prune -printf "%P\n" \) | sed -e 's,/\.bzr$,,'
<Peng_> Heh. I just use 'find' to get a list of all directories and then loop through it.
<jakobb> to anyone: there used to be a bug regarding errors that occur when redirection takes place, does anyone remember the # by accident?
<awilkins> LeoNerd: Heh, I have a powershell script for the same reason
<LeoNerd> mmmm
<LeoNerd> Sounds like 'bzr branches' needs some work then
<awilkins> ls | where { $_.PSIsContainer } | ls -force -inc .bzr | where { ($_.Name -eq ".bzr") } | foreach { $_.Parent }
<awilkins> It doesn't recurse, but some of my trees are .. large, and I don't want to recurse them
<LeoNerd> That's what the -prune is for
<awilkins> I'm not very skilled with "find" as yet
<Peng_> Hmm, replacing my 'find' hack with os.walk was quite easy. Yay. :)
<Peng_> (I've never used os.walk before.)
<abentley> Peng_: There's a bug in the svn bindings that can cause ludicrous memory consumption, if you have bzr-svn.  But branches uses bzr transports, and they're not very efficient for this.
<Guest51940> abentley: What exactly is triggering that?
<Jc2k> hi jelmer/guest51940 :p
<abentley> Guest51940: I don't know.
<Guest51940> abentley, Just a regular pull/push with bzr-svn doesn't use more memory than usual these days
<abentley> Guest51940: That's with the new bindings?  I'm talking about the old ones.
<Guest51940> abentley, ah, ok
<abentley> And I'm talking specifically about the 'branches' command.
<abentley> Which uses BzrDir.find_branches.
<Peng_> abentley: I do have bzr-svn installed, but none of the branches in question use it in any way (though some are copies of svn imports).
<abentley> Peng_: Doesn't matter whether they use it.
<LeoNerd> I'm not using svn at all
<RAOF_> Ah.  You're talking about the 'bzr multi-pull consumes 1GB resident' funness?
<abentley> LeoNerd: Are you seeing ludicrous memory consumption?
<LeoNerd> Yup
<LeoNerd> In fact, if I run 'bzr branches' from my $HOME, it throws everything else out to swap, then OOM killer bites
<lamont> Format <RepositoryFormatKnit1> for file:///home/lamont/stuff/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<lamont> what check (short of a bzr command) can I use to see that this warning is going to come out, I wonder?
<abentley> LeoNerd: Please file a bug, then.  So far, every case of this has been solved by uninstalling bzr-svn.
<LeoNerd> Ahright :)
<abentley> lamont: I don't think there's anything you can do without running a bzr command.  The list of deprecated formats will be different depending on your bzr version.
<lamont> right.  specifically, 1.6 vs knit, or "is there a way to tell that I have a knit1 format by just checking a file or its contents?"
<abentley> lamont: you can "cat $PATH_TO_REPO/.bzr/repository/format"
<lamont> cool
<Peng_> Wait...my os.walk() code is completely broken.
<Peng_> Anyway, off-topic.
<Peng_> Weird...I seem to have poked one of my bzr branches over http.
<awilkins> ls
<awilkins> oops
<Pieter> . .. docs movies warez xxx
 * awilkins wonders if Pieter executes any other commands
<awilkins> rm -rf /dev/brain
<Pieter> rm: command not found
<mitchchapman> Using bzr 1.6 on Windows XP, I am suddenly getting this error on every operation: "bzr: ERROR: invalid header line: ''"  My dirstate file appears to be empty.
<mitchchapman> Does anyone know how to recover from this situation?
<abentley> mitchchapman: do you have any changed files?
<mitchchapman> Yes.
<abentley> Move all your files except .bzr into a temp directory
<abentley> delete .bzr/checkout and its contents.
<abentley> run "bzr checkout ."
<abentley> That should give you a tree in the state you last committed.
<abentley> Then copy your working tree files back in place.
<abentley> If you had added or moved any files, you'll have to do that again.
<mitchchapman> abentley: That did the trick, thank you very much!
<abentley> mitchchapman: You're welcome.
<chadmiller> Hi all.  In bzrlib, what's the best way to find if a revisionid exists in a branch?  All the ways I see in bzrlib.branch work only if the revision also has an integer revno.
<abentley> chadmiller: bzr log -r revid:$REVISION_ID
<abentley> If that shows the entry, it's in the branch.  If it raises an exception, it's not.
<chadmiller> abentley: Okay.  I'll reverse-engineer what "log" does.  Surely there's a smarter way.  Note my "In bzrlib," preposition.
<abentley> chadmiller: Oh, then "best" is highly variable.
<chadmiller> cheapest?  "if revid in some_hash:"...
 * chadmiller greps around for NoSuchRevision
<abentley> Cheapest would be branch.repository.get_graph.iter_ancestry([branch.last_revision])
<abentley> Or I guess branch.repository.get_graph().is_ancestor(candidate, branch.last_revision())
<abentley> However, *any* operation that can answer your question will scale badly if the answer is "no".
<abentley> So I would reconsider trying to do that.
<chadmiller> abentley: Well, I'm trying to use Graph.find_unique_ancestors(), which lists every rid if the exceptions list contains only an invalid rid.
<chadmiller> Arguably, it should raise an exception.  I can't wait, though.
<abentley> chadmiller: I think that anything that can answer your question will take at least as long as find_unique_ancestors if there is an invalid revision-id.
<abentley> The only way to know if a revision_id is present in a branch is to walk the ancestry of the last revision in the branch.
<abentley> until either you find it, or you reach the graph origin.
<chadmiller> Right.  I'm not worried about time for missing revid.  I must raise a warning though, in the case where someone gives me an invalid revisionid.
<abentley> Invalid revision ids are those that end with a single ':'
<chadmiller> I wouldn't mind taking the graph origin as an error.  I'll look at that.  I can test if the set Graph.find_unique_ancestors() contains the origin, I suppose.  Hrm.  Now, to get the origin....
<chadmiller> abentley: When I say it, I mean "invalid" to be "not present in the history at all"
<abentley> chadmiller: No, you mean "not present in the ancestry at all".  If it's present in the ancestry but not the history, it doesn't have an integer revno.  But you said you wanted to allow things without integer revnos.
<chadmiller> abentley: Thank you.  bzr internals argot is still new to me.
<jam>  abentley: well technically you can walk both ancestries, and if you find them converge
<jam> then you only need to search some of the ancestry
<jam> (things that are descendents of the common point)
<jam> I use that sort of logic in the lazy revno code I've been putting together
<jam> and it is also somewhat how "Graph.find_distance_to_null()" works.
<jam> chadmiller: the 'origin' is "NULL_REVISION"
<jam> but that is going to be common to all revisions
<jam> so won't show up in "find_unique_ancestors()"
<jam> Actually, I would be surprised if "find_unique" returns the complete set
<jam> unless the ancestries are completely separate
<jam> chadmiller: http://rafb.net/p/M1l6OR91.html
<jam> there is also "Graph.find_difference()"
<jam> which can give you the difference on each side
<jam> if one side is empty
<jam> then that revision is in the ancestry of the other.
<chadmiller> jam: Hrm.  "...the difference on each side"?  I have only a revisionid and one branch.  I don't see how find_difference() can help.
<jam> chadmiller: Branch.last_revision()
<jam> left_unique, right_unique = graph.find_difference(Branch.last_revision(), old_last_revision())
<jam> if len(right_unique) == 0:
<jam> then old_last_revision is in the ancestry of the current tip
<jam> because it has no unique ancestors
<jam> Otherwise left_unique == graph.find_unique_ancestors(Branch.last_revision(), [old_last_revision])
<jam> chadmiller: does that help?
<jam> find_difference() computes the symmetric difference
<jam> (what is in A that isn't in B, and what is in B that isn't in A)
<jam> find_unique only computes 1 side
<jam> (because in the general case it is cheaper to compute 1 side if you don't care about the other side)
<jam> vila: ping
<vila> jam: pong
<jam> vila: I notice you updated the status of a lot of bugs without updating their importance. Is there a reason?
<vila> not really, I don't think I update major ones though, just trying to clear the New queue
<vila> I generally affect an importance when I get enough understanding of the consequences to do so
<jam> So, IMO, if you are triaging it to confirm it, then it should have an importance rating.
<jam> Obviously Wontfix/invalid don't need them
<jam> And sometimes "incomplete" doesn't
<jam> that depends on if there is enough information to give a severity indication.
<jam> But certainly "Confirmed" sounds like we should know how important the bug is.
<vila> and when do you use triaged vs confirmed ?
<jam> vila: Triaged / Confirmed is ... unclear. I believe I understand how LP wants us to use them.
<jam> Specifically, Confirmed is for non-bzr devs
<jam> to say that "I saw this too"
<jam> (confirmed)
<jam> Triaged is for project devs
<jam> to say that there is enough info to give an importance rating.
<jam> and if someone wanted to work on it, they could
<jam> Martin always uses Confirmed
<jam> I've started using Triaged
<jam> and I don't think we've come up with official project policy.
<jam> But I will note
<jam> non project devs can set "incomplete" "invalid" and "confirmed"
<abentley> jam: Kiko is in favour of *never* using confirmed.
<jam> you have to be in the ~bzr group to set "Triaged"
<jam> abentley: hm... I haven't seen that. But I don't hang out on #launchpad. :)
<jam> Do I misunderstand the idea of the Malone definitions?
<abentley> jam: It was in the launchpad mailing list.
<chadmiller> Wow, jam, I step away to get food and you fill my screen!  :)
 * chadmiller reads.
<jam> well, a lot of it is not related to you :)
<abentley> jam: "Triaged" means "confirmed by Someone Important" to kiko
<jam> abentley: sure, which is why I would use Triaged for ~bzr users, and leave Confirmed to non ~bzr users.
<vila> abentley: that's how I was using confirmed (humbly though :)
<jam> vila: sorry, you're Someone Important
<jam> you gotta step up to that :)
 * vila tried...
<vila> :D
<jelmer> awilkins, ping
<jam> vila: do you have any experience with python's xmlrpclib?
<jam> I was just poking at bug 186920
<ubottu> Launchpad bug 186920 in launchpad-bazaar "bzr launchpad does not handle proxy when used for name resolution " [Undecided,New] https://launchpad.net/bugs/186920
<jam> And I linked: http://bugs.python.org/issue648658
<jam> chadmiller: ping me if you understand/don't understand what I mentioned
<chadmiller> jam, thanks.  I will.
<vila> jam: no
<vila> yeah, the main problem is that david has strange setup, I'm following this bug for ages but never find the time to work o nit :-/
<vila> s/has/has a/
<vila> jam: dinner time here, I may come back later... or not :)
<jam> david?
<jam> vila: eat well
<vila> jam: david cournapeau, the guy who reported the bug, that's not the first one, its DNS is proxied or something weird like that
<jam> vila: well, xmlrpclib doesn't do proxying either
<jam> which I thought was the same bug
<jam> regardless, I was asking about the xmlrpclib side of things :)
<jam> but still, don't let me interrupt food
<awilkins> jelmer: bzr-svn is getting my standard baptism of fire ; branching a 13880 revision trunk with over a GB of content
<awilkins> jelmer: We shall have to see how it manages.
<jam> vila, is bug 265070 just another 'redirection handling' bug?
<ubottu> Launchpad bug 265070 in bzr "PathNotChild: Path "http://url" is not a child of path "http://jakob@url": user name mismatch" [Undecided,Fix committed] https://launchpad.net/bugs/265070
<jelmer> awilkins, ah, cool
<awilkins> jelmer: One little thing ; the lib "dav" is "neon" in 1.5
<jelmer> awilkins, did you see bug 263570 ?
<ubottu> Launchpad bug 263570 in bzr-svn "bzr-svn cannot be compiled for Subversion 1.5.* without hand-editing setup.py" [Undecided,New] https://launchpad.net/bugs/263570
<awilkins> That's the "dav is now neon" thing
<awilkins> I hand-edited it and replaced "libsvn_ra_dav-1" with "libsvn_ra_neon-1"
<awilkins> awilkins: Then I went back and built it for 1.4.6 after you patched it
<jelmer> awilkins, any chance you can confirm this patch doesn't break anything for you?
<jelmer> I'd like to apply it for the next release, preferably without breaking anything :-)
<awilkins> jelmer: I'll run the test suite and post you the log now
<jelmer> I also fixed compatibility with svn 1.4 on windows, btw
<awilkins> jelmer: I'm not sure how necessary that is, but it's welcome
<awilkins> jelmer: The WC library is never used to touch a "real" SVN WC AFAIK, so the nasty "upgrade" doesn't happen
<awilkins> jelmer: Heh, the "hell branch" has just finished caching metadata
<awilkins> Fetching the highly nsaty first revision
<awilkins> This is a really good test corpus because the repo layout has really been screwed around with (or a bad one, depending on your viewpoint :-)  )
<jelmer> awilkins, if it's not performing well enough, you may want to try trunk
<awilkins> jelmer: It's not leaking loads of memory, so that's good (so far)
<awilkins> 6/9699 and rising
<awilkins> What does trunk do that 0.4 doesn't ?
<jelmer> it's more performance tuned
<awilkins> jelmer: 30 revisions and still not many positive memory delta above r 1 ; I'm optimistic
<jelmer> ah, great
<awilkins> jelmer: Impressive, it's rock steady - the odd blip for a big revision (eats 140MB plus and then dumnps it all)
<awilkins> Then right back down to 308,732KB
<jelmer> back in ~30 min
<awilkins> I'll switch to trunk and run the test suite again
<vila> jam: there is no redirection bug I'm aware of :-) The code has just bitrotten  from the days it was used  the first access which was always for the branch format. But now the hpss probing changed the context a bit and things are a bit blurry :)
<vila> I'm missed bug #245964 at the time, but I what is this Michael's change you're referring to ?
<ubottu> Launchpad bug 245964 in bzr "nosmart+http interacts badly with http redirects" [High,In progress] https://launchpad.net/bugs/245964
<vila> s/I'm/I've/ s/I what/what/
<jam> vila: your sed expression is harder to parse than the original :)
<vila> exactly my thought :)
<vila> see ? redirection is hard for brain :)
<jam> and yes, that is the patch I'm talking about
<jam> The specific bug(s) are than nosmart+... fails to remember "nosmart+" and it seems that "http://user@host" fails to remember the "user@" during the redirect.
<jam> "are that"
<jelmer> awilkins, thanks for the update
<jelmer> I've fixed TypeError: rcvr() takes exactly 4 arguments (3 given)
<jelmer> in the 0.4 branch
<awilkins> jelmer: Now at 4912/9699 and detecting some memeory ;leakage
<awilkins> back in a mo
<abentley> jelmer: Do you know what the the current status of gnome-to-bzr imports is?  Where it's happening, and who's doing it?
<jelmer> abentley, jc2k and thumper are the main people responsible afaik
<jelmer> abentley: it's on http://bzr-mirror.gnome.org/
<abentley> jelmer: Cool
<abentley> Thanks.
 * Jc2k looks in
<Jc2k> abentley: there are 2 independant mirrors, mine is on bzr-mirror.gnome.org (and also does a git and mercurial mirror). bzr-playground.g.o is looked after by canonical
<Jc2k> abentley: so maidenhead and.. i think london?? for where
<abentley> Jc2k: "where" meant URL :-)
<abentley> I'm confused.  I thought that Canonical was taking over from you.
<Jc2k> some how we ended up with 2 mirrors :)
<abentley> Jc2k: We should straighten this out.  I'll poke thumper next time I talk to him.
<Jc2k> abentley: im meant to be involved in playground somehow (thumper says im meant to have some kind of admin rights on the box)
<abentley> Jc2k: I ask because someone just wanted to get Launchpad to import http://svn.gnome.org/viewvc/seahorse/seahorse-plugins/trunk
<abentley> And I figure that would be counterproductive.
<abentley> Could you set such a mirror up?
<Jc2k> it will happen automatically on bzr-mirror
<Jc2k> if it hasnt already
<Snaury> hey jelmer, so what about my 1.4/1.5 patch? does it have any problems?
<Jc2k> hmm hasnt already
<jelmer> Snaury, Nope, it all looks fine to me now
<jelmer> Snaury, I was hoping awilkins can test it as well, after that I'll merge it
<Snaury> ah, ok.
<Snaury> I didn't realize Internet Explorer could screw patch filename like that. :-/
<Jc2k> oh
<eean> how do you checkout a tag?
<jelmer> Snaury, thanks for these patches, btw!
<Jc2k> abentley: so, i think its a bzr-svn 'bug'...
<Snaury> You're welcome. :)
<jelmer> eean, try "bzr branch -rtag:<name-of-tag> <url>"
<abentley> Jc2k: May I have your email address so that I can direct Andreas Moog to you?
<jelmer> Jc2k, ?
<Jc2k> abentley: there is no mirror of it because bzr-svn only handles trunk/branches/tags...
<Jc2k> jelmer: seahorse has trunk, branches, tags, seahorses-plugins
<jelmer> Jc2k, it will handle that by default - are you specifying a branching scheme explicitly perhaps?
<Jc2k> no...
<eean> jelmer: can I switch the current checkout?
<Jc2k> abentley: john.carr@unrouted.co.uk, and #gnome-bzr on irc.gnome.org :)
<jelmer> eean: "bzr pull . -rtag:<tag-name>"
<jelmer> Jc2k, strange
<eean> "No revisions to pull."
<jelmer> Jc2k, ah, it uses two branching schemes
<Jc2k> jelmer: yes
<jelmer> Jc2k: so you'll need two separate svn-import commands
<Jc2k> jelmer: i'd prefer to do surgery and make seahorse-plugins a seperate repository..
<Jc2k> jelmer: because i hate special casing the mirror
<jelmer> "bzr svn-import --scheme=trunk" and "bzr svn-import --trunk1 svn://svn.gnome.org/svn/seahorse/seahorse-plugins/"
<jelmer> s/--trunk1/--scheme=trunk1/
<Jc2k> :)
<jelmer> Jc2k, yeah, splitting it out may be a better idea
<Snaury> jelmer: btw, what bzr rebase does when I have merges in my diverged branch?
<jelmer> Snaury, in the branch you're rebasing you mean?
<Snaury> jelmer: yes. I might be wrong, but I think I might have lost some merges in the past by just doing bzr rebase. Poof and merge is gone, only direct commits were left. I'm not sure if I'm not mistaking though, I'll try reproducing it now.
<jelmer> it will skip merge revisions if the changes they merged were already merged upstream (unless --always-rebase-merges is specified)
<jelmer> if the revision was not merged in upstream, it will rebase the changes as it does with regular revisions and keep the information about the revisions that were merged
<jelmer> Snaury, does that help?
<eean> sheesh checking out a new tag takes like an 10 minutes
<eean> from locally
<jelmer> eean, that doesn't sound right, it should just be changing the tree
<jelmer> eean, did you specify the . ?
<beuno> eean, you need shared repos
<eean> I had to do bzr branch -rtag:mysql-5.1.26 mysql-server/ mysql-server-5.1
<eean> the bzr pull didn't work
<jelmer> eean, perhaps specify --force to bzr pull
<Snaury> jelmer: yes, so maybe I was just mistaken. :) I have pretty weird trees, maybe I applied the same change in both trees, or something else. Weird...
<eean> logically a pull command wouldn't work
<eean> its not what a pull is for :P
 * jelmer wished "bzr switch" would accept a -r argument
<eean> bzr checkout should accept a tag
<eean> that would make sense to me
<jelmer> eean, I agree
<eean> your not really switching branches if you checkout a tag
<jelmer> eean, that would mean switching the master branch to that tag as well though
<eean> or bzr branching shouldn't be so slow, then it wouldn't matter.
<vila> jam: I don't think the user should be remembered during a redirect... it could even return an ftp:// url
<vila> the root problem problem underlined by the FIXME is that we are not able to reliably put back the bzr decorators (http+pycurl and now nosmart)
<vila> another root problem is that we don't try to reuse the transport at the point (get_transport() with no possible_transports
<vila> and finally the real root, IMHO, is that nosmart+ was meant to disable the hpss probing under specific circumstances and that people now use it a bit more freely
<jam> vila: well, smart + bzr-svn interacted poorly, IIRC
<jam> so people tried no-smart
<vila> but yes, indeed, there are redirections bugS now
<jam> as for remembering user@ or not... if it is on the same host, under the same scheme, it seems reasonable to keep it
<jelmer> jam, nosmart will not work with bzr-svn
<vila> jam: get_transport() will reuse it indeed.. if possible_transports gives the hint
<vila> hmm, it may need a bit of help regarding user :-)
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available ! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Snaury> jelmer, I was just able to reproduce this. bzr rebase really drops some merges.
<Snaury> jelmer, try this: http://pastebin.ubuntu.com/43735/
<Snaury> by the end of the script myrepo/remote-branch-df will have no trace of any changes to 1.txt (which was in the merge).
<Snaury> That's what happened to me once.
<Snaury> I'm using http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/ revno 105
<jelmer> Snaury, Thanks, I'll see if it's expected behaviour
<jelmer> Snaury, Sorry, I was wrong about the merge behaviour
<jelmer> it will just skip all merges
<Snaury> :(
<jelmer> since it's hard to be smart about them
<jelmer> Snaury, you can use --always-rebase-merges though
<Snaury> jelmer: just tried that. in my example --always-rebase-merges doesn't change anything.
<Snaury> jelmer: but it's different now. the merge was rebased, but the revision is completely empty(!)
<jelmer> Snaury, hmm, I can reproduce that
<jelmer> Snaury, please file a bug
<Peng_> jam: Congrats on the release. :)
<jam> thanks Peng_
<vila> jam: You released 1.7 ?
<jam> vila: 1.6.1
<vila> jam: kidding :-)
<jam>  /topic
<jam> 1.7rc1 will be monday
<jam> so I had to get 1.6.1 out the door :)
<AmanicA> thanks jam for your persistence with 1.6!
<vila> I *know* :-) I was just finishing reading your mails about your feelings about the 1.6 release ans I was trying to make you smile
<AmanicA> I also just finised reading that thread :)
<Snaury> jelmer: see bug #266897 -- I even reduced the test case, it doesn't matter if there's another commit after the merge or not.
<ubottu> Launchpad bug 266897 in bzr-rebase "bzr-rebase loses merges" [Undecided,New] https://launchpad.net/bugs/266897
<Snaury> *test case -> test script
<jelmer> Snaury, thanks
<jam> AmanicA, vila: Thanks for your support. Now where were you during 1.6rc3-5? :)
<vila> jam: hmmm, partly in vacations and partly working like crazy to finish my old job :-D
<AmanicA> jam: I was away on holiday in europe
<vila> And even if I have been relatively silent these past days, I *did* work on "broken" (by platform) tests and I did my best to triage bugs (we are close to ~200 new bugs *only <cough>*) (learning a lot in the process. Far more than I can show right now), so I supported you more than you know :)
<jam> vila: you've been on the 'good' side of the process :)
<vila> jam: as for the reviews... Well, I plead gulty with mitigating circumstances (sp? blame google :), I didn't feel pertinent enough on the subjects :-/
<vila> LOL
<jam> Though I will say you know a lot more than you think you do
<jam> and you probably *should* be at least looking at the patches
<jam> so as to familiarize yourself with it
<jam> anyway, I'm done for the weekend
<jam> I'll catch you all on Monday
<vila> Oh, I looked at many....
<vila> sure, enjoy your week-end !
<AmanicA> cheers
<Odd_Bloke> vila: Where are you working now?
<dato> hi guys, I thought I'd just come by to say farewell. I'm trying to cut down the number of irc channels I'm in, and I think it's time to say good-bye to this one. I'm sorry that I've finally abandoned bzr, but I wish you the best of luck.
<dato> lifeless: sorry I never got to comment on the thread you asked me to, things have been hectic (in a good way), and I'm afraid I must cross it off my TODO list with "ENOTIME".
<mwhudson> yay for fixing #237067
<AmanicA> bug #237067
<ubottu> Launchpad bug 237067 in bzr "RemoteBranch.lock_read() doesn't lock the underlying repository" [High,Fix committed] https://launchpad.net/bugs/237067
<AmanicA> (just wanted to see what it is :)
<jelmer> dato: Sorry to see you leave here :-(
<jelmer> dato: Keep up the good work, I guess I'll see you around in some other channels :-)
<AfC> Oh, that's just charming: upgrade the format of a share repository, and then in one its branches `bzr info` reports Repository tree (format: unnamed)
<mwhudson> i think you get that when the branch format and the repository format together don't have a name
<AfC> Well is it "bad"?
<mwhudson> (1.6 == branch7 and packs5, i think)
<mwhudson> it's unfortunate
<AfC> uh huh
 * AfC is getting a little tired of all these formats and variants. Surely a) Bazaar could upgrade itself, and b) it could enable subtrees or rich-root or whatever if it needs it.
<AfC> Why should a user ever have to run `bzr upgrade`?
<nDuff> AfC, users can reasonably want to control when upgrades happen to allow older clients to be supported until their IT departments are ready to upgrade everyone.
<nDuff> AfC, silently doing upgrades when features require them can create unexpected compatibility issues with other users running older clients.
<AfC> "IT department"? These are _developers_ we're talking about. This isn't a corporation wide rollout of some office suite.
 * nDuff was involved in a startup using bzr with a very non-IT-proficient web design staff.
<nDuff> AfC, not everyone who uses a revision control system is a developer
<nDuff> AfC, and (sad as it is) not all developers know how to maintain their own systems (or are granted the rights to do so).
<AfC> nDuff: so compatibility issues, fine, but it would be nicer for the rest of us if that sort of thing was turned on explicitly, rather than the bulk of the user universe having to deal with the insane mess that is bzr help init-repo
<nDuff> AfC, anyhow, even if you *were* a developer-only shop, you wouldn't want one person running all the latest RCs to force everyone else to upgrade to an unstable version early, yar?
<AfC> nDuff: right. So some branch.conf flag says "don't auto upgrade me". Easy
<AfC> nDuff: (and yes, I would assume transparently taking care of shit like that would only upgrade at releases, etc)
<AfC> [Reading the 1.6.1 release note blew my mind]
<AfC> [certainly the fact that it cited "and if you've only been using releases you're ok" is a point in my argument]
<AfC> [but exposing an argument that is called "--1.6.1-rich-root"? Come _on_]
<fullermd> Well, it could be worse; it could be called 'star-merge' or something...
<nDuff> heheheh.
#bzr 2008-09-06
<jelmer> AfC: So, 1) the rich root format should become the default so there's no need for users to know about rich root anymore 2) there should be a way to enable an auto-upgrade mode in bzr
<AfC> fullermd: :)
<jelmer> AfC, ?
<jelmer> AfC: If that's what you're saying, I completely agree.
<AfC> jelmer: yup
<AfC> jelmer: (and then the nuance that I would argue that auto-upgrade should be default, with much larger teams dealing with potential compatibility problems by disabling it, thereby leaving a "better" user experience for people using it in smaller contexts / just learning)
<fullermd> That would work nicer if the last default-upgrade hadn't blown fiery chunks on me   :p
<AfC> fullermd: were they tasty? :)
<fullermd> I dunno.  I force-fed them to lifeless.
<lifeless> dato: ah well; I'll hope bzr is something you try again from time to time
<lifeless> AfC: svn does a mandatory upgrade; users complain bitterly in nearly every IRC channel I'm in, on *every* svn release.
<AfC> lifeless: interesting
<jelmer> lifeless: I think automatic upgrades should be optional, but they would be nice
<AfC> A somewhat different question is "should I have upgraded to --format=1.6?" No idea, other than the general notion that newer formats are hopefully better maintained code paths, etc.
<lifeless> git changes the data structures as new versions come in silently; for instance, using a submodule in  git adds pointers that will confuse older git clients, but nothing to help the user using that older client figure out whats wrong
<jelmer> lifeless, after all, bzr introduces new formats more often than svn with its 2 year major release cycle
<lifeless> AfC: unless a plugin or documentation tells you to, you should never need to type --format in annywhere
<lifeless> jelmer: I could buy into that, with some study on version propogation
<lifeless> note that 1.6 isn't a 'default' yet. It's used by bzr as-needed, and when a few months have past and everyone is likely to have a build available, then we'll make it the default
<AfC> lifeless: (sorry, but I really believe that `bzr upgrade --1.6.1-rich-root` looks terrible)
<lifeless> AfC: so do I
<AfC> lifeless: er, so why did you just state not to use --format=1.6.1-rich-root? Sorry bud, you lost me
<lifeless> AfC: 1.6.1-rich-root is mentioned in the documentation because we had a brown paper bag bug in 1.6. Its why there is a 1.6.1.
<AfC> I got that part
<lifeless> the only people affected by the bug are bzr-svn users that have run bzr branch --stacked
<lifeless> noone else in the world needs to run upgrade --1.6.1-rich-root
<AfC> It seemed like you were saying "never use the --format" form of specifying a format version
<lifeless> I was referring to both --format=X and --X
<AfC> So you're saying we _shouldn't_ have upgraded to X=1.6?
<lifeless> the use of parameters to choose a version is a sign of needing to do something at least slightly unusual, and most folk should never need to do that
<lifeless> AfC: are you using bzr-svn ?
<AfC> In this particular repo, no
<AfC> lifeless: ^
<lifeless> AfC: then there is no motivation for you to change your format
<AfC> oh shit
<AfC> um, should I downgrade back to --default then?
<lifeless> the 1.6 family of formats add the logic to support stacked branches (on the side doing the stacking)
<lifeless> they are no faster or more efficient than the '0.92-pack' family of formats
<AfC> ah
<AfC> well shit.
<AfC> That was a waste of time, then
<lifeless> if you went to '--1.6' then just leave it, its fine. or go back to --default if you like
<AfC> I'll stick with "leave it"
<lifeless> if you were on default and went to --1.6.1-rich-root, then you're in the wide wide world of rich roots now, and can't go back to default anyhow.
<AfC> 1.6
<lifeless> cool
<AfC> That'll teach me to be proactive.
<AfC> Clearly, I should not be doing systems administration before I've had a cappuccino.
<AfC> And so with that, I go out into the hurricane.
<lifeless> if you are passing a format parameter to any bzr command, its most likely that you are either a) using bzr-svn or b) experimenting with a development format to give feedback or c) doing something you do not need to do
<lifeless> AfC: ^ future reference
 * AfC celebrates (c)
<lifeless> this will always be the case
<Peng_> AfC: You should figure out how to upgrade to btrees. :D
<AfC> I don't think btrees go very well in espresso
<jelmer> lifeless: What happened to rich-root-pack as default format?
<lifeless> jelmer: thats how we'll get rid of a) from that list
<lifeless> jelmer: I don't know precisely whats left on the TODO list to achieve that, I thought we were pretty close at one point.
<awilkins> jelmer: Looks like my large SVN repo is nearly done
<jelmer> awilkins, cool
<awilkins> About 100 revs to go (it's a bit slow now)
<awilkins> I'm being a bit rubbish at reading this task manager
<awilkins> It says "Private bytes 506MB"
<awilkins> "Virtual Size 1.1GB"
<awilkins> I have no idea which one is the memory consumption :-)
<awilkins> But it's definitely the first time I've tried it and it's got this far without a) an error or b) running out of memory
<awilkins> Someone explain what a rich root is because I can't find a definition in the wiki
<markh> what I kept looking for as a younger man....
<awilkins> Heh. I had the opposite, a girl I had no chance with because her boyfriend was a millionaire...
 * markh expects only the Aussies will understand that...
<markh> bugger!
<awilkins> 9647/9699! exciting
 * awilkins is bored waiting for it and will now try Bazaar on IronPython 2.- b4
<awilkins> ooh, generating file id map
<awilkins> New steps
<lifeless> awilkins:
<lifeless> mistype, sorry
<markh> So, incase anyone is interested, bzr.dev's selftest on windows now results in "FAILED (failures=55, errors=50, known_failure_count=14)".  47 or so of the errors are the LockContention issue - so once we knock that off it will almost be manageable.
<mkanat> How do I cancel a bzr mv?
<markh> mkanat: bzr revert?
<mkanat> markh: I don't want to revert everything, just the mv.
<markh> specify the old name?
<mkanat> It says my new name isn't versioned.
<markh> or maybe even the new name? :)
<mkanat> Oh, nevermind.
<mkanat> Specify the old name was right. :-)
<mkanat> I was just in the wrong directory.
<markh> yeah, it just worked for me :)
<poolie_> hello
<markh> g'day martin
<markh> and the next most common test failure is related to URLs not being put together correctly
<markh> eg:
<markh>   File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1339, in test_abspath
<markh>     transport.abspath("/foo"))
<markh> AssertionError: not equal:
<markh> a = 'unlistable+file:///O:/window%7E1/testbzr-t4cckw.tmp/test_abspath%28UnlistableServer%29/work/foo'
<markh> b = 'unlistable+file:///O:/foo'
<poolie_> jam, hi?
<bob2> null pulls seem to have become absurdly fast
<markh> so does anyone understand transport.abspath?
<poolie_> markh: hi, i think i do
<markh> poolie_: so a test is calling 'transport.abspath("/foo")'.  Best I can tell, that boils down basically to 'abspath(transport._rootpath, "/foo")'
<markh> and as the second path is absolute, that always returns '/foo' - ie, the _rootpath is ignored
<poolie_> that seems plausible
<poolie_> but, kind odd to be passing that tbh
<poolie_> normally we should only be working relative to the transport
<poolie_> which test
<markh> on windows, I'm seeing just /foo - and the test is failing - its expecting to see _rootpath
<poolie_> (i have to go in a minute but i'll be back)
<markh> I'm wondering how it works on Linux
<markh> test_transport_implementations.TransportTests.test_abspath\(ReadonlyServer\)
<markh> (but many of the test_abspath variations fail)
 * awilkins keeps meaning to set up an Ubuntu image for seeing what Linux does for particular test cases
<poolie_> In [4]: get_transport('file:///home/').abspath('/goo')
<poolie_> Out[4]: 'file:///goo'
<markh> I've got one, just done have my debugger of choice and never mastered pdb ;)
<awilkins> Heh, I just insert 'print "bumhole : " + relpath
<awilkins> Highly unprofessional to use rude words in debug messages but it relieves the tension
<poolie_> that assertion at line 1338 does seem plausible to me
<markh> heh :) - print "WTF - ", blah is my usual :)
<poolie_> so it looks like the problem is that transport.clone('/') is not really taking you up to the root
<poolie_> sorry i need to go or i will miss the shops
<poolie_> biab
<markh> poolie_: that test works for you though?
<markh> no probs
<poolie_> on linux, yes
<markh> that is what I don't grok :)
<markh> ttu later
<poolie_> markh, i'd suspect clone('/') has some kind of bug
<poolie_> would drill into that
<awilkins> markh: At least linux HAS a "/"
<awilkins> Windows doesn't have one, but it does contain drives...
<markh> awilkins: its time you got over your fascination with roots ;)
 * markh ducks
<markh> ok, so clone being wrong is the clue I needed
<awilkins> Meh, I had to tinker with the local transport to treat "/" specially on Windws
<awilkins> Hmm.
<markh> hrmph
<awilkins> Which test is it?
<markh> I think its stranger than that.  It doesn't make sense to me that 'transport.abspath('foo') returns me at the root of the transport, while transport.abspath('/foo') gives me the root of the file-system?
<markh> test_abspath in test_transport_implementations
<markh> maybe that is by design.  I better understand things more before I jump to conclusions...
<awilkins> It's my fault
<markh> heh - handy you are here :)
<awilkins> bisect 3549 and 3550
<markh> that would be 3549.5?
<awilkins> 3549 is clean, 3550 introduces the bug
<awilkins> 3550 fixes SSHD support on windows
<awilkins> I'm not sure it causes problems for anything but the test, noone has complained
<awilkins> It doesn't fail on Linux because it's platform specific behaviour
<markh> that path is handling "/" as a special case, but the test isn't testing specifically that - so it might be possible to fix without reverting what you added?
<markh> s/path/patch/
<awilkins> I think we can fix the test, probably
<markh> there are quite a few like it actually
<awilkins> Yipe
<markh> test_has_root_works, test_clone_to_root
<markh> and test_clone_from_root seems about it
<awilkins> markh: The problem seems to be that abspath makes use of the concept of "root", which windows doesn't have
<markh> well, it does and it doesn't
<awilkins> (the test, that is)
<markh> \foo does mean something on Windows - its just that '\' doesn't make every file available
<awilkins> Yes, I exploited the "doesn't" part
<markh> How would a windows server prevent, say, the CD drive from being shared?
<markh> or network shares
<awilkins> By not sharing them?
<awilkins> Access control lists?
<jam> hi poolie_
<markh> jam: hi - poolie ran out to the shops
<awilkins> Regardless of the merits of one approach over another, /foo is a different idea to \foo because \foo requires you to know what pwd is
<awilkins> Whereas /foo is always /foo
<markh> awilkins: yeah - but trying to pretend windows is otherwise might be a can of worms
<markh> I'm not a windows server admin would expect '/' to share every mapped drive
<awilkins> The only case where '/' is allowed as a transport base on windows is when you are executing "bzr serve"
<markh> but - I don't really want to start a debate over that :)
<awilkins> All other routes in go through checks that prevent you using '/'
<jam> hi markh
<awilkins> It's the only way that sshd works because the --inet call uses '/' as a transport base
<jam> markh: using anything but a relative path for Transport gets you into the wide world of undefined
<awilkins> Otherwise you can only server repos that are on the same drive
<awilkins> as python.exe
<markh> yeah, I'm happy to accept that requirements.  I don't quite understand why the tests are failing though when they aren't explicitly testing '/'
<jam> so ".get('/foo')" is ... ?
<jam> I eventually wanted to forbid it
<jam> I don't think we got that far
<awilkins> It's because on windows, a transport with base '/' is actually ''
<markh> but - these tests don't have a base of '/' do they?  They have a base in the temp dir.
<awilkins> These tests don't have any dir - they are testing path math, not file io
<jam> markh: I believe spiv introduced a test on the behavior of passing '/'
<jam> at the time, I believe I wanted it to abort, but he was fixing some other bug
<jam> and we didn't want to do both.
<markh> jam: the issue is many windows tests are failing, along the lines of:
<markh>   File "O:\src\bazaar\bzr\bzr.work\bzrlib\tests\test_transport_implementations.py", line 1295, in test_clone_from_root
<markh>     root_transport.clone('.bzr').base)
<markh> AssertionError: not equal:
<markh> a = 'readonly+.bzr/'
<markh> b = 'readonly+file:///O:/window%7E1/testbzr-t4cckw.tmp/lone_from_root%28ReadonlyServer%29/work/.bzr/'
<markh> I'm happy to avoid a debate about the correct semantics for serving '/' at the current time :)
<awilkins> I apologize for causing this bug by the way :-)
<markh> awilkins: and accept the thanks for fixing the bug :)
 * awilkins is thinking
<markh> no - sorry
<markh> I meant the *original* bug
<markh> it was obviously a real requirement
<jam> markh: so the problem is about ".clone('/')" is returning 'readonly+' instead of returning "readonly+file:///"
<jam> I think it should strip the O:
<awilkins> The o:// is correct
<awilkins> o:/
<jam> I think the *test* is about not doing two '//'
<jam> so you don't get file:////
<jam> well, file:////.bzr
<jam> and the same for
<jam> http://host/.bzr being correct
<markh> a couple of other similar failures also have '+file' and '+.bzr' different in the scheme portions of the URLs, which I suspect is a different problem (but they *also* have the path portion wrong)
<awilkins> markh: o:/ is where your python.exe is, yes?
<markh> yes, and the source tree and the temp dir
<markh> o:\window%71 is %temp%
<jam> window%71... seems like an interesting temp dir
<markh> o:\Windows_Temp_Files - I've changed %TEMP% in my global environment.  I keep getting sick of going digging for it :)
<jam> ahh, o:Window~1
<markh> and "\temp" has kinda been abused by me over the years to mean more like "scratch"
<jam> the dreaded 8.3 name
<jam> funny story... I worked for a while at a company that tracked stocks
<jam> We had a feed that came in, ~2GB per day
<markh> and o: is my fastest dsik :)
<jam> and it would sort the stocks by prefix a/ b/ c/ etc
<jam> the "D" directory got filled with "DE:foo" because we got the german stocks
<jam> Which caused you to end up with D~1324234 style names
<jam> disabling the 8.3 names made the whole thing go *tremendously* faster
<jam> because you didn't end up with a path collision for *every* file in the directory
<markh> interesting!
<awilkins> I wonder if it makes things just go faster anyway, it must eliminate a pointless check
<markh> %temp% could end up suffering a similar problem I guess with too many similarly prefixed temp files that don't get cleaned up
<awilkins> I can't think of anything I use now that needs 8.3. names
<jam> awilkins: yeah, but in this case it is at least O(N) to insert a new file
<jam> because it has to find a new unique 8.3 name
<awilkins> Nasty
<jam> And when you have 100,000 german stocks... N gets big
<markh> if you disable short paths, I could imagine a few things failing
<jam> markh: yeah, things that don't like spaces, etc. But most *new* programs should do fine
<jam> Then again for %temp% maybe not
<markh> I recall some issue where its extremely hard to use an argv[0] with spaces in it to some exec/spawn function, for example.
<markh> I've personally written code that will fail if win32api.GetShortPathName() fails :(
<markh> but in all cases I've used it, its been the last alternative I could think of
<jam> markh: ah, and tla/baz-1.0 used 8.3 in creative ways
<jam> Specifically, Arch had a really bad habit of repeating itself in path names
<jam> Last I checked it would create a 13-layer deep path structure
<jam> with a lot of redundancy
<jam> Which could easily put you over the 260 char limit
<jam> so we hacked in code
<jam> that would *create* the paths with the full name
<jam> and then remember it as the 8.3 name
<jam> 12 * 13 = 156 chars
<jam> so we would stay underneath MAXPATH
<jam> ugly hack, but it worked
<awilkins> NTFS can actually use much longer filenames, I think it's just the userland that won't use more than 260 chars
<awilkins> (academic)
<jam> awilkins: you have to disable the checking
<jam> using \\?\full\path\to\the\file
<jam> You a) can't use a relative path anymore
<jam> and b) cygwin didn't support it
<markh> heh - interesting hack :)
<jam> and Arch only compiled on cygwin
<markh> and most apps don't support it!
<jam> markh: right, Explorer didn't support it
<jam> in XP
<jam> Or at least win 2k
<markh> no point passing a "\\?\" huge string on the command-line to an app that just uses open() on it, for example
<jam> so you couldn't "del" the directory
<jam> you had to rename them
<jam> until it was short enough
<markh> yes
<jam> and *then* delete it
<markh> I've been stuck with exactly that when testing the same issue :)
<jam> And I think explorer actually segfaults trying to browse to the dir
<jam> not "sorry I cannot do that" but actually hangs and dies
<markh> and the cmdprompt failed in creative ways
<markh> I ended up doing the renames under the cmdprompt
<jam> awilkins: so the answer is a "sorta" for paths > 260
<markh> technically yes, practically no in general :)
<awilkins> Hg was running into that the last time I used it
<markh> for paths that only you ever work with, yes
<jam> awilkins: yeah, one of the problems with re-using the paths given to you by the user
<awilkins> it escapes capitals with underscores
<awilkins> so for long paths with lots of caps in....
<jam> awilkins: I remember someone who was versioning their Moin, which used capital letters for the hex hashes
<awilkins> ... nested in c:\Documents and Settings\user\Application Data\Hg
<jam> so you had 40 characters all caps
<markh> at least vista has changed back to reasonable paths in most cases
<awilkins> So has WinXP when you diddle the install disk
<jam> markh: yeah, I do like C:\Users\username again
<jam> Documents and Settings crummy to type
<markh> awilkins: so without your patch I hate to report I get 26 more tests passing
<awilkins> I mostly expand env variables when working in those folders these days
<awilkins> lots of $env:appdata
<awilkins> markh: 'tis a dilemma
<markh> and it we knock off the LockContention errors we will be down to ~25 errors, which is getting good
<awilkins> I think that might help some of the errors I've been seeing on auto-packs on SMB shares
<awilkins> Might be down to bloody oplocks though
<markh> I've seen something similar, but the error is too transient to be locks IMO
<markh> well - bzr's use of locks anyway
<awilkins> Where you commit to a bound branch and get error 17
<awilkins> (you can fix by packing the branch, even over the network)
<markh> can't recall the exact details now
<awilkins> Neither can I, I must grab the log from the affected users
<jam> awilkins: autopacks don't trigger SMB issues
<jam> IIRC, the problem is that the network stack on win32 doesn't let you write > ~10MB at a time
<jam> and we were expecting normal file operations
<jam> which lets you write say 100MB
<jam> I thought we had a patch for that sort of thing, to "spool" out to files chunks at a time
<jam> should be in either 1.6 or 1.7
<awilkins> jam: Would that only work over network transports?
<jam> awilkins: so it happens when writing on SMB
<jam> because apparently the psuedo file
<jam> writes into the network stack
<jam> So we changed it for *all* writes to the filesystem
<awilkins> Aha
<awilkins> This is a 1.6 client
<jam> awilkins: we first encountered the issue on networking stuff like bzr+ssh and socket.recv()
<awilkins> It has my switch sibling patch, but otherwise it's release (I think)
<jam>     * Pack operations on windows network shares will work even with large
<jam>       files. (Robert Collins, #255656)
<jam> that will be in 1.7rc1 this monday
<jam> bug #255656
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656
<awilkins> THat seems familiar
<awilkins> Although I seem to remember an error with a "7" in the code as well
<jam> speaking of which, markh, any chance to get a 1.6.1 final build uploaded?
<awilkins> I'll pull those logs if I recall
<jam> awilkins: well markh mentioned error 17.
<jam> But it certainly sounds like what you were running into
<markh> jam: it actually just finished uploading recently!
<awilkins> markh: If you change that transport.clone('/') to clone('/bar') and the next line to /bar/foo it fixes those 7 failures. Where are the rest?
<markh> I used the '-1' convention you suggested
<jam> awilkins: of course, you just broke the *point* of that test
<jam> markh: sounds good. Actually, can you update the bazaar-vcs.org/WindowsDownload page as well?
<awilkins> jam: I confess, I don't understand the point of that line if it's not to check that cloning /bar and getting a relative foo is equivalent to an absolute /bar/foo
<awilkins> (or / + foo == /foo )
<jam> awilkins: it is to check that for "/" + "foo" == "/foo" and not "//foo"
<jam> versus '/foo' + 'bar' == '/foo/bar'
<jam> basically it is testing the edge case of when we need to insert an extra slash, and when we don't
<awilkins> It's 0342 and I'm not functioning. Bedtime. I'm not sure there is a simple way out of this anyway... it's one of those cogitive dissonance/ impedance mismatch/ tomato tomato things
<jam> I always like how "tomato tomato" doesn't work at *all* in print.
<jam> I've see "tomatoe tomato" but then you're just misspelling
<harbinger0x7c0> Hi...  I'm new to bzr and I'm looking for some help with bzr-svn and ssh tunnels.
<jelmer> harbinger0x7c0, hi
<markh> jam: updated the wiki
<jam> thx
<harbinger0x7c0> Hi, jelmer!  So, would you like to hear what I'm trying to do?
<jelmer> harbinger0x7c0, sure
<harbinger0x7c0> There's a svn server I'd like to be able to connect to, but it's behind a firewall I can only bypass by connecting to another machine.  I set up a 2-hop ssh tunnel to get through, but I think I'm missing something in the syntax for connecting to it because I get an error about an unsupported protocol.
<harbinger0x7c0> The URL I provided was "svn+ssh://alt255@localhost:8080/home/alt255/SemanticAnalysis"
<jam> harbinger0x7c0: well, the first thing to test with any of this, is whether *svn* connects correctly
<harbinger0x7c0> That makes sense...  I'll try it out and report back.
<harbinger0x7c0> Okay.  I was able to successfully check out using svn over the same tunnel.
<markh> jam: so best I can tell, the awilkin's patch changed things to that osutils._win32_local_path_to_url('/') no longer includes the current drive in the URL.  That doesn't sound good to me.
<jam> markh: the change seems fine to me, as long as it gets expanded to the rest of the code correctly
<jam> I have no problem faking "file:///" on windows when we need to
<jam> I *believe* we already use file://host/ to translate for \\network\drives
<markh> so should "/foo" get the drive back in the URL?
<markh> ie, is only '/' special?
<jam> markh: no "/foo"  should just be an illegal filesystem path
<jam> since it doesn't have a drive lettr
<jam> but that doesn't mean we can't create a path file:///foo
<jam> well, we can't create the *file* but we
<jam> can make the string
<markh> yeah - its not an illegal filesystem path :)  I understand bzr wants to treat it as special.  But that would mean all tests that use '/foo' are invalid on windows?
<markh> and does it mean those tests should actually be throwing an "illegal path" type exception?
<jam> markh: we should *never* be trying to open('/foo') on any system
<lifeless> markh: no tests should be doing /foo anywhere :P
<jam> so just representing it in memory... seems fine to me
<jam> So I see tests like:
<jam>         # the abspath of "/" and "/foo/.." should result in the same location
<jam>         self.assertEqual(transport.abspath("/"), transport.abspath("/foo/.."))
<jam>         self.assertEqual(transport.clone("/").abspath('foo'),
<jam>                          transport.abspath("/foo"))
<jam> (sorry for flooding)
<markh> what about tests like 'transport.abspath("/foo")'?
<jam> but that doesn't seem like anything that would really break anywhere
<markh> well - isn't "/foo" an invalid abspath on windows?
<jam> markh: LocalTransport.abspath('/foo') => file:///foo
<jam> markh: it *is* but so is "C:/not/a/direcotry/foo"
<jam> (again, I personally think the transport api should all be relative paths *anyway*, but that is a deeper change)
<markh> so when you say "/foo" is an illegal filesystem path, what's that mean?
<markh> I took it as meaning its an invalid abspath
<jam> markh: so my point is... we don't need to detect that it is invalid until we try to *do* something with it
<jam> because we have to detect when a path doesn't exist anyway
<markh> if its invalid, shouldn't we detect that early?
<jam> again, real code shouldn't be making up paths
<jam> it should take them from the FS with stuff like 'abspath()' etc
<markh> so - getting back on topic - if "/foo" is invalid, the tests should not be using it on windows, right?
<markh> regardless of when it is checked
<sohail> hi
<jam> markh: the tests are only testing the join() etc logic, I don't think '/foo' is a problem.
<sohail> how can I copy a directory to another directory?
<sohail> not move, but copy. I want to copy a directory and make modifications
<markh> and that join logic makes no sense on windows as the path is invalid
<markh> right?
<markh> we don't need to test the "/" edge case for invalid paths - we don't care *what* it returns for practical purposes.
<jam> markh: well, we also are testing http transport etc. There is at least an argument about not running that test for LocalTransport and win32, except we still need to handle join("file:///' , 'C:') correctly, because of things like "bzr serve"
<markh> yes, some new tests are probably needed I agree
<lifeless> markh: tests that actually do IO shouldn't be using /foo
<lifeless> markh: I don't think any are
<lifeless> markh: tests that test url joining logic it should not matter regardless of platform
<lifeless> markh: and if it does matter, I don't understand why
<lifeless> sohail: 'cp' - we don't have a copy operation in bzr today
<lifeless> sohail: (other than 'bzr branch' to make a full new branch
<sohail> lifeless, doh :-(
<sohail> I have a presentation that I want to rip up
<sohail> I guess I can just do a file system copy
<jelmer> harbinger0x7c0, sorry, was away for a bit
<jelmer> harbinger0x7c0, what's the error you get with bzr-svn?
<harbinger0x7c0> jelmer: the error is 'bzr: ERROR: Unsupported protocol for url "svn+ssh://alt255@localhost:8080/home/alt255/SemanticAnalysis"'
<jelmer> harbinger0x7c0, is bzr-svn listed if you run "bzr plugins" ?
<harbinger0x7c0> jelmer: heh...  no. :-[
<jelmer> harbinger0x7c0, so it looks like bzr-svn isn't installed correctly
<harbinger0x7c0> jelmer: it looks like I'm short the svn development files.  Do you know what they would be named for Fedora?
<jelmer> harbinger0x7c0, on Debian/Ubuntu it's libsvn-dev, not sure about fedora
<harbinger0x7c0> jelmer: I got 'make' to finish, but now when I use 'bzr plugins' it says "Unable to load plugin 'svn' from '/home/tomas/.bazaar/plugins'".
<jelmer> harbinger0x7c0, please check ~/.bzr.log
<harbinger0x7c0> There's an "AttributeError: 'module' object has no attribute 'properties_handler_registry'" from line 160 of __init__.py
<jelmer> harbinger0x7c0, your version of bzr is too old
<harbinger0x7c0> jelmer: so I need an older svn-bzr?
<jelmer> harbinger0x7c0: yeah - see the list on bzr-svn's wiki page
<harbinger0x7c0> jelmer: lol, now it's unhappy about the python bindings.  It's starting to look like maybe 'yum' isn't always as convenient as I thought.
<jelmer> harbinger0x7c0, you can't use the vanilla python bindings with fedora if you're using bzr-svn < 0.4.11
<harbinger0x7c0> jelmer: I need to find the Fedora analog to the 'python-subversion' package, right?
<jelmer> harbinger0x7c0, if you have bzr-svn < 0.4.11 you need to apply certain patches to python-subversion as well
<jelmer> you can't just use the released version of python-subversion, since fedora doesn't carry the required patches afaik
<harbinger0x7c0> jelmer: I think I'm going to see about just getting a more recent version of bzr instead...  That's seeming a little simpler just now.
<markh> jam: you still here?
<harbinger0x7c0> jelmer: thanks for your help.  I think I'm done playing with this for tonight.
<clemente> The release notes for 1.6.1 are not linked in the home page; is this intended?
<poolie__> clemente: they probably should be hey?
<clemente> poolie__: I think so. Lots of people want to see what's new
<poolie__> how's that?
<markh> poolie: found a 2 line patch to solve 32 of those LocalTransport test failures :)
<clemente> I think that many people are waiting for bzr to greatly improve and become better than the others :-)
<clemente> therefore they are curious about the new improvements
<poolie> markh, nice
<markh> so if we get rid of the lock contention, we will be close to 20 errors left!!
<LarstiQ> sweet!
<jml> lifeless: thanks for the review
<jml> lifeless: but you are never, ever going to convince me that adsorbSuite is a good name for anything :)
<poolie> really 'adsorb'?
<mwhudson> my word, jml on a weekend
<markh> heh - and a 1 character change for the other last 3 :)
 * markh mutters about linux people forgetting the 'b' in the file-mode... ;)
<jml> poolie: really.
<jml> mwhudson: yes! I have internet at home
<poolie> aside from anything else that distracted me into wikipedia description of material science
<poolie> :)
<mwhudson> jml: congratulations
<poolie> Adsorption is a process that occurs when a gas or liquid solute accumulates on the surface of a solid or a liquid
<mwhudson> yeah, adsorb is something to do with catalysts, isn't it?
<jml> I suggest "test_suite_nomnomnom" as an alternative
<mwhudson> jml: ha
<poolie> i guess it's just possible that the tests accumulate on the surface of the other test
<LarstiQ> markh: ai, I may be guilty of that myself.
 * jml goes to watch film
<lifeless> jml: I'm not defending adsorb
<lifeless> jml: I appreciate that making people read dictionaries is not a goal of testresources :). But the replacement name has its own issues, which is what I focused on, I thought
<LarstiQ> what's wrong with nomnomnom?
<lifeless> LarstiQ: too many things
 * LarstiQ ducks for cover
<poolie> night all
<poolie> lifeless: did you mean absorb or adsorb?
<poolie> anyhow, night!
<fullermd> Mmph.  So, are we really seriously not putting releases in bazaar-vcs.org/releases/src/ anymore?
 * markh learnt today that adsorb was a word!
<AfC> Aren't we just the Oxford English Dictionary today.
 * AfC just looked it up. I had no idea that was a word either
<poolie> fullermd: yes, we should be
<poolie> there is a makefile rule to do it and it's in the process doc
<poolie> there may have been a technical issue
<poolie> anyhow, seriously goodnight!
<fullermd> Oddly enough, I knew that word, though for the life of me I can't think of any good reason why I would.
<pfeil> Hi, I would like to set up a bzr server for an open source project. I will push the inital source code, every body else can branch. When someone has modifyed the source, he/she should be able to commit, but without touching my stable branch. I will then review the changes and merge when appropiate to the release trunk. (This model is described as "1.3.7   Decentralized with human gatekeeper" in the Bazaar User Guide). Can someone point me to where
<AfC> to where...?
<fullermd> To where!
<Odd_Bloke> pfeil: You got cut off at 'to where'. :)
<pfeil> Can someone point me to where I find instructions on how to set up the server?
<pfeil> And - especially - the permission rights.
<mwhudson> well, this sort of thing is extremely easy on launchpad
<AfC> If you have a server where they have (or you can create) normal user accounts for each committer, it's pretty easy too.
<pfeil> I have already lokked into that, but I have a very restrict OpenSource licences, so Launchpad is not right for me.
<AfC> "restrictive" and "open source" do not go in the same sentence.
<pfeil> I have a ubuntu 8.04 server running ssh+sftp + whatever I will need...
<pfeil> AfC: Well to be more precisely: Its Open SOurce, Users may not make money with it and are foreced to submit ALL changes.
<AfC> pfeil: so for what it's worth, we have the setup you require in the repository we host. It does work to isolate one group of developers from another. You just use unix permissions and an appropriate umask. Frankly it's got nothing to do with bzr and everything to do with systems administration.
<Odd_Bloke> pfeil: What license is it under?
<pfeil> It is a propriate license, I am working on just right now - no official or approved Open Source License.
<Odd_Bloke> OK.
<Odd_Bloke> As AfC said, if you have a server where users have a login, then the problem is trivial.
<AfC> Odd_Bloke: (well, not quite - he wants isolation. That makes it trickier)
<pfeil> Odd_bloke: Yes I have a server. When I understand the abouve posting right, I will have to add a user account for every subsriber to the project?
<Odd_Bloke> AfC: "restrictive" and "open source" often go together.  The GPL is very restrictive, in order to ensure that the four freedoms aren't compromised.
<Odd_Bloke> AfC: Well, they just push to a world-readable branch in a well defined place in their home directory.
<AfC> Odd_Bloke: sure sure. But you know what I was talking about. And so does he. It's either Open Source or it isn't. It's not really something we need to quibble about.
<Odd_Bloke> Which you can easily setup in locations.conf.
<fullermd> Not something we have to quib...   dude, it's IRC!
<pfeil> Well is there any docu about setting this up. I am not expreienced with seiitng bzr up on a server at all and i dont want to open wide security holes.
<AfC> fullermd: :)
<kowey> howdy, #bzr folks! is one of the organisers for the previous bzr sprint around, please?
<Odd_Bloke> pfeil: If you are happy to use separate account for each user, then just treat bzr branches as directories in terms of security.
<AfC> Making that work with a shared repository takes a bit of care but is a nice touch.
<pfeil> I would like to read a howto. Without, I will have to try around. This will take time. If there is a doc out there, I would be more than happy if someone can point me to it.
<AfC> Pardon the dumb question, but I'm not a regular Ubuntu/Debian user these days. What do I have to do after adding the PPA line to a sources.list to make apt-get upgrade not ignore it?
<AfC> (something about accepting a signature?)
<AfC> Hm. Forget it. I guess it works anyway
<ronny> hi
<ronny> anyone knows if "Javier Derderian" shows up here from time to time?
<hsn_> python based installer for 1.6 available?
<Kamping_Kaiser> if i want to export a bzr repo into something i can make .debs out of, what tool do i need? i cant seem to see one in the bzrtools package.
<Odd_Bloke> hsn_: What do you mean by 'python based installer'?
<Odd_Bloke> Kamping_Kaiser: 'bzr export'.
<Kamping_Kaiser> hm. ok, thanks Odd_Bloke
<Odd_Bloke> Kamping_Kaiser: Alternatively, use 'bzr-buildpackage --split'.
<Kamping_Kaiser> Odd_Bloke, hm. thank you. i think thats wha ti was after
<Kamping_Kaiser> Odd_Bloke, yes, thats what i was after. thanks very much :)
<Odd_Bloke> Kamping_Kaiser: No worries.
<hsn_> Odd_Bloke: installer without included python
<Odd_Bloke> hsn_: Presumably you mean for Windows.  I'm afraid I don't know.
<Odd_Bloke> markh and bialix are the two primary Windows people.
<Odd_Bloke> But I don't know if markh is around over weekends.
<Peaker> hey, isn't "lp://proj-name/branch-name" an acceptable URL for bzr? (Launchpad)
<Peaker> oh nm, found the right URL
<Odd_Bloke> Peaker: lp:proj-name/branch-name is presumably what you found.
<Peaker> Yeah, dropping the //
<Peaker> also registered the project properly
<Odd_Bloke> :D
<Peaker> I just registered xpdb - forking pdb to fix its troubles
<Peaker> (pdb.py)
<wolever> I'm having a weird problem where `bzr log $FILE` seems to show _all_ revisions (that is, the same as `bzr log`) instead of just the revisions in which $FILE is changed... Any advice?
<beuno> wolever, that *is* odd
<beuno> what version of bzr are you using?
<wolever> 1.6
<wolever> This is a branch which was created with bzr-svn, if that's relevant
<beuno> ah, that could be why
<beuno> wolever, are you subscribed to our mailing list?
<wolever> No, but I could be
<beuno> because it's the weekend, and all the relevant people seem to be resting for some reason
<beuno> or, you could file a bug/question in Launchpad
<beuno> whichever you rpefer
<beuno> prefer even
<wolever> Ok
<wolever> I'll try my luck on the mailing list -- thanks
<beuno> welcome'
<wolever> I presume the users list would be more appropriate than the developers?
<beuno> we actually don't have a users list
<beuno> we're one big family
<beuno> and all developers are very friendly
<wolever> Ah, good stuff -- and I guess that's this one: https://lists.ubuntu.com/mailman/listinfo/bazaar ?
<beuno> yeap
<wolever> Yes, this is defiantly a problem with bzr-svn... I'll post to their bug tracker instead.
<Guest2056> wolever, what verison of bzr-svn are you using?
<wolever> Guest2056: I'm just in the middle of updating to the newist version -- lemme check and get back to you
<wolever> Dang
<wolever> After updating to the newest bzr-svn it's just erroring out
<Guest2056> wolever, you updated to 0.4.12 ?
<wolever> I'm running the HEAD of http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/
<wolever> Here are the commands I'm running: http://pastebin.com/d73819fb1
<wolever> Before everything was dying, the `bzr log a` would show both revisions -- not just the revision which 'a' was added.
<wolever> Darn -- the last line should be `bzr log a` :P
<Guest2056> wolever, "bzr log a" shows just one revision here
<wolever> Which version of bzr-svn are you using?
<Guest2056> the 0.4 branch
<wolever> Blast...
<wolever> Which rev?
<wolever> It's possible that something is broken with my build of SVN... So I can look at that too
<Guest2056> wolever, 0.4 revision 1708
<wolever> Darn, ok -- then something is wrong with my svn.  When I run `bzr co file://...`, it says "bzr: ERROR: a is already versioned"
<hsn_> !help
<ubottu> Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
<hsn_> wow 2 minute botlag
<Guest2056> wolever, still there?
<wolever> Yup
<Guest2056> wolever, have you tried refetching the branch after removing the svn cache?
<wolever> Yup
<wolever> Same deal
<Guest2056> and the branch you're checking out is just created with those commands you pasted earlier?
<wolever> Yup
<Frenzel> hi all
<Frenzel> I have a quick question with hopefully a simple answer. In our project there are lots of people commiting but not all enter a good descriptive commit description. Can I edit commit descriptions?
<Guest2056> hi Frenzel
<Frenzel> Hi
<Guest2056> Frenzel, not at the moment, there is an open bug report that discusses the implications of supporting this.
<Frenzel> I would say, make it possible because now it is a mess
<Guest2056> Frenzel, it's not trivial to support
<Frenzel> That I understand :)
<Guest2056> I certainly see the use case for it, though
<Frenzel> but eventhough I would like to have this feature
<Frenzel> Where can I find this open bug report?
<Frenzel> you have a URL/bugid?
<Guest2056> Frenzel, it should be in launchpad, not sure what the bug id is
<Guest2056> Frenzel, there has been some discussion about changing commit messages on the bazaar mailing list earlier, it mayve been mentioned there
<Guest2056> Search for the subject "Changing a commit message"
<Frenzel> ok
<Frenzel> thanks a lot
 * Peng_ has been pulling from lp:bzr-svn for 7 minutes . . . . .
<Peng_> Oh, it's done.
<Peng_> Oh, lp:bzr-svn points to a different branch now. That'd explain it. Never mind. :)
<LarstiQ> oh, which one?
<Peng_> LarstiQ: It changed from 0.4 to the trunk.
<LarstiQ> what, that thing lives again? :)
<Peng_> I think I can pull from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ without a traceback now too. Yay.
* abentley changed the topic of #bzr to: current topic is: Bazaar version control system | http://bazaar-vcs.org | Bundle Buggy under maintenance | bzr-1.6.1 now available ! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Stellaris> Good evening, does anybody know of a (free) bzr hosting like launchpad, but with private repos/accounts? I looked at the tour on their site, but didn't see anything about private branches/hosting
<Stellaris> Did I miss it?
<Guest2056> Stellaris, Afaik launchpad doesn't have that, at least not for free
<Guest2056> Stellaris, (the folks in #launchpad know more about this, probably)
<Guest2056> Stellaris, you should be able to use any sftp/ssh shell server for private hosting though
<Stellaris> Guest2056, okay, will look into that, thanks
<bud3030> Hi, I have be looking for some time to delete bzrlib to upgrade but can't find enough to make this change
<LarstiQ> bud3030: you probably shouldn't do that.
<bud3030_> hi lost the window
<LarstiQ> 22:41:31 < LarstiQ> bud3030: you probably shouldn't do that.
<LarstiQ> bud3030: do you want to use a newer version of bzr?
<bud3030_> yes
<LarstiQ> bud3030: where does your current one come from, package manager, run it from source?
<bud3030_> just leave the dir and run source
<bud3030_> thank I guest my ID should be ID iot
<bud3030_> login out thanks
 * LarstiQ blinks
<Guest2056> rockstar, fwiw, branching KDE branches with bzr-svn now works
<Peng_> abentley: I guess you can take the Bundle Buggy thing out of the topic now.
<Peng_> abentley: What was the old server it was on? What's the new one?
<abentley> Peng_: Yes.
* abentley changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available ! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Peng_> I don't use BB much, but it definitely feels fast. Nice. :)
<Peng_> Yay Linode?
<abentley> Peng_: The old server was a Feisty Xen virtual machine hosted by unixshell.  The new one is a Hardy Xen virtual machine hosted by linode.com
<Peng_> How large is the Linode?
<abentley> Peng_: a Linode 360
<Peng_> ok :)
#bzr 2008-09-07
<Peng_> Hmm. bzrlib.plugins.search.index.index_url() should support possible_transports. cmd_index wastes a transport just to parse the URL.
<Peng_> Or I guess index_url should just take a transport directly.
<cammoblammo> `bzr ignored` seems to list the ignored file then the rule for identifying it. Is there any way the rule can be stripped from the output without resorting to awk or the like?
<fullermd> Perhaps you want ls --ignored
<cammoblammo> fullermd: Thanks! That's perfect.
<adam> Hi
<adam> can I set bzr to ignore .pyc on *all* newly created projects?
<fullermd> Depends on what exactly you're asking.
<fullermd> You can add .pyc to your personal ignores.  You could theoretically hack bzr to add .pyc system-wide.
<fullermd> But there's no way to make a new projects spring into being with a .bzrignore handling .pyc's. no.
<adam> ah, too bad.
<adam> I was thinking about the ~/.subversion/config ignore settings.
<adam> so I understand bzr doesn't have the equivalent.
<fullermd> There's the list in ~/.bazaar/ignore that covers yourself
<fullermd> (of course, it actually contains .pyc already...)
<fullermd> But that doesn't do anything for other people, of course.
<adam> fullermd: ah, awesome.
<adam> so yeah, that would basically be the equivalent :)
<adam> hm
<adam> that list exists, and includes .py[co]
<adam> yet for some reason, they aren't being ignored.
<adam> fullermd: oh, I know what happened.
<adam> I did `bzr add *`
<fullermd> Ah, yeah, that would do it   :)
<adam> fullermd: once you did `bzr init` at the root of a source tree you'd like to VC entirely, what would you do then?
<adam> how would you add everything, every nested file and directly, except those in ~/.bazaar/ignore?
<adam> *directory
<fullermd> 'bzr add' by itself.
<adam> ah, hah.
<fullermd> 'add' with no args is what uses the ignore list.  'add' of specific files never does.
<adam> fullermd: that's awesome.
<adam> bzr is so convenient, I'm happy I chose it.
<adam> thanks a bunch.
<fullermd> np  :)
<fullermd> (actually, I think that phrasing is a little off...)
<fullermd> If specific files are named on the 'add' command line (e.g. "bzr add foo.pyc"), ignores have no power.
<fullermd> If they're not ("bzr add", "bzr add somedir/"), then ignores determine which of the found files (add is recursive) get added.
 * adam nods
<fullermd> Guardrails without straitjackets.
<evge> I have bzr branch on test server and want to force something like post commit hook to auto update this branch after each remote commit, so the server is serving up to date content ?
<bob2> there's an update-after-push plugin
<LeoNerd> .oO( Why is that a question? )
<bob2> https://launchpad.net/bzr-push-and-update
<mamatata_> arghh... big emergency here! did a 'bzr add' but wanted to go back to ignore some. without thinking much did a 'bzr revert' now all my changes (lots) are reverted :S anything i can do??
<fullermd> They'll be around in backup files.
<fullermd> whatever.~1~ or the like.
<mamatata_> love you fuller!
<mamatata_> is there a quick way to replace all 26 of them?
<LarstiQ> not from bzr that I know, but with shell scripting, sure
<mamatata_> hmm okay... gotta take a break before i erase all those with a wacky shell script...
<LarstiQ> mamatata_: right, I suggest you cp -a your working tree before you do anything else :)
<LarstiQ> or at the very least your backup files
<olejorgenb> bzr ls simply lists the files in the directory?
<olejorgenb> or have I somehow managed to add all the files
<olejorgenb> if 1 is the case, how to I check what files are versioned? (without pulling to a empty location)
<fullermd> ls --versioned shows which files are versioned.
<olejorgenb> fullermd: thank. (guess that actually was pretty easy to find in the manpage. Sorry)
<olejorgenb> what is the purpose of ls (without --versioned) though?
<fullermd> Well, it lists the files in the tree.  With no options, it's probably not used much.
<fullermd> It's usually used with one of the filters.
<Lani78> I installed Loggerhead using "sudo python setup.py install". It seems to me that loggerhead want to have the loggerhead.conf in "/usr/bin". Is there anyway to have it look for the configuration file in "/etc"?
<Lani78> It also seems that it wants to write a "loggerhead.pid" file in the /usr/bin folder. Is this really advisable? I would like to redirect that file to something like "/var/lib/loggerhead/loggerhead.pid", can that be done as well?
<stefanlsd> does bzr have anything like  gitk ?
<stefanlsd> bzr-gui?
<beuno> stefanlsd, bzr-gtk
<beuno> and qbzr
<stefanlsd> beuno: which would u recommend?
<beuno> stefanlsd, bzr-gtk has more features
<beuno> so bzr-gtk  :)
<stefanlsd> beuno: kk. thanks :)
<nekohayo> hey, could anyone tell what went wrong? http://ecchi.ca:8000/1.png
<beuno> nekohayo, the packs error?
<beuno> it happens sometimes
<nekohayo> beuno: yeah, why? and how do we fix that?
<beuno> you just re-push and it gets fixed
<nekohayo> beuno: are you sure? that error seems to have come up while issuing a "bzr push" command
<beuno> nekohayo, yeap, I'm sure. It's happen to me a few times
<beuno> we haven't quite managed to figure out what causes it
<nekohayo> why does that happen? connection problems?
<nekohayo> hm
<beuno> lifeless, ^
<nekohayo> (well, just curious)
<zbrown> Is there a good way to bzr repo that you can push/pull from with users that don't actually have an account on the machine?
<Lani78> zbrown: If you are still there: I created a bzr account on my server and then access it with ssh and added the users public key to the bzr account.
<zbrown> oh I see
<zbrown> Lani78: thats what I was thinking about doing, just wondered if anyone had other suggestions
<Lani78> The drawback is that all users have the same access rights then.
<Lani78> zbrown: thats the suggestion that I got some weeks back, but I'm fairly new to both linux and bzr, I'm learning bit by bit ;)
<zbrown> hehe
<zbrown> Lani78: ya, my main thing is I have one other collaborator on a project and am just looking for an easy way for us both to have access without giving out another account
<Lani78> zbrown: I think that it would be easy to create an account for that project then, an account that doesn't have a password and that has no shell (/bin/false). And then ask your collaborator for his public ssh key so you can add both yours and his to that user account.
<Lani78> This is manageable for small sites with few users and few projects. But I cannot use this at work, as it is to much administration. At least for me that doesn't know Linux. And access to projects changes daily. So I would love to see some nice administration tool where you easily could give read/write access to specific projects to single developers.
<zbrown> ya
<nekohayo> indeed, it seems that pushing again worked, beuno
<Lani78> But I've understood that the bzr-team have tried to avoid any authentication code. They relay on the Linux or Apache for that.
<zbrown> understandably
<zbrown> I haven't entirely settled on bzr yet either... we'll see
<zbrown> it could also end up as a git repo
<Lani78> zbrown: That made me remember that someone also suggested that you could make your project available through Apache, and have Apache control the access. But I don't know how to do that.
<Kosjer> hi there, i just wanted to ask about the mac osx 10.5 installer binary distribution  why there isnt a 1.6.1 version out yet like with the 10.4 installer version. its still at 1.5.0
<zbrown> ya... I like to avoid apache when I can
<zbrown> Kosjer: different maintainers and the 10.5 one probably hasn't gotten around ot it
<Kosjer> ahhh oki doki
<Kosjer> thx
<uliwitness> Hi.
<uliwitness> Is this the right place to ask about a weird message I'm getting trying to bzr push to a server?
<uliwitness> I get a few "FTP temporary error: 451 (...) Append/Restart not permitted, try again. Retrying." and then "bzr: ERROR: Transport error: FTP temporary error during APPEND (...)" followed by the same 451 append/restart message.
<uliwitness> It worked fine on my old FTP server, but it seems BZR's FTP and my new server don't see eye-to-eye. Is there a way I can diagnose this further?
<ericvw> Am I able to change the committer information for previous revisions if someone's contact info changed?
<Odd_Bloke> ericvw: No, revisions are immutable.
<ericvw> I could do the most recent by uncommit though and then change the commiter name thought, right?
<Odd_Bloke> Yes, provided no-one has branched from you.
<Odd_Bloke> Because you'll be creating a new revision.
<ericvw> Odd_Bloke: thank!
<justdave> if I have a bzr checkout, and it's possibly been locally modified, and I want to update from the repo and overwrite whatever local changes I had, is there a way to do that with a checkout?
<justdave> I had been doing it with "bzr pull --overwrite" before
<lifeless> justdave: is this a valid rephrase: "I want to discard my changes and be up to date" ?
<justdave> but when switching to a different branch at one point, blew away the checkout and checked out again
<justdave> apparently the first one was a clone instead of a checkout and pull doesn't work on a checkout? :)
<justdave> lifeless: yes, that's correct
<lifeless> "bzr update; bzr revert"
<justdave> ok, good enough. :)
<lifeless> pull --overwrite doesn't discard uncommitted local edits, the above will
<lifeless> which is why I rephrased for clarity
<justdave> oh, I think I know what was going on...  because the original one was a clone, "bzr up" just updated locally and didn't actually pull anything from the upstream repo
<justdave> --overwrite just makes pull to an update after updating the local repo doesn't it
<justdave> so since this one is a direct checkout and not a clone, "bzr up" by itself would be equivalent to what I was doing before.
<GaryvdM> Hi - Is it possible to split a file into 2, without losing annotate info?
<lifeless> nearly equivalent
<lifeless> justdave: bzr up will turn local commits into a pending merge, as part of its mission to preserve the svn/cvs 'up && commit' pattern
<lifeless> justdave: which is why the revert command's discard of pending merges is needed to complete the reset
<justdave> in theory there shouldn't be local edits anyway...  using it for a production website
<lifeless> justdave: instead, using revert --forget-merges makes it equivalent to pull --overwrite
<lifeless> GaryvdM: hi, no, not yet.
<GaryvdM> ok
<lifeless> justdave: cool
<justdave> hmm, bzr update doesn't seem to take a tag/revision argument...
<lifeless> there is a patch in the bug tracker
<justdave> maybe that's why we did the pull thing, because it does
<lifeless> if you want a branch that is conceptually able to differ from your trunk, use a branch not a checkout
<justdave> the website always updates to the same tag, so we check in as needed then when it's tested and ready to go live, we move the tag and the website picks it up
<lifeless> IMO anyhow, pull is clearer when managing a mirror
<lifeless> justdave: ah; interesting
<lifeless> justdave: checkouts mirror the branch; if you used a branch rather than a tag it would work
<lifeless> one branch for dev, one for tested
<justdave> I'll continue messing with this in a bit, need to travel, back online when I get there. :) (half hour or so)
<justdave> thanks for the help :)
<lifeless> np
<GaryvdM> If I can see a way to make bzr faster, but it would require adding a parameter to and existing function
<GaryvdM> and I could make the parameter optional
<GaryvdM> would a patch be rejected because it changes an api?
<lifeless> no; see HACKING for a dscription of our api management
<lifeless> is this hypothetical, or do you have an actual case of this?
<GaryvdM> I have a actual case
<lifeless> care to elaborate ?
<GaryvdM> Sure - just give me a sec
<GaryvdM> Ok - in bzrlib/log.py
<GaryvdM> in get_view_revisions and in _filter_revisions_touching_file_id
<GaryvdM> we do parent_map = .... graph.iter_ancestry...
<GaryvdM> This is slow
<GaryvdM> I want to do it once in calculate_view_revisions
<lifeless> ok
<lifeless> a few news
<lifeless> *notes*
<GaryvdM> and pass it as a parameter to get_view_revisions and in _filter_revisions_touching_file_id
<lifeless> firstly, log got a bit rearranged recently
<lifeless> make sure you have the make_log_rev_iterator function in your log.py (if you have bzr.dev you're fine)
<lifeless> hmm, are you saying that both get_view_revisions and _filter_revisions_touching_file_id both call the same underlying api ?
<GaryvdM> I don't have make_log_rev_iterator in log.py
<GaryvdM> Yes - in the versions I have
<GaryvdM> I have revno 3695 of bzr.dev
<lifeless> ok
<lifeless> you should update :P
<lifeless> anyhow, I've checked and ye, its still duplicated, on the same graph object no less
<lifeless> I have
<lifeless> def make_log_rev_iterator
<lifeless> in my log.py
<GaryvdM> I was pulling from lp. Let me pull from the bzr site.
<lifeless> so
<lifeless> looking at this
<lifeless> I think this could be integrated into the filter stack better, but that is separate and not needed to prevent the duplicate work
<lifeless> and I think that this is a good thing to do
<lifeless> as the _filter function is private you don't need to make parameters optional - its not frozen in any way
<GaryvdM> ok
<GaryvdM> Sorry lifeless: where do I find HACKING ?
<lifeless> doc/developers/
<GaryvdM> thanks
<mwhudson> so, what's the story with the transport api and url encoding?
<lifeless> urls in urs out
<lifeless> get_transport is magic
<lifeless> local_abspath gets a local filename
<lifeless> filenames are unicode
<lifeless> urls are octets as per std66
<mwhudson> ok
<mwhudson> this doesn't seem to be covered by the transport_implementation tests
<mwhudson> maybe
 * mwhudson tries to think
<lifeless> should be
<lifeless> test_unicode_paths
<lifeless> test_has
<lifeless> test_list_dir_result_is_url_escaped
<lifeless> etc
<mwhudson> yeah
<mwhudson> i think our transport is a bit funny when you give it unescaped paths
<mwhudson> but actually dtrt when its inputs are properly escaped
 * jml focuses on something else, despite how tempting this discussion is.
<mwhudson> jml: you'll get your chance to think about this when you review the resulting branch :)
<GaryvdM> lifeless: I tried making that change, but it made no difference to the speed. I the graph loading maybe cached?
<GaryvdM> *i
<GaryvdM> *Is
<spiv> Good morning.
#bzr 2009-08-31
<lampliter> hey, hoping bzr+eclipse folks around?
<lampliter> hmm same echo as earlier :-)  fwiw, the docs for bsz-eclipse are seriously out of date.  Eclipse apparently changed the user interface in the plug-ins section
<lampliter> either that or I'm wandering around the wrong part of eclipse.  That's been known to happen before.
<sorakiu> i am developing a website on a contract -- i'm a little fuzzy on gplv2 -- can i put the source in a bazaar repository without opening the source code?  i'm using bzr as-is
<bob2> sure
<bob2> [IANAL] copyright affects derivative works, your website doesn't derivce from bzr
<sorakiu> its only if i make changes to bzr the program or link against it that gplv2 applies, right?
<sorakiu> ahh - thx
<sorakiu> i like it so far -- its cool
<lifeless> bob2: you gotta stop with the I ANAL stuff :P
<lampliter> this a family channel even if we are a tad bzr
<lifeless> I know :)
<lifeless> IANAL stands for I Am Not A Laywer
<lampliter> I just thankful he didn't hut a <heart> after the I
<lampliter> :-)
<bob2> and INAA stands for I Need An Adult
<lifeless> buts its confusion for folk that don't know the abbreviation, and folk that do don't need the warning (IMO) - only laywers need to declare that they aren't giving legal advice.
<lifeless> bob2: lol
<lampliter> I was old when folks started using those abbrevs
<lampliter> <sigh>
<lifeless> :)
<lampliter> so GOMLYPK
<lampliter> get off my lawn you punk kids
<verterok> lampliter: hi
<verterok> lampliter: what's the issue with bzr-eclipse?
<Noldorin> hello.
<Noldorin> does the bzr smart server still not have its own authentication?
<lifeless> that is correct
<lifeless> we recommend that you layer it either over ssh or http if authentication is required,
<Noldorin> lifeless: yeah, that's what i've done at the moment. just makes it a bit of a pain when i want read-only http access
<Noldorin> to the public
<lifeless> Noldorin: Indeed; we should make that better. I'll file a bug.
<Noldorin> cheers :)
<Noldorin> lifeless: how's the 2.0 release coming along btw? i take it this won't get included...
<poolie> spiv, i'll call you in a minute
<spiv> poolie: ok
<igc> poolie: I'll like a call this morning as well please
<poolie> cool, i'll call you after
<igc> poolie: my 'chat' list is long btw - content filtering, migrations, performance, upgrades, website, docs, packaging, GUIs, etc.
<lifeless> Noldorin: no chance
<lifeless> Noldorin: it needs code
<Noldorin> fair enough
<Noldorin> plans for the release going well anyway?
<igc> lifeless: I'd like to submit that doc contents tweak you approved to 2.0
<igc> lifeless: what's the pqm address?
<lifeless> submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> pqm_email = pqm@bazaar-vcs.org
<igc> lifeless: thanks
<lampliter> verterok: sorry, debugging vpm probs with mac
<verterok> lampliter: np
<lampliter> thank you for paying attention to my request for help
<lampliter> okay, the problem is the documentation screen shots are out of sync with the current version of eclipse
<lampliter> I think it's installed properly.  I think I've set up things properly but, I can't figure out how to grab my files from launch pad from eclipse
<verterok> lampliter: Project new --> Bazaar --> Branch as a new Prokect
<verterok> lampliter: sorry, that should be: File --> New --> Project --> Bazaar --> Branch as a new Prokect
<lampliter> I'm using pydev  does that matter?
<verterok> lampliter: or checkout as a new project
<verterok> lampliter: no, it shouldn't
<verterok> lampliter: is your .project and .pydevproject? versioned?
<lampliter> they were originally managed by Emacs and command line bzr but my hands broke worse and I'm trying to put speech recognition macros on top of the eclipse user interface
<lampliter> so, it's making a lot of changes all once
<lampliter> I'm going to be asking the eclipse people a lot of embarrassing accessibility questions in the relative near future.  :-)
<spm> lampliter: given I just had an eclipse bug moved into 'triaged' - 3 years after reporting and providing all desired info - don't hold your breath :-)
<lampliter> hehe well, anyone who uses Python well knows that job is a lot slower.  ;-)
<lampliter> speech recognition error, job/Java
<spm> Oh I dunno... job/java sounds perfectly sane to me ;-)
<lampliter> okay, I have a checkout of my project sitting in my project directory.  Do I want to put my eclipse project in the same place?
<spm> if I understand your meaning correctly; yes. I personally do this and bzr ignore the eclipse files; but I also use cmdline bzr so ymmv
<spm> s/use/vastly prefer/
<lampliter> Understood.  When my hands aren't too bad shape and am working in Linux, I prefer the command line as well.  But when I'm using speech recognition, I am stuck on Windows
<lampliter> so I need to build a hand friendly speech driven environment
<lampliter> so back to my question.  I found I had a copy of my project checked out.  Do I want to just impose the eclipse project environment on top of that or do I want to put the eclipse project in a different location?
<lifeless> 4 bugs to go
<lampliter> it can't cope with spaces in the path names
<lampliter> bzr import Wizard can cope with spaces in the path names such as "my documents".  It fails by stripping off the my and then not letting you move forward without saying anything
<lampliter> I've just spent the past 15 minutes trying to figure out why it couldn't figure out where my project directory was
<lampliter> it's not your fault.  Microsoft was an idiot for allowing spaces in filenames in the first place
<bob2> what is "bzr import Wizard"?
<lampliter> is part of the plug-in for eclipse.  Bazaar Import Wizard
<bob2> oh
<lampliter> oh, I also see part of the cognitive problem.  It says the final location to branch from and then has the browse button when it really should be a repository URL.  I'm sorry, my brain is not working right.  It's been a long day
<lampliter> on the plus side, I got my blood sugar down to 72.  And the fact that I'm channel surfing quite as bad as a sign I should go get something to eat and bring my blood sugar back up a bit
<lampliter> joys of being diabetic and still not fully in control
<poolie> https://bugs.edge.launchpad.net/~ian-clatworthy/+assignedbugs
<lifeless> spiv: is that needing review?
<poolie> Bugs in Bazaar Version Control System <https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&amp;field.importance=Critical&amp;field.status=New&amp;field.status=Incomplete&amp;field.status=Confirmed&amp;field.status=Triaged&amp;field.status=In+Progress&amp;field.status=Fix+Committed> -- igc
<lifeless> I need a teddy bear I think.
<lifeless> spiv: Up for a call? bug 402652
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Triaged] https://launchpad.net/bugs/402652
<lampliter> okay, got a few  more  neurons.  When through and finish the create a project and it failed during the checkout
<lampliter> she says "error while executing checkout object of type 'NoneType' has no len()
<lampliter> I'm guessing something in the authentication/identity area is not set up right
<lifeless> grabbing food
<lifeless> poolie: if you're done with your other calls; you could ring my mobile ;)
 * igc lunch
<lifeless> laksa is just the best thing in the world when one is sniffly
<yek401> so I know you said bzr join --reference isn't supported.. but is it even functional in any of the dev releases?
<TravisD> I am new to bzr (as a warning, mostly). I have a branch on my laptop which i wish to push to a repository on a server I have access to
<lifeless> cool
<lifeless> is it misbehaving, you are just looking for 'getting started' help ?
<TravisD> I issue the command bzr push sftp://..., and I get an error, bzr: ERROR (ignored): GraphIndex(', followed by a long URL, followed by bzr: ERROR: Generic path error: ... unable to rename to ...
<TravisD> (Sorry about breaking that into two messages)
<lifeless> TravisD: that could be a permission issue
<lifeless> what are the last 3 or so path elements in the error?
<lifeless> the bits under 'repository/'
<TravisD> bzr: ERROR (ignored): GraphIndex('sftp://tdick@gpu.srv.ualberta.ca/~/bzr_projects/SameGameSolver/trunk/.bzr/repository/indices/904bda77bfd1ba65ea5e551d8529329d.rix')
<TravisD> bzr: ERROR: Generic path error: '482iwleesvd30gra23ql.pack': Failure: unable to rename to '../packs/904bda77bfd1ba65ea5e551d8529329d.pack')
<TravisD> ]
<TravisD> ahh, sorry about the multiline paste -- was not expecting that
<lifeless> ok
<lifeless> that looks like you are missing write or execute permission on the packs directory
<TravisD> hmm
<TravisD> as a point of interest, in "SameGameSolver", ls -a shows no .bzr directory
<TravisD> should there be one?
<lampliter> from bzr-eclipse -- Executing: checkout lp:akasha C:\Users\esj\workspace\akasha; Error while executing checkout object of type 'NoneType' has no len()
<lifeless> TravisD: yes, otherwise the writes to create the indices and uploads/pack would have failed
<lifeless> TravisD: oh sorry
<lifeless> TravisD: no, there's no need for a repositoriy, use of a separate repository is optional
<lifeless> the .bzr under trunk is an in-place repository for just that branch and should work totally fine
<TravisD> ah, I see
<TravisD> Earlier I issued: bzr init-repo .../SameGameSolver
<TravisD> would that not make the .bzr directory?
<lifeless> yes it would have ;P
<TravisD> I will try it again :)
<TravisD> lifeless, this is from a fresh attempt: http://www.pastebin.org/13543
<TravisD> this time the .bzr is present as expected
<lifeless> TravisD: sorry I'm on a phone call
<TravisD> thats no problem
<TravisD> lifeless, any ideas?
<lifeless> looking now
<TravisD> thanks :) Sorry to be a pester
<lifeless> no bother
<lifeless> was a longish call
<TravisD> haha no problem
<lifeless> TravisD: that does look like some sort of perm error
<lifeless> what ftp server is it, do you know?
<lifeless> also, you don't need the separate 'init' step, just pushing will create a new branch for you
<lifeless> could you please file a bug for us to gather data and debug this?
<TravisD> I don't know the server, unfortunately
<TravisD> is there a way I can check in an ssh session?
<johnjosephbachir> i have foo1/file.txt and foo2/file.txt. i want to apply changes made to foo1/file.txt in r5 to foo2 -- is there a slick way to do this, or do i just generate a diff, and apply it on the commandline with patch
<lifeless> TravisD: ssh -vv host
<TravisD> OpenSSH_4.6, OpenSSL 0.9.7j 04 May 2006
<lifeless> johnjosephbachir: are foo1 and foo2 branches?
<johnjosephbachir> no-- two directories in the same branch
<lifeless> TravisD: ok, no huge surprises there
<lifeless> johnjosephbachir: then just make a diff and apply it
<johnjosephbachir> lifeless: that seems so 2005, but okay. :)
<TravisD> lifeless, could a malformed branch on my system cause this kind of error?
<TravisD> Also, I think I'm using bzr 1.18, if that makes a difference
<TravisD> (Just installed Karmic Koala and got it out of the debian repositories)
<lifeless> TravisD: no, I don't think so
<TravisD> lifeless, drwxr-xr-x  2 tdick  uofa   2.0K Aug 30 21:37 packs <-- this is the permissions on the packs directory in .bzr/repository/
<lifeless> TravisD: on the server?
<TravisD> yep
<lifeless> I dunno.
<lifeless> I need to pop out for a bit; someone else may be able to help, but I really recommend you file a bug
<TravisD> sure, how do I do that? haha
<lifeless> https://launchpad.net/bzr/
<TravisD> alright :) thanks
<lifeless> click on file a bug
<poolie> igc, i might file that bug about getting it into add/remove?
<igc> poolie: sure
<igc> poolie: https://lists.ubuntu.com/archives/bazaar/2009q3/061200.html
<poolie> thanks
<TravisD> bug submitted, fairly comprehensive, I think
<poolie> https://lists.ubuntu.com/archives/bazaar/2009q3/061200.html igc
<igc> poolie: did you mean to post a different link to the one I gave you?
<poolie> i did :)
<poolie> i actually meant bug 421778
<ubottu> Launchpad bug 421778 in bzr "want Bazaar in Add/Remove Applications and the Applications menu in Ubuntu/Debian/etc" [High,Confirmed] https://launchpad.net/bugs/421778
<jml> quick question
<lifeless> boom-tish
<jml> I want to move files from one branch to a related branch
<jml> a non-related branch
<lifeless> do you need to take history?
<jml> lifeless, I'd like to, but only if it's easy to do so
<lifeless> [note that taking history takes /all/ file histories]
<lifeless> jml: does that influence your answer
<jml> lifeless, it does.
<jml> lifeless, I'll just copy the contents and forget history
<lifeless> do you need to take history?
<jml> history is bunk
<lifeless> tada
<vila> hi all
<lifeless> hai
<poolie> lifeless: have you hit bug 421804 ever?
<ubottu> Launchpad bug 421804 in launchpad "launchpad ajax steals focus while loading" [Undecided,New] https://launchpad.net/bugs/421804
<poolie> hello vila
<vila> hmm, my karmic slave won't complete booting... any magic key during boot to get a root shell ?
<lifeless> poolie: it wouldn't surprise
<lifeless> me to find that I have
<lifeless> poolie: on the 2a group combining, I want John's input..
<lifeless> poolie: I've asked for it in the bug, and I'm EODing... 'now'
<poolie> igc, just as feedback "improve documentation bundling" is a poor summary
<poolie> compared to say "split documentation bundles by language"
<lifeless> poolie: I think I have hit it, yes.
<lifeless> the language of the 'This bug affects me too  Edit' message annoys me.
<poolie> it's a bit better now
<lifeless> It doesn't affect my web browser/laptop/launchpad.
<lifeless> its a bit of a philosophical annoyance
<poolie> hi vila
<poolie> how's stuff?
<vila> good, my karmic slave booted finally (I had to threaten it of reinstall, that worked)
<poolie> heh :)
<loxs_wrk> hi, will bzr 2 work with bzr 1 branches?
<lifeless> yes
<lifeless> it will create bzr 2 branches by default
<lifeless> but you can read from bzr 1 branches into a bzr 2 branch
<loxs_wrk> and 1 won't be able to work with bzr 2 branches?
<lifeless> 1.16 and above can
<loxs_wrk> I see, thanks
<lifeless> we will be strongly encouraging people to upgrade
<loxs_wrk> well, people will upgrade when distros upgrade :)
<loxs_wrk> like my distro (gentoo) is already updated
<vila> lifeless: 'selftest is using atext for some strange reason'.... :-D You really don't know ?
<lifeless> vila: no, I don't
<vila> well, because there is no such thing as setUp/tearDown for TestSuite...
<lifeless> stopTestRun
<poolie> yay gentoo
<lifeless> for instance
<lifeless> vila: but separately, why not do it per test
<vila> lifeless: correction: there *was* no such...
<vila> lifeless: I think the rationale was to catch any possible problem in any test (or outside or at the border or... catch'm all...)
<vila> that's the most I can recall from the discussion, I think it was with spiv
<lifeless> vila: right, I'm not saying 'no catcher', just 'per-test' - that makes it cleaner, at the cost of 5 mkdirs
<spiv> I don't recall the specific discussion.
<vila> that helped keep the /tmp dir cleaner too (since we often regressed there and also because ctrl-c'ing tends to avoid the atexit)
<spiv> I can imagine using atexit as a hackish solution to that sort of problem.
<lifeless> vila: Don't feel that I'm attacking you please; I think its a bug that we use atexit, as demonstrated by my bug report.
<vila> spiv: I'm pretty sure you're the one annotate will point its finger at for using it in the first place ;-)
<vila> OOOh, no problem there !
<lifeless> vila: if you agree that we can do better, great. If you think we should stay with atext, lets discuss why ;)
<vila> I agree we should do better, I was just trying to bring the context back
<spiv> vila: quite possibly :)
<vila> I wasn't throwig stones either !
<spiv> vila: it's ok that my memory is poor because we have a vcs to remember stuff for me ;)
<vila> spiv: exactly :)
<spiv> But glancing at the comments on that atexit.register, it does seem to be used because we don't have a good way to know when the TestCaseWithMemoryTransport.TEST_ROOT resource is no longer needed, so atexit is a cheap approximation of what we want.
<spiv> If it were free to create and destroy that directory with every test that wants it then that would solve the problem.
<spiv> As would removing the need for that particular safety net :)
<spiv> (Or if measurement shows that the cost of doing that per test is negligible, let's just do that right now)
<vila> data point: I just deleted ~200 testbzr directories from my /tmp dir
<lifeless> vila: so clearly its not working :P
<vila> I ctrl-c a lot :)
<vila> but that sounds too much
<spiv> Ctrl-C shouldn't prevent atexit from triggering, AIUI.
<spiv> But yes, clearly it is failing to clean up reliably.
<vila> poolie: regarding bug #390502, my jaunty slave is using 2a for ~1 week, I intend to migrate the others today
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [Critical,Confirmed] https://launchpad.net/bugs/390502
<vila> That's not the same as upgrading the lp branches, but stilll a significant test IMHO
<poolie> that's good
<poolie> i'd like to do it soon
 * igc diiner
<igc> dinner
<poolie> vila, i'm going to poke at getting an EC2 for packaging going
<vila> to replace kerguelen you mean ?
<poolie> yes
<poolie> vila, can you point me to any good instructions on how to set up a win32 build environment?
<lifeless> I think sidnei did some
<vila> jam's brain ?
<lifeless> hmmm
<vila> what precisely do you want ? compiler/dev tools setup or just buildbot setup ?
<lifeless> http://www.mail-archive.com/bzr-windows@lists.launchpad.net/msg00058.html
<poolie> the first
<vila> the most recent one I know about is the one robert pointed to ^
<vila> http://bazaar-vcs.org/BzrWin32Installer is the corresponding wiki page
<poolie> oh it's pretty awful
<vila> poolie: yes
<vila> the dream setup should be: 1) install bzr.exe, 2) bzr branch lp:bzr-pimp-my-windev, 3) bzr pimp-my-windev 4)....
<poolie> mm
<lifeless> vila: you could use a config; that can unpack tars and stff too :P
<lifeless> but I think sidnei made it all work via buildout
<vila> lifeless: we're talking about *installing* the tools, not running the installer build
<lifeless> vila: I know
<vila> and yes, 'pimp-my-win' is a plugin that can untar unzip run installers :-D
<vila> and sidnei made an install via buildbot ?
<vila> never heard about it...
<lifeless> he made nightly windows builds
<lifeless> didn't he?
<vila> yes, they have been integrated in the test farm, they currently run on kerguelen
<vila> they rely on kerguelen having all the needed tools already installed
<vila> test farm all green by the way (after the necessary fixes for the  week-end related hiccups)
<lifeless> even win32?
<vila> win32 selftest has been disabled because it (currently) 1) crash with CantCreateThread without reporting the number of failures, 2) run under cygwin (not the primary target)
<lifeless> oh right
<vila> I want a local setup to debug both
<poolie> CantCreateThread because there are too many leaks?
<poolie> :/l
<vila> poolie: That's my best guess yes
<isma_tin> buenos dias a todas/os
<spiv> Hmm, the global _page_cache in chk_map interferes with noticing missing data.
<spiv> It would be less dangerous to cache per-repo rather than globally.  Oh well, I can hack around that...
<lifeless> jelmer: do you use doap?
<thumper> thank you to whoever fixed commit --strict not to complain when I say to commit only one file of several changed \o/
<lifeless> thumper: hmm, 2a? bzr nightly ?
<lifeless> -might be a bug
<thumper> no
<thumper> I mean it
<thumper> if I say a file name
<thumper> don't bitch about the other changed files
<lifeless> I'm not offering a value judgemnet :)
<lifeless> just saying that the change in behaviour may have been an untested case, and that both the old and new behaviour are not necessarily strictly intentional
<lifeless> I'm glad you like what its doing now.
<lifeless> hmmm, I'm writing blog posts that are too long now.
<crisb> anyone around who can help me with an AIX test problem? just need a few pointers.  its #405745
<spiv> crisb: it hangs?
<spiv> crisb: maybe hit SIGQUIT (probably Ctrl-\) and type "bt" and add that to the bug.
<spiv> crisb: it might be interesting also to run just the HTTP tests without the blackbox tests.
<bialix> spiv: ping
<spiv> crisb: e.g. "bzr selftest -s bt.test_http"
<spiv> bialix: pong
<spiv> (Although I need to tear myself away from my laptop soon)
<bialix> spiv: is it known problem with 1.18?
<bialix> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('odict.html-200
<bialix> 90118140732-dye8mko5bfy12t15-2', 'bialix@ukr.net-20090118142612-vk1ob9k8l58oivi8')")
<bialix> got while run command: bzr get lp:bzr-scmproj/0.4.5
<spiv> crisb: (I've added these comments to the bug)
<crisb> spiv:cheers, just giving it a go now
<spiv> bialix: probably bug 354036, looking now.
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<bialix> spie: filed my case as https://bugs.launchpad.net/bzr/+bug/421860
<ubottu> Launchpad bug 421860 in bzr "branch error: Error received from smart server: ('error', "Absent factory for" [Undecided,New]
<bialix> spiv: ^
<spiv> bialix: yes, it's bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<spiv> bialix: the fix script attached to 354036 identifies several missing inventories
<bialix> so it's not fixed?
<spiv> bialix: it is in bzr
<bialix> oh, it's THAT bug again?
<spiv> bialix: but affected branches in launchpad are hard to fix due to the way Launchpad keeps separate copies for where you push to and where other users read from.
<spiv> So the fix script fixes it for users that can write to the branch, but not those that can only read from it.
<bialix> so what I should do?
<lifeless> bialix: run the fix script
<spiv> a) Run the fix script and get a Launchpad admin to delete the mirrored branch and trigger a fresh mirror from the hosted area, or b) delete/rename the branch on Launchpad entirely and repush :(
<lifeless> for a) you could also run the fix script and push something there
<lifeless> or uncommit, then push the original again after it mirrors the uncommit?
<lifeless> spiv: 6
<bialix> on my current PC I have no copy of that branch
<spiv> lifeless: that won't cause the missing inventories to get copied across to the mirrored area AFAIK.
<lifeless> spiv: doesn't matter does it? I thought bzr+ssh read from the main copy...
<spiv> lifeless: if you have write access.
<wgrant> lifeless: Only if you have write access.
<lifeless> oh bah
<lifeless> need a 'fixme' button
<spiv> lifeless: write access == use hosted area, everyone else == mirrored area.
<lifeless> bialix: bzr pull nosmart+ , and it will work
 * spiv makes some noise on the bug.
<lifeless> spiv: in the summary please
<wgrant> Will a tip change not cause the puller to resolve it? Maybe I've previously fixed it with a format change...
<wgrant> (that causes a full remirror)
<lifeless> wgrant: yes, format change does full mirror
<lifeless> tip changes do regular pulls
<bialix> spiv, lifeless: pull from http source does work
<wgrant> lifeless: And a regular pull won't fix it?
<lifeless> no, it won't
<crisb> spiv: have attached the backtraces (both hang)
<bialix> spiv: your script hang on Windows
<bialix> spiv: I told you so many months ago
<spiv> lifeless: done
<spiv> bialix: it's lifeless' script :P
<bialix> then lifeless
<spiv> bialix: I'm not sure why it would, I don't see any obvious portability pitfalls in it.
<lifeless> bialix: does it run into a locking issue?
<bialix> it prints me: missing inventories(...) and then hang
<bialix> lifeless: how can I know this?
<lifeless> bialix: at that point it should be uploading the inventories
<lifeless> bialix: is there any network traffic
<spiv> Are you running it against Launchpad or a local branch?
<bialix> no
<lifeless> bialix: use Process Explorer
<bialix> no network traffic
<bialix> it just hang
<bialix> and it seems it does the job
<bialix> and then hang
<lifeless> very odd
<lifeless> uhm
<spiv> If you're running it against a remote branch then I have no idea unless there's something about open SSH connections causing the process to never die.
<bialix> because on second run I've got: Missing inventories: set([])
<bialix> spiv: I should run it against local? why for?
<bialix> the problem IS with lp: branch
<spiv> bialix: well, I can imagine some scenarios :)
<spiv> bialix: but just checking assumptions
<bialix> yeah, ol win people ar dump?
<spiv> Not at all.
<spiv> If it's local, then the typical locking bugs would have been my first suspect.
<bialix> spiv: I don't understand the problem and your script, so I'm just using instructions from summary
<bialix> it said about bzr+ssh
<bialix> so why I should use it local? my problem with lp only
<spiv> But because it's network, that seems unlikely, so it I guess it's something about the way it uses the network, e.g. maybe somehow there's a non-daemonic thread created by paramiko.
<spiv> The bug can apply to local branches too.
<Raim> hi
<spiv> It's more unusual to have stacked branches locally, but it does happen.
<bialix> spiv: because problem solved I have no desire nor time to dig so deep.
<bialix> spiv, lifeless: thanks
<bialix> but it hang
<spiv> bialix: sure.  I'm happy to help debug a bug report, but "it hangs" with no further info rarely leads to a fix :)
<Raim> what should I do if I want to move a subtree into its own repository? fast-export/import?
<bialix> spiv: I hope it's lat time I've got this error
<bialix> last
<bialix> Bug #421860 marked as duplicate
<ubottu> Launchpad bug 421860 in bzr "branch error: Error received from smart server: ('error', "Absent factory for" [Undecided,New] https://launchpad.net/bugs/421860
<spiv> bialix: I hope so too
<bialix> Raim: only if you want to filter out history
<bialix> spiv: but frankly: what kind of details you'd like to have?
<spiv> vila: 405745 sounds like your territory
<spiv> bialix: to debug the hang?  Where it's hung; and what threads are running.
<bialix> spiv: it's a standalone script, I have no idea how to set BZR_PDB=1 and stop it without KeyboardInterrupt
<spiv> Yeah, that's a pain.
<bialix> wait a sec
<Raim> bialix: no, I want to keep the full history of this subtree. what should I use then? already tried to find something in the wiki...
<spiv> Normally I'd ask for a traceback from SIGBREAK, but some hacking would be necessary.
<bialix> Raim: bzr split then
<spiv> But I guess KeyboardInterrupt would give one.
<bialix> spiv: on Windows there is no SIGBREAK
<spiv> bialix: oh yes there is :)
<lifeless> SIGBREAK will kill it though
<lifeless> what you want is
<lifeless> python -m pdb script.py
<Raim> bialix: thanks, that seems to be what I am looking for!
<lifeless> erm
<lifeless> python -m pdb script.py URL
<bialix> spiv, lifeless: there is indeed 2 threads
<spiv> lifeless: (right, but inside bzr SIGBREAK on win32 does what SIGQUIT does on posix)
<lifeless> spiv: yup; however we're not inside bzr;)
<bialix> lifeless: -m pdb run it in the pdb
<bialix> what's next?
<vila> spiv: ooh, didn't notice the updates on the page, looking at it
<lifeless> run it
<bialix> c?
<lifeless> and hit ctrl-C once it hangs
<spiv> bialix: ok, and I guess thread2.isDaemon() == False ?
<lifeless> that should leave you in pdb
<spiv> bialix: (for future reference, jam and I recently added SIGBREAK support to main bzr, so you can hit Ctrl-Break (IIRC) on windows to get dropped into a pdb prompt)
<spiv> bialix: (unfortuately not helpful for this script)
<bialix> f*** pdb does not understad backslashes
<lifeless> gnight
<bialix> lifeless, spiv: http://pastebin.com/m2ff23706
<bialix> pdb is not much help
<spiv> Interesting.
<bialix> spiv: this does not work on WIndows
<bialix> Ctrl+Break simply stops the script
<vila> spiv: humpf, hang on *server* close !
<spiv> bialix: it stops the script, but not bzr
<bialix> ot does not matter
<bialix> it
<spiv> bialix: try "bzr log lp:bzr", and hit Ctrl-Break
<bialix> it just kill bzr or script
<spiv> bialix: it's a handy trick to have
<bialix> maybe it's  FAR use Ctrl+Break
<spiv> jam definitely tested it :)
<spiv> FAR?
 * bialix trying
<bialix> interesting
<bialix> it works now
<bialix> with log
<spiv> bialix: anyway, with that pdb prompt from the script, please try:
<bialix> but I'm sure in most situation it just kill the process and all
<spiv> import threading
<spiv> pp [t.daemon for t in threading]
<spiv> bialix: yep, in most situations it does, but for bzr we've set it to drop into pdb instead :)
<spiv> (bzrlib.breakin has the magic)
<bialix> *** TypeError: TypeError("'module' object is not iterable",)
<spiv> Oh, oops:
<spiv> pp [t.daemon for t in threading.enumerate()]
<spiv> That's what I get for typing untested code into IRC :(
<bialix> *** AttributeError: AttributeError("'Transport' object has no attribute 'daemon'",)
<spiv> !
<bialix> ?
<spiv> That's a weird error.  I guess pdb isn't very good with list comprehensions.
<spiv> Ok, just "pp threading.enumerate()"
<maxb> bzr: ERROR: Tree transform is malformed [('overwrite', 'new-27', u'branch-format'), ('overwrite', 'new-29', u'branch-lock'), ('overwrite', 'new-34', u'README'), ('overwrite', 'new-9', u'.bzr')]       <---- umm, eek! What is bzr trying to tell me?
<bialix> [<paramiko.Transport at 0x15d4150L (cipher aes128-cbc, 128 bits) (active; 1 open channel(s))>,
<bialix>  <_MainThread(MainThread, started)>]
<spiv> pp threading.enumerate()[0]
<bialix> <paramiko.Transport at 0x15d4150L (cipher aes128-cbc, 128 bits) (active; 1 open channel(s))>
<spiv> pp threading.enumerate()[0].daemon
<bialix> *** AttributeError: AttributeError("'Transport' object has no attribute 'daemon'",)
<spiv> Oh!
<spiv> Huh.
<bialix> yeah
<spiv> pp threading.enumerate()[0].isDaemon()
<spiv> (hope springs eternal)
<bialix> False
<spiv> Ok, it is the paramiko thread, as I speculated.
<bialix> cool
<spiv> I'm not sure why that would be different for the script vs bzr.
<bialix> pdb-over-irc in action!
<spiv> Yeah.  Painful :)
<spiv> But it gets there in the end.
<bialix> I think it should be in Standard Python library
<bialix> spiv: I think bzr does not use threads?
<spiv> Normally not.
<spiv> "bzr serve" does.
<spiv> And dependencies like paramiko sometimes do.
<bialix> so this is difference between script and bzr
<bialix> or not
<bialix> do you want me other testing?
 * bialix bbiab
<spiv> bialix: no, I want dinner :)
<spiv> I can't really see why a script would behave differently to bzr here.
<spiv> Oh, ugh, garbage collection.
<spiv> Normally a __del__ triggers the disconnect method.
 * bialix back
<spiv> I have no idea why the script is *less* likely to allow that to happen.
<spiv> Perhaps "del b" at the end of the script would do it.
<bialix> script does os.exit
<spiv> Or perhaps putting the Branch.open line inside main would.
<spiv> Oh yeah, that's right, the 'bzr' script does do os._exit, which would conveniently sidestep the problem of daemon threads.  Heh.
<spiv> That probably does explain it.
<spiv> Either that, or the fact that the open branch object is a module global in the main script might.
 * bialix trying
<bialix> does not help
<bialix> hang anyway
<spiv> Sheese.
<spiv> Sheesh, rather.
<bialix> after moving b into main() and del b in finally
<bialix> what?
<spiv> Not sure why it's not gc'd.
<spiv> Try "import gc; gc.collect(); print gc.garbage" at the end of the script.
<bialix> non-daemon threads never
<bialix> on windwos
<bialix> AFAIK
<bialix> and in my programs it's always problem
<spiv> There's a __del__ that normally takes care of this thread.
<bialix> so in my multi-threaded programs I'm always force daemon mode
<spiv> Sure, but this thread is supposed to be stopped by the normal garbage collection.
<spiv> (I mean, __del__ is evil and should die, but that's a separate matter...)
<bialix> I dunno
<spiv> (And really, this __del__ could be replaced by a weakref callback, which would be more reliable)
<bialix> spiv: I think I'd better stop here. Enjoy your dinner, I'm going to lunch
<poolie> vila, hi, still here?
<spiv> bialix: ok.  Thanks for digging into this mystery.
<poolie> hi spiv :)
<bialix> I hope it was helpful
<spiv> poolie: hello, goodbye ;)
<spiv> bialix: it was
<bialix> poolie: pretty awful?
<spiv> bialix: it's nice to slowly get closer to understanding mysteries :)
<vila> poolie: yup
<poolie> good night, i'm just trying to catch ... vila
<poolie> bialix: the instructions to set up a win32 build environment seem complicated
<bialix> spiv: thanks
<poolie> that's not the fault of their authors
<bialix> pretty or awful? ;-)
<bialix> heh
 * bialix really wanna lunch
<poolie> vila, see PM
<bialix-lunch> poolie: maybe you don't trust, but I've tried to simplify things
<poolie> heh
<bialix-lunch> though cog must die today
<poolie> hopefully soon we'll have a machine image that people can use to test it
 * bialix-lunch don't think it complicated
<bialix-lunch> :-P
<crisb> spiv: seems to be hanging while doing setattr during close on the socket
<Raim> is there a way to preview the diff of shelved changes?
<Raim> I mean, without applying them
<Raim> I ran into a state where the shelved changes cannot be applied again... "bzr: ERROR: No final name for trans_id 'new-1'"
<vila> crisb: as commented in the bug, the close comes after a shutdown()....
<bialix> Raim: I don't find the way, maybe unshelve --dry-run -v does?
<Raim> bialix: unfortunately not
<bialix> if it's not I'd suggest to file a bug and ensure abentley will see it.
<vila> crisb: still there ?
<crisb> vila: yep sorry, was just trying out some simple python socket stuff to check it was ok
<vila> crisb: great, and the answer is ?
<crisb> vila: cant get it to happen with just a simple listen/accept/shutdown/close program
<vila> right, so close() shouldn't hand after shutdown() sounds like a valid assumption to you ?
<vila> s/hand/hang/
<crisb> vila: yeah, as far as I know its good to do shutdown before close :)
<vila> crisb: so back to my first question: Is that behaviour new or are you trying selftest for the first time under AIX ?
<crisb> vila:think its been that way ever since i've been building bzr on aix..
<vila> crisb: well, I kind of prefer  that :-/
<crisb> vila: however since I started doing my bzr for unix page I wanted to get the selftests working. (i've never had any problems with general usage of bzr on aix - but I dont do much http serving stuff)
<vila> can you re-rerun 'bzr selftest -s bt.test_http -v' and attach  the result to check what tests pass before the hanging one ?
<vila> crisb: You have my strong sympathy for doing that and I hope I can help you succeed in making the full test suite running there
<vila> crisb: keep in mind though that selftest is a very special case when in comes to hanging threads, bzr is normally run as a client XOR a sever
<vila> server
<vila> and there are some gremlins in python related to the socket stack when using multiple threads AND having clients doing weird stuff with servers AND servers trying to kick clients when they do weird stuff :)
<crisb> vila: :)
<crisb> vila: plus the fact that AIX is a great example of 'old IBM' :)
<crisb> ie. hmmm everyone does it like this.....lets do it OUR way
<vila> i.e. it's very unfortunate that *you* can't (yet !) use the test suite to get confidence that stuff works, but this bug... smells just like that
<vila> well, bzr is supposed to shielded by python for those grey areas :D
<crisb> vila: have to admit I've built python too !
<vila> crisb: do you think you used controversial settings ?
<crisb> vila: not really.  few patches for aix weirdness of building shared libraries, but nothing really naughty.
<vila> crisb: do you have ssl support ?
<crisb> vila: i do
<vila> ok
<vila> can you re-rerun 'bzr selftest -s bt.test_http -v' and attach  the result to check what tests pass before the hanging one ?
<vila> attach to the bug for the record I mean
<crisb> vila: done
<vila> rats, all my bets are off so far, I was more or less hoping to see pycurl there :-/
<crisb> :(
<vila> This test does really.... nearly nothing, start the server, stop the server, nobody connects
<crisb> vila: sorry will have to continue later..gf is kicking me out ;)
<vila> crisb: last thing !
<vila> crisb: what you can try is: 'bzr selftest -s bt.test_http --list >all.tests'
<vila> and from there use: 'bzr selftest --load all.tests' deleting all hanging tests as you encounter them....
<vila> that may give us more hints...
<vila> crisb: when you're back :-)
<crisb> vila: aha - will do :)
<vila> crisb: ^
<vila> crisb: thanks !
<maxb> Is there any way to be notified when a pull results in *tags* being transferred?
<maxb> If you "bzr branch -r some_earlier_revision", the new branch will include all tags from the parent, even ones pointing at revisions that it does not have ..... bug?
<garyvdm> Hi jam.
<jam> hi garyvdm
<ctrlsoft> hi garyvdm, jam
<ctrlsoft> jam: thanks for the review!
<garyvdm> Jelmer?
<garyvdm> Hi
<jam> hey jelmer. Surprised to see your other nick
<jam> ctrlsoft: nice to have you back, too :)
<garyvdm> I got qlog using KnownGraph. I did not result in a performance increase. :-)
<jam> garyvdm: well, if you are using stuff like "branch.iter_merge_sorted_revisions()" before, that has already been taught to use KnownGraph under the covers
<ctrlsoft> heh, at the current pace of development it's hard to catch up with even two weeks of changes :-)
<jam> I don't really know what you do directly, versus indirectly
<jam> It also depends on if the bottleneck is in the Qt portions, versus the bzr loading portions.
<garyvdm> jam: .iter_merge_sorted_revisions is a big portion
<garyvdm> about 50% of the load time
<garyvdm> So I am going to peruse just loading the mainline first, and there rest of the graph when the expands a node.
<garyvdm> *when the user..
<garyvdm> And when bzr can store the gdfo, then I will make it only load the bits of the graph needed.
<trondn> why do bzr upgrade leave a backup.bzr directory in my repository ?
<beuno> trondn, in case you need to revert
<beuno> if something breaks, etc
<trondn> well, if bzr upgrade succeeds, why do I want to revert?
<trondn> seems to me that I should create a clone before trying to upgrade if I wanted to revert...
<beuno> trondn, it's a fantastic question
<beuno> I'm an advocate of removing the backup dir once it has upgraded
<beuno> but some developers feel that we may get into a situation where things fail, and the dir gets deleted anyway, leaving you with data loss
<trondn> well I wouldn't try upgrade on my master repository without having a backup first...
<trondn> pretty much the same they tell you to when you upgrade your os ;)
<beuno> yeah, I've been nagging to at least have an --delete-after-upgrade option
<tbradshaw> hello, is it appropriate to ask end-user questions about bzr in here?  Or, perhaps, should all questions be asked on launchpad?
<LarstiQ> tbradshaw: that's appropriate
<tbradshaw> thanks
<tbradshaw> I'm having issues where I'm trying to commit to a svn branch, and it's informing me that my svn version is out of date, when that doesn't appear to be the case:
<tbradshaw> http://pastebin.projects.quakecon.org/65
<tbradshaw> of note, I'm on OSX
<LarstiQ> tbradshaw: is subvertpy compiled against that svn though?
<tbradshaw> Hmmm, good point and likely not
<tbradshaw> I'm pretty sure that I just fetched the OSX latest binaries from the bzr site
<tbradshaw> I'll confirm
<LarstiQ> tbradshaw: so, with an svn working copy, the data structures system svn 1.6 stores may not be readable by subvertpy libsvn 1.5
<LarstiQ> tbradshaw: one option is to bzr branch, commit in that, push
<tbradshaw> Forgive my naivety, I'm a bit new at bzr
<LarstiQ> avoids having to muck with svn working copy formats
<LarstiQ> tbradshaw: np
<tbradshaw> I had attempted to follow the instructions to do just that.
<tbradshaw> these: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-a-central-repository-mirror
<tbradshaw> and I was a bit surprised when a commit immediately triggered a push
<LarstiQ> the commands listed there can't get you in the situation you're in
<tbradshaw> no, I'm wrong
<tbradshaw> I followed my history
<tbradshaw> and I used "checkout" instead
<LarstiQ> tbradshaw: what does `bzr info` say in the branch you tried to commit in?
<LarstiQ> tbradshaw: right, that makes more sense
<tbradshaw> I'll get a fresh branch made and give it another shot
<tbradshaw> thanks for your time LarstiQ, I appreciate it. :)
<LarstiQ> tbradshaw: let me know how things work out :)
<tbradshaw> I will!
<lifeless> moin moin
<lifeless> jam: hi
<lifeless> jam: ping
<tbradshaw> LarstiQ: while I did end up with a different workflow, the core issue didn't resolve
<tbradshaw> it appears that the bzr 1.17 disk image provided for Mac OSX is insufficient for now. :(
<LarstiQ> tbradshaw: hmm
<tbradshaw> LarstiQ: would you be familiar with the differences in the osx disk images?  For instance, would you expect some sort of incompatibility with using an image intended for an older version of OSX?
<tbradshaw> it appears that the 10.4 images are kept very up to date
<tbradshaw> in comparison with 10.5
<tbradshaw> hmmm, I guess those are unstable anyway
<tbradshaw> I'll try reinstalling, just in case it does any rebuilding that could resolve this for me
<LarstiQ> tbradshaw: I'm not really familiar with them, no
<tbradshaw> perhaps I can just rebuild subvertpy
<ronny> sup
<ronny> where is jelmer?
<ctrlsoft> back from vacation as of yesterday!
<ronny> im tring to allocate all the guys from the different svn interaction projects in order to get a single svn history analysis lib that can deal with most of the broken fucked up svn repos out there
<ronny> (kida selfish, i need such a thing for anyvc)
<ronny> and meh, i dont want yet another one, svn is pain enough on its own
<jelmer> can you explain a bit better what you're looking for exactly?
<jelmer> bzr-svn has functionality for this, but it makes assumptions about the sort of history changes that can happen and honors bzr-svn-specific revision/file properties to cope with things that can't be represented in svn natively
<ronny> jelmer: i want something that can view messed up svn histories (unfortunately those exist all over the place) as something semilar to a dvcs dag
<jelmer> ronny: so, subvertpy could take care of some of this but it would need hooks in various places so bzr-svn can still do its magic
<ronny> (and i'd like the possibility to dump enough metadata at svn to make it easyly usable by stuff like hgsubversion and bzrsvn)
<lvh> Hi!
<lvh> I'm using Packs 6 (uses btree indexes, requires bzr 1.9)
<lvh> is updating to 2a a good idea?
<beuno> lvh, yes. Major performance wins, and some space savings as well
<beuno> keep in mind, you'll need to upgrade all your branches
<lvh> Okay. It is in a state that I can expect my repos to not be eaten?
<lvh> Oh.
<beuno> yes it is  :)
<lvh> Well, it's a branch of twisted
<lvh> In that case i need to wait for them to move to 2a
<lvh> beuno: Thanks for the quick answer :-)
<beuno> welcome'
<ronny> lifeless: on a sidenode, for me bzr something is still constantly at least 0.2 seconds slower than hg something (usually 0.4-0.5 vs 0.2-0.3 seconds) when will that be fixed (cause its the difference between noticable to my attention span)
<lifeless> ronny: it'll be 0.1 faster or so if you run with --no-plugins I suspect ;)
<ronny> lifeless: i got tonns of plugins on hg and none of bzr
<lifeless> ronny: how long does 'time bzr --no-plugins info' take
<ronny> real	0m0.843s
<ronny> user	0m0.419s
<ronny> sys	0m0.146s
<ronny> bzr v 1.18, old format branch
<ronny> it takes about 0.1 seconds less outside of a bzr dir
<ronny> hmm
<ronny> it goes down 0.3 after the caches are hot
<lifeless> so how long?
<ronny> real	0m0.550s
<ronny> user	0m0.429s
<ronny> sys	0m0.120s
<ronny> on a small vellum branch
<lifeless> right
<lifeless> thats just info, no -v
<lifeless> ?
<ronny> lifeless: just info
<lifeless> ok
<lifeless> so this is basically your lower bound for bzr on your machine
<ronny> lifeless: its a laptop
<lifeless> now try with 'time bzr --no-plugins info'
<ronny> and no sdd
<lifeless> ronny: its not IO, not once the cache is hot
<ronny> real	0m0.547s
<ronny> user	0m0.381s
<ronny> sys	0m0.143s
<lifeless> info doesn't write
<lifeless> bzr plugins
<lifeless> I bet you have 2 or 3 installed
<ronny> launchpad, netrc_credential_store, qbzr
<lifeless> :)
<zsquareplusc> http://bazaar-vcs.org/Scenarios has some empty pages, like "Share common versioned code (e.g. standard utilities) between multiple projects" is there some other documentation about this?
<lifeless> so, I'd like to make the overhead of loading code lower
<lifeless> but its so far proved fairly resistant to cheap fixes
<lifeless> zsquareplusc: doc.bazaar-vcs.org has a comprehensive user guide
<ronny> lifeless: my lower bounds for hg are around:
<ronny> real	0m0.271s
<ronny> user	0m0.179s
<ronny> sys	0m0.082s
<ronny> lifeless: and thats with with 14 extensions
<lifeless> ronny: yes, hg's code is extremely pithy
<ronny> 'pithy' ?!
<ronny> i quite like it, most of the anyvc stuff for hg was done in fractions of the time i needed for bzr
<jelmer> ronny:
<jelmer>        adj : concise and full of meaning; "welcomed her pithy comments";
<jelmer>              "the peculiarly sardonic and sententious style in which
<jelmer>              Don Luis composed his epigrams"- Hervey Allen [syn: {sententious}]
<ronny> jelmer: ah, thanks
<lifeless> ronny: pithy - small, compact.
<jelmer> ronny: that's mainly dependent on what you're familiar with though, I suspect
<ronny> lifeless: but that quite fits the most important rule 'to be fast, do less'
<ronny> jelmer: well, hg is something i can keep i my head as whole, bzr isn't
<ronny> and that results in a direct massive productivity gain
<jelmer> ronny: I'm working on bzr-hg and for me it's the other way around
<ronny> hg's model is absolutely simple
<ronny> you got a store of revlogs, some represent files, then there is the manifest, and the changelog,
<ronny> one of the thing that might be bugging is stuff like infering directory-renames
<lifeless> ronny: so its bzr's: you have a byte store, files, inventories & commits.
<ronny> i came to the conclusion that cimplex inventories are no real gain
<ronny> they never catch the intresting details
<ronny> cause thats file-level refactorings
<ronny> lifeless: bzr's model is not that appearant from how one codes for it
<jelmer> ronny: where are inventories significantly different from manifests?
<ronny> jelmer: i think the main difference is dont care about directories
<ronny> also there is no inode id maping
<jelmer> ronny: inode id mapping?
<ronny> (god how i hate that path2id stuff on memorytrees)
<ronny> jelmer: another issue with bzr is, all those inheritance tres that distribute meanings across the whole source tree
<ronny> jelmer: btw, whats driving you to do bzr-hg, and whats missing to make a hg-bzr as well?
<jelmer> ronny: being able to "bzr branch hg://foo" and natively push/pull hg repo's
<jelmer> I'm not sure what would be necessary for a hg-bzr
<zsquareplusc> don't you get that for free then? when you can push to empty hg repo you have the conversion?
<zsquareplusc> lifeless: is scrolled through the contents of the user guide but i don't see anything about that topic.
<ronny> jelmer: from the bzr codebase side, is there any diffence to it where the bzr repos are?
<ronny> jelmer: i think the only thing really missing is some quick wraper around hg's localrepo
<zsquareplusc> is there a workflow that helps where svn:externals are used in the other VCS?
<lifeless> zsquareplusc: not currently
<lifeless> zsquareplusc: we haven't finalised our equivalent to externals, they aren't supported today. You can use an external tool, such as config-manager, instead.
<lifeless> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#workflows
<zsquareplusc> but is it possible to to a bzr checkout of one branch within an other? running ci/update etc on the "sub repo" would be to bad
<lifeless> is the workflows stuff you were asking about
<lifeless> you can checkout Foo ; cd foo; checkout bar
<lifeless> that works fine, you just have to commit bar and foo separately
<zsquareplusc> ok :-)
<ronny> jelmer: my ideal goal would be to have n-way integration between all reasonable vcs's on anyvc, but thats pretty much a pipedeam for now
<lifeless> jelmer: hi
<lifeless> jelmer: is bzr-svn supporting concurrent access to the same svn /repo/ ?
<jelmer> lifeless: as much as svn itself is
<lifeless> jelmer: in #twisted, a sqlite3 operationalerror was encountered by exarkun
<jelmer> lifeless: ah
<lifeless> pushing and pulling at the same time to svn
<jelmer> lifeless: using tdb should work around that
<jelmer> ronny: in that regard anyvc provides the same sort of abstraction as bzr does
<ronny> jelmer: i thing bzr's abstractions are layered a bit weird, a vcs shoudl be a vcs first, not a abstraction lib
<poolie> hello jelmer, welcome back
<poolie> hello jam?
<lifeless> morning mr poolie ;)
<jam> hi poolie
<poolie> hi, shall we talk?
<jam> poolie: yeah, can you call the house? I just got the new laptop so not everything is set up yet.
<poolie> sure
<poolie> sorry, sound troubles...
<jam> np
<lifeless> jam: whats the new laptop?
<jam> lenovo t500
<jam> 2.8GHz cpu, 3GB ram, etc
<lifeless> nice
<lifeless> hmm fastexport-hg is kinda slow
<lifeless> about 5revs a sec
<lifeless> jam: when you are around, I want to talk realtime about this
<lifeless> grouping issue
#bzr 2009-09-01
<lifeless> igc: hai
<igc> morning all
<igc> hi lifeless
<poolie> hi igc
<igc> hi poolie, jam
<lifeless> igc: have you used netbeans as a datasource for benching?
<igc> lifeless: no
<lifeless> igc: I ask, because one of the drizzle folk was bemoaning the lack of a bzr scm module
<lifeless> so I pulled the thing... 1.7GB, 90K files
<lifeless> 133K commits
<igc> lifeless: as in an addon for NetBeans?
<lifeless> yeah
<lifeless> their addons are all in tree
<lifeless> _pain_
<igc> lifeless: yuk
<igc> lifeless: it was nice to see qbzr-eclipse 0.7 out overnight
<igc> and I'm pretty sure there's someone working on a C++ Builder/Delphi integration along those same lines
<igc> lifeless: http://bazaar-vcs.org/IDEIntegration/Guide
<igc> lifeless: I'm pretty sure nick put together the original qbzr-eclipse integration in around 2 days
<igc> lifeless: so it's typically easy to get *something* useful going
<igc> lifeless: my main reluctance with doing an integration myself is ongoing ownership - it's better if someone using a given IDE everyday owns it IMO
<lifeless> igc: I agree; I don't really like the different UI that qbzr-* gives though
<ronny> igc: are you Ian Clatworthy?
<igc> roony: yes
<igc> ronny: ^
<ronny> igc: great, well, what do people do that do api-level integration instead of subprocess levle integration :P
<igc> ronny: I'm not sure I understand the question ...
<igc> ronny: you can always call into bzrlib and into qbzr itself if you want
 * ronny is the author of anyvc, a vcs abstraction lib, i just import bzr instead of calling to it
<igc> though the qbzr API has no stability guarantees
<igc> ronny: the point behind using the qbzr applets is to same the engineering time required to design, develop and test 30-40 dialogs
<ronny> igc: well, does it have version metadata, and some more convience tools for common ops than bzrlibs?
<ronny> igc: im not sure if qbzr wil lbe that helpfull for me, as i need the dialogs for other vcs's, too
<igc> ronny: right. Down the track. I'd hope to see qbzr working in combination with bzr-svn, etc. to provide a common GUI over multiple VCSs but it sounds like you're solving a different problem
<ronny> igc: yup, i'll probably have to support the svn integrations anyway at some point
<jelmer> fwiw the combination of qbzr and bzr-svn should already work
<jelmer> John Szakmeister did quite a bit of testing with it and reported bugs
<lifeless> igc: hg fastexport is kinda slow :(
<igc> lifeless: yep
<igc> lifeless: on packs, so it bzr-fast-export; 2a is a much happier place for bulk data export/import
<igc> s/it/is/
<lifeless> yeah
<lifeless> I should hope so :P
<poolie> igc, so i liked your wishlist blog postn
<poolie> but i think we need to distinguish "things that will actually block 2.0" from "things we'd like to do" :-/
<poolie> because that list is pretty incompatible with hitting karmic
<igc> poolie: yep
<poolie> 2.0 is kind of trying to be two different things
<poolie> the release that makes 2a the stable format
<poolie> and the "everything's great and finished" release
<fullermd> It's also trying to be the "Crap, we have to hit karmic" release...
<igc> poolie: no, it's not the later
<igc> poolie: 2.0 is trying to be 2.0
<igc> poolie: that does mean a new format
<igc> poolie: it also means "now's a god time to take another look at Bazaar if you're not using it"
<igc> good
<poolie> sure
<poolie> i guess i'm glad you're raising these things but the week we're trying to freeze the code is a
<poolie> well, maybe not a great time
<poolie> :/
<igc> poolie: that's not totally fair ...
<igc> I've been raising better packaging for weeks and weeks now on multiple email lists
<poolie> that's true
<poolie> -> phone
<flacoste> if I use bzr-svn to merge a svn branch onto the trunk, will svn grok the merge?
<lifeless> jelmer: ^
<flacoste> i was talking with a guy last week at Agile2009 who use git-svn
<flacoste> on windows
<flacoste> he finds it painfully slow
<flacoste> and that was another pain point for him
<flacoste> i want him to have another try at bzr
<flacoste> he try it out last year
<lifeless> bbs fooding
<igc> hi jelmer
<igc> jelmer: I think qbzr is working over bzr-svn
<igc> jlemer: I wonder if we need some tweaks though, e.g. a gui way of doing a dpush" or whatever name we selected for that operation
<igc> jelmer: ^^^
<lifeless> jelmer: ping
<igc> bbiab
<poolie> spiv: hi, late call?
<spiv> poolie: sure
<poolie> will call in 2m
<spiv> Hmm, jam's mail server is bouncing mail.
<rbelem> anyone knows which command in !bzr shows just the changes from a given revision?
<bob2> what is !bzr?
<rbelem> bob2, ops... typo
<rbelem> :D
<fullermd> The logical counterpart of ~bzr
<rbelem> ehehehe
<bob2> bzr diff -c xxx
<rbelem> bob2, that was exactly what I was wanting
<rbelem> thanks a lot!
 * rbelem leaving
 * igc lunch
<andrewks> is there a way to make bzr missing walk up a sequence of branches?
<AfC> up?
<tbradshaw> LarstiQ: a status update:.  After recompiling subvertpy, I was able to get things to commit properly to the svn repo!  Thanks again for your help earlier today.
<andrewks> AfC: transitive relationships.  the parent of the parent branch, etc
<AfC> andrewks: so, to my knowledge, no, that's not built in. But it wouldn't be _that_ hard to [shell] script, especially if you assume that branches are sanely set-up, and that `bzr diff -r ancestor:` does what you want it to in each branch. Or you could parse `bzr info` output. etc
<andrewks> yes, I'm going with sane locations for now.  This isn't something I have to do often
<fullermd> AFAIK it all chains fine, so things like "parent:parent::parent" would DTRT.
<fullermd> Also really screw up your brain trying to read, but hey, you can't have everything...
<fullermd> Or maybe it doesn't 'cuz my brain is screwed up.  It's probably too late for anything I say to be worth listening to today...
<AfC> fullermd: hm. Not so sure about that: `bzr status -r ancestor:ancestor:` just now didn't work
<vila> hi all
<poolie> hi vila
<vila> hey !
<lifeless> https://bugs.launchpad.net/bzr/+bug/422403
<ubottu> Launchpad bug 422403 in bzr "bzr log -v -n 0 | less on drizzle takes ~ 3-4 secs before displaying anything in less" [Undecided,New]
<lifeless> hi vila
<vila> add --forward to that and we should be quite close to the slowest possible context
<lifeless> he runs this all the time
<lifeless> to see what he has pulled
<vila> I think Ian answer makes sense, drop -n0
<vila> drill down only when needed
<vila> that's the only work around I can think of
<poolie> spm: actually maybe we should talk here
<spm> poolie: heh. indeed. just reading now.
<poolie> vila: well, it can be an open bug still
<poolie> let's make sure it's deduped and clear: takes too long to start showing revisions for indented less
<vila> until we are able to calculate revnos lazily, that bug will remain open... lol, fully agree poolie :)
<poolie> sure
<spm> poolie: err. I'm not sure I can do that - I think I fail on the "friendly sysadmin" part???
<poolie> saying it depends on the other bug is ok
<poolie> damn
<poolie> need 3 wise men too
<lifeless> [he didn't tell me he used -0 :P]
<vila> lifeless: they just love to trick us :-)
<poolie> it might be worth drilling into why he's doing this
<poolie> is it that he really wants to see all the history and -n0 is the best way
<spm> poolie: yeah, that looks fairly straight forward. shall I start to make it so?
<poolie> well, i guess you'll still need incremental revnos
<poolie> spm, yes, how about turning off pqm first
<poolie> at least for that branch, or globally
<poolie> and let's make an extra adhoc backup of it, then run check
<spm> globally for bzr, yes. backups is good.
<vila> poolie: we have incremental revnos if we display mainline revisions only :-) We start at the top and decrement, easy.
<vila> s/top/tip/
<poolie> right
<spm> poolie: lifeless: I can't help but feel I'm missing something really obvious here. the master location is (pqm config) /home/pqm/archives/thelove/bzr/2.0 but that's only a 44Kb directory. 1.18 etc are the same. ??
<poolie> spm, that's probably a bzr branch with no working tree
<poolie> what does bzr info show you?
<spm> poolie: it is; would it really be that small tho?
<vila> spm: and a shared repo above it
<spm> right. yes.
<spm> shared repository: /home/pqm/archives/thelove/bzr
<spm>   repository branch: .
<vila> spm: 44Kb now sounds even too much :)
<lifeless> spm: cd to /home/pqm/archives/thelove/bzr
<lifeless> spm: upgrade *that*
<spm> vila: heh. well a sum total of 570Mb is more the ballpark I was expecting.
<lifeless> spm: same as launchpad, shared repo.
<poolie> ok
<poolie> so tar up the whole thing before starting?
<poolie> and then run check in there
<poolie> oh also we should check what version of bzr you're using there
<vila> not sure, it will make a difference when run locally, but upgrading the test slaves, I noticed huge differences in performances between 1.17, 1.18 and 2.1dev, I think 2.0rc1 at least is needed here (or did spiv patch regarding IDS landed in bzr.dev only ?)
<spm> so tarball: ~/archives/thelove/bzr-backup-2.0.tar fwiw
<spm> we have bzr 1.17 locally; I can moderately easy create a special bzr of any version needed?
<poolie> using 2.0rc1 would be good
<poolie> or the ppa nightly
<spm> ppa's is hard. build from source/branch is easy
<spm> amusingly :-)
<vila> lp:bzr/2.0 then
<vila> hmm, wait
<poolie> yes, that'd be good
<lifeless> vila: need 2.0 on launchpad before it will be fast :P
<lifeless> poolie: re conversion performance: this is what spiv and I meant by 'very slow without network deltas'
<lifeless> poolie: its not hanging, its doing millions of little round trips on the VFS
<vila> lifeless: it already makes a difference when pulling from lp
<poolie> lifeless: it's not doing any network io
<poolie> as observed by trace
<lifeless> poolie: oh, thats extremely odd
<poolie> strace*
<vila> poolie: but didn't you have CPU consumed ?
<lifeless> did you try ctrl-\ and inspect?
<poolie> yes, that's the bug i filed
<lifeless> ok
<poolie> now i'm fixing bug 341535 :)
<ubottu> Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Medium,In progress] https://launchpad.net/bugs/341535
<lifeless> looks like a server bug of some sort
<lifeless> hmm
<vila> I didn't comment on the bug, but I had symptoms pretty close to yours (poolie) except my pulls finished...
<vila> spm: so, lp:bzr/2.0 is already a bit more than 2.0rc1, nothing to be worried about I think, but if you keep notes on the upgrade it will be good to note the revno you used
<spm> vila: 'kk
<spm> btw. "Setting ssh/sftp usernames for launchpad.net." how do I stop bzr from doing that? it creates that )(*^)*(&^(%^&%$&*%^$*&%ing authentication.conf file and hence fails to connect. I assume by not using lp:bzr/blah syntax
<vila> err, how do you connect ?
<vila> you use bzr-pqm user right ?
<vila> on lp I mean
<spm> bzr branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0 bzr-2.0 <== works; bzr branch lp:bzr/2.0 bzr-2.0 <== fails
<spiv> Why is the existence of the authentication.conf a problem?  Because it's putting in 'spm' rather than 'bzr-pqm'?
<spm> spiv: tbh, I don't precisely know, but using that lp:bzr breaks it totally. it's bzr-pqm, I'm sudo'd as the pqm user.
<vila> sudo doesn't matter, what is you $HOME ?
<spm> oh that's right - we have aliases "somewhere" that map users keys to branches or somesuch.
<vila> authentication.conf is such a map !
<spm> .ssh/config
<vila> also
<vila> but looked at after :)
<spm> ISTR that the issue is around the *other* accesses that this uid has; all with diff keys
<vila> spm:  what is your $HOME ?
<spm>  /home/pqm
<vila> what is /home/pqm/.bazaar/authentication.conf  content?
<vila> LOL, I never went to https://edge.launchpad.net/~bzr-pqm before :D
<spm> vila: [Launchpad] host = .launchpad.net ;; scheme = ssh ;; user = launchpad-pqm
<vila> so launchpad-pqm should be bzr-pqm ? Oooooooh, that's the problem ! It's used for launchpad and bzr right ?
<spm> vila: launchpad no, but other projects yes.
<spm> sorta.
<vila> spm: and they need that launchpad-pqm identity ?
<spm> heh. they have their own. like bzr-pqm :-)
<spiv> The same PQM instance is used for multiple projects?
<spm> yeha. what spiv said. thanks andrew :-)
<spiv> That seems strange to me, no wonder we're having trouble :)
<vila> haaa, I think I get it, the lp directory service  is the one that create auth.conf, so that explains the difference
<poolie> nice image for pqm :)
<vila> poolie: made me LOL yes :)
<spm> huh. default balleny doesn't have pyrex installed, just the bzr pqm chroot does.
<poolie> vila, so on bugs like the pqm speed one, can we change the description/subject to something reflecting the general bug?
<vila> spm: strictly speaking the lp dir. service is wrong here, it shouldn't create an auth.conf file because... using different users to connect to the same host is not a case that auth.conf can handle (I think(
<vila> poolie: pqm speed bug ? # ?
<poolie> sorry, i meant log speed
<spm> vila: fair enough
<vila> spm: the bad news is that the only work-around I can think of is 1) stop using  lp: shortcuts, 2) always mention user@bazaar.launchpad.net in urls
<spiv> Or set BZR_HOME differently for each pqm 'instance', as a substitute for having different system users.
<spm> vila: heh. 1, we'd kinda figured out, if not enunciated clearly. 2. ?
<spm> spiv: ahhh. that's easily doable I 'spect
<vila> spm: spiv idea is better :)
<vila> spm: same effect: the user is explicit so auth.conf is not injecting a bad one anymore
<spm> vila: spiv is more than just a teddy bear; you heard it here first.
<vila> dropping bear ?
<spm> vila: ah. right.
<spm> vila: so the upgrade/check. /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr revno /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0 ==> 4647
<poolie> seems about right
<poolie> we should try check on it?
<spm> is running atm. just "/.../bzr check"  yes?
<spm> err.. in /home/pqm/archives/thelove/bzr to be more precise
<poolie> right
<poolie> and did you tell pqm to stop processing mails?
<poolie> thanks for doing it today btw, i know it's getting late
<spm> poolie: aye, processing bzr ones at any rate. is cool, I had to work later today anyway.
<vila> we can't 'bzr log' without showing any revnos at all ? Did we lose that or did I dream it ?
<poolie> i don't recall having that
<poolie> it might be useful
<vila> I thought --show-ids was doing that but no
<vila> poolie: I think you should create a 2.1 milestone,
<poolie> good idea
<vila> creating 2.1 release branch may wait though
<poolie> vila, it should be something different, like --no-revnos
<vila> poolie: I agree
<poolie> vila, do you want me in particular to do it?
<poolie> i don't mind, but don't you have access?
<poolie> lifeless: i'm trying a conversion here and getting
<vila> oh no, it was just that I wanted to check with you first (you may have had (sp ?) a reason for not creating it)
<poolie> bzr: ERROR: The file id "mpregen-20070411063203-5x9z7i73add0d6f6-1" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x4372650>.
<vila> poolie: it was also mentioned in https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10854 and really that's a new *series* that should be created :)
<poolie> right, it should be both
<poolie> though, um
<vila> :)
<poolie> actually i'm not sure how this will interact and whether the milestone should be on trunk or on the 2.1 series
<poolie> probably the second, for the final release
<poolie> were you wanting to target something now?
<vila> no
<vila> but someone want, and in principle, since bzr.dev now says 2.1dev, 2.1 should exist
<vila> that's why I repeat the "create milestone" mantra several times in releasing.txt, because that's the one that is the most often forgotten
<vila> but no urgency, just something I wanted to get out of my mind and onto the RM shoulders :)
<vila> (that's the famous: "you can sleep now, that's not *your* problem anymore" joke :)
<poolie> :)
<vila> poolie: bzr-gtk create milestones in the trunk series, I'm not sure that's better, but just have a look at https://edge.launchpad.net/bzr-gtk/+series
<spm> fyi: bzr check still running. just going afk for a bit; will be back in 10.
<poolie> vila, they may not branch for releases?
<poolie> vila, my point about the bug title is: don't mention "1233 revisions" or "on mysql" unless it really is specific to that case
<vila> indeed. I did the last two releases, but I just followed the existing practice. In retrospect, I'm almost sure it wasn't really a conscious decision, just a simplification that lp allowed
<poolie> users always make them specific but i'm sure it's clearer if we make them as general as is appropriate
<poolie> helps with removing dupes etc
<poolie> i'll do a 2.1 series now
<poolie> the little diagram is interesting
<vila> poolie: good point
<vila> yes, that's why I pointed you there
<lifeless> poolie: when did you last check your repo ;)
<jml> lifeless, "Handing over to a machine to do CI is just as expensive as handing to a colleague." -- Handing over to a machine is probably a little cheaper
<vila> it captures the release process amazingly
<lifeless> vila: the other thing forgotten is 'create NEWS headers'
<poolie> lifeless: just now :-O
<jml> (advogato sucks for replies)
<vila> lifeless: I mentioned it in the cover letter
<lifeless> jml: for you, not for the machine :)
<vila> I thought you read it there first, but that's just more telepathy obviously :)
<vila> oh, no *create*, yes, I forgot that, I thought you were referring to NEWS header ordering with overlapping releases
<vila> but both are tied anyway
<lifeless> :P
<poolie> lifeless: i'm just checking it again now in a clean local branch
<jml> lifeless, when you hand off to humans, you almost always have to transfer knowledge. that's less commonly true for machines.
<lifeless> poolie: also are you upgrading with the latest ?
<jml> although there's probably an argument-by-different-definition to be made there
<poolie> yes, trunk as of today
<poolie> i might use 2.0 instead though
<lifeless> jml: How about this: When you hand off to a human, you can stop worrying, but the act of handing costs more. When you hand off to a machine, you know its coming back to you if it fails, so there is some cognitive load.
<lifeless> jml: And I'm asserting that these, while different, are approximately the same
<lifeless> jml: what blog site did you end up using?
<jml> lifeless, I use blogger.
<lifeless> what would you like to see them improve?
<jml> lifeless, I think I'll use wordpress for my next project though.
<lifeless> hosted or self-run?
<jml> lifeless, ease of pasting code samples :)
<lifeless> and why wordpress?
<jml> lifeless, I host my own blogs currently, blogger sftps them to my site
<lifeless> interesting; and does your feedback too?
<lifeless> to your site, or from your site?
<jml> blogger uploads to my site
<lifeless> nice
<jml> I actually have no idea how comments work, but they do work.
<jml> lifeless, wordpress because it seems to have the biggest community and all the blogs I see that look good & use free software seem to use wordpress
<poolie> lifeless: i just reproduced this failure on a fresh branch of bzr from lp into a fresh directory :/
<jml> it's also quite flexible.
<lifeless> poolie: \o/ dogfooding
<lifeless> jml: and you'll self host again?
<jml> how do I get pqm-submit to not care about the fact that I lack a local copy of the branch I want to submit?
<jml> lifeless, probably.
<lifeless> though I understand that for wordpress that means more than it did/does for blogger
<lifeless> jml: patch it
<lifeless> jml: its on my 'do it the next time it annoys me' list.
<vila> jml: what are you submitting then ? pqm-submit is more or less supposed to ensures that *you* are submitting *this*
<jml> vila, I'm submitting a patch on someone else's behalf.
<vila> jml: irrelevant :) In principle you still need to "sign" *this*, where is *this* ?
<lifeless> vila: nah, thats recent
<lifeless> vila: pqm-submit is 'tell pqm what to do'
<lifeless> vila: there is no good reason to prevent clueful use being convenient.
<vila> lifeless: I know, hence my "in principle" and "more or less"
<lifeless> vila: I'm arguing the principle is unclear :)
<lifeless> like the bug on switch. boy that hurt :(
<jml> here's what I want
<vila> We agree :) I'm trying to avoid popularizing a hole I dislike in pqm-submit :-)
<jml> (as a hacker of Launchpad)
<lifeless> a fast test suite
<jml> a way of submitting an approved merge to land, conditional on tests passing
<lifeless> a great user experience
<vila> lifeless: :D
<poolie> i'm posting a reproduction on bug 422423
<ubottu> Launchpad bug 422423 in bzr "NoSuchId error upgrading to 2a" [Critical,Confirmed] https://launchpad.net/bugs/422423
<jml> a way of submitting an approved merge to land
<poolie> it's just a tarball from lp
<jml> lifeless, those too.
<poolie> i have to go out with S now, but i'll come back and look at this
<poolie> spm, we'd probably better not proceed until we get to the bottom of it
<lifeless> jml: please, its pretty obvious; take the code, opportunistically fix it. Use it and submit a merge.
<lifeless> jml: (like I did for removable :P)
<jml> lifeless, suree.
<lifeless> jml: by obvious I mean that the code is small and simple.
<jml> lifeless, yeah, I'll do it the next time I get a chance
<jml> but I don't have any more time to hack this evening
 * igc dinner
<jml> and if I did, I really ought to use it to pack, not hack.
<spm> poolie: ok, at this stage the check actually failed.
<poolie> interesting
<poolie> so
<poolie> we should probably reenable pqm, and not proceed further until we know what's causing this
<spm> https://pastebin.canonical.com/21673/
<spm> oki
<spm> bzr pqm re-enabled
<poolie> thanks
<poolie> i'm going to look at it tomorrow, or at most later tonight
<poolie> spm is that pastebin before it failed??
<poolie> it has no errors
<vila> found error:Internal check failed: revno does not match len(mainline) 1649 != 1674
<spm> I'm not sure how serious an error that is? recommendations to RTFM will be ignored. :-)
<vila> that's a bit strange, and I can't see if it's for 0.8 or 1.8... 1.8 has 3766 revisions in the mainline anyway...
<vila> spm: ok, 0.8 has 1674 revisions so that's the one
<vila> spm: I'm pretty sure reconcile will fix that
<spirov92> I have 2 branches in the same directory, let's say branch1 and branch2, with a similar file structure. Can I copy branch1/lib/some_file.php to branch2/lib/some_file.php using bzr?
<emmajane> ping poolie
<johnf> abentley: will you be doing a 2.0.0 release of bzrtools?
<abentley> johnf: Yes.
<johnf> jelmer: same question for bzr-svn :)
<jelmer> johnf: I'm going to release a bzr-svn matching bzr 2.0, probably bzr-svn 1.0
<jelmer> johnf: not sure yet for bzr-git
<jelmer> has anybody seen james_w recently?
<igc> night all
<CameronP> HI there!
<CameronP> I just installed bzr!
<CameronP> Trying to merge my first lot of changes back to main branch - through tortoise bzr , i cant find a way to merge
<jam> is anyone else seeing launchpad be a bit slow to load today?
<Kobaz> how do you perminantly remove something from a branch
<luks> you can't
<Kobaz> aww, i thought i remember reading something somewhere that you could
<jelmer> you can remove a revision from a *branch* by using "bzr uncommit"
<Kobaz> uncommit only removes from the head it seems
<garyvdm> Kobaz: You can do it, by branching it to a new branch, and deleting the old branch. This won't remove it from other branches that may have the revision.
<Kobaz> k
<Kobaz> so if you like, delete stuff, and then branch?
<Kobaz> or do uncommits, and then branch?
<garyvdm> Hi jelmer
<garyvdm> jelmer: was going to ask if you knew of any code that uses ui.get_username, other than bzr-svn, but I see that bzrlib/config.py uses it.
<garyvdm> do uncommits, and then branch
<lifeless> moin
<lifeless> jam: ping
<jam> morning lifeless
<lifeless> howzitgoing?
<jam> pretty good
<lifeless> jam: so, recompressing
<jam> I'm trying to evaluate real-world effect. but making branching from scratch significantly slower isn't a real gain, IMO
<jam> if it was only incremental, then maybe
<lifeless> Without this we will still fragment
<lifeless> sue to incremental pushes to common repos
<lifeless> s/sue/due/
<jfroy|work> jelmer: wasn't there a way to see the svn revision associated with a particular bzr revision? I can't seem to find that info anywhere.
<lifeless> now, I desire us to have a hybrid, but its not clear to me that we should block 2.0 on having a hybrid
<jam> lifeless: incremental pushes will eventually autopack
<jam> so we won't fragment in the same way that we were
<lifeless> jam: yes, but that argument applies to the prior code too
<lifeless> there were two causes of fragmentation: separate push events, and group filtering
<lifeless> there is currently one cause of combining - pack
<jam> lifeless: sure, though the latter was a much bigger portion of it
<jam> lifeless: well, autopack combines
<lifeless> jam: yes
<jam> so incremental push /pulling has a chance to pack everything but the initial stuff
<lifeless> jam: I'm not classing autopack as fundamentally different
<lifeless> jam: except that the user doesn't /choose/ it
<lifeless> jam: right
<lifeless> so an initial pull of LP, with large amounts of history, is going to take ages before the next auto-complete-pack
<lifeless> but the data that was pulled will be read from many many times
<lifeless> wow! hg fast export has sbeen running for 24 hours now
<lifeless> still not finished
<jam> lifeless: exporting what?
<lifeless> netbeans
<lifeless> 40G stream so far
<lifeless> I was looking at the chance of quick-hack to make an hg plugin for it
<lifeless> sadly way to high a cost to fit in opportunistic coding time
<lifeless> but having done hg branch (1.6G ofdata, 90K files, 133K revs), I figured I may as well get a test case for 2a from it
<jam> lifeless: do you mean a bzr plugin for netbeans ?
<lifeless> yes
 * lifeless adds caffeine
<jam> argh.... with a fresh windows install, I decided to try py26, overall nice, but now pycrypto spewes 2 deprecation warnings everytime I connect via ssh :(
<lifeless> urgh
<lifeless> rmeinds me
<jam> I think there is an open bug about pycrypto and python2.6
<lifeless> I should send the python 2.6 fixes to pyrex upstream
<jam> but they haven't released a new pycrypto yet
<jam> lifeless: the Exception issues?
<lifeless> yeah
<jam> lifeless: I'd rather we switched to cython :)
<lifeless> jam: I want us to reevaluate our external deps
<lifeless> I'd like cython, testresources, testscenarios, subunit, sphinx, all to become hard build deps
<lifeless> We also need to start versioning the output of cython so we can build it on pqm
<lifeless> and elsewhere
<lifeless> have you converted mysql-server into 2a?
<jam> lifeless: not recently, but I did do testing in the past w/ mysql
<lifeless> I'm going to talk focusedly at drizzle today
<lifeless> mtaylor: ^
<beuno> mwhudson, +1 to upgrade loggerhead to 2a?  it's alrady 1.9-rr anyway...
<jam> lifeless: so I think there is distinctly several possible tradeoff points for the balance between recompression on the fly none, some, all. I think unordered + none is a better tradeoff today than all, and we can write a 'some' implementation for the next release.
<mtaylor> lifeless: ola
<jam> lifeless: http://bazaar-vcs.org/Roadmap/BrisbaneCore/Details scroll down to: $ du mysql-5.1-test
<lifeless> mtaylor: drizzle should upgrade to 2a
<jam> mysql 5.1 at that stage went from 501MB => 170MB on disk
<mtaylor> lifeless: it's ready for us to convert all of our branches?
<lvh> apparently so!
<lvh> dash is doing it for twisted
<lvh> and twisted is super important
<jam> lvh: launchpad itself has been using it for a while
<lifeless> mtaylor: the bug you encountered on libcpuinfo is fixed
<mtaylor> ok. cool
<lvh> jam: yeah, apparently my fears of pre-release non-default repo formats eating my data is unfounded
<mtaylor> lifeless: what's the version of bzr that it requires?
<lvh> s/is/are/
<lifeless> 2.0rc1 should be pretty damn solid, even though we have landed more bug fixes since
<lvh> mtaylor: 1.16 or something.
<lifeless> mtaylor: I suggest 2.0rc1
<lvh> mtaylor: it's been around for a few releases
<lvh> 2, I believe
<lifeless> mtaylor: 1.16 and up can read-write it
<lifeless> mtaylor: but there are bugs in those versions that make it desirable to upgrade all the way
<mtaylor> so, I have to get about 50 people to upgrade their bzr ... so I need to be real specific. do I need to have them upgrade to 1.16? or to 2.0rc1?
<lvh> lifeless: if I want to use 2a for my branch I have to wait until the maintainer for the main project updates everything to 2a first, right?
<mwhudson> beuno: sure
<lifeless> lvh: if they are on a rich-root format, you can upgrade early and send bundles
<lifeless> lvh: if they aren't on a rich root format, you have to wait
<lvh> I think they are.
<beuno> Peng_, upgrading LH to 2a
<jam> lifeless: it seems the bazaar wiki will lock you out if you hit Preview too frequently... :(
<lifeless> jam: lol
 * mtaylor now considers whether to upgrade all of our branches to 2a while brian is at burningman
<lifeless> mtaylor: let me get an estimate for drizzle
<jam> and, of course, it doesn't tell you how long the lockout period is, and it warns that submitting too soon may increase the lockout time...
<jam> is it seconds, minutes, an hour?
<jam> argh
<lifeless> #is
<lifeless> 8-way machines <3
<lifeless> hah, conversion error
<mtaylor> heh.
 * mtaylor will wait until that is fixed :)
<beuno> anyone know how to remove a backup.bzr dir from LP?  hitchhiker tracebacks when using rm
 * lifeless reconciles drizzle
<beuno> abentley, ^ any ideas?
<lifeless> beuno: whats the traceback?
<lifeless> beuno: also, I know that lftp works
<mtaylor> beuno: lftp
<abentley> beuno: rmtree.
<beuno> wow
<beuno> that's it, rmtree
<beuno> thanks abentley
<beuno> and lifeless and mtaylor
<abentley> beuno: np
<beuno> we really need to fix this to smoothen upgrades
 * mtaylor AGREES
<abentley> beuno: See also: https://answers.edge.launchpad.net/launchpad/+faq/675
 * mtaylor would sort of love it if there were a button on launchpad that said "upgrade"
<beuno> mtaylor, rockstar had that on his plate for a while
<beuno> I even got a nice icon for him
<beuno> but something... happened
<mtaylor> hewh
 * rockstar looks up
<mtaylor> rockstar: bzr branch upgrade button ftw?
<lifeless> mtaylor: There is a bug. Put it in your wishlist for lp :)
<lifeless> unless you've done one already
<mtaylor> lifeless: prolly have :)
<mtaylor> lifeless: I think around the time I upgraded drizzle to 1.9
<lifeless> mtaylor: there is a thread on lp-users
<lifeless> mtaylor: about 3 wishes for lp
<lifeless> mtaylor: it is to that that I refer
<mtaylor> oh, right
<lifeless> I'm getting 6 GB of ram for this machine today
<lifeless> \o/
<rockstar> mtaylor, so, the work is basically done, except that we need to actually upgrade the branch without blocking your work.
<lifeless> rockstar: really?
<lifeless> rockstar: I would have thought blocking there work was expected
<rockstar> lifeless, you were there when Mark told us we need to.
<rockstar> (it was at lunch at AllHands)
<lifeless> rockstar: oh right. sadness
<rockstar> lifeless, it's not a big deal, and actually an excellent point.  However, then we got other things.  I'm sure we'll get back to it soon after 3.0
<lifeless> rockstar: well if its easy to go great, its obviously better than blocking. OTOH I still think that most projects are so small they wouldn't notice or care
<lifeless> s/to go/to do/
<lifeless> jam: I want to use knowngraph in reconcile/check
<lifeless> jam: can you think of any gotchas?
<rockstar> lifeless, I think the most difficult thing to worry about is the chicken and egg upgrading of stacked branches.
<lifeless> rockstar: we've fixed that upstream
<lifeless> rockstar: bzr upgrade URL_of_stacking_branch just works now
<lifeless> you can't use the branch till thats done - so lp should do a reverse graph walk and fix them up
<rockstar> lifeless, oh, awesome.  I think I have some projects to upgrade then.
<lifeless> use 2.0rc1
<jam> lifeless: I don't know of any specific gotchas, other than you need to have the whole graph, but you should have that for check/reconcile
<lifeless> not because its strictly needed for that
<lifeless> but it has the most fixes
<jam> It doesn't currently expose a way to get the individual parents
<jam> but garyvdm put together a patch for that
<lifeless> bugger :( reconciled drizzle fails to upgrade too.
 * lifeless bugginates
<garyvdm> Hi jam and lifeless
<jam> so garyvdm, was the code you were using already using iter_merge_sort?
<jam> (the code you 'improved' to start using KnownGraph)
<jam> I believe it is Branch.iter_merge_sorted_revisions()
<jam> as if you want to look for a perf improvement, it iter_merge_sorted_revisions was updated to use KnownGraph internally
<garyvdm> jam: let me have a look
<jam> so you may need to compare between versions of bzr, rather than qbzr w/ vs w/o KnownGraph support
<garyvdm> jam: I we were previously using bzrlib.tsort.merge_sort
<garyvdm> Not Branch.iter_merge_sorted_revisions, because we have to handle multiple branches
<jam> ah, ok
<garyvdm> jam: If you are intrested: lp:~garyvdm/qbzr/knowngraph
<garyvdm> jam: I need so time to profile it in detail to see why it is not faster.
<jam> garyvdm: taking a look
<jam> garyvdm: so... the *biggest* improvement you could get is switching to the find_ancestry stuff, which doesn't yet support multiple sources
<jam> merge_sort itself is probably at most a second or so of your runtime
<garyvdm> Jam: I agree
<garyvdm> jam: I also can only initialy load the mainline. That would be a big win.
<jam> garyvdm: you might try something like this: http://paste.ubuntu.com/263407/
<jam> and see if that gets you somewhere nice
<lifeless> hi garyvdm
<lifeless> jam: https://bugs.edge.launchpad.net/bzr/+bug/422849
<ubottu> Launchpad bug 422849 in bzr "InconsistentDelta error upgrading drizzle repo to 2a" [Critical,New]
<jam> lifeless: I don't know anything offhand other than: https://bugs.launchpad.net/bugs/422423
<ubottu> Launchpad bug 422423 in bzr "NoSuchId error upgrading to 2a" [Critical,Confirmed]
<jam> which Martin just reported
<lifeless> I'll track this one down
<lifeless> and see if it fixes martins after that
<lifeless> could be a common cause with different visible effects
<jam> obviously the guess is that there is a problem with the computation of the delta
<lifeless> :)
<lifeless> I'll be getting more conversion timing data
<lifeless> as well
<jam> istr converting mysql took about 2 days on a rather old machine
<lifeless> typo
<lifeless> I meant 'fetch timing'
<lifeless> I will be doing this netbeans repo test conversion
<lifeless> partly to say to the sun folks how great it is :)
<lifeless> and also to see how we do: 1G of 1.7G are manifests.
<emmajane> poolie, morning
<poolie> hello emmajane, lifeless
<lifeless> hi poolie
<lifeless> poolie: 'Slack' is highly entertaining. I think I'm an eve :P
<poolie> hm
<poolie> i don't recall that bit, is that one of the personas?
<lifeless> poolie: yes, the first one
<lifeless> seeks growth & challenge
<lifeless> poolie: so you know, drizzle isn't converting to 2a either
<lifeless> I'm investigating now. It may have a common cause with the error you had yesterday. Or maybe not.
<poolie> because, not yet, or because?
<poolie> oh i see
<lifeless> 'fails to convert'
<poolie> i was going to work today with igc on content filtering
<poolie> anyhow breakfast first
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/422849
<ubottu> Launchpad bug 422849 in bzr "InconsistentDelta error upgrading drizzle repo to 2a" [Critical,New]
<lifeless> Once I know the cause I'll target it etc
<lifeless> still gathering details/assessing
<poolie> hm
<poolie> i tested mysql a little while ago
<poolie> i could retest it, which would narrow the problem to whatever time window that was
<poolie> i was thinking i
<lifeless> drizzle != mysql though, different history
<poolie> ... well i was but i'll tell you later
<poolie> true
<beuno> HPSS calls: 8670 (8668 vfs)
<beuno> \o/
<beuno> (upgrading LH to 2a)
<lifeless> WTB: network upgrade.
<beuno> :)
<beuno> mwhudson, Peng_, lh is on 2a
 * mwhudson runs upgrade locally
<lifeless> mtaylor: drizzle only drops 14MB in 2a
<lifeless> mtaylor: what do you have in there..binaries?
<lifeless> found the bug
<igc> morning
<mtaylor> lifeless: nope. no binaries for us!
<lifeless> spiv: what tests would be the closest ones to the ones you changed in your ids-only-necessary-texts for bug 422849
<ubottu> Launchpad bug 422849 in bzr "InterDifferingSerializer generates InconsistentDelta error upgrading drizzle repo to 2a - adds a file already versioned" [Critical,In progress] https://launchpad.net/bugs/422849
<mtaylor> lifeless: why don't we drop more?
<lifeless> mtaylor: I don't know yet
#bzr 2009-09-02
<lifeless> mtaylor: it may simply be that that is the size of your tree
<lifeless> mtaylor: how big is a drizzle tarball (gz)
<mtaylor> lifeless: 7M
<poolie> hi all
<lifeless> mtaylor: so before its 178 and after its 164
<lifeless> mtaylor: did you perhaps start with all of mysql and *then* delete huge chunks ?
<mtaylor> lifeless: yes.
<lifeless> thats it then
<mtaylor> (not history of course, but yet)
<mtaylor> yes
<lifeless> we can't compress changes to the deleted files, cause they aren't changing :)
<mtaylor> ah, fair enough
<mtaylor> was there ever a plan to do partial branches - like a full branch except perhaps going back only 100 revisions or so?
<lifeless> kindof
<lifeless> we have ~ 1/2 of it done - stacked branches
<lifeless> the other half is disconnecting them and allowing user controlled connect/disconnect
<mtaylor> so that I just just pull the stacked branch without pulling the stacked on branch?
<lifeless> yes. handwaves furiously.
<mtaylor> indeed
<lifeless> how big was a mysql tarball (gz)
<lifeless> mtaylor: ^
<chaosbit> Hi, is there a ticket management system recommended for bazaar?
<lifeless> bzr can integrate with quite a few - we allow you to configure that. However we ship with built in configuration for launchpad
<lifeless> and launchpad knows how to read the data back out of bzr pretty well
<mtaylor> lifeless: 19M
<lifeless> mtaylor: urggle. Ok we should investigate
<lifeless> mtaylor: 1.18 will convert ok. don't convert with 2.0 or bzr.dev at this time. Brrrroken
<lifeless> silently too sometimes.
<mtaylor> lifeless: lovely
<lifeless> yeah
<lifeless> aliases variable
<lifeless> alised
<lifeless> bah. spellink iz broken.
<lifeless> 'aliased'
<lifeless> spiv: ping
<lifeless> beuno: what bzr did you use to upgrade lh ?
<lifeless> beuno: if you used 2.0 or bzr.dev you should redo it with 1.18
<beuno> lifeless, 2.0rc1  :(
<lifeless> bug 422849
<ubottu> Launchpad bug 422849 in bzr "InterDifferingSerializer generates InconsistentDelta error upgrading drizzle repo to 2a - adds a file already versioned" [Critical,In progress] https://launchpad.net/bugs/422849
<beuno> lifeless, and by redo, you mean...?
<lifeless> back out, restore the backup, convert again.
<lifeless> theres a high chance it wrote arbitrary data into your history
<lifeless> and I don't have stats on what % of the time it will catch the error with the inconsistent delta warning.
<beuno> ok, sill do it
<beuno> thanks lifeless
<beuno> dinner now, fix later
<lifeless> beuno: if you converted over the network its ok
<lifeless> beuno: its only if you converted locally that its fail
<poolie> jelmer: hi, still here?
<lvh> hi
<poolie> emmajane: still here?
<beuno> lifeless, ah, I did.
<lifeless> more detail coming up on the list soon.
<emmajane> poolie, barely :)
<poolie> ok :)
<poolie> don't need to hang around on my accoutn
<poolie> if you didn't already do it (i haven't read all my mail) i'm going to forward some screenshots to the list
<poolie> i'd like to continue the discussion there
<emmajane> poolie, I'm making slides explaining square dancing as an analogy for PHP. you're welcome to distract me. :)
<poolie> heh :)
<emmajane> poolie, Oh. the screenshots went to the list this morning. there's been about 10 replies?
<lvh> i dont understand the difference between bzr branch -r -5 . ../next; bzr pull . --overwrite -r -5 and bzr branch -r -5 . ../next; bzr uncommit -r -5 # could anyone please explain?
<lvh> maybe it's just because i havent slept in 24 hours :-D
<poolie> are those two alternative sequences?
<lifeless> lvh: the uncommit leaves the tree changes in your current directory
<emmajane> poolie, the two that I sent? one has the carousel and one is closer to the wireframe.
<lvh> lifeless: Ah, whereas the former will properly pretend I never changed anything?
<poolie> you'll discard your working tree changes as well as the revisions
<lvh> as long as 'discard' means 'move into the new branch' thats what I want :-)
<lvh> but im guessing thats what the bzr branch -r -5 does
<lifeless> lvh: heres a better recipe
<lifeless> bzr branch . ../next
<lifeless> bzr pull . --overwrite -r -5
<lifeless> I have you a buggy recipe before
<lvh> okay
<lvh> thanks :-)
<poolie> lifeless: i wonder if we should remove the downloads for 2.0rc1?
<poolie> well done btw
<lifeless> poolie: that would be a good precautio
<lifeless> n
<lifeless> master: Exporting thorough delta revision 93606/133780 with 140/822/110 added/changed/removed files
<lifeless> still going...
<emmajane> poolie, the wifi keeps dropping me and i'm going to call it a night. please do eemail if I've missed anything.
<spiv> lifeless: pong
<poolie> hello spiv
<poolie> lifeless, tangentially https://bugs.edge.launchpad.net/launchpad-registry/+bug/422902
<ubottu> Launchpad bug 422902 in launchpad-registry "want a way to lock/embargo releases and downloads" [Undecided,New]
<lifeless> spiv: hi; see the list, and my question about tests :)
<thumper> rockstar: how to you create a new pipe and take the uncommitted changes?
 * spiv looks
<spiv> oh, the question about tests is in scrollback, not on the list?
<lifeless> yes
<spiv> Something in per_interrepository I think.
<spiv> I think .test_fetch.test_fetch_parent_inventories_at_stacking_boundary (and similarly test_fetch_parent_inventories_at_stacking_boundary_smart)
<poolie> igc, +1 to you trying to improve the installer
<jelmer> poolie: yep, somewhat
<igc> poolie: I'll be off irc for a while, learning InnoSetup & reviewing how the current installer hangs together
<poolie> it's probably redundant to tell you so but please document or script it so we can reproduce it
<igc> poolie: call me re the content filtering stuff when you want
<poolie> i think a big problem here is that this is complex and manual, and requires building up state on a particular machine
<poolie> unless lifeless wants help with 2a bugs i'm going to do that today
<poolie> ok i will
<poolie> s/that/content filterign
<poolie> spiv, ^^ that's what i had to say
<poolie> how about you?
<igc> poolie: there's 2 patches related to content filtering submitted yesterday for review so starting with those might be good
<igc> poolie: sure, I'll write things up
<igc> bbl
<poolie> kk
<poolie> igc there is a wiki page about it
<poolie> and john said he sent mail to canonical-bazaar recently
<lifeless> poolie: I have an errand to run in crows nest (my memory); leaving for that shortly.
<poolie> k
<poolie> we can do lunch if you want
<poolie> igc, also, i'll leave it up to you where you want to experiment
<poolie> but at some point we need all the dependencies on an ec2 machine
<poolie> so, maybe it would save time to do it now...
<poolie> otoh if you need to experiment it may be easier to do it locally
<poolie> i'll send you the rdesktop command anyhow
<igc> poolie: I just want to make it work locally first
<igc> poolie: I saw the doc re ec2
<poolie> k
<poolie> i have some changes locally
<spiv> poolie: about to ask for reviews for the chk roots-only commit_write_group check;
<poolie> as far as using just a single account etc
<spiv> I'm then going to unshelve the changes I have for testing for all relevant chk keys and work on that, the prototype appears to function.
<poolie> lifeless: is there anything i should do on 2a?
<poolie> i guess primarily, do you think all those failures have the same cause?
<lifeless> poolie: try my patch
<lifeless> poolie: see if it addresses the error you had]
<poolie> good idea :)
<mtaylor> lifeless: wow. I _really_ love silent mode in automake 1.11
<lifeless> mtaylor: :)
<lifeless> poolie: checking it is on my todo but its easy to parallise on
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023
<poolie> sure, that's just the kind of thing i was looking for
<rockstar> thumper, I shelve the changes, add-pipe, and then unshelve.
<thumper> rockstar: ok
<thumper> anyone know why we get UnexpectedStderr: Unexpected standard error from subprocess: warnings.warn("%r was gc'd while locked" % self.repr) ??
<thumper> I think the UnexpectedStderr may be ours (LPs) but I'm not sure
<poolie> hi
<poolie> thumper: i've never heard of UnexpectedStderr
<poolie> but the warning is ours
<poolie> um
<poolie> i thought we got rid of them
<thumper> poolie: the UnexpectedStderr are probably our checking of the bzr process for pulling
<poolie> if it's your code calling into bzrlib you're probably missing a try/finally: thing.unlock()
<mwhudson> thumper: generally those warnings are associated with other branches that failed to pull
<thumper> poolie: we aren't getting it all the time, just a few times
<poolie> mm
<mwhudson> for a while, all loom branches did that, but i think that's fixed
<poolie> so i'd speculate that either in the puller code or bzr
<poolie> something is unlocked normally but not after an exception
<lifeless> poolie: did it fix your issue
<lifeless> ?
<lifeless> <gone/>
<poolie> lifeless: that seems to have fixed it
<spm> poolie: recognising this is a bit of a "how long is a piece of string?", are we expecting to try again on the bzr upgrade to 2a today? Is cool either way, just wanting to get an idea on timing etc.
<poolie> spiv, what do you think of http://sourcefrog.net/tmp/20090901-341535-eintr.diff
<poolie> spm, if lifeless's patch, which i'm testing now, lands
<poolie> and it's the top priority
<poolie> that should unblock us redoing the upgrade
<spm> excellent!
<poolie> to find the next bug :)
<poolie> or not
<spm> ha
<spiv> poolie: wow, that seems a bit extreme somehow.  But it's probably correct.
<spiv> Assuming it does actually work when you test it manually :)
<poolie> it does
<poolie> see https://bugs.edge.launchpad.net/bzr/+bug/341535
<ubottu> Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Medium,In progress]
<poolie> where i also say i'm on the verge of making a decorator object that wraps these methods
<poolie> do you know of one?
<poolie> that would also make it more testable, though
<poolie> :/ it's one of those things where unit testing it does not give great assurance that it actually works
<poolie> spiv, what do you think?
<poolie> if i make a class i just need to make sure it's used everywhere
<poolie> i guess it can be stuck into the constructors fairly easily
<ricardo_br> hi people! I'm using version 1.6.1, is there any command that I can see the files that changed between the revisons x..y?
<spiv> Hmm, I'm torn.
<spiv> Decorating the socket/pipe/etc object is probably cleaner, but on the other hand your patch is nice and straightforward.
<bob2> ricardo_br: bzr diff -r x..y | diffstat?
<poolie> or 'bzr status -r x..y'
<bob2> oh, neat
<poolie> spiv, if i thought there would be more cases then i'd do the object
<poolie> ricardo_br: you might like to upgrade though, that's a bit old now
<poolie> is that the package in a distro?
<spiv> If the underlying objects weren't private to the SmartMedium classes, that would be a pretty strong case for decorating.
<spiv> poolie: right.
<poolie> it's true it's more than 3 cases, strictly speaking
<poolie> maybe i'll propose just this for now
<spiv> poolie: So, I'm happy with the patch as is.  If you feel like writing the decorator I'm happy to look at that page too :)
<spiv> But it's not a big deal to postpone that refactoring indefinitely.
<ricardo_br> poolie: I think I've installed it through ubuntu apt-get install
<ricardo_br> I've changed one file in the rev 61 and another file in the rev 62, when I run "bzr diff -r61..62" I can see only the changes in the file in rev 62
<poolie> ricardo_br: you'll need -r61..63 then
<poolie> sorry
<poolie> -r 60..62
<poolie> the previous one is "the changes from 61 to 62"
<poolie> spiv, <https://code.edge.launchpad.net/~mbp/bzr/341535-eintr/+merge/11029> but it's not urgent
<ricardo_br> poolie: thanks! it worked. Just another question, can I see only the file names?
<poolie> rather than what happened to them?
<poolie> um
<poolie> not super easily, but you could use a shell script
<poolie> btw newer versions for ubuntu are in https://launchpad.net/~bzr/+archive
<poolie> spm btw the patch i referred to above is https://code.edge.launchpad.net/~lifeless/bzr/bug-422849/+merge/11023 and bug 422849
<ubottu> Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849
<ricardo_br> thanks for the tips poolie and bob2, I'll checkout the new versions
<poolie> just fyi; we'll ping you when we get closer
<spm> poolie: did you mean me? or andrew? I assume the latter.
<poolie> no, you
<poolie> that's the one that's blocking the upgrade
<poolie> you don't need to do anything with it
<poolie> just in case you were wondering
<spm> ah, right. wit hthe plot now.
<johnf1> What is the mailing list and bundle-buggy still the best for patches or merge request in launchpad?
<jam> johnf: best is merge request
<johnf> jam: and a separate branch per feature/bug fix?
<jam> johnf: generally
<jml> hey
<jam> hey jml
<jml> if I wanted to do a patch _right now_ to stop Bazaar from treating directory removal as a conflict when the directory contains pyc files, how should I go about it?
<jam> anyway, off to bed for me
<jml> jam: g'night
<AfC1> jml: doesn't .bzringore *.pyc mean that that problem goes away?
<AfC1> bah
<jml> hmm. does it?
 * jml tries science
<mwhudson> AfC: no
<mwhudson> it's the old "junk vs deliberately unversioned" chestnut
<AfC> jml: I think fondly of science. Especially mixing the chemicals together and making them go phoof!
<jml> but it's irritating me enough to do something about it.
<jml> there, I just empirically verified that mwhudson is right.
<jml> AfC, well, in these enlightened times chemicals are entitled to do whatever they want in the privacy of their own home.
<jml> ok, so git really is quite fast.
<johnf> is there a way to create a branch of bzr inside launchpad without having to branch to my laptop and then push?
<spiv> Well, you could do "bzr branch lp:bzr lp:~johnf/bzr/foo", but that still goes via your laptop...
<spiv> If you already have bzr on your laptop, it shouldn't be very expensive to do that push, though, because the branch will be stacked on lp:bzr.
<johnf> spiv  as in 200MB traffic needs to go both ways or does everything happen on the server end?
<johnf> ahh it's the stacking that I don't have
<spiv> (and even in the lp:bzr -> lp:~johnf/bzr/foo it should still stack, although I can imagine it would fall a fair way short of being full efficient as that case hasn't been tested much)
<spiv> You don't?  Stacking should be automatic when you push to Launchpad, unless your local copy of bzr is in an old format?
<johnf> yeah just realised my bzr.dev wasn't off launchad
<johnf> fixing that now
<johnf> so if I branch from lp. then branch again on disk and then push to lp will everything remain stacked?
<vila> hi all
<spm> hey vila
<poolie> hi spm, vila
<poolie> spm, it looks like that patch will work but other stuff came up and we're not likely to attempt the upgrade today
<poolie> we'll probably merge it and may try it tomorrow
<spm> fair enough, shame in a way :-/
<poolie> jml, still around?
<jml> poolie, yep
<poolie> quick call?
<jml> poolie, sure.
<jml> skype or pots is fine by me
<poolie> let's see if skype will play
<lifeless> bug 422849 is in pqm for 2.0
<ubottu> Launchpad bug 422849 in bzr "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,In progress] https://launchpad.net/bugs/422849
<vila> lifeless: trivial enough to land without review ? I ask because I read the related mails first thing this morning (before hitting enter on 'bzr upgrade', pfew, lucky me) and couldn't find the merge proposal...
<vila> and didn't notice the linked branch until now :-/
<vila> lifeless: right, so the patch is indeed trivial and was in the bug comments, good
<vila> lifeless: yet.... fixing a critical bug without adding test[s]... :-/
<lifeless> vila: it was reviewed :)
<vila> ok
<lifeless> vila: I want tests; I'm not done on the bug. If you felt like writing some test during your day that would rock; otherwise I hope to get something that triggers it cleanly etc tomorrow.
<vila> Ha great
<lifeless> vila: missing tests shouldn't prevent us fixing a problem!
<vila> sure
<vila> obviously I missed some discussion, no worries, just catching up
<vila> happy to see we agree on all fronts :)
<vila> and above all thanks for fixing it since, well, I *was* about to upgrade locally :)
<lifeless> my pleasure :)
<vila> that close: ''
<lifeless> poolie: spm: I think we should wait for bzr.dev nightlies to have this fix before executing on 2a for bzr.dev
<lifeless> Doing otherwise will make it harder for people to be sure they can upgrade cleanly themselves.
<lifeless> vila: your test spike looked interesting
<vila> lifeless, spm: exactly why I asked to keep notes about what version was used to upgrade. (And I don't pretend my crystal ball warned me, it was just,,, well, prophylactic acting)
<lifeless> vila: I look forward to seeing it in action.
<vila> shell-like you mean >
<vila> shell-like you mean ?
<lifeless> vila: I'm hoping that it will be able to be totally simulated in memory :)
<lifeless> yes
<vila> Many threads are converging in the right direction I think, I like jam ideas about MemoryTree and branch builder, I really think we should upgrade them
<lifeless> so do I
<lifeless> I think we should build our testing safety net safety net first
<vila> I mean, add the missing features to MemoryTree and branch builder so they can be used more broadly
<lifeless> I see the most important things being some additional glue and reporting
<lifeless> so we can answer questions like 'how important is this test', or 'these tests'
<lifeless> 'if I delete this test, what coverage do I remove'
<vila> oh yes...
<lifeless> and 'what tests add no coverage today?
<lifeless> '
<vila> an important milestone to reach is to know that all code is covered (even if only once), I have no idea where we are today
<lifeless> now, we'll need to think about the answers to those questions, but I think you'll agree that they are very interesting questions
<vila> ooooh yes
<lifeless> andrew wrote a coverage plugin
<lifeless> and there are some coverage analysis tools in the python testing community
<lifeless> At the risk of sidetracking you :)
<vila> we have a --coverage option, I need to use it more :)
<vila> well, not only me :)
<lifeless> --coverage is the plugin
<lifeless> I think
<vila> nah, bzr help global-options
<vila> available in every good bzr :)
<lifeless> ah no
<lifeless> needs to be per test
<lifeless> or you can't answer those questions
<lifeless> figleaf sections can do it
<lifeless> or per test decorators
<lifeless> with only a moderate failure mode for tests of lsprof
<vila> so, to run test in isolation I use selftest-by-n.py: http://paste.ubuntu.com/263626/
<vila> ./bzr selftest --list >all-tests
<vila> selftest-by-n.py --starting-with --in-tmp --number 1 all-tests
<vila> I didn't play with it for months but ran it again last time we discussed about that, I need to analyse a bit more, but I already have some leaks identified (the meacs-bzr-send.xxx.el in /tmp for one)
<vila> s/meacs/emacs/
<vila> and the bzr-limbo ones !
<lifeless> pastebin.com/f600ce040
<lifeless> thats much/most of my sketch
<lifeless> enjoy
<vila> :-D
<lifeless> It needs:
<spiv> Yeah, the existing --coverage is pretty basic.
<lifeless> better data mode
<lifeless> and thats about it
<spiv> per-test collection/reporting would be neat.
<lifeless> the better model I think would be best to try next is:
<vila> lifeless, spiv: My gut feeling is that trying to de-tangle coverage data is... NP-complete, I'd rather generate coverage data for each test in isolation and work hard to avoid redoing it uselessly
<lifeless> file_line:file_line_id  file_line_id:testid_id  testid_id
<lifeless> vila: I agree; thats what my plugin does
<vila> oh
<vila> but then you don't need to go down to lines, you can just keep 'test -> modules+'
<lifeless> spiv: --lsprof-tests gives you stome per test stuff today; no consistent reporting
<vila> stome ?
<lifeless> some
<vila> ha.
<NEBAP|work> can someone point em to technical information about the default file format that is used by bazaar? I just want to create a little reader application ..
<NEBAP|work> s/em/me
<poolie> look at the developer notes in doc.bazaar-vcs.org
<poolie> vila, i might sign off soon
<lifeless> vila: per line gives you per function when combined with diff
<poolie> is there anything you want to talk about?
<lifeless> vila: which gives you 'run the tests for this change'
<vila> lifeless: If it works, great ! My fear is that it's trickier to get right than just: run these tests because one of their associated module has changed
<vila> poolie: nothing in particular, I think I've got enough feedback on shell-like tests to make a more concrete proposal (without putting too much features yet anyway, mostly doc, look at doctest matching and some polish)
<vila> Overall, the intent is to have something that you can copu/paste your shell session, lightly edit it and a get a runnable test
<lifeless> vila: the function matching code is done and working
<vila> s/copu/copy/
<lifeless> vila: its just an efficient index that is needed
<vila> lifeless: That's how I understood it
<vila> lifeless: err wrong context :)
<vila> I thought you were talking about doctests :)
<lifeless> nooo
<lifeless> 31K revisions of netbeans to go
<poolie> vila, cool, i was happy to see that posted
<igc> poolie: vila: well done on your progress on the 'shell test' stuff
<vila> poolie: I thought so :-) The trigger was when you said: 'could be used for merge resolution tests' to which I nearly replied 'Will you stop reading my mind ! '
<igc> vila: I'm yet to look at it but it's very much along the lines of what I've been dreaming of
<vila> igc: not for you ! You're testing at far too high levels already :-P
<igc> vila: I'm sure when it's ready it will help casual contributors write more tests more easily
<poolie> igc, something nontechnical came up today so i didn't do anything on filtering :-(
<poolie> sorry
<poolie> maybe tomorrow
<igc> vila: :-)
<igc> poolie: np
 * igc dinner
<poolie> good idea
<vila> igc: yup, casual contributors is definitely the target
<NEBAP|work> only thing I found is http://doc.bazaar-vcs.org/latest/developers/packrepo.html which didnÂ´t help enough ..
<NEBAP|work> are there no more detailed docs about the file system?
<NEBAP|work> or is there already a php script that is able to read bazaar branches?
<lifeless> NEBAP|work: I believe folk have written php code to call out to bzr
<lifeless> NEBAP|work: I wouldn't recommend reimplementing the disk format: there is a chunk of code and logic there, its neither small nor simple
<NEBAP|work> lifeless: yeah
<NEBAP|work> lifeless: I just want to enable my page to read the format to easily implement some "open source" code viewing ..
<NEBAP|work> and I didnÂ´t find any implementations in php
<lifeless> bug fix -> bzr.dev
<vila> lifeless: you may want to review the patch I'm preparing about the leaks to see why you didn't catch these ones (that's for tomorrow)
<lifeless> vila: I haven't written code to catch os calls yet
<vila> lifeless: at least I *think* you didn't catch them, but since your related patch hasn't landed yet(
<lifeless> vila: like subprocess :P
<lifeless> vila: I haven't had time to progress that spike for a few days
<lifeless> vila: feel free!
<vila> :-)
<vila> not sure the ones I'm catching are in the scope, so far that's tmp files created explicitly but not cleaned up
<lifeless> seriously though, I think the next step is more protection and or coverage
<lifeless> after that run-changed-code
<lifeless> then back to isolation
<lifeless> vila: my plan there is: hook into file() and open() and unlink()
<lifeless> + rename
<lifeless> a create file attempt outside TEST_ROOT and /tmp is an error
<lifeless> ditto read
<lifeless> a create file / dir in /tmp that isn't later cleaned up is an error
<vila> TMPDIR not /tmp, just in case :)
<lifeless> clean up can be mv into TEST_ROOT
<lifeless> or mv and delete within TMPDIR
<vila> "isn't later cleaned up" is the tricky one since you can't trap it early, you can only whine at tearDown time
<vila> lifeless: but that should work and be quite pleasant, I wonder if I should leave these leaks to server as easy preys...
<vila> s/server/serve/
<vila> well, they are there already, they can be fixed but not merged where they are needed.
<NEBAP|work> there is no php script that is able to read a bazaar branch, the only thing I found is one that executes some shell calls to bazaar, which wonÂ´t work on most servers ..
<NEBAP|work> but I found out that some other guys also are searching for a php script to read their branches ^^
<NEBAP|work> so
<lifeless> NEBAP|work: I would estimate 3-4 weeks solid work to reliably read the data format, including race conditions etc.
<NEBAP|work> ^^
<lifeless> NEBAP|work: If you are up for that, well great.
<NEBAP|work> hmm
<NEBAP|work> otherwise maybe no one will start
<lifeless> Start a project; study the bzr code, and when the code is ambiguous, we can provide more insight.
<NEBAP|work> ok
<lifeless> But! I think its much better off using e.g. bzr's xmlrpc server
<lifeless> or shelling out
<lifeless> than reimplementing.
<NEBAP|work> hmm
<NEBAP|work> the problem is that most php server doesnÂ´t allow system calls
<NEBAP|work> s/server/servers
<NEBAP|work> so
<lifeless> NEBAP|work: you'll need C to read the file content anyway
<NEBAP|work> really?
<NEBAP|work> why?
<lifeless> compression logic is slow in high level languages
<lifeless> and bzr data is very very tightly compressed
<NEBAP|work> hmm
<NEBAP|work> that might be a problem
<NEBAP|work> for me it will only work if I just use php
<NEBAP|work> so
<lifeless> can you just export the files you want from bzr
<lifeless> e.g. using bzr uplaod
<NEBAP|work> there is no detailed documentation of the file format?
<NEBAP|work> yes
<NEBAP|work> thought of that
<NEBAP|work> but uploading some php files (sources) will end up with problems maybe
<NEBAP|work> and it would be really cool to push a new rev and be able to read the branch using php
<lifeless> there are detailed docs of various layers, many of which are part of the source
<lifeless> e.g. pydoc bzrlib.bzrdir
<lifeless> will tell you about the bootstrap files
<lifeless> there isn't an 'implementors guide'
<NEBAP|work> k
<NEBAP|work> so
<lifeless> you *will* have to read through and understand the code in bzrdir, repository, repofmt/*{or the formats you want to understand}, branch, versionedfiles, tree, revisiontree
<NEBAP|work> IÂ´ll start by checking the bazaar sources
<lifeless> inventory
<lifeless> and maybe more
<NEBAP|work> thanks
<NEBAP|work> that will give me a starting point :)
<lifeless> good luck
<NEBAP|work> thank you :)
<jelmer> james_w: hi!
<james_w> hey jelmer
<james_w> how's it going?
<vila> hey james_w jelmer  :)
<vila> jelmer: welcome back !
<james_w> hey vila
<jelmer> Hi Vincent!
<jelmer> james_w: I saw you committed bzr 1.18 in the bzr branch - did you find somebody to sponsor for Debian yet?
<james_w> I didn't
<jelmer> james_w: Ok, I'll have a look at uploading then
<james_w> I need to fix bzrtools
<james_w> and you may want to confirm what I did with bzr-svn
<vila> jelmer: I built packages for bzr-gtk but I didn't know how you proceed for debian, keep me in the loop when/if you need to update the related branches
<james_w> there's bzr-gtk and loggerhead as well, but I don't think they are version locked
 * jelmer nods
<vila> james_w: bzr-gtk is version "locked" on the bzrlib API, so it's ok for bzr-2.0
<vila> since the API didn't change
<NEBAP|work> lifeless: which is the default format? knitrepo or pack_repo?
<vila> NEBAP|work: groupcompress_repo
<vila> NEBAP|work: at least it will as soon as 2.0 is out
<NEBAP|work> ah ok
<jelmer> what's the plan for 2.0 exactly? Just those two blocker bugs?
<NEBAP|work> how long will that take? IÂ´ve seen there is much traffic in the 2.0 branch ^^
<vila> AIUI 2.0rc2 should be a couple of days away
<NEBAP|work> cool
<vila> lifeless: fix landed in 4.666, that was really an evil bug :-D
<lifeless> yes
<lifeless> aliasing
<lifeless> it would be nice if python had a 'final' facility.
<lifeless> like C/C++ const | java final | most any functional language
<bob2> or a pyflakes check
<lifeless> bob2: can't catch all the evil I can do
<bob2> nothing can
<lifeless> bob2: but yes it could help
<lifeless> SA isn't a common python idiom though
<lifeless> so it would need to be brought in gradually.
<lifeless> james_w: ping
<james_w> hi lifeless
<lifeless> did you see my WARNING mail to bazaar@
<lifeless> if not, go read it :P
<lifeless> I'd like to ensure that the bzr nightly builds have that patch in them, asap.
<lifeless> IIRC you coordinate those?
<james_w> yeah
<james_w> when was the bug introduced?
<lifeless> 24th or so, IIRC
<james_w> and the easiest way to do that is to get it in to trunk
<lifeless> the patch is in trunk
<james_w> the nightlies aren't affected then
<james_w> then the nightlies pick it up
<james_w> or is that "run them now please"?
<lifeless> james_w: you haven't been building for a week?
<lifeless> james_w: its 'run them now please, and shepard them through'
<james_w> no
<james_w> ok
<lifeless> I'm sure they would build normally anyhow
<lifeless> just want personal assurance that it succeeds, as this is a blocker for doing the bzr upgrade to 2a
<james_w> sure
<lifeless> thanks hugely
<lifeless> if there is a problem, can you mail poolie and I
<james_w> they are not fully automated yet
<james_w> sure
<lifeless> and I'll fix my tomorrow am, hopefully in time to catch you or [can anyone fix things if it breaks] ?
<james_w> I don't want to automate them on my end without making the tools to do so available to everyone
<james_w> anyone can upload to the nightly ppa that is a memeber of the team
<james_w> I forget who that is now
<james_w> you, John, Martin
<lifeless> ok cool
<lifeless> anyhow, it passed PQM
<james_w> they are running now fwiw
<lifeless> I'm sure there will be no difficulty
<lifeless> thanks!
<lifeless> I'm past EOD myself, so I'm now going to forget about this until after-sleep
<james_w> sure
<james_w> go sleep
<james_w> jelmer: bzrtools fixed on bzr.debian.org so available when you want to upload 1.18
<james_w> hmm, not in bzr.dev yet
<james_w> ah, not on LP yet
<CameronP_> Hi there i was wondering if I could get some advice on repository layouts..
<lifeless> jelmer: so you use doap?
<jelmer> james_w: thanks!
<jelmer> lifeless: yeah, occasionally
<jelmer> lifeless: I try to keep my doap files up to date, but I don't always use doap yet where I want to.
<lifeless> jelmer: you might like to reply to my doap-interest post
<jelmer> mainly because the tools are incomplete
<jelmer> lifeless: I'll have a look
<lifeless> without dependencies its hard to write useful tools beyond toys IMO
<lifeless> its relationships make foaf useful
<jelmer> lifeless: it depends on what you want to use it for I guess
<jelmer> if you want to use DOAP to help with packaging, I agree dependencies are a need
<lifeless> jelmer: relationships let you build a package spiderer
<lifeless> without that its just another way to write a readme and news file :)
<jelmer> lifeless: true, though a parseable one
<CameronP_> Do you guys help out newbs to baazar?
<spiv> CameronP_: yes, although sometimes the channel is just quiet.
<spiv> CameronP_: a more specific question might attract more answers
<CameronP_> Yeah sorry after that I just worked it out myself!
<CameronP_> I was just having issues creating shared repositories
<spiv> CameronP_: Heh, ok :)
<CameronP_> spiv, If I want to get the latest version of a branch, but dont want any history (eg for publishing to web server) is the bets way via the --lightcheckout ?
<CameronP_> --lightweight i mean
<lifeless> CameronP_: to publish to a webserver, use bzr upload
<lifeless> its a plugin
<lifeless> and designed for web publishing
<awilkins> Does that just do a "straight" upload each time or does it rsync or do incremental updates?
<CameronP_> oh ic...
<CameronP_> spiv: Thanks I'll take a look
<spiv> awilkins: incremental, I believe.
<spiv> awilkins: see http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
<garyvdm> Hi - I'm haveing to push some branches (in 2a format) via a slow ftp connection. It keeps on repacking the remote repo. This is realy irritating. Is there any way to disable this, and what would the effects of that be?
<spiv> jam: around?  I want to check which email address is good for you atm, as the usual one seems to be bouncing.
<CameronP_> spiv: What is meant by JUst the working tree for upload
<CameronP_> eg say I've create a shared repostiory repository
<CameronP_> and then ive created a project called xyz
<CameronP_> and i only want to "upload" via the plugin just the project xyz
<spiv> garyvdm: if do a manual pack, it'll fully pack the whole repo which will have the side effect of delaying large autopacks for quite a while.
<spiv> garyvdm: there's no option for disabling autopacks entirely that I know of
<spiv> garyvdm: the effects however would be a steady slowdown in read speed when accessing the repo, especially over a network.
<garyvdm> spiv: I don't really understand what pack does, but maybe the autopack policy needs to be different for dumb remote to local, and smart remote.
<spiv> CameronP_: if you want to just upload the files, no history, to a webserver, then the bzr-upload plugin is probably the best tool.
<spiv> CameronP_: whether or not you have a shared repo doesn't affect that.
<CameronP_> yeah im confused i think
<CameronP_> the problem is that the central repo is the same server the website is on
<CameronP_> so my understanding isnt fitting if you know what i mean
<CameronP_> I havent worked out how to install it yet :(
<spiv> garyvdm: it combines many small pack files into a single pack file, which is already beneficial in itself... for 2a there's the added benefit that having more content in one file gives better compression.
<spiv> garyvdm: autopacking generally triggers ~10 writes to a repository (a single push would count as one write in this context, assuming there was something to push, as would a single commit).
<spiv> garyvdm: crudely, autopacking means that by the time you've committed hundreds or thousands of times you'll still only have a few (say <20, and often <10) pack files, rather than hundreds or thousands.
<spiv> So it's small, regular doses of pain now to avoid worse pain later :)
<garyvdm> spiv: I see. I'm going to take a look code to see if I can hack it to make it repack less often for dumb remote transports.
<luks> well, 1000 => 10000 is not very regular
<spiv> CameronP_: Well, you could "bzr upload" to a local directory just as easily as to a network local.
<spiv> garyvdm: that won't really help
<spiv> garyvdm: in that when it finally does trigger, it'll just be much much worse.
<spiv> Because it'll have more to do.
<garyvdm> spiv: I push to these branch often, and then work on them on the machine that I'm pushing to locally.  It can repack when I'm on that machine...
<garyvdm> CameronP_: Have you come right with installing bzr-upload. Maybe I can help you.
<spiv> CameronP_: you can probably install that plugin simply by doing "bzr branch lp:bzr-upload ~/.bazaar/plugins/upload", although you may need to make the ~/.bazaar/plugins dir first.
<CameronP_> yeah what i did was go into usr/lib/python2.4/site-packages/bzrlib/plugins/
<CameronP_> and did a bzr branch https://launchpad.net/bzr-upload
<CameronP_> which made an upload dir in the plugins dir
<spiv> CameronP_: you may need to make sure its 'upload', not 'bzr-upload' in that plugins dir.
<CameronP_> spiv: thanks that fixed it
<CameronP_> well it got the command working
<CameronP_> so now, this is where i get confused
<CameronP_> im sitting in my public_html dir where i want to download to
<CameronP_> and issuing the command bzr upload /home/xyz/repository/courses
<spiv> I think you have the usage backwards :)
<CameronP_> Yep
<CameronP_> i think your right...
<CameronP_> heh
<CameronP_> so how does it know where to download the files to?
<spiv> Judging from the README, you want to be in /home/xyz/repository/courses and do "bzr upload ..../public_html"
<CameronP_> AHHHH
<CameronP_> noob mistake, thanks a lot
<spiv> It would probably be harder to make that mistake if the target was a network location :)
<spiv> As most systems don't let you "cd sftp://somehost/foo" ;)
<CameronP_> yay it worked ;) Thanks spiv
<CameronP_> now it has that cool option of auto updating... that will be great
<garyvdm> CameronP_: bzr upload --auto :-)
<moldy> hi
<CameronP_> ah dang :(
<CameronP_> now upload has caused an error
<CameronP_> i found a patchfor it, but it should have already been fixed in that version i downloaded yeah?
<CameronP_> https://bugs.launchpad.net/bzr-upload/+bug/312686
<ubottu> Launchpad bug 312686 in bzr-upload "Error "you cannot specify None for the display encoding" on commit" [Undecided,New]
<CameronP_> he has a diff file, there is, that the same as a patch file?
<CameronP_> so can i use like patch -p0 < xyz.diff
<moldy> what's the recommendation for migrating an svn repo that uses svn:externals?
<jelmer> moldy: there isn't a really good solution
<jelmer> moldy: nested trees will provide similar functionality
<jelmer> until then you can work around the missing functionality by using config-manager of scmproj
<CameronP_> Well I patched it, but now getting another error, basically it looks like its returning text back to tortoisebzr
<CameronP_> so  tortoisebzr is throwing an error
<moldy> jelmer: well, basically i just want the data and the history, the externals can become normal directories
<jelmer> moldy: in that case, you can just convert the containing tree to bzr
<jelmer> and then use "bzr join" to import the external branches
<moldy> jelmer: i'm trying :) struggling with bzr-svn right now
<moldy> jelmer: which tool do you recommend?
<jelmer> moldy: To import from svn ? bzr-svn
<jelmer> moldy: Should work just the way you would use bzr itself
<moldy>     from bzrlib.plugins.svn import format
<moldy> ImportError: cannot import name format
<moldy> hmmmm
<jelmer> moldy: what version of bzr-svn are you using?
<moldy> jelmer: 0.6.4
<moldy> jelmer: with bzr 1.15.1
<bebraw> how can i revert a branch to the state of the trunk?
<jelmer> moldy: hmm, that's odd
<moldy> 0.6.1 seems to work better, now i just need to install subvertpy
<jelmer> moldy: 0.6.4 also needs subvertpy
<jelmer> that could explain the other error
<moldy> jelmer: hm, maybe
<moldy> i don't think so, though
<moldy> my bzrtools seems to be lacking something that 0.6.4 requries
<jelmer> bzr-svn doesn't depend on bzrtools
<jelmer> in any way or form
<moldy> wait, let me check again
<moldy> ah right, i mean bzrlib
<moldy> from bzrlib.plugins.svn import format
<moldy> my bzrlib.plugins has no "svn" module
<jelmer> that's a red herring, there's something else that's failing
<jelmer> such as subvertpy not being loadable, that's causing the svn plugin to be unloadable and thus be "msising"
<moldy> it isn't there, i looked at it
<moldy> find /usr/lib/python2.6/site-packages/bzrlib/ -name "*svn*" --> nothing
<jelmer> moldy: that's not the only location searched
<jelmer> moldy: ~/.bazaar/plugins is included as well, for example
<moldy> huh? how does it pull that trick
<moldy> bzrlib.plugins.__file__ is __init__.py in the above directory, and it doesn't import anything
<bebraw> nm. bzr branch to rescue :)
<moldy> 0.6.1 works when subvertpy is installed, 0.6.4 shows the same error as before
<CameronP_> does anyone know how i  can get hte upload plugin to "forget" a directory in uploaded to , its saved  location is wrong
<vila> CameronP_: --remember
<CameronP_> thanks vila, yeah auto unfortuantely breaks it :( what a shame
<CameronP_> tortoise bzr that is
<vila> ?
<CameronP_> when you have --auto on, and then you do a comit remotely, it fails as it returns stoutput back to tortise about it doing an auto update
<CameronP_> so then it all gets broken
<vila> CameronP_: file a bug, I don't use tbzr myself and I'm not sure I understand what you're describing, but it sounds like something that needs to be fixed
<CameronP_> Yeah, there is a  bug open, and a guy posted a patch but it doesnt quite fix it
<CameronP_>  https://bugs.launchpad.net/bzr-upload/+bug/312686
<ubottu> Launchpad bug 312686 in bzr-upload "Error "you cannot specify None for the display encoding" on commit" [Undecided,New]
<phinze> hey #bzr, trying to write a small plugin this morning... two questions: is there a nice searchable API somewhere for bzrlib or does everyone just use the HTML version
<SamB_XP> phinze: well, ideally the HTML version would *be* searchable ;-)
<phinze> number two, i'm trying to see if a given path has changed given a ChangeBranchTipParams... can anyone point me in the right direction as to where to look in the API
<moldy> jelmer: ok, thank you, bzr-svn seems to work fine now... now i just need to wrap my head around bzr join :)
<SamB_XP> I actually tend to grep the bzr source a lot, personally ...
<phinze> SamB_XP: true... just inquiring as to what the active folks use for their reference
<phinze> SamB_XP: i'm not averse to that :)
<SamB_XP> anyway, I was thinking maybe it wouldn't be that hard to rig some javascript up to search the docs?
<phinze> unfortunately i'm still such a newb to the base API that sometimes the source is not the fastest way
<phinze> SamB_XP: true... a la rubybrain or something similar
<CameronP_> does anyone know where bzr puts itself on install?
<phinze> so anyways i'm making my way through Repository and such, and i think i need to first generate some sort of delta given new_revid and old_revid
<awilkins> CameronP_: Which OS :-)
<CameronP_> centos (rhel)
<awilkins> CameronP_: I think bzrlib goes in the relevant site-packages
<awilkins> CameronP_: I have a centos box under my clutches but I installed it from sources
<CameronP_> same
<CameronP_> i wondered where it went once installed
<awilkins> Do a
<awilkins> cd /
<awilkins> find -name bzrlib    # :0
<vila> 'bzr version ' should tell you
<CameronP_> bzrlib
<CameronP_> ah ic im doing a locate on bzr
<awilkins> "bzr" is a small script that calls into bzrlib
<CameronP_> yeah thats what im looking for
<awilkins> It'll be inside your python stuff somewhere
<CameronP_> so i can run it from a script
<CameronP_> yeh...thanks
<vila> CameronP_: 'which bzr' should tell you and then 'bzr version' will tell you all the details, also, try 'bzr plugins -v' to see what plugins are installed and where
<phinze> ah get_revision_delta in Branch
<phinze> there we go
<CameronP_> thanks vila
<phinze> hmm what's confusing me now is in the pre_change_branch_tip state, the new_revid does not exist in the branch i have reference to
<LarstiQ> phinze: branch or repository?
<phinze> which in a way makes sense, since it's *pre*, but i don't know how i can get a revision delta
<phinze> ooo good call
<phinze> doesn't exist in branch, might in repository?
<LarstiQ> yeah
<phinze> cool; will look in that direction, thx
<phinze> beautiful, now we're cookin with gas ;)
<moldy> jelmer: i succesfully converted the containing repository to bzr now. can you give me a hint on how to use bzr join to join the former svn externals? i get errors about missing working trees
<jelmer> moldy: clone the external URLs at the places where they need to be in the tree
<jelmer> and then run "bzr join <path>"
<moldy> jelmer: thanks, trying that
<moldy> jelmer: seems to work, nice. thank you (i also had to add a "bzr co" on the cloned path)
<jelmer> moldy: if you had a treeless repo, that might indeed be necessary
<moldy> seems to be the default for svn-import
<jelmer> moldy: ah, yeah - that's correct
<jelmer> moldy: newer versions will tell you though that you need to run "bzr co"
<moldy> i see
<jelmer> (the trees aren't automatically created since they can take up a lot of space if you have a lot of branches)
<moldy> jelmer: can i safely delete those .bzr.retired.0 files that are created by the joins?
<jelmer> moldy: yeah
<moldy> ok, thanks for your help
<tbradshaw_> Hello there, as a quick question, are "push" and "pull" symmetric?  Is it safe to use them interchangeably, or is there more to a push than there is a pull?
<vila> tbradshaw_: they are symmetric
<tbradshaw_> ah, that's great.  Thanks, vila. :)
<vila> given that you switch your source and target branches when using them I mean
<CameronP_> gnight all..
<vila> tbradshaw_: the only edge cases where you can observe differences is regarding updating the working tree, but bzr does a good job of warning you when that occurs
<vila> CameronP_: night
<tbradshaw_> heh, yup, I just ran into that
<tbradshaw_> and the documentation provide was solid
<tbradshaw_> s/provide/provided
<vila> CameronP_: did you file a bug regarding tbzr/upload interactions ?
<vila> ....
<moldy> how do i give a branch that uses a shared repo its own repo?
<tbradshaw> I ran into a bug in bzr 1.5 (the current version in debian stable) that prevents me from pulling
<tbradshaw> and so I had hoped to "cheat" but using the other side to push instead, where I'm using a newer version
<moldy> ah, got it
<moldy> hmm, no :)
<tbradshaw> I'm up against this bug: https://bugs.launchpad.net/bzr/+bug/307091
<ubottu> Launchpad bug 307091 in bzr "Too many concurrent requests (dup-of: 246233)" [Undecided,New]
<ubottu> Launchpad bug 246233 in bzr "TooManyConcurrentRequests error when ssh connection fails (bzr crashes when pulling)" [High,Fix released]
<tbradshaw> is there a workaround?  Could I generate one of those merge files, scp over, that directive file
<tbradshaw> and then do it that way
<tbradshaw> also, I had no idea I was going to trigger that bot
<fullermd> moldy: There's an option to 'reconfigure' to do that.
<moldy> fullermd: i can also just branch from it, right?
<fullermd> Well, if you branch in the repo, the new branch will be using the repo too...
<moldy> fullermd: ok, but branching from outside will work?
<fullermd> From doesn't matter; it's to that does.
<moldy> ok, i see
<fullermd> I get the feeling that at least one of us is confused over what you're trying to accomplish, though.
<moldy> fullermd: the big picture is that i am converting an svn repo, then re-organizing it
<fullermd> What would that clal for switching a branch to using an internal repo?
<moldy> fullermd: i want the former svn branches to turn into standalone branches now
<fullermd> 'k, but why?
<moldy> i don't really have any special reasons
<moldy> disk space is not an issue, and it seems easier, less to worry about
<fullermd> It saves IO as well as disk space, since various actions no longer need to copy stuff around.
<fullermd> About the only thing being standalone gains you in the general case is being able to mv it arbitrarily around the filesystem.
<moldy> which is nice, for the moment
<moldy> i am juggling with several svn/bzr repos/branches, it's easy to get confused at the moment :) i can always setup a shared repo later if i want to
<jelmer> moldy: try bzr reconfigure --standalone in the branches
<moldy> jelmer: thanks
<mthaddon> jelmer: not sure if you're aware, but there's a request from lifeless for us to upgrade PQM for bzr, but there's a new python-subunit dependency and we'd really like that in karmic before anything else (so we can backport to our repo)
<mthaddon> jelmer: is that something you could help with?
<jelmer> mthaddon: I can request a sync I guess, that way we'll end up with subunit in karmic
<jelmer> That might require a freeze exception at this point though
<jelmer> james_w: ping
<james_w> hi jelmer
<james_w> mthaddon: you need bzr68?
<mthaddon> james_w: I'm not really sure what that means... :(
<fullermd> bzr written in ALGOL 68?
<james_w> mthaddon: you need a specific revision of python-subunit?
<james_w> pqm depends on something in subunit revisions 67 or 68?
<mthaddon> james_w: lifeless says in the RT that it depends on lp:~subunit/ubuntu/karmic/subunit/snapshots
<jelmer> mthaddon: ah
<jelmer> mthaddon: in that case you'd probably need a completely new package in Karmic since the one in Debian would be too old
<mthaddon> jelmer: that's possible, yeah
<james_w> jelmer: but debian is only one revision behind lp:subunit isn't it?
<jelmer> james_w: no, 11
<jelmer> lp:subunit is at revision 79
 * james_w fails at subtraction
<jelmer> base 10 ?
<james_w> mthaddon: but yeah, we can do it but it will require a freeze exception
<mthaddon> james_w: cool, thx
<james_w> mthaddon: you don't want to rely on me for this though
<mthaddon> k
<lamont> james_w: it's universe, no?
<james_w> it is
<lamont> lalalalalala what freeze?
<lamont> :-)
<james_w> heh
<james_w> they are free with exceptions at this point in the cycle
<james_w> just needs someone to explain why they want it and that they have done some testing
<lamont> I mean,  I can go make sure that -release doesn't care... I assume it has a relatively short build time?  (like prolly minutes or less on i386/amd64)?
<james_w> probably
<lamont> 4 minutes on ia64
<lamont> so... you've tested it and you're happy with it?
<james_w> I haven't looked at it
<lamont> ah.  well, I expect _someone_ of the gang has, since it's a dep of sutff they're using all the time,...
 * lamont goes to prod the right people
<lamont> james_w: since lifeless is the one asking for it, I'm gonna assert that either it's good, or he's gonna fix it.  if you'll package it, I'd be happy to give it a quick blessing and upload it, or you can... ok?
<james_w> I can upload
<james_w> he's packaged it
<james_w> it looks like, at least
<lamont> thanks.  feel free to just do so.  RM slangasek said he won't kill me for shoving it that way
<james_w> I'm just busy with other things right now, so don't want to get pulled in to this
<lamont> ah.  so it's already packaged?
<lamont> and if we just bzr branch from the snapshot, it should be shiny?
<james_w> well, the branch referenced in the RT is package branch
<lamont> \o/
<lamont> mthaddon: you wanna play with the packaging and then I'll upload it?
<mthaddon> erm, will give it a go
<phinze> hmm so i'm trying to iterate on all new revisions in a pre_change_branch_tip hook
<phinze> i've got my logic down but then realized it was only running on the last revision being pushed
<phinze> so i was trying to do something with range(params.old_revno + 1, params.new_revno)
<phinze> but i can't figure out how to convert each revno into a revid ... i ask the branch and it says "nope i don't have that revno just yet"
<phinze> need revids so i can get trees/deltas
<phinze> from the repository
<phinze> any help much appreciated... brb for a quick mtg :)
<beuno> Peng_, I've *just* realized that your tshirt never got shipped
<beuno> and, doing the process again, the world-wide shop doesn't let me ship to the US
<beuno> and the US shop doesn't have LP tshirts
<beuno> grrrrrrrrrrrrrrrrrrrrrrrrrr
<phinze> so i'm still working on detecting whether a given path is changed in a pre_change_branch_tip
<phinze> i'm trying to figure out whether what i need be figuring out is how to iterate over each revision in the branch change
<phinze> or if i need to be figuring out how to get a delta that covers the entire span of the tip change
<phinze> i've been learning a lot from the API docs, but it's taking me a lot longer at this juncture since i don't know which direction to look in
<Milo-> hey, I have a project that has its versions controlled with bzr, I just did few uncommit operations, and I would like to lighten my repository slightly..
<Milo-> is there a way of removing those old packs?
<Milo-> without breaking anything
<Milo-> heh google was faster
<Milo-> or not
<phinze> Milo-: a little quiet in here today
<phinze> check out https://bugs.launchpad.net/bzr/+bug/43753
<Milo-> yup it is
<ubottu> Launchpad bug 43753 in bzr "uncommit option to remove revision data from repository" [Medium,Confirmed]
<phinze> looks like there's still no support as yet built in, but there's aplugin linked there
<Milo-> I see
<Milo-> nice, a plugin without readme :)
<phinze> i believe the correct term is "self documenting" ;D
<Milo-> no idea how to use that ...
 * phinze will pull it and take a quick look
<Milo-> it just has one __init__.py file
<Milo-> and reading it gives me no hint at all.
<phinze> ah, you just drop the directory into ~/.bazaar/plugins/PLUGIN_NAME/__init__.py file
<phinze> so it looks like that path format ^^
<phinze> assuming you're on some sort of unix variant
<phinze> if you put it in the correct place, bazaar automatically loads it
<phinze> and you'll get "bzr remove_revision" looks like
<phinze> http://bazaar-vcs.org/BzrPlugins <-- for more info on bzr plugins
<LarstiQ> phinze, Milo-: plugins are usually installed by `bzr branch plugin/url ~/.bazaar/plugins/pluginname`
<Milo-> yes I see
<LarstiQ> where pluginname is a valid python identifier, ie, strip the leading 'bzr-'
<phinze> wahey - there's even a convention ;)
<Milo-> gah, it's bzr remove-revision :) not the way phinze said it :)
 * phinze blushes, tries in vain to cover up large NEWB letters flashing above his head :)
<Milo-> I get error when I run that command
<Milo-> well, can I just rm obsolete packs?
<beuno> yes
<beuno> I do all the time
<twohey> I was wondering if someone here knew how to setup email notifications for pushes / commits to a master branch.
<twohey> i'm pretty sure this is possible given https://lists.ubuntu.com/archives/bazaar-commits/
<twohey> but my googling failed to find documentation on how to fix this
<jam> Milo-: don't delete the directory, but you can delete the *content* of obsolete_packs
<lifeless> moimoin
<Goosey> bzr 1.17, "bzr help commands' encounters internal error. Fresh install. Anything I should look at?
<lifeless> Goosey: windows?
<Goosey> lifeless, ah yes. Windows XP
<Goosey> installed with the standalone installer
<jam> Goosey: upgrade to 1.17.1
<jam> there was a bug in the packaged version of one of the plugins
<jam> nothing serious
<jam> just caused 'bzr help commands' to fail
<jam> (and nothing else, IIRC0
<Goosey> jam, sure enough. thanks
<lifeless> twohey: hi
<lifeless> twohey: the stuff on bazaar-commits is just done by devs installing bzr-email
<lifeless> twohey: if you're using bzr+ssh you can do the same on a server by installing and configuing bzr-email on the server
<twohey> lifeless: thanks.
<twohey> is there documentation for bzr-email? I can't seem to find anything on how to set it up
<lifeless> its a plugin, so that part is generic
<lifeless> then bzr help email
<twohey> should have known, thanks
<lifeless> jam: bug 402652
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652
<jam> lifeless: do you have a question?
<lifeless> jam: IIRC I reviewed it
<lifeless> jam: was there more to do before landing?
<jam> lifeless: is that the groupcompress sort order portion?
<jam> That has landed in 2.0 and trunk
<lifeless> ah. the robert is awake but confused event
<lifeless> cool, I'm glad that that has landed
<lifeless> ok, reviews for 2.0 done
<lifeless> I thnk
<lifeless> hi jam
<jam> hey
<lifeless> so, I've reviewed ians patch
<lifeless> andrew is doing insert stream
<lifeless> you and I were bouncing group combining around
<lifeless> are you still looking at group combining, or should I pull your progress and continue? Alternatively I could do the tests for the conversion bug that I deferred
<lifeless> or pick up the content filtering patch and work on that
<jam> I'm still working on the group combining
<jam> I think I have a decent heuristic
<jam> I just need to
<jam> 1) add tests and tie it into insert_record_stream
<jam> 2) Check that we don't end up with issues with Remote streams
<jam> since I think I determined that they will call insert_record_stream() 1/group
<jam> which negates the benefit of what I'm doing
<lifeless> I'll look at 2 for you now
<jam> So either we need to persist a group between groups
<jam> or combine the stream into a bigger stream
<jam> I favor the latter
<jam> um....
<lifeless> jam: I'll have it done in about 10 minutes I think
<jam> lifeless: running "bzr selftest -s bt.test_repository.Test2a.test_autopack_unchanged_chk_nodes" is taking 5.3s for me
<jam> but if I do "--lsprof-tests" it drops to 1.3s
<lifeless> !
<jam> sorry, 1.8s
<lifeless> wow
<jam> yeah
<lifeless> lsprof makes our code go faster.
<lifeless> [kidding]
<jam> lifeless: same results if I do '--lsprof-file ,,foo.txt'
<lifeless> thats not something I saw coming
<jam> I guess I just dropped to 3.8s, and now 1.7s
<jam> very weird
<jam> anyway, still 'tree.commit()' 20 times shouldn't really take that long...
<lifeless> hmm, actually this may be trickier
<lifeless> jam: locking is slow - are you on windows?
<jam> yeah
<jam> still way too long, IMO
<lifeless> I agree; not sure how to fix it. That test does want separate packs
<lifeless> uhm perhaps suspend_write_group+resume_write_group
<lifeless> or
<lifeless> memorytransport
<lifeless> the latter I think would be better
<jam>         tree = self.make_branch_and_memory_tree('tree', format='2a')
<jam> 1325ms
<jam> unless a memory tree is still backed by the real disk repo
<lifeless> it is
<lifeless> you need
<lifeless> self.vfs_transport_factory = MemoryServer
<lifeless> and then that
<jam> 421ms
<jam> a decent improvement
<lifeless> better indeed
<jam> and that includes test-suite setup overhead
<jam> 312ms if it isn't the first test being run
<jam> still fairly surprising given what it should actually be doing... but at least it isn't terrible now
<lifeless> changing to TestCaseWithMemoryTransport would reduce some overhead too
<lifeless> and further still when I fix bzrlib.config to not write to disk, and bzrlib.bzrdir.clone to not search unconditionally for repository policies (which is a reason we have to have the fake containing dir on disk)
<lifeless> netbeans export at 118K/133K
<lifeless> 103G
<jam> ouch
<lifeless> it will be _very_ interesting to see what bzr makes of this tree
<lifeless> I'm hoping it will be an eat-their-lunch event
<lifeless> either way we'll learn something
<lifeless> hmm, this needs an object.
<lifeless> refactorating
<lifeless> ok: for remote streams
<lifeless> I'm on it.
<lifeless> no direct tests, and its going to need them now; I'm going to write one small test for this specific case, refactor, and push a branch for you to merge into your work.
<lifeless> First though, I need a drink, bit dehydrated
<jam> k
<lvh> hi!
<lvh> I'm wondering what the canonical (no pun intended ;-)) way of doing this in bzr is. Suppose I have a branch of a project, with commits A -> B -> X -> Y, up to B is pushed to launchpad
<lvh> someone did a code review of B, and X, Y is the start of a bunch of new functionality
<lvh> so, I guess moving X, Y into a new branch would make sense
<lvh> lifeless helped with this, this command: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6
<lvh> now, once I fix the things the review hinted at in the main branch I would like to have these changes also be done in the new functionality branch, of course
<lvh> in git, i would do this with rebase
<lvh> how do i do this in bzr?
<lifeless> cd new branch
<lifeless> bzr merge old branch
<lifeless> [review]
<lifeless> bzr commit
<fullermd> That sounds like a pretty roundabout way of doing bzr branch -r-6 . ../p-g
<lifeless> fullermd: no, its kindof the reverse
<lvh> lifeless: wait, merge the old branch from the new branch?
<fullermd> It huh?
<lvh> I do actually do this, right: bzr branch . ../positioning-gpsd; bzr pull . --overwrite -r -6
<fullermd> It's the same thing, just directly expressing what's being done instead of backing and filling..
<lifeless> lvh: you want the reviewed changed from the older branch in the newer branch ?
<lvh> lifeless: Ah, I was thinking of not having two separate branches anymore, but yeah I gues sthat makes sense too
<lvh> eg have the branch just be a temporary container for commits
<lvh> but your way makes more sense, never mind :-)
<lvh> lifeless: thanks again!
<lifeless> fullermd: it is, except that the branch dirs are reversed the other way, which, when you're thiking abuot a problem a specific way is confusing.
<fullermd> lvh: Well, once you merge, you _do_ just have one branch  :)
<lifeless> fullermd: Feeling philospohical today?
<fullermd> lifeless: Oh, I overread the 'cd' in the middle.
<lvh> fullermd: the old branch disappears?
<poolie> hello all
<lifeless> lvh: no, it doesn't.
<lvh> or two directories in the same state
<lvh> plus or minus a few branch specific commits
<fullermd> It _can_, since you have all its revs.  Unless you need to keep it aroudn for somethign else.
<lifeless> lvh: the old branch is untouched. the new branch has the changes you made in old merged into it,
<lifeless> lvh: so the old branch isn't needed at that point, thats all that fullermd is saying, I think.
<lifeless> hi poolie
<lvh> oh, right
<fullermd> I'm always feeling philosophically.  It's just usually not very cogent or meaningful  :p
<lvh> thats okay, I have a quickly learning heuristic filter
<lvh> (if lifeless: pay attention else: ignore)
<fullermd> Excellent.  We always need more quick learners   8-}
<lifeless> jam: done
<lifeless> mm
<poolie> hello jam
<lifeless> bzr push ../foo with uncommitted changes in . pushed those changes to ../foo as uncommitted there ><
<lifeless> surprising
<lifeless> jam: lp:~lifeless/bzr/adjacent-streams - merge that
<lifeless> poolie: james_w rebuilt the debs last night.
<lifeless> poolie: I haven't manually confirmed they are green yet, but they should be.
<poolie> that's great
<bialix> vila: are you still here?
<vila> no :)
<vila> bialix: Won't stay long, but I'm listening to you
<bialix> config.py AuthenticationConfig
<bialix> get_user and get_password
<bialix> which transport can trigger them?
<vila> all
<bialix> we have bug in qbzr, re bzr-svn
<bialix> jelmer insist bzr-svn uses these methods
<vila> ach, bzr-svn :-/
<bialix> I'd like to test my bug fix w/o svn
<bialix> so, bzr+ssh?
<bialix> or sftp?
<vila> what do you mean by 'jelmer insist' ?
<bialix> wait a sec, I'll show bug number to ubottu
<vila> all transports can potentially make use of auth.conf, that's less useful for ssh because there are better solutions there (ssh agents and .ssh/config)
<bialix> https://bugs.launchpad.net/qbzr/+bug/418252
<ubottu> Launchpad bug 418252 in qbzr "attempt to check out SVN repo never gets anywhere" [High,Confirmed]
 * bialix waves to emmajane
 * emmajane waves to bialix 
<bialix> I like design #2, but I've already wrote this
<bialix> vila: paramiko as ssh agent can use auth.conf
<bialix> err
<bialix> vila: paramiko as ssh client
<vila> yes
 * vila reading the bug report
<bialix> so, which transport will trigget get_user?
<vila> any transport can
<emmajane> bialix, excellent :)
<vila> so you can test with whatever is easier for you
<bialix> vila: for local testing I'd prefer stick to sftp/ssh
<vila> there shouldn't be any difference from bzr-svn if I read jelmer comments correctly
<vila> so, if you can get get_user/get_password called from the command line, the same should occur from tbzr
<bialix> vila: I have fuzzy feeling that sftp/ssh transport deduce user name somehow
<bialix> vila: this is my question actually: how can I force get_user ask
<vila> things have changed in this area... but I can't point to when exactly
<bialix> I can use ftp
<vila> you can force get_pasword by connecting to a host where your key is not authorized or temporarily rename your key to force a password check...
<vila> ftp is simpler :-)
<bialix> get_password is not problem
<bialix> qbzr lacks get_user implementation
<bialix> I don;t remember I ever seen prompt for user name with bzr CLI
<vila> bialix: just look at the bzrlib tests then ! get_user is tested almost like get_password
<vila> bialix: We didn't have get_user for a very long time because it's very rarely used, I think we first need it for an http server
<poolie> lifeless: jam says he's finished working for the day, so if you want to take over that would be good
<poolie> don't wait to hear back from him
<lifeless> heh, chinese whispers
<lifeless> ok
<lifeless> he says its just tests and glue
<lifeless> I'll start with glue.
<bialix> vila: test_config tests very low level API
<bialix> vila: I can't test with http, heh, have to find some open svn repo to test this
<vila> bialix: test_ui not test_config
<bialix> test_ui?
<vila> bzrlib/tests/test_ui.py contains test for get_username
<bialix> yes, but it's low level too
<bialix> ok, vila, perhaps we both need to go offline till tomorrow
<vila> what's wrong with low level tests ? You want low level tests for your qbzr implementation right ?
<vila> bialix: yeah, good idea :)
<bialix> no, I want high level
<bialix> manual test with real access to real branch
<bialix> heh
<bialix> gnight vila
<bialix> :-)
<vila> bialix: let's talk about that tomorrow then :) The problem with manual tests is that... you pay in blood every time you run them :)
 * bialix waves
<bialix> tomorrow
<bialix> pay in blood? scary
 * bialix finally disappear
#bzr 2009-09-03
<lifeless> jam: 110G and growing, 13K to go
<hoser> Is anyone familiar with bzr.webdav?
<poolie> hoser: not very, but if you have a question go ahead and ask
<hoser> Hmm.. well.. at the moment I'm using svn for a lot of projects, and would like to switch to bzr. I've been looking at the webdav plugin but if I'm right, it's basically for the client side, and there's nothing but pure dav on the server side. With svn there are apache modules mod_dav_svn and mod_authz_svn. I'm just wondering if similar things exist somewhere
<hoser> so that on the server you can implement read/write controls, allow different usernames to access different projects, etc
<lifeless> we have a wsgi server
<lifeless> and you can do some policy stuff there' for auth we depend on apache
<lifeless> note that with a distributed vcs like bzr policy and access concerns are rather different
<lifeless> rather than one repository with N different permissions and groups
<lifeless> its easier to adminster N repositories, each for one user-or-group
<hoser> yes, but I imagine most projects still have a central authoritative branch
<lifeless> sure
<hoser> which is all I'm concerned about
<lifeless> the N repositories can be on the same server - apache has all tjhe facilies needed to do that with either wsgi or webdav
<lifeless> [wsgi is a lot faster at push and pull than webdav]
<hoser> So you recommend looking into wsgi, then
<lifeless> yu
<lifeless> yup
<lifeless> its in our docs too
<hoser> OK, will do. The key things that are currently motivating switching vcs are: renaming as a known operation, easy branch and merge, offline commits. So if I can sort out the server side I'll be very happy
<lifeless> cool
<hoser> Thanks for your help
<lifeless> have a read of the docs and if they are unclear or you need inspiration / support just give us a yell
<spiv> lifeless: want to review https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root/+merge/11033 ?
<lifeless> sure
<lifeless> spiv: you could look at my adjacent streams patch if you like
<spiv> Ok.
<lifeless> spiv: its not up for review as such, just look at the tip commit
<spiv> lifeless: that looks reasonable.
<lifeless> spiv: ok, I might land that now, to avoid noise in the other patch
<lifeless> ok?
<spiv> lifeless: Hmm.  One comment: it's not clear from the method names/docstrings what the interface to that class is.
<spiv> i.e. that you should call .record_stream rather than .iter_something...
<lifeless> spiv: I could make them private, but its a private class
<spiv> A brief comment in the class docstring, or renaming the other methods to have leading _, or something along those lines would be good.  It will make understanding the class easier to make it clear what the entry point is.
<lifeless> it kind of wants to be several classes
<lifeless> one that does the lookahead handling and grouping
<lifeless> and one that turns stuff into NetworkRecordStreams
<spiv> Right, because of the relatively complex state it holds.
<lifeless> and handwave
<lifeless> otoh this is clearer I think than the previous code
<lifeless> for all that it does more
<spiv> Well, with the other code the "now what is the first method that calls the rest" was easy to answer because of the nesting of the functions :)
<lifeless> I'll tinker a little. I don't feel much need to polish though: this was the only known defect in this area, and we knew that when we wrote it.
<spiv> Just put "Expected usage: decoder = _ByteStreamDecoder(...); stream = decoder.record_stream()" in the class docstring if you like, that'd be enough to satisfy me.
<lifeless> sure
<lifeless> grabbing foodstuffs
<lifeless> spiv: why do you change pack_repo to know about chk_bytes?
<spiv> lifeless: because it was convenient ;)
<spiv> lifeless: I was thinking of pushing that into groupcompress_repo, though.
<spiv> Now that I've made a separate method that GCPackCollection could override.
<lifeless> I suggested that
<lifeless> but there is another implication
<lifeless> we either are missing the check for inventories on packs
<lifeless> or there is duplication amongst things withthis broad goal
<lifeless> I ask that you look for which of those in your future work
<spiv> I *think* the former, at least partly.
<spiv> Because of the existing 'get missing parent inventories' checks that happen in streaming fetch (but perhaps not all fetch code paths?)
<lifeless> throw a stream with only a revision in it at a repo; see what happens :)
<lifeless> 10K to go
<twb> You guys change your repo format a lot, right?
<lifeless> some people think so
<twb> What's the end-user workflow for updating the current repo's format?
<lifeless> we're about to make our first change to the default since nov 2007
<lifeless> twb: 'bzr upgrade'
<twb> OK, thanks.
<lifeless> there is a guide with docs
<lifeless> but that should be the heart of it :)
<twb> (I work on Darcs, and we're adding in-place upgrading of the repo format.  I want to avoid unnecessary differences with other VCS' CLIs.)
<lifeless> cool
<lifeless> what have you improved in the repo format?
<twb> Several years ago we hashed the files in the "pristine" directory, which is an unmodified copy of the working tree.  We also changed the semantics of patch application, e.g. two identical changes no longer conflict.
<twb> Historically upgrades have been done by making a copy of the repo, but people want to be able to make the change in-place.
<lifeless> yeah
<lifeless> its convenient, particularly for developers on C/C++ projects
<twb> Why?  Because they have huge codebases?
<lifeless> because their build products are expensive
<twb> (I mean: why C/C++ especially)
<twb> You mean their compilation process is really slow?
<lifeless> yes
<twb> Yeah, I can see that.
<spiv> right, they want to be able to recycle .o files etc if at all possible.
<twb> distcc :-)
<lifeless> 9.8K revisions to go.
<lifeless> hg fast-export. Slowness. cry.
<lifeless> mind you, I have a 117G fast import to test out next
<twb> At least it works :-/
<lifeless> darcs doesn't?
<twb> darcs fast-import of a git repo was busted on a mkdir -p-type operation, last time I checked.
<lifeless> [darcs fast export I mean]
<twb> IIRC darcs fast-export gets more love, because most people want to leave darcs, not join it :-)
<twb> Because you start out with a small project that Darcs works well for, and you end up with a big project that Darcs is too slow for.
<lifeless> yeah we had that problem
<lifeless> took about 18 months to properly solve it
<twb> But also I use hg at work and it is super annoying.
<lifeless> still don't have as lovable patch workflow as darcs does
<AfC> I have a bzr-svn created branch of GTK. It took about 2 days to make. Blogged about it back then, maintained it publicly. It even caused Jc2k to take an interest and set up bzr mirrors etc.
<AfC> Meanwhile, GNOME (abetted by the very same Jc2k, traitor) switched to Git. Idiots. But I am now wondering: how to I talk to it?
<AfC> Can I somehow leverage the existing bzr-svn created revisions? Or do I use some bzr-git plugin (which launchpad claims to use, not sure if I believe it).
<AfC> Should I use git natively to clone & transfer their repo down, and then use something local disk to convert to bzr?
<lifeless> you can use bzr-git
<lifeless> same author as bzr-svn :)
<lifeless> and yes, lp uses bzr-git
<lifeless> no, you can't use the existing bzr-svn import of gtk, because there isn't a guaranteed correspondence with what they imported to git
<poolie> spm, lifeless, how about we try the conversion/switchover again now?
<poolie> (or after lunch)
<spm> poolie: I can kick off the check now, but am also debugging an LS issue -so somewhat distracted; but should be cool.
<lifeless> I'd rather not have you distracted :)
<lifeless> I think we should do it
<lifeless> when do you think you'll be ours, body n soul?
<spm> lifeless: hrmmm. say 2-3 weeks? we can schedule something in then? :-P
 * lifeless wedges 3pm into spm's schedule
<lifeless> (earlier would be better..)
<spm> seriously tho - I'll rebuild a new bzr from trunk. kick off the make check - and go from there? after lunch basically.
<lifeless> spm: make sure you have rev 4666 or newer
<AfC> lifeless: ok, so I guess I'll throw away the bzr-svn branches. That's mostly what I wanted to know.
<lifeless> AfC: yup
<spm> lifeless: actually 3pm is a horrible time - I can send Dee off alone; but that's usually when I leg stretch by fetching the boy back from school
<AfC> bzr-git is bundled now, right
<AfC> er, is anything bundled now?
<lifeless> the windows installer bundles a bunch
<lifeless> we haven't progressed on bundling elsewhere
<AfC> I thought we were going to batteries included everything useful. Hm.
<lifeless> ETIME
<poolie> etime?
<poolie> afc, igc is working on bundling some more stuff on windows
<poolie> we're not going to block 2.0 on bundling more things
<AfC> poolie: ah
<poolie> we may do that after 2.0 actually freezes though=
<poolie> that will make it easier to change the packaging
<AfC> poolie: well, I'm glad to hear Canonical employees are spending time on making Linux better.
<poolie> spm, lifeless, how about just after you get back from trawling the playgrounds? :)
<spm> poolie: rob trawls playgrounds!??!!?
<poolie> no, only you
<spm> damn. so much for an unsubtle attempt at sliding out of that one ;-)
<fullermd> ...  I knew we were going for a friendly VCS and all, but I didn't know we were aiming at _friendly_...
<poolie> but seriously
<poolie> ping us then?
<spm> poolie: will do
<spm> lifeless: bzr revno 4667 from dev is built/live and working
<lifeless> jml: poolie: Want to lunch tomorrow; talk LP bug handling & the like?
<lifeless> poolie: I has book for you
<spm> poolie: if you're ok with it; I'll stop bzr pqm now; and start a make check on the tree with the 4667 revno I just built
<spm> (and a new backup -> assumed)
<lifeless> spm: doit
<spm> 'kk
<spm> ...../bzr check in progress
 * spm afk for lunch
<jam> lifeless: this line doesn't look right to me:
<jam> +        for record in self.iter_pack_records:
<jam> since I can't find 'iter_pack_records' and if I did find it, I would expect it to be a callable iter_pack_records():
<lifeless> jam: its assigned to self
<lifeless> its a generator we keep using
<lifeless> look at seed_state()
<lifeless> jam: I got your call; thanks! where is your current branch?
<jam> lp:///~jameinel/bzr/2.1b1-pack-on-the-fly
<poolie> spm, that's great
<poolie> lifeless: that's ok
<poolie> i mean lunch tomorrow is ok
<lifeless> great
<jam> lifeless: yeah, I called poolie because you didn't answer your phone :)
<lifeless> jam: was in the other room - sorry
<lifeless> and at max ring volume its stupidly quiet
<jam> not a big deal, it got through to you
<lifeless> 125087/133780
<lifeless> nearly there
<lifeless> 119G
<AfC> Jelmer's dulwich page http://samba.org/~jelmer/dulwich/ claims a GPG signature for 0.3.3 but the .asc there is not being groked by by `gpg`. Nor by `file`.
<AfC> It is certainly not ASCII, whatever it is
<lifeless> file dulwich-0.3.2.tar.gz.asc
<lifeless> dulwich-0.3.2.tar.gz.asc: PGP signature
<AfC> um
<AfC> oh, weird. Epiphany has saved a gzip of it. Is that a transfer-compression miss-thing
<lifeless> yes
<lifeless> also note that his link is to 3.2
<lifeless> gpg dulwich-0.3.3.tar.gz.asc
<lifeless> gpg: Signature made Fri 24 Jul 2009 04:29:25 EST using RSA key ID D729A457
<lifeless> wget -S http://samba.org/~jelmer/dulwich/dulwich-0.3.3.tar.gz.asc
<AfC> ah, that's also not helping
<lifeless>   Content-Type: text/plain
<AfC> jelmer: ping? You've got a copy & paste bug
<AfC> Meanwhile, /me uses trusty wget
<lifeless> I'd need a network trace to say. Could be either server misconfig or epiphany damage.
<AfC> ok, good signature now, thanks
<AfC> lifeless: I think it's probably Epiphany trying to be too clever
<lifeless> possibly
<AfC> lifeless: jelmer's c&p bug didn't help either. Nothing like multiple simultaneous unrelated problems.
<lifeless> equally possibvly is the server claiming content encoding
<AfC> server claimed "Vary: Accept-Encoding" ... I wonder if that faked out Epiphany's "Download..."
<AfC> something for another time. Thanks Robert
<lifeless> yeah, it means that it will give wget and epiphany different answers :)
<lifeless> I bet there was a content encoding on the response you got, and the interaction fails
 * AfC grumbles ... Galeon did such things correctly. I need to go bitch at someone, I think
<lifeless> debug first
<lifeless> :)
<lifeless> get the right culprit
<AfC> You kidding? Random drive-by bitching is much more fun. Especially when innocent bystanders get caught in the cross-fire.
<fullermd> Innocent?  They're on the internet.
<AfC> I lost my innocence long before the internet.
<AfC> Oh, I hate my life
<AfC> bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade'
<AfC> after 2 hours of work trying to get bzr-git to work.
<poolie> hm, probably a mismatched version of the plugin
<AfC> poolie: yeah, I'd branched trunk. I'm gonna try branching from the newest sounding release tag
<poolie> i don't *think* we changed that recently though
<AfC> I just packaged released dulwich, so I guess I'll use released bzr-git to go with it
<AfC> Bah. No, that didn't help
<AfC> So, I'm trying
<AfC> $ bzr info git://git.gnome.org/gtk+
<AfC> prepatory to trying
<poolie> spiv, tell me about bug 406687?
<ubottu> Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687
<AfC> $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/
<poolie> git+ssh:// maybe?
<AfC> [though I guess that's optional, I'm not pushing at the moment, just like to have r+w since I do]
<AfC> poolie: probably - but git:// needs to work first
<Talden> Does anyone know if bzr-svn should support local access (file:///...) to Subversion 1.6 repositories?  I get a 'not a branch' exception suggesting no.
<AfC> poolie: c.f. http://www.gtk.org/download.html
<fullermd> I thought bzr-git only got along with local access.
<fullermd> Or maybe I'm thinking of bzr-hg.
<poolie> afc, and what happens? just that typeerror?
<AfC> yes
<poolie> fullermd: i think there is at least some remote support now
<AfC> poolie: ^
<spiv> poolie: the partial fix (ensure revisions have corresponding inventories present, and that those inventories + any parent inventories have chk root entries present) is with PQM (although I think PQM is paused for the 2a migration?).
<poolie> ah it may be
<AfC> [off topic, but:
<AfC> $ bzr info ssh://afcowie@git.gnome.org/git/gtk+/
<AfC> gives
<poolie> and the next step is to check that the whole inventory closure is there?
<spiv> poolie: the more comprehensive fix is underway, I think I have working code for checking all necessary chk records are present, but I want to write some tests now to prove that :)
<AfC> bzr: ERROR: Unsupported protocol for url "ssh://afcowie@git.gnome.org/git/gtk+/": bzr supports bzr+ssh to operate over ssh, use "bzr+ssh://afcowie@git.gnome.org/git/gtk+/".
<AfC> which would be WRONG :)]
<poolie> how about opening a new bug for that larger fix?
<poolie> afc, right, i guess you really mean 'dwim over ssh'
<lifeless> poolie: well I filed this bug for the larger fix
<spiv> poolie: and then having found all relevant chk pages, then extract the relevant text versions from that and check they are present too.
<AfC> but keep in mind Linus's avowed hatred of git+ssh:// so most of the time people will be using ssh://
<AfC> poolie: yeah
<poolie> though that's actually a bit hard to implement
<lifeless> poolie: we never did get to talking about this yesterday.
<AfC> poolie: I think bzr should dwim too
<AfC> :)
<AfC> poolie: ie s/bzr+ssh/ssh/
<AfC> but anyway
<spiv> As lifeless says the existing bug is for the larger fix, although that is a bit inconvenient because it limits how much tracking we can do in LP.
<AfC> yeah,
<AfC> $ bzr info git+ssh://afcowie@git.gnome.org/git/gtk+/
<spiv> Although filing a smaller bug now and immediately marking it fix committed feels like cheating :)
<AfC> gives the bzr: ERROR: exceptions.TypeError: open_workingtree() got an unexpected keyword argument 'recommend_upgrade' crash
<lifeless> poolie: I contend that we should fix the larger issue now, without necessarily delaying 2.0
<poolie> that's fine
<lifeless> poolie: because its defensive
<poolie> i'm just asking or suggesting that there be one bug per incremental step
<poolie> opinions may vary on whether this is clarity or overhead :)
<lifeless> AfC: its bzr-git that you'd need to tweak/change not dulwich :)
<spiv> Yeah, at least when one of those steps is targetted to a milestone and others aren't...
<lifeless> poolie: I think that when it helps us its clarity.
<AfC> lifeless: good to know. I had to package & install to system to use it, me not being a sophisticated pythonista
<poolie> exactly
<AfC> lifeless: but meanwhile bzr-git is crashing, so I give up.
<AfC> Data point: git clone gtk+ took 25m17s
<lifeless> AfC: at least file a bug on bzr-git. I bet you're pulling from some place jelmer has forgotten about
<poolie> afc, please put the traceback in a bzr-igt bug
<lifeless> AfC: what url did you get bzr-git from
<poolie> spiv, so what did the news or merge for the branch you have sent say?
<AfC> lifeless: um... info says http://bazaar.launchpad.net/~bzr/bzr-git/trunk/ and history says ... lp:bzr-git
<poolie> 'partially fix ....'?
<AfC> lifeless, poolie: ok, will do later today.
<spiv> poolie: right
<spiv> +* Prevent some kinds of incomplete data from being committed to a 2a
<spiv> +  repository, such as revisions without inventories or inventories without
<spiv> +  chk_bytes root records.  Partially fixes #406687.
<spiv> +  (Andrew Bennetts)
<poolie> i guess the operational change i'm suggesting is to never say (in news, merges, proposals) "partially fix blah"
<poolie> split it and then totally fix the split off bit
<poolie> if you see what i mean
<spiv> Yeah.
<lifeless> poolie: so, this may mean larger landings
 * SamB_XP wonders why you people are all green
<lifeless> or more landings that do things without references to bugs.
<fullermd> SamB_XP: It's not easy.
<SamB_XP> *groan*
<spiv> I'm not sure if that will *always* fit well, but maybe I'm wrong.  I'm happy to try that out.
<SamB_XP> I don't know what you mean
<lifeless> AfC: and what revno do you have?
<spiv> (I'm sure it will often work well, though)
<poolie> as (i think) Orwell said, 'break any of these rules rather than doing something barbarous'
<lifeless> I would like to understand the concern about what spiv did though
<AfC> lifeless: trunk 603. 0.4.1 whatever the tag said
<spiv> Right.  I think "make separate bugs rather than write 'partially fixes'" is a good default policy.
<spiv> What should I do about the landing that's in-flight?  Just let it be, I suppose.
<lifeless> AfC: what does bzr help plugins show
<lifeless> spiv: pqm is disabeld
<lifeless> we're upgrading to 2a
<SamB_XP> hoooray!
<spiv> lifeless: right, which means the flight-time is going to be quite long :)
<fullermd> Gotta be a way to plug that into the VCS/airlines thing   :p
<lifeless> AfC: it should list a directory that bzr-dif is being loaded from
<lifeless> bzr-git, I mean
<lifeless> I kindof think we should have one bug filed per thing a user reports
<poolie> lifeless: am i right in thinking you agreed with robert on what to do with recombining groups, bug 402652?
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652
<AfC> lifeless: you meant `bzr plugins -v` I assume. It says 0.4.1, from the .bazaar/plugins symlink, which points to my 0.4.1 branch
<lifeless> and not use the bug tracker as a proxy for merges; merges are merges.
<spm> lifeless: poolie: the check came back with "found error:Internal check failed: revno does not match len(mainline) 1649 != 1674" istr vila suggested just running reconcile would fix same?
<poolie> i think that's right
<spiv> poolie: lifeless usually agrees with himself ;)
 * AfC thinks we should discuss bzr-git another time. I think you guys are doing something more important and I don't want to distract you
<poolie> about the check
<lifeless> spm: run bzr reconcile in that dir; it will say it fixes the branch, then hit ctrl-c
<spm> lifeless: oki
<lifeless> AfC: yeah bug filing time
<poolie> lifeless: about whether issues are change requests or user issues or what; um, it's a very open question but i think in this case the balance is wrong
<lifeless> specifically, I don't see any tension between saying you're working towards a bug and landing some code
<poolie> i'm not saying strictly 1:1 bug with changes
<poolie> me either
<poolie> however, he's done more than that here
<lifeless> if its because you want to untarget the bug; I'd just untarget the bug. *My* intent when I filed it was that the larger fix is what we'd do for 2.0
<poolie> it's not
<lifeless> ok
<spiv> poolie: I'm going to file a new bug for the smaller fix; link to it from the existing bug, and replace the 'partially fixes <old bug>' in that NEWS entry with the new bug.
<poolie> i do think it's possible in principle that we could decide only part of the change was needed
<poolie> and in that case having them separate would help
<poolie> cool
<spiv> In an ideal world, splitting (and joining) bugs would be an easy operation (and create no confusion).
<lifeless> so, I think the confusion is that 'work' and 'requests' are different here. AFAICT its only the desire to be able to talk about the work later, to either show we did it, or to show someone that suffered it and wants to know if there is a fux, that drives the idea of assigning a new label
<poolie> lifeless: so, re bug 402652?
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Fix committed] https://launchpad.net/bugs/402652
<lifeless> poolie: we're working on it
<SamB_XP> lifeless: or show *what* you fixed
<poolie> lifeless: i basically agree; maybe i'm putting more value on those things than you do
<lifeless> SamB_XP: the merge log does that
<spm> lifeless: interesting. never said it was fixing. just did it's thing. "Reconciling branch file:///home/pqm/archives/thelove/bzr/0.8/ ;;revision_history ok.;; Reconciling repository file:///home/pqm/archives/thelove/bzr/ ;; Reconciliation complete"
<lifeless> spm: well, goodo
<lifeless> next
<spm> check again?
<lifeless> yes
<lifeless> we cycle until check is clean
<spm> wfm as a plan
<lifeless> but let us know when its not to think about how to handle
<lifeless> there are some things we might say 'meh' to
<lifeless> check and reconcile are not ideal yet.
<spm> 'k will do
<spm> ie play it safe; anything unusual pls to be asking loudly kthx
<lifeless> 7.5K to go
<jml> lifeless, lunch tomorrow sounds good.
<spm> lifeless: poolie: check still going. the previous check fail has passed this time (post reconcile) so looking good
<RenatoSilva> I have a speific code that I think was introuced in some revision? Anything better than bzr log -p | grep -n 'code' to find the revision?
<lifeless> bzr search some things from the code
<fullermd> I'd find a rev that has it and use annotate, if the former is easy.
<RenatoSilva> lifeless: how to make it search?
<lifeless> RenatoSilva: via the bzr-search plugin, however it sounds like you don't have that, so log -p | grep is fine too
<RenatoSilva> ok
<spm> lifeless: poolie: that check has finished. no issues. https://pastebin.canonical.com/21777/  I'm about to be afkingfor the school run, so can continue when I get back?
<lifeless> ok
<lifeless> bah 4 hours to go on this export. sheese
<fullermd> And you're already a bunch of hours ahead of most of the world.
<lifeless> fullermd: 121G of fast-export stream so far
<lifeless> fullermd: from 1 .7G hg repo
<fullermd> Better your IO subsystem than mine.
<bob2> your poor laptop
<fullermd> So, is this thing you're doing with spm now theoretically the Big Switch, or just testing in anticipation of?
<jml> I really want to read and summarize the test speed thread
<jml> sadly, I have other things to do
<lifeless> bob2: this is on my i7
<lifeless> bob2: my laptop ould have run out of disk.
<lifeless> fullermd: Biggus Switchus
<lifeless> jml: heh. Trials n Tribunals.
<jml> yeah
<lifeless> there is a time to talk, and a time to do.
<lifeless> jam: your branch has tests.
<lifeless> jam: I'm not sure whats missing, looking at it
<jam> lifeless: well, the fact that the test passes with "if len(factories) == 1" rather than "if manager.check_is_utilized()" is one of them
<jam> so we don't have a test that insert_record_stream uses the right functionality
<jam> anyway, /me => bed
 * vila waves at jam !
<fullermd> Bed?  The sun isn't even up yet!
<AfC> I am SO pleased to read that poolie's "heart rate" is going up, and that he's getting "excited".
<spm> poolie: lifeless: shall we continue?
<lifeless> AfC: ?
<lifeless> spm: yes
<spm> lifeless: cool. so next step: I assume is the bzr upgrade --2a ?
<AfC> lifeless: From: Martin Pool <mbp@canonical.com>  Message-ID: <e01316480909022053n78bb7eci7a98f981a5b77b97@mail.gmail.com> Subject: Re: metronome mail for Bazaar 2.0 and 1.18
<poolie> spm, hi
<poolie> afc, i can't tell if that was sarcasm or not
<spm> poolie: heyo, so dunno how much of the above you saw? but we're all ready to roll.
<AfC> poolie: it was humour, yes.
<poolie> iow you're not pleased?
<poolie> spm, i think i saw all of it, and the next step would be to do the upgrade
<poolie> so let's do it!
<AfC> poolie: I thought it was funny. What comes next after "increasing excitement"? By the time you guys release, you're going to be talking about "orgasms", I'm sure.
<poolie> ok
<poolie> it was meant to be a bit funny
<AfC> then good!
<spm> poolie: 'kk. I'll give you all 10 seconds to cross fingers, arms legs, then I hit enter. starting.... now.
<poolie> a dryer way to say it is that when there's more release-related activity we should say more about it
<AfC> poolie: dry, yes. Interesting, no
<spm> hahahahahaha. bzr: ERROR: File exists: u'/home/pqm/archives/thelove/bzr/backup.bzr/': [Errno 17] File exists: '/home/pqm/archives/thelove/bzr/backup.bzr/'
<AfC> You know the Bazaar hackers are working too hard when humorous replies to funny emails fall flat.
<poolie> drier*
<poolie> :)
<AfC> You guys really need to teach bzr not to repeat itself.
<poolie> no, just checking
<AfC> yup
<poolie> i think in a sense releases, or the process of releasing, should be boring
<poolie> you should get more satisfaction from improving things and then getting it out is just a natural consequence
<spm> speaking from an operational side, couldn't agree more - releases should be boring.
<AfC> poolie: "should be boring". That makes it official. You're now a corporate worker slave
<poolie> it's like being excited about getting to a concert on time, not the performance itself
<SamB_XP_> the release should be exciting
<SamB_XP_> ... to the users who get to use all the cool new doodads
<poolie> btw that error, i agree it looks lame
<poolie> it's actually python doing it, and the behaviour varies per python release
<poolie> so while we could eliminate it, it's nontrivial to do it correctly
<poolie> and make sure it's shown just once on all versions
<poolie> it would make a good personal-pleasure bug
<lifeless> spm: so bzr upgrade --2a in the root
<lifeless> spm: and in each branch
<lifeless> poolie: are you doing escudero ?
<lifeless> poolie: or is spm, or its been forgotten ?
<spm> err. poss the latter.
<lifeless> spm: there is a repo on escudero needs the same treatment
<lifeless> spm: and we'll have to do the 1.17/1.18/2.0 branches on lp too
<spm> lifeless: flip side, I have almost no access on esco itself - only via balleny
<lifeless> ok
<lifeless> I'll ssh in
<spm> rephrase - can login look around; but nothing special
<lifeless> 1.17, it'll do
<lifeless> bzr check under way
<lifeless> spm: now, for bzr.dev, we're going to change where it points at at the same time
<spm> lifeless: oki
<igc1> any windows users online right now?
<poolie> hi igc1
<igc> hi poolie
<lifeless> lamont: did you upload subunit to karmic this morning? If so thanks :)
<lifeless> lamont: I was going to release 0.0.2 before asking for a FFe :>
<spm> lifeless: what's the preferred way of u/ging the required branches on LP? I assume we can take a branch from the newly upgraded (or use the existing subdir in the shared repo) and delete old/push that? or?
<lifeless> ok its a little complex.
<lifeless> uhm
<spm> heh
<lifeless> there's a guide
<lifeless> but lets toss that out the window
<lifeless> is bzr.dev upgraded ?
<spm>  <smash?
<spm> not yet.
<spm> Transferring revisions 9600/27302
<lifeless> when it is, do the following.
<lifeless> bzr init --2a lp:~launchpad-pqm/bzr/bzr.dev   [adjust the user if I got it wrong]
<spm> 'k
<lifeless> then bzr push the bzr.dev branch there using --remember so it sticks
<lifeless> thats probably a Good Time to change the bzr pqm config too, for bzr.dev
<spm> this is from ~/archives/thelove/bzr ? vs one of the subdirs
<spm> right
<lifeless> the subdir +trunk
<spm> ah. righto
<lifeless> then
<lifeless> in the bzr project on lp
<lifeless> change the branch for the trunk/bzr.dev series to point at this new branch.
<spm> k
<lifeless> now, if we're lucky, we can just delete the other launchpad-pqm owned branches and repush them.
<lifeless> if we're unlucky we can either rename-and-push, or we can bzr upgrade --2a <URL> them
<spm> but the key is the bzr.dev; right. makes sense. stacked on I assume.
<spm> ew
<lifeless> yes, for all new things pushed
<spm> right
<lifeless> once escudero is upgraded, all the old branches will suddenly start crying
 * spm fetches a box of tissues
<lifeless> elephant tears
<spm> 3 boxes of tissues
<vila> hi all
<spm> hey vila
 * vila forgot to unmark as away...
<poolie> spm, we're talking about it...
<spm> poolie: np
<spiv> lifeless: I wonder how changing the branches on lp like that will interact with the merge proposals against the existing lp:bzr?
<vila> spiv: stop beating the dead horse :)
<lifeless> spiv: they will need to be resubmitted
<vila> I'm 95% sure we need to resubmit them anyway after having been upgraded
<SamB_XP_> spiv: they'll suddenly be against lp:~bzr/bzr/???, I guess
<spiv> Ok.  That's a shame (but not a show-stopper).
<vila> spiv: The way I see it is that we're changing the devlopment focus, so lp:bzr gets a new semantic, mp were done against the old one, *something* has to be done, I don't think this can be automated
<lifeless> vila: oh it would merge ok
<lifeless> vila: but the trunk url config is changing
<vila> mmm
<spm> Transferring revisions 11100/27302 <== this may take a while I'm thinking...
<lifeless> spm: no
<lifeless> spm: time stands stil
<lifeless> l
<lifeless> l
<lifeless> l
<lifeless> l
<spm> heh
<lifeless> I'm setting up a new 1.9 format mirror of bzr.dev to become the new trunk for all the old stacked branches
<lifeless> poolie and I just discussed some of the merits of different ways of tackling this
<lifeless> we're going to keep them working, for now at least.
<spm> oki
<lifeless> 4.5K to go
<jml> oh, that reminds me
<lifeless> .oOo.
<jml> (the ohloh LP enlistment is moving very very slowly)
<spm> I'm going to afk and grab an early dinner (curry made last night - should be nicely improved by now). if you need me in a hurry, ring my mobile, or home phone.
<lifeless> jml: \o/
<lifeless> jml: where is it up to ?
<jml> lifeless, 8248/66451
<lifeless> spm: I'm basically EOD'd: when that completes please SMS me or wave furiously or something.
<jml> lifeless, it was at ~6500 this morning
<lifeless> jml: holy swear words bat man
<lifeless> _what_ command are they running
<jml> lifeless, Launchpad doesn't track that, you'd have to ask them :)
<lifeless> jml: how does launchpad track the enlistment ?
<jml> lifeless, it doesn't. my data is from, https://www.ohloh.net/p/launchpad/enlistments
<lifeless> jml: k
<SamB_XP_> ooh! how did you ever get access to that information!
<jml> lifeless, I guess someone who knows bzr could maybe derive the command from the apache log
<SamB_XP_> </fake-awe>
<lifeless> SamB_XP_: its on the page :P
<spiv> http://www.ohloh.net/forums/3491/topics/3685 claims they run "bzr log --long --show-id --forward --include-merges -r 1.. -v"
<spm> lifeless: oki, will sms
<lifeless> poolie: I believe there is a cron job donig 'bzr update' in the bzr.dev tree on escudero.. what account is that under - can you cancel it ?
<poolie> i don't recall, but yes i can
<poolie> .. find out and cancel it
<lifeless> spm: ~bzr-pqm is the user I think
<lifeless> spm: has it converted yet ?
<spm> lifeless: yeah, that sounds more sane
<spm> nope. 14000
<poolie> done
<spm> just over half way
<spm> lifeless: so guestimating.... about another hour.
<poolie> spm: to upgrade? that seems slower than it was for me
<lifeless> poolie: much older machine
<spm> poolie: about 2 hours in total.
<lifeless> balleny is uhm 3.5? 4? years old
<spm> AMD Opteron(tm) Processor 250
<spm> single cpu, no cores.
<lifeless> 1 core !
<spm> almost as old as me and vila!
<spiv> no cores would explain slowness ;)
<jml> does bzr actually use more than one core for upgrading?
<lifeless> jml: no, but other things can
<spm> anyways - back to cooking poppadums - and trying not to eat them all as they emerge.
<vila> spm: you mean me *+* you :)
<vila> spiv: right, they finally found the worst way ever to use bzr log :-)
<jml> vila, you should comment on the thread :)
 * jml was quite impressed with ohloh's friendliness and willingness to actually do stuff to support bzr better.
<SamB_XP_> jml: well, there sure were a lot of people asking for bzr support!
<SamB_XP_> ... how does one get a CPU with no cores ?
<SamB_XP_> ... what does it *do*?
<LarstiQ> jml: when was this? they ignored bzr for a year or so
<SamB_XP_> LarstiQ: I think the proper term is "were swamped"
<SamB_XP_> not "ignored bzr"
<LarstiQ> SamB_XP_: ok, let me rephrase that. Despite a lot of people asking for support, and some offering help, I have never seen a public statement from ohloh on the issue.
<LarstiQ> but maybe I don't care about their site enough
<SamB_XP_> there aren't very many of them!
<LarstiQ> SamB_XP_: not enough to reply on the forum thread?
<jml> LarstiQ, well, they've supported bzr for a while
<jml> LarstiQ, but they replied quite quickly to my thread about Launchpad open sourcing
<bialix> bonjour vila
<vila> hello Alexander
<LarstiQ> jml: cool
<LarstiQ> jml: yeah, my disappointment is from the period before they supported bzr
 * LarstiQ lost interest on the way
<jml> heh
<bialix> morning knows better than night, I've decided that much simpler for me will be to write special hidden command which invokes get_user/password methods for me
 * jml likes that expression
<vila> *commands* ? Wow, I'm lost here, I really need to read the code you will write...
 * vila upgraded 1/3 hosts, fully checked
<bialix> vila: ^, so I won't need to lookj for real svn repo to test
<bialix> vila: ?
<vila> And you will have automated tests then ?
<vila> Oh I got it !
<bialix> vila: heh, you're really out of context
<lifeless> jml: it saddens me to hear that lp doesn't use pqm's test facilities at all :(
<bialix> vila: :-P
<bialix> no automated tests yet
<vila> you will fake the svn repo behavior to ensure you can catch get_password/get_username ?
<bialix> yes!!!
<vila> bialix:  but if you do that you're '' close to have automated tests !
<jml> lifeless, well, it's much more a function of our terrible test suite rather than anything in pqm
<bialix> vila: I need to test that our SubprocessUIFactory in QBzr works OK for get_user et al methods for subprocessed bzr command
<lifeless> jml: I'm still sad though
<jml> lifeless, sorry :(
<bialix> vila: it will be pain to properly write automated test
<vila> You already suffered for not having an automated test for that !
<jml> lifeless, tbh, it doesn't sadden me, it just annoys me constantly. I really miss the days when someone trying to land a failing branch meant that only that person had to care about the failed attempt.
<vila> Not writing it now, when you got the concept clearly in your head... is a bit like not making the one missing step to get there :-/
<jml> (whether that person was me or someone else)
<vila> you want to write an hidden command, I say this hidden command can be part of your test framework
<vila> bialix: Where will you write that command otherwise ? In a plugin ?
<lifeless> jml: I hear you have Influence now
<jml> lifeless, I don't have magical powers though.
<lifeless> jml: cow
<lifeless> [have you seen apt cow?]
<jml> lifeless, my influence on this kind of thing is the same as it always was.
<lifeless> I know
<jml> [I have!]
<lifeless> I was teasing
<lifeless> 4K revisions to go
<lifeless> and then I can put my new memory in!
<jml> lifeless, if we could test and land a new LP branch in under 15 minutes, I would argue for switching back to PQM
<bialix> vila: one day I bribe you to help properly set up test suite for QBzr based on QTest
<bialix> :-P
<vila> :-D
<bialix> testing GUI is not easy
<jml> lifeless, but as it stands, I think the current (flawed) system is better than the massive queues we had with a traditional PQM set up.
<vila> bialix: I hope to meet you at one bzr sprint one day....
<bialix> me too
<lifeless> jml: me too
<vila> bialix: 'testing GUI is not easy' that's why you should test at lower levels :-P
<bialix> vila: rrrrrrr
<bialix> vila: but I need test high level interactions!
<vila> bialix: You can't get robust walls if you don't use robust bricks
<bialix> vila: when you will have a 5 minutes to relax, look into qbzr/liv/subprocess.py SubprocessUIFactory
<spm> 19000/27302 ... getting there....
<vila> Start with robust bricks and your walls will be solid enough even if not tested
<bialix> vila: I'm amazed
<vila> the opposite is a dream, a nice dream, but a dream anyway
<vila> Obviously my english is not good to explain that :-/
<bialix> I like dreams
<vila> Obviously my english is not good enough (not are my typing abilities :) to explain that :-/
<bialix> and my french even worse than your english
<vila> want to hear my russian ?
<vila> :)
<vila> na gavariu pa ruski
<bialix> :-) :-)
<bialix> LOL
<bialix> ne
<vila> bialix: exactly ! :-D
<vila> 3 words and 1 mistake already !
<bialix> your russian is better and better every time! :-D
<bialix> vila: writing tests is good, and like them, but for QBzr sometimes is much faster to write bugfix w/o tests
<vila> bialix: so, why don't you just copy/paste get_password in subprocess.py (and update whatever corresponding code that handles GETPASS) ?
<vila> bialix: It's always faster to write the bugfix without tests
<bialix> and because I have not infinite amount of free time I have to choose between bugfix w/o test and no bugfix at all
<vila> What takes more time it to reproduce the bug so you can diagnose it to be able to write the bugfix :)
<vila> And if you write down how long you spend on the respective tasks... at one point you realize that writing tests saves a lot of time. And if it doesn't... you have to learn how to write better tests :)
<bialix> to reproduce THAT bug I need to find such svn repo
<vila> bialix: wrong
<bialix> vila: I hear you! I hear you! I believe you! But I have reason to do otherwise
<vila> You know you need to implement get_username, do that, test it, ask the people encountering the bug to check your fix :)
<bialix> more: I share your belief in tests
<vila> if you tested it correctly, you're 99% sure they will come back to tell you: "Great ! It works ! Thanks !"
<bialix> aaaaaah!
<bialix> vila!
<poolie> hello, vila, bialix
<vila> hye poolie
<bialix> hello
<bialix> poolie: I have a question about traceback generator code
<bialix> poolie: I have a question about traceback report generator code
<poolie> sure
<bialix> https://bugs.launchpad.net/bugs/423221
<ubottu> Launchpad bug 423221 in qbzr "External diff no longer works" [Undecided,New]
<bialix> poolie: ^, if you llok at the bug report generated by bzr you'll see there is bencoded dict passed as argument
<poolie> bialix: sorry i don't see the connection?
 * igc dinner
<bialix> err, bencoded list
<poolie> oh, right
<bialix> what can I do to decode it for easy understanding?
<bialix> some hook into trace.py maybe?
<bialix> any advice?
<poolie> so
<poolie> i guess this is obvious, but it's not the trace code that's doing the encoding
<poolie> it's the qsubprocess or whatever
<bialix> no
<bialix> yes, this string generated by qbzr internals
<bialix> I just think for me will be nice if qbzr devs see not only raw string but also decoded list
<poolie> from the command line you can say something like this:
<poolie> python -c 'import sys;from bzrlib.util.bencode import bdecode;print bdecode(sys.stdin.read())'
<poolie> but i can see how putting it into the bug report would make something easier
<poolie> how about if
<bialix> yes, exactly
<poolie> we add another line of output that's called something like decoded_arguments
<poolie> and we call a function in trace.py that can optionally return different more readable arguments
<poolie> then it can look for a --bencode option?
<bialix> that will be great
<bialix> maybe just provide hook point?
<poolie> right, then the plugins could hook it
<bialix> may I file this feature request as bug report?
<poolie> of course
<poolie> um
<bialix> thanks
<bialix> um?
<poolie> my only concern would be, at the time we've already crashed
<poolie> the more code we call, the more likely it is that something else will go wrong
<bialix> yep, this is a problem
<poolie> for instance if one of the plugins isn't installed properly, calling this hook might break something more
<bialix> heh
<poolie> and prevent us getting a traceback at all
<poolie> that probably wouldn't happen in most cases
<bialix> I'll ask gary for his mind
<poolie> i think that string is fairly readable once you know a bit about it
<poolie> about bencode
<poolie> we should test if apport will work ok on windows
<bialix> because we have special code to show qbzr tracebacks in GUI dialog, maybe we just override it
<bialix> poolie: apport on windows? you want real testing? any pointers on how to setup it?
<bialix> igc working on better installer
<bialix> because I'm fan of bzr.exe I need apport working with bzr.exe
<poolie> i think that if you just install it from https://launchpad.net/apport
<poolie> then bzr will try to use it
<poolie> then do something like 'bzr assert-fail' or make it crash in some other way
<bialix> at which level bzr hook into apport?
<poolie> when we want to report an error, we try to import appotr
<poolie> apport*
<poolie> and if we can, we use that to write the error to a file, rather than printing it ourselves
<bialix> is it invoked as subprocess?
<poolie> no, just as a python library
<bialix> this won't work for bzr.exe
<bialix> it should be bundled inside it
<poolie> oh?
<poolie> right, but we could bundle another python library into it?
<bialix> or there is should be plugin to setup sys.path
<bialix> bundle into bzr.exe? yes, but it makes it a bit bigger
<poolie> that's true
<vila> lifeless: one more mp vote where you forgot the leading space
<poolie> it's probably not very big
<bialix> how big apport is?
<lifeless> vila: someday it will listen to me
<bialix> I'll look if I can wrap apport into plugin
<vila> LOL
<poolie> 332k
<poolie> we could cut out only the bits we need, which is probably less than half
<bialix> well, py2exe is very good in tracking actual import dependencies so it will pick only required modules
<bialix> but py2exe don;t know about lazy_imports
<poolie> in this case it's not lazy
<bialix> igc: can you look into bundling apport into bzr.exe? just installing it in your python will be enough
<poolie> it's imported inside the function that uses it, but py2exe should be able to handle that
<bialix> poolie: so, what I should expect when apport is working?
<bialix> how I can see it actually working ok?
<poolie> try 'bzr assert-fail' and rather than a traceback it should tell you the location of a crash file
 * bialix get lp:approt
<bialix> poolie: bzr: ERROR: Unable to create symlink 'data/icons/scalable/mimetypes/text-x-apport.svg' on this platform
<spm> poolie: fyi: Transferring revisions 20000/27302
<bialix> poolie: I'm unable to get apport sources
<lifeless> 3K to go, 126G
<lifeless> you can do itm 128G FTW
<poolie> bialix :/
<poolie> there is a tarball
<poolie> sorry about the symlink bug
<poolie> i tried it under wine and it didn't work well
<poolie> i have to go now, i may be back later
<vila> spm: just checking pqm mail submissions are disabled right ?
<poolie> i'm not sure why eithr
<bialix> C:\work\Bazaar\zzz\apport\apport-1.8>setup.py bdist_wininst -d.
<bialix> To build Apport you need https://launchpad.net/python-distutils-extra
<bialix> huh?
<bialix> poolie: no way for apport today, too much obstacles
<vila> dependencies.... salt of the earth :-/
<bialix> poolie: and you say that installing windows dev tools is tricky!
<bialix> comparing to apport it was easy
<spm> vila: aye
<vila> bialix: that's certainly a *big* difference between windows and linux and linux devs tends to be used to automatic depedency tracking: you want a tool, you install it, if dependencies are needed, they are taken care of automagically
<spm> vila: we've still got a ways to go on the 2a upgrade. so the pqm processing is disabled
<vila> spm: sure, I understand that,
<vila> fully
<spm> cool :-)
<vila> upgrading my various dev hosts too just to shake things a bit more
<bialix> vila: I see how easy it may look, but I prefer to understand what's going on
<vila> by doing it at the same time
<bialix> this one reason why I hate eggs
<vila> bialix: but you don't need to care anymore once you use a distro where people's work is to make damn sure the dependencies are right
<bialix> I don;t want to talk about it
 * bialix bbl maybe
<vila> ok, np
<vila> james_w: ping, strangeness here: https://code.edge.launchpad.net/~debian-bazaar/bzr-gtk/debian the last commit is by you and says 'works with bzr-1.19' ?? and lp can access it since 2009-09-01
<spm> Transferring revisions 24700/27302
<spm> thumb twiddling excitement :-)
<jml> :D
<jml> hmm.
<jml> spm, by my calculations, ohloh's import of Launchpad should be finished by the 13th.
<spm> jml: which year?
<jml> my bad.
<jml> spm, I meant to say, "the 13th century AD"
<spm> when the universe wraps around again?
<lifeless> 2.2K
<lifeless> 127G
<lifeless> jam: I won't get to the group combining patch today
<james_w> vila: the branches were upgraded
<james_w> vila: the commit message is a typo
<vila> james_w: ok, which branches upgraded to what ?
<james_w> debian branches to 2a
<vila> oh great
<lifeless> igc: does fast-import get multiple branches?
<vila> james_w: so the lp branch should be re-created ?
<james_w> I guess
<james_w> it looks like LP doesn't like mirrored branches being upgraded
<lifeless> james_w: it should remirror
<lifeless> jml: ^
<jml> what
<jml> yes, it should.
<vila> remirror as opposed to ?
<lifeless> vila: error ? :P
<lifeless> vila: lp is meant to delete its copy and start over when the format doesn't match
<vila> lol, no, the question was, was is lp doing right now ?
<vila> ha ok
<jml> my understanding of the code is that it should be doing that.
<jml> what's actually happening?
<vila> jml: lp says This branch may be out of date, because Launchpad has not been able to access it since 2009-09-01
<vila> https://code.edge.launchpad.net/~debian-bazaar/bzr-gtk/debian
<jml> hmm
<lifeless> now, I filed a bug about it /not doing/ this, but mwhudson/jml seemed convinced it was only a scanner issue at the time.
<spm> poolie: lifeless: 'repository converted'
<lifeless> ok, push trunk to ~bzr-pqm/2.0
<lifeless>                ^bzr
<lifeless> bleh
<lifeless> spm: I fail.
<spm> is cool - I get the gist :-)
<jml> hmm
<lifeless> spm: to ..bzr.dev
<lifeless> spm: not to 2.0
<lifeless> trunk is bzr.dev :P
<spm> ahh. no didn't get that gist. right. lemme run the cmd line past you first. one sec...
<jml> so, while I don't dispute that the bug is occurring
<jml> and that it's probably in the puller
<jml> if you look at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/annotate/head%3A/lib/lp/codehosting/puller/worker.py and grep for 'format', it's hard to see what's wrong
<spm> lifeless: ~/archives/thelove/bzr/+trunk$ ...<funky_path>/bzr push --remember bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr.dev
<lifeless> no
<lifeless> ... bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<spm> gah. missed that. sorry.
<spm> lifeless: ? https://pastebin.canonical.com/21784/
<lifeless> https://edge.launchpad.net/bzr is kinda ugly @ 800 wide
<lifeless> thats good
<lifeless> now do it again
<spm> oh? ok.
<spm> well <....> me. is working.
<lifeless> stacking
<lifeless> fails
<lifeless> then exists so doesn't alter the setting
<lifeless> iz UI bug
<spm> ah. perhasps a nicer error message would help? :-D
<spm> snap :-)
<lifeless> yes
<lifeless> critical, not blocker
<spm> right
<spm> kinda like being a windows sysadmin again. if something fails, try it exactly the same way a 2nd or third time. usually works then. :-D
<lifeless> oh don't say that
<lifeless> thats nasssty
<spm> Created new branch.
<spm> nasty. maybe. accurate tho.... /cynical
<lifeless> ok
<lifeless> now I'm going to change trunk to point at the 2a format branch
<spm> 'kk, and likewise am modifying trunk in pqm config
<lifeless> ok, escudero's bzr.dev is now a branch alias
<spm> publish_to=bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<spm> published_at=http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<spm> sane ^^?
<lifeless> is that analagous to 1.18?
<spm> copy'n'past'nmodify, yup
<lifeless> spelling etc optional
<lifeless> kk
<lifeless> doit
<spm> ZZ
<lifeless> now, to update the 2.0 bzr-pqm branch
<lifeless> want to do this the easy way?
<spm> 7.30pm? whadda reckon? :-)
<lifeless> got lftp there?
<spm> errrr...
<lifeless> [it does sftp]
<spm> yes!
<vila> spm: not windows related (if it fails, try again), I used to do that in GCOS days
<lifeless> lftp sftp://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> rm -rf .bzr [in lftp speak,w hich I forget offhand]
<Spabby__> hi guys is there a yum repo that has a newer version of bzr than the epel one please?
<lifeless> \o/ 128G fastexport stream from netbeans hg repo
<spm> lifeless: this'd be in the 2.0 dir I assume? or move existing to one side and create a new.
<spm> on nm. I'm being dense.
<lifeless> spm: we're deleting the 1.9 format history on lp; replacing it with the updated master copy.
<lifeless> Spabby__: http://bazaar-vcs.org/Download
<lifeless> has a yum repo listed
<Spabby__> yes
<spm> right - yeah - worked that out. was thinking in terms of copy down.
<Spabby__> but the version is 1.3.1
<Spabby__> which is really old
<Spabby__> it's the epel one I mentioned in my initial question
<lifeless> Spabby__: oh, I did'nt know that
<spm> lifeless: so. .bzr rm'd from baz.lp.n/~bzr-pqm/bzr/2.0
<lifeless> I'm sorry, I don't know know of others
<lifeless> spm: cd to the 2.0 branch; push it, with --use-existing-dir
<spm> lifeless: to confirm: .../thelove/bzr/2.0$ /srv/pqm.ubuntu.com/chroot-amd64/home/pqm/bzr-2.0/bzr push --use-existing-dir
<lifeless> spm: also, remember the 2.0 review team change?
<lifeless> we need to do that here as well
<lifeless> spm: ack
<lifeless> to the bzr.dev branch
<spm> lifeless: vaguely - that was in the LP ui from memory? change to ~bzr-devs or similar
<lifeless> bzr-core
<lifeless> yes
<spm> right
<lifeless> https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev
<spm> Using saved push location: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0/
<spm> Source branch format does not support stacking, using format:
<spm>   Branch format 7
<spm> Using default stacking branch /~bzr-pqm/bzr/bzr.dev at lp-45207760:///~bzr-pqm/bzr
<spm> Created new stacked branch referring to /~bzr-pqm/bzr/bzr.dev.
<spm> looks good
<spm> lifeless: review team changed to bzr-core
<lifeless> spm: ok
<lifeless> spm: repeat the 2.0 process on the other existing bzr-pqm branches
<lifeless> I think thats 1.17 and 1.18
<lifeless> unlock pqm
<spm> phew. for a minute there I thought you meant 0.1 to 1.18 :-)
<lifeless> and thank you, We all appreciate your doing this late :)
<lifeless> I'll write up docs to the list
<spm> ta
<vila> spm: I second that: T-h-a-n-k y-o-u
<lifeless> its kinda snappy in loggerhead now
<lifeless> :P
<spm> 1.17 done (damn this is faster the 2nd time)
<lifeless> spm: yupyup
<spm> 1.18 done
<spm> so if ya'll feeling brave, we can re-enable PQM then?
<lifeless> DoIt
<vila> https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0 still says Repository format:  	Packs 6 (uses btree indexes, requires bzr 1.9)
<vila> https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev is fine
<lifeless> vila: check http with bzr client
<spm> bzr pqm, re-enabled
<lifeless> super
<vila> lifeless: you're right, bzr client reports the right format, the web site lags ?
<lifeless> vila: scanner bug
<spm> cache?
<spm> shouldn't be replication lag. that's < 5 secs
<lifeless> spm: metadata cache in lp
<spm> figures
<lifeless> spm: its coherency bug
<lifeless> filed, queued.
<vila> I'd say data in some table extracted from .bzr and either not updated or not refreshed (I hope it's the later)
<spm> lifeless: I look forward to your patch for same tomorrow morning. :-P
<lifeless> spm: filed some months ago
<spm> anyways. anything else at this stage? leave it for vila to break overnight?
<vila> on my way to submit a simple patch to bzr.dev :-D
<spm> hahahahahah
<vila> 1) upgrade the local integration branch :)
<vila> 0) upgrade the bounded stacked branch
<lifeless> 1.5K to go
<spm> oki, outa here. night all.
<lifeless> thanks again.
<alex_morelli> a good day to all
<alex_morelli> I need some help with a OSX 10.4 installation: even after installing Python 2.6.2, the installer complains of an incompatible version and asks me to install Python 2.6
<alex_morelli> do I need to reboot after installing Python?
* lifeless changed the topic of #bzr to: Bazaar version control system | bzr.dev is in 2a format | 1.18 final released soon | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<alex_morelli> someone can help me?
<lifeless> alex_morelli: I would sorry, but I am really not here :(
<lifeless> vila: ^
<lifeless> any idfeas?
<jelmer> fetch from hg into bzr seems to somewhat work now with current versions of bzr and hg
<james_w> \o/
<lvh> yay, finally we can throw hg away
<jml> jelmer, grats
<lifeless> 133304/133780, 129G
<lifeless> so very very close
<lifeless> 138378654414 - netbeans fastexport
<lifeless> igc: ^
<ronny> lvh: evil ...
<lvh> ronny: haha
<ronny> well, i guess i'll have to do a sprint on hg-bzr next week
<lvh> don't mind me, I'm just trolling
<ronny> hmm, bzr is starting to spit into my waters (with all those abstractions)
<ronny> but i dont see me wanting to use bzr's api anytime soon
<ronny> brb, food
<lvh> ronny: that's okay, I feel very much the same way about hg's api
<lvh> oh wait, I'm not supposed to use hg's python api because it's not public :-)
<jelmer> lvh: mercurial's API doesn't have the abstractions that bzr's API has
<jelmer> lvh: for better or worse
<lvh> jelmer: I'm mostly talking about hg.ui.ui()
<lvh> err, mercurial.ui.ui() probably :-)
<lvh> jelmer: every time I moan about it people tell me "yeah stop using that the api is private"
<lvh> jelmer: my reaction is to stop using hg, I like public apis
<jelmer> ahh
<jelmer> the API stability of mercurial is also a bit of a concern for bzr-hg :-/
<lvh> which API
<lvh> there is no API!
<lvh> jelmer: I ran into the same problem when making a version updater for git repos
<lvh> jelmer: eg inspect the current repo state -> produce __version__="foo" in __init__.py
<lvh> jelmer: then I noticed that hg seems to assume that you are always working interactively
<lvh> jelmer: and there is no real way aorund that
<lvh> jelmer: (But I'm not really sure -- the original/core dev told me to use os.system and parse the output, so I stopped using hg)
<jelmer> lvh: well, there is an API, just no guarantees about its stability
<lvh> jelmer: yeah, I dont think that really counts :-)
<lvh> jelmer: but sure -- there's an API, and you're not supposed to use it
<ronny> jelmer: i like the fact that its a unstable api
<ronny> jelmer: all the suckage slowly goes away, and doesnt has to stay for centuries
<jelmer> functionality is always deprecated first in Bazaar before it is removed several versions later
<jelmer> that's good for API users, but a bit of a burden on developers
<ronny> well, bzr is kind of __huge__ and has stuff spead out in unpleasant ways
<ronny> i still dont understand bzrs actual repo formats, for hg it was like read 3 files, done including backward compatibilities
<ronny> for bzr i lost interest after dozens of files, tonns of inheritance and pain
<eLBati> ciao
<eLBati> using env var http_proxy , is it possible to use username and pass for authenticate to proxy?
<vila> eLBati: yes
<vila> eLBati: Did you try ?
<eLBati> vila: yes, but I get a connection time out
<eLBati> doing bzr branch
<vila> eLBati: use -Dhttp and look at your .bzr.log to check
<vila> eLBati: if you don't understand the http headers I canhelp but be aware that your credentials will appear there
<eLBati> vila: thanks
<eLBati> vila: http://pastebin.com/m30eee712
<eLBati> someone is not responding
<vila> you didn't specify -Dhttp :-/
<vila> oh, wait, you're trying to use a lp: url, that's a known bug beehind proxies :-//
<eLBati> yes, lp
<vila> you need to use the resolved URLs instead,
<eLBati> ah
<vila> what os/versions are you using ?
<eLBati> ubuntu 8.04
<eLBati> how could I resolve URL?
<eLBati> (lp:openobject-doc)
<vila> hmm, by going to the web site,
<vila> lp:openobject-doc is bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/
<vila> or http:// instead of bzr+ssh://
<vila> eLBati: https://code.launchpad.net/openobject-doc is the entry point,
<vila> from there you get access to all existing branches in the project and by clicking on each one, you'll get a page with all the urls you need
<eLBati> thanks vila
<vila> eLBati: and the relevant bug is #186920
<ronny> btw, is there anything for bzr comparable to submodules/subrepos/externals?
<vila> ronny: nested trees, but it's still a work in progress
<NET||abuse> hey bzr folks,,, i have a site i downloaded from the server, put under bzr version control on my local drive, developed new pages for, and now I need to publish to the webserver again. is there a good way to push the code up to a server from my local machine?
<vxnick> NET||abuse: try bzr-upload
<lvh> hi!
<lvh> what's the easiest way to see the revision id's of the last past commits?
<lvh> I've tried olive-gtk but that doesnt seem to show me the revision ids.
<lvh> bzr log -l 10 or so?
<lvh> Yay, that shows revnos :-)
<jelmer> lvh: --show-ids
<eLBati> vila: http://pastebin.com/m6b8d36eb
<eLBati> with easy_install I can authenticate
<vila> lvh: bzr log -l 10 --show-ids
<vila> eLBati: bzr-1.3.1, right, I'm 99% sure this has been fixed in recent bzr version, you may want to add the bzr-ppa repository to your software sources
<eLBati> I have 1.3.1
<vila> yes, I can see that, let me find the bug
<vila> eLBati: in the mean time, look here for instructions on how to get the latest stable release of bzr: https://launchpad.net/~bzr/+archive/ppa
<gioele> hello
<vila> eLBati: bug #366107
<ubottu> Launchpad bug 366107 in bzr "Bazaar should attempt Basic authentication if HTTP server offers NTLM" [Undecided,Fix released] https://launchpad.net/bugs/366107
<gioele> vila: hi, thank you for fixing bug #423331 ;)
<ubottu> Launchpad bug 423331 in bzr-upload "Don't upload additional files in / but in another directory" [Wishlist,Fix released] https://launchpad.net/bugs/423331
<vila> so you need at least 1.15 to get the fix
<vila> gioele: my pleasure, your description made it obvious and I felt bad that I didn't realize what Alfredo was talking about :-/
<eLBati> thank you vila
<vila> eLBati: Note that using the ppa bzr archive is how we distribute the upgrades to all Ubuntu releases
<gioele> vila: one last thing: what is supposed syntax of that option? Is a simple "upload_revid_location = foo" in branch.conf is 'foo' interpreted relative to the path given on the command line?
<vila> so adding it to your software sources is the best way to get future updates as they become available
<eLBati> vila: ;)
<jam> btw, morning vila
<vila> gioele: yes, relative to the remote path, if you find a clearer way (thatn the README attempt) to explain that, patches are welcome :-)
<vila> mornign jam !!
<vila> Was about to say: Always happy to help (tm), so you were in my thoughts :)
<gioele> vila: oops, I didn't see the README file in the bzr-upload source code :(
<vila> gioele: no worries, it means we need a better way to communicate the documentation (and since the targeted audience is web developers, may be one of them will help generate some doc :) Or look into the effort led by igc to generate the html doc from the plugins... I need to check that
<NET||abuse> hmm, i've never pulled code down from launchpad before.
<NET||abuse> how do i get the plugin?
<vila> NET||abuse: which one ?
<NET||abuse> i'm looking to use bzr-upload
<NET||abuse> so they didn't have direct downloads on the site, just list the trunk in the code section.
<vila> cd ~/.bazaar/plugins (create the dir if it doesn't exist) bzr branch lp:bzr-upload upload
<vila> yeah, the plugin authors are bit lazy about distributions...
<NET||abuse> so i suppose i have to pull code down, and sure why not, i'm getting into bzr and git a bit more than svn these days.
<NET||abuse> i seem to be mixing up both from project to project, bit confusing at times.
<NET||abuse> that lp alias, can i make my own and assign it to my own launchpad installation, was looking to host my own launchpad on my webserver for the various projects i'll be buliding over the coming months/years ;)
<NET||abuse> and if it was a straight forward way to do things, it would win out as the choice over git and trac
<NET||abuse> i've already setup svn trac before for 2 projects on my site, but trac doesn't make multiple projects a very straight forward proposition.
<NET||abuse> launchpad i imagine would make things simple, as the decisions on how to sperate out projects would be kinda made for you, and launchpad on the ubuntu side works well :)
<vila> NET||abuse: try #launchpad if you want support for that, I'm sure they'll be happy to help (tm too) :)
<NET||abuse> tm?
<vila> Trade Mark
<gioele> vila: mini-bug report for bzr-upload (a these lazy users, always requesting things): #423770
<gioele> very low priority, filed just in case somebody else need it
<vila> ubottu: wake up bot, tell us about bug #423770 please
<ubottu> Launchpad bug 423770 in bzr-upload "Don't quit with "bzr: ERROR: Failure" when upload_revid_location is a directory" [Undecided,New] https://launchpad.net/bugs/423770
<vila> thanks
<vila> gioele: thanks for filing it, there is already a FIXME in the code about more tests with invalid paths, that one is certainly the most obvious error one can make... I even wonder if I didn't make a mistake in giving full control instead of just providing the directory....
<vila> NET||abuse: oh, and if you use karmic, bzr-upload is already packaged there
<kfogel> Anyone know how to turn a revision id (such as "launchpad@pqm.canonical.com-20090806060602-gqejhnxt9rbj5cr1" into a loggerhead URL?  I don't see a way to get to a revision by raw ID through loggerhead; only by revision number (which for various reasons isn't ideal here, as we have different branches with the same rev ids having different rev numbers).
 * kfogel supplies the closing paren missing in the middle of the above: ")"
<NET||abuse> vila, no, jaunty till full release
<NET||abuse> when's karmic out?
<vila> 9.10 ? :D
<NET||abuse> yeh, i woulda thought this month
<NET||abuse> just havn't seen any kind of promotion for it.
<gioele> vila: I promise that if you change that option I will not complain :)
<vila> :-)
<gioele> now, back to *using* bzr-upload
<gioele> thank you again
<gioele> bye
<kfogel> jelmer: any idea how to turn a revision id (such as "launchpad@pqm.canonical.com-20090806060602-gqejhnxt9rbj5cr1") into a loggerhead URL?  I don't see a way to get to a revision by raw ID through loggerhead; only by revision number (which for various reasons isn't ideal here, as we have different branches with the same rev ids having different rev numbers).
<jelmer> kfogel: hi
<jelmer> kfogel: It was possible IIRC it is possible, since I remember there was a bug in that code at some point. Let me check..
<jelmer> s/it is possible//
<kfogel> jelmer: that'd be great; I didn't see anything in loggerhead UI for it, but could have missed it.
<james_w> kfogel: I think you can do it by crafting the URLs
<james_w> I assume they still work, the "prettier" ones are the ones that are presented though
<jelmer> kfogel: it seems just using the revid instead of the revno works
<jelmer> kfogel: http://HOST/PATH/revision/REVID
<kfogel> jelmer: wow, I never even thought to try that
 * kfogel looks
<kfogel> jelmer: yup
<kfogel> jelmer: thanks for the tip
<jam> kfogel: the only thing to watch out for is crazy escaping...
<kfogel> jam: ?
<kfogel> jam: the only funny thing in there is an "@" sign, right?
<jam> kfogel: well revision ids *can* have more than just '@' in them
<jam> Though if they are just bazaar ones, they probably won't
<kfogel> jam: ?  is there a known charset I can depend on?
<jam> svn ids, for example, have ':'
<kfogel> jam: this is just bazaar
<jam> I think some may have '/'
<jam> etc
<jam> Technically revision ids are UTF-8 strings, but I think the underlying issue is that cherrpy does crazy stuff with things like '/'
<jam> anyway, it probably won't matter for what you are doing
<kfogel> they're link targets in a wiki
<jam> I just seem to recall that one of the primary reasons to move away from cherrypy was because it had lossy escaping
<jam> kfogel: so *if* a link works for you, then it is probably good for all eternity.
<jam> :)
<kfogel> jam: comforting
<jam> I'm just not confirming that all mappings from revid will actually lookup the exact content in loggerhead
<jam> though if this is normal bzr operations, it should work ok
<phinze> oof, okay so my plugin now successfully detects if a tip change touches anything inside a given path, happy times there...
<phinze> now i need to figure out how to check if a given change to a protected path was made by a merge with an authorized branch
<kfogel> jam: what would be a non-normal operation?  I mean, these are all commits...
<jam> kfogel: importing from svn
<jam> importing from git
<jam> someone hand-crafting revision-ids to do something special
<jam> kfogel: not things you will likely encounter, depending on what that wiki page is for
<kfogel> jam: https://dev.launchpad.net/Contributions/Draft
<jam> kfogel: I wouldn't expect that to ever be a problem. Especially if you are always linking the pqm revision
<jam> although by the same token, if you are linking to launchpad's trunk, I would expect that linking by revno would *also* always just work
<kfogel> jam: I am, although I have a separate ambition to remove PQM from the picture and just have us committing directly.
<kfogel> jam: but that's a different discussion :-)
<kfogel> jam: part of the problem is that launchpad has four trunks
<kfogel> jam: linking by revno also just works -- that's how it was working up until about 5 minutes ago, in fact.
<vxnick> hi all - is it possible to branch a repo into another repo? I've done this, but 'bzr add' doesn't add the branched repo to the current repo (if that makes sense)
<jam> vxnick: I think you are thinking of "branching a branch" not a "repo". Yes it is possible ,but we won't add it to the containing branch
<vxnick> jam: so I'd need to branch it on the production server separately then
<jam> vxnick: I believe so
<vxnick> jam: thanks
<phinze> jam: got spare cycles for me to bother you about this tip change hook i'm working on? .. just a couple of conceptual questions
<jam> phinze: possibly, though my load counter is pretty high right now :)
<phinze> jam: if not, is AOK... just looking to sap your expertise for fun and profit
<phinze> jam: basically i'm stuck given the fact that i'm given a old_revid and a new_revid ... and none of the new revisions exist in the *branch* yet but they're in the *repository*
<phinze> so i can get the last new revision easily, as i have its id
<phinze> but i'd like to iterate over all the incoming revisions, because i want to see if changes being made to the dirs i'm watching come from the right place
<jam> g = branch.repository.get_graph()
<jam> g.find_unique_ancestors(new_revid, [old_revid])
<jam> b.repository.revision_trees(unique_ancestors)
<jam> phinze: something like that?
<phinze> jam: beautiful
<phinze> the API is large... i was making my way, but slowly :)
<jam> phinze: you'll have to double check some of the api to make sure you are supplying the values correctly
<jam> but something like that should work
<jam> also you may want b.repository.revisions(...)
<jam> if you want to read the commit message, etc
<jam> but if you want the tree contents
<phinze> awesome, you've definitely saved me some significant head-scratching times
<jam> then revision_trees()
<phinze> right... i've got code that walks the delta between old and new and successfully detects if watched paths have changed, but now i've got to nail those changes down to a revision to see if it's a merge from trunk
<jam> phinze: ah, so user A isn't allowed to modify them, but it is okay if they look changed because they merged it from trunk?
<phinze> basically the plugin ensures that certain dirs are only changed in trunk and merged to projects ... we've had a lot of trouble with people making changes and diverging when they shouldn't
<phinze> jam: right
<jam> phinze: why do you care about the individual revisions, rather than the net effect of the merge?
<jam> why not just compare old_rev_id and new_revid's trees
<jam> rather than every step along the way
<phinze> that's what my current code does... walks through newtree.changes_from(oldtree)
<phinze> but isn't it possible that the tip change includes many revisions, some of them merges from trunk and others local changes?
<jam> phinze: well, if you only have trunk changes, then the result of the merge should be empty
<jam> since those changes are already on the trunk
<phinze> jam: bzr branch lp:bzr-protect to see what i gots
<phinze> meant to be run on the shared repository
<jam> phinze: when I get  a chance... I'm currently upgrading all my branches to --2a format, which is being ... involved :)
<phinze> ahh fair
<jam> phinze: you might want to look at something like "merge --preview"
<jam> which does a merge, and figures out what the final content changes are
<fullermd> Does upgrade recurse yet?
<phinze> jam: will do, thanks for all the advice -- i'll keep working on it
<jam> fullermd: my branches are new enough, but I decide to 'bzr branch lp:bzr' rather than upgrading from scratch
<jam> phinze: so just doing "new.iter_changes(old)" you could easily have changes in there that are 'bogus' because your trunk changed something and old didn't change anything
<fullermd> Well, I was asking for me, but I guess I can just test it   :)
<jam> you could look at "common_ancestor.iter_changes(new)" but that may also include things that, like you said, are from trunk
<jam> fullermd: I don't believe so
<jam> not sure
<fullermd> A quick test agrees with you.  Gruuh.
<phinze> jam: exactly, so i want to exclude from the list of invalid changes anything that originated in an authorized branch
<phinze> i mean i could probably simplify the use case if i dictate that merges from trunk must be made exclusively
<phinze> so cd project.bound; bzr merge ../trunk.bound; bzr ci;
<jam> phinze: so there is also the possibility that when someone merges trunk, they also edit the content before they commit
<phinze> jam: ick, i suppose that's true, but this is not meant for protection from a hostile environment, just as an aid to clumsy developers :)
<jam> phinze: my point is
<jam> if you do the merge --previou
<jam> --preview
<jam> then *nothing* should change for those files
<phinze> ahhhh
<phinze> ok
<jam> since it should only include changes that have already happened
<jam> it also allows someone to
<jam> bzr commit -m "modify some files"
<jam> bzr revert bad_files -r -2
<jam> bzr commit -m "didn't mean to do that"
<jam> and still end up with a clean merge
<jam> as long as they undo their mistake before it gets merged.
<phinze> gotchya
<phinze> so the commands you just listed, that would be something someone did on trunk?
<jam> phinze: commit + revert would be something they did on their branch
<phinze> ahh bad_files being stuff that would be protected
<jam> phinze: right
<phinze> so--and i'm sorry i'm being slow with this--you're suggesting i look into checking merge --preview into the use case for the plugin (i.e. users would somehow work with it) or into the execution of the tip-change hook
<jam> phinze: so how are users changing the tip?
<jam> via a checkout
<jam> via push?
<jam> via ???
<jam> (PQM?)
<phinze> 95% of the time via checkout
<jam> phinze: and where is this check running? locally, or on the server?
<phinze> and i can dictate that it is always via $METHOD_FOO if that makes this plugin work for us
<jam> phinze: well, I would *recommend* via a checkout, and I would *recommend* setting 'append_revisions_only=True' in the trunk's branch.conf
<phinze> jam: both of these are true currently
<phinze> so it's bzr co bzr+ssh://dev/trunk trunk.bound
<jam> so... what you are getting is a new_revision_id which is actually the product of the merge
<jam> so just doing new.iter_changes(old) should result in 0 changes to the protected files
<jam> the point of 'merge --preview' is that the 'result of the merge should not change these files'
<jam> and you are already dealing in the 'result of the merge'
<jam> now... how do you actually introduce *desired* changes to those files?
<phinze> oooooh... i just realized i've been testing by doing 'bzr push' and not emulating the actual environment
<jam> phinze: well, bzr push should operate the same as 'bzr commit'
<jam> since the end result is a revision which should be a merge into the trunk last revision
<phinze> ah ok
<jam> given that you have 'append_revisions_only'
<jam> there is a small possibility of something else
<jam> which I'll graph
<jam> just a sec
<phinze> jam: heh, i feel bad i always try and make my questions simple and pointed and it always spins out into me trying to get my head around something you're spending much effort to explain :)
<jam> phinze:  http://paste.ubuntu.com/264530/
<phinze> http://gist.github.com/180399 <-- current code, in more easily visible form
<jam> http://paste.ubuntu.com/264532/ for a bit more detail
<phinze> okay, so "will push cleanly as" refers to a push from where to where
<phinze> from user -> project branch?
<jam> phinze: right
<jam> see the second paste
<jam> normal operation would be to merge the change to a single mainline revision
<jam> however, push with append_revisions_only will allow the other
<phinze> so basically this is an edge case that could circumvent the policy?
<phinze> so if we dictate "only merge into trunk, don't push"
<phinze> we should be in the clear, no?
<jam> phinze: so instead of 'changes_from()' I would use the 'iter_changes()' function
<jam> phinze: it won't circumvent policy
<jam> not really
<jam> just that potentially D could modify the files, and E revert those changes
<jam> and the policy would then allow that to be pushed
<jam> and you would have a mainline revision which modifies and reverts content
<jam> http://paste.ubuntu.com/264536/
<jam> I would change your inner loop to ^^
<phinze> ha! so python folk really do use _ ... i was wondering about that yesterday
<phinze> even though _ is just a valid variable name and just gets reassigned
<jam> phinze: also, I find: http://bazaar.launchpad.net/~phinze/bzr-protect/trunk/annotate/head%3A/__init__.py
<jam> to be just fine without having to go to github :)
<jam> phinze: it is generally used to mean "I'm ignoring this variable"
<phinze> jam: ah sorry, rubyist in a foreign land :)
<jam> python interpreter's use it to store the 'last computed value'
<jam> well, *interactive interpreter*
<jam> inside python itself
<jam> it is just another variable you can assign or not
<jam> but it isn't auto-assigned
<phinze> jam: right i'm familiar with its usage, i just assumed since _ had a value in testing that it was somehow not the Right Way
<jam> 'value in testing' ? you mean in the interactive?
<phinze> it was in interactive
<jam> we use it inside bzrlib to just mean "I'm ignoring you"
<phinze> so i must have just been confused by that
<phinze> alright [/aside] :)
<phinze> so empty list evaluates to false as well
<phinze> nice
<phinze> alright lunchtime here... thank you a million times... i will be working on this once i get back
<jam> phinze: empty list/set/tuple/etc all evaluate to false
<jam> you could also do
<jam> if len(foo) == 0: if you want
<phinze> jam: next time you're in town i definitely owe you a beer ;D
 * vila 2/3 hosts upgraded to 2a, submission sent to pqm (involving both hosts and lp) ! EODing
<spirov92> a question- I have 2 branches-mysite/working and mysite/devel. one is put on the server, and one is for local development. They need to have different database config files. How do I copy just *some* changes from one to the other?
<spirov92> I'm thinking while I'm cd'd to mysite/devel, bzr push ../working. if I haven't changed the different files, will that work?
<jam> phinze: what town is that?
<phinze> jam: iowa city; i work with keith; we had lunch and talked RCS :)
<jam> ah, right
<moldy> hi
<jam> been a while since I've thought about you guys :)
<phinze> we're still here, plugging along with bzr ;)
<phinze> i extended the cerberus CI package with bazaar support and that's been working decently for us http://cerberus.rubyforge.org/
<phinze> got it pushed upstream and everything :)
<lifeless> moin
<phinze> jam: incorporated your suggestions, much cleaner now: http://bazaar.launchpad.net/~phinze/bzr-protect/trunk/annotate/head%3A/__init__.py
<phinze> reading about TransformPreview to try and figure out how to detect valid changes to protected directories
<phinze> jam: hmm after re-reading above and looking again wondering if your suggestions already account for that; because merges don't show up in the iter_changes loop
<phinze> but i don't see how that could be the case since there's no detection being done as to the origin of each change... i'm not sure if i should be trying to use the '(source_parent, target_parent)' returned in the tuple from iter_changes to figure that out
<jam> so, phinze, the whole objective here is that the change relative to the last committed trunk revision should have no paths in the 'protected set'
<jam> which should be okay for all cases
<lifeless> hi jam
<jam> hi lifeless
<jam> the main problem is how do you end up introducing *wanted* changes?
<lifeless> 129G of fast import to test today :P
<jam> lifeless: at least it finally finished
<lifeless> jam: yeah. I was very happy about that
<lifeless> I just installed my memory upgrade too
<jam> ooh, shiny
<jam> though 6GB <<< 129 :)
<lifeless> yes
<lifeless> sadly true
<lifeless> I let fast import try overnight
<jam> I'm pretty sure igc recommends .gz your fast import file
<lifeless> startsed at 300Revs/sec
<lifeless> thrashing when I got up, so stopped it and put the memory in
<phinze> right...
<lifeless> jam: I didn't get to the group combining, doing the dogfood upgrade took over
<jam> lifeless: yeah, I'm still working on getting my branches upgraded as well
<phinze> jam: ideally relative to the last committed revision from "an authorized branch"
<phinze> such that it's configuravble
<phinze> but the concept is the same yes
<phinze> jam: perhaps a companion command that does the merging from trunk/authorized_branch in a sane way?
<phinze> bzr authorized_merge ../trunk.bound => merges to tip of trunk and commits?
<phinze> bzr authorized_merge ../my_dumb_branch => Exception: my_dumb_branch not listed as authorized branch
<jam> phinze: well, any sort of direct access to the branch that isn't using the plugin would work, too
<jam> however, you could set up the pre filter based on source? I'm not really sure
<jam> you could check the username of the committed message
<phinze> hmmm... yeah basically we just need the i-know-what-i'm-doing detection
<phinze> :)
<phinze> jam: yeah that's easy
<phinze> check branch.conf for "smart_people"
<phinze> my pie in the sky spec for this plugin was that it would actually split off the changes and attempt to make a commit to trunk and merge it in before attempting a commit to the project branch
<phinze> crazy? oh yes
<phinze> but i think limiting merge access to certain users is probably a good first step
<lifeless> jam: in-1.9-format is in 1,9
<jam> lifeless: check
<lifeless> jam: I think you're ina checkout of 2a or something with an old bzr format
<jam> bzr pull http:..../bzr.dev-in-1.9 is not working
<lifeless> jam: I did, I replied on the list
<phinze> eh, the more i think about it the less satisfied i am with it as a compromise... i feel like there should be some way to detect "changes that came from trunk"...
<lifeless> jam: yes, I *think* you'll find that 'bzr info' also fails
<thumper> what would cause a VersionedFileInvalidChecksum when pulling from a merge directive into a branch?
<jam> thumper: best guess, a bundle created with a version of bzr before it actually worked with 2a formats
<thumper> jam: what about a bundle that was created when it worked and a pulling with a version that didn't?
<jam> thumper: probably as well
 * thumper nods
<thumper> LP has this
<lifeless> what release did you fix bundles in?
<jam> lifeless: 1.18rc1 according to NEWS
<lifeless> lp has 1.18
<lifeless> sorry
<lifeless> 1.17
<thumper> we have 1.18 landed but not rolled out
<jam> lifeless: any idea why lp:bzr would be 3x larger than it should be?
<jam> 90MB vs 30MB after 'bzr pack'
<lifeless> none as yet
<lifeless> once spm gets here I'll use him to poke around
<spm> o/
<lifeless> o hai
<lifeless> you can eat first :P
<jam> lifeless: interesting...  I have converted to 2a locally, and tried to push to an existing 1.9 branch. It gave me "no revisions to push" which is probably accurate
<jam> but I expected cross-format warnings first
<lifeless> jam: the branch has a duplicate check
<lifeless> based on tip
<jam> ah, self.tip == remote.tip exit early?
<jam> fair enough
<jam> I'm not *terribly* surprised, just a little surprised :)
<lifeless> I think; also possibly if you were pushing to lp, the remote stuff may have helped defer issues
<jam> yeah
<jam> I was
<spm> lifeless: already eaten etc :-) need to be at the boy's school this morning for a fathers day whatsit. so afk from ~8-10am; hence the early start.
<jam> I also have my downloaded copy, which is ~100MB on disk, which I can use for post-introspection if necessary
<lifeless> jam: not sure on that one. Have you solved the mystery of why you think in-1.9 is in 2a?
<jam> lifeless: you did add code to auto-pack after upgrade, right?
<jam> even for remote?
<lifeless> jam: yes, Interfaces
<lifeless> jam: remote uses the same interface locally
<jam> lifeless: I think the branch I was pulling into was a checkout of bzr.dev, which caused the failure at 'open master branch' though the failure message doesn't make that clear
<lifeless> on the far end
<lifeless> jam: yes, thats what I thought :)
<jam> well, the failure message doesn't indicate what branch format it is failing to read
<lifeless> jam: as in, something along those lines :)
<jam> what branch format *file*
<lifeless> jam: yeah, we might want a optional url in the error
<lifeless> spm: so, can you please pastebin ls -l archives/thelove/bzr/.bzr/{obsolete_,}packs
<lifeless> spm: on balleny
<spm> lifeless: No such file or directory on both cases
<lifeless> add repository/
<jam> .bzr/repository/{...
<lifeless> spm: our repo is 3 times larger than we expected
<lifeless> spm: we want to figure out why
<jam> lifeless: so it could certainly be fragmentation copying it from balleny to lp
<jam> especially if they have different ideas of 'groupcompress' order
<lifeless> oh, also we might benefit by getting a copy of ~/.bzr.log*
<lifeless> jam: lp is running 1.17
<jam> lifeless:  I assume that is pushed from pqm
<lifeless> jam: so thats a very plausible theory
<lifeless> jam: yes
<jam> lifeless: what version is pqm running?
<jam> also 1.17?
<lifeless> high security -> lower security
<spm> lifeless: https://pastebin.canonical.com/21816/
<lifeless> jam: the conversion was done with .dev 4667
<jam> lifeless: sure the conversion, but what pushed it to lp?
<lifeless> same same
<jam> lifeless: obsolete packs has a nice small: -rw-r--r-- 1 pqm pqm 31820 2009-09-03 15:12 8bc55f8aeed4e37d4d993bff6b8a26dd.pack
<jam> packs probably has a bunch of garbage packs in there
<jam> though I'm a bit surprised by the dates
<lifeless> spm: bzr dump-btree .../repository/pack-names, please
<spm> lifeless: https://pastebin.canonical.com/21817/
<jam> lifeless: ones like: -rw-r--r-- 1 pqm pqm 14115960 2009-09-03 09:12 0eeefcbd67df67ab2e7decf890907ba7.pack  are about 6 hours older than the obsolete pack
<jam> now that is strange
<jam> they appear to all be referenced and the nicely packed one is in obsolete...
<jam> although... are those all in bytes?
<lifeless> yes
<jam> I guess 32k would be way too small
<lifeless> I asked for -hs, got neither :(
<lifeless> that that pack is in obsolete_packs is just weird
<lifeless> spm can you do the ls again, with -lhS please
<jam> lifeless: so the size in packs is 54MB
<jam> which is approx what I would expect from packs if it was loose
<jam> though it bloated to 90MB on lp
<spm> lifeless: certainly
<lifeless> thanks!
<spm> lifeless: https://pastebin.canonical.com/21818/
<lifeless> jam: I can't explain that tiny pack
<jam> lifeless: I assume the tiny pack is just remnants from other stuff
<jam> like merging a revision
<lifeless> oh, I know
<lifeless> it will be a merge from a 1.9 branch
<lifeless> that does the following:
<jam> but it would seem that we did *not* repack the whole repo into a single pack after upgrade
<jam> is this an IDS artifact?
<lifeless> fetch (converting); insert; autopack that one pack file
<jam> that IDS only causes autopack of the *last* entry, and not all entries?
<lifeless> yes, IDS was used to convert
<lifeless> uhm, not sure
<lifeless> IDS should be passing in all the packs it accumulated on the way
<lifeless> unfortunately because a 1.9 branch landed we can't see what obsolete packs was
<lifeless> the log files will help
<lifeless> spm: ^
<jam> lifeless: so the overall layout looks like what I would expect from IDS without having it repack everything
<jam> it looks like IDS's pack every 10k 1k, etc
<spm> lifeless: the ~/.bzr.log as in?
<lifeless> jam: well, standard log10 backoff
<lifeless> spm: and .old too please
<jam> lifeless: right, especially given we have 27k revs
<jam> and there are 2 10+MB packs, 8 1-7MB ones
<jam> and a couple small ones
<jam> it doesn't perfectly line up, but pretty close
<jam> lifeless: so with pack-on-the-fly starting from the 'badly packed' copy from launchpad:
<jam> time bzr branch test-area
<jam> real    1m2.541s; 101MB (same as source)
<jam> time bzr-pack branch test-area
<jam> real    1m42.478s; 61MB
<jam> time bzr pack
<jam> 2m0s ; 30MB
<lifeless> spm: the next thing I'd like you to do
<jam> so the current pack-on-the fly code does help, albeit not as much as a full pack
<lifeless> spm: is to gather the same ls data, for the master copy of the bzr.dev branch on codehosting
<spm> 'kk
<thumper> hey lifeless, poolie: https://code.edge.launchpad.net/bzr/+activereviews https://code.edge.launchpad.net/bazaar/+activereviews https://code.edge.launchpad.net/~lifeless/+activereviews https://code.edge.launchpad.net/~lifeless/bzr/+activereviews
<jam> lifeless: I also realized a bit ago that we may need to look again at 'chk_map.iter_interesting_nodes()' for pack-on-the-fly performance
<jam> it returns 'unordered' at each 'level' of the tree
<jam> rather than grouping by subkey
<spm> lifeless: we have the backup copy - pre the migration - if on the very off chance that'll help. worst case, I can rerun same ??
<jam> ('pack' groups by subkey)
<lifeless> spm: thanks, for now keep it in reserve
<spm> lifeless: https://chinstrap.canonical.com/~spm/bzrlog.tgz
<spm> 'k
<lifeless> spm: nothing is wrong with our conversion, just identifying things we want to fix in bzr where it could have done better
<jam> so, take that back, 'bzr pack' results in 39MB, but still better than now
<spm> lifeless: ahh right. goodo
<lifeless> 06:44:17 38000/133780 commits processed at 1030/minute (:38000)
<jam> lifeless: this is your fast-import ?
<jam> and IIRC, fast-import still buffers way to much in memory
<jam> lifeless: so I have to redact slightly
<lifeless> yes
<jam> pack-on-the-fly is 41MB after 1m37s sending
<jam> no-pack is 101MB after 1m01s
<jam> pack is 39MB after 2m0s
<lifeless> isn't real world data lovely :)
<lifeless> thumper: whats changed?
<jam> testing already-packed to new location
<thumper> lifeless: approved merges at the top, other heading changed, you can now have it for project groups and person/product
<lifeless> thumper: awesome; sorry that I had to ask :)
<thumper> lifeless: and if you look at someone else's reviews, it shows better
<thumper> lifeless: pn
<thumper> np
<lifeless> spm: how we going on the private copy on codehosting?
<spm> lifeless: getting - just getting the disk location now
<jam> pack-on-the-fly-from already packed: 41MB 1m0s
<jam> lifeless: so it is working as we would like
<jam> it packs data when it needs to
<jam> doesn't spend time repacking when the source looks good
<jam> gets close to full pack results
<jam> lifeless: however, I think the branch was started from bzr.dev rather than --2a, should we cherrypick it, then?
<lifeless> jam: well, I started mine from 2a, you merged .dev :P
<jam> lifeless: I probably started from dev
<lifeless> I'd land on .dev
<lifeless> then cherrypick back
<lifeless> My remote streaming thing hasn't landed on .dev either
<spm> lifeless: https://pastebin.canonical.com/21820/
<jam> lifeless: adjacent-streaming?
<lifeless> onyl got it into 2a before the shutdown for conversion
<lifeless> yes
<lifeless> just needs a new NEWS entry in the IN DEVELOPMENT section
<lifeless> spm: thanks
<lifeless> 50M where pqm pushed
<lifeless> 91M where lp copied
<lifeless> I think fragmentation
<lifeless> lets get 2.0 on lp; then get a pack run of all public copies :)
<spm> ....!!!!
<lifeless> spm: it will same 60% of disk or more
<spm> Oh! In that case, I'm pushing it in now. 'k
<lifeless> spm: see how one repo is 50M the other 90?
<spm> yeah - I was wondering if that was an issue - hence the frag comments made some sense
<lifeless> jam: I'm satisified that we know the causes here
<lifeless> jam: are you?
<jam> lifeless: I haven't specifically investigated how the pack is laid out, but I *think* we know what was going on.
<jam> As long as we are sure of the version of bzr pqm used to push to launchpad
<jam> that it was doing 'groupcompress' and not 'unordered' fetching
<lifeless> spm: you used the custom build to do the push didn't you ?
<lifeless> last night I mean
<spm> lifeless: to do the pushes we did last night; yes. but verifying my history - one sec
<lifeless> jam: that will be in the log files
<lifeless> jam: however, server is 1.17
<spm> lifeless: aye. every time. revno 4667 on all 5 pushes.
<jam> lifeless: I'm pretty sure for 'bzr push' it is the client version that matters here
<lifeless> jam: right. 50M on balleny, 50M on the private copy on lp, 90MB on the public copy
<lifeless> jam: so I think the first push was unordered
<jam> lifeless: https://code.edge.launchpad.net/~jameinel/bzr/2.1b1-pack-on-the-fly/+merge/11162 whenever you want
<lifeless> jam: and the mirror fetch was gc and fragmented
<jam> lifeless: ah, so when I access over sftp, I'm actually getting the mirrored copy?
<jam> lifeless: then +1
<lifeless> yes
<lifeless> spm: please, on codehosting, run bzr pack in mirror copy
<lifeless> the one with the 90MB pack
<spm> sure
<lifeless> it won't stop this going ugly, but it will help mitigate
<spm> want a backup copy first? JIC?
<lifeless> no
<spm> :-) brave man
<lifeless> do the same for the 1.17 1.18 2.0 public branches
<spm> oki
<jam> spm: Not worried about 'bzr pack' destroying things
<lifeless> spm: pack happens automatically everywhere; if you have to back up before doing it, you'd have to backup before running commit
<spm> ew
<jam> 'bzr upgrade' is a bit more sensitive, but pack is pretty well handled
<spm> right, makes sense
<lifeless> spm: also, we have private master copies we can use *if* in the extraordinary event that pack went south
<lifeless> so we're already backed up
<spm> lifeless: this'll be using bzr 1.17 - I'm assuming that's ok
<lifeless> to sumamrise
<lifeless> spm: thats fine
<spm> 'kk
<lifeless> we think that: a) IDS didn't do a full pack during the 'upgrade', and perhaps-it-should perhaps-it-shouldn't
<lifeless> and b) that fragmentation between the 1.17 GC order and the rev 4667 of trunk order turned 50MB into 90MB
<lifeless> jam: https://pastebin.canonical.com/21820/ is the codehosting sizes
<lifeless> 07:11:57 41000/133780 commits processed at 635/minute (:41000)
<lifeless> -rw-r--r-- 1 robertc robertc 89M 2009-09-04 07:06 a6968b0190033b59553272ded45d13fa.pack
<jam> lifeless: yeah, the mirrors I was aware of, and that fits right at what I'm comfortable saying "this is fragmentation issues with older versions of bzr"
<jam> lifeless: especially given that the gc order pqm pushed to lp would be different than the gc order
<jam> that lp thinks would be best pushing to the mirror
<jam> lifeless: now to figure out why my network bandwidth isn't getting saturated while fetching from lp
<jam> even in 'unordered' sorting
<jam> lifeless: any ideas where to start?
<spm> lifeless: https://pastebin.canonical.com/21822/ mirrors done for bzr.dev <== keep on truckin'?
<lifeless> jam: get a network trace, we need data on out of order, window sizes etc
<lifeless> jam: I've seen lp be a bit spotty from time to time, but we don't have a hard analysis
<lifeless> spm: sweet go forward and pack
<spm> on 2.0, 1.17 and 1.8? oki.
<lifeless> spm: you can remove the contents of [but not the dir] obsolete packs there
<lifeless> bzr will remove it itself eventualyl
<jam> lifeless: of course, spm just borked my stream and it has to restart now :)
<spm> I'll go for the latter option - eventual remove
<lifeless> spm: kk
<spm> jam: I deliberately waited till you were mid access :-P
<jam> though nice to see that it did so graciously, without interruption
<lifeless> jam: \o/
<lifeless> jam: should happen on the client side
<lifeless> jam: unless you're using sftp
<jam> lifeless: using bzr+ssh
<lifeless> sorry, I meant to say 'on the server side'
<jam> lifeless: yeah, it should notice the repack, and start reading from the new packs
<lifeless> \o/ layers, and \o/ us
<jam> _get_remaining_record_stream and all
<spm> lifeless: fwiw. 2.0: -rw-r--r-- 1 codehost codehost 170K 2009-09-03 10:37 a6acd2ed3e0fa3df6e472d7476523cf7.pack <== the other file is 163K, even worth doing the pack?
<lifeless> spm: oh hmm no
<lifeless> ignore
<KhaZ> Hello: Apologies if I shouldn't ask about fastimport here, but I'm havnig some difficulty and hope someone can help.  Basically I'm trying to use the svn front end, and I'm getting: A lot of: Exporting revision 266... skipping. messages, with the result being that I don't get a valid bzr repo built.
<spm> will check 1.17 and 18 to be sure
<jam> lifeless: is that because it is stacked?
<lifeless> jam: yes
<lifeless> KhaZ: you're welcome to ask about anything :)
<lifeless> KhaZ: is it the svn export that is skipping, or the bzr import ?
<jam> spm: So did you do the 'bzr pack' using 1.17?
<lifeless> jam: yes he did
<spm> jam: aye
<mneptok> lifeless: why does God not intervene to stop bad people from doing bad things?
<mneptok> lifeless: (this relates to the continued use of CVS by some people)
<lifeless> mneptok: because he likes a little tittle himself
<KhaZ> lifeless: It's the export.  If I do the left hand side of the pipe:  ~/.bazaar/plugins/fastimport/exporters/svn-fast-export.py ~/dev/eddie_svn | bzr fast-import -, it still gives that message.
<spm> mneptok: because that's mnepolo's job - God delegated.
<lifeless> KhaZ: so, I don't know much/anything about the svn fastexport code
<lifeless> uhm
<lifeless> igc /might/
<KhaZ> Ah, too bad.  Yeah, unfortunately the message isn't very helpful.  I don't know why it's skipping exactly.
<lifeless> but he won't be up for an hour and change
<spm> lifeless: fwiw, 1.17 and 18 are empty on the packs
<jam> lifeless: what is a good wireshark filter for excluding everything but ssh?
<lifeless> KhaZ: if you just want to import to bzr, can I suggest bzr-svn's excelling svn-import command
<lifeless> jam: port 22
<KhaZ> Oh.  Neat.  OK, I'll try out svn-import.  Wasn't sure the difference.
<jam> lifeless: ip.addr == 91.189.90.11 seems good enough
<jam> (bazaar.lp.net)
<jam> so about 18s in, it starts 'thinking'... presumably that is determining revs to send, etc
<jam> lifeless: hm... I'm seeing a fair amount of 'retransmission' packets
<lifeless> do you have SACK enabled?
<lifeless> what OS
<jam> lifeless: Windows
<lifeless> yes but which one
<jam> Vista Basic
<jam> Current window is 259888
<jam> though it has gone down to 150 at the lowest
<jam> wel, 150000
<jam> you know what, though. I'm also running in the basement, on wireless in the top floor
<jam> it may just be wireless retransmission issues
<jam> I don't generally notice, though
<jam> And my connection looks good
<jam> claims 88% signal
<lifeless> HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
<lifeless> SackOpts
<lifeless> whats that set to / does it exist
<jam> lifeless: no SackOpts exits that I can find
<lifeless> check the wireshark handhake
<lifeless> was selective act enabled ?
<lifeless> (in the 3 way handshake at the start)
<jam> lifeless: I'm not really sure what to look for there
<lifeless> so if there are lots of retransmissions
<lifeless> and selective ack is off
<jam> download time with bzr.dev was at least 9m45s
<jam> which is a lot better
<lifeless> it has to retransmit the entire missing segments
<jam> of course, that is with 3x less data :)
<KhaZ> Hrmm.  I'm tryign to run bzr with the bzr-svn import stuff, but it's giving me an error: bzr: ERROR: exceptions.ImportError: cannot import name format
<lifeless> are you installing by packages, or from source?
<lifeless> what does 'bzr plugins' say - is svn listed?
<KhaZ> From package.  Gentoo's emerge, to be precise.
<KhaZ> No module named send
<KhaZ> Unable to load plugin 'svn' from '/usr/lib64/python2.6/site-packages/bzrlib/plugins'
<lifeless> odd
<lifeless> that should write a back trace to ~/.bzr.log
<KhaZ> There is more to it, but nothing suspicious except that ilne
<KhaZ> What does it mean "no module named send"?  That's no python module I know of.
<KhaZ> easy_install doesn't know of it either.
<lifeless> is there a backtrace in the log?
<lifeless> about the plugin load failure?
<lifeless> http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html
<lifeless> bah, jamgone
<lifeless> http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html
<KhaZ> Ah, yeah, there is a log file there.  Let me see.
<KhaZ> Yeah; apparently it's trying to load bzrlib.send and it doesn't exist
<KhaZ> I tried that from a python interpreter, same thing.
<lifeless> KhaZ: could you pastebin the trace please
<KhaZ> Certainly.  One moment.
<KhaZ> Sorry about the delay: http://pastie.org/605095
<igc> morning
<lifeless> KhaZ: what version of bzr do you have?
<lifeless> KhaZ: I strongly suspect that its quite old - current versions have a bzrlib.send module
<KhaZ> 1.15.1
<KhaZ> Is that old?
<lifeless> current stable is 1.18, about to release 2.0
<lifeless> 1.15.1 isn't hugely old - 4 months or so. But the error you're getting says that your bzr-svn is mismatched with your bzr[lib]
<KhaZ> Ah.  Looks like Gentoo masks the recent versions
<lifeless> hi igc
<jam> lifeless: yeah, EOD for me
<igc> lifeless: fast-import will handle multiple branches
<jam> morning igc
<igc> hi jam
<jam> just started another download with the new pack-on-the-fly to see if it is any different
<jam> I'm guessing not
<lifeless> jam: I'll review and land stuff
<jam> lifeless: sounds good
<lifeless> http://blog.sesse.net/blog/tech/2009-08-30-11-33_trying_to_understand_tcp_performance.html
<igc> jam - do you have a moment for a very quick chat re installers?
<igc> eithe online or Skype?
<igc> jam: I want to know whether build-release.py is still used?
<igc> jam: and whether I can test out the buildbot stuff on linux separately to packaging as an installer?
<jam> igc: I don't use build-release anymore
<jam> The last builds have been done purely with 'make installer-all'
<igc> so it's obsolete?
<jam> igc: yeah
<jam> as of... 1 or 2 builds
<jam> so not very obsolete
<igc> ok
<jam> I just made the transition
<jam> I need to go now, and I haven't found my cell phone... sorry
<igc> jam: do I need cygwin?
<igc> jam: np
<jam> igc: you need 'make' etc, cygwin being the easiest way to get it
<igc> I have make
<jam> I generally install cygwin + gcc+mingw32
<jam> for building for py2.4 and 2.5
<igc> ok
<jam> I've started using VS 2008 for py2.6 ,though not on Kerguelen IIRC
<jam> lifeless: on this transmission, my windows seems to be down to 64k
<jam> and I'm still getting up-and-down on the transmission
<igc> jam: ok bye for now - I'll email any other questions
<jam> k
<jam> igc: also 'python setup.py -c mingw32'
<jam> is good to know about
<jam> but there is also a 'disutils.cfg' or something like that you can set up
<jam> so that it is always enabled
<jam> I certainly recommend digging up my email to canonical-bazaar
<jam> circa, a few months ago
<jam> probably 'win32' in the title
<igc> ok
<lifeless> igc: 08:12:56 52000/133780 commits processed at 414/minute (:52000)
<lifeless> the timing data
<lifeless> is that over the last 1K
<lifeless> or total time/total revs done
<igc> lifeless: averaged since the start - the last minute will be a lot worse than that
<lifeless> it would be interesting to see that difference
<igc> lifeless: compare the time for 51k vs 52k
<lifeless> be a good clue about where it goes south
<lifeless> 08:08:24 51000/133780 commits processed at 421/minute (:51000)
<lifeless> 05:45:33 Collecting statistics ...
<lifeless> 06:07:24 Starting import of 133780 commits ...
<lifeless> 06:07:31 1000/133780 commits processed at 7707/minute (:1000)
<igc> lifeless: it will go south at 80k and 120k
<jam> igc: it looks like the thread is 'More work on win32 installers' though it seems to have a lot more posts than I remembered
<lifeless> igc: thats when you're doing a full pack yes?
<lifeless> 13 minutes or so @ 40K
<igc> jam: do we have the archives online?
<jam> igc: I believe so
<igc> lifeless: yep - full pack every 4 checkpoints by default and we checkpoint every 10k
<igc> lifeless: both numbers are controllable via options
<igc> jam: I'll look - thanks
<lifeless> yeah, I don't think they are the problem
<lifeless> but having a weighted or windowed average would be really useful
<lifeless> how would you feel about that
<jam> lifeless: I have a couple of pcap files now. New download was much slower (14m vs 9m)
<jam> anyway, really away
<igc> lifeless: I'm ok with whatever stats make sense
<igc> lifeless: as a comparison, the kernel with 145k revisions took 13 hours
<lifeless> igc: right, but does this make sense to you ?:P
<lifeless> igc: specificalyl, changing at X/minute
<lifeless> to
<lifeless> in $total_time[X/minute], last 1000 in $minutes[Y/minute]
<lifeless> or something similar
<igc> sure
<lifeless> because I think its actually doing 250/minute
<lifeless> which is hugely slower and more representative [it also suggests something to be looking into]
<igc> lifeless: kernel pack times fyi ...
<igc> 40k: 19 minutes; 80k: 49 minutes; 120k: 108 minutes
<igc> 145k: 90 minutes
<igc> so 3.5 hours of the 13 in pack
<lifeless> 08:12:56 52000/133780 commits processed at 414/minute (:52000)
<lifeless> 08:23:55 53000/133780 commits processed at 388/minute (:53000)
<lifeless> 1000 in 11m - < 100/minute
<poolie> hi all
<lifeless> hi
<poolie> jam, hi?
<moldy> hi
<moldy> what exactly is the effect of being a "parent" branch of another branch?
<igc> hi poolie
<igc> moldy: being a parent doesn't affect a branch
<igc> moldy: having a parent means there's a default location to pull from (for example)
<igc> moldy: and commands like 'bzr diff -rsubmit:' show you what's changed via you started on this branch
<igc> s/via/since/
<moldy> igc: it has no effect on the way the history is kept, right?
<igc> moldy: right
<igc> hi emmajane
<moldy> igc: ok, thanks
<igc> how is/was the conference?
<emmajane> igc, hey
<emmajane> igc, it's going well. I did my presentation today and people seemed to like it, so that's always good.
<emmajane> two more days.
<igc> emmajane: well done
<emmajane> igc, thanks :)
<igc> emmajane: square-dancing vs php right?
<emmajane> igc, aye :)
<emmajane> igc, at 9AM
<igc> emmajane: it's never too early for square dancing :-)
<igc> php on the other hand ...
<emmajane> igc, that's what i thought too :)
<emmajane> igc, people thought I was completely nutters but then decided I might be right.
 * fullermd glances over at IRC from his PHP-writing...
<lifeless> fullermd: feeling dirty yet?
<fullermd> Yet?  Was it supposed to go on hiatus at some point?
 * emmajane chuckles
<moldy> i have 2 branches that, according to bzr, "share no common ancester". what is the right way to make one branch the ancestor of the other?
#bzr 2009-09-04
<igc> moldy: where did the branches come from?
<igc> moldy: iiuic, no common ancestor implies they have no history in common
<moldy> igc: they come from a converted svn repository
<igc> moldy: converted via bzr-svn or bzr-fastimport?
<moldy> igc: bzr-svn
<igc> moldy: I don't know much about bzr-svn sorry
<igc> jelmer: still around today?
<moldy> igc: as a last resort, i could manually create another branch off of branch a, apply the differences to branch b, and use that one as the new branch b (i don't desperately need all the history), but i am wondering if there is a better way
<igc> moldy: see if jelmer or anyone else has a better idea first
<igc> moldy: if not, that sounds ok to me
<lifeless> moldy: were the branches in the svn repo created by doing 'cp', or by separate imports?
<moldy> lifeless: i have no idea :)
<moldy> lifeless: hm, now that i thinj about it, probably by "cp", but i cannot vouch for it :)
<lifeless> if they were, I would expect bzr-svn to have joined them
<lifeless> uhm, I suggest filing a bug on bzr-svn, if they have common ancestry in svn
<moldy> hm, they have common history in svn
<moldy> i ran bzr-svn on the whole repository
<S11001001> is it kosher to use 2a repo format for all new repos if you only care about 1.17+ support?
<moldy> but i also changed the layout a bit, so i joined stuff into the branches that had their own svn modules before, maybe that was the problem
<lifeless> S11001001: yes, thats fine.
<lifeless> 2a is usable [but not ideal] from 1.16 on
<lifeless> S11001001: we will be strongly recommending 2.0 and above everywhere
<bob2> probably silly question, but was the 2a upgrade issue fixed before trunk switched?
<poolie> igc, hi
<igc> hi poolie
<poolie> so if putting sphinx onto hardy is hard, um
<SamB> dangit, bzr help needs some sort of close-match spell checking when the edit distance is just a few characters between the user entry and what they actually wanted help on ...
<poolie> SamB: i don't think bzr-guess does this but it would be an easy extension
<SamB> say, "help revision-specs" instead of "help revisionspec"
<SamB> poolie: heck, I think this is important enough to be in core!
<poolie> igc, did it turn out you can't run it from source
<igc> poolie: yet to try
<SamB> especially for the non-command topics
<SamB> which have rather arbitrary names
<igc> poolie: I might get to it today
<poolie> i just wondered
<igc> polie: need to upgrade to 2a first
<poolie> the issues lamont mentions may block it running from source too
<poolie> in which case we might
<igc> poolie: maybe
<poolie> hm, i guess we could ask for a karmic chroot there
<igc> poolie: let me try from source first
<igc> poolie: karmic may be out before they get to it either way :-(
<poolie> igc, from recent mail it looks like karmic may not be LTS
<igc> poolie: I thought 10.4 was LTS
<poolie> you also get into the problem that slightly exotic server hardware may not be supported by newer kernels
<poolie> at least i think i recall that happening in going to hardy
<poolie> right but karmic is not 10.4
<poolie> it will be 9.10
<igc> right
<SamB> hmm ... my "bzr log" is silly and only looks in the current branch for revisions even when they're in the same repo, it seems :-(
<poolie> so the earliest they'll probably want to upgrade the base os there is may 2010
<lamont> poolie: it shouldn't be _hard_ to put sphinx in hardy
<lamont> it just needs to not be self-build-depending...
<lamont> for a round
<poolie> i'm not sure what that means
<poolie> is it getting rid of the circular dependency?
<fullermd> SamB: Well, if they're not in the current branch, it's tough to get the revno...
<SamB> bah!
<lamont> poolie: I expect that the reason jinja2 build-depends sphinx is for its own docs?  is it possible to strip the sphinx-needs from jinja enough to build and have it work enough to build sphinx enough to build jinja-with-sphinx to build sphinx-with-full-jinja?
<SamB> why can't it just skip that?
<fullermd> I think the typical answer to things like that is "because your patch for it hasn't been merged'   :p
<poolie> lamont: i expect that's true too, and that it is possible
<SamB> or at least give a less scary-looking error that explains what went wrong a bit better ...
<poolie> but i haven't looked at the source at all
<lamont> poolie: it has to be.. it's just a question of how far back in history one has to go
<fullermd> (note that the error you get is a NoSuchRevision, but it doesn't come from looking up the rev, it comes from branch.revision_id_to_dotted_revno()
<poolie> oh, because it was not circular at the time it originally went into debian or ubuntu?
<SamB> of course, I'm on an old build atm because I was hoping to figure out how to look at the changelog ...
<poolie> Samb, i agree, file or dupe a bug
<lamont> I admit I haven't been watching, but I expect that the decision on next-LTS won't be made until at least the next UDS, so it'll either be 10.04 or 10.10
<igc> hi sidnei
<sidnei> igc: oi
<igc> sidnei: a questions fro you ...
<lifeless> circular deps are sadness
<sidnei> igc: shoot
<igc> can I use/test the buildout stuff on linux
<igc> I'm thinking of getting the image right ...
<poolie> lifeless: did you see bialix's comments about 'apport's dependencies are so hard on windows'?
<igc> then worrying about how the installer does something with it
<lifeless> poolie: yes
<lamont> poolie: and the real issue is that it needs a file that isn't even delivered by python in hardy... :(
<lifeless> jml: poolie: 12 for lunch?
<sidnei> igc: uhm. if i recall correctly, you should be able to run bootstrap.py then bin/buildout on linux
<sidnei> igc: but after that it invokes a batch file
<poolie> lifeless: sure, where?
<lifeless> you had two restaurants you wanted to revisit
<lifeless> so lets hunt down the second
<poolie> wfm, i think you'll like it
<sidnei> igc: that won't give you much other than fetching the dependencies though
<igc> sidnei: and do you know how it packages python, qt and pyqt?
<sidnei> igc: pyqt needs to be installed manually using the .exe installer into your global python interpreter, and so does a few other dependencies.
<igc> sidnei: my xp partition is only a few G so I want to do as much work as I can elsewhere
<sidnei> igc: and finally it uses py2exe which is basically black magic to me to pull all the dlls and dependent libs into library.zip
<igc> sidnei: ah - so the qt stuff ends up in there?
<sidnei> igc: i'm pretty confident that it does. haven't paid close attention.
<sidnei> igc: the final step is just packaging it up with innosetup
<igc> sidnei: and that's the bit I had planned to improve but ...
<igc> it seems that's about 10% of the job
<sidnei> igc: correct
<igc> vs gathering everything, compiling it, etc.
<SamB> jelmer: how come bzr-rebase is so outdated?
<igc> sidnei: so adding more plugins basically comes down to editing the buildout.cfg file and build-installer.bat.in file right?
<sidnei> igc: yes
<igc> sidnei: I don't want to install cygwin. I have make installed. Does that sound ok?
<sidnei> igc: yup, that's how i have it here
<sidnei> igc: i actually install cygwin but don't use bash. i only put c:\cygwin\bin in %PATH%
<sidnei> igc: i believe that a different way of achieving what you wanted would be to not use py2exe, but instead build a custom python install
<sidnei> igc: i have code for doing that which we could possibly borrow
<sidnei> igc: in fact, i think that would make things a lot easier for everyone including people building plugins
<igc> bbiab
<sidnei> me too. *wink*
<jelmer> SamB: outdated in what sense?
<jelmer> SamB_XP: outdated in what sense?
<lifeless> poolie: so where should I meet thou?
<AfC> lifeless: ping? [personal]
<lifeless> spm: procedure change:
<lifeless> new pqm branches need:
<lifeless>  - bzr-core set as reviewer
<lifeless>  - bzr-core subscribed to the branch
<lifeless> because *reviewers are not notified*
<spm> lifeless: oki; will add to docco. I assume the new branch we did last night needs this asap?
<lifeless> done it
<spm> awesome, ta.
<lifeless> for 2.0 and bzr.dev
<lifeless> only cause I'm in bzr-core and can thus do it
<spm> :-)
<spm> so..... what I'm hearing is you've got the tools to do this yourself; therefore our update needs are minimised? :-P
 * spm looks forward in great anticipation to the response to that unsubtle troll
<poolie> lifeless: i guess here
<lifeless> poolie: ok, I'll drift your way
<lifeless> jml: ^
<jml> lifeless, I just got off the phone :)
<jml> poolie, I'll probably be a little later than 12
<poolie> np
<moldy> bzr does not work directly over ssh, without a bzr server?
<spiv> moldy: you can use sftp
<spiv> moldy: but having bzr installed on the remote side and using bzr+ssh will be faster.
<moldy> spiv: is it enough to have bzr installed, or do i need to have a server running?
<spiv> It simply needs to be installed.
<moldy> hm, does not seem to work for me
<spiv> (And on PATH)
<moldy> which bzr versions are compatible?
<spiv> Does "ssh yourhost bzr --version" work?
<moldy> yes
<spiv> Basically all of them.
<spiv> What specifically does "not seem to work" mean?
<moldy> well, i have 1.15.1 against 0.11.0
<spiv> Oh, ok.
<moldy> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<spiv> 0.11 is pretty ancient, probably 1.15.1 won't work with that.
<moldy> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
<moldy> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\
<spiv> 0.11 was the very first version to have any sort of "bzr serve" support.
<spiv> And it was basically just a glorified sftp, you may as well just use sftp :)
<moldy> unfortunately, sftp doesn't work either :)
<spiv> Oh?
<spiv> That's pretty weird.
<spiv> The error message is correct though, that upgrading the bzr on the server would fix your problem.
<moldy> i think i will look for a backport of a more recent bzr version to debian etch
<spiv> It's very unusual for sftp not to work.  Is that an intentional server configuration I wonder?
<spiv> (0.11 is almost 3 years old, btw)
<moldy> might be that my local bzr is broken, sftp itself works
<spiv> What error do you get?
<moldy> ah, it seems to be related to the svn plugin
<moldy> i'm not sure why it uses that plugin when trying sftp, though
<spiv> Ah.  You can try "bzr --no-plugins ..."
<poolie> hello spiv
<poolie> igc, did you file a bug or talk to someone about packaging explorer on ubuntu?
<poolie> it'd be nice to have it
<moldy> spm: thanks for your help. with a recent bzr on the remote side, it works
<spiv> moldy: great!
<spiv> poolie: good afternoon
<poolie> oh so it is
<poolie> how's stuff?
<spiv> Well, my local repo passed "bzr check" so now it's in the throes of upgrade --2a.
<xnox> Can I unshelve a change from branch a/ onto branch b/
<xnox> if it was shelved inside branch a/
<spiv> xnox: unshelve in a/ and then do "bzr merge --uncommitted ../a/" in b/ is probably simplest.
<spiv> Otherwise all I can think of is copying the .bzr/checkout/shelf directory.
<poolie> would be nice if you could
<spiv> poolie: and I'm wondering what happened to my merge request yesterday, and wondering what the most painless way to resend it is when I'm in the middle of an upgrade...
<xnox> spiv: thanks
<thumper> whoever came up with merge --uncommitted was a genius
<igc> poolie: it was with james_w I believe - I can't recall raising a bug, only emailing
<igc> thumper: yes, I use it a lot (and no it wasn't me)
<xnox> One more questions =) I've started to use bzr-svn to push to an svn repo. Is there a way to remember push login & password?
<poolie> xnox: in auth.conf i think?
<xnox> poolie: ok thanks I'll look into that
<SamB> ... is there a way to commit in the style of "darcs record", which has a slightly better interface than "bzr shelve" to select what to inclue in the patch?
<S11001001> SamB: interactive plugin
<SamB> why does searchiong for "bzr darcs commit" (sans quotes) not seem to help me find that?
<S11001001> branch http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk as interactive into your plugins directory
<SamB> S11001001: I know how to install a plugin
<S11001001> just in case :)
<SamB> and if I was having trouble finding it now that you told me the name, I would have asked ;-)
 * igc lunch
<S11001001> take care, because it doesn't work in dumb terminals (like emacs shell)
<SamB> that's fine
<SamB> I wasn't really going to use it there
<SamB> and I don't think darcs really likes that either ;-)
<S11001001> I have used it for some time now with darcs just fine
<S11001001> also, the hunk finder is more eager in bzr-interactive
<S11001001> whereas I think if hunks are separated by 1 line of context in darcs they will be treated separately, this is not so in interactive
<SamB> oh, really?
<SamB> doesn't the red highlighting confuse emacs?
<SamB> S11001001: hmm, I don't remember darcs being that smart
<S11001001> what highlighting?
<SamB> well, usually of either things that darcs didn't get (non-ascii bytes) or a $ to mark the end of a line with trailing whitespace
<SamB> (instead of the actual byte, it prints a red escape sequence)
<S11001001> hmm, possibly I've never recorded any such things
<SamB> (really annoying when you're writing programs using UTF-8 operators!)
<SamB> well, I guess it would at worst look just slightly more horrible and less eyecatching than in a real terminal ;-)
<SamB> ... and of course you can always use the Emacs terminal *emulator*
<S11001001> icky, I like moving around my shell history like a text buffer
<SamB> it can't do that?
<SamB> aww :-(
<SamB> well, I guess you'd have to switch modes first if it could
<SamB> I mean, toggle something
<SamB> to change the key bindings
<SamB> so that they wouldn't go to the app
<spiv> Less than 500 revisions left to upgrade.  Oof.
 * SamB wonders how to get emacs to describe a keymap in an intelligable manner -- wishes it had more types :-(
<SamB> S11001001: hmm, needs abit of work ...
<S11001001> the developer is open to bundles :)
<SamB> is it you?
<SamB> anyway, was just pondering it ;-)
<S11001001> not at all, I merely contributed -F support
<SamB> ah
<SamB> what's that for?
<S11001001> it's supported by built-in commit, just was broken in the wrapper commit that interactive provides
<SamB> ah
<SamB> is that the one that takes the commit message from a file?
<S11001001> I name my log files ++log in honor of arch
<SamB> you ... honor ... arch ?!?  :-(
<S11001001> I liked arch, kept using it until about the time bazaar-ng 1.5 was released
<spiv> S11001001: and you call temp files ,,foo? :)
<SamB> I can't like arch
<S11001001> just 1 , actually
<SamB> it has too many damn pointless concepts!
<spiv> Heh.
<S11001001> , is garbage that tla promises not to delete
<SamB> or, at least, too many damn pointless components in a name
<spiv> S11001001: <gollum>my precioussss</gollum>
<S11001001> well I don't name my log files ++log instead of ++log.myproject--mainline--0.1.scompall@nocandysw.com--2009-ddi for nothing
<SamB> I guess the thing is that I never tried arch until I was already hooked on darcs for the time being
<SamB> now I'm not so much hooked on darcs, but still use it as one of my VCS yardsticks
<S11001001> I don't think darcs existed back in 2004
<SamB> not sure
<SamB> I don't remember exactly when #haskell got me hooked
<S11001001> hmm, actually it seems to have, but I didn't hear about it until 2007 anyway
<SamB> yeah, I was pretty sure it was older than that ;-)
<S11001001> it was the community standard for common lisp projects until recently
<SamB> darcs?
<SamB> or arch?
<S11001001> darcs
<SamB> did they start using git too or something?
<SamB> or git, bzr. & hg too?
<SamB> oops, s/./,/
<S11001001> git, hg, and svn have all insinuated themselves
<SamB> what the?
<SamB> why svn?
<SamB> ... is it because of google code?
<S11001001> bknr.net svn is the new host for Edi Weitz's popular libraries, and clozure (an implementation increasing in popularity) also uses svn for source and binary distribution
<SamB> oh, is clozure JVM-based?
<S11001001> you're thinking of clojure :)
<SamB> oh.
<SamB> okay.
<SamB> I was just trying to find an excuse for brain-deadedness
<SamB> hmm ... how would I use emacs to search for a line that has $(HIDE) on it and isn't immediately preceded by one with $(SHOW) in it?
<S11001001> Clozure was once OpenMCL, but MCL went and changed its license, and Clozure added GNU/Linux and Windows support, then x64 and x86
<S11001001> surprisingly, porting to platforms other than OS X/PPC was a surefire way to increase popularity
<SamB> no duh
<SamB> especially with the PPC macs being discontinued
<SamB> hmm, so they ... added support for PPC Windows before support for x86 anything?
<SamB> was there even an MS Windows for PPC?
<S11001001> it's a little weird, they added linux/x64, then windows/x64, then similarly for the x86
<S11001001> IIRC, porting to the register-starved x86 was harder than amd64 support
<mneptok> SamB: yes
<SamB> ... I mean, I know arty in #reactos was working on porting that to PPC, but I forgot about whether there was an MS predecessor ;-)
<mneptok> SamB: NT 3.5 was released for PPC. there may have been others.
<mneptok> anyhow, such discussions are not really on-topic for #bzr
<SamB> mneptok: yeah, but, was anyone asking a bzr question?
<SamB> oh, I've got one!
<mneptok> SamB: that's not really the point.
<SamB> does bzr work on NT 3.5 PPC?
<mneptok> SamB: walk into a police station at 3am and do a striptease. when they tell you that it's not a strip club, ask "well, was anyone being arrested?!"
<SamB> mneptok: that's a bit different
<SamB> I think they'd be arresting you for indecent exposure
<mneptok> SamB: so please don't risk the same here.
<SamB> or because they didn't want to see your dick
<mneptok> SamB: such language *definitely* is not welcome in #bzr
<SamB> oh, sorry.
<SamB> should I have said "penis"?
<mneptok> you should probably keep your mouth shut and be thought a fool, rather than open it and remove all doubt.
<SamB> fine, fine, #haskell-blah, here I come ...
<SamB> I should be fine there as long as I remember not to talk about Haskell ;-)
<spiv> jml: regarding your comment about the puller from about 7:30pm yesterday: bug #424136
<ubottu> Launchpad bug 424136 in launchpad-code "Cannot upgrade stacked branches from 1.9 to 2a on Launchpad" [High,Confirmed] https://launchpad.net/bugs/424136
<jml> oh yes?
<spiv> jml: the problem appears to be that the assumption that "Branch.open" succeeds in tha face of rich-root mismatch in stacked-on/stackee is wrong.
 * jml tries to parse that for the third time
<spiv> jml: stacked-on: just changed from 1.9->2a
<spiv> jml: my branch: just changed from 1.9->2a the hosted area, still 1.9 in the mirrored area
<spiv> jml: puller: tries Branch.open(mirrored-my-branch), fails because 1.9 can't stack on 2a because 1.9 and 2a have different rich-root support.
<spiv> jml: puller therefore gives an error rather than propagating the upgrade that would fix the error.
<jml> spiv, I see.
<jml> spiv, so we ought to catch those errors and upgrade as if we detected a format change?
<spiv> jml: or open in a way that doesn't fail if stacking won't work.
<jml> spiv, you're bringing back bad memories
<jml> spiv, is that even possible?
<spiv> e.g. BzrDir.open(...).open_repository()
<jml> hmm
<spiv> (because stacking is configured by the branch)
<spiv> Or perhaps BzrDir.open(...).open_branch(ignore_fallbacks=True).
<jml> perhaps.
<spiv> Or potentially just catch the relevant exception.
<jml> catching the exception seems like the most robust to me.
<spiv> bzrlib.errors.IncompatibleRepositories I believe.
<spiv> Well, not making inspecting the format of object A dependent on details like "A's config says stack on B, but B is not compatible" seems more robust to me :)
<jml> spiv, yeah, fix bzr
<jml> spiv, in the meantime the integration team will integrate :)
<spiv> But I can understand that having a separate "check formats" and "now open it for actual use" phases might be awkward in your code.
<jml> spiv, we already do something like that... icbw
<spiv> bzr is working fine: it's refusing to do Branch.open because it can't be opened.
 * jml actually dials up the code
<spiv> The problem is your code says "give me a full branch object with fallbacks and everything" when (at this point) it just wants "give me the branch and repository formats"
<jml> and what's the bzr API for that?
<mwhudson> pretty sure there isn't one, or at least wasn't back when we wrote this
<spiv> the_bzrdir.find_branch_format() / RepositoryFormat.find_format(the_bzrdir)
<spiv> Or I suppose you could use BranchFormat.find_format(the_bzrdir) for consistency.
<mtaylor> lifeless: I find the motu process/system quite frustrating
<mtaylor> lifeless: not that you can do anything about it - I'm just complaining :)
<jml> spiv, how do they interact with RemoteRepository
<jml> et al
<spiv> jml: IIRC you'd probably get back a RemoteRepository, still.
<spiv> jml: anyway, catching IncompatibleRepositories would work fine for this case, and would probably be the most minimal change.
<spiv> I don't really mind what you do so long as it works ;)
<igc> spiv: can I request a 30 second review ...
<igc> spiv: https://code.edge.launchpad.net/~ian-clatworthy/bzr/422533/+merge/10976
<bialix> hello igc
<vila> hi all
<spiv> igc: heh
<spiv> igc: 30 seconds was perhaps pessimistic :)
<vila> igc: Can I request a 30 secs test for that one-liner since you obviously found a hole in the coverage ? :)
<vila> igc: at least don't close the bug until you had that test...
<igc> vila: it's a formatting issue of very low priority - I don't feel a test is necessary sorry
<vila> it's untested code for which you had the test almost written since you encounter it, anybody else will spend more time on it
<spiv> vila: I don't think a test is worth it.
<spiv> It would be a test for the contents an error string; it's unlikely to regress, but adding a test would likely add needless friction if anyone *does* tweak the wording.
<spiv> It's a different case I feel to what we test in test_errors (which are generally worthwhile tests).
<vila> A test about an invalid property value is not worth it ?
<vila> right, I'm still dreaming, let's reboot
<vila> hi all, have a good day
<igc> vila: w.r.t. bzr-upload, what version should I include in the Windows installer?
<igc> vila: and in terms of help for it, all you need to do is ...
<igc> add whatever text makes sense to the module docstring
<igc> and the plugin guide generator will find it
<vila> igc: thanks ! Time to move the README there
<igc> vila: the Plugin Guide has one chapter per plugin
<igc> the first section for each is the plugin help, then one section per command provided by the plugin
<vila> igc: I intend to release 1.0 before bzr-2.0 so I'd like to have 1.0 there
<igc> vila: if required, I guess plugins could have extra help topics, e.g. upload-tips
<igc> vila: but if they do, I don't currently go looking for them ..,
<igc> and I'm not sure how hard or otherwise it would be
<vila> module doc string if perfect
<vila> at least to address the problem of giving more exposure to the doc :)
<igc> so for now, it's in the plugin top-level help or it's in help on a plugin command (or it doesn't make it into the Plugin Guide)
<lifeless> mtaylor: tell me more later :)
<mtaylor> lifeless: I will :)
<jml> Conflict: can't delete lib/lazr because it is not empty.  Not deleting.
<jml> 1 conflicts encountered.
<jml> rm -rf lib/lazr
<jml> bzr resolve lib/lazr
<jml> (guess how many times I've had to do that this week!)
<lifeless> poolie: I've done the bug status tweak I was mentioning earlier :)
 * lifeless waves ciao
<jml> lifeless, ciao
 * quicksilver tries running bzr pull over GPRS. should be fun.
 * quicksilver reflects that bzr+ssh would have been a better choice for a high latency link.
<NET||abuse> hey guys, trying to use the upload command here,,
<NET||abuse> the documentation is a little vague,
<NET||abuse> however i've done bzr help upload.
<vila> NET||abuse: did you read the README ?
<NET||abuse> now what do i do to point it at a location?
<NET||abuse> oh, it's in bzr by default on jaunty it looks like.
<NET||abuse> didn't load the plugin files into my ~/.bazzar
 * igc dinner
<vila> NET||abuse: http://paste.ubuntu.com/264826/
<NET||abuse> vila, yeh, i pulled down the source into my projects folder, have a copy of it now and am reading the README
<NET||abuse> much appreciated,
<NET||abuse> just trying to figure out,
<NET||abuse> how do i upload a subdirectory of the main branch?
<NET||abuse> i have other configurations for local testing and things in directories here, so i was just going to upload parts
<NET||abuse> and i have an extra directory layer that isn't on the live server
<vila> NET||abuse: You can't do that yet
<NET||abuse> means i should be able to just upload the src/server directory, it holds my www application system and etc directories.
<NET||abuse> arrg
<vila> You can only upload a full branch working tree
<NET||abuse> that's annoying.
<NET||abuse> that's pretty much useless then.
<NET||abuse> just have to do big scp transfers then
<vila> there are various ways to address it, none available yet
<NET||abuse> overwriting the whole site
<vila> one way is to create a dedicated branch as a fork of your trunk and delete all unwanted stuff there
<vila> you can then merge in that reduced branch and upload that
<vila> NET||abuse: filing a bug report explaining your use case can only help defining the feature
<vila> NET||abuse: or add your case description in bug #212677
<ubottu> Launchpad bug 212677 in bzr-upload "Should allow uploading specific files" [High,Confirmed] https://launchpad.net/bugs/212677
<NET||abuse> vila, ok, i'll add some description to that bug, bookmarked it.
<vila> poolie, lifeless, spiv, igc: data point: I upgradeb ~200 branches in a shared repo over NFS without trouble (~400MB of data processed there)
<vila> upgraded even
<vila> funnily enough, the first 'bzr info' after that whined about a NFS stale on a FoRmAt file, once and never again :)
<poolie> hello vila
<poolie> vila, i wonder if they had a flaky network card or switch or something
<vila> something weirder than that since the file disappear after several days, NFS is excluded as cause (IMHO)
<Lo-lan-do> Hi all
<Lo-lan-do> Is anyone in particular linked to Loggerhead?
<Lo-lan-do> I guess it's jelmer again :-)
<Lo-lan-do> jelmer: Any plans on uploading a recent Loggerhead to Debian?
<poolie> Lo-lan-do: or mwh, but he's not a dd
<Lo-lan-do> I'm going to need it for a client. I can do the required work (updating the packages and providing backports for Lenny) if needed, I'd just like to know in advance so it doesn't come as a surprise to them when IÂ bill for my time.
<Lo-lan-do> This could be said to be an offer for help, but I don't want to step on anyone's toes.
<jelmer> Lo-lan-do: Hi!
<jelmer> Lo-lan-do: You're more than welcome to help out with the loggerhead packaging
<jml> g'night poolie
<poolie> night!
<jelmer> Lo-lan-do: I was going to update your patch to fix the use of libyui-js, but have been away since debconf9 so haven't had much time for that
<poolie> nothing like a good night's sleep :)
<jelmer> (-:
<james_w> I put the latest loggerhead release in karmic the other day
<james_w> it's on bzr.debian.org
<jelmer> ah, great
<AfC> Has there been a 2.0-rc2 release as yet?
 * AfC is scared about the upgrade bug, and 2.0-rc1 is what Gentoo is shipping as ~arch right now
<vila> AfC: not yet
<luks> why do they ship release candidates?
<AfC> luks: they never used to package Bazaar's rc's, but I guess someone was listening to the fact that the lead up to 2.0 is a bit different.
<AfC> After all, we want people testing.
<luks> yeah, but making ever Gentoo user a tester is probably not such a good idea :)
<luks> +y
<jelmer> james_w: did you manage to keep the yui stuff in loggerhead working?
<james_w> was the patch not complete?
<jelmer> james_w: it was complete but last time I attempted to merge a new upstream I had trouble keeping the yui-js patch applied and loggerhead working
<james_w> hmm
<james_w> there were no conflicts, but I don't understand why
<lifeless> igc: something going south on this import :(
<lifeless> 10:10:27 64000/133780 commits processed at 263/minute (:64000)
<lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
<lifeless> still working on the next 1000
<lifeless>  4847 robertc   20   0 6153m 4.8g 1208 D    0 83.8 375:11.54 python
<lifeless>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<vila> bialix, bialix, where are you :-/
<vila> naoki: ping
<vila> naoki: You're the one I need ! revno 171 broke the test farm installer build
<vila> naoki: revno 171 of tortoisebzr I meant
<vila> naoki: http://paste.ubuntu.com/264900/
<Lo-lan-do> jelmer: Okay, thanks.  I'll keep in touch however things work out.
<jelmer> hmm, bzr-stats seems to think that lifeless, jam, igc and vila are the same person
<vila> jelmer: hehe, I mentioned that some weeks ago :)
<vila> I don't know when it occured, I wonder if --authors may have tricked it but that should have occurred months ago when we landed bbc
<Lo-lan-do> It's all a cabal anyway.
<vila> jelmer: Where did you run it ?
<jelmer> vila: bzr.dev
<vila> wow, just ran it on an upgraded bzr.dev, snappy :)
<vila> jelmer: so, that's really weird becase jam and vila survive but steal from each other anyway :D
<vila> lifeless and igc disappear completely though, shame
<vila> given only those four are involved, I'd say --author tricked bzr-stats, 90% sure :)
<jelmer> I'll have a look at it when I find some time
<jelmer> Yeah, 2a is teh awesome
<jelmer> I know I'm repeating myself, but I'm really looking forward to 2.0 !
<vila> :)
<jelmer> lifeless: how would a test have multiple statusses?
<bialix> vila: are you summon me up?
<vila> wow, magic bialix ! How did you know ? 8-)
<vila> I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
<mortehu> I get this on commit: bzr: ERROR: Cannot commit to branch BzrBranch6('file:///me/app/'). It is bound to BzrBranch6('file:///other/app/'), which is bound to file:///other/app/.
<vila> mortehu: no more than one level of binding
<mortehu> I see.  I'll have to read up on how this works.
<bialix> vila: ?
<vila> bialix: yes ?
<vila> bialix: I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
<bialix> I don't understand
<bialix> https://bugs.launchpad.net/tortoisebzr/
<bialix> you need this I guess
<vila> k
<mortehu> vila: You did notice that the last two paths in the error message were identical?
<vila> mortehu: no
<vila> that;s weird
<bialix> vila: naoki said something about removing some dependencies from tbzr build so he can build with other compiler or sdk
<bialix> vila: so maybe there is difference in build environment between him and your slave
<vila> I filed a bug
<vila> bu g#424303
<vila> bug #424303
<ubottu> Launchpad bug 424303 in tortoisebzr "fix for #421890 broke the automated installer build" [Undecided,New] https://launchpad.net/bugs/424303
<bialix> ok
<vila> mortehu: what is your setup ? Can you issue 'bzr info' in each branch involved /
<vila> ?
<mortehu> Checkout (format: pack-0.92) Location: branch root
<vila> mortehu: don't spam the channel, use a paste service instead and copy the whole output
<mortehu> That was the whole output.
<vila> >-/
<vila> bzr version
<mortehu> 1.5
<vila> ouch, what os are you using ?
<mortehu> It's some other dude's repository (I normally use something else).  He went to sleep. :)
<mortehu> Debian
<vila> 1.5 is... more than year old... but I'm surprised we can't get more info... try 'bzr info -v' ?
<mortehu> I'll just put the files in his working copy and have him commit in the morning.
<mortehu> Thanks for your time, by the way.
<vila> mmmm, branch6... did we even support that in 1.5 ?
<vila> yes we did
<mthaddon> not sure if anyone's around who can help here, but I'm testing the upgrade of the bzr PQM instance and running into problems because the existing format is pack-0.92 but current lp:pqm is 1.14-rich-root or 1.9-rich-root - can I convert the current branch to the right format?
<jelmer> mthaddon: I think so
<jelmer> mthaddon: At least, can't think of any reason why that would be a bad idea
<mthaddon> jelmer: so how would I do that? bzr upgrade --1.14-rich-root ?
<jelmer> mthaddon: yep
 * mthaddon gives it a go
<mthaddon> jelmer: cool, worked a treat, thx
<jam> jelmer: that would be a rather prolific person, then
<jam> jelmer: Unittest doesn't declare that you can't call both addError and addSuccess from the same test
<jam> I've seen it getting a successful run, and then an error during cleanup
<jam> or even 2 errors :)
<jam> morning vila
<vila> morning jam
<Kobaz> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was         made: 'chroot-163675084:///project/base/'.")
<Kobaz> i upgraded bzr on my server and now i get that
<Kobaz> i'm using bzr+https://
<Kobaz> with the bzr-smart thingee
<jelmer> did the submit branch for bzr change recently?
<jam> Kobaz: known bug, I'll try to track it down for you
<jam> jelmer: yes
<jam> it is now on LP
<Kobaz> jam: yeah i found the bug, it poped up in 1.16
<jelmer> Should I just be using lp:bzr?
<jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<jelmer> jam: thanks!
<Kobaz> supposidly was fixed in 1.17
<Kobaz> but it's still happening in 1.17
<Kobaz> https://bugs.launchpad.net/bzr/+bug/400535
<ubottu> Launchpad bug 400535 in bzr "ChrootServer/ChrootTransport not used by "bzr serve"" [Critical,Fix released]
<Kobaz> looks like a regression
<jam> Kobaz: actually 348308
<jam> bug 348308
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<jam> there is a workaround in that bug report
<Kobaz> hm
<Kobaz> is there anything obviously bad about using the workaround?
<Kobaz> or should i stick with what i've been using: 1.13
<jam> Kobaz: generally I would recommend newer bzr's for a variety of reasons
<jam> I don't think the workaround is that bad
<jam> we really need to get something like that into a real fix
<Kobaz> what's major between 1.13 and 1.17?
<jam> Kobaz: significantly better streaming + stacking support, support for the 2a format repository which is the default in 2.0 (to be released in the next week or two)
<jam> I can point you to NEWS if you want details
<Kobaz> k sure
<Kobaz> hmm
<jam> Kobaz: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
<Kobaz> okay, the workaround appears to be working
<rockstar> jam, hi
<jam> hey rockstar
<rockstar> jam, I seem to have a brokenness in my tarmac trunk that is preventing me from merging a branch.
<rockstar> (I originally thought it was a tarmac bug, but bzr reports the same error, hiding the spectacular traceback)
<rockstar> jam, pastebin -> https://pastebin.canonical.com/21836/
<rockstar> Shoot, that probably should have gone to p.u.c
<jam> rockstar: we use p.c.c fairly often here
 * rockstar is still getting used to working on Free Software every day.
<jam> rockstar: so I *think* that xml 5 is non-rich-root
<jam> which means it shouldn't be existing in your rich-root format repo
<jam> trying to do 'bzr pull' I'm getting the same error
<rockstar> jam, target branch for merge is 2a
<rockstar> jam, also, it's possible that your branch is pre-upgrade, so pulling in gets the same error.
<jam> that isn't what I see here: https://code.edge.launchpad.net/~rockstar/tarmac/main
<rockstar> jam, chk inventories == 2a, right?
<jam> rockstar: yes
<rockstar> abentley, ^^
<jam> ah...
<jam> Development repository format
<jam> which would be... --dev6 or so
<jam> certainly something weird going on...
<jam> I wonder if you merged a broken bundle but had it successfully merge
<rockstar> How do I find that out?
<abentley> rockstar: looking...
<jam> rockstar: I'm trying to lftp mirror it to check
<rockstar> abentley, for background, it looks like tarmac trunk is broken.
<jam> also, there should be 0 xml inventories in chk inventory land
<rockstar> jam, I thought I remembered you talking about that at AllHands.
<jam> rockstar: downloading now
<abentley> jam: if you need an exact mirror, you can use "hitchhiker mirror . $LOCAL_PATH"
<jam> abentley: thanks
<jam> so... once I did the mirror using lftp, it doesn't seem broken on this end... :(
<jam> hm... I wonder about bzr 1.17 on lp versus bzr.dev locally
<jam> ah, or cross-format issues
<jam> checking a few things
<jam> rockstar: so your trunk is in --dev6-rich-root and not --2a
<jam> which might be a problm
<jam> I'm guessing bzr 1.17 is trying to send the revisions using the generic streaming code
<jam> which was broken until recently fixed (prob bzr 1.18 required)
<rockstar> Hm, how'd that happen?  I specified --2a on the upgrade.
<jam> rockstar: bzr info sftp://bazaar.launchpad.net/~rockstar/tarmac/main/
<jam> Repository branch (format: development6-rich-root)
<rockstar> :/
<jam> so 1.17 is probably trying to cross-format stream by casting to XML inventories, and newer bzr's don't like it
<jam> and they shouldn't, because xml5 wasn't actually compatible with --dev6, we just didn't realize it in time
<jam> rockstar: can you do a similar 'bzr info' check?
<jam> I'm wondering about a problem between the hosted side
<jam> and the mirrored side
<jam> as I'm pretty sure *my* sftp access gives me the mirror
<rockstar> repository: Development repository format - rich roots, group compression and chk inventories
<jam> rockstar: that would be --dev6
<jam> so my suggesstion...
<jam> 'bzr upgrade --2a'
<jam> possibly prefixed with
<jam> hitchhiker lp:tarmac rmtree backup.bzr
<rockstar> Also, if I upgrade my branch locally, and push, the pushed version won't get upgraded, so I need to rmtree .bzr as well, right?
<jam> rockstar: when you push, we preserve
<jam> I was actually meaning "bzr upgrade --2a lp:tarmac"
<jam> so upgrade the remote
<jam> but yeah, you could do it the other way as well
<jam> bzr push --use-existing, etc.
<rockstar> Okay, great.
<nealmcb> Sometimes I clone an individual file in a project and then it evolves on its own.  is there any way to track that in bzr?
<nealmcb> e.g. so I could go to the clone, ask for a history, and find out that earlier history was in the file it was cloned from?
<rockstar> nealmcb, how are you cloning the individual file?
<awilkins> nealmcb: No, Bazaar has no model for copying files as yet
<nealmcb> rockstar: now I 'clone it' with cp....
<nealmcb> awilkins: do you know of others that do?
<nealmcb> not a big deal, but I like meta information :)
<awilkins> Subversion will let you do it. I don't know about Mercurial or git, but I suspect git might by dint of the way it works internally
<luks> svn does :)
<nealmcb> thanks
<rockstar> jam, I just did an upgrade and a fresh branch, and I still get: Development repository format - rich roots, group compression and chk inventories
<michaelforrest> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'ProgressBarStack'
<rockstar> jam, this is a new shared repo as well, created with bzr init-repo --2a
<vila> jam: hurrah ! #412930 approved :-D
<vila> michaelforrest: out-of-date bzr-gtk plugin ?
<bialix> vila: oho
<jam> rockstar: unfortunately it looks like RepositoryFormat2a doesn't have its own get_format_string
<rockstar> jam, but it merges this time...  O_o
<jam> so it is re-using the old one
<rockstar> jam, is that a bug?
<bialix> vila: can you kick the build of tbzr as of revno.171?
<jam> sorry, it is get_format_description( that we need
<jam> anyway, yeah, I'm reporting it as a bug
<jam> should be easy to fix
<vila> bialix: kicked
<bialix> vila: I think revno.172 introduced that problem with build
<vila> ha 171, no, I don't have that level of detail, I thought it wsa a new revision, sorry
<michaelforrest> hurray! thanks vila.
<vila> I used qlog and searched for the last revision that modified the file and got the revision I indicated
<bialix> vila: in revno 172 naoki removed definition of ARGB typedef, I think this is root of problem
<vila> bialix: ohh, I see what you mean,
<vila> I just run qlog again
<vila> bialix: I think you're right but the way the build works today, I can only use the tip of the branch
<bialix> well, I'm not sure it will be good idea to commit there just to check this idea
<vila> let's wait for naoki input then
<bialix> vila: oki
<bialix> what is "square dancing"?
<bialix> emmajane: ^
<vila> bialix: not sure, I think it north american folk dance :)
<vila> bialix: not sure, I think it's a north american folk dance :)
<emmajane> vila, aye :)
<emmajane> bialix, google for "square dance tutorials" :)
<vila> emmajane: clicking images for that search gives.... suprising results :)
<emmajane> vila, lots of poofy skirts?
<vila> not exactly... nothing wrong either, just not really related
<emmajane> heh
<emmajane> maybe google.ca gives different results.
<bialix> not sure about google results.
<bialix> it's a dancing on the streets?
<abentley> bialix: The "square" means that people are arranged in a square, facing each other.  It doesn't refer to city squares.
<emmajane> bialix, did you look at the slides?
<vila> argh, grrr, google.fr ! I hate that, how many times should I bang google on the head so that it understand I want google.com and nothing else *by default*. I can go to localized version when *I* want thank you very much
<emmajane> bialix, there are actually pictures and links in the slides.
<bialix> which slides?
<emmajane> bialix, that I dented
<emmajane> bialix, I assume that's what you're referring to?
<bialix> I'm not sure
<awilkins> Bah, being back at work sucks
<vila> awilkins: go back to vacations
<awilkins> Just got my reminder to do my pointless weekly blog
<bialix> ok, nm
<awilkins> My manager wants me to set up 15 user profiles that take 10 minutes each and I'll also have to badger people for their passwords to do it. Which is silly.
<awilkins> And now i'll stop whining
 * emmajane blinks.
<jam> awilkins: script it :)
<jam> make sure the script includes a poorly written email asking users for their passwords
<vila> jam: ROTFL
<awilkins> jam: It's a fricking GUI :-(  I have the sources :-)  They are horrible :-(
<vila> go directly to jail don't get the 20.000 FF :)
<awilkins> Freedom Fries? I'd be one FF if I ate 20,000 Freedom Fries :-p
<Lo-lan-do> FusionForge!
<vila> awilkins: close but no cigar :) Very close: French Francs, I didn't play monopoly since more than... the time we switch to Euro :)
<Lo-lan-do> (Note that FusionForge now supports Bazaar, although the pluginisn't quite complete yet)
 * awilkins knew it was French Francs, which is why the joke about Freedom Fries was funny. ish.
<Lo-lan-do> (But it will be soonish, see above for my reasons)
<jelmer> Lo-lan-do: w00t!
<jelmer> Lo-lan-do: Any idea when that sort of stuff would end up on alioth?
<Lo-lan-do> jelmer: It's *already* on alioth :-)
<vila> awilkins: I thought you were british and that the fries joke was north-american only :)
<Lo-lan-do> But the incompleteness shows: no commit stats and no Loggerhead.
<awilkins> I am British, but we hear enough of the American news to know the phrase "Cheese-eating Surrender Monkey"
<Lo-lan-do> I recently completed/fixed the git plugin for another customer. bzr is next.
<vila> Never went to war myself, I can speak about the surrender part, but I like cheese and I'm a monkey :)
 * Lo-lan-do fills up the Channel Tunnel
<awilkins> There's a bloke who wants to open a British restaurant in Italy... partly to show case our cheeses (which are different, but good too)
<vila> british cheese ? I thought you eat only dutch cheese :D
<awilkins> vila: Edam is like plastic
<Lo-lan-do> If I ever go on a month-long tour of Europe, I'll be sure to taste stuff besides the typical.
<vila> let's start some european civil war to start the week-end :D
<awilkins> vila: We have some of the greats, like cheddar, stilton, stinking bishop
<awilkins> I do like Jarlsberg
<Lo-lan-do> English cheese, German wine, Greek beer, and so on.
<awilkins> I was shocked to find myself liking _Amercian_ beer
<awilkins> But only the local stuff from microbreweries
<vila> ..and counting ? I went to visit some friend last week-end and he said: "See, we do some wine and some cheese here", to which I replied: "Funny, nearly every french can say that, whaterver region they are from, they do some local wine and cheese !" :-D
<Lo-lan-do> The only beer I managed to like is (kill me now) Kriek.
<vila> Lo-lan-do: Belge une fois ?
<Lo-lan-do> I am not!
<awilkins> I like kriek. And framboise
<vila> No offence meant :)
 * Lo-lan-do is a garlic-stinking, pastis-drinking, smelly-cheese-eating Frenchman
<Lo-lan-do> No moustache though, sorry.  It itches.
<tbradshaw> hmmm
<tbradshaw> so I'm getting a bzr error on the creation of a fresh local repo?
<luks> are you?
<tbradshaw> indeed, but it seems so unlikely. :/
<tbradshaw> http://pastebin.projects.quakecon.org/67
<luks> you are misunderstanding bzr concepts
<luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#core-concepts
<tbradshaw> what am I misunderstanding?
<tbradshaw> is it just that "status" doesn't operate on a repostory?
<luks> yes
<tbradshaw> which would make sense, of course, but I wouldn't expect an error in that case
<luks> why not?
<luks> it's like running "cat" on a directory
<tbradshaw> because a command with unfulfilled prerequisites shouldn't execute?
<luks> it doesn't, and it tells you why
<tbradshaw> cat on a directory gives a very reasonable response. :)
<tbradshaw> but, anyway, I don't mean to get into a critique on software behavior
<tbradshaw> I'm satisfied knowing that bzr doesn't work on repositories and I was just misusing it
<luks> bzr st tells you that there is no working tree
<luks> so it can't operate
<tbradshaw> indeed
<tbradshaw> the curiousity was that it gives an error on an nonexistent directory
<tbradshaw> which lead me to believe an error during construction, rather than a simple misuse
<tbradshaw> but, that's okay, it's still just a user error. :D
<luks> that's where it would expect the working tree to be defined
<luks> I agree the error message should be nicer
<luks> if you want to "work" with bzr, you need to create a branch
<tbradshaw> thanks for pointing out the difference, however.
<luks> which is done using: bzr init
<luks> bzr init-repo just creates a container for revisions
<tbradshaw> yes, my intention was to create a local repository, such that I could store some related branches
<tbradshaw> I had just been using bzr status liberally as a "sanity check"
<luks> yep, then you need bzr init inside that directory
<luks> you can run bzr info as a sanity check
<tbradshaw> and so when my "sanity check" failed, I ran for help
<tbradshaw> ah!
<luks> it will tell you what is in the current directory
<luks> but status is strictly a working tree operation
<tbradshaw> so I should also bzr init?  Or would I go right to branching?
<tbradshaw> my hope is to set up my local repository
<tbradshaw> such that I have ./trunk
<tbradshaw> and ./username/branches
<luks> if you already have a branch somewhere, you can use bzr branch
<tbradshaw> if that sounds reasonable
<luks> I thought you are creating a new project
<tbradshaw> no sir, launchpad stuff
<tbradshaw> I just haven't done the local repository before
<luks> ah, bzr branch is it then
<tbradshaw> is it necessary for additional branches to be directly in the local repository?
<tbradshaw> or can the local repository have some directory structure of it's own?
<tbradshaw> ala, is it okay to mkdir branches, then branch other things from launchpad into that directory?
<luks> no, you can have subdirectories there
<luks> bzr will look for the repository in all parent directories until it finds one
<Lo-lan-do> You can have branches separately.  Read about "lightweight checkouts".
<Lo-lan-do> Hm.  Maybe I'm replying to the wrong question.  Ignore me please :-)
<tbradshaw> :)
<tbradshaw> yeah, that looks exactly how I had hoped it when when done
<tbradshaw> thanks for setting me straight luks
<tbradshaw> I appreciate the time and instruction. :)
<luks> sorry about the first reaction :)
<luks> I thought you are a git user trying to use bzr as git :P
<luks> withuot reading the documentation
<tbradshaw> ha ha!  Nope.  Just a longtime svn user, still trying to wrap my head around distributed version control.  I'm about 85% of the way there. :)
<tbradshaw> but I make some poor assumptions sometimes, as you noticed.
<tbradshaw> anyway, thanks again. :)
<garyvdm> Hi igc
<igc> hi
<igc> night all
<mthaddon> about to update PQM after the current run, if anyone's interested
<michaelforrest> is bzr viz supposed to support viewing differences between multiple branches?
<michaelforrest> I don't know how collaboration is supposed to work if I can't get a project overview like the github network graph..
<garyvdm> michaelforrest: It can do it if the first branch has all the revisions that are in the second branch
<michaelforrest> yeah that doesn't really help me
<garyvdm> michaelforrest: If not, it fails silently.
<michaelforrest> I want to see everything everyone's done
<garyvdm> michaelforrest: qlog is much better at that
<michaelforrest> so I can see if there's anything worth taking
<michaelforrest> what is qlog?
<michaelforrest> a plugin?
<garyvdm> michaelforrest: simialar to viz, but better, found in qbzr plugin.
<michaelforrest> ok
<michaelforrest> I'll try that
<michaelforrest> thanks
<michaelforrest> oh, except... I'm on a Mac!
<garyvdm> :-( - I believe that it is possible to run qbzr on a mac, but the installation is difficult.
<garyvdm> michaelforrest: specifically the pyqt install.
<michaelforrest> I'll see if macports does the job
<luks> it seems there is a py25-pyqt4 port
<luks> so it should work, it will just take some time
<michaelforrest> ah ,thanks luks
<garyvdm> Hi luks
<luks> hi garyvdm
<garyvdm> luks: I'm working on: http://bazaar-vcs.org/qbzr/Blueprint/BrowseRedesign
<garyvdm> bbl - Dinner
<luks> the mockup looks good
<luks> but implementing it will be harder, as it's not exactly standard UI
<naoki_> I'm sorry. I fixed tbzr build error.
<naoki_> I can't build trunk directly because I don't have VC++2008 Std.
<naoki_> I don't know autobuild environment. Is it build another branch?
<jam> naoki_: we have buildbot running on a win2k3 machine
<jam> http://babune.ladeuil.net:26862/waterfall
<vila> naoki_: still no good, but I'm not sure the bot got your last revision
<naoki_> For example, (1) push to lp:tortoisebzr/pre-trunk, (2) autobuild (3) push to lp:tortoisebzr
<jam> specifically something like: http://babune.ladeuil.net:26862/builders/installer-dev-plugin-dev
<vila> jam: it looks like my pqm submission go in a black hole... no feedback mail :-/
<jam> vila: are you using the right submit branch?
<jam> blackholes suck, though...
<jam> it seems to happen often with pqm
<vila> I used bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev, should I use http instead ?
<vila> trying, will pass around later, dinner time
<jam> vila: yes, http
<vila> jam: even more obscure, I have mail in bazaar-commits for my submissions !
<vila> jam: that is, the mails are accurate, but the revisions are nowhere to be seen, neither in the old trunk nor the new one...
<vila> finally, the submission to http came back as failure: nothing to merge
<BasicOSX> Great job on 2a, love it!
<jam> vila: so... when you submit to pqm it does the merge and commit locally, and the pushes that to lp
<jam> it is *possible* for that push to fail
<jam> in the past we had problems with redundant packs after autopack, etc
<jam> and that tends to kill pqm but give it 'nothing to do'
<jam> because its local branch has the revisions merged
<jam> thanks BasicOSX
<jam> yeah, I just branched 'bzr.dev' from scratch in about 3m30s
<jam> down from 12m+ last I used it
<BasicOSX> yeah, same here. Amazing speed increase
<vila> jam: yup, I came to the same conclusion, the merge went fine, the push failed, no idea how to track that further though without a LOSA :-/
<jam> vila: Not possible, as far as I know
<jam> mthaddon ,or spm ?
<mthaddon> vila: how can I help?
<vila> ho !
<jam> mthaddon: it would seem that pqm successfully merged something but failed to push it to lp
<vila> mthaddon: it seems that pqm can't push to lp
<jam> can you check pqm's logs?
<mthaddon> jam: sure - when did this (not) happen
<jam> vila knows for sure
<jam> maybe 3 hours ago
<vila> I think I did the submission 2h30 ago
<jam> vila: yeah, and the email is sent post push, not post commit
<jam> so that also would fit the symptoms
<mthaddon> jam, vila: https://pastebin.canonical.com/21854/
<jam> mthaddon, vila: looks like a direct bug in pqm
<jam> something got a string pointing to a branch, and thought it was getting a Branch object
<jam> perhaps aliasing of a variable?
<mthaddon> jam: possibly not - https://pastebin.canonical.com/21856/
<jam> mthaddon: well, that could be a factor too, but certainly pqm shouldn't be treating a string as a Branch object :)
<vila> damn it, can you check the authentication.conf file
<jam> the latter may have triggered the former, though
<vila> mthaddon: if auth.conf exists in ~/.bazaar and user is not bzr-pqm... that will explain why spm called auth.conf with poetic names
<vila> mthaddon, jam : that's in addition to the direct pqm bug of course
<mthaddon> https://pastebin.canonical.com/21858/ is from .ssh/config and the public key seems to match https://edge.launchpad.net/~bzr-pqm/+sshkeys
<vila> mthaddon: at worse, you should check with spm about auth.conf, my memory of the discussion is that you shouldn't use lp: on pqm only bzr+ssh urls
<mthaddon> vila: I tried it again with bzr+ssh urls - got the same
<vila> mthaddon: but what appear in ~/.bazaar/authentication.conf ?
<mthaddon> although for some reason auth.conf has launchpad-pqm user :(
<vila> mthaddon: if you don't specify a user in the url, auth.conf will provide it
<vila> here we are....
<nxvl_> hi! i was wondering about the "--fixes" option, in the docs it says i can close multiple bugs, but it doesn't say how the parameters need to be passed
<mthaddon> was updated 2009-09-04 14:47
<vila> so,  the solution is to remove auth.conf
<nxvl_> as in space separated, comma separated, a --fixes option for each
<vila> but we need to understand how and whem it came back
<mthaddon> vila: why would that have been created?
<vila> mthaddon: *you* tell me :-D
<vila> my 8-ball can't read the logs there :)
<mthaddon> vila: which logs?
<vila> mthaddon: It was a joke, I have no idea where to look :-/
<vila> .bzr.log certainly, but for what command ?
<mthaddon> yeah, me neither :(
<vila> Some command that use lp: certainly since that is the one that trigger the creation of the [launchpad] section in auth.conf,
<mthaddon> vila: should I just remove that file for the moment?
<vila> but I don't know precisely which... lp-login ? What did bazaar.conf says ?
<vila> mthaddon: yes
<mthaddon> vila: oh, hang on a sec...
<vila> err
<vila> hang on
<mthaddon> so I did an upgrade of PQM earlier
<vila> what hour ?
<mthaddon> let me confirm
<vila> in pqm time so we can relate to 'was updated 2009-09-04 14:47'
<mthaddon> about three hours ago...
<mthaddon> so this is sounding promising - if we just remove this file we should be good
<mthaddon> which I've now done
<vila> in bzr trunk you should now be able to try: 'bzr missing :push' and it should tell you about 2 missing revisions
<mthaddon> I'm not really sure what directory that'd be from, locally - let me see if I can find anything
<vila> ,bzr.log should give you some hints
<mthaddon> vila: https://pastebin.canonical.com/21859/ <-- gah!
<vila> mthaddon: 'bzr info' ?
 * vila wonders what escudero maps to...
<mthaddon> https://pastebin.canonical.com/21860/
<vila> mthaddon: 8-( I'm lost
<vila> lifeless, jam: wrong setup on escudero ?
<jam> nxvl: --fixes A --fixes B --fixes C I believe
<nxvl> jam: thnk you!
<vila> nxvl: I confirm, I used it last today (sry missed the question)
<jam> vila: pqm shouldn't be pushing to escudero directly
<jam> I believe it pushes based on the submit branch
<jam> and its internal config
<mthaddon> well at least bzr ls bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev is working now
<jam> whatever maps http://bazaar.lp.net/... => bzr+ssh://...
<nxvl> vila: :D
<mthaddon> vila: I see two revnos diff between that dir locally and bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev - should I just push to there?
<jam> mthaddon: sure
<vila> mthaddon: that's what I want yes, thanks :)
<mthaddon> jam, vila: ok, done
<mthaddon> now up to revno 4674
<vila> mthaddon: what I hope though, is that you won't have to do it for every submission :)
<mthaddon> :)
<vila> mthaddon: thanks a ton !
<mthaddon> sure - I'll keep my fingers crossed
<vila> mthaddon: we should check with spm about that authentication.conf mess, there is a bug waiting to be fixed there :)
<vila> may be even some in pqm, no feedback is really bad in these circumstances
 * vila EODing SWEing :)
 * fullermd SBI NRZ's to vila.
<jam> well, I think someone like lifeless gets an email when pqm crashes like this
<jam> but it doesn't help the submitter much
<jam> until he wakes up and notices :)
<kfogel> LarstiQ: https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233  :-)
<lifeless> jam: crashes how?
<lifeless> jam: also, how to get a memory trace from a running bzr process?
<lifeless>  4847 robertc   20   0 6284m 4.8g 1200 D    0 84.1 379:17.46 python
<jam> lifeless: pqm was crashing by failing to push to lp:bzr
<jam> it seems that ~/.bazaar/auth.conf  got set
<jam> and so it was trying to login as someone like spm
<jam> in doing so
<jam> it failed to send a message to vila about his merge
<jam> it would successfully merge, run the tests, commit, push would fail
<jam> no email
<lifeless>  fixed in pqm trunk
<lifeless> I think
<jam> also, there was a bug about "parent_branch" being a string
<lifeless> theres an RT ticket for deployment alreadyt
<jam> when it thought it should be a Branch object
<jam> for memory trace
<jam> bzr branch lp:~jameinel/+junk/py_memory_dump
<jam> setup.py install (needs pyrex)
<jam> then
<jam> SIQUIT
<jam> from memory_dump import scanner
<jam> scanner.dump_gc_objects('foo.json')
<jam> though right now I'm making decent use of
<jam> trace.debug_memory()
<jam> which just uses /proc/PID/status
<lifeless> this is the netbeans import
<lifeless> its now 6:42
<lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
<lifeless> was the last output
<lifeless> its been thrashing for 19 hours
<jam> lifeless: well, IIRC from igc, if you just do 'bzr fast-import foo.fi' the fast-import code caches all texts in memory
<jam> there was something about doing a 2-pass system
<jam> which allows the code to know what texts will be referenced again
<jam> which has been implemented, I believe
<lifeless> jam: I think it caches refs to them; its a 129G .fi file:
<jam> but igc knows better
<jam> lifeless: no, it caches the texts
<jam> see igc's recent comments about how fast-import isn't ready to scale to really-big-imports
<jam> at least, that is what I understood from various threads
<lifeless> hes being doing kernel and openoffice
<jam> lifeless: with 2 passes
<jam> I would assume
<jam> 1 pass generates a map
<jam> used in the second pass
<lifeless> anyhow, I'm going to get a trace, file a bug, and zerg it :P
<RenatoSilva> hey what's this? http://pastie.org/606334
<Xavura> It's a URI.
<Xavura> :x
<RenatoSilva> how to solve that error? is it a bzr bug?
<jam> so lifeless on my networking issues
<jam> I came back late at night from my slower Linux server, and branched all of bzr.dev in 3.5min
<jam> which was great
<jam> though my last time on the Windows box was 14min
<jam> (both post-pack)
<jam> Unfortunately I didn't try again to see if it was time of day, versus windows/linux
<jam> I did test right now, and I can get about 1.5MB/s (byte not bit) on my wireless network from a local server
<jam> on windows (using rsync)
<jam> I wonder if maybe our code that does some cpu processing while reading is causing problems on windows
<lifeless> that would show up with the window being full
<lifeless> we can tell the os we want it to be bigger
<lifeless> uhm
<lifeless> rephrase
<lifeless> 'it might be paramiko'
<lifeless> I suggest trying paramiko on linux, from the same machine
<lifeless> [as few variables changed as we can]
<fullermd> RenatoSilva: It's some plugin being out of sync with your bzr.
<fullermd> RenatoSilva: rebase, maybe?
<mthaddon> lifeless: PQM upgrade seems to be busted
<mthaddon> for U1 at least
<mthaddon> lifeless: https://pastebin.canonical.com/21864/
<lifeless> mthaddon: did the new dep get installed?
<mthaddon> lifeless: it did, yep
<lifeless> oh fnar fnar that looks like a bug
<lifeless> gimme a sec I'll check trunk
<mthaddon> thx
<lifeless> ok just delete the parameter on that line
<lifeless> it passed tests. Clearly that line isn't tested :(
<mthaddon> lifeless: erm, which parameter on which line?
<statik> mthaddon: the same patch I already pasted :)
<mthaddon> ah!
<lifeless> pushing rev with it in it anyhow
<lifeless> statik: mthaddon: sorry about that
<statik> no worries
<lifeless> gimme a week with nothing else queued, I could really sort pqm out
<mthaddon> lifeless: I think we can fit one of those in around about April 2035
<lifeless> that soon? :)
<mthaddon> yeah, I'm being optimistic
<lifeless> jam: ok, dumping that json; whats the easiest tool to use to answer 'where did 6G of ram go' ?
<RenatoSilva> fullermd: what's rebase and out of sync with bzr?
<jam> lifeless: cat foo.json | sort | uniq | sort [something to sort on the size column] > sorted.json
<jam> there is also
<jam> memory_dump.loader
<jam> om = memory_dump.loader.load('dumpfile.json')
<jam> s = om.summarize()
<jam> print s
<jam> print s.summaries[0]
<jam> the introspection stuff could certainly use more work
<jam> but it may be a start
<jam> I also have a branch of runsnakerun that can load them an compute square maps, etc
<jam> but at 6GB, rsr is pretty useless
<jam> there are probably enough objects that just loading the dump is going to be a couple G
<fullermd> RenatoSilva: Well, it's on your list of plugins.  The erroring function sounds like something I think is in rebase.
<RenatoSilva> what's rebase?
<fullermd> The plugin.
<RenatoSilva> bzr pull -----> not a branch
<RenatoSilva> how to solve this
<RenatoSilva> I just want to make it work
<fullermd> Well, presumably it's installed from a release, so it would need one in sync with your bzr.  I don't really know details; I don't use rebase.
<fullermd> (I don't know for sure rebase is what's causing your problem either, but I know I've heard that error before related to plugins, and rebase seems the most likely suspect)
<bialix> I've got error in tests in my plugin:   File "bzrlib\commands.pyo", line 212, in get_cmd_object --> BzrCommandError: unknown command "init"
<RenatoSilva> I don't use rebase either, I did not even know that thing ever exist
<bialix> what I should do?
<jam> RenatoSilva: the error is a known bug in bzr's 1.17 win32 installer because it bundled a version of bzr-rebase that caused 'bzr help commands' to fail.
<jam> use a different installer
<jam> 1.18rc1
<jam> etc.
<bialix> invoke install_bzr_command_hooks for those tests?
<jam> RenatoSilva: note that there are no known real problems with 1.17, just that 'bzr help commands' is unhappy
<bialix> dear core devs, can you give me advice?
<RenatoSilva> jam: official release is still 1.17? Ok at least I know the cause, I guess I'll wait for the fix in official release or so
<jam> RenatoSilva: 'bzr pull ==> not a branch' probably means you don't have a branch... either the source or the target
<RenatoSilva> jam: rebase is not a branch
<RenatoSilva> btw, I'd run bzr help commands to know how to see/change my user name that go into commits
<RenatoSilva> since I won't install RCs, I ask here, how? :)
<bialix> lifeless: should I run install_bzr_command_hooks for my tests if I need get_cmd_object to work?
<jam> RenatoSilva: bzr help commands --no-plugnis
<jam> bzr help commands --no-plugins
<jam> bzr whoami
<lifeless> bialix: the main one in bzrlib? no
<RenatoSilva> yeah, whoami!!!!!
<RenatoSilva> jam: thanks!
<bialix> lifeless: so why my test failed on get_cmd_object then?
<lifeless> bialix: I'm not here today - if jam can't give you a hand perhaps post to the  list?
<bialix> ok
<bialix> jam: can you give me advice about get_cmd_object?
<RenatoSilva> the whoami is stored for each OS user in his profile right?
<lifeless> bialix: I would guess though that you've overridden setUp()
<lifeless> and not called the base class setUp
<lifeless> or something like that
<bialix> lifeless: no
<jam> RenatoSilva: yes
<jam> bialix: I don't know much about it, without having a bit more background of how the test is failing
<jam> however, I'm also done for the weekend...
<bialix> ok, thanks guys for making bzrlib api harder to use
<RenatoSilva> ok tahnks
<lifeless> bialix: that makes me sad, that you say that
<lifeless> bialix: I'm sorry its giving you trouble; if you mail the list I'll be happy to help figure it out, but I can't today.
<bialix> lifeless: I found that you invoke install_hook in the test_commands.py
<lifeless> I'm doing breakfast then out finding stuff for my brothers birthday
<lifeless> bialix: yes, but thats to test that the hooks work
<bialix> it's not the part of TestCase setUp()
<lifeless> all normal bzrlib tests have the commands registered by default
<bialix> perhaps when I run selftest -s bp.scmproj it won't
<lifeless> bialix: the hooks are setup by doing run_bzr_command
<bialix> and I'm using run_bzr()
<lifeless> bialix: if you don't call run_bzr_catch_errors or run_bzr_catch_user_errors at all, they won't be registered
<lifeless> bialix: why?
<bialix> because it works for my plugin
<lifeless> well, if you want to call it directly, yes then you will need to install the hooks manually.
<bialix> yep, explicit call to install_hook helps
<bialix> thanks
<lifeless> calling it directly will mean you don't get error formatting
<lifeless> its better to call one of the run_bzr_catch variants
<bialix> lifeless: no, I need only run_bzr()
<lifeless> bialix: why?
<bialix> because I run bzr commands as in-process
<lifeless> in the test suite or your ui?
<bialix> in my backend
<lifeless> sounds like you have an implementation of run_bzr_catch_user_errors
<lifeless> can you not just use it directly?
<bialix> lifeless: you said you're busy ;-) I'm just want to release my plugin and make its test suite pass again after 7 months of not running it
<bialix> even if it ugly inside
<lifeless> kk
<bialix> it working in the end
<bialix> all tests passed, everybody happy
<RenatoSilva> How to delete the latest revision from Launchpad branch?
<RenatoSilva> Anything better than branch+uncommit+revert+delete+push?
<bialix> uncommit lp:xxx ?
<RenatoSilva> bialix: it will uncommit directly in the lp copy?
<bialix> it should
<RenatoSilva> cool, but I won't get uncommited stuff when I branch it, or will I?
<bialix> but I'm not sure what is lp copy for you
<bialix> no, you don't get
<RenatoSilva> launchpad's copy of the branch, not local copy
<bialix> I'd rather to not use term "copy"
<RenatoSilva> why
<bialix> because they are different branches
<bialix> you're working with dvcs in the end
<bialix> RenatoSilva: those branches like twins: they seems similar but have different wives
<RenatoSilva> bialix: ok got it, but with copy I meant same revisions, non-diverged
<bialix> is the wall of white house still white when you to trun round the corner?
#bzr 2009-09-05
<lifeless> jam: the scanner dump just finished :)
<lifeless> jam: 6.4G 2009-09-05 09:46 foo.json
 * lifeless goes again
<BasicOSX> bzr check, what does "inconsistent parents" mean?
<poolie> BasicOSX: hi, it means there's a difference between the graph index and the parents recorded in the revisions
<poolie> reconcile should fix it
<BasicOSX> https://bugs.launchpad.net/bzr/+bug/418492 is bug I opened on it, I'll try with latest pull
<ubottu> Ubuntu bug 418492 in bzr "ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository" [High,New]
<Stavros> hello
<Stavros> how can i change the name of a commit?
<Stavros> it's the last commit i made
<Stavros> err, name = commit message
<Stavros> can i remove just the commit but leave all my changes in my working copy?
<AfC> Stavros: for the _very last_ commit
<AfC> Stavros: you can simply use
<AfC> $ bzr uncommit
<AfC> Stavros: or strictly the last ð commits
<AfC> $ bzr uncommit -r -ð
<AfC> [I think]
<AfC> Stavros: if you uncommit then is goes back to everything showing changed when you do `bzr status`
<Stavros> AfC: that deleted my changes, though
<fullermd> Basically, uncommit does what the name suggests; it does the opposite of commit.  Shuffles you back to the previous rev, but leaves your WT alone; any pending edits, adds, mv's, etc, are still sitting there pending.
<Stavros> it didn't leave them in my working copy
<Stavros> i managed to shuffle things around
<Stavros> maybe i broke things, though
<AfC> Stavros: your working tree would only change if you did
<AfC> $ bzr revert
<AfC> after the uncommit
<Stavros> that won't revert to anything, since the uncommit already reverted
<fullermd> That seems unlikely.  It's never been meant to, doesn't in testing here, and I don't recall seeing a bug about it ever.
<Stavros> fullermd: about what?
<fullermd> uncommit making changes to the WT.
<Stavros> hmm
<Stavros> what does "bzr uncommit; bzr status" show?
<fullermd> Just what's expected; a big ole pile of changes.
<fullermd> (I make a throwaway branch of an existing project and uncommitted about a hundred revs.  Few minor things happened in that time...)
<Stavros> that's odd
<Stavros> hmm
<Stavros> well, thanks for your help, i'll pull and redo it
<fullermd> Certainly if it really IS touching the WT, that would be a bug.  It just seems an unlikely one.
<Stavros> nah, it's probably my fault, thanks
<fullermd> Oh, nice.  Annotate fakes up revnos that can't be used.
<jam> fullermd: but if you did 'bzr commit' they would work
<lifeless> jam: so; the json file is 6G :P
<jam> lifeless: probably a bit of duplication in there but yes
<jam> the json is usually ~= the size of memory
<jam> and ~ the same size when you load it back
<jam> a little smaller
<lifeless> so, is there anything that can give a half decent picture on this, without needing 6G or working set ? ;P
<fullermd> Sure, but that would defeat the purpose of _reviewing_ the merge   :p
<jam> fullermd: you always have uncommit
<jam> lifeless: unix tools tend to do a decent job with a bit of grep/sed fu
<lifeless> so, looking at the file
<lifeless> Am I wrong, or its not json? its a series of separate json elements... ?
<fullermd> Difficult tool to use at times.
<jam> lifeless: right, I think we technically should have a [ ] around everything
 * fullermd blinks.
<fullermd> info's "first revision" seems to be really eager to get back to null.
<jam> lifeless: I should also mention the 'strip_duplicates.py' script in py_memory_dump, which is a cheaper way to do "sort -u" or whatever to get duplicate lines removed
<jam> It just keeps a lightweight set object in memory of the object addresses, and doesn't keep the rest of the details
<jam> anyway... off to bed
<lifeless> gnight
<lifeless> jam: I'll chat with igc about fastimport on monday
<CameronP_> Hi All
<vila> lifeless: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13 captures many ideas I have about concurrency, among others, the idea that many places can be made concurrent (replace queues with iterators in that article) without adding complexity to the code
<vila> lifeless: you may need to read a bit before, but that page is the key one IMO
<CameronP_> Hi vila, thanks a lot for that help the other day, a lot of the problems seem to be because the upload plugin is for use against the current  devel version of bzr
<CameronP_> I was trying to use it agains stable
<CameronP_> Few bug reports have popped up over the last few days which were the problems I were having
<vila> CameronP_: sorry about that, indeed I made use of a recent addition in the API and I should address that before releasing 1.0
<vila> were you able to upgrade to a more recent bzr version ?
<vila> Can you remind me what os/version you're using ?
<vila> CameronP_: ^
<CameronP_> Sorry was afk
<CameronP_> At the moment Im using stable (1.17?) and centos 5
<CameronP_> what version would you recommend to upgrade to?
<vila> ha ok. Use 'bzr version' to check
<CameronP_> yeah 1.17
<vila> I don't have a general recommendation, it varies greatly depending on *your* constraints, like how easy it is for you to upgrade, can you run from sources, are you willing to run from sources (you'll need to install a bit more packages to be able to build the extensions, etc)
<vila> Also, are you blocked on that bug in bzr-upload ?
<CameronP_> well it still seems to work it just throws errors
<vila> Are you using the --auto feature ?
<CameronP_> and im trying to get a system set up for a whole lot of noob developers
<CameronP_> i had to turn that off
<CameronP_> does it work on the later versions?
<CameronP_> that may fix all of my problems
<CameronP_> i installed it from source last time
<CameronP_> for the stable
<vila> bzr-upload or bzr itself ?
<CameronP_> both
<vila> oh, then you can safely upgrade to bzr-1.18, read the topic of this channel :-D
<vila> 1.18 is really around the corner, days
<vila> not weeks
<vila> source code freeze was week[s] ago
<CameronP_> cool, that that should fix some of the issues with upload hey?
<vila> it should, it it doesn't please comment on the bug
<vila> you have windows users too right ?
<CameronP_> yeah...
<vila> there are installers ready for them too :)
<vila> https://launchpad.net/bzr/
<vila> in fact the only thing missing for 1.18 to be officially released is... announcing it I think :)
<CameronP_> heh cool, so should I uninstall 1.17 first, before upgrading?
<CameronP_> will  that affect my current repository?
<vila> CameronP_: uninstall: no idea, depends of your distro
<vila> CameronP_: affect the repo: surely not
<vila> CameronP_: The closer you come to 2.0 the easier it will be to use the 2a format, you can even start to use it now, but there are a few gotchas in the upgrade process in some cases
<vila> CameronP_: If you're happy with the size of your repos and the performance you get today, you may prefer to just wait
<CameronP_> yeah it will be fine for us now... performance seems pretty good and im not dealing with large projects..
<CameronP_> ok running 1.18 now...lets see how to goes ;)
<CameronP_> vila: everything works fine apart from --auto now vila
<CameronP_> ill just write some scripts so that they can call it manually
<vila> what is breaking with --auto ?
<CameronP_> it just returns text back to tortoise bzr (which then says its an error)
<CameronP_> but it just looks like the stdout ouptput
<CameronP_> of the auto doing its job
<vila> CameronP_: Have you tried setting upload_auto_quiet to True in one .conf file as indicated in the README ?
<CameronP_> NO, arg... i didnt know there was a README! sorry about that
<CameronP_> that iwll probably fix it
<vila> CameronP_: there is another critial bug about that README being hard to find :-)
<CameronP_> heh... i guess these are all good things to get sorted out as new users like myself start using it...
<vila> Have you read 'bzr upload --help' ? Or more broadly, what did you read ?
<CameronP_> yeah i saw the -q otpion there initally
<CameronP_> but couldnt work out how to set it in a conf file..
<CameronP_> well didnt know you could
<CameronP_> so stopped there
<CameronP_> if that makes sense
<vila> the option is new and came after *you* reported the problem :)
<CameronP_> lol..
<vila> yes, you make sense, great sense, thanks
<gimbal> hey folks; does anyone know a foss-project-hosting service that supports bzr? not seeing it listed for any of the open ones listed at http://stackoverflow.com/questions/10490/best-open-source-project-hosting-site
<vila> gimbal: launchpad.net ?
<gimbal> gimbal: really; i didn't know launchpad was available for non-bzr-central projects; cool
<gimbal> now does anyone know about a bzr plugin for doing sccm on the contents of hte (afaik) 'zip' compressed openoffice document files?
<gimbal> trying to find one; maybe it's a pipe dream.... would like to manage all the document-sccm through the project sccm system, along with the code for a project
<vila> gimbal: none that I know of, but several people expressed interest, it's doable
<gimbal> i see
<vila> I eman, it can be done by hooking at the right places, nobody found the time to start it yet
<gimbal> ja gern ^x^
<vila> but given openoffice python support, it's bound to occur :)
<gimbal> ahh, i see.... yeah making it integrate with ooo that could help i bet....
<gimbal> i mean, afaik, there's probably some sort of sccm-tooling system in ooo already
<gimbal> not as if I can jump on the coding for it, myself, but hey while it's up might as well draw on the whiteboard heheh
<gimbal> i just might stick with docbook, anyway
<gimbal> i mean, the only thing i don't like about it is editing project documentation in xemacs, but I can get over that ^-^
<gimbal> hey not to get political or anything, but my final question I guess ^-^ is about like so: Wasn't bzr based on Tom Lord's Arch originally?
<gimbal> I mean, in the thought of giving credit about it...
<CameronP_> vila: config works! running like a dream now
<CameronP_> auto working perfectly
<vila> CameronP_: great
<vila> gimbal: hmm, I think the history is a bit more complex than that, google could certainly hep you there
<gimbal> villa: well I wish it could; tried this search, it didn't come up with much: bzar "tom lord's arch"
<gimbal> er .. bzr; didn't typo in the search query phrase, there, either
<vila> gimbal: baz cames before bzr and after tla/arch (blurry there) search for that maybe
 * vila lunch
<gimbal> yeah, baz now I remember that command name
 * gimbal hopes Tom Lord is doing alright, today; gnuarch.org seems to be nonresponsive. maybe his work didn't get the full attention that was due
<gimbal> that said, I'd like to close my session here by mentioning: We can write all the nifty code we'd like to, but it doesn't write itself originally. If Tom Lord's work had anything to do with the evolution of bzr, I think it would be a fair thing for someone to describe, online, hopefully without getting political about - just honest\
<lvh> hi
<lvh> how many releases are to be expected more or less before 2.0 final?
<lvh> or is 2a just the new format, not related to the bzr format 2.x
<vila> lvh: 1.18 is due soon, then there will be 2.0 for which rc1 is already out and rc2 is also close
<lvh> Cool!
<vila> 1.18 is almost out, installers are ready, it also miss the official announcement
<vila> 2a becomes the default format with 2.0, but is available from 1.16
<vila> 1.16.1
<lvh> Seems like only last week 1.17 was released.
<lvh> Be right back :-)
 * fullermd can't help feeling that "1.18 due soon" takes on the quality of a poor joke.
<moldy> hi
<moldy> how do i tell bzr not to create those ~1~ files all over the place?
 * vila sadly agrees :-/
<vila> moldy: do you know what they are for ?
<moldy> vila: no idea, i only know that they are confusing setuptools, it ends up including them in SOURCES.txt
<vila> moldy: they are the backups created when you use 'bzr revert'
<moldy> vila: ah, thanks. aliasing bzr revert to bzr revert --no-backup :)
<vila> moldy: the only way to lose your changes ! :-)
<vila> moldy: you know that right ?
<vila> echo "super important modification worked on for weeks" >>some_file
<vila> bzr revert --no-backup
<vila> Errrrk, damn bzr ! You kill my job !
<moldy> i don't work on anything that long without committing :p
<vila> moldy: good, just wanting to make you know the risks
<vila> moldy: good, just wanting to make sure you know the risks
<vila> fullermd: what is the freebsd equivalent of: '/etc/init.d/network restart' ?
<vila> fullermd: rc.d/netif stop; netif start ?
<vila> rebooting just in case
<vila> >-/
<SamB_XP> jelmer: hmm, is it possible to use svn-import to import into a subtree of a shared repository?
<fullermd> vila: Not sure what that does...
<vila> fullermd: np, next question, how do you activate something in rc.conf (avahi is my target) ?
<fullermd> vi   :)
<fullermd> (emacs totally doesn't work.  OS has standards, y'know)
<vila> fullermd: no need for that, emacs is already installed :)
<vila> fullermd: lier :-P
<fullermd> You can glance at the script to see what the var basename is, but it's probably 'avahi'
<vila> err, what script ? And is there a magic rule to infer variable names in rc.conf ?
<fullermd> Hm, well, I see an avahi_daemon and avahi_dnsconfd on my system (not enabled); not sure which is what.
<fullermd> Usually the var name is similar to the script name (in /usr/local/etc/rc.d/).  Sometimes it's not, and you'd have to glance at the first few lines.
<fullermd> But the vars end up as ${BASENAME}_enable to flip it on and off.
<fullermd> So grep _enable /usr/local/etc/rc.d/WHATEVER will probably show it.
<fullermd> Then just set it to YES in rc.conf.
<vila> ha ! usr/local/etc ,of course, silly me
<fullermd> Actually, I think there's some arg...
<fullermd> Ah, rcvar.
<fullermd> % /usr/local/etc/rc.d/avahi-daemon rcvar
<fullermd> # avahi_daemon
<fullermd> avahi_daemon_enable=NO
<fullermd> So you could "/usr/local/etc/rc.d/avahi-daemon rcvar >> rc.conf" and edit from there.
<fullermd> Until you mess up one time and > instead of >>'ing, anyway.
<fullermd> (but hey, that's why rc.conf is in a bzr branch  ;)
<vila> err, wait, you mean I should add the whole avahi-daemon file to /etc/rc.conf ?
<fullermd> No, juset that var.
<vila> ha, ok, done
<fullermd> (rc.conf being just a shell script that's sourced to set them, though of course being a script you COULD do all sorts of really bad evil stuff in it)
<vila> fullermd: what do you use to restart the network modules ?
<vila> source by who when ?
<fullermd> Sourced by rc scripts when they run.
<fullermd> "the network modules" doesn't really mean anything, I don't think...
<vila> ok at boot time then.
<fullermd> Or whenever you run them.
<vila> hmm, what if... you plug a network card say
<vila> no...
<fullermd> If you `/usr/local/etc/rc.d/avahi-daemon start` it sources rc.conf to figure what to do.
<fullermd> (and does nothing if _enable isn't YES'd)
<vila> and how do I know that usr/local/etc/rc.d/xxx is taken into account ? All are tried and act depending on the _enable vars ?
<fullermd> devd should notice interfaces being plugged in (USB, say) and config them as rc.conf says.  I dunno if there's some way to 'restart' them based on rc.conf changes; I always just re-ifconfig manually.
<vila> ifconfig down; ifconfig up ?
<fullermd> Right.  Every rc.d scripts in the various dirs checked is run during boot; only those _enable'd (or those antisocial or special that don't check an _enable) do anything.
<vila> ok, good,
<fullermd> `ifconfig $INT inet 1.2.3.4/5 alias` or whatever I'm doing.
<fullermd> (that way I can do it BEFORE I encode it in the script, so if it turns out to be a horrible mistake, I can reboot and it'll be gone ;)
<fullermd> I mean, not that I ever make horrible mistakes.  But some less perfect people do, so I hear.
<vila> yeah, I always do all kind of horrible mistakes :)
<vila> That's why I so love virtual machines :)
<fullermd> rc(8) described the standard args to rc.d scripts.  Basically start, stop, and restart are the main ones you touch.  rcvar as above gives you hints about the enable var name.
<fullermd> force{start,stop} ignore _enable and always {start,stop}.
<vila> the bad news in my case is that freebsd is not that well supported by virtualbox, so I can't run X (summarized to the caricature)
<fullermd> Some scripts add other args.  The pgsql script has an 'initdb' arg to init the database, for instance.
<vila> ok, usual boilerplate then s/init.d/rc.d/ and a lot of knowledge can be reused, thanks for the hint (again, but saying s now, just in case :)
<vila> s/s now/so now/
<fullermd> No prob  :)
<fullermd> And {en,dis}abled by vars in a conf file, rather than being symlinked off into some other dir with magical names.
<vila> ha ha ! I can ping freebsd.local !
<vila> fullermd: yeah, but how do you address the ordering ?
<vila> oh, let me guess, PROVIDE and REQUIRE ?
 * fullermd nods.
<vila> hmm, closer to launchd on OSX then
<fullermd> `/sbin/rcorder /etc/rc.d/* /usr/local/etc/rc.d/*`
<vila> I can run that ? Just display things ?
<fullermd> Builds up the graph.
<fullermd> Yah, that just prints the list.  rc does that and then iterates it.
<vila> whoohoo, save me hours !
<fullermd> There are advantages to an OS developed by people who overthink everything  ;)
<vila> Is there a way to configure the console with more than 25x80 ?
<fullermd> Yah, there are some VESA modes available.  Lemme see if I can remember how to get at 'em...
<vila> It's kind of funny, for years I searched to minimize the time spent on administering my systems, yet, I keep learning along the way... and suddenly it pays off :)
<vila> well, that and you understanding the questions and giving the right answers :)
<fullermd> 'k, the rc.conf(8) manpage lists [most of] the base system config vars.
<fullermd> allscreens_flags set options to run vidcontrol(1) with.
<fullermd> And vidcontrol(1) has modesetting.  I haven't messed with it in probably 10 years, but the manpage and my memory say that `vidcontrol $MODE` is all you need.  It lists the choices of modes in the manpage.
<fullermd> Are you running i386 or amd64?  I thought I remembered hearing that VESA and amd64 don't get along, but I'm not sure.
<vila> amd64 I think, let me check
<vila> yeah, I started with: 7.2-RELEASE-amd64-dvd1.iso
<fullermd> Well, if it doesn't work, it'll yell at you; would be surprised if it tried and screwed something up.
<fullermd> Hm, I seem to only have 80x25 on my amd64 system...
<vila> operation not supported by device
<fullermd> (`vidcontrol -i mode` lists 'em; my i386 has thirty-some)
<vila> same here, 80x35 only
<vila> I can live with that, the aim is to configure a slave for the test botnet
<fullermd> Yeah, I think it's something about VESA modeswitching requiring hooks into vm86 pseudo-real mode, and you can't do that when you're in long (amd64) mode.
<fullermd> Just get it well enough to boot, then ssh in from nice big xterms   ;)
<vila> so, how do I authorize root to log via ssh ?
<vila> I got PAM auth error
<vila> forget it, will install sudo
<fullermd> Yah.  You can enable it in the sshd config, but su/sudo is Better(tm) anyway.
<vila> find . -name sudo -print
<vila> oops, wrong window :)
<fullermd> I've long forgotten the root passwords to half the boxes I run (and I was the only one who ever knew most of 'em), thanks to sudo   ;)
<fullermd> ports/security/sudo
<fullermd> Note that if you have portupgrade installed, its `portinstall` command can do the searching for you, and a guess at the name is usually right enough.
<fullermd> (e.g., `portinstall sudo`)
<vila> ooooh 9-)
<fullermd> But that means letting it install one of those weird niche languages, portupgrade being written by wackos...  ;)
<vila> I was doing like instructed: cd <package> ; make all install clean :)
<fullermd> Yah, 's what portinstall does.  But saves you a touch of typing.
<vila> I was already instructed to install it anyway :)
<fullermd> Ooh, I didn't know my instructions were followed so closely.
<fullermd> Now you will dance for me!
<vila> Wow, sudoers (in /usr/local, got it ;-) is read only !
<vila> hehe, wanna see my notes ? :-)
<fullermd> Sure, you're supposed to use visudo on it   ;)
<vila> ooooh
<fullermd> (just like you use vipw instead of vi /etc/master.pa<TAB>)
<vila> One day I will learn vi :)
<vila> emassu<TAB> rats :)
<fullermd> vi$WHATEVER should obey $VISUAL/$EDITOR
<fullermd> (an advantage of visudo is that it does syntax checks when you exit so you get less chances for foot-shooting)
<vila> mah, I didn't set that (mixing my gentoo attempt :-/)
<LarstiQ> set it to cat!
 * fullermd quickly checks to make sure AfC isn't around...
<vila> I'll retry later with gentoo anyway
<fullermd> Anyway, I need to get going; gotta go help some friends of mine lay a patio before it starts raining.
<vila> unless Afc can point me to a virtualbox image ready to be reused, but I doubt that match gentoo philosphy
<vila> fullermd: sure, enjoy your week-end, your help was invaluable (which is why I can't pay you :-)
<fullermd> I think there's a ##freebsd here on freenode that may help if you have other troubles.  I've never been in it, so I dunno how helpful it is.
 * fullermd has his uses   8-}
<vila> fullermd: but a beer anytime we meet !
<vila> fullermd: or even champagne if it's near my home :)
<fullermd> (BTW, did you read my infamous BSD/Linux rant?  It may help you over philosophical humps; that's what I was really aiming at in writing it)
<vila> not sure, not recently at least, sounds like the perfect moment to read it though...
<vila> http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php ?
<fullermd> Yah.  Just follow the trail of smoke from the flamefests it ignited.
<vila> google rules...
<fullermd> I really should update it, along with the rest of my site.  But most of it is on mindset, so it doesn't really change much.  Just calls for tweaking and clarifying here and there.
<fullermd> (I wrote it as a draft, sent it to some people I knew for reviews and opinions.  2 days later, I woke up to my DSL line smoking and a link from slashdot...   fun times)
<fullermd> One of the posts about it said something like "Wow, this guy is an arrogant, condescending asshole."  I didn't know I came through so well in writing   ;)
 * fullermd waves and scampers off.
<vila> heh, reading
<SamB_XP> huh ... I would have expected "bzr pull -r 10000" to pull in revision 9998, if that was the last one ...
<SamB_XP> but it didn't!
<vila> Now you knwo
<vila> Now you know (I HATE ruining joke typos)
<SamB_XP> well, I really think it ought to do that *and* tell you that there actually isn't a revision 10000
<vila> file a bug when your expectations are fresh in your mind
<vila> \but the short answer is that if you want the latest you just 'bzr pull'
<vila> if you want to *know* the latest 'bzr revno'
<vila> revnos have a defined semantic in a branch,  some persistence across related branches for old revnos, but at the base it's a branch-centric concept, throwing revnos in the wild doesn't really make sense
<SamB_XP> vila: I was just pulling in spurts of 1000 or so so I wouldn't lose everything if my machine rebooted mid-pull
<vila> SamB_XP: I'm pretty sure pull itself is resumable these days
<SamB_XP> hmm, and possibly launchpad should have some kind of fallback for the series display ...
<SamB_XP> ... the canvas element doesn't work too good in Links ;-P
<LarstiQ> vila: resource consumption would be my reason to pull per 1000
<SamB_XP> yeah, that's the other thing
<SamB_XP> that also seems to correlate somehow with my random reboots
<vila> LarstiQ: same answer, we shouldn't consume more or that's a bug
<vila> urgh, we really shouldn't cause reboots !
<SamB_XP> it's not bzr's fault
<vila> I hope it's not tha case
<vila> pfew
<SamB_XP> just about anything can do it for me
<SamB_XP> it was just a contributing factor
<vila> Is your nick an indication of the OS you use ?
<SamB_XP> the one I'm IRCing from, yes
<SamB_XP> but I'm using bzr on my other one
<LarstiQ> what is a "SamB" OS?
<SamB_XP> LarstiQ: XP is the OS ;-P
<SamB_XP> SamB runs Debian
<vila> Simple And Mostly Booting ?
<mneptok> Swap Ate My Battery
<chrispitzer> so I have a repo with a dozen or so revisions in it.  I want to pull a given past revision out into a different directory... how do I do this?
#bzr 2009-09-06
<Noldorin_> lifeless: hello?
<Adys> bzr: ERROR: Unable to connect to target of bound branch BzrBranch6('sftp://sigrie/~/projects/sigrie/') => file:///home/sigrie/projects/sigrie/: Not a branch: "/home/sigrie/projects/sigrie/".
<Adys> /home/sigrie/projects/sigrie: Tree is up to date at revision 766.
<Adys> Any idea what's wrong? I moved that folder recently
<bsdemon> Hi, is there any tutorial on bzrlib?
<bsdemon> I want to build simple wiki app on top of bzr repository
<jml> bsdemon, no tutorial, per se.
<jml> bsdemon, it's probably best to learn by browsing the code at bzrlib/builtins.py
<bsdemon> jml, ok, thanks
<bsdemon> I just want to manipulate bzr branch like adding, commiting, viewing diffs
<bsdemon> but api seems to be complex
<jml> bsdemon, it's actually pretty good, as big apis go
<bsdemon> are there facades, that simplifies apis?
<bsdemon> I said complex, not bad :)
<jml> bsdemon, I guess I should have said "its complexity matches the problem domain, for the most part"
<jml> bsdemon, ummm, not really.
<jml> bsdemon, I mean, apart from the command line :)
<bsdemon> :) ok, will tru to dive in sourcecode
<bsdemon> Can I create in memory branch from another branch?
<lifeless> yes, if you branch onto a MemoryTransport
<lifeless> however, thats probably not what you want to do
<lifeless> I think you want to make a new commit ?
<bsdemon> yes
<lifeless> the core api here is Branch.get_commit_builder
<lifeless> if you wish to operate totally from memory, you will want to look at MemoryTree
<bsdemon> thanks
<lifeless> if you want to operate from disk (and I advise that, as most page hits will beon the current content)
<lifeless> then you should look at WorkingTree
<lifeless> specifically: tree = bzrlib.workingtree.WorkingTree.open('path')
<lifeless> tree.commit('new commit')
<lifeless> you may wish to use both of these, MemoryTree for edits, WorkingTree for serving page loads.
<lifeless> I dunno :)
<bsdemon> thanks, that is all i was thinking about
<bsdemon> i want to implement some comet-powered interface for wiki edits like ethrepad does
<Adys> http://pastebin.com/d3a63720a
<Adys> Was this ever fixed? I'm running 1.13 and cant upgrade on that server
<Adys> its something to do with symlinks i think
<vila> Adys: yes it has been fixed in later versions
<vila> Adys: It's not related to symlinks as far as I recalled, but I'm surprised it was in a released version, what os are you using ? What does 'bzr version' says ?
<Adys> gentoo
<Adys> 1.13
<Adys> 1.13.2 sorry
<vila> hmm, someone said gentoo already ships 2.0rc1 :-/
<Adys> O_o
<Adys> ill ask my sysadmin again, a week ago that was still the latest version
<vila> I'm not a gentoo expert but isn't there overlays that can provide more recent versions ?
<Adys> possibly
<Adys> thanks
<vila> Adys: what does 'bzr info' says in that branch >
<vila> Adys: what does 'bzr info' says in that branch ?
<Adys> I fixed the branch
<Adys> recreated it
<vila> o_O
<Adys> deleted it, pushed again remotely
<Adys> new bzr init*
<Adys> Standalone tree (format: pack-0.92)
<vila> ha, I think you had a checkout before and a branch now, the bug was with checkouts as I recall
<Adys> That's quite possible, yeah
<vila> so worked around the bug, but you should be ok now
<Adys> Yep
<Adys> Im getting bzr upgraded to 1.18 right now anyway
<vila> good
<vila> err, but how do you do that ?
<vila> you just said you couldn't upgrade no ?
<Adys> no idea I'm not the one in charge :)
<Adys> Well a week ago i couldnt
<Adys> gonna see if I can update anything now
<ramvi_> I get bzr: ERROR: Not a branch: /home/ramviroot/source/wubi/lp:wubi/ when trying to do bzr branch lp:wubi
<ramvi_> I'm on a debian machine
<ramvi_> what do I do?
<LarstiQ> ramvi_: ensure you have the launchpad plugin
<ramvi_> LarstiQ I don't know how to get it in debian etch. In ubuntu it's installed automatically
<LarstiQ> ramvi_: which is included in the bzr release, so either you ran with --no-plugins or someone removed it
<ramvi_> right.. I didn't run with no-plugins
<LarstiQ> ramvi_: what does `bzr plugins` say?
<ramvi_> azaar (bzr) 0.11.0
<LarstiQ> that is a very ancient bzr
<ramvi_> It's the one on my servers repos
<ramvi_>  /usr/lib/python2.4/site-packages/bzrlib/plugins/launchpad
<LarstiQ> ramvi_: I don't know if there are backports for etch
<LarstiQ> ramvi_: you do know etch is old-stable?
<ramvi_> yeah, no - I don't know a lot about debian
<ramvi_> it says I have the launchpad plugin
<LarstiQ> ramvi_: the current stable Debian release is lenny, etch is no longer supported by Debian (but you could see if backports.org is of any help)
<LarstiQ> ramvi_: ok, any info in ~/.bzr.log then?
<ramvi_> I think the plugin failes
<ramvi_> Traceback (most recent call last):
<ramvi_>   File "/usr/lib/python2.4/site-packages/bzrlib/commands.py", line 611, in run_bzr_catch_errors
<LarstiQ> ramvi_: could you use a pastebin to show the entire traceback?
<ramvi_> LarstiQ: http://pastebin.com/d1af972b2
<LarstiQ> ramvi_: hmm. I can only interpret that as the launchpad plugin no supporting lp: in 0.11 yet
<LarstiQ> ramvi_: you really should try getting a newer bzr
<ramvi_> LarstiQ: Done. it's working
<ramvi_> Thanks for your time LarstiQ
<Lo-lan-do> LarstiQ: Etch *is* supported by Debian.
<Lo-lan-do> At least until 2010-02-14 or Squeeze releases, whichever comes first.
<LarstiQ> Lo-lan-do: ah hm, maybe I let my own need-to-upgrade-old-etch server bleed into that too much :)
<Noldorin> hello
<Noldorin> could someone please point me to the download for the smart server?
<Noldorin> can't seem to fgind it anywhere
<SamB> Noldorin: it's actually included in bzr, afaik
<SamB> check the manual
<vila> Noldorin: it's part of bzr itself, nothing more to download
<SamB> ... and the easiest way to use it is probably via SSH
<Noldorin> i had it on my server at one point, but managed to delete it :P
<Noldorin> i see
<Noldorin> SamB: can't seem to find the bzr_smart_server file though
<SamB> Noldorin: file?
<Noldorin> bzr_smart_server.py
<Noldorin> i mean
<SamB> why would there be a file called that?
<Noldorin> not sure, but that's what i had on my server before
<Noldorin> it's where the URL rewriting module redirects /.bzr/smart to
<Noldorin> the CGI gateway i believe
<Noldorin> vila: any ideas?
<vila> the name doesn't ring any bell, I suspect you created it locally...
<SamB> the manual mentions "bzr-smart.fcgi"
<Noldorin> problem was, a friend set this up for me, and i wasn't sure precisely what he did
<Noldorin> right
<Noldorin> well my server doesn't have fcgi, only cg
<Noldorin> cgi*
<SamB> Noldorin: what server is that?
<SamB> anyway ... http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi somehow seems the relevant piece of documentation even if you *aren't* using fastcgi?
<Noldorin> it's a shared server provided by storminternet
<SamB> hmm, oh, wait
<Noldorin> cheers. i'll take a look
<SamB> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#running-a-smart-server is probably better ;-)
<Noldorin> it's windows/iis6 btw
<Noldorin> right
<Noldorin> i saw that already
<Noldorin> doesn't seem to instruct how to set it up
<SamB> hmm.
<Noldorin> SamB: the file contains a class named WSGIServer, in case that helps
<SamB> http://bazaar-vcs.org/ServerGuide/IIS maybe ?
<Noldorin> SamB: that would *seem* to be what i want/..
<Noldorin> though it doesn't mention a .py file
<Noldorin> i'll take a look later. got to be off now
<Noldorin> thanks :)
<Noldorin> bye
<jelmer> SamB: you can import a subtree with svn-import, just specify the subtree's URL
<SamB> jelmer: actually, I just wanted to import *to* a subtree of a shared bzr repository...
<jelmer> SamB: that would only work for by-reference nested trees
<jelmer> SamB: and those don't work yet..
<SamB> jelmer: I'm not talking about nesting of working trees or anything
<SamB> just importing the branches into a subdirectory of the shared repository ...
<SamB> ... so I can keep them straight from non-svn-imported branches
<lifeless> moin moin
<lifeless> jelmer: hi
<lifeless> jelmer: /win 55
<lifeless> WTB a reviewer
<mwhudson> lifeless: good luck with that at this time of day, i guess
<lifeless> mwhudson: oh look, a python coder.
<lifeless> mwhudson: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279
<lifeless> mwhudson: its a) small b) small and c) small
 * mwhudson waits for */5
<lifeless> mwhudson: it has diff now
<mwhudson> lifeless: but now i'm on the phone i'm afraid
<lifeless> meh, its just your boss
<lifeless> :)
<lifeless> mwhudson: so if you can have a look when your call ends, that would be great
<mwhudson> ok
<wgrant> mwhudson: Ah, the BMP diff generator is only */5? That explains a bit.
<Necoro> hey - I'm currently trying the "bzr switch" approach, i.e. having one central reposority and a lightweight checkout where one can switch between the branches
<Necoro> but one thing is missing: listing which branches exist in the repository ...
<Necoro> has anyone an idea how to achieve this?
<lifeless> bzr branches ..
<Necoro> ".." won't work ;) (different locations)
<lifeless> well, $path :P
<Necoro> but probably (as long as I only have one project using the shared repo), an alias could do it
<lifeless> mwhudson: I have my repo at ..
<lifeless> with the working tree under it
<lifeless> mwhudson: typo
<Necoro> (hmm - and bzr branches takes quite some time :| ... well better than nothing)
<lifeless> Necoro: do the repo branches have trees? or is it on the network ?
<Necoro> lifeless: currently they have trees
<lifeless> that will make branches slower
<Necoro> ah ok
<lifeless> it has to read all the directories
<poolie> hello all
<lifeless> poolie: hi
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279
<lifeless> ^- I can haz review please poolie
<Necoro> btw: is there a difference (in functionality) between bzr-pipelines and bzr-looms -- or is the former one just a re-implementation of the latter?
<lifeless> spiv: https://code.edge.launchpad.net/~spiv/bzr/insert-stream-check-chk-root - you need to update the branch on lp I think
<lifeless> Necoro: looms can version the precise state of the set of branches
<poolie> hi lifeless
<lifeless> Necoro: pipelines cannot
<lifeless> Necoro: not everyone needs that feature; looms are somewhat less polished I think. I wish I had a week to clean up looms.
<lifeless> afk for a little
#bzr 2010-09-06
<poolie> hi all
<spiv> Good morning.
<Jerub> morning.
<Jerub> ah, found the button to upgrade the branch on lp
<poolie> hi spiv
<bialix> hi all
<bialix> vbonjour vila
<vila> bialix: hey !
<bialix> no, I mean just bonjour
<vila> oh, too bad, I thought it was a special bonjour just for me ;-)
<bialix> vila: do you by any chance know does 2.2.1 will be released this week as https://launchpad.net/bzr/+milestone/2.2.1 page says?
<bialix> I need to prepare new qbzr release then
<vila> bialix: not that I know of :-/
<bialix> ok, will try to catch poolie tomorrow
<vila> bialix: or jam, AIUI he is the 2.2 RM (but IMBW, this occurred during my vacations and I may have missed something)
<spiv> Good evening bialix, vila
<spiv> bialix: poolie probably won't be around tomorrow, it's igc's funeral :(
<vila> spiv: good evening
<vila> spiv: can you confirm who is the RM for 2.2 ?
<spiv> vila: not sure off the top of my head!
<vila> :-/
<spiv> I'd have to search my email...
<spiv> We should put it in the /topic
<lifeless> jam
<vila> spiv: indeed
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: jam bzr 2.2.0 is out
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: jam | bzr 2.2.0 is out
<lifeless> IIRC, I'm moderately sure
<bialix> you again have killed Kenny :-(
<vila> bialix: Is that your poney ?
<bialix> spiv: evening
<bialix> spiv: I see
<bialix> vila: win32 compatibility: https://bugs.launchpad.net/bzr/+bug/631350
<ubot5> Launchpad bug 631350 in Bazaar "bzr 2.2 @ win32: print non-ascii characters to console made in user_encoding() instead of terminal_encoding() (affected: 1, heat: 6)" [Critical,Confirmed]
<bialix> I'm very very very unhappy
<bialix> have to fix it now
<spiv> bialix: :(
<vila> bialix: and no report prior to yours ? Had nobody tested 2.2 on windows with any beta ?
<bialix> with non-ascii characters?
<vila> bialix: or all they all US... yeah
<bialix> I'm reading almost all bug reports now, I don't remember any
<spiv> Right :/
<bialix> I suspect this bug caused by poolie's refactoring of ui
<vila> bialix: one more reason to make windows tests run on babune (it uses a french localized xp and should catch such regressions if there are the right tests for them)
<bialix> will try to look at the reasons tonight
<vila> bialix: thanks
<bialix> it's incredibly hard to write proper test for such things
<vila> bialix: then we have to fix it, this shouldn't be hard (not implying it's easy today)
<bialix> because it depends on difference between user_encoding() and terminal_encoding() and not all characters could be shown in french locale vs russian locale, and...
<vila> bialix: but your report doesn't mention a crash right ? So it's a ui thing and should be (hopefully) shallow
<bialix> it's not a crash, but this is very irritating
<bialix> and this is definitely regression
<vila> +1
 * bialix just installed 2.2 final this morning
<vila> the weird thing is (without knowing the actual cause) that we are aware of the trap, so it's weird we don't have at least one tests tripping up...
<bialix> I understand what you mean
<vila> hehe, 'one tests', cute freudian slip :)
<bialix> yep :-)
<bialix> vila: I'm sure we have non-ascii black box tests, but they don't check the exact output, because of encodings differences between machines
<bialix> it should be possible to change, it's just not very trivial and very time consuming
<vila> "not very trivial and very time consuming" that's the bug
<bialix> but I might try to change this, cause I don't like when Kenny has been killed
<bialix> I have no time to work on this right now, but I will catch you in next few days vila and ask you for your mind about specific tests
<vila> bialix: ack
 * bialix bbl
<poolie> hi vila
<vila> hey poolie, sry was otp
<poolie> np
<poolie> just saying hi, how are you?
<vila> fine, I've tweaked babune a bit this week-end so that some failed runs are restarted automatically, even less work there ;)
<vila> and I should soon propose to some of us to run a subset of the test suite on all platforms for a given branch
<vila> I can use it right now, I just have to find how to propose it to others
<poolie> hm, i seem to have a clone
<poolie> vila, one of us should do the announcement
<vila> poolie: I haven't closely followed the various installers builds, checking lp
<poolie> i think we're all up to date
<poolie> we should check
<poolie> i got sidetracked by working out why the web site wasn't updating
<poolie> now i'm up in brisbane
<poolie> at ianb's house
<GaryvdM> Hi poolie, vila.
<GaryvdM> poolie, vila: The following installers are done: Windows, Mac, and Ubuntu ppas.
<vila> poolie: should the Release notes text be used as is for the announcement, it sounds fine as is
<vila> poolie: at https://edge.launchpad.net/bzr/+milestone/2.2.0
<poolie> good with me
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: jam | bzr 2.2.0 has been officially released
<vila> poolie: mail sent and announcement done on lp
<vila> poolie: wikipedia already up-to-date...
<poolie> thanks!
<poolie> vila, see my pm?
* 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: poolie | Release Manager: jam | bzr 2.2.0 has been officially released
<HollyRain> hi! in .bzrignore file, can be used comment lines? #
<HollyRain> comments in lines (which start with character #)
<Odd_Bloke> I have a repository which I just removed a lot of branches from.
<Odd_Bloke> Is there any way I can remove the now unreferenced revisions from it?
<Odd_Bloke> s/repository/shared repository/
<maxb> Only by branching each branch you want to keep into a new empty shared repository, AFAIK
<MichealH> Hello?
<MichealH> Can someone tell me how to login to Launchpad via #bzr
<MichealH> *bzr
<MichealH> Anyone?
<maxb> What do you mean? Set your launchpad username to allow bzr+ssh access to branches?
<maxb> If so, 'bzr launchpad-login your-lp-id'
<MichealH> Okay
<MichealH> I need a ssh key?
<maxb> for that, yes
<MichealH> How do I make one?
* lindbohm.freenode.net changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.2.0 is out
<HollyRain> hi! in .bzrignore file, can be used comment lines?
<HollyRain> comments in lines (which start with character #)
<bialix> HollyRain: yes, o'course
<HollyRain> bialix:  ok, I'd been looking for it in doc. but I din't find nothing
<bialix> lemme check
<HollyRain> at least here, no
<bialix> HollyRain: yes, I think you're right.  I can't find this either. Can you file a bug report, please?
<HollyRain> http://doc.bazaar.canonical.com/bzr-0.9/tutorial.html
<HollyRain> I'll file the bug report
<bialix> thank you
<HollyRain> np
<maxb> HollyRain: You know that's a very very old version of that document?
<bialix> maxb: http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/ignore-help.html there is nothing about comments; http://doc.bazaar.canonical.com/bzr.2.2/en/user-reference/patterns-help.html there is nothing as well
<maxb> Sure, I just didn't want HollyRain relying on potentially other out of date info
 * bialix nods
<HollyRain> This was looking at http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/index.html but nothing
<HollyRain> anyway the bug has been reported
* 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: poolie| Release Manager: jam | bzr 2.2.0 is officially out
<bialix> vila: thanks
<mgz> <vila> the weird thing is (without knowing the actual cause) that we are aware of the trap, so it's weird we don't have at least one tests tripping up...
<mgz> it has been rather hard to write proper tests ticking this kind of thing as they tended to make the whole test suite fall over if they failed
<vila> mgz: I don't get it. If you write a single test to reproduce the problem, there is no reason for it to... ohhhhh
<vila> mgz: but with all your fixes, that should a thing of the past !
<mgz> yup, there's now no reason not to.
<vila> mgz: right, at least that's a reasonable explanation (bialix ? Saw that ?)
<bialix> wwwhat?
<vila> bialix: mgz more or less said that unicode-related failing tests had the tendency to break the whole test suite. That may be why we don't have enough of them to catch the problem you reported earlier
<bialix> you guys read the mind of each other, I forgot my mind reader at home
<bialix> vila: hmm, I don't think so
<bialix> or maybe mgz means testtools quirks?
<vila> bialix: mgz fixed a couple/bunch of issues regarding tests where the *log* contained unicode, yeah, testtools, subunit, pyjunitxml
<bialix> yep, it bit me couple of times. glad it's  fixed now
<bialix> but the problem with unicode output is not new, it was there long before testtools and other zoo
<mgz> yeah, there have been a bunch of issues, and I may still have to hunt a few more down.
<mgz> but I have my trusty bug spear!
<vila> bialix: you said it's a regression, that sounds like something not covered by a test. And there may be a good reason for that
<bialix> the reason is in the fact that different windows machines have different oem codepage, so we have to create expected result non-ascii string. it could be a bit boring
<mgz> we can fake that a little too though, alexander, run_bzr takes an encoding parameter for the streams, so we could make a test that fails on nix as well.
<bialix> actually it's a stab in the dark right now. I think at least status should check exact string. unless we force utf-8 in the tests :-/
<mgz> (ie, the output should be in the stream encoding, not utf-8 as the user encoding will still be)
<bialix> mgz: the crucial point is to have get_user_encoding() and get_terminal_encoding() return different values
<mgz> but that might not be needed to make a test that will fail if the wrong one is used, was my point. anyway, I'll have a look at the bug in more detail.
<vila> bialix: we know how to force get_user_encoding() and get_terminal_encoding() for a given test
<bialix> mgz: I'm not quite understand your point, honestly. that bug is all about using wrong encoding (ansi instead of oem)
<bialix> vila: yes
<bialix> we have private hook points in osutils to do so
<vila> yup, so we should be able to reproduce your bug
<bialix> I can reproduce it even without this (joking joking)
<mgz> ...I'm not having any luck on that front at the moment...
<vila> lol
<mgz> I've got a cp437 terminal on a cp932 system, and bzr 2.2 r5082
<vila> mgz: use astral chars ?
 * vila wonders what astral chars are....
<vila> klingon ?
<mgz> ehe, they're ones that get encoded as \uXXXX\uXXXX in utf-16 :)
<maxb> surrogate?
<mgz> yup, with surrogates.
<bialix> cp932??? http://msdn.microsoft.com/ru-ru/goglobal/cc305152(en-us).aspx
<bialix> japanese?
<GaryvdM> mgz: Any chance I can put uncode in the log, and have it printed as uncode, and not as a \uXXXX string?
 * bialix waves hello on GaryvdM
<jelmer> GaryvdM: please tell me more about this new "uncode" character set :-P
<mgz> bialix, yup, that's what my system uses... I'll try a russian terminal codepage and c/p your example
 * jelmer also waves
<GaryvdM> mgz: The reason is, for my qlog tests, I can print a much more informative picture if I can use unicode.
<GaryvdM> Hi bialix
<bialix> cp866 is russian oem,
<GaryvdM> :-P -> jelmer
<bialix> mgz: try any accented character
<mgz> garyvdm: should Just Work now
<mgz> but you'll want new versions of several things possibly.
 * GaryvdM installs the latest testtools
<mgz> ...bialix, why is bzr init 5 in your example creating a 1.9 format tree? I get a 2a one with 2.2
<bialix> mgz: because I have special plugin to enforce this
<mgz> okay.
<bialix> try look for format1 plugin in ml year or so ago
<mgz> so, no luck: http://pastebin.ubuntu.com/489284/
<mgz> there must be some other factor involved than just the osutils functions
<bialix> mgz: https://bugs.launchpad.net/bzr/+bug/631350/comments/3
<ubot5> Launchpad bug 631350 in Bazaar "bzr 2.2 @ win32: print non-ascii characters to console made in user_encoding() instead of terminal_encoding() (affected: 1, heat: 6)" [Critical,Confirmed]
<GaryvdM> mgz: Sweet - it works: http://pastebin.ubuntu.com/489285/
 * bialix pulls latest changes from lp:bzr/2.2
<bialix> GaryvdM: I suspect we need to rebuild 2.2 installere
<mgz> one note of caution gary: you need to be actually using unicode objects not utf-8 strs if you want it to work elsewhere, and still may print funny on terminals of limited ability
<GaryvdM> bialix: Do we need to do that before 2.2.1?
<mgz> ah, good idea bialix, I'll grab the 2.2 installer and try that
<bialix> GaryvdM: it depends on the date of 2.2.1
<GaryvdM> mgz: Yes - my next question is how can I detect If I can safely use unicode, or if I should rather output ascii?
<mgz> check the terminal encoding! :)
<GaryvdM> bialix: What reason for 2.2.0-2 ?
<bialix> mgz: ha! 2.2 branch is not broken!
<mgz> we're trying to track down an encoding bug gary
<GaryvdM> mgz: How can I check for testtools support?
<bialix> mgz: http://pastebin.ubuntu.com/489290/
<mgz> __version__ greater than 0.9.5, but I think we'll want to be enforcing that soon anyway
<bialix> GaryvdM: waut, why you said 2.2.0-2?
<bialix> GaryvdM: wait, why you said 2.2.0-2?
<mgz> +or equal to
<bialix> GaryvdM: https://launchpad.net/bzr/2.2/2.2.0 has only 2.2.0 without -1 or -0
<bialix> what I'm missing? *blinks*
<GaryvdM> bialix: I just meant a new ver of the 2.2.0 installer.
<vila> bialix: x.y.z-n 'n' if for installers if something goes wrong but doesn't require a change in x.y.z
<bialix> GaryvdM: what's new docs bug
<GaryvdM> ok
<bialix> GaryvdM: https://bugs.launchpad.net/bzr-windows-installers/+bug/631470
<ubot5> Launchpad bug 631470 in Bazaar Windows Installers "Core Documentation in bzr 2.2.0 setup.exe has warning (affected: 1, heat: 6)" [High,Confirmed]
<GaryvdM> ok
<bialix> and I'm not sure yet what's wrong with encodings
<mgz> oaky, yup, the installer is borked
<mgz> C:\Program Files\Bazaar2.2>bzr.exe mkdir b:\alex2\Ð¢ÐµÑÑ
<mgz> added b:\alex2\'?aa
<bialix> finally
<mgz> I'll pdb in an poke around, see if I can work out what's up.
<mgz> user and terminal encoding are right...
<bialix> using pdb on bzr.exe is...
<bialix> can't find the word
<bialix> a bit maso
<mgz> :)
<vila> bialix: you're talking to mgz you know...
 * bialix have to go now, hopefully bbl tonight
<bialix> vila: err?
<vila> bialix: joke :)
<bialix> I suspect that
<mgz> se you later bialix, I'll see if I can make some progress on this.
<bialix> I know mgz is fearless
<mgz> okay, this is kinda funky.
<mgz> the bazaar ui object contains a codecs wrapper, contains stdout
<mgz> the codecs wrapper and stdout both have the encoding cp866 set
<mgz> and the wrapper correctly encodes the unicode russian to a cp866 bytestring, and writes it to the python file
<mgz> ...which somehow is coming out mangled as-if it's being decoded as... something random latin-ish then encoded as mbcs or similar
<mgz> sys.version is 2.6.4 ... can we build an installer with something else?
<mgz> ...not that I can find any likely upstream bug
<GaryvdM> mgz: The 2.1 installers have python 2.5 - I don't know if that help?
<mgz> I'll try one, pretty sure this isn't related to bzrlib code changes
<mgz> py2exe seems most likely, to be honest
<mgz> (Pdb) ctypes.cdll.msvcrt.printf("\x92\xa5\xe1\xe2")
<mgz> Ð¢ÐµÑÑ4
<mgz> (Pdb) os.write(sys.stdout.fileno(), "\x92\xa5\xe1\xe2")
<mgz> '?aa4
<mgz> so, certainly a build problem, printing through msvcr90.dll is borked, and worked through msvcrt.dll both of which are linked
<mgz> unfortunately that means I'm not entirely sure what the right fix is.
<maxb> Sounds a bit wrong to have 2 CRTs linked
<mgz> it's not as wrong as it sounds from nix perspective, but it's possibly indicative of something
<mgz> as I understand it, starting with 2.6 you have to ship some vc 9 dlls with python
<mgz> the older threaded runtime is from my system.
<docoptix> hi. does anyone know of a way to limit the bandwidth bzr uses on commit?
<Muscovy> If I've made edits to an older revision of a branch, is there a way to automatically merge my changes with the new version?
<beuno> Muscovy, sure, bzr merge should do that for you
<beuno> or do you *just* want to cherrypick that change?
<Muscovy> merge is probably what I'm looking for.
<Muscovy> I don't have an issue right now, but I've manually merged things a few times now.
<Muscovy> I figured it was time to learn the proper way. :P
<mgz> are your changes committed or uncommitted?
<mgz> if uncommitted, just `bzr update` and resolve the conflicts
<Muscovy> bzr update wouldn't overwrite my edits?
<mgz> no, it's nice like that.
<Muscovy> Ok, thanks.
<maxb> jelmer: Hi. Are you around? I wanted to bring bug 397526 to your attention.
<ubot5> Launchpad bug 397526 in Bazaar GTK+ Frontends "0.96.0, 0.99.0 tarball does not contain credits.pickle (affected: 3, heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/397526
<bialix> jam: ping
<jelmer> maxb: Yeah, I've seen it
<jelmer> maxb: Haven
<jelmer> 't had time to roll a new tarball yet
<bialix> vila: are you still here?
<maxb> Ok - as it was an old bug which got reopened, I just wanted to check it had been noticed
<jelmer> maxb: Unfortunately bzr-gtk is severely lacking developers at the moment
<maxb> I pretty much only use it for bzr-notify :-/
<jelmer> maxb, what about bzr viz?
 * jelmer would still like to make the nautilus integration really rock at some point
<maxb> qlog is too good not to use :-)
<maxb> In fact, that's pretty much the sole reason I even have Qt installed at all :-)
 * jelmer has qt installed for mumble, skype and twinkle
<jelmer> for some reason proper VOIP apps only come in Qt form
<mac9416> How can I remove a file from version controlling without deleting it.
<mgz> bzr remove --keep
<mac9416> mgz, thanks.
<bialix> mgz: thanks for your analysis
<mgz> I'm a bit stuck on how to fix it though unfortunately...
<mgz> well, apart from big things like "go back to Python 2.5"
<bialix> mgz: I'm going to check py2exe faq
<bialix> and I'd like to look on the build machine, at least on build product before it get packed into installer. but for this I need either Garyvdm or jam
<dorins> Hi. Any qbzr devs around?
<dorins> I made some improvements to qdiff UI in this branch: lp:~dorins/qbzr/qdiff-changes . How do I go about requesting that it be merged into main branch?
<lifeless> click on 'propose for merge' in the web ui
<dorins> Do I leave the default merge target- lp:qbzr? Or should I set a specific version branch as merge target?
<lifeless> the default is the main branch
<dorins> That was easy. Thanks lifeless!
<lifeless> no problem
#bzr 2010-09-07
<jeremy> hi
<bullfrog1492> anyone here?
<bullfrog1492> the bzreclipse download is down @ the only mirror that still seems to be up: http://verterok.com.ar/bzr-eclipse/update-site/
<bullfrog1492> please advise.
<jelmer> verterok: ^
<mgz> poolie or someone else in charge, do I need to bug for contributor agreement for lp:~zigarn/bzr/440472-string-bugtracker to be merged?
<lifeless> I think so
<anteru> Hi
<anteru> Is there anyone working on the website?
<mwhudson> does anyone know what
<mwhudson> <lifeless> this means:
<mwhudson> <lifeless>  - either LP team supports the code base
<mwhudson> <lifeless>  - or the distro have it in main and support the code base
<mwhudson> <lifeless>  - no *new* SPOFs
<mwhudson> <lifeless>  - transparent
<mwhudson> <lifeless>  - no *slower* than what we have today
<mwhudson> <lifeless>  - no *higher* expected maintenance overhead (stability, corruption, robustness)
<mwhudson> <jamesh> you could always migrate the librarian to S3 ...
<mwhudson> baaaaa
<mwhudson> does anyone know what
<mwhudson> AttributeError: 'Tag' object has no attribute 'parents'
<mwhudson> implies?
<mwhudson> trunk dulwich, git & bzr
<fullermd> Seems to me I've heard reports of that, and it was a result of some API slippage among pieces.
<fullermd> But I don't remember any details.
<mwhudson> reverting to the most recent tags on bzr-git and dulwich gets different errors :(
<fullermd> See?  Progress!
<mwhudson> i think it might be that imports from local git repos are busticated?
<verterok> bullfrog1492: hi, sorry. I'll contact the owner of the server, I can't even login via ssh
<verterok> bullfrog1492: fyi, it seems to be a dns problem, should be fixed pretty soon. in the meantime the update site is accesible in a different domain: http://guille.beuno.com.ar/bzr-eclipse/update-site/
<johnf> What does "inconsistent parents" mean in a bzr check?
<spiv> johnf: short answer: nothing important
<spiv> (I'm not really here, hopefully vila or someone can go into more detail if you need it)
<johnf> spiv: yeah wondering why it occurs. Related to the bzr repository analysis I'm doing
<mwhudson> johnf: i think it means that the file graph and the revision graph don't always specify the parent revids in the same order
<lifeless> mwhudson: well, I know what the former means.
<bullfrog1492> verterok: thank you very much
<mwhudson> it's entirely possible i'm completely wrong
<mwhudson> i actually meant to say that before lifeless's comment :)
<bullfrog2000> verterok: I tried using http://guille.beuno.com.ar/bzr-eclipse/update-site/, but it seems to be hanging at "Calculating requirements and dependencies"
<bullfrog2000> when i try to install
<vila> hi all 1
<vila> <shudder> even there I manage to make typos :)
<mwhudson> vila: are you low on caffeine, nicotine or both?
 * vila get a needle and does an analysis...
<vila> nope, seems correct
<vila> ob both counts
<vila> on
<vila> :-(
<vila> :-D
<mwhudson> :-)
<vila> should be something else then...
<johnf> Is it possible to tell which version of bzr a particular commit was made with?
<lifeless> its not stamped
<lifeless> one can guess depending on how buggy it is :P
<johnf> :)
<vila> johnf: is it still related to the inconsistent parents ?
<johnf> vila: no
<vila> ok
<johnf> do source downloads of bzr prior to 0.17 exist anywhere?
<lifeless> lp I guess
<johnf> only goes back to 0.17 in 2007
<vila> johnf: if not on lp, there are tags and you may use some VCS to get back at the sources you're interested in ;)
<fullermd> I think before that the primary downloads were off the bazaar-ng.org site.
<johnf> good poing :)
 * vila wonders if it
 * vila wonders if it's a typo or pun on 'poing' meaning first in French ;)
<fullermd> Doesn't seem accessible any more.  It just redirects itself into the wiki.
<vila> fist not first :-(
<fullermd> If you have to use a fist, it's best to be first   :p
<johnf> heh
<johnf> Has "bzr mv" always existed?
<fullermd> As long as I've used bzr (sorta)
<Jerub> that was one of the selling points wasn' tit?
<Jerub> that it could rename and svn couldn't?
<johnf> just checked out tag for 0.1 and I can move did indeed exist
<johnf> sorry that's 0.0.5
<vila> johnf: what kind of archeological stuff are you on ? ;)
<johnf> vila: heh I've been asked to perform some analysis on a repository for a client, going back to 2006 :)
<vila> johnf: oh, hmm, I hope you will be able to tell us about the interesting bits
<vila> johnf: Is the repo public or not ?
<johnf> vila: no it isn't
<vila> johnf: yeah, I guessed... but better to be sure :)
<lifeless> johnf: is this the thing you rang me about ?
<johnf> lifeless: yes
<lifeless> nice
<lifeless> gl
<starenka> how can i annotate deleted file (get to know when and who deleted it)?
<CcxCZ> starenka: bzr log <file>
<CcxCZ> well duh
<CcxCZ> but the file is not there
<CcxCZ> there was some history grep plugin
<lifeless> bzr log -v | less, and search for the path (/PATH0
<starenka> lifeless: how come i can't | grep it?
 * starenka shots himself in the head (bad file name :) )
<starenka> thanks
<bialix> heya
<bialix> vila, mgs: ping
<bialix> vila, mgz: ping
<vila> bialix: pong
<bialix> https://bugs.launchpad.net/bzr/+bug/631350/comments/11
<ubot5> Launchpad bug 631350 in Bazaar "bzr 2.2 @ win32: print non-ascii characters to console made in user_encoding() instead of terminal_encoding() (affected: 1, heat: 6)" [Critical,Confirmed]
<bialix> vila: I'm very confused
<bialix> the only way I can think of is to try to reproduce the same with simple python script
<vila> wow, I can understand why, this sounds pretty awful
<bialix> and check is this a bug in Python 2.6 or MS dlls
<bialix> so, the tip to go back to 2.5 does not sound completely crazy this morning
<vila> bialix: long term (and may be even short term), it may be better to diagnose and fix... I don't know what will be required to downgrade to 2.5 on windows...
<bialix> vila: and maybe I need to look at the build machine soon. I think I should contact either jam or Garyvdm
<vila> bialix: yup, maybe check with mgz first, he seemed to be on something
<mgz> ah, bialix, you tried with a standalone 2.6? that was worth doing.
<bialix> I'll wait for mgz comments. He hunted that bug very effectively yesterday
<bialix> mgz: heya!
<vila> bialix: and what output do you have with the 2.2.0 installer ?
<bialix> the same as with py 2.6
<mgz> how about something even simpler and just do `python26 -c "print 'Ð¢ÐµÑÑ'"
<bialix> added as comment 12
<vila> bialix: Ok, borked then. And when you say 2.2 sources which revno ?
<mgz> or at least see how minimal we can get a repo without bzr
<bialix> vila, mgz: https://bugs.launchpad.net/bzr/+bug/631350/comments/13
<ubot5> Launchpad bug 631350 in Bazaar "bzr 2.2 @ win32: print non-ascii characters to console made in user_encoding() instead of terminal_encoding() (affected: 1, heat: 6)" [Critical,Confirmed]
<vila> bialix: and make sure you have the compiled extensions too, that may be another source of differences if dirstate is involved
<mgz> if this is a python upstream bug, great. I couldn't really believe it would be, as it's pretty giant and I found nothing on their tracker.
<mgz> one thing to try: locale module in python 2.6
<mgz> using the c locale has always been a great way to shoot yourself in the foot on windows
<bialix> C:\work\Bazaar\bzr-2a\2.2>C:\Python26\python.exe -c "print u'\u0422\u0435\u0441\u0442'"
<bialix> Ð¢ÐµÑÑ
<vila> mgz: works nicely on OSX too (regarding feet)
<mgz> okay, how about with import locale;locale.set_locale('') on the front
<mgz> (or whatever it is we do in bzr on that front)
<bialix> vila: compiled extensions does involved here. it's all about output
<bialix> vila: compiled extensions does NOT involved here. it's all about output
<vila> bialix: except if they provide a different *input* :)
<bialix> if you look at my bug report you can see that *sometimes* bzr produce correct output
<mgz> *locale.setlocale(locale.LC_ALL, '')
<bialix> vila: I don't think so
<vila> bialix: should be easy to prove that it's irrelevant then ;-P
<bialix> vila: I don't have VS2008 compiler :-P
 * vila bangs head on desk
<vila> bialix: waitaminute, you mean you never compile extensions yourself ?
<bialix> I can copy pyds from bzr.exe but I'm sure  it's irrelevant
<bialix> vila: for Python 2.5 I have VS2003
<vila> bialix: eerk, don't do that, if they are out-of-date you'll get all sort of weirds errors
<bialix> for Python 2.6 I need VS2008. I don't have it, and not very keen to install it right now
<vila> bialix: ha, so you build your own bzr.exe for py25 from sources ?
<bialix> and I'm not sure which version of mingw-gcc should support both 2.5 and 2.6
<bialix> vila: I *can* build bzr.exe for py25, yes
<bialix> but I don't because I prefer to dogfood official installer
 * vila cries, we *need* a free (as in speech) versioned dev setup
 * bialix cries too
<vila> bialix: but how can you test your fixes ?
<bialix> I haven't done the changes to compiled extensions yet
<bialix> and I'm happy with Python 2.5, so if I need to test something I can build extensions for 2.5
<mgz> okay, that repos it for me.
<vila> mgz: repro ?
<bialix> vila: I don't understand what you can't understand
<vila> bialix: I didn't understand how you built extensions, now I do, you use py25 ;)
<bialix> YES
<vila> bialix: but stay with the installer as much as you can
<bialix> yes, excatly
<bialix> because somebody should file bugs about installer
<vila> bialix: sure, what I wasn't getting was the py25/py26 difference
<bialix> py2.3 have used old MSVS v.6; py2.4/2.5 switched to VS2003, py2.6/2.7 switched to VS2008
<mgz> http://pastebin.ubuntu.com/489663/
<bialix> every time it created pain in the *ss for people
<mgz> ^that repo.
<bialix> mgz: it's not quite correct; what sys.stdout.encoding says?
<bialix> print is not quite correct to use here
<mgz> cp866
<bialix> mgz: please use unicode for Ð¢ÐµÑÑ: u'\u0422\u0435\u0441\u0442'
<mgz> as does locale.getpreferredencoding *prior* to calling setlocale
<bialix> oops
<mgz> identical.
<bialix> does we call set_locale in bzrlib???
<mgz> the problem is it's trying to get to a codepage from the system *language*
 * bialix cries
<mgz> when both the system codepage and terminal codepage are unrelated
<mgz> so... step one, kill the locale module :)
<bialix> kiil the chicken
<mgz> don't know why the locale setting started mangling streams in msvc 9, but we can avoid it at least.
<bialix> so this is either bug in python2.6+ or misfeature in python2.6+
<bialix> I think the latter
<mgz> well, I think python 2.6 might be able to blame it alternately on us and microsoft
<bialix> yes, of course, of course, why not
<bialix> I think blaming us is the right choice
 * bialix is going crying for the rest of the day
<mgz> well, two options I think on the fixing front
<mgz> #1 just don't call setlocale on windows, we don't use any of the features it attempts to provide anyway
<mgz> #2 do locale.setlocale(locale.LC_ALL, ".%d" % locale.getpreferredencoding())... but that might still mess stuff up
<mgz> getting all that crap out of the bzr startup script would be nice, there's already some mac workaround and a giant comment in there
<vila> mgz: time for a brzlib.osutils.locale module ?
<vila> mgz: yup, I know this comment :-(
<vila> mgz: and I'm pretty sure it's not accurate anymore
<mgz> well, the flipside of that is it's a process-global setting we really only want to hit once even on platforms that benefit from it
<mgz> but packagifying osutils and some serious sanitising is one of the things I've got notes on in case I ever have a free month :)
<vila> mgz: all the encodings we use (terminal, output, user) are already cached so we shouldn't set it more than once anyway
<vila> mgz: yup, but starting with locale may be a first step
<vila> could be overkill for this bug though, just mentioning
<vila> bbib
 * bialix bbl
<bialix> mgz: ping
<mgz> pong: http://pastebin.ubuntu.com/489700/
<mgz> just reading a confused thread on mingw-users on this too, doesn't help much
<bialix> I've just realized I'm testing on native English Windows XP with Russian locale. I have to test on my home notebook with native Russian Windows XP
<bialix> but after your paste I'm not sure there will be any difference
<bialix> mgz: so this is a bug in msvcrt90.dll?
<mgz> I think it will still be broken if the terminal and general codepage are different, unless they've special-cased that somehow
<mgz> it's an... odd... behaviour change, at any rate
<bialix> why anybody want to re-encode the strings -- I don't understand
<mgz> can see why they've done it, the locale dependent c functions need to return a bytestring in some sensible encoding, so languages have a default encoding tagged on
<bialix> heh
<mgz> somewhere along the line they've had people expecting to be able to change the locale+codepage of the whole process like this,
<mgz> as per this post saying "mingw should do it like msvc" <http://lists-archives.org/mingw-users/10242-problem-with-setlocale.html>
<bialix> in python everything was easy: if you have unicode then it will be encoded on output
<mgz> but Python 2 cheats
<bialix> should we still file a bug against python?
<mgz> it encodes to bytes itself then wants those kept pristine through the c library byte handling functions
<mgz> (not a big requirement, but apparently breakable)
<mgz> pretty much, we want to avoid this by not going near LC_CTYPE, which isn't hard because it's strictly less useful than unicodedata anyway
<mgz> really, the only thing we *might* be using currently is strftime, for all its other flaws at least the c locale stuff lets to cherrypick categories
<bialix> omg
<bialix> http://msdn.microsoft.com/en-us/library/tf52y4t1(VS.71).aspx this page says that only putws (unicode version) encode the output
<bialix> there is no indication that puts should re-encode the output
<mgz> right, this is... talking about different things
<mgz> <http://msdn.microsoft.com/en-us/library/x99tb11d> "The category must be either LC_ALL or LC_CTYPE to effect a change of code page."
<mgz> That's all I can see in the docs, but the implication is they've bundled chcp-like functionality into setlocale
<mgz> I don't quite get it, but... we can avoid this problem.
<bialix> mgz: http://pastebin.ubuntu.com/489707/
<mgz> yeah, it's pretty dumb.
<bialix> but if I run chcp 1251 and repeat the same steps it's anyway borked
<bialix> http://pastebin.ubuntu.com/489708/
<bialix> crazy
<bialix> if you know how to avoid this crazyness I'll +1e6 on the patch
<mgz> don't call breakmyprogramrandomly(LC_ALL, "")... ehm, I mean, setlocale
<mgz> I'll put up a branch to that effect for review.
<bialix> thank you
<ddaa> just wondering
<ddaa> is there a hack around to provide authentication on plain bzr:// ?
<lifeless> ssltunnel ? :P
<ddaa> oh
<ddaa> yep, bzr serve --port localhost:4155 woud work with tunelling
<ddaa> but that's pointless, because then you may as well use bzr+ssh.
<maxb> What would be neat, would be SASL auth on top of the smart server protocol
<ddaa> I can imagine that stunnel might be easier to setup than sshd in some cases (windows...)
<ddaa> Thanks.
<mgz> dammit. missplaced apostrophe.
<mgz> ...and tyop in the first sentence
<mgz> think that's a sign of time to give up on computers and do something else
<vila> mgz: ok, got it.
<vila> mgz: many regressions about unicode/locale have been introduced in 2.1 when we stopped running LC_CTYPE= LANG=C LC_ALL= ./bzr selftest
<vila> well s/in 2.1/since 2.1/
<vila> mgz: try it on trunk :-/
<mgz> I think this bug might be a bit harder to hit than it appeared, I wouldn't be suprised if on Alexander's all russian, all the time, box no mangling happens even though the basic code page and terminal codepage differ
<mgz> but locale things are just a pain, there's actually some benefit on nix though as it controls a bunch of system things as well as the c language stuff
<vila> mgz: http://paste.ubuntu.com/489776/ will remind you some things
<mgz> yeah, that's the "don't know how to map unicode to the filesystem" joy
<vila> mgz: not only, it doesn't *finish*
<mgz> the tests falling over is an easier fix, must remember to do that...
<dev001> .join #suse
<bialix> hi jam
<jam> morning bi
<jam> bialix (tab fail)
<bialix> is it possible to look at build machine? I'm interesting in py2exe.log file and/or in the content of win32_bzr.exe folder
<bialix> I suspect we should bundle manifest files for our exe files
<bialix> they're not currently installed with standalone installer
<bialix> jam: ^
<jam> bialix: the build machine is currently stopped, but we can bring it (from scratch) if you want. We'll need to trigger a fresh build to get any interesting output, though
<bialix> Gary said he's going to build new installer tonight, maybe I should waut him then
<bialix> wait
<GaryvdM> Hi jam
<GaryvdM> jam: Please may I do a build on the ec2 server
<jam> GaryvdM: I'll spin it up
<GaryvdM> jam: Thanks
<GaryvdM> jam: I started building a vm, but not done yet.
<jam> GaryvdM: i was also hoping to get it set up on vila's babune machine, but we haven't done much with that
<jam> we should add a startup script that emails me so I know when the instance is actually running :)
<GaryvdM> bialix probable on his way home. I read he was just talking to you.
<jml> can I use bzrlib to fetch an http page with query parameters?
<jam> jml: Transport.get_bytes() talks in URLs, so it should be possible
<jml> jam: thanks.
<vila> jml: not so sure, that rings a bell around split_url or some other url related function that get rid of the junk (err, sorry, query)
<vila> jam: yeah, I know :-/ But clean full test suite first ;)
<jam> anyone know the name of the app that pops up the 'enter your password for the keymanager' dialog?
<GaryvdM> jam: what os is this on?
<jam> GaryvdM: lucid
<jam> I'm trying to file a bug
<jam> the 'info' areas can take the cursor
<jam> so if you click on the dialog to enter your password, it doesn't actually let you type
<jam> until you click inside the edit box
<jam> it has caught me a few times, seemed bug worthy
<jam> I'll just file it in gnome-keyring
<jam> jml: some questions about the codehosting stuff if you have time.
<jam> I can find the code that starts the 'sftp' server, is that *also* the smart server code?
<jam> The best I can find is registering the 'launch_smart_server' adapter
<jam> but I have no clue where that actually gets invoked
<jml> jam: you mean daemons/sftp.tac? that launches the SSH server which handles both, yes.
<jam> jml: specifically I was looking at "make run_codehosting" which starts sftp, and tracks down...
<jam> but thanks
<jam> that gives me the general location
<jml> jam: there's some code somewhere (ExecOnlySession) that makes an SSH session that allows exactly one thing: running commands
<jam> jml: yep, I know that code, but I diddn't know what service calls that code
<jml> jam: ahh right. it's registered as an adapter somehow, and then conch uses that when the SSH client asks for a session.
<jam> the sftp code inherits from an Application that calls itself "sftponly"
<jml> yeah, that's legacy, sadly.
<jam> jml: I figured it was the only place that looked like it *could* be running it, but it certainly wasn't directly obvious :)
<jml> because developers have no idea or control over how scripts are invoked in production, we are generally reluctant to rename them.
<jam> jml: 'make run_codehosting' seems to invoke 'bin/run ... codebrowse' which in turn starts codebrowse via 'make run_codebrowse'. It then adds a "stop_at_exit(<make process>)".
<jam> Does that mean when running codehosting *make* is actively running
<jam> waiting on the exit of the loggerhead script?
<jam> (It feels very odd to me that it indirects through make)
<jam> (As I'm creating a new long-lived process, I'm trying to determine what the "correct" method is)
<jml> I don't know why it indirects through make
<jml> I didn't have anything to do with codebrowse.
<jml> jam: someone on #launchpad-dev might know about that.
<jml> jam: I've got to head out now. Good luck.
<jam> np, thanks for your help jml
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2.0-setup.exe
<GaryvdM> Build of lp:~gz/bzr/setlocale_on_posix_only_631350
<GaryvdM> For Bug 631350, I'm trying to test if the installer I built of mgz's branch fixes the the bug.
<ubot5> Launchpad bug 631350 in Bazaar "Python 2.6 @ win32: print non-ascii characters to console produce borked output (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/631350
<GaryvdM> But I can't paste the unicode into the console.
<GaryvdM> When I try paste Ð¢ÐµÑÑ, it comes out as ????
<GaryvdM> Do I maybe have to change the console encoding? How?
<HollyRain> when is used "bzr push <url>", where is stored the URL information?
<maxb> HollyRain: In .bzr/branch/branch.conf
<maxb> Use 'bzr info' to see it in friendly form
<HollyRain> thanks
<maxb> Use 'bzr push --remember' to update it without needing to edit the file manually
<drumm> If I bzr join in something, is there a way to get that root back out so I don't have to remember where it came from for bzr merge .. ?
<GaryvdM> :-( The windows installer specific bug are disheartening.
<GaryvdM> *bugs
<GaryvdM> jam: I'm done with the ec2 server. I don't know if you want to leave it on for bialix so that he can look at Bug 632465 or not.
<ubot5> Launchpad bug 632465 in Bazaar Windows Installers "[manifest?] bzr.exe using system msvcrt90.dll from sxs, not the bundled one (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/632465
<GaryvdM> jam: Thanks
<jam> GaryvdM: np, sorry to hear about the win32 installer stuff, but I'm *very* happy that it isn't me :)
<GaryvdM> jam: All the issues seem to fallout from the python / pyqt upgrade...
<jam> GaryvdM: I'm sure there are quite a few there, at least they aren't just plugin related :)
<JoshBrown> I'm using qbzr and something seems to be converting my symlinked path into an incorrect expanded one:
<JoshBrown> Run command: bzr merge ~/.bzr/snakes-game/tail-code --revision 27
<JoshBrown> bzr: ERROR: Requested revision: u'27' does not exist in branch: BzrBranch7('file:///mnt/Home/Misc/Mine/Packages/Bazaar/snakes-game/trunk/')
<GaryvdM> JoshBrown: I don't think that qbzr is affecting it. I think that if you ran  bzr merge ~/.bzr/snakes-game/tail-code --revision 27 from the terminal, you would get the same result.
<maxb> JoshBrown: Can you tell us more about what branches are symlinked to what in your arrangement?
<GaryvdM> JoshBrown: What is the output of ls -l ~/.bzr/snakes-game/
<JoshBrown> maxb, GaryvdM: ~/.bzr â /mnt/Home/Misc/Mine/Packages/Bazaar
<JoshBrown> maxb, GaryvdM: There are no other symlinks inside those subdirectories
<maxb> So, um, why is it looking for the stated revnum in ..../trunk when you asked for it in ..../tail-code? :-(
<GaryvdM> JoshBrown: what says bzr info ~/.bzr/snakes-game/tail-code
<JoshBrown> Repository tree (format: 2a)
<JoshBrown> Location:
<JoshBrown>   shared repository: .bzr/snakes-game
<JoshBrown>   repository branch: .bzr/snakes-game/tail-code
<JoshBrown> bzr: ERROR: Parent not accessible given base "file:///home/josh/.bzr/snakes-game/tail-code/" and relative path "../../../../../../../../home/josh/.bzr/snakes-game/trunk/"
<JoshBrown> maxb, GaryvdM: It works fine if I give it an exact filepath (i.e. '/mnt/Home/Misc/Mine/Packages/Bazaar/snakes-game/tail-code')
<maxb> JoshBrown: Do you have a traceback in ~/.bzr.log corresponding to your original "Requested revision ... does not exist" ?
<JoshBrown> maxb: No...
<maxb> oh
<maxb> I don't suppose executing 'bzr merge -Derror  ~/.bzr/snakes-game/tail-code --revision 27' produces one?
<JoshBrown> If it helps, I actually have multiple layers of symlinks: ~/.bzr â ~/.pkg/Bazaar & ~/.pkg â /home/josh/Home/Misc/Mine/Packages
<JoshBrown> maxb: It's already merged using an exact filepath, but I can setup a new branch to test it if you want
<GaryvdM> Good night all - I have to wake early tomorrow...
<maxb> JoshBrown: Well, if you have time, info that leads to finding bugs is always good
<Buttons840> when viewing the bzr logs, there is a "branch nick" listed, this appears to default to the name of the folder your working from (forgive my terminology); is there a way to change this branch nick?
<dash> bzr nick super-awesome-branch
<Buttons840> are the effects retroactive on old logs?  (i'm about to tias, but if anyone wants to answer anyways)
<maxb> No, bzr revisions are always immutable once committed
<dash> pretty much nothing is retroactive on previous commits
<maxb> s/pretty much //  :-)
<dash> maxb: well 'uncommit' provides a convincing appearance. :)
<Buttons840> is uncommit really just another commit?
<dash> it just changes what the tip revision is
<maxb> i.e. "these revisions may still exist on your disk, but we're ignoring the fact they once existed in this branch"
<JoshBrown> maxb: I think this is a qbzr issue since everything works fine using plain bzr
<maxb> that seems rather odd. Possible, but odd
<JoshBrown> maxb: Yeah, maybe it's something to do with canonicalization of links or something like that. Anyway I'm off for now, I'll check the differences between the commands I'm running and the ones qbzr is running tomorrow. Bye, and thanks for the help!
<ayan> how do you get a list of available branches?  i'm looking for the eqivalent to "git branch -la"
<dash> ayan: available where?
<ayan> available in a cloned repository.
<dash> ayan: 'ls'
<ayan> ah!  thank you.
<ayan> hm.
<ayan> hmm... maybe i should rtfm harder.
<dash> ayan: what's wrong?
<fullermd> And you don't clone repositories, you clone branches.  So there's not much to list  ;)
#bzr 2010-09-08
<ayan> i see.  i'm trying to map git concepts onto bzr.
<ayan> how do i copy a repository with all of the associated history a la ``git clone''?
<dash> ayan: i'd use tar, probably
<dash> ayan: but usually, it's not necessary
<dash> ayan: just use 'bzr clone' to get the branch you want
<ayan> okay, thanks.  off to rtfm harder. :)
<poolie> hi jelmer, all
<spiv> Good morning.
<mangojambo> Hi, I need a help here with osx bazaar: I'm  running bazaar explorer and I'm getting the follow error when I try to open Settings > Configuration > User Configuration :
<mangojambo> QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory
<mangojambo> QFileSystemWatcher: failed to add paths: /Users/mj/.bazaar/bazaar.conf
<mangojambo> Please, how can I fix it?
<maxb> Does /Users/mj/.bazaar/bazaar.conf exist?
<mangojambo> maxb: no. But I creat a file ( touch ~/.bazaar/bazaar.conf) and the error stops, but nothing happens
<maxb> mangojambo: Ok, that sounds fairly likely
<maxb> This means that the "errors" you posted are not errors, but just informational notes, and the real problem is something else
<mangojambo> so, how can I fix it, or just access user configuration to set my user, email, etc ?
<maxb> I'm afraid I don't know enough about qbzr to suggest what the problem might be
<mangojambo> maxb: ok, thanks man. I will keep trying here.
<mangojambo> seeya
<poolie_> hi spiv
<poolie_> apparently search on the bzr web site is broken so i'm going to try to fix that now
<poolie_> then do something about stale locks
<poolie_> i hope you got back eventually
<poolie_> and apparently i'm the pilot
* poolie_ changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out
<spiv> Yes, I did get back eventually!  Very back row of the plane, but that arrives very shortly after the front so it was ok ;)
<poolie_> :)
<poolie_> slower exit, but greater survivability
<spiv> Plus I got to watch the rest of the neverending press conference.
<poolie_> everyone can have 30 minutes of fame if they ramble enough
<spiv> And the gradually increasing groans and eyerolls from the people watching it waiting for the result.
<spiv> The mood towards rambling could be summarised as: "don't they know some people have planes to catch?"
<spm> hahah
<spiv> As soon as the key bit arrived the suddenly 2/3rds of the people hanging around disappeared, or at least it felt like that.
<jam> spiv: do you know why spawnProcess seems to return a 'Process' object that doesn't claim to implement IProcessTransport (though spawnProcess claims to return that type?)
<spiv> jam: sounds like a bug (in either docs or implementation...)
<spiv> jam: on windwos?
<jam> spiv: PosixReactorBase
<jam> spiv: twisted/internet/interfaces.py says thait IReactorProcess returns IProcessTransport
<spiv> So the default reactor (select)?
<jam> PosixReactorBase returns internet.process.Process directly
<jam> spiv: I don't really know, but IOCPReactor does the same thing
<jam> spiv: I'm trying to replace a spawnProcess call with my own stuff, but the details are a bit.. hazy
<spiv> Well, Process is supposed to implement that IIRC
<spiv> Certainly twisted.internet._dumbwin32proc.Process does
<jam> spiv: well, I can't find it saying "implements()"
<poolie> hello jam
<jam> spiv: right, that is the only thing that *does* implement it
<jam> hi poolie
 * jam is digging into twisted internals right now
<spiv> jam: please file a bug
<jam> which isn't a whole lot of fun, but doesn't seem too bad
<spiv> jam: I think it's just missing the implements declaration
<jam> spiv: so my concern is whether implementing the minimal IProcessTransport will be enough
<spiv> jam: AFAICS it does actually satisfy that contract
<jam> spiv: Process probably does
<poolie> jam, is this because the reviewers really wanted twisted rather than otherwise?
<jam> *I* don't know if I need to implement more
<poolie> or because you need to fix the conch server?
<jam> poolie: the ssh daemon is a Twisted process
<jam> poolie: right
<jam> I need to connect up the ssh incoming with the spawned process
<jam> IProcessTransport is pretty minimal, so it shouldn't be too bad
<jam> the concern is that it also seems intermingled with IProcessProtocol
<jam> and that is a much larger api
<jam> spiv: for example, I don't think spawnProcess calls transport.makeConnection(proto)
<jam> though I'm still wrapping my head around everythingf
<spiv> Process.__init__ does that
<spiv> IIRC
<jam> spiv: yeah, in a try/except: loop, no less
<jam> (bare except)
<jam> I didn't see it originally because __init__ is quite long
<jam> I *did* see it in the win32 one, and was trying to reconcile that
<spiv> (I wonder if it would be clearer if ProcessProtocol didn't implement IProtocol, and instead was explicitly adapted...)
<jam> I'm thinking about inheriting from one of the classes in the Process stack, to get some of the file handle polling stuff
 * jam doesn't really know what IProtocol is, or where Protocol is different from something else
<jam> spiv: and the docstring for IProcessTransport is: A process transport.
<spiv> I think if you are trying to inherit from Process for anything other than implementing a new reactor you're probably not gelling with Twisted well.
<jam> which is *mighty* helpful
<spiv> Well, it's the transport for a process! :)
<jam> Very true
<spiv> IProtocol is very slim, take a look at it.
<jam> spiv: so I'm spawning a process outside of the current process and connecting to it
<jam> which is ~ a subclass of Process
<jam> I have pipes to read / write to
<jam> I have a PID
<jam> etc
<jam> it is a good fit for IProcessTransport
<spiv> Just thinking of network services for a moment, Twisted has "protocols" and "transports": a transport is something like TCP or SSL (or a pipe...) that can convey a bytestream.  A protocol is something that can receive a byte stream.
<jam> I also have to manage talking on several file descriptors, etc, which Process already implements
<spiv> (and decode it into HTTP request objects or whatever the protocol is)
<jam> I just don't want to call _fork
<jam> I might inherit from BaseProcess, or _BaseProcess (which inherits from BaseProcess oddly enough...)
<spiv> A IProcessTransport is a transport with some extra features like pid and the ability to send signals.
<jam> spiv, poolie: Do you know if waiting for a pid that isn't a child just raises an error?
<jam> (I can test it, but I figured I could ask first)
<spiv> jam: that sounds like a reasonable fit for IProcessTransport too
<spiv> s/that/I think that/
<jam> spiv: I don't know how to submit bugs to twisted, and probably have to log in
<jam> any chance you could submit one for me?
<jam> Just a simple "internet.process.Process' does not implement IProcessTransport
<jam> (though it is returned by spawnProcess, which claims to return one of those)
<spiv> You do need to log in, it's a Trac instance: twistedmatrix.com/trac
<jam> spiv: yeah, I know where it is, but have no user, and it isn't really worth signing up for a 2 line bug report :)
<spiv> Ok, but if you're poking at Conch I can almost guarantee you'll have more bugs to file before you're done ;)
<jam> spiv: well, I'm certainly trying to avoid poking at any twisted internals :)
<mkanat> Why does it seem like committing to a remote bound branch is so much slower than committing locally and then pushing?
<jam> mkanat: it is possible, time it and check
<jam> it pretty much does exactly that internally
<jam> but it is possible there is a different code path
<poolie> mkanat: because we're compressing the things to store relative to things stored remotely, maybe?
<jam> poolie: we write it locally, then push, then update the branch pointer
<mkanat> poolie: That could be. It could also have to do with taking a lock on the remote repo, or something.
<poolie> mkanat: also, if there's a difference, getting a -Dhpss log should make it obvious why
<mkanat> poolie: Okay.
<jam> and/or --lsprof-file foo.callgrind
<jam> anyway, back to family time
<poolie> jam i'll try to catch you tomorrow afternoon your time
<spiv> jam: http://twistedmatrix.com/trac/ticket/4648
<poolie> i think i'll delete the rendered html from the website branch
<poolie> now we can generate it on the server it just seems to be noise
<mkanat> poolie: Yeah, and probably confusing to anybody who checks it out, if by some chance it ever wasn't up to date with the source.
<mkanat> We used to store compiled docs along with Bugzilla; we removed them many years ago. It was a good idea. :-)
<poolie> ok, and i think site search is working again, can someone test it?
<anteru> Hi, is anyone working on the Website?
<poolie> i am
<poolie> is it broken?
<anteru> If so, are there specific requirements for it? I'm playing around with a new layout which moves bzr slightly closer to what git and hg have on their front-page.
<poolie> ok
<poolie> i think it could certainly be improved and clarified
<poolie> do you mean a requirements doc, or technical requirements?
<anteru> I.e. a prominent download link fed from Launchpad directly, and two boxes for quick start
<poolie> the source is in lp:bzr-website
<poolie> that would be gerat
<anteru> poolie: Requirements as in what _has_ to be on it, and technical as in lib x must be used
<anteru> I don't know if there is some requirement from canonical for instance
<poolie> nup, both are negotiable
<poolie> whatever makes sense
<anteru> Ok
<anteru> I assume it should work with Python 2.x?
<poolie> yes
<poolie> any dependencies for generation should ideally be packaged in ubuntu
<poolie> but we can work that out o
<anteru> All right, I'll keep on hacking then. As soon as I have some mockup done, I'll be back, but it might take some while.
<poolie> also, i think it's nice to keep the current approach of static generation, if possible
<poolie> that would be great
<poolie> you could post some screenshots or urls to the list, or here
<anteru> Sure, as soon as I'm happy with it :)
<anteru> I just wanted to check if someone else already works on a redesign for the front-page.
<jbowtie> Please send them to the list, I wanted to tweak the Sphinx template for the documentation to feel more integrated with the website.
<poolie> that would be great too
<poolie> also to make the wp blog consistent with the site
<poolie> anteru: you can look at the canonical design standards for inspiration
<poolie> which are probably linked from wiki.ubuntu.com
<anteru> uh oh folks :) one at a time, maybe (:
<poolie> but we don't have to stick to them
<jbowtie> anteru: I'm putting my hand up to work on the Sphinx template, I just want to see what you're thinking so I head in the same direction. ;)
<anteru> actually, I wanted to do some clean-slate CSS3 and modern web design stuff, and as the bazaar frontpage is only a single page, I thought this is a good victim. Especially as it has some problems right now (tiny fonts, too many links, difficult to navigate, outdated content.)
<anteru> give me a minute, and I can show you the current hacky state, basically blocking out the layout/content
<anteru> quick: screenshot tool for kubuntu?
<anteru> got it
<anteru> http://img13.imageshack.us/img13/2373/bildschirmfoto1vt.png
<anteru> danger: ugly and work-in-progress
<anteru> anything which looks remotely fancy is CSS3 shadow/rounded-borders/etc. so the amount of images is kept to a minimum and it should degrade gracefully
<jbowtie> You're right about ugly.  :)
<anteru> it's work in progress
<jbowtie> I know, I was kidding, you should see my early designs. Actually better if you don't.
<jbowtie> First impressions: better (already) than the existing site. somewhat text-heavy for a front page. shell scripts might scare off those looking for bzr explorer.
<anteru> with some more context: http://img84.imageshack.us/img84/6872/bildschirmfoto2q.png
<anteru> well, that's why I want to keep the image at the top, then the explanation, then I'll probably add a small breaker with projects currently using it, and then the shell scripts
<anteru> it also needs a bit stronger colours IMAO
<anteru> but the yellow logo means it will basically only go well with blue, or some orange-looking stuff
<jbowtie> I'd lose those borders, makes it too blocky.
<anteru> ok. I'm keeping them for now, as it eases layout a bit
<jbowtie> If you make them a light grey you can still see your layout but get a better feel for what it looks like with just whitespace.
<jbowtie> I'm thinking it would be nice to show both the command line and a close-up of the gui interface. Play to both audiences.
<anteru> also need to move it into some grid, right now it's completely ad-hoc
<jbowtie> Maybe those quick-start blocks could link through to more detailed instructions (in the gui case with step-by-step screenshots)
<jbowtie> I think you could try recoloring the logo (and making it smaller). Or maybe we can come up with a better one.
<anteru> hm, one possibility would be to have a jquery powered slide-show basically, showing you both step by step
<anteru> I.e. you just click and you see a "focus" screenshot on the left and the corresponding shell instructions on the right
<jbowtie> Worth experimenting with, might not work on the front page though with everything else that needs to be communicated.
<anteru> but first things first, but current todo is to get a proper grid in place first, then get all the content onto the page, then fix colors, then do some real layout, and then get back to discussion
<anteru> args, I need to learn to type :/
<jbowtie> No worries, I'm supposed to be working anyway. Send it to the mailing list when ready, I don't spend a lot of time on IRC.
<anteru> just for reference, my own website has lots of whitespace: anteru.net :P
<anteru> Yeah, I actually have to do some graphics stuff as well ... but still good to get some early opinions.
<anteru> graphics == opengl code, not the painting style
 * anteru goes lurking again
<JoshBrown> Where do I file a bug about launchpad documentation?
<twb> I get a backtrace trying to branch a repository over bzr+ssh, with 2.2.0 on my end and 1.3.1 on their end.
<twb> Is that expected?  Should I fall back to sftp: ?
<JoshBrown> What does the backtrace say?
<twb> Sorry, one moment
<twb> http://paste.debian.net/88489/
<twb> (I got distracted in another channel.)
<twb> OK, and sftp fails with "EOF during negotiation"
<twb> Note: I know that repo exists (I can see .bzr and such with ls -a on the far end), but I don't know if it's the repo I want, nor if bzr is actually working on the far end.
<JoshBrown> twb: That suggests that is may be a more generic error
<twb> bare ssh IS working
<twb> Oh, maybe it's because these fucktards block ICMP, so MTU negotiation doesn't happen.
<twb> Let me try dialing the MTU down to 1450 or so.
<mkanat> twb: 1.3.0 is really old.
<twb> mkanat: I'm not going to upgrade random stuff on a customer's production server.
<mkanat> twb: That's certainly your prerogative.
<twb> Thank you for understanding that :-)
<JoshBrown> twb: He has a point, why can't you upgrade it?
<twb> Because upgrading software, particularly out-of-band, tends to introduce bugs as well as features.
<twb> Unless I *really truly NEED* a feature, I'm not going to go out of my way to upgrade things.
<mkanat> twb: If you're using just ssh:// or sftp:// then you're not interacting with the bzr on the server at all.
<mkanat> twb: So that would be something protocol related.
<twb> Right; which is why I suspect MTU
<mkanat> twb: Could be.
<mkanat> twb: Are you on some network where MTU auto-negotiation actually happens? I haven't seen one of those in quite some time.
<twb> mkanat: MTU negotiation definitely *doesn't* happen on this network
<twb> Because they block ICMP
<mkanat> twb: Okay. So it would be odd for the server to have specified an MTU below the standard then, right?
<twb> mkanat: it's a pptp vpn, unfortunately
<mkanat> twb: Ohh.
<mkanat> twb: So you might be hitting the problem before you even really get into their network.
<mkanat> twb: But in that case, bzr+ssh wouldn't have worked at all, right?
<twb> Why not?  ssh works over the VPN
<mkanat> twb: If there was an MTU problem, I mean.
<twb> IIRC MTU problems manifest only when you start shoving nontrivial data
<twb> e.g. ssh works until you run "ls"
<mkanat> twb: That could be.
<mkanat> twb: You'd have to send a packet larger than the MTU, I suppose.
<twb> FWIW, with an mtu of 1446 I still see the symptoms described above for sftp: and bzr+ssh:
<twb> Right.
<twb> (Larger than *their* MTU,  that is)
<mkanat> Right.
<mkanat> twb: Can you normally "ssh" or "sftp" to the server?
<twb> Yeah
<twb> My bzr URI syntax is right, right?
<twb> I always fuck it up when using hg
<twb> Ugh ugh ugh
<twb> ssh works, sftp doesn't
<twb> AFAICT someone has installed an sshd_config on this host that's not compatible with the version they're actually running.
<spiv> twb: ugh, that's a regression
<twb> spiv: let me clarify
<twb> sftp bwired-dvmh-mgmt-01.bulletproof.net ==> subsystem request failed on channel 0 \n Couldn't read packet: Connection reset by peer
<twb> i.e. sftp fails outside of bzr
<spiv> twb: the traceback for 2.2.0 against 1.3.0 is the regression I'm referring to
<twb> Oh right
<spiv> (Possibly would happen with 2.1 as well?)
<twb> So it looks like I can't actually clone this repo, since the regression happens for 2.2.0 vs. 1.3.0 on bzr+ssh, and sftp isn't available (though ssh and scp ARE)
<twb> Re. sftp, the problem is *definitely* ssh, *not* bzr
<twb> Sep  8 14:33:18 bwired-dvmh-mgmt-01 sshd[31333]: error: subsystem: cannot stat internal-sftp: No such file or directory
<paul__> hi.  HELP!  rebase has stuffed my working branch in a very bad way,
<paul__> https://bugs.launchpad.net/bzr-rewrite/+bug/632894
<ubot5> Launchpad bug 632894 in bzr-rewrite "rebase did NOT include all the commits AFTER a merge (affected: 1, heat: 8)" [Undecided,New]
<paul__> i've reported the bug, but now i need to fix the problem in a hurry
<paul__> i assume the commits are still in the repo *somewhere*, how can i find and pull them?
<mkanat> twb: Glad at least that you've got it figured out now, though.
<spiv> twb: I think I can give you a workaround, just a sec
<paul__> eg, i know when i do bzr uncommit, it tells me a magic thing i can type in to retrieve that commit back
<paul__> how do i get a list of those?
<fullermd> paul__: There's a 'head' command in bzrtools that digs through the repo and tells you what head revs there are.
<spiv> paul__: bzr heads --dead-only
<spiv> paul__: you'll need the 'bzrtools' plugin if you don't already have it
<fullermd> It should be a short enough list that you can make a good stab at which you want.
<paul__> oh god, thanks, there it is
<fullermd> So you should be able to 'pull --overwrite -rwhatever .` to restore it in-place (or fiddle around with making a new branch at that rev if you prefer)
<fullermd> (don't miss the '.' in that command line)
<paul__> i'll do a branch to check first
<paul__> if this doesnt work my only remaining copy is in my editor
<paul__> there are quite a few heads, more than i thought there would be
<paul__> and theres more than one for this particular checkin!
<paul__> same timestamp
<paul__> i only checked it in once, then i did a rebase which stuffed things up
<paul__> can someone please check that bug?  if its real, then it could be a very serious problem to a lot of projects
<fullermd> Well, you can check both.  It may take some rooting, but it's there.
<twb> spiv: thanks, please stick a "twb:" in front when you have it, so my notification system wakes me up
<spiv> twb: will do, sorry something else has come up right at this second, but I will get back to you soon I hope.
<twb> No rush; I'm just gonna scp -r it across and look at the repo; I don't need to patch it just yet
<twb> Is there an equivalent of "bzr viz" that works on the terminal (like "hg glog")?
<spiv> bzr log -n0, to an extent.
<twb> I meant for the little DAG down the side
<spiv> Not that I know of, but it'd be nice to have.
<twb> Oh well.  I'll xinit /usr/bin/bzr viz
<spiv> twb: bzr branch lp:~spiv/+junk/bzr_ssh_v2_hack ~/.bazaar/plugins/
<twb> spiv: Branched 0 revision(s).
<spiv> Oh, gar.
<spiv> I'll fix that :)
<spiv> twb: ok, pull now (or delete and rebranch)
<twb> Still fails
<spiv> Details?
<twb> Sorry
<twb> http://paste.debian.net/88495/
<spiv> I don't see bzr_ssh_v2_hack in your list of plugins there.
<twb> That's because you told it to dl to plugins/ itself
<spiv> Oh!
<spiv> Sorry, that was careless.
<twb> OK, now I did something bad
<twb> ImportError: No module named bzrlib
<spiv> Huh.  pastebin the traceback (add -Derror to the command line if it doesn't emit one)
<twb> And now that error is gone agan
<twb> I have no idea what happened there
<spiv> Weird!
<twb> spiv: bzr+ssh works after that plugin is cloned into a subdir of ~/.bazaar/plugins/
<spiv> twb: great!  I'll work on fixing the bug properly for 2.2.1/2.3
<twb> Will that branch remain available?
<twb> I'd like to mention it in my ticket system
<spiv> twb: sure
<twb> Thanks for the prompt response
<spiv> You're welcome, I'm glad the workaround worked.
<vila> hi all !
<poolie> hi there vila
<vila> poolie: hey !
<vila> poolie: Can you clarify your comment on bug #323111 ? Oh, you already did
<ubot5> Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 1, heat: 8)" [Medium,In progress] https://launchpad.net/bugs/323111
<poolie> :)
<vila> yeah, I had that policy thing in mind too, I'm about to write the tests and code for that.
<vila> Blueskying, a registry could be used to decide that based on a... config variable maybe ;)
<vila> but I think it will be overkill for a first submission
<vila> and there are some interactions with junk files we may want to address first too (though that's a bit more invasive, currently my patch modify TreeTransform only)
<twb> $ /usr/bin/time bzr log --help >/dev/null ==> 2.73user 0.08system 0:02.81elapsed 99%CPU (0avgtext+0avgdata 84320maxresident)k
<twb> Why does bzr need three seconds in the CPU even to print the help text?
<twb> On the same host, "hg log --help" takes less than half a second of CPU time
<fullermd> 0.090u 0.030s 0:00.12 100.0%
<vila> 0.11user 0.00system 0:00.11elapsed 97%CPU
<twb> The host in question is running bzr 2.2.0 on Debian sid.
<fullermd> I tend to suspect my system isn't REALLY 20x as fast as yours...
<spiv> twb: try with --no-plugins; the hack I gave you would have the side-effect of forcing the import of a bunch of often unnecessary code.
<twb> spiv: with --no-plugins it's still 1.2s user
<spiv> (As might some of the other plugins you have installed, I haven't looked at e.g. etckeeper's impact on load times)
<spiv> Ok, well that's half the problem at least ;)
<twb> I have bzrtools and python-paramiko installed, but not bzr-{doc,gtk,svn}, python-kerberos, python-pycurl or xdg-utils installed (the packages bzr suggests).
<spiv> twb: that is pretty slow, though!  It's 0.096s user on my laptop.
<spiv> twb: perhaps somehow the .pyc files are missing or stale in your install?
<twb> About the only thing I can think of is "byte-compile = optimize" in /etc/python/debian_configuration
<twb> But I would *hope* that it's only byte-compiling files once
<spiv> Hmm, possibly.
<twb> And in any case, if it was a python problem it ought to break hg, too
<spiv> Yeah, unless the packaging is quite different or something.
<twb> Oh, and I'm on an SSD, so probably my read speeds are good and my write speeds are bad.
<vila> or unless bzr triggers something hg doesn't but it still python related :)
<vila> twb: check your install for the .pyc files, if they aren't there python have to generate them at each run
<spiv> twb: try 'python -v /usr/bin/bzr rocks'
<twb> http://paste.debian.net/88516/
<spiv> twb: if it is importing from .py files rather than .pyc/.pyo, and/or emitting a bunch of "can't create", that'd be a problem
<spiv> twb: yep, it is looking for and failing to load .pyc files.
<twb> That's stupid :-/
<twb> I shouldn't have to run bzr as root to get pycs
<spiv> twb: ah, because /usr/bin/bzr has "#!/usr/bin/python", which won't look for .pyo
<twb> Stupid debian
<spiv> twb: if you have "#!/usr/bin/python -O" it would look for .py
<spiv> Er,
<spiv> twb: if you have "#!/usr/bin/python -O" it would look for .pyo
<spiv> That extra char matters :)
<spiv> twb: Perhaps you should set byte-compile = standard, optimize in /etc/python/debian_config ?
<vila> spiv: ETOOCLOSE(pyo, typo)
<spiv> (if that works)
<spiv> vila: hah
<twb> spiv: hum, I'll try that.
<spiv> twb: arguably the bzr deb package could check that config and adjust the #! line accordingly, it might be good to file a bug about that.
<twb> You'd think that part would be done in some magical way for *all* packages
<spiv> Yeah, it seems like something that python-central ought to help with.
<spiv> Maybe it does, and the bzr package just doesn't use it?
<twb> Damned if I know
<spiv> I'm no expert in packaging :)
<spiv> Definitely this counts as a bug in the packaging, though.  That's a pretty unpleasant result :(
<spiv> Setting a config var to optimize shouldn't make programs go 10x slower :(
<vila> Hopefully it doesn't disable the C extensions...
<spiv> vila: on that count at least we ought to be safe.
<vila> Is it conceivable to set -O from a running python script without spawning a new interpreter ? ....
<twb> OK, after changing that to standard, optimize, and dpkg-reconfigure bzr bzrtools, I get 0.6s or 0.4s without plugins
<twb> And with python -O it's 0.056s for both
<vila> twb: more in line with hg then ?
<twb> Yeah, thanks
<vila> twb: would you mind filing a bug for that ?
<vila> urgh, a raw 'bzr' tracebacks
<vila> hmm, bad wikkid
<twb> vila: against what, though?
<twb> Last time I looked, the debian maintainers basically said "don't change /etc/python/debian_config or we will ignore you"
<vila> err, you lost me here, do you mean the bug is triggered because you modify /etc/python/debian_config; ?
<twb> vila: yes, I think so
<twb> IIUC I accidentally said "make .pyo but not .pyc" when I should've said "make .pyo AND .pyc"
<spiv> Right.
<twb> And a more or less separate bug is that python programs in Debian ignore .pyo files
<vila> twb: then file it at https://bugs.launchpad.net/bzr/+filebug and we'll see from there
<vila> twb: I don't have such a setup but hopefully someone will be able to reproduce
<vila> twb: and if nothing else, it will document your workaround
<spiv> vila: it's a packaging issue, really, filing it against Debian is probably more appropriate
<twb> spiv: so anyway, what I'm gonna do now is sudo sed -i '1s/^#!.*python$/& -O/' /usr/bin/* ;-)
<vila> spiv: unless it's immediately triaged as WontFix as twb hinted
<bialix> heya
<spiv> twb: *shudder* :)
<twb> Well, if it increases bzr's speed tenfold, it'll probably increase other stuff
 * bialix waves hello at GaryvdM
<GaryvdM> Hi bialix
<vila> twb: I won't bet the increase will apply to every command...
<bialix> thank you for new installer
<spiv> twb: well, I'd expect optimised bytecode to have minimal impact on bzr over unoptimised.
<GaryvdM> bialix: Does it fix the bug? Did not seam to work for me.
<bialix> bug with russian characters? yes!!!
<twb> spiv: it was 0.6 vs. 0.05
<twb> spiv: for --help, anyway
<spiv> twb: Strange.  I don't see that here.  I see basically no difference.
<bialix> GaryvdM: I suspect you should test with accented characters instead of russian ones for your system
<twb> spiv: did you make .pyo's for all your libraries and stuff?
<spiv> twb: to be clear, I mean where the bytecode is precached for both cases (i.e. with .pyc and .pyo files)
<spiv> twb: right
<bialix> GaryvdM: I'm going to test PyQt 4.5.2 which I have in my archives re bug with frozen child window
<GaryvdM> bialix: ok
<bialix> GaryvdM: is there specific reasons for us to use the latest PyQt?
<bialix> at least on windows
<spiv> twb: forcing Python to recompile the bytecode every invocation is certainly going to hurt a lot, but at least for bzr the practical benefit of the -O optimisations should be negligible
<twb> OK, I remeasured it and I can't see the difference anymore
<twb> (pyo vs pyc)
<spiv> -O is very, very mild in what it does.
<GaryvdM> bialix: I was hoping to be able some new features. Does 4.5.2 support QVarent.toPyObject
<spiv> There's also -OO, which possibly would help bzr a little bit if only by reducing the size of the bytecode to load by omitting most docstrings.
<bialix> GaryvdM: I dunno
<GaryvdM> *to be able to *use* some new features
<bialix> yep, I understood
<spiv> It's a nasty trap to have /etc/python/debian_config contain such an attractive option that actually means "please break me" :(
<fullermd> Eh, it's just like a lava pit in Quake.  Just there to see if you're paying attention.
<bialix> GaryvdM: about new features: IIRC we discussed this at UDS and decided to not break backward compatibility in 0.19; and 0.19 is our bzr 2.2 companion, right?
<GaryvdM> bialix: Yes
<bialix> I don't mind to change required PyQt for 0.20
<bialix> GaryvdM: 4.5.2 works ok
 * bialix re-testing with 4.7.2
 * bialix wants qabout dialog as in Explorer to easily see the versions of used PyQt/Qt
<bialix> GaryvdM: 4.7.2 is buggy.
<bialix> GaryvdM: can we downgrade to 4.5.2? please? pretty pretty please?
<GaryvdM> bialix: Ok - I'm busy building my own build host. If I get that to work, I'll do that. Else we are going to have to ask jam to do it for us.
<GaryvdM> bialix: Please will you put the 4.5.2 installer somewhere I can download it.
<bialix> bialix.com will be OK for you?
<GaryvdM> That's cool
 * bialix is uploading, installer is 17MB big
<vila> GaryvdM: Can I ask you to document every single step so anybody can reproduce ?
<GaryvdM> vila: I'm following jam document
<vila> GaryvdM: then update and complete ;)
<GaryvdM> bzr.dev/doc/developers/win32_build_setup.txt
<bialix> oh, that will be awesome
<GaryvdM> vila: sure. I've chosen to use msys rather than cygwin
<vila> GaryvdM: great, any chance you're doing that in a fresh VM ?
<GaryvdM> vila: So if that works, I'll note that.
<bialix> GaryvdM: http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe + http://bialix.com/python/PyQt-Py2.6-gpl-4.5.2-1.exe.asc (gpg signature)
<GaryvdM> vila: I am
<GaryvdM> bialix: Thanks
<bialix> when I will have a free week or so, I will try to re-create my build environment without cygwin/msys. Heh
<vila> GaryvdM: Woohoo ! Make copies ! Argh, no, windows licenses :-(
<vila> GaryvdM: anyway, make copies for you so you can restart from a clean state if needed
 * bialix is trying PyQt 4.7.6 now
<bialix> riverbank guys even don't have RSS for their news %( in which age they're living?
<bialix> 4.7.6 -> nope, the same
 * bialix bbl
<fullermd> Still no bzrtools for 2.2?   :(
<poolie> fullermd: does anything fail or does it just need a release?
<fullermd> I'm not aware of anything failing, which doesn't mean much since I don't use much of anything from it.
<fullermd> Though I'd offhand assume enough people use both stuff from it and have upgraded to 2.2 by now that we'd have heard about any major breakages.
<maxb> erm, huh. If there's no bzrtools for 2.2, how do we have one in the PPA?
<Ddorda> hey guys, how do i clean modifications i did on a branch?
<Ddorda> i mean locally changes
<maxb> fullermd: It's been tagged, apparently
<maxb> Ddorda: bzr revert
<Ddorda> maxb: awesome thanks
<MacSlow> Greetings
<MacSlow> Can someone tell me what happended to olive (of bzr-gtk)?
<MacSlow> it doesn't seem to be installed with it anymore.
<vila> MacSlow: is has been split off bzr-gtk
<MacSlow> so there's no more stand-alone way to start it?
<MacSlow> only bzr visualise?
<vila> MacSlow: it's now at lp:olive
<MacSlow> vila, ok thanks
<vila> MacSlow: much of the activity around stand-alone GUI for bzr is around lp:bzr-explorer
<vila> MacSlow: which use qbzr mainly (even if on eof its early goals was to remain toolkit agnostic so in theory it could also use a bzr-gtk back-end)
<vila> s/on eof/one of/ funny typo
<maxb> abentley: Hi, will you be releasing a bzrtools 2.2.0 tarball?
<mangojambo> Hi, where do I report a small bug ?
<mgz> bug 633180 is funny.
<ubot5> Launchpad bug 633180 in Bazaar "applet crashes on commit (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/633180
<git__> hi
<git__> how well does bzr do with image versioning?
<nDuff> I vaguely recall y'all having some shiny, shiny toolage analyzing Bazaar's performance over time (and isolating specific changesets where performance regressions occurred). Not having much luck googling it, though -- is that all in my head?
<jml> nDuff, bzr-usertest
<nDuff> jml, ahh -- thanks!
<ddaa> I noticed that bzr-git does not support push
<ddaa> but a look at the code suggests that it does support commit-to-git with roundtripping.
<ddaa> Meaning, a commit done directly on checkout based on a git foreign branch will store all the good metadata, but that feature is missing from push.
<jelmer> ddaa: it supports push, too
<ddaa> I am wondering, maybe "rebase" or "replay" can be used to produce essentially the same effect as push.
<jelmer> ddaa: Just that roundtripping is still disabled at the moment.
<ddaa> jelmer: obviously, it supports dpush
<ddaa> what do you mean "the roundtripping is disabled"?
<jelmer> ddaa: I'd like to make sure that we have a stable format before enabling roundtripping.
<jelmer> ddaa: There are two mapping formats - 'v1' which doesn't support roundtripping and 'experimental', which does. v1 is the default.
<ddaa> Oh.
<ddaa> Any idea when experimental will become v2 and v2 becomes the default?
<jelmer> when I finish my work to make the bzrlib testsuite run against foreign formats
<ddaa> So, if I understand correctly, commit on git foreign checkout currently does not work?
<jelmer> ddaa: It's got some issues - for example it won't use what's in the working tree but what's in the index.
<ddaa> Oh, that's interesting.
<jelmer> ddaa: and I don't think it will use the revision id that's specified by the caller of WorkingTree.commit, if any.
<ddaa> That's actually not what I meant though :-)
<jelmer> ddaa: Sorry
<ddaa> I meant commit on a bzr branch bound to a git branch, or commit to a bzr lightweight checkout of a git branch.
<jelmer> ddaa: I doubt that commit on a git foreign checkout will work; on a non-bound branch it might.
<ddaa> Gotcha.
<jelmer> commit to a lightweight branch *might* work
<jelmer> uhm, lightweight checkout
<ddaa> Once roundtripping is enable, that will all magically work, right?
<jelmer> in theory, yep
<jelmer> there will probably be minor things to fix up
<glyph> does the bot here pipe up about bzr-svn bugs as well?
<glyph> well, assuming it doesn't
<jelmer> glyph: I don't think it tells us about bzr bugs either :-)
<glyph> https://bugs.launchpad.net/bzr-svn/+bug/633522
<ubot5> Launchpad bug 633522 in Bazaar Subversion Plugin "annotation fails on calendarserver trunk (affected: 1, heat: 6)" [Undecided,New]
<glyph> dash: you broke the internet :(
<dash> glyph: oh noooo
 * jelmer fires off a clone of calendarserver
<glyph> jelmer: please be kind, use a shared repo :)
<dash> glyph: what, you guys don't have a giant svn server farm over there?
<dash> ;)
<glyph> dash: uh yeah, "us guys", sure
<glyph> I think you are closer to the "cloud" than me :-P
<dash> true
<glyph> I'm sure there are ... servers
<glyph> I just don't want to get the bill for all of them because all 111 people in #bzr decide to clone it from scratch :)
<jelmer> glyph: If only a bug report would immediately get the attention of 111 developers...
<glyph> jelmer: if only!
<glyph> thanks for looking at it
<glyph> can you repro?
<jelmer> glyph: nope
<jelmer> glyph: The branch that you're working in, did it or its repo exist before you switched to bzr-svn 1.0.4 ?
<glyph> jelmer: I guess it probably did.
<glyph> If I locally clone into a new repo, will I work around it, or do I need to do a fresh clone from the server?
<jelmer> glyph: I suspect one of the older versions of bzr-svn that you used probably introduced broken data
<glyph> and do I need to blow away my svn cache
<jelmer> glyph: A local clone will just copy the broken data, so you'd need a fresh one from the svn server.
<jelmer> I don't think the cache would be affected but it's quite quick to regenerate so I would recommend blowing it away.
<dash> glyph: a lot of times i've had odd issues with bzr-svn on 'pull' or 'up' that have gone away if i do a fresh pull from the svn server into a different branch, then in the afflicted branch do a pull from the fresh one
<jelmer> dash: can you still reproduce that sort of thing with 1.0. 4?
<dash> jelmer: i haven't yet, IIRC
<dash> jelmer: if i do, i will let you know. :)
<jelmer> dash: thanks
<glyph> dash: OK, I'll try that first, I guess :)
<glyph> sooo slow :(
<mgz> hm, if I want to do a cosmetic edit to someone else's branch before merging it with hydrazine, is there a way? or would that have to be a whole new mp?
<jelmer> mgz: I think that would have to be a whole new MP
<mgz> argh, and bugger, I can't merge to 2.2
<jelmer> at least, I can't think of a way around that..
 * glyph discovers hydrazine and becomes excited
<glyph> is there a bug-reporting GUI?
<mgz> ...I struggle to envision how that would improve on a web browser
<mgz> generally people want bug reporting clis
<jelmer> glyph: I think bughugger is a GUI for bugs (among other things) on Launchpad
<glyph> screenshots plz
<jelmer> heh, I don't use it.. but I'm sure Google can help.
<dash> http://www.murraytwins.com/blog/?p=60
<dash> eeenteresting
<glyph> jelmer: qannotate works on a fresh pull
<glyph> erm, annotate, too ;)
<jelmer> great (-:
<glyph> pulling the fresh pull into my existing repo blows up with a different traceback though
<jelmer> so that would've been a bug in an older version of bzr-svn that's since been fixed
<glyph> I've saved the broken branch (branching it produces the same error) in case you're interested in me pushing it somewhere later
<jelmer> glyph: yes, that's to be expected tas your existing repo has some broken data
<glyph> gotta run now
<jelmer> glyph: I would recommend cloning your existing branches into the new repo and getting rid of the old one
<jelmer> I'm not really interested in the broken repo - the fact you've just successfully used annotate means this is an old bug.
<jelmer> 'morning mwhudson
<mwhudson> hi jelmer
<mwhudson> jelmer: btw, is importing from a local git repo known to be broken in bzr-git currently?
<jelmer> mwhudson: it was earlier, perhaps I forgot to push my fixes
<mwhudson> jelmer: i think that might be the case
<mwhudson> (i did this a couple of days ago, but i don't think i've seen any lp:bzr-git changes since)
<jelmer> I'll check
<jelmer> it reminds me...
<jelmer> https://dev.launchpad.net/FailingBzrSvnImports, https://dev.launchpad.net/FailingBzrGitImports
<jelmer> with much thanks to maxb
<mwhudson> nice
<mwhudson> 1.0.4 will be deployed tomorrow, right?
<jelmer> yep
<mwhudson> a few to retry then
<mwhudson> https://dev.launchpad.net/FailingBzrGitImports#Nested%20trees is a bit uh, well....
<ddaa> when 2.3 is out, someone will have the joy to update cscvs to deal with those too :-)
<ddaa> Or maybe not...
<mwhudson> ddaa: weeeeeeeeeeeeeeeeeeeeeeeeeeeeellllllllllllllllllllllllllll
<ddaa> is that the sound of you falling in one?
<jelmer> ddaa: nested trees in CVS? Do I want to know?
<ddaa> module references
<jelmer> aha
<ddaa> historically, the policy was "just ignore those, only import the root module"
<ddaa> conceptually, it's not very tricky
<ddaa> I think svn externals are worse, with their ability to refer to branches in other repositories
<mwhudson> ddaa: oh right
<mwhudson> ddaa: well, actually the current policy is "just ignore those, only import the root module, then blow up doing the validation cross check at the end"
<ddaa> oh right :-)
<jelmer> ddaa: the main issue with svn externals is that they can create implicit directories
<ddaa> I remember the motivation for not fixing this one was that anyway, cvs repos using those are essentially useless without the module references.
<mwhudson> ddaa: it's CVS's fault really, if you do cvs co compound-module, the CVS/Root file (i think it's that one) only references the root module
<ddaa> jelmer: that sounds like an instance of "I can't decide whether it's a branch or a directory"
<mwhudson> "conceivably versions something" indeed
<ddaa> mwhudson: right, I guess fixing that would have involved touching the graph magic lifeless put there once, and that I was never able to make sense of.
<mwhudson> fortunately the day when one can just ignore cvs is getting closer
<bialix> mgz: around?
<mgz> yo bialix
<bialix> yo martin
<bialix> are you using hydrazine to send merge requests?
<mgz> I am, want a tutorial?
<ddaa> mwhudson: btw, I was a bit amused at noticing the import failure at ~vcs-imports/cvs/trunk
<ddaa> also, lp REALLY needs a new icon for ~vcs-imports
 * mwhudson hadn't seen that one
<ddaa> not only my artwork sucks, but it does not make sense anymore
<bialix> mgz: no, just a confirmation you're using it from windows machine and it's possible to install it for mere mortals
<ddaa> it dates back to the time this was called ~buttress
<bialix> lol
<mgz> yup, about the only windows-hostile thing I've run into is the script you want to run doesn't have '.py' on the end
<bialix> oh
<bialix> then
<mgz> launchpadlib does mean having to deal with setuptools, but that's a pain everywhere
<bialix> [01:20]	<mgz>	I am, want a tutorial?  --- YES!!!
<mgz> and there's 2.5ism in one of the many launchpadlib dependencies that I put a mp up to fix some months ago and have heard nothing about, so still have to patch locally
<bialix> because you prefer py2.4, as I remember
<bialix> that's ok
<bialix> so, can I have a cookie, err, short tutorial how you install it?
 * fullermd ships bialix a cookie.
<bialix> *crunch* *crunch* yummy!
<mgz> bialix: something like http://paste.ubuntu.com/490588/
<mgz> and... I misplaced an apostrophe again
<bialix> mgz: yummy, awesome, thanks!
<mgz> yell if I got anything wrong there or you run into anything else, I might polish this up and post somewhere
 * ddaa refrains from making a bad jokes involving poles and ukrainians
<bialix> ddaa: :-P
<bialix> I think I know this joke
<ddaa> that would not be "spiritual" :-P
<bialix> please, don't
<ddaa> tell me about it!
<bialix> in Ukraine we're usually telling jokes about unkrainians and russians
<ddaa> next time you see sabdfl, ask him about that Baikonour launch operator he saw the day before he took off :-)
<bialix> I'll note
<bialix> at uds I was too shy to talk with him
<ddaa> you're not alone there, but it's all in your head. He's remarkably level headed.
<ddaa> Actually, I find that somewhat disturbing.
<jelmer> n
<jelmer> n
<jelmer> grr, wrong window has focus
<poolie> good morning
<fullermd> jelmer: No, it's n w.
 * bialix waves hello at poolie
#bzr 2010-09-09
<poolie> hello bialix
<bialix> poolie: do you have any specific plans for 2.2.1?
<bialix> I mean a more or less precise date
<bialix> because I need to release qbzr 0.19.1
<poolie> let's see
<poolie> the actual freeze date for 2.2.0 is over a month ago now
<poolie> we could do it pretty soon
<poolie> when do you want to do 0.19.1? sooner, or later?
<jelmer> 'morning poolie
<poolie> hi there
<poolie> i wonder what's in the 2.2 branch now?
<bialix> poolie: I want to have 0.19.1 sooner or in time with 2.2, so GaryvdM can bundle it into installer
<poolie> could you do it early next week and then we'll do 2.2.1 after that?
<bialix> I'll do it this weekend then
<poolie> my fixes for add are in there, plus some smaller fixes
<poolie> and they had quite a few dupes and would be worth getting out=
<bialix> ok
 * bialix eods
<poolie> bye
<poolie> gz, bialix, i'll resubmit the setlocale patch
<poolie> oh apparently jam sent it, and it's working through pqm
<mgz> poolie: what would a fixture for thread leaking entail? for the moment I've kept it all as-is but moved it to the test result (...and then poked various other unrelated things nearby that I probably should have filed seperate bugs on but kept breaking stuff)
<poolie> basically just moving everything in to a self contained object that's notified when the test starts and finishes
<mgz> I think this is pretty low-overhead though, and having to enable it per-testcase will probably mean we miss tests that aren't obviously using threads
<poolie> i don't know if that's enough
<poolie> it could be confined to a fixture even if the base bzr testcase always starts it
<poolie> ie you don't need to do it per case
<mgz> I'll wham what I've done up in a mp as it might be easier to discuss there
<mgz> bah, this is so going to conflict with my other branch, should have thought of that
<poolie> hi spiv
<spiv> hi poolie
<spiv> There's a regression in 2.2 I'm filing now that I'd like to have fixed in 2.2.1
<poolie> oh ok, thanks for filing it
<spiv> bzr+ssh:// to pre-1.6 bzr smart servers fails :(
<spiv> poolie: https://bugs.edge.launchpad.net/bzr/+bug/633745 is the bug, btw
<ubot5`> Launchpad bug 633745 in Bazaar "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 6)" [Critical,Confirmed]
<lifeless> is that related to the spam we're getting from crontab I wonder?
<poolie> thanks-
<poolie> almost not critical, but worth fixing
<spiv> It's pretty shallow, but it's disappointing that hpss to pre-1.6 servers was broken in 2.2, after we had a different bug breaking it in 2.1.
<spiv> Oh, I forgot, I have a plugin users can install as a workaround (this bug originally came up IRC yesterday)
<spiv> lifeless: yes, I expect my fix will assist with some noise from various scripts, not sure if it's the spam you're specifically thinking of...
<lifeless> something about ssh and NoneTypes ;P
<spiv> Probably the same, then :)
<lifeless> please for the love of puppies fix it.
<lifeless> its driving crontab mail for lp nuts ;)
<spiv> lifeless: it seems the love of puppies isn't enough to inspire a bug report, though?
<lifeless> spiv: pretty sure someone was doing one
<lifeless> spiv: I didn't file one myself because of that
<spiv> lifeless: yeah, I thought there would be too, but a few searches didn't find any.
<lifeless> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://lifeless@bazaar.launchpad.net/)> ignored
<lifeless> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x24490c8> ignored
<lifeless> is what I see
<lifeless> that case is ec2land, but it looks very similar in cron mails
<spiv> Yeah, that's the bug.  Until this manifestation I didn't know it was more harmful than occasional noise on stderr.
 * spiv -> lunch
<lucidfox> Is there an equivalent of git merge --squash? I.e. merging several subsequent commits from a different branch into one?
<dash> that's what merges _are_ :)
<dash> so yes, 'bzr merge'
<spiv> Well, if you really want to act like --squash, I think you'd also need to do 'bzr revert --forget-merges' after 'bzr merge'.
<spiv> But I may be skimming the git docs too hastily.
<lucidfox> Wait, then how do I do a merge the way git merge works - preserving commit history from the other branch?
<spiv> That's just 'bzr merge'.
<spiv> IIRC, 'git merge' with no args is roughly like 'bzr merge --pull && bzr commit'
<spiv> Or if you prefer, 'bzr merge' with no args is roughly like 'git merge --no-commit --no-ff'.
<lucidfox> That's great :)
<lucidfox> So far I've actually found bzr having fewer gotchas and obscure corner cases than git
<lucidfox> and more intuitive overall
<spiv> That's what we're aiming for :)
<FryGuy-> i think it's only confusing for people that deeply understand git, and can't see why anyone would want to do it differently
<lucidfox> heh
<lucidfox> Well, it has saner defaults
<FryGuy-> i really like bazaar's "a branch is a path" over the whole repository thing git has.. having two semanticly different things that you have to deal with confuses me a lot
<FryGuy-> that too
<lucidfox> I actually miss parallel instantly switchable branches
<FryGuy-> i have that
<FryGuy-> it's not intuitive how to get it in bazaar though
<FryGuy-> you can have a path for your working folder be a checkout of a branch, and then bzr switch between branches
<spiv> lucidfox: I'm sure someone in here can walk you through how to set that up in bzr; short description is 'have a lightweight checkout that you bzr switch between (treeless) branches'
<FryGuy-> and you can do things like bzr qlog \dev\branches\*
<poolie> ok so after all that distraction i'm going back to prompting to break locks
<vila> hi all !
<fullermd> Eek!  ETOOMUCHENTHUSIASMINTHEMORNING
<vila> fullermd: lol, catch e: drink more coffee
<vila> enthusiasm is good, can't live without it.
<lifeless> sure you can :P
<lifeless> ^- not enthusiasm :)
<vila> well I can... but...
<lifeless> :>
<fullermd> Coffee doesn't add to enthusiasm.
<vila> the sky isn't always blue nor the sun shining, better rely on inside resources :)
<poolie> vila how hard do you think it would be to write textuifactory tests against a scriptrunner?
<vila> fullermd: being awake helps finding it back :-P
<fullermd> Kinda the opposite, actually.  It makes me more alert, so I better understand the !#&$*%@ my clients try to say, which makes me less enthusiastic about anything other than mass murder...
<fullermd> But then, you can't spell "slaughter" without "laughter", so I guess it's not entirely unrelated.
<vila> poolie: use '<' ? Oh no, you mean hooking a textuifactory into stdin ?
<poolie> mm, hooking up the streams
<poolie> probably not too hard?
<vila> yup, if it's not, that's a bug
<vila> fullermd: see ? Laughing is good, always. Do you think DEATH don't laugh at you ?
 * vila shamefully recycles a Desproges's joke :)
<vila> err, shamelessly ?
<poolie> yes
<vila> if I start typoing shamefully as a portementeau between shame and fullermd where will I end...
<fullermd> Mississippi, apparently.  So try to avoid it  :p
<poolie> vila will it cope with input or output that's not a full line?
<poolie> eg i want a script like
<poolie> Break lock?
<poolie> < y
<vila> poolie: no idea, but your input will likely includes a new line. But char-based input... is tricky
<poolie> that's ok, i don't need sub-line input
<poolie> just for it to cope somehow with an output bit with no trailing \n
<poolie> i might try it
<vila> poolie: c.f. shelve input handling requires setup under emacs for example
<vila> poolie: but I don't think textuifactory *allows* char-based input
<poolie> to tell emacs to send it single keystrokes not lines
<vila> shelve use a dedicated method for that (~90% sure)
<vila> poolie: no, fully different subprocess handling
<vila> I set it up once but it was... sub-optimal, so I'm back to 'shelve --all' only
<poolie> :/
<poolie> iwbn for it to detect stdin couldn't do single characters, and then read lines
<poolie> isn't there M-x terminal or something like that, that should send single chars?
<poolie> oh maybe that's what you mean
<vila> don't remember the exact mode, but yes, one that doesn't consider stdin to be line-based like the venerable shell-mode
<vila> I think that's why I revert, not everything I needed was supported there or the interactions was too much different
* spm changed the topic of #bzr to: Launchpad down/read-only from 0800-1100 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out
<vila> poolie: another way to fix the problem will be to have shelve use a uifactory that could be configured to requires that any input includes a <return>
<poolie> that's what i meant
<vila> oh, that would be really sweet ;)
<poolie> if $TERM=emacs, or something a bit smarter
<poolie> oh, again :/
* poolie changed the topic of #bzr to: Launchpad down/read-only from 0800-1100 UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/
<poolie> vila what do you think of something like http://paste.ubuntu.com/490797/
<bialix> hey vila, poolie, and all all all
<spiv> poolie: nice /topic update :)
<poolie> thanks
<bialix> vila: as you work on conflicts again, I would like to ask: is it worth to extend auto-resolve logic to check whether conflicted path still exists, especially when conflict about inability to delete some dir and if there is no such path anymore just mark conflict as resolved?
<poolie> :) i think that's exactly what he was just oding
<poolie> *doing
<vila> poolie: x and y or z hurts
<vila> bialix: yes
<poolie> oh, true
<bialix> I thought vila working on moving garbage to the trash can
<lucidfox> "Launchpad will be going offline for maintenance in ten minutes." <--- nnnooooo!
<poolie> i don't normally use it but in that context it's ok
<bialix> (joke)
<poolie> i know
<vila> bialix: that's related :)
<bialix> ok, then
<vila> http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution for a broader view
<vila> bialix: moving unversioned files to bzr-orphans dir get rid of some conflicts so they don't even have to be resolved
<bialix> I think my thought is related but has its own benefits
<vila> bialix: this also avoid requiring a disctinction between precious and junk files by *not* deleting them
<vila> bialix: see the wiki above, orphaning is a simpler first step
<bialix> and may help to fix bug 628561
<ubot5`> Launchpad bug 628561 in Bazaar Explorer "delete should move files to the trash (affected: 2, heat: 16)" [Low,Confirmed] https://launchpad.net/bugs/628561
 * bialix looks
<vila> bialix: bug #628561 is yet another variation, the patch I'm working on requires the orphan dir to part of the working tree so far,
<ubot5`> Launchpad bug 628561 in Bazaar Explorer "delete should move files to the trash (affected: 2, heat: 16)" [Low,Confirmed] https://launchpad.net/bugs/628561
<vila> bialix: I have some ideas about how to allow it to be *outside* of the working tree but it requires more work (basically requiring it to be inside the wt guarantees that we rely on TreeTransform including rollbacks)
<bialix> yes, because system trash can is very system dependent, I can use your orphan dir as poor man emulation
<poolie> ok https://code.edge.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 posted, with the same diff
<vila> poolie: isn't it a good place to start implemeting a simple fixture
<poolie> interesting
<vila> bah, I should comment on the mp instead
 * bialix waves at GaryvdM
<poolie> for what? the test ui factory?
<poolie> hi gary
<poolie> ok, i'm off to take an umbrella to stephane at her office :)
<GaryvdM> Hi all
<vila> poolie: make_test_ui_factory
<poolie> vila, it may be
<vila> poolie: you've seen my PM ???
<poolie> i don't know if it would add much when no cleanup is needed
 * GaryvdM has been lurking...
<vila> poolie: well, it's even more interesting when no cleanup is needed since you don't tie the fixture to the test class
<vila> or something
<vila> and the other end, make_test_ui_factory not accepting parameters for stdout and stderr while not hinting about it in its name also itches a bit
<poolie> well, it was only a tiny change
<bialix> GaryvdM: any success with your own build host?
<vila> yeah, no problem, and they can be added later and using a test method also allows for simpler implementations, just mentioning
<vila> GaryvdM: tell us yes :)
<vila> poolie: I think my point is more: hey, this goes in the right direction for fixtures, way to go !
 * poolie feels better now :)
<poolie> i think tearing bits of test base classes into fixtures would be nice too
<GaryvdM> bialix: I got stuck where it can't find htmlhelp. I've fix this before on the ec2 server, so this time I'll make sure to document what I did :-p
<vila> yup. defining such test methods is waaaay better than duplicating their content all over the place
<bialix> GaryvdM: yep
<GaryvdM> I was very tired last night, so I did not try to hard.
<vila> GaryvdM: way to go (Did I just said that earlier ?)
<spiv> Ok, I think I'm done for the day.  See you tomorrow!
<vila> spiv: cu
<vila> ARGH, lp down... iwbn to be able to setup a bzr branch to fallback to a local mirror for ready-only ops...
<vila> like in being able to handle 'bzr diff -rsubmit:' without tweaking branch.conf
 * vila goes filing a bug on .... idiot
<voidspace> so I have a locations.conf in ~/.bzr
<voidspace> should that be ~/.bazaar?
<GaryvdM> voidspace: Yes
<voidspace> thanks
<vila> that makes two questions the same day that could be answered by 'bzr config' or something...
<vila> voidspace: the closest today is 'bzr version' which mentions 'Bazaar configuration'
<voidspace> vila: thanks
<mgz> hey all.
<GaryvdM> Hi mgz
<vila> mgz: hey !
<vila> mgz: reviewing lp:~gz/bzr/selftest_leaked_threads_measuring_633462 is high on my TODO list, many thanks for working on that, I wasn't finding the time myself and that was frustrating
<mgz> I ended up touching more stuff than I intended to, and thought of a way of doing less moving around of code before I fell asleep last night
<mgz> but as I'm on a selftest bent I thought I go through and try and knock off all the stuff that has been annoying me for a while
<mgz> something like ~10 bugs... how fast can I squish 'me
<mgz> *em
<vila> mgz: try using a loom for that so you can more easily make several submissions
<mgz> I was using shelve, but the fix broke some unrelated tests that were doing slightly dodgy things, and can't submit a mp with failing tests... it spiralled a little just when I was trying to get to bed
<vila> I know the feeling :-/
<maxb> Is anyone out there running < lucid any more, who could volunteer to test bzr-svn in the proposed ppa/
<maxb> ?
<Glenjamin> Hi guys, is there any way to force a bzr+https URL to use urllib instead of pycurl?
<Glenjamin> The certificate is invalid on the server, but i know its fine.
<bialix> try urllib+bzr+https
<vila> bzr+https+urllib ?
<bialix> vila knows better
<vila> bialix: you were right, but order matters
<bialix> ok
<vila> Glenjamin: are you sure you bzr+ in front ? (I don't remember if all combinations are registered)
<vila> Glenjamin: are you sure you need bzr+ in front ? (I don't remember if all combinations are registered)
<vila> Glenjamin: we probe for a smart server anyway so this shouldn't be required
<Glenjamin> it's a writable smart server over https
<Glenjamin> ah
<vila> Glenjamin: in fact there is a nosmart+ prefix to *disable* this probe
<Glenjamin> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<vila> httpS
<Glenjamin> bzr push https+urllib://url
<vila> or is this error message generic ? Ha, seems so
<vila> ok, try bzr+https+urllib then
<Glenjamin> not registered
<GaryvdM> maxb: I have a hardy vm. But I'll only be able to look tommorrow.
<Glenjamin> is there any way to disable pycurl, or make SSL exceptions? I found a couple of bugs on LP, but they seem to be old
<vila> Glenjamin: there are several that relates to that, old, yes, lack of time :-/
<Glenjamin> i'll just turn on http until i get the cert sorted i guess
<vila> Glenjamin: there is something weird in your server config that makes the probe fails maybe, to you have a .bzr.log handy ?
<vila> Glenjamin: I was 99% sure we didn't need to register bzr+https+urllib since urllib is already the default, let me check
<vila> Glenjamin: argh, yes, urllib is the default for http but pycurl is still the default for https
<vila> Glenjamin: the idea is that since some people relies on ssl certificate verifications we can't disable it by default
<vila> Glenjamin: there is more than one client involved right ?
<Glenjamin> there will be, yes
<vila> Glenjamin: the best I can offer then is  plugin, but it should be installed on all clients... and uninstalled once you fix your certificate :-/
<Glenjamin> yeah, i'm planning to put a plugin on anyway for a shortened url scheme
<Glenjamin> but normally i'd have the plugin in the repo and have users use the full URL once to get the plugin
<vila> Glenjamin: lp:~vila/+junk/defaultToUrllib a bit dusty, but still working without any updates for... OMG, I never committed it :)
<vila> Glenjamin: just a sec :)
<vila> last modification date is 2008-01-22 16:25...
<Glenjamin> i've just allowed bzr+http access for now
<Glenjamin> i think we've got a cert for this domain somewhere
<vila> Glenjamin: which means your passwords are in the clear then (if you use Basic)
<Glenjamin> its on the same subnet, it'll do for the next few days
<vila> Glenjamin: ok, np with me :)
<vila> Glenjamin: I didn't hear anything anyway, I wasn't even there
<vila> Glenjamin: ok, lp:~vila/+junk/defaultToUrllib is now up-to-date, feel free to copy/paste in your own plugin if you have some deployment policy for it
<Glenjamin> i'm now getting ('error', "'module' object has no attribute 'ElementTree' back from the server =/
<Glenjamin> i'm fairly sure it was working before
<vila> Glenjamin: this rings a bell, 'bzr version' on the server ?
<vila> I'm pretty sure we've fixed something there quite recently, mgz ?
<mgz> yeah, get the latest bzr-xmloutput plugin
<mgz> or... is that the same error? no, something else.
<Glenjamin> 2.1.1
<mgz> can you get the full traceback from the .bzr.log on the server?
<Glenjamin> i can, once i figure out how to get the wsgi app to log :)
<vila> 2.1.1... meh, when did your related modification landed mgz ?
<vila> Glenjamin: and on the client ?
<Glenjamin> client: http://pastebin.com/MCXszMBS
<vila> hmm, bzr-xml-output shouldn't be involved there, this is happening in the server, we need its log :-/
<vila> Glenjamin: well, we need the traceback, it should be in the log, but if you find it elsewhere, that's good enough :-/
<vila> Glenjamin: and that's cetainly worth filing a bug
<vila> Glenjamin: ...unless you have some hooks installed on the server that could involve xmloutput ?
<Glenjamin> vila: the server doesn't even have xmloutput =/
<vila> Glenjamin: good, one less possible cause
<vila> Glenjamin: the weird thing is, I'm pretty sure mgz related change occured only on trunk, not in 2.1 nor 2.2
<Glenjamin> managed to get the server log
<Glenjamin> http://pastebin.com/3gT0Za2B
<Glenjamin> the wsgi make_app tries to access stdin/out which mod_wsgi doens't allow
<Glenjamin> ah, it seems to be exactly https://bugs.launchpad.net/bzr/+bug/254278
<ubot5`> Launchpad bug 254278 in Bazaar "module object has no attribute ElementTree (affected: 2, heat: 7)" [Low,In progress]
<vila> Glenjamin: https://code.edge.launchpad.net/~gz/bzr/remove_monkey_patched_elementtree_escaping_614522/+merge/34028 may be relevant too
<Glenjamin> is that in 2.2?
<vila> Glenjamin: I don't think so, checking... no
<Glenjamin> i'll monkeypatch the server then, ta
<vila> Glenjamin: can you comment on bug #254278 ? With your bzr version and the log, this probably will be just a backport of the above fix but I can't investigate precisely right now
<ubot5`> Launchpad bug 254278 in Bazaar "module object has no attribute ElementTree (affected: 2, heat: 12)" [Low,Confirmed] https://launchpad.net/bugs/254278
<vila> Glenjamin: oh, if you path your bzr on the server, say so in the bug then !
<vila> Glenjamin: oh, if you apply the patch to bzr on your server, give some feedback  in the bug too !
<Glenjamin> done, thanks for the help :)
<vila> Glenjamin: perfect
<vila> Glenjamin: thanks to you, knowing that the fix works is a good part of the... work :)
<mgz> ah, so I actually fixed his bug, rather than creating it?
<mgz> woho!
<vila> mgz: yeah :) All you have to do now, is 1) fire an mp for backporting it to 2.1, 2) assign the bug to yourself..... 4) profit ! ;)
<mgz> I'd better just check a profile under 2.1 as well to make sure it's not using the hack majorly either
<mgz> :)
<vila> NOOOOO, ff lost my review :(
<Glenjamin> oh, out of interest - what workflow do you guys use for conflict resolution?
<fullermd> I like to use physical intimidation and loud profanity, myself.
 * bialix is second here
<mgz> okay, Toshio's post in that bug is the only thing that could make sense, but I can't repo the problem here so there might also be some wdgi import issue going on
<mgz> Glenjamin: could you get your wsgi script to give you the module path to bzrlib.xml_serializer.elementtree please?
<mgz> ...with conflicts I just generally search through for >>> and double check the diff after resolve, but don't take that as best way
<dash> smerge-mode in emacs is nice.
<CcxCZ> vimdiff is also nice
<vila> smerge-mode is emacs is nice
<vila> Glenjamin: but what do you mean by workflow here ? The way we resolve the conflicts (including the tree-shape ones) or something more high-level ?
<tedg> Uhm, I got an error that I have no clue on:
<tedg> bzr: ERROR: An inconsistent delta was supplied involving u'/COPYING', 'copying-20100507105513-ntbj8bqjbsjpuvq7-1'
<tedg> reason: Attempt to add item at path already occupied by id 'copying-20100505091350-s6ph8iovvrnhwpp9-17'
<tedg> Can someone translate that for me please?
<vila> bialix, Gary (offline :-/): where is qbzr today on this topic (conflict resolution) ?
<vila> tedg: -Derror will give a backtrace
<tedg> vila, Okay.  I have a backtrace, but that doesn't tell me much.
 * vila fires qblame
<vila> tedg: that's from revno 4553 by lifeless, the comment says: Add checks for inventory deltas which try to ensure that
<vila> deltas that are not an exact fit are not applied.
<tedg> vila, Okay, why are my deltas not an exact fit?
<vila> tedg: I don't fully parse that myself ;)
<vila> tedg: what was the bzr command ?
<tedg> vila, merge-upstream
<vila> I was afraid you'd say something like that :-/
<vila> tedg: file a bug
<tedg> Sure, but I need to figure out how to get my work done as well :)
<vila> I don't think this can be answered without reproducing and some analysis :-/
<vila> tedg: this smells like a parallel import problem though as I don't think COPYING is often renamed
<vila> tedg: and don't forget to tag the bug UDD
<tedg> vila, Will do.  Doing by hand now to see if I can get more info.
<vila> tedg: checking the COPYING file-id in both branches should confirm that they are the ones involved
<vila> james_w: does tedg problem above rings a bell ?
<bialix> vila: conflict resolutions? qconflicts or qresolve command
<vila> grr, ring, no s
<tedg> vila, How do I get the file ID of a file.
<james_w> vila: yes
<james_w> tedg: it's fixed in bzr-builddeb trunk
<vila> tedg: here you go :)
<bialix> vila: if you're lucky enough you can launch external gui merge tool; then say which conflict is resolved
<vila> Glenjamin: ^
<vila> bialix: thanks, that was for Glenjamin
<bialix> Glenjamin: what is your question actually?
<vila> tedg: bzr inventory --show-ids | grep COPYING
<tedg> james_w, Will that get in Maverick?
<james_w> tedg: yes
<Glenjamin> mgz: it was xml.etree iirc
<tedg> vila, Thanks!
<tedg> james_w, Woot!  If I do the merge-upstream by hand now do you expect that to work?
<Glenjamin> vila: thats pretty much what i mean - i've been thinking about writing a plugin so you can do "bzr resolve --this FILE" or "bzr resolve --other FILE", which basically does mv on .THIS or .OTHER and resolves
<Glenjamin> but can't decide if there's any point
<james_w> tedg: by hand how?
<vila> Glenjamin: http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
<mgz> Glenjamin: thanks, is that first path through the import maze then. would you mind reverting the hack stripping diff, and try a one line addition higher up for me?
<vila> Glenjamin: that's a work in progress
<Glenjamin> mgz: sure
<mgz> vila: thanks for the review, hope it won't upset you too much if I poke the branch a bit further
<mgz> Glenjamin: after http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/annotate/head%3A/bzrlib/xml_serializer.py#L33
<Glenjamin> oh hang on
<mgz> add import xml.etree.ElementTree
<Glenjamin> what's a good way to revert
<vila> mgz: not at all, but put the mp to wip then
<Glenjamin> i literally edited the file in dist-packages
<mgz> vila: not that big a poke
<vila> mgz: see http://babune.ladeuil.net:24842/job/selftest-windows/161/ and ping again for a refresh
<mgz> Glenjamin: patch -R with same input?
<tedg> james_w,  bzr branch ubuntu -r upstream-0.0.9 work ; cd work ; tar -xvzf 0.0.10 ; bzr commit ; etc.
<Glenjamin> i was lazy and just hacked it out with nano D:
<james_w> tedg: it's not great as it doesn't get the pristine-tar data in
<james_w> tedg: and it's probably quicker to use a checkout of bzr-builddeb trunk to run that one command
<tedg> james_w, yes, how do I add that?
<james_w> tedg: you can't do it from the command line
<mgz> okay, overwrite with http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/download/john%40arbash-meinel.com-20100217171116-h7t9223ystbnx5h8/xml.py-20050309040759-57d51586fdec365d/xml_serializer.py then
<tedg> james_w, Heh, well, I'm at the final step -- so quicker isn't an issue at this point :)
<mgz> (and make sure the perms don't get mangled)
<mgz> vila: had problems with using result.stream and subunit in the test collection branch, I might need some extra code to make it happy
<mgz> ...I'll stick this in the mp
<vila> mgz: does it mean the babune run won't complete ?
<vila> mgz: no idea is an acceptable answer
<mgz> I didn't get as far as working out why subunit was unhappy last time, and it was a good thing to remind me about
<vila> 'remind me about' ? Me ? When ?
<mgz> you mentioned babune in the mp, and I thought "oh, er..."
<vila> ah, ok
<Glenjamin> mgz: that appears to fix the issue as well
<mgz> this is a slightly different situation so may actually be fine
<mgz> glenjamin: great, thanks.
<Glenjamin> is there some sort of weird lazy loading going on in etree?
<mgz> our code is slightly dodgy and relying on what other people's modules happen to import
<mgz> vila: I think I might put that one-liner up for 2.1 rather than the monkey-patching strip, it's a less scary diff
<TresEquis> jelmer: thanks very much for tracking down the KARL3 svn-import issue
<jelmer> TresEquis: np
<Glenjamin> heh, conflicts somewhat more complex than my use case :D
<vila> mgz: sure thing, will ease SRU
<tedg> james_w: upstream bzr-builddeb does fix it.
<james_w> great, thanks for testing tedg
<james_w> it will be uploaded soon, there are just a couple more fixes that I want to include
<vila> Glenjamin: you mean you were referring to text conflicts only ?
<Glenjamin> i was referring specifically to the case where i just want to say "use this one" in a text conflict
<mgz> with newish bzr you can do `bzr resolve --take-this`
<mgz> or --take-other
<Glenjamin> ah, thats exactly what i was after
<Glenjamin> cheers for the help today guys, time to go :)
<vila> Glenjamin: eerk no, I'm pretty sure --take-{this|other} doesn't work for text conflicts (yet)!
<vila> argh, too late :(
<vila> mgz: for the record (and Glenjamin) see 'Provide additional actions for text conflicts' at http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution,  Implementing --take-this and --take-other first sounds like a bad idea as people may confuse them with --prefer-this and --prefer-other.
<mgz> it's bad for real conflicts, quite often people have versioned auto-generated things where you just want the stupid
<vila> mgz: yeah, we need either versioned properties and file-level config variables to set a default action for these specific files
<vila> mgz: job 161 finished, but no output related to the leaks, expected ?
<mgz> yeah, see new comment in the mp
<vila> ha, let see
<vila> mgz: hehe, so... add comments :-P
<mgz> well, there are some things I intend to change but not yet, and it's confusing me :)
<vila> mgz: I tend to add # FIXME: rumble the wigging -- vila yyyymmdd, even in committed stuff, it's easier to find them back
<mgz> me too when thinking straight.
<mgz> gra, and now I rememeber why I did this as well, bt.test_selftest has too many weirdnesses in it
<vila> mgz: well, be careful there to not reduce the test coverage, otherwise, feel free to rewrite
<mgz> it's mostly a case of tests taking shortcuts that happen to work, but aren't anything like a real test run
<vila> mgz: not reduce in test_selftest I meant, but since we have delegated some to testtools...
<vila> mgz: which one ?
<mgz> so, passing things that aren't real test cases but just implement the three methods some particular code path happens to use, and so on
<mgz> or, in this case, doing test runs without doing startTestRun/stopTestRun around it
<mgz> which is more understandable, and I don't think I want to mess with
<vila> mgz: ha, this kind, hmm, the easiest is to complete the mockups then
<vila> mgz: unless there is a way to make the tests more specific...
<vila> mgz: InstrumentedTestResult ?
<mgz> yup, which isn't all that evil really.
<vila> mgz: turn it into module-level class and define daughter classes for tests, will be clearer too
<mgz> I think my plan A was possibly better, which was, invent report_tests_starting, keep startTestRun, deprecate startingTests
<mgz> *startTests
<vila> mgz: I don't know what testtools chose there
<mgz> well, report_* is a bzrlibism, but one I quite like.
<mgz> testools adds startTestRun (as per Python 2.7) and that's all.
 * vila needs to go, bbl
<mgz> bye! I think I'm going to stop worrying and just address your review comments instead.
<jam> mgz: how I learned to stop worrying and just love the review comments...
<jam> (Dr. Strangelove if you didn't get the reference)
<jam> spiv: if you get this, IProcessTransport is a load of crap
<jam> I have been implementing lots of Process attributes because they get used all over the place, which are *not* specified in IProcessTransport
<mtaylor> bzr: ERROR: An inconsistent delta was supplied involving u'po/POTFILES.in', 'potfiles.in-20100726013555-fcxe3tgefhkh1mxt-1'
<mtaylor> reason: Attempt to add item at path already occupied by id 'potfiles.in-20100203232321-8hvd3vlf9l7taryv-34'
 * mtaylor is sad
<mgz> okay, done.
<mgz> jam: a film I really should rewatch at some point.
<mgz> mtaylor, is that exactly what tedg hit earlier?
<mgz> in which case, the answer was:
<mgz> <james_w> tedg: it's fixed in bzr-builddeb trunk
<mtaylor> mgz: ah - I'll try upgrading to trunk and see if it fixes it
<mtaylor> mgz: yes. fixed in trunk. thanks!
<vila> mgz: seriously, it would have a been a shame to land without those lovely comments ;)
<jelmer> 'evening vila
<vila> jelmer: hey !
<GaryvdM> Hi all.
<GaryvdM> I've got an odd problem. When I try run bzr branch lp:subvertpy, I get this error:
<GaryvdM> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/subvertpy/".
<GaryvdM> This is at home. If I ssh to a work server, and run from there, it works fine.
<vila> -Derror ? .bzr.log ?
<vila> typo ?
<vila> GaryvdM: meh, same here
<vila> GaryvdM: ever see this funny %2Bbranch before ?
<vila> GaryvdM: lp:~jelmer/subvertpy/trunk works, smells like a lp bug to me
<lifeless> this is new
<lifeless> its thumpers code to support lp: for private branches
<lifeless> thats +branch
<lifeless> please file a bug on launchpad-code
<GaryvdM> lifeless: Ok
<GaryvdM> Thanks
<marienz> is there a way to create a branch with rich-root support that bzr 1.5 can read using bzr 2.1.2? I'm hoping to be able to pull some code onto a debian lenny system.
<marienz> "bzr help current-formats" and "bzr help other-formats" don't really show anything appropriate, but the 1.5 user reference claims 1.5 did support some rich-root format already.
<marienz> this is complicated by me not having direct access to a debian lenny system
<GaryvdM> marienz: Looking at the code, you could use the rich-root-pack format.
<marienz> GaryvdM: ah, thanks, I was incorrectly assuming the list from "bzr help current-formats" and "bzr help other-formats" would be complete :)
<GaryvdM> marienz: Yhea - I'm not sure if there is a help topic to see all the old formats.
<marienz> no worries, this had better not be a common thing to want to do
<marienz> arguably I should get a newer bzr installed on that box anyway
<GaryvdM> marienz: The formats are in bzrlib/bzrdev.py
<marienz> I can figure it out now that I know the list I got from help is incomplete
<poolie> good morning; hi jam
#bzr 2010-09-10
<poolie> hi spiv
<spiv> Hi poolie
<poolie> how are you?
<spiv> Pretty good, codebrowse now appears to generate OOPSes :)
<poolie> great :)
<poolie> now we just need to stop it generating oopses :)
<poolie> so we're half done?
<spiv> And tell the OOPS reports infrastructure about them, apparently, but yes :)
<spiv> At least it gives a slightly less ugly page now, even if the reports aren't visible to devs yet :)
<lifeless> spiv: are you going to drive this through to conclusion?
<lifeless> spiv: if not, please be sure to handover clearly so I or someone else can
<spiv> lifeless: I just sent a mail to matsubara
<lifeless> \o/
<spiv> lifeless: (who finally replied to my mail to him from weeks ago :/)
<james_w> renames + bzr-builddeb are starting to get really hairy
<james_w> well, they've always been hairy, I'm just starting to realise :-)
<lifeless> james_w: lol, yes.
<james_w> what we have currently is buggy, and worse, unstable
<james_w> it might permute the file ids in your tree on every merge
<james_w> which is...not ideal?
<lifeless> james_w: it shouldn't do that, I don't think.
<lifeless> james_w: at least, the patch I put in had some reasoning about that sort of thing around it.
<james_w> lifeless: it looks through a number of trees (including itself) and if the path has a different id in any tree then it will switch it
<james_w> so it won't reach a steady state if there are two trees that continue to differ on path2id for a particular path
<lifeless> it switches? I thought it took the incoming id
<lifeless> because the incoming is 'upstream'
<james_w> incoming is a list, not a single tree
<james_w> so I think we may have two things that are currently conflated to unpick
<james_w> or some earlier assumptions may have to be changed, and it changed to be fewer trees to examine
<james_w> there is a "goal tree" that we want to look at
<james_w> and the old semantics which was "a list of trees that you should re-use ids from for added files"
<james_w> which was added to mainly reduce the conflicts between debian + ubuntu IIRC
<james_w> from something like the parallel import problem
<lifeless> and upstream vs tarballs
<lifeless> we want ids to flow from upstream -> tarball -> debian -> ubuntu
<lifeless> I think :)
<james_w> yeah, I think
<james_w> we have 3 commands to consider: 1. dh-make 2. import-upstream/merge-upstream 3. import-dsc
<james_w> dh-make is pretty boring for this, as it just introduces a tarball to a branch, so there is only one source of ids. I just need to check that it will only have a single tree, the upstream tree, and we can ignore it
<lifeless> james_w: well
<james_w> yes, that's a boring case as there is only a single tree
<lifeless> james_w: one problem is that dh-make is what folk are pointed at to 'get going', but if their project is in bzr, they should really start from there.
<james_w> lifeless: dh-make works with existing branches
<lifeless> ok
<lifeless> cool, my misunderstanding
<james_w> "if the project is in bzr then start in a branch at the revision corresponding to the release you are packaging"
<james_w> it just means we can talk about a single command as the starting point
<james_w> import-upstream, this has more trees for sure
<james_w> there's the existing "pristine tree" and an optional upstream tree
<james_w> we don't really care about the packaging tree, except for an instance of the parallel imports problem
<james_w> if we have an upstream tree then it should be authoritative, otherwise there is just the pristine tree, so there's no issue
<james_w> the parallel imports problem is: 1) add a file in the packaging 2) new release contains (just in the tarball) that same path
<james_w> if we do nothing we get a path conflict, but we can choose to turn that in to a contents conflict if we like
<james_w> so far so good
<james_w> import-dsc is more complicated I think
<james_w> first there are two import_archives done, one for upstream and one for the packaging
<james_w> in command line usage there are few trees
<james_w> just the ones you are importing on top of
<james_w> if we ignore parallel imports then upstream is easy, as there is just the single tree
<james_w> for the packaging it may be more tricky, as you have the existing packaging tree, plus the pristine tree you just created
<james_w> my guess is that in that case you want the pristine tree to be authoritative
<james_w> it will have little impact generally
<james_w> however, if we ignored parallel imports then if a file migrates from packaging to upstream (no bzr involved) then you can get packaging fileids changing
<james_w> so far, I think we want 0 or 1 target trees, which are authoritative and we look for renames in etc.
<james_w> and 0 or 1 opportunity trees which we will take fileids from if we are about to generate one and that tree has the path already
<james_w> I'm suspicious that doing that will cause some problems, but I don't know what they are right now
<james_w> when the importer use import-dsc, it has access to a lot more trees though, everything for Ubuntu and Debian, past and present
<james_w> so, we could have 0 or more opportunity trees, and just pass them as that, but as I said, there may be pitfalls there
<james_w> however, it may be that we want target trees as well
<james_w> if not now, then maybe further down the road
<james_w> I have a feeling that my experiment with rename detection in import-dsc fell down due to something related to that same question
<james_w> so, what could go wrong with taking fileids from another tree, rather than generating them?
<james_w> we would have to ensure that the ids weren't duplicates within our tree
<james_w> obviously it can associate files with different "identities", but that's a risk that is outweighed by the benefits IMO
<james_w> I can't really see any other issues
<lifeless> right
<james_w> if there is a target tree, now or later, then it will override, so that would get you out of some holes
<lifeless> I put dup catching code in my patch, fwiw
<james_w> lifeless: well, I spent the morning dealing with a crash due to duplicated ids :-)
<lifeless> ahh
<james_w> coming from a rather odd place though
<james_w> if upstream renamed a file, then shipped another file at the old path in the tarball that wasn't in the branch, the code would use the same id for both
<james_w> when may we want target trees in import-dsc?
<james_w> maybe when we detect e.g. a merge from debian->ubuntu
<lifeless> james_w: hang on, I fixed that exact same bug 3-4 months back
<lifeless> james_w: with test.
<james_w> I can see we may later when it knows about upstream trees and tries to guess how to graft them on
<lifeless> james_w: this sounds like a regression
<james_w> lifeless: I think it was the other way round, where it renamed on top of another file
<lifeless> oh, perhaps its a variation on the theme.
<james_w> bug 588060
<ubot5`> Launchpad bug 588060 in bzr-builddeb "unversioned executability issue, perhaps in builddeb (affected: 2, heat: 7)" [High,Fix committed] https://launchpad.net/bugs/588060
<james_w> ah, no, you fixed rename and replace with a versioned file
<james_w> I just extended it to unversioned
 * james_w gets to work implementing the above
<spiv> Hmm, yo yo internet for me today.
<james_w> done
<james_w> night all
<poolie> night james
<jam> hey poolie I have a question for you
<jam> I had a question about async/sync feedback of the spawned process. I have all the connections working and "bzr log bzr+ssh://" is working, but it ends up hanging because Twisted needs to know when the process ends
<jam> anyway, I'll try to write something up
 * jam goes to play the new Metroid
<poolie> hi jam
<poolie> jam, can you point me to your code?
<vila> hi all !
<vila> poolie: see late comment on your ui mp
<poolie> k
<poolie> vila i'm just trying a side branch towards testing these things from scriptrunners
<poolie> bit of a distraction but nice if we can do it, from the point of view of testable examples
<vila> sure thing
<vila> I'm feeling more and more inclined to write 'bzr config'...
<poolie> arguably the 'all the configs we have open' should be semi-global state
<poolie> perhaps in this context object robert wanted
<poolie> vila, oh, what would it do? just be a command to set state?
<vila> poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var
<vila> or *unset* one !
<poolie> could be good
<poolie> what are you going to do today?
<vila> finish submitting proposal for bug #323111 and then... setup a proper TODO list
<ubot5`> Launchpad bug 323111 in Bazaar "Cannot delete directory with ignored files (affected: 1, heat: 8)" [Medium,In progress] https://launchpad.net/bugs/323111
<poolie> i mention script runners because even when i intentionally change uncommit's confirmation string, it still passes its tests :/
<poolie> oh, yay
<vila> urgh, how come ?
<poolie> it seems that aspect is not tested
<poolie> i would guess because it's a bit too hard to write good tests for user confirmation
<poolie> spiv, where was that testdoc script?
<vila> he he :) :-| :-/
<poolie> vila, so fwiw it fails because scripts run with a TestUIFactory whose stdin is connected to a (probably empty) stringio
 * vila shudders... almost all transform tests force the format to be dirstate-with-subtree, I wonder what consequences it has on coverage :-/
<poolie> would it be reasonable to arrange for them to pull lines from the script? maybe so
<poolie> perhaps only for tests that specifically want this?
<vila> err, did you try adding '< y' lines ?
<vila> if the script provides no input, that should be an empty stringio, but if it does... it should be respected
<poolie> hm
<vila> hmm, ok, I overreacted, half of them only force the format :-/
<poolie> still, would be good to separate it out
<poolie> at least to an abstract "a format with subtrees"
<poolie> we could grep for more tests like that
<vila> yup, or put them under.. per_workingtree
<vila> oh wait, there may be some there already so probably they *are* tested indirectly
<poolie> actually it's better than i thought
<poolie> it complains the string is missing a newline
<poolie> which it is
<poolie> but it seems easy to make it tolerate that
<poolie> but now i really need to go
<vila> script error reporting needs some love, iirc I needed a trick to produce correct line numbers for embedded strings
<poolie> just getting a diff across the whole script might help
<poolie> sometimes the one line it complains about is not very obvious
<poolie> matcher might help
<vila> matchers... yeah, I should *really* start using them :-/
<poolie> not so hard
<poolie> just need to change your habit
<poolie> oh, and we need to convert some existing utilities
<vila> oh, I'm fully convinced :)
<vila> It's just that I keep forgetting ;)
<bialix> hey
<bialix> vila, poolie: re https://code.launchpad.net/~mbp/bzr/ui-factory/+merge/34956
<bialix> what qbzr should be aware of?
<vila> bialix: the new ui.confirm_action() method, that's the point of the mp
<bialix> so?
<bialix> my brain is slightly slow this morning
<vila> bialix: may be you should read it, or at least the comments
<vila> bialix: the question is: 'what impact would it have on qbzr if any' to add a new ui method
<bialix> ok, IIUC qbzr should override this method, right?
<vila> bialix: if you want to decorate it yes, otherwise it will fallback to get_boolean
<bialix> as I remember we already using our own ui class, so we just need to override that method here
<bialix> the good example is quncommit
<vila> bialix: yeah, I think it's enough, I was worried about a case where you override confirm_action and not get_boolean, but that doesn't make sense I think
<bialix> it has the custom asker
<bialix> no, I really feel stupid today, wait a sec
<vila> my concern was: are we introducing a new method that suddenly will prompt from the console ?
<bialix> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/annotate/head%3A/lib/subprocess.py#L832
<bialix> my answer based on the link above: no, we have implementation for get_boolean
<bialix> we == qbzr
<vila> but since the implementation use get_boolean, I think it was silly. Now, if we make confirm_action depends on config variables... there may be other concerns like: always ask when using GUI, respect config var from command line
<bialix> vila: how well bzt-gtk will behave I don't know
<vila> & respect config var from command line *otherwise*
<bialix> "I think it was silly" -- I don't understand
<bialix> which one config var from command-line?
<vila> I think *I* was silly, my concern was silly
<vila> confirm_action use a confirmation_id the plan is to map it to a config var
<bialix> so, your concern about our inability to handle get_boolean was wrong, right? ok
<vila> so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just the command, stop asking will you ?'
<vila> bialix: yes
<vila> so, for uncommit, the default will still be to ask the user, but *I* will be able to set it from a config file to say: 'hey, I just typed the command, stop asking will you ?'
<bialix> so, your concern about our inability to handle get_boolean was wrong, right? ok, when user can override any config parameter from command-line in the universal way? that would be great
<bialix> sorry
<bialix> the last message messed up
<bialix> something wrong with chatzilla
<bialix> will we have an universal way to override any config option from command line, like hg?
<vila> bialix: you mean:<vila> I'm feeling more and more inclined to write 'bzr config'... ?
<vila> <poolie> vila, oh, what would it do? just be a command to set state?
<vila> <vila> poolie: explore the active configs for wt/branch/repo/nothing (revealing the overrides) and set one config var
<vila> <vila> or *unset* one !
<bialix> vila: no, like this: `bzr uncommit --config "bazaar.conf:uncomiit_dont_ask_me = True"
<vila> bialix: no like -obzrlib.lock.break=y
<bialix> hg allows user to provide config settings for *current* coimmand
<bialix> the latter is fine too
<vila> bialix: see bug #<that one, thanks ubottu>
<bialix> ubottu, don't sleep, read vila's mind, please
<vila> bug #491196
<ubot5`> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line (affected: 3, heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/491196
<vila> yeah, -O not -o
<bialix> yeah, rocks
<vila> bialix: just metoo it will you ? :D
<bialix> :-)
<bialix> bug 634240
<ubot5`> Launchpad bug 634240 in Bazaar Explorer "Initializing colocated branch fails. (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/634240
<bialix> signature of set_reference was changed in 2.2? but news has no mention of it
<bialix> vila: you merged taht patch from jelmer
<bialix> it has no news
<vila> patches welcome :)
<bialix> revno 5050.115.58
<bialix> in trunk
<bialix> the train is already left the station
<bialix> who want patches now?
<vila> all the people ready to fall in the same trap
<vila> bialix: I can't find this revno, revid ?
<bialix> sorrrrrrrrrry, it's revno in 2.2 branch
<bialix> revid:pqm@pqm.ubuntu.com-20100507115028-tuuxmnormm8oetw6
<bialix> it was possible to avoid compatibility break here, but anyway, the train is already left
<bialix> sorry for the rant
<vila> bialix: right, I reviewed it and rely on bzr-loom to catch compatibility issues so I missed this one :-/
<vila> bialix: is that a problem for bzr-explorer only or are there other colo related plugins that will suffer from it
<bialix> I'm not sure yet, I need to check bzr-colo plugin itself
<vila> bialix: did you find this by running a test suite or manually ?
<vila> bialix: underlying question: can we automate something to detect such problems in the future ?
<bialix> user filed bug report
<vila> :-(
<bialix> vila: perhaps
<bialix> this specific bug -- yes, it's possible to create at least blackbox test for explorer
<vila> On the positive side, it's more instance satisfying the rule: any bug is a missing test :)
<bialix> will do while I will be fixing this particular bug
<vila> bialix: thanks
<bialix> vila: tests rock, yes, but gosh, it tends to steal too much time
<vila> bialix: as do bugs
<bialix> bzr-colo seems not affected, Neil has 2 code paths for 2.1 and 2.2
<spiv> Hmm, the per_tree/test_list_files.py tests could use some refactoring (and many more cases)
 * vila grumbles: stupid emacs can't be spawned from xchat to open spiv links
 * vila get away from copy/pasted test code in disgust :(
<vila> spiv: from future import BB:approve :)
<spiv> vila: hah
<spiv> Something to try forget about over the weekend and tackle on Monday, perhaps :)
<spiv> vila: have a good weekend :)
<vila> spiv: you too !
<spiv> Also, I'm enjoying the new --format=shiny I added to lp:testdoc
<vila> spiv: wow, yummy !
<vila> spiv: did you try that on the bzr test suite ?
<bialix> vila: from past import brlib-2.1 :-P
 * bialix hides
<vila> bialix: you're so last century :-p
<bialix> I'm tired to fix bugs every time some lib updated it's version
<bialix> and, yes, I'm
<jdobrien> help!
<jdobrien> I am having a problem in maverick with bzr
<jdobrien> pqm-submit is broken now
<jdobrien> which...I need :)
* mthaddon changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: jam | bzr 2.2.0 is officially out | patches welcome: http://webapps.ubuntu.com/employment/canonical_BSE/
<jdobrien> hehe
<GaryvdM> jdobrien: What error are you getting
<jdobrien> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://None@bazaar.ubunet/)> ignored
<jdobrien> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0x17088c0> ignored
<jdobrien> sorry for the paste
<GaryvdM> np
<GaryvdM> jdobrien: Seeing If I can reproduce
<lifeless> I'm just droppng by after cleaning teeth :P
<lifeless> 2.2.1 fixes this
<jdobrien> GaryvdM, this is with the latest from bzr
<jdobrien> GaryvdM, sorry. i mean latest maverick
<lifeless> it shouldn't be harmful for pqm-submit though, just noisy.
 * lifeless waves bai
<jdobrien> hmm
<jdobrien> GaryvdM, oh fiddle-dee dee, lifeless is right. it's still working
<jdobrien> now i have queued my job many times :)
<jml> I've got a bunch of checkouts in a directory, and I'd like to quickly get some information about their diff from trunk
<jml> essentially, I want to do "bzr di -r submit: $checkout | wc -l" for each of them
<jml> is there a plugin for this
<spiv> jml: not that I know of
<spiv> vila: yes, I added --format=shiny to testdoc because I wanted a quick and easy way to get a sense of the tests that were already in a module
<jml> spiv, thanks.
<jml> I hope vila's bzr-gardener is released someday soon.
<spiv> Although I did try it out on bzrlib/tests/test_*.py, and it looked... shiny.  Bit long, though ;)
<vila> jml: shudder, me too
<vila> jml: but it's in the front of my mind I swear
<jml> :)
<vila> jml: I even have an emacs opened with an unfinished line of code :-/
<vila> spiv: is it visible somehwere ?
<spiv> vila: it's visible in your very own terminal!  testdoc --format=shiny bzrlib/tests/test_*.py
<vila> spiv: hehe, the next question would have been: 'or is there a one-liner ?' :-D
<spiv> vila: it's pretty simple tool.
<vila> spiv: hmpf, attributes... emacs.raise ENOTIMPLEMENTED
<vila> ha, works better in terminal.... reminds me of gentoo :-P
<vila> spiv: err, some text is barely readable, is that deliberate ?
<vila> spiv: things like: From Unicode String Ascii Contents
<vila>     From Unicode Deprecated
<vila>     From Unicode String Unicode Contents
<vila>     From Utf8 String
<vila>     None
<vila> are in so grey so light... it's white :)
<vila> spiv: [37;1m
<spiv> vila: my terminal has a dark background.
<spiv> vila: patches welcome!
<vila> hehe
<allenap> MemoryTree has no revert() method, WorkingTree does. Does anyone know if this is this intentional or a defect? I tried, briefly, to use TestCaseWithMemoryTree in some Tarmac tests, but Tarmac relies quite heavily on revert. I wondered if I should file a bug.
<mgz> this... rings a bell
 * mgz seaches list archives
<mgz> https://lists.canonical.com/archives/bazaar/2009q3/061426.html
<mgz> about merge rather than revert, but "MemoryTrees aren't a complete
<mgz> emulation of a WorkingTree
<mgz> seems relevent.
<mgz> file a bug maybe?
<jelmer> alennap: revert and merge both use treetransform underneath
<allenap> mgz: If MemoryTree is not intended as a full emulation of WorkingTree then that's enough. I might file a bug to update the docstring though.
<james_w> jelmer: revert doesn't does it?
<jelmer> james_w: it does, WorkingTree.revert() calls out to bzrlib.transform.revert which uses TreeTransform
<allenap> jelmer: I don't have any experience with treetransform. I am fairly inexperienced with bzrlib on the whole. Are you suggesting that I could perform a revert on a MemoryTree using treetransform?
<bialix> GaryvdM: ping
<jelmer> allenap: Aaron's saying in that email that merge doesn't work for memory tree because there are alternatives (PreviewTree, TransformPreview) for treetransform on memorytree. I merely wanted to clarify that that goes for revert, too.
<bialix> GaryvdM: what is your mind on bug #614123?
<ubot5`> Launchpad bug 614123 in QBzr 0.19 "Model tests not testing correctly (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/614123
<allenap> jelmer: Okay, cool :) Thank you.
<jelmer> allenap: Unless you can use PreviewTree/TransformPreview in the code too, it's probably not possible to use TestCaseWithMemoryTree I guess. Perhaps Aaron has suggestions.
<allenap> mgz: Thank you too.
<allenap> jelmer: I'm okay doing without TestCaseWithMemoryTree. The test suite is fairly small for Tarmac and will remain so for a long while I would imagine, so using on-disk trees is fine for now.
<jelmer> allenap: if you're used to the launchpad testsuite everything is fast and small ;-)
<allenap> jelmer: Dead right :)
<james_w> jelmer: huh, I thought it was implemented separately, thanks
<jelmer> it's quite elegant the way it's done.
<mgz> gra, annoying bugs.
<mgz> erm... jelmer, the email I just sent you probably comes off rather too snarky. what I meant was saying "Don't Do That Then" doesn't seem to be an effective stratgey to dealing with cross platform issues
<jelmer> mgz: It didn't come across as particularly snarky but thanks anyway :-)
<mgz> is launchpad ignoring email from jam? I see a couple of messages from him that launchpad still doesn't have.
<mgz> eg, https://code.launchpad.net/~vila/bzr/323111-backup-names/+merge/35109
<vila> mgz: yeah, he voted but forgot to sign and I reply to the mp...
<vila> replied
<vila> mgz: so launchpad refused his email, but *I* only commented so no sig required
<vila> urgh, hopefully the spammers don't read this channel :-}
<cody-somerville> vila, if not, I'm sure they google for "hopefully the spammers don't read this" ;p
<vila> cody-somerville: ouch: About 794,000 results (0.22 seconds)
<vila> cody-somerville: dood luck to them :-D
<vila> ghadd good luck, pff, bad luck yeah
<mgz> vila, have we got a bug about the babune random failure on bzrlib.tests.per_transport.TransportTests.test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) ?
<vila> mgz: spiv filed on upstream
<mgz> cool.
<vila> mgz: you're talking about the https specific one right ?
<mgz> looks like it.
<vila> where we get some attribute missing instead of EBADF ?
<mgz> yup.
<vila> mgz: there is also the infamous error: Socket is closed in lib/python/paramiko/channel.py", line 787, in sendall_stderr
<vila> I don't know if we have a bug filed for that, but ISTR that we catch OSError when we should catch socket.error somewhere...
<mgz> spiv got that one too though, right? (provided paramiko ever releases a new version)
<vila> no, spiv patch is about IPV4 IPV6
<vila> the one I mentioned doesn't make any test fail, just a spurious traceback
<vila> from a private paramiko thread or do you I mix several ones... haaa, I need to finish something else first :)
 * mgz stops distracting vila
 * vila is sure mgz has better things to do :-P
<mgz> that is also true... :P
<GaryvdM> mgz: How much do you know about building vsproj?
<GaryvdM> I got an error building tortoisebzr, which I've know idea how to fix :-(
<GaryvdM> But I restared my vm, as I'll only be able to pastebin error in about 5 min
<mgz> not much unfortunately, I'm not up to date on the tooling changes
<GaryvdM> He - I'm sure you know more than me :-)
<mgz> paste it when you've got it and I'll see if I can help
<GaryvdM> Ok thanks
<mgz> 12448KB    31KB/s | Fetching revisions:Inserting stream <- what the hell bzr, this is a one rev change on top of the very latest bzr.dev
<mgz> pushing that shouldn't require more than 10MB download
<beuno> maybe it's packing
<mgz> I'd really rather it didn't.
<GaryvdM> beuno: Packing on a pull should not result in extra data being downloaded.
<GaryvdM> It dose though on push to a dumb transport.
<GaryvdM> mgz: bzr+ssh or http?
<mgz> lp: so should be the former, right?
<GaryvdM> Only if launchpad-login is set
<mgz> it wouldn't let me push to lp:~gz without.
<GaryvdM> Yhea
<mgz> dammit! it's that same bug I hit before
<mgz> what was the workaround...
<mgz> (interrupted the first push because it was going sloooow/hung, and trying again does "fetch up to rev {None}")
<mgz> ..delete branch via webinterface then push again
<GaryvdM> mgz: Oh - this is a push, not a pull
<GaryvdM> mgz: did it say it was stacking?
<mgz> yeah, but this bug makes it re-download the entire repo. I'd just forgotten I'd done the exact same thing before.
<mgz> ...in April.
<mgz> https://lists.canonical.com/archives/bazaar/2010q2/068134.html
<GaryvdM> vcbuild.exe : error VCBLD0004: Project 'c:\bzr_inst_build\bzr-windows-installers\build-win32\tortoisebzr\bzr-2.2\shellext\tbzrshellext.vcproj' does not contain a configuration called 'Release|x64'.
<GaryvdM> http://pastebin.ubuntu.com/491715/
<GaryvdM> mgz: ^ and ideas?
<mgz> okay, that sounds pretty straightforward
<mgz> presumably the vsproj file really doesn't contain an x64 release config
 * GaryvdM checks
<mgz> so, either the switch /p:Configuration="Release";Platform="x64" needs changing
<mgz> or the project file needs to grow an x64 section
<GaryvdM> It dose have the x64 platform in the .vcproj
<GaryvdM> I think the problem my be that I only have 32bit windows :-(
<GaryvdM> *may
<mgz> hm...
<GaryvdM> I think it tries to build 32bit and 64bit versions of the shellext
<GaryvdM> Let me try figure out how to disable the 64 bit version build.
<beuno> hrm
<beuno> new bzr error for me:
<beuno> beuno@beuno-laptop:~/canonical/ubunet/trunk/sourcecode/funambol_cared$ bzr up
<beuno> bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-8005'), ('versioning no contents', 'new-8004'), ('versioning no contents', 'new-8008')]
<vila> beuno: ouch, sry I was afk (dinner and cooking, yes in that order), did you manage to sort it out ?
<beuno> vila, hi!
<beuno> yes
<vila> beuno: 1) malformed transform is only raised for *bugs*
<beuno> I poked it at until it went away
<beuno> reverted, updated, yelled
<beuno> not sure how I can report this, if it was a bug
<vila> it would be nice if you had a recipe to reproduce
<vila> beuno: it probably involve setting the same branches/checkout at some revisions... Did you had uncommitted changes ?
<vila> beuno: what kind of wt was it ? branch, checkout, light/heavy, bound branch ?
<vila> beuno: may be just attaching a good chunk of your .bzr.log could be a good start and shouldn't require too much time
<vila> beuno: poking at that we may have direct answers or more precise questions
<vila> vila: I try to summarize my thoughts quickly because I won't be long ;)
<fullermd> If you have to summarize your thoughts to yourself, I think you WON'T be long   :p
<beuno> vila, I can do that
<beuno> the branch is ~1gb
<beuno> from a private project
<beuno> I'll file a bug with logs
<beuno> and we can take it from there
<vila> beuno: wfm
<vila> fullermd: My thoughts are currently focused on my cooking (which I'm not sure you will be offered to taste now (which you will, I'm sure, deeply regret :-P) and let me assure you it smells already very good) and that, trust me, just can't be summarized, no matter how long you thought about it :-D Now go check the parenthesis, summary ! Ha !
#bzr 2010-09-11
<knittl> hi guys
<knittl> i recently did a benchmark "log of subtree"
<knittl> bzr really sucks xD
<knittl> 8 minutes for 10 k revs
<knittl> yes, _minutes_
<knittl> * bzr really sucks at this operation xD
<knittl> (nobody should take it as offense)
<lifeless> knittl: what format
<lifeless> what bzr version
<knittl> lifeless: current bzr version and i didn't specify a format, so i'd guess 2a (or whatever it's called)
<lifeless> seems to definitely need tuning
<knittl> yeah. right now it loses by a huge margin
<knittl> in average 500x times slower than git/hg
<lifeless> its that much slower than bzr log -v too :P
<lifeless> please do file a bug
<knittl> -v prints modified files? that means it would be still slower
<lifeless> log -v of the whole tree is reasonable
<lifeless> log -v of a subtree would be slow for the same reason log subtree is slow
<knittl> it's reasonable fast but still slower than the others. i don't have a problem with that ;)
<knittl> i'm now trying on a smaller repo with shorter history â as soon as log -v has finished
<knittl> in a 2k repository it only takes 20s
<lifeless> hmm
<lifeless> please file a bug
<lifeless> I smell a regression
<knittl> !bugs
<ubot5`> If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
<knittl> lifeless: i read somewhere that a subtree log in a branch is really slow
<knittl> and it's known
<knittl> but this is not a branch, this is the only line of history
<knittl> (i'm using the django repository as a reference)
<knittl> also, it's impossible to log a file in a directory that was removed
<lifeless> you can with -r
<knittl> what's r?
<lifeless> log -r revitexistedin path
<knittl> ok
<knittl> hmmmâ¦
<knittl> but it works with files in root, which got removed
<lifeless> if they were removed in the last commit only
<knittl> a friend tested this case for me. i don't know if the file was removed only then
<knittl> lifeless: https://bugs.launchpad.net/bzr/+bug/503071 maybe this bug?
<ubot5`> Launchpad bug 503071 in Bazaar "bzr log DIR could layer above iter_changes (affected: 2, heat: 6)" [Medium,Confirmed]
<lifeless> thats the perf of log DIR bug
<lifeless> but log -v is too slow
<knittl> i was talking about bzr log -- dir
<lifeless> I think that that is new
<knittl> log -v isn't much slower than normal log (it scales proportionally)
<Kamping_Kaiser> hi all, are ther eparticular situations in which you would want to use merge --pull over pull?
<Kamping_Kaiser> guess i sshould explain where the question is from
<Kamping_Kaiser> the tool 'mr' uses 'bzr merge --pull' to update repos, but if there are uncommited changes the update bails. 'bzr pull' successfullydoes these updtes
<Kamping_Kaiser> so unless ther eis a particular reason i'm not aware of to use merge, i might file a bug suggesting to simply use pull
<lifeless> well they are different things
<lifeless> pull maintains a mirror
<lifeless> merge integrates changes from another branch; merge --pull says 'mirror if you can otherwise merge'
<Kamping_Kaiser> if i have locally commited changes and i pull, it overwrites them? (I've not noticed that behaviour, thats all)
<lifeless> no, pull will error, merge will merge, merge --pull will merge.
<Kamping_Kaiser> hm
<Kamping_Kaiser> so i'm going to get an error of some sort either way.
<Kamping_Kaiser> guess i'll have to make sure i send my patches imediately in future instead of sitting on them :)
<jml> I would like to push a Bazaar branch to Twisted's Subversion repository
<jml> but I'm afraid it will break something in the Subversion repository that I will be unable to fix.
<jml> what should I do?
<jelmer> jml: Create a local clone of the svn repository and push to that first?
<jml> hmm. I guess I do have read access to the actual repo.
<jml> I guess I also don't really know how to check for badness.
<jml> all I really have are nebulous fears.
<jelmer> I think if it does something wrong it will be fairly obvious from a look at "svn log -v"
<jml> ok. I hope this works. I'd really love to abandon svn.
<jml> this is a fairly lengthy process :)
<jml> jelmer, bzr-svn seems to be doing more work than I'd expect. "Initialising Subversion metadata cache "
<jelmer> jml: that should be a one-time thing
<jml> oh wait, I think I get it.
<jml> I've been using the bzr-svn mirror of Twisted without bzr-svn installed, but now I've installed it so I can try writing to svn repos with bzr.
<jml> jelmer, interestingly, pushing up the branch doesn't make a revision that creates the branch as you would normally expect in svn.
<jml> jelmer, this breaks some of our trac automation.
<jml> man. I'm so late. Gotta go.
<jelmer> jml: You mean the new revision does the copy *and* the changes as opposed to creating the branch in a separate revision?
<jelmer> jml: ttyl
<JoshBrown> maxb: You remember we were talking about that qbzr issue to do with filepaths?
<JoshBrown> <JoshBrown> maxb: I think this is a qbzr issue since everything works fine using plain bzr
<JoshBrown> <maxb> that seems rather odd. Possible, but odd
<JoshBrown> <JoshBrown> maxb: Yeah, maybe it's something to do with canonicalization of links or something like that. Anyway I'm off for now, I'll check the differences between the commands I'm running and the ones qbzr is running tomorrow. Bye, and thanks for the help!
<JoshBrown> maxb: Turns out Bash expands the `~` character, but qbzr doesn't. Could this be classed as a bug?
<vyoma> Hello
<vyoma> I'd like to know if there are guidelines for setting up Bazaar repository(folder structure) for projects involving Eclipse plug-ins.
<vyoma> Projects involving Eclipse plug-ins usually involve 'n' number of plugin (can be called modules) and each are worked on as separate (but interdependent) projects.
<vyoma> Any pointers or links to documents would be helpful.
<lifeless> voidspace: hi; just so you know, you've dropped of launchpad-dev :P
<lifeless> voidspace: have I shown you pypi.org/pypi/fixtures
<lifeless> vyoma: a person called 'verterok' often hangs out here; they wrong bazaar-eclipse, and are sure to know.
<lifeless> mgz: ping
<lifeless> mgz: I know its late, but :
<lifeless> ERROR: junitxml.tests.test_junitxml.TestWellFormedXml.test_error_with_surrogates
<lifeless> ----------------------------------------------------------------------
<lifeless> Traceback (most recent call last):
<lifeless>   File "junitxml/tests/test_junitxml.py", line 313, in test_error_with_surrogates
<lifeless>     self.assertTrue(unichr(0x201A2) in traceback)
<lifeless> UnboundLocalError: local variable 'unichr' referenced before assignment
<lifeless> Ran 18 tests in 0.007s
<mgz> ...but I've been to bed for a few hours and got up again
<lifeless> darn, I just reverted with my conflict fixes
<lifeless> anyhow, where does unichr come from on python2.6 on Ubuntu ?
<mgz> should be in builtins
<lifeless> so
<mgz> there's a better way of spelling that make-it-work-on-Python-3 thing anyway
<lifeless> defining it locally makes it a non-free variable
<lifeless> so you have to do
<lifeless> local_unichr = chr
<lifeless> and local_unichr = unichr
<lifeless> ....
<lifeless> something_with_local_unichr
<mgz> rather than making unichr work like I did, just create that string in one way for Python 3 and another for Python 2
<lifeless> or that
<mgz> want me to push something doing that? It's slightly more annoying because unichr is limited by sys.maxunicode and you can't just use u-prefixed strings
<lifeless> if you would like to push anything that makes it work, that would be dandy
<mgz> okay, this works, pushing.
<mgz> ah, of course, test didn't fail here as I'm giving narrow unicode builds a pass anyway
<lifeless> just fixing conflicts
<mgz> hm, point about lack of news taken.
<lifeless> I hope I wasn't too subtle
<mgz> thanks for merging those lifeless.
<lifeless> my pleasure
<lifeless> sorry I was slack
<lifeless> been beating up on LP transparency and performance
<mgz> was good to get a little testing on babune first anyway
<lifeless> 0.6 is up on pypi and launchpad anyhow
<mgz> fantastic.
<lifeless> now, wtf did I put the source package branch
<lifeless> hmm
<lifeless> pyjunitxml could grow a parser too
<lifeless> to allow injection from an xml file into python/subunit
#bzr 2010-09-12
<parthm> hello. do blackbox tests to something special to cause hooks to not get invoked? i am trying to write a test for bug #403687
<ubot5`> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/403687)
<parthm> it works well on command line but test case doesn't show the status info. http://pastebin.com/98h4RSMG
<parthm> bug #403687 is to add shelve summary in status.
<ubot5`> Launchpad bug 403687 in Bazaar "bzr status should show shelved changes (affected: 6, heat: 24)" [Wishlist,In progress] https://launchpad.net/bugs/403687
<parthm> or am i doing something wrong in the test case?
<parthm> nevermind. found setUp(): self._clear_hooks() in class TestCase
<parthm> will add the hook specifically in this test case.
<lifeless> parthm: thats almost certainly wrong
<lifeless> parthm: the hook should be in the hooks registry or it won't show in bzr help hooks either
<parthm> lifeless: oh. so it looks like i added the hook in the wrong place. where is the hook registry?
<parthm> lifeless: ah. hooks.known_hooks.
<parthm> lifeless: thanks :-)
<parthm> lifeless: hmm. i think i am confused now. the StatusHook is already added. i am just looking to add a predefined show_status_summary hook using installed_named_hook. whats a good place to do that.
<parthm> lifeless: right now i am just calling install_named_hook at the bottom of status.py
<parthm> http://pastebin.com/iUXKsg1t
<lifeless> parthm: Installed hooks are cleared before/after tests
<lifeless> if you want/need a hook to always be installed, do that in the constructor of the relevant class, or in the relevant tests
<parthm> lifeless: will do. for status.py there isn't a class so i suppose that will have to be module level. for the tests i will do it in the constructor
<lifeless> there should be a Hooks class still
<parthm> lifeless: yes. i could add it there. i looked at smart.request. that seems to be adding the its jail_info handler at the module level. i wonder whats the suggested practice for pre-defined hooks that ship with bzr
<parthm> s/pre-defined hooks/pre-defined hook handlers/
<parthm> class Hook mainly defines the hook. adding a handler there doesn't seem clean.
<lifeless> thats right
<parthm> lifeless: ok. so for the tests i will do it in the constructor so that all status tests get the behavior. thanks.
<lifeless> parthm: I don't know what you mean by that
<lifeless> parthm: but I'm sure it will get sorted in review :P
<parthm> lifeless: yes :-) ... basically, for the bb test i am writing i can either add the hook in the test itself, or on the test class level (__init__). doing the latter seems correct as all status tests will get the behavior of bzr as seen by the user.
<lifeless> parthm: __init__ on test classes cannot be used.
<lifeless> parthm: perhaps you mean setUp ?
<parthm> lifeless: yes. setUp :P
<parthm> lifeless: perhaps, _clear_hooks shouldn't be clearing the default hook handlers? i suppose thats a topic for the mailing list :-)
<parthm> lifeless: thanks.
<lifeless> parthm: it totally should clear them
<lifeless> parthm: test isolation
<lifeless> If you want to test something with a specific thing installed; install that thing in the test.
<parthm> lifeless: but if bzr always hooks in some handlers than thats default behavior?
<lifeless> parthm: that sounds weird
<lifeless> parthm: take the command hooks for instance; the ones to return bzr commands are *not installed* in tests.
<lifeless> parthm: run_bzr calls through the codepath that installs them at process startup; calling the public functions directly in a test that hasn't registered them or called run_bzr will find 0 bzr commands instaled.
<parthm> lifeless: ah. yes. that makes sense. thanks.
<jml> jelmer, exactly that. " the new revision does the copy *and* the changes as opposed to creating the branch in a separate revision"
<lifeless> jml: welcome back to the land of the living
<jml> lifeless, thanks.
<jml> lifeless, although technically work doesn't start for another day :)
<lifeless> ha!
<lifeless> jml: can we have a work catchup your tomorrow evening then ?
<jml> lifeless, definitely
<jml> lifeless, what time?
<lifeless> my 8am is free, as flacoste is still awl
<jml> you're still in NZ, right?
<lifeless> 35 1/2 hours from now
<lifeless> yes
<jml> lifeless, ok. 9pm my time. we'll talk then.
<lifeless> \o/
<lifeless> on testtools
<lifeless> have you seen fixtures 0.2 ?
<lifeless> jml: ^
<jml> lifeless, no, I haven't.
<lifeless> so there is a limit with addCleanup that became clear
<lifeless> james_w felt that fixtures that swallowed exceptions would be unusable, and in fixing that I realised I swallowed exceptions because delegated cleanups can only report one exception
<lifeless> but non-delegated cleanups can report all exceptions
<lifeless> jml: https://code.edge.launchpad.net/~python-fixtures/python-fixtures/trunk is the branch
<lifeless> have a look at the last two commits
<jml> lifeless, looking
<jml> lifeless, I used a nasty hack to get around this in the Launchpad fixtures code
<lifeless> specifically, I want a way, with testtools cooperation, to do self.addCleanup and when the cleanup runs be able to report on multiple exceptions
<lifeless> rather than just one
<jml> lifeless, right. I see the diffs now.
<lifeless> whats in fixtures will work I think, but its only a first sketch.
<jml> lifeless, I've a got a "fail last" behaviour in Launchpad's fixtures model.
<jml> errr raise last.
 * jml is still pre-cofee
<lifeless> jml: I chose the first one because its more likely to be the trigger
<jml> lifeless, yeah. I wanted to make sure that everything got run.
<jml> anyway, I'm not too clear what recursive finally behaviour is anyway :)
<lifeless> jml: me too :)
<lifeless> to both :P
<jml> brb
<lifeless> so, I'm proposing we change run_cleanups to look for a return value of a list, and if there is one, pass each element to record_traceback
<jml> a return value of a list?
<lifeless> yeah, as I did in fixtures
<jml> ok. the last two revisions you pointed me at seem to have little to do with what you're talking about :)
<jml> http://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/revision/4 ; http://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/revision/5
<dsuch> Hi, I'm not sure if I understand it corectly in the sample workflow http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/organizing_your_workspace.html#local-sandbox, the 'sandbox' checkout isn't ever actually used for anything directly, right? It's just just a temporary name before I make real branches and switch what 'sandbox' is pointing to?
<lifeless> jml: http://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/revision/3
<lifeless> dsuch: sorry, its late here and I've a million things to do before sleeping, hopefully someone else will answer
<dsuch> sure thing
<knittl> could a bzr revno like 123.1.4.2.3 exist?
<knittl> third rev of second branch of fourth revision of first branch of rev 123?
<spiv> knittl: http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html#understanding-revision-numbers
<knittl> spiv: yes, i'm reading that, but i'm still in doubt
<spiv> knittl: as it says, "Dotted revision numbers have three numbers"
<knittl> spiv: so what happens to the branch of a branch?
<spiv> knittl: (unless you are using a > 2Â½-year-old version of bzr)
<knittl> that's in the docs. but i still don't know how they would be represented?
<spiv> x.2.y
<spiv> or x.3.y, etc.
<knittl> but that when they are branched from the same commit
<spiv> It might be easiest to experiment with some toy branches?
<knittl> hm no, it isn't
<spiv> Ok :)'
<knittl> spiv: yes i did. but having only one branch in a dir is confusing
<spiv> There have been some posts on the mailing list about this, with ascii art diagrams, hopefully google can find them.
 * spiv -> zzz
<janisozaur> I have a (svn-imported) project that in its master branch has "a" and "b" directories. is it possible to split "a" and "b" into separate branches, keeping revision history? there aren't many commits to "b", so manual solution is plausible. using bzr 2.2.
<jelmer> janisozaur: see the "bzr split" command
<janisozaur> jelmer, thanks
<janisozaur> another question: is it possible to see the commit log (also diffs?) for the incoming changes? equivalent of "hg incoming" or "svn log -r BASE:HEAD"
<janisozaur> I've performed a "bzr split a" and "bzr split b" but the commit log for "a" and "b" still lists diffs as "a/somedir/somefile.cpp" while it should list it as "somedir/somefile.cpp" (disregarding top-level "a" or "b" respectively, also splitting diffs where they change both "a" and "b"). do I have to execute any other command to fix it (repack, update or whatever?), can it be fixed or should it be considered a bug?
<jasono> I am trying to use bzr now that I have let bzr know who I am. But it
<jasono> didn't work, it's not trusted. It gave me this:
<jasono> jaso@Familyroom:~$ bzr whoami "Jason Odoom <jasonodoom@gmail.com>"
<jasono> PLEASE HELP!
<jasono> jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr whoami "Jason Odoom <jasonodoom@gmail.com>"
<jasono> jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr branch lp:ubuntu-tour
<jasono> The authenticity of host 'bazaar.launchpad.net (91.189.90.11)' can't be
<jasono> established.
<jasono> RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89.
<jasono> Are you sure you want to continue connecting (yes/no)? y
<jasono> Please type 'yes' or 'no': yes
<jasono> Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to
<jasono> the list of known hosts.
<jasono> Permission denied (publickey).
<jasono> bzr: ERROR: Connection closed: Unexpected end of message. Please check
<jasono> connectivity and permissions, and report a bug if problems persist.
<jasono> jaso@Familyroom:~$
<beuno> jasono, so
<beuno> do you ave your ssh key up on launchpad?
<jasono> Yes, I do.
<beuno> jasono, so the "whoami" command isn't used for authentication
<beuno> the lp-login one is
<jasono> how do i do it
<beuno> well, it looks correct
<jasono> It didn't work.
<beuno> is this a new ssh key?
<beuno> have you ever used it?
<jasono> I guess so. I took it from the Ubuntu Project on Launchpad.
<jasono> BUeno.
<janisozaur> is it possible to see the commit log (also diffs?) for the incoming changes? equivalent of "hg incoming" or "svn log -r BASE:HEAD"
<lbieber> are there known problems with bzr/launchpad today?
<janisozaur> both are fine here
<jasono> I am trying to use bzr now that I have let bzr know who I am. But it
<jasono> didn't work, it's not trusted. It gave me this:
<jasono> jaso@Familyroom:~$ bzr whoami "Jason Odoom <jasonodoom@gmail.com>"
<jasono> jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr whoami "Jason Odoom <jasonodoom@gmail.com>"
<jasono> jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr branch lp:ubuntu-tour
<jasono> The authenticity of host 'bazaar.launchpad.net (91.189.90.11)' can't be
<jasono> established.
<jasono> RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89.
<jasono> Are you sure you want to continue connecting (yes/no)? y
<jasono> Please type 'yes' or 'no': yes
<jasono> Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to
<jasono> the list of known hosts.
<jasono> Permission denied (publickey).
<jasono> bzr: ERROR: Connection closed: Unexpected end of message. Please check
<jasono> connectivity and permissions, and report a bug if problems persist.
<jasono> jaso@Familyroom:~$
<jasono> PLEASE HELP. THANK YOU!
<lifeless> jasono: please answer beuno's questions
<lifeless> janisozaur: 'bzr missing' may do what you want
<lifeless> lbieber: there was something going on last night
<lifeless> lbieber: are you having issues? #launchpad if so
<beuno> jasono, have you ever succesfully used the key to connect to anything?
<jasono> NO.
<jasono> I just tried it yesterday to join the Ubuntu Tour project on Launchpad. I got it from: http://www.ubuntutourproject.org
<beuno> jasono, and how did you generate the key?
<jasono> INto the terminal. C + V
<jasono> These were the instructions: Set up a Launchpad account
<jasono> If you don't have a Launchpad account yet, you can register here.
<jasono> You'll need to set up an SSH key. To do so, run:
<jasono> sudo apt-get install openssh-client
<jasono> to install openssh. Then, make a key with:
<jasono> ssh-keygen -t rsa
<jasono> Press enter to use the default name. You will need to provide a password and confirm it to protect the key. You now have your SSH keys. Upload the public key to Launchpad. To do this, open ~/.ssh/id_rsa.pub in a text editor, and paste it into the text box on your SSH keys page.
<jasono> Then, join our team here.
<lbieber> lifeless:  ok, will check there
<jasono> Hello.
<jasono> bueno
<beuno> jasono, that sounds about right, but something seems wront with your ssh key set up
<beuno> what's the output of:  sftp bazaar.launchpar.net
<jasono> The Terminal told me it was a security problem.
<jasono> Output: sudo apt-get install bzr
<jasono> Now you'll need to tell bzr who you are. To do this, run:
<jasono> bzr whoami "Your Name <youremail@domain>"
<jasono> bzr launchpad-login your-launchpad-username
<jasono> bueno
<rumbert> what is the tool or command to delete any file in the tree which is not in the repository?
<lifeless> rumbert: bzr clean-tree ?
<rumbert> lifeless: yes, thanks.
<lifeless> jasono: you need to answer beuno's questions, he is trying to help you.
<rumbert> Unfortuneately, that does not seem to suffice to do the merge i wish.  I don't think any files are changed by me, I'm only using bzr to mirror. there could be additional files created by a build.
<lifeless> rumbert: that shouldn't worry bzr
<jasono> Sorry, everything's going too fast. I missed it then. What was it?
<lifeless> rumbert: you could do bzr ls --ignored | xargs rm too ?
<lifeless> jasono: 08:09 < beuno> jasono, that sounds about right, but something seems wront with your ssh key set up
<lifeless> 08:09 < beuno> what's the output of:  sftp bazaar.launchpar.net
<jasono> I gave him the output, atleast I tried to.
<jasono> Or did.
<rumbert> lifeless: interesting idea.
<lifeless> jasono: you need to run the command
<lifeless> and paste hwat it shows
<jasono> Can you please give me the command?
<lifeless> rumbert: or add --ignored to clean-tree, its already there ;)
<lifeless> jasono: 08:24 < lifeless> 08:09 < beuno> what's the output of:  sftp bazaar.launchpar.net
<lifeless> jasono: sftp bazaar.launchpad.net
<rumbert> to only maintain a mirror and make no changes, does one still need to use 'merge'?
<lifeless> no
<lifeless> just bzr pull
<rumbert> lifeless: pull won't change the working tree though.  I need to update the working tree.  Maybe 'switch' ?
<lifeless> pull will change the working ree
<jasono> The output: jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr whoami "Jason Odoom <jasonodoom@gmail.com>"
<jasono> jaso@Familyroom:~$ bzr launchpad-login jasonodoom
<jasono> jaso@Familyroom:~$ bzr branch lp:ubuntu-tour
<jasono> The authenticity of host 'bazaar.launchpad.net (91.189.90.11)' can't be
<jasono> established.
<jasono> RSA key fingerprint is 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89.
<jasono> Are you sure you want to continue connecting (yes/no)? y
<jasono> Please type 'yes' or 'no': yes
<jasono> Warning: Permanently added 'bazaar.launchpad.net,91.189.90.11' (RSA) to
<jasono> the list of known hosts.
<jasono> Permission denied (publickey).
<jasono> bzr: ERROR: Connection closed: Unexpected end of message. Please check
<jasono> connectivity and permissions, and report a bug if problems persist.
<jasono> jaso@Familyroom:~$
<jasono> opps sorry
<jasono> lifeless Output: http://paste.ubuntu.com/492755/
<jasono> http://paste.ubuntu.com/492755/
<lifeless> jasono: you need to run 'sftp bazaar.launchpad.net'
<jasono> Okay. I'll try.
<jasono> lifeless Can you help me with that command? http://paste.ubuntu.com/492757/
<beuno> jasono, so, what we need to do is debug why your ssh key isn't working
<beuno> it is not a bzr issue
<jasono> Oh.
<beuno> in order to get more information
<jasono> How do I do that?
<beuno> I need you to type in a terminal the following command, and pastebin the result:
<beuno> sftp -vv bazaar.launchpad.net
<beuno> jasono, did that make any sense to you?
<jasono> Yeah it did. I figured out what paste bin was for. :) Here it is: http://paste.ubuntu.com/492760/
<beuno> jasono, ok, so it seems you are sending launchpad the wrong username
<beuno> try running this command:
<beuno> bzr launchpad-login jasonodoom
<beuno> and then
<beuno> again: sftp -vv bazaar.launchpad.net
<beuno> uhm
<beuno> hold on
<beuno> ignore that
<beuno> try this instead: sftp -vv jasonodoom@bazaar.launchpad.net
<beuno> just that command
<jasono> If it helps, my Launchpad: https://launchpad.net/~jasonodoom
<beuno> and pastebin the result
<jasono> Result: http://paste.ubuntu.com/492762/
<beuno> hrm
<beuno> lifeless, do you know what this means?
<beuno> debug2: we did not send a packet, disable method
<lifeless> jasono: can you try beuno's new one
<lifeless> 'sftp -vv jasonodoom@bazaar.launchpad.net'
<jasono> OKay.
<jasono> With the '
<lifeless> no
<beuno> lifeless, he did
<jasono> Quick question. So if someone gives me a command with ' and ends with' don't copy and run '?
<lifeless> beuno: check the command at the top of the pastebin
<beuno> that pastebin is both times
<beuno> just smashed together
<lifeless> oh I see
<lifeless> thanks
<beuno> threw me off for a bit as well  :)
<lifeless> beuno: the disable method - note that the dsa key is nill
<jasono> Gave me this: http://paste.ubuntu.com/492765/
<lifeless> default is rsa for new keys isn't it ?
<beuno> yes, and he ran: ssh-keygen -t rsa
<lifeless> yes
<lifeless> and the one on lp is rsa
<lifeless> so there are two possibilities
<lifeless> jasono: did you run ssh-keygen more than once ?
<jasono> Yes I did. Before, I thought I was suppose to run these commands in the password encryption tool in accessories. When I found out (realized) what I was doing was wrong I ran it. When I typed the commands and it didn't work I retried the processed over.
<lifeless> ok
<lifeless> ssh-keygen makes a new key; its like going to the locksmith and changing all your locks
<jasono> Wow.
<lifeless> so we need to check that the key you are using is the lock that you have given launchpad
<lifeless> https://edge.launchpad.net/~jasonodoom/+sshkeys
<lifeless> that page shows the key(s) that launchpad knows about
<lifeless> if you run
<lifeless> cat .ssh/id_rsa.pub
<lifeless> it shouls show you some similar text
<lifeless> please see if they are the same.
<jasono> Yeah it does.
<jasono> Gave me this: http://paste.ubuntu.com/492769/
<lifeless> ok they are differnet
<lifeless> what you need to do
<lifeless> on your https://edge.launchpad.net/~jasonodoom page
<lifeless> go edit ssh keys
<lifeless> and paste in what you have in .ssh/id_rsa.pub
<jasono> How do I edit? And edit to what?
<lifeless> https://edge.launchpad.net/~jasonodoom/+editsshkeys
<lifeless> in the 'add an ssh key' box
<jasono> Got it.
<jasono> Type what?
<jasono> The pub........
<jasono> Type this: .ssh/id_rsa.pub
<lifeless> the
<lifeless> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuyiffpiyaanm4 (and all the text that followed
<lifeless> copy and paste is probably easiest
<jasono> The one from the Terminal?\
<lifeless> yes
<jasono> Coo. OKay.
<jasono> I hit import and it added the Key.
<lifeless> try
<lifeless> sftp jasonodoom@bazaar.launchpad.net
<lifeless> again
<jasono> Gave me this:http://paste.ubuntu.com/492772/
<beuno> jasono, you didn't run the command lifeless just told you
<beuno> run:  sftp jasonodoom@bazaar.launchpad.net
<jasono> Okay I'l do it
<jasono> wants my password
<beuno> that is good news
<beuno> it means it's fixed
<jasono> can i check automatticall yunlock when im logged in?
<jasono> so type my password right
<beuno> sure
<beuno> so, the bzr command should work now
<jasono> sftp>
<jasono> gave me
<beuno> good
<beuno> close the terminal
<beuno> and now try the bzr command again
<jasono> lifeless and bueno sorry i crashed
<beuno> that's fine
<beuno> I was saying that it should all be fixed now
<beuno> try running the bzr command
<jasono> the one that lets it know who iam right
<beuno> no
<beuno> the last one that was failing
<beuno> bzr branch lp:ubuntu...etc
<jasono> bueno not sure if ican find it, let me see
<beuno> jasono, all this stared because you wanted to get a bzr branch
<beuno> bzr branch lp:ubuntu-tour
<beuno> that was the command
<jasono> From here: http://ubuntutour.org/contribute/branch/ JUst wanted to join the project
<jasono> gave me this http://paste.ubuntu.com/492782/
<beuno> jasono, ok, so run: bzr branch lp:ubuntu-tour --use-existing
<jasono> told me theirs already a branch ubuntu tour
<beuno> ok, so lets remove it:
<beuno> rm ubuntu-tour -r
<beuno> after that, run again:
<beuno> bzr branch lp:ubuntu-tour
<jasono> Fetching revisons...................
<jasono> 52 branched revisons
<beuno> great
<beuno> congratulations
<beuno> it works
<beuno> you can go back to what you where doing now  :)
<jasono> Thanks!!!!!!
<jasono> Wait
<jasono> I didn't register
<jasono> Now you'll need to tell bzr who you are. To do this, run:
<jasono> bzr whoami "Your Name <youremail@domain>"
<jasono> bzr launchpad-login your-launchpad-username
<beuno> jasono, that is done
<beuno> don't worry
<jasono> didnt do this
<beuno> you did that previously
<jasono> cool
<jasono> what about................. hod on
<jasono> hold
<jasono> this
<jasono> Press enter to use the default name. You will need to provide a password and confirm it to protect the key. You now have your SSH keys. Upload the public key to Launchpad. To do this, open ~/.ssh/id_rsa.pub in a text editor, and paste it into the text box on your SSH keys page.
<jasono> did i do it
<beuno> jasono, yes
<beuno> you're done with all that
<jasono> Thanks man. But how do I upload and edit?
<beuno> jasono, those instructions should be on the project page
<beuno> I don't really know how that works
<jasono> dont get it
<jasono> i dont know how to revise and where this all goes
<jasono> thank you bueno
<jasono> are you on launchpad?
<beuno> jasono, I work for Canonical
<beuno> on the Ubuntu One team at the moment, but I've been in different places :)
<jasono> oh cool. okay so i guess you were trained on this?
<jasono> I have to learn all this stuff. Thanks. :)
<beuno> jasono, np
<knittl> where can i find docs on bzr inventory and such?
<lifeless> pydoc bzrlib.inventory
<knittl> lifeless: looks good. thanks
<knittl> how can i make bzr display all untracked files in a working dir?
<beuno> knittl, bzr ls --unknown
<knittl> beuno: i deleted everything and did bzr revert
<knittl> :D
<poolie> hello beuno
#bzr 2011-09-05
<mgz> okay, posting that for review before I go cross-eyed
<mgz> the actual changes in the branch are simple and should fix nearly all the problems, the overall picture is just complicated
<mgz> and whoops, I totally forgot earlier dulwich isn't managed on launchpad, just realised merge proposal was asking vcs imports to look at it
<jelmer> mgz: the mp has been merged
<mgz> hey, you magically did the right thing despite the fact I'm an idiot!
<jelmer> mgz: thanks for looking into that colo bug
<mgz> ...I take it you did it manually by somehow reading my mind, or does launchpad help out?
<jelmer> mgz: launchpad doesn't help out, especially as I use dpush on dulwich
<jelmer> mgz: for bzr-svn pushes (which have roundtripping) it does recognize merges properly
<mgz> ^some of the colo thing I think is just going to be messy because you're trying to layer an extra external thing onto urls
<mgz> but it should all be fixable at least
<mgz> I think it just needs choosing what behaviour is wanted in a few corner cases,
<mgz> the sort of branches anyone will use in practice should be fine already.
<vila> hi all !
<poolie> hi vila
<poolie> nice report
<poolie> oh no :)
<vila> poolie: hehe
<vila> poolie: you've been good at updating that topic for the past weeks ;)
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
<poolie> that was really classy actually
<poolie> i think i can manage it this week
<vila> poolie: try https://code.launchpad.net/~vila/udd/819910-file-mp/+merge/73927 for an easy one (it's already deployed which is... well it is ;)
<poolie> thanks
<poolie> fwiw i really prefer just 4-char indents for paramter continuations
<vila> fwiw I just type enter and let my editor do the Right Thing ;)
<poolie> or not :)
<vila> well, overriding that will be really unconvenient and error prone
<vila> I almost never do indentation mistakes because I just follow the mode...
<poolie> well, i strongly suspect there's a variable to control it
<poolie> but it's not a big deal at all
<poolie> it just stood out since it was Â½ the diff :)
<vila> hehe
<vila> the 4 spaces indent *is* used if the line is truncated after the opening brace
<poolie> oh, i see
<vila> and overall, I think it makes a lot of sense: either you put *all* parameters on the following line or you align them
<poolie> i think lp's style guide asks for that
<poolie> ours doesn't, so i'm not saying you're wrong
<vila> no worries, I've noticed the various usages long ago and just attributed them to other editors
<vila> poolie: oh, just looked at the mp, yeah, unfortunate and useless here :-/
<vila> poolie: left over from a more involved attempt
<vila> poolie: I generally revert them but forgot that one
<vila> no big deal, just explaining
<Riddell> bonjour
<vila> Riddell: hey !
<vila> Riddell: we just a got a storm of PristineTarError on the package importer (   http://package-import.ubuntu.com/status/73aaec3da59a46ab68e18ea8c195a6e7.html) all of them related to kde: any obvious cause to your eyes ?
<vila> jelmer: do we support bz2 on jubany ? (Shot in the dark)
<vila> poolie: did you talked to mthaddon ? The new pqm was ready to deploy last Friday but I deferred to you (targeting today) while the queue was purging (Friday)
<poolie> no, i haven't talked to him since friday
<vila> poolie: given the config, I think we can use --parallel=fork and ask for /tmp to be tmpfs mounted, that should give us something around 5 mins to land a patch (hopefully)
<mthaddon> I'm planning to put it live today
<vila> hehe, excellent :)
<vila> mthaddon: so, can /tmp be tmpfs mounted ?
<mthaddon> vila: I'd like to have a successful run first, then we can do that, yep
<vila> great
<vila> mthaddon: just ask if you need me to trigger such a run
<mthaddon> vila: ok, I'll let you know when we're ready for it - thx
<vila> poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check-trunk/+merge/73500 didn't cause problems and provides a limited but useful view, are you ok to deploy the moral equivalent for all branches ? If nothing else, it will provide some fuel for the new pqm tests
<poolie> oh hi mthaddon
<mthaddon> o/
<poolie> that's great, thankyou
<poolie> vila, i still have qualms about doing test-futzing things in stable branches
<poolie> 2.4 is ok
<poolie> just more on general principal than because i think the specific risk is very high
<vila> hehe, ok, I'm glad you care about stable branches this way, I do too :)
<poolie> :) if you think it's worthwhile it's ok
<poolie> woo!
<vila> poolie: the fundamental reason I want that on all branches (including stable ones) is that it will give us hard data about regressions.
<vila> poolie: what was this 'woo' for ?
<poolie> i got some improvements to lp mail handling working
<poolie> see that channel
<vila> oh, ok, yeah, great !
<vila> jelmer, poolie: http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates updated, I think only one of you can act from there
<vila> jelmer, poolie : also, in the freeze announcement I said I will officially announce the release tomorrow, but thinking again about it, it doesn't really make sense
<poolie> specifically 2.2.5?
<vila> jelmer, poolie : people interested in SRUs just get them via updates, telling them about it via mail... doesn't seem to match
<poolie> because it's only useful to people tracking 2.2, ro more specifically on maverick?
<vila> yeah, 2.2.5
<poolie> yeah
<poolie> i think it's useful there be something they can read about it
<poolie> but it's important it be in context so people tracking trunk or 2.4 are not confused
<vila> poolie, jelmer: ok, I'll update releasing.txt and will announce it when it's available (ping me if I forget)
<vila> poolie: on my RM plate this week: freeze 2.4.1 (2.5b1 will be next week) (https://launchpad.net/bzr/+milestones for the overview)
<Riddell> vila: I don't know I'm afraid, when I try it locally pristine tar works fine
<vila> Riddell: ok, thanks
<Riddell> using .bz2 can't be the issue, plenty packages use that
<jelmer> vila: what pristine-tar version is on jubany?
<jelmer> pristine-tar 1.03 fixed a bzip2 issue when the bz2 compressor was changed
<vila> jelmer: 1.11ubuntu1~0.IS.8.04
<jelmer> hmm
<vila> jelmer: may be unrelated, I was surprised mainly by all failures occurring being for kde and was wondering if something changed there recently
<jelmer> vila: I can't find much that could be related; did KDE perhaps change the way they create their tarballs?
<poolie> ok guys i'm off to squash
<poolie> have a good day
<vila> jelmer: thanks for looking, I'll dig later to better understand the issue and let you know (cleaning up my plate from other stuff right now)
<vila> poolie: you too !
<jelmer> have fun poolie :)
<vila> jelmer: I started using https://code.launchpad.net/~vila/udd/analyze-log-imports/+merge/74057 to get a better understanding on when imports succeed and where they come from (ubuntu/debian)
<vila> jelmer: the vast majority todat are from debian (sid, wheezy) may be that's where something occurred recently
<jelmer> vila: are you sure it's bz2 files, not xz files?
<Riddell> jelmer: did you get PQM error messages from https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 and https://code.launchpad.net/~jr/bzr/i18n-topic-help/+merge/73653 ?
<vila> jelmer: no, not sure, just read the p-i web site so far
<jelmer> Riddell: ah, yep. Let me see if I can find them and forward to you.
<vila> Riddell, jelmer : In case you missed it, mthaddon should be very close to provide the new pqm
<Riddell> the pqm queue is empty, the perfect time to do a switcheroo
<vila> Riddell, jelmer : So send one submission at a time so you can use the new one sooner ;)
<jelmer> hehe
<jelmer> Riddell: forwarded
<Riddell> I do wish PQM fail logs didn't include all the expected failures
<jelmer> Riddell: it should be possible to add a subunit filter to filter them out
<lifeless> in pqm even
<lifeless> change the filter invocation
<Riddell> who's our unicode expert?
<jelmer> Riddell: probably jam, though any of us know a fair bit about it
<jelmer> Riddell: oh, jam and mgz I guess
<Riddell> this solves my problem but it doesn't look very elegant gettext(unicode(fmt, 'utf-8')).encode('utf-8')
<Riddell> and is probably incorrect if not using utf-8
<jelmer> Riddell: I think generally we try to make sure we know what the encoding is of things we handle :)
<jelmer> Riddell: where does fmt come from?\
<Riddell> it's https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547  and fmt is the error string
<Riddell> and bzrlib.tests.test_errors.TestErrors.test_duplicate_record_name_error is the test case I need to fix
<jelmer> Riddell: it looks like our (de-facto) policy is to have _fmt contain utf-8
<jelmer> hmm, though there are a few exceptions
<jelmer> Riddell: perhaps check the type and raise a deprecationwarning if _fmt has a different type than what you expect
<Riddell> well the type is just str I think
<jelmer> Riddell: some things in bzrlib.errors use unicode for their _fmt
<Riddell> so that's unlike to work with my solution above
<jelmer> Riddell: gettext requires a bytestring I guess?
<jelmer> Riddell: in that case it seems most reasonable to:
<jelmer> check if type(fmt) == unicode, and if it is, convert to utf-8 (perhaps after printing a deprecation warning)
<jelmer> after that, simply passing fmt to gettext
<jelmer> hmm, I guess it's the other way around
<Riddell> yes
 * jelmer hopes he is still making sense
<jelmer> Riddell: either way, your solution looks reasonable though we'd probably have to make sure to cope with the situation where a fmt is passed in that has type "unicode"
<Riddell> so if it's a str() convert to unicode, if it's unicode issue deprecation warning and pass to gettext direct?
<jelmer> Riddell: Yeah, that seems the most reasonable to me. The only thing I'm not sure about is whether we want fmt to be unicode or utf8 by default
<jelmer> Riddell: we seem to've gone for utf8 in a lot of places though, and that's what we do for almost all _fmt strings at the moment
<jelmer> vila, jam: ^
<Riddell> jelmer: by utf8 you mean a str that contains utf8 bytes?
<vila> jelmer: the ~consensus is to: 1) wait as long as possible before encoding 2) default to utf8 is nothing better is known
<vila> that doesn't really answer the decoding though
<vila> Riddell: 33	+from bzrlib import i18n, tests, errors, workingtree
<vila> use multiple lines sorted to avoid conflicts ;)
<vila> 56	+ err = str(e)
<vila> Riddell: ask mgz, but I'm pretty sure he will object ;)
<vila> Riddell: unicode issues make my head spin, I know mgz have spend quite some time to get things right in the subunit/testtools python2.4 -> 3.x to notably, so I'll defer to him there
<Riddell> vila: object to str(e) ?
<vila> yeah
<vila> because. among other things,  some paths may be involved when reporting an error
<vila> Riddell: Oh, and don't feel bad, http://package-import.ubuntu.com/status/ mentions 58 + 10 + 5 + 2 (and probably some I miss) failures related to UnicodeError...
<vila> so it's not like you're alone in this boat
<Breedlings> hi folks, I'm struggling with setting up .htaccess to limit access for checkouts. Can anyone advise please?
<Riddell> https://code.launchpad.net/~jr/bzr/i18n-errors/+merge/73547 updated if anyone wishes to eye over again
<jelmer> Riddell: we typically use .decode("utf-8") or safe_unicode to convert to utf8
<jelmer> that's a minor nitpick; it'd be great if somebody could also have a look wrt the bigger picture
<Riddell> ok safe_unicode now in
<Quintasan> jelmer: Do we have git branch support in LP now?
<jelmer> Quintasan: no, that branch has not yet landed
<soren> jelmer: Is it far off, you think?
<davi_> jelmer, hi, had some limited success with round tripping support. mostly works, but there are a couple of issues. subsequents pushes (-r N) to the repository fails with exception, but pull from the git repository works. another thing is that partial pushes attempt to get all tags, which is bound to fail. should i report bugs for these?
<jelmer> soren: it's ready, just waiting to land at this point
<jelmer> soren: we've also just updated to bzr 2.4 so I'd like to make sure that's all working without problems before landing the colocated branch work
<soren> jelmer: So.. Less than a month's time?
<jelmer> soren: definitely.
<soren> Cool beans.
<jelmer> soren: well, I should know to never make promises like that. But really weird things would have to happen if it doesn't land within a month.
<jelmer> davi_: Can you perhaps comment on the roundtripping bug with what you've found?
<davi_> jelmer, sure
<jelmer> s/if it doesn't/for it not to/
<jelmer> Riddell: hmm
<jelmer> Riddell: I just realized, one of the things we'll have to take into account when translating errors is how this interacts with errors sent by remote servers
<Riddell> jelmer: mm
<Riddell> I can do some tests
<Riddell> but first I need to write this app developer week talk
<vila> jelmer: The more I see you work on foreign plugins the more I think some of these plugins should land into core...
<vila> jelmer: with optional dependencies may be...
<vila> s/optional/soft/
<jelmer> vila: I'm pretty happy with the current situation. What advantage would having them in core have?
<vila> batteries included, less regressions when something change in core
<jelmer> vila: we can't really do batteries included as we can't reasonably ship the dependencies of the foreign plugins
<vila> it may also help to refine the core design by exposing the plugin needs
<jelmer> vila: unless you want to ship copies of the apache libraries, svn libraries and subvertpy for bzr-svn, the mercurial source code for bzr-hg and dulwich for bzr-git :)
<vila> yeah, that's why I said 'soft' dependencies
<jelmer> that's not really "batteries included"
<vila> yeah but I think you get what I meant ;)
<vila> pycurl is such a  soft dependency for example, used if present
<jelmer> vila: I'm not sure what shipping the foreign plugins really adds in that case, as the user will still have to install e.g. python-subvertpy
<vila> but if you don't support the idea, never mind, there are arguments both ways
<vila> sure, but that can be addressed with a friendly warning, etc
<jelmer> vila: for now it's not really possible anyway, as the plugins don't pass the bzr.dev testsuite
<vila> your status.net remark about pull <git> ; push <svn> made me think about it
<vila> jelmer: yup, I know
<vila> jelmer: the counter-argument is that the work you're doing right now can't be done if they were part of core
<vila> hmm
<vila> well "can" be done but probably not as cleanly
<jelmer> vila: I like the idea of making it easier for end users to use the foreign plugins, but I don't think that necessarily means including them in the core
<vila> I see
<vila> and agree ;)
<jelmer> vila: I think it's already fairly easy to get the foreign plugins installed on a Linux system. We seem to do alright for bzr-svn on Windows and Mac. bzr-git isn't included in the windows installer. Not sure about bzr-git on Mac.
<vila> ...and no idea about other distros
<vila> I see no mention of git in the mac installers
<jelmer> vila: do you know about "whohas" ?
<vila> no, is that a command, an IRC nick, something else ?
<jelmer> vila: It's a command, from the "whohas" package in Ubuntu
<jelmer> vila: try "whohas bzr"
<vila> wow
<vila> hmm, we need to find an openSUSE maintainer :-/
<fullermd> Jeez, git is a pain to use...
<vila> fullermd: try bzr-git ;)
<Riddell> vila: we need opensuse packages?
<Riddell> I've done those before
<vila> Riddell: `whohas bzr` says openSUSE carries 2.0.5...
<Riddell> ** Talk on Bazzar Explorer in 5 minutes in #ubuntu-classroom
<mgz> hm, Riddell's gettext on errors branch is a fun set of problems.
<Riddell> uh oh
<nigelb> Riddell: ping
<Riddell> nigelb: hi
<nigelb> All set? (sorry about the schedule mistake)
<nigelb> Could you join #ubuntu-classroom-backstage as well, in case something goes wrong, or you need help :)
<Riddell> what schedule mistake?
<nigelb> "it gives the full power of tools like git but it's understandable to people other than Linus" -- I'm always going to use this when I talk about bzr.
<nigelb> Riddell: Nice talk.
<nigelb> LOVED your description of bzr :)
<Riddell> thanks nigelb
<Riddell> mgz: what problems do you think it has?
<mgz> eg:
<mgz> _fmt = 'Permission denied: "%(path)s"%(extra)s'
<mgz> return gettext(unicode_fmt).encode('utf-8')
<mgz> 'Lupa ev\xc3\xa4tty: "%(path)s"%(extra)s' % {'path':u'.', 'extra':''}
<mgz> try evalling the last line.
<mgz> the problem is the error module is pretty confused already, so it's hard to cleanly add in gettext
<mgz> basically, mixing str and unicode types breaks when non-ascii is involved, and some things we want to use with errors are bytes, and some (like paths) are unicode
<mgz> currently _fmt is ascii (are there any exceptions?) so provided the inputs are only one or the other, we're fine
<mgz> but if _fmt becomes some non-ascii utf-8 string from gettext, more things start breaking
<mgz> so really you're exposing existing problems rather than creating new ones.
<mgz> but using osutils.safe_unicode is just wrong ;)
<Riddell> mgz: why is it wrong?
<mgz> because if you don't know the type of the input, you can't safely handle it
<mgz> it's a check in the wrong place.
<mgz> one thing I don't completely understand is the preferred input for gettext-the-python-module
<Riddell> mgz: it might not have one
<Riddell> generally it's going to expect just ascii characters
<mgz> and it will always return unicode?
<mgz> gettext proper has the normal mess of encodings
<Riddell> yes it returns unicode strings
<jelmer> mgz: what's wrong with using safe_unicode if we know the input is going to be utf8 or unicode ?
<mgz> jelmer: we very seldom do, and when we actually do, that's just a bad api - pick one or the other
<jelmer> mgz: sure, I agree we should pick one or another but we can consider one deprecated, which I think Riddell's patch does
<mgz> the common case is often utf-8 or ascii, but should really be looking at LC_MESSAGES or similar environmental settings
<jelmer> mgz: this is about the contents of BzrError._fmt, which would be set by a programmer. I think we require utf8 or unicode there.
<mgz> I don't see why we can't just require ascii.
<mgz> and write a test to that effect.
<jelmer> mgz: what if we ever need to use a non-ascii character in a format string?
<mgz> then we break that error for anyone with LANG=C? doesn't seem worth it.
<mgz> I don't understand from that branch (having not followed naoki's changes that closely) is how we're getting all the _fmt strings out for translation, I guess it's a seperate step?
<Riddell> yes that's hidden in export_pot.py
<Riddell> which is a funny way to do it compared to just using  gettext() around all the strings
<mgz> it's a side-effect of Python I guess.
<mgz> we don't want to do the translation at byte-code compile time
<mgz> wait, wrongly phrased
<mgz> class definition time.
<jelmer> it would be neat if we could do it at byte-code compile time.. :)
<mgz> Riddell: okay, so the only thing I think that really needs fixing before landing is
<mgz> +            return gettext(unicode_fmt).encode('utf-8')
<mgz> remove the encode.
<mgz> there's no problem with _fmt being unicode there, calling str() on an exception encodes to utf-8 anyway, and mixing a utf-8 translation and unicode path would be common and break everything
<Riddell> mgz: then this fails
<Riddell> ./bzr selftest -s bzrlib.tests.test_errors.TestErrors.test_duplicate_record_name_error
<mgz> that's not suprising, but fixing that one error is easier than fixing every error that includes a path
<Riddell> but the test looks valid to me
<mgz> I'd make the exception decode the name.
<mgz> -        self.name = name
<mgz> +        self.name = name.decode("utf-8")
<mgz> then the test would pass as written.
<mgz> would be nice to delay that till the format step, but there's no simple way to do that.
<Riddell> but aren't there other errors which will need the same?
<mgz> probably, they're completely inconsistent at the moment.
<mgz>     raise errors.DuplicateRecordNameError(name_tuple)
<mgz> huh?
<mgz> in bzrlib.pack  ...but... variable seems to be a string despite being having 'tuple' in the name
<mgz> or, no, it is a tuple, that will something... gr...
<mgz> Riddell: adding a test with an error _fmt string that's translated would be helpful I think...
<mgz> maybe make the ZzzTranslations thing use more than just ascii?
<mgz> then the test you added would fail.
<Riddell> ok thanks mgz, I've got to go out now
<mgz> bye! I'll write a few things in the mp.
<aquarius_> in Ubuntu, /usr/share/pyshared/bzrlib/tests/ftp_server/pyftpdlib_based.py contains a test for bzr that uses pyftpdlib, but... pyftpdlib doesn't seem to be packaged?
<mgz> that certainly was an issue... there's a bug for it somewhere
<mgz> bug 781140
<ubot5> Launchpad bug 781140 in Bazaar "Missing test coverage for FTPTransport, needs pyftplib" [Medium,Fix released] https://launchpad.net/bugs/781140
<aquarius_> aha
<aquarius_> nice one :)
<AuroraBorealis> so i'm trying out the 'sign always' thing in bzr where it uses my gpg key
<AuroraBorealis> but where is it finding my gpg key? i haven't told it where it is and it keeps saying my passphrase is incorrect
<mwhudson> AuroraBorealis: it runs gpg
<mwhudson> so if echo '' | gpg --clearsign works, probably bzr will to
<mwhudson> o
<AuroraBorealis> well im on windows so i have not set it up really
<AuroraBorealis> and i have no idea how to set it up to use my key
<AuroraBorealis> but it somehow is using my key
<mwhudson> how can i make --show-base the default for merge ?
<mwhudson> i guess an alias works
<poolie> hi all
<mgz> hey poolie.
<poolie> hi there
<mgz> confusing bug numbers... I thought launchpad just gave me the same thing twice
<mgz> but it's 842223 and 842233
#bzr 2011-09-06
<poolie> mgz, heaven help us when we get to 7 digits
<poolie> maybe we can have optional punctuation: 184-2223
<poolie> biab
<arnetheduck> hi, just noticed you forgot to blame me for the log matching in http://doc.bazaar.canonical.com/latest/en/release-notes/bzr-2.5.html#bzr-2-5b1 =)
<vila> arnetheduck: the way devs ususally take credit is to add a news entry in doc/en/release-notes/bzr-x.y.txt, unfortunately no reviewer reminded/explained that to you :-/
<vila> arnetheduck: it's not too late to either send an email to the mailing list with the entry you want or file a merge proposal (that will certainly be approved ;)
<vila> arnetheduck: sorry about the confusion there, I really appreciate this feature (I even encountered a case where I suggest to use it only to be reminded that it was available only in 2.5 ;)
<jelmer> grar
 * jelmer does the mumble configuration dance
<Riddell> ping vila
<Riddell> no jam I guess
<vila> jelmer, Riddell, jam: poolie sent an email saying he will be off
<vila> Riddell: yeah :)
<Riddell> vila: that's no excuse for you to skive off!
<vila> hehe, I'm not !!
<vila> jelmer: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29
<zyga> ho
<zyga> hi
<zyga> how is bzrlib expected to be initialized on python 2.4 where there is no with support?
<vila> zyga: bzr-2.3 is the last stable version supporting python-2.4
<vila> zyga: 'with' is not used there
<zyga> vila, so just bzrlib.initialize() and "go" ?
<vila> zyga: that's what the doc string says, yes
<Guest95861> Hey all â I think this is probably a really obvious question, but I just cannot seem to find an answer. I have a Launchpad project that I was doing some work with, that I then decided to update my local code from upstream. I performed a bzr merge, but now that left me with uncommitted changes locally (not my changes, they are the changes from upstream)
<Guest95861> What did I do wrong?
<Guest95861> Performing additional bzr merges complains about the uncommitted changes
<Guest95861> The actual thing I want to accomplish is to have my repo look like the upstream repo
<jelmer> Guest95861: hi
<jelmer> Guest95861: you didn't do anything wrong - you have to commit the merge
<Guest95861> Oh! Thank you!
<Guest95861> I thought committing it might make my local copy go out of sync
<supton> is `bzr pull --overwrite -rOLDER_REVSION_THAN_CURRENT` really as dangerous as it looks?
<supton> as in, it permanently stomps on all local commits
<supton> ...that are not available from the pull repos
<AuroraBorealis> if all else fails, just make a backup before you do anything
<jelmer> hi supton
<supton> hi jelmer
<jelmer> supton, it removes the reference to those revisions from the local branch
<jelmer> supton, but the revisions are still available from the repository, you should be able to get those revisions back from the repository by using "bzr heads"
<supton> jelmer: so say I checkout... `bzr branch -r123 lp:~seanupton/+junk/something` and then make a local commit to r124 in that branch (but never push anywhere), then my automated build tool does a `bzr pull --overwrite -r123` in that branch.  What happens to local r124?
<jelmer> supton, the branch gets updated to point at r123
<jelmer> but the contents of r124 are still in the repository
<supton> FWIW, I am adding revision-pinning support to the bzr support of an automated build tool (mr.developer, which is an extension for zc.buildout). https://github.com/seanupton/mr.developer/commit/47f83fa4d59d5f06373c7cb2f91e6d00bf07c741#L1R63
<jelmer> supton, ah, cool
<jelmer> supton, it's a pity you're calling out to bzr rather than importing bzrlib
<supton> jelmer: does bzr heads command exist in 2.4.0?
<jelmer> supton, yes, but it's a part of the bzrtools plugin
<supton> jelmer: I'm assuming that the goal of upstream folks for mr.developer is few library deps.
<supton> jelmer: ah, okay, I'll install bzrtools
<jelmer> supton: that seems silly, given installing bzr will pull in that library anyway
<supton> jelmer: yeah, but the typical assumption among a lot of folks using buildout is that they are not using the system python
<supton> which means they don't want to install bzrlib in their buildout or for the python running their apps when it is installed (sufficiently, as far as they care) in the system python's site-packages
<supton> so folks like me are using macports or apt to get bzr, bzrtools, bzrlib, etc and then only lightly automating around them from python app deployments that are not using the system python at all.
<poolie> hi jelmer, all
<jelmer> g'morning poolie
<jelmer> I hope you're feeling better
<poolie> a bit
<poolie> well, mostly better
<poolie> might go back to bed in a bit though
<poolie> how are you?
<jelmer_> alright, doing some more foreign branch hacking before sleep
#bzr 2011-09-07
<wallyworld_> poolie: dumb question. bzr branch stacking is recursive right? A stacked on B which is stacked on C etc
<spiv> wallyworld_: yes
<wallyworld_> spiv: thanks
<wallyworld_> spiv: how's google?
<spiv> Pretty good!  Commuting and working in an actual office has taken a bit of getting used to, though.
<spiv> But the office has better espresso machines than I have at home :)
<wallyworld_> spiv: i just bought a new dual boiler espresso machine. but i imagine google's would be better! what are you working on?
<spm> o/ spiv
<spiv> wallyworld_: This: http://code.google.com/apis/maps/documentation/places/
 * wallyworld_ looks
<spiv> Hi spm
<wallyworld_> looks interesting. of course, now you have an excuse to go and get a Samsung Galaxy Note or other cool smartphone for "work" purposes :-)
<vila> hi all !
<fullermd> Eh?  You're not allowed to show up before breakfast...
<vila> yeah. I took my breakfast
<fullermd> I haven't, though.
<Riddell> happy Wednesday
<vila> Riddell: thanks ! Happy morning to you !
<fullermd> vila: OK, now you can show up   :p
<vila> hehe, file and fixed a bug in the mean time ;)
<vila> filed
<fullermd> Shoot, that's nothing.  I've created TWO!
<vila> you win :)
<vila> jelmer_: ping, 2.4.0 on jubany ? I've lost track of progress there, care to refresh ?
<vila> jelmer_: refresh *my memory*
<jelmer_> vila: there's an open rt in the queue
<fullermd> jelmer_: So, I got a little confused in the colo discussions.  Is this expecting to use a new format or not?
<jelmer_> fullermd: eventually, no. it's expecting to be an addition to 2a
<fullermd> Ah.
<jelmer_> fullermd: in the mean time, we might do the development in a separate format so we can be sure that whatever changes we make to 2a are correct
<jelmer_> Riddell: hi
<jelmer_> Riddell: do you perhaps know what this error is about? http://pastebin.ubuntu.com/684394/
<Riddell> hmm, it doesn't think it has expired
<Riddell> jelmer_: what does  gpg --list-key 4F8D1513  give you?
<jelmer_> Riddell: this is on one of the buildds
<jelmer_> Riddell: I've recently added python-gpgme to the build deps so we can run the gpg tests, and this is the only remaining failing test
<Riddell> SIGNATURE_KEY_MISSING = 1   so it thinks the key doesn't exist
<Riddell> but it should be the expired_key in bzrlib/tests/test_gpg.py
<Riddell> that test doesn't have a self.import_keys()  so maybe that's what is missing
<jelmer_> I can reproduce the issue on my local machine with a different account (without writable homedir and missing ~/.gpg), although it gives (2, None) there rather than (1, u'4F...')
 * jelmer_ tries
<Riddell> that fixes it for me, testing with a new user
<jelmer_> Riddell: What if that users' ~/.gpg doesn't exist and isn't writable?
<Riddell> if it doesn't exist then gpgme will make it, but if it's not writable I don't know but I guess something will fail
<jelmer_> Riddell: we shouldn't really be touching anything out of the test directory when running the tests; can we perhaps override the home directory gpgme uses?
<Riddell> no, I think gpg is pretty stuck on ~/.gnupg
<Riddell> I couldn't find any way to change it when I looked
<jelmer_> Riddell: it looks like gpgme has a way to set the home directory, but I guess pygpgme might not expose it
<jelmer_> Riddell: I'll file a bug against bzr/pygpgme
<jelmer_> Riddell: Can you propose that self.import_keys() fix, or should I?
<Riddell> jelmer_: I'll do it
<jelmer_> Riddell: thanks
<jelmer_> Riddell: it looks like gpgme should honor the GNUPGHOME environment variable
 * jelmer_ patch0rz
<Riddell> jelmer_: bzr-explorer 1.2.1 seems to be in its debian packaging reponsitory but not in debian, are you able to upload it?
<jelmer_> Riddell: sure, one sec
<jelmer_> Riddell: do you mean 0.21.1-1 ?
<Riddell> jelmer_: bzr-explorer (not qbzr)
<Riddell> although qbzr could do with the upgrade too I see
<jelmer_> Riddell: I'll have a look at aboth
<jelmer_> s/a//
<jo-erlend> what do you think about using bzr to version Audacity projects?
<jelmer> hi jo-erlend
<jelmer> jo-erlend: I'm not too familiar with the Audacity format, is there anything in particular you think might be problematic?
<jo-erlend> fairly large files.
<jelmer> jo-erlend: how large is large?
<fullermd> Well, presumably WAV's for the like, so you'd get dozens to low hundreds of megs...
<jo-erlend> well.. A small project of a few minutes often consumes hundreds of megs. But bzr doesn't really care about the total, only the largest file?
<jelmer> jo-erlend: yeah, the max memory usage would probably be the size of the largest times 2 or 3
<ccxCZ> jo-erlend: if you don't need full VCS feature set, I would actually suggest rdiff-backup
<jo-erlend> that might be something to consider, actually.
<poolie> hi
#bzr 2011-09-08
<\u03b5> Ummm, how do I undo either unshelving or merging?
<\u03b5> bzr unshelve slipped out of my fingers before I committed a merge
<spiv> \u03b5: with a bit of difficulty :/
<\u03b5> I begin to suspect that :-)
<spiv> \u03b5: I think the simplest way is something like do the merge again in a fresh tree, then the diff between the two trees is the change you unshelved
<\u03b5> good idea!
<spiv> \u03b5: so perhaps make a fresh working tree, do the merge there, and commit it
<poolie> hi spiv
<spiv> \u03b5: then just just copy over the files from the other tree (or you might even be able to 'bzr merge --uncommitted' from it)
<spiv> \u03b5: or something along those lines
<\u03b5> I get the idea, thanks :)
<spiv> Hi poolie!
<\u03b5> yep, bzr got the hint with merge --uncommitted
<\u03b5> well, thanks again
<MvG> Good morning! I'm just thinking about bzr log and its --include-merges option. What it actually does is not so much about the merges themselves, i.e. the commits with two parents, but instead about the sidelines, i.e. the commits not in the left-parent-only mainline. So I wonder whether that option should be renamed to --include-sidelines, with the old name kept for compatibility but not advertised through help any more.
<MvG> The main reason I'm thinking about this is because I believe it would make sense to have an option --exclude-merges or --without-merges that would omit any merging commit, i.e. those commits that have two parents. The rationale being that usually the merges contain little actual modifications, whereas the non-merging commits contain the changes. So especially for a change log it would be useful to only have the non-merging commits to document what c
<MvG> But having two options, --include-merges and --exclude-merges, which don't do the opposite of one another and which are even expected to be used together would be very confusing indeed. And I believe that calling the two-parent-commits "merges" makes more sense than calling the sidelines "merges", so if you agree, I'd rather change the name of the current option.
<mlh> oh! Et tu Spiv?
<mlh> congrats :-)
<vila> I'll freeze 2.4.1 today, if you have objections, yell ;)
<poolie> hi mvg, vila
<vila> hey !
<vila> oh, hi MvG !
<MvG> Hi there!
<poolie> mvg i think the feature basically makes sense
<poolie> of course for some branches of some projects, like bzr, everything will be a merge
<poolie> you could change it to --include-merged
<poolie> though perhaps a one-character difference is confusing in other ways
<MvG> poolie: I'd have it --include-sidelines by default, overridable.
<poolie> i mean rather than 'sidelines' you could call them 'merged'
<MvG> Ah, sorry, my misunderstanding.
<MvG> Hmmm. Rather asking for confusion, without giving any benefits, as any form of backwards compatibility depends on no change at all.
<MvG> So if you have to change it, it doesn't matter by how much.
<MvG> And I believe "sideline" is the well established bzr term for these things, right?
<MvG> By the way: can you reproduce bug #842695, or is there something broken in my local clone?
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
<MvG> In other words, do you get the same unrelated commits, or do you get the ones I'd have expected?
<poolie> we do call them 'mainline'
<poolie> not specifically 'sideline' that i've heard, or not so commonly
<poolie> but it's probably a pretty good name for it
<poolie> mvg, so regarding bug 842695
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
<MvG> yes?
<poolie> sorry, phone
<poolie> so john seems to be saying that if you don't give --include-merges
<poolie> it tells you about the nearest inclusive mainline commit
<poolie> which i think is reasonable
<poolie> otherwise --no-include-merges would tend to print nothing
<poolie> it does mean it's more than just filtering though
<poolie> so then there are two questions
<poolie> - is it getting it wrong
<poolie> and is a better behaviour possible
<jam2> morning all
<poolie> jam, can pqm-submit work with a non-local source branch?
<vila> poolie: IIRC that's what spiv change was about months ago, --ignore-local and --public-location ?
<jam> poolie: i've never tried the non-local thing
<jam> I generally copy it and use --public-location
<jam> but I think vila has a point
<vila> poolie: revno 61 in the pqm plugin
<jam> if you --ignore-local it shouldn't care
<vila> arf, and this revno introduces a StackedConfig in pqm-submit... jelmer, yet another use case for stacks
<Riddell> so do we have a shiny new PQM?
<poolie> hi jam, i'll try to reply about metadir/colo stuff later
<poolie> i'm inclined towards having it in trunk though
<poolie> but i'll try to explain this
<poolie> or to catch you to talk about it
<vila> Riddell: not yet, mthaddon is working on it, auth issues (see #launchpad-ops)
<MvG> poolie: Sorry, read your reply only now. Wrt bug 842695: when listing mainline commits only, it is doing the right thing. It is only when including sidelines that it somehow selects completely wrong commits, which apparently have nothing at all to do with the path specification given as an argument.
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
<MvG> I guess it's somehow related to the fact that the dir was once a separate branch which was later joined, but that in itself isn't enough for a test case reproducing this.
<jelmer> vila: I'm not opposed to stacks, I like them. I don't see the use case for a stack registry yet though
<vila> jelmer: right *yet* is probably the key word here ;)
<vila> jelmer: liaise with mthaddon if your current pqm submission fails or exhibit any weird behavior, you're on the new pqm \o/
<jelmer> vila: I can tell, it's fucking quick
<vila> :)
<vila> jelmer: and that's without /tmp as tmpfs nor --parallel :-D
<mthaddon> it's succeeded
<mthaddon> I'm about to go to lunch, but after lunch will get tmpfs set up and log syncing sorted
<jelmer> mthaddon: Thanks *very* much for setting that up!
<mthaddon> you're welcome
<mthaddon> now if launchpad would just update https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev ....
<vila> mthaddon: bzr missing tells me jelmer's patch has landed
<jelmer> yeah, Launchpad has now picked it up as well
<MvG> jelmer: is the fix for bug 842993 a real bug fix or rather an improvement?
<ubot5> Launchpad bug 842993 in Bazaar "reconfigure silently ignores one of two requests" [Medium,Triaged] https://launchpad.net/bugs/842993
<MvG> Sinde when does bzr accept translations on lp? Thinking about doing a bunch of German ones...
<Riddell> MvG: since yesterday
<Riddell> I haven't made an announcement yet
<Riddell> but go ahead, it would be good to have a real language to test with, and keep an eye out for problems which can be reported to me
<MvG> Reasonable positions for line wraps are hard to decide in the LP UI with its variable-width font for the translation boxes...
<MvG> Fixed width for both original and translation and boxes at 80 cols would be better.
<MvG> Ah, as I'm not an official LP translator, I can only make suggestions, but they don't count as translations, even in the absence of official translations. Well, so be it.
<Riddell> I was strongly advised to set that else the quality of translations is very poor
<Riddell> I'm sure it can be hard for you to join the translations team
<Riddell> you could also just translate the .pot file directly
<jelmer> MvG: either way, it's a good change :)
<jelmer> MvG: I'm not sure if it should be for IMPROVEMENTS or BUG FIXES, up to you
<jelmer> how upset were you when it didn't do what you expected ? :)
<MvG> Not at all upset about it not doing the stuff I wanted, but rather annoyed about it not printing any warning. After all, I expect commands to either succeed ot tell me about it. Pushed it as a bug now.
<MvG> Riddell: Joining the team isn't an option, otherwise I'd feel obliged to do more translations than I can reasonably afford. I'd rather write useful apps in that time.
<MvG> I won't do a full translation of bzr for the same reason, but will see how far I get.
<MvG> jelmer: do you need another merge proposal to merge the release notes from lp:~gagern/bzr/bug842993-reconfigure ?
<jelmer> MvG: please
<lamalex> hey guys,  i can never remember the syntax for doing this.. i want to revert out a single revision that is not HEAD
<lamalex> it's not just bzr revert -r 36 is it?
<lamalex> given rev 36 is the one i want to pull out
<Peng>   To remove only some changes, without reverting to a prior version, use
<Peng>   merge instead.  For example, "merge . --revision -2..-3" will remove the
<Peng>   changes introduced by -2, without affecting the changes introduced by -1.
<poolie> hi all
<Noldorin> hey jelmer
#bzr 2011-09-09
<jelmer> 'evening poolie, Noldorin
<Noldorin> hi :-)
<Noldorin> how's collocated branch project, i was going to ask?
<jelmer> Noldorin: which bit in particular?
<Noldorin> jelmer, all bits. lp, bzr, bzr-git :-)
<poolie> hi jelmer
<poolie> so my half-baked idea was that we should just merge the metadir colo stuff
<poolie> putting it in a side branch has never seemed to work well, because people don't in practice test it much either as users or developers
<poolie> also, once you ask users to test it at all, they will basically count on it
<poolie> it's hard to do more than a smoke test without putting real data in
<poolie> i think the most you can expect of that kind of tester is that they be willing to have a rougher ride than they normally did
<poolie> which i suppose is kind of what dev formats went towards
<jelmer> poolie: I'm a bit wary about using a side branch too, as it just means having to do lots of merge work (and probably bug fixing) later rather than continuously
<poolie> that too
<jelmer> poolie: John makes a good point about not being able to change it once it's landed though, especially as we're changing an existing format rather than introducing a new one
<poolie> also, with the best of intentions, i don't things get the same level of review until they're actually going to come in
<poolie> and also eventually landing them as one big bump makes things harder
<poolie> that is true
<poolie> i wonder if we can do something about saying "it will be stable by 2.5.0"
<poolie> (and less stable during the betas)
<poolie> generally speaking i don't like to make plans that rely on predictions like that but it's a tool we can use
<jelmer> poolie: I think that might be a reasonable compromise
<Noldorin> jelmer, hmm....?
<Noldorin> poolie isn't hte only one here ;-)
<jelmer> poolie: especially as I don't really expect us to make changes to the format, but it's nice if we can crawl back through the trap door if we really have to
<jelmer> Noldorin: sorry
<jelmer> Noldorin: we're talking about colocated branches though :)
<Noldorin> it's ok
<Noldorin> oh right
<Noldorin> didn't notice
<Noldorin> hehe
<jelmer> Noldorin: so, the support for importing colocated branches on launchpad hasn't landed yet. No further changes are necessary to bzr-git
<Noldorin> ok cool
<Noldorin> and 2.5b1 coming soon?
<jelmer> Noldorin: yes, the 15th - https://launchpad.net/bzr/+milestone/2.5b1
<Noldorin> not soon enough ;-)
<Noldorin> but okay
<Noldorin> that's good
<Noldorin> jelmer, when is LP support coming?/
<jelmer> Noldorin: there's an approved branch that adds it, which still needs to land and then be deployed. So, hopefully a couple of days, perhaps more.
<Noldorin> jelmer, probably by time of 2.5b1 release though right?
<jelmer> Noldorin: probably, but they're unrelated
<Noldorin> jelmer, in terms of release, yeah i'd presume so...ok godo to know :0
<pippijn> hi
<pippijn> how can I show the diff between my own repository and upstream?
<bob2> diff or commits?
<pippijn> diff
<pippijn> I just need a complete patch against upstream
<poolie> pippijn: probably 'bzr diff -rsubmit' or 'bzr diff -rancestor:UPSTREAM_URL'
<poolie> inserting the right relative path there
<pippijn> upstream is lp:inkscape, I think
<pippijn> ah, I think it works
<pippijn> yep
<pippijn> thanks
<pippijn> but it has to connect to upstream for this.. isn't this information also in my repo?
<vila> hey guys !
<lifeless> pippijn: the data is, but the information about what is current isn't.
<pippijn> ok
<lifeless> pippijn: you can have an explicit local mirror of lp:inkscape if you like
<pippijn> it's ok for now
<lifeless> it would then be up to you to pull in changes into that mirror, but you could diff when offline
<pippijn> I'm not doing many diffs
<pippijn> and I'm certainly not doing diffs when offline
<pippijn> I'm only doing a diff when updating the patch in our (*puke*) svn repo
<lifeless> heh :)
<vila> vila_: Wrong machine ;)
<vila> Land ! bzr committers, land ! With our new shiny pqm, running 'make check' is down to 23 mins ! \o/
<vila> And that's without /tmp mounted as tmpfs AFAICS (S == say ;)
<lifeless> vila: do you have --parallel=fork in place ?
<vila> lifeless: not even :) But we don't need a losa for that, so I'm waiting for all losas tweakable stuff to be done before looking into it :)
<poolie> hi lifeless, vila
<vila> poolie: hello !
<poolie> hi there
<vila> I just did a 'bzr pull' on my bzr trunk and things look alarming !
<vila> can anybody running from source try a 'bzr missing' ?
<vila> I' afraid something may have gone wrong when switching on pqm maybe ??
<poolie> hm
<poolie> worked for me
<lifeless> vila: alarming in what way?
<poolie> what actually goes wrong?
<vila> http://paste.ubuntu.com/685803/
<vila> Note the 'Removed revisions'
<vila> where are they gone ?
<poolie>  ah, you should have said
<poolie> good question
<poolie> that does sound like something like the pqm branch being out of date
<vila> ha, ok, they are still there
<vila> look at revno 6124
<poolie> they're still merged?
<poolie> ok, so it was out of date, but jelmer's branch was based on the tip
<poolie> that's probably why it didn't fail to push to lp
<vila> yup
<poolie> well, that's a bit unfortunate but i think not worth doing anything about now
<vila> yup
<vila> sorry for the false alarm but well, that was unexpected
<lifeless> append_revision_only=False :P
<vila> my thoughts exactly
<poolie> could you get one of the losas to set that on our branches?
<poolie> i don't see why not
<vila> on the other hand pqm guarantees that under normal circumstances
<poolie> obviously there is a bit of horse-has-bolted
<vila> poolie: I kind of fear that it would make it harder to recover (we can ask for a push --overwrite if we want to fix such issues today)
<poolie> that's true
<poolie> so, we could ask them to push over it now and then remerge the later revisions
<poolie> that's not really clearly objectively better
<poolie> since none of the revisions that got pushed to the side were tagged for a release i think we should just live with it
<vila> poolie: oh yes, let's just live with it
<poolie> i'm glad you noticed though
<poolie> you did have me a bit worried there was some horrible corruption :/
<fullermd> I worry about corruption from vila all the time...
<vila> fullermd: thanks for recognizing my hard work !
<vila> I mean, I put a lot of effort into *not* fixing my tyops and such...
<vila> Because it provides such an endless source of tests...
<vila> stress tests even :)
<fullermd> Oh, totally.  I mean, if you didn't, people might start thinking your were a chatbot!
<vila> That's how you recognize aproject with a true TDD mentality: search for the most awkward member and nominate him as RM :-D
<poolie> i hope eliz's mail doesn't turn into a futile thread about what's reasonable or not
<poolie> there are a lot of things about windows that aren't reasonable
<vila> one key point here is that it's hard to setup a windows dev machine
<vila> as in: not documented enough or even automated
<vila> 573 spurious import failures
<vila> requeued
<vila> interestingly 8 other ones were qualified as spurious and retried automatically
<vila> i.e. the importer can already do that but not all cases are recognized
<vila> jelmer (huh, where are you ?), Riddell : investigating http://package-import.ubuntu.com/status/73aaec3da59a46ab68e18ea8c195a6e7.html aka PristineTarError, it looks like pristine-tar can't recognize the bzip2 produced here
<Riddell> I can't imagine what would be unusual about KDE's tars
<Riddell> although I can recreate it locally
<Riddell> "pristine-bz2 failed to reproduce build of kde-l10n-is_4.7.1.orig.tar.bz2"
<poolie> o/ riddell
<poolie> Riddell, vila, if either of you get a chance could you look into https://bugs.launchpad.net/udd/+bug/820671
<ubot5> Ubuntu bug 820671 in Ubuntu Distributed Development "no libvirt in maverick-updates or natty-updates udd trees" [Critical,Triaged]
<vila> Riddell: yup, me neither
<vila> Riddell: I digged a bit into pristine-tar itself, and well, once you found the code involved, it's basically try with this executable with this params and if you get a different result, barf
<vila> Riddell: so while I can't imagine *what* is different in kde, it's still surprising that *only* kde packages have triggered that so far
<Riddell> it works fine with older versions, just this version it doesn't like
<vila> Riddell: did they jump on bzip2 wagon ahead of time ?
<vila> which version of what ?
<vila> Riddell: wag: 32bits/64bits ?
<Riddell> pristine-tar from 4.6.90 to 4.7.0 works fine
<vila> Riddell: hmm, thanks for the detail
<Riddell> vila: I have an upstream asking for more information if he might be of use
<vila> Riddell: you mean kde upstream or pristine-tar upstream ?
<Riddell> vila: kde upstream
<vila> Riddell: ha
<poolie> i'm going to sign off soon
<vila> my understandin gso far is that it's a pristine-tar bug, but they will indeed need more information
<vila> poolie: enjoy your week-end !
<poolie> thanks, i hope to
<vila> Riddell: may be some change in bzip2 itself...
<vila> Riddell: if this is the case, people producing the bz2 should not be able to reproduce the issue with pristine-tar ?
<Riddell> that'll be a suse guy, I wonder if I can install pristine-tar on suse and try
<vila> may be unrelated but the bz2 I'm looking at has root/root as user/group for all files
<vila> nah, irrelevant, that's part of tar which bz2 don't read
<Riddell> "<bcooksley> suse 11.4+ use bzip2 1.0.6, debian stable has 1.0.5"
<Riddell> pristine-bz2 runs fine on suse with that tar
<Riddell> next step would be to try upgrading bzip2 on debian and try it
 * Riddell tries
<Riddell> "The current version is 1.0.6, released 20 Sept 2010"  hmm, we're slacking
<vila> Riddell: I tried running pristine-tar from sources and reproduced the issue...
<vila> Riddell: that was yesterday though and maybe I missed some point or used the wrong sources... let me double-check
<Riddell> vila: how do you mean pristine-tar from sources?
<Riddell> hmm, installing bzip2 1.0.6 doesn't seem to help pristine-tar
<Riddell> well that leaves one solution, move the UDD importer to a suse machine
<Riddell> :)
<vila> Riddell: bah, misread, that's bzip2 that needs to be updated ? But won't that break other tars ?
<Riddell> I presume bzip2 is backwards compatible
<Riddell> and mostly forwards compatible since these tars can be read by normals tools
<Riddell> however it doesn't seem to help
<vila> what I mean is that if we use a new bzip2 to recognize old ones, it may fails the way it fails today by using an old bzip2 to recognize new ones
<vila> Riddell: that's confusing... do you see what I mean ?
<vila> Guest27145: don't try to hide
<Guest27145> :)
<Riddell> vila: it might but surely it's going to be backwards compatible?
<Riddell> I wonder if libbzip2 is to blame rather than bzip2
<vila> Riddell: well, in this case, I'm afraid it means: so compatible you can't see a single difference :)
<vila> Riddell: but it's up to pristine-tar devs to speak on that matter, I'm not sure I understand all the cases here nor the way to address them
<jelmer_> vila, Riddell: have you seen bug 576119
<ubot5> Launchpad bug 576119 in libmemcached "Crash in Init() in memcached.hpp" [Undecided,New] https://launchpad.net/bugs/576119
<jelmer_> ?
<jelmer_> Debian bug 576119
<ubot5> Debian bug 576119 in pristine-tar "pristine-bz2 failed to reproduce build of kde-l10n-it_4.4.2.orig.tar.bz2" [Normal,Fixed] http://bugs.debian.org/576119
<vila> jelmer_: Yeah ! Of course not :)
<jelmer_> The changelog entry mentions -t to try harder, which I don't think bzr-builddeb uses yet
<jelmer_>        -t  Try harder to determine how to generate deltas of difficult bz2
<jelmer_>            files.
<jelmer_> worth a shot :)
<Riddell> all programmes should have a -t Try harder option
<jelmer_> heh
<Riddell> "pristine-bz2 will have to try especially hard to reproduce kde-l10n-is_4.7.1.orig.tar.bz2 (This could take a long time.)" I can see it breaking sweat
<jam> Riddell: I'm curious what it actually does. It sounds like it randomly samples time-stamps, whatever then bz2's it, then checks to see if the sha hash matches.
<jam> Which IMO certainly does fall into the "try especially hard"
<jam> having to indirect through *both* bz2 and sha would be terrible
<vila> -t takes indeed far longer and... doesn't work here :-/
<jelmer_> jam: it looks like it's indeed doing brute-forcing, but of the block size
<jam> jelmer_: who uses bz2 that doesn't just use -9?
<jam> (the default, and the highest level)
<jelmer_> jam: pbzip2, which is used by the KDE folks
<jelmer_> (p for parallel)
<Riddell> if I install SUSE's bz2 RPM onto my ubuntu system then pristine tar works fine
<Riddell> they do have some patches to it
<jelmer_> Riddell: interesting
<Riddell> this seems to be the offending patch  https://build.opensuse.org/package/view_file?file=bzip2-maxlen20.patch&package=bzip2&project=openSUSE%3AFactory&srcmd5=3ee4cf959e98e3ca50a881d1cdc13570
<vila> Riddell: so, in effect, they *reverted* to generate the old (< 1.0.3) .bz2 files
<Riddell> I guess so
<vila> so if this patch is not there, bzip cannot produce such files and pristine-tar is doomed
<vila> bzip2
<vila> the weird thing is that it seems that pristine-tar includes zgz just for this purpose (and use 20 there not 17)
 * vila lunch time
<jelmer_> vila: Do you know how the merge tool code works?
<Riddell> vila: shall I report a bug on pristine-tar or is there more we can look into?
<vila> Riddell: I think you've found enough evidence for the pristine-tar maintainers to see (especially the url above and the failing .bz2 from the package importer)
<vila> jelmer_: superficially yes
<vila> . o O (It's a bit surprising that bzip2 website doesn't mention any VCS archive)
<vila> Riddell: let me know how it goes, it would be nice to link that bug to a udd one too
<jelmer_> vila: I'm pretty sure it's in git
<jelmer_> vila: either way, lp:pristine-tar :)
<vila> jelmer_: bzip2 :)
<jelmer_> ah, sorry
<vila> jelmer_: hehe np, I made exactly the same mistake while talking to Riddell :)
<mthaddon> jelmer_: did you get an error email from PQM?
<jelmer_> mthaddon: I don't think I did - I got a confirmation email to say one of my branches had landed
<mthaddon> hmm, maybe it was just that the web UI was stale
<mthaddon> ok, thx
<mthaddon> vila: I think the web UI was just stale - carry on with your tests pls (one submission to any branch is fine - just want to make sure it goes through with tmpfs in place
 * vila prepares
<vila> mthaddon: I'll ping you first
<jelmer_> I've just submitted another one
<vila> jelmer_: against bzr.dev ? I'm preparing for older branches, 2.2 needs to be merged into 2.3 and up
<jelmer_> vila: yep
<vila> jelmer_: 1 failure (by the way, mthaddon is testing mounting /tmp as tmpfs so watch for related failures)
<jelmer_> vila: Yeah, just noticed. Not sure what that's about
<vila> mthaddon: I'm ready, waiting for your green light
<jelmer_> vila: btw, did I mention I got the number of failures from running bzr.dev tests against bzr-svn down to less than 100 yesterday evening?
<mthaddon> vila: go for it
<vila> jelmer_: the messages about tags updated is... yummy :)
<vila> jelmer_: no you didn't ! \o/
<jelmer_> vila: yeah, I noticed. I'll have a look at it later today
<vila> jelmer_: I didn't mean the bug I filed, I mean all other cases where it's great to have the feedbaclk ! :)
<vila> back
<vila> what with non-sense tyops !!1!!
<jelmer_> vila: :)
<vila> jelmer_: but now that I have a '1 tag(s) updated.' message, I wonder which tag it is :D
<jelmer_> vila: yeah, that might be useful to mention too, indeed.
<vila> jelmer_: I'll cowardly settle for a mutter() call :)
<vila> hmm, looking at .bzr.log is... interesting, I didn't realize there was that much noise there ;)
<jelmer_> vila: I think it makes sense to mention the updated tags in the output
<jelmer_> I guess the only odd case is if somebody actually updates 200 tags
<vila> well, I'd put it under -v with the revisions no ?
<vila> and in this case, well, 200 or 1000, you get what you asked for ;)
<vila> ha ha, xz incoming on jubany: http://package-import.ubuntu.com/status/pleiades.html#2011-09-09%2003:33:07.686923
<vila> jelmer_: what did you sat about xz ?
<vila> say
<vila> mthaddon: no noticeable difference with tmpfs, that's.. unexpected
<vila> mthaddon: you did the change *in* the chroot ?
<mthaddon> vila: yep, in the chroot
<jelmer_> vila: basically, xz is supported by bzr-builddeb; it happily calls pristine-tar
<jelmer_> vila: however, pristine-tar doesn't support xz properly yet, so it will just generate a delta that consists of the entire file
<vila> jelmer_: so we need a more recebt bzr-builddeb on jubany ?
<jelmer_> vila: well, didn't you update it recently? that version should have included xz support already
<jelmer_> however, even when we do have that it will be painful for big packages
<vila> jelmer_: I did, revno 607
<vila> jelmer_: well, jubany doesn't complain about pain ;) But here it fails
<jelmer_> ah, the support is there but it assumes lzma rather than xz
<vila> for the suffix ?
<vila> jelmer_: nm, I can see the source... but the source suggests it handles .tar.xz fine, and with tests >-//
<jelmer_> vila: that's just the upstream tarballs, not the stuff that's in debian
<vila> ha ok
<vila> mthaddon: my submission against 2.3 succeeded, I noticed the email is <pqm@cupussao> instead of <pqm@pqm.ubuntu.com> though
<vila> mthaddon: Patch Queue Manager instead of Canonical.com Patch Queue Manager while I mention nits...
<fullermd> Onoes, it's a free agent!
<mthaddon> vila: should we remove the tmpfs since it doesn't speed things up?
<jelmer_> vila: I'll upload a patch
<mthaddon> vila: have fixed (I think) the pqm@cupuasso part
<vila> mthaddon: yes, but that's the first time I see tmpfs *not* providing a huge boost
<vila> mthaddon: may be I'm confused because it makes a real difference when running with --parallel=fork ...
<jelmer_> vila:  lp:~jelmer/bzr-builddeb/tar-xz
<vila> jelmer_: what do you want me to do with that ? Review ? Test on jubany ? Deploy on jubany ?
<vila> jelmer_: oh, that's *instead of* not *in addition* ?!?!
<vila> jelmer_: I'm confused, part of this patch seem to implement 'rather than' while other so 'in addition' >-}
<jelmer_> vila: yeah - debian doesn't actually support .tar.lzma
<jelmer_> (xz is the second version of lzma)
<vila> jelmer_: ha, ok.
<Noldorin__> wha'ts the difference between bzr pull and merge?
<LeoNerd> pull is for when you are just behind on history, and just adding extra revisions
<LeoNerd> merge is for when you have diverged history, in a branch, and need to reconcile changes changes from both sides
<henninge> HI! Is there a PPA for bzr builder? I need to install bzr-bulider >=0.5 on lucid.
<AuroraBorealis> what is bzr builder?
<henninge> https://launchpad.net/bzr-builder
<henninge> I don't know exactly, I just need it to satisfy a dependency ...
<AuroraBorealis> what error is it giving?
<henninge> I am installing a package on lucid that has bzr-builder >= 0.5 as a dependency
<henninge> but only 0.2 is packaged
<henninge> This not really a bzr question, I guess.
<AuroraBorealis> hmm
<AuroraBorealis> build it using checkinstall?
<henninge> build what?
<AuroraBorealis> checkinstall will prodce a deb
<AuroraBorealis> i dunno if it will work with that though
<henninge> dpkg-buildpackage -b
<AuroraBorealis> building debs is like black magic. i have no idea how to do it otther then checkinstall =)
<henninge> that's ok ;)
<Noldorin> LeoNerd, so in certain cases merge and pull will do the same thing?
<Noldorin> i.e. when branches haven't diverged
<LeoNerd> Er.. pass. Not sure offhand. If there's no diversion I just pull
<Noldorin> heh ok
<AuroraBorealis> if the branch hasn't diverged then why are you merging :o
<Noldorin> that's not my question
<Noldorin> LeoNerd, there's also bzr merge --pull to confuse things more ;-)
<Noldorin> hrmm
<henninge> Noldorin: merge and pull are different.
<Noldorin> how so?
<Noldorin> in the case branches haven't diverged
<Noldorin> seems identical to me
<AuroraBorealis> doesn't pull/push make it a mirror?
<henninge> Noldorin: pull will pull in multiple revisions and put them in your branch.
<henninge> Nephyrin: merge will merge the revisions which you then need to commit.
<henninge> Noldorin: ^
<henninge> Noldorin: that creates only *one* revision  on your branch.
<Noldorin> henninge, ohh, got it!
<henninge> Noldorin: and merge --pull will use pull instead of merge if the branches have not diverged.
<Noldorin> henninge, and just normal merge if they have diverged, right?
<henninge> right
<Noldorin> henninge, and bzr update is like bzr merge, except it replies to the working tree rather than the branch itself?
<Noldorin> it applies*
<Noldorin> oops
<henninge> ah
<henninge> It updates your working tree from your branch.
<henninge> if you are wokring on a full branch and working tree, merge and pull will do that for you.
<Noldorin> henninge, bzr update merges changes from the branch into the working tree, whereas bzr pull merges from another branch into the branch?
<fullermd> Wow, that sounds like a wildly confusing way to explain it...
<henninge> fullermd: possibly ;)
<Noldorin> how would you explain it?
<Noldorin> also, merge and pull don't change the working tree afaik...
<henninge> also, I am not sure on all aspects of update tbh
<fullermd> I dunno, but I'm pretty sure I wouldn't try drawing parallels between merge and update   :)
<fullermd> Er.  Both change the working tree...
<Noldorin> fullermd, they both do merging of a sorts :-P
<fullermd> Well, so does 'pack'   :P
<Noldorin> i don't use pack
<Noldorin> that's out of the question
<Noldorin> fullermd, so if you do a pull, then an update is not necessary after right?
<Noldorin> to get to the latest rev.
<fullermd> Correct.
<Noldorin> fullermd, and bzr update automatically does a pull in 'bound' branches i suppose?
<fullermd> Oh, you don't want to get me started there...
<Noldorin> hah
<Noldorin> is that right though?
<Noldorin> more or less
<fullermd> Sorta, sometimes.
<Noldorin> hah
<Noldorin> well bound branches make it like centralised VCS afaik
<fullermd> And then sometimes it does a sort of horrific pivot double-merge and completely ruins your life.
<Noldorin> that's how i think of them
<Noldorin> fullermd, hah i think i'll ignore that for now :-)
<Noldorin> thanks for clearing it up anyway
<jelmer_> vila: still there ?
<vila> jelmer_: yup
<vila> jelmer_: I've tried setting up a bot to do reviews but once debugged he said: nah, I don't want to do that
<jelmer_> vila: I think we should be good to update to the latest version of bzr-builddeb
<jelmer_> the worst thing that can happen is that xz tarballs still don't work
<vila> jelmer_: ok, my concerns were about things like 'Cope with move of features in bzr 2.5' and other 'compat with bzr-svn' stuff
<jelmer_> vila: those should both be backwards compatible
<vila> thanks for confirming
<vila> jelmer_: also, if I can deploy from bzr-builddeb trunk, I know I don't leave a weird setup someone else will be confused by
<vila> (carrying an uncommitted change to disable the merge hook is bad enough)
<vila> jelmer.... come back !
<jelmer> vila: sorry
<vila> ha, good :)
<jelmer> vila: what I was trying to say before the kernel on my other machine oopsed..
<jelmer> vila: those two changes should only affect the test suite of bzr-builddeb anyway
<vila> hehe, oops, sorry not funny :-/
<vila> ok,
<vila> did you get:
<vila> jelmer_: also, if I can deploy from bzr-builddeb trunk, I know I don't leave a weird setup someone else will be confused by
<vila> (carrying an uncommitted change to disable the merge hook is bad enough)
<jelmer> I'm still not sure why that change is necessary
<jelmer> where do we actually merge?
<vila> jelmer: we need a newer dpkg-dev
<jelmer> vila: yeah, but why is that relevant if that merge hook never gets called
<jelmer> (also, could we perhaps automatically disable the merge hook in bzr-builddeb if a new enough dpkg-dev is not available)
<vila> it got called
<vila> that will work yeah
<vila> jelmer: rt #47638 by the way
<jelmer> vila: thanks
<vila> jelmer: ?? what for ?
<jelmer> vila, for that rt
<vila> jelmer: it's a week old :-/
<jelmer> vila: for mentioning the RT # :)
<jelmer> ... the music
<jelmer> .. the joy it's bringing
<vila> oh :)
<vila> really ? Funny you mention that while a police car was under my windows :)
<vila> That's not me ! Help.asdffglkjjk6yq43t
<jelmer> hehe :)
<fullermd> Why did you throw a police car out your window?
<vila> because I'm not done yet
<vila> told them to come back later
<Noldorin> hey jel
<Noldorin> jelmer
<Noldorin> i have a branch which i uncommit up to a certain revision, and then run bzr revert...it tells me the working tree is out of date thereafter -- why?
#bzr 2011-09-10
<Noldorin> is there any short version of bzr help?
<Noldorin> how do i diff two different branches at different revisions?
<Noldorin> ...is anyone here alive? :-P
<AuroraBorealis> i am
<Noldorin> good to know
<Noldorin> how do i diff two different branches at different revisions?
<axatrikx> can anyone suggest any good books for bug fixing in launchpad?
<Noldorin> how do i diff two different branches at different revisions?
<maxb> Something like -r 123:abc..456:def I'd expect
<Noldorin> maxb, revision:branch format?
<maxb> yes
<maxb> bzr help revisionspec for more info
<Noldorin> ok cheers
<zulax> we have 2 projects, 6 ppl
<zulax> and all collaborators will be working on a window machine
<zulax> but i would like to have the repos on ubuntu
<zulax> is bazaar right choice for me?
<zulax> and i m hoping tortoisebzr will let us easily browse/push/pull repos without having the need to install a bazar-server
<vila> zulax: If bzr is installed on the ubuntu machine, you already have the simplest setup for a server. Configure ssh and you're done.
<zulax> ok
<vila> zulax: setting up ssh clients on windows is only slightly harder (but you may already have that)
<zulax> would tortoisebzr take care of that?
<zulax> or do i need putty like
<vila> yup, putty like and then tortoisebzr should work
<zulax> ok,
<zulax> we have svn but i dont think its built for collaboration
<zulax> and git is slightly more complex
<zulax> and lack of windows support
 * vila nods
<wilx> Hi.
<wilx> What am I doing wrong with fast-import?
<wilx> http://codepad.org/O1k6lcKP
<wilx> See the paste.
<wilx> I have installed the module into ~/.bazaar/plugsin/fastimport and I have added the path...
<pzn> I'm an old-style programmer from cvs era. I did the cvs->svn step some years ago, now I'll give a try to bzr. can someone recommend a quickstart to brz for someone that is used to svn?
<pzn> sorry for the bad english: does bzr supports this development model: personal merge can be made by anyone, blessed maintrunk merge can be made by anyone (but it has to be someone else). I mean that if userA requested a bless, then userB userC anyone (except userA) can bless. if userB requests a bless, then userA, userC, ... can bless it
<pzn> maybe I should have read more docs before asking my previous question...
<pzn> does using debian squeeze bzr version (2.1.2) will be good for most projects, or does this old version misses some main and good new features from 2.4 version?
<fullermd> That sounds like a development ruleset, not so much a VCS thing.  I s'pose you could loosely enforce it with hooks some way or other if you tried...  sounds more trouble than it's worth.
<fullermd> 2.1 should _work_ OK.  But it's a fair ways back; 2.4 will have rather better performance, and there've been a fair number of features/etc since then.
<pzn> fullermd, tks! better impose some "by mouth agreement" enforcement, than "hook software enforcement", if that is what I understood
<pzn> fullermd, for regular workflow (sorry for the svn terms) create, checkout, update, commit, merge, I'll have no problem with 2.1, ok?
<fullermd> Well, I was gonna go with "pair of pliers and a blowtorch", myself, but whatever works  ;)
<fullermd> I'm not aware of any showstopper bugs in up to date 2.1.x, thought that may not mean much.  But certainly the workflow would be the same, so it's at least good enough to experiment with.
<pzn> will bzr work ok for "binary" files (just for version control, not for diff between versions) like spreadsheets or pdf files?
<pzn> fullermd, it took me some minutes to understand "pair of pliers and a blowtorch" in my language, but google helped me :-D
<fullermd> As long as they're not too big.  Presumably you're talking about sub-few-dozen-megs.
<pzn> fullermd, in current SVN, 10Mb is the bigger one and it has a 20 different revisions (2000 revisions in full project head). I don't intend to put iso CD or iso DVD images on bzr :-)
<fullermd> No, that's a significant difference between bzr and systems like SVN/CVS.  The only granularity you deal with is the branch; neither more nor less.
<pzn> so you mean that people that work with documentation will need to have the full project on their computers... that is bad for me...
<pzn> but if that gets really bad, I can workaround by creating one repository "/project-sourcecode" and another repository "/project-doc"
<pzn> I didn't get the idea behind "use of memory"... suppose I do an "get from server" in the full project. then I open "gimp" to edit an jpg binary file of the project. then I open "openoffice-calc" to edit an spreadsheet. why would it use several times in memory?
<fullermd> Well, for instance, packing up diffs when you commit/etc has to hold at least an "old" and "new" copy in memory, plus whatever is taken up by the differences.
<pzn> fullermd, ok, got the point. the memory usage is only at "commit" operation. no problem
<fullermd> Well, at various others to.  I wouldn't attempt to compile a complete list.
<pzn> fullermd, thanks for your help. I'll go home now. bye
<AuroraBorealis> what does "bzr: Error 5" mean? o.o
<fullermd> It's like error 4, but more so.
<AuroraBorealis> apparently.
<AuroraBorealis> (aka error codes are the worst things ever)
<AuroraBorealis> i just got this and i dunno if i should do something about it haha
<AuroraBorealis> bzr: ERROR: [Error 5] C:/Users/Mark/Code/bzr/python/FASubmissionScraper/trunk/.bzr/branch/lock/releasing.fb82ujn47r8758ue2z3g.tmp/*
<fullermd> On my system, errno 5 is EIO...
 * fullermd has no idea how consistent that would be...
<AuroraBorealis> as in it couldn't read the file?
<fullermd> Usually something like that.
<fullermd> Seems kinda odd that a file would be called '*'.
<AuroraBorealis> yeah
<AuroraBorealis> and that there is no stack trace either
<fullermd> Is it happening more than once?
<AuroraBorealis> no
<AuroraBorealis> but i have been having problems (in earlier problems of bazaar) where the lock file doesn't get deleted
<fullermd> I think that branch/lock/ directory should be empty (but extant) if you don't have anything running.  Any droppings in it?
<fullermd> I think a common suckage source on Windows has been that (a) you can't delete a file that's open, and (b) virus scanners have a tendancy to open files for arbitrary lengths of time.
<AuroraBorealis> although my problem was in the ~/.bazaar/lock directory
<AuroraBorealis> not the actual branch ones
<AuroraBorealis> annnnd opening that location makes explorer say "location is not accessible: access is denied"
<AuroraBorealis> oh god, "unable to display current owner"
<AuroraBorealis> so now i have a rogue folder that i am unable to delete ;<
<zulax> i just setup up apt-get install bzr on my ubuntu
<zulax> then i installed bzr on windows machine
<zulax> can i now browse the repo on ubuntu from windows?
#bzr 2011-09-11
 * AuroraBorealis sighs
<AuroraBorealis> for some reason when bazaar calls gpg it doesn't call pinentry and it just fails =(
<AuroraBorealis> it seems that bzr explorer needs to use --no-tty
<AuroraBorealis> for the gpg command
<jelmer> AuroraBorealis: please file a bug :)
<AuroraBorealis> k
<AuroraBorealis> submitted. https://bugs.launchpad.net/bzr-explorer/+bug/847388
<ubot5> Ubuntu bug 847388 in Bazaar Explorer ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Undecided,New]
<jelmer> AuroraBorealis: thanks
<AuroraBorealis> i just commit using the regular terminal command and it works, so i think its just a --no-tty issue
<AuroraBorealis> however i dont know where in the code the command gets called so i can't test it xD
<jelmer> AuroraBorealis: it's in bzrlib/gpg.py
<AuroraBorealis> it seems that the tty environment variable is not set in ubuntu
<AuroraBorealis> and thats whats causing it to freak out
<AuroraBorealis> not sure if thats bad or not
<AuroraBorealis> it also appears that --no-tty fixes it, but i'm unsure of how to integrate that :3
<AuroraBorealis> annnnnd i seem to of figured out a solution. but now how to i generate a patch or something :o
<jelmer> AuroraBorealis: I'd recommend running the gpg related tests and fixing anything that breaks: ./bzr selftest --no-plugins gpg
<AuroraBorealis> after i make my changes?
<jelmer> AuroraBorealis: yep
<AuroraBorealis> kk
<jelmer> AuroraBorealis: well, ideally you should fix the tests to expect what you want to happen and then fix bzrlib.gpg
<jelmer> but this works too, and makes more sense given you've already changed bzrlib.gpg.
<AuroraBorealis> where are the tests located?
<AuroraBorealis> and this is kinda hard to test as it requires bazaar explorer
<AuroraBorealis> (as os.environ("TTY") has to not be set)
<jelmer> AuroraBorealis: this shouldn't require bzr explorer - I just meant tests that make sure that --no-tty is specified
<AuroraBorealis> yeah, i'm assuming these are unit tests. but the way to check that --no-tty is only specified correctly is to be using it where the environment variable for tty is not set, like in a GUI
<AuroraBorealis> unless i'm misunderstanding something
<jelmer> AuroraBorealis: sure, but in the unit test you can override the environment variable and see if the right parameters are specified
<AuroraBorealis> ah ok.
<jelmer> AuroraBorealis: see bzrlib.tests.TestCase.overrideEnv
<AuroraBorealis> i cant seem to run this bazaar branch i checked out from launchpad because it can't import "shlex_split_unicode"
<AuroraBorealis> any idea how to fix that jelmer so i can run the tests? xD
<Noldorin_> hi jelmer
<jelmer> hi Noldorin_
<jelmer> AuroraBorealis: I'm not sure - that should only be necessary on Windows I think
<AuroraBorealis> well the test cases are working i guess
<AuroraBorealis> so i'm trying to figure how how i borked those :<
<Noldorin_> jelmer, i am finding many bzr bugs these days...
<Noldorin_> while researching this issue
<jelmer> Noldorin_: what exactly?
<Noldorin_> jelmer, for a start, https://bugs.launchpad.net/bugs/846122
<ubot5> Ubuntu bug 846122 in Bazaar "bzr thinks working tree is out of date after uncommit" [Undecided,Confirmed]
<jelmer> Noldorin_: is the history empty after that operation perhaps?
<Noldorin_> what history?
<jelmer> Noldorin_: what's the output of "bzr revno"
<Noldorin_> jelmer, 46
<jelmer> Noldorin_: that's odd - is this in a bzr-git tree?
<Noldorin_> nope
<jelmer> Noldorin_: bound branch?
<Noldorin_> jelmer, maybe
<Noldorin_> i forget
<AuroraBorealis> is there a way to use 'print' when you are using these test cases? it seems that its not actually printing them (and causing other tests to fail)
<jelmer> AuroraBorealis: I generally use bzrlibtrace.mutter
<jelmer> AuroraBorealis: I generally use bzrlib.trace.mutter
<jelmer> AuroraBorealis: that will be printed as part of the test output if a test fails
<AuroraBorealis> also another question
<AuroraBorealis> bzrlib.TestCase.overrideEnv says that the environment variable will be reset after each test
<AuroraBorealis> is a test the entire class that extends TestCase or are they the individual methods?
<lifeless> the method
<lifeless> the class is a way to group related tests and (sometimes) test helpers that are specific to that group
<AuroraBorealis> ok. so i guess i have no idea why the environment variable for 'tty' would be none
<AuroraBorealis> as i thought it would be None if you were running like a user interface, but its none even if you invoke bzr from a command line
<AuroraBorealis> so i have no idea how to distinguish when you should add the --no-tty switch or not
<AuroraBorealis> well, it appears that just adding --no-tty works, so how do i submit this as a patch to the bug report i opened?
#bzr 2012-09-03
<mgz> morning
<xnox> bzr-cia is broken due to hostname changes. Please review & merge https://code.launchpad.net/~xnox/bzr-cia/fix-hostname/+merge/122490
<jelmer> xnox: Thanks, looks good
<xnox> jelmer: thanks. Kind-of broke the work flow used by #ubuntu-installer devs
<jelmer> xnox: Merged now; I'll also update cia-clients
<xnox> cool! =) thanks
<jelmer> We should probably file a RC bug about this.
<kinkie> Hi all, a question: I need to merge a branch which is stored in a format 2a repo into one which is in format pack-0.92. direct merge will not work, nor will going through a bundle. Is there any way to do it without losing the merged branch history?
<kinkie> thanks
<jelmer> hi kinkie
<jelmer> kinkie: how are things?
<kinkie> Hi jelmer
<jelmer> kinkie: there is no easy way to do that. Why do you still have a branch in 0.92 format?
<kinkie> jelmer: doing fine.. doing some endless refactoring on squid.
<kinkie> Some squid developers are running old platforms and are not happy about being forced to upgrade to newer versions of bzr :\
<kinkie> apart from that, I'm running marathons - it's fun and relaxing, but it  takes lots of time :)
<kinkie> back to the merge: you said that there is no easy way. What is the hard way? :)
<jelmer> kinkie: even to bzr 1.16, which was released in June 2009?
<kinkie> Guess so.   I hope I'll manage to convince them sooner than later.
<jelmer> kinkie: The hard way is to replay the entire branch in the 0.92 format somehow
<jelmer> with new revision ids
<kinkie> bzr diff -c <revid>,  bzr commit -m "message"?
<kinkie> foreach revid to be merged?
<jelmer> kinkie, yes, roughly
<kinkie> sigh.. there's 100 of them :\
<kinkie> okay
<kinkie> thanks
<jelmer> kinkie: the rich root migration was a bit of a mess :-(
<kinkie> Heh. I am sure that if it was a mess, it's because there was no other way
<jelmer> kinkie: yup; doesn't make it less of a pain though..
<mgz> can't you fast import to older formats?
<mgz> manually scripting the replay seems painful and error prone
<jelmer> mgz: ah, that's a good point
<jelmer> kinkie, that's worth a shot too
<kinkie> Sounds interesting. Is there a recipe?
<kinkie> I'm branching the fastimport plugin now.
<jodh> I'm having trouble getting a packaging recipe to work (http://paste.ubuntu.com/1183378/). The 'nest-part' seems to work, but when I attempt to build using pbuilder, no build actually happens and I end up with a .deb containing only config files. Anyone have any ideas?
<jelmer> hi jodh
<jelmer> jodh: Does the source package that result from the recipe look okay?
<kinkie> hm..:
<kinkie> kinkie@metro:~/squid/workspace/sourceformat$ bzr fast-export
<kinkie> bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module
<kinkie> kinkie@metro:~/squid/workspace/sourceformat$ bzr fast-import
<kinkie> bzr: ERROR: command 'fast-import' requires argument SOURCE
<kinkie> yet the fastimport python module has installed without errors
<jelmer> kinkie, note that the fastimport python module is different from the fastimport plugin
<mgz> that looks fine to me, the second one
<mgz> you want `bzr help fast-import` maybe?
<kinkie> isn't it distributed with the fastimport plugin itself?
<kinkie> ok: lp:python-fastimport, right?
<mgz> it's a dependency, but if you're branching from source, you're expected to be the kind of person who reads INSTALL
<mgz> or at least after realising it doesn't work, reads it :)
<kinkie> heh. Took me a short while ;)
<kinkie> done and installed
<kinkie> so the suggestion is fast-export then fast-import to convert the 2a branch to pack and then merge?
<jelmer> kinkie, yep
<kinkie> or can I fast-export the bundle directly? It'd just work ont he merge directive, right?
<jelmer> kinkie: I'm pretty sure that wouldn't work
<mgz> it probably expects a branch, but you can convert a bundle to a branch reasonably simply
<kinkie> nah, I'll just go the branch way
<kinkie> I'll be damned, it IS fast - 3k commits/minute
<kinkie> neat
<sil2100> Hello uys
 * sil2100 has keyboard problems
<mgz> do we need to think of words with lots of gs in to try to get you to type?
<jodh> jelmer: thanks for the pointer. I don't understand why yet, but the usual ubuntu packaging seems to automagically add a couple of gobs of black magic to the packaging. And that doesn't seem to happen in the recipe scenario. However, I now have a lead to follow...
<jelmer> kinkie: you shouldn't export the entire branch, just the new revisions - otherwise you'll have trouble merging later
<jelmer> jodh: recipes are just a way of creating a source package
<sil2100> Anyway, I need help, since I think I broke by accident the unity merger
<jelmer> hi sil2100
<sil2100> Hi jelmer!
<jelmer> sil2100: what can we help with?
<jelmer> jodh: so after you've built the recipe, the usual ubuntu packaging comes into play
<mgz> sil2100: which branch? the quantal packaging one?
<sil2100> jelmer: ok, so... we had a wrongly placed tag in bamf trunk, so I wanted to move it to the right place - so I did a bzr tag --delete, bzr tag and push, but now it seems that whoever wants to do a bzr pull gets a tag conflict
<sil2100> mgz: no, bamf source branch
<jelmer> sil2100: the easiest workaround is for them to remove their local tag by that name and then pull
<mgz> sil2100: okay, so everyone could do that same operation on their local branches (annoying)
<mgz> or you could delete the tag from the master and just let it revert
<jelmer> sil2100: tags aren't versioned, so there is no easy way to replicate changes to existing tags
<sil2100> jelmer, mgz: the problem is, the mergers do a bzr pull without any -overrides
<sil2100> jelmer: if I re-add the tag in the same place as it was, will it be the 'same' tag and not make any conflicts?
<jelmer> sil2100: also, newer versions of bzr have 'bzr pull --overwrite-tags'
<jelmer> sil2100: yes
<mgz> basically, one side or the other needs to have the tag deleted before pull
<mgz> no overwrite needed.
<jodh> jelmer: well, something is going awry as the rules file for Ubuntu seemingly is behaving differently under pbuilder with upstream source than with the ubuntu source. I'm having to force a dh_autoreconf for the upstream case.
<sil2100> jelmer, mgz: thanks!
<jelmer> jodh: the ubuntu source probably comes with a prebuilt version of configure, whereas the upstream source doesn't have one
<jelmer> jodh: in other words, the contents of the tarball and the upstream branch are different (does the tarball perhaps have an autogen.sh that's run?)
<jodh> jelmer: you're right - the ubuntu branch has configure under vc whereas upstream doesn't. There is no autogen.sh in either branch.
<sil2100> jelmer: just one more question - is there a nice way of moving a tag from one commit to another without breaking bzr pull's of others?
<jelmer> sil2100: only if they didn't have the old version of the tag (since tags are not versioned)
<sil2100> jelmer: awww, too bad... thanks
<kinkie> jelmer, mgz: I tried and failed to do as you suggested :( Maybe I need a step-by-step recipe :\ Can we talk about this tomorrow maybe?
<kinkie> Thanks
<kinkie> (now I must go)
<jelmer> kinkie: Sure, we'll be around tomorrow
<jelmer> kinkie: Have a nice evening
<SamB_MacG5> vila: Hmm, how do I uninstall the Qt packages installed by the mac installer? They aren't showing up in pkgutil(1)'s output...
<vila> SamB_MacG5: pfew, isn't there an uninstaller with the isntaller (it's been a looong time since I looked at an OSX install)
<vila> SamB_MacG5: if I were to try doing that myself, I'll search the recipe that every install leave in some dir below... /Library ? /System/Library ?
<SamB_MacG5> vila: I got your name from the source paths compiled into the Python extensions from the most recent powerpc/i386 universal installer I could find
 * vila blushes
<vila> SamB_MacG5: yeah, I did build some installers for some time *after* I was really hacking on OSX, but really, just execute the scripts and smoke test them
<SamB_MacG5> ah
<vila> SamB_MacG5: so I have some background but the mac I used is... not at my desk anymore
<mgz> I'd think macs were best used as desks. anything not a computer, for that matter. door stop, frisbee...
<vila> SamB_MacG5: but I don't remember ever building powerpc stuff unless the compiler was a cross-compiling one being my back ;)
<SamB_MacG5> Can't you, like, install Amiga OS 4 on powermacs or something ?
<vila> dunno, I install Ubuntu on the macs that are on my desk
<fullermd> Unbutu?  Is that like Amiga OS 5 or something?
<vila> yeah
<mgz> it's like freebsod
<mgz> but with different colours
<fullermd> freelsd comes with every color.  And then some.
<SamB_MacG5> vila: that would explain why the Qt, SIP, and PyQt included in the installer in question are all intel-only ;-P
<vila> SamB_MacG5: hehe, yes :) Are you really trying to install on a powermac ?
<SamB_MacG5> oh, I installed it on a power mac ages ago
<fullermd> (which is when pretty much anything done on a power mac was done  ;p)
<SamB_MacG5> by which I mean some months
<vila> but with which version of OSX ? Due to lack of resources I think only osx 10.5 and 10.6 have installers built for them (at best)
<vila> on the other hand, building your own is pretty easy (but will probably take some time to compile qt...)
<SamB_MacG5> now I'm just trying to fix the bzr 2.3 mac installer build scripts and accompanying README so that the resulting installer will be fully universal when built on 10.5
<mgz> SamB_MacG5: have you found lp:bzr-mac-installers?
<SamB_MacG5> (distutils-based extension builds are automatically powerpc/i386 universal when built on 10.5)
<SamB_MacG5> mgz: yes, I have, thanks to someone (you?) adding a link there to that one wiki page in response to my reporting a bug about there not being any mention of the build scripts there
<mgz> I think credit goes to gordon (also the maintainer of the current mac installers)
 * SamB_MacG5 couldn't remember who did it
<Trmandy> Hi guys, I have a bzr branch in which I wish to "squash" all revisions up to 100 into a single commit, and retain revisions 101 and above. How can I go about doing this? I can't quite wrap my head around what is necessary to make this happen.
<mgz> Trmandy: try playing with the export and import commands from bzr-fastimport
<mgz> note this is rewriting history, so isn't a good thing for a public branch
<Trmandy> yep, understood. This is a private branch
#bzr 2012-09-04
<kinkie> Good morning
<mgz> morning!
<jelmer> moin
<kinkie> :) Do you have a few minutes to try and help me with  the 2a to pack merge recipe? (BTW: I've raised the request to upgrade the repository - the discussion looks positive so far)
<mgz> kinkie: how far did you get?
<kinkie> not very, as I didn't understand how I was supposed to be doing it. I don't understand how to select the changesets to fast-export
<kinkie> I guess it may be something like -r submit:..-1 ?
<mgz> right, there is a revision param, which yo can pass the range of commits you want
<mgz> but submit: probably won't work? just find out the revno of the last common rev however
<kinkie> I'm trying to merge into trunk, and there have been quite a few merges from trunk to the branch.. is that dealt with?
<mgz> good question.
<mgz> I suspect that will mess things up, but can't see without trying
<kinkie> I'm also trying
<Carpette> hi
<Carpette> any idea what this kind of error is guys ?
<Carpette> bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left
<Carpette> this is producing only on one of my branches, the others are working correctly
<Carpette> so i suppose the problem come from the .bzr folder, but i have no idea where to search
<xnox> what was the command again to see "dangling" heads in bzr
<xnox> e.g. the ID of commits I uncommitted
<mgz> xnox: `bzr heads` which is part of the bzrtools plugin
<xnox> mgz: ok. thanks. not sure why it kicked off bzr-svn cache a non-bzr-svn branch. maybe shared repo had some bzr-svn revisions =/
<micahg> is there any way to continue  a bzr git import that failed do to running out of disk spacE?
<lifeless> yes, just continue; its incremental
<micahg> sorry, forgot to mention this is local
<micahg> and if the answer is the same, how?
<xnox> micahg: first do $ bzr pull -r1
<xnox> micahg: then every subsequent pull is incremental
<xnox> micahg: you are probably stuck with incomplete bzr tree which bzr doesn't like at all.... =(
<xnox> (tree/branch/checkout)
<xnox> that's from my eperience of doing git -> bzr of binutils&gcc repositories
<xnox> I usually looped @ about 1000 revisions.
<xnox> for me it was not the case of disk space, but rather running out of ram. So i'd trigger manual repacks as well.
<micahg> xnox: ah, ok, I've got plenty of RAM, but little disk space :)
<xnox> micahg: branch one revision, loop as you feel need & repack in between. Repack twice to delete redundant packs.
<micahg> the problem is that branching didn't finish, so it's not a real repo yet
<xnox> micahg: $ bzr branch -r1
<xnox> =)
<xnox> micahg: $ bzr branch -r1 $URL
<micahg> so, I have to start over though?
<xnox> yes, sorry.
<micahg> 22G ATM :(
<xnox> micahg: is it public? I can probably create you a branch.
<xnox> =)
<micahg> no, I need it locally :)
<micahg> well, it's public,, yes, but I need it locally
<micahg> lifeless: was your continue comment only for an LP bzr branch or for a local one as well?
<lifeless> micahg: both
<lifeless> micahg: bzr-git conversions are incremental
<micahg> lifeless: ooh, how to continue :)
<lifeless> as xnox said
<lifeless> there may be a simpler way
<lifeless> jelmer: would know
<micahg> bzr: ERROR: This operation is not supported by the Git smart server protocol. :(
#bzr 2012-09-05
<glyph> Hiya. We've got a buildbot which is using bzr, while our main repository is still SVN.  The buildbot wants to build svn revisions.  svn:revno almost does what we want, except it demands a level of precision we can't necessarily provide:
<glyph> To wit, when we have a revision number that is in a branch, but we try to check it out on trunk, we don't get the "highest without going over" behavior that "svn checkout" would produce.
<glyph> Is there a way to get that behavior without lots of hacking of 'bzr log' and its output?
<lifeless> possibly
<lifeless> uhm
<lifeless> before:svn:xxx
<lifeless> or after:svn:xxx
<lifeless> or you could write a plugin for svn-approx:xxxx
<lifeless> which would do whatever you need
<lifeless> revision resolving plugins are pretty simple
<glyph> lifeless: interesting
<glyph> lifeless: that doesn't seem to work though.
<glyph> bzr: ERROR: Unsupported protocol for url "after:svn:34810"
<lifeless> after might be science fiction
<lifeless> I suspect you need a small resolver
<lifeless> bzr help revisionspec will give you the current ones
<lifeless> you can look at e.g. bzr-svn to see how svn: is implemented and registered
<glyph> lifeless: OK.  Probably don't need it, but that's good to keep in mind.  I did write a bunch of shortcut plugins for my own personal use :)
<glyph> no revision plugins though.
<spiv> revspec plugins are pretty straightforward.
<lifeless> glyph: I suspect a plugin is what you need, that or a patch to the svn revspec to be fuzzy
<tomprince> bzr: ERROR: Requested revision: u'svn:35497' does not exist in branch: BzrBranch7('http://svn.twistedmatrix.com/bzr/Twisted/trunk/')
<tomprince> ^--- does this indicate an out-of-date version bzr/bzr-svn?
<spiv> tomprince: is the bzr-svn plugin loaded?  (does it appear in 'bzr plugins' ?)|
<spiv> Or possibly it means that bzr mirror of the svn trunk is out of date?
<tomprince> I don't have access to the host. It could be that the bzr-svn plugin is loaded.
<tomprince> http://buildbot.twistedmatrix.com/builders/rhel6-32bit-py2.6/builds/984/steps/bzr/logs/stdio
<tomprince> spiv: ^--- is the output I get.
<tomprince> I'm trying to diagnose the problem remotely, so I can provide instructions to the person who has access to the machine.
<spiv> I guess ideally the 'bzr' step of that buildslave config would capture the .bzr.log and put it somewhere visible.
<spiv> Or perhaps run bzr with -Derror or something
<spiv> Well, 'bzr log -r-1 -v --long --show-ids http://svn.twistedmatrix.com/bzr/Twisted/trunk/' shows its currently at svn's r35499
<spiv> So that error does suggest that there's something wrong with bzr-svn on that slave.
<mgz> morning
<jelmer> pom
<jelmer> tomprince: hi
<jelmer> tomprince: did that revision touch that particular branch?
<jml> *awesome*
<jml> $ bzr di
<jml> === modified file 'sourcedeps.conf'
<jml> bzr: ERROR: Could not understand response from smart server: ['x\x9c\xa5\x92\xcb\x0e\x820\x10E\xd7\xf2\x15\xee\r\xad\xa0\x10\x1f\xf1cJ[\xa1\x81>\x9c\xb6$\xb2\xf0\xdb\x85\x80Q0\x01\x13\x17\x93Lf\xe6\xde\x93\xde\x14a!\x8d\x06\x17Z']
<mgz> hm... new in the last few days I take it?
<jml> mgz: new today for me
<jml> lightweight checkout
<mgz> we upgraded launchpad to bzr 2.5.1 which has some new fancy for doing some operations over the smart server that weren't before
<mgz> so, please file a bug with as much info as possible.
<jml> ok.
<mgz> obvious work around is have a local trunk branch that you branch from, so diffs from lwc use that
<jml> yeah, I'm doing that right now
<mgz> thanks jml.
<jml> huh, apparently a lock has been taken
<mgz> ...you might need to manuall break it
<mgz> also worth putting in the bug report
<mgz> ah... launchpad might be unhappy right now?
<jml> mgz: https://bugs.launchpad.net/bzr/+bug/1046265
<ubot5> Ubuntu bug 1046265 in Bazaar ""Could not understand response from smart server" when diffing lightweight checkout of LP branch" [Undecided,New]
<mgz> is it repoducable, I neglected to ask?
<jml> mgz: yes, although I haven't tried from a fresh light-weight checkout, only one that already existed.
<jam> mgz, jelmer: any success with the python-defaults stuff?
<jam> jml: what were you using a lightweight checkout for that you were running diff? (the only specific common one I know of is the download-cache, but diff is pretty useless for tarballs)
<jml> jam: a branch that contains only a config-manager configuration file, sourcedeps.conf
<jelmer> jml: can you file a bug about this issue?
<jml> jelmer: is https://bugs.launchpad.net/bzr/+bug/1046265 somehow insufficient?
<ubot5> Ubuntu bug 1046265 in Bazaar ""Could not understand response from smart server" when diffing lightweight checkout of LP branch" [High,Confirmed]
<jam> jelmer: he did file #1046265 was there another one?
<jelmer> jml: worked on landing use-bzr-policy-open earlier, and am going to upload a new python-defaults soon
<jelmer> jml: No, that's great - thanks
<jml> jelmer: np.
<jelmer> I didn't see that
<jam> jelmer: use-bzr-policy-open?
<jam> an lp branch
<jelmer> jam: yep, to get launchpad to use the bzr code for safely opening branches
<jml> see also $ bzr ci
<jml> Committing to: bzr+ssh://bazaar.launchpad.net/~canonical-ca-hackers/ca-configs/txpkgme-configmanager/
<jml> modified sourcedeps.conf
<jml> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://jml@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<jml> Traceback (most recent call last):
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 930, in exception_to_return_code
<jml>     return the_callable(*args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1141, in run_bzr
<jml>     ret = run(*run_argv)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 673, in run_argv_aliases
<jml>     return self.run(**all_cmd_args)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 697, in run
<jml>     return self._operation.run_simple(*args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple
<jml>     self.cleanups, self.func, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
<jml>     result = func(*args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 3688, in run
<jml>     lossy=lossy)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 218, in write_locked
<jml>     result = unbound(self, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/workingtree_4.py", line 218, in commit
<jml>     result = WorkingTree.commit(self, message, revprops, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 218, in write_locked
<jml>     result = unbound(self, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/mutabletree.py", line 211, in commit
<jml>     *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 290, in commit
<jml>     lossy=lossy)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 132, in run
<jml>     self.cleanups, self.func, self, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
<jml>     result = func(*args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 452, in _commit
<jml>     self.builder.abort()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 217, in abort
<jml>     self.repository.abort_write_group()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/remote.py", line 1212, in abort_write_group
<jml>     suppress_errors=suppress_errors)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repository.py", line 282, in abort_write_group
<jml>     self._abort_write_group()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 1708, in _abort_write_group
<jml>     self._pack_collection._abort_write_group()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 1565, in _abort_write_group
<jml>     operation.run_simple()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple
<jml>     self.cleanups, self.func, *args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
<jml>     result = func(*args, **kwargs)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 436, in abort
<jml>     self.upload_transport.delete(self.random_name)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/transport/remote.py", line 313, in delete
<jml>     resp = self._call2('delete', self._remote_path(relpath))
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/transport/remote.py", line 181, in _call2
<jml>     return self._client.call(method, *args)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 59, in call
<jml>     result, protocol = self.call_expecting_body(method, *args)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 72, in call_expecting_body
<jml>     method, args, expect_response_body=True)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 55, in _call_and_read_response
<jml>     return request.call_and_read_response()
<jam> jml: pastebin is your friend :)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 157, in call_and_read_response
<jml>     return self._call(protocol_version)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 189, in _call
<jml>     response_handler = self._send(protocol_version)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 265, in _send
<jml>     encoder, response_handler = self._construct_protocol(protocol_version)
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 241, in _construct_protocol
<jml>     request = self.client._medium.get_request()
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/medium.py", line 884, in get_request
<jml>     return SmartClientStreamMediumRequest(self)
<jam> also, at least with a trivial branch here, I don't see the failure when creating a new lightweight checkout of a single-file single-commit branch and modifying it and committing.
<jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/medium.py", line 1167, in __init__
<jml>     raise errors.TooManyConcurrentRequests(self._medium)
<jml> TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://jml@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<jml> bzr 2.6.0dev3 on python 2.7.3 (Linux-3.5.0-10-generic-x86_64-with-
<jml>     Ubuntu-12.10-quantal)
<jml> arguments: ['/usr/bin/bzr', 'ci']
<jml> plugins: bash_completion[2.6.0dev3], branchdashboard[unknown],
<jml>     bzrtools[2.5.0], changelog_merge[2.6.0dev3], damage[unknown],
<jml>     difftodo[unknown], grep[0.5.0dev], launchpad[2.6.0dev3],
<jml>     netrc_credential_store[2.6.0dev3], news_merge[2.6.0dev3],
<jam> jml: so if this is a public thing, can you tar up your local checkout, and put it somewhere for us to test?
<jml>     po_merge[2.6.0dev3], pqm[1.4.0dev], stats[0.2.0dev], svn[1.2.3dev],
<jml>     weave_fmt[2.6.0dev3]
<jml> encoding: 'utf-8', fsenc: 'UTF-8', lang: 'en_GB.UTF-8'
<jml> *** Bazaar has encountered an internal error.  This probably indicates a
<jml>     bug in Bazaar.  You can help us fix it by filing a bug report at
<jml>         https://bugs.launchpad.net/bzr/+filebug
<jml>     including this traceback and a description of the problem.
<jml> oops
<jml> sorry.
<jml> you know that thing where hitting Ctrl-C doesn't always copy because something in Ubuntu is slower than I am? that.
<jml> I had meant https://bugs.launchpad.net/bzr/+bug/1046284
<ubot5> Ubuntu bug 1046284 in Bazaar "TooManyConcurrentRequests when committing to lightweight checkout" [Undecided,New]
<jml> no it's not
<jml> jam: this is a different branch (I think)
<jml> jam: chinstrap:~jml/txpkgme-configmanager.tar.gz
<jam> jml: and this is using Q with the packaged bzr? or bzr.dev? or ?
<jml> jam: packaged Q. (should I have included more information in the bug report?)
<jam> jml: I think it has enough info there, but sometimes it is easier to just ask
<jml> :)
<jam> jml: bzr status says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~canonical-ca-hackers/ca-configs/txpkgme-configmanager/".
<jml> jam: oh. well. it is a branch.
<jam> jml: https://code.launchpad.net/~canonical-ca-hackers/ca-configs
<jam> are you sure it isn't private?
<jml> jam: oh yeah, it's private.
<jam> so... I can't see it then :)
<jml> jam: but not for any good reason that I know of
<jam> jml: you are welcome to make it public, or add me for analysis purposes.
<jml> jam: ah, right. you still work for Canonical, right? :P
<jam> (and then kick me out later so I don't get bug spam)
<jam> jml: I got paid last month, so I'm pretty sure I do
<jml> jam: I've subscribed you to txpkgme-configmanager. Let me know if you need more access.
<jam> jml: I can see it, and I can confirm that 'bzr diff' gives me a failure
<jml> cool.
<jam> jml: ok, I think I've figured out the bug
<jam> I'm not sure why the ordering is this way
<jam> but essentially, the _iter_files_bytes code yields a 'call this function to get the content of the file'
<jam> however, the outer code is never calling that function.
<jam> which means the bytes of the file are still in the stream
<jam> so the next iteration goes through and says "is there another record here" and gets the file content instead of the tail of the stream.
<jam> jml, jelmer: I see why now, should be a simple-ish fix
<jelmer> jam: Thanks for debugging that
<jelmer> jam: Are you submitting a fix?
<jam> jelmer: yeah, the specific issue is that WT4 is doing list(iter_files_bytes())[0]
<jam> however, that consumes the iterator
<jam> *before* it consumes the content.
<jelmer> ah
<jam> so we just have to turn it into a for loop, etc.
<jam> and then think about if we have a test hole.
<jam> iter_files_bytes wasn't being used according to its spec, so one implementation did it differently (remoterepo vs local repo)
<jam> but it wasn't detected because local repo caches the contents and returns a trivial function
<jam> jelmer: interestingly, it looks like i'm the one to blame.
<jam> back in rev 4204
<mgz> well, that's nice.
<jelmer> jam: to be fair, we never had that behaviour until recently
<jam> jelmer,mgz: yeah it worked because we didn't actually implement iter_files_bytes as an RPC
<jam> I wrote get_file_text back in bzr-1.14.. wow.
<mgz> but iters that happen to always be listiter then usage breaking when that changes kind of thing isn't uncommon
<jam> mgz: yeah, the issue is that you have to consume the callable returned as you iterate
<jam> which I think has bit us once before, but it is pretty uncommon.
<mgz> ...I think those words would make sense if I'd put them together in the right order
<jam> mgz: well, I know the code and the problem, so it made enough sense to me :)
<jam> jelmer, mgz: it has been a while since I dug into the hard bits. How would you set up a test for a lightweight checkout of a remote repository?
<jelmer> jam: it depends a bit; for what you're hitting now I guess a blackbox test might be most appropriate?
<jam> jelmer: I'd like to do a per-wt test sort of thing.
<jelmer> jam: There are no tests verifying wt against a specific remote branch I think
<jam> jelmer: yeah, which I think is part of the testing hole I mentioned earlier.
<jelmer> jam: perhaps just add a test in bzrlib/tests/per_workingtree/ that sets up some remote branch and gets the wt to use that, if they are compatible?
<mgz> jam: probably subclass TestCaseWithTransport then parametrise against classes in bt.test_server
<mgz> ReadonlySmartTCPServer_for_testing should do, can then operate on branch locally the check it out, and make some tree changes, and diff
<jam> mgz: well, I only need to call 'wt.get_file_text()' with a backing of a remote repo, so 'dif' isn't necessary
<jam> (it is also why commit fails, etc.)
<mgz> doesn't seem like per_workingtree has any remote tests
<jam> well, I'm guessing, I didn't try to commit to a branch that isn't mine :)
<jam> right
<idnar> so there's `bzr deleted` and `bzr renames`; is there anything like `bzr modified`?
<idnar> I'm looking for something nicer than bzr status -S | horrible-shell-hacking-here
<mgz> idnar: what would be calling that?
<idnar> I want to open all modified (and added, for that matter) files in my editor; so something like gvim -p $(bzr blahblah) would be my usage
<idnar> it's not too important, I was just wondering if I missed something easy
<mgz> hm, so writing shell is probably no worse than using the python bzrlib api or a plugin
<fullermd> ls is more the interface intended for that.
<mgz> odd, ls seems to be showing me ignored files by default
<mgz> and lots of files that are not in fact modified...
<fullermd> Hm, I thought ls had --modified and --deleted and such. But the help doesn't list them.
<mgz> idnar: so, that's probably what you want, you might just need to submit some patches to fix it first :)
<micahg> bzr: ERROR: zlib.error: Error -3 while decompressing: incorrect header check   trying to branch a local git repo to bzr
<hariom> What are pros and cons of creating bzr repo in non root user space
<mgz> hariom: I don't know exactly what you mean, but I can't think of any reason you'd want to do it.
<mgz> micahg: is that a bug report or an observation?
<micahg> mgz: it's an observation, I'm happy to file a bug report if appropriate :)
<micahg> google was not forthcoming with a matching bug report
<mgz> without traceback context (see .bzr.log) it's hard to suggest anything
<micahg> mgz: http://paste.ubuntu.com/1187398/
<mgz> generally errors from zlib mean a data file has been corrupted, but branching from git (which doesn't use the same mechanisms) might mean it's a dulwich bug or something
 * micahg wishes he knew the equivalent of bzr check for git
<mgz> right, was going to suggest that, but also don't know it
<mgz> could set BZR_PDB=1, repeat the operation, step up the stack trace a bit and see if the packfile looks sane
<mgz> micahg: either way, a bug report against dulwich would not hurt
<gmarkall> would the bzr check equivalent be git fsck, maybe with --full and/or --strict?
<micahg> gmarkall: ooh, thanks
<micahg> mgz: consistency check finished, checkout still failed, I guess a dulwich bug it is then
<mgz> oh, pants
<mgz> how do I cancel a pqm run...
<lifeless> sudo make me a sandwhich
<mgz> I fear that won't work.
<lifeless> sandwich then
<mgz> and it's past the merge step to renaming the branch from under it is no good.
<mgz> ...I don't have rights to uncommit from bzr.dev so can't fixup afterwards either
<lifeless> land the reverse patch.
<lifeless> uncommit on public branches is evil anyhow.
<mgz> how much will webops hate me if I ask them to kill the process on whatever machine bzr's pqm runs on these days?
<lifeless> well, thats what I meant by sudo :P
<mgz> the merge will work, it's just targetted at the wrong branch, so will confuse the history
<lifeless> its a fairly routine request - is it mid test run ?
<mgz> yup,
<mgz> thanks lifeless. I really must let launchpad load the diff before sending these routine things to land.
<chinoto> http://doc.bazaar.canonical.com/beta/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories
<chinoto> so my coworker decided to use that link to restrict access to our dev server so... "outsource workers"? could work on a project with us, but I can't even do a simple "bzr whoami"
<chinoto> shnarf
<mgz> chinoto: why would you want to run `bzr whoami` on the dev server?
<mgz> and what exactly is the problem you're having?
<chinoto> well I wanted to run "bzr update", but it didn't work so I decided to try a simpler command and saw whoami
<chinoto> we have lines like this in '.ssh/authorized_keys'
<chinoto> command="bzr serve --inet --allow-writes --directory=/home/bzr/repo",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= XYZ
<chinoto> and I tried to do 'ssh bzr@dev.ffusa.net "bzr whoami"', but it just blinked at me...
<maxb> chinoto: you misunderstand how that ssh authorized keys stuff works - it means you cannot run commands on the server, so of course ssh host command does not work
<chinoto> perhaps it isn't misunderstanding, but not understanding in the first place :3
<chinoto> so I'm guessing this means I can only interact with the server through local bzr commands (eg 'bzr log --line :parent'). in order to update the server's working tree I would have to ssh in as a different user and do 'sudo -u bzr bzr update'?
<lifeless> if you have a working tree
<lifeless> servers generally don't
<chinoto> well we do
<lifeless> you may want bzr-upload for publishing a website, for instance.
#bzr 2012-09-06
<mgz> morning people!
 * fullermd obviously isn't one   ;p
<mgz> you're a category to yourself perhaps fullermd?
<fullermd> I'm autoontological!
<jam> mgz, vila, jelmer, jml: I put up a branch to handle: bug# 1046284
<jam> bug #1046284
<ubot5> Launchpad bug 1046284 in Bazaar "TooManyConcurrentRequests when committing to lightweight checkout" [Undecided,In progress] https://launchpad.net/bugs/1046284
<jam> In doing so, I'm starting a new branch for bug #1046697
<ubot5> Launchpad bug 1046697 in Bazaar "missing integration tests of lightweight checkout and remote repository" [Medium,Triaged] https://launchpad.net/bugs/1046697
<jam> Which so far has found at least 2 bugs in lightweight checkouts with remote repositories.
<jml> jam: cool :)
<jam> So I'm trying to decide how much to split this up.
<jam> Right now, I'm thinking to do 1 branch per small fix, and then have an overall integration branch that runs the full permutation tests.
<jam> That should leave us with easy to review small steps, and a test suite that ensures all those are correct when we're done.
<jam> vila,mgz,jelmer: Would you prefer I wait until I've fixed all the holes and have one major branch to review?
<jam> also, the initial fix is targeting 2.5
<jam> however, all these cleanup fixes could just be done in bzr.dev if we feel that is a 'safer' way to do it.
<jam> Thoughts?
<vila> out of blue, I'd say: target a final branch with all permutations passing and do as many intermediate branches you feel are small enough to review ? So basically, you're already doing that, go for it ;)
<vila> now, if you hesitate about 2.5 vs dev:
<vila> if 2.5 is deployed on lp, you'll get bug reports soon enough and would need to fix those bugs anyway, so go for 2.5
<vila> the alternative being rolling back from 2.5 on lp, I don't think you'll hesitate long ;)
<mgz> I don't mind seeing small intermediate branches, even if there's a rollup that's what lands in the end
<jam> vila: so far they are all client side fixes
<jam> so while the initial bug is exposed by bzr-2.5 on the server, it is only the client that needs updating.
<jam> Anyway, I'm happy to improve our test coverage and fix the holes that we've had a long time.
<jam> They aren't strictly regressions.
<jam> But meh, targeting 2.5 is cheap and easy.
<jam> If it was "we should target 2.1" I might fuss a bit.
<vila> client only but uncovered because lp has been upgraded, so to me, that's still part of the 2.5 experience, even for the clients
<vila> if < 2.5 clients encounter the issue, well, they'll have to upgrade
<jam> vila: so for 'get_file_text' it won't impact anyone who is running <2.5 because they won't try the new rpc
<jam> for the other bugs... I've only uncovered 1, which is that "WT.bzrdir.sprout()" is broken if you have a RemoteBranch.
<jam> but I'm sure we've had it for a while.
<vila> pretty good then
<jam> And upgrading LP would have triggered it.
<jam> I'm assuming I'll run into more bugs, though, as part of updating the test suite
<vila> clarification: lp has been upgraded or not ?
<jam> vila: lp has been upgraded
<jam> we added 1 new rpc, which triggers the bug in a bzr-2.5.1+ client calling WT.get_file_text()
<vila> to which version ? lp:bzr/2.5 or still with lp specific additional fixes ?
<jam> in a lightweight checkout of a remote repo.
<jam> vila: have to ask jelmer, but I think just stock 2.5.1
<mgz> it's a pretty specific thing, that most people haven't done because the performance was terrible
<mgz> now the performance isn't so terrible, but it breaks
<vila> mgz: but isn't it the recommended emacs setup ?
<mgz> have we got docs for the new way of doing :policy = appendpath stuff?
<mgz> an example locations.conf that sets the push_location of a lp branch sensibly would be nice
<mgz> ah, is all under configuration-help
<jelmer> grmbl, xchat seems to remove highlighting indication after disconnects
<jelmer> jam: yes, 2.5.1
<mgz> bug 1046773 confuses me
<ubot5> Launchpad bug 1046773 in Bazaar "can't push into new project" [Undecided,New] https://launchpad.net/bugs/1046773
<mgz> he claims this is against launchpad as a smart server, but I fixed bug 722416 in 2.4b1
<ubot5> Launchpad bug 722416 in Bazaar "Smart server transmits MemoryError as ('error', '')" [High,Fix released] https://launchpad.net/bugs/722416
<jam> mgz: note that 'error' is any generic "We didn't know about this error in advanced". It may not be MemoryError.
<jam> mgz: also note that he is using 'bzr-2.5b1' so still a beta release.
<jam> I would ask him to update to bzr-2.5.1 and confirm that the bug still happens.
<jam> we could have changed an RPC verb between b1 and 2.5-final or something like that.
<mgz> but as part of that fix, I made the smart server return the full error class name
<mgz> which is all server side.
<mgz> does launchpad actually keep bzr logs for smart server access? I can't find any.
<mmrazik> hi
<mmrazik> could somebody help with this stacktrace:
<mmrazik> http://pastebin.ubuntu.com/1188779/
<mmrazik> maybe a known error?
<jam> mmrazik: so we recently upgraded bzr on Launchpad, such that it now closes the connection if you leave it idle for more than 5 minutes.
<jam> I think if you either upgrade bzrlib locally, it will auto-reconnect.
<jam> Or just reconnect yourself.
<mmrazik> jam: thanks! let me try
<jam> I think sidnei was mentioning earlier that tarmac opens a connection, runs the test suite, and then tries to commi tit.
<mmrazik> jam: yes. Thats this case as well
<mmrazik> jam: do you know what version of bzrlib should I use?
<mmrazik> the box is something old (?oineric)
<jam> mmrazik: I'm sure the connection retry logic is in bzr-2.5
<jam> I thought there was an argument at the time that we were going to backport it to bzr-2.1 (stable series)
<jam> but I then was on rotation, so maybe that never happened?
<jam> (i don't see a release-notes indicating the retry logic was in any older stable release)
<jam> mgz, jelmer, vila: Do you remember what happened with the retry logic? Is my statement sound? (it is in 2.5, and we never backported it to a 2.1 release?)
<jelmer> jam: Yeah, I remember us backporting it to at least 2.2 too
<jelmer> but I'm not sure if we ever did a release with those changes
<mmrazik> how can I reconnect manually? Can you point me to some docs?
<jam> jelmer: Yeah, I think I did the work, but we wanted to wait to see how it sorted out.
<jam> mmrazik: https://launchpad.net/~bzr/+archive/ppa can get you a newer bzr for oneiric
<mmrazik> jam: thanks
 * mmrazik tries
<jam> ppa:bzr/ppa I believe
<jam> mmrazik: for the manual reconnect, I would just say re-open the branch object.
<jam> But I don't know the internals of tarmac all that well.
<mmrazik> I'll try the ppa first
<jam> ah, I think I know what is happening, and what we didn't expect.
<jam> the server is closing the ssh connection, and the ssh subprocess notices, cleans up and goes away
<jam> and then bzr tries to talk to the ssh process that isn't there anymore.
<jam> which is why we are getting EPIPE instead of ConnectionReset.
<mmrazik> that explaing the EPIPE
<mmrazik> yep
<jam> mmrazik: if you want to do a quick test, you might try forcing "BZR_SSH=paramiko" in the environment.
<jam> And see if that triggers ConnectionReset instead.
<jam> Just as a 'my hypothesis is sound' :)
<jam> then again, you may have credentials with openssh, and nothing will work with paramiko
<mmrazik> what is paramiko btw?
<mmrazik> I'm trying it right now...
<jam> mmrazik: paramiko is a python ssh implementation.
<jam> (we especially use it on Windows where openssh is likely not to be present.)
<mmrazik> jam: with paramiko it seems to be stuck at this stage:
<mmrazik> 26057kB     0kB/s | Revert phase:Apply phase:adding file 0/1
<mmrazik> mhm... the same stack trace with bzrlib 2.5.1 :-/
<jam> mmrazik: still EPIPE? strange.as there shouldn't be a subprocess for paramiko.
<jam> ah, you mean with 2.5.1
<mmrazik> jam: yes, EPIPE with 2.5.1
<jam> mgz, jelmer: https://code.launchpad.net/~jameinel/bzr/2.5-remote-wt-tests-1046697/+merge/123061 is a rollup of all the fixes for lightweight checkouts and a remote repository.
<jam> it ended up only 459lines, so you might just review that.
<mmrazik> jam: if I have bzrlib.branch object, what can I do to re-connect
 * mmrazik is trying to read the API but doesn't find anything
<jam> mmrazik: I think there are 2 things to try, depending on how comfortable you are hacking python code and testing it.
<mmrazik> lets try :)
<jam> I think one issue is that we are using a socket_pair rather than a pipe to communicate to the subprocess, so we didn't expect EPIPE.
<jam> mmrazik: so to just reconnect manually,y ou can do "mybranch = mybranch.bzrdir.open_branch()" I think.
<jam> that would be at the tarmac level.
<mmrazik> yep
<mmrazik> just trying that
<mmrazik> I need at least some quick hack to make the system work
<jam> at the bzrlib level, I would probably do something like: http://pastebin.ubuntu.com/1188861/
<jam> I think the issue is that the retry logic is there, but it isn't treating EPIPE as a connectionreset failure.
<jam> mmrazik: I would guess the traceback is slightly different (the line numbers at least don't match up) can you paste the new traceback?
<mmrazik> jam: http://pastebin.ubuntu.com/1188864/
<jam> mmrazik: hmm... it looks like it is actually retrying at that point...
<jam> the failure is occuring at line 13 of: http://pastebin.ubuntu.com/1188866/
<jam> note that we've caught a ConnectionReset and are retrying the request.
<jam> mmrazik: my wife is giving me the "I've been ready to leave for 15 minutes" look, so I have to go now, but I'm happy to work with you more tomorrow.
<mmrazik> jam: thanks!
<jam> mgz, jelmer: ^^ if you can get a chance to follow up on this. We *might* need to rollback bzr-2.5 but hopefully we can do a client side fix instead.
<jelmer> jam: *nod*
<mgz> ...I'm confused by the status of this reconnect bug,
<mgz> it's paramiko only, or for any ssh connection?
<mmrazik> mgz: I tried paramiko but it didn't really help. The stack trace went away but tarmac "hang" at certain stage
<mmrazik> so its any ssh connection
<mmrazik> I'm just trying paramiko with the newest bzrlib
<mmrazik> to see if there is a change
#bzr 2012-09-07
<jam> mmrazik: feel free to ping me when you come back online
<jam> I'm guessing paramiko + tarmac is actually trying to prompt for a password/etc which is why it is hanging. (Since you probably have credentials set for openssh that paramiko might not know about.)
<jam> we can debug that if we want, but given it looks like the connection is being retried and is *still* failing, I think we need to dig deeper.
<jam> So I'd like to debug it in a bit more hands-on way.
<mmrazik> jam: ok. Let me try to re-create the setup. Will take me a few minutes.
<mmrazik> jam: so this is where I'm right now: http://pastebin.ubuntu.com/1190380/
<mmrazik> jam: but I'll be on a phone for a while now
<mgz> morning!
<vila> hi mgz
<mgz> hey vila
<jam> mmrazik: k, I'll be doing lunch and digging into some lp stuff for a bit, but I'll try to be responsive when you get back.
<mmrazik> jam: is there something I should try now?
<mmrazik> I'm a bit stuck TBH
<jam> mmrazik: do you know what version of tarmac you are running (just to try to set things up similarly here)
<jam> mmrazik: line numbers in your traceback don't quite match up to tarmac trunk, but you might be able to do something like: http://paste.ubuntu.com/1190405/
<jam> ah, you might need to do both branches, 1 sec
<jam> http://paste.ubuntu.com/1190407/
<jam> mmrazik: ^^ should re-open both branches, creating new connections. at least as a stop-gap. I'd like to fix bzrlib, though, if you don't mind helping me investigate.
<mmrazik> jam: I'm on it now
<mmrazik> jam: regarding tarmac -- its unfortunately custom tarmac extension I didn't even write
<mmrazik> let me check if it is somewhere on bzr
<mmrazik> but the setup is fairly complex and requires jenkins
<mmrazik> the exension is some jenkins pre-commit logic and that is also why it fails. It waits for the jenkins job to finish only then commits.
<mmrazik> jam: I think the easiest way to reproduce will be to create some custom "sleep 420" pre-commit hook
<jam> mmrazik: is this the same one that sidnei was looking at recently?
<jam> (not sure which team you're on)
<mmrazik> jam: I don't know but we are different teams (and this one was written by yet another team)
<mmrazik> for me this tarmac stuff is almost end of life and I want to get rid of it
<mmrazik> its just some legacy I had to maintain
<jam> mmrazik: what are you switching to?
<mmrazik> jam: more jenkins driven approach. where the logic is in jenkins.
<mmrazik> it also scales better because jenkins can schedule build slaves
<mmrazik> right now tarmac must be running on the same node where the jenkins job runs
<mmrazik> anyway... going to patch tarmac with the patch you provided
<mmrazik> patched/running
<mmrazik> jam: I believe it is this one: https://code.launchpad.net/~didrocks/tarmac/tarmac-jenkins
<mmrazik> but as I said there should be a simpler way how to reproduce
<jam> mmrazik: seeing if I can reproduce it trivially.
<mmrazik> jam: the tarmac patch you provided didn't help :-/
<mmrazik> http://pastebin.ubuntu.com/1190430/
<mmrazik> AFAICT it now fails in the  "source.bzr_branch = source.bzr_branch.bzrdir.open_branch()" which I just added
<jam> mmrazi|otp: http://paste.ubuntu.com/1190441/
<jam> is another patch you can try when you get back.
<jam> mgz: poke
<mmrazi|otp> jam: running it
<mmrazik> jam: still no luck :-/ http://pastebin.ubuntu.com/1190559/
<jam> mmrazik: the traceback shows it isn't the new code: source.bzr_branch = source.bzr_branch.bzrdir.open_branch()
<mmrazik> jam... argh... sorry. I didn't apply it correctly
<mmrazik> jam: yes. Just looking at it
<mmrazik> jam: looks better now. There is still a stacktrace but I think its because the tarmac user is not allowed to push into the branch
<mmrazik> I'm now trying with the real thing
<mmrazik> jam: ack. it works with the tarmac patch.
<jam> mmrazik: so that at least gets you up and running again.
<jam> I'm trying to see if I can reproduce here. The 5-min wait to test is a bit annoying.
<mmrazik> jam: yep. Many thanks for the help.
<jam> I think I tried paramiko, and found it hangs at the point of reconnect.
<jam> which might be what you saw.
<mmrazik> let me know if you need some more help with this
<jam> well, I should know in about 200 more seconds if it reproduces locally.
<jam> mmrazik: :( it doesn't reproduce here, the retry works: http://paste.ubuntu.com/1190598/
<jam> (that is seconds *10)
<jam> at 5 min it gets the 'you're disconnected' from the server.
<jam> at 35s, the client notices, and retries the connection.
<jam> and successfully gets Branch.last_revision()
<mgz> hm. I wonder what's different.
<mmrazik> :-/
<jam> mgz: well offhand I wouldn't expect EPIPE from a *socket* object, but the traceback clearly looks like it is failing while retrying, not failing in the initial request (and then failing to retry)
<jam> mgz: hmm.. right now I'm running on Windows, which uses actual pipes, rather than socketpair. I wonder if that matters.
<jam> mgz: can you run this on your machine: http://paste.ubuntu.com/1190654/
<jam> and maybe you as well mmrazik ^^
<mgz> jam: sure
<jam> I can see that if I run BZR_SSH=paramiko, I don't see the stderr 'you have been disconnected' message.
<mmrazik> jam: running
<mmrazik> so far so good. just numbers
<mmrazik> oh..
<mmrazik> thats expected :)
<jam> mmrazik: well, expected for 350s :)
<jam> mgz, mmrazik: weird, when running with paramiko, we end up looping on a socket.sendall trying to send 119 bytes, and we just keep failing.
 * mmrazik shour read the code before copy&pasting&running something
<mmrazik> s/shour/should/
<jam> it gives us a "sent 0 bytes" in response, but doesn't actually give an error.
<jam> I think we should probably have a check for 'if bytes sent == 0: EOF"
<mmrazik> jam: the code can reproduce the error
<mmrazik> http://pastebin.ubuntu.com/1190681/
<jam> mmrazik: so... progress of a sort.
<jam> bug #1047309
<ubot5> Launchpad bug 1047309 in Bazaar "ssh paramiko loops endlessly sending 0 bytes" [High,Confirmed] https://launchpad.net/bugs/1047309
<jam> mgz, jelmer: can you think if sock.send() can legitimately say "I couldn't send any content right now" without raising EINTR?
<jam> I realize it returns the number of bytes written, but if it can't write *any* bytes, should we treat that as EOF immediately or should we try a couple times.
<jelmer> jam: couldn't there be a buffer that's full, or something like that?
<jam> jelmer: man send says: http://paste.ubuntu.com/1190698/
<jam> it will block until it can send what you asked
<jam> unless you are in non-blocking mode
<jam> but then send should fail with EWOULDBLOCK
<jam> MSG_NOSIGNAL (since Linux 2.2)
<jam>        Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connec-
<jam>        tion.  The EPIPE error is still returned.
<jam> interesting.
<jam> and we use blocking sockets (because when you set nonblocking it causes the smart server tests to fail)
<jam> mmrazik|otp: ok, in this particular case, it looks like it is getting EPIPE during the first send, not during the retry, so I think our code just isn't handling EPIPE as a connection reset
<jam> I'll try to dig some more.
<jam> mgz: can you confirm that it fails for you?
<mgz> onesec
<mgz> okay, running remotely, will tell you when it returns
<mgz> 30
<mgz> Connection Timeout: disconnecting client after 300.0 seconds
<mgz> and traceback at loop end.
<mgz> same as mmrazik.
<jam> mgz: k, I think I know the bug, and i'll put up a fix, can you run the fixed code in a sec.
<jam> mgz, mmrazik: If you are comfortable running bzr from source: lp:///~jameinel/bzr/2.5-conn-reset-socket-pipe-1047325
<jam> it doesn't have a test, but it should fix the problem
<jam> (if it is that we aren't retrying at all.)
<mgz> sure, I'll test that.
<mgz> probably just want the builddeps on this..
<jam> mgz: did you get a chance to test the branch?
<jam> I also have: https://code.launchpad.net/~jameinel/bzr/2.5-unending-sendall-1047309/+merge/123268
<jam> up for review.
<mgz> jam:
<mgz> Connection Timeout: disconnecting client after 300.0 seconds
<mgz> 31
<mgz> 32
<mgz> 33
<mgz> 34
<mgz> ConnectionReset calling 'Branch.last_revision_info', retrying
<jam> mgz: did it print the revision_id at the end?
<mgz> so, will review other branch, and that fix looks good
<mgz> jam: yup, the lack of traceback was the main thing :)
<jam> mgz: I think the fix is good, I'd like a test for it, so if you have ideas, I'm listening.
<jam> I might get to it over the weekend, and then we should do 2.5.2
<mgz> I do wonder about if we've got the exception wrapping at the right level
<mgz> there are some tests that try to check connection reset stuff, but are a little unreliable as terminiation a connection from one thread in a process to another thread is not actually the same as what really happens
<mgz> the short answer is you replace the underlying call to raise an exception we've observed it raising and make sure it propogates wrapped up netly
<mgz> *neatly
<mgz> but a more real world test would be grand...
<awilkins> Gah, why did I ever set things up with NTLM auth (answer : because most of my users are noobs and it's easier when it works...)
<awilkins> In the position where I have a tree that SVN can check out fine (anonymously) but Bazaar can't branch it (fails the NTLM auth)
<awilkins> Does Bazaar just use PyCurl if it's installed?
<awilkins> Hmm, maybe not
<mgedmin> every time I see "Aborting commit due to empty commit message." I feel that I â¥git
<mgedmin> you're missing an opportunity here with that interactive roadblock
<mgz> mgedmin: I'm not sure what you're referring to, but every time, and you've never got as far as just sending a patch?
<awilkins> Every time I see a commit without a log message, I feel that I â â¢â¹ the annoying sod that committed it.
<jml> you guys are going to force me to implement 'bzr branches --merged' aren't you?
<mgz> are we?
<fullermd> Look, I never _said_ I'd kill your puppy if you didn't...
<mark06> is it possible to make bazaar recognize mac newlines?
<mark06> it's considering the whole file changed when no newline conversion happened in fact
#bzr 2013-09-03
<Noldorin> is colocated branch support still developmental?
<jelmer> Noldorin: Yeah, I was working on it but never finished it.
<Noldorin> jelmer, ah okay. that explains why all the documented for it is limited and old then :)
<Noldorin> jelmer, plans to finish it at some point/
<jelmer> Noldorin: I don't think there is any documentation, is there ? :-)
<jelmer> It's not meant to be used yet.
<Noldorin> heh no, just a few pages on the wiki i mean
<jelmer> Noldorin: No, I'm no longer working on bzr.
<Noldorin> jelmer, oh i seeâ¦ quite the comapny or just working on a different project now?
<jelmer> Noldorin: quit the company, and switched away from using bzr
<Noldorin> oh i see
<Noldorin> jelmer, what do you use now?
<Noldorin> jelmer, ?
<Noldorin> oh well...
<Noldorin> typical jelmer heh
<Noldorin> the disappearance act
<SamB> Noldorin: judging by his blog and his debian/changelog entries, I'd have to say he's switched to git
<Noldorin> SamB, oh no :(
<Noldorin> how treacherous
<Noldorin> git is horrid.
<Noldorin> at least bzr is still under active development, thank goodness
 * SamB checks bzr log lp:bzr again ...
<Noldorin> SamB, know if someone is continuing work on colocated branches though?
<neXyon> hi, how can I find the meaning of the a.b.c revision numbers that annotate for example show?
#bzr 2013-09-04
<Wiz_KeeD> is tehre anything wrong in creating a bzr init . and bzr init-repo .
<Wiz_KeeD> in the same directory meaning?
<Noldorin> is colocated branch support already integrated in latest bzr?
<Noldorin> there seems to be a separate bzr-colo plugin
<Noldorin> how are they relateD?
<fullermd> I think one is sketchy and incomplete, and the other is sketchy and incomplete.
<jelmer> Noldorin: hi
<Noldorin> hi jelmer
<Noldorin> fullermd, ha i see
<Noldorin> jelmer, yep, your work again ;)
<jelmer> Noldorin: the two are unrelated; the bzr-colo plugin works better I think, though I've never used it
<Noldorin> ah right
<Noldorin> got it
<jelmer> the support in core is incomplete, and sketchy at best. I wouldn't recommend using it for production stuff.
<Noldorin> cheers
<jelmer> Noldorin: nobody else is working on colocated branch support in bzr core; not sure about bzr-colo
<Noldorin> yeah bzr-colo seems semi-active
<Noldorin> hm
<Noldorin> jelmer, incidentally, why did you move to git? i'm curious
<jelmer> Noldorin: the short answer is that that's what everybody else is using; the long answer is at http://stationary-traveller.eu/pages/bzr-a-retrospective.html
<Noldorin> ah, fair enough jelmer
<Noldorin> bah, i have plugins installed on two places on my system it seems:
<Noldorin>  /usr/local/lib/python2.7/site-packages/bzrlib/plugins
<Noldorin>  /usr/local/opt/bazaar/lib/python2.7/site-packages/bzrlib/plugins
<Noldorin> what's up with this? :S
<fullermd> How bazaar.
<Noldorin> heh
 * fullermd hasn't had a good excuse to use that in _weeks_.
<Noldorin> fullermd, it seems bzr is actually reading the former dir but not the latter, however
<fullermd> The latter sounds like a dropping from some sort of specialized intallation.
<jelmer> hi thedac
<jelmer> hi thumper
<thumper> hi jelmer
<jelmer> thumper: I sent in a merge request for wikkid recently; are you still maintaining it?
<thumper> jelmer: hey, yeah I saw it, yes kinda maintaining it, not done a lot recently
<thumper> I hove no real objection to merging it, just haven't gotten around to it :)
<Noldorin> fullermd, what does that mean heh?
<jelmer> thumper: I'm not in a hurry, just wanted to make sure it wasn't sitting there pointlessly :-)
<thumper> :)
<fullermd> Some sorta super-install that includes a local python, maybe?
<fullermd> Or maybe just an install from a somewhat screwy config that dropped files there due to being built against an odd python system, etc.
<fullermd> I refer to such things professionally as "Idunnowasn'tme".
<Noldorin> heh
<Noldorin> fullermd, probably homebrew making a mess of things...
<fullermd> Could be.  The /opt/ bit is a dead giveaway for a lot of specialized package management/installation tools.
<Noldorin> fullermd, should a normal bzr install have a root lib/ dir?
<Noldorin> it seems to just include the python2.7/ dir that isn't getting used
<fullermd> Well, it's gonna put files in whatever %%PYTHON_SITELIBDIR%% is, and that's usually /something/lib/pythonX.Y/site-packages/
<fullermd> So packages will usually have paths in them like "lib/python....." since they'll install rooted at /usr/local or /opt or the like, depending on the system.
<Noldorin> i see
<Noldorin> meh, all fixed now :)
<Noldorin> fullermd: unrelated question: is there any way to remove dead heads from a branch?
<fullermd> That sounds contradictory.  If it's in a branch, it's not dead  :)
<fullermd> From a repository?  Not in any UI sense.
<Noldorin> fullermd, well all non-tip heads are dead no?
<fullermd> "Non-tip head" also reads rather contradictorialiciously   :)
<Noldorin> fullermd, take it up with the develoepr of bzrtools then :P
<Noldorin> that's the terminology they use
<Noldorin> contradictorily is the word you want incidentally :)
<fullermd> No, it's a word that would be _sufficient_.  The word I _wanted_ is the one I used   ;p
<Noldorin> fullermd, haha okay then
<Noldorin> we'll grant you poetic licence for now i suppose...
<fullermd> I've got 3 points on my poetic license currently.  2 more and I'll have to sit through another class.
<Noldorin> not surprised i am, the way you're at it1
<Noldorin> sheer gratuity, that is.
<fullermd> Anyway, I think you're mis (or over-) reading.  In a branch, 'head' and 'tip' are pretty well synonymous.
<Noldorin> fullermd, but are there not dead heads in a repo?
<Noldorin> which are not tips of any branch
<fullermd> In the sense of the 'heads' command, it's tweaking the definition of head a bit to mean descendentless revs.
<Noldorin> ah
<Noldorin> i see
<fullermd> In that sense, a branch tip may not be a 'head' (e.g., I merge a branch into another; that branch's "head" now _does_ have a descendent in the repo, but it's still the tip of that branch)
<fullermd> A head dead[1] in a repo would be one that isn't in any branch.
<fullermd> [1] I didn't switch the words around.  I only switched the first letters.
<Noldorin> right
<Noldorin> heh
<fullermd> So, there can't possibly ever be a dead head in a branch  :)
<Noldorin> yes fair enough
<Noldorin> anyway
<Noldorin> fullermd, how can i remove dead revisions (or heads in the bzrtools sense) ? ;)
<fullermd> Pretty straightforward.  Just write a gc command/plugin.
<fullermd> Actually, you can even cheat and start from the gc plugin that almost existed and worked 10 versions and 2 formats ago, so it's even easier.
<fullermd> Not only will that clean up your repo, but it's sure to get you money, fame, and chicks.
<fullermd> (if you release it, anyway.  Nobody likes a jealous coder)
<Noldorin> fullermd, gc?
<Noldorin> hah
<fullermd> Oh, I guess you could call it something else if you really wanted.
<Noldorin> i always knew getting into bzr would earn me those things!
<Noldorin> now it's finally paying off eh
<Noldorin> fullermd, what does 'gc' mean though?
<fullermd> Exactly!  If it weren't for bzr, I'd have spent last weekend sitting at home alone!
<Noldorin> well jolly good you didn't then!
 * fullermd nods.
<fullermd> Thanks to bzr, I sat at home alone and committed things into a bzr repo.
<fullermd> 'garbage collect' or some inflection thereof.
<Noldorin> fullermd, oh well, then what more could you ask for? who needs chicks, fame, money when you have that
<Noldorin> fullermd, ah i see
<fullermd> Well, I'd ask for colocated branches and a gc command, for starters...
<Noldorin> okies
<Noldorin> i'll have them both to you tomorrow sir!
<Noldorin> fullermd, would you be so kind as to point me to the existing bzr gc stuff?
<Noldorin> if it exists in a branch indeed?
<fullermd> I have no idea if it exists anywhere publically.  I think either jam or lifeless was the one fiddling with it, but it was a long time ago.
<fullermd> pre-2.0 even, I think.  So there have probably been 3 supercontinents formed and broken up since.
<lifeless> heh
<Noldorin> eek
<Noldorin> fullermd, maybe i can just fiddle with bzrtools to add the feature ;)
<fullermd> Hey, while you're in there, you can update it to quiet down and accept that 2.6.0 is a valid bzr release.
<Noldorin> fullermd, oh, where does it complain about that?
 * fullermd shrugs.
<fullermd> Whenever you use it.
<fullermd> Plugin "Bzrtools" is not up to date with installed Bazaar version 2.6.0.
<fullermd> There should be a newer version of Bzrtools available, e.g. 2.6.
<Noldorin> fullermd, looks like it's already been fixed in the devel branch
<fullermd> (complains about the 2.7 in bzr.dev too of course, but you can pass two stones through one bird)
<fullermd> Mmm.  I don't see any; last change about versions was for 2.5 Thu 2012-01-19.
<fullermd> missing says I'm up to date.  Maybe upstream moved behind my back.
<Noldorin> hm
#bzr 2013-09-05
<Noldorin> fullermd, incidentally, how exactly are pull and update related? they seem to do very similar things
<fullermd> pull changes a branch (and possibly its WT) to match another branch.  update changes a WT to [some rev along] its branch.
<Noldorin> fullermd, ah. both do a merge though no?
<fullermd> Not in the sense of the "merge" command.
<fullermd> update does a merge in the conceptual sense, in that it tries to bring forward any uncommitted changes relative to the previous base rev to the new one.
<fullermd> (and pull's internal 'update' if there's a WT does the same)
<Noldorin> fullermd, ah so pull automatically does an update if there's a WT?
<fullermd> Well, except the wacked-out bound-branch --local case, where it does crazy things to screw with you.
<fullermd> But you asked for it, so you deserve it.
<Noldorin> ha
<Noldorin> fullermd, what's bound-branch --local case? :P
<fullermd> Conceptually, yes.
<Noldorin> hmm?
<fullermd> ...  you're probably too young to be told about it.
<Noldorin> ha
<Noldorin> i can handle it, try me!
<fullermd> Y'know that feeling where you cough so hard your liver ends up dangling out of your mouth?  It's kinda like that, except with version control.
<Noldorin> nopeâ¦ i'm pretty sure that's anatomically impossible!
<fullermd> Exactly.
<Noldorin> ha
<Noldorin> fullermd, so if i just stay clear of it i'll be happy and missing out on nothing?
<fullermd> Sadly, bzr's anatomy got rewired once so that it's possible.
<Noldorin> heh okay
<fullermd> Yes.  Never ever type "ci" and "--local" at the same time.  If you see anybody else do it or advocate it, beat them to death with a baseball bat.  It's the only merciful thing to do.
<Noldorin> and also, what's the diff between update and revert nowâ¦ is it just that update chances the current revision number too?
<Noldorin> heh okay, i will trust you on that
<fullermd> Two...  three...   some number of things.
<fullermd> First, yes, update changes the WT's idea of what rev it's based on; revert doesn't.
<fullermd> Second, revert only puts a file/files exactly to the state of the given (or implicit) rev, not attempt to merge outstanding changes like update does.
<fullermd> Third, update only makes sense on the whole WT; you can't update just one file.
<fullermd> So update is more for things like "Hey, I want to step back and see what things were like in rev X".
<fullermd> Whereas revert is more for cases like "throw away these changes I've made since last commit", or "stage up changes to this file to move it back to the state it was in at rev X"
<fullermd> i.e., "bzr revert -rX file" is pretty much like "bzr diff -rX file | patch -R"
<fullermd> (ignoring cases of renames etc)
<Noldorin> ah
<fullermd> There are a lot of cases where you _could_ use either, but the unfitting one is likely to make things squirrely down the line.
<Noldorin> fullermd, but you said revert puts the file in the same exact state as the file at the specified revision?
<Noldorin> squirrely. haha. got it
<fullermd> Yes.
<fullermd> An alternate expansion (again ignoring complications from renames) would bzr "bzr cat -rX file > file"
<fullermd> Dur.  "would be".  Eye khan tipe.
<Noldorin> fullermd, you just audibly ran together the be and the first syllable of bzr. understandable ;)
<Noldorin> fullermd, okayâ¦ so does it warn you if the file has uncommitted changes?
<Noldorin> or what
<fullermd> No.  After all, the overwhelming majority of uses are of the "throw away my uncommitted changes" variety.
<fullermd> I can't remember the last time I used -r on revert.  But the last time I used revert with no -r was less than an hour ago.
<Noldorin> makes sense
<Noldorin> fair enough
<Noldorin> fullermd, thanks :)
<Noldorin> fullermd, oh yeah, and last thing: i see trees mentioned every once in a while in relation ot bzrâ¦ i know what working trees are, but what about trees in general?
<fullermd> Usually people mean the same thing.
<fullermd> Sometimes you'll run into some propellerhead using it to talk about an internal data structure.
<lifeless> flap flap flap
<Noldorin> lifeless ?
<Noldorin> fullermd, i see
<Noldorin> fullermd, so what about these split/join commands that work with trees?
<Noldorin> and yeah i know about tree data structures. assumed it wasn't them. :)
<fullermd> join is a shortcut to merge-into-subdir (a previously unrelated branch)
<fullermd> split is a shortcut to "branch ; rm everything else ; mv to root ; commit"
<fullermd> (they're not really complementary operations, naming suggestiveness aside)
<Noldorin> fullermd, oh cool. wish the help was that clear. i get it now
<Noldorin> wish the help were*
<fullermd> Well, you wouldn't want it to put me out of a job, would you?
<Noldorin> of course not ;)
<fullermd> Think what would happen to me standard of living if, say, I only got paid HALF as much to hang out on IRC.
<Noldorin> fullermd, then you wouldn't be able to live the high life any more either!
<Noldorin> ^
<Noldorin> heh
<lifeless> fullermd: they aren't complementary? They reverse each other....
<fullermd> No they don't.  If you join a branch in, then split it off, you don't get anything at ALL like the old branch.
<lifeless> fullermd: oh?
<fullermd> It gains like 2 kadnillion pounds, and the mainline history is completely different.
<fullermd> (and those pounds are NEVER coming off, man!  Even if Noldorin gets that gc command written!)
<lifeless> fullermd: so the weight gain is directly analogous to an add/delete pair
<lifeless> fullermd: however the mainline history is an interesting point
<Noldorin> hah
<lifeless> fullermd: since there can be only one at the joined point
<fullermd> Also, if you ever go back and 'merge' that branch into the one you just did the join/split from, it's gonna delete everything.
<lifeless> both operations drive time forward, yes.
<lifeless> they are tree shape operations, not history edits.
<lifeless> Both could be expressed as history edits.
<fullermd> I guess you could call them complementary in that one kinda does the "opposite" of the other, but it doesn't do the "reverse" of the other, which is easy to misinfer from the names.
<lifeless> so undo in every case is 'pull -r -2 . --overwrite'
<lifeless> gc isn't semantic
<fullermd> An extra sticky point is that split doesn't do what a lot of people would automatically think it does either.  Not that I think it reasonably could, but it's a training wart.
<fullermd> That's why it wouldn't take the pounds off   8-}
<lifeless> so yeah, split isn't filter
<lifeless> filtering is a history edit
<lifeless> splitting isn't
<fullermd> Yeah.  Whereas on the "join" side, there's not so much confusion among things you could think of it as doing.
<lifeless> I think split and join would be more clear if they only manipulated the current tree; I don't recall exactly whether they do or don't.
<fullermd> Mmm, I dunno.  split sorta has to make a new tree anyway to do its job.  Or a new branch, at least.  I s'pose in theory it could be implemented to not change the current tree/branch at all, and just make the new one --new-branch /somewhere/else
<fullermd> But I think most uses of it would then go ahead and wax that subdir from the original branch anyway.
<fullermd> And join, well, it _could_ leave that subtree/.bzr there, but that just means that 'ci' starts acting differently depending on where you are in your now-whole project.
<fullermd> I think it's just an explanatory/training issue.  I like making the non-complementary (not necessarily in those words) point just so it's easier to explain this command, and then that command.
<fullermd> Rather than "this pair of commands", which I think confuses things more.
<lifeless> fullermd: split doesn't have to make a new tree
<lifeless> fullermd: it can be define in two parts; 'remove subtree' which is well known (rm -r) and 'promote a subtree to the root' which is this-tree-only.
<lifeless> fullermd: join can just setup the tree ready to commit - do the merge etc
<fullermd> It does, I think.
<fullermd> Yep.
<fullermd> Actually, looks like split doesn't create any of the revs either, just does the pre-manipulations.
<fullermd> (leaving you two trees with uncommitted changes)
<lifeless> good
<lifeless> so, I don't see any reason they can't be complementary. It's what happens if you commit in the middle that is hairy :)
<fullermd> You've been wallowing in git too long, soaking up that rancid "auto-commit merges" oil  ;)
<lifeless> fullermd: eww, I still hate that
<lifeless> fullermd: I embrace history editing now; but then I embraced that before I stopped hackin on bzr (e.g. my manifesto on it...)
<fullermd> I saw a thread on the git list just the last few days about a merge proposal (whatever they call it) to default-disable non-ff 'pull's too.
<lifeless> yay
<lifeless> that will avoid lots of omfg experiences
<fullermd> http://thread.gmane.org/gmane.comp.version-control.git/233554
<fullermd> (I haven't watched it close enough to tell if it's going to land or not)
<Noldorin> fullermd, interesting. bzr branch seems to do garbage collection already
<Noldorin> fullermd, would seem like gc should effectively do a branch into itself then, conceptually
<quicksilver> mathrick: I owe you a massive debt for showing me @emacsrocks and the author thereof. Just discovered his 'modern' string and functional programming libraries for elisp. Life-changing!
<mathrick> quicksilver: you're welcome! I've only discovered him by accident myself and I've been using multiple-cursors constantly since then
<quicksilver> mathrick: ( https://github.com/magnars/dash.el https://github.com/magnars/s.el  )
<mathrick> yup, I haven't actually looked into them as libraries, but magnars's been astonishingly productive since he discovered emacs himself
<mathrick> I think he's been using it for less than two years?
<mathrick> quicksilver: oh heh, dash is actually named after RD, that's neat
<quicksilver> mathrick: he'd been using it just a few weeks when he uploaded the first emacsrocks video (or that's what he said)
<quicksilver> mathrick: I've been using emacs for 19 years. I feel kinda inadequate :)
<mathrick> heh
<mathrick> quicksilver: 15 here, and my first years with elisp were terrible, which I've been made acutely aware of recently when I cleaned it up
<tlonim> I am trying to ignore a directory from parent with bzrignore (during merge), but when I merge that directory is also included in conflicts, any way to avoid this?
<mgz> tlonim: you should just be able to resolve the conflicts as you merge
<mgz> so, eg, do the merge, `bzr mv` the files in the dir you want to keep somewhere else, delete or ignore the other bits, run `bzr resolve` on all the paths you've dealt with as listed in `bzr st`
<tlonim> I did a bzr remove <dir> and then bzr resolve --all (since this directory's conflicts were the only ones left)
<tlonim> that should do right?
<mgz> you don't want --all probably...
<mgz> it's dangerous
<tlonim> the only conflicts remaining were for that ignored directory, other conflicts I had resolved by then
<mgz> and you probably need to remove all the actual files, rather than leaving them around
<mgz> anyway, provided the confict is resovled and the directory is unversioned when you commit, you should be fine
<tlonim> yeah
<tlonim> thanks
<ovnicraft> hello, i have a doubt when merge braches i want to know with detail what means * prefix in output for each file
<ovnicraft> i know +N means new
<ovnicraft> i cant find documentation about it? anyone can help me with this ?
<mgz> ovnicraft: it means the +x bit changed on the file
<mgz> see `bzr help status`
<ovnicraft> mgz, this +x change happens when C&P as usual ?
<mgz> depending on your filesystem it might, yes
<dpb1> Hi -- we have a dependency branch that contained jar files and other binaries.  Is there any way to purge the history of those files to speed up full checkouts?  Or are the only options lightweight checkouts and starting over with a new branch?
<mgz> as long as you don't have +x bit edit wars, you should be okay
<mgz> dpb1: there aren't nice easy ways, unfortunately
<mgz> you can rewrite them out of history, which is a somewhat manual process
<mgz> you can also just try repacking the repo which may help checout speed
<dpb1> mgz: what is the rewrite option?  does it involve contacting some bzr admin somewhere? :)
<mgz> it would involve using something like the bzr-rewrite plugin to completely change the repo history, which would also mean everyone would need to recheckout that
<dpb1> ok, like git rebase
<mgz> that might be an admin level thing, depending on how you're set up
<mgz> yup.
<dpb1> mgz: thx, I'll look into it.  I *think* we have a lot of jars in there, so it might be tedious, but it's worth learning about it.
<dpb1> I appreciate the help
<ovnicraft> mgz, how i can revert the +x change in my merge, considering what i get others changes what i need ? be specific by file ?
<lduros> hi, i'm trying to import a tar.bz2 file into a branch and merge it
<lduros> isn't it bzr import my.tar.bz2 my-branch?
<lduros> it tells me import doesn't work :\
<lduros> ah import-upstream
<jelmer> lduros: "bzr import" is a part of bzrtools I think
<jelmer> lduros: bzr import-upstream is for debian packages
<lduros> aH
<lduros> does it matter if I run import-upstream then?
<lduros> or will import work for tarballs?
<lduros> ah ok i got import now after installing bzrtools
<lduros> i'm using an upstream branch (made from tarball) and trying to merge it in my own: I get the following error:
<lduros> bzr: ERROR: The file id "nsiudpserversocket.i-20130905203643-hbkb6sb8s5pcmrpu-21924" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x7f1850c2ff90>.
<lduros>  
<lduros> i'm fine with replacing the file with whatever is in upstream
<lduros> is there a way I can work around this when doing bzr merge?
<lduros> trying bzr reconcile ../upstream
<lduros> hopefully it will do something
<lduros> hmm same error
<mathrick> jelmer: is bzr diff showing nothing for raw git branches a known problem?
<mathrick> working with git tools is annoying
<mathrick> I really miss silverline view of merges
<mathrick> throwing everything that ever crossed the DAG at me by default is not helpful when I'm trying to see the recent history and whether upstream has merged something
<mathrick> fortunately bzr qlog works fine on git branches, but without diffs it's pretty hard to use it as my only view into them
<Noldorin> hey fullermd, lifeless
<Noldorin> hi jelmer, too
<jelmer> Noldorin: hi
<jelmer> Noldorin: not sure - if it doesn't work it should be giving you a backtrace I think
<jelmer> what are you seeing?
<Noldorin> jelmer, hmm, what are you replying to? :)
<jelmer> Noldorin: sorry, EWRONGPERSON
<Noldorin> heh k
<jelmer> mathrick: not sure - if it doesn't work it should be giving you a backtrace I think
<Noldorin> no prob
<jelmer> what are you seeing?
<jelmer> Noldorin: what's up?
<Noldorin> jelmer, was wondering, were you ever involved in the gc functionality for bazaar?
<Noldorin> fullermd was mentioning the other day there was some gc plugin someone was working on
<jelmer> Noldorin: I think that might have been jam or lifeless
<Noldorin> jelmer, ah okay. so you don't know anything about it? i was just curious, because it seems the branch cmd already does a fair bit of gc
<jelmer> I've discussed it numerous times with people, but I don't think I ever wrote a single line of code :-)
<Noldorin> could be adapter perhaps
<Noldorin> ah :)
<jelmer> Noldorin: where does the branch command do gc?
<Noldorin> jelmer, i've no idea, but it's evident in practice!
<Noldorin> no idea where in code that is...
<Noldorin> jelmer, apparently it also helps slim down the metadata drastically after a split/join cmd
<Noldorin> so yeah, the branch operation must do something good with respect to gc
<jelmer> Noldorin: I think saying it does gc is confusing
<Noldorin> why?
<Noldorin> it evidently does
<jelmer> it selectively copies data, that's a different thing than gc
<Noldorin> jelmer, but that's *effectively* doing gc, if you know whati  mean
<jelmer> Noldorin: no, because you're not changing the base repository
<Noldorin> consider a hypothetical branch onto itself
<jelmer> Noldorin: have you seen doc/developers/gc.txt ?
<Noldorin> jelmer, i disagree. conceptually it's like a gc
<Noldorin> even if it's not in practice
<Noldorin> jelmer, no, is that in the main bzr branch?
<jelmer> Noldorin: I understand what you're getting at, but by that reasoning "bzr init" also does gc
#bzr 2013-09-06
<jelmer> Noldorin: yeah, that doc is in the main branch - has been for a number of years :)
<Noldorin> jelmer, does it though? i didn't think bzr init actually copies data from any other branch
<Noldorin> ok
<jelmer> Noldorin: it copies data, but just the data that is relevant *for the new branch*. It doesn't copy a lot of other data that would still be valid because other branches, either in the same repository or in stacked branches, rely on it.
<jelmer> s/valid/necessary/
<Noldorin> ah
<Noldorin> jelmer, eek, what's the command to do a shallow branch again? i'm just trying to get lp:bzr now, but i don't want it to be however many GB the full rev history would fill on my system heh
<Noldorin> jelmer, do i just want a stacked branch maybe?
<jelmer> Noldorin: FWIW the repository is 70Mb, not GB
<jelmer> Noldorin: --stacked
<Noldorin> oh right
<Noldorin> i thought it would be a lot larger!
<Noldorin> that's surprisingly small
<Noldorin> jelmer, guess you do a lot of metadata compression...
<lifeless> Noldorin: branch only copies referenced history
<lifeless> Noldorin: that is very different to repository level gc
<lifeless> Noldorin: which has to delete content other concurrent processes may be looking at
<lifeless> Noldorin: someone writing gc can of course layer on all the selective-copy work that branch layers on too.
<Noldorin> eek
<Noldorin> okay
<Noldorin> lifeless, has any of the implementation vaguely described in doc/develoeprs/gc.txt been started in fact?
<lifeless> Noldorin: I don't know, sorry - I haven't been following bzr dev closely for oh 3 years now
<Noldorin> ah
<lifeless> Noldorin: it's not conceptually hard to do
<fullermd> Only thing I ever even heard rumors of was that old gc plugin, and if it's even available anywhere it was so long ago that it probably wouldn't fit without substantial rework anyway.
<lifeless> Noldorin: but it does involve working at core levels of data storage to ensure correctness around locking / visibility etc
<Noldorin> lifeless, yeah, i wouldn't know where to begin with that...
<Noldorin> lifeless, fullermd, probably infeasible for someone who doesn't know the internal structure of bzr still, no?
<fullermd> Structure is an illusion.
<mathrick> jelmer: it just thinks there were no changes
<mathrick> mathrick@megumi ~/elisp/dist/git/multiple-cursors $ bzr diff -c -1
<mathrick> mathrick@megumi ~/elisp/dist/git/multiple-cursors $
<Noldorin> hey fullermd
<Noldorin> (if you're there)
<Noldorin> lifeless, jelmer ?
<mgz> Noldorin: it's a rle of irc, to just ask your question, rather than trying to handshake specific people
<Noldorin> mgz, no. i need specific expertise
<Noldorin> mgz, and i know who dealt with these things
<mgz> the the mailinglist is a better venue. it's the middle of the night in nz for instance
<mgz> *then the
<Noldorin> ah yes
<Noldorin> maybe
<mathrick> Noldorin: it's still a better idea to ask directly, even if you ping specific people, to bootstrap the talk, rather than going "you here?" "Yeah, what's up?" "Oh, I was away still around?"
<Noldorin> actually, i do have a general question anyway:
<Noldorin> what's the best way to learn about the internal structure of bzr?
<Noldorin> the way it uses metadata
<Noldorin> the formats utilised
<Noldorin> etc.
<mathrick> Noldorin: for some things, there will be blueprints and design docs on the wiki and launchpad
<Noldorin> ah
<mathrick> but I'm not familiar with any central place which would have complete, current and accurate picture
<Noldorin> hmm
<Noldorin> guess i'll just browse the wiki then
<Noldorin> mathrick, any areas/pages in particular you might be able to point me to? :)
<Noldorin> mathrick, i want to work on a gc/cleanup implementation after i familiarise myself with things
<mathrick> Noldorin: nope, sorry, I can't claim anything resembling enough familiarity to be able to tutor people
<Noldorin> fair enough
<vila> Noldorin: use the source, that's the only up-to-date version. The tests though should give you examples for anything you may dream about ;)
<mathrick> vila: what I always find tricky in large systems with involved and tricky design like bzr is finding out why things are, and which parts are the important bits you need to undertsand, and which are just details
<mathrick> unfortunately source usually doesn't tell you that
<lifeless> Noldorin: the code
<lifeless> Noldorin: there are design docs in the source tree; and there are design docs in the classes
<jelmer> Noldorin: hi
<Noldorin> lifeless, in the classes?
<Noldorin> lifeless in the actual code you mean?
#bzr 2013-09-07
<lifeless> yes
<Noldorin> lifeless, fair enough. will have a look, thanks
<Noldorin> hey jelmer
<Noldorin> what's up with this? http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/
<Noldorin> bazaar is sort of dying, isn't it?
<smartboyhw> Noldorin, what?
<smartboyhw> Bazaar is still widely used by Ubuntu and other FOSS projects
<Noldorin> smartboyhw, evidence is that it's been on the decline for a couple of years now, and development is slowing down, especially w.r.t. plugins, and people are gradually abandoning bzr everywhere
<Noldorin> it's sad, but it seems to be the case
<smartboyhw> Noldorin, I like Bazaar myself (it's simplier to use), but I think Canonical's efforts has switched to other aspects, so it makes sense
<Noldorin> maybe yeah
<Noldorin> smartboyhw, the number of canonical devs working on it has decreased dramatically it seems
<Noldorin> and outside contributions are virtually nil now
<smartboyhw> Noldorin, yeah
<Noldorin> smartboyhw, personally i'm with you. bazaar's conceptua/semantic model of version control makes a lot more sense than, say, git's
<Noldorin> but there are other tradeoffs to be make
<Noldorin> smartboyhw, a bzr-like wrapper over git might be a nice way forward actually. even some bzr devs have suggested that in the past, i noticed, on a mailing list
<smartboyhw> Noldorin, OK
<fullermd> It's not dying, it's pining for the fjords.
<Noldorin> heh
<Noldorin> fullermd, who knew bzr was norwegian?
<fullermd> Remarkable version control system, ain't it?  Lovely UI.
<Noldorin> :P
<Noldorin> speak sense, you!
<jelmer> hi Noldorin
<Noldorin> hiya
<SurvivorZ> OK. I have a feature branch w/ 8 commits. All 8 commits are merged into trunk. Now I have 5 more commits, merged into trunk, that should be in the feature branch. I know I can get to b4 the merge via $ bzr branch -rREV_B4_MERGE . newDir, but then how do I cherry pick pull the 5 later changes into the new branch? Everytime I do, it includes the merged feature branch, which makes it a copy of trunk.
<SurvivorZ> repo=".."; for rev in {21..27}; do echo -n "Rebasing -r$rev from $repo: "; msg=`bzr log --short -c$rev $repo | grep -Ev '^ *[0-9]+ [[:alpha:] ]+' | sed -e 's/^ *//g' -e 's/ *$//g' | tr -d '\n'`; echo $msg; bzr merge -c$rev $repo; bzr commit -m"$msg"; done
<SurvivorZ> I just created that to do what i want...
<Noldorin> jelmer, not to mind. i found your old remove-revision plugin. handy little tool, cheers!
<jelmer> ah, cool
<jelmer> hope it's useful to you :)
<jelmer> it's not the most efficient way this could be done, but I guess it sort of works
<Noldorin> jelmer, yeah, it's an infrequent operation, so as long as it works, i'm happy heh
<Noldorin> jelmer, hmm. is it possible to have a user-local ignore file for a branch?
<Noldorin> i.e. one that doesn't exist in the actual branch
<jelmer> Noldorin: in short ,no. see the mailing list for details
<Noldorin> ah
<fullermd> Well, if there isn't one for the branch, you can.
<fullermd> Just stick a .bzrignore in there and don't add it.
<fullermd> (and ignore itself, so you don't accidentally do so)
<lifeless> Noldorin: you can have a user-local global ignores file
<Noldorin> fullermd, yeah i want them side by side, really
<Noldorin> lifeless, that's good enough for me, i suppose, yeah :)
<fullermd> You could hack up the filesystem so that it alternates which one shows up on any given stat()/open()   ;)
<Noldorin> fullermd, oh oh, what a superb idea!
<Noldorin> well worth my time, no doubt
<Noldorin> so elegant too
 * fullermd is full of such wisdom!
<Noldorin> i bet
<Noldorin> so i'm trying to update bzr remove-revisions so that it works in the latest bzr now
<Noldorin> bzr: ERROR: exceptions.AttributeError: 'CHKInventory' object has no attribute '_byid'
<Noldorin> any ideas how to fix this?
<Noldorin> nvm
<Noldorin> but now i need to figure out what's happened to repository.text_store and repository.control_store
<fullermd> Obviously, they're closed for the weekend.
<Noldorin> fullermd, closed permanently, i hear
<Noldorin> fullermd, but i also hear they reopened under new names and formats. perhaps you know more about it? :P
<fullermd> I don't.  I just dork around with the UI, I stay away from that icky "thoPyn" or whatever that's under the hood.
<Noldorin> heh i see
<jelmer> Noldorin: yeah, I think the plugin is specific to an older format
<Noldorin> mm
<Noldorin> jelmer, was hoping i could rewrite it easilyâ¦ but not proving trivial
<Noldorin> not with my knoweledge of the internals at least
<jelmer> it should be fairly easy - basically just clone the repository revisions but exclude the ones specified
<Noldorin> heh
<Noldorin> that assumes i know the object model
<Noldorin> but still
<Noldorin> if i invest a little time, you're probably right!
#bzr 2013-09-08
<Noldorin> jelmer, sorry disconnected
<Noldorin> jelmer, hi
<jelmer> Noldorin: Himmagery
<jelmer> I mean, Hi
<Noldorin> heh
<Noldorin> :)
<Noldorin> jelmer, so the problem i'm having with porting your plugin is that repository.text_store and .control_store were VersionedFileStore objects, but they've been (apparently) moved to the .revisions, .inventories, .texts, etc. properties
<Noldorin> which are VersionedFiles objects, not stores
<jelmer> sure - the plugin is specific to an older repository format
<Noldorin> yes but. my point was that i was asking you what the new equivalent is.
<Noldorin> surely you have some knowledge about how it's changed over time?
<jelmer> Noldorin: .revisions, .texts and .inventories are roughly the equivalents
<Noldorin> why does VersionedFileStore exist then?
<jelmer> Noldorin: I'm not sure I follow
<Noldorin> VersionedFileStore has many of the old methods that existed on VersionedFiles
<Noldorin> but isn't really used anywhere, as far as i can see
<Noldorin> jelmer, replacing the copy/delete functionality for VersionedFiles isn't immediately apparent
<jelmer> Noldorin: sorry, it's been way too long since I've looked at this stuff
<Noldorin> heh okay
<Noldorin> jelmer, no anyone who could help me then maybe?
<jelmer> basically, you want to generate the record streams for texts/inventories/revisions and insert those into the new repository
<jelmer> Noldorin: I'd suggest asking on the mailing list
<Noldorin> ok
<Noldorin> i don\'t really have the time or patience to wait for mailing list replies, but maybe...
<jelmer> Noldorin: you can always dig further enough to find it yourself :-)
<Noldorin> the code is very convoluted though
<Noldorin> and not well commented
<Noldorin> so chances of that are virtually nil
<Noldorin> dynamic languages are a PITA to read as well
<jelmer> Noldorin: meh, it's all just what you're used to
<Noldorin> somewhat
<Noldorin> but not completely
<jelmer> I think the main thing lacking here is a doc that explains the overall architecture
<Noldorin> jelmer, i agree
<xnox> In ubuntu saucy, bzr hasn't been migrating to release pocket for a while now.
<xnox> trying: bzr
<xnox> skipped: bzr (32 <- 31)
<xnox>     got: 99+0: i-99
<xnox>     * i386: bzr-gtk, groundcontrol, nautilus-bzr
<xnox> those three packages need fixing =/
<xnox> or removal.
<jelmer> hi xnox
<jelmer> xnox: bzr-gtk is slated for removal from Debian, so I'll request its removal from Ubuntu too
<xnox> jelmer: hello. Ok. What about the other two? bump the dependencies & see what breaks (if anything) ?
<jelmer> xnox: nautilus-bzr comes from the bzr-gtk source package
<jelmer> I'm not sure about groundcontrol
<xnox> ok.
<jelmer> xnox: it looks like groundcontrol has a dependency on bzr-gtk, even in Debian (where it will probably break :-()
<xnox> ack.
#bzr 2014-09-02
<shadeslayer> hi, is there a way to figure out who touched a file last in bzr?
<LeoNerd> bzr log path/to/file   | head   ?
<LeoNerd> Perhaps with --one-line
<jelmer> also, --limit=1
<shadeslayer> jelmer: LeoNerd thx
<shadeslayer> that'll work
#bzr 2014-09-03
<thrustcore> I'm getting a tree transform that's malformed... can I somehow just reset everything and try and update again?
<thrustcore> somehow bzr revert && bzr update fixed it
<thrustcore> no idea how tho
<mark06> I have a plugin for pidgin/pidgin++ I want to include in the main distribution, what's the best way of handling this?
<mark06> both pidgin++ and the plugins live on separate branches
<mark06> I feel like just adding them to pidgin++'s source code but it's ugly.... it's a duplicated copy which needs to manually be updated whenever plugin's branch is updated
<mark06> it would be nice if there was some way to merge diverged branches... or maybe there's some better approach? thanks
<jelmer> mark06-away: you're talking about nested trees
<mark06> thanks for the feedback
 * mark06 decides to download the additional plugins during build and avoid complicating things 
<mark06> http://bazaar.launchpad.net/~renatosilva/pidgin++/trunk/revision/146
<mark06> any idea how to fix this? http://i.imgur.com/QUbHigl.png
<mark06> hmm, for rev too
#bzr 2014-09-05
<mark06> hi all, how can I fix this? http://i.imgur.com/PJqmetD.png
 * mark06 fixed the problem with qbzr by installing a newer version of it
<mark06> is this fair enough? http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/256
<mark06> hi all, is this correct? http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/256
<mark06> if there's no dead heads, then it's assumed that there's no uncommits to purge at all
#bzr 2014-09-07
<ciampix> hi all. Since I do not want to experiment with important repos...is there something like a bzr sandbox server? TIA
<mark06> so slow :( http://i.imgur.com/L4VyRT7.png
 * mark06 calculates one day or so
#bzr 2016-09-06
<rindolf> Hi all.  what is the equivalent of Â«git show [commit-id]Â» in bzr? I want the diff of an individual commit/revision.
 * rindolf found bzr diff -c
<LeoNerd> Yah; the -c is the "change" introduced at some number; i.e. the diff between that and its previous
<throstur> is it possible to mark a file as "revision-less" in bzr, (eg. for binary files) ?
#bzr 2016-09-08
<uelo> Hi, one of my .pack files is getting too big (+200 Mb). Is it possible to reduce the size or manually edit the pack file and remove specific commits?
<thebigj> Hello, Pycon India this time organizing 3 days devsprint.
<thebigj> (14:58) <   thebigj> We request Tryton community to submit entry. CFP is already started.
<thebigj> (14:59) <      cedk> thebigj: I think an email to tryton mailing list is better to reach more people
<thebigj> (15:00) <   thebigj> You can submit praposal here: https://in.pycon.org/cfp/dev-sprint-2016/proposals/
<thebigj> Sorry
<thebigj> Pycon India this time organizing 3 days devsprint.
<thebigj> We request this community to submit praposal here (https://in.pycon.org/cfp/dev-sprint-2016/proposals/) CFP is already started.
<thebigj> Please suggest if know better place than this to reach to the community. Thanks!
#bzr 2016-09-09
<thebigj> Hello, Members.
<thebigj> Pycon India(https://in.pycon.org) is happening on 23rd to 25 September, 2016.
<thebigj> https://in.pycon.org/cfp/dev-sprint-2016/proposals/
<thebigj> This time we have 3 days Dev sprint. The Call for praposal is already started. You can submit praposal on above link.
<thebigj> If you have any questions you can ask me here :)
