#bzr 2008-03-03
<jdong> LaserJock: is 0.4.8 released?
<LaserJock> I thought it was supposed to be
<LaserJock> and 0.4.7 would do fine as well
<LaserJock> I think ... not positive there
<jdong> LaserJock: yeah, it was supposed to be but I don't see it tagged in the branch yet
<xif> what's the status for bzr XML logs?
<ubotu> New bug: #197840 in bzr-svn (universe) "bzr-svn fails to install (Ubuntu Hardy, with ppa bzr)" [Undecided,New] https://launchpad.net/bugs/197840
<ubotu> New bug: #197841 in bzr "ppa bzr package 1.2~rc1-1build2 for Ubuntu Hardy fails to install" [Undecided,New] https://launchpad.net/bugs/197841
<tro> there seems to be a dependency problem with the 1.2 debs for feisty
<tro> bzr depends on bzrtools, but bzrtools 1.2 depend on bzr <1.2
<tro> so i have to use the old bzrtools (0.19 or something)
<vimes656> I just installed the bazaar Mac bundle for PPC but 'bzr' command is not in my path
<ubotu> New bug: #197897 in bzr "bzr export trips assertion if directory contains nested branches" [Undecided,New] https://launchpad.net/bugs/197897
<lifeless> moin
<ubotu> New bug: #197916 in bzr "bzr move in widows: directories are case sensitive" [Undecided,New] https://launchpad.net/bugs/197916
<james_w> morning lifeless
<lifeless> hi james_w
<AnMaster> hm it seems like the bzr website breaks in wide screen, a friend posted this http://forthelose.net/broked.png
<AnMaster> I don't have widescreen but the page does indeed fail if widescreen is used
<beuno> AnMaster, can you file a bug about it with the screen resolution?
<AnMaster> guess so
<beuno> AnMaster, thanks  :D
<AnMaster> https://bugs.launchpad.net/bazaar/ ?
<AnMaster> beuno, what project to select?
<AnMaster> there are so many, and not sorted
<beuno> AnMaster, just file it under https://bugs.launchpad.net/bzr/
<AnMaster> not bazaar???
<beuno> AnMaster, I thnk bzr will be fine, if not, it will be changed
<indraveni> i need help in setting up loggerhead through apache web server via proxy
<indraveni> could some one tell me how to do that
<ubotu> New bug: #197964 in bzr "http://bazaar-vcs.org/ website breaks at widescreen" [Undecided,New] https://launchpad.net/bugs/197964
<indraveni> none here to help me in loggerhead?
<indraveni> when would michael hudson be here probabaly
<awilkins> Verterok: You have an email address for bzr-eclipse patches?
<xif> what does it mean for the purposes of bzr when I have an "unknown" file in the commit message?
<nebuchadnezzar> hello,
<poolie> hello
<poolie> xif: it means it's neither added or ignorde
<poolie> it is harmless
<poolie> just a suggestion you might want to add or ignore it
<xif> poolie: yeah, thanks, but after I commit, it doesn't appear any more.
<poolie> hrm
<poolie> where is the message exactly?
<xif> poolie: when I do `bar ci`
<poolie> and the filename there, is that a file that you've previously added, or what is it?
<xif> poolie: it appears like this in the commit feedback:
<xif> modified:
<xif>   join_favs.py
<xif> unknown:
<xif>   error_log
<poolie> hm
<poolie> did you produce that file? or your build process?
<poolie> could it be it was deleted after you committed?
<poolie> sorry low battery
<poolie> send mail to bazaar@lists.ubuntu.com for more help
<xif> poolie: I produced it
<xif> poolie: thanks anyway
<xif> it seems to be indicated only if there are pre-added files (like join_favs.py in the example) that have local modifications
<nebuchadnezzar> I want to develop a hook and I wonder how I can get a string of the location of a BzrBranch object
<Verterok> awilkins: sorry for the delay, send it to my mail (I send it in a priv. msg)
<nebuchadnezzar> I find nothing in the api for this
<nebuchadnezzar> erf, this is .base, sorry for the noise
<LarstiQ> phanatic, jelmer: bzr viz is sooo much slower than gitk (--all), how come?
<phanatic> LarstiQ: it used to be even slower a few months ago :P
<nebuchadnezzar> hi again
<nebuchadnezzar> Is there a way to run hook only for specific branches ?
<ricardokirkner> hi. I am trying out the bzr server option. I am trying to branch from my machine to a central server (on which I have the bzr server running), but nothing is happening, and I dont know where to look for problems
<jakobb> nebuchadnezzar: if i remember correctly from a similar question some time ago the answer is: no
<ricardokirkner> I watched the .bzr.log file
<ricardokirkner> but there is nothing noteworthy there... any ideas?
<jakobb> nebuchadnezzar: but if you really want this, you could write in the hook something like: 'if branche_name == required_name' :P
<beuno> ricardokirkner, how are you branching?  bzr://?
<ricardokirkner> beuno: bzr+ssh://
<jakobb> very, very, very ugly though
<beuno> ricardokirkner, that sould fire off the bzr smart server if the server has it installed
<jakobb> branching To a remote server?? is that possible at all? shouldn't that be pushing or something along those lines?
<beuno> ricardokirkner, oh, branching _to_ a remote server
<beuno> not sure you can do that
<ricardokirkner> mhhh.. may be... the thing is like this. I created a project on my machine
<ricardokirkner> now I want to set up a central server with the project... I thought about creating a branch there, and then binding to that branch
<ricardokirkner> what is the correct way of doing this?
<beuno> ricardokirkner, than you want to oush instead of branch
<beuno> push
<beuno> bzr push bzr+ssh://url
<nebuchadnezzar> tahnks jakobb
<ricardokirkner> I get the same...
<ricardokirkner> the bzr client hangs on a "read(6, "
<ricardokirkner> so I guess it is waiting for the server to answer
<ricardokirkner> but I cannot see what the server is waiting for
<nebuchadnezzar> jakobb: do you think it's possible to add a variable in the configuration and test this variable in the hook ?
<nebuchadnezzar> can I add arbitrary variable in localtions.conf ?
<ricardokirkner> ok. I managed to get the push through, but I had to specify the full path on the server... (so the --directory argument was quite useless). what i did was bzr+ssh://user@server/full_path_to_repo/branch
<ricardokirkner> what I wanted to do is bzr+ssh://user@server/branch
<ricardokirkner> is that possible?
<jakobb> nebuchadvessar: pfff, i have no idea... i'm quite new with bzr; what i just told you is what i remembered from an earlier answer in this channel and some common sense
<beuno> ricardokirkner, only if your ssh hay jaillshell or something like that. Or, I *think( you can tell the smart server to use a directory as it's base dir
<beuno> there was a bug about that a while ago
<beuno> not sure if it's closed
<ricardokirkner> ok, I will search the bug database, thx
<nebuchadnezzar> jakobb: ok, thanks, I though you were a guru which remember old conversation ;-)
<jakobb> nope; conversation was like a week ago :P
<nebuchadnezzar> jakobb: ok, I can add whatever option I want in locations.conf and I can check it in my plugin with push_result.source_branch.get_config().get_user_option('myoption') :-)
<jakobb> cool!
<ubotu> New bug: #198016 in bzr "running bzr stat" [Undecided,New] https://launchpad.net/bugs/198016
<jelmer> abentley: ping
<jelmer> I just tried to get http://bundlebuggy.vernstok.nl/bzr-gtk/ up and running again, but there appears to be a function unimplemented now
<abentley> Paste?
<jelmer> http://bundlebuggy.vernstok.nl/bzr-gtk/
<jelmer> :-)
<jelmer> AttributeError: ("'function' object has no attribute 'filter_by'", <bound method Root.index of <bundlebuggy.controllers.Root object at 0x8b6ef0c>>)
<ubotu> New bug: #136530 in bzr-gtk "gstatus doesn't take -r" [Wishlist,Triaged] https://launchpad.net/bugs/136530
<mtaylor> http://bazaar.launchpad.net/~ndb-bindings/ndb-bindings/trunk/files/monty%40inaugust.com-20080220213951-rnva0vu08gvyz8cd
<mtaylor> nm
<beuno> abentley, does this look like something you where aiming out for XMLoutput documentation: http://bazaar-vcs.org/XMLOutput
<ubotu> New bug: #116651 in bzr-gtk "typos in bzr help commands output" [Undecided,Fix released] https://launchpad.net/bugs/116651
<ubotu> New bug: #124760 in bzr-gtk "missing gmerge command/class" [Wishlist,Triaged] https://launchpad.net/bugs/124760
<ubotu> New bug: #125932 in bzr-gtk "non valid sym link makes olive fail" [Low,Triaged] https://launchpad.net/bugs/125932
<ubotu> New bug: #136432 in bzr-gtk "olive installs to two locations" [Medium,Triaged] https://launchpad.net/bugs/136432
<ubotu> New bug: #137172 in bzr-gtk "Olive: Glade file cannot be found if installed in home" [Low,Triaged] https://launchpad.net/bugs/137172
<ubotu> New bug: #147022 in bzr-gtk "[viz] add a search box" [Wishlist,Triaged] https://launchpad.net/bugs/147022
<jelmer> LarstiQ: dude!
<LarstiQ> jelmer: So I'm currently trying to find out the 'why' behind conflicting changes, with gannotate as help
<jdong> aahhh all the bugs!
<jelmer> jdong: :-)
<LarstiQ> jelmer: find an interesting line, look at the diff, turns out to be big, would like to be able to search for a function in that diffwindow
<TFKyle> bugs, mm
<LarstiQ> jelmer: so I guess the featurerequest is navigation help in diffwindow
<jelmer> LarstiQ: that'd make sense
<jelmer> LarstiQ: it would actually be nice to be able to rely on something like meld for that in all cases
<jelmer> I would happily ditch what we have at the moment for meld integration
<ubotu> New bug: #135457 in bzr-gtk "bad version_info" [Undecided,Fix released] https://launchpad.net/bugs/135457
<ubotu> New bug: #136741 in bzr-gtk "tracebacks in bzr-gtk 0.90" [Undecided,Fix released] https://launchpad.net/bugs/136741
<ubotu> New bug: #183412 in bzr-gtk "bzr gannotate requires a filename" [Wishlist,Triaged] https://launchpad.net/bugs/183412
<ubotu> New bug: #183627 in bzr-gtk "viz crams revid onto your clipboard" [Undecided,New] https://launchpad.net/bugs/183627
<LarstiQ> jelmer: that would work I guess
<LarstiQ> jelmer: what needs to be done for that?
<jelmer> basically, meld needs to be fixed
<jelmer> I think that at the moment it only allows you to specify a file system trdee
<jelmer> whereas we would want to be able to specify a in-memory diff or perhaps functions that allow meld to inspect a in-memory tree
<Odd_Bloke> Turns out the SUPER-WIDE 'bzr viz' bug has been fixed in trunk by the addition of a scroll bar.
<ubotu> New bug: #173698 in bzr-gtk "the viz screws up when opening a branch with no revisions" [Low,Triaged] https://launchpad.net/bugs/173698
<Odd_Bloke> jelmer: Shelve/unshelve could do with being hooked into commit, to get the git-gui sort of experience.
<jelmer> Odd_Bloke: That was actually the bug report I was just triaging :-)
<jelmer> Odd_Bloke: The two could share most code, indeed.
<phanatic> jelmer: i'll have a look at the bugs you've tagged olive
<jelmer> phanatic: Cool, thanks
<ubotu> New bug: #177695 in bzr-gtk "Don't print traceback for NoSuchFile error" [Low,Triaged] https://launchpad.net/bugs/177695
<LarstiQ> jelmer: gannotate being really slow is a known problem? (overheard something about regressed annotate speed today)
<ubotu> New bug: #151824 in olive "use single click for bookmarks" [Undecided,New] https://launchpad.net/bugs/151824
<jelmer> LarstiQ: Even slow compared to "bzr annotate" ?
<ubotu> New bug: #121103 in bzr-gtk "bzr-gtk extensibility" [Wishlist,Triaged] https://launchpad.net/bugs/121103
<jelmer> LarstiQ: there was some talk today about annotate in general being slow
<ubotu> New bug: #144549 in bzr-gtk "[viz] branches should be collapsible" [Wishlist,Triaged] https://launchpad.net/bugs/144549
<ubotu> New bug: #144965 in bzr-gtk "Can't drag and drop files from olive" [Low,Triaged] https://launchpad.net/bugs/144965
<LarstiQ> jelmer: good point, no
<LarstiQ> jelmer: what is the eta of meld support? I could go on with usability requests for diffwindow
<ubotu> New bug: #151818 in olive "Don't ask about setting default push location" [Undecided,New] https://launchpad.net/bugs/151818
<ubotu> New bug: #130245 in bzr-gtk "feature request: bookmark behaviour" [Wishlist,Triaged] https://launchpad.net/bugs/130245
<ubotu> New bug: #144963 in bzr-gtk "Selecting a revision with the popup dialog for history mode does not start browsing at that revision" [Undecided,Incomplete] https://launchpad.net/bugs/144963
<ubotu> New bug: #144964 in bzr-gtk "Actions that are not applicable to the current selection should be greyed out." [Low,Triaged] https://launchpad.net/bugs/144964
<ubotu> New bug: #151819 in olive "create bookmarks by drag and drop" [Undecided,New] https://launchpad.net/bugs/151819
<ubotu> New bug: #144958 in bzr-gtk "cannot copy text in annotate window" [Wishlist,Triaged] https://launchpad.net/bugs/144958
<jelmer> LarstiQ: well, somebody has to do it :-)
<jelmer> LarstiQ: The main issue is that meld itself actually has to be modified
<ubotu> New bug: #130634 in bzr-gtk "Ability to revert from diff window" [Wishlist,Triaged] https://launchpad.net/bugs/130634
<ubotu> New bug: #133220 in bzr-gtk "ReadOnlyError when using tag for bzr viz" [Medium,Triaged] https://launchpad.net/bugs/133220
<ubotu> New bug: #144961 in bzr-gtk "Not possible to annotate a file while in history mode" [Undecided,Incomplete] https://launchpad.net/bugs/144961
<ubotu> New bug: #144962 in bzr-gtk "Not possible to exit history mode once in it" [Undecided,Incomplete] https://launchpad.net/bugs/144962
<ubotu> New bug: #131589 in bzr-gtk "graphical diff-tool not usable when launched through "bzr gstatus"" [Low,Triaged] https://launchpad.net/bugs/131589
<Odd_Bloke> What's being done to these bugs to make ubotu think they're new?
<beuno> Odd_Bloke, probably triaging them
<ubotu> New bug: #103198 in bzr-gtk "make it easier to see the diff from gcommit" [Wishlist,Fix released] https://launchpad.net/bugs/103198
<beuno> Odd_Bloke, just got a better explanation, seems they're new to ubotu
<Odd_Bloke> Ah, OK.
<LarstiQ> jelmer: and could gannotate possibly not keep the tree locked?
<jelmer> LarstiQ: patches welcome >-)
<LarstiQ> jelmer: :P
<Ng> is bzr merge --preview supposed to not work when stdout != terminal?
<LeoNerd> Define "not work"
<Ng> with either | less or >lala I get an AssertionError
<baco> hi, which is the best schema to make a server that allow commits from outside without using the systems accounts, but giving users accounts and passwords for bzr use only?
<jdong> baco: probably by using either SFTP or bzr+ssh, giving users in each case a restricted shell instead of a full-blown account
<jdong> baco: personally, I'd also supplement that with a second-lay MDAC system like Apparmor or SELinux but I'm known for being excessively paranoid :)
<jdong> baco: Either MDAC or the new OpenSSH chrooting system
<TFKyle> jdong: what do you suggest for restricted shells?
<johnny> rssh?
<baco> jdong: But then that requires again giving users an account in the system, although they have a restricted shell, I am trying to avoid that
<baco> jdong: I'd prefer something like webdav, where you can store users accounts and passwords in a file, but the webdav module is not yen in my distro
<TFKyle> baco: the smart server possibly? (not sure how that works with auth, I assume there's a way to specify users though)
<johnny> TFKyle, not that i've seen...
<baco> TFKyle: I thought the smart server did the commits using the user that calls the process, not other auth method
<johnny> yes
<johnny> that's how it seems
<johnny> i've got my two devel envs setup.. one for mtn , one for bzr
<johnny> my bzr one uses system accounts, and mtn doesn't
<jdong> baco: bzr currently can smart-serve on: Over stdin/stdout, executed over ssh and a pipe, or over a TCP port, where bzr serve is run inside some directory
<jdong> baco: IMO the ssh method is the best, but that makes it the sysadm's responsibility to enforce permissions
<TFKyle> baco: well, in a system that you don't create separate accounts for it makes sense that the commits won't be done by separate user accounts, though yeah it doesn't seem at first glance that bzr serve --allow-writes does any auth
<baco> TFKyle: What I want is a system not having all the users accounts for commiters I want them to commit, but being able to control which person do what by other means
<james_w> Ng: that's a bug I expect (merge --preview | less)
<Ng> james_w: indeed. I'm told it's fixed in bzr.dev :)
<james_w> Ng: even better
<Ng> OOI, could there also be a pull --preview?
<james_w> Isn't that diff?
<james_w> diff -r branch:wherever?
<james_w> It doesn't default to the pull location, and there is no revspec for that yet, but it should give you the same.
<james_w> Also it won't complain if you have diverged.
 * Ng shrugs, I'm no bzr expert, but if that is valid then pull --preview should be equivalent to it :)
<Ng> (and would save me remembering the default URL)
<james_w> Yeah, that seems sensible.
<james_w> I'll file a bug if you like.
<Ng> heh, sure :)
<Ng> I'll be happy to subscribe to it and monitor its progress ;)
<james_w> Ng: sure, one minute.
<Ng> james_w: ah, I recognise you from bug 195020. hi :)
<ubotu> Launchpad bug 195020 in ubuntu "Locale it_IT missing, but it's present (dup-of: 178402)" [Undecided,New] https://launchpad.net/bugs/195020
<ubotu> Launchpad bug 178402 in gdm "[hardy] missing language error" [High,Fix released] https://launchpad.net/bugs/178402
<james_w> Ng: https://bugs.launchpad.net/bzr/+bug/198084
<ubotu> Launchpad bug 198084 in bzr "Please add pull --preview" [Wishlist,New]
<Ng> james_w: nice, thanks :)
<james_w> no problem
<jdong> jelmer: is there an ETA on the new release of bzr-svn
<jelmer> jdong: This week somewhere probably
<jelmer> we're at a bzr sprint atm
<jdong> jelmer: right, mmmkay. I heard that there might be shallow branching on the horizon?
<jdong> err... no pun intended
<Odd_Bloke> Heh.
<jelmer> (-:
<jdong> but in all seriousness, is shallow branching a foreseeable result of the sprint?
<ubotu> New bug: #198084 in bzr "Please add pull --preview" [Wishlist,New] https://launchpad.net/bugs/198084
<jelmer> jdong: Not sure
<jelmer> jdong: it may well be, but there's other things I'd like to work on as well
<jdong> jelmer: cool. For me and bzr, limited history is probably the biggest thing I am missing
<ubotu> New bug: #198105 in bzr "Should create ~/.bazaar/plugins/ automatically" [Undecided,New] https://launchpad.net/bugs/198105
 * awilkins also votes for shallow history ; getting a full history is prohibitively expensive for old SVN repos
<beuno> jelmer, we have wireless
<beuno> I can tell you how if you pong me back  :p
<awilkins> jelmer: DO you know where the problem is for https://bugs.launchpad.net/bzr-svn/+bug/190832
<ubotu> Launchpad bug 190832 in bzr-svn "PROPFIND exception during check out of Subversion branch behind https" [Undecided,New]
<awilkins> Verterok: Did you get my small insignificant patch?
<Verterok> awilkins: hi
<Verterok> yes I'm just reading it :)
<Verterok> awilkins: I also see that you get the new code from trunk, great
<jelmer> beuno: Heya
<jelmer> beuno: We just got back, received phanatic's SMS about the wireless details
<jelmer> awilkins: Not really, but it's probably one of the commits since 0.4.7 that has made it regress
<beuno> jelmer, ah, higher-level technology  :p
<jelmer> beuno: how was your dinner?
<jelmer> awilkins: the http support is hard to test on a regular basis since it requires so much things to be set up
<beuno> jelmer, pretty good, although they where out of almost anything, so I ate what was my 5th choice  :p
<jelmer> heh, ok
<beuno> how about yours?
 * Odd_Bloke finally gets the wireless working.
<Odd_Bloke> *shakes fist*
<jelmer> Odd_Bloke \o/
<jelmer> beuno: Was pretty good too, we ate some simple dinner at a pub
<Odd_Bloke> Should we also have wired, or not?
<beuno> jelmer, we did exactly the same
<beuno> Odd_Bloke, not sure, jelmer does for some reason
<jelmer> Odd_Bloke: Yes, wired should be available
<jelmer> but you need to have the linux machine in your room booted up
<awilkins> Using wireless networking provides an incentive to make the network code faster.... bwwghagagagaga
 * awilkins watches tumbleweed roll past
<jelmer> well, we've got shallow branches now, no need for performance anymore :-P
<awilkins> They work?
<jelmer> awilkins: yes, but they haven't been merged yet
<jelmer> afaik they're being reviewed at the moment
<awilkins> jelmer: It's nice to hear that ; does bzr-svn work with shallow branching?
<jelmer> not yet, but with a bit of luck I'll fix that this week during the sprint
 * awilkins swears at the persnickity ways of Eclipse
<Odd_Bloke> jelmer: What are the steps to get the wired 'Net working?  The wireless is painfully slow.
<jelmer> Odd_Bloke: 1) Find a cable
<jelmer> 2) Plug one end in the wall socket
<beuno> Odd_Bloke, I suspect it's not the "wireless" the problem as much as the "sucky connection", which I believe will be that way no matter how you hook to it
<jelmer> 3) Plug one end (not the end you put into the wall) in your laptop
<jelmer> 4) profit \o/
<beuno> Odd_Bloke, there may be a 10 pund thing in between which jelmer seems to think they won't charge, but they _do_ have his credit card info, so....
<beuno> s/pund/pound
<Odd_Bloke> Ah, I was put off by the Â£10 thing.
<jelmer> Odd_Bloke: The reception told me that the broadband in our room had already been paid for so I just hit "OK"
<Odd_Bloke> beuno: It's about 10 times faster on the wired network.
 * Odd_Bloke may have to steal from jelmer if this doesn't work out. :p
 * beuno chooses not to risk it and deal with irssi lag
<jelmer> the wireless is pretty good here
<jelmer> 30ms to home
<Odd_Bloke> My eTV isn't displaying any charge.
<mwhudson> which hotel are you guys in?
<Odd_Bloke> mwhudson: Park Plaza R1verbank
<mwhudson> nicer than the rotchester? :)
<mwhudson> Odd_Bloke: looks like you need to set up some kind of zip-line affair from the hotel to and from the office :)
 * Odd_Bloke hasn't been in the Rochester, so couldn't say.
<Odd_Bloke> mwhudson: It's already been discussed. ^_^
<beuno> mwhudson, Rinchen seems to think so, yes
<jelmer> mwhudson: It's a little bit fancier I think, but not all that different
<jelmer> we got bathrobes and slippers and that sort of thing
<mwhudson> mind you, i'm not sure why people hated the rotchester so much
 * jelmer thought the rochester was ok
<jelmer> it's not like we spent all day inside of the hotel room or anything
<Odd_Bloke> Neither the slippers nor the bathrobe fit me. Â¬.Â¬
<beuno> abentley, what are the chances you feel like taking a look at the XML spec we drew up with Verterok?  just to see if "that's what you meant"  http://bazaar-vcs.org/XMLOutput
<abentley> Yes, that is the sort of information I want to know about the format.
<beuno> abentley, thanks :D   We'll keep on working on that so we have something mergeable by the end of the sprint
<abentley> The most obvious thing that bothers me about the revision format is that it only lists particular revision properties.
<abentley> I would want it to list all of the revision properties.
<Verterok> abentley: ok, It's easy to add :)
<Verterok> I made a patch for svn revisions some tiem ago, but never send it. :P
<awilkins> A schema would be good too.
<Verterok> awilkins: once we freeze the format a xsd and dtd are going to be available
<abentley> The status format doesn't seem to be able to describe symlinks.
<awilkins> awilkins: Just an idea ; when I do a tool that outputs XML I tend to put in an option switch to make it spit the schema to STDOUT
 * awilkins stops talking to himself and addresses Verterok instead ^^^
<Verterok> ups, it should, maybe we missed something :P (checking it now)
<beuno> awilkins, we can include it in the doc, don't think that should be outputed by bzr
 * Odd_Bloke sleeps.
<beuno> abentley, I'm suming up what was discussed in the sprint today, any chance you can fork the whiteboard pics my way?
<abentley> Lemme see.
<abentley> It'll be a couple.
<beuno> abentley, great, thanks. I'll blog it I guess, and maybe send to the list if it's useful
<abentley> You wanted all the whiteboards or just the xmloutput one?
<beuno> abentley, all of em if possible. I'd like to have a daily summary before we forget what we talked about on friday  :D
<abentley> I'm emailing them now.
<beuno> abentley, thanks!
<james_w> beuno: I think it might be quite cool for you to blog a couple of things about the sprint if you are happy to do so.
<beuno> james_w, yeap, I'm doing exactly that. I don't have any pictures (I'll make sure to take some tomorrow), but I'm writing general impressions and I wanted to add what topics where discussed, and maybe attempt to capture some conclusions, but that one is trickier
<james_w> beuno: that's great. I think just spreading the word a bit that there is a sprint on, and you are discussing loads of interesting stuff, and working in patches would be great.
<james_w> s/working in/working on/
<beuno> james_w, yeap, absolutely. My post should hit the planet in a while.  When are you coming, btw?
<james_w> thursday.
<james_w> well, Wednesday night, but I probably wont be eating with you guys as I have some friends to meet.
<beuno> james_w, great. I've been talking with lifeless about the whole "bazaar" <> "baz" migration, so I'll be waiting for you to look into it more detailed
<james_w> beuno: cool, I'll be glad to help.
<james_w> I don't think it will be too much work, as I think "bazaar" will end up installing "baz" for a long time no matter what we do, so that's not going to annoy anyone.
<beuno> james_w, yeap, should be straight forward, just want to get it right  :D
<james_w> of course :)
* bpeterson changed the topic of #bzr to: Bazaar discussion
* bpeterson changed the topic of #bzr to: Bazaar discussion | London Sprint May 14 - 18 https://launchpad.net/sprints/bzr-200705
<randomnewguy> is there a way to make bzr use version numbers < 1, i have noticed that projects are generally < 1 until they are release ready
<luks> bzr doesn't do version numbers, does it?
<beuno> randomnewguy, you mean have a revision 0?
<radix> randomnewguy: bzr puts no restrictions on the version number you give to releases of your projects...
<bpeterson> randomnewguy: you can tag anything you want
<randomnewguy> i assumed that the revision would correlate with the release number
<randomnewguy> guess ill just put a 0. infront :p
#bzr 2008-03-04
<bpeterson> randomnewguy: no, revisions just show the flow off changes in time, not the version
<bpeterson> randomnewguy: since versions are arbitrary, they are tags, a marked revision number which we assign a version number to
<randomnewguy> im only just starting with bzr, are tags a feature?
<Peng> Yes.
<randomnewguy> ok thanks
<fullermd> As opposed to a bug?   :]
<randomnewguy> i didn't know the option to tag a revision existed
<fullermd> bpeterson: Why are we referencing a spring from last May?
<bpeterson> randomnewh
<Peng> There are over 16,000 revisions in Bazaar's Bazaar branch. Usually a couple a day. A couple releases a day wouldn't be very nice...
<bpeterson> fullermd: opps
<bpeterson> fullermd: oops
* bpeterson changed the topic of #bzr to: "Bazaar version control system discussion (http://bazaar-vcs.org)"
<Peng> Isn't there a new sprint right now?
<Peng> s/new //
<beuno> Peng, yeap, at this exact moment
<bpeterson> Peng: do you know the url so I can get it right
<beuno> (well, we're suppose to be sleeping now, but bleh)
<Toksyuryel> The topic should make a note what the latest version is
<randomnewguy> Peng: i guess its a little more practical when you only have 6 like me
* bpeterson changed the topic of #bzr to: "Bazaar discussion | Latest release is 1.2"
<Peng> Yesterday, the topic was: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08"
* Peng changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08"
<bpeterson> Peng: that should do it... thanks
<Toksyuryel> that looks good :)
<Toksyuryel> should set +t and turn on topiclock, then only the correct people can set the topic instead of it being able to be screwed up by anyone
<beuno> Toksyuryel, it hasn't been a problem until now
<beuno> it's much less work to leave it open I think
<Toksyuryel> basically all you do is put a /msg chanserv in front of the topic command and it's otherwise the same
<Toksyuryel> and this is why I don't like the squeaky wheel mentality, it's always better to stop problems before they happen if you find yourself in a situation to be able to do so :)
<Toksyuryel> but it is of course your decision
 * Toksyuryel is just throwing it out there
<beuno> Toksyuryel, but then you have to give access to people
<beuno> and only those can change the topic
<beuno> and they would get bugged to do so by others
<hsuh> anyone knows why bzr somehow doesn't have problems with line endings when you work with unix <-> windows merges, but hg does?
<beuno> it's not so straight forward  ;)
<Toksyuryel> don't they already have access?
<Peng> Wait, what?
<Peng> Bzr doesn't handle line endings, but hg optionally can.
<Peng> I'd say you're just lucky that your text editors aren't screwing around with line endings.
 * Toksyuryel hates DOS line endings =/ what is wrong with those people
<hsuh> hm.. i'm using emacs here and there, the editors are the same, so maybe the problem was that i had some type of filter configured... happy now anyway :)
<Peng> HTTP uses DOS line endings. I wonder how much bandwidth that wastes?
<Toksyuryel> tons probably, people all over the world download millions of multi-kibibyte html documents every day
<Toksyuryel> the individual user may not notice anything but the ISPs have a lot of extra strain they don't need because of that
 * Verterok sleeps
<Toksyuryel> estimating extremely conservatively, let's suppose an ISP that serves five million customers that each download 1000 HTML documents every day averaging 100 lines per file. Calculated out that ends up costing the ISP 4tbits per day.
<Toksyuryel> the actual amount wasted in reality is probably a lot higher
<LeoNerd> For that matter, anyone who properly indents their HTML would waste loads more in leading spaces
<LeoNerd> gzip FTW :)
<Toksyuryel> indeed ^_^
<johnny> yes.. gzip..
<Toksyuryel> gzip is a great solution and I know at least firefox supports that
<Toksyuryel> there would still be some waste in the HTTP headers but that would be minimal compared to what it would have been otherwise
<Toksyuryel> unfortunately we probably can't force everyone to gzip their pages any more than we can force them to use UNIX line-endings =/ it's too bad
<johnny> hmm.. we force unix line endings in your pre commit hooks :)
<johnny> our*
<Toksyuryel> but anyway, getting back on topic, bzr rocks <3
<johnny> now if only we could make sure they are using the pre commit hooks :)
<johnny> that is on topic tho..
<johnny> sorta
 * beuno is off to bed
* bpeterson changed the topic of #bzr to: âhttp://bazaar-vcs.org/ | | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08"â
<Toksyuryel> why...?
* bob2 changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08
<tro> retupmoca: line endings. can bzr handle them or would i have to write a pre-commit hook?
<fullermd> I think "neither" is the current answer...
<fullermd> I believe line ending stuff (and I/O filters in general) is on the topic list for the current sprint, but I'm not sure.  And of course that doesn't help anything at the moment.
<retupmoca> um....what?
<retupmoca> someone set off my highlight
 * retupmoca fades back into the darkness
<indraveni> hi all
<indraveni> when I am trying to run loggerhead, I am seeing an error message
<indraveni> http://pastebin.ca/927304
<indraveni> what does error message mean?
<indraveni> thus i am not able to start loggerhead
<Peng> It means UART gettin' online!
<Peng> I don't know, Google it.
<Peng> You need to set autoreload.package, even if to an empty value.
<indraveni> but, yesterday it was working without any problem Peng
<indraveni> after some time, only it started showing this problem
<Peng> Well, I have no idea.
<Peng> I've never used TurboGears.
<indraveni> Peng, have u used loggerhead ?
<Peng> Nope.
<Peng> I'm on shared hosting so I've been afraid to try it.
<Odd_Bloke> Morning.
<DataShaman> hi there
<DataShaman> anyone give a hint what i'm doing wrong?
<DataShaman> I've setup a central branch as per Team collaboration, distributed style
<DataShaman> where you can have local bugfix branches
<DataShaman> when I create a pristine branch of the central trunk, it has no files in it, even though the repo has files in it
<jakobb> DataShaman: what is the command you use to create the branch?
<DataShaman> anyone?
<DataShaman> anyone here want to help me with a problem using bzr?
<DataShaman> please
<fullermd> 02:03 <jakobb> DataShaman: what is the command you use to create the branch?
<DataShaman> the local branch?
<fullermd> Whichever one has no files in it.
<DataShaman> std bar branch bzr+ssh:....
<DataShaman> bzr branch bzr+ssh://blah...
<DataShaman> the central repo has files in it
<DataShaman> when i pull in the branch, it says 35 revisions are branched
<DataShaman> but no files are created in the pristine copy
<fullermd> Try info.
<DataShaman> shared repo is the parent folder, which makes sense
<DataShaman> repository branch is .
<DataShaman> parent branch is the remote repo
<fullermd> Pastebin the whole output.
<DataShaman> k
<DataShaman> http://pastebin.com/d28708aa5
<DataShaman> with -v
<DataShaman> do a info on the central repo as well?
<DataShaman> central repo: http://pastebin.com/d776df7b5
<fullermd> No, that's enough.  Shows the expected.
<fullermd> You don't have a WT, which means you created the repository with --no-trees.  So, nothing's "broken"; it's doing just what you asked.
<fullermd> Run a "bzr co" in the branch to instantite a WT for it.
<Peng> Any good way to turn --no-trees off? You can rm .bzr/repository/no-working-trees.
<fullermd> I think it's one of those things to slot into reconfigure.
<DataShaman> ok
<DataShaman> i get it
<DataShaman> my pristine copy of the central repo shouldn't have a working tree, ideally correct?
<DataShaman> when I create a feature branch off the pristine copy, how do i get it to create a working tree with the branch command?
<Peng> DataShaman: <Peng> ... rm .bzr/repository/no-working-trees.
<Peng> Odd_Block? :)
<fullermd> Well, it shouldn't if you don't want it to   :)
<DataShaman> :)
<Odd_Bloke> Peng: Ping? ;)
<fullermd> It depends on the details of how you want to work.
<DataShaman> let me give you a brief rundown
<DataShaman> central repo, with trunk
<DataShaman> me at remote site, with pristine branch copy, and local branches for bugfixes, features, etc
<Odd_Bloke> Sprint People: I was denied access to the Executive Lounge (No Executive Lounge?! DENIED!) so will hang around in the lobby until ~quarter to.
<DataShaman> the pristine branch copy with no WT, since it seems wasteful to have one there
<DataShaman> but local bugfix branches obv must have WTs :)
<fullermd> How do you intend to land the bugfix branches when they're completed?
<DataShaman> i assume that in my case, the pristine copy MUST have a WT?
<DataShaman> hmm, point
<DataShaman> it has to merge into the local i suppose
<fullermd> The way I do such things is to use a checkout of the trunk for my "local pristine" copy.
<Peng> DataShaman: You can use "bzr remove-tree" and "bzr checkout" ("bzr co") to switch a branch between having a WT and not.
<DataShaman> ok
<fullermd> Then when I need to land a bugfix branch, I can go into it and "bzr up ; bzr merge ../bugfix ; bzr ci" to land it into trunk.
<lifeless> moin
<fullermd> (actually, I also often do trivial stuff straight on trunk too, but that's all up to your workflow choices)
<DataShaman> fullermd: ok, thanks for your help, it makes sense now
<DataShaman> viola, all there now :)
<Peng> Lazyweb: Can "bzr up" show a log of the revisions it's pulling, like "bzr pull -v"?
<james_w> bzr up -v perhaps?
<james_w> ah, no, sorry, you want log, rather than file changes, I don't think that's possible.
<Peng> I'll stick with avoiding checkouts then.
<Peng> (Except for the occasional lightweight checkout.)
<fullermd> I've never found pull -v useful myself...
<AfC> This is a few days old, but an interesting post from elijah: http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/
<poolie> hi afc
<poolie> you've landed in london?
<poolie> that is interesting
<AfC> poolie: yeah. His section on Bazaar was a bit of a ramble (perhaps that's a bad sign) but his comments on Subversion, Mecurial, and Git seemed insightful.
<jamesh> AfC: it'd be interesting to know what the "several features of git not present in other systems that [he is] absolutely addicted to" are
<jamesh> ah.  he's elaborated in a comment
<luks> the various ways of destrying your history with rebasing/filtering/etc.? :)
<jamesh> "speed[1], repository container[2], the index[3]"
<jamesh> "and history rewriting[4]"
<bialix> abentley: BB is down.
<Odd_Bloke> lifeless: I've written up the network performance stuff at http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms
<Odd_Bloke> poolie: At the bottom of http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms
<lifeless> Odd_Bloke: thanks
<Odd_Bloke> jelmer: I've added the stuff on the board re: bzr-gtk to http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms
<jelmer> Odd_Bloke, w00t, thanks!
<beuno> poolie, at some point in the sprint, I'd like to chat with you about the "command not found" spec if you can
<poolie> yes, we should
<Verterok> vila: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/37768
<Zindar> hi guys.. are you in london now?
<beuno> Zindar, yeap, we're all in London
<Zindar> so am I today/tonight
<Zindar> just wanted to see if anyone feels like meeting up, drinking bear, etc tonight... if there is time
<Zindar> bear = beer....
<Zindar> strange if not :)
<beuno> Zindar, not sure what happens after we finish, but you can re-check at ~6pm and see
<Zindar> I might not have internet this afternoon though....
<Zindar> sms possibilities to someone? :)
<jelmer> Zindar: hi
<jelmer> +31645516686
<Zindar> thank you :)
<Zindar> +46730808013 if you need me
<jelmer> thanks
<Zindar> or somehting
 * awilkins fancies a nice drop of bear
<Odd_Bloke> awilkins: TMI. ;)
<Peng> You can get bear online.
 * Peng wanders off.
<TFKyle> mm, bear
<TFKyle> though I think I'd prefer some venison
<luris> what do I do if I accitently added a symlink to my repo?
<luris> bzr remove <linkname> doesn't seem to work
<AfC> luris: it ought to.
<AfC> luris: you could always just
<AfC> $ rm linkname
<AfC> and see what `bzr status`
<AfC> reports
<luris> AfC: I ended up running bzr rm --new && bzr add
<dato> is igc in London?
<lifeless> yes
<Odd_Bloke> He's over there -->
<lifeless> indeed, -->
<lifeless> dato: ping
<dato> lifeless: pong
<lifeless> did you write something to watch a branch and email out changes observed on it?
<dato> could somebody ask him if by Â«your thoughts will give us things to keep in mind when developing bzr-fastexport soonÂ» he meant that he's going to write it?
<jdong> while true; do bzr log | mail ..... LOL
<dato> lifeless: yes, though it's a bit rough.
<lifeless> dato: url ? squid3 is mocving to bzr :)
<lifeless> dato: he says 'yes ian will write it if noone else does'
<dato> lifeless: ok
<dato> lifeless: https://launchpad.net/bzr-hookless-email
<igc> hi dato
<dato> hi igc
<lifeless> dato: syou should put that on the plugins page or osomething
<dato> lifeless: ah yes, I forgot to do that.
<lifeless> perhaps we should have a 'extensions' page or something that lists all the not-a-plugin ut works-with-bzr stuff
<lifeless> dato: can local_bzrlib be deleted now ? :)
<dato> lifeless: actually no. it has a patch that I didn't manage to submit yet. (also because I wasn't very sure it would be ok)
<dato> (code for setting the envelope-sender and smtp recipients)
<dato> lifeless: anyway this program could be rewritten as something that just calls the configured plugins as if they were being called by the committer. so that it'd be also able to send stuff to CIA and else.
<lifeless> dato: right, but I needed something now :>
<dato> right. it'll do the job.
<dato> igc: so, ooi, do you have an estimate of how much code bzr-fast-export.py would be?
<LarstiQ> wasn't there a revspec or so to get the working tree state?
 * LarstiQ wants to diff his workingtree state against the top pending merge
<LarstiQ> or perhaps I mean just diff against a pending merge
<igc> dato: I think a simple implementation of bzr-fast-export could take as little as an hour or so
<igc> dato: I would like to include one in bzr-fastimport
<dato> I'll read that as "igc time" ;)
<igc> dato: the key word is "simple"
<igc> it's one thing to dump stuff out
<igc> it's another to think through all the issues needed to make bzr-fast-export and bzr-fast-import "round-trip"
<igc> in other words, I want to get a fast-export that is useful to our community, not just other communities :-)
<dato> yah :)
<igc> my first driver for fast-export though is as a QA tool to show that fast-import works
<igc> my second driver is making some funky 'filter' branch' style functionality possible
<igc> dato: there are also some implementation options to consider ...
<igc> the easiest fast-export is to walk the repo and print stuff as you go
<igc> a slower, but maybe more useful way?, is to generate Command objects and add __str__ to each
<LarstiQ> what is fast-export?
<igc> the latter is more object-oriented, but might suck performance wise
<igc> LarstiQ: git implemented a tool called git-fast-import that accepts a stream of comands/data
<igc> tools that generate that stream are called *-fast-export
<igc> I've written a plugin that takes the same import stream as git handles
<igc> so we can reuse all the existing exporters
<LarstiQ> ookay
<igc> but we're yet to have an exporter that dumps that format
<igc> after all, no-one ever wants to use another VCS having used bzr :-)
 * LarstiQ swallows the switching to git stories
 * dato confesses he has temptations at times.
<dato> not because I'm unhappy, which I'm not
<igc> seriously though, it's actually a feature being able to get from bzr to other tools in that ...
<igc> some teams want to be confident that picking bzr wouldn't lock them in
<ubotu> New bug: #198417 in bzr "bzr diff -r ancestor: should use parent branch if not specified" [Undecided,New] https://launchpad.net/bugs/198417
<ubotu> New bug: #198418 in bzr "bzr send gives incomplete help on error" [Undecided,New] https://launchpad.net/bugs/198418
<LarstiQ> igc: which entirely makes sense
<igc> LarstiQ: for more info, see http://bazaar-vcs.org/BzrFastImport
<LarstiQ> igc: thanks
<tbnorth> hi all - how can I tell if bzr thinks a file's binary?
<ubotu> New bug: #198422 in bzr-gtk "Annotate doesn't show active revision" [Low,Triaged] https://launchpad.net/bugs/198422
<james_w> tbnorth: the only way I know is to edit the file and run bzr diff. binary/not binary isn't much of distinction in bzr currently though, why would you like to know?
<tbnorth> I use an IDE that changes the EOLs, I have a script that changes them back (i.e. makes working copy EOLs match last revision)  I don't want the script tripping over binary files
<ubotu> New bug: #198425 in bzr "bzr info should not say "shared repository" unless it is actually a shared rather than colocated repository" [Low,Confirmed] https://launchpad.net/bugs/198425
<tbnorth> james_w: so perhaps I should do my own test for binariness
<ubotu> New bug: #198441 in bzr "Windows XP install nit: missing new program highlight on start menu" [Undecided,New] https://launchpad.net/bugs/198441
<spiv> jelmer: fwiw, there's no python-subversion update in gutsy-backports, but the dependencies to take it directly from hardy aren't too bacd.
<spiv> s/bacd/bad/
<jelmer> spiv, ah, ok
<spiv> jelmer: svn-import of Twisted seems to be stable at ~79MB, which is a dramatic improvement :)
<spiv> Hmm, spoke too soon.  It just jumped to 145MB... still doing much better than before though.
<cr3> is there a way to grab source from a repository but not the .bzr directory?
<cr3> I'm grabbing a project now and the .bzr directory itself is over 300MB, that's overkill considering I just want to build the project
<TFKyle> cr3: I believe you could do a lightweight checkout (bzr branch --lightweight)
<TFKyle> er, bzr co --lightweight rather :)
<jdong> TFKyle: I'm not convinced that it's really much faster.
<cr3> TFKyle: thanks, I'll try that
<jdong> it might involve downloading fewer bytes but I don't think it'll actually be "faster" per se
<jdong> cr3: the real feature you want is shallow branching *cough* *cough* (looks at jelmer, lifeless , and those at the bzr sprint)
<TFKyle> possibly, not sure exactly how it works
<cr3> jdong: branch compared to co --lightweight was 5 times bigger, significant difference. thanks!
<jdong> cr3: I know it's gonna be bigger, but I didn't know whether or not it's gonna be faster
<jdong> cr3: slight disclaimer, I've got a gigabit internet pipeline so YMMV :D
<jdong> cr3: and I'm not sure if it works, but bzr export might be able to operate on a branch URL and be even faster?
<james_w> bzr export DEST [BRANCH]
<_flx> hi
<_flx> what is the migration procedure for a bzr server 1.1 to 1.2 ?
<jdong> I believe just do the upgrade? Nothing broke backwards-compatibly
<jdong> (I think)
<_flx> jdong: Thx it worked
<jdong> great to hear
<ubotu> New bug: #198479 in bzr "crash: "bzr branch https://code.launchpad.net/~bzr/bzr/trunk"" [Undecided,New] https://launchpad.net/bugs/198479
<james_w> hi mwhudson_. It's good to see loggerhead still getting standalone releases. Thanks.
<mwhudson> james_w: news travels fast :)
<mwhudson> james_w: are you at the bzr sprint?
<james_w> mwhudson: I arrive on Thursday. Are you there>
<mwhudson> james_w: sadly, no
<mwhudson> having flown half way around the world moving from the uk to new zealand, my response to "hey!  do you want to fly back to the uk again in a few weeks?" was, perhaps, predictable
<james_w> :-)
<james_w> I think you got the better end of the deal though.
<ubotu> New bug: #198519 in bzr "'Connection timed out' on lp branch attempt shouldn't result in a crash" [Undecided,New] https://launchpad.net/bugs/198519
<philn__> hi
<ubotu> New bug: #198552 in bzr-gtk "Doesn't apply bzr metadata-only changes to files" [Medium,Triaged] https://launchpad.net/bugs/198552
<philn__> i'm trying to branch a https:// repo but get a curl error:
<philn__>     curl.perform()
<philn__> error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
<radix> philn__: If you're on Ubuntu or Debian, make sure your ca-certificates package is up-to-date.
<philn__> hi radix ;)
<radix> yo :)
<philn__> using gutsy here plus pinned hardy .. ca-certificates is up-to-date
<radix> philn__: And you have the -updates repositories enabled?
<philn__> 20070303
<philn__> hmm lemme check
<radix> hmm, yeah, that's what I have on Hardy.
<philn__> i have gutsy-updates yes
<philn__> should i try some bleeding bzr edge?
<radix> I dunno, I'm not sure what the problem is. It doesn't sound like updating bzr would make a difference.
<radix> philn__: oh, wait, what's the https:// server you're trying to branch from?
<philn__> it didn't, had exact same error with gutsy version
<radix> philn__: maybe it really doesn't have a certificate that is registered with your system
<philn__> it's a seecreet server ;)
<radix> philn__: and is it signed by a "normally trusted" CA?
<radix> or is it some self-signed cert?
<philn__> how can i know that?
<radix> philn__: Well, does your browser complain when you visit the site with it?
<radix> (or did it complain and did you permantly accept the certificate anyway, some long time ago? ;)
<mwhudson> you can also try using bzr branch https+urllib://whatever/...
<radix> ah. is that the way you get around verification :)
<philn__> i get a warning in my browser yes
<philn__> mwhudson: tries that; didn't work
<radix> what happened ?
<philn__> SubversionException: ("PROPFIND request failed on '/blahblah')
<philn__> wtf, it's not a svn repo ;)
<radix> oh dear, so you're also trying to branch an svn branch?
<radix> oh.
 * radix looks at mwhudson 
<philn__> looks like that /svn_path comes from my ~/.subversion directory btw
<mwhudson> oh er what?
<radix> I got no idea.
<mwhudson> philn__: i guess you could try --no-plugins too
<philn__> mwhudson: dude, it works :)
<mwhudson> cool
<philn__> thx mwhudson and radix
<mwhudson> the subversion exception is some kind of bug, clearly
<mwhudson> don't know if it's reported yet...
<philn__> i can report it if needed
<abentley> Would that be #192743?
<philn__> i have a $HOME/.svn .. so could be yes
<Odd_Bloke> Bug #192743
<ubotu> Launchpad bug 192743 in bzr-svn "bzr-svn is irritating when in a (non-svn) subdirectory of an svn working tree" [Wishlist,Invalid] https://launchpad.net/bugs/192743
<nslater> how do i do a get without having any of the .bzr directories?
<philn__> heading bed, gn8
<Odd_Bloke> nslater: Could you expand on your problem a little?
<nslater> i would like to do "bzr get -r 666 http://example example" but not have the .bzr dirs
<nslater> i thought export would do it, but alas no
<Odd_Bloke> nslater: Where do you not have the .bzr dirs?
<nslater> can you rephrase please?
<nslater> Odd_Bloke: ?
<Odd_Bloke> nslater: Which location does not have the .bzr dirs?
<nslater> im not sure what that means, i want to create a local directory of the repository with no .bzr directories
<bob2> nslater: in what way does 'bzr export' not do what you want?
<Odd_Bloke> nslater: Do the bzr get and then bzr export locally.
<nslater> bzr export -r 86 http://intertwingly.net/code/venus/ planet-venus-0~bzr86.orig
<nslater> bzr: ERROR: Not a branch: "/home/nslater/svn/python-apps/packages/planet-venus/trunk/planet-venus-0~bzr86.orig/".
<nslater> do i really have to do two operations to get a "clean" version of the repository?
<bob2> nslater: arguments go the other way round
<beuno> Odd_Bloke, is there coffe up there?  my gf keeps kicking her adsl modem, so the conversation is taking a bit longer than expected
<beuno> s/coffe/coffee
<Odd_Bloke> beuno: Yeah, there is.
<Odd_Bloke> Nice hot choocolate too.
<bob2> nslater: bzr export -r 86 planetblah http://...
<beuno> Verterok, mate?
<nslater> trying with reversed arguments
<Verterok> beuno: yeap
<beuno> Verterok, be up in ~15 then
<nslater> bzr export -r 86 planet-venus-0~bzr86.orig http://intertwingly.net/code/venus/
<nslater> bzr: ERROR: Connection error: while sending GET /code/venus/.bzr/branch-format: (111, 'Connection refused')
 * Verterok 'll be waiting
<nslater> it works fine for a "get"
<nslater> it's really slow, is that normal?
<nslater> another error:
<nslater> bzr export -r 86 planet-venus-0~bzr86.orig http://intertwingly.net/code/venus
<nslater> bzr: ERROR: Connection error: while sending GET /code/venus/.bzr/repository/knits/eb/%254c%2549%2543%2545%254e%2543%2545-20060830201635-546cbbdb8a049f22.kndx: (111, 'Connection refused')
<bob2> I''m having intermittent trouble reaching that website in my browser
<beuno> nslater, the first thing to do would be to upgrade your storage format (although it's unrelated)
<bob2> as well as with bzr
<nslater> beuno: what do you mean storage format?
<bob2> beuno: nslater is branching someone else's branch
<beuno> bob2, aaah, right. nslater nevermind than, carry on
<nslater> :)
<nslater> hmm, i am also getting general errors from that site
<nslater> weird, it was working before
<Odd_Bloke> nslater: Try pulling into a shared-repo, you'll be able to do it in segments (i.e. resume when the connection fails).
<nslater> sorry, i dont know what that means
<nslater> also, this needs to work reliably with no assistance
<bob2> bzr init-repo blah ; bzr branch htp://... blah/blah ; bzr export foo.tar.gz blah/blah
<bob2> bzr export should do what you want, it just seems that intertwingly is having network issues
<nslater> okay, thanks
<bob2> the init-repo thing is what Odd_Bloke was sugesting, since the "branch" command will resume if rerun
<nslater> okay, thanks for all the help guys!
<mwhudson> so hm
<beuno> Verterok, on my way up
<mwhudson> i want to know the set of revisions that are introduced by the revision
 * Verterok hopes so :P
<mwhudson> i.e. those revisions which are ancestors of revision X but not of X's left-hand parent
<mwhudson> oh er
<mwhudson> find_difference!
<abentley> mwhudson: Unfortunately, that method's not completely accurate.
<mwhudson> abentley: ah
<abentley> The accurate way is to use get_ancestry on both revisions and then do set operations.
<abentley> We are strongly interested in making find_difference accurate, since it scales much better.
<abentley> Good night.
<mwhudson> seems pretty slow
<mwhudson> good night
#bzr 2008-03-05
 * awilkins cackles evilly because he has just written some thoroughly evil yet powerful Java generics code
 * jdong thinks awilkins could've sliced out "yet powerful" and "generics"
 * awilkins doesn't care, it nearly worked first time around :-)
 * awilkins is going to bed
<lamby> jelmer: dbus-fu now works? :)
<jelmer> lamby: yep, just packaged it
<jelmer> with a bit of luck I can get lifeless to upload it tomorrow
<lamby> jelmer: I must admit, that was one of the main things that lured me into packaging bzr-gtk.
<lamby> (Maybe bzr-gtk could be uploaded too, ooi?)
<jelmer> we're also working on a new bzr-gtk
<lamby> Oh neat. What's the motivation behind that?
<beuno> lamby, among other things, fixing nautilus integration  (jelmer is discussing as he falls asleep)
<Odd_Bloke> So I was anticipating finding an AfC in my room...
<beuno> Odd_Bloke, and you found what?
<Odd_Bloke> No AfC.
<beuno> is that a metaphore?
<Odd_Bloke> No, AfC is Andrew Cowie. :)
<beuno> right, was just trying to block the continued gpg discussion out of my head
<beuno> but that joke got cut off too
<beuno> must be time for bed
 * beuno is off
<lamby> 'sup Odd_Bloke
<lamby> jelmer: nn ;)
<jelmer> lamby: g'night
<Odd_Bloke> lamby: o/
<indraveni> hi all
<indraveni> i want to use trac as front end for my bzr site
<indraveni> I need some help on this
<indraveni> i installed trac and trac-bzr
<indraveni> and when I am accessing the trac, browse code, page
<indraveni> the following is the error i am seeing
<indraveni> http://pastebin.ca/928643
<indraveni> could some one please help me in resolving this issue
<bob2> are you using the recommended trac, trac-bzr and bzr versions?
<ubotu> New bug: #193253 in launchpad-bazaar "sockets being leaked in branch puller tests" [High,Confirmed] https://launchpad.net/bugs/193253
<indraveni> bob2, recommended ? I am using debian os. thus done installation through aptitude
<indraveni> I now downloaded trac-bzr frm launchpad from the traunk
<indraveni> but I am not knowing how to install it or use it
<indraveni> could some one here , help me out
<ubotu> New bug: #198645 in bzr-dbus ""bzr commit" does not trigger DBus signal" [Undecided,New] https://launchpad.net/bugs/198645
<tbnorth> hi all - how can I change the path to the parent branch?  It should be using /home/user/... but instead it's using /mnt/250GB/home/... which is only valid on one machine.
<fullermd> Does it matter?  It wouldn't have any meaning except on one machine anyway.
<bob2> ('bzr pull --remember /home/...' or edit .bzr/branch/branch.conf)
<james_w> indraveni: there is a a README in the source that should help.
<indraveni> its only saying about after installation
<indraveni> james_w, nothing about how  to install or ue
<indraveni> use
<tbnorth> thanks bob2
<tbnorth> fullermd: I clone my whole file system between machines, but sometimes I forget to check if I'm on the common symbolic path of the machine specific mount path
<huslu> someone here knowledgeable about debian's bzr package?
<ubotu> New bug: #198646 in bzr "Invalid http response ... Expected a boundary" [Undecided,New] https://launchpad.net/bugs/198646
<james_w> huslu: what about it?
<huslu> james_w: in lenny i have to install a lot of extra packages to be able to use recent bzr, (x11-common, etc)
<james_w> huslu: that sounds a little odd. I don't know the reason though.
<james_w> I don't have time to investigate now, sorry.
<james_w> There will be other knowledgeable people on in the next couple of hours I think.
<huslu> ok, np. etch-backports has it ok, just lenny.
<james_w> Has it started recommending bzr-gtk?
<huslu> 'suggesting', yes
<huslu> but that's not forced to install with it
<bob2> are you using aptitude?  there's a recommends chain bzr -> bzrtools -> graphviz -> libxt6 -> x11-common.
<huslu> no, just most up to date apt
<huslu> apt 0.7.11
<huslu> buy yes, with apt-get it forces to install graphviz, libxt6, and so on.
<bob2> maybe APT::Install-Recommends is on by default these days
<huslu> that may be very likely
<huslu> i have to see where's the settings for Install-Recommends
<corevette> my bzr says: Unable to obtain lock file:///home/corevette/www/.bzr/repository/lock held by corevette@gmail.com on host corevette-desktop [process #12320]
<Peng> The repo is locked.
<Peng> Do you have another bzr process running (presumably with the PID 12320)?
<corevette> my PID's only go up to around 8000 peng
<Peng> Wait, are you working on that machine or pushing to it from another?
<Peng> Anyway, if you're 100% sure nothing else is going on (do a ps on both machines), use "bzr break-lock $location".
<corevette> peng, nevermind, i just pulled in a different location...and if it fixed it
<mrevell> phanatic: Could we talk about Olive today?
<jml> Odd_Bloke: did you take notes on the Admin breakout?
<Odd_Bloke> jml: http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms
<phanatic> mrevell: sure, it'd be great
<mrevell> phanatic: Lovely. I'm busy from around 11.00 until 13.00.
<mrevell> phanatic: Sorry dude.
<phanatic> mrevell: may i join you? :)
<mrevell> phanatic: sure, please :)
<Lllama> Morning all. I've just done a merge and got some conflicts. I'm editing the BASE, THIS and OTHER files and can fix the changes, but I'm not sure what I need to be doing to resolve the conflict. I.e. which file will be the master version and whether I need to delete the others. A bit of a newbie question but any pointers will be gratefully received.
<beuno> Lllama, just rename your file once you've solved them
<beuno> to it's original name
<beuno> (I suppose that should be in the docs...)
<spiv> mwhudson_: well done on the release
<Lllama> beuno: Ah, so I take the THIS, BASE and OTHER, create a resolved version and then save that as the original file. (the original file is still in the directory, so I'll be overwriting it.)
<beuno> Lllama, right
<beuno> you just edit the original one to what you want
<beuno> or overwrite it
<Lllama> beuno: Excellent. Thank you.
<beuno> Lllama, welcome
<Zindar_> Lllama: or you can just ignore THIS, BASE, OTHER... edit the original.. it contains markers on conflicts, solve them...  then run bzr resolve on the file...
<Zindar_> I never open THIS, BASE, OTHER... I do use them for auto resolve tools thoguh, like bzr extmerge
<Lllama> Zindar: cool.
<bob2> where can I set bzr_Remote_path?  the [DEFAULT] block in ~/.bazaar/locations.conf seems to be the wrong one.
<snod> Ã¶s
<lifeless> bob2: not sure you can in a config yet; seems to be an open bug
<LarstiQ> Zindar: are you still in London today?
<Zindar> yes.. but leaving at 1600
<Zindar> so.. just in a few hours
<LarstiQ> ah.
<Zindar_> crap network
<soren> If someone e-mails me a patch and I'd like to import that into bzr somehow (e.g. using the text of his e-mail as the body, and his sender address as the committer info), how to do?
<soren> It's fine if I need to copy/paste the body of his e-mail into the commit message, but isn't there a command line option to use another committer identity or something?
<fullermd> You probably want --author
<fullermd> The best solution would be for the submitter to use bzr and send you a bundle instead of course   :)
<soren> Sure.
<soren> Er.. Yeah, --author is totally what I want.
<soren> How could I have missed that? *shrug*
<fullermd> It's relatively new I think; 2 or 3 versions, maybe.
<soren> fullermd: Yeah, well, I looked at "bzr help commit" just before I asked my question :)
<fullermd> Oh.  Well, in that case, it's REALLY new, and was pushed to all installations via a secret backdoor bzr installs right after you asked.
<soren> I suspected that :)
<muszek> hi
<asabil> hmm, seems like launchpad is getting crazy again :/
<asabil> locks are being held
<muszek> I have a problem... suddenly two files "stopped being added" (are not versioned anymore)... I try to add them again - I don't get any message and these files still show up as "unknown" when I do bzr status.  In the past I modified them many times and had no problems.
<muszek> using 1.1.0.candidate.1 on Debian Sarge
<asabil> anyone having this problem :
<asabil> Unable to obtain lock lp--1217851700:///lock
<asabil> held by asabil@bazaar.launchpad.net on host vostok [process #17382]
<asabil> locked 4 seconds ago
<asabil> using bzr break-lock will just create another lock
<beuno> asabil, do it twice
<beuno> or maybe 3 times, LP sometimes hast multiple process waiting to lock it
<asabil> beuno: thx, fixed my problem
<muszek> someone please help: http://pastebin.us/?show=d82d276b
<muszek> I've figured out the problem...
<beuno> asabil, :D
<fullermd> Different files than you thought were unknown?
<muszek> fullermd: I ran a db dump script from grandparent dir... and it placed those sql files in that grandparent dir (I didn't predict that)... and I kept trying to add those already added (grandparent) files and bzr status kept telling me, that grandparent files are unknown
 * fullermd nods.
<asabil> hmmm
<asabil> can anyone take a look at this :
<asabil> https://code.launchpad.net/~easy-radio/easy-radio/trunk
<asabil> seems like a bzr/launchpad issue
<mathrick> hiya
<mathrick> what is the easiest way to convert a CVS repo to bzr, without having a local copy of CVSROOT?
<Zindar> I don't know.. but I created a very simple thing using cvsps once...
<fullermd> AFAIK cvsps-import and tailor can both use cvs remote.  It'd be a buttload slower than local, though.  And probably run up the same or more network traffic/server load...
<mathrick> fullermd: cvsps yells at me that :pserver: is not supported and I need a local copy
<fullermd> Are you using --use-cvs?
<mathrick> no
<mathrick> I tried that, same result
<salgado> hey guys, what's the new record command (from looms) for?
<salgado> people have been merging from a loomified branch of mine and they were able to see the threads even though I never ran 'bzr record'
<CardinalFang> Hi all.  Should we expect a new version of Bazaar very soon?  I don't want to trouble my sysadmin to update twice.
<beuno> CardinalFang, a few weeks time
<beuno> there is one every month
<CardinalFang> Gracia.
<beuno> :D
<Odd_Bloke> beuno: There's something of a gap this time, because of the sprint.
<beuno> Odd_Bloke, a gap where?
<awilkins> Whe, just got bzr approved as part of an internal project.
<LeoNerd> Is there a way to use bzr against CVS repos, like there is bzr-svn for SVN ones?
<awilkins> Well "not objected to", which is nice
<LeoNerd> I'd love to be able to do things like 'bzr shelve' in checkouts
<awilkins> LeoNerd: AFAIK there is no round-trip support for CVS
<LeoNerd> :/ Boo
<Odd_Bloke> beuno: There'll be an extra week or so before the release.
<Odd_Bloke> awilkins: \o/
<awilkins> LeoNerd: You can get a bzr repo to follow a CVS repo (I think) but pushes to "home" would have to be patches
<awilkins> Is there PQM for CVS?
<LeoNerd> Hmm? Not sure I get what you mean there
<beuno> Odd_Bloke, right, hence, pushing it a few weeks. It was suppose to be out the first days of march IIRC
<awilkins> LeoNerd: I mean, is there an automatic thing that can accept patches which you've generated from your bzr tree and commit them to a CVS repo for you.
<beuno> actually
<beuno> I'm wrong
<beuno>  1.3 final  21 March
<awilkins> Verterok: I may be devoting more effort to bzr-eclipse simply because I'll be wanting to use bits of it.
<LeoNerd> awilkins: Well, I wouldn't mind if it had to be a bound tree.. that every commit operation pushed it to the CVS repo immediately
<awilkins> LeoNerd: http://bazaar-vcs.org/pushcvs?highlight=%28cvs%29  ??
<LeoNerd> Mmmm
<awilkins> LeoNerd: Is this a CVS repo you have influence over?
<awilkins> LeoNerd: Could you get them to migrate it to.... well, SVN at least ...
<LeoNerd> Heh.. It's been a point of contention for a while now :P
 * awilkins only uses CVS when he is forced to
<LeoNerd> Personally I'd vote to move the whole lot to bzr.. But.. naturally, some corporate inertia here ;)
<awilkins> My VCS experience started with Visual SourceSafe and moved onto Subversion
<Verterok> awilkins: nice :)
<awilkins> I dallied a little with monotone, git and hg, but I seem to be gravitating to bzr
<awilkins> Verterok: I have this horrible project to work on which needs revision control ; trunk-> branch merges are part of the deal, as are renames.
<awilkins> If I use use SVN I'll have to automate ALL of the revision control because I need merge tracking
<Verterok> awilkins: merge is in the next-features-to-land
<awilkins> I've been checking out the Roadmap :-)
<Verterok> awilkins: the conflicts resolution integration might take a bit more of time/effort
<awilkins> Verterok: Meh, even worse for me, I'm dealing with models not text files.
<awilkins> Verterok: Fancy shchmancy not-editing-the-xml-by-hand features like that are firly in "Stage 2"
<ubotu> New bug: #198793 in bzr "Problem accessing branches via bzr+https" [Undecided,New] https://launchpad.net/bugs/198793
<ubotu> New bug: #198798 in bzr "doc.bazaar-vcs.org needs a search form" [Wishlist,Triaged] https://launchpad.net/bugs/198798
<Verterok> awilkins: it' good to have this present during the design, bzr-eclipse could provides a extension point for the conflict resolution thingy ;)
<awilkins> Verterok: I'd be unsurprised to discover that there was already such a thing in there
<awilkins> Verterok: Eclipse has extension points for the kitchen sink
<awilkins> Question : Is it acceptible to modify content in a pre-commit hook?
<Verterok> awilkins: sure, but bzr-eclipse should provides the hooks for the bzr side
<fullermd> I don't think it's _possible_ to modify content pre-commit currently.
<awilkins> fullermd: The hook document says you mustn't modify delta_tree, but does that mean "you mustn't touch delta_tree" or "You mustn't do anything that would changes delta_tree" or even "you mustn't modify ANYTHING even if it wouldn't delta_tree because you'd just be tidying one of the files it describes as having changed"
<igc> abentley: here's the email - https://lists.ubuntu.com/archives/bazaar/2007q4/035340.html
<awilkins> So e.g. you couldn't read delta_tree and run a tidy on files it mentions
<awilkins> The way I read it, the only way for a pre-commit hook to abort a commit is to throw an exception, that right?
<Prodoc> good afternoon
<Prodoc> is it possible to change a commit message afterwards?
<beuno> Prodoc, no. You'd have to bzr uncommit
<beuno> and commit again
<Prodoc> darn
<Prodoc> I was hoping to prevent that
<awilkins> The commit log is probably hashed into the revision ID like everything else....
 * awilkins possibly displays lamentable ignorance of internal working here, presumes it's rather like monotone in some respects
<abentley> igc: tx
<LarstiQ> jam: 17:46:12 < igc> abentley: here's the email - https://lists.ubuntu.com/archives/bazaar/2007q4/035340.html
<ubotu> New bug: #198821 in bzr "switch of lw checkout shouldn't require force when branch moved" [Medium,Confirmed] https://launchpad.net/bugs/198821
<spiv> jelmer: http://rafb.net/p/nNwbWU65.html
<henke> How can I downgrade a branch to an older format?
<spiv> henke: use "bzr upgrade --foo", where "foo" is the format you want to downgrade to.
<TFKyle> spiv: how much does that help performance? I wouldn't expect refering to a variable there would be that slow but you never know
<henke> spiv, I tried that, but it tells me that it is already in the latest format
<spiv> henke: what formats do you want to downgrade from/to
<spiv> TFKyle: about 6x
<TFKyle> wow
<henke> spiv, well, it might not be necessary to downgrade now. Found some backport of a newer bzr for a friend
<spiv> TFKyle: i.e. "bzr svn-import" on Twisted's SVN takes ~20 sec per branch, rather that about 2 minutes.
<spiv> henke: ah right, for compatibility with old clients, I see.
<Odd_Bloke> abentley: The code is at https://code.launchpad.net/~daniel-thewatkins/+junk/bzr-mirror if you get time to glance over it.
<beuno> +junk sounds like it's promising
<Odd_Bloke> beuno: It's not a bzr branch, and I can't be bothered to set up a new project yet. :p
<Stavros> hello
<Stavros> say i checked out rev -2, made some changes and want to check in again
<Stavros> how would i do that?
<beuno> Stavros, commit?
<beuno> if it's a checkout, it will end the changes automatically
<Stavros> will it let me commit something from two revs back?
<Stavros> because i hate subversion so ****ing much right now
<fullermd> You can't commit onto a non-head rev...  you can only make a new branch from that and merge it.  A checkout might do that behind your back, not sure.
<Stavros> well, what i want to do is check out something two revs back, make some changes and recommit, overwriting those two revs
<fullermd> Well, you can dump revs via uncommit or pull or some such.
<luks> why not just uncommit them and commit the new change?
<fullermd> (assuming they're not out in the wild where other people are basing work off 'em, of course)
<mathrick> it seems to me that you could use bzr-rebase for that
<beuno> Stavros, or, you can branch, so bzr revert -r REVID
<luks> mathrick: no
<beuno> and you would have your commit history
<beuno> mathrick, no
<Stavros> bzr-rebase sounds like what i need
<luks> no, it doesn't
<beuno> Stavros, you won;t be able to merge back
<Stavros> will it make it look like i'm in HEAD without changing files?
<Stavros> beuno: i don't want to merge anything
<Stavros> i just want to commit my files
<beuno> Stavros, never again?
<beuno> bzr rebase will distroy your history
<Stavros> oh
<beuno> (or destroy)
<Stavros> that's not it then :P
<beuno> I'd say either uncommit
<beuno> or revert and commit
<beuno> both will do it for ya'
<Stavros> won't revert change my files?
<beuno> one will keep history that you reverted the change
<beuno> Stavros, revert will leave the files at the exact stage they where in htat commit
<beuno> so you don't need to checkout a few revisions back
<Stavros> beuno: destroying my changes, then
<beuno> Stavros, branch somewhere else
<beuno> do bzr revert
<Stavros> yeah, i was looking for something automatic
<beuno> copy over whatever you want
<beuno> and commit
<Stavros> ideally, i could just make bzr think i'm in head
<luks> Stavros: what should be the final result of this?
<luks> two branches with different heads?
<Stavros> luks: no, revisions -1 and -2 completely gone
<mathrick> humm, I have problems with upgrading a branch in dirstate format, upgrading to pack-0.92 works just fine, but when I try rich-root-pack, it fails with a missing revision error
<luks> or just one branch, with 2 revisions removed and one new
<Stavros> luks: the latter, yes
<luks> Stavros: then uncommit is what you want
<luks> uncommit twice
<mathrick> it's a CVS repo imported by tailor, btw
<luks> and then commit
<Stavros> luks: ah, but i have already done the changes, will that matter?
<fullermd> Uncommit probably isn't what you want, if you want to wipe out the changes in those revs.
<luks> Stavros: make a new branch and move them aside (merge --uncommitted)
<Stavros> aha, thanks
<fullermd> That'll just lose the commit granularity, not the changes.
<Stavros> ah, good
<Stavros> thanks a lot for your help
<fullermd> I'd try pull, myself.  That merges WT changes, though I've never tried it backward.
<Stavros> fullermd: oh
<Stavros> that might actually work
<fullermd> (merging changes backward, that is; I've used it to reset head often)
<Stavros> fullermd: well, when you pull from other revisions and change something, how do you recommit?
<Stavros> assuming that's what "reset head" means
<fullermd> Well, what pull does is essentially reset the head of the branch.
<fullermd> In normal usage, it's to a descendent of the previous head, but it can do it to an ancestor too, or an unrelated rev.
<mathrick> http://pastebin.com/m2e5c84e1 <-- any idea what might cause that, and how I can fix it?
<Stavros> oh
<Stavros> i didn't know you could pull to a release and ignore subsequent ones
<fullermd> At least when going forward, it will try to merge WT changes across (like a 'cvs up' with local changes)
<Stavros> ah, i see
<fullermd> I presume it will at least try to do so when it's moving "backward" too; I don't know how successful it would be in any given case, but it can't hurt to tar up a backup and try.
 * mathrick attempts to trick someone into looking at his error
<bobbo> does anyone know how i could fix http://pastebin.ubuntu.com/5315/plain/ ?
<beuno> bobbo, bzr break-lock
<beuno> bzr break-lock bzr+ssh://bobbo@bazaar.launchpad.net/~bobbo/+junk/bzr-grab
<beuno> (you might need to do it twice)
<LarstiQ> beuno: why is that?
<LarstiQ> beuno: repo, branch, tree?
<LarstiQ> but not tree because remote?
<beuno> LarstiQ, LP spawns multiple smart server threads for some reason and keeps getting locks
<beuno> not sure *why*
<beuno> but it's very common
<beuno> so you have to kick all of em in the nuts, or be fast enough before it locks it again
<bobbo> beuno; thanks that fixed it
<Odd_Bloke> I've found that breaking the locks via sftp rather than bzr+ssh tends to reduce the chances of screwage-up.
<phanatic> sprinters: anybody up for a nearby pizza hut maybe?
<jelmer> phanatic: anything that's food & relatively quick sounds good to me
<phanatic> jelmer: there's a restaurant near the tower, and near the hotel as well (ca. 15 mins by foot)
<james_w> Hi all. Is anyone still at the office?
<Odd_Bloke> james_w: Yeah, there are people around.
<james_w> Hi Odd_Bloke. Is cprov there?
<Odd_Bloke> Though we're heading off fairly imminently (I think).
<Odd_Bloke> james_w: I have no idea, I'm afraid.
<james_w> Odd_Bloke: no problem. If you see him, can you tell him he needs to ask for a new key at reception, as they had to invalidate his to give me one.
<james_w> Odd_Bloke: it's not that important though.
<james_w> See you all tomorrow, got to dash.
 * awilkins suspects that everyone is eating a large restaurant dinner
 * awilkins had to mak edo with leftover pizza
 * fullermd isn't...
<Odd_Bloke> awilkins: I ate room service, the other guys went for pizza.
<Odd_Bloke> And there are some guys in a pub somewhere.
<awilkins> Meh, I'm at home listening to NIN and drinking Vokdy-tonic
<awilkins> I contemplated coming, but it was a bit short notice, my python is not strong, and I'm too busy at work.
<grantgm> is there a good way to go about tracking the splitting of files?
<awilkins> grantgm: Use git :-)
<awilkins> Copy the file and delete the bits you don't need?
<grantgm> awilkins: alright...that's what I thought the answer might be.
<grantgm> does git have support for that?
<grantgm> it would be nice if I could 'bzr cp', but I'm sure that would cause all sorts of confusing-ness for merging later on
<awilkins> Git (AFAIK) tracks _content_ rather than _files_, so it naturally tracks file splitting and joining.
<awilkins> It snapshots whole trees as revisions
<awilkins> Although you might ge ta more coherent response in a git channel, where the people are either not in a huge pizza orgy in London, or drunk in their office.
<grantgm> mmm...pizza orgy...
<ferringb> disturbing imagery
 * awilkins would settle for a pizza quickie right now.
<fullermd> Sounds like a sausage-fest.
<abentley> The pizza was totally into it, so I don't know what your problem is;.
<grantgm> oh noes...tomato sauce EVERYWHERE!
<awilkins> At least you don't have to deal with that anchovy smell
 * awilkins stalled the conversation againb
<abentley> awilkins: After a while, you don't even smell the anchovies.
<awilkins> Does bzr have a (per file) merge hook / configurable file merge support ?
<abentley> No, but tomorrow I'll be helping Odd_Bloke get started on implementing that.
<awilkins> Can you have per-branch hooks (ooh, becoming petilent here)
<awilkins> *pestilent
<abentley> awilkins: Sure.
<awilkins> abentley: Where would you put a per-branch hook?
<fullermd> You can put 'em in branch.conf, and probably in locations.conf too.
<abentley> In ~/.bazaar/plugins
<awilkins> How about somewhere in the branch so they propagate?
<fullermd> That I more doubt.
<abentley> awilkins: There are a few security issues with that.
<awilkins> (with a config option to switch it on so you canb't hack people so easily with it)
<awilkins> Hah, was just getting there
<awilkins> ... maybe you could just permit signed revisions of hook that have been user-approved to run
<awilkins> ("revision" and "signed" being redundant of course)
<awilkins> Meh, you could even have branch plugins I suppose
 * awilkins is getting power-mad
 * fullermd unplugs awilkins.
<awilkins> Hooks are effectively special plugins anyway
<radix> I would love to have something that said "this branch has a branch hook, as shown. Would you like to enable it?" upon branch
<abentley> awilkins: I don't think remotely-configured hooks are on anyone's roadmap.  Sane, secure patches accepted.
<awilkins> Remote config was always a feature people kept asking for in SVN
<awilkins> All the hooks are already in the repo with that of course
<awilkins> Things like automatic mime-type attributes were a local config option which meant that redistributing the was a PITA when you had a lot of users
<awilkins> (esp when your users have a habit of surfing your repo directly to check content, and they hit a page with no mim-type in Firefox, which respects them and treats it as text/plain)
<awilkins> (IE was fine because it's a presumptive pile of crap)
<beuno> vila, http://permalink.gmane.org/gmane.emacs.devel/91263
<beuno> vila,
<Odd_Bloke> beuno: That whole thread makes for interesting reading.
<Odd_Bloke> Apparently one of the things git has going for it is a large and active developer base...
<Odd_Bloke> Anyhow, bed time.
<jelmer> Odd_Bloke! \o/
<jelmer> Odd_Bloke: You're missing all of the interesting discussions
<mwhudson> oh god, of course loggerhead 1.2 had to have a catastrophic embarrassing bug
<Peng> What is it?
<awilkins> What, it outs people at random?
<mwhudson> the changelog view is randomly ordered
<awilkins> Unstable sort algorithm?
<mwhudson> well, just no sort algorithm
<awilkins> Ah. hashtable?
<mwhudson> i changed the way that filtering ghosts was done, and a side effect was that the order of the results of a particular method ceased to be related to the order of the input
<awilkins> Anyone else get a copy of "Ghosts" by Nine Inch Nails?
<paty__l> i'm thinking about participating at gsoc doing bazaar integration for eclipse. with whom i can talk about it?
<awilkins> Verterok
<awilkins> aka Guillermo Gonzalez
<paty__l> thanks =)
<Verterok> hi paty__l :)
<paty__l> hi =) does this integration with eclipse has already been done or it is still open?
<Verterok> I'm working on this, but all contributors are more than wellcome
<Verterok> paty__l: take a look at: http://bazaar-vcs.org/BzrEclipse
<paty__l> great.. i'll have a look at this. is bazaar going to participate at gsoc this year?
<Verterok> paty__l: yes, are you only interested in Eclipse integration or in any other IDE integration, like Netbeans or IDEA?
<Verterok> awilkins: thanks for the hilight ;)
<paty__l> i have some experience with building eclipse plugins and i dont have this experience with Netbeans or IDEA. but if it is possible to learn it untill the program begins, i'm interested
<awilkins> Has Jelmer Veernooij been at Sprint?
<Verterok> paty__l: oh, great. If you want to work in the eclipse integration there is plenty of work to be do
 * awilkins cheers
<Verterok> paty__l: also, if you are interested in learning other IDE integration, you are wellcome too :)
<Verterok> awilkins: yes, he's leaving tomorrow
<awilkins> I have a win32 test log from bzr-svn for him
 * awilkins reads PEP-8 and immediately gets annoyed that it recommends spaces over tabs for indents
<paty__l> great :) i'm interested in working in the eclipse integration. where can i learn more about what work still need to be done in this integration?
<awilkins> Try the bzr-eclipse roadmap... http://bazaar-vcs.org/BzrEclipse/Roadmap
 * Peng gapes at awilkins. Tabs?!
 * awilkins prepares for TAB JIHAD
<paty__l> sure.. i'll have a look at that
<Verterok> paty__l: if you have any questions, don't hesitate in contact me you can find my email, Jabber, etc at launchpad.net/~guillo.gonzo
<paty__l> oh, great.. thanks :) i'll have a look and if have any questions, i'll contact you
<Verterok> great :)
<mlh_> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00234.html  - awesome
<awilkins> Heh, someone posted the Stallman quote from that thread earlier
<awilkins> "We should all snuggle up to Bzr because it want's to be a GNU too" (or words to that effect)
<jdong> mlh_: that's awesome
<jdong> I might... start using emacs.... because of this :)
 * awilkins would rather not have to pay a surgeon to unknot his fingers
<awilkins> Get Bram Moolenaar to change vim to bzr.
#bzr 2008-03-06
<awilkins> Blech, don't you just love to hate MS sometimes.
<awilkins> I just found a weird file called DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.ini my user profile
<awilkins> It's an archive of 128-byte compressed thingies
<awilkins> Turns out it's where WMP8 stores it's "recent files" tripe
<awilkins> I wasted 10 minutes figuring out what that was
<uws> I'm a little concerned.
<Peng> Me too.
<uws> If indeed Bazaar is becoming a GNU Project... (see http://permalink.gmane.org/gmane.emacs.devel/91263 for evidence)
<uws> ...will I be forced to grow my beard as a happy Bazaar user?
<uws> Please clarify. Love, /me.
<Peng> Just a moustache will be acceptable.
<Peng> You could always switch to Mercurial. They only require lustrous eyebrows.
<uws> Okay. For Gnome I'm still using SVN on a daily basis... centralized haircuts perhaps?
<bob2> http://www.advogato.org/person/apenwarr/diary/371.html <- git luvin'
<Parker-> awww
<Parker-> Isn't that cute
<jamesh> bob2: is he really saying that it is remarkable that you can store files in less space than a conventional filesystem if you don't want to modify them?
<ferringb> jamesh: compression (rw on compressed blocks is a pita), fs overhead, etc...
<ferringb> 'course that guy is calling git a fs, which is a bit odd in my eyes ;)
<jamesh> ferringb: I realise that.  I am just a bit surprised that he doesn't appear to realise it
<jamesh> of course, that might just indicate that the jobs he is working on fit the model of git's object database
<speakman> hi ppl!
<ubotu> New bug: #148783 in olive ""Unknown error" (DBus) when trying to commit" [Undecided,New] https://launchpad.net/bugs/148783
<james_w> http://chistera.yi.org/~adeodato/blog/entries/2008/03/05/one_day_with_git.html
<james_w> dato: hi. Are you around?
<awilkins> Hmm, VCS are filesystems ; git was even written by the king of filesystem design, Torvalds
<awilkins> It would seem that people like the pre-commit feature of git ; what would the chances of puttin it in bzr be?
<awilkins> I have to admit, thinking about it, it would be pretty cool.
<james_w> awilkins: what do you mean by pre-commit?
<awilkins> This git add -p thing.... putting things into a sort of special "to be committed" revision is how I'm thinking about it
<awilkins> Like "I'm reviewing all my diffs and this bit is ok, so I'll put it in pre-commit, where it will wait until I'm finished, but now lit no longer distracts me in diff operations because it doesn't show up"
<awilkins> A bit like shelve in reverse, I suppose
<dato> james_w: hi
<james_w> hi dato. How are you?
<james_w> awilkins: I think it should be possible. I'm not sure where it would fit, maybe a new command?
<dato> james_w: I'm actually quite well, thanks. just suffering a bit with Uni, but I guess that's normal :-)
<james_w> dato: yeah.
<james_w> dato: thanks for the post, I found it very interesting.
<awilkins> james_w: Reading the (horrible) man page, it also appears that you can just "pre-commit" hunks of the file.
<james_w> awilkins: add --interactive?
<dato> james_w: great
<james_w> dato: and thanks for doing the packaging of bzr. I hope you'll keep doing it while you still use bzr, you do a great job.
<james_w> dato: and I hope that you we can improve bzr so that you don't feel the need to leave.
<awilkins> james_w: I'm not sure, that blog page you posted earlier says git add -p
<awilkins> james_w: The --interactive mode is where you can commit just hunks, yes
<dato> yeah. I would even continue to do it if nobody else is available, is doesn't need much time.
<james_w> dato: cool. Thanks.
<james_w> awilkins: yeah, it's quite nice.
<dato> igc: around? I was impatient and took a stab at implementing bzr-fast-export.py. I didn't need to use any code from your fastimport plugin, though. also, I dubbed it (though still mostly unpublished) bzr-crude-export.py, as not to conflict with your prospective -export.py. would you like to take a look? I have no idea if I'm making good use of the bzrlib API or not.
<james_w> awilkins: I think making it something you explicitly do on top would be ok. I think the "git add file; edit file; git commit" not committing the current state is something that we don't want.
<dato> igc: it can import single branches, preserving merges, even -r 0..-1 merges. importing several related branches into a same git repository is next in my TODO.
<james_w> awilkins: unless you have staged hunks perhaps.
<awilkins> james_w: Yes, we don't want to let the "creeping evil" of git in by trying to adopt it's features
<james_w> awilkins: :)
<awilkins> THe comparison with git/vi is fair
<awilkins> (I don't use git, it's windows non-nativeness puts me off)
<awilkins> But people forget that more and more non-techy users are now having to use VCS systems
<james_w> yeah, I think it might be. However I wouldn't mandate that all contributors to my project use vi.
<james_w> that would be too much, so I'll let you use emacs, but that still excludes people.
<awilkins> I have a hard enough time teaching non-programmers to use SVN
<awilkins> I think git would be a bridge too far
<igc> dato: hi. I'd be happy to take your work so far as a basis for mine
<awilkins> dato: Could I see it too? My interest is seeing an example of fast-import format generation in a language I understand better than C.
<igc> dato: it would be great to get things round-tripping as best we can between us
 * awilkins may have to write mks-fast-export *shudder*
<dato> http://chistera.yi.org/~adeodato/tmp/2008-03-05/bzr-crude-export.py is yesterday's version
<dato> right now I was converting REVISION_LIST to a dict, and there's a bug with filenames that contain non-ascii, but that's easily fixed (haven't committed yet)
<dato> oh, and I was hoping to diagnose some problem I was having with quotes
<igc> dato: ok, let me know when you're happy with it and I'll bundle it inside fastimport if that's ok
<awilkins> dato: You _know_ you should be uploading a bzr branch to that server, right? :-P
<dato> igc: ack
<igc> and open up the plugin to multiple committers
<awilkins> Or maybe you could both just start a launchpad branch for it
<dato> awilkins: well, tbh I was unsure where to put it, and whether to try git *g*
<dato> no, seriously, I'll get this figured out soon
<dato> igc: is two revision_trees + changes_from + get_file_text the proper way to do it?
<dato> igc: answer whenever you can, in some hours or days ;)
 * dato leaves for class now.
<igc> dato: I hadn't thought about it yet sorry :-)
<igc> I'll think about it today, ask abentley, etc.
<dato> igc: yeah, np.
<dato> oh, that'd be awesome, but feel no pressure.
<dato> bbl
<lifeless> less ~/bin/drop-caches
<lifeless> #!/bin/sh
<lifeless> # get written data to disk (not that its guaranteed)
<lifeless> sync
<lifeless> # (drop the unmodified pages)
<lifeless> echo 1 | sudo tee /proc/sys/vm/drop_caches
<lifeless> LarstiQ: ^
<poolie> lifeless: that tee command is not write
<poolie> right
<poolie> it does not write :)
<poolie> you need um
<soren> lifeless: Why 1?
<poolie> 1 for on
<soren> No.
<LarstiQ> 1 for pagecache
<soren> 1 to free pagecache.
<soren> 3 to free both pagecache, dentries and inodes (i.e. everything that can be freed).
<soren> -NOCONTEXT, so Idon't know what you're trying to do exactly, but I find that usually 3 is what people really want.
<LarstiQ> 3 does make it slower
<LarstiQ> soren: what we're doing is looking at cold cache startup time
<soren> s/NOCONTEXT/ENOCTXT/, obviously.
<jamesh> lifeless: I uploaded a pair of branches to implement half of my proposed changes to bzr-dbus
<jamesh> lifeless: with those changes applied, it should provide equivalent functionality
<mrevell> beuno: Did you get the Ogg file?
<beuno> mrevell, yeap, thanks!  Ping me when it's up on Launchpad blog and I'll post on the planet
<mrevell> cool, will do
<lifeless> soren: its changed since I first wrote the script :)
<lifeless> soren: thanks for th details
<soren> lifeless: Hm... Not that it matters much, I'm sure it's always been this way, actually.
 * spiv likes "man proc"
<beuno> james_w, this might be useful: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-March/000395.html
<james_w> beuno: thanks.
<james_w> beuno: I forgot to bring my wiki login password. Is it ok if I add to the page at the weekend?
<beuno> james_w, it's alright, I'll add the bits you sent and you can tweak it if you feel it's not well represented
<beuno> just thought I'd poke you to do work for me  :p
<james_w> :-)
<ubotu> New bug: #199147 in bzr-svn "svn: revision identifiers don't work even in bzr-svn branches" [Undecided,New] https://launchpad.net/bugs/199147
<lazy1> How do I view the log for a directory (including all files and subdirectories)
<beuno> lazy1, just do:  bzr log dir/
<james_w> lazy1: that doesn't work right at the moment I'm afraid.
<beuno> james_w, no?  I ust fired it off and it seemed to work fine
 * beuno re-checks
<lazy1> It shows only the log for the directory, but not for the files inside
<james_w> beuno: it shows the first revision that adds the dir, at least for me.
<beuno> aaah, that's right
<james_w> and maybe renames of the directory.
<beuno> lazy1, listen to james_w  :D
<ubotu> New bug: #132191 in bzr-gtk (universe) "installs unuseable desktop file to bzr commit-notify" [Medium,Fix committed] https://launchpad.net/bugs/132191
<lazy1> I will, thanks
<lazy1> james_w, any intentions to implement this?
<james_w> lazy1: yes, there is. I can't remember what is blocking it at the moment.
<lazy1> OK, thanks
<ubotu> New bug: #199150 in bzr "AssertionError during merge of two branches with similar content but no shared base revision" [Undecided,New] https://launchpad.net/bugs/199150
 * beuno waves to jelmer 
<jelmer> hey beuno
<beuno> how was your flight?
<jelmer> I came closer than ever to missing it
<jelmer> but other than that it was ok :-)
<jelmer> anything interesting happening @ the sprint today?
<beuno> jelmer, no fire alarm yet, if that's what you're hinting at
<jelmer> I meant more in terms of topics that have been discussed :-)
<beuno> launchpad bashing was fun
<jelmer> ah, heh
<beuno> and the gpg-signing bit was interesting too
<jelmer> that's probably the only nice thing about closed software from a user pov
<Odd_Bloke> jelmer: I was about to phone you for bzr-svn support, but spiv helped me out. :p
<Faithful> Hi, can I use Bazaar is binary files like jpg or autocad drawings?
<jelmer> you can complain about stuff that sucks without being told "patches are welcome" ;-)
<jelmer> Odd_Bloke, :-)
<jdong> Faithful: yes
<Faithful> and it still does diffs of revisions?
<jdong> umm... internally, yes. If you try to diff two revisions with binary changes, I don't know what it'll display
<spiv> jelmer: I now have a svn-import of Twisted at http://people.ubuntu.com/~andrew/twisted/.  Thanks!
<jelmer> spiv: w00t
<awilkins> Ok, % formatting a string ; why doesn't this work "my %s string %s %s" % ["sexy", "is", "cool"]
<elmo> % () not % []
<awilkins> Hmm, better
<awilkins> Still getting error, but different error :-)
<ubotu> New bug: #199166 in bzr "Move revisionloader.py into core" [Undecided,New] https://launchpad.net/bugs/199166
<bast> hi everyone
<bast> i've a strange problem
<bast> i use bzr all the time
<bast> i manage a lot of project with it
<bast> and suddendly i can'to anything with it
<bast> bzr status/branch/commit/ etc
<bast> nothing works
<bast> my processors is used at 100%
<bast> no output
<bast> i don't understand :s
<awilkins> Try the same command with --no-plugins
<phanatic> beuno: you shouldn't have said that about the fire alarm... see what happened :P
<bast> awilkins: nothing changes
<bast> obliged to do a ctrl+Z then to kill
<luks> check ~/.bzr.log
<bast> luks: i'w watching it
<bast> 0.158  encoding stdout as sys.stdout encoding 'UTF-8'
<bast> 0.159  bzr arguments: [u'init']
<bast> 0.160  looking for plugins in /Users/bast/.bazaar/plugins
<bast> 0.160  looking for plugins in /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bzrlib/plugins
<bast> 0.160  Plugin name __init__ already loaded
<bast> 0.160  Plugin name __init__ already loaded
<bast> 0.214  encoding stdout as sys.stdout encoding 'UTF-8'
<bast> 0.444  created control directory in file:///private/tmp/
<bast> 0.452  creating repository in file:///private/tmp/.bzr/.
<bast> 0.464  creating branch <bzrlib.branch.BzrBranchFormat6 object at 0x1c1c890> in file:///private/tmp/.bzr/
<bast> my processor is at 100%
<bast> and the init on an empty dir
<bast> isn't finished
<bast> i have a macbook on mac os x
<luks> hmm
<bast> i used it all the time and it begin to error with no reason
<bast> i have python 2.5.2
<bast> bzr 1.2
<luks> I don't really know how to debug something like this
<luks> `python -m trace --trace /path/to/bzr` is what I personally would do, but that's extremly verbose and only useful if you know some python
<bast> i don't know python :s
<luks> well, you can still try and see where it ends
<luks> but as I said, expect lots of text in the terminal :)
<poolie> luks, bast: what are you trying to do?
<bast> i tried another shell
<bast> :s
<bast> nothing change
<bast> to know where is the bzr command it's whereis no ?
<phanatic> http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html
<luks> poolie: find out why bzr hangs
<poolie> on unix, try pressing ctrl+backslash?
<bast> i'm on mac os
<bast> it's don't work
<LarstiQ> phanatic: executive summary?
<spiv> luks: isn't there an strace-like tool you can attach to a running process?
<phanatic> LarstiQ: tla fork + BeOS competitor... :)
<luks> I have no idea :)
<poolie> it was funnier 15 years ago...
<LarstiQ> phanatic: ah :)
<awilkins> Gah, tinymce's new plugin style is annoying, it confuses JSEclipse
<beuno> might be of interest: http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html
<LarstiQ> beuno: phanatic just mentioned that
<beuno> LarstiQ, right, fire thing threw me off
<LarstiQ> beuno: heh
<mwhudson> getting thrown off the millbank tower would be unfortunate
<LarstiQ> mwhudson: it would be a lot faster than walking all the stairs each day.
<Toksyuryel> interesting
<Toksyuryel> I'm not sure the author like bzr :(
<Toksyuryel> seems like a fan of git =/
<james_w> for a few days now at least.
 * Toksyuryel supposes that once bzr's been rewritten in C or some other compiled language, more people will wake up to how awesome it is :)
<dato> james_w: heh
<james_w> Toksyuryel: that should be any day now.
<beuno> james_w, http://launchpadlibrarian.net/12471357/buildlog_ubuntu-hardy-i386.baz_1.4.2-5.4_FAILEDTOBUILD.txt.gz
<TFKyle> hmm, someone should see if they can get bzr translated via. rpython :D
<Toksyuryel> I'll use it as-is though... I don't care how much slower python is, I more than make up for in the time I'm not spending fighting with it to do what I want it to do
<Toksyuryel> james_w: cool, I didn't realize it would be so soon, I figured they'd want to deal with all the bugs and missing features first, but seeing how fast this thing moves they'll probably show up soon enough anyway
<orospakr> Toksyuryel, god, why?
<beuno> james_w, https://edge.launchpad.net/ubuntu/+source/bazaar/1.4.2-5.3
<Odd_Bloke> spiv: I just got http://paste.pocoo.org/show/31944/ using the stable 0.4 tip.
<Odd_Bloke> Hmm, I also seem to be getting it with the latest stable.
<Toksyuryel> orospakr: ?
<orospakr> Toksyuryel, why would anyone want to rewrite bzr in a different language?
<Toksyuryel> orospakr: There is a perception that bzr is "slow" because python is an interpreted language. While it is true that bzr the program would run a hell of a lot faster written in a compiled language such as C, most people miss that bzr is still faster than other VCSes because even though the code runs slower you get more work done faster because you aren't fighting with the software
<Toksyuryel> orospakr: however, it's still a worthwhile change and it'll get a lot more people interested in bzr. and according to james_w it's almost done anyway :)
<orospakr> That is my opinion, actually.  Hence my remark asking why anyone would want to rewrite it. :P
<orospakr> ack.
<orospakr> But the Python code has unit tests, doesn't it?
<orospakr> Does this C implementation have all the tests and features that the original python version does?
<luks> Toksyuryel: the fact that bzr is "slow" is not that much relevant to python
<orospakr> I still with the Python version, thanks.
<orospakr> s/I still/I'll stick/
<james_w> Toksyuryel: sorry, I was being sarcastic.
<orospakr> Toksyuryel, it really wouldn't be a worthwhile change.
<james_w> It's exactly the opinion of the bazaar team that the increased ease of programming more than offsets any speed costs of an interpreted language.
<Toksyuryel> james_w: oh, good; I was hoping such a rewrite would be saved until after essential features are implimented and most bugs worked out :)
<orospakr> In fact, it would be a big waste of time.  If they want to fix any performance issues, they should profile the software and work on any problem spots.
<orospakr> Which they have done, in fact.
<orospakr> I don't find bzr slow, in fact.
<orospakr> There are some facts for you. ;)
<Toksyuryel> I remember someone mentioned before that it was in the plans, was implied to be very far off plans and happy to see that attention is being paid more where it's needed :)
<james_w> Toksyuryel: I don't think it is anyone's plans.
<LarstiQ> Toksyuryel: the option has been held open, but don't expect to see that happen
<james_w> anyway, time to eat. Bye all.
<LarstiQ> right
<Toksyuryel> enjoy your meal
<orospakr> Declaring a "rewrite in a compiled language" is the worst way to optimize software. :)
<orospakr> Mostly because you go from having tested, working software to no software at all.
<Toksyuryel> better than writting code that needs comments the length of a docteral thesis
<Toksyuryel> but I don't think bzr is going to go there anytime soon :) too many features to add and bugs to fix
<fredreichbier> hello
 * Toksyuryel personally would still use bzr if it were written in BASIC or hell, even java- it'd still be faster to use than anything else because of the way it works
<fredreichbier> how do i change the remembered default location of `bzr push`?
<awilkins> bzr push --remember
<Toksyuryel> anyway, time for bed for me... getting sleepy and incoherent :) good night everyone *waves*
<fredreichbier> hm awilkins that didn't work. i just changed the value in ~/.bazaar/locations.conf, seems to work now
<fredreichbier> thank you anyway
<awilkins> bzr might work on IronPython one day, that's sort-of-compiled
<apol> is there anybody from ide integrationg around?
<apol> *integration :P
<apol> if there isn't anyone, could anybody point me out who should I ask?
 * apol feels alone
<LeoRochael> This is probably a FAQ, but, I'm using the launchpad bzr packages for ubuntu, and there doesn't seem to be a bzr-1.2 compatible version of bzr-svn
<dato> there isn't one yet
<LeoRochael> can I compile from source or is bzr-svn 0.4.7 not compatible with bzr 1.2?
<LeoRochael> or maybe the bzr-svn "trunk" has bzr 1.2 support?
<mwhudson> i must admit i generally just do "cd ~/.bazaar/plugins; bzr get lp:bzr-svn svn"
<yacc> lp:bzr-svn ?
<LeoRochael> yacc: I assume it means the launchpad repository for bzr-svn
<yacc> oh ;)
<yacc> Is that a general shortcut?
<LeoRochael> yacc: I suppose so, for launchpad hosted projects...
<johnny> now if only launchpad was open source..
 * johnny wants to hack on it..
 * johnny wants XMPP messaging..
<blueyed> Can you have multiple branches in a single directory? so that you can switch to one of them, commit and switch back?
<johnny> i don't understand that workflow method personally..
<LeoRochael> blueyed: bzr shelve perhaps?
<johnny> but it seems like you can with hselv right?
<LeoRochael> johnny: I can understand this workflow when you have a lot of external systems that point to your directory and you don't want to keep changing them to other directorys to keep two branches in parallel
<LeoRochael> quick example
<LeoRochael> say you're managing your ~/public_html with bzr
<luks> use a lightweight checkout and 'bzr switch'?
<bob2> blueyed: you can have a repository with multiple branches, then use "bzr switch" to switch a single checkout between them
<johnny> hmm... LeoRochael   aha.. now i get it.. i do that all the time with monotone, but i wonder if i'm missing anything
<zepard> hi people
<zepard> I am wondering why the http://bazaar-vcs.org/ReleaseRoadmap is showing the latest version upcoming = 0.92
<bob2> no one has updated it since september - guess lp has replaced it
<zepard> ok its there for historical reasons I guess but google still indexing it first
<zepard> the first page shows the 1.2 download though
<zepard> :(
<blueyed> my workflow is: branch the vcs-import branch from launchpad (for a mega-feature-foo branch) and while refactoring, I want to make changes there which should go to another, new branch "trunk".. so I'd like to switch to "trunk" (in the same directory, basically the current branch without the locally modified changes; needs to be created) and commit only some files there. Then switch back.
<blueyed> http://bazaar-vcs.org/ReleaseRoadmap needs to redirect somewhere useful.. or needs an update (for a long time already).
<zepard> redirecting would more simple but not smooth since the updated page is in lp.
<zepard> an update then :)
<zepard> since there is not a huge activity on this page
<bob2> blueyed: that can work - branch from lp to some other location, then checkout that location somehwere and work in the checkout
<blueyed> bob2: sure, but that would require me to change the directory for testing that subbranch/-feature.. think DocumentRoot entry in Apache..
<blueyed> ..so it's far more comfortable to check this into the same other-feature branch, which is bad.
<LeoRochael> blueyed: what about "bzr shelve" or "bzr switch"?
<dato> MadCoder: I see you were the last to touch unquote_c_style() in 7fb1011. could you investigate, who is at fault here: http://dpaste.com/38299/
<dato> er, EWIN
<bob2> blueyed: eh, no
<bob2> blueyed: you bzr switch amongst branches stored outside the checkout, which doesn't require you to move or edit different files
<andrei_> hey guys! I love bzr :). quick question: are you going to participate on summer of code this year?
<andrei_> cause i'd be interested, as a student
<andrei_> i see something on http://bazaar-vcs.org/SummerOfCode
<andrei_> but i guess these are the projects from last year, right?
<mnemoc> hi, what's the command equivalent to svn export http://.... in bzr?
<luks> bzr export http://...
<mnemoc> uh
<mnemoc> luks: thanks :)
<blueyed> LeoRochael, bob2: I would certainly get away using "bzr branch ... new", "bzr shelve", "bzr switch new", "bzr unshelve", "bzr ci", "bzr switch ." or something similar, but sounds dirty.. ;) isn't git able to switch to another branch more easily in the current directory/checkout?
 * mwhudson dumps the "efficiency over NFS thread" unread
<mwhudson> am i missing anything?
<mnemoc> can i list the tags on a remote location?
<Peng> Oh, I didn't know you offered bzr under other licenses.
<dato> Peng: ref?
<Peng> Homepage.
<Peng> "Free. Bazaar is available under the GPL v2 or later. If you want to embed Bazaar into your products under a different license, please contact us."
<dato> ah
<dato> thanks
<Odd_Bloke> apol: You want beuno and Verterok, I think.
<apol> um, hello beuno and Verterok?
<beuno> apol, yeah, hello
<Verterok> apol: hi :)
<apol> i'm a kdevelop developer and i'd like to know how prepared is bzr to work with ide's
<apol> are there any libraries and so?
<apol> haven't investigated yet :P
<Odd_Bloke> apol: http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-a1f0e77d00a77e7f4634334e12dd5703e44fd8aa has some thoughts from the sprint that is ongoing.
<apol> is there anything of this done?
<apol> beuno: Verterok: ^
<beuno> apol, sorry, yeah
<beuno> well, we've just started putting a plan together
<beuno> so I can't point you to anything specific
<beuno> but I can get back to you with pointers and some general information
<Verterok> apol: for Java (aka Eclipse) I'm using bzr-xmloutput plugin
<apol> beuno: ok, that's a good place to start :P
<beuno> eclipse is using xml to talk to bzr
<beuno> so there is no reason you can't do that today
<beuno> apol, and visual studio integration is using an embedded python interpreter
<beuno> apol, can you bind to python?
<apol> beuno: well, I'm working on a kross plugin, that would enable this possibility
<apol> that's why i was asking actually
<beuno> apol, than you can talk to bzrlib directly
<beuno> and it's fairly straightforward
<beuno> let me get a link for you
<beuno> apol, http://bazaar-vcs.org/Integrating_with_Bazaar
<apol> thanks beuno
<Verterok> apol: I'm looking http://kross.dipe.org/, and it seems to provide python bindingss
<LeoNerd> I find quote a lot, I use "shelve" to take out changes, to "commit" the rest, then "unshelve" the others back in, in order to do a partial commit of my changes. Is there perhaps a way to do this more directly..?
<apol> Verterok: yes sure, that's what i meant :P
<apol> looks like integration using python is what i was looking for
<Verterok> apol: yeap
<apol> Verterok: why don't you use that on eclipse? can't bind to python?
<Verterok> apol: Eclipse is Java based, for the moment there is no decent Java-python bridge
<apol> oh ok
<Verterok> apol: so, I use a wrapper, with multiple implementation, the current one uses bzr executable + xmloutput
<apol> well, I'll look into that this weekend
<Verterok> apol: when Jython reacchs 2.5, it will be jython based :D
<Verterok> apol: great!
<apol> maybe I'll try to apply on that kross+bzr thing for gsoc
<apol> Verterok: yes i was thinking of jython
<apol> seems like sun hired some hackers to work on it
<Verterok> apol: it's in 2.3 compatibility, bzr needs 2.4 :(
<Odd_Bloke> apol: lifeless or poolie are probably people to talk to regarding GSoC.
<Verterok> apol: if you decide to apply for gsoc, please contact pooli
<Verterok> Odd_Bloke: exactly :)
<apol> Odd_Bloke: I would try to apply on the kdevelop side i think
<apol> but i'll contact them anyway
<beuno> apol, yes,, we really want IDE integration
<beuno> so it's a good time to jump in and get a lot of help
<Odd_Bloke> LeoNerd: What would you envision a more direct approach looking?
<beuno> make sure you keep us updated on progress
<beuno> and don't hesitate to contact me or the list directly
<LeoNerd> bzr interactive-commit  =>
<LeoNerd> Then it goes to a shelve-like yes/no list of hunks
<LeoNerd> At the end, it asks  "Commit? (y/n)" and then offers to enter a message
<apol> beuno: I will :) thanks
<beuno> apol, thanks
<LeoNerd> I.e. interactive commit would be literally like shelve + commit + unshelve, but with the yes/no reversed
<apol> np
<beuno> apol, if you could drop me an email anyway so I have your details when we have a document prepared and send them to you: argentina@gmail.com
<apol> beuno: are you from argentina? :P (i'm spanish/catalan)
<beuno> apol, yeap, feel free to use spanish if it's easier for you  (so is Verterok)
<apol> :P ok
<apol> not really easier, but more familiar you know ;)
<beuno> apol, I do  ;)
<apol> sent
<Odd_Bloke> LeoNerd: If you're interested in writing it, you could do that from a plugin.  It's probably too niche to go into the core, but I (and guys on the list) could probably give you some pointers.
<LeoNerd> Niche?
<LeoNerd> Heh.. I only mention it 'cause I'm having an argument with a darcs fan who says that's how darcs commit works :P
<LeoNerd> I wondered if it's be nice to have in bzr, to wave back
<Odd_Bloke> LeoNerd: It's probably non-trivial, and probably wouldn't get used by that many people.
<Odd_Bloke> That said, if it's there, people will use it.
<LeoNerd> Well, I for one would use it loads
<LeoNerd> Almost every commit I make is shelve-assisted
<Odd_Bloke> Me too, but I want to be able to assess my tree-state and perhaps make some modifications.
<Odd_Bloke> So I probably wouldn't use it.
<Odd_Bloke> However, if your workflow is different, that's cool.
<james_w> sorry, I missed the start of this conversation. Are you discussing darcs record's hunk level commit?
<LeoNerd> Yah
<james_w> have you tried bzr's record plugin?
<LeoNerd> Ah, no
<LeoNerd> Shall look into that, thanks
<james_w> http://bazaar-vcs.org/BzrPlugins
<james_w> http://projects.collabora.co.uk/~asabil/bzr/bzr_record/
<Odd_Bloke> james_w: That second link is broken. :(
<james_w> oh dear.
<Peng> That's not good.
<james_w> http://people.collabora.co.uk/~asabil/bzr/bzr_record/
<james_w> Can someone edit the wiki page please?
<Odd_Bloke> james_w: Done.
<james_w> thanks.
<Odd_Bloke> james_w: It seems that 'record' doesn't actually do commits, just creates patches of the changes you've made.
<LeoNerd> Ah.. :/
<Odd_Bloke> LeoNerd: That said, it demonstrates how to integrate the shelf stuff into a separate command.
 * LeoNerd nod
<james_w> Maybe we should post to the list for some clues on how to integrate it with commit.
<Odd_Bloke> TBH, this functionality can be replicated with "bzr shelve && bzr commit -m '<message>' && bzr unshelve --all".
<LeoNerd> Yes.. that's exactly what I do now
<LeoNerd> I just sometimes get confused in my head and say yes when I mean no, or vice versa
<LeoNerd> You have to shelve away the things you _don't_ want
<LeoNerd> Whereas interactive commit would say yes to the things you _do_ want.
<Odd_Bloke> Ah, yeah, I see.
<james_w> I know a lot of people love "darcs record".
<Odd_Bloke> LeoNerd: So the record plugin seems to have its various concerns fairly well separated, so a lot of what you want to do could fairly easily be scavenged. :)
<james_w> night guys
<Peng> I like "hg record", but it was weird to get used to after "bzr shelve".
#bzr 2008-03-07
<Odd_Bloke> LeoNerd: I'm going to bed now, if you want to discuss this in more detail, drop me an email at D.M.Watkins@warwick.ac.uk (or email the list). :)
<Odd_Bloke> Night all!
<mwhudson_> damn people in london and their sleeping habits
<dash> Hi. someone remind me how to roll a working copy back to a previous revision? I seem to have svn brain today, I expected 'bzr up -r ...' to do it :)
<LeoNerd> bzr revert -r ...
<dash> hah, ok
<LeoNerd> You're thinking in CVS-mode :)
<alwyn> Hi everyone
<alwyn> Anyone have success using bzr-svn against a svn repository with authentication?  The passwords are cached by my subversion client, but no joy on both gentoo and mac os x...
 * mwhudson_ has been amusing himself this evening: http://people.ubuntu.com/~mwh/really_hacked_up_changelog_view.png 
<asabil> anyone knows if there is a way to have bzr behave in a similar way to git ? concerning branches and repositories ?
<asabil> I mean 1 folder contains many branches
<Peng> Not yet.
<Peng> Maybe in the future.
<asabil> ans is there a way to rewrite the history ?
<luks> rewrite in what way?
<igc> morning
<asabil> luks: change the commit log
<asabil> or change the committed files
<luks> uncommit + commit?
<asabil> luks: something like : http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
<asabil> luks: maybe you would want to take a look at this: http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/
<asabil> it is quite biased toward git, but still contains interesting ideas and complains about bzr
<luks> umm, I think I really don't want to :)
<luks> no, bzr doesn't have anything like git-filter-branch, but I think that's good, not bad
<asabil> luks: that's exactly his complain: the bzr devs don't want to listen:p
<luks> I'm not a bzr dev, btw
<luks> but I wouldn't listen anyway :)
<asabil> luks: and honestly git-filter-branch can be really useful
<luks> how so?
<luks> isn't VCS about keeping your history?
<luks> I can understand it's use for migrating or restructuring branches
<luks> but not to change commit message or things like you mentioned
<asabil> yes, but let me give you some use cases
<asabil> let's say I work for a company A, that uses bzr
<fullermd> There are many very good reasons to want to wipe out history   :)
<asabil> I worked for a long time on a proprietay project for them , and some day they decided it should go open source
<asabil> however, there are some files early in the history of the bzr branch, that are confidential
<asabil> I still want to pusblish the whole branch with its history
<asabil> how do I do ?
<luks> yes, that's one valid use case
<luks> but the first two you mentioned were not
<asabil> which ones ?
<luks> <asabil> luks: change the commit log
<luks> <asabil> or change the committed files
<asabil> luks: sometimes there are typos in the commit log
<luks> typo in the commit message is IMO part of the history and should stay there
<asabil> and sometimes there is a morron in your project who would put crappy commit logs
<luks> otherwise you break the branch for everybody else
<asabil> and you want to fix that
<luks> it's part of the history, don't change the history :)
<fullermd> Down, boy!  Keep your dogma on its leash!
<asabil> :)
<luks> I guess I just don't like git too much, so I'm not the right person do discuss this :)
<asabil> luks: I don't like git at all, and for good reasons
<fullermd> In a lot of cases, breaking the branch is totally acceptable.  In a lot of cases, I know exactly where every copy of the branch is, so remaking them all is a bloody inconvenience, but entirely possible.
<asabil> but many people like git, and if you really like bzr, you should listen to their critics and improve
<luks> I'm not saying filtering shouldn't be possible
<luks> but in git it' a common operation
<luks> *it's
<luks> btw, I don't like bzr either :)
<asabil> ...
<luks> but it's the only acceptable one
<asabil> I think there are many things to improve in bzr, maybe also change its name
<fullermd> "All mail clients suck.  This one just sucks less."
<asabil> many people still confuse bzr with bazaar
<Odd_Bloke> asabil: That's going to be fixed soon.
<asabil> oh really ?
<Odd_Bloke> The Debian 'bazaar' package will install both bzr and baz.
<Odd_Bloke> And eventually just bzr.
<asabil> that would be better
<Peng> Typos are one thing, but sometimes I really do want to change the commit message when it's wrong.
<johnny> version the changelogs lol
<johnny> err commit messages
<Peng> That could work.
<Odd_Bloke> johnny: The commit messages _are_ versioned, with the content of the trees.
<Peng> It would, of course, be too complicated, but would be useful.
<johnny> i mean seperately Odd_Bloke
<johnny> but i personally don't need such a thing..
<johnny> you could find a way to replay the history tho
<luks> Peng: then uncommit it and commit again
<luks> if you notice it later and the branch is already published, rewriting is IMO the wrong thing to do
<Verterok> morning
<asabil> I still think that rewriting the history and filtering a branch can be a really neat fature for bzr
<asabil> also bzr could improve its handling of Limbo files
<asabil> maybe by adopting an interactive ui like darcs
<asabil> or having an ibzr command that is fully interactive
<Peng> luks: The only time I can remember it bothering me was with a personal, non-code branch that isn't published. There had also been commits since it.
<LarstiQ> asabil: handling of Limbo files?
<asabil> LarstiQ: unknown files
<asabil> LarstiQ: you know the "Oh sh*t i forgot to add those files before committing"
<LarstiQ> asabil: ah. You confused me since limbo has a specific meaning in bzr, and I have never heard of this use before.\
<LarstiQ> jam: are you running bzr serve or somesuch?
<dato> LarstiQ: http://blogs.gnome.org/newren/2007/12/08/limbo-why-users-are-more-error-prone-with-git-than-other-vcses/, presumably
<Odd_Bloke> asabil: There's 'bzr shell', in bzrtools I think.
<jam> LarstiQ: I am now :)
<asabil> Odd_Bloke: and ?
<asabil> Odd_Bloke: ever used darcs ?
<LarstiQ> asabil: maybe you are looking for commit --strict?
<asabil> LarstiQ: rather something like darcs record
<Odd_Bloke> asabil: 'bzr shell' is similar to an interactive bzr command, but I should have read more context.
<Odd_Bloke> asabil: Didn't you write the 'record' plugin?
<asabil> Odd_Bloke: yes, the record plugin should be renamed btw into bzr make-patch
<asabil> or something like that
<Odd_Bloke> asabil: Ah, yes, I recall now.
<asabil> I wanted it to become like darcs record, but never had time to finish it
 * LarstiQ is a bit low on cycles
<Odd_Bloke> I'd have thought it would be fairly trivial to switch from creating a patch to creating a commit.
<LarstiQ> asabil: I don't know darcs well, what about record is it that you are looking for?
 * Odd_Bloke doesn't have any motivation to do it himself, because he wouldn't ever use it.
<Odd_Bloke> I'd be happy to help someone who does have some motivation though.
<asabil> LarstiQ: basically darcs is fully interactive, so when you issue a darcs record (the commit equivalent), it will prompt you about the hunks to record
<asabil> (in a similar manner to bzr shelve), then it will ask you for a record name (commit message), before finishing the record
<asabil> iirc it will also warn you about unknown files
<LarstiQ> asabil: right, which --strict will also do
<asabil> LarstiQ: --strict is interactive ?
<LarstiQ> asabil: no
<asabil> Odd_Bloke: maybe can we cook up something together ?
<asabil> Odd_Bloke: I want to make the record plugin add a --interactive command to commit
 * LarstiQ doesn't think interactivity is desirable in the general case, so if there are useful features of record that can also work non-interactive, that would be nice to factor out
<asabil> s/command/option/
<LarstiQ> or rephrased, not only the interactive users should benefit
<asabil> make the interactive users benefit until you find a way to make the non interactive users benefit as well
<LarstiQ> fair enough :)
<jelmer> dudes!
<LarstiQ> jelmer!
<jelmer> how is the sprint today?
<LarstiQ> jelmer: they just did a firealarm test
<LarstiQ> but announced it so we could just sit and not do the entire evac thing
<Odd_Bloke> asabil: There was someone in here last night who was also interested in that exact thing.
<Odd_Bloke> It was, in fact, LeoNerd (implicit ping). :)
<jelmer> LarstiQ: ah, that's nice for a change
<vila> yeah, there were nice enough when I explained why *I* prefer it to be a lighter test...
<LarstiQ> jelmer: do you have anything to say on file copies/path tokens?
<jelmer> LarstiQ: I'm not sure I entirely remember how they were supposed to work
<LarstiQ> ah :)
<Odd_Bloke> jelmer: abentley and lifeless are probably about to have a discussion regarding file copies, hence the question. :)
<spiv> Odd_Bloke: Any chance of you adding a "mirror-update" command to that plugin today? :)
<jelmer> Odd_Bloke/LarstIq: The wiki page on path tokens doesn't appear to have any actual design details, just use cases :-(
<Odd_Bloke> spiv: That's my next step. :D
<LarstiQ> jelmer: rob's comment was that pathtokens may be a implementation strategy for filecopies, but they don't need to be the way to do it.
<spiv> Odd_Bloke: I have a use-case of a sort
<jelmer> LarstiQ: makes sense
<Odd_Bloke> spiv: Cool.
<spiv> Odd_Bloke: I have just made a "bzr svn-import" of Twisted's SVN on my laptop, and when I update it (by running bzr svn-import again in the same dir), I'd like a way to update the copy of the import I've put at http://people.ubuntu.com/~andrew/twisted/
<spiv> Odd_Bloke: rsync works atm, but isn't exactly ideal...
<asabil> Odd_Bloke: let's say I have a patch, how do I commit it (working on --interactive)
<jelmer> too bad there's no video feeds
<jelmer> but at least there is the BrainStorms page
<Odd_Bloke> asabil: Well, apply it to the tree and then commit as normal, I guess.
<LarstiQ> jelmer: we could do a conference call I suppose
<asabil> oki
<Odd_Bloke> spiv: I've just pushed an initial implementation of mirror-update to mirror.dev.
<spiv> Odd_Bloke: thanks!
<jelmer> LarstiQ: it's being discussed right now?
<Odd_Bloke> jelmer: Nope, plugins ATM.
<Odd_Bloke> spiv: So I'm finding some slightly odd behaviour in that the mirror-update command is pulling the revisions and the history into the branches appropriately but 'bzr log' complains about logging the null revision.
<Odd_Bloke> 'bzr log -r1' shows the right thing, however.
<spiv> Odd_Bloke: hmm, mirroring a rich-root-pack repo doesn't work
<spiv> It creates pack-0.92 at the destination then barfs.
<jelmer> hmm, is bundle-buggy down or just being slow
<james_w> Odd_Bloke: are you using tree.pull() or branch.pull()
<Odd_Bloke> I get "bzr: ERROR: Repository KnitPackRepository('file:///var/tmp/foo/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///var/tmp/blah/.bzr/repository/')" when doing that.
<Odd_Bloke> spiv: ^
<Odd_Bloke> james_w: branch.pull()
<spiv> Odd_Bloke: right.
<james_w> Odd_Bloke: you want tree.pull() anyway.
<Odd_Bloke> jelmer: abentley was using it earlier, but I don't know about ATM.
<Odd_Bloke> james_w: How's that going to cope with branches without trees, which is probably what we want from this (as the eventual use-case is switching into the mirrored branches)?
<james_w> Odd_Bloke: well, use open_tree_or_branch() and then you know whether there is a tree there already, and then switch between tree.pull() and branch.pull()
<james_w> Odd_Bloke: and I guess you have to solve that branch.pull() problem.
<james_w> I can show you some code that does the former if you like.
<Odd_Bloke> james_w: Sure, please. :)
<Odd_Bloke> jelmer: BundleBuggy WFM ATM TLA.
<jelmer> Odd_Bloke: hmm, looks like it's just being very slow to me
<Odd_Bloke> spiv: Yeah, it'll be fun. :p
<jelmer> Peng: Do you have pqm access or should I submit the branch for "http://bundlebuggy.aaronbentley.com/request/%3C47C5D9C0.5080702@mattnordhoff.com%3E" ?
<jamesh> jelmer: the debian/watch files for bzr-email and bzr-pqm in Debian seem to be pointing at the wrong LP pages
<jamesh> according to http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org
<jelmer> jamesh: as far as I know there is no watch file for bzr-email and bzr-pqm
<jamesh> jelmer: maybe that site creates automatic watches then.  My mistake :)
<jelmer> jamesh: I wonder how though
<jelmer> since it seems to be using launchpad urls
<dato> igc: ayt?
<LarstiQ> heya dato
<dato> hey LarstiQ
<jamesh> jelmer: the home page from the package metadata
<ubotu> New bug: #199440 in bzr "Traceback if authentication.conf contains section without password " [Undecided,New] https://launchpad.net/bugs/199440
<igc> hi dato
<jelmer> jamesh: and it then makes assumptions about the releases being on launchpad as well?
<igc> dato: spoke to abentley re the best way to do fast-export ...
<dato> aha
<igc> two revision-trees and changes_from is fine
<igc> abentley also mentioned iter_changes
<igc> and had some idea down the track
<dato> I saw iter_changes, but only as a _underscore_method, so I went with public stuff
<abentley> changes_from is a bit ugly and lossy.
<igc> s/idea/ideas/
<igc> re more efficient ways
<igc> I imagine that two rev-trees + changes_from is fast enough for any projects though ...
<igc> so we ought to stick with that initially I feel
<igc> s/any/many/
<dato> abentley: lossy?
<LarstiQ> Odd_Bloke: one of the log messages of bisect we looked at mentioned working with merged revisions, what was that about then?
<ubotu> New bug: #199442 in bzr "every command twice encode sys.stdout?" [Undecided,New] https://launchpad.net/bugs/199442
<Odd_Bloke> LarstiQ: I dunno, I thought it coped with them too.
<Odd_Bloke> I may have screwed the test up. ^_^
<dato> igc: now, I have bzr-crude-export.py in a state that does everything I'd need, so I'm not sure how much more time I'd like to put into it. otoh, I'd like to release it. so, how about I drop a mail about it in bazaar@ and git@, and mention that it'll probably need a new home in the future, possibly bzr-fastimport?
<abentley> dato: There are some combinations with kind changes that aren't recorded properly by changes_from.
<dato> abentley: ok. my script doesn't look at kind_changes atm, so...
<igc> dato: I definitely want it in fastimport and I'm happy to own it
<dato> abentley: btw kind_changed seems missing in TreeDelta's __doc__
<Odd_Bloke> spiv: I'm not going to work that mirror bug out now, as I think the git-style branches discussion will have some bearing on it.
<dato> igc: ok. shall I keep calling it -crude, or would be -fast ok with you? I'll mention in __doc__ that later on it'll live in launchpad.net/bzr-fastimport
<igc> dato: fast is ok. If you send me the code or link, I'll include it real soon now
<igc> bbiab
<asabil> Odd_Bloke: ok, done I will publish my interactive commit crack
<Odd_Bloke> asabil: Cool. :)
<asabil> Odd_Bloke: any name to suggest ?
<asabil> bzr_interactive ?
<Odd_Bloke> asabil: interactive-commit, or somesuch.
<asabil> Odd_Bloke: it also contains a record-patch command
<Odd_Bloke> asabil: I dunno then.
<Odd_Bloke> It can always be changed later. :p
<asabil> abentley: what do you think about adding the record-patch command to bzrtools ?
<beuno> LarstiQ, *ahem*debconf*ahem*
<abentley> I'm not keen on making it easy for people to do partial commits.
<LeoNerd> It's already easy... bzr ci some files here
<LeoNerd> The hunk selection only extends a bit further, to do changes -within- files.. It's really no worse in principle
<LeoNerd> It just depends on the (fairly-arbitrary) way that the user has split their content across files
<abentley> LeoNerd: Different-in-degree is good enough for me.
<asabil> abentley: oO record-patch is about creating patches manageable with quilt
<LarstiQ> beuno: yes, thank you :)
<abentley> asabil: You should really look into looms, then.
<abentley> That should be a much more reliable way of generating quilt-compatible patches.
<dato> igc: ok, I CCed you. I'm sorry is a git repo, but feel free to use git-fast-export! :-P
<asabil> oh, oki didn't know aboutit
<asabil> thanks
<spiv> Odd_Bloke: makes sense
<Odd_Bloke> spiv: That's what I thought.  However, it seems like the discussion may not happen after all...
<spiv> Odd_Bloke: we'll see...
<Odd_Bloke> *ominous music*
<jml> how do I list all commands provided by a plug in?
<spiv> jml: "bzr help commands | grep PLUGIN-NAME
<beuno> jml, or use lifeless' plugin-info plugin: https://launchpad.net/bzr-plugin-info
<jml> spiv: doesn't work
<jml> <-- still not stupid
<Odd_Bloke> abentley: http://pastebin.slackadelic.com/426 is a patch that removes a couple of Python-2.5isms from your LP directory service patch.
<jml> spiv: because help wraps
<abentley> Odd_Bloke: tx
<Odd_Bloke> abentley: NP.
<spiv> jml: "grep -1 PLUGIN_NAME" ;)
<jml> spiv: wrath
<jml> spiv: and violence.
<LarstiQ> jml: :)
<jml> spiv: (it doesn't always wrap)
<VSpike> i'm using bzr to control a web application.  My hosting co only gives me access to the webspace by ftp.  Can I use bzr to push changes up to the hosting space?
<james_w> VSpike: yes. You can push over ftp.
<VSpike> i tried "bzr init ftp://user:pass@hosting.com" but I get an error "File exists: '/.bzr': 550 /. bzr: access is denied"
<james_w> VSpike: that doesn't look good.
<VSpike> I'm using bzr 1.2.0 on Windows
<james_w> VSpike: also, bzr will not create a working tree on the ftp server, so I don't think it will do what you want.
<beuno> VSpike, and also, it will have the bzr repository online, making it easy to download the source
<beuno> VSpike, we are working an a plugin to tackle the website-uploading workflow
<beuno> so keep an eye out for it  ;)
<VSpike> bueno the whole source is always in the webspace anyway, and I can specifically block access to .bzr
<VSpike> Hmm I don't think even rsync can do ftp
<VSpike> rats
<beuno> VSpike, right, well, you still have the working tree issue, which is the actualy files
<beuno> but, again, a solution to that is very close by
<beuno> just not today
<VSpike> I'm not sure i understand the working tree issue?
<beuno> VSpike, the working tree is the actual files
<hmeland> The "bzr push" will only push the repository part, i.e. stuff under ".bzr".
<beuno> so when you push, you just send the repository files, which are the ones under .bzr
<VSpike> ah right
<beuno> VSpike, so you would need ssh access on the other end to do this now
<beuno> (if you're willing to block the .bzr directory via htaccess or something)
<VSpike> Understood
<VSpike> Timestamps never seem to match either so probably the easiest/safest thing to do it use a sledgehammer and just write a script to ftp everything up
<beuno> VSpike, right, at the moment
<VSpike> okay.  thanks!
<hmeland> Any ftp mirroring tool should be able to do the job.
<beuno> (I'm personally doing php magic to do it on top of bzr, but that's not available yet either :p)
<awilkins> Is this stuff convered in the FAQ? Because it's sure as heck a FAQ in here.
<awilkins> Oh, and while we're talking about timestamps, was it a conscious design decision for timestamps in working trees not to match the timestamp of the files last revision?
<beuno> awilkins, we're aiming at solving the actual problem, so I suppose a FAQ wouldn't make any sense at the moment
<hmeland> I seem to recall there being a bug on the file-timestamp issue; don't know the status, though.
<LarstiQ> awilkins: What are they instead and what case are you thinking of?
<awilkins> I find the timestamp thing annoying because my tree compare tool is time sensitive
<awilkins> LarstiQ: The timestamps are "time of writing to disk" from the build phase
<LarstiQ> awilkins: ah right, so clean checkout you mean.
<awilkins> LarstiQ: Yup
<LarstiQ> awilkins: Doesn't sound like a desing decision, but rather a bug I think.
<awilkins> It feels like a bug to me :-)
<awilkins> ALthough AFAIR it's optional behaviour in TSVN... I'll look at the settings dialogue
<hmeland> Of course, in a distributed system, using the "commit time" for file timestamps could lead to clock skew related problems.
<awilkins> Yech, there is that
<awilkins> Ok, it's optional default to "off" in TSVN
<awilkins> But I find myself comparing local file trees a lot more with bzr because branching is much more frequent
<hmeland> Out of interest, which timestamp-sensitive tree compare tool are you using?
<awilkins> Beyond Compare 2
<LarstiQ> awilkins: any chance that could use bzrlib?
<awilkins> It has a rules-based compare as well, which gives more accurate results, but it still marks the "newer" file if they are different
<lifeless> awilkins: timestamps are not set to time of last revision deliberately
<lifeless> awilkins: /away
<awilkins> Would you be against an option to do so?
<lifeless> awilkins: without a good reason, yes. :). We do have an open bug that the times should all be identical
<awilkins> Is this because it's expensive to determine the last revision of individual files?
<awilkins> Oh, anyone who does BzrGtk here?
<hmeland> I've never used "Beyond Compare", but according to http://diablopup.blogspot.com/2007/07/product-recommendation-beyond-compare.html it would seem that it has an "ignore timestamp differences" option?
<beuno> awilkins, jelmer and phanatic
<phanatic> what did i wrong this time? :)
<beuno> phanatic, bzr-gtk, apparently  :p
<awilkins> phanatic: Nothing, I just have a suggestion to make tool shelling a bit more flexible ; I'm currently operating with a very crude custom hack so I can use my 3-way merger of choice
<awilkins> Using subprocess with a list of args isn't compatible because it uses an arg format that isn't MFC flavoured
<awilkins> I've just hacked in a custom line for the tool I'm using using a % format string, but that obviously isn't portable to anyone else
<awilkins> hmeland: Thanks for that, it's nice to learn new things about your favourite tools (even thought they are blindingly obvious)
<hmeland> awilkins: No problem, glad to help :-)
<awilkins> I just wish it did 3-way merge (have to wait for v3 to do that....)
<lifeless> awilkins: several reasons.
<lifeless> awilkins: one is that different machines have datestamp skew
<lifeless> awilkins: another is that datestamp of commit is not sufficient to ensure correctness for build systems it in fact makes things worse than what we do today)
<awilkins> Yes, I can see that too ; different platforms with different timezone behaviours too.
<lifeless> awilkins: that too
 * awilkins curses Win32 for having stupid TZ behaviour and has for many years
<awilkins> Do the dates in bzr try to be UTC internally, btw?
<luks> awilkins: they are in local time + timezone
<lifeless> Ng: want to stab loggerhead btw?
<Ng> lifeless: sure
<lifeless> awilkins: anyhow, what would settingthe datestamp for you buy you?
<Ng> lifeless: done
<awilkins> lifeless: the red "newer" highlights in my compare tool would be on the right side
<lifeless> awilkins: ah; so the tool is broken ? :>
<LarstiQ> well, if it's just a general tree compare tool, where else would it get the information from?
<lifeless> LarstiQ: newer from datestamps is inherently meangingless in the presence of diff & patch
<lifeless> awilkins: a plugin to 'reset' a tree timestamp state should be easy enough to write
<awilkins> lifeless: I thought the same myself
<awilkins> lifeless: "newer" has value if you are (e.g.) uploading content to an FTP with limited bandwidth and youre target FTP server does not support CRC
<ubotu> New bug: #103199 in bzr-gtk "diff window should not block typing in gcommit" [Medium,Fix released] https://launchpad.net/bugs/103199
<Odd_Bloke> igc: I'm pretty happy with the 'mirror' command available at https://code.edge.launchpad.net/~daniel-thewatkins/bzr-mirror/mirror.dev .  If you want to have a play around with it and give me some feedback, that'd be good. :)
<ubotu> New bug: #118461 in bzr-gtk "symlinks not handled correctly" [Low,Confirmed] https://launchpad.net/bugs/118461
<ubotu> New bug: #120524 in bzr-gtk "Fold arrow in commit dialog serves no purpose" [Low,Fix released] https://launchpad.net/bugs/120524
<ubotu> New bug: #120526 in bzr-gtk "Not possible to specify an external diff viewer to use" [Low,Confirmed] https://launchpad.net/bugs/120526
<beuno> Verterok, https://bugs.launchpad.net/bzr/+bug/86652
<ubotu> Launchpad bug 86652 in bzr "commit option to set revision properties" [Undecided,New]
<beuno> would your patch fix that?
<jelmer> Peng: ping
<jelmer> beuno: No, that only supports registering custom revision property displayers if we're talking about the same patch
<Verterok> beuno: nope, I'm working on showing the properties
<beuno> jelmer, right, but that would be a start, wouldn't it?
<Verterok> jelmer: thanks ;)
 * beuno pokes ponders asigning the bug to Verterok
 * Verterok hides, and run away :)
 * beuno stops bug triaging and goes back to coding
<Verterok> beuno: but I can put some time in adding the option, but I need someone to review my code
<ubotu> New bug: #131471 in bzr-gtk "bzr gconflicts outputs error messages when pushing green button and no files are in conflict" [Low,Fix committed] https://launchpad.net/bugs/131471
<ubotu> New bug: #199513 in olive "gcommit crashes: ERROR: dbus.exceptions.DBusException" [Undecided,New] https://launchpad.net/bugs/199513
<beuno> Verterok, right, just kidding (not really)
<jelmer> beuno: I actually think #86652 would be a bad idea
<jelmer> beuno: I've just commented
<Verterok> ok
<ubotu> New bug: #147011 in bzr-gtk "[viz] date format is too verbose" [Wishlist,Fix released] https://launchpad.net/bugs/147011
<fredreichbier> hello
<phanatic> squashing bugs is fun
<fredreichbier> i have a problem: i and another developer use launchpad+bazaar for the code. now he did some changes and pushed them as revision 11. i did some changes, too, and so i committed by own changes in my own branch and then merged his and my changes together. but after pushing it to launchpad, his revision disappears and is replaced by my revision. what's wrong? :)
<LarstiQ> fredreichbier: It didn't disappear but is merged in, have a lookg at bzr log, it should show his commit indented
<fredreichbier> right, but it disappeared in launchpad
<beuno> fredreichbier, well, launchpad doesn't show sub-revisions
<beuno> you will probably see it with "code browse"
<beuno> jml, ^   :p
<fredreichbier> ah
<fredreichbier> ah yes in 'browse code' it's visible. thank you :)
<beuno> fredreichbier, welcome
<beuno> jam, https://code.launchpad.net/landscape  == no code. I'm I looking in the wrong place?
<ubotu> New bug: #199527 in bzr-gtk "viz tracebacks when refreshing on an uncommitted and recommitted branch" [Undecided,New] https://launchpad.net/bugs/199527
<tro> how would i uninstall bzr 1.2 if i installed it from source (ie. python setup.py install) into the default directory?
<Verterok> tro: in what OS?
<tro> linux
<Verterok> tro: as root?
<tro> i have bzrlib in /usr/lib/python.2.5/site-packages
<tro> ya
<Verterok> rm bzrlib, and the bzr executable
<Verterok> that's all
<tro> o ok. thanks
<phanatic> tro: manually remove the bzrlib directory there + bzr executable + bzr manpage -- that's pretty much all i guess
<beuno> Odd_Bloke, would you take a look at: https://bugs.edge.launchpad.net/bzr/+bug/190512
<Verterok> phanatic: thanks
<ubotu> New bug: #199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New] https://launchpad.net/bugs/199539
<ubotu> Launchpad bug 190512 in bzr ""bzr: ERROR: No such file" on bzr push" [Undecided,New]
<beuno> it might be realted to the bug you just posted
<tro> man, you'd think setup.py would be able to record where it installed the files and have an "uninstall" command or something
<Odd_Bloke> tro: That's what your package manager is for. :)
<tro> Odd_Bloke: yeah, i guess. i wonder if checkinstall can handle setup.py installations
<fredreichbier> tro: as far i know it can
<awilkins> Anyone know if the capability for symlink on Vista (NTFS 6) has shown up in CPython?
<Odd_Bloke> Verterok: beuno: ISTR https://bugs.edge.launchpad.net/bzr/+bug/199539 being something to do with xmloutput.  Am I just inventing that?
<ubotu> Launchpad bug 199539 in bzr "plugins command crashes complaining about "verbose"" [Undecided,New]
<beuno> Odd_Bloke, I'd like to go for the "inventing" bit, but I can change my mind if you point me to what makes you think that
<Verterok> Odd_Bloke: thanks, the xmloutput it's fixed, maybe it's a old version?
 * awilkins discovers that symlinks for Vista have not shown up yet
<batoms> i had asked this a while back but is it possible with bazaar to branch from one remote tree to another remote tree without going through the local machine
<batoms> e.g. can i branch from a launchpad tree to another launchpad tree without first downloading the first tree and reuploading it
<awilkins> batoms: You could probably do it if you had ssh access to the target machine, but otherwise, no
<awilkins> How does run the tests from inside a python console?
 * awilkins is testing IronPython to see how lacking it is to run BZR
<LarstiQ> awilkins: os.system('./bzr selftest')? ;)
<LarstiQ> awilkins: I think we looked at IronPython yesterday and got a bit scared at the differences.
<awilkins> Heh, I don't think the win32 "os" has system
<LarstiQ> awilkins: you should be able to do the same thing as cmd_selftest from bzrlib/builtins to kick off the testsuite.
<LarstiQ> awilkins: I'm rather sure it does.
<awilkins> I tried import bzrlib
<awilkins> then bzrlib.test_suite()
<awilkins> Ran into an error :-
<awilkins> Ah, I need to chdir to where bzr is
<awilkins> LarstiQ: Maybe the IPY implementation of "os" has no .system() call.
<LarstiQ> awilkins: from bzrlib.tests import selftest; selftest()
<LarstiQ> awilkins: hmm, could be
<awilkins> No module named fcntl
<LarstiQ> http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Differences&referringTitle=Home iir
<LarstiQ> awilkins: oh bother
<LarstiQ> awilkins: you have some work cut out for you
<awilkins> I'm testing with IP 2.08 A which is a bit closer
<awilkins> It's mostly idle interest and the promise of 1.8x performance (which is probably not true beacuse the performance critical stuff should be C)
 * LarstiQ wasn't aware there was a 2.x line?
 * awilkins didn't bother with the 1.1 line
<awilkins> One problem is that it completly foobars most of your platform capability detection by reporting that sys.platform == 'cli'
<awilkins> Most of your code uses osutils which could be patched, but most of the tests directly check sys.platform
<awilkins> And of course, sys.platform is still 'cli' even when you run IPY on Mono/Linux
 * awilkins has a bzr.iron branch with comments on each platform check.
<LeoNerd> http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html   <== Quite favourable to bzr, I think :)
<awilkins> Heh, that's the third time I've seen that here today
<awilkins> Heh, this first error is a problem with the CPython platform detection ; subprocess thinks it's running on something posix
<awilkins> Where's the msvcrt module? Builtin?
<fredreichbier> msvcrt is a builtin module
 * awilkins has now discovered this
<awilkins> Darn
<lifeless> tchau, see you on the flipside
<batoms> could anyone ssh to launchpad for me and branch a tree for me
<batoms> my connection is too slow
<batoms> i've been waiting on a branch for hours
<phanatic> beuno: http://www.ubuntu.com/news/landscape
<beuno> phanatic, yeah, but jam mentioned the client was open source
<phanatic> beuno: it seem it's "just free"
<phanatic> for my fellow "beer hackers": http://xkcd.com/323/
<LarstiQ> Odd_Bloke: http://thedailywtf.com/Articles/SQL-Sentences.aspx
<Odd_Bloke> LarstiQ: A true WTF.
<Vantage> hi all, is bzr cvsps import working with bzr 1.1/1.2?
<Vantage> i know it worked with 0.18 and broke with 0.96.  I'm just wondering what the current status is
 * LarstiQ doesn't know, but it should obviously
<Stavros1> hello
<Stavros1> i would like a setup where i review changes made by people before committing to the master repo, how would i do that with bzr?
<LarstiQ> Stavros1: you can do that in a multiple of ways. bzr.dev development does that with a combination of pqm and bundlebuggy
<Stavros1> hmm, i don't know what any of those are
<LarstiQ> :)
<LarstiQ> Stavros1: bzr.dev can only be committed to by pqm, which is a bot that you send a merge requested, it merges your branch when it gets to it in it's queue and  enforces policy (in our case, it runs the testsuite)
<LarstiQ> Stavros1: if it succeeds, it commits, otherwise, it rejects the merge
<Stavros1> oh hey, that's great
<Stavros1> does it notify you as well?
<LarstiQ> Stavros1: bundlebuggy is a tool to help the review process, you send bundles to a mailing list, and it tracks if it's merged or not
<LarstiQ> Stavros1: yes
<Stavros1> awesome
<LarstiQ> Stavros1: see http://bundlebuggy.aaronbentley.com/
<Stavros1> hmm i just looked at that, but i don't know how i can roll stuff back if it doesn't pass the code review
<Stavros1> (or something equivalent)
<LarstiQ> Stavros1: roll stuff back?
<Stavros1> roll the commit back, if it shouldn't be in the repo
<Stavros1> i want to sort of check the commits to see if they should be committed to the main repo
<Stavros1> like pqm, only manual
<LarstiQ> Stavros1: that would be a classical gatekeeper workflow methinks
<Stavros1> ah, i saw some info on that but i couldn't find the page now
<Stavros1> oh found it, workflows
<Stavros1> yes, that's it
<Stavros1> i don't want to set up an entire system for that though, it's going to be just me and someone else at first
<Stavros1> so what can i do? create a branch and always have them push there?
<Stavros1> and rebranch if i don't want to include the commit?
<LarstiQ> Stavros1: well, they can publish their own branch, and you then merge from it, review, accept/reject by committing or reverting
<LarstiQ> Stavros1: or, get the other person to use `bzr send`
<Stavros1> bzr send sounds nice
<Stavros1> it sends me mail and then what do i do?
<LarstiQ> Stavros1: you can read the diff and see if you want to have it, then bzr merge it
<Vantage> how do you guys deal with having large quantities of binary files that are versioned (e.g. images and flash files for a website) along with your code.  These would make branches fairly large.  Is there a way to have make having multiple branches on a machine a little less disk space expensive?
<LarstiQ> Stavros1: or merge it and then do some checks, you have options :)
<LarstiQ> Vantage: yes
<weigon> can you see in a bzr push which revno I got on the remote-tree ?
<LarstiQ> Vantage: you can use a shared repository to share revisions between branches
<LarstiQ> Vantage: and if it's about working trees, see link-tree from bzrtools
<Vantage> LarstiQ:  and just use bzr switch to switch between them?
<LarstiQ> Vantage: that's an option, yes
<Vantage> LarstiQ: that was the one I thought of. Any other options?  I'm googling link-tree right now...
<LarstiQ> Vantage: I don't know right now
 * LarstiQ gets back to hacking for a while
<Vantage> LarstiQ: ok, thanks.  When you said "an option" I thought you meant you knew of others :)
<jelmer> Odd_Bloke: What exactly does "owner" on the brainstorm page mean?
<Odd_Bloke> jelmer: Person in charge of making it happen, I guess.
<Odd_Bloke> igc added it.
<jelmer> ah, ok
<LarstiQ> jelmer: xp style terminology I think
<Stavros1> i have a server running linux, what are my options for a read-only bzr repo?
<Odd_Bloke> Stavros1: HTTP. :)
<Stavros1> Odd_Bloke: oh, with apache? does it also support auth?
<jelmer> Odd_Bloke: and contributors? The people who contributed to the discussion @ the sprint or the people interested in contributing?
<Odd_Bloke> Stavros1: I'm not sure about auth, I'm afraid.
<Stavros1> does it use apache?
<Odd_Bloke> jelmer: People who are anticipated to help out in the implementation (I guess).
<Vantage> couldn't you just set permissions on the tree and use ssh?
<Odd_Bloke> Stavros1: Posting to the ML or asking a question is probably the best thing to do, most of the Bazaar guys are heading to the pub right now (end of sprint :D).
<james_w> jelmer: I think the "owner" is the person that you should talk to if you are interested in the feature. Contributors are those that are interested in it.
<Stavros1> Odd_Bloke: ah :p
<james_w> Though the owner are the ones that are probably going to drive it if it is going to happen.
<Stavros1> Vantage: i probably could... i don't want to give people access to the machine, though
<Vantage> Stavros1: you could put that copy on a separate machine (or virtual machine) and just push to it when you do releases
<Stavros1> ah, i don't have another machine (even virtual) to spare...
<Vantage> Stavros1: well they'll have to access somewhere ;)
<Stavros1> they can access the server, just not all of it :P
<Stavros1> i wonder if i can chroot it
<Vantage> Stavros1: I remember something called scponly which might work
<Stavros1> aha, i'll check it out, thanks
<igc> jelmer: owner means "I'll guide/monitor this"
<Vantage> Stavros1: you can also do lighter virtual servers with linux-vserver or openvz I believe.  They don't do hardware vm
<jelmer> Odd_Bloke, james_w, igc: Thanks!
<igc> jelmer: Contributor means "I'll  do the work if the owner doesn't" :-)
<Stavros1> Vantage: well the apache solution sounds nice, do you have any info on that?
<beuno> jelmer, so being the owner is where you want to be
<Stavros1> or actually i can just use ftp on another branch, i guess
<LarstiQ> beuno: unless you have zero contributors.
<igc> s/if/IF/
<beuno> LarstiQ, that just means you have to blog a lot
<Vantage> Stavros1: well apache is just putting it up on a publically accessible webserver, not sure about authentication support for bzr with that though, probably...
<Stavros1> Vantage: oh duh, you're right :/
<Stavros1> bzr has http access...
<Vantage> Stavros1: yup :)
<Stavros1> so i can just point apache to the repo
<Stavros1> well that's simple enough
<Stavros1> actually i have trac with the bzr plugin, does that expose the functionality?
<Stavros1> i mean the repo
<Vantage> Stavros1: they can browse it, but I don't think they can branch from it (but I could be wrong)
<Stavros1> hmm, i was wondering if it has a url that points to the bare directory
<zepard> hi
<Vantage> Stavros1: it might.  Shouldn't be hard to set one up if it doesn't though
<LarstiQ> jelmer: oi, you added me to Line Endings ;P
<jelmer> LarstiQ: Yeah, I initially assumed this was about who contributed to the actual discussion
<jelmer> LarstiQ: You shouldn't be there any more now
<Stavros1> Vantage: indeed, i'm doing it as we speak
<Stavros1> it would just be nicer if it had one
<Stavros1> i'll open a ticket
<igc> night all
<james_w> fooooooood!
<beuno> food+1
<LarstiQ> fair enough
<phanatic> food++
<Odd_Bloke> http://icanhascheezburger.files.wordpress.com/2008/01/funny-pictures-pandas-eating-noms.jpg
<Stavros1> it works! thanks for your help
<Stavros1> auth works too, since it's a normal directory
<dato> oh, no james_w
<abentley> dato: They were off to the pub last I heard.
<dato> ok, thanks
<blueyed> Can you query the last "push" to a repo (or "commit" for a checkout)? Is this "latest revision" in "bzr info -v"?
<bpeterson> blueyed: yes
<blueyed> well.. unfortunately "bzr info" is probably slower than "bzr commit". is there a shorter path for getting this info?
<dato> blueyed: sorry, I did not understad your problem very well?
<dato> maybe you want `bzr log -r -1 | grep timestamp` ?
<dato> gotta go now
<blueyed> dato: I'm thinking about optimizing the add-5-a-day tool: only commit if the last commit is older than 1h.
<blueyed> yes.. makes sense and is faster.
<bpeterson> blueyed: I'd try bzr log
<awilkins> blueyed: how about bzr revision-info
<awilkins> blueyed: forget it, that doesn't have the TZ offset in the time
<awilkins> But it is UTC though....
<blueyed> awilkins: it's quite some faster.. There is probably something better even in bzrlib though, which does not require using the email module to parse the output of a subprocess.. ;)
<awilkins> Email module? Just take the split between the first and second "-"
<awilkins> Or a regexp of 14 digits beginning with "20"
<blueyed> awilkins: yes, from rev-info, but not from log.. a subprocess it bad though, isn't it - if I'm already in python.. can't I use bzrlib for this?
<awilkins> blueyed: Yes, of course you can
<ubotu> New bug: #199654 in baltix "bzr on fat32/ntfs from ubuntu  works only with sudo init/commit" [Undecided,New] https://launchpad.net/bugs/199654
<ubotu> New bug: #199655 in bzr "bzr status shows pending merges with incorrect indentation" [Undecided,New] https://launchpad.net/bugs/199655
<ubotu> New bug: #199659 in bzr "editor backup file left over after bzr commit" [Undecided,New] https://launchpad.net/bugs/199659
<blueyed> awilkins: any hints where to look in bzrlib?
<awilkins> branch.py is where I'm looking
<awilkins> from bzrlib import branch ; b = branch.Branch.open(branchRoot) ; b.last_revision_info() ; # that seems to work
<awilkins> Doesn't work for alternative revid formats like bzr-svn though
<jelmer> There is no guarantee that standard revids follow that format either
<awilkins> How do you make a python object tell you what members it contains?
<awilkins> I can't be arse to pick through all the source looking for what revision_history() emits
<Odd_Bloke> Evening all.
<blueyed> awilkins: I use ipython and tab for that..
<blueyed> ipython is really awesome wrt to tab-completion.. in fact it's also a shell replacement I've heard.. ;)
<awilkins> bah, theyre just strngs anyway
<blueyed> awilkins: yes, b.last_revision() seems to be the closest so far..
<awilkins> blueyed: But you can't rely on the format and it's just a string
<jelmer> b = Branch.open("foo")
<jelmer> b.repository.get_revision(b.last_revision())
<Odd_Bloke> jelmer: o/
<jelmer> that last line will return a revision object which contains the commit timestamp among other things
<jelmer> hey Daniel
 * awilkins discovers __dict__
<blueyed> jelmer: thanks, r.timestamp is it..
<Odd_Bloke> jelmer: LarstiQ, Verterok, beuno, phanatic and I are sitting in the bar at the hotel with our laptops out. \o/
<jelmer> Odd_Bloke: Which is why you're currently talking with me on IRC ? ;-)
<beuno> Odd_Bloke, with girls, of course (?)
<jelmer> *without laptop* >-)
<jelmer> ah
<jelmer> out as in you have them in front of you
<jelmer> not as in you have them turned off
<jelmer> well, I'm getting some sleep
<jelmer> slept a total of 8 hours in total in the last two days and not much during the sprint either
<jelmer> Say hi to the other folks over there for me!
<beuno> jelmer, how was your exam?
<jelmer> beuno: It went ok, but not brilliant.
<jelmer> with a bit of luck, I'll pass it
<beuno> jelmer, well, bzr-gtk got better, so that might help for your conscious
<jelmer> :-)
<james_w> hi jelmer. Sorry I missed you at the sprint.
<james_w> Sleep well.
#bzr 2008-03-08
<Odd_Bloke> jelmer: Night!
<awilkins> ipython is certainly... pretty
<blueyed> well.. revision-info isn't really the last commit though..
<blueyed> but that's ok as in "branch not updated (from both sides) in the last x minutes"
<Peng> jelmer: I don't have PQM access.
 * Verterok heading to bed
<ubotu> New bug: #199712 in bzr-stats "stats plugin crashes" [Undecided,New] https://launchpad.net/bugs/199712
<justjeff> Good morning / afternoon / evening, all. I'm seeking a little wisdom.
<justjeff> Specifically if I were to write a GUI front-end to Bazaar in C++, would be a great benefit to using Bazaar's Python API (through, e.g., Boost.Python), or would it be perfectly reasonable to interact with Bazaar repositories / working trees solely through the bzr tool?
<justjeff> (Most GUI front-ends or IDE plugins for CVS, SVN, etc. do the latter, no?)
<jdong>  yes, IMO you should be using the API for serious programs
<jdong> the API has much more stability, command line output is subject to UI change
<justjeff> Do you know of any other programs written in C++ doing so, and if so, what path they have taken? (That is, whether they're using Boost.Python to link into Bazaar, or some other method.)
<justjeff> Or is somebody maintaining a C++ API already?
<justjeff> (Back in about 30, have to get lunch.)
<scode> Is there any support for authentication/authorization with read/write 'bzr serve':s? I didn't find this mentioned in the docs, but perhaps I am missing it.
<james_w> scode: no, I don't think so.
<scode> Thanks!
<asabil> scode: use bzr+ssh:// if you want auth
<scode> asabil: Yeah, was hoping to avoid ssh though (to minimize need for integration with the host system)
<lifeless> jdong: for ide's, we're now recomending xmloutput
<Odd_Bloke> Morning.
<lifeless> hi
<lifeless> I'm about to go offline till back in au
<Odd_Bloke> lifeless: Have a good trip! :)
<lifeless> thanks
<lifeless> you too :>
<asabil> is there any way to install bzr-svn with bzr 1.2 ?
<jelmer> not yet
<asabil> oki
<beuno> hey lifeless, I think most of us are. Thanks for everything  :D
<Odd_Bloke> jelmer: Is there a plan for the next release yet?
<jelmer> I was hoping to do it during the sprint but was distracted by other things
<beuno> jelmer, we just need the deactivate thing in nautilus, right?
<jelmer> beuno: yep
<beuno> (I've been looking into it, but haven't gone as far as a patch yet)
<Odd_Bloke> beuno: Stop distracting him! :p
 * beuno can't understand why his suitcase won't close if there are _less_ things than when he got here
<dato> beuno: things ate a bit too much?
<beuno> dato, :p     english food seems to be fattening
<ubotu> New bug: #199801 in olive "Olive translations are not being used" [Undecided,New] https://launchpad.net/bugs/199801
<bialix> hi
<james_w> hi bialix. How are you?
<bialix> hi kames_w
<bialix> sorry, james_w
<bialix> looking for some one who help me write README for check eol pre-commit
<james_w> bialix: I can probably do that.
<bialix> I think this document need to describe format of .checkeol file
<bialix> now it sectioned
<bialix> and I hope it's valuable improvements
<bialix> here is my branch: https://code.launchpad.net/~bialix/+junk/checkeol
<bialix> I'm again starting to get English courses, so I hope to improve my skill during this year
<bialix> james_w: btw IPython project leaning to switch to launchpad and bzr
<bialix> I read yesterday in their ML discussion about bzr vs hg
<james_w> bialix: that would be cool.
<bialix> it seems like launchpad is killer feature for them
<bialix> Ville Vanio who made request for check eol hook is winows maintainer of ipython
<bialix> s/winows/windows/
<bialix> ipython guys have unresolved question about migrating their Trac tickets base
<james_w> they should contact someone from the launchpad team, I assume there is a way for them to do it.
<james_w> unfortunately I don't know who.
<bialix> it seems like their already do
<bialix> at least vcs-import mirrors their svn main branch
<bialix> https://code.launchpad.net/~bialix/+junk/checkeol
<bialix> sorry
<bialix> https://launchpad.net/ipython
<jelmer> jamesh is the person to talk to about migration of bugs to launchpad
<bialix> hi jelmer
<bialix> jelmer: what it means 'bzr-svn on Windows needs to rock' from brainstrom wiki page?
<jelmer> Hi Alexander
<jelmer> bialix: Not sure, I don't think I was there when they had that discussion
<bialix> ok.
<jelmer> afaik bzr-svn on windows works as long as you're willing to install .exe's from various locations
<jelmer> but that's nothing new on Windows afaik
<bialix> yep
<bialix> james_w: I wrote some text or README. Could you look at it?
<james_w> bialix: it looks good to me.
<bialix> good :-) thanks
<neh> hi all... I've got a bound repo that I had forgotten about, so I went and moved the remote repo. I have changes in my working tree, and need to switch to the new location of the remote repo. What's the best way? I'm thinking I should do commit --local on my changes, then do a bzr switch, then commit normally. Should that work?
<awilkins> Add a --remember to your next pull/merge
<Odd_Bloke> Evening.
<neh> Ah, that will set the bound location as well? So, can I just pull --remember from the new location without losing my new changes?
<awilkins> Maybe unbind / bind?
<neh> I was just thinking that might be simplest...
<neh> thanks, awilkins
<nexus10> hi - I'm getting myself tangled up with permission/owner/group problems on an sftp repo -- can anyone suggest some best practices?
<nexus10> I set the repo up to be g+w on everything -- and I have a cron script that commits to this repo as user cronbot group cronbot, these being the user and group who own all files in the repo
<Odd_Bloke> nexus10: The Bazaar sprint has just finished, so the majority of the bzr development team and community are heading home or sleeping (or both) ATM.
<Odd_Bloke> You'd probably be best off either waiting until Monday, or sending an email to the Bazaar mailing list. :)
<nexus10> Odd_Bloke: great, thanks -- I'll direct this to mail then
<ubotu> New bug: #199935 in bzr-dbus "bzr-dbus doesn't give its hooks names" [Undecided,New] https://launchpad.net/bugs/199935
<jelmer> that reminds me
<jelmer> any debian developers around that could sponsor an upload of bzr-dbus?
<awilkins> jelmer: 0.4 r 945 isnt' comatible with 1.2 anymore because of the "hardlink" parameter
<jankeesvwoezik> Hi Guys, Can I ask a question thats been asked a million times before?
<Odd_Bloke> jankeesvwoezik: Don't ask to ask. :)
<jankeesvwoezik> is there a Gui for Bazaar for Mac?
<jankeesvwoezik> I searched but i didn't find any
<jankeesvwoezik> only windows and linux
<jankeesvwoezik> right?
<Odd_Bloke> jankeesvwoezik: The main GUI project is bzr-gtk, which I know can work on Mac (though doesn't look native).
<awilkins> Does the gtk stuff work on mac?
 * jdong grumbles
<jdong> a combination of merging and rebasing ruined a bzr-svn mirror
<Odd_Bloke> awilkins: Well, phanatic uses a Mac, so I expect so. :p
<jankeesvwoezik> Odd_Bloke: Can you give me a clue how to get it runing
<jdong> more conflicts than a Ballmer-Theo De Raadt meeting.
<Odd_Bloke> jankeesvwoezik: I'm afraid I really have no idea how to go about it.
<Odd_Bloke> jelmer might have a better idea. (IMPLICIT PING)
<Odd_Bloke> jdong: Rebasing has that effect. :(
<awilkins> Freebasing?
<awilkins> :-P
<jdong> Odd_Bloke: aye, but when tracking and pushing back to svn I got to a point where I had to use rebase to push it back into svn
<jdong> Odd_Bloke: I wish bzr-svn had a "git svn dcommit" type feature to prevent that
<jdong> (implicit ping :D)
<jdong> (implicit Launchpad bug)
<jelmer> awilkins: the 0.4 branch is meant to be used with bzr.dev
<jelmer> awilkins: the 0.4.8 branch is meant to be compatible with 1.2
<awilkins> jelmer: Ah
<jankeesvwoezik> doesn't anyone uses a mac over here :)
<jankeesvwoezik> thats funny
<jelmer> jankeesvwoezik: there are a couple of people that do
<jankeesvwoezik> ok
<jelmer> jankeesvwoezik: but afaik most use bzr-gtk on the mac
<Odd_Bloke> jdong: Could you describe what dcommit does for me?  Hard though it may be to believe, the git docs aren't helping me out.
<jankeesvwoezik> but not to many
<jelmer> jdong: ruined in what sense?
<jdong> jelmer: well I rebased 3 times successfully, then I believe I did a merge afterwards and attempted to rebase again...
<Odd_Bloke> jdong: NM, jelmer is vastly more qualified to talk about bzr-svn than I am. :)
<jelmer> jdong: rebase rewrites your history so it has to be used with care
<jdong> jelmer: and rebase seemed to try to start at the beginning of history
<jdong> jelmer: and every step seemed to result in error
<jdong> conflict that is
<jdong> with it pulling what seemed to be arbitrary revisions of my code in history
<jdong> jelmer: I'm quite sure it was user error on my part
<jelmer> jdong: what does git svn dcommit do?
<jankeesvwoezik> how do you run gtk on mac? Does anyone know?
<jdong> jelmer: I believe it commits to svn by diffing each "missing" commit and pushing that commit into Subversion
<jdong> jelmer: so all the commits get into Subversion but not the ancestry of merges
<jelmer> jdong: that still won't work if you have used rebase
<jelmer> jdong: also, it breaks roundtripping
<jdong> jelmer: well.. I used rebase because bzr-svn suggested that I use rebase
<jelmer> jdong: Where does it suggest that?
<jdong> jelmer: it refused to push into svn after a few merge cycles
<jelmer> jdong: that's incorrect
<jdong> jelmer: it said something along the lines of needing to rewrite revision history
<Odd_Bloke> So does it essentially rebase the missing revisions on top of trunk?
<jdong> and that I needed to either rebase or push into a non-repository-root
<Odd_Bloke> Where 'it' == 'dcommit'.
<jdong> Odd_Bloke: yeah pretty much
<jelmer> jdong: ah, you're not using branches in Subversion?
<jdong> jelmer: correct
<jelmer> jdong: I wouldn't object to supporting something like dcommit but keep in mind that you could then only push into subversion, never pull from it (you'd get a Branches diverged error)
<jdong> jelmer: hmm, well I have no reason for wanting dcommit except for the circumstance I arrived in. Do you have a better suggestion for how I could've avoided my initial error in the first place?
<jelmer> jdong: Actually, suggesting rebase is correct
<jelmer> jdong: Don't use merge
<jdong> jelmer: ok so I should use rebase instead of merge for all workflow?
<jelmer> jdong: yes - or use branches in your subversion repository
<jdong> jelmer: ok, gotcha
<jdong> jelmer: does the rebase help information forewarn my disaster?
<awilkins> cd svn
<awilkins> oos
<jelmer> jdong: maybe it should have a warning about not being a good idea in general to use rebase
<jdong> jelmer: :)
<nexus10>  I was just about to start using bzr-svn to allow topic branching, disconnected commits etc for a primary repo that needs to stay as svn -- ant pointers re rebase /merge etc? What else should I read?
<nexus10> s/ant/any/
<Odd_Bloke> nexus10: If you only want a single commit in the SVN repository for each of the feature/topic branches (and are happy for them not to be stored in SVN while under development) you shouldn't need to worry about merge/rebase.
<Odd_Bloke> You'll use merge, but you won't need to worry. :p
<nexus10> Odd_Bloke: and if I'd like to keep the commit messages for each bzr commit, and shove them all into svn, then what's the best plan?
<Odd_Bloke> nexus10: Rebasing onto SVN trunk, I believe, but IANA bzr-svn user so am probably not the best person to let you know.
<nexus10> Odd_Bloke: ok, thanks
<distatica> hey folks, I'm trying to remember here, there's a way to do something similar to trac + subversion, with bzr, but it's not the trac bzr plugin..
<distatica> loggerhead, there we go
<Odd_Bloke> jelmer: My concern with hiding hooks under the covers is that they can be used to do quite a lot of stuff which the user might object to.  At least being able to see that _something_ other than bzrlib is doing stuff when $ACTION is performed could be valuable.
<jelmer> Odd_Bloke: At the very least, the command should be hidden imo.
<jelmer> Odd_Bloke: Except for user-specific hooks, I think hooks are an implementation detail
<awilkins> jelmer: 0.4.8 test log from win32
<awilkins> http://filebin.ca/rctjoz/test.939.zip
<Odd_Bloke> jelmer: Well, currently, the only hook I have is being provided by a plugin (bzr-dbus, in this case), so all hooks are, to an extent, user-specific.
<jelmer> Odd_Bloke: It could be useful to know that commit notifications by email are enabled but the fact that there is a Python "set_rh" hook registered by the "email" plugin is not all that interesting
<jelmer> Odd_Bloke: With user-specific I mean site-specific hooks, such as the shell hooks
<Odd_Bloke> jelmer: Sure.
<Odd_Bloke> jelmer: So are you saying that this command in its current form should be hidden, or that any command which describes what hooks happen on particular actions should be hidden?
<jelmer> Odd_Bloke: The command in its current form should at the very least be hidden imho
<Odd_Bloke> OK, I accept that.
<jelmer> Odd_Bloke: But I'd prefer to have "bzr commit" be more vocal about what hooks it's running
<jelmer> Odd_Bloke: I guess to word it a bit better, I think this is internal data that shouldn't be exposed to the user like that but I think it's perfectly fine to have a hidden command to aid developers.
<Odd_Bloke> jelmer: Sure.
<Odd_Bloke> Thanks for the review. :)
#bzr 2008-03-09
<Odd_Bloke> beuno: Would a fix for https://bugs.edge.launchpad.net/bzr/+bug/116377 fit in with your plugin work?
<ubotu> Launchpad bug 116377 in bzr-gtk "Output spam when a plugin is out of date" [Undecided,Fix released]
<exarkun> What's this?  bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eexarkun/pyopenssl/trunk/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<Odd_Bloke> exarkun: Hi. :)  That probably means you've done a checkout of a branch over HTTP, and have tried to perform an operation that requires write-access to the remote branch.
<nekohayo> hello folks, does anyone have links/documentation/tutorials on how to do backporting fixes, and how to do cherry-picking?
<Odd_Bloke> You _probably_ didn't mean to do a checkout, but instead a branch.  Doing a 'bzr unbind' will remove the binding between your local branch and the remote one.
<beuno> Odd_Bloke: I'm not sure what kind of fix that would be. It just seemed bzr-gtk doing the wrong thing to me
<jelmer> Odd_Bloke,beuno: That bug has already been fixed, btw
<Odd_Bloke> jelmer, beuno: Sure, I'm talking about the bzr side of things that is discussed in the bug.
<Odd_Bloke> And there's talk of plugin metadata &c. so a little lightbulb went off. :p
<beuno> Odd_Bloke: right, there might be something to do there, yes
<beuno> I'll asign it to me
<beuno> thanks  :D
<beuno> oooooor
<beuno> wel
<beuno> well, lifeless already has it, and it's incomplete
<beuno> but I'll take it into account
<beuno> I
<beuno> argh
<beuno> I'm off to bed
<Odd_Bloke> nekohayo: To perform a cherrypick, use 'bzr merge -rx..y <branch>'.  Just be aware that bzr's cherry-picking support isn't fantastic. :)
<Odd_Bloke> nekohayo: As for backporting fixes, ISTR some discussion of it a while ago.  Let me have a think/poke around for something.
<nekohayo> Odd_Bloke: whaddya mean by "not fantastic"? (note: I'm a VCS newbie. I came from SVN, I did not even know what a branch/merge was all 'bout)
<jelmer> awilkins: thanks
<Odd_Bloke> nekohayo: Basically, we don't keep track of as much metadata as we eventually will.
<Odd_Bloke> But, TBH, I don't really know what the practical effects of that are ATM.
<jelmer> nekohayo: bzr's support is as worse as svn's at the moment
<jelmer> s/worse/bad/
<Odd_Bloke> nekohayo: So, I can't really find the stuff I was referring to before.  You might be best off firing a mail to the mailing list asking for advice. :)
<Odd_Bloke> jelmer: I tried to subscribe to the bzr-gtk list during the sprint and haven't received any sort of confirmation.  Any ideas what might be going on with that?
<Odd_Bloke> Where confirmation also includes list emails. :p
<jelmer> Odd_Bloke: I didn't see any confirmation note so you're definitely not on the list yet
<jelmer> Odd_Bloke: The list is all canonical-hosted though, so there's not much more I can tell you
<jelmer> Odd_Bloke: Have you tried subscribing again
<Odd_Bloke> jelmer: I was about to. :)
<Odd_Bloke> I have just done so, in fact. :p
<piedoggie> got a Q about merges
<piedoggie> had a conflict and now have files ending in BASE, OTHER, THIS
<Odd_Bloke> piedoggie: That's not a question so much as it is a statement. :)
<piedoggie> :-)  distracted by torchwood
<piedoggie> need pointer on what these files are and how to resolve conflicts
<Odd_Bloke> piedoggie: Well, when bzr merges, it uses three files: the file from the base revision (the revision that the two versions of the file both descend from), the file from the other branch being merged, and the file from the branch in which the merge is being performed.
<piedoggie> right
<Odd_Bloke> So each one of those files is one of those versions.
<Odd_Bloke> However, if you edit the file itself (i.e. if you have foo.BASE and friends, foo) you should see some conflict markers which show you where the conflict was.
<Odd_Bloke> The conflict markers will be a lot of '<'s, '='s or '>'s (one line of each per conflict).
<piedoggie> k  (btw, bzr is one a very few pieces of sw that does not make me swear violently on a regular basis)
<piedoggie> so just edit foo and use the other for reference?  then use 'bzr resolved foo' to clena up?
<Odd_Bloke> piedoggie: Yeah, that's basically it.
<RAOF> piedoggie: Or even just "bzr resolve".  It should be smart enough to notice that you've resolved the conflicts.
<piedoggie> cool.  simple and works
<nekohayo> I had that question in mind for a long time, too.
<nekohayo> just about figured out a few days/weeks ago.
<nekohayo> having 3 files for this is a tad confusing to me, oh well, once I figured out how to do it with Meld...
<mwhudson__> this is a bit strange: http://paste.ubuntu-nl.org/58952/
<dereine> i work local with files, then i want to push it to a sftp:// site, but the 2 directorys are not the same, is this normal?
<hmeland> In what way are the directories "not the same"?  "bzr push" will only update stuff under $target_dir/.bzr/, i.e. it will not update the working tree files.
<hmeland> If you need to update the working tree files, you will typically need shell access on the destination site.
<hmeland> I've heard rumours that a plugin that extends "bzr push"'s functionality to also update the working tree files is in the works.
<asabil> hmeland: push-and-update is the name of the plugin
<hmeland> The plugin I heard rumours of sounded like it wouldn't need shell access on the target site.
<dereine> hmeland: i have shell access on the site
<dereine> how can i update the working tree files
<asabil> dereine: by hand ? just ssh, and issue bzr update
<dereine> ah ok thx
<asabil> dereine: but why would you need a tree there ?
<asabil> if it is for web access, I would suggest running loggerhead
<dereine> because it's the "live"site
<asabil> oO ?
<asabil> not sure I got it
<asabil> you are pushing a website using bzr ?
<dereine> i develop a theme and some modules of a website offline and than a want to push&update the dir there
<dereine> it's a cms
<asabil> ah ok, I see
<jelmer> hmm
<jelmer> my blog is the first hit for the term "Mercurial branches" in google?
<LarstiQ> heh
<davi> Is there a GNU Project controlled alternative to the Canonical's Launchpad free service?
<Toksyuryel> davi: Savanah iirc
<davi> great!
<davi> Toksyuryel, so why projects use Launchpad? What advantage does Launchpad offer?
<jelmer> davi: it has tighter bzr integration
<jelmer> if you use "bzr commit --fixes lp:<bugnumer>" launchpad will automatically link the branch and the bug report
<jelmer> for example
<davi> I see, Savannah should catch up
<Toksyuryel> bazaar is developed by cannonical, who also develop launchpad. also it was only a few weeks ago that bazaar became a GNU project, so the launchpad stuff is far more mature in terms of integration
<Toksyuryel> someone'll probably start implimenting savanah integration sooner or later
<davi> thanks Toksyuryel
<Toksyuryel> more likely to be someone from GNU than someone from canonical though
<Toksyuryel> I am still concerned about the logistics of this new arrangement tbh
<Toksyuryel> I started reading through the GNU coding guidelines and one of the first things it says that you can't "refer" to non-free projects, which has me worried about the future of the launchpad integration unless they decide to finally release it to us
<Bronger> Well Mailman is also integrated heavily into non-free software ...
<Toksyuryel> if the launchpad stuff is all in a plug-in that'd allieviate any concerns I think
 * Toksyuryel knows he spelled THAT wrong...
<Toksyuryel> jelmer: can that syntax support commits that fix multiple bugs at once?
<jelmer> Toksyuryel: afaik, yes
<jelmer> but I have to admit I've never used it that way
<Toksyuryel> cool
<Toksyuryel> if you're coding carefully it rarely happens but sometimes you get a little ahead of yourself
<Toksyuryel> it's one of those things that it's nice to know it's there :)
<beuno> Toksyuryel, I suppose you can file a question in Launchpad, and, if not, it will be converted into a wishlist bug
<jelmer> 'morning beuno
<beuno> mornin' jelmer, how's it going?
<Toksyuryel> beuno: jelmer says it already exists?
<Toksyuryel> *said
 * Toksyuryel ponders how food that's never been in the freezer can be freezerburned
<beuno> Toksyuryel, ah, I wasn't convinced by his answer  :p
<jelmer> Toksyuryel: as beuno says, if you would like to be sure, please file a question
<jelmer> beuno: pretty good, thanks. I'm trying to get bzr-svn up and ready for a release.
<Toksyuryel> I'll check the docs first and if it's not in there then I'll think about filing a question :)
<jelmer> beuno: Are you guys still around in London or now somewhere else?
<beuno> jelmer, we're in Prague now
<beuno> London is too expensive
<phanatic> :)
<phanatic> especially if you don't get per diem from canonical ;)
<beuno> jelmer, I'm going to work on the nautilus bit today so we can see if it's in a releaseble state
<jelmer> ah, cool
<beuno> hey phanatic!   yeah, or a nice hotel with slippers
<phanatic> hey beuno :)
<phanatic> btw i couldn't get the nautilus stuff working on my hardy box. i must have missed something...
<beuno> phanatic, would be interesting to debug that
<phanatic> beuno: oki, i'll fire up the machine
<LarstiQ> gar massive filesystem corruption :(
<leo2007> hi there
<LarstiQ> hi leo2007
<phanatic> beuno: i've installed nautilus-bzr.py to /usr/lib/nautilus/extensions-1.0/python/ - it should be correct, but doesn't seem to work even after a reboot (emblems are available tho).
<jelmer> phanatic: Do you have python-nautilus and python-dev installed?
<phanatic> jelmer: i have python-nautilus installed, but not sure about python-dev. will check...
<dereine> is it able to "push" for a older version of bzr?
<beuno> jelmer, is there a way around the py-dev thing?
<jelmer> beuno: Well, you can create a symlink yourself
<jelmer> but basically, it's a bug in the python-nautilus package
<beuno> dereine, _to_ an old version, or _from_ an old version?
<dereine> to an old version
<beuno> dereine, yeap, no problems doing that
<dereine> thx
<dereine> but who?
<beuno> whi?
<beuno> er, who?
<jelmer> bug 44704
<dereine> but how, sry i'm german
<jelmer> ubotu: bug 44704
<beuno> but #44704
<beuno> argh, I can't type today
<beuno> phanatic, did installing python-dev work?
<jelmer> ubotu appears to be dead today
<beuno> I went on looked it up
<Kamping_Kaiser> he was tehre not long ago
<Kamping_Kaiser> ubotu, ping
<beuno> jelmer, maybe we should symlink for the time being, from install?
<jelmer> beuno: I'd rather not - people who install python-dev would then get conflicts, etc
<jelmer> beuno: I'd rather just get that bug fixed, it's been open for ages
<beuno> jelmer, so we should just patch the package than?
<beuno> we're too late for hardy though  :(
<dereine> so how can i push as a old version of bzr
<beuno> dereine, bzr will push with the format that the remote repo has, so it will do it automtically
<dereine> ah ok thx
<phanatic> installed python-dev, still haven't appeared in nautilus
<leo2007> how to convert a project under svn to bzr?
<beuno> leo2007, there is a bzr-svn plugin to do so
<LarstiQ> dato: I didn't see a way to comment on your blogpost, but bzr can do that too, although the syntax could admittedly be nicer: '(?!debian/).*'
<dato> LarstiQ: oh, wow
<LarstiQ> oh
<LarstiQ> you might want to prefix with RE:
<dato> wow, I didn't know about that
<LarstiQ> so, echo 'RE:(?!debian/).*' > .bzrignore
<ubotu> Launchpad bug 44704 in nautilus-python "Expects to find libpython2.4.so, should look for libpython2.4.so.1" [Low,Confirmed] https://launchpad.net/bugs/44704
<dato> LarstiQ: thank you, I'll update the entry.
<LarstiQ> dato: it's python regexes under the hood, but without RE: it will treat it as zshish globs
<ubotu> ping yourself ;-) really the diodes all down my left side are sore
 * LarstiQ looks for the zsh aspects of it
<dereine> how do i update a dir which has only some files, but on the push goal there are much more files
<LarstiQ> I know we discussed things like **/ in the past
<LarstiQ> dato: it's certainly at least sh globs ;)
<dato> and RE: can have any python stuff?
<LarstiQ> dato: python regexes
<LarstiQ> not python code
<dato> yeah, I meant that
<dato> ok
<LarstiQ> in that case, yes
<LarstiQ> I don't know we document that well enough?
<LarstiQ> ah, bzr help ignore lists an example of RE:
<LarstiQ> dato: mind writing up a patch to extend the ignore help with your debian example?
<dato> ok
 * LarstiQ continues whipping nested-trees in shape
<jelmer> LarstiQ: \o/
<Verterok> moin
<Verterok> jelmer: thanks for the review ;)
<dereine> what is "âcreate-prefix" for?
<LarstiQ> dereine: akin to mkdir -p
<phanatic> jelmer: installed python-dev, but still can't see any bazaar actions turning up in nautilus
<jelmer> phanatic: Try running nautilus manually
<jelmer> it may spit out something on the command-line
<LarstiQ> dereine: so if the directory structure you want doesn't exist at the remote side, --create-prefix will create the missing bits.
<phanatic> jelmer: it doesn't spit out anything unfortunately. is there a switch for this maybe?
<jelmer> phanatic: No, afaik it should spit out information by default
<jelmer> phanatic: Are you sure you installed it in the right directory?
<jelmer> Verterok: You're welcome. Hopefully one of the other voters can also approve it (but I guess it will not before monday)
<jelmer> *be before
<phanatic> jelmer: it returns to the shell after i launch nautilus manually
<jelmer> phanatic: you need to kill the running instance of nautilus first
<jelmer> phanatic: nautilus --quit
<dereine> another question whats the diference between update and upgrade
<jelmer> dereine: upgrade upgrades the branch to another file format
<dereine> and update?
<jelmer> dereine: update updates to the tip of the master branch (for checkouts)
<phanatic> jelmer: i've restarted my machine twice...
<jelmer> phanatic: yes, but that will not show anything on the command-line
<phanatic> i have nautilus-bzr.py in /usr/lib/nautilus/extensions-1.0/python/
<beuno> phanatic, nautilus --quit && nautilus --no-desktop
<phanatic> jelmer: killing nautilus doesn't help either (it relaunches itself, again no output)
<phanatic> beuno: thanks, i was looking for that :)
<jelmer> phanatic: see beuno's comment
<Verterok> jelmer: sure, but in the meantime I can improve it with your and other voters comments
<phanatic> nice, it couldn't load python-nautilus
<dereine> i have on one (1) branch much more files than on the other(2);  when i push(1) to (2) and update (2) , the dirs of (2) get moved to .moved
<beuno> dereine, you have conflicts
<dereine> yes but the conflict is that there are much more file than on the branch i update
<beuno> dereine, right, if you keep pushing and updateing without resolving, you will just generate more .moved files
<phanatic> it seems i won't be able to test under hardy. i get an undefined symbol error when loading nautilus-python
<phanatic> oh, the same error that's described in the debian bts
<dereine> beuno: but resolve does nothing
<dereine> do i need to have the same startpoint for both branches?
<beuno> dereine, take a look at: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts
<ubotu> New bug: #200203 in bzr-svn "branch using bzr-svn just hangs" [Undecided,Fix released] https://launchpad.net/bugs/200203
<Odd_Bloke> Afternoon.
<jelmer> any turbogears experts here?
<manfre> how do i change the push location of an existing branch?
<beuno>  manfre you can just do a push to the new location with --remember
<manfre> ok
<beuno> and it will override the default
<manfre> thanks...that worked
<beuno> manfre, you're welcome
<j1mc> hi all - i used sed to create a working copy of a file (file_temp.xml) and then used mv to overwrite file.xml with file_temp.xml.  ...
<j1mc> when i do a bzr status, there's an asterisk after file.xml... does this mean it can't do a diff anymore?
<j1mc> (or that the diff won't be accurate?)  i don't want to have people reviewing changes that are actually just the entire xml file.
<exarkun> Odd_Bloke: Yesterday you answered my question about LockDir and mkdir() over HTTP
<exarkun> Odd_Bloke: The operation that failed was "bzr checkout".
<luks> j1mc: I think it means that the executable bit changed
<j1mc> luks: thanks.  i'll check that out.
<LarstiQ> j1mc: if you do bzr diff, it should tell you what's different
<j1mc> LarstiQ: thanks.  it looks like you're right... it is still reflecting the changes when i do bzr diff.
<Odd_Bloke> exarkun: Right, a checkout implies that any changes you commit locally will be propagated upstream.
<Odd_Bloke> This obviously can't happen over a dumb HTTP server, so it errors.
<Odd_Bloke> There's a bug already open about the rubbish error reporting there.
<LarstiQ> it could over webdav, if/when vila finishes it :)
<Odd_Bloke> exarkun: You probably want 'branch' instead of 'checkout'. :)
<exarkun> Odd_Bloke: To be clear, I wasn't making any changes though.
<exarkun> Odd_Bloke: I'm not sure if you're saying it's a known bug in "bzr checkout" or if you're saying something else.
<Odd_Bloke> exarkun: I'm saying that it's intentional that 'checkout' fails, because checking out over a read-only protocol doesn't make sense (in bzr).  I'm saying that the fact that this isn't made clear to the user until they ask in the IRC channel is a known bug. :)
<exarkun> Aha, I understand.  Thanks.
<j1mc> luks: you were right about the executable bit.  changing now.  thanks for your help.
<james_w> Anyone know how to update an inventory entry?
<speakman> luks: I'm sorry. I think I'm too new to bzr (and distributed rcs) to understand what you're telling me. :(
<asabil> speakman: basically in DRCS, each person has a branch or a repository copy
<asabil> actually calling DRCS DRCS, can be quite misleading
<asabil> by DRCS are just a generalization, so basically any DRCS can also operate in a Centralized mode
<asabil> just by having a central copy of the repository/branch
<asabil> this is what is called the baseline (or the trunk)
<asabil> since this is possible and very easy to have, bzr has 2 modes of operation
<asabil> 1) normal branches (the ones you get using bzr branch)
<asabil> 2) bound branches (aka checkouts) (the ones you get using bzr checkout)
<asabil> if you do a bzr branch URL, you will get a disconnected (normal) branch
<asabil> if you do a bzr checkout URL, you will get a bound branch
<asabil> the update command is generally only meaningful in the case of bound branches
<huslu> asabil has a good point, imo this checkout with bound branches and subtle differences like that are not very visible in user guide.
<asabil> huslu: the best way to solve it is with a graphic
<asabil> showing the different workflows
<huslu> right, but at least for me still the differences weren't so clear - meaning it didn't clearly make a difference that certain things go together only with certain other things.
<huslu> the workflows graphics does not convey that stuff is 'bound'
<huslu> so now i am starting to get it, but it took several times reading and trying to get the point. then again i am a newcomer to version control.
<speakman> asabil: thanks alot for youre explanation!
<asabil> you are welcome, they are not very clear though, feel free to ask any question you might have
<mamato> hi, i'd like to save some changes (in some separate branch?) and revert to old commit (letting those changes aside for now cause i dont like them anymore), how should i do this? commit/revert-r/more changes/commit?
<asabil> mamato: take a look at bzr shelve
<mamato> another question (since no one seems around ;) yet?), if i want to commit separately different parts of the changes in a file, the simplest way is to backup the file somewhere revert the second mod, commit, bring back backup, recommit?
<asabil> :D
<asabil> mamato: take a look at bzr-interactive
<mamato> hmm, my bzr seems a bit out of date...
<asabil> mamato: http://bazaar-vcs.org/BzrShelveExample
<asabil> mamato: both are bzr plugins
<asabil> mamato: just install bzrtools to get bzr shelve
<asabil> concerning bzr-interactive, it is a plugin you can find in the plugins page
<mamato> ah oki... i have 0.9...
<asabil> that should be enough
<mamato> actually, shelve does not look exactly like what i'm looking for... i tried switching my app to a new library, made a bunch of changes for that, realized the library doesn't do it, decided to go back to not use that new library for now (indefinitely). i just thought i'd save those changes just in case i ever want to see what i had done at that time.
<asabil> mamato: create a new branch ?
<mamato> maybe, i'm not sure, i haven't used branches yet... i guess
<asabil> you started using branches from the day you created your bzr repo
<asabil> :p
<asabil> mamato: bzr branch -r ... branch1 branch2
<asabil> you can branch of an old revision
<asabil> for example
<asabil> bzr branch -r 1234 branch.newlib branch.oldlib
<mamato> does that create a new directory with everything duplicated?
<asabil> yes
<asabil> but from the revision 1234
<asabil> 1 branch == 1 directory in bzr
<mamato> hmm, not really necessary... especially since i haven't yet fixed the fact that way too many big objects files have been entered in the bzr db...
<asabil> mamato: can you install bzr gtk ?
<asabil> and then run bzr viz
<mamato> and?
<mamato> i already have it installed
<asabil> it should show you the revision tree of your project
<mamato> yep
<asabil> just create a branch from the point where you didn't do all those changes you don't want anymore
<asabil> isn't that what you want ?
<mamato> looks good... thx... going back to figuring out other bzr stuff
<mamato> how do i setup olive to work with my bzr tree? "branch/initialize"?
<mamato> i'm looking for GUI to select multiple files and commit them together
<mamato> hmm... nevermind... command line works great...
<phanatic> mamato: bzr gcommit (if you have bzr-gtk installed)
<mamato> works nice thx
<mamato> how can i use meld to merge committed with current version?
<mamato> whow! meld automatically works with bzr! nice!! i'm starting to quite like using bzr :)
<asabil> mamato: bzr gconflicts
<asabil> would allow you to run meld automatically
<mulander> http://paste.org/index.php?id=2229 <- does bzr have a solution for such a problem?
<luks> mulander: branches "sticking on people's hard drives" is one of the main points of bzr, but I don't think there is a CSV convertor that works in both ways
<luks> so committing back to CVS will by probably a problem
<mulander> luks: I am aware of DVCS main approach
<mulander> luks: the problem is that the 'company' is using CVS, the admins have bad ideas
<mulander> and we developers have to live with it :)
<luks> it's weird that the admin sets the rules
<luks> in me experience it's usually the other way around
<asabil> mulander: cvs -> bzr should be easy
<asabil> bzr -> cvs is technically feasible, but you will lose a lot of metadata
<mulander> luks: this is a more compilacted thing
<asabil> and there is no available tool for doing it
<mulander> 1. why they do it - because we have many development teams
<mulander> and one of them pushed their arguments before us
<mulander> 2. the main concern are the binary files.
<asabil> mulander: I think a DRCS is the best solution for your problem
<asabil> and if you could s/CVS/SVN/ that would make thinks far less painful
<mulander> asabil: the problem is that this is a large company
<mulander> asabil: so things go slow, especialy infrastructure changes
<luks> Tailor might be theoretically to push the changes to CVS, but I wouldn't rely on that
<luks> er, +able
<asabil> mulander: I managed to change this in a large company before
<mulander> asabil: I'm trying from day 1 :)
<mulander> bzr is one of my targets for a switch
<mulander> the most probable one atm.
<asabil> mulander: maybe you need to hold a presentation or a talk ?
<mulander> asabil: had several so far
<asabil> mulander: bzr, and mercurial are the ones I can suggest
<mulander> asabil: bzr got better scores in the initial research.
<asabil> :)
<asabil> anyway, going to bed
<asabil> gnight and good luck
<mulander> asabil: g'night
<mulander> asabil: thx
<manfre> how do i remove a lock on a branch? A commit didn't process and now i can't do anything else to the branch
<beuno> manfre, bzr break-lock
<manfre> beuno, thanks
<beuno> manfre, welcome'
#bzr 2009-03-02
<rockstar> jelmer, ping
<lifeless> spiv: 78->25
<bignose> lifeless: if you have the bandwitch available, your input on the above questions for loom and quilt would be appreciated
<bignose> s/witch/width/
<lifeless> bignose: hmm, thought there was a bug open; filing one
<lifeless> I want bzr send to generate a patch series
<lifeless> https://bugs.edge.launchpad.net/bzr-loom/+bug/336470
<ubottu> Ubuntu bug 336470 in bzr-loom "bzr send should output a patch series (by default, overridable) when used with a loom" [Undecided,New]
<poolie> lifeless: do you have any ideas about bug 336267?
<ubottu> Launchpad bug 336267 in bzr "bzrlib.errors.KnitCorrupt during branching" [Undecided,New] https://launchpad.net/bugs/336267
<lifeless> poolie: something has mangled the actual error, but from its phrasing I'd guess at zlib
<poolie> yes
<lifeless> poolie: (phrasing and being in the header parsing stage)
<poolie> it seems like a very low-level error to be caused by us
<lifeless> I don't think its a bzr bug, though it might be. I'd instead be expecting bad data
<poolie> i thought so too
<lifeless> its on the client side
<lifeless> and its in the pack repo code
<lifeless> so its using regular vfs methods; and spiv and I haven't done anything nasty to those
<bignose> lifeless: thanks for the response, and the bug report
<lifeless> bignose: the send -r thread:..-1 loop is missing a 'bzr switch next-thread' in it, if you want to reproduce by hand
<bignose> why would I choose âsendâ over âdiffâ in this case?
<lifeless> I realise its at my end, but please use plain ascii for this conversation, otherwise I can't read what you are typing.
<lifeless> I saw "why would I choose a over a in this case?"
<fbond> Does anyone here use trac-bzr?  Can anyone tell me if it is capable of working with multiple branches?
<fbond> I get the feeling that it is supposed, to, but I'm only able to successfully browse the branch containing the most recent revision.
<bignose> lifeless: why would I choose 'send' over 'diff' in this case?
<lifeless> bignose: if you're submitting to bzr users, use send. If you're submitting to non-bzr users, you can use send or diff
<lifeless> bignose: send includes the revision metadata and any dependent history to allow a normal merge to be done at the far end
<bignose> okay. since in this instance I'm only generating the patch for use with quilt, I'll just use diff.
<greg-g> What is the correct workflow for maintaining two branches of a project with a "dev" and a release branch (eg: 1.0)?  Do I commit to dev, then pull that commit from dev to the 1.0 branch somehow? or just commit to both separately (which would have the possibility of non-mergeable branches later, right? I might be wrong with this)
<poolie> greg-g: definitely don't make unrelated commits to both
<poolie> i'd consider having actually a branch per individual release on 1.0
<poolie> like 1.1, 1.2, etc
<poolie> otherwise, either merge in to 1.0 and then do bzr ci -m "release 1.0.1"
<poolie> or just pull
<poolie> either would work
<greg-g> our 1.0 is the branch that we are going to release as 1.0 when we feel it is ready. basically a "stable" branch
<poolie> the first will be better if you ever need to do little fixes directly in 1.0 to fix packaging bugs for examlpe
<poolie> oh i see
<poolie> so the other thing is, it's generally easier to merge from a more-stable branch into a less-stable
<poolie> than vice versa
<poolie> so i'd consider, for any work that will land in 1.0
<poolie> doing it in a branch based off 1.0
<poolie> then merging to 1.0, and then either merging all of that back to trunk, or merging the individual bits
<poolie> this is not so much for technical reasons as just that as the software changes
<poolie> it tends to be easier to update your 1.0 changes to fit other stuff than to backport your fixes
<greg-g> so for things that are more or less self-contained commits, put in 1.0, then merge to dev from there. but what about things that are partially implemented but we want to test with dev?
<poolie> how do you mean partially implemented?
<greg-g> then later, when completed, merge only that feature into 1.0
<poolie> igc, btw thanks for fixing the status html; what was wrong?
<poolie> igc, also, maybe i should change it to order bzr-dev first?
<poolie> greg-g: ok i think i understand
<poolie> i would: make a branch off 1.0, implement it there
<poolie> and primarily test there
<poolie> if, before you're finished, you also want to check how well it will mesh with dev
<poolie> make *another* branch coming dev, merge your new features in to that
<poolie> then when you're done, you merge those two work branches in to 1.0 and dev respectively
<greg-g> gotcha
<greg-g> would cherrypicking also be an acceptable way to handle that (cherrypick it from dev to 1.0)?
<greg-g> I saw there was something about bzr not tracking cherrypicked revisions.  I'm too knew to understand where that will have an adverse effect in the future.
<igc> poolie: status html? you mean the colouring?
<igc> poolie: I think the first tool ought to be bzr-current, i.e. the currently released version
<igc> bzr.dev ought to be compared to that
<igc> poolie: I'm not sure looking at earlier versions (before bzr-current) buys much
<igc> poolie: the 3 interesting versions IMO are bzr-current bzr-dev bzr-brisbane
<igc> lifeless: bzr selftest groupcompress is failing because ...
<igc> 1. I haven't compiled the groupcompress_c stuff using pyrex
<igc> 2. some other issue
<igc> lifeless: it looks like the tests are *meant* to skip ...
<igc> the compiled tests if the compiled stuff isn't there?
<spiv> no
<igc> I wonder if setUp() happens before tests_needs_feature?
<spiv> (^ that was <lifeless>)
 * spiv & lifeless -> food
<lifeless> igc: possibly; for now, just build them :)
<poolie> igc, i was thinking bzr-dev first because that's what we're more likely to change for good or ill
<poolie> also i should check current is in fact current now :)
<lifeless> as we have a current now, that should be easier to maintain :)
<lifeless> greg-g: the adverse effect is fairly small and isolated. Its two things:
<lifeless>  - you can't use bzr to report 'what has been cherrypicked'
<lifeless>  - you may get spurious conflicts on subsequent merges if you change the line of code further
<poolie> greg-g: what robert says is correct, but it's not so much about bzr capabilities
<poolie> more that it's actually easier for you to write it in 90% of cases if you do not cherrypick
<poolie> but keep it separate to start with
<greg-g> lifeless / poolie thanks! I think I've got it figured out now.
<lifeless> greg-g: anytime
<mwhudson> poolie, spiv: could one of you make the tweaks you ask for for my "LockableFiles.__del__ must die" as you land it?
<poolie> no promises but i'll try
<mwhudson> thanks
<lifeless> jam: ping
<poolie> abentley: BB is down
<abentley> poolie: restarted
<poolie> thanks
 * igc food
<lmiller> Hi
<poolie> gar too much mail
<fullermd> I have some ideas on how to handle that.  I'll send you an email about it...
<contingencyplan> Have a question for you guy, if anybody's around:
<contingencyplan> I'm currently using mercurial, but I've hit a brick wall, so seeing if bazaar can handle this better.
<contingencyplan> I have a repository with a subdirectory in it with code. When I started making the repository, I was the only one using it, so that was fine, but now I'm in another project that also needs that code.
<contingencyplan> How easy is it to have 2 bazaar repositories that share a common code-base? Ideally, I want that common code-base to be transparent to each repository - for my private repository, it looks and acts just like it always has, for the new repository there's no apparent difference whether it's in that repository or stored elsewhere.
<contingencyplan> (sorry for the lengthy msg there)
<lifeless> contingencyplan: there is a merge-into plugin that can join the two brances
<lmiller> Anyone know how to get the bzrbuildbot plugin working with a central bzr repository?
<lmiller> From what I can tell, each user needs to put it in their own plugins dir
 * igc bbiab
<lifeless> lmiller: what hook does it use?
<lmiller> on change
<lmiller> post_change_branch_tip I believe
<lifeless> lmiller: that will run on the server
<lifeless> lmiller: as long as you're pushing with bzr 1.6 or so, and over bzr+ssh, not sftp or webdav.
<lmiller> lifeless: It requires a location.conf file, but I don't seem to have anywhere to place it on the server
<lmiller> where the server will find it I mean
<lifeless> lmiller: you can configure the same settings in branch.conf
<lifeless> in the branch you want to test
<lmiller> So, if I wanted to trigger the main branch, I would edit branch.conf inside the repos (eg /repos/main/proj/.bzr/branch/ )?
<lmiller> I'm coming from svn, so excuse me if I ask nervously about editing files inside the repository ... heh heh
<lifeless> yah, repos/main/proj/.bzr/branch/branch.conf, if your branch is bzr+ssh://host/repos/main/proj
<lifeless> its not ideal, we want a better answer here, but it will work :)
<lmiller> exceptions.NameError: global name 'failure' is not defined
<lmiller> Ah, I love programming
<lifeless> :P
<mwhudson> flymake-mode ftw
<jml> so, it looks like bzr-svn really really really wants more than 360MB of RAM
<lmiller> lifeless: Thanks for that ... all working now
<lifeless> lmiller: cool
<vila> Hi all ! :-)
<fullermd> Wow, that's way too chipper.  You obviously have coffee you need to share...
<vila> fullermd: hehe, no, same coffee as usual, but some days are better than others, just from the start (the opposite is also true...)
<poolie> vila: hello, welcome!
 * igc dinner
<vila> poolie: thanks :)
<poolie> vila, want to talk?
<vila> poolie: with pleasure
<poolie> could you call me here then?
<vila> sure
<lifeless> ok, stream branching collection of patches all landed
<lifeless> tomorrow, streaming from stacked
<poolie> hi
<poolie> way to go
<poolie> vila, does bug 336582 look familar to you at all?
<ubottu> Launchpad bug 336582 in bzr "test hang in TestStackingConnections.test_open_stacked" [Undecided,New] https://launchpad.net/bugs/336582
<vila> poolie: didn't Andrew mention that on the list today ?
<poolie> it sounded familiar somehow
<vila> poolie: hmm, he mentioned hpss not sftp though
<spiv> vila: yeah, my patch wouldn't affect sftp
<poolie> tired -> good night all
<spiv> Weird that the traceback involves SFTP, but the test doesn't run at all if FTPServer is missing.
<spiv> I suspect the test is not granular enough...
<lifeless> gnight poolie
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> so I've replied to your mail
<lifeless> short story though is that you need to be digging deeper, and I'd like to help you do that
 * igc reads email
<igc> lifeless: thanks. I've got to run right now - might be back later
<lifeless> igc: ok, well I may be up; if I am, skype will know :P
<lifeless> igc: and if so, chat/call me on skype, I doubt I'll have irc in front of me
<igc> lifeless: still there?
<lifeless> yes
<igc> so no fast path is running
<igc> in log -v currently
<lifeless> well then :P
<igc> what routine are you thinking of?
<lifeless> CHKInventory._make_delta(aCHKInventory)
<lifeless> line 1709 in my copy of inventory.py
<lifeless> if you're not hitting that, then you're not seeing CHK delta generation, and it will blow chunks.
<lifeless> if you are seeing that, you're at least getting some of the work done by the CHK core
 * igc pulls up profiling data
<lifeless> but unless you have an lsprof run, its going to be very hard to tell whats going on :)
<igc> lifeless: 77% of time in iter_changes() - inventory.py line 1655
<igc> no calls to make_delta
<lifeless> ok
<lifeless> thats the CHKInventory fast path
<lifeless> so, I'd look at what its doing
<lifeless> (or it should be - is it CHKInventory.iter_changes?)
<igc> lifeless: oh, I know what's its doing ...
<igc> reo.get_delta_for_revisions() builds trees and calls tree.changes_from() -> delta._compare_trees -> iter_changes
<igc> s/reo/repo/
<igc> lifeless: yes, CHKInventory.iter_changes()
<lifeless> ok, that all seems normal
<lifeless> so we're looking at the right code path
<lifeless> now, it may be doing duplicate work
<lifeless> it may be discarding one side of the trees, or things may not be getting kept in ram once loaded
<lifeless> I'd be inclined to instrument
<lifeless> finding duplicate CHK page reads, for instance
<lifeless> a cheap way of detecting this
<lifeless> is too look in the call graph
<lifeless> if you're doing (say) a 100 revision range
<lifeless> and you see 1M get_record_stream calls
<lifeless> then something suspect is going on
<lifeless> remember that there is nearly _no_ optimisation in here at the moment
<lifeless> assume that the core data structures are decent - John is tuning them, and they have passed all our design checks along the way
<igc> lifeless: ok, so 1000 revisions -> 15830 get_record_streams calls in groupcompress
<lifeless> 15 pages per revision
<lifeless> what project?
<igc> first 1k revisions of wordpress
<lifeless> how big is wordpress, files in the tree
<igc> lifeless: small, 142 files
<lifeless> so
<lifeless> we expect
<lifeless> 1 read to get the inventory, 1 to get the root of the dir map, 1 to get the root of the inventory entry map
<lifeless> (roughly)
<lifeless> so we can explain 3K reads
<lifeless> that leaves 12K reads to calculate the differences, but 142 entries isn't many
<lifeless> to get 15 reads per diff, I'd expect more files or many very large changes
<lifeless> so - I suggest using my patch for VersionedFileDecorator to whip up a little LoggingVersionedFile
<lifeless> and decorate the chk versioned file object on the repository
<lifeless> then dump the log to disk after the operation, and we can look for repeated requests
<igc> lifeless: interesting
<lifeless> you only need to care about get_record_stream, and the keys parameter
<lifeless> an interesting test would be diffing one revision
<lifeless> log -v 1..2
<igc> yes
<lifeless> for instance
<igc> lifeless:I'll start digging deeper - thanks for your help
<lifeless> my pleasure
<lifeless> I'm oing to play computer games for a bit
<lifeless> I'll check back in a while
<djr> Is there anyone around who understands how to install from source (bzr-*.tar.gz) on linux, please?
<_MMA_> Ok. So it's 8hrs later and a upload to a branch I was working on is still locked. "bzr break-lock" does nothing and the recommended command to use when it tells me the branch is locked tells me: "bzr: ERROR: Unsupported protocol for url "lp-45955728:///~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio/.bzr/repository/lock"
<djr> Installing bzr from source is supposed to require only Python, right? So why does it fail trying to run gcc?
<lifeless> _MMA_: "bzr break-lock lp:~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio"
<lifeless> djr: it tries to build the C accelerators, if you don't have them then you can still just run from source
<lifeless> djr: but we recommend building them, it makes a big performance difference
<_MMA_> lifeless: Thanx man. I don't know whether I should file a bug. The suggestion it gives seems wrong.
<lifeless> _MMA_: there is one about the url it gives being bad,and another that we should auto-break in some situations
<_MMA_> Ok. I'll just hope it resolves itself. ;)
<_MMA_> lifeless: Maybe you can tell about one more. I have a bunch of older branches. So I'll get the "please use 'bzr upgrade' to get better performance" warning from time to time. So, I do. But then when going to upload after that, after upgrading, I get the warning again. Am I missing something?
<lifeless> _MMA_: you need to upgrade each instance - so you need to upgrade where you are pushing to
<lifeless> there is a bug/limitation in upgrade at the moment with launchpad; you need to use 'bzr upgrade sftp://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio' rather than 'bzr upgrade lp:~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio'
<_MMA_> lifeless: Oh sure sure. Each branch. I didn't mean to imply that I wanted to do it once and it would be fixed for all.
<lifeless> :)
<_MMA_> I will upgrade a branch. Then on same branch, get the warning again.
<lifeless> _MMA_: do you have a shared repo?
<_MMA_> ~ubuntustudio-dev's yeah.
<lifeless> on your laptop/workstation I mean
<lifeless> launchpad doesn't have shared repos
<_MMA_> Oh Oh. ie: 2 machines that work on network shared folder?
<_MMA_> Both have access to some BZR work Im doing?
<lifeless> _MMA_: no, its a specific term in bzr, a 'shared repository', created by 'bzr init-repo'
<_MMA_> Ok. I remember now. No.
<lifeless> _MMA_: please run 'bzr info -v' on a branch where you are having this happen
<_MMA_> Gotcha
<lifeless> if you pastebin the output the next time it warns, I'd be delighted to help you
<_MMA_> lifeless: I'll be doing some more work later so Ill be sure to if it happens again.
<lifeless> djr: its possible we have a setup.py regression with installing without the extensions; if thats the case, please file a bug
<lifeless> djr:  you can run bzr from source without installing it, as a work around - just symlink 'bzr' into your path, or add the source dir to your path
<_MMA_> lifeless: So when I run "bzr upgrade" it makes a "backup.bzr" folder.  After doing "bzr add" it added that folder and now I look to be uploading that content. Can I either *not* create that backup or delete "backup.bzr" later?
<lifeless> you can't avoid the backup; just rm -rf backup.bzr once you've done the upgrade in a given branch
<_MMA_> lifeless: After or before a push to LP?
<_MMA_> Oh I see.
<lifeless> before you next commit ;)
<lifeless> if you've committed it, just uncommit
<_MMA_> Well I did. :( So now I've been sitting at: "[\      ] Transferring:Walking content. 1/1" since I broke the lock.
<lifeless> igc: deeper still :)
<igc> lifeless: in the morning, when I'm awake :-)
<lifeless> igc: sure
<lifeless> igc: are you starting to see the shape of the intent ?
<LarstiQ> beuno: do you know if loggerhead is supposed to generate relative links, instead of hardcoding the hostname in the href?
<igc> lifeless: I think so. just saw your reply ...
<igc> the root would change for a read-centric operation like log though
<igc> s/would/won't/
<lifeless> igc: Nodes are immutable, so they will never change after being written;
<lifeless> igc: however the root will be different for  every inventory unless the inventories are identical
<igc> sure
<lifeless> igc: so for log, we should be reusing the tree - first as child then as parent
<igc> lifeless: we do reuse the trees at the repo level *but* the code for iter_changes (tree.py line 928) always calls through to CHKInventory.iter_changes()
<lifeless> igc: right, that should be fine
<lifeless> oh, the variables you asked about, I was looking in inventory.py
<lifeless> I'll reply again tomorrow after I page this in
<lifeless> igc: _get_node would seem to be buggy, as it notes: does not update
<lifeless> igc: fixing that to actually update the items dict may be useful :)
<igc> :-)
<lifeless> igc: all the same
<lifeless> it kindof assumes that the differences from treeA to treeB will be similar to treeB to treeC
<lifeless> for that to matter
<lifeless> CHKMap is the code to own though
<lifeless> its the driving abstraction
<lifeless> gnight!
<igc> night (and thanks)
<LarstiQ> beuno: it seems loggerhead.apps.branch.url: request.construct_url(...) includes the hostname, so that is one piece were it is already broken
<LarstiQ> beuno: (for my use case at least, maybe there is a reason for this?)
<_MMA_> lifeless: http://paste.ubuntu.com/125256
<beuno> LarstiQ, old versions of paste/patedeploy?
<LarstiQ> beuno: python-paste 1.6, python-pastedeploy 1.3.1
<beuno> hrm, that seems correct
<LarstiQ> let me make sure I'm using loggerhead trunk
<LarstiQ> beuno: yeah, lp:loggerhead 288
<beuno> LarstiQ, it does use absolute URLs, but it should be generating them properly
<beuno> you've got apache setup properly, etc?
<LarstiQ> beuno: well, how does it generate them?
<beuno> LarstiQ, based on what apache tells it through pastedeploy
<beuno> there's some stuff in the README about it
<beuno> did you follow that?
<LarstiQ> beuno: my situation is (outerhost:4443 -> innerhost:80 -> localhost:8080)
 * LarstiQ needs to look at how pastedeploy works then
<LarstiQ> beuno: the README.txt is very thin, but yeah I've got a ProxyPass setup like that.
<beuno> LarstiQ, hrm...  I don't really know. It's all mwhudson's magic
<LarstiQ> beuno: k, I'll go bother him then (and in fact already have a thread at bugs.launchpad.net)
<LarstiQ> beuno: thanks :)
<igc> night all
<LarstiQ> night igc
<djr> about installing bzr on linux, again. In the absence of gcc, once I have unpacked the tar.gz, what do I do? the InstallationFaq says link to ~bzr/bzr.dev/bzr, but I don't have that file/directory.
<djr> Is the bzr executable in the archive all I need?
<james_w> djr: if you just run ./bzr from the unpacked source it should work
<djr> Indeed it does. I wasn't sure if maybe it was an illusion and wasn't working properly. Could someone who understands these things refresh InstallationFaq on the wiki?
<LarstiQ> beuno: fwiw, I stuck in: relative_url = urlparse.urlunparse(('', '') + urlparse.urlparse(absolute_url)[2:])
<LarstiQ> beuno: and now it works, I'll followup with mwhudson
<beuno> LarstiQ, ah, cool. Thanks   :)
<LarstiQ> beuno: that does destroy the 'To get this branch, use bzr branch /loggerhead' bla, but ah well
<beuno> LarstiQ, right. We're very bad with URLs in LH
<_MMA_> lifeless: Man. "bzr upgrade" has never worked for me. :( I puled the branch new. (gave me the upgrade warning) Did "bzr upgrade" and removed "backup.bzr". Made a minor edit then committed/pushed to LP. Gave me the "bzr upgrade" warning again. :(
<awilkins> djr: It will work out of the archive, but there are some parts that can be compiled to give more performance
<Kinnison> _MMA_: It may be warning about the branch on LP
<djr> awilkins: following the wiki seems to violate Principle of Least Surprise. It says 'all you need is Python', but by default tries to invoke gcc, and gives no guidance on how to proceed once it has failed.
<_MMA_> lifeless: Current output of "bzr info -v ": http://paste.ubuntu.com/125281
<LarstiQ> _MMA_: that sounds like the _remote_ branch needs to be upgraded
<_MMA_> LarstiQ: Ahh.. Maybe that's what I'm hitting with alot of my branches. Is that something *I* can do?
<LarstiQ> _MMA_: ie, `bzr upgrade sftp://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-icon-theme/UbuntuStudio`
<LarstiQ> _MMA_: yes
<_MMA_> Ah...
 * _MMA_ tries.
<jam> lifeless: pong (if you are still awake)
<_MMA_> LarstiQ: That looks like it. Thanx man.
 * _MMA_ goes to upgrade all his branches.
<LarstiQ> _MMA_: glad I could help
<jam> djr: doesn't it tell you that you can use "build_ext --allow-python-fallback" ?
<Lo-lan-do> Hi all
<Lo-lan-do> I'm having a strange error with bzr-rebase... http://pastebin.com/df38d43c
<Lo-lan-do> It tells me my tree is out of date although it isn't.
<djr> jam: no it doesn't. there is a long an noisy traceback that concludes "log.warn('\n Cannot build extensions.\n' TypeError: not all arguments converted during string formatting
<jam> djr: ok, our warning code has a typo in it. :(
<djr> to (mis)quote Etienne "I tried bzr once. It failed to install!"
<jam> Looking closer, it is the code trying to tell you '--allow-python-fallback', but it falls over at that time.
<jam> I'll make sure that is fixed for the next release
<djr> is that an additional option to 'setup.py install' ?
<djr> A: no, it's not an option that INSTALL recognises
<jam> djr: it is 'python setup.py install build_ext --allow-python-fallback'
<asabil> hi all
<asabil> it seems like bzr doesn't display a progress bar anymore when ran from inside a script
<asabil> (for example from inside jhbuild)
<asabil> is this a known issue ?
<jam> asabil: there have been some reports of the progress bar disappearing on win32, but I haven't heard anything about scripts
<jam> it may be the same root cause, though
<asabil> hmm ok
<jam> it is possible that the code figuring out the 'terminal width' is somehow getting a width of 0
<jam> or some other strang ebit
<jelmer> jam, it may be related to that
<jelmer> progress bars aren't resized for me anymore
<jelmer> they always stay small
<jam> jelmer: well we don't continually poll
<jam> we used to check on every update, I think
<jam> which isn't great either
<jam> the code has a comment about SIGWINCH
<djr> jam: thanks John, that's done the trick. I think that's a documentation fix as well as a code fix required? Or why not enable fallback by default, so that the first-time would-be user gets a working install even if not an optimum one?
<jam> but I don't see anything that uses a null progress bar anywhere
<jelmer> jam, well, they even stay small if I resize my terminal window *before* starting bzr
<jam> djr: because first-time users should know that they aren't getting an optimum one
<jelmer> jam, that used to work ok with the previous progress bars
<djr> jam: if you've triggered the fallback path you could tell them
<jam> jelmer: we never resize the progress bar itself
<jam> which is intentional
<jam> we *do* write more text off to the right
<jelmer> ah, ok
<jam> vila: are you around?
<jam> (bbiab, changing network connections)
<jam> ok, back
<LarstiQ> jelmer: you want me to file a new bug, and then you can mark it as dupe if that happens to be the case, right?
<jelmer> LarstiQ, please
<vila> jam: yup
<LarstiQ> jelmer: done
<oubiwann> spiv (or anyone else): got a question for you
<oubiwann> is there any way to move/copy/import code from a completely separate branch into a subdirectory of a different codebase and preserve the revision history of the original?
<radix> oubiwann: yes
<radix> with a plugin I think
<radix> The word "join" is floating through my head
<oubiwann> radix: awesome -- I'll google-dig and see what I can find, thanks :-)
<jam> oubiwann: lp:bzr-merge-into
<jam> should get you going
<jam> or https://edge.launchpad.net/bzr-merge-into if you want a bit more info
<oubiwann> jam: thanks!
<radix> okay I guess I was wrong about join :)
<jam> radix: join works, but only in rich-root trees, etc, etc.
<jam> we're getting there :)
<radix> ah :)
<jam> jelmer: quick question about samba
<jam> I have a fairly old samba server running, and for some reason when I mount it, I can see the directories just fine
<jam> but if I try to read any *file* it aborts with a READ ERROR
<jam> Errno 13, Permission Denied  (it would seem)
<jelmer> jam, how old is fairly old?
<jam> jelmer: 3.0.23a-1.fc4.1
<jam> what is weird
<jam> is that it mounts just fine on my Vista machine
<jelmer> jam, doesn't sound familiar
<jelmer> jam, and on the client side?
<jam> $ smbclient --version
<jam> Version 3.0.28a
<jelmer> jam, The kernel version I mean
<jelmer> jam, (since the kernel module is not actually part of Samba)
<jam> client is Hardy, server is FC4
<jam> 2.6.24-23-generic
<jelmer> hmm, that should work quite well
<jelmer> jam: are you using smbfs or cifsfs?
<jelmer> if you're not using cifsfs yet, you may want to give that a try
<jam> i'm guessing my FC4 server won't have cifsfs
<jam> but my client *is* using cifs
<jelmer> jam: It's the client for which it should matter
<jam> //192.168.2.10/jameinel on /home/jameinel/juju type cifs (rw,mand,nosuid,nodev,user=jameinel)
<jam> //192.168.2.10/jameinel on /home/jameinel/juju type cifs (rw,mand)
<jam> according to mount
<jam> why would there be 2 entries?
<jelmer> as the server doesn't need any kernel stuff
<jelmer> there shouldn't be two entries
<jelmer> jam, that may be the source of the problems
<jam> jelmer: well, after 1 umount, I have a single entry, but then it does:
<jam> $ sudo umount /home/jameinel/juju
<jam> This utility only unmounts cifs filesystems.
<jam> This utility only unmounts cifs filesystems.
<loffe> How can I "bzr upload" with some uncommited changes?
<loffe> To be clear: I want to upload the last commited revision, w/o working changes...
<jam> loffe: 'bzr shelve; bzr upload; bzr unshelve' ?
<james_w> "bzr upload -r -1"?
<jam> jelmer: any idea of how to get it to unmount via something other than 'umount'?
<jelmer> jam: Well, umount.cifs but I think that's also what umount is invoking under the hood
<jam> jelmer: yeah, that gives the same error
<jam> as does 'smbumount'
<jam> though those only give the error 1 time
<jam> while 'umount' gives it twice
<vila> loffe: both suggestion by james_w and jam should work, file a bug if it doesn't
<loffe> jam, james_w thanks, -r did it. However shelve loks like a nice command
<jam> umount -f doesn't work either
<jelmer> jam: no idea then, sorry :-/
<jelmer> jam, The duplicate mount doesn't seem right to me though
<jam> -f, -n, -l, all der-br0ken
<jam> all say that they can only unmount a cifs filesystem
<jam> and mount certainly thinks that is what I have
<jam> note that there are *no files* if I do "ls mounted/path"
<jam> so there isn't a real mount there
<jam> just something claiming that there is... :(
<jam> jelmer: could there be a UID mapping issue?
<jam> that 'jameinel' on the local machine versus the remote machine is causing problems?
<jelmer> jam: all files will be accessed as the user with which you did the mount
<jam> (I ended up manually removing the line from mtab, and things are a bit nicer now)
<jelmer> and it will also do local access checking
<jelmer> if you have unix extensions enabled in the server, it should just use the same uids the server has
<jam> so the uids *are* different
<jam> 502 == jameinel on the server, 1000 == jameinel locally
<jam> though ls seems to say everything is 'jameinel.jameinel'
<jam> oh well, I guess I'll try repacking over sftp then
<jam> ah, but that fails because it tries to read approx 2GB in one pass...
<jelmer> jam: so if you're the only one using the remote server over smb from unix, you can disable the unix extensions
<jelmer> jam: and you should be able to specify a uid= option to mount to indicate what user should appear to own all remote files
<jam> jelmer: I'd be happy to do so, if I knew how to turn them on/off in the first place
<jam> jelmer: I tried uid= and it still failed
<jelmer> jam, "unix extensions = no" in smb.conf on the server side
<jelmer> jam, uid= is ignored if the server has unix extensions enabled
<jam> hmm.. I guess I'll try that
<jam> jelmer: so setting 'unix extensions = no' changed the default file/dir permissions, which seems correct
<jam> setting them manually via the -ofile_mode=XXX sets them as I would expect
<jam> but I still can't read anything
<jelmer> jam, did you override the uid=?
<jam> jelmer: yep
<jelmer> hmm, no idea then - sorry :-(
<jelmer> It's probably a cifsfs bug, but no idea what specifically
<jam> jelmer: I see this in the client's /var/log/message: Mar  2 10:39:45 liliana kernel: [1105324.900870] Status code returned 0xc0000022 NT_STATUS_ACCESS_DENIED
<jelmer> jam, that would suggest the server refusing the operation
<jelmer> jam, can you read these files with a windows machine?
<jam> jelmer: yep
<jam> from Vista
<jam> (I'll note that when I started accessing this share from Vista, it seemed to break mounting via Linux)
<jam> I don't know if that is relevant at all
<jelmer> jam, the vista machine may have a lock open at the moment?
<jelmer> jam, samba will enforce windows-like locks across clients, which are mandatory not advisory
<jam> jelmer: different files
<jam> but on the same fs
<jam> I can't read *any* files via linux
<jam> I can see the directory listing, etc
<jam> but when I go to 'cat foo' it gives me a perm error
<jelmer> hmm, still no idea then
<jam> does 'mount' list the options that you supply when doing 'smbmount', because I'm supplying a lot that I don't see
<jelmer> jam, no, it doesn't list them
<jelmer> jam, man mount.cifs should
<jam> no luck
<jam> and certainly I can supply what are obviously wrong parameters
<jam> and nothing complains
<jam> at least not right away
<LarstiQ> jelmer: hmm, I get the impression my bug mail is slower than your bugmail
<lifeless> jam: hi
<jam> hi lifeless, you're up early :)
<lifeless> 7am, not so early :P
<lifeless> jam: igc: was having trouble with gc
<lifeless> jam: did you see the bug
<jam> I saw one which has an obvious fix
<jam> something about None not being sortable
<lifeless> None is not indexable?
<jam> yeah
<lifeless> jam: is that fixed?
<jam> lifeless: fix just committed, thanks for the reminder
<lifeless> jam: jinx :) thanks
<lifeless> jam: so, I'd like to have a copy of python in gcrchk255
<jam> well, gcr is undergoing a lot of flux right now
<jam> but I'm willing to kick of a conversion to have a data point to talk about
<lifeless> jam: not to give them so much as to say, look, this is what we're polishing at the moment
<jam> I suppose the other thing is that I haven't been making the -rich-root variants yet, as I already have too many variants
<jam> but that, again, is easy to fix
<jam> ultimately, I'd certainly rather have rich-root as the default variant
<lifeless> jam: does https://code.edge.launchpad.net/~bzr/bzr-groupcompress/trunk have gcr? or just whats still suitable for bbc ?
<jam> lifeless: trunk does not have gcr
<jam> I'll push up a branch, though
<lifeless> jam: I can't promise to look at it :P.
<jam> lifeless: what is your feeling about disk compatibility
<jam> that's fine
<jam> I'm just trying to decide whether I should leave all-new format strings
<jam> or whether we should somehow support both for a hile
<jam> while
<lifeless> its easy to twiddle them
<lifeless> I do not care about backwards compatibility for repo formats in bbc/gc
<lifeless> they are both entirely experimental
<lifeless> as opposed to beta like devX formats in trunk
<jam> lifeless: lp:~bzr/bzr-groupcompress/rabin  for now
<lifeless> jam: so the rabin index extension
<lifeless> jam: you're having some trouble with that?
<jam> I have it working for now.
<jam> Just by using multiple indexes
<jam> I know how to combine them
<lifeless> right
<jam> but this ended up easier to implement
<lifeless> thats how gc started
<lifeless> oh
<lifeless> I see, nice
<dlee> Any chance there's a bzr<-->MediaWiki versioning solution, much like we have for Bzr<-->Subversion?
<poolie> hello all,
<poolie> hello jam
<lifeless> hi
<jam> morning poolie
<poolie> jam, want to talk in 5m?
<jam> poolie: sure, you can call my cell phone, I have to go pick up my wife at the train station
<poolie> sure
<lifeless> jam: btw, streaming pull is landed to now, at least the first cut thereof
<kees> /home/kees/.bazaar/plugins/hooks/__init__.py:20: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5.
<kees> what should I be using instead?
<mwhudson> kees: install_named_hook
<kees> mwhudson: so, if I had this:   Branch.hooks.install_hook('pre_commit', run_tests)
<kees> I want Branch.install_named_hook now?
<LarstiQ> hey mwhudson
<mwhudson> kees: yes, and you need to pass a name too
<lifeless> kees: Branch.hooks.install_named_hook('pre_commit', run_tests, 'Run my tests')
<lifeless> mwhudson: ITYM "no, keep the hooks component in the object path" :)
<mwhudson> LarstiQ: hello
<kees> mwhudson: cool, great.  is there a way to install hooks only in a given bzr tree?
<kees> mwhudson: right now, I have this as a global hook, and it does:
<mwhudson> kees:
<LarstiQ> mwhudson: I suspect I need to file a new bug re my ssl/proxy troubles.
<mwhudson> um
<kees> def run_tests(local, master, old_revno, old_revid, new_revno, new_revid, seven, eight):
<kees>     if 'ubuntu-cve-tracker' in master.base:
<kees> as a way to only run it for the ubuntu-cve-tracker tree
<mwhudson> kees: you can put
<mwhudson> [/home/kees/cve-tracker]
<mwhudson> my_magic_config = value
<lifeless> kees: use a config variable
<mwhudson> in ~/.bazaar/locations.conf
<lifeless> kees: if not master.get_config().get_user_option('cvs_enabled'): return
<kees> mwhudson, lifeless: ah, interesting, okay, thanks.
<lifeless> kees: then you can enable per branch using branch.conf, or url prefix via locations.conf
<lifeless> jelmer: we're getting a bad pattern on that bug :)
<mwhudson> LarstiQ: probably sane
<LarstiQ> mwhudson: will do tomorrow, to tired to think now
<LarstiQ> ciao
<mwhudson> :)
<Glenjamin> hey guys, are there any docs around on using bzr's functions programatically?
<Glenjamin> i was going to just write a shell script, but i thought error handling would be much neater just using normal python
<beuno> Glenjamin, maybe something like: http://bazaar-vcs.org/Integrating_with_Bazaar
<Glenjamin> ah perfect
<Glenjamin> thanks
<beuno> welcome'
<mxpxpod> jelmer: are there docs for subvertpy?
<igc> morning
<jam> lifeless: i noticed, it breaks brisbane-core when you merge the new streaming code ... :)
<lifeless> jam: :P ><
 * igc breakfast
<james_w> thanks Aaron
<abentley> james_w: np
<james_w> abentley: my reviews won't be counted as votes, correct?
<abentley> james_w: They will.
<james_w> oh, ok
<lifeless> yay netsplits
<kenichi> feeling blind, are there any sort of instructions for loggerhead setup anywhere?
<kenichi> oh hee, nm.
<lifeless> abentley: I intend to move cloning_metadir down to the format, with a signature like Format.cloning_format(self, a_dir)
<lifeless> abentley: this is to allow avoiding more VFS calls
<lifeless> abentley: alternatively, I could do a network version of cloning_metadir; do you have a preference/haven't thought about it ?
<abentley> lifeless: I think it's okay to move it down, but you've got to make sure that format is accurate, then.
<lifeless> abentley: well the goal is to have RemoteBzrDirFormat.cloning_format(a_dir) call self._real_format.cloning_format(a_dir), where a_dir is a RemoteBzrDir
<lifeless> abentley: I think I'll do a network version, for now
<abentley> lifeless: works for me.
<lifeless> abentley: because its not an api change, and thats easier in some ways
<poolie> jam, regarding weave merge
<poolie> i thought i remembered that we would conflict on delete vs change
<poolie> i might be wrong
<abentley> poolie: I think it's not interpreted as a change because the line is moved.
<poolie> really, does weave know about that kind of merge?
<mwhudson> jelmer: are you here?
<thumper> :(
<thumper> looks like not
<mwhudson> lazy students
<jelmer> mwhudson, hey
<thumper> jelmer: why are you awake!
<mwhudson> jelmer: does bzr-git support branching from non-master branches in a repo?
<mwhudson> (please excuse any lack of understanding of git from me...)
<jelmer> mwhudson: not yet, as bzr has no way to address those branche syet
<mwhudson> ok, that issue
<jelmer> mwhudson, bzr git-import will import them though
<mwhudson> git-import will import all branches in a repo
<mwhudson> ?
<mwhudson> jelmer: also, is lp:bzr-git, lp:dulwich the way to get the latest, most fun, bzr-git?
<jelmer> mwhudson, yes, git-import imports all branches
<jelmer> mwhudson, the latest is lp:dulwich and lp:~jelmer/bzr-git/trunk
<mwhudson> jelmer: ok thanks
<jfroy> Hey people.
<jfroy> Are there specific setup instructions for running the bazaar test suite?
<jfroy> I naively tried to run bzr selftest, only to have it immediately die on me with bzr: ERROR: No module named blackbox.test_diff
<lifeless> jfroy: generally you should be running from the source, not from a binary
<jfroy> that is what I did
<jfroy> I went into the source distribution and ran the ./bzr
<jfroy> perhaps I need to force that path on the sys.path first
<lifeless> jfroy: no, shouldn't need to
<lifeless> jfroy: uhm that was from a tarball?
#bzr 2009-03-03
<lifeless> does it say blackbox.test_diff, or bzrlib.tests.blackbox.test_diff ?
<jfroy> Ah, it's working
<jfroy> I, apparently, had not used the . :p
<jfroy> * ./
<lifeless> :)
<jfroy> ERROR: blackbox.test_export.TestExport.test_tar_export
<jfroy>     global name 'tests' is not defined
<lifeless> try ./bzr selftest --no-plugins
<lifeless> if that works, you have a plugin adding tests oddly
<jfroy> Well if I'm running from a source distribution, would it still find any plug-ins?
<lifeless> yes
<jfroy> The system running those tests doesn't have any in ~/.bazaar
<lifeless> ok
<jfroy> but it does in the system-wide bzrlib
<lifeless> this is windows?
<jfroy> Mac OS X
<lifeless> ok
<lifeless> please try anyway
<lifeless> './bzr selftest --no-plugins'
<jfroy> looks good
<jfroy> seems it does load system-wide plug-ins
<jfroy> *eats his tongue* never mind
<jfroy> same error
<jfroy> well, maybe just bite :p
<lifeless> ok
<lifeless> what version ?
<jfroy> 1.12
<jfroy> quite a few failures in blackbox.test_filesystem_cicp
<lifeless> its odd that its only reporting 'blackbox..' rather than bzrlib.test.blackbox...
<lifeless> it makes me think something has gone seriously wrong with module loading
<lifeless> what python version ?
<jfroy> 2.5.1
<jfroy> (apologies for the delay)
<lifeless> vila: was that the bust version?
<jfroy> So aside from that import error and the failures in filesystem_cicp it looks good so far
<jfroy> Are those filesystem tests known failures on OS X?
<james_w> lifeless: your extend_command patch ignores the "plugins_override" parameter that controls whether plugins should be able to override builtins. Is that the desired behaviour?
<lifeless> james_w: yes
<lifeless> james_w: because that patch doesn't support replacing commands at all
<lifeless> jfroy: theres a buggy python on some mac os X's
<lifeless> jfroy: bugs in the tarfile module, and somewhere else, IIRC
<lifeless> abentley: on http://bundlebuggy.aaronbentley.com/request/%3C1235999150.10731.0.camel@flash%3E, it would be nice if the project: Bazaar link was to merge requests, and the actual project-meta-data was a link on the right
<lifeless> abentley: just an oddity but I *always* click on Bazaar and end up where I don't want to be
<lifeless> jelmer: has the network_name stuff been clear enough for you?
<rocky> jelmer: hey, which branch of TracBzr should i use for trac 0.11.3 ?
<jelmer> lifeless, is there any reason for not explicitly comparing that the various bits that make up a repository's stream ?
<jelmer> rocky, sorry, I no longer follow trac-bzr development
<jelmer> rocky, I've only been involved to the degree that we need it for bitlbee
<rocky> jelmer: someone is the lead maintainer or it's simply not being maintained?
<jelmer> rocky, I don't think there has been a maintainer for the past 2 years
<rocky> ouch, that's too bad
<jelmer> rocky, I have been doing some work keeping merging patches people put up until a couple of months ago
<jelmer> s/keeping//
<rocky> gotcha
<jelmer> rocky: There's enough people interested in trac-bzr, there's just no maintainer atm
<rocky> i need it for ClueMapper
<rocky> i want to support bzr as the main repo format instead of svn under my trac
<jelmer> rocky, would you be interested in stepping up as maintainer?
<jelmer> rocky, It shouldn't be a lot of work, as there seem to be enough people proposing patches
<jml> mwhudson: https://code.edge.launchpad.net/~jml/+junk/bzr-establish
<mwhudson> thanks
<jelmer> there just needs to be somebody to review and merge them
<lifeless> jelmer: can you rephrase - 'explicitly comparing that the various bits that make up a repository's stream
<lifeless> '
<rocky> jelmer: it's a possibility
<mwhudson> jelmer: lp:~jelmer/bzr-git/jelmer, not lp:~jelmer/bzr-git/trunk, right?
<jelmer> lifeless, so, rather than defining that repoformat X matches the network representation of repoformat Y, wouldn't it be possible to just compare the serializer format, inventory format, etc?
<jelmer> lifeless, Not suggesting it should work that way, just wondering why it can't work that way?
<jelmer> mwhudson, Yeah, http://people.samba.org/bzr/jelmer/bzr-git/trunk
<jelmer> mwhudson, it requires bzr.dev atm
<poolie> jam, if you're still here, is there any mysterious reason why http://pastebin.ubuntu.com/125544/ is not a valid simplification?
<mwhudson> jelmer: ok
<jml> mwhudson: http://code.mumak.net/2008/10/bazaar-hacking.html ; http://code.mumak.net/2008/10/more-bzr-hacking.html
<lifeless> jelmer: su
<lifeless> jelmer: 'so'.
<lifeless> jelmer: two formats may have the same serialiser but still not want to behave identically
<lifeless> jelmer: (format) is a complete encapsulation of behaviour, and works for things like bzr-svn that don't particularly even have serialisers
<lifeless> jelmer: I think we do want to end up with a complete meta-description, but we're currently adding dimensions faster than verbs are keeping up, so using a format.network_name is future proofing until we're ahead of the curve and can lock-down the round trips for operations and eliminate teh vfs
<jelmer> lifeless: ah
<jelmer> lifeless: That makes sense to me
<jelmer> lifeless, so
<jelmer> lifeless, bb:approve
<nevans> I accidentally rebased a branch, and now I want to get back the original.  what would be the easiest way to find the tip revision ID for the original?
<jelmer> lifeless, as this was the only bit I wasn't sure about
<lifeless> jelmer: well, its all landed :P I was more asking because we have the room to change things if it was interacting badly with bzr svn
<james_w> nevans: "bzr heads" from bzrtools will help
<jelmer> lifeless, ahh
<nevans> bzr heads is taking forever to return... is there some way to point it at the last common revision, and tell me only the descendants of that?
<lifeless> jelmer: I have no desire to make your task *harder* :P
<jelmer> lifeless, it shouldn't affect bzr-svn unless you're pushing from a svn repository to a smart server right?
<nevans> BTW: as an aside, I really like how "bzr uncommit" gives you the original revision id right before it does its work.  ;)
<lifeless> jelmer: or pulling from a smart server with svn behind it
<lifeless> jelmer: so you have several things you can do; you could:
<lifeless>  - return a network_name of a bzr native format [where you claim that your streaming data is that format, and that cloning should create that format]
<lifeless>  - return a unique network_name [where both ends will need bzr-svn installed, but you can potentially stream in a optimised form]
<jelmer> I can't really do (1) sensibly
<jelmer> since it will mean things using Repository.{texts,inventories,revisions} a lot
<lifeless> ok
 * mwhudson gets the feeling he's doing it wrong
<mwhudson> bzr: ERROR: No such file: u'/home/mwh/src/git-play/.git/inventory': [Errno 2] No such file or directory: u'/home/mwh/src/git-play/.git/inventory'
<lifeless> note that pushing from a svn workingtree to a hpss smart server is probably not that common :)
<jelmer> mwhudson, bzr-git doesn't support working trees yet
<jelmer> lifeless, I've seen people do it :-)
<lifeless> mwhudson: its not finished :)
<mwhudson> i guess i should read the README
<mwhudson> jelmer: how can i make it do something interesting?
<lifeless> jelmer: ok; so we can either say 'install bzr-svn on the server' (for 2), or perhaps have a bzr-svn-light that has just the Format objects, no actual capabilities.
<jelmer> mwhudson, bzr.dev branch git://git.kitenet.net/etckeeper
<jelmer> lifeless, there's no fallback scenario in case the network format the server offers isn't supported by the client?
<jelmer> no *generic* fallback scenario
<lifeless> jelmer: no
<lifeless> jelmer: you wanted to avoid people creating branches on the server the server can't open; this does that :)
<mwhudson> jelmer: eh, i thought network support was flaky, did i get the wrong end of the stick
<mwhudson> anyway, seems to be working, yay
<jelmer> mwhudson, pull is the main thing that's flaky
<mwhudson> jelmer: ok
<jelmer> lifeless, well, if the server understands the format a branch is stored in, it could always send it to the client in some generic format that the client udnersatnds
<jelmer> mwhudson, please do file bugs for things you find don't work or don't work well
<jelmer> lifeless, can you explain the bzr-svn-light thing a bit perhaps?
<mwhudson> jelmer: how do you use a dev version of dulwich out of curiosity?  just set $PYTHONPATH
<jelmer> mwhudson, yeah
<mwhudson> fair enough
<jelmer> lifeless, did apt-get find python-subvertpy for you btw?
<mwhudson> jelmer: well for starters, bzr init; bzr pull git:// breaks nastily :)
<mwhudson> init --1.9-rich-root is fine though
<jelmer> mwhudson, whoops
<lifeless> jelmer: no
 * jelmer gets some sleep
<lifeless> jelmer: so, generic formats - yes, we could write a mapping table that says '1.9 is the same as 1.6'
<lifeless> jelmer: and if we tell the client about a format it doesn't understand, it could ask us to translate somehow
<lifeless> jelmer: and similarly client -> server
<jelmer> lifeless, yeah, that's what I meant
<lifeless> jelmer: however, option (2) doesn't have a mapping from 'svn' to 'bzr' at all at the moment:P
<jelmer> ah, in that sense
<jelmer> lifeless, tunneling svn over bzr
<lifeless> jelmer: spiv and I discussed doing this if its needed, but right now there is simply no way to work with a format not mutually known
<lifeless> jelmer: so we felt it was ok to not-improve-the-situation
<jelmer> lifeless: Yeah, I agree
<lifeless> jelmer: go sleep. doing some testing might be good if you get the chance
<lifeless> if we're wrong and it it suddenly problematic, we have 1.5 weeks to get a solution for the beta
<nevans> still waiting for "bzr heads" to respond with anything... in the meantime, I've managed to open a python console and get the base revision before the rebase.
<rocky> jelmer: functionally, if i point repository_dir to some random dir that contained repos that contained various branches.... trac should "think" that the random dir is the base repo right? (for TracBzr)
<nevans> is there any way for me to use the Revision object to tell me its children
<nevans> (I'm very much a python newb)
<jelmer> nevans, fwiw bzr-rebase will store the revid of the revision it is a rebase of
<nevans> jelmer: o rly? :)
<jelmer> nevans, in the 'rebase-of' revision property
<nevans> too easy.  :)
<jelmer> nevans, it's not exposed in the UI, but there under the covers
<nevans> how do I retrieve the revision properties?
<jelmer> rocky, I think some people reported that that bit was broken
<jelmer> rocky, It seemed to be having trouble using more than one bzr repository
<jelmer> rocky, but multiple branches would be fine
<jelmer> rocky, at least that's what I remember reading
<jelmer> nevans, If you have a Revision object, it has a 'properties' member
<jelmer> nevans, Repository.get_revision("some-revid").properties["rebase-of"]
<rocky> jelmer: most trac projects i work with don't really correspond to the lightweight notion of bzr repos... since my trac projects consist of more than one code component and each code component really should get it's own bzr repo
<lifeless> nevans: revision.parent_ids
<rocky> so i guess the multiple repo thing is something that "fits me"
<jelmer> rocky, are you talking about a bzr repo or a bzr branch?
<nevans> jelmer: thanks.  that does it! :)
<rocky> jelmer: well, i have the ClueMapper "project" where it has it's own trac site ... but that project has 5 different libraries that all relate to one another conceptually ... so it seems to me each library should get it's own repo
<rocky> and then each library (which has it's own repo) has it's own trunk and various branches
<rocky> any decent-size project i work on is like that
<rocky> jelmer: so if i call tree.inventory.path2id('') then bzr returns me None if the root of the branch has no files? that seems, odd
<lifeless> rocky: two trees A and B that are both for different projects have different root ids
<lifeless> rocky: at some point between 'null tree', 'new tree' and 'first commit' the id has to be set
<lifeless> rocky: bzr chose to do it at 'bzr add' in the new tree
<rocky> ah
<rocky> lifeless: i'm using launchapd branches for the first time and when i try to push my local branch to a launchpad branch that i just registered it gives on odd error saying the target branch exists but doesn't have a valid .bzr directory ... is that normal?
<lifeless> mwhudson: ^
<mwhudson> rocky: push --use-existing-dir probably?
<mwhudson> rocky: but in general, don't register hosted branches in the ui :/
<rocky> lol
<jam> poolie: http://pastebin.ubuntu.com/125544/ seems fine to me
<rockstar> rocky, seriously, it's best to just push to Launchpad.
<rocky> rockstar: sure, i will from now on...  but i was just following the logical path to do what i needed, so i guess something needs some work there ;)
<lifeless> rocky: yah, it needs to be deleted :)
<rocky> hehe
<rocky> whatever works ;)
<rocky> anyways, bedtime for me
<rocky> night
<lifeless> gnight
<poolie> thanks jam
<poolie> and thanks for the reviews
<mwhudson> dulwich and bzr-git require python 2.5 ?
 * mwhudson sads
<johnf> I'm upgrading my smart server to 1.12. I'm currently running it out of fcgi. Does this still work or should I be using bzr --serve?
<poolie> johnf: hi; afaik it should still work; spiv should know
<lifeless> johnf: it should still work
<lifeless> johnf: please tell us if it doesn't :)
<johnf> Might switch to serve and cook up an init script for the debian package
<igc> igc
<igc> is back
<lifeless> hi igc
<lifeless> johnf: FWIW most folk run over bzr+ssh i think
<poolie> hello igc
<lifeless> johnf: afc runs a live server with --serve, on the internet. He may have a script.
<spiv> johnf: what poolie and lifeless said.
<johnf> spiv: I'm going to move to --serve the fcgi was a pain
<spiv> Fair enough.
<spiv> Which HTTP server?  Apache?
<johnf> yes. Going to use mod_proxy
<lifeless> erem
<lifeless> johnf: --serve isn't http
<poolie> lifeless: did you also say something similar to  https://bugs.edge.launchpad.net/bzr/+bug/322893
<ubottu> Launchpad bug 322893 in bzr "new progress bars only use 80 columns" [Medium,Confirmed]
<johnf> lifeless: ahh :)
<lifeless> johnf: --serve is 'bzr://'. IANA registered protocol.
<johnf> ok back to fcgi then :)
<lifeless> johnf: if you want bzr-over-http, you need mod_python or fcgi or whatever
<lifeless> johnf: you don't need to do bzr-over-http
<lifeless> poolie: yes, I did
<lifeless> poolie: I also filed a bug about comment truncating
<johnf> lifeless: yeah pondering connecting to it directly at the moment
<johnf> should "bzr serve" be logging a whole heap of NotImplemented errors? Works fine but is logging errors
<poolie> probably not
<poolie> like what?
<jml> hello
<poolie> hi
<jml> [-                   ] Transferring:Walking content. 0/36
<poolie> :-}
<jml> I've been pushing up a branch to Launchpad for about 421.534s now
<poolie> srsl?
<poolie> got a trace?
<jml> yes.
<jml> poolie: I've got the bzr log
<jml> poolie: and I'm running with -Dhpss
<poolie> show spiv/lifeless?
<lifeless> jml: version?
<jml> http://paste.ubuntu.com/125595/
<jml> Bazaar (bzr) 1.13dev
<lifeless> johnf: its a bug, fixed in bzr.dev
<jml> from the nightly ppa
<lifeless> jml: revno please
<lifeless> jml: the full package version has the revno in it
<jml> (bzr version should tell me the revno, don't you think?)
<jml> Version: 1.13~bzr8.10-4065-1
<lifeless> jml: (maybe, file a bug on the packaging)
<jml> it's still going, fwiw.
<jml> ok, now it's done
<lifeless> jml: it was reading from 186.818  hpss call w/readv: 'readv', '/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/fee0993f46df016a5650a9004f0f4fdf.pack'
<lifeless> and writing to
<lifeless> 187.201  hpss call w/body: 'append', '/~jml/launchpad/source-package-branch-listing/.bzr/repository/upload/05wh3tplu93ue19c02ok.pack',
<lifeless> jml: I suspect it was filing in missing deltas for files you modified the first time
<fignewman> This is probably a stupid question, but I can't find an answer. I'm using bzr in a simple centralized manner (checkout/commit) and I can't find a command similar to subversion's 'svn st -u' (that is, I want to see what has changed upstream since I last updated)
<lifeless> fignewman: bzr missing
<jml> lifeless: that's quite possible.
<lifeless> jml: so, this is because the streaming code path precludes the pack optimised one, which really is quite fast; we're using the public generic interface to stream
<jml> lifeless: I know what all of those words mean.
<lifeless> jml: -> should be faster on bzr.dev servers, but some possibilities of slower on downlevel smart servers
<fignewman> lifeless: thanks. It's complaining, but I think I know why.
<fignewman> lifeless: would be nice if it defaulted to the branch when using a checkout.
<lifeless> fignewman: possibly;possibly we should do status -u for this case
<lifeless> fignewman: our checkouts are also branches (in that they are a checkout of a branch)
<fignewman> lifeless: is there a way to set a default or should I just use an alias?
<lifeless> fignewman: there may be a canned alias like :master, not sure though
<lifeless> fignewman: you can just do missing --remember
<poolie> jml, i got a tuit to make a debug_flags config option
<johnf> lifeless: if I set post_commit_to in ~/.bazaar/bazaar.conf in the [DEFAULT] section should bzr-email work for all branches?
<lifeless> johnf: yes
<jml> poolie: what for?
<poolie> so people can always capture hpss logs rather than needing to remember it
<poolie> i guess you can use a shell alias
<fignewman> lifeless: --remember doesn't seem to be in my version (1.3.1). For all I know, my issue was long ago resolved anyway. Thanks for the help. This will work nicely.
<lifeless> poolie: you can't pass debug_flags to a smart server
<lifeless> poolie: it would be nice to put them in branch.conf and have it just work :)
<poolie> lifeless: when it's run over ssh you mean?
<poolie> i think what i'm doing will make it read them from ~/.bazaar/bazaar.conf on the server
<lifeless> ok
<lifeless> thats a start :)
<jml> poolie: oh, cool.
<poolie> starts are good :)
<jml> poolie: well, I have -Dhpss
<jml> as an alias.
<jml> poolie: but that sounds like a great idea.
<johnf> lifeless: for bzr-email when the hook runs under bzr serve the op type seems to be "change" instead of "commit" does that make sense?
<lifeless> johnf: yes. Possibly a bug, but probably just de riguer
<johnf> what is a change vs a commit. Should I patch bzr-email to also send email on change or work out why it's change instead of commit?
<lifeless> johnf: change is uncommit/push/pull
<lifeless> johnf: commit is commit
<lifeless> johnf: have you read 'bzr help email' ?
<johnf> yes
<lifeless> it can send mail on change
<lifeless> what bzr-email version do you have?
<johnf> trunk. But the thing is I'm performing a commit not a push. or does a commit become a push over bzr:// ?
<lifeless> johnf: it becomes a push
<lifeless> two-phase commit thingy
<johnf> ahh ok I'll set post_commit_push_pull then
<johnf> you want a patch for the docs to make that more obvious?
<johnf> or would a patch for bzr-email to detect it's running in server mode make more sense?
<lifeless> feel free to make it as lovely as possible
<lifeless> I don't know offhand how easy it will be
 * igc offline for ~ 2 hours
<poolie> [rfc] rename TestCase.get_transport to something like get_test_transport, because it's not interchangeable
<lifeless> poolie: mmm, it could detect absolute urls, but we shouldn't really be using those in tests *anyway*
<poolie> detect them and error?
<poolie> i guess
<poolie> well, actually we commonly do if we have a url from somewhere else
<poolie> foo.base for example
<lifeless> well, we have foo then :) - is this something you're running into repeatedly?
<johnf> any easy way to work out from a plugin if you are running in server mode?
<lifeless> johnf: 16:30 < lifeless> I don't know offhand how easy it will be
<johnf> lifeless: heh I'm going to try for the server_started hook
<johnf> although I have a feeling I won't get the callback
<lifeless> spiv: arrrgh test_stacking failing, sometimes, if you run a specific test before it
<vila> hi all
<johnf> is there a way to get the path to the repo from the branch object? ie if it is chroot-1244:///devel/test I want '/devel/test'
<johnf> or do I just need to regex on branch.base?
<lifeless> its a software chroot
<lifeless> look at bzrlib.transport.chroot
<lifeless> but!
<lifeless> what you probably want is branch.public_location() or whatever
<johnf> lifeless: yeah I'm hacking the public_branch functionality. I adding public_branch_prefix which gets put on the front of everything served by the server
<lifeless> johnf: why do you want the repo at all though
<johnf> as in why am I running a server vs bzr+ssh?
<lifeless> no
<lifeless> as in why do you want the repo at all
<johnf> as in why do I want a central code repository?
<lifeless> no
<lifeless> you said you wanted the path to the repo - /devel/test; thats not usable in the general case by clients, its not relevant for bzr commands, it doesn't really have any use.
<lifeless> so I assume you have a larger use case
<johnf> for the email in bzr-email. ie right now the email is displaying chroot-123:///devel/test or for other branches in that repo chroot-234:///devel/website
<lifeless> and I'd like to know what it is
<lifeless> johnf: branch.public_location() -> print that
<johnf> ie multiple branches serverd by the same "bzr server"
<lifeless> johnf: if thats wrong, the server admin can fix it by configuring in branch.conf or locations.conf
<lifeless> its the same problem as a backend webserver with a squid frontend:)
<lifeless> you have to tell the backend somehow where clients are coming into it from
<johnf> doesn't that assume I set public_location for every branch?
<lifeless> yes, so - if its not there assume branch.base is sane IMO.
<lifeless> as an admin you can set it for all served branches with three lines in locations.conf
<johnf> once per branch or globally for all?
<lifeless> for all
<johnf> ahh that's what I want let me go look that up
<johnf> lifeless: hmm what would I be setting in locations.conf?
<lifeless> in theory; note that you may have found a bug/current limitation - we need more adopters of server side stuff!
<lifeless> [file:///srv/bzr/blah/blah]
<lifeless> public_branch:policy = appendpath
<lifeless> public_branch = bzr://host
<lifeless> then .../blah/blah/b1
<lifeless> will get
<lifeless> bzr://host/b1 as its public url
<lifeless> for instance, I have:
<lifeless> [sftp://bazaar.launchpad.net/%7Ebzr/]
<lifeless> public_branch = http://bazaar.launchpad.net/~bzr/
<lifeless> public_branch:policy = appendpath
<lifeless> "everything I push to lp/~bzr is visible on http://.../~bzr
<johnf> ok let me give it a whirl
<lifeless> the transport chroot may break it
<lifeless> if so file a bug
<lifeless> but thats the _right_ solution
<johnf> and then that should appear in branch.get_public_branch() ?
<lifeless> yes
<lifeless> woo, finally landed that branch
<lifeless> I thought it would never give in and succeed
<johnf> lifeless: just sent you a review request. I have a feeling the way I store wether we are in server mode is a bit of a hack. But my python skills are lacking
<lifeless> johnf: thanks
<johnf> I also have a patch for the locations.conf chroot problem. But I'm trying to find a less hacky solution
<johnf> At the moment I convert chroot-12345:///devel/test into /devel/test  which means you can match it using [/] in locations.conf
<lifeless> I would teach the location config handler that a chroot transport is to be unchrooted, then looked up
<johnf> I'd really like to get at the non-croot path so I could turn the chroot into /srv/bzr/devel/test and match using [/srv/bzr]
<lifeless> keep Branch ignorant of that
<johnf> in config.py?
<johnf> that's where I've been hacking so far. it;s the unchrooting from there that is the trick
<lifeless> bzrlib.transport.chroot
<lifeless> look in there
<crisb> hi, i've got a problem with my bzr where if I do a second commit I get a SHA1KnitCorrupt error - anyone had this before?
<lifeless> no
<lifeless> what bzr version?
<crisb> 1.12
<lifeless> are you on nfs/ftp/sftp?
<crisb> its a branch I got via sftp yeah
<lifeless> does 'bzr check' pass on it?
<crisb> with flying colours
<lifeless> unusual :P
<lifeless> uhm, what does bzr info -v report ?
<crisb> http://pastebin.com/m35a6a43c
<Kamping_Kaiser> can someone explain why i have bzr looking for an svn cache?
<Kamping_Kaiser> bzr status
<Kamping_Kaiser> Initialising Subversion metadata cache in /home/kgoetz/.bazaar/svn-cache/d35b4800-ec1a-0410-b8e8-ae9f3643f637
<Kamping_Kaiser> is this a bug, or a feature i've not noticed before?
<lifeless> Kamping_Kaiser: you have bzr-svn installed, and have run bzr in a svn checkout
<lifeless> Kamping_Kaiser: its doing just in time translation of metadata
<Kamping_Kaiser> lifeless, aaah, that explains it. (i only installed bzr-svn recently). thanks for telling me - i'd forgotten this was an svn dir *heh*
<lifeless> Kamping_Kaiser: that is the idea :)
<lifeless> crisb: this is very odd
<lifeless> crisb: unfortunately its late for me; could you file a bug?
 * Kamping_Kaiser tries it out.
<lifeless> you should get a backtrace in ~/.bzr.log , that backtrace with the version details and so on would be very useful
<crisb> lifeless: sure.  its strange I've tried it on another machine with python2.5.2/bzr 1.11 and all ok.  the branch is taken from a machine with bzr-1.12/python2.6.1
<lifeless> crisb: none of those raise alarm bells
<lifeless> crisb: and check dos a scan of all the texts that could be failing
<crisb> lifeless: bzr check fails as soon as I've done the first commit after branching
<crisb> the sha1 that is corrupt is the one of the last revision
<lifeless> crisb: its fascinating, and AFAIK unique, but I have to halt()
<lifeless> crisb: sorry
<lifeless> jam: vila: either of you might like to look at this ? ^
<crisb> lifeless np ;)
<crisb> about halting that is!
<johnf> lifeless:  just to confirm the functionality. If I have a location of [/srv/bzr] and I have append policy with public_branch = http://bzr.com/ then if a banch lives at /srv/bzr/project/trunk then the public url should be http://bzr.com/project/trunk
<vila> crisb: Did you file a  bug already ?
<crisb> vila: not yet I was just fiddling around a bit more
<vila> crisb: ok, Di you try bzr check just after branching ? And what bzr version do you use on the machine where the bug is occurring ?
<crisb> bzr check just after branching is fine, its bzr 1.12
<vila> crisb: OS ?
<crisb> vila: linux
<vila> crisb: installed from the PPA or from sources ?
<crisb> crisb: its the bzr package which I (mostly) maintain! its mandriva, and built from the official tar ball
<crisb> vila: even lol
<crisb> history is its a import from CVS using cvsps-import.  the import was done on another machine with 1.11
<vila> crisb: Ha ! Mandriva, sorry, didn't match earlier :-/ Help me page in the context, ... yeah that way :)
<vila> crisb: did you run the full test suite successfully ?
<crisb> vila: :(
<crisb> good call, its totally failing today!
<vila> crisb: let's start with that, can you file a bug and attach the selftest output ?
<vila> crisb: try to mention python version, and also versions for supporting libraries like pycurl or paramiko
<crisb> vila: its probably my fault ;) i also package python-pycrypto.....added a little patch for py2.6 ;)
<vila> crisb: np, let us know if you can fix it or how we could help
<crisb> vila: is pycrypto used for sha-1 calcs?
<vila> crisb: I don't think so, but it's used by paramiko and we use paramiko for sftp
<crisb> vila: think my patch is ok then...blackbox.test_aliases.TestAliases.test_aliases shouldnt use pycrypto
<vila> crisb: err, I miss context to follow you there :)
<crisb> vila: that test fails with sha-1 of reconstructed text does not match expected sha-1, but should not touch any code changed by my pycrypto patch right?
<vila> I'm not familiar enough with pycrypto to be definitive here, it may populate some methods that override the ones we use for example
<vila> crisb: you can run 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' with and without your patch to check that
<vila> crisb: using '-s' is really faster in these cases
<crisb> http://pastebin.com/m488db1d9
<crisb> vila: same with and without patch
<vila> crisb: can you try on a 32bits machine with the same config ?
<aboSamoor> I want to commit to my repo from another PC, what I have to do ?
<vila> aboSamoor: how are the two PCs connected ? How can your branch (which use a repo but is not a repo) accesible from the other PC ?
<aboSamoor> vila: I have a launchpad account and I commit using my laptop. I branched it in my PC but I can not commit I got Public Key denied. I did not do anything other than branching.
<crisb> vila: passes on 32-bit
<vila> crisb: here we are :-/
<vila> crisb: can you file a bug ?
<crisb> vila: sure.
<crisb> vila: seems unlikely that no bzr developers use 64-bit though?
<vila> crisb: with python2.6 ?
<vila> crisb: I try to test many combinations, but I lacked that one, I have 32bits/2.[456] and 64bits/2.5 myself + OSX 10.4 but I've yet to automate that...
<vila> I'm setting up 64bits/python2.6 right now, but until I make a diagnosis there, that sounds a lot like a python bug, we shouldn't have to take care of that...
<lifeless> [getting a drink] try removing the .so files in bzrlib/
<crisb> vila: i swear this has been working :|
<lifeless> johnf: yes; its in the docs that this works too :)
<lifeless> johnf: bzr help configuration
<vila> crisb: that's what bugs are about :)
<lifeless> [gone again]
<Coke> One file was locally removed, how do I update just that file from the remote branch?
<luks> bzr revert it
<vila> crisb: by the way, can you do the same tests with python2.5 ? 32 and 64 ?
<Coke> Oh
<Coke> that is so ugly
<Coke> what happens if one file is deleted, some other are changed and I do revert on that directory? all changed files reverted to?
<luks> revert just the specific file
<luks> bzr revert my/removed/file.c
<crisb> vila: 337183
<vila> crisb: ask ubottu instead #337183
<vila> huh ? bug #337183
<ubottu> Launchpad bug 337183 in bzr "tests fail with sha-1 corrupt on bzr-1.12/python2.6 64-bit" [Undecided,New] https://launchpad.net/bugs/337183
<vila> thanks
<crisb> vila: have a sneaky feeling 1.11 was ok
<vila> crisb: you used 2.6 with bzr-1.11 ?
<crisb> yeah
<vila> crisb: do you have 2.5 available on your 32/64 machines ?
<crisb> no unfortunately :(  i've tried 1.11 on a 32-bit machine with py2.5
<vila> crisb: hmm, no 1.11/2.6/64bit where you can run 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' ?
<vila> crisb: in fact we are in kind of opposite configs :-) I have to build 2.6 from source...
<crisb> heheh
<crisb> i can try to get a 1.11
<crisb> vila: bzr's fault ;)
<crisb> vila: at least it proves i'm not going mad!
<vila> crisb: by that you mean you ran 'bzr selftest -s bb.test_aliases.TestAliases.test_aliases' on 1.11/2.6/64bit machine ?
<vila> and it passed ?
<crisb> vila: yep, straight off
<lifeless> crisb: did you try removing the .so's ?
<crisb> lifeless: bzr extension so's? no.
<lifeless> try then :)
<vila> lifeless: sorry I thought you were talking to johnf, what do you have in mind with the so ?
<lifeless> vila: removing them
<vila> lol
<lifeless> vila: eliminates non-python code
<vila> crisb: I can't reproduce here with bzr.dev python 2.6 built from sources, no bzr extensions so far
<vila> crisb: correction, I have bzr extensions
<lifeless> also note that all of ubuntu's devs are on 1.12 now
<lifeless> sorry
<lifeless> I mean 2.6
<lifeless> so we should be seeing this very widespread
<vila> lifeless: with jaunty ?
<lifeless> yes
<crisb> vila: ok so now its weird, i've just reinstalled bzr 1.12 RPM and all is fine....
<vila> crisb's fault :-)
<crisb> vila: it always is! lots of bugs here
<vila> crisb: np, better safe than sorry
<vila> crisb: Can I mark  #337183 as invalid or do you intend to try harder to make it fail again ? ;)
<crisb> vila: lets invalidate it, not sure what I can do to reproduce.  apologies for the waste of your time
<vila> crisb: np, helping users is never a waste of my time
<crisb> can I get a diff of revision 1-4 without 3 somehow?
<rocky> lifeless: don't suppose you know the easiest way to get the ancestry of a particular file id ?
<rocky> apparently workingtree used to have a private _get_weave() method that could then get the ancestry from
<james_w> rocky: you mean the list of revisions that touched a particular file id?
<rocky> james_w: maybe... i'm trying to work with someone elses code that used self.tree._get_weave(file_id).get_ancestry(rev)
<rocky> _get_weave doesn't exist anymore it seems
<james_w> ah
<james_w> I'm not sure exactly what replaced it
<james_w> or even what that did, sorry
<james_w> rocky: I think you need to go through VersionedFile now
<rbriggsatuiowa> is there a way to get merge to tell me what revisions it is merging in?
<rocky> james_w: if i have the repo and branch for the file_id, what's the stndard way to get the VersionedFile obj?
<rocky> dir() yields me a bit too much ;)
<james_w> rocky: not, sure, never done it :-)
<james_w> repository.revisions
<james_w> that gives you a VersionedFiles
<RaceCondition> how do I convert a git repository to a bzr one?
<RaceCondition> while keeping the history
<Lo-lan-do> RaceCondition: There's a bzr-git plugin, but it's not complete yet.
<RaceCondition> so it's not possible yet?
<Lo-lan-do> It should be possible for one-time migrations.
<Lo-lan-do> I wrote http://lists.fusionforge.org/pipermail/fusionforge-general/2009-January/000004.html which has a section on bzr/git interoperability.
<Lo-lan-do> But there's been some activity on bzr-git lately, so hopefully it'll reach its full feature set soonish :-)
<james_w> rocky: yeah, not sure, it's not obvious to me that VersionedFiles exposes the per-file graph like that
<RaceCondition> Lo-lan-do: a one-time migration is what I need
<RaceCondition> I could simply lose all the history too without much problem though
<Lo-lan-do> RaceCondition: Then bzr-git should work.
<RaceCondition> Lo-lan-do: OK, thanks
<vila> jam: ping
<vila> jam: when is CHKMap.iter_changes() used ?
<jam> morning vila
<jam> whenever someone feels like it, I guess :)
<jam> I think it is used as a custom InterTree method
<vila> :-)
<jam> for CHKRevisionTree.iter_changes()
<vila> ENOTFOUND
<jam> vila: CHKinventory.iter_changes() calls down to self.id_to_entry.iter_changes()
<Kobaz> yeah
<Kobaz> er
<jam> And I believe the default InterTree.iter_changes() calls tree.inventory.iter_changes()
<vila> yup, self.target.inventory.iter_changes(self.source.inventory), thanks
<vila> jam: well, it's not exactly the defaut, but I want to remove the hack that leads to that call by adding a proper InterTree optimiser
<vila> see bzrlib/tree.py line 926
<jam> vila: aren't "CHKRevisionTrees" just RevisionTrees ?
<vila> jam: I think so :-) Hence ENOTFOUND :)
<jam> ah, ok
<jam> I would like to not introduce CHKRevisionTree unless we have to
<vila> I want to remove the XXX but keep the implementation, so I don't intend to change anything else
<Kobaz> yeah
<Kobaz> er
<vila> i.e. is_compatible will be try: source and target defines id_to_entry return True except: return False
<jam> vila: ah, sure, sounds like a good plan
<vila> jam: the only problem is to find *where* to put that :-) As it seems I need to call it InterCHKTree (or InterCHKRevisionTree) even if none of these objects exist...
<vila> jam: revisiontree.py to start with ? Will we ever add a CHKMap to dirstate ?
<jam> so, you'll need to create a new Inter object, yes
<jam> CHKMap w/ dirstate...
<jam> we *will* want a custom implementation
<jam> probably something that 'chains' changes
<jam> specifically, dirstate can find the difference from the source tree to the basis tree quickly
<jam> and then you want to compute the different from the basis to any other tree
<jam> which should make "bzr diff -r XX" fast
<jam> That is pretty low on *my* priority list, though. As it is fairly complex, and not a common op
<vila> jam: ok, so InterCHLRevisionTree to start with, I'll define it in revisiontree.py then
<Kobaz> i would love to be able to do a bzr diff while in the process of a bzr commit
<Kobaz> i used to do that with svn all the time
<vila> Kobaz: bzr commit --show-diff
<Kobaz> yes i know
<awilkins> What about qcommit (look at list of diffs, clickity)
<Kobaz> but it would be nice to be able to selectivly show individual files
<jam> vila: Why not CHM ?
<jam> :)
<Kobaz> i want a non-gui
<vila> jam: lol
<Kobaz> i dont see why the affected files have to be locked for reading
 * vila would prefer a record-laughter/send-url to just 'lol'
<jam> Kobaz: the file that is locked is the meta-info file
<jam> which we have plans to change so it doesn't cause this problem
<jam> it just is low priority right now
<Kobaz> nifty
<jam> versus other thinsg
<Kobaz> yeah
<vila> Kobaz: you want a non-gui yet you can't fire a diff while committing ? You mean commit fire you editor but you don't consider your editor as a GUI ? (Trying to understand where you encounter the problem)
<RaceCondition> I'm trying to commit over HTTP/WebDAV but getting Transport operation not possible: http does not support mkdir()
<Kobaz> vila: non-gui as in non-x
<awilkins> e.g. - you're using `screen` and want to check the diffs in another terminal while the commit dialog waits
<awilkins> (editor being e.g. vim)
<Kobaz> vila: i'm generally working in two or three ssh sessions to the same system
<Kobaz> so i'll use emacs in one, to make my commit, and do diffs in another iwndow
<RaceCondition> I've set up the DAV lock file and HTTP basic auth, pull works fine, but not push/commit
<Kobaz> right now with bzr commit --show-diff, i do a split window, it seems to work out, but i really prefer to be able to navigate the tree and just say... i wanna do this file
<vila> Kobaz: have you tried dvc ?
<Kobaz> what's that?
<vila> Kobaz: ok, have you tried diff-mode in a buffer containing the output of 'bzr diff -rsubmit:' ?
<Kobaz> nope
<Kobaz> it sounds like it would be cool
<vila> Kobaz: dvc is a layer above that, a package that aim to provide the same UI than pcl-cvs was providing but for all DVCS
<Kobaz> mmm, i've never used diff-mode, that's pretty cool
<vila> Kobaz: my work cycle is: hack, get a buffer with 'bzr diff' in diff-mode (dvc-diff provides that and some additional niceties) from there I can do C-c C-c and it opens the file at point in that exact position (line and char) C-c C-a apply/revert the hunk at point
<Kobaz> i need to change my colors though, some text is black on black, heh
<vila> Kobaz: it makes appyling/reverting any hunk a breeze
<vila> Kobaz: and more importantly allows me to navigate between all the files I'm modifying
<vila> Kobaz: I know no other IDE that can beat that
<Kobaz> yeah
<Kobaz> sexy
<vila> Kobaz: Oh, and I almost forget: when commit time is near: C-x 4 a in any hunk create the ChangeLog entry (remember to create the ChangeLog file at your project root though)
<Kobaz> mmm
<vila> Kobaz: So I *prepare* my commit in ChangeLog by doing multiple reviews of the diff buffer far before committing
<LarstiQ> jelmer: I don't know if you uploaded bzr-svn to the ppa, but 0.5.2 is only in hardy
<vila> Kobaz: So I never need to look at diffs when committing, I just copy/paste my already prepared messager
<Kobaz> mmm
<Kobaz> ionteresting
<Kobaz> interesting
<RaceCondition> does bzr not handle tildes (~) in URLs well?
<Kobaz> have you studdied the logs
<Kobaz> er
<awilkins> RaceCondition: I know it doesn't understand them for bzr+ssh://
<RaceCondition> awilkins: http+webdav is what I'm using
<RaceCondition> it "normalizes" ~ to %7E
<RaceCondition> and then Apache makes an automatic permanent redirect which bzr errors on
<awilkins> RaceCondition: Not tried it ; but is the user on the server the owner of the home folder you are aiming at?
<RaceCondition> awilkins: the home folder, yes, but not the part that is accessed via WebDAV
<RaceCondition> does it matter?
<awilkins> I'm not entirely sure over WebDAV
<RaceCondition> hmm, well, I changed to absolute paths instead of ~, but getting different errors now
<RaceCondition> has anyone verified that the webdav plugin actually works?
<rocky> jelmer: ping
<Keybuk> remind me who does "bzr fast-import" :)
<Keybuk> bzr: ERROR: Bad restart - attempted to skip commit :3 but matching revision-id is unknown
<Keybuk> :-(
<jelmer> rocky, pong
<jelmer> Keybuk, igc (Ian Clatworthy) does fast-import
<james_w> Keybuk: that's igc
<james_w> Keybuk: are you using the latest lp:bzr-fastimport ?
<Keybuk> james_w: afaik
<james_w> ok
<james_w> that was either fixed recently, or caused recently
<james_w> I guess it must be the latter :-)
<jelmer> LarstiQ, I uploaded 0.5.2 to Hardy at Barry's request
<Keybuk> oh, no, I'm out of date
<Keybuk> ssh'd to the wrong machine when I checked
<Keybuk> let me pull and try again
<james_w> jelmer: would you be willing to sponsor an upload to Debian this week?
<rocky> jelmer: just curious, some TracBzr code is calling _get_weave(fileid) to in order to get merge history but in some versino of bzr _get_weave() disappeared... do you know a better way to track down merge history for a fileid ?
<Keybuk> james_w: still fails with current HEAD
<LarstiQ> jelmer: ah
<jelmer> james_w, yes, happy to sponsor
<james_w> jelmer: cool, thanks, I'll put details in a mail
<jelmer> rocky: Repository.texts might have some function that can return ancestry
<rocky> oh cool
<rocky> jelmer: just so i'm familiar with terminology here... what exactly is a "weave" in the context of bzr? is it a repo format, or just some technique for relating things or ?
<james_w> one annoyance with the hook to provide a starting commit message is that it means you can't exit without changes to cancel the commit
<jelmer> rocky, it's a place where revisions for a particular file are stored
<jelmer> rocky, it no longer exists in newer repositories
<rocky> ah i c
<jelmer> rocky, has been replaced with Repository.texts
<rocky> gotcha
<jelmer> rocky, which manages all revisions of all texts
<rocky> i'm looking at VersionedFiles (which is what .text is an instance of ) but it seems rather low level with no functions that work with fileid's
<jelmer> rocky: Keys are a tuple of (fileid, revision)
<jelmer> rocky, VersionedFiles is generic
<rocky> ohh
<rocky> that makes sense
<rocky> so looks like annotate may give me the ancestry i need
<rocky> strange, doesn't seem obvious how to get a VersionedFile instance from VersionedFiles
<jelmer> rocky: annotate will give you the contents
<jelmer> rocky, not the ancestry
<jelmer> you may need to use bzrlib.graph.Graph combined with Repository.texts.get_parent_map
<rocky> yeah right now i'm eye'ing VersionedFile.get_ancestry() which seems to do what i need...but it's not obvious how to get a VersionedFile from a repo when i have the current file_id and rev
<rocky> or is VersionedFile not really used anymore?
<rocky> (since it was tied to Weave it seems)
<rocky> sorry if i'm acting like a noob on this, i'm trying to get more comfortable with bzrlib flow of things so i can be more useful :)
<jelmer> it was the base class for Weave's and Knit's
<jelmer> rocky, no worries
<jelmer> rocky, I think yu want bzrlib.graph.Graph(repo.texts.get_parent_map)
<jelmer> rocky, I think yu want bzrlib.graph.Graph(repo.texts.get_parent_map).iter_ancestry([(myfile, textrevision)])
<mxpxpod> jelmer: hey... I was wondering if there are any docs for subvertpy
<jelmer> mxpxpod, pydoc subvertpy :-)
<jelmer> mxpxpod, other than that, I'm happy to answer questions about subvertpy or update the docs where necessary
<jelmer> mxpxpod, more dosc were added recently, so be sure you're running from lp:subvertpy
<mxpxpod> jelmer: how would I update a repo with a self-signed certificate? I get an exception saying the server certificate verification failed: issuer is not trusted
<jelmer> mxpxpod, specify an Auth handler when opening RemoteAccess
<jelmer> mxpxpod, the Auth handler should contain a SSL server certificate checker
<mxpxpod> jelmer: I was using c = client.Client(); c.update(['/path/to/checkout'])
<jelmer> mxpxpod, try something like this:
<jelmer> c = client.Client(auth=Auth([my_ssl_checker]))
<mxpxpod> jelmer: and what is my_ssl_checker?
<jelmer> see bzrlib.plugins.svn.auth.create_auth_baton for an example
<mxpxpod> ok
<jelmer> mxpxpod, HTH, if not, I should be around again later tonight
<mxpxpod> jelmer: ok, thanks for the help
<jelmer> or feel free to email me, and I can add a trivial example to the bzr branch
<mxpxpod> jelmer: awesome, I'll do that
<mxpxpod> jelmer: that worked great, thanks!
<phinze> i feel bad, but i keep getting frustrated when someone else eats my commits to our trunk
<phinze> and the log starts looking like 2345: merging from remote, 2346: merging from remote
<phinze> with all of the actual messages as subcommits
<beuno> phinze, you can set an append-only policy
<beuno> so nobody can do that
<radix> phinze: That can actually be a good thing, depending on your development methodology
<beuno> they'd have to change the workflow
<beuno> as in, have a checkout of trunk, and merge changes *into* that from other branches
<radix> phinze: if you do feature/fix-per-branch, it works out quite well: the merge commit shouldn't just say "merge from remote", but actually describe the feature or fix
<radix> then it's easy to generate a news file for a release :)
<phinze> well it's more like #123 my change, #124 a merge of everyone elses changes while i was working, #125 my other change, #126 a merge of everyone elses changes while i was fixing thta
<phinze> or i suppose the order would be flipped
<phinze> with the merges coming before the changes
<beuno> phinze, right. So, set append only policy to trunk
<beuno> and tell everyone to change the workflow to the one I mentioned above
<phinze> beuno: yeah i suppose that's the way to go
<phinze> not sure if i have the clout to force other people into that workflow though
<beuno> phinze, just set the append only flag, and the rest will happen on it's own   ;)
<phinze> beuno: oooo you are talking about a setting i can make
<beuno> phinze, of course
<beuno> append_revisions_only
<phinze> okay, i like that, so what will the offending coworkers experience then
<beuno> :)
<phinze> they branch trunk locally, make changes (while other commits are being made to shared trunk)
<phinze> then they want to push
<phinze> and shared trunk denies them?
<beuno> yes
<beuno> set it in on branch.conf of trunk
<phinze> cool, now when they come to me with their local branch in that messy state... how do i get them out of it? :)
<beuno> well, they will get denied merging and pushing
<beuno> which is when you explain
<beuno> they should have a checkout
<beuno> merge into that, and commit
<beuno> so no push involved
<phinze> gotchya
<Ollie_R_> hey if i do a bzr push it keeps this info i.e.. bzr info displays it so it must be recored. Is there anyway to remove this?
<beuno> Ollie_R_, in ~/.bazaar/locations.conf
<Ollie_R_> beuno: just manually edit it?
<beuno> Ollie_R_, yes
<Ollie_R_> beuno: perfect thanks
<beuno> phinze, so you edit .bzr/branch/branch.conf
<beuno> and add: append_revisions_only = True
<jam> phinze: I'm sure you have the clout, since if you set the policy, everyone's client will complain if they don't :)
<phinze> jam: that's always the best way, no? :)
<jam> phinze: well, don't you have a developer meeting this afternoon anyway?
<jam> Just tell them that jam on IRC said that this is the 'one true way'
<jam> :)
<jam> (seriously, though, checkouts of trunk are a great way to go)
<phinze> jam: lol you know too much about our group.  dev mtg is thursday and it's on the agenda.  we'll set the policy after the meeting gives fair warning.
<phinze> yeah i've got the important players to agree with me
<jam> (and having updates show up as "merged feature XXX" is another really good thing)
<jam> especially when combined with 'bzr log --short -r -10..-1'
<phinze> and the fact that you can set the policy on the shared branches is golden
<jam> right, so with the policy set, you don't *have* to use a checkout
<jam> they could still push/pull
<jam> as long as they manage to maintain the history correctly
<phinze> jam: hah, keith was just talking about your favorite log format
<jam> *but* a checkout will help maintain that much easier
<phinze> oh i didn't know about -# notation, i've been wasting keystrokes on last:#
<jam> phinze: also '-#' works better in aliases, IIRC
<jam> if you do 'bzr log -r -10..-1' but there are only 5 revisions, it still works
<jam> I think 'last:10' might give an error about there not being 10
<phinze> cool
<CaMason> I'm on windows, and using `bzr diff --using=BCompare` which launches my diffs on a file-by-file basis. Is there a way to get the entire diff output as one 'temp' file?
<awilkins> jelmer: Ping?
<eydaimon> are there any variables I can use? Such as $author$ etc?
<awilkins> eydaimon: No keyword subbing yet
<eydaimon> thanks
<lifeless> rocky: list(Graph(parents_provider=t.branch.repository.texts)._make_breadth_first_searcher([(file_id, revision])))
<lifeless> rocky: thats roughly the replacement for the line of code you quoted, if you really need that :P
<Ollie_R_> is it possible to turn a heavyweight checkout into a lightweight checkout after If I have already done a checkout or bound to a repo
<beuno> Ollie_R_, bzr reconfigure --lightweight-checkout
<Ollie_R_> beuno: again many thanks
<beuno> Ollie_R_, you're very welcome
<beuno> hiya lifeless
<beuno> you're up early, aren't you?
<lifeless> fsvo up
<beuno> my best guess of what that means is "my fiancee woke me up"
<lifeless> for some value of up
<beuno> :)
<rocky> lifeless: yeah, that looks good, course i was a little scared by the fact that Graph's constructor says it should rarely be used ;)
<lifeless> rocky: it should be rarely used
<lifeless> rocky: accessing all of history like that isn't generally a good idea
<rocky> lifeless: of course now you have me using another private method ;)
<rocky> _make_breadth_first
<lifeless> hi mneptok
<mneptok> ahoy
<mneptok> irssi is strange.
<lifeless> irssi, life, ce la vie
<lifeless> lol, again with the softpedia - http://linux.softpedia.com/get/Programming/Version-Control/bzr-search-40745.shtml
<sidnei> lifeless: evil! what text indexing does it use? xapian? lucene? something else?
<beuno> sidnei, of course, it's something custom lifeless wrote
<beuno> using existing libraries is for wimps
 * awilkins thanks sidnei for answering a question on his brainstack about "wtf is lucene"
<awilkins> Yeah, how can you be sure that existing libraries will have exactly the right bugs?
<awilkins> mneptok: irssi is awesome
<awilkins> jelmer: Ping?
<lifeless> sidnei: its a trivial text index I wrote using bzrlib primitives, java bindings were too nasty, and xapian was too local-only for my taste
<sidnei> lifeless: solr might be an option, it's lucene with a http frontend, rest-inspired api, works around both issues.
<lifeless> sidnei: well, won't work over ftp :P [the current index does]
<lifeless> sidnei: also it would seem to require running up a large infrastructure to answer 'bzr search foo' from vim, which is concerning :)
<lifeless> sidnei: thats actually my main concern for this; xapian would have been nearly ideal with its embedded design
<lifeless> anyhow, the result is fast enough to do search completion for loggerhead :)
<lifeless> beuno: is there a demo site showing that still?
<sidnei> lifeless: been burnt by xapian myself. there's some great python client support for solr though, we've used it for replacing the built-in search in plone
<beuno> lifeless, http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/files
<beuno> Peng_ rocks
<lifeless> sidnei: I will poke at it
<lifeless> beuno: oh, I should merge that I guess, remind me tomorrow
<lifeless> sidnei: go to the url beuno just linked
<lifeless> sidnei: search box in the top right, type stuff in. You can't down arrow into the results yet
 * lifeless looks at beuno
<lifeless> sidnei: so you have to click
<sidnei> lifeless: looks cool!
 * beuno hides behind his piles of work
<lifeless> sidnei: if you hit enter you get the non ajax search page for whatever you had been typing
<beuno> lifeless, although, now that it's been YUI-ified, I have a pretty good idea how to do that
<beuno> not that I have the time to implement it, but maybe I'll manage to trick someone
<sidnei> lifeless: very nice
<sidnei> lifeless: fyi, if you ever look at solr, this is a good start to look at how to integrate it with an existing system http://pypi.python.org/pypi/collective.solr/
<lifeless> thanks
<mneptok> awilkins: alternate_nick cannot be defined in the main core section of the config file. it has to be defined in a separate core param elsewhere. weird.
<lifeless> thumper: the bzr-playground mirror-log file is inaccessible now
<lifeless> thumper: also the bzr-search indices for trunk seem awol
<lifeless> Jc2k: do you still have your imports with search?
<Jc2k> lifeless: it all just forwards on to bzr-playground now
<Jc2k> there were some old imports on the playground box in my home directory
<mwhudson> jelmer: ping
<rockstar> jelmer, hello!
<savvas> /usr/lib/python2.6/dist-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead <- I suppose this will be fixed for bzr (if it wasn't already) :)
<mwhudson> savvas: well, hashlib isn't present in 2.4, which bzr still runs with
<savvas> ah, I see
<mwhudson> so, "yes", i guess, but it's not totally trivial
<savvas> mwhudson: is there a list with what would possibly break with python 3?
<mwhudson> i have no idea, but i imagine the list would be rather long
<mwhudson> i think the unicode/str stuff probably makes a mess
<savvas> thanks for the information, good to know what to expect :)
<igc1> morning
<poolie1> hi igc
<poolie1> jam (over here), i was tempted to look at some of the highest bugs, but
<poolie1> that's probably actually a distraction from brisbane core
<jam> morning igc
<igc> poolie1: hi. I'm probably going to hit the review queue today
<jam> igc: what is your comfort level for doing some testing with groupcompress+rabin?
<igc> hi jam
<jam> I've just finished a couple rounds of updates
<poolie1> i'd really like to get that running on orcadas
<jam> and while I'm going to be working on changing the actual layout a bit next
<poolie1> if the conversion speed is getting better i'd even think about not using pre-canned data
<jam> I think I have the compressor/decompressor pretty well settled
<mwhudson> jelmer, Jc2k: either of you here?
<jam> poolie1: I don't think it is in the 'good enough' stage yet
<igc> poolie1: yesterday was unproductive - slept much of the day
<nua> Hi all, quick question: Does a branch always have revision no. 1 as its first revision? or could it be something strange like 0.1?
<igc> jam: can I get some help with chk_map.iter_changes()?
<igc> jam: I'd like to know when excluded_keys ought to be populated
<Jc2k> mwhudson: sup
<jelmer> mwhudson, hi
<Jc2k> ha
<jam> igc: so... I believe robert was the original author of that code, and I don't have a tremendous handle on it. But I'll try to help when I can.
<Jc2k> jelmer: great timing :)
<jelmer> Jc2k, somethign is weird here today
<jelmer> I had the same thing with james_w a bit earlier
<jam> robert went with a sort of 'priority queue' (heap) to determine what keys should be checked next
<mwhudson> :)
<jam> in general, you have 3 states
<jam> keys which are in the 'known uninteresting' set
<jam> keys which are in the 'known interesting' set
<jam> and keys that you don't know yet
<mwhudson> jelmer, Jc2k: is the dulwich dependence on python 2.5 a deep thing?
<jelmer> mwhudson, not really
<jam> known uninteresting is a sha1 sum that you have seen on both sides
<jam> obviously no changes there
<jelmer> mwhudson, it's mainly just laziness
<mwhudson> i have a terribly terribly awful branch that seems to make it work on 2.4...
<jam> so all children of those keys can be excluded
<jam> known interesting is more difficult
<mwhudson> lp:~mwhudson/dulwich/2.4-hacking i think
<rockstar> jelmer, if you think it's worth it, I'm willing to clean up the awfulness of that branch.
<jam> it is a sha1 sum that doesn't exist on the other side, and you *know* that it isn't possible to find it
<jam> for example, if the prefix on side 1 doesn't have an 'A' record, then you know the sha1 underneath 'A' is interesting.
<mwhudson> of course maybe we'll actually be able to use 2.5 before this is super important
<jelmer> mwhudson, rockstar: that would be nice
<mwhudson> jelmer: cool
<jam> So 'excluded_keys' sounds like things that are "known_uninteresting", though I haven't really dug through the code (yet)
<mwhudson> jelmer: also the dulwich tests fail on trunk for me
<igc> jam: right
<poolie1> nua: the first is always 1
<nua> poolie1: excellent, thanks :)
<poolie1> jam: compression speed not good enough to convert on every benchmark, or not good enough to field it?
<mwhudson> dulwich.tests.test_pack.TestPackData.test_iterentries
<poolie1> orcadas is sad about the hardy upgrade, it keeps saying
<poolie1>  /srv/benchmark.bazaar-vcs.org/bzrbench/bin/monitor-load.sh: 18: 1236118801: not found
<poolie1> so i'll probably fix that first
<poolie1> nice error though: )
<jam> poolie1: not good enough to convert on every benchmark
<Jc2k> mwhudson: that test never passed for me on my main laptop, but i think i have seen it pass somewhere :/
<jam> poolie1: time bzr pack on a python.org repository gc+rabin+chk255 is 30 minutes
<mwhudson> Jc2k: nice
<jam> I'm not sure how long a conversion is
<poolie1> ok, so igc did write this nice new pre-canned data thing
<poolie1> we can use that
<mwhudson> Jc2k: i bet its a 64 bit, 32 bit bug
<jam> poolie1: though as for my 'improvements', that is down from 1.8hrs yesterday
<igc> jam: can you taz.bz2 that python branch and upload it to orcadas?
<Jc2k> mwhudson: ooh, it never passed on my 64 bit laptop *i think*
<jam> igc: I'm not sure that I have access to orcadas, and I'm pretty sure .bz2 isn't going to pack it any better :), but I can upload it somewhere
<mwhudson> i love the readable error
<mwhudson> it's so easy to see which things aren't equald
<igc> jam: if therer's a matching 1.9 branch, we'd like it uploaded as well
<igc> jam: the tar.bz2 format is just what usertest expects to find as source input
<jam> igc: sure
<igc> tar.gz is fine as well
<igc> jam: is your rabin branch available somewhere as well?
<poolie1> gzip -1 then
<jam> igc: lp:~bzr/bzr-groupcompress/rabin
<mwhudson> basically it comes down to
<mwhudson> -901046474 != 3393920822
<mwhudson> but
<mwhudson> -901046474&0xffffffff == 3393920822
<jam> mwhudson: just to mention zlib.crc32(text) returns a signed 32-bit PyInt on 32-bit platforms, and a signed 64-bit PyInt on 64-bit platforms. However as crc32 is a 32-bit object, it shows up negative in 32-bit platforms and *positive* on 64-bit
<mwhudson> i.e. it is some kind of clipping thing
<jam> I don't know where else that happens
<jam> but we ran into it in our code
<mwhudson> i doubt git is using crc32 somehow
<mwhudson> but yes, it's something like that
<mwhudson> Jc2k: should i file a bug?
<igc> jam: any thoughts on how long before you'll be ready to merge that into the groupcompress trunk?
<jam> igc: So I think the compressor / decompressor are good
<jam> And certainly faster than gc-trunk
<jam> I don't have a pure python implementation yet
<jam> (not sure how much I'm going to bother, potentially I'll use the old GC code as the python impl)
<igc> jam: groupcompress needs a Makefile then :-)
<jam> igc: python setup.py build_ext -i
<jam> works fine here :)
<Jc2k> mwhudson: *nod*
<jam> igc: I'm uploading: python-gcr255-rr2.tar to my home directory on orcadas now
<jam> It tells me that I should expect it to get there in about 2 hours
<ronny> jelmer: is there any git cappability that tells if old/new objects are supported?
<igc> jam: ah - cool. I wasn't sure if that only handled std plugins. If it works for other plugins installed as well, that's neat.
<jam> igc: well doing it in *bzr* won't build the plugin, but doing it in the plugin directory works fine
<jelmer> ronny, in the protocol you mean?
<ronny> jelmer: in the repo itself
<jelmer> ronny, no
<jam> igc: anyway, the next step is to change how labels, etc work. Which is a fairly major change to the bytes-on-disk
<jam> which is sort of what I was waiting for
<jam> I suppose I could land it earlier rather than later
<ronny> jelmer: ah, k, sad
<igc> jam: no hurry
<mwhudson> Jc2k: https://bugs.edge.launchpad.net/dulwich/+bug/337483
<ubottu> Launchpad bug 337483 in dulwich "dulwich.tests.test_pack.TestPackData.test_iterentries fails on a 64-bit system" [Undecided,New]
<igc> jam: my focus is trying to get log -v faster and it just isn't in the small tests I've done to date
<jam> igc: you might look at 'iter_interesting_nodes' which is a different approach to culling chk pages
<jam> I don't know if it is specifically faster/slower
<jam> just a different ordering
<igc> jam: yeah, I'm yet to digest the last 50% of the chk_map code
<jam> anyway, I'm done for the night
<jam> later guys
<igc> jam: night and thanks
<poolie1> night jam
<poolie1> and thanks for the roadmap updates
<igc> spiv: has http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E landed yet?
<poolie1> lifeless: is there actually a bzr-gc plugin or am i just dreaming?
<igc> poolie1: bzr-groupcompress
<spiv> igc: not yet; I need to take another look at it now that vila has landed related changes for HTTP network activity reporting
<spiv> igc: partly because I should probably reuse some of the code, and also to be sure it won't cause double-counting of bzr+http traffic.
 * igc breakfast
<nua> I'm trying to get the id of the first revision in a branch using bzrlib, but branch.get_rev_id('1') is throwing an exception: BzrBranch6('file:///home/testuser/test/revnotest/') has no revision 1
<nua> ...there must be a neater way of doing this!
<spiv> nua: have you tried branch.get_rev_id(1)
<spiv> nua: i.e. the revno you pass in should be an int, not a str.
<nua> spiv: yes, it says its not a valid revno
<spiv> what is branch.last_revision_info()?
<spiv> nua: branch.get_rev_id(1) works for me.
<nua> spiv: that's interesting!
<spiv> nua: http://rafb.net/p/D2wnww23.html
<nua> spiv: thanks, I'll look into my code
<poolie1> igc, lifeless, i meant garbagecollect not groupcompress :)
#bzr 2009-03-04
<Ng> is it possible to copy a file from one place in a branch to another and retain its history? not move, copy
<james_w> Ng: not currently
<Ng> james_w: ok, ta
<james_w> Ng: history of a file means tracking a file id across versions
<james_w> duplicate file id in a singled revision => ARRGHH!
 * Ng nods
<james_w> there are some suggestions for how to extend the model to allow splitting and joining file ids though
<james_w> so maybe one day
<fbond> Hm, bzr branch --no-tree would be useful.
<fbond> Am I missing something obvious?
<mwhudson> it would be useful
<spiv> fbond, mwhudson: that's probably why it exists in bzr.dev...
<mwhudson> spiv: hooray time machines
 * spiv -> food
<fbond> spiv: Ah, neat.
<lifeless> igc: ping
<lifeless> poolie: you're dreaming, but I want to write one
<igc> hi lifeless
<lifeless> igc: I have 356 seconds of internet left
<igc> lifeless: fyi, I went digging into what log -v was doing yesterday afternoon
<igc> the chk_map.iter_changes() code was loading some nodes twice - about 20% in my test
<lifeless> igc: 180sec left :P we may need a phone call or something. I'maround until 1345 sydney time
<igc> I put a simpe cache in to stop that but it made next to no difference in overall time
<lifeless> igc: ok
<lifeless> igc: I think a useful thing to do would be to calculate/report in a brute force way the actual common/left-only/right-only node for two trees
<lifeless> igc: we could use that to say 'we should be doing X work'
<lifeless> igc: and it would also be useful to jam in evaluating the flavours
<lifeless> I don't think he's got such a tool yet [I may be wrong]. repositorydetails would be a good place to put it
<igc> ok, I'll download repodetails and see what's it doing now
<igc> I'm still digesting chk_map's code fwiw
<poolie> lifeless: do you still want your .../rob directory on orcadas?
<poolie> i'm going to tar it up
<poolie> that machine's almost out of disk
<igc> poolie: lifeless is offline for 2 hours - flying
 * igc lunch
<thumper> spiv: is http://bazaar-vcs.org/SmartPushAnalysis1.13 up to date?
<spiv> thumper: no, the current numbers are a bit better
<spiv> lifeless and I have been improving things too rapidly to make keeping the page up to date worthwhile :)
<poolie> igc, thanks, np
<bignose> jelmer: upgraded âbzr-loomâ on Debian squeeze
<bignose> now I get: Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
<bignose> the plugin is still there (a â/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/â directory with Python modules)
<mwhudson> bignose: if you run bzr -Derror rocks you should get a better error message
<bignose> $ bzr -Derror rocks
<bignose> Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
<bignose> It sure does!
<mwhudson> bignose: what version of bzr?
<bignose> $ bzr --version
<bignose> Bazaar (bzr) 1.5
<bignose> all as per Debian âsqueezeâ
<mwhudson> oh, that's fairly old
<mwhudson> ~/.bzr.log might have something about loom's failure to load
<bignose> nevertheless, both it and âbzr-loomâ are as in Debian âsqueezeâ, with no dependency issues.
<mwhudson> hm
<bignose> yes, the log does have something
<bignose> warning: paste bomb
<bignose> [19317] 2009-03-04 14:53:47.719 WARNING: Unable to load plugin 'loom' from '/usr/lib/python2.5/site-packages/bzrlib/plugins'
<bignose> 0.239  Traceback (most recent call last):
<bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugin.py", line 208, in load_from_dir
<bignose>     exec "import bzrlib.plugins.%s" % name in {}
<bignose>   File "<string>", line 1, in <module>
<bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/__init__.py", line 61, in <module>
<bignose>     import branch
<bignose>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/loom/branch.py", line 767, in <module>
<bignose>     class LoomBranch7(LoomSupport, bzrlib.branch.BzrBranch7):
<bignose> AttributeError: 'module' object has no attribute 'BzrBranch7'
<mwhudson> yeah, the bzr is too old for the bzr-loom
<bignose> am I right in thinking that means this version of âbzr-loomâ should depend on a newer version of âbzrâ?
<mwhudson> sounds like a packaging bug
<bignose> okay. I'll file a Debian bug for this.
<mwhudson> good idea :)
<mwhudson> bzr 1.6 will make that error at least go away
<bignose> mwhudson: thanks for the troubleshooting
<mwhudson> np
<bob2> isn't pycurl still optional?
<bob2> (for accessing http:// urls)
<bignose> accessing them fails entirely for me, unless I install it.
<bignose> bob2: I presume we're talking about Debian bug#518098 ?
<bob2> bignose: yeah
<poolie> vila: are you up? see  ^^ about pycurl
<vila> poolie: not yet but soon :)
<vila> bob2: pycurl is optional but is/was the default for http and is still the default for https, what bzr version/os are you using ?
<bob2> vila: bigtone was having problems on debian with http with bzr 1.5
<vila> hmm, debian bug#518098 seems to refer to bzr-1.5
<bob2> yeah
<vila> :-) I'm pretty sure many (or at least several :)  bugs have been fixed in that area
<vila> bob2: do you have an url to access that bug, google only gives mailing lists hits
<vila> bignose == ben finney ?
<bob2> bugs.debian.org/518098, yes
<vila> He's right about the recommends (at least today, don't clearly remember for 1.5) also, one should not take DependencyNotPresent regarding pycurl too seriously since we may as well not show it, the other http implementation being selected in that case anyway
<vila> bob2: thanks for the url
<bob2> so it has nothing to do with pycurl, and something else is going on?
<vila> bob2: ok, so after reading the bug report, I think ben is wrong about pycurl being mandatory, I may need to check what has changed since 1.5 but I don't have cases where pycurl works and urllib doesn't (except for https certificate verification, but that doesn't apply here)
<vila> bob2: I may also need the relevant pycurl version too...
<bob2> vila: the version of pycurl he doesn't have installed? ;p
<vila> bob2: oh well, in the end, if it works with pycurl and until bzr is upgraded to a more recent version, the simplest is certainly to just install pycurl
<vila> bob2: :-)
<vila> bob2: Sorry, I'm not yet fully awake, so, one last try at explaining it clearly:
<vila> bob2: there are two http client implementations for bzr: one is pycurl based the other is urllib2 based
<vila> bob2: they are roughly equivalent these days except for the https certificate verification that only pycurl implements
<vila> bob2: no https involved here, so it should be a bug in urllib that has been fixed *after* bzr-1.5
<vila> bob2:  installing pycurl (which makes it the default http client used) fixes the problem
<vila> bob2: ergo, for bzr-.15, install and use pycurl is the way to go
<vila> bob2: ergo, for bzr-1.5, install and use pycurl is the way to go
<poolie> good night all
 * igc dinner
<vila> bob2, bignose: sorry for the delay, but I'm pretty sure debian bug #518098 has been fixed as bug #230223 on lp (fix released in 1.6)
<ubottu> Debian bug 518098 in bzr-loom "bzr-loom: can't use Bazaar =?utf-8?Q?with_?=" [Normal,Open] http://bugs.debian.org/518098
<ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Fix released] https://launchpad.net/bugs/230223
<vila> sorry, ubottu, that was a debian bug I was talking about, not a bzr-loom one at all :)
<Kamping_Kaiser> hehe.
<ROza27> hi
<james_w> vila: it has, but that package is just in experimental currently
<ROza27> has anyone used trac with bazaar?
<vila> james_w: ? You mean bzr is packaged in experimental with a more recent version ? Which one ?
<james_w>        bzr |    1.5-1.1 |      unstable | source, alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc
<james_w>        bzr |     1.12-1 |  experimental | source, alpha, amd64, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
<vila> james_w: ok, great
<james_w> it can get moved to unstable now, I just don't have the poert
<james_w> power
<james_w> rockstar: awesome news, thanks
<vila> good morning jam
<jam> morning vila, sorry about the delayed response :)
<vila> :-)
<bac> hi.  i'm trying to help someone who needs to break a lock on a repo on LP.  do i remember correctly that using sftp instead of bzr+ssh is helpful in breaking stubborn locks?
<beuno> bac, stubborn in what way?
<bac> beuno: in the way that it won't break...
<beuno> bac, error message?
<bac> nope
<bac> https://answers.edge.launchpad.net/launchpad/+question/62700
 * beuno looks
<bac> beuno: shouldn't you be sprinting or something?
<beuno> bac, shhhhhhhh
<beuno> bac, I'd suggest deleting the branch and pushing again
<beuno> considering it's empty
<bac> ah, ok.  i just seem to recall when i was in asia trying to push to devpad i used to get a bunch of held locks and spiv suggested breaking the lock using sftp.  i could be on crack, though.
<beuno> yeah, although I think it's different in LP
<bac> beuno:  in rockstar's suggestion he mentions ":push" -- what exactly is that?
<beuno> bac, that's the push location
<bac> beuno:  so can you use :pull and :parent, etc anywhere a location is needed?
<beuno> bac, yeap
<bac> is that documented anywhere?
<beuno> I expect that 'bzr help revisionspec' would
 * bac notes "bzr revno :parent" doesn't work as expected
<bac> nope, they aren't really revisionspecs
<beuno> well, you know parents...
<LarstiQ> they're not revisionspecs
<RainCT> Hi
<LarstiQ> bac: hmm, I can't find it in the bzr topics atm
<LarstiQ> bac: but yes, :submit etc is very useful
<bac> LarstiQ: no, me neither.  i'm looking in directory_service.py.
<bac> they really are handy and should be documented somewhere
<RainCT> bzr isn't working here on Jaunty.. It says that I need dulwich, but there is no "python-dulwich" package nor anything like that
<RainCT> ah wait, seems like it's a plugin that gives the error, nevermind
<LarstiQ> RainCT: dulwich would be bzr-git
<LarstiQ> (requiring it)
<LarstiQ> bac: oh, I didn't know about :this
<RainCT> LarstiQ: right, just figured that out.. I'm too fast to complain :)
<phinze> is there any way to get bzr to spit out the location of its parent branch?
<phinze> looking for shorthand way of doing bzr up $PARENT_BRANCH; bzr merge $PARENT_BRANCH .
<phinze> where "its" is "the current branch's"
<james_w> ":parent"
<phinze> james_w: perfect, thanks
<phinze> where would i have found that in bzr help?
<phinze> (just curious)
<james_w> nowhere :-)
<james_w> someone *just* opened a bug saying that it should be documented
<phinze> ah ha, well that makes me feel better :)
<Mez> and the conversion is complete. Work now uses bzr. I wonder how that happened <evil-laugh />
<LarstiQ> Mez: that still needs work here, hmm
<Mez> LarstiQ: poor you :d
<jelmer> jfroy, ping
<jfroy> pong
<jfroy> jelmer: ping?
<jelmer> jfroy, pong
<jfroy> eh, I was just wondering why you pinged me and then went silent :p
<jelmer> jfroy, I was wondering if you could still reproduce bug 332364
<ubottu> Launchpad bug 332364 in bzr-svn "NoSuchRevision error while branching remote repository" [Medium,Triaged] https://launchpad.net/bugs/332364
<jfroy> I'll give it a go
<jfroy> I didn't since the bug status didn't change
<jfroy> (test it again, that is)
<jelmer> jfroy, thanks
<jfroy> it failed again
<sabdfl> jelmer: ping
<jelmer> sabdfl, pong
<jelmer> jfroy, thanks, can you pastebin the exact traceback?
<jelmer> jfroy: Since the error has hopefully changed :-)
<sabdfl> jelmer: i submitted a branch for merging on bzr-gtk, do you review those?
<jfroy> it has not
<jfroy> at least not much
<sabdfl> the branch removes the actions from the notifications bzr-notify emits
<sabdfl> actions turn notifications into alerts (i.e, dialogs with cancel buttons that stick around forever) on jaunty
<beuno> sabdfl, I reviewed and merged it a few days ago
<sabdfl> ah, thanks beuno
<sabdfl> would it be possible to put an updated package together?
<sabdfl> for 9.04?
<beuno> jelmer, you do the packaging for Ubuntu, right?
<sabdfl> also, beuno, do you know the status of bzr and loggerhead packages in jaunty?
<jelmer> sabdfl: I think a tweaked version of it has been merged based on your patch, which only disables it if the notify daemon (is that the right name) doesn't support actions
<jelmer> beuno, Yeah, for Debian/Ubuntu
<sabdfl> jelmer: that's better than my patch, i just used a hacksaw :-)
<jelmer> sabdfl, I uploaded a fixed package to experimental, james_w was going to request a sync for that for jaunty
<beuno> sabdfl, loggerhead is in 1.10, which is the latest release. bzr is in 1.12, which the latest release as well.
<beuno> we could do a release of LH, trunk has advanced quite a bit since then
<beuno> I'll talk to mwhudson about it
<sabdfl> beuno: that would be a good idea, yes
<sabdfl> when is bzr 1.13 due?
<jelmer> sabdfl: IIRC According to the original schedule a RC1 would be due in a couple of days
<beuno> sabdfl, I think after the brisbane sprint next week
 * jfroy pasted http://pastie.textmate.org/private/fpkj1uc5yvyqrehvopq8ow
<jfroy> jelmer:
<beuno> jelmer, hasn't that been pushed back due to the sprint?
<sabdfl> i believe 1.13 adds good work on the network performance front, so would encourage a plan to release it *and* get packages into 9.04
<jelmer> beuno: Ah, I wasn't aware of that
<beuno> jelmer, if I do a release of LH, can you do an upload to debian so we can sync?
<jelmer> beuno, My information dates back a month
<jelmer> beuno, yeah, np
<jelmer> beuno, just ping me when it's out :-)
<jelmer> jfroy, thanks
<jfroy> np
<beuno> jelmer, awesome, thanks. I'll work on it today/tomorrow evening
<beuno> sabdfl, I'll email the list about it. When's the jaunty deadline?
<sabdfl> beuno: we're already into UI freeze exception territory: https://wiki.canonical.com/DesktopExperienceTeam/JauntyUIFExceptions
<beuno> sabdfl, ah, so it's pretty urgent to get these out then  :)    I'll poke people about this
<sabdfl> thanks beuno
<jpds> How can I resolve a conflicting tag?
<rockstar> kfogel, so, it looks like your discussion about PQM is a little different than what PQM really is.
<kfogel> rockstar: oh?
<kfogel> where did we go off track?
<rockstar> Basically, it's similar to Tarmac, only that it gets it's merge requests from email.
<rockstar> It's still "client side" in the same way Tarmac is.
<kfogel> hmmmm
<kfogel> rockstar: so should they be merged?
<rockstar> kfogel, absolutely not.
<rockstar> PQM is pretty terrible in general, and is heavy, and a pain to install.
<kfogel> rockstar: might be good to write a section on how they differ, since they're similar...
<kfogel> oh
<kfogel> rockstar: well, don't write that :-)
<kfogel> rockstar: is Tarmac meant to eventually replace PQM?
<rockstar> So I wanted something lightweight, and something that was closely connected to Launchpad.
<jfroy> vila: ping
<jfroy> +
<kfogel> rockstar: *nod*
<kfogel> rockstar: is the lightweight-ness or heavyweight-ness noticeable to the user anyway, though?
<rockstar> kfogel, yes.  I tried setting up PQM for another project three times.  Each time, I got nominally closer than the previous time, but eventually gave up because of difficulties.
<rockstar> kfogel, ask thumper what he thinks of PQM's codebase.  :)
<thumper> *cough*
<kfogel> rockstar: heh.  Okay, so it's not  that it's heavy in terms of code size or internal complexity, it's that it's heavy in terms of user setup.
<rockstar> kfogel, all of the above.
<kfogel> whew
<kfogel> rockstar: PQM is not Canonical code?
<kfogel> rockstar: (I haven't interacted with it much, mostly what I know is hearsay)
<rockstar> kfogel, I believe it is now, but it's pretty old and crufty, and I wouldn't say there is active development going on.
<LarstiQ> kfogel: it's a pre-bzr codebase
<kfogel> LarstiQ: ah
<jseutter> question: anyone know how I can get the bzr sources to build bzr on my system?  I need something that can talk branch format 7 to check out bzr.
<jseutter> (and yes, all I have done is go to the bzr homepage and try to follow the instructions there.)
<jelmer> rockstar, are there any plans to have tarmac work for non-lp?
<LarstiQ> jseutter: I'd try the latest release.
<rockstar> jelmer, not currently.  I mean, it figures out which branches to merge through the Launchpad API.
<rockstar> I guess it could grow that though.  Patches welcome.
<jelmer> rockstar, Cool, I might look into that then
<rockstar> jelmer, it would be much appreciated.
<rockstar> jelmer, I thought it might be good to grow some email features.
<jelmer> rockstar, yeah, that's the bit I'm interested in
<rockstar> jelmer, also, we've talked about a pluggable branch landing system, so it may be that tarmac could become that, with a LP plugin, and an email plugin.
<jseutter> LarstiQ, sorry, I could have been more clear.  To check out bzr it is telling me that I need bzr 1.6 or newer.  The binaries listed on the bzr homepage are all older than that.
<jseutter> I can't get the source to build a new version of bzr to get the source.
<jseutter> ugh.  My brain is fried.  At any rate, I have a chicken and egg problem.
<jseutter> I checked the Ubuntu packages and the Epel repo, and they're both older than 1.6.
<jseutter> oh wait, there's a slackware link on the homepage that is 1.6.1.  I'll try building that
<jseutter> oh fark.  1.12 > 1.5
<jseutter> sorry about that.
<lifeless> poolie: hi
<lifeless> I've gatecrashed Tim's
<poolie> hi lifeless
<poolie> congrats
<bob2> vila: thanks!
<spiv> lifeless: d'oh, my less test skips patch failed because of your bzrdir network name changes...
<jfroy> vila: when you get around, I need to discuss a few items concerning credential providers
<lifeless> spiv: sorry :)
<poolie> jfroy: he's probably not back for 8h now
<jfroy> poolie: nothing urgent
<jfroy> *it's nothing urgent
<jelmer> jfroy, see privmsg
<poolie> lifeless: progress messages are less important than making sure there are no showstoppers in the version in jaunty
<lifeless> poolie: right. So let me cap the high features for you
<lifeless> spiv: please add any I miss ;)
<lifeless> poolie: we do network streaming push to stacked and non-stacked branches
<lifeless> poolie: we do network streaming pull from non-stacked branches, and for stacked ones now use the generic versioned-files based fetch rather than pack-optimised [a slight regression for that specific case]
<lifeless> poolie: the streaming requires both client and server to have the format for both source and target in common; that is pushing from a svn checkout to a bzr branch requires the server to have bzr-svn installed
<lifeless> we have a bunch of new verbs for creating objects over the wire and getting more data about them when we open them
<lifeless> we may find glitches during the beta cycle, but we'll fix them without more wire changes I expect
<lifeless> we're happy with the general structure of the data on the wire, so I don't expect we'll need to drop the new verbs at all, or at least not for a long time
<lifeless> so we can support the jaunty versions happily
<poolie> have you tested all these cases manually, as well as in selftest?
<lifeless> not explicitly, and I don't think thats a particularly good use of time until rc1 is out.
<lifeless> I'm dogfooding though, and so is spiv
<lifeless> so are the folk using bzr nightlies, though they will be nearly universally dogfooding the backwards compatibility behaviour not the new code
<spiv> So far I've had no nasty surprises from dogfooding.
<jelmer> fwiw I'm dogfooding too
<igc> morning lifeless, spiv, jelmer
<jelmer> hi Ian
<poolie> ok
<poolie> so, regardless, i'd like you to please test those cases manually today
<poolie> historically this is the kind of change that has caused knock on effects and i'd ilke to reduce the chance in this release
<lifeless> poolie: thats going to be basically the whole day
<lifeless> poolie: there are a _lot_ of permutations
<poolie> is it better to spend that day next week during the sprint?  i think that's even worse.
<poolie> and if the other alternative is to do this release in to jaunty without integration testing, i like that even less.
<lifeless> poolie: whats the due date for jaunty? Can we not do a days full-permutation testing after the sprint?
<lifeless> poolie: and do a point release if we find any issues?
<poolie> so that would give us more networking improvements in 1.13, but more chance that there are bugs in the ones we do have?
<poolie> wiki.u.c is down and i don't have the dates written down here
<poolie> ui freeze is today, beta freeze is march 19
<lifeless> thursday after the sprint
<lifeless> If we're going to do this sort of manual testing, I'd much rather do it monday the 16th
<poolie> because why?
<lifeless> well, we have two days left. We might be able to get to streaming-from-stacked, or vfs-free branch-from-non-stacked if we keep the momentum up
<lifeless> as soon as we stop, the protocol is frozen for those verbs until the release in the absence of serious issues.
<spiv> lifeless: I'm a bit unsure what the right fix for the less-skips + network_name failure is.  The server-side is failing on control_format.get_branch_format().network_name() in sprout_bzrdir_branch_ref tests.
<lifeless> spiv: is there a network name for BranchReferenceFormat?
<spiv> No, there isn't.  The error is AttributeError: 'RemoteBranchFormat' object has no attribute '_network_name', btw.
<poolie> spiv, what do you think?
<spiv> poolie: as lifeless says, we are tantalisingly close to some milestones.
<poolie> ok
<poolie> i will hold you two responsible if there are showstoppers in this release
<spiv> So it's even harder than normal to be enthusiastic about manually testing ;)
<poolie> but i wish you luck
<poolie> sure, i can sympathize with that
<lifeless> spiv: *serverside* is using a RemoteBranchFormat?
<spiv> lifeless: right!
<spiv> lifeless: it's a RemoteBzrDirFormat test.
<lifeless> spiv: those two nouns should never be in a single sentence unless it is '*serverside does not use RemoteBranchFormat objects*'
<spiv> Or rather, a bzrdir_implementations test.
<spiv> Heh.
<spiv> lifeless: ok, I can tweak bzrdir_implementations/test_bzrdir to explicitly use get_vfs_only_url or something.
<lifeless> spiv: there may betwo issues; the test asking the server to do something bong; the server not preventing third-party-requests.
<lifeless> spiv: we know the second exists
<spiv> Well, the test was creating a branch reference (on a server), and then sprouting it (to a new url on the same server)
<spiv> All three failing tests were following that pattern.
 * igc breakfast - bbl
<spiv> If I change it to create the branch reference locally, then sprout to a server, it works.
<spiv> If I change it to create a remote branch reference, and sprout it to local, it still fails.
<lifeless> spiv: so its reasonable to say to the server 'create a branch reference to url XXX'
<lifeless> spiv: its not reasonable for the server to assume it can read it
<spiv> Right.
<lifeless> upo	el	thanks
<Jerub> what's the best way to transition from svn to bzr? I tried using bzr-svn but it didn't work for me.
<lifeless> Jerub: in what way didn't it work
<spiv> Jerub: bzr-svn 0.5 has been working very well on the couple of projects I've tried it on.
<Jerub> it was a few weeks ago i did it, I don't actually remember what the failure was.
<lifeless> poolie: so qa wise I'm much more concerned that we're going to DOS the lp smart server
<lifeless> than tat we'll have the client fail to work as desired
<lifeless> poolie: theres plenty of adhoc testing that occurs as we just use the client, as we test stuff for the python guys and so on
 * Jerub runs it again
#bzr 2009-03-05
<jelmer> yay, bzr-svn is now feature complete \o/
<spiv> jelmer: oh?
<jelmer> spiv, annotate and eliminating svn-push were the last remaining bits
<james_w> \o/
<spiv> jelmer: sweet
 * james_w opens the champagne
<poolie> wow way to go
<spiv> jelmer: someone on another channel asks about svn:externals ;)
<jelmer> spiv: that requires bzr itself to support them first :-)
<spiv> jelmer: :)
<jelmer> the server side ("bzr svn-serve" or "bzr serve --svn") is also not done yet
<spiv> jelmer: that's ok, neither is native "bzr serve" ;)
<mwhudson> jelmer: yay
<mwhudson> jelmer: will there be a 0.6 or will this be 0.5.3 ?
<jelmer> mwhudson, 0.5.3 or 1.0.0
<mwhudson> jelmer: cool
<mwhudson> jelmer: are you going to make lp:bzr-svn non-remote again at some point?
<jelmer> mwhudson: Only if there's some way to keep the copy on launchpad up-to-date rather than between 0 and 8 hours out of date
<mwhudson> it _should_ be possible to write a hook that uses the api to request a mirror by now
<mwhudson> but i don't think one has been written
<poolie> lifeless: trailing whitespace just bit me too
<lifeless> heh
<lifeless> jelmer: grats
<lifeless> jelmer: there is an xmlrpc thing you can call, apparently.
<poolie> ah actually no
<poolie> it was a literal tab, and that was worth catching
<lifeless> heh
<lifeless> yes they are worth catching
<poolie> did you resubmit your test_source patch?
<poolie> if not i will
<jelmer> mwhudson, yeah, I still need to look at that
<jelmer> mwhudson, or hope somebody else does :-)
<mwhudson> jelmer: i'll take your requirements on board :)
<lifeless> poolie: no, because marius said he would
<lifeless> poolie: the more clean version
<Jerub> now I remember one of the issues with bzr-svn, it gets exponentially slower as it goes.
<jelmer> Jerub, Which version are you using?
<Jerub> 0.5
<jelmer> Jerub, try 0.5.2
<jelmer> that should be significantly faster
<jelmer> in particular on large repositories
<mwhudson> jelmer: why don't you use hosted branches btw?
<Jerub> jelmer: well, I've just cancelled the svn-import that had been going for over an hour
<Jerub> jelmer: so I hope this is faster.
<jelmer> mwhudson: It ties me into Launchpad, over which I have no control.
<jelmer> mwhudson: Hosting on a different machine and mirrorring into launchpad (which is still done, just not into lp:bzr-svn) means there's always a backup
<jelmer> *also means
<mwhudson> fair enough
<mwhudson> though i hope launchpad isn't going to go away any time soon :)
<mwhudson> we have backups on tape too
<Jerub> why bother? raid is good enough to back everything up.
<spiv> Jerub: raid isn't very good at preserving data eaten by fat fingers :)
<mwhudson> or fires
<spiv> mwhudson: pfft, nature
<Jerub> Sorry, I couldn't help it. My sarcasm exploded over the channel.
<Jerub> (I've actually had an office fire, and recovered from offsite backups)
<spiv> Jerub: :)
<mwhudson> http://www.facebook.com/pages/Bazaar/128354670412?sid=7bd5847db77e5312163ecf237785b8c9&ref=s
<spiv> Jerub: backup strategies is a topic a bit like editor or vcs preferences...
<spiv> mwhudson: that's a bit random
<spiv> Maybe we should replace our wiki with a myspace page ;)
<Jerub> spiv: I think until you've had to count the minutes until the wholesaler turns their phone system on in the morning so you can ask for immedate delivery of half a dozen servers, you can't really appreciate the value of offsite backups fully.
<lifeless> igc1: how are you going
<lifeless> spiv: also, I've a _huge_ long pull going from python.org
<lifeless> 1448 byte packes
<Jerub> jelmer: is there a reason I should be told to upgrade to svn 1.5 if I'm using svn 1.5 already?
<lifeless> jelmer: hours now :(. So not sure sure why
<spiv> lifeless: 1448 is better than 510!
<Jerub> jelmer: also, this is /significantly/ faster. after 20 minutes I'm past branch discovery and on copying revisions, last run I'd not gotten through 75% of branch discovery
<lifeless> spiv: 510 was the window size :(
<mwhudson> spiv: we should use facebook for canonical's calendaring needs!
<jelmer> Jerub: The 1.5 warning should be fixed in the next version
<Jerub> jelmer: awesome
<lifeless> spiv: I've stopped it after 99m
<lifeless> spiv: oh! I have an idea
<lifeless> spiv: ping
<james_w> you're going to try TCP/spiv?
<lifeless> james_w: no, I think we might be partial-reading from the socket
<lifeless> which will lead to acking less than we can
<james_w> ah
<Jerub> lifeless: have you straced it to see how big the reads are?
<lifeless> Jerub: about to
<spiv> lifeless: pong
<lifeless> spiv: see before
<spiv> Hmm, read sizes?
<spiv> lifeless: it should always be trying 64k when reading from a TCP socket
<lifeless> spiv: yeah, I've just validated that
<lifeless> spiv: and its often getting way less
<lifeless> recvfrom(4, "\0\1\242B406\ntexts\n\nknit-ft-gz\n2160@6"..., 65536, 0, NULL, NULL) = 5792
<lifeless> recvfrom(4, "cc4771:python%2Ftrunk:Lib%2Ftest"..., 65536, 0, NULL, NULL) = 1448
<lifeless> recvfrom(4, "\2\377\255\223\273\262\333 \20\206{?\3056\231\330\216\344"..., 65536, 0, NULL, NULL) = 5792
<spiv> (It is less optimisitic when reading the pipe from a bzr+ssh connection, but that's not the issue here obviously)
<lifeless> spiv: however, we haven't tested raw protocol from the dc
<lifeless> spiv: it could be :P
<riyo> Hello all! Let's see how much I can learn tonight. First time VCS user, reviewed CVS/SVN/Git, and all those other ones, and decided on this one ^_^
<riyo> Just because the commands made alot more sense, then those other ones. Like "whoami", simple, lol
<riyo> Anyways, just got through the quick user guide, and my question is this. Okay, I commit my file, lets say I finished my project, and want to look back, how do I do that?
<lifeless> bzr log?
<riyo> Like, what Im trying to say, I'm working on my project, and I decide to try something new. So I go route A, decide it's "okay", and start going a different route, route B, can I do that? And revert back to the "fork" in the road
<riyo> I don't know, I tried that in the documentation, it worked, but isn't working now. And It just showed my commits, not the file itself :/
<riyo> also, bzr diff, and log, aren't working anymore, wtf
<riyo> do I have to specify a file or something?
<riyo> bzr log filename ?
<poolie> riyo: no, they default to the whole tree
<poolie> riyo: are you in the right directory?
<riyo> Yeah I am
<poolie> so what do you mean by not working?
<poolie> do you get an error msg?
<riyo> Let me upload a picture ^_^
<riyo> http://i44.tinypic.com/141teu8.png
<riyo> There, is it supposed to do that? It just shows comments, which btw, is that a mispelling? commits?
<poolie> :)
<poolie> that's what bzr log is meant to do, yeah
<poolie> 'committer' is the person who committed
<riyo> Is that pronounced "comment-er", or "commit-er"?
<poolie> the second
<poolie> they're called commits, not comments
<riyo> But...they....are comments, lol
<riyo> How confusing.
<riyo> Anyways, what's the point? Don't I want to see what source code of mine changed?
<poolie> i don't know, do you? :)
<riyo> Ugh, yeah, otherwise theres no point, lol
<riyo> I wish it was just a hotkey, for a "snapshot", and I could scroll through each picture, lol
<spiv> riyo: you can do "bzr diff -c 2" to see changes made in commit 2.
<riyo> WTF does that mean, lol --> @@ -0,0 +1,1 @@
<riyo> ...is this some sick joke :P
<lifeless> riyo: thats standard notation for showing a textual change of a file
<lifeless> riyo: it means from line 0, for 0, to line 1, for 1
<riyo> This is overly complciated.
<riyo> Is this really the answer I'm looking for?
<riyo> Cause heres my problem.
<riyo> I create php websites, take the index.php file for example. I work on it, but before I do, I make a backup, just incase I mess up everything
<riyo> I end up with 100's of copies, lol, untill I'm finished or have scraped it.
<riyo> Is this my solution?
<spiv> riyo: yes
<spiv> riyo: you might find that some of the GUI tools make exploring the saved history a bit easier
<lifeless> riyo: with bzr you won't need as many copies, the bzr-upload plugin can make deploying your websites easier
<spiv> riyo: if your installation has the "qbzr" plugin, then "bzr qlog" is quite good.
<spiv> riyo: if you just want to view a file as it was at an earlier revision, use "bzr cat -r 2 path/to/file"
<riyo> I wish there was a video tutorial. If I ever get the hang of this, I'm so making one.
<riyo> bzr: ERROR: QBzr require at least PyQt 4.1 and Qt 4.2 to run. Please check your install
 * igc1 lunch
<lifeless> spiv: doing get_parent
<jml> igc1: ping
<igc1> hi jml
<jml> igc1: hi
<jml> igc1: I have a story about logging that I'd like your help with
<jml> igc1: I've heard a rumour that you touched log last?
<igc1> jml: :-)
<jml> igc1: so... what I want to do is find all the commits that I've made to Launchpad via PQM since the last release.
<jml> igc1: the way I can tell if a commit was mine is if I'm the author of one of the parents of a mainline revision
<jml> I can write that as a predicate function with little to no worries
<jml> igc1: what I want is a way of passing a predicate function to show_log to filter the revisions I see.
<igc1> jml: hmm
<igc1> jml: log needs restructuring and vila and I still don't agree on how
<jml> igc1: ok.
<lifeless> I'd do a filter
<lifeless> it can buffer a little and so on and feed it out
<jml> igc1: so, doing 'if foo(revision): yield revision' is going to be a bit slow, obviously
<lifeless> then give the filte ra predicate as a parameter
<igc1> jml: I think we ought to add a --user option (or something like that) that matches on a name ...
<lifeless> igc1: +1 on more capabilities, -1 on new options, I'd really rather agree on a search language and use that
<jml> what I *really* want is Bazaar Query Language
<igc1> possibly propagatng upwards to the mainline as file filtering does
<lifeless> igc1: so that bzr-search can do it fast
<jml> lifeless: great minds :)
<igc1> BQL is Python :-)
<igc1> jml: as a short-term thing ...
<igc1> log --line -n0 | grep Lange
<igc1> make it a contenxt grep if that helps
<jml> igc1: ... and then filter that to find the mainline revisions ....
<igc1> lifeless: bzr-search is nice but it doesn't exclude making log easier to use
<igc1> bzr log --user me
<igc1> and
<igc1> bzr log --user @names-in-file
<igc1> have plenty of value to casual users - a query language is just too advanced for them
<igc1> lifeless: we can use bzr-search behind the scenes to make it efficent of course
<jml> igc1: so, if I could do that and then only see mainline revisions which I pqm-submitted, I'd be happy
<igc1> iff it's installed
<jml> (although the *real* bug there is that PQM doesn't set author)
<igc1> jml: right
<igc1> jml: but even if it did, there would still be a use for seeing mainline revisions where a user authored one of the merged revisions
<lifeless> igc1: bzr log -m user:me
<igc1> I guess the new multiple author field could simplify that
<jml> igc1: I do think some sort of domain-specific language/API for specifying searches would be a good idea.
<lifeless> igc1: bzr-search is orthogonal yes, but adding many many options is not great
<igc1> jml: so *just* matching against a revision isn't smart enough
<jml> igc1: agreed.
<jml> although it's smart enough if I'm writing the revision-matching function :)
<lifeless> igc1: I wasn't proposing depending on bzr-search, I was proposing that many-options is not a better UI
<igc1> jml: but log, except for file filtering, isn't structured that way btw
<lifeless> igc1: the revision filters are iterators, or they were
<igc1> lifeless: sure
<lifeless> igc1: so it should handle arbitrary filtering just fine
<jml> igc1: ok
<igc1> but the level filtering takes out merged revisions it's never going to display before those iterators are called
<igc1> so log -n0 only passes you the mainline revisions
<igc1> it's all part of "don't generate stuff you don't need"
<igc1> "smart" filtering like jml wants means ...
<mwhudson> hello knowledgeable people
<mwhudson> what port does git talk to the internet over?
<igc1> a revision filter needs to say "give me everything and then post filter the levels out"
<igc1> except for file filtering, we don't do that currently
<igc1> lifeless: I like the -m user:me idea btw
<lifeless> igc1: can't the level filtering happen as a normal filter in the chain so you can get there first?
<igc1> lifeless: there's a high cost (> 60 sec overhead) for getting all levels for mainline for large repos
<igc1> s/for/vs/
<igc1> we only want to do it if we really need to
<Jerub> oh wow, bzr-svn 0.5.2 actually worked.
<igc1> jml: so the short answer is ...
<igc1> post processing log --line -n0 is an order of magnitude easier than extending log as you want right now
<igc1> hmm - maybe 2 orders of magnitude
<jml> heh, ok.
<jml> I'm going to try for a middle way, writing my own crappy log-like command.
<igc1> lifeless: on anotrher topic and answering your earlier Q, I'm making much better progress ...
<igc1> thanks to your assistance yesterday
<igc1> I'm hacking repodetails as discussed
<lifeless> spiv: ping
<Jerub> jelmer: why does bzr-svn count down for 'discovering revisions' while doing a bzr pull
<igc1> though *generating* branches in the new formats is still proving painful
<igc1> upgrade works for development5 but simply refuses to for ...
<igc1> formats like gc-plain-chk255, even for really simple branches
<igc1> at least now I know enough to stand a chance of traking down the problems
<spiv> lifeless: pong
<lifeless> spiv: tommorrow I'm likely to be largely offline
<lifeless> spiv: and its freeze then
<lifeless> I'm just finishing off branch.get_parent verb
<lifeless> have you been working on stacked pull ?
<igc1> though the immutable nature of CHKInventories means fastimport is currently out of service as a test branch generation avenue
<spiv> lifeless: no, not yet :/
<lifeless> igc1: if fastimport was mutating invnetories inRevisionTree's, it was being naughty
<lifeless> igc1: thats *never* been a intended capability
<Jerub> crud, that was my problem. I thought I wanted bzr svn-import when I actually wanted bzr checkout
<igc1> lifeless: it wasn't
<igc1> it was copying the basis and then using the API (add/del, rename, remove_recursive_id) to build the new one
<lifeless> ok
<lifeless> that would be slow
<lifeless> using CommitBuilder would be better
<lifeless> because it will calculate the per file graph for you
<igc1> it now has a code path for building deltas and calling create_by_apply_delta() but the root handling is still screwing me around
<lifeless> igc1: how so?
<lifeless> essentially there are three interfaces for adding data to a repository - fetch, repository.add_revisions, and get_commit_builder
<lifeless> *any* other code path is immediately suspect and probably a reimplementation of one of the others
<igc1> it's not clear what the initial root_id of the first inv should be
<igc1> I was setting it to inventory.ROOT_ID but then the root mproperty was falling over 'cause self[root_id] didn't exist
<igc1> also does the first delta need an entry for the root?
<igc1> that sort of stuff is very unclear
<igc1> I think the first revision is now genewrating but a subsequence call to directories() is falling over
<igc1> anyhow, I'll leave fastexport on hold and get back to repodetails
<lifeless> yes it does
<igc1> lifeless: fwiw as well, fast-export was *much* quicker not going through commit-builder, at least many months ago
<lifeless> igc1: so, either fast-import was buggy, or commit-builder was
<lifeless> :P
<igc1> commit-builder is good for adding one revision but not optimise at all for multiple revision loading
<lifeless> igc1: I don't see why it would be different
<igc1> lifeless: let's talk about it next week
<lifeless> igc1: anyhow, lets ignore that; we have shiny new things
<eferraiuolo> I wrote a blog post detailing my Bazaar setup on my Mac. I thought others maybe interested and wanted to share it with the community:
<eferraiuolo> http://925html.com/techniques/using-bazaar-on-a-mac/
<jml> lifeless: just landed your addSkip patch
<lifeless> thanks
<lifeless> so subunit's one needs a review
<lifeless> ciao
<Kamping_Kaiser> hm. almost an entire branch without a status updae :\
<poolie> eferraiuolo: nice
 * fullermd sure hopes those streaming changes will improve committing in checkouts across the smart server   :|
<spiv> fullermd: almost certainly.  You're welcome to try installing bzr.dev and letting us know how it goes :)
<fullermd> Well, I have bzr.dev.  Just only on the client side   :p
<fullermd> Just messes with your flow when commit takes upward of 20 seconds...
<spiv> Yeah.
<fullermd> I'm just trying to figure out whether that's an actual failing of bzr, or a clever trick somebody added to convince people not to work directly on trunk...
<spiv> Personally, I think it's a failing.
<spiv> I think there are valid use cases for working on a checkout of trunk.
<fullermd> Man, some people just don't know how to help build a good conspiracy theory...
<fullermd> The proper response would have been something like "Not only is it _intended_, it was intended by SPACE ALIENS, who encoded those coding choices in our DNA while forcing us to build the Pyramids."
<fullermd> That way not only do we have an excuse for why it happens, but we demonstrate that bzr is the oldest VCS at the same time.
<fullermd> (it was just only circa 2005 that it was translated into python from limestone...)
<wgrant> spiv: There are also often valid use cases for working on a checkout of a branch that multiple people are working on at once...
<spiv> wgrant: right
<vila> hi all
<vila> jfroy: pong
<jfroy> vila: yo
<jfroy> so, I implemented a crude keychain auth provider.
<jfroy> Plugin, that is.
<vila> jfroy: great, publish it on lp :)
<jfroy> I ran into one limitation, and one weird thing while doing so.
<jfroy> vila: I need to clear it with Apple legal first.
<vila> jfroy: ? You're working for Apple ?
<jfroy> Yeah
<vila> ok
<jfroy> I managed to get Bazaar approved for inclusion in internal builds of Mac OS X :)
<vila> jfroy: congrats :)
<jfroy> And I want to bundle a few useful plug-ins with it.
<jfroy> Eh, well git and hg are already there, but anyways.
<jfroy> OK, so first of all, the realm isn't passed down to auth providers
<jfroy> I trivially patched bzr.dev to do so
<vila> jfroy: send a patch so I can review it
<jfroy> It's useful to look up Subversion repository passwords since they are stored as "<scheme://host:port/path> realm" generic passwords
<jfroy> Secondly, the authentication.conf section *name* is passed to the auth provider
<vila> bzr-svn is taking care of that, so I thought we already fixed the realm bit with Jelmer...
<jfroy> Unfortunately, the credentials are needed for probing
<jfroy> otherwise, you get prompted *twice* for your credentials.
<jfroy> it's a miserable user experience, in other words
<vila> jfroy: if the auth provider knows about the credentials, you don't get prompted
<jfroy> yes. that's quite correct
<vila> if it doesn't (and *because* we don't save credentials so far) you get prompted twice
<vila> that's the actual limitation
<jfroy> I understand that -- the keychain auth provider works beautifully
<jfroy> but it needs all the information to do a useful search
<jfroy> host, port, realm, path, username
<jfroy> technically, it doesn't need the username
<vila> ayou should have them as part of the credentials parameter in decode_password
<jfroy> So in any case, passing the auth section name to providers seems odd. Your own netrc plug-in looks for the key "host" in the credentials argument, yet that's *never* stored in the credentials dictionary by bzr.dev
<vila> if you don't, that's a bug I should fix
<vila> AuthenticationConfig.get_credentials should certainly set the credential attributes from the received parameters, it seems it still doesn't
 * jfroy pasted http://pastie.textmate.org/408078
<vila> Now that you mentioned it, it may be that Jelmer worked around that and I thought he fixed it when in fact it's still to be fixed
<jfroy> that's the current code in bzr.dev
<jfroy> so basically in my prototype I hacked some code to create a new AuthenticationConfig object, load its config (private method, bad), get the section using the provided name, and get at the info I need.
<vila> jfroy: yup, that's where things should be tweaked, damn, no realm there :-/
<jfroy> And even that's not a good solution, since a partial patch based on the keys in the section is possible. The information should come from the actual request.
<jfroy> bzr-svn itself handles authentication through the svn libraries
<jfroy> there's no work to be done there
<jfroy> the probing process is entirely in bzrlib
<vila> jfroy: we agree, when I say add the attributes to credentials, I'm talking about the actual request ones
<jfroy> right
<vila> including realm
<jfroy> What I was worried about is that I didn't understand at all how the code works, since with that code, *your* plug-in is also broken
<jfroy> it depends on a 'host' key being set in credentials
<jfroy> and that's clearly not being done
<vila> jfroy: it could be that the tests are not good enough
 * jfroy pasted http://pastie.textmate.org/408081
<jfroy> from the netrc plug-in
<vila> jfroy: indeed, it seems I'm testing at a too low level to catch that and that the tests always provide a host
<jfroy> it seems there's a disconnect in the credential provider plug-in protocol / interface
<jfroy> If you want, I can provide a comprehensive patch to address those issues tomorrow.
<jfroy> There are other issues
<vila> jfroy: sure !
<jfroy> Namely one of performance
<jfroy> get_user and get_password both use get_credentials
<vila> jfroy: note that I'll be traveling for the next 48 hours so there will be some lag
<jfroy> and they don't cache
<jfroy> which implies credentials will be searched for / fetched on average twice
<jfroy> that's fine, I'm aiming at getting this in 1.13
<vila> jfroy: don't bother about performances here, that's called once per connection which will cost far more anyway
<jfroy> I think the changes are low risk enough to be OK.
<jfroy> that's not necessarily true
<vila> 1.13rc1 is due tomorrow, but try anyway
<jfroy> For instance, someone conscious about security might authorize bzr to access his or her keychain only once
<jfroy> under this code, he will get prompted twice
<jfroy> granted, the keychain provider could cache
<jfroy> But it seems to be a flaw that should be addressed upstream
<vila> you're talking about UI here, not performance and yes, the keychain provider can cache
<jfroy> I'm not going to include that in my patch, it's a secondary and separate issue
<jfroy> The last thing is a ER for later.
<jfroy> We could add a "probe username" method to the credential provider interface.
<jfroy> Certain providers, like the keychain one, can provide credentials with only a the request parameters.
<jfroy> That is, you can wildcard the username and request "give me any item that matches the server part of things"
<jfroy> This would allow bzr to match the user experience of svn
<jfroy> I'm wondering if get_user might not already allow for this to happen
<jfroy> And damn, rc1 tomorrow huh....
<poolie> hello jfroy
<jfroy> poolie: greetings!
<vila> jfroy: there is bug #321918 to address that I think
<ubottu> Launchpad bug 321918 in bzr "ability to register credentials providers that are always queried" [Wishlist,Triaged] https://launchpad.net/bugs/321918
<jfroy> Ah yes, true, unless the provider is configured in authentication.conf it won't happen
<vila> jfroy: that's the point, user choice is always respected
<jfroy> I don't think that's correct
<jfroy> Not entirely
<vila> jfroy: the user is right
<vila> neither you and me can change that :)
<jfroy> Respecting user preferences is of the utmost importance
<jfroy> *however*
<jfroy> Unless the user takes explicit action, defaults should reflect the user's *expected* behavior
<jfroy> And on Mac OS X, as far as credential storage and queries go, that's the keychain.
<vila> default applies when user says nothing
<jfroy> yes, agreed
 * igc1 dinner
<vila> Once your plugin register itself as being always queried unless the user says otherwise, you get what you're asking for
<jfroy> yes, that's the ideal user experience I'm aiming for.
<vila> jfroy: we all agree there
<jfroy> But there should definitely be a way to disable the provider globally or for a specific host.
<jfroy> In any case, that's not for the 1.13 timeline
<jfroy> I'm hoping I can write a narrow enough patch for the config module it will make it past what I assume are very stringent requirements for including a patch in a release that's reached RC.
<vila> jfroy: don't get focused on releases, send your patch, I'll do my best to get it included asap, even if asap is 1.14 :)
<jfroy> I suppose.
<poolie> vila, i guess you'll be leaving within 24h?
<vila> poolie: yup in less than 8h even
<poolie> vila, so should it be you, or bob tanner for 1.13 RM?
<poolie> i'd like to expand the group of people who do it but
<poolie> he isn't on the core team yet and it's kind of a high responsibility place to starte
<poolie> start*
<vila> If we can shift the dates by a week, that will be perfect for me
<poolie> you'd do it on your last day here?
<poolie> that would be ok, except that beuno and james_w would rather we do it sooner so it's in jaunty
<vila> because cutting a release while traveling is a sure recipe for disaster
<poolie> we can probably still get it in if we do rc1 tomorrow but not if it's a week later
<poolie> i know
<poolie> what do you think re bob?
<vila> That would indeed be the first time someone without vote or pqm access will be RM, which make that harder if only on technical ground
<vila> Otherwise I'm fine with bob, as I said I can act as the backup so may be I can team with him and try a double-head RM :)
<LarstiQ> jseutter: did you get it to work?
<mattions> hi
<mattions> where can I find the plugin for network manager?
<mattions> the link in the website lead to an empty directory
<mattions> Does anybody knows how to make bzr-svn remember my svn password
<mattions> ?
<igc> night all
<loxs> http://dpaste.com/6962/       --- this happens when I try to use bzr on a network drive. Everything is fine when I use it on a local drive. Any ideas?
<mneptok> loxs: sorry, haven't used Windows in >10 years
<loxs> me too... :(
<mneptok> not that it's a Windows issue per se, but backslashes and drive letters make me run away in fright. :)
<spiv> loxs: not sure, but what sort of network drive?
<loxs> spiv, it's a novell share
<spiv> loxs: it looks like the problem is something like a network drive where "mkdir mydir; touch mydir/myfile; mv mydir foo; cat foo/myfile" isn't reliable
<loxs> the strange thing is that it worked till yesterday (before reinstall of the system)
<spiv> loxs: i.e. bzr has renamed a lock directory, then gone to read the info file out of that directory (to make sure it really is the lock this process owns), and suddenly the info file is gone.
<spiv> loxs: it's quite likely to be an intermittent issue if I'm right; i.e. if you try again a couple of times it might work.
<spiv> loxs: also
<spiv> loxs: it would be interesting to know if S:/Bespoke/Cashless Vending/Cashless
<spiv>  Vending/Database/trunk/.bzr/checkout/lock/releasing.n0oxup06wmyexxs1agxg.tmp/in
<spiv> fo
<spiv> still exists.
<loxs> spiv, nothing in the lock directory
<spiv> loxs: hmm, interesting!
<spiv> loxs: I don't know what could cause that.  It's possible that it's due to wacky network filesystem semantics, but I struggle to imagine plausible network drive behaviour that would cause that.
<loxs> you are probably right... as it used to work yesterday
<spiv> loxs: a bug report would be appreciated, though.
<loxs> spiv, what kind of information should I supply for this?
<spiv> loxs: the error message, the traceback from the bzr log file (see 'bzr version' for its location), the fact its a network share, and that the info file isn't there when you look manually
<spiv> loxs: oh, and of course that it's *novell* share :)
<loxs> ok, I'll do it now
<spiv> loxs: plus anything else you think interesting, but we can always ask for more info if necessary.
<spiv> loxs: feel free to just paste this IRC conversation into the bug report if that makes your life easier ;)
<loxs> thanks :)
<loxs> hm, spiv... in the log file... before the error you saw, there it says that it's some kind of translate error    File "bzrlib\transport\__init__.pyo, line 307, in _translate_error
<loxs> yesterday, the locales of my workstation were different
<spiv> loxs: that's not related to locales
<spiv> loxs: that's code for turning errors accessing files and directories from platform-specific into bzr-internal error codes.
<loxs> spiv, https://bugs.launchpad.net/bzr/+bug/338220
<ubottu> Launchpad bug 338220 in bzr "bzr fails on a novell share on windows" [Undecided,New]
<loxs> spiv, actually the lock directory is not empty... only the windows explorer can't see this files O.o
<loxs> when using dir through the command prompt, they are there
<spiv> loxs: interesting.  So it does have an 'info' file?
<loxs> yes
<loxs> and the bad part... that files has broken encoding  bits in it ....
<spiv> Ok, then I guess my first hypothesis is correct.
<spiv> Oh?
<loxs> some of the letters in that file are "squares" probably the encoding on the novell share differs from mine
<loxs> no, no problem with this... the squares are unix line terminators
<spiv> Oh, right.  Yes, bzr will always use \n as the line terminator in that file.
<loxs> spiv, when I enable the "show system folders" option in windows explorer, now I can see these "missing" directories
<loxs> but bzr still doesn't work
<salgado> Source format does not support stacking, using format: '1.6'
<salgado>   Packs 5 (adds stacking support, requires bzr 1.6)
<salgado> I got that when trying to push a branch to Launchpad.  does it mean bzr will push all history on that branch?
<beuno> salgado, yes
<beuno> try upgrading the repository  (ie ~/canonical/lp-branches)
<beuno> upgrade --1.9
<beuno> you can do 1.6, but 1.9 is fater
<salgado> beuno, I don't think it did, though.  it took only a couple minutes to complete
<salgado> (just finished)
<beuno> s/fater/faster
<beuno> that was a very bad typo
<beuno> salgado, try:  bzr info
<beuno> it should tell you
<salgado> Shared repository with trees (format: 1.6)
<beuno> and the branch?
<salgado> I've pushing branches from this repo for ages, and stacking always worked
<salgado> Repository tree (format: unnamed)
<beuno> salgado, but rsync sometimes breaks stuff
<beuno> where do you get unnamed?
<salgado> I got that error after interrupting a push which was working fine (i.e. no message about stacking not being supported)
<salgado> s/error/warn
<salgado> beuno, on the branch I was trying to push
<beuno> salgado, delete de branch and push again
<beuno> AFAIK, there's no way to resume pushing a stacked branch
<salgado> right, I was not trying that
<salgado> this is another branch
<salgado> the one I interrupted I deleted
<spiv> salgado: 1.6 is a stacking-capable format
<spiv> salgado: there's a bug that for some reason bzr.dev sometimes thinks that source branches in a stacking-capable format aren't in a stacking-capable format.
<salgado> spiv, for some reason one of the branches in my (1.6) repo ended up created in a different format (unnamed, it seems)
<spiv> salgado: so bzr gives that bogus warning.  And "upgrades" 1.9 source branches to 1.6 on the server :(
<salgado> sounds like what I just saw
<spiv> "unnamed" isn't a format as such, it's just "bzr info" getting confused.
<spiv> It gets confused if the combination of branch format and repo format is outside a very narrow set :(
<spiv> info -v can be helpful when that happens, because it will describe the components formats individually.
<spiv> salgado: jml filed the bug, feel free to subscribe and/or update it with some info
<spiv> salgado: we want to fix it for the 1.13 release, although at this stage I'd be doubtful about it getting fixed in time for 1.13rc1
<spiv> salgado: also, upgrade to 1.9 already ;)
 * spiv -> zzz
<salgado> thanks for the help spiv.  I'll do that
<vila> spiv: does 'second push failed to complete a fetch set' rings a bell ?
<mattions> is there any way to tell the bzr-svn tool to remember my subversion password? I have to type two or three times every commit.
<jelmer> mattions: you can get subversion to cache your password for you
<mattions> how?
<jelmer> mattions, force subversion to cache the password somehow, e.g. by running "svn ls <url>"
<mattions> it's strange
<mattions> i ran it and it still ask the password
<mattions> twice, actually
<mattions> svn 0.4.16dev0
<mattions> Bazaar (bzr) 1.9dev
<jelmer> you may need 0.5 for thi
<jelmer> s
<mattions> I see
<mattions> well, I'm on intrepid
<mattions> is there any bzr packages?
<mattions> I mean 0.5 is available for intrepid?
<mattions> ok, found it
<mattions> I'll try
<mattions> jelmer: one more question: is the network-manager plugin dismissed?
<jelmer> mattions, dismissed ?
<mattions> the link brings to an empty directory
<jelmer> it's a bzr branch
<mattions> ah
<mattions> and nothing is showed
<mattions> when you look from http
<mattions> ok, thanks :)
<mattions> the network-manager plugin is not on the PPA right?
<jelmer> mattions, no
<jblount> I have a branch that gives me "No Public branch set for /path/to/branch_name" on pqm-submit, and I'm a little lost on how to fix this.
<jblount> The public branch is a lp branch
<jseutter> LarstiQ: Yes, it works fine now.  The problem was with me, not bzr. :)
<jam> jblount: echo 'public_branch = lp:...' >> .bzr/branch/branch.conf
<jam> Or configure a policy in ~/.bazaar/locations.conf
<jblount> jam: Thanks for the help, I had my ~/.bazaar/locations.conf b0rked and didn't remember where the setting came from.
<radix> Does anyone know what all needs to be upgraded (software & branch-formats & repository-formats) in order to take advantage of stacked branches (on Launchpad)?
<jam> radix: generally your repo needs to be upgraded to 1.6 or newer (I recommend 1.9 a lot)
<jam> which implies the bzr version
<radix> jam: on which side?
<jam> radix: Launchpad already supports 1.9 and newer
<jam> so just the client
<radix> both sides? only server? only clients?
<jam> or is there another server involved?
<radix> jam: sure, launchpad supports 1.9, but my repository there is not on 1.9 format
<jam> radix: so if you upgrade your local repo to 1.9
<jam> when pushing to LP
<jam> bzr will create a new branch+repo that can stack on older formats
<radix> (at least, I don't think it is. I can't figure out how to check what repo format my lp repo is in)
<jam> you *can* upgrade the repo on LP
<jam> and there are reasons to do so
<jam> but it isn't necessary
<jam> stacking cares that the Stacked branch is in the new format, not the stacked-on branch?
<jam> does that make sense?
<radix> jam: okay, so I should just tell all my developers to upgrade to >= 1.9 and do "bzr upgrade --1.9" in their repositories (anything about branches?)
<jam> radix: it is good to upgrade the branches, but not strictly necessary
<jam> as we will auto-upgrade when we need to
<radix> okay, I'll do this and find out whether it speeds up new branch pushing for my team
<radix> thanks very much for the advice jam :)
<jam> radix: what team?
<radix> landscape
<radix> jam: I think what you said about stacked vs stacked-on makes sense, yes.
<salgado> jam, if I have a 1.9 repo with a 1.6 branch inside it.  what happens if I create a new branch out of the 1.6 one; will it be 1.6 or 1.9?
<radix> jam: but did you actually mean the "Stacked branch's repository" instead of "Stacked branch"?
<jam> salgado: 1.9 branches == 1.6 branches. Only the repo changes
<salgado> oh, cool.  so upgrading my repo to 1.9 (from 1.6) should be everything I need to do?
<jam> radix: for the most part, yes. The stacking location is actually set in the branch (so if you had a shared repo, with lots of stacked branches, they could potentially be stacked on lots of different locations)
<jam> salgado: yep
<radix> I think there used to be a message printed to the console when doing a push that used a stacking branch, but now I don't see those any more.
<radix> oh awit
<radix> there it is!
<radix> okay, I think I got it working :-)
<jelmer> luke-jr, ping
<jam> radix: so pushing up a stacked branch doesn't have to push the whole history, but at the moment the data it *does* have to push is a bit slower to transfer than before
<jam> so for *small* projects, stacking isn't a win yet
<jam> landscape may be big enough
<radix> yeah, Landscape is definitely big enough
<jam> I believe if everything goes as planned, 1.13 will fix some of the remaining rough edges
<radix> our repo is 39MB, and that's really painful for the brazilians and the italians
<thekorn> jelmer, I think I fixed 294396, now I would like to test my changes, is there any way to test olive without installing it system-wide?
<jelmer> bug 294396
<jelmer> ?
<ubottu> Launchpad bug 294396 in bzr-gtk "Branch, get... cancel, fail" [Undecided,In progress] https://launchpad.net/bugs/294396
<jelmer> thekorn, you should be able to run it in-place
<thekorn> yeah, sorry, bug of course
<jelmer> thekorn, I just mentioned that to trigger ubottu as I wasn't sure what bug or project that was
<thekorn> hmm, it always picks the version from /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/branchbox.py
<jelmer> thekorn, you'll need bzr-gtk installed in ~/.bazaar/plugins/gtk
<thekorn> jelmer, no this also did not work, "Unable to load plugin 'gtk' from '/home/markus/.bazaar/plugins'", so I just tested my fix in a gtk.Window with two instances of this widget
<jelmer> thekorn, please check ~/.bzr.log
<thekorn> jelmer, http://paste.ubuntu.com/126791/ looks like another bug, maybe my bzr version is too old
<jelmer> thekorn, yes, your bzr is too old
<thekorn> jelmer, do you know off hand which version I need
<jelmer> 1.10 or 1.11 I think
<thekorn> ok, getting 1.12* from the PPA now
<thekorn> jelmer, ok, thanks for your help, it worked now, adding a branch with a fix now to this bug
<jelmer> thekorn, bzr-gtk doesn't use merge proposals on launchpad
<jelmer> thekorn, please submit the merge request to the bzr-gtk mailing list
<thekorn> oh, ok
<jelmer> Peng_, do notifications work for lp:bzr-svn ?
<nekohayo> hey there, I have someone trying to push to launchpad and getting an error that it's locked... while not being able to break the lock
<nekohayo> anyone knows what's going on in http://pastebin.ca/1353627 ?
<jam> nekohayo: your lp:// url either needs 3 / or none
<jam> bzr break-lock lp~woutc/specto/specto-woutc
<jam> sorry
<jam> bzr break-lock lp:~woutc/specto/specto-woutc
<jam> or
<jam> bzr break-lock lp:///~woutc/specto/specto-woutc
<nekohayo> on the other hand, why was bazaar giving a false suggestion then?
<jam> nekohayo: well, it was using a three / url, though it should have stripped the extra numbers from 'lp-XXXX'
<nekohayo> is that a known bug?
<jam> nekohayo: I believe I've seen that bug reported before, yes
<nekohayo> jam: ah, https://bugs.launchpad.net/bzr/+bug/255062 I guess
<ubottu> Launchpad bug 255062 in bzr "Advice to "use bzr break-lock lp-NNNN:///..." is incorrect (dup-of: 250451)" [High,Confirmed]
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed]
<jelmer> rocky, hi
<seb_kuzminsky> i'm transitioning from a git repo to bzr, and i want to reorganize it a bit in the process
<seb_kuzminsky> we've got an upstream tarball and a bunch of local patches
<seb_kuzminsky> the old git repo has the contents of the tarball as its first commit
<seb_kuzminsky> then a bunch of commits of locally-generated patches
<seb_kuzminsky> then another patch from upstream, then more local stuff, etc
<seb_kuzminsky> it's all in a single branch in the git repo
<seb_kuzminsky> what i want in the new bzr repo is an "upstream" branch without any of our stuff in it, and a "local" branch
<seb_kuzminsky> the local branch should ideally consist of a branch off the first upstream commit, then some local commits, then a merge from the second upstream commit, etc
<seb_kuzminsky> but i'd settle for importing the old git repo as the "local" bzr branch, as long as I could sensibly diff and merge between upstream and local after the inital setup is done
<seb_kuzminsky> so i used git-fast-export | bzr fast-import to turn the git repo into a bzr "local" branch, and that worked great
<seb_kuzminsky> then i made an "upstream" branch and committed all of upstream's stuff there
<seb_kuzminsky> but now when i diff between the bzr branches, it doesnt seem to think the identical files are identical...
<seb_kuzminsky> it seems to (correctly) think that the upstream and local branches don't share history
<seb_kuzminsky> so my question (finally!) is:  can i fool or bribe bzr into thinking that upstream and local are related now?
<seb_kuzminsky> some kind of a fake merge perhaps?
<jelmer> seb_kuzminsky, not afaik
<seb_kuzminsky> :-(
<jelmer> seb_kuzminsky, the only option you have is to recreate one of the two branches
<seb_kuzminsky> what do you mean?
<jelmer> and while recreating it using the same file ids the other branch is using
<jfroy> morning
<jfroy> I have a small patch to submit to bzr, is it as simple as using bzr send?
<seb_kuzminsky> jelmer: i'd be happy to throw away the current broken bzr repo and re-create it in some new way, but i dont know how
<jelmer> jfroy, yep
<jfroy> Gotta provide an email now :p
<jfroy> Send to bazaar@lists.canonical.com?
<jelmer> yep
<jelmer> seb_kuzminsky, Unfortunately, I don't think there's a way to do that yet
<jfroy> well that's awesome
<seb_kuzminsky> jelmer: ok thanks, i'll just do it by hand
<seb_kuzminsky> luckily our history is pretty short ;-)
<rocky> jelmer: heyo
<jelmer> rocky, was wondering if you could three revision properties in the cluemapper repo
<jelmer> would be set by older (broken) versions of bzr-svn 0.5
<jelmer> unsetting them would fix svn-import
<jelmer> rocky, bzr:base-revision on r512
<rocky> oh
<rocky> that should be doable
<rocky> "if you could three revision properties" ... think you missed a word there
<jelmer> sorry
<jelmer> if you could remove three revprops
<rocky> what would be the easiest way to remove them?
<rocky> and on what paths?
<ilia> hi all
<ilia> I have a question
<ilia> anybody knows, how can I edit branch history? I need to change commiter's e-mails only.
<beuno> ilia, you can't
<beuno> it's immutable
<beuno> you may be able to use bzr-rebase plugin, but it will make the branch incompatible with all the rest
<jelmer> beuno, rebase doesn't change that sort of thing
<jelmer> rocky, revision properties are set on the revision not on a particular path
<jelmer> rocky, svn propdel -r512 --revprop bzr:base-revision <url> should do it
<ilia> I have last 13 commits in a branch, which are my own
<ilia> and I did it with wrong e-mail
<ilia> I can branch from 13 revisions ago and make all changes in a single commit with a right e-mail, but it's an ugly solution
<beuno> jelmer, it doesn't?  I thought it let you re-commit in a sense
<rocky> jelmer: done
<ilia> bueno, what do you mean by "incompatible"?
<beuno> ilia, revision IDs change, so existing branches will be completely different and unmergeable
<ilia> there were no new branches during last 13 revisions
<rocky> jelmer: any part of Clue* you're most interested in ?
<ilia> i.e. the revisions I want to edit are currently only in one branch
<jelmer> rocky, just browsing
<pfanelli> hey, i am trying to setup pqm and can't figure out what goes in the queue and how to get it in there
<pfanelli> any ideas?
<jelmer> rocky, seems to still be there
<beuno> pfanelli, you have to send the location of a branch to PQM
<beuno> which PQM should be able to access
<beuno> you send those with the bzr-pqm plugin
<beuno> which IIUC, it sends it in through RPC with a gpg signature
<pfanelli> i am running bzr 1.12, i have the bzr-pqm and bzr-email plugins loaded, i setup the public and target branch settings in the .bazaar/locations.conf file...
<pfanelli> i my 'work' branch, i am running 'bzr pqm-submit -m "pqm submit test"...
<pfanelli> i also did the 'bzr pqm-submit with a dry-run - and i can see that the email that is going to be emailed to pqm is gpg'ed correctly
<pfanelli> and the pqm user is getting the email
<pfanelli> then i run the 'pqm -v -d --run' command, but i don't see anything in the queue
<LarstiQ> pfanelli: pqm can be a bit difficult to setup
<pfanelli> but i have to say that it is awesome
<pfanelli> all of this sw is awesome :)
<LarstiQ> thank you :)
<pfanelli> you guys are fantastic (i have been trying to find a way to start helping you guys out)
<pfanelli> started looking at bzr bugs, but not sure where to start
<pfanelli> who would be the correct person to ask about setting up pqm?
<rocky> jelmer: i issued your cmmand... .svn said property was deleted ... not sure what else
<rocky> jelmer: is there a specific path i have to delete it from?
<rocky> i'm just doing it at the root of the repo
<LarstiQ> pfanelli: Odd_Bloke, lifeless and Kinnison have set up pqm before, but maybe I can try to help debug too
<pfanelli> LarstiQ: cool/thx, i am sooooo close on this, just trying to figure out what to ask next :)
<LarstiQ> pfanelli: does pqm need to pick the mail up and enter it in the queue maybe?
<LarstiQ> pfanelli: the mail arrives for the pqm user, what happens next?
<LarstiQ> pfanelli: is there a procmailrc involved?
<jelmer> rocky, hmm, that's odd
<pfanelli> i took a guess and thought maybe that when i would run 'pqm --run' that it would read the mail in /var/mail, but when i ran 'pqm -h' is said that --run would process the queue...
<pfanelli> so that's what got me thinking that, there has to be something in the queue to process
<jelmer> rocky, svn propget --revprop -r512 bzr:base-revision https://dev.serverzen.com/svn/cluemapper still works
<pfanelli> i think i have a chicken-and-egg thing going on here 8)
<LarstiQ> pfanelli: let me take a gander at the pqm source
<rocky> jelmer: http://cluebin.appspot.com/pasted/89262
<jelmer> rocky, it's lying!
<jelmer> rocky, :-)
<rocky> lol
<jelmer> rocky, do you allow changing of revision properties in hooks/pre-revprop-change-hook ?
<jelmer> rocky, you may have to temporarily edit that in order to be able to remove revision properties
<jelmer> although it should also be giving you an error rather than silently ignoring you
<rocky> jelmer: i've never intentionally changed anything in hooks/pre-*
<rocky> jelmer: there is no pre-revprop-change script ... just the .tmpl one
<jelmer> rocky, For now, you should be able to just create one that jsut does "exit 0"
<jelmer> rocky, and remove it afterwards
<rocky> k
<pfanelli> LarstiQ: man that's a good idea, i am gonna' look at the unit tests for pqm (man, why didn't i think of this earlier)
<rocky> bah, having ssh issues
<jsled> I've a branch ("trunk") at revno 6797, and another ("remote") at 6667, which was the last point at which I sent a mergedirective to a coworker.  Why would `bzr send -o update ../trunk` report "Bundling 0 revision(s)."?
<rocky> jelmer: ok, i think i've done it ;)
<jelmer> rocky, thanks! :-)
<jelmer> jsled, there are no revisions in remote that are not in trunk
<jsled> Ah.  Cause I'm exactly backwards.  *ahem*  Sorry.
<jsled> jelmer: thanks.
<jelmer> rocky, the second one is r589, for which bzr:base-revision should also be removed
<rocky> jelmer: i just removed that file =P
<jelmer> rocky, s/file/property ?
<mwhudson> good morning
<jelmer> hey mwhudson, abentley
<abentley> jelmer: morning.
<jelmer> abentley, could you give bundlebuggy a kick?
<jelmer> it doesn't seem to be responding atm
<rocky> jelmer: no, the pre hook file that allowed me to delete the rev properties =P
<jelmer> rocky, ahh :-)
<jelmer> rocky, sorry
<jelmer> rocky, bzr check said there were 3 such revisions
<rocky> ah ok
<jelmer> rocky, so there should be another one after the one I just reported
<rocky> jelmer: ok, that one's removed
<abentley> jelmer: restarted
<jelmer> abentley, thanks
<jelmer> rocky, thanks
<jelmer> rocky, the last one is r591
<rocky> jelmer: done
<jelmer> rocky, merci
<jelmer> jfroy, how are you using the netrc plugin?
<jfroy> jelmer: sorry back
<jfroy> I'm using using netrc myself
<jfroy> But the code is clear
 * jfroy pasted http://pastie.textmate.org/408694
<jfroy> it at minimum expects a 'host' key in the credentials dictionary
<LarstiQ> oh, that sounds familiar
<jfroy> and the netrc tests synthesize credential dictionaries with a 'host' key set.
<LarstiQ> did I not report that bug? :(
<jfroy> however AuthorizationConfig never did set that
<jfroy> LarstiQ: maybe :p I honestly didn't check.
<jfroy> My patch was written with my keychain credential store plug-in in mind, but also conforms to the expectations of the netrc plug-in.
<LarstiQ> jfroy: it's entirely possible, bad larstiq has not been getting to many things on his todo list
<fullermd> That keeps other things on the list from getting lonely.
<LarstiQ> yes, but any time now they might petition the UN for recognition of their own nation.
<fullermd> Hah!  Fat chance.  They're your vassals, totally dependant upon you for any sustenance or boon you might grant them!
<fullermd> You're just demonstrating the point by starving them out, see.  Clenching the iron fist.
<pigmej> Hi everyone,
<pigmej> How to get commit message from bzrlib ?
<LarstiQ> pigmej: for a given revision?
<pigmej> Yes
<pigmej> I cannot find that in docs...
<LarstiQ> pigmej: revision.message
<pigmej> hmmm
<LarstiQ> pigmej: say, 'from bzrlib.workingtree import WorkingTree; tree = WorkingTree.open('"."); print tree.branch.repository.get_revision(tree.last_revision()).message
<pigmej> Hmm
<pigmej> I'm going in other way...
<pigmej> like
<pigmej> my_branch=branch.Branch.open(....)
<pigmej> repo=my_branch.repository
<pigmej> repo.lock_write()
<pigmej> and then revtree=repo.revision_tree(rev_id)
<pigmej> rev_id is previously set to my_branch.last_revision() in that "example"
<pigmej> is it better to go trough WorkingTree?
<pigmej> i need branches "support"
<LarstiQ> no, this is fine
<LarstiQ> so then
<LarstiQ> repo.get_revision(rev_id).message
<pigmej> thanks ;)
<pigmej> btw I think that the better api documentation is needed ;d
<LarstiQ> pigmej: revision_tree() gets you the RevisionTree of that revision, not the Revision object itself
<LarstiQ> pigmej: where did you look to find this information?
<LarstiQ> pigmej: ie, what do we need to change to have better helped you?
<LarstiQ> pigmej: patches welcome btw ;)
<pigmej> http://starship.python.net/crew/mwh/bzrlibapi/
<pigmej> here for example ;d
<pigmej> and there http://bazaar-vcs.org/BzrGivingBack
<LarstiQ> ok, and then, at what pieces of that did you look?
<pigmej> LarstiQ: Finally i fetch
<pigmej> revison=revtree.inventory()
<pigmej> LarstiQ: anyway what is the best way to fech binary files content ?
<LarstiQ> pigmej: I don't know about "best", but I'd do "fileid = revtree.path2id('NEWS'); fileobj = revtree.get_file(fileid)"
<pigmej> LarstiQ: so the same way that me :d
<pigmej> I'm going to write some bzr_wiki ;-)
<pigmej> web wiki engine managed via bzr ;)
<pigmej> just for fun ;d
<LarstiQ> pigmej: ah ok, cool :)
<LarstiQ> pigmej: I don't know how up to date the ikiwiki bzr backend is, but you could look at that too
<LarstiQ> pigmej: but keep us posted about your progress :)
<pigmej> LarstiQ: mine "bzr_wiki" in final ver should have full web access to naturally
<pigmej> I will see :)
<LarstiQ> pigmej: are you aware of http://bazaar-vcs.org/Integrating_with_Bazaar btw?
<pigmej> I have read this :)
<pigmej> From that I have revtree ;-)
<LarstiQ> ok :)
<ferringb> curious, anyone seen failed locks w/ "Transport operation not possible: readonly transport" when doing bzr pull $URL -d $CHECKOUT , yet have it succeed fine when doing cd ${CHECKOUT} & bzr pull $URL # ?
<poolie> ferringb: that is strange
 * ferringb thought so
<ferringb> solution atm is to kill the checkout, which sucks a bit though
<poolie> ferringb: does it tell you which transport is readonly? or does the traceback in ~/.bzr.log  give any clues?
<ferringb> forgot about ~/.bzr.log
<poolie> is it a checkout bound to another branch?
<ferringb> sec
<jam> morning poolie
<ferringb> poolie: remote, bzr server is chucking it
<poolie> hello jam
<ferringb> poolie: re: checkout bound to another branch, if by that you mean is the checkout w/in a repo... yes, tis.
<ferringb> the branch it's pulling from, that side has a similar setup although I'd expect bzr server to handle that- the odd thing is that bzr-server does lack write perms to those directories (intentionally since commits aren't routed through it since when we deployed it bzr-server was raw and questionable), although those issues aren't seen for other ops
<pfanelli> this stuff (bzr, pqm, cm, etc...) is fantastic!  I have been working today trying to get pqm setup and working with bzr. I forgot the link in pqm over to the bzr code. I ran the pqm tests and it said I was using 1.13 but needed 1.12. So I ran 'bzr revert -r date:2009-02-13' on my bzr.dev and presto it works.  That's the motto 'it just works'.  Fantastic :)
<ferringb> poolie: figured out an additional naggle actually. that co came from a different upstream branch, iow foon.com/repo1, the pull --overwrite fails when it attempts foon.com/repo2 over the same co
<spiv> jam: btw, the numbers for time spent generating a stream for the network are 22% in fileids_altered_by_revision_ids, and 16% because _read_records_iter_raw is used rather than _read_records_iter_unchecked
<pfanelli> another pqm ?...I have the 'mail_reply=1' set in my .pqm.conf file, but when I run 'pqm -v -d --run --report' i am not seeing any mail reply?  Any ideas why?
<pfanelli> any pqm guru's out there? Is this a bad time of the day/night/
<pfanelli> ?
#bzr 2009-03-06
<bob2> pfanelli: might have more luck on the mailing list
<pfanelli> bob2: thx. I got this channel off of the bzr web site. I also checked for answers on LP.  Do you know how to subscribe to the mailing list? (this is probably a stupid ? :) ). Also, I was gonna' ask a question on LP. Do you think i should also do this?
<bob2> pfanelli: https://lists.ubuntu.com/mailman/listinfo/bazaar - dunno about lp
<pfanelli> bob2:  heh, i just looked up the mailing list on the bzr site (duh - my bad, lol)  thanks!
<bob2> pfanelli: no worries
 * igc offline for an hour or so while travelling
<spiv> I've just submitted 3 of Robert's approved patches to PQM, given that he's offline today.
<jelmer> is there any chance of the 30+ patches currently in BB landing before 1.13?
<jfroy> jelmer: I just got a "Could not determine revno for ... because its ancestry shows a ghost at ..." error, thoughts?
<jfroy> while trying to commit to a svn branch
<spiv> jelmer: of all of them landing?  I'd estimate that at near 0.
<spiv> jelmer: there's a good chance that some of them will, though...
<spiv> Perhaps even most?
<phinze> is there a location alias for the "checkout of" branch?
<lifeless> spiv: thanks
<tallen> anyone seen any integration with Visual Studio and Bazaar?
<tallen> I see this https://launchpad.net/bzr-visualstudio but it doesnt seen active
 * igc is back online
<igc> jam, if you're still around, the groupcompress tests are failing
<igc> I think I know the fix but I'm not sure ...
<igc> add "start = entry.start" around line 236 in groupcompress.py?
<lifeless> spiv: ping
<poolie> hi lifeless
<jelmer> jfroy, please file a bug
<jfroy> will do if I see it again
<jelmer> spiv, most would be nice
<jfroy> I wiped the cache and tried the operation again (a commit), and it worked
<jelmer> jfroy, it's not reproducible?
<jfroy> (well, also made a clean checkout)
<jfroy> I haven't seen the same error again yet
<lifeless> poolie: hi
<jfroy> I always try a "wipe cache, get a clean checkout" while tracking bzr-svn top of tree.
<jfroy> It's not unreasonable for changes to invalidate existing branches or the cache
<jelmer> jfroy, unless there is a bug that's been fixed no changes should be invalidating existing branches/cache
<jelmer> jfroy, was this the same branch we fixed a bug in yesterday?
<jfroy> yes I believe so
<jfroy> actually no
<jfroy> well, yes and no :p
<jfroy> same subversion branch
<jfroy> but much older local branch (my actual daily work branch)
<spiv> lifeless: pong
<lifeless> spiv: about to send in a tags fix
<spiv> lifeless: hooray.  ratchet improvement? :)
<lifeless> spiv: surprisingly, not yet. 4 verbs in and still equilibrium
<spiv> lifeless: I'd love a review of my fetch with search patch (http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090306005950.GD7819%40steerpike.home.puzzling.org%3E)
<spiv> lifeless: huh, odd.  What's the current culprit?
<lifeless> spiv: tags
<lifeless> so get_parent_ was equilibrium
<lifeless> ten tags - first _should_merge,
<lifeless> but .tags needed real
<lifeless> then branch._transport needed real
<lifeless> which is what I'm working on at the moment
<lifeless> oh, open_branchV2 is in there too, to get the format
<lifeless> spiv: also there is an oddity on decod of responses
<lifeless> spiv: '' -> ()
<jam> igc: something like that. I think I fixed it in a different branch by using 'entry.start' in place of 'start', but either should be fine
<lifeless> spiv: or more clearly, ('',)
<lifeless> spiv: and, ratchet -> 11
<hackedhead> i'm about to travel, and i have a small class projec that i'm using bzr to track on my deskop, i'm the only 'developer' and it's not public anywhere. i'd like to move the working tree to my laptop while i travel... can i simply copy the directory over? or is there better way?
<poolie> sure just
<poolie> on your laptop,
<poolie> bzr branch bzr+ssh://desktop/~/what/ever
<poolie> oh, and make a repo in the right place on your laptop first
<igc> jam: yeah, it looked like start was being set in the if branch but not the else branch
<hackedhead> 'make a repo' meaning a directory for it to live in, i assume
<spiv> lifeless: I fixed some bugs in your get_parent branch to be able to land it, btw
<lifeless> spiv: ok, I'll pull now
<spiv> lifeless: where you were passing 'foo' rather than ('foo',) as a response
<igc> jam: the unclear bit was knowing what start ought to be set to - and entry.start looked a likely option :-)
<poolie> hackedhead: i mean, in your home directory, do
<poolie> bzr init-repo myproject
<spiv> lifeless: you had some tests and code that had (x) rather than (x,), happily other tests noticed :)
<jam> igc: yeah, inside that if, entry.start is set to start
<poolie> or whatever name you want to use
<lifeless> spiv: yes, I've just been cleaning that up here too
<poolie> this will make a directory to hold all your branches
<jam> it is outside the if that already has it
<igc> jam: another minor quibble, the groupcompress branch had a heap of bzr tags in it referencing missing revisions
<igc> jam: I'm not sure if they're gone know but my concern was how they got there
<lifeless> igc: root cause: pull not propogating tags
<hackedhead> poolie: okay, and when i get back i can do a merge from the desktop, using ssh again, in the other direction?
<poolie> yes, or just push to the desktop
<hackedhead> oh, right, okay
<poolie> presumably no other work will have happened there while you're away
<poolie> so just a push will do
<hackedhead> yes. =]
<poolie> hth
<hackedhead> yeah,much, ty
<igc> lifeless: I'm not sure I understand - why would a 'bzr-0.15' tag exist in the groupcompress repo at all?
<poolie> you're welcome
<lifeless> igc: oh, that? blame jam :P
<hackedhead> o/
<igc> maybe the orginal branch shared a repo with bzr.dev or something?
<jam> funny, I don't remember ever trying to merge my jam-integration branch into groupcompress
<jam> I honestly don't have any idea why the tags would have spread to GC
<jam> maybe I did a 'bzr merge' with a bad path once?
<jam> igc: It shares a repo, but it shouldn't have shared a branch
<lifeless> spiv:
<lifeless> [BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]
<lifeless> spiv: clear as day now.
<lifeless> spiv: also note: VFS-free!
<lifeless> spiv: I'm going to ignore the duplicate call [for now]
<lifeless> spiv: as caching coherency requires a little care, and this is already somewhat better
<poolie> lifeless, jam, this branch was originally going to set the format to 1.9-rich-root
<poolie> to get it over with
<lifeless> poolie: which branch
<poolie> to set the default format for 1.13 to 1.9
<poolie> i'm inclined now to stick with plain 1.9
<lifeless> works for me
<lifeless> spiv: reviewing your patch about fetch paramaters
<spiv> lifeless: nice
<lifeless> spiv: so, I want to combine the first three calls
<lifeless> spiv: with a lock_read() we could optimistically ask for the next two or even three
<spiv> lifeless: a lock_read on which object?
<lifeless> spiv: Branch
<spiv> Hmm.  If we opened branches read-locked, then get_stacked_on_url and last_revision_info are obvious things to fetch.
<lifeless> yes
<lifeless> but api clarity does still matter :)
<spiv> Right.
<lifeless> Branch.open().unlock().lock_write() blows
<spiv> There is definitely some friction with the current API here.
<jam> poolie: I wouldn't do rr
<jam> given the 5-hour conversion times
<lifeless> I could buy into Branch.open_read_locked()
<spiv> lifeless: me too
<poolie> me three
<poolie> jam, ok
<jam> wait for something like CHK, which gives a real benefit
<lifeless> spiv: reviewed
<lifeless> spiv: in short; some smoke tests for the new capabilities; and some naming changes
<lifeless> spiv: also please review my tags patch :)
<poolie> lifeless/spiv: changing the default format to 1.9 bumps test_branch_from_trivial_branch_streaming_acceptance to 18
<lifeless> poolie: tsk!
<poolie> putting just a number there makes it hard to see what actually was added
<lifeless> poolie: yes, thats true. OTOH its very easy to work with for us
<lifeless> poolie: when some of the ratches are still > 100
<poolie> yes that's the tradeoff
<poolie> i know i know
<lifeless> :)
<poolie> been there too
<lifeless> spiv: oh bah, ignore the self.debug() call I left in
<spiv> lifeless: was already reviewing :)
<lifeless> poolie: it stays at 11 for me
<lifeless> spiv: K, I'll wait for your feedback and remove the debug call at the same time
<lifeless> poolie: I see:
<lifeless> [BzrDir.open, BzrDir.open_branchV2, BzrDir.find_repositoryV3, Branch.get_stacked_on_url, Branch.last_revision_info, BzrDir.cloning_metadir, Repository.get_parent_map, Repository.get_stream, Branch.get_parent, Branch.get_tags_bytes, Branch.get_tags_bytes]
<lifeless> poolie: however, I do see an increase in blackbox.test_branch.TestSmartServerBranching.test_branch_from_trivial_branch_to_same_server_branch_acceptance, which is from 65 to 66
<poolie> lifeless: http://pastebin.ubuntu.com/127042/
<spiv> lifeless: reviewed
<lifeless> poolie: yeah, most of those will be tags
<lifeless> poolie: print self.hpss_calls[8].stack
<poolie> i guess it's also reading the stacking control file
<lifeless> poolie: will show you the cause
<poolie> that's nice
<poolie> well it's http://pastebin.ubuntu.com/127042/
<poolie> meh
<poolie>     format_string = transport.get(".bzr/branch-format").read()
<lifeless> poolie: right, but look higher :)
<lifeless> poolie: _ensure_real is generally a symptom
<lifeless> you'll find something like merge_tags_if_needed
<poolie> sure, of get_parent
<lifeless> or get_parent :)
<lifeless> get_parent as landed though
<poolie> just recently?
<lifeless> today
<spiv> Yes, a couple of hours ago.
<poolie> so maybe that didn't reduce the rpc count, but it did eliminate vfs access here?
<spiv> Right.
<lifeless> yes get_parent_map was no improvements in round trips, but one less cause of vfs
<lifeless> the next patch removes the last cause
<spiv> lifeless: s/get_parent_map/get_parent/ :)
<lifeless> bah yes
<spiv> Perhaps it should be called get_parent_location to reduce confusion?  Not that the wire API is the same as bzrlib's API...
<lifeless> spiv: see thursday's chat:)
<lifeless> spiv: _run_with.. should show the transform
<poolie> ?
<poolie> on staying on the main game?
<poolie> at a guess
<lifeless> poolie: no, about verb names
<spiv> lifeless: oh, _run_with... was self-explanatory to me :)
<lifeless> spiv: I can't tell if  I need a lambda or not
<lifeless> spiv: for instance
<spiv> lifeless: please feel free to extend the docstring; the transform for the given example is just "return _run_with_write_locked_target(callable, *args, **kwargs)"
<lifeless> (what if _transport is only defined in the lock_written state? for instance)
<spiv> Typically if a function takes *args/**kwargs then lambdas are unneccessary.
<poolie> ok so that one's still failing after merging bzr.dev...
<poolie> because now tags() is forcing a real repository...
<spiv> poolie: so the problem is that _ensure_real of a BzrBranch7 is one VFS call more expensive than of Branch6?
<lifeless> spiv: your cloning_metadir looks odd
<lifeless> spiv: sometimes you return a tuple
<poolie> i think so
<lifeless> spiv: sometimes you return a string, for branch_name
<lifeless> spiv: is this deliberate?
<spiv> lifeless: do I?  Hmm.
<poolie> that would be consistent with it having to read its stacking url over the vfs
<spiv> lifeless: IIRC I meant to always return a tuple.
<spiv> lifeless: ugh, so I do.
<lifeless> spiv: adjusting
<poolie> therefore i think it's correct for that count to go up by 1 given the level of technology in this branch
<spiv> lifeless: thanks.
<lifeless> spiv: and letting pqm handle the fallout
<spiv> poolie: what's odd to me is that 1.6 has stacking URLs too...
<lifeless> spiv: current default is 0.92
<spiv> Oh, ok.
<spiv> In that case, it all makes perfect sense :)
<lifeless> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1236311834.10834.1.camel%40lifeless-64%3E
<spiv> poolie: given that lifeless is about to land get_tags_bytes, which should get rid of the VFS from that case, a temporary +1 bump sounds ok to me.
<lifeless> poolie: ^ is about to land
<lifeless> poolie: and it will conflict on that line
<spiv> poolie: but as lifeless says maybe just merging in that branch will be easier?
<poolie> k, i'll look at some other failures first
<lifeless> poolie: so the other acceptance test in test_branch.py *will* go up for 1.9 as default, with my branch
<lifeless> poolie: and thats fine
<lifeless> (65->66 for me - you have +1 on that change)
<poolie> i wish, again, we printed stack traces as soon as they occurred...
<seb_kuzminsky> is it bad if "bzr check" says "2 inconsistent parents"?
<seb_kuzminsky> on the repo where it says that, i can't push changes in
<seb_kuzminsky> i made that repo with "git-fast-export | bzr fast-import", and it seems to work fine locally, but not in branches i've made off it...
<poolie> seb_kuzminsky: it may be a bzr-fastimport bug then
<poolie> seb_kuzminsky: ideally someone would run bzr reconcile on that repo
 * seb_kuzminsky reads about reconcile
<poolie> lifeless or spiv, one of you might want http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480903052104k63c85898t88ed90dcccdc7715%40mail.gmail.com%3E
<poolie> also  spiv is http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E now obsolete?
<seb_kuzminsky> "Reconciliation complete."
<seb_kuzminsky> bzr check is clean now :-)
<seb_kuzminsky> but it still doesnt work :-(
<spiv> poolie: not obsolete, but it does need another look to figure out how it should interact with vila's http network activity
<seb_kuzminsky> i removed ran reconcile on the "master" repo, removed the remote branch, re-branched to the remote machine, committed on the remote machine, and tried to push
<seb_kuzminsky> bzr: ERROR: Revision {set([('null:',)])} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(<bzrlib.btree_index.BTreeGraphIndex object at 0x18a5a90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x16518d0>)), <bzrlib.knit._DirectPackAccess object at 0x16033d0>)".
<seb_kuzminsky> both repos are 1.9-rich-root, in case that matters
<seb_kuzminsky> both 'check' clean
<spiv> seb_kuzminsky: which version of bzr?  I think this bug was fixed in bzr.dev about a week ago.
<seb_kuzminsky> "1.13dev" on the remote machine
<seb_kuzminsky> "1.12" on the master server
<seb_kuzminsky> upgrade the server?
<seb_kuzminsky> remote is on the bzr intrepid ppa
<spiv> seb_kuzminsky: upgrade the 1.12 to bzr.dev if you can, IIRC
<seb_kuzminsky> server is intrepid's 1.12-1~bazaar1~intrepid1
<seb_kuzminsky> spiv: do i need the nightly ppa?  or is beta good enough?
<seb_kuzminsky> looks like i need beta
<seb_kuzminsky> s/beta/nightly/
<spiv> seb_kuzminsky: nightly, I think.
<spiv> seb_kuzminsky: https://launchpad.net/bugs/317654 is the bug, btw
<ubottu> Ubuntu bug 317654 in bzr "error about null revision not present pushing to server" [High,Fix committed]
<spiv> seb_kuzminsky: also, you may be able to workaround it by using sftp:// rather than bzr+ssh://
<seb_kuzminsky> hmm
<seb_kuzminsky> yes, sftp:// pushed successfully
<seb_kuzminsky> but it didnt run the hooks (bzr-email, bzrbuildbot)
<spiv> Yeah.
<seb_kuzminsky> those only run with ssh, right?
<spiv> That's right.
<seb_kuzminsky> ok
 * seb_kuzminsky adds bzr-nightly-ppa to sources.list.d/bzr.list
<lifeless> spiv: I've just forwarded you a pqm failure
<spiv> lifeless: ok
<lifeless> spiv: I'd like to ask a favour
<lifeless> spiv: land my http://people.ubuntu.com/~robertc/baz2.0/integration branch
<spiv> lifeless: ok
<lifeless> spiv: its likely that ^^^^[log from bzrlib.tests.branch_implementations.test_hooks.TestOpen.test_open(RemoteBranchFormat-default)] is one of several failures with hooks
 * spiv nods
<lifeless> so running hooks.* RemoteBranchFormat should flush them out
<lifeless> I *think* at a glace that the branch is being opened remotely in more cases
<lifeless> so trivially adjusting may be sufficient
<seb_kuzminsky> server is on 4083 (latest in bzr.dev), remote machine is on 4058
<seb_kuzminsky> remote still can't push, same error
<seb_kuzminsky> upgrading remote to 4083 now
<spiv> seb_kuzminsky: remote needs to be at least 4061
<spiv> seb_kuzminsky: "missed it by *that* much" ;)
<seb_kuzminsky> heh
<seb_kuzminsky> that's what i get for hopping off of the nightlies and down to the boring old stuff in the "release" ppa  ;-)
<spiv> seb_kuzminsky: also, the network protocol is in a fair bit of flux in bzr.dev atm.  So until 1.13rc1 is out, you may need to keep client and server on the same version of bzr.dev to avoid weird smart server failures.
<seb_kuzminsky> ok thanks for the heads up
<spiv> (but on the plus side it ought to be noticeably faster)
<seb_kuzminsky> ooh, thanks!
<spiv> seb_kuzminsky: if you *do* get weird failures though, please let us know :)
<seb_kuzminsky> oh you'll know
<seb_kuzminsky> ;-)
<spiv> :)
<seb_kuzminsky> looks like it worked
<spiv> seb_kuzminsky: great
<seb_kuzminsky> aw yea
<seb_kuzminsky> thanks spiv!
<seb_kuzminsky> yeah that's all working just fine :-)
<seb_kuzminsky> yay, thanks again!
<seb_kuzminsky> ok i'll be back when it breaks next time ;-)
<spiv> seb_kuzminsky: good :)
<spiv> lifeless: the three calls are [server] open_branchV2, [client] open, [server] get_stacked_on_url
<lifeless> spiv: right,
<lifeless> open_branch didn't open the branch
<spiv> Right.
<lifeless> spiv: I need to go
<lifeless> spiv: good luck with the branch
<spiv> lifeless: not a problem
<spiv> lifeless: happy travels
<poolie> yes bye lifeless
<poolie> spiv, i have a failure now in test_clone_unstackable_branch_preserves_stackable_repo_format
<poolie> because RemoteBranchFormat, at least in the version of trunk that i've merged, claims not to support stacking
<poolie> whereas with this change it will
<poolie> does this ring any bells?
<spiv> poolie: hmm
<spiv> poolie: that does ring some bells, in that a recent landing touched that code.
<poolie> i think in general robert was going to make tags be handled by making teh format depend on the particular branch
<poolie> not sure that's a great idea
<poolie> at the moment it says it always supports tags
<poolie> so i'm going to make it consistent with that and hope :)
<spiv> poolie: but IIRC the change was that it was going to rely on the underlying format to decide
<spiv> Right, that's what Robert's patch for tags does.
<spiv> (make the format of the branch handle it)
<spiv> Not sure what the overlap with tags and stacking is here though?
<poolie> well, they're both capabilities that are determined by the real on disk format
<Peng_> So now that the 'authors' revision property has been added, 'author' is no longer written, right? Isn't that bad for backwards compatibility with older clients?
<Peng_> I mean, it's not a big deal, but still.
 * igc dinner
<poolie> i thought that we changed it to write out only the additonal authors?
<poolie> but you should raise that on the list?
<Peng_> jelmer: You mean LP's email notifications? I don't know. I know they work for lp:~jelmer/bzr-svn/0.5-mirrored.
<spiv> poolie: regarding the repository acquisition policies, yes, it is a bit weird.
<poolie> spiv, i'm going to try to move it
<spiv> poolie: lifeless lands some changes to allow Branch.clone and others to accept a repository_policy kwarg
<spiv> For similar reasons.
<poolie> hm i remember seeing that but i can't find the mail
<poolie> ah ok
<poolie> so, i'd like to clean it up but it's not all that bad
<poolie> we always create a bzrdir there before we think about stacking
<Peng_> poolie: You thought it was changed to what?
<poolie> but it doesn't really matter because there's only one relevant bzrdir format, and we can choose to make a different branch format before the branch is created
<poolie> i'd say it's not great though
<Peng_> Oh, it only uses 'authors' when multiple authors were passed. That's not so bad, then.
<poolie> Peng_, i thought the issue had been taken into account
<Peng_> Wait, never mind.
<Peng_> poolie: ISTM commit only sets 'authors' now.
<Peng_> beuno: Will Loggerhead try to perform syntax highlighting on gigantic files? IIRC, Mercurial limited it to smallish files.
<poolie> spiv if you're still here
<poolie> or anyone really
<poolie> these likes look backward to me
<poolie> 233  	                require_stacking = True
<poolie> 234  	                result._format.require_stacking()
<poolie> uups
<poolie> 232  	            if not require_stacking and repository_policy._require_stacking:
<poolie> 233  	                require_stacking = True
<poolie> 234  	                result._format.require_stacking()
<poolie> oh i see
<Peng_> poolie: Mailing list message sent, fwiw.
<Mez> hey, anyone have any idea why all of a sudden, I can do a bzr up but not a bzr st (permission denied)
<poolie> what's in the traceback in ~/.bzr.log?
<Mez> one sec
<Mez> poolie: nothing sinister
<Mez> http://rafb.net/p/EMHVs538.html
<Mez> and an strace sees it trying to find files, but getting ENOENTs back
<poolie> but it says permission denied?
<Mez> yep
<poolie> how strange
<poolie> how about bzr -Derror st
<Mez> running selftest .
<poolie> huh?
<Mez> one sec
<Mez> poolie: http://rafb.net/p/qMF0NF83.html
<poolie> ok
<poolie> this is probably because there's a directory in your working tree that you can't read
<poolie> try just ls -laR
<Mez> ah, gnupg
<Mez> http://rafb.net/p/6yTDaq68.html
<poolie> yep
<Mez> o_O
<poolie> also, bug 338653
<ubottu> Launchpad bug 338653 in bzr "OSError is printed without a useful filename" [Medium,Confirmed] https://launchpad.net/bugs/338653
<Mez> the permissions are set to the user though
<Mez> ah, no execute on the directory
<Mez> ok, now getting "no handlers found for logger "bzr"
<poolie> with which version?
<Mez> 1.12
<Mez> (on intrepid)
<Mez> thanks for the help mpool
<igc> vila: do you have some time to give CHKInventory some test love?
<igc> I think we need tests across both Inventory & CHKInventory for *all* the read-only APIs
<igc> the mutation APIs need to be tested separately of course
<igc> we then need to test all of the above for each of the serializer combinations, e.g. chk16, chk255
<AfC> Damn mutants! They're everywhere! Oh, wait...
<igc> vila: what do you think?
<awilkins>  Blimey, DVCS 4tw
<awilkins>  svn working copy of 4 branches : 713 MB on disk
<awilkins>  bzr checkouts, plus the full history of the entire project : 484 MB total
<Peng_> awilkins: Eh. svn's lack of working copy compression FTL. They could do better than 484 MB if they wanted to.
<awilkins> Yeah, and the 17,840 files vs 5,864 isn't too hot either
<awilkins> Gnnnnargh my frickin mother-in-law has put all the cardboard in the recycling bin even though there is a fricking sign on the lid that says not to
<awilkins> Now I'll have to empty the fricking thing out or get fined or something
 * awilkins is sorry for the noise
<Toksyuryel> I thought cardboard was recyclable o.O
<Toksyuryel> are you sure the sign says not to put that in there?
<awilkins> Yes, there is a separate pickup for cardboard/paper
<Toksyuryel> ah
<awilkins> This is the plastic/cans bin
<Toksyuryel> ahhhh, I get it
 * Toksyuryel 's place just has one bin for all the recycling, heh
 * awilkins wonders if they take organic waste, like dismembered^W old meat.
<Toksyuryel> nah, those go to the soylent green facility :P
<workthrick> hiya
<workthrick> so, has anyone thought about getting something like darcs's patch algebra for bzr? Darcs is absolutely neat in that branches sort of magically fall out of related changes, and that you can freely change past patches in non-conflicting ways, but the UI they add to it that tries to pass for a VCS is unbelievably shitty
<luks> hard to do something like that in bzr where each revision has it's parents (the history forms a graph), so the order can't be changed
<workthrick> I guess, that was also a question of "how very hard would it be to do?"
<workthrick> because the patch algebra has some really cool consequences (at least as long as you don't get into exponential time corner cases :)
<luks> by hard I meant impossible :)
<workthrick> like the fact that darcs is the only VCS that gets merges right where a series of patches reverts changes textually, but not semantically
<luks> the patch theory is based on the fact that you can manupulate the order of patches, which in bzr you can't
<workthrick> I know, so bzr would have to be hacked quite badly. I supposed as much. But would it really be completely impossible to allow reordering them?
<luks> using the DAG model bzr uses, yes
<workthrick> darcs has ordering too. It just has rules for generating a new order from the old one
<luks> history in the DAG model is immutable, every state (=revision) strictly depends on everything that happened before
<luks> if you change one piece, everything breaks
<workthrick> so what is the model darcs uses? As far as I understand things, it's DAG + algebra for generating new, semantically equivalent DAGs
<luks> the main difference is that it's main object are patches
<workthrick> oh
<luks> in bzr it's states (revisions)
<luks> the fact that data are delta compressed is just implementation detail
<workthrick> hmm
<luks> you can see it as if you had one full directory of files for each revision
<workthrick> yeah, I get that
<davidoc> Another question: is it possible to discard old revisions before a specified revision? I split a tree and I want to get rid of the revisions before the split.
<luks> just a few lines above I explained that something like that is not possible :)
<workthrick> hehe
<luks> you can make a new branch, without the revisions
<luks> but the revisions you want to keep will not be identical, they will just look similar
<davidoc> oops!
<davidoc> So how would I do that?
<luks> I don't know of any straightforward way, unfornatunatelly
<pigmej> is there any way to get from python api revisions where single file was changed ?
<davidoc> Oh well. I suppose I can manually create a new repo with the files as they were at the time of the split.
<Tak> pigmej: yes
<Tak> log.find_touching_revisions()
<pigmej> Tak: hmmm
<luks> I wouldn't use log for that, but on the other hand I don't know what's the currently used API for that
<pigmej> log is for whole branch ?
<Tak> I'm sure it can be done by walking the revision tree if you prefer
<Tak> pigmej: it also accepts a file id
<luks> Tak: it can be done without walking the whole tree, every file has it's own tree stored
<luks> I just don't know the current API
<Peng_> What the? My Loggerhead instance is freaking out. "built revision graph cache: 3762.8832850456238 secs", and it's out of idle workers.
<Peng_> It's good to know that condition doesn't melt my VPS. :)
<pigmej> becouse i'm afraid that checking whole tree will be wrong idea ( becouse of performance )
<Peng_> It doesn't want to shut down, either, but that hardly makes it worse... :P
<DrHalan> hey, i want to check out a PPA in launchpad with olive. What url do i have to use for "branch"?
<luks> lp:bzr-gtk
<luks> oh wait, PPA?
<luks> do you want to install olive from PPA or get the developmnent branch of olive?
<DrHalan> no i want to modify a package in an PPA using olive. Isn't that possible?
<luks> not sure if I understand, sorry
<luks> PPA is a way to build ubuntu packages, it has nothing to do with olive
<pigmej> Hmm in docs I find only logs method...
<DrHalan> ah okay thanks luks
<pigmej> the fastest way to get revision message ( commit message )
<pigmej> revtree=repo.revision_tree(rev_id)
<pigmej> revision=revtree.inventory
<pigmej> revision.message ?
<luks> repo.get_revision(rev_id).message
<luks> or get_revisions if you need more of them
<luks> calling get_revision multiple times is way slower than get_revisions
<Peng_> D'oh, I think I killed Loggerhead at the exact time when it started killing the hung threads itself.
<pigmej> luks: thanks
<pigmej> i need to call it more than one time
<mattions> jelmer: I've upgraded bzr to the latest released and also the bzr-svn
<mattions> but still my svn password is not cached
<mattions> I checkout the repository directly with bzr, not svn
<jelmer> mattions: Did you force svn to cache the password?
<mattions> can be that the problem?
<mattions> I run svn ls <url>
<mattions> but it doesn't ask for the password
<mattions> is it correct?
<jelmer> mattions, ah, you only need passwords for committing?
<mattions> yeah
<jelmer> mattions: So I guess you would have to do a commit with svn first
<mattions> but the problem is the directory is not a working copy of svn
<jelmer> mattions: That's a workaround unfortunately
<mattions> ok, so you suggest
<mattions> wipe out everything
<jelmer> mattions: There's a bug in bzr itself that makes it doesn't support password caching
<mattions> checkout with svn
<jelmer> mattions, no, just make a temporary checkout with svn and do a commit therre
<jelmer> mattions, then remove that temporary svn checkout
<jelmer> and everything should work
<mattions> or right, I'll give a go
<mattions> no, it doesn't work
<mattions> it is normal that ask the password 4 times?
<msoulot> Hi, I try to download with this command "bzr branch lp:bpierre-config-vim .vim" and I get this error message "You have not informed bzr of your launchpad login. If you are attempting a
<msoulot> write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
<msoulot> bzr: ERROR: Target directory ".vim" already exists."
<msoulot> someone can explain me what does it mean, please ?
<jpds> msoulot: Try backing up your current vim configuration: mv .vim .vim-backup
<msoulot> ok thanks but what this sentence means "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again."
<jpds> msoulot: If you have a Launchpad ID, you have register it with bzr doing: bzr launchpad-login <lp-id>
<jpds> It probably comes up because you're branching from lp:
<jelmer> mattions, sorry
<jelmer> mattions, doing a "svn commit" in a svn working copy didn't work?
<jelmer> Or it didn't cache the password?
<msoulot> I got an account on launchpad and i tried "bzr launchpad-login msoulot@gmail.com" and i got this error message "bzr: ERROR: The user name msoulot@gmail.com is not registered on Launchpad."
<Tak> do more recent versions of bzr-svn support externs?
<jelmer> Tak: no - it technically can't
<jelmer> Tak, since bzr doesn't support externs
<Tak> ever?
<mattions> jelmer: it didn't cache the password
<mattions> it worked
<jelmer> mattions, do you maybe have you svn set up to not cache passwords?
<mattions> well, how I can discover that?
<jelmer> ~/.subversion/config IIRC
<mattions> with gnoem svn the password is cached
<jelmer> ah
<jelmer> we may not be loading that yet for bzr-svn
<mattions> default is yes
<mattions> so yes is able to cache that
<mattions> actually bzr ask me the password 4 times when I do a commit
<mattions> 2 times when I do an update
<jelmer> so I should fix subvertpy/bzr-svn to also use the gnome keyring svn auth provider
<mattions> but here I am using another subversion
<mattions> not GNOME related
<mattions> I never tried to use bzr with GNOME svn
<jelmer> you're using svn 1.6?
<jelmer> mattions, so bzr asks for a password when updating and svn does not?
<mattions> yes
<mattions> svn 1.5.1
<jelmer> mattions: Can you access the root of the svn repository without a password?
<mattions> no, I need to authenticate to access the svn
<mattions> is not public
<jelmer> hmm, so the password *is* cached by svn but not found by bzr?
<mattions> exactly
<mattions> another interg ont eh temporary checkout if I use bzr to update or commit
<mattions> the password is not requested
<SamB> hey ... does anyone know of an (unofficial) debian package for baz-import ?
<luks> isn't baz-import in bzrtools?
<SamB> seems to be omitted :-(
<luks> are you sure? because I see it in http://packages.debian.org/sid/all/bzrtools/filelist
<mattions> ops, I've seen the sentence I wrote before is a little bit mispelled
<Peng_> msoulot: Use your LP username (like in https://launchpad.net/~username), not your email address.
<mattions> I wanted to say that from the temp checkout the password is not requested for the update or the commit
<SamB> huh ... I guess that's what I get for using experimental :-(
<SamB> ... but pybaz is apparantly not available anymore anyway?
 * SamB doesn't use experimental for much, just a package here and there
<jelmer> mattions, can you check where the password is cached?
<jelmer> luks, SamDB: It's no longer in bzrtools
<jelmer> was removed recently
<luks> well, it is in 1.5 :)
<jelmer> luks, yes, aaron split it out
<luks> and (sane) debian has 1.5
<jelmer> squeeze won't
<jelmer> mattions, I would expect ~/.subversion/auth
<mattions> yes is there
<jelmer> mattions, what version of subvertpy are you using?
<mattions> (0, 6, 1)
<mattions> jelmer: on synaptic the package (python-subversion) shows up as 1.5.1dsfg1-1ubuntu
<jelmer> mattions, python-subversion is not used by bzr-svn
<jelmer> and not the same thing as subertpy
<SamB> try looking at the bzr-svn package in synaptic?
<SamB> then go from there?
<mattions> I installed bzr from the PPa
<mattions> but if I search for the subvertpy I can't find the package
<joem86> hello everyone.
<SamB> hmm, bzr-svn used to depend on python-subersion
<jelmer> mattions, python-subvertpy
<jelmer> SamB, no longer as of 0.4.10
<joem86> I installed bzr-gtk on ubuntu 8.10 from the default repository. Do I need to logoff and login to use nautilus-bzr?
<SamB> jelmer: that's odd
<SamB> 0.4.10-2 seems to ...
<jelmer> SamB, maybe 0.4.11
<mattions> jelmer: 0.6.1-1~ppa1~intrepid1
<jelmer> mattions, Hmm, no idea then sorry
<jelmer> gtg
<mattions> k, no probl
<SamB> jelmer: it looks like the BzrTools wiki page needs to be updated to point at the new home of baz-import
<SamB> (since a number of other pages link there in connection with baz-import)
<SamB> hmm, what I'd *really* like is support for foreign tla/baz branches
<SamB> I actually want to look at emacs' history including merges without having to use tla *shudder*
<SamB> is there a nice way to do git-style branch-switching ?
<awilkins> SamB: There's the switch command
<awilkins> Works best in a checkout of a branch in a no-trees repository
<awilkins> (lightweight for preference)
<SamB> huh.
<awilkins> It will locate siblings so you can do
<awilkins> bzr switch foo  # my repo contains foo and bar and I am in a checkout of bar
<awilkins> It doesn't have the "branches hidden inside your clone" thing
<awilkins> This is a point of contention for some.
<awilkins> I myself don't mind it but think it would silence many critics if there was a way of supporting either method
<SamB> is there a howto somewhere?
<awilkins> Off the top of my head, I can't recall. It goes.... i) make a no trees repo (with bzr init-repo) ii) branch something you are interested in into it iii) make a branch for a feature iv) use bzr co --lightweight to grab a working tree of it v) switch that at will
<gnomefreak> what bzr app includes bzr-handle-patch? I'm guessing what ever one it is causes my context menu to have "open" on top(nothing ever opens and than have "open with"(is all i want to use open for)
<gnomefreak> ah bzr-gtk
<SamB> peculiar! the wiki is making empty <span class="anchor" id=...> elements instead of using <a id=...> or <a name=...> ...
<jpds> Goes anyone know where the error at http://paste.ubuntu.com/127303/ could be from?
<awilkins> A proxy? The web server?
<SamB> awilkins: I made a wikipage at http://bazaar-vcs.org/GitStyleBranches -- I wonder if the HOWTO I desire will magically appear ?
<gnomefreak> here is the command and output. it should not try to grab upstream tarball since i already have it. looked in changelog nad it is how it should be. http://pastebin.mozilla.org/631007
<ignas> hi
<ignas> can I make a stacked branch  when branching from a branch stored in a shared repository?
<Peng_> ignas: Sure?
<ignas> Peng_: then why am I getting
<ignas> Source format does not support stacking, using format: '1.6'
<ignas>   Packs 5 (adds stacking support, requires bzr 1.6)
<ignas> while on the server i am getting: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<Peng_> Does it still work?
<Peng_> And when are you getting that error? When you try to "bzr upgrade"? That's because the default format is pack-0.92. 1.6 is newer.
<Peng_> I don't know about stacking, so I can't help much. Does the source repository have to support it?
<ignas> oh, so if I want the newer format I must upgrade to the newer format explicitly?
<ignas> something is weird, both the stacked branching and lightweight checkout (i am doing it through http) are trying to download the full repository
<ignas> and i don't really want to have to do that (it's 70 megabytes)
<Peng_> I doubt it will download the entire repository, but it will have to download quite a bit of it to pull out all of the data it needs.
<ignas> Peng_: kind of annoying, as that bit is like 20 megabytes, but it's downloading it at 30 kb/s, while checking out does 70mb at 200kb/s so I kind of don
<ignas> don't know what I am gaining ;)
<ignas> ok, seriously, bzr co --lightweight took 6 minutes and takes up 18 mb, bzr co took 5 minutes and takes up 51 mb (got 200kb max download speed)
<ignas> seems like lightweight checkouts are of any use only if you are very very bandwith constrained, and will do only 1 checkout ever
<ignas> if you want to get a branch of the same project too - shared repository will be both more space and bandwith and time efficient than 2 lightweight checkouts...
<Peng_> What about "bzr branch --stacked"?
<Peng_> 1.) Like I said, I don't know much about lightweight checkouts or stacking. 2.) This really sounds atypical. What version of bzr are you using? It's probably been improved (especially in the release coming up next).
<ignas> it is doing at least as much work as lightweight, but I don't want to spend the 6 minutes to find out for sure
<ignas> bzr 1.12
<ignas> and my project has a looong history
<Peng_> Huh.
<Peng_> Well, I'm surprised, but I don't have anything else to add.
<ignas> it's quite sad, but I am not surprised
<Peng_> Erm, how did you count how much bandwidth was used?
<ignas> bzr has a progress bar that shows how much was downloaded
<ignas> also du -sh matches that number
<ignas> for a lightweight checkout at least
<ignas> mostly matches ;)
<ericvw> To any developers available, will Bazaar be participating in Google Summer of Code?
<BasicOSX> Any bazaar developer launchpad team members online? I volunteered to be  the manager for 1.13 and I need a developer to push the changes into PQM
<jfroy> whoa, there seems to be some issue with adding large files in bzr.dev
<jfroy> I just added a 166 MB file to a branch, and Python shot upward of 1 GB of real memory before completing
<jam> morning igc
<poolie> hello
<jam> hi poolie
<jam> I'm a bit surprised to see you around on your weekend
<jam> trying to get the 1.9 patch finished?
<igc> hi jam, poolie
<poolie> and to help bob tanner
<poolie> i have to go out so i don't know if i can finish it today :/
<jam> igc: I responded to a couple of your bbc patches
<igc> jam: thanks very much for working on the chk-map bug. I'm testing it now
<poolie> i was kinda hoping someone would look at the traceback and say "oh, obviously you just need x" :-)
<jam> I also have a proposed patch which might help your performance
<jam> as InventoryDirectory.children() didn't seem to be using _entries_cache properly.
<jam> poolie: well I did see you return unconditionally true for Remote*
<jam> which seemed a bit fishy to me
<poolie> it was previously unconditionally false :/
<poolie> since that class inherited the default
<poolie> that seems so strange though
<jam> judging by the test name
<jam> it looks like we should be using an old-format
<jam> and have it not try to stack *at all*
<jam> and it is checking, and naturally failing
<jam> did we get rid of a 'clone_on_transport' implementation?
<igc> jam: so I got two patches with the same name - one at 7.20 and one at 7.23 (it's 7.34 now)
<jam> igc: one is against bzr.dev
<jam> the other against brisbane-core
<igc> jam: do I just apply the last one then?
<jam> mailman thoughtfully noticed that the first patch was 800k+
<jam> igc: yeah
<igc> to brisbane-core?
<jam> they are the same content
<igc> ok
<jam> (bazaar@ rejected my first post as being too big)
<poolie> jam, yep, in trunk RemoteBranch definitely always says it doesn't stack
<jam> poolie: So _ensure_real() seems the right trick, but in the end, I think that would require doing "bzr branch lp:XX lp:YY" for it to ever come into play
<poolie> i think this test is actually branching one remote branch to another
<poolie> hm
<poolie> i guess it would be better to avoid ensure_real and to use the network name, if we know it, to find the equivalent local format object and then ask that
<jam> poolie: isn't that what _custom_format is about?
<jam> Anyway, to get things *landed* I would go with _ensure_real()
<jam> rather than spending a lot of time, the day of an RC
<jam> Or set it back to False if that doesn't cause other problems
<jam> poolie: ah you know what... that sort of makes sense. We are testing that if the source format is too old, we don't try to stack.
<jam> And then it is layering RemoteBranch on top of that
<jam> and by changing False => True
<jam> it is now trying to stack, even though the real format doesn't support it
<jam> and thus the test is failing
<poolie> you're talking about test_clone_ignores_policy_for_unsupported_formats?
<jam> poolie: that is the test you showed was failing, yet
<jam> yes
<fta> anyone working on a fix for the md5/sha Deprecation Warnings /w python 2.6 in jaunty?
<jam> fta: I thought vila had a fix for that a while back
<jam> fta: specifically, I see code like:http://paste.ubuntu.com/127469/
<jam> It may just be that the version in Jaunty is older than that patch
<jam> fta: what version is there?
<jam> (It could also be that there is other code that is importing md5/sha1 that we missed)
<fta> !info bzr jaunty
<ubottu> bzr (source: bzr): easy to use distributed version control system. In component main, is optional. Version 1.12-1build1 (jaunty), package size 5077 kB, installed size 17328 kB
<jam> bzr --version
<jam> I would have thought 1.12 had that... :(
<poolie> there are a couple of them with similar failures
<poolie> but all i think to do with the intersection of policy with old formats
<poolie> hm, i should have checked what that test does in trunk
<poolie> maybe it just skips
<poolie> ah ok, i see now what you meant about ensure_real
<poolie> possibly it should fall back to ensure_real if it doesn't know the custom_format
<jam> fta: though I also saw some discussion about things like bzr-pqm causing the problem
<poolie> but the thing is this is called on the format, not the branch
<jam> and that just required another jaunty update
<jam> because it was an old python package
<jam> poolie: so punt and just continue to return False
<poolie> fta, i have a bug about it in python-crypto
<jam> RC is *today* anyway :)
<poolie> jam, i'll try it
<poolie> if it actually works its fine but i think i had more failures that way
<igc> jam: your patches have improved things a lot thanks
<jam> igc: /cheer
<jam> If the directory cache helps
<jam> go ahead and land it
<jam> I just wanted someone to actually run the code before I did
<igc> jam: *but* we're still slow - 1m6s vs 40s for gc-chk255  vs 1.9 over 1k revision in wordpress
<jam> igc: If you are having to call iter_entries()
<jam> then you are going to probably be slower
<jam> why do you need to read the whole inventory?
<igc> that's with all your patches ad my iter_non_root_entries() which is still a big win
<jam> (That kind of code is what got us into trouble in the first place)
<igc> well, the inventory layer is now ok
<igc> The time is evenly spread around chkmap.apply_delta
<jam> igc: If you want, you can try setting _FAST = True in groupcompress.py
<jam> And see how much that effects things
<igc> jam: tell me about parent_id_basename_to_file_id is a good idea
<igc> jam: I see you're planning to make it non-optional
<jam> igc: it is already non optional
<jam> all formats have it
<jam> --dev3 was the only one that didn't
<jam> and robert and I agreed it could just go
<igc> thinking out loud, do we really need it for 1000s of historical revisions or could we generate it the first time it was required?
<jam> igc: it changes only when you have a rename/add/delete
<jam> so for 1000s of revisions, you get 10 changes
<jam> not a lot of overhead
<igc> jam: well every revision has one of those doesn't it?
<jam> igc: every revision has one, but they are all the *same*
<igc> jam: how does it speed lookups?
<jam> the root chk pointer doesn't change
<jam> unless the tree shape changes
<jam> (rename/add/delete)
<jam> igc: for a specific example, the python 40k revisions, has about 300k entries in id_to_entry, but only 12,000 in parent_id...
<jam> igc: it speeds up mapping "path" => file_id
<jam> id_to_entry is purely file_id => entry
<jam> so you have to find an entry
<jam> then load its parent
<poolie> jam, ok, changing it back to return false from supports_stacking seems to be making things pass
<poolie> fingers crossed
<jam> etc
<poolie> probably by just not running those tests :/
<jam> More importantly, to go from a parent to its children
<jam> you have to iterate the *whole* inventory
<jam> poolie: no, it says "clone ignores stacking"
<jam> and it passes
<jam> poolie: because you said it doesn't support stacking
<jam> thus we ignore the stacking policy
<igc> jam: path2id for CHKInventory is currently a copy of the code in Inventory?
<poolie> ok so not literally TestSkipped
<poolie> but it's not testing the real case which is that the remote branch may in fact be stacked
<jam> igc: The issue is *specifically* InventoryDirectory.children()
<jam> if you look at the code path I "removed"
<jam> it walked the whole inventory
<jam> looking for "entry.parent_id == self.file_id"
<jam> because we don't have that info stored any other way
<jam> without the parent_id_basename_to_file_id map
<jam> poolie: I don't know what other tests you are looking at, but the one you posted as failing
<jam> isn't doing that
<jam> I'm sure there are others that probably fit what you describe
<jam> and I think it would be great to address them in 1.14 :)
<igc> jam: ok  - children lookup certainly needs to be fast
<igc> jam: I'll land your chkinventory-children patch now
<jam> igc: I keep forgetting to ask... How's the weather in brisbane?
<Turl> hi
<Turl> I'm getting some warnings about md5 and sha python modules, I thought you would like to know
<igc> jam: absolutely beautiful right now
<Turl> that modules are deprecated (the warning says that) and you should use 'hashlib' now
<jam> poolie: I just tried to update the BrisbaneCore page with some ideas about "major blockers". I don't know that I got everything, and it probably isn't fully polished. But that is what I've thought of so far
<jam> Turl: there seem to be some issues with the python-crypto package in Jaunty
<jam> which we depend on
<jam> hopefully that will get resolved soon
<jam> igc: What's the temp? (So I know what clothes to pack)
<igc> jam: looks like there's some rain on the way but otherwise nice: http://www.bom.gov.au/products/IDQ10095.shtml
<Turl> ok jam, I thought I would let you know about this :)
<jam> igc: I should also mention that jelmer found brisbane-core to be *vastly* faster for bzr-svn converting OOo. Something like 30hrs to do a full conversion, versus 30hrs for the first 10k revisions.
<jam> Turl: thanks. It is a known issue, though I haven't personally followed closely.
<poolie> great
<Turl> np jam
<poolie> that was bug 337073
<ubottu> Launchpad bug 337073 in python-crypto "python-crypto uses sha module that's deprecated in python2.6" [Medium,Confirmed] https://launchpad.net/bugs/337073
<igc> am: I saw that result from jelmer - it's very promising
<igc> jam: ^^^
<jam> igc, poolie: have a good day. I'm done for now. I may sign on later tonight just to do a quick review before I leave tomorrow, but no guarantees
<jam> igc: so that brings back the question of why you ever have to deal with the whole inventory.
<jam> igc: I should also mention that "time bzr fast-export" of my mysql-525 stuff was down around 1 minute. which is == git fast-export on the same data
<jam> igc: that said, "time bzr repository-details" which extracts everything to fultexts, and analyzes chk pages
<jam> is 15s
<jam> so there is still some room
<jam> (just extracting the texts, with no sha sums, etc, is around 6s)
<igc> jam: yes, fast-export seems pretty good and I've done zero profiling/tuning on it
<abadger1999> Is there someway to turn off ensure_config_dir() ?
<abadger1999> ensure_config_dir_exists()
<igc> jam: I'm only dealing with the whole inventory when loading texts. I'll see what the latest repo code does there
<poolie> jam, ok, have a good night
<poolie> i have to go and run some errands
<poolie> that test is still failing
<poolie>  i may poke at it later but it may miss at least rc1 as i expect bob will do that soon
<abadger1999> we're working on a server that submits to a bazaar repo.  It runs as apache.
<abadger1999> When we run this: work_tree.smart_add([self.path]) It tries to create a .bazaar directory in apache's home dir.
<igc> jam: _install_revision still walks the whole inventory via iter_entries()
<igc> jam: fast-import uses a parameterized version of that code
<jam> igc: consider how InterDifferingSerializer does it
<jam> which is able to use _make_delta etc and not need full inventories
<jam> I don't know what you need, I just know that if you have to walk the whole inventory
<jam> things will be slow
<jam> so we need to think if there is a way around it
<igc> jam: right. I'm not sure whether jelmer was going via repo.install_revisions() or not
<igc> if he was, he would have hit the iter_entries() speed issue that existed until just now?
<jelmer> igc: no, I'm not using repo.install_revisions()
<jelmer> igc, I'm using add_revision(), create_by_apply_delta() and directly accessing the texts VFs
<igc> jelmer: so IIUIC, install_revisions() is walking the inventory to build the per-file-graph? Are you doing that some smarter way?
<jelmer> igc: bzr-svn stores the per-file graph
<jelmer> and for non-round-tripped revisions, subversion provides the necessary data
<igc> so the OOo conversion to development5 only works if bzr-svn is used?
<jelmer> igc: Not sure I understand
<rocky> jelmer: ping
<jelmer> igc: The conversion doesn't require round-tripped-revisions or anything, it works with a vanilla OOo SVN repo
<jelmer> rocky, pong
<rocky> jelmer: i decided in an effort to force myself to understand things more i would rewrite get_history() for BzrFileNode in TracBzr (ti's currently what's breaking on bzr 1.12 anyways) ... and i've getting a better understanding such that i can populate the log view properly...
<rocky> but my revision identifiers are nasty ... they are branchpath,fileid
<rocky> and in the trac log view that looks horrible
<jelmer> rocky, branchpath,revid?
<rocky> sorry yes
<rocky> the branch path is fairly long, and the revision_id is huge
<rocky> so it really messes up the log view display
<rocky> is there a more sane way to reference a rev?
<igc> jelmer: I'm trying to work out how you converted the OOo repo so quickly to development5-subtree format
<igc> jelmer: fast-export is currently slower on the new formats
<igc> s/export/import/
<jelmer> igc, ah
<jelmer> igc, yes, bzr-svn would be required for the improved performance
<jelmer> rocky, path,revno?
<rocky> what's the diff between a revno and a revision_id ?
<jelmer> igc, I was also using an improved version of brisbane-core, with another patch
<jelmer> rocky, a revno is smoething like "2"
<jelmer> rocky, a revision id is something like "jelmer@samba-org-20083424782362386-0fjksdhgfkjsdh"
<rocky> jelmer: right, i understand that they look different but what i mean is what limits one versus the other... why have a revno and a revid ?
<jelmer> rocky, revno is more human readable
<jelmer> rocky, it's only unique to a particular branch though
<jelmer> revid is used internally in Bazaar and globally unique
<jelmer> also, revno's are sortable
<jelmer> so revno 42 is always older than revno 43
<rocky> so revid's are meant to be actual uuid's ?
<jelmer> rocky, they are globally unique but not like RFC4122
<rocky> define "global" :)\
<jelmer> rocky, e.g. bzr-svn uses the UUID of the svn repository and the revision number of the subversion commit for the bzr revid
<jelmer> rocky, global as in the same revid is supposed to always point at the same revision
<jelmer> independent of what branch or repository it is in
<jelmer> rocky, e.g. try running "bzr log --show-ids" in one of your branches
<rocky> ah cool
<rocky> jelmer: ok, in any event, the log view works now and doing diff between revs on log view works and clicking on a rev link works... bt clicking on a changeset link doesn't yet work
<jelmer> cool
<rocky> jelmer: here's a question... in a branch, does revno *have* to start with 1 and is it guaranteed not to skip revno's ?
<jelmer> rocky, there are functions in bzr for looking up the revno
<jelmer> rocky, ideally you should be using those rather than calculating them yourself
<jelmer> that would also do caching when it's available
<rocky> i'm only asking because i found code inside bzrlib that is adding up it's revno's by itself ;)
<rocky> in bzrlib.log
<jelmer> they can also get quite complex if they're not on the mainline
<rocky> the whole dotted revno thing right?
<jelmer> yeah
<jelmer> igc: This is all the more reason to move this logic into a Importer object in bzrlib :-)
<igc> jelmer: Agreed! Once I get this version working fast, I'll do that. Next week's sprint will be a good time to talk to lifeless and jam about it
#bzr 2009-03-07
<smoothice> anyone here know how to do a diff between two completely different bazaar branches on Launchpad? (in the same project)
<Peng_> mwhudson: Thanks for the Loggerhead bug fix. :)
<mwhudson> Peng_: thanks for the report!
<mwhudson> i had a flight today, so nothing better to do...
<Peng_> :D
<Peng_> I can never decide, should I reply to the bug report to confirm it was fixed?
<mwhudson> i don't think it's necessary really
<mwhudson> obviously follow up if it's not fixed :)
<Peng_> Heh.
<Peng_> (Bugzilla has both "RESOLVED" and "VERIFIED" states. I think it's useful.)
<BasicOSX> Is there a set of prereq's of packages that needs to be installed for self-test to work? Is it documented anywhere?
<spiv> Ah good, my branch finally made it through PQM.
<lulzmachine> hey! how can I get a file back? I managed to ruin it in my last commit
<Peng_> lulzmachine: "bzr revert -r -2 foo.py"?
<lulzmachine> thx :)
<mwhudson> Peng_: >:)
<pigmej> Hi again
<pigmej> I have a question
<pigmej> some time ago I've read that bzr can take an action after a commit / push etc
<pigmej> I cannot find it in docs again ;/
<LarstiQ> pigmej: `bzr help hooks`
<pigmej> LarstiQ: i need python api for taht
<pigmej> that*
<pigmej> I'm almost sure that I read about that in docs / on page etc...
<pigmej> ok nevermind ;]
<pigmej> that's it ;)
<LarstiQ> pigmej: hmm?
<pigmej> That's what I need :)
<pigmej> I forgot english word ( hook ) for that ;)
<magcius> Does TortoiseBzr have a simple way to push to remote repositories?
<LarstiQ> doesn't it have 'push'?
<magcius> I couldn't find it. I'm not on Windows right now.
<magcius> Is it in the commit dialog?
<LarstiQ> magcius: it's based on qbzr, so you could look at how it does things
<magcius> There is qpush, but I couldn't find a menu item for it in TortoiseBzr.
<magcius> LarstiQ, http://bazaar-vcs.org/TortoiseBzrContextMenu
<magcius> Those are all the items in the context menu right now. I don't see any Push anywhere.
<smoothice> anyone experiencing issues connecting to Launchpad at the moment?
<LarstiQ> smoothice: yes, multiple people are, so it's not you
<LarstiQ> magcius: that page isn't really clear to me on how the menus actually look
<smoothice> LarstiQ: how long as this been going on?
<smoothice> has*
<LarstiQ> smoothice: no idea, couple of people have asked the same question in 1 page of scrollback on #launchpad
<smoothice> ok, thanks
<smoothice> we'll wait and see
<Goundy> Bazaar Branch Format 6 (bzr 0.15)
<Goundy> is there a way to get the branch anyway ?
<Goundy> It's on a testing server.. I mean I'll not use that branch for commits & push
<Goundy> Just getting the sources
<LarstiQ> Goundy: I'm not sure what the question is.
<Goundy> LarstiQ well i started: bzr checkout http://bazaar.launchpad........
<Goundy> to get my sources on a server am using to test my software
<Goundy> but it fails and says "Bazaar Branch Format 6 (bzr 0.15)"
<Goundy> I'm wondering how can I force getting the sources
<LarstiQ> that's not an error message
<Goundy> oh god
<Goundy> sorry >_<
<Goundy> I copied the wrong thing
<Goundy> bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 6 (bzr 0.15)\n'
<Goundy> LarstiQ here it is :-)
<LarstiQ> Goundy: ok, so what version of bzr are you using?
<Goundy> 0.11
<LarstiQ> ugh
<Goundy> I can't upgrade it's not my server
<Goundy> and it's the latest debian package I think
<LarstiQ> Goundy: you can run bzr from source though
<Goundy> LarstiQ run bzr from source ? I don't understand
<LarstiQ> Goundy: Debian stable is on 1.5
<Goundy> ew
<Goundy> weird
<LarstiQ> Goundy: I really really recommend you use something not as ancient as 0.11
<Goundy> LarstiQ well I know but it's just for getting the sources
<Goundy> and not for doing any commitments & push
<LarstiQ> Goundy: wget tarball; tar xzf tarball; cd bzr; ./bzr branch url
<Goundy> ah
<LarstiQ> Goundy: you are using an ancient version of bzr that can't read the (slight lesss ancient) newer format of the branch you're trying to use.
<Goundy> LarstiQ ok thanks ;)
<luke-jr> hey
<luke-jr> any way to do --stacked where the new branch is usable without the parent branch, provided I don't actually try to access the old stuff?
<abentley> luke-jr: no, that's called "shallow branching", and we haven't implemented it yet.
<rocky> jelmer: ping
<jelmer> rocky, pong
<jelmer> luke-jr, hi
<luke-jr> hi
<rocky> jelmer: i haven't done exhaustive testing but my TracBzr branch (bzr1.12-trac0.11.3) seems to work good now...
<jelmer> rocky, does it use revno's now?
<rocky> jelmer: yes
<rocky> branch,revno
<jelmer> luke-jr, any chance you could have a look at bug 326278 ?
<ubottu> Launchpad bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,Incomplete] https://launchpad.net/bugs/326278
<rocky> jelmer: the thing is, i haven't tested any of my changes on bzr < 1.12 or trac < 0.11
<rocky> jelmer: there's a good chance that the bzr changes i made will not work on bzr < 1.12
<jelmer> rocky, bzr < 1.12 shouldn't be a problem
<jelmer> rocky, not sure about trac < 0.11
<rocky> jelmer: i suspect it may still work on trac < 0.11 but i haven't tested
<rocky> i don't think i did anything that was trac-specific
<rocky> s/did/changed/
<luke-jr> jelmer: maybe when I touch that project again; I don't really feel like working atm :x
<rocky> so i don't know what trunk status is... if i should propose merging this first or what
 * rocky hasn't used launchpad much either
<nua> if I have the Branch object and a revision id, how do I get a Revision object for that id?
 * SamB wonders if there is a bzr equivalent for "darcs oblitarate"
<glyph> Good afternoon
<glyph> What is the proper etiquette for landing a branch?
<glyph> By which I mean, I've been using bzr very lightly, mostly for synchronizing hobby projects between my laptop/desktop/server machines
<glyph> the idiom I've been using has been to make a bunch of changes, then push them to the "master" branch on my server
<glyph> I recently realized that this was creating a rather odd version history
<glyph> since I'd have a dozen changes I made on my laptop, then a dozen changes I made on my desktop, but they weren't organized into merges so I couldn't see in my history view when I'd done a "push"
<glyph> The only better way to do things that has occurred to me is to make a local "trunk" branch and a local "working" branch on each machine
<glyph> then do "bzr merge ../working" in trunk before I'm ready to push.
<LarstiQ> that is a common workflow
<glyph> LarstiQ: Is there a way to do that without creating the second branch?
<LarstiQ> (you don't need to merge if working is a simple superset of trunk)
<LarstiQ> glyph: maybe you'd like to work with a checkout instead?
<glyph> LarstiQ: I don't know :) but I don't think so
<glyph> A checkout would force me to push after each commit, yes?
<LarstiQ> glyph: commit does the work, so you don't have to manually 'push', but yes
<glyph> LarstiQ: I feel like a whiteboard would let me explain what I'm after much more easily... let me try to explain a different way
<LarstiQ> glyph: unless you supply --local to commit, when you're ready you would then `bzr update` and commit
<LarstiQ> glyph: sure
<glyph> I encountered this problem a few days ago when the branches on my desktop and laptop diverged.
<glyph> On my laptop, I just did 'bzr merge' to pull in all the changes from the server branch, and that worked great, but it took me a while to understand the diff in my working copy
<glyph> when I finally resolved the conflicts and committed, the resulting history also confused me, because what I really wanted to say was "bundle up the conflicting changes here and let me re-apply them to trunk" or maybe "let me see what I've changed vs. the server's branch"
<glyph> maybe I'm trying to get too complicated here, and just having the second local "trunk" branch makes sense
<glyph> at least, I guess that would solve my current problem
<glyph> but I'm wondering if there's more to it than that :)
 * LarstiQ doesn't see a clear question to grasp onto
<glyph> for example, right now I work in SVN for all my major projects.  merging a feature branch in SVN means, unless you're a rocket-scientist, dropping the branch's history before you merge it
<glyph> I like bzr because it allows me to keep the branch's history
<glyph> LarstiQ: Yes, I apologize :)
<glyph> the thing is, if you have a branch in SVN, it basically represents a diff against trunk since the point it diverged.  If you've got a feature branch, that's really what you want; something that can be collapsed down to a single diff for easy viewing.  I don't understand how to get that diff using bzr.
<LarstiQ> glyph: bzr diff -rancestor:
<glyph> LarstiQ: oh.
<glyph> oh that is so beautiful I could weep.
<LarstiQ> glyph: or you could diff two branches with bzr diff --old and --new
<glyph> LarstiQ: hang on I'm still trying to appreciate the grandeur of -rancestor:
<LarstiQ> ok :)
<LarstiQ> glyph: also see `bzr help revisionspec`
<glyph> LarstiQ: okay
<glyph> LarstiQ: despite the complete incoherence of my question, you've helped a lot :)
<glyph> One more thing though
<glyph> I have heard certain people talk about a thing called a "merge instruction"
<glyph> what's the right way to create one of those
<LarstiQ> glyph: merge-directive? `bzr send`
<LarstiQ> glyph: but a little more context wouldn't hurt to make sure I get what you mean :)
<glyph> ah
<glyph> merge *directive*
<glyph> LarstiQ: well, let's say I'm working on a project with a guy on AIM
<glyph> LarstiQ: I want to send him a pile of changes, but putting them on a web server is problematic (for reasons which are not too interesting)
<glyph> and putting them on an SSH server is fraught with configuration peril
<glyph> so I'd like to just drag and drop something onto the IM window (which, thanks to lots of work making sure my firewall _always_ does what I want for IM transfers, will actually work)
<LarstiQ> glyph: `bzr send` allows you to carry revisions in one file suitable for smtp or IM, so yeah
<LarstiQ> glyph: you tell it which branch to use as a basis to determine which revisions to include, and off you go
<LaserJock> does anybody know if somebody has looked at maybe getting bzr-gtk to use Ubuntu's new notify-osd system?
<LarstiQ> LaserJock: I know sabdfl did some bzr-gtk / new ubuntu notify related things
<LaserJock> ah, cool
<LaserJock> maybe I'll shoot him an email
<fta> $ bzr revert
<fta> bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable"
<fta> ??
<fta> how can i know what is unavailable?
<LarstiQ> fta: do you have write permissions on that tree?
<LarstiQ> fta: (see ~/.bzr.log for the traceback)
<fta> LarstiQ, http://paste.ubuntu.com/127974/
<ronny> sup?
<fta> LarstiQ, i own the full tree, everything is u+rw
<fta> strace shows no attempt to lock or open anything
<LarstiQ> fta: does `bzr info -v` say it's locked?
<LarstiQ> fta: in which case, either something is holding the lock, or it is stale and you can break it with `bzr break-lock`
<fta> nope, no mention of lock in there
<fta> and break-lock says: bzr: ERROR: The lock for '/data/bot/xulrunner-1.9.2.head.daily.intrepid' is in use and cannot be broken.
<LarstiQ> it doesn't mention a lock, yet it is in use?
 * LarstiQ blinks
<LarstiQ> fta: lsof?
<fta> ohoh, an old bzr is still there
<fta> LarstiQ, thanks. I killed it. for some reason, a bzr bd was still running after 2 days, doing nothing
<LarstiQ> fta: woops
<LarstiQ> fta: james_w might be interested in that if you can reproduced it I guess
<fta> i guess so too. I'll keep an eye on my bot
#bzr 2009-03-08
<SamB> is BZR_PROGRESS_BAR=none working for anyone else ?
<SamB> it isn't working for me ...
<jml> SamB: I've never tried it.
<SamB> well, progress bars look really unsightly in emacs buffers :-(
 * SamB wonders if he reported https://bugs.launchpad.net/launchpad-bazaar/+bug/339380 against the correct thing ...
<ubottu> Ubuntu bug 339380 in launchpad-bazaar "push doesn't work when default stacking branch is a mirror that has failed to update ?" [Undecided,New]
<SamB> um, that's not an ubuntu bug is it ?
<SamB> it wasn't supposed to be ...
<SamB> where did everybody go?
<SamB> to bed ?
<SamB> (because of the DST change?)
<jelmer> still here
<jelmer> SamB, #launchpad is more appropriate for launchpad bugs though
<SamB> well, I can't really tell where the bug is ;-)
<jelmer> lifeless, ping
 * SamB wonders if he should report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517770 on launchpad, Debian isn't responding and he has no reason to believe this is a Debian problem ...
<ubottu> Debian bug 517770 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Normal,Open]
<SamB> huh, that thing is neat
<LaserJock> SamB: it nows eeeeverything :-)
<Peng_> mwhudson: If I break the build, you have only yourself to blame. :P
<jelmer> SamB, I'm pretty sure it's not debian specific
<jelmer> SamB, just haven't had time to forward it to lp yet
<SamB> oh, okay, I guess I'll do it then
<james_w> SamB: I've just done it
<james_w> bug 339385
<ubottu> Launchpad bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Undecided,New] https://launchpad.net/bugs/339385
<SamB> ah, okay, subscribed myself to that
<SamB> would it be innapropriate to flag this bug as affecting an emacs-lisp package that runs bzr and expects it to honor that environment variable ?
<SamB> the launchpad documentation doesn't seem to be very clear on the intended meaning of "also affects" ...
<LaserJock> SamB: it would be I think if something had to be fixed in the emacs package in order for it to work
<SamB> oh, no
<LaserJock> so I would think in this case it wouldn't be appropriate
<SamB> but if the package had users, wouldn't it be nice to be able to somehow indicate that this bug would affect that package, so that they wouldn't file a bug against it?
<SamB> but I guess that's more of a launchpad question ...
<LaserJock> well, it might yes, but it would sort of depend on if that's likely
<LaserJock> like take a bug in grep. you're not going to add an "Also affects" to every program that uses grep
<SamB> well, no ;-)
<SamB> but it's very likely that this particular bug will affect anyone using this emacs package on its own code ...
 * SamB wonders when the bug occured
<SamB> (that's how I found it; I initially reported it against the elisp package only to discover that it *was* setting the env var but that wasn't working)
<LaserJock> then what you'd normally do is mark the elisp package task as "Invalid" and do "Also affects" for bzr
 * SamB decides to update http://bazaar-vcs.org/GitStyleBranches with how it's working for him
<SamB> that wasn't necessary because the elisp package wasn't yet using a bug tracker
 * SamB wonders why in the world MoinMoin has markup for <h1> ...
<ronny> hu?
<ronny> its a wiki
<SamB> yes, but the H1 should come from the page title
<ronny> hmm
<ronny> im sure there is some obscure use case that is/was necessary
<SamB> I've tried to explain the procedure in detail: http://bazaar-vcs.org/GitStyleBranches -- criticism welcome
<lifeless> jelmer: pong
<Spaz> does bzr have a way to copy files?
<luks> hm, bzr+ssh (push) is doing something stupid. progress bar is on "Transferring:Walking content. 900/995" and it's doing tons of tiny append requests (~300 bytes on average)
<luks> Spaz: it doesn't
<Spaz> :(
<LarstiQ> luks: -Dhpss?
<LarstiQ> luks: this sounds a bit familiar, just a sec
<luks> LarstiQ: how do you know I knew about the append requests? :)
<luks> s/know/think/
<luks> and sftp fails with PathError: Generic path error: '51i9iwdq4q7i7h37s2ub.fetch': Failure: unable to rename to '../packs/1735d9ebad85f138adac0df322fbfaf0.pack')
<LarstiQ> luks: so that is how you knew ;)
<luks> so it's not possible to push this branch to a remote server
<LarstiQ> luks: bug 331823?
<ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,Fix released] https://launchpad.net/bugs/331823
<luks> there is no stacking involved
<LarstiQ> luks: the title might not be describing the actual problem correctly
<luks> well, unless recent bzr is doing something automagically
<LarstiQ> luks: the bug in question is not in 1.12, but was in bzr.dev
<LarstiQ> fwiw
<LarstiQ> if that doesn't work, it is unfortunately something else
<luks> frankly, that sftp fails worries me a little more
<luks> I never had good luck with bzr+ssh
<luks> the pack code still hides the actual error, so without hacking bzr I can't even know why it's failing
<MarcWeber> Which is the bzr command to find a diff adding or removing a string?
<luks> bzr doesn't have such a command built-in
<MarcWeber> luks ? I'd like to know wether there has been a test case containing "stop on never"
<MarcWeber> So can't I just export a long list of diffs or such?
<luks> there is bzr log -p, but that's probably not released yet
<MarcWeber> I don't mind installing an experimental bazaar version..
<MarcWeber> Thank you!
<LarstiQ> MarcWeber: you can also use the bzr-bisect plugin
<LarstiQ> MarcWeber: which is a bit more general than what you asked, but can get it done.
<MarcWeber> :-) bzr -> git would do as well.
<luks> LarstiQ: I wonder how, you need to check manually whether the string is there or not
<LarstiQ> luks: as the test for yes/no you run 'grep string'
<luks> LarstiQ: that's O(log N) vs O(1) operation :)
<luks> (for human work)
<LarstiQ> luks: oh, I use the 'automatic' branch of bisect, where you write the test once
<LarstiQ> Odd_Bloke: merge it allready ;P (I don't suppose you have since recalled what the problem was?)
<harobed> in bazaar online document, at 5.2.2   Starting a central branch, are there one error in "Here is an example of the second way:" ?
<harobed> I think last line bzr push sftp://centralhost/srv/bzr/project/trunk isn't useful because second example use checkout
<luks> link?
<harobed> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#publishing-a-branch
<harobed> at  5.2.2
<luks> yep, that's wrong
<luks> commit will automatically push in this case
<harobed> Ã happy, I well understand :)
<harobed> luks: can you fix it ?
<luks> maybe, it's been some time since I last sent a bzr patch :)
<luks> I think the example should use branch, not checkout
<luks> because checkouts are explained later
<luks> hm, or not
<luks> "Note that committing inside a working tree created using the checkout command implicitly commits the content to the central location as well as locally."
<harobed> yes
<harobed> I think we must delete push line
<luks> yep
<harobed> luks: you send the patch ?
<harobed> or I do ?
<luks> already sending it
<harobed> great ;)
<luks> or do you want to? :)
<harobed> no, I'm continuing Bazaar user guide reading...
<lifeless> right, BB mail-bombed:)
<Odd_Bloke> LarstiQ: I haven't, and I don't really have time to check whether it's a major issue or not.
<awilkins> jelmer: Ping?
<jelmer> awilkins, pong
<awilkins> jelmer: Are you interested in public SVN repos that cause tracebacks in bzr-svn?
<jelmer> awilkins, yes, very much so
<awilkins> jelmer: The MythTV SVN causes an AssertionError on both a branch and the trunk
<jelmer> awilkins, URL ? :-)
<awilkins> jelmer: I can pack up the repo I have for you to save you some time if you want
<awilkins> http://svn.mythtv.org/svn/branches/release-0-21-fixes
<awilkins> It's a /trunk , /tags , /branches  layout
<awilkins> Traceback at  http://pastebin.ubuntu.com/128387/
<awilkins> ls
<jelmer> awilkins, when does it break exactly?
<jelmer> during the copying phase?
<awilkins> Copying revisions
<awilkins> Hmm, don't need "obsolete packs" do we
<jelmer> awilkins, around which revision?
<jelmer> I'm at 800 now
<awilkins> Around 15000
<awilkins> I was bandwidth bound here, but I don't know which end
<awilkins> I suspect mine though, only 2mbit
<awilkins> Using 1.9-rich-root
<awilkins> As I recall it identifies about 20,000 revisions to copy, and when you try again after it breaks, it has about 4,000 left
<awilkins> Uploading my repo (178MB in an archive) would probably take longer than you downloading at your end :-)
<jelmer> awilkins, I don't get impressive results here either, it seems mainly restricted by the CPU in the server and the latency
<jelmer> hi weigon
<weigon> hi
<rocky> heyo jelmer
<jelmer> hey rocky
<rocky> jelmer: don't suppose you've had a chance to try out my branch? (no idea if you intend on eventually upgrading your tracbzr instnaces)
<jelmer> awilkins, I think I get ~75k
<jelmer> rocky, I don't actually have any tracbzr instances running
<jelmer> rocky, we have one at bugs.bitlbee.org, but I don't have any access to the admin side of things
<rocky> ahhh, gotcha
<jelmer> rocky, If it fixes any actual bugs (the _get_weave one, right?) and you're confident it works well I'd be happy to review it though
<rocky> jelmer: well before my changes i couldn't actually browse the repo, got several problems... not sure what you mean regarding _get_weave tho
<rocky> this is with bzr 1.12
<rocky> jelmer: i wouldn't care about officially branching off to have a branch to release from that only cares about trac 0.11 and bzr > 1.12 support
<rocky> could probably get rid of some gunk that way
<rocky> jelmer: btw, is there anyway to delete a branch from launchpad? i'd like to get rid of my sandbox branch
<jelmer> rocky, Hmm, what in particular broke with 1.12 ?
<jelmer> rocky, I think it's possible to remove a branch from lp, not sure how exactly
<rocky> jelmer: let me switch my branch back to find the original problems
<gnomefreak> in Hardy i'm getting an error when running bzr bd --merge --dont-purge --builder=...... its telling me Unable to load plugin 'builddeb' is there a way around this?
<rocky> jelmer: the _get_weave bug you described... that's because of bzr 1.12
<gnomefreak> bzr: ERROR: unknown command "bd" is also there
<rocky> jelmer: which means viewing the revision log for a file broke
<jelmer> rocky, right
<jelmer> rocky, Please request a merge of your branch into trunk
<rocky> jelmer: hm... looks like that bug was reported back with bzr 1.6 ... bug #263300
<ubottu> Launchpad bug 263300 in trac-bzr "Does not work with bzr 1.6" [Undecided,New] https://launchpad.net/bugs/263300
<jelmer> yeah, it's pretty old
<rocky> wow, which is a duplicate of a bug referencing bzr 1.5
<rocky> jelmer: i think i'll do some more research and such before i request a merge
<jelmer> rocky, more research why ? Because you're not confident your code is right?
<rocky> because i just found out some more info on the bug regarding what the code was just trying to accomlish, it's possible i missed something
<rocky> plus, my branch does more than just fix that
<rocky> it fixes 1 other thing as i recall and cleans up backend.py for pep8
<jelmer> rocky, generally, please keep separate bug fixes in separate branches
<jelmer> so they can be merged independently
<rocky> well, the branch started out as "sandbox" because i didn't know what i was fixing :)
<mwhudson> Peng: hi
<mwhudson> Peng: "However, if I truncate builtins.py, it can't figure it out." -- if you disable the filename guessing, right?
<Peng_> mwhudson: Right.
<Peng_> mwhudson: I'm not sure if I tested it with filename guessing enabled.
<Peng_> mwhudson: Yeah, with filename guessing, it works.
<stefanlsd> How would i revert some changes I did in revision 2.  I am now on rev 13, but just want to drop the rev 2 changes?
<LarstiQ> stefanlsd: obliterate? (harder) or apply a reverse diff? (easy)
<LarstiQ> stefanlsd: bzr merge . -r 2..1
<LarstiQ> for the latter
<mwhudson> Peng_: ok
<mwhudson> Peng_: land it :)
<Peng_> mwhudson: Alright. Thanks. :)
<mwhudson> thanks for the fix
<Peng_> :)
<stefanlsd> LarstiQ: thanks. the reverse diff worked great.
<Peng_> Done.
<lifeless> mwhudson: moin
<mwhudson> lifeless: hi
<thumper> morning
<jelmer> 'morning lifeless, mwhudson, thumper
<lifeless> jelmer: what tz are *you* in :P
<lifeless> jml: https://edge.launchpad.net/testscenarios
<lifeless> jelmer: you might like current subunit - all the merge requests that were outstanding have been landed :)
<awilkins> jelmer: Did your branch from the SVN at mythtv.org reproduce that AssertionError
<lifeless> radix: http://bazaar.launchpad.net/~radix/subunit/report-errors-better/revision/50 ?
<lifeless> radix: no test for it ? :P
<jfroy> jelmer: ping
<LarstiQ> lifeless: I have vague notion in my head that you've done something with testing and resources, is that correct?
<lifeless> LarstiQ: :P
 * LarstiQ wonders how to interpret that :P
<LarstiQ> lifeless: the problem I have is that some tests need different/largish datasets, I'd like the loading of them work irregardless of where you run the test from
<lifeless> LarstiQ: lp:testresources may match your needs
<LarstiQ> lifeless: kiitos
<lifeless> LarstiQ: its specifically designed though, for resources that multiple tests need
<lifeless> LarstiQ: e.g. 'a mysql db' or 'a configured django server' etc
<LarstiQ> lifeless: not too far from what I'm going through
<lifeless> LarstiQ: there is another project, 'testscenarios' which is closer to regular dependency injection, which is 'run this one test in N different scenarios'
<lifeless> LarstiQ: high up my TODO list is making these two projects play really well together
<LarstiQ> lifeless: also useful, but not what I'm looking for right now
 * LarstiQ had briefly looked at some things on pypi
<lifeless> LarstiQ: just ping me for any info you want on testresources
<lifeless> the api needs a little love at the moment
<LarstiQ> lifeless: will do
<mwhudson>   File "/home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/plugins/groupcompress/groupcompress.py", line 753, in get_record_stream
<mwhudson>     yield FulltextContentFactory(key, parents, sha1, bytes)
<mwhudson> UnboundLocalError: local variable 'bytes' referenced before assignment
<mwhudson> um, guys?
<lifeless> mwhudson: that wouldn't seem to work :P
<mwhudson> this was bzr pull ../bzr.dev into an empty --gc-chk255 branch
<lifeless> mwhudson: intent that line 4
<lifeless> and at the end of the if at line 742 yield a chunked one appropriately
<lifeless> indent
<mwhudson> lifeless: i have no idea what "yield a chunked one appropriately" means
<lifeless> yield ChunkedContentFactory(key, parents, sha1, bytes)
<lifeless> erm
<lifeless> s/bytes/chunks
<lifeless> mwhudson: probably want to drop into pdb once, and check the type of chunks
<lifeless> if it is a bytestring, just change the variable names
<mwhudson> lifeless: seems to be progressing now
<lifeless> if it is a list, ^^ chunked factory type
<mwhudson> well, to a point, then i got
<mwhudson> bzr: ERROR: Revision {('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x21d9b50>".
<lifeless> mwhudson: I suspect you have a very old bzr.dev repo
<lifeless> that looks like the issues I was repairing in mine
<mwhudson> there's something about bzr.dev -r 1512 that confuses it
<mwhudson> it's fairly old i guess
<mwhudson> reconcile time?
<lifeless> grab a copy from http://bazaar-vcs.org to /tmp
<lifeless> reconcile isn't a big enough hammer
<mwhudson> or that
<mwhudson> ok
<lifeless> brekfasty things
 * mwhudson stabs his isp
<mwhudson> lifeless: (when you get back) is lp:bzr repaired sufficiently?
<Kobaz> aww
<Kobaz> bzr diff doesn't take multiple files for arguments
<thrope> hi - I'm having some trouble, runninng 1.12 and bzr-svn 0.5.2 - dont use it much, bt just tried to check the log of NEWS in loggerhead branch, got an error about subvertpy
<thrope> so I installed subvertpy with easy_install
<thrope> and now I just get a segmentation
<thrope> I was hoping bazaar would be getting more stable with the frequent releases after all the trouble i had when starting out with it
<thrope> but it seems not!
<thrope> what can I do to debug a segmentation fault
<thrope> when i try to do log on a file
<bob2> Kobaz: eh, yes it does
<thrope> removing bzr-svn seemed to fix it - strange that it completely breaks bzr, even on plain bzr branches that having nothing to do with svn
<lifeless> mwhudson: lp:bzr - dunno
<lifeless> mwhudson: I'd hope so cause the format change recently was done after repair
<lifeless> thrope: so bzr-svn sefaulting - please do file a bug on bzr-svn
<mwhudson> should be then
<lifeless> thrope: as for it affecting to many bzr commands, I've filed a bug on that just recently :), and the next version is somewhat better. It does hook in at a very basic level though which means that early-faults inbzr-svn will show up
<thrope> lifeless: i will reinsall and see if I can reproduce it, but I reading a bit I think it doesn't support python 2.4 which I am on, so perhaps it was that
<mwhudson> lifeless: same result with lp:bzr :(
<lifeless> mwhudson: hmm
<lifeless> mwhudson: as a hack, set the format._fetch_order = 'topological' in groupcompress
<lifeless> mwhudson: see if that helps
<mwhudson> lifeless: i need more clues than that
<mwhudson> ah, repofmt.py
<mwhudson> lifeless: no difference
<lifeless> testing myself
<lifeless> mwhudson: wherein does it fail?
<lifeless> like, revno ?
<mwhudson> lifeless: https://pastebin.canonical.com/14704/
<mwhudson> it's r1512 that seems to be the problem
<mwhudson> i can pull -r 1511
<lifeless> Pull phase:Transferring revisions 2200/22421
<mwhudson> and then pull -r 1512 fails
<mwhudson> lifeless: it fails soon for me then :)
<lifeless> ok
<mwhudson> repository has 2600 revisions
<lifeless> mwhudson: so, ('selftest-20050621060616-bb8b5b36e3c950c8', 'robertc@robertcollins.net-20050919060519-f582f62146b0b458') is in the source
<lifeless> mwhudson: and not in the target
<lifeless> ('selftest-20050621060616-bb8b5b36e3c950c8', 'john@arbash-meinel.com-20051123154424-a02f8bf990a1fed5')
<lifeless> is the text to insert
<lifeless> I suspect I'll end up hacking deeply on this today :(
<lifeless> mwhudson: ah
<lifeless> (Pdb) self.source.has_revision('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
<lifeless> True
<lifeless> (Pdb) self.target.has_revision('robertc@robertcollins.net-20050919060519-f582f62146b0b458')
<lifeless> True
<lifeless> I remember this
<lifeless> mwhudson: for now, use what you've got to play with :)
<jml> lifeless: thanks.
<mwhudson> lifeless: yeah, makes senss i guess
<lifeless> mwhudson: I've pushed the groupcompress initial bugfix
<lifeless> mwhudson: wipe out your chk repo
<lifeless> mwhudson: and apply this:
<lifeless> --- bzrlib/repository.py        2009-03-07 06:42:07 +0000
<lifeless> +++ bzrlib/repository.py        2009-03-08 23:28:00 +0000
<lifeless> @@ -3381,10 +3381,7 @@
<lifeless>                          # We don't copy the text for the root node unless the
<lifeless>                          # target supports_rich_root.
<lifeless>                          continue
<lifeless> -                    # TODO: Do we need:
<lifeless> -                    #       "if entry.revision == current_revision_id" ?
<lifeless> -                    if entry.revision == current_revision_id:
<lifeless> -                        text_keys.add((file_id, entry.revision))
<lifeless> +                    text_keys.add((file_id, entry.revision))
<lifeless>              revision = self.source.get_revision(current_revision_id)
<lifeless>              pending_deltas.append((basis_id, delta,
<lifeless>                  current_revision_id, revision.parent_ids))
 * mwhudson tries that
<mwhudson> lifeless: it's getting further, at least
<lifeless> mwhudson: we still have a root bug, I'm not landing that patch as it will potentially make fetches a lot longer, but it will work :)
<mwhudson> lifeless: i then got
<mwhudson> bzr: ERROR: Revision {('NEWS-20050323055033-4e00b5db738777ff', 'john@arbash-meinel.com-20060920223617-ee51f416037ec263')} not present in "<bzrlib.plugins.groupcompress.groupcompress.GroupCompressVersionedFiles object at 0x1c2dc90>".
<mwhudson> 7600 revs in :(
<lifeless> mwhudson: grah, I'll run with the change I had you made; but again - use what you have :P
<Kobaz> bob2: no it doesn't
<Kobaz> budder {~/projects/basePBX/postgres/t} kobaz$ bzr diff *
<Kobaz> bzr: ERROR: Path(s) are not versioned: postgres/t/v_cos_includes.pl postgres/t/v_extensions.pl postgres/t/v_trunks.pl postgres/t/v_cos.pl postgres/t/generatePolycomConfig.pl postgres/t/l4p_tests.conf "postgres/t/#v_cos.pl#" postgres/t/v_trunk_groups.pl "postgres/t/#v_extensions.pl#"
<Kobaz> those files are in the repo... and if i do bzr diff v_cos_includes.pl, it works fine
<Kobaz> and even the help says it takes one file
<Kobaz> Usage:   bzr diff [FILE...]
<Kobaz> hmm
<bob2> Kobaz: because you used *, which your SHELL expands to every random file in that dir
<lifeless> Kobaz: what are you trying to accomplish?
<bob2> Kobaz: if you did bzr diff onefileinthebranch.pl twofileinthebranch.pl etc it would work
<Kobaz> actually, if i do bzr diff file1 file2, that actually works
<Kobaz> lifeless: do a diff of all the files in the dir
<Kobaz> okay, so it does take multiple files... but it doesn't handle wildcards properly
<lifeless> Kobaz: 'bzr diff .'
<Kobaz> ah, that works
<bob2> Kobaz: your shell handles the wildcards
<SamB> heh
<Kobaz> well
<bob2> "'bzr diff legitfile.pl somefilethatisn'tinthebranch.pl" should file, imo
<Kobaz> apparently there's some difference between bzr diff *, and bzr diff everyfileinthedirectory
<mwhudson> lifeless: bzr.dev 2238 seems to be the problem this time
<Kobaz> because if i take all the files... and make a list, and send it to bzr diff.. it works fine
<bob2> Kobaz: you missed a file
<bob2> Kobaz: e.g. the # backup files
<Kobaz> but bzr diff * (which in theory is the same thing)... doesn't work
<Kobaz> that doesn't throw an error
<Kobaz> bzr diff #v_cos.pl#  #v_extensions.pl#  generatePolycomConfig.pl  l4p_tests.conf  v_cos.pl  v_cos_includes.pl  v_extensions.pl  v_trunk_groups.pl  v_trunks.pl
<Kobaz> that works fine
<Kobaz> $ echo *                                                                                                                                                   #v_cos.pl# #v_extensions.pl# generatePolycomConfig.pl l4p_tests.conf v_cos.pl v_cos_includes.pl v_extensions.pl v_trunk_groups.pl v_trunks.pl
<Kobaz> that's the shell expansion
<Kobaz> so... something wiggity is going on
<Kobaz> ooooooh
<Kobaz> i see what's going on
<Kobaz> the error message is wrong
<Kobaz> bzr diff \#v_cos.pl# generatePolycomConfig.pl
<Kobaz> bzr: ERROR: Path(s) are not versioned: postgres/t/generatePolycomConfig.pl "postgres/t/#v_cos.pl#"
<Kobaz> it should say : bzr: ERROR: Path(s) are not versioned: "postgres/t/#v_cos.pl#"
<Kobaz> because the perl script is versioned
<mwhudson> lifeless: so using the gc-chk255 format, loggerhead works but is ~twice as slow on most pages
#bzr 2010-03-08
<RenatoSilva> hm sorry, that's not what I want
<RenatoSilva> I want to diff the whole tree in rev 146 and current uncommitted version
<RenatoSilva> just like the current revision was 146
<RenatoSilva> (that command would work as I expect in this case)
<chx> how can i check the version of a checkout? neither bzr status nor bzr info tells me :(
<poolie> bzr revno
<chx> curious. i have two chkecouts, one works, the other throws an APC error (yeah, php webapp) and according to bzr revno they are the same rev?
<chx> oh well. we will figure it out, thanks
<poolie> chx: are they checkouts of the same branch? are they both clean?
<chx> yes and yes
<chx> and they even look the same because i checked a file i changed fairly recently but wait...
<chx> you gave me an idea
<poolie> at this point i would probably 'diff -r' them to get a plain diff without any bzr complications
<chx> hrm, there is a settings file unversioned in his dir but cant cause anything liek this... weiiiiiird. i will just chalk it up to APC.
<poolie> in case something is unversioned or ignored
<mwhudson> diff -r -x .bzr :)
<igc> hi all
<igc> poolie: was that a tweak vote for the What's New in 2.2 doc?
<poolie> igc, i'm not overriding vila but otherwise yes
<poolie> so it's up to you to decide if you want to block on him
<igc> poolie: ok. I'll ping him later today and see if I can make us both happy
<cody-somerville> If I upgrade a branch, can I downgrade it if I run into issues?
<bob2> not if you upgrade to a rich-root-format
<bob2> (from a non-rich-root format)
<cody-somerville> What does the "upgrade this branch" action on launchpad do?
<RAOF> Basically runs âbzr upgrade $THE_BRANCHâ on the launchpad server.
<cody-somerville> The branch currently works with bzr 1.13.1, 2.0.2, and 2.1.0. If I upgrade the branch, will any of those versions no longer be able to interact with the branch?
<mwhudson> cody-somerville: 1.13.1
<mwhudson> (it needs 1.16+)
<RAOF> But bzr+ssh will work all the way back to 1.6, won't it?
<spiv> RAOF: bzr+ssh unfortunately does not fully isolate the client from the remote format
<spiv> RAOF: we'd like to get to that point, but haven't yet.
<mwhudson> and i guess crowberry's ram thanks you for that so far
<RAOF> Oh, really?  I seem to recall testing that 1.6 would branch at one point; maybe I misremember or didn't check hard enough.
<spiv> I suspect you misremember; the hpss client has always checked the remote format string and expected to recognise it.
<lifeless> spiv: not true
<lifeless> spiv: very early hpss was sftp only
<lifeless> sorry, VFS only
<Peng> That contradicts what spiv said?
<mwhudson> lifeless: wouldn't that mean that the _server_ wouldn't have to understand the branch format?
<lifeless> mwhudson: right, I suspect i just failed to read now.
<Peng> Hmm, if you use nosmart+bzr+ssh, will the servef still ignore the format?
<Peng> server*
<lifeless> yes
<Peng> Neat.
<lifeless> [modulo bugs]
<Peng> Yes, that's exactly what I was worried about...
<spiv> lifeless: well, except that the VFS behaviour also checks the remote format too :P
<lifeless> spiv: yes, server side doesn't. I was misreading.
<spiv> Ah.
<parthm> vila: hi
<Supertanker> How do I set my local branch back to a specific revision?
<Peng> Supertanker: In what way? Do you just want to revert the working tree or actually remove later revisions from history?
<Peng> Supertanker: Anyway, "bzr revert -r 123", "bzr update -r 123" (in a recent bzr) or even "bzr uncommit -r 123" are what you want.
<Supertanker> Peng, ah, okay, as usual, I have fine-grained control. Thanks :)
<NyRy> had a question about creating new sub-directories in a directory that belongs to a branch
<NyRy> Do I need to issue the command add again?
<bob2> you need to tell bzr to add anything you would like it to care about
<bob2> as a shortcut, 'bzr mkdir' mkdirs then adds
<NyRy> bob2: I can see in bzr status that bzr has a few directories as "unknown"
<NyRy> Can I use the bzr add command at the parent level or do I need to add each sub-directory individually?
<NyRy> should back up and say that I'm using bzr to vc my web root on my server
<NyRy> I did an initial add, but since new directories have been added
<bob2> presumably you did 'bzr add .' then, so you know the answer now :)
<NyRy> Trying to figure out if I can use "bzr add" at the web root to recursively add everything new or if I have to add each new directory individually
<bob2> yes, of course
<bob2> surely that's how you added stuff originally?
<bob2> don't forget to carefully check the output of 'bzr status' before committing
<bob2> so you don't commit junk
<NyRy> yes, originally did bzr add, but can I do that again
<NyRy> not sure since somethings from the orig add are already in the repository
<NyRy> Sorry if this sense basic, but I'm not 100%
 * igc food
<neaj> when i 'bzr merge http://svn.repo/...', bzr pulls all 300+ revisions before telling me "Branches have no common ancestor" .. can't it fail faster?
<poolie> neaj: perhaps in principle it could
<poolie> you could file a bug against bzr-svn
<neaj> OK thanx .. i guess it's no problem with a fat pipe, but i'm not that well-connected
<poolie> there might be something about the svn protocol that makes it hard to do quickly
<poolie> i'm not sure
<vila> hi all !
<vila> poolie: hey patch pilot :)
<poolie> hello vila
* 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 | bzr 2.1.0 is out
<lifeless> poolie: tomorrow can you reply to my end-of-rotation email?
<poolie> sure
<lifeless> the one I sent friday
<lifeless> its the sort of email to which silence makes one nervous ;)
<poolie> i was waiting for david to agree or whatever
<poolie> but i'll reply
<lifeless> heh.
<lifeless> tjanks
<lifeless> mkanat: ISE's on loggerhead:( - #launchpad
 * igc dinner
<xterm> Hello, is it possible to get a file back from repository if i delete it locally without having to re-checkout the entire repo ?
<neaj> poolie: jelmer lobbed the issue back at you ;-]
<jelmer> sorry :-)
<Peng> xterm: Just the current copy? "bzr cat bzr+ssh://...."
<Peng> xterm: Might still download a decent chunk of data, though.
<neaj> i feel strange .. the bzr channel is bizarely friendly .. (in comparison to most channels I visit)
<xterm> Peng, thank you.
<idnar> bzrly? :D
 * Peng revokes idnar's pun license
<lifeless> neaj: we try ;)
<idnar> heh heh
<lifeless> idnar: -groan- :P
<dvheumen> hi, I've got a question about running the bzr selftest. I've created a branch of lp:bzr/2.0 and I try to run the selftest, but either 2.0 contains errors (according to the test) or it might be that the selftest modules of the *installed* version (2.1) are used. Can I somehow find out what modules are in use?
<dvheumen> I'm running the selftest like: <bzrdir>$ ./bzr selftest
<lifeless> dvheumen: that should be fine. whats erroring?
<spiv> dvheumen: you can check what './bzr --version' reports
<lifeless> dvheumen: and have you run make?
<dvheumen> I just noticed this warning before the actual testing starts: "Unable to load plugin 'news_merge' from '/usr/lib/python2.6/dist-packages/bzrlib/plugins'". This seems to confirm my suspicions.
<dvheumen> no I haven't run make, is this necessary?
<spiv> dvheumen: ah, ./bzr will still try to load the system-wide plugins I guess
<dvheumen> is there any way around this? maybe set PYTHONPATH or something? (I'm not at all familiar with python, yet, but I'd like to change that :P)
<Peng> Well, --no-plugins will disable all plugins.
<jelmer> dvheumen: alternatively you can remove the news_merge plugin in the install directory
<jelmer> dvheumen: if you have admin rights
<jelmer> although we'd be interested to hear why that plugin is failing to load, that seems like a bug
<lifeless> jelmer: for < 2.1, not a bug
<lifeless> jelmer: early fail
<jelmer> lifeless: ah, ok
<lifeless> jelmer: commitfromnews will work on anything; it doesn't [yet] need shiny-newness
<jelmer> lifeless: I think this is about news_merge though
<lifeless> jelmer: yes, I was offering a possibility that you were remembernig the other news related plugin as one that should work on 2.0
<jelmer> lifeless: ah
<jelmer> lifeless: sorry, monday morning syndrome
<lifeless> de nada
<dvheumen> but, I'm still curious, now that I run the selftest with '--no-plugins', is it assured that it runs the 2.0 selftest modules that are in the branch instead of the modules in /usr/lib/python2.6/dist-packages/bzrlib? (And how could I check this?)
<lifeless> yes, and by using python to inspect the various modules __file__
<lifeless> we set the path for bzrlib.plugins explicitly, other than that we use the defaults, and its the manual setting that loads plugins from the system install
<dvheumen> okay thanks
<persia> Good day.  Is there a way to untag akin to uncommitting?
<Peng> persia: bzr tag --delete
<Peng> persia: As with uncommit, it's hard to get rid of the tag from any branches you've pushed to, though. bzr push --overwrite and bzr tag --delete are you friends there.
<persia> Peng: Thanks.  There's always an option I fail to find :)
<Peng> your*
<persia> I used to use push --overwrite a lot, but I've become more conservative about push :)
 * LeoNerd ponders  bzr pushover  as an alias for  push --overwrite
<dvheumen> hi, about the question i asked earlier (regarding the selftest running system-wide plugins even though it is run from a local branch directory). It seems to me that it is worth mentioning something about that in the Bazaar Testing Guide. Do you agree?
<Peng> If it includes other semi-rare gotchas, then yes, that sounds good to me.
<Peng> (Not that I'm an authority on this.)
<dvheumen> Peng, what do you mean by 'other semi-rare gotchas'? Other than that it might result in errors/warnings/unloadable plugins if the modules do not correspond to the bzr version being tested?
<Peng> I mean that it's not a super-common issue. If the guide is very high-level, I'm not sure it warrants mentioning
<Peng> But if the guide goes into other things, and you think it fits well, it sounds good to me.
<dvheumen> okay, well that's exactly why I ask. The point is, I'm just starting with python development so I might encounter things that to others might seem obvious. I'd like to help, but stating the obvious is not that interesting :P
<Peng> It's not obvious, IMO. It's a good thing to warn people about. It's just...it's not a problem people will run into *that* frequently, and I don't know if the testing guide is the kind of document that should include such warnings. (I don't know because I haven't read it.)
<dvheumen> okay tnx, I'll think about it :P
<jam> morning all
<maxb> jelmer: hello from yesterday
<jelmer> maxb: hello
<jelmer> maxb: I remember pinging you, just need to figure out why :-)
<maxb> ah :-)
 * kfogel is away: reboot
<jelmer> maxb: You had an open merge proposal against one of the bzr-rebase branches that I removed
<jelmer> if it still applies, can you please resubmit it?
<maxb> ah, so I did. It's been hanging around on my "Do I need to rethink this logic one more time?" pile
<maxb> I actually have four separate bzr-rewrite branches at various stages of completeness :-/
<jelmer> maxb: heh, ok
<dvheumen> hi. I'm trying to do some (first-time) bugfixing for bazaar. I've selected myself a bug and now I've got some questions about how to approach the test case(s). (I noticed that the patch pilot is currently not online, but maybe someone else can help?) It's about bug: https://bugs.launchpad.net/bzr/+bug/498409 I've selected it to not be too complicated, but maybe the bug itself is even rediculously simple (or I don't get it :P)
<ubottu> Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,Confirmed]
<jelmer> dvheumen: hi
<jelmer> dvheumen: I think that's a fairly tricky thing to test
<jelmer> fixing the bug without a test would be simpler, but alternatively, could I suggest picking a different bug?
<dvheumen> jelmer, this is the fix I have now. http://paste.ubuntu.com/391170/
<dvheumen> I could pick another bug, I don't mind, but if it is this simple ...
<dvheumen> the code is in the 'cmd_revert' class
<jelmer> dvheumen: that looks reasonable enough
<jelmer> dvheumen: Perhaps submit this as a merge request and ask the patch pilot for further guidance?
<dvheumen> should I just make it a branch and then pick a more suitable bug? :)
<dvheumen> okay, I'll do that
<jelmer> dvheumen: I think there might be a helper class that can remember the locking that has been done on a tree somewhere, but I don't have time to look for it atm.
<jelmer> Martin should be able to help you out with that bit though.
<dvheumen> jelmer, okay, so that's how you approach such a case. Okay, I'll ask Martin and in the mean time I'll have a look for the class. Thanks
<dvheumen> I do know how to pick the wrong bugs :P
<jelmer> dvheumen: yeah, that's the pattern we usually use for things like that.
<jam> vila: are you still around?
<jam> (just wanting to say hi)
<vila> jam: yeah, hi ! I thought you were in vacations and without internet access ?
<jam> no, starts on Wed night
<jam> 10th
<vila> oooh, ok
<jam> anyway, I hope you had a decent weekend
<jam> I saw your went offline briefly, (on Fri?)
<jam> power outage?
<vila> yeah, a planned one
<vila> of course it took longer than planned :-/
<dcraven> Is there a way to "name" a shelved change so that you can later retrieve it by that given name rather than the assigned number?
<vila> dcraven: bzr shelve -m name
<vila> dcraven: but you still need to use the number obtained from 'bzr shelve --list'
<dcraven> Oh. Something tells me I missed an obvious bit of the doc :)
<dcraven> vila: That's good stuff. THanks.
<vila> dcraven: may be :-) But if you didn't file a bug asking for clarifications :)
<vila> dcraven: may be :-) But if you didn't, file a bug asking for clarifications :)
<vila> comas are important...
<dcraven> vila: Oh I did see that. I think I mis-interpreted the function of "message".
<vila> ok
<jam> vila: commas are important, too
<vila> jam: hehe, I can't fix a typo without doing another one, story of my life :)
<marv> so i was reading up on bzr, and finally found something I don't like. apparently if you 'bzr merge' and then 'bzr push' it will mess up the remote side's history (making it match the local side). Is there any way around that besides following the "best practice" that involves making all changes in a separate branch and merging that into clone of the central one and pushing?
<beuno> marv, yes
<beuno> set a variable on the server side
<beuno> I can't remember off the top of my head
<beuno> but it's something like append_only = True
<marv> beuno: i saw a reference to that. something like history append only?
<james_w> well, that forces you to use that workflow
<marv> but from what I was reading, that only makes the push that would mess things up fail
<marv> I'm wondering why there can't just be an option to 'push' (or maybe the default) to make it work in a way that doesn't rewrite history remotely
<james_w> not really
<james_w> you could provide an alternative to merge that allowed you to avoid this situation if used at the right time
<marv> in one of the threads i saw, someone said they were going to ask for a merge --remote flag or something
<marv> i guess you could rebase instead of merging, but I'm not sure I like that
<marv> but it seems like there should be like a 'push as merge' command that makes the remote side end up as if I had done all those extra steps but without me having to do them.
<asabil> marv, that's because merge is asymmetric
<asabil> if you instead keep a checkout of trunk, and always merge into trunk then that should be fine
<marv> why should i have to do that? that seems like a UI wart to me. you're asking me to do several extra steps that could all be automated. and the most obvious way of doing things doesn't do what I want. And I see other projects with guides that say you have to follow this certain workflow or you'll mess up our history.
<lifeless> marv: so, its automatable in principle. Its just code.
<lifeless> marv: so far, noone has done a really nice automated version that preserves digital signatures and so on.
<marv> lifeless: interesting. so someone is or was working on it then?
<lifeless> there was at least one plugin offering what you describe
<marv> any idea what it was called? it might be a good place to start
<wadesworld> is there a way to change an existing branch to a different connection method?  i.e. I did bzr branch sftp:// and now I want to change the connection method to bzr+ssh://
<wadesworld> can that be done, or is the only way to branch a new copy with bzr+ssh?
<maxb> wadesworld: bzr pull --remember otherurl
<wadesworld> cool, thanks :)
<lifeless> marv: remotemerge, I think
<nvsbl> can someone help me?
<nvsbl> after i encrypted my home drive (using this guide: http://jacob.hoffman-andrews.com/README/index.php/2009/12/08/howto-encrypt-an-existing-home-directory-on-ubuntu-karmic-koala/)
<nvsbl> bzr suddenly stopped working
<nvsbl> now i get this:
<nvsbl> Permission denied (publickey).
<nvsbl> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<jpds> nvsbl: That sounds more like an SSH error.
<marv> lifeless: thanks
<marv> although i can't find anything on it with google
<maxb> nvsbl: Are you saying you encrypted the homedir on the remote server or the local machine that you're running bzr on? (Either way it's still a SSH problem)
<nvsbl> the local machine
<nvsbl> is there a specific place i can go to ask for help
<nvsbl> perhaps a specific forum or irc channel?
<lifeless> well we can try to help you
<maxb> I can't think of an obvious place for generic ssh help (other than #ubuntu, which is useless because it's so high volume)
<lifeless> does 'ssh <host>' work
<lifeless> what does it output
<lifeless> what does ssh -vv <host> output
<lifeless> etc
<nvsbl> what should the host be if i were trying to get something off launchpad?
<maxb> bazaar.launchpad.net
<maxb> In that case, it would say "No shells on this server." if it's working correctly
<nvsbl> .....No such Launchpad account: nvsbl
<nvsbl> debug1: Authentications that can continue: publickey
<nvsbl> debug1: Trying private key: /home/nvsbl/.ssh/identity
<nvsbl> debug1: Trying private key: /home/nvsbl/.ssh/id_dsa
<nvsbl> debug2: we did not send a packet, disable method
<nvsbl> debug1: No more authentication methods to try.
<nvsbl> Permission denied (publickey).
<nvsbl> why does it think my launchpad account is that? that isn't my account and i'm logged in as my real account
<nvsbl> http://paste.ubuntu.com/391265/ if having the entire output helps
<awilkins> nvsbl, Try  `bzr launchpad-login <your launchpad account name>`
<nvsbl> i did
<nvsbl> same thing
<maxb> nvsbl: Of course, `bzr launchpad-login` only affects bzr. If you're testing it with ssh manually, you'll need to say `ssh your-lp-id@bazaar.launchpad.net`
<nvsbl> http://paste.ubuntu.com/391271/
<nvsbl> same thing, still
<servilio> hi all!
<servilio> I am still struggling with importing from svn
<servilio> using bzr 2.1 & bzr-svn 1.0.2
<NfNitLoop> servilio: Struggling how?
<servilio> no matter what I try, I end up with an empty repository
<servilio> branch, whatever I make
<NfNitLoop> as in, 'bzr log' doesn't show any revisions?
<NfNitLoop> or as in, it lacks a working copy?
<servilio> NfNitLoop: yep, an empty log
<NfNitLoop> do you get an error?
<servilio> NfNitLoop: no error
<NfNitLoop> are you able to svn checkout the same URL?
<servilio> command used: bzr svn-import --verbose file://$PWD/repo-svn/plone/mcmaster.branding.theme repo-bzr/mcmaster.branding.theme
<servilio> NfNitLoop: let me try...
<servilio> NfNitLoop: oh, wait, I can do svn ls no problem
<NfNitLoop> Hrmm, strange.
<servilio> NfNitLoop: and checkout too, just did it
<servilio> I've tried creating a shared repo, and a standalone branch, and a branch inside a shared repo
<servilio> no luck
<NfNitLoop> anything interesting in ~/.bzr.log ?
<servilio> let me see
<NfNitLoop> (please use a pastebin for anything over a couple lines)  :)
<servilio> no error
<servilio> was about to ask what pastebin to use :D
<NfNitLoop> Ehh, doesn't matter to me.
<NfNitLoop> I don't see one in the topic.
<servilio> me neither
 * servilio goes to search for a paste
<NfNitLoop> http://ubuntu.pastebin.com/
<maxb> servilio: You should not need to create anything at all before running `bzr svn-import`
<servilio> maxb: that's what I thought, but that didn't work either
<servilio> NfNitLoop: http://paste.lisp.org/+226A
<maxb> Looks to me as if bzr-svn is having trouble understanding your svn repository
<maxb> Is this repository public?
<servilio> maxb: unfortunately, no
<maxb> hm
<servilio> maxb: not that it could not be, I just don't have a server for it
<servilio> maxb: public server, it is
<NfNitLoop> strange, that log seems to think it found 21 revisions.
<maxb> Well, the easiest way for someone else to understand the problem would be for them to see if happening
<NfNitLoop> and it explicitly says that it didn't create a working copy.
<NfNitLoop> did it create empty subdirectories for you?
<NfNitLoop> with svn-import, iirc those subdirectories are your branches.
<NfNitLoop> THEY will have your history (bzr log)
<servilio> NfNitLoop: when pointing to a non-existing directory it will create it and it has a .bzr directory inside
<NfNitLoop> and 'bzr log' in that directory has no revisions?
<servilio> NfNitLoop: no revision, it even complains that it is not a branch
<NfNitLoop> is mcmaster.branding.theme a branch?   Or does it contain trunk/ branches/ and tags/ ?
<servilio> bzr info says it is a shared repo
<NfNitLoop> nono, the one in your SVN repo.
<servilio> NfNitLoop: it contains the regular trunk/branches/tags structure
<NfNitLoop> ah.  Hmm.
<NfNitLoop> I don't know.
<NfNitLoop> as I've said before, I just use 'bzr branch'.
<servilio> by bzr info I meant when doing it on the newly imported dir
<maxb> servilio: Could you run `svn info file://$PWD/repo-svn/plone/mcmaster.branding.theme` and pastebin please?
<servilio> NfNitLoop: thanks anyway!
<NfNitLoop> try doing bzr branch file://$PWD/repo-svn/plone/mcmaster.branding.theme/trunk yourNewTrunkBranch
<nvsbl> alright, i fixed what was wrong
<nvsbl> all i had to do was create a new ssh key with my launchpad username
<servilio> maxb: http://paste.lisp.org/+226D
<maxb> servilio: Right.... I'm guessing that the problem might be with bzr-svn's layout detection
<maxb> Just to confirm, file:///home/servilio/Trabajo/McMaster/RHPCS/Plone/code/repo-svn/plone/mcmaster.branding.theme/trunk exists?
<servilio> maxb: yes
<servilio> maxb: it is an existing, used repository
<servilio> maxb: I am migrating it to bzr
<servilio> maxb: well, trying to...
<maxb> OK, go to your ~/.bazaar/subversion.conf and find the [c133bc4f-f41c-0410-a8f9-f4ee1c8ca9d1
<maxb> ] section .... It says "guessed-layout = trunk3" ?
<maxb> Change that to "layout = trunk-variable"
<maxb> then try again
<servilio> maxb: will try again, remember using that layout in the command line, but when trying to import the whole repo last  week instead of project by project
<servilio> maxb: great! that created a shared repo and inside the trunk, but I only see 4 revisions from the 40+ that are in svn
<NfNitLoop> servilio: it'll only get revisions that are actually IN trunk.
<NfNitLoop> try doing svn log on file:///home/servilio/Trabajo/McMaster/RHPCS/Plone/code/repo-svn/plone/mcmaster.branding.theme/trunk
<NfNitLoop> it likely only has 4 revisions in it.
<servilio> NfNitLoop: already did ;)
<servilio> doing "svn log file://$PWD/repo-svn/plone/mcmaster.branding.theme/| grep ^r | wc -l" outputs 55
<NfNitLoop> Hrmm.
<NfNitLoop> servilio: at some point in its history, was trunk/ moved?
<NfNitLoop> maybe it's only showing history since trunk has been at its new location?
<NfNitLoop> (I'm not quite sure how that works.)
<servilio> NfNitLoop: if I add --stop-on-copy the log stops at 34
<servilio> NfNitLoop: maybe that together with something else, but not the moving/renaming of the repository alone
<NfNitLoop> servilio: well, does the bzr branch at least accurately reflect the current state of trunk?
<servilio> NfNitLoop: haven't checked that yet
<servilio> NfNitLoop: kept myself busy trying to find a way to keep the history
<NfNitLoop> well, if it has the right content, it's a matter of bzr representing history as best it can.
<NfNitLoop> if it has the wrong content, it's a bug in bzr.
<NfNitLoop> those have two different solutions. :)
<cody-somerville> Thank you bzr developers for making me not have to worry about 'default branches', 'fast forwarding', and other git hell.
<NfNitLoop>  hehe.
<NfNitLoop> cody-somerville: amenn to that!
<NfNitLoop> What is a default branch and fast forwarding? :p
#bzr 2010-03-09
<dvheumen> poolie, I'm working on an 'easy' bug (patch pilot program), and I've got a question for you regarding the approach to take to set up a test for this change. The bug is 498409, (https://bugs.launchpad.net/bzr/+bug/498409) Do you, by any chance, have some time?
<ubottu> Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,In progress]
<poolie> hi dvheumen
<poolie> sure, happy to
 * poolie looks
<poolie> i just finished a call, i'll get some coffee and be back in a minute
<dvheumen> k
<dvheumen> tnx
<dvheumen> okay, well, fixing the bug seemed pretty simple, and jelmer had some said it seemed reasonable to him, so that gives me some confidence. He also gave me a hint on how to approach this particular type of test, which helped greatly. But it seems I've got some sort of a special case (or lack of understanding of python code, which is more or less a given :P)
<dvheumen> This is what I have at the moment (scrambled together) as a test: http://paste.ubuntu.com/391380/ . I know: 1. that this doesn't work, 2. I've chosen the wrong test file for this particular test. 3. I didn't finish the test exactly, but I wanted to compare the content self.locks. But I think that this approach, using this lock helper, doesn't work since cmd_revert creates its own branch instance. And that's where I'm currently stuck :P
<dvheumen> * I wanted to compare the locks history, although now I'm not sure if that was stored in self.locks, but you get the idea
<poolie> hi
<poolie> so, right, actually fixing the bug will be pretty trivial
<dvheumen> Oh, btw, I do think there's a way to work around this, by adding an optional parameter to cmd_revert's run-method in which you can pass on the branch. But I don't like that approach
<poolie> one line probably
<dvheumen> poolie, that's the easy part :P
<dvheumen> I'll get the diff for you
<poolie> so the choice of test location should probably be guided by whether the fix is in cmd_revert or elsewhere
<dvheumen> http://bazaar.launchpad.net/~danny.vanheumen/bzr/bug-498409-bzr-revert-takes-a-branch-lock/revision/4740
<poolie> if it's changed in branch.py, per_branch would be an appropriate place to test it
<poolie> i'm glad you asked for help btw
<dvheumen> it's changed in builtins.py, so the preferred location seemed to be: tests/commands/test_revert.py probably
<poolie> right
<dvheumen> although that one doesn't exist, at least not in the 2.0 branch
<poolie> so i think there is test framework support to record all locks that are taken?
<dvheumen> poolie, right, found that one too
<dvheumen> but it requires you to use a branch instance that is wrapped in this helper that records the history
<lifeless> not all conceptual locks, but all actual locks, yes.
<lifeless> dvheumen: hmm, I think you're missing the lock tracker
<poolie> i thought there was a way to do it globally
<poolie> but this may be only in my head
<lifeless> look at bzrlib.tests.TestCase._track_locks
<lifeless> thats uses the lock hooks to check some test characteristics - that locks are matched during tests
<dvheumen> poolie, I've been using the tests in tests/per_branch/test_locking.py
<lifeless> a single test can hook into Lock.hooks additionally to get extra callbacks
<dvheumen> lifeless, okay, this is interesting. I hadn't seen that yet.
<poolie> dvheumen: what he said is correct: you should be able to just do the test then inspect _lock_actions i think
<dvheumen> poolie, do you by any chance know if they are recorded by default, or should I activate this in some way?
<poolie> it looks like it's on by defaulct
<dvheumen> okay, thanks, in that case I'll give it a try (tomorrow)
<poolie> we should add this to the testing guide
<dvheumen> +1 :P
<dvheumen> poolie, btw, I'm glad you're helping. I've wanted to dive into python for some time, and this provides some goals to tackle :)
<poolie> if there are any bugs tagged 'easy' where it's not obvious how to begin, that's a meta-bug
<poolie> ask someone here and they will add a comment explaining it
<poolie> or tag it -easy :-)
<dvheumen> okay, will do
<dvheumen> hmmm ... maybe I'm asking too fast here, but ... it seems to me that _lock_actions only records lock + unlock, but does not make a distinction between tree, branch and repository locks
<dvheumen> ow w8, I'm asking too fast. There is a distinction made. nevermind, I'll continue puzzling
<poolie> if i were you i'd print the whole thing and look at what happens now
<dvheumen> poolie, yeah, I know. I'm first setting up a test file at the correct location
<dvheumen> btw, maybe it's something to add to the Bazaar Testing Guide documentation too, but I wasn't sure. I was running the selftest of a local 2.0 branch, but the plugins that are tested are taken from the system-wide library patch, and those are of version 2.1.0. Maybe it's a useful remark.
<dvheumen> *path
<poolie> hm, that's no good
<poolie> these are system-wide plugins?
<dvheumen> uhhmm.. well maybe you understand. I ran './bzr selftest' in a local branch in my home dir. But it tried to run tests for the bzr 2.1.0 that was installed with some plugins. One of the plugins wasn't supported in bzr < 2.1.0 so that's how I noticed the error
<dvheumen> *when
<dvheumen> too late, too many errors in my sentences :P
<dvheumen> okay, now a decent clarification: the bzr core tests are ran without problems. But the tests for the plugins are taken from the system-wide library path
<poolie> ok, i see what you mean
<dvheumen> so './bzr selftest --no-plugins' works as expected, but without '--no-plugins' I immediately get the error that one of the plugins can not be loaded
<poolie> right
<poolie> so
<poolie> probably it's a bug in that plugin if it doesn't cleanly declare that it can't work with bzr 2.0
<poolie> it may arguably be a bug in bzr too that it's even trying to load plugins if they're meant for 2.1
<poolie> iow if they're installed underneath the bzrlib directory of a different copy of bzr
<dvheumen> no it's more that, if I just run the unit tests, especially as someone without experience with bzr (or python dev) it seems that the unit tests fail, but it's actually a plugin, not the code in the local branch
<dvheumen> so my first idea was: how can the unit tests fail on a stable release?, while it's actually because of the plugins, not bzr itself
<dvheumen> but it's pretty obvious now, so maybe it's not worth mentioning
<poolie> what i think should be happening is: you get a message 'plugin blah needs bzr 2.1 and can't work with bzr2.0.4'
<poolie> and then the tests pass
<poolie> there are many cases where it is not this clean
<poolie> we should fix them
<lifeless> poolie: dvheumen: you can also hook in explicitly.
<lifeless> because it can be disabled in the test suite, I wouldn't look at self._lock_actions; rather I'd hook it yourself
<lifeless> that way your setup doesn't get recorded, only the bit where you are doing the actual test.
<poolie> how should he do that?
<dvheumen> lifeless, hmmm, I think you're going too fast for me. Do you, by any chance, have an example I can look at?
<lifeless> # prep the test now
<lifeless> #...
<lifeless> locks_taken = []
<lifeless> def gather_lock(result): locks_taken.append(result)
<lifeless>      bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', gather_lock, None)
<poolie> mm
<lifeless> self.run_bzr('revert') # or whatever you want your test code to be
<poolie> it's a bit gross to write this into the particular test
<lifeless> self.assertLength(1, locks_taken)
<poolie> dvheumen: rather than writing your own hook, maybe you should just look at _lock_actions before and after running revert
<poolie> look at what has been added to it
<lifeless> poolie: if disable_lock_checks is disabled, that variable will be untouched always
<lifeless> poolie: its really not meant to be 'user' visible.
<lifeless> I don't think inspecting it from subclasses is a good idea. I think its a bad idea in fact.
<poolie> ok
<poolie> so perhaps we should add to the base class a similar or identical implementation that can be reused?
<poolie> hm
<lifeless> in fact, the hook in this case can be:
<lifeless> locks_taken = []
<lifeless> bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', locks_taken.append, None)
<lifeless> its two lines :)
<poolie> or perhaps we should always record them, and just disable the actual _checks
<poolie> the point is to make it easier for people like danny to write these tests
<lifeless> thats possible too
<lifeless> I do think we should make it easier for people like danny to write tests
<dvheumen> lifeless, I can follow that, but do you know by any chance if I can make a distinction between read/write lock and tree/branch/repository level? Because I got this info, http://paste.ubuntu.com/391407/ and I only see a filename, but it's probably more
<lifeless> however, the _lock_actions is orthogonal infrastructure; it will have noise in it, and clearing it will make cleanups fail
<lifeless> dvheumen: only write locks will show up
<dvheumen> aha, nice :)
<lifeless> dvheumen: its a bit dirty, but you can see the '/branch/' and '/repository/' in the paths.
<dcoles> G'day. Does any know if bzr-svn honours $http_proxy?
<lifeless> these locks are at the lowest layer; Repository and Branch build on top of them: the hook is reporting on things that don't know they are a branch/repository/etc
<poolie> dcoles: it should
<lifeless> dcoles: I think it might
<poolie> in pre-2.0 versions there are problems resolving lp: urls through proxies
<dvheumen> lifeless, yeah I saw that, but it seems like a filename to me, with LockResult around it, I thought this might be some python notation of something like a data structure or so
<dcoles> poolie: Thanks. I'm using 2.1 at the moment, though can't seem to get it to work
<dvheumen> it seems a bit tricky to just search for 'Repository' or 'Checkout' in this string
<lifeless> dvheumen: nope ;) its just that we've given things on disk reasonably sensible names.
<dcoles> poolie: Is there a way to enable debugging so I can see the requests made in the log?
<poolie> dcoles: what in particular? and use -Dhttp
<lifeless> dvheumen: I think its a little tricky too - OTOH this is relatively simple; we can add a higher layer hook later (and i you wanted to do that I'd be happy to mentor)
<poolie> actually those filenames do look pretty strange
<poolie> why is there randomness directly appended to the name?
<lifeless> poolie: the first one is the metadir lock; called branch because of its starting back in 0.0.x; and this is the 'initialise data structure on disk' stage - the lockdirs may not actually exist yet.
<dcoles> poolie: Just like to be sure that I'm actually trying to use the HTTP server - at the moment I get DavRequestFailure - could not connect to HTTP server
<dcoles> poolie: Cheers - I'll take a look
<poolie> lifeless: what i mean is, why is it .bzr/repository/lockyxb3rn4sw1oyx1jzkt45 not .bzr/repository/lock
<poolie> is it still stuck with a temporary name used during creation?
<poolie> it seems strange it would still have that name at least at the time it is released.
<lifeless> poolie: right, thats what I'm saying; I'm guessing it that its during the bootstrap of the lock.
<lifeless> poolie: and we want the release path to match, for the lock checking code
<lifeless> ah actually
<poolie> so i propose to add http://paste.ubuntu.com/391411/ to the guide
<lifeless> poolie:         return '%s(%s%s)' % (self.__class__.__name__,
<lifeless>                              self.lock_url, self.details)
<poolie> looks like a bad repr or something
<poolie> mm thought so
<poolie> that will at least give people a clue
<poolie> adding a better method +1
<lifeless> poolie: I really don't like suggesting people look at _lock_actions
<lifeless> poolie: can we just given a two-line example of capturing to a list?
<poolie> it's just going to encourage that to be copy-and-pasted
<poolie> how about if we add a common method and call that?
<lifeless> sure, though that is more work than simply documenting what can be done today.
<lifeless> at two lines long I'm not personally concerned by copy and paste
<dvheumen> or I could add it after I created a decent example?
<lifeless> anyhow - either is fine with me. Just poking at private stuff in the base class isn't.
<dvheumen> I don't mind
 * lifeless puts nose back into C code for indicator-sound
<poolie> dvheumen: that'd be good
<dvheumen> I'm already contacting you after I've written a (more or less) decent test :P
<dvheumen> okay, created a TODO list. I'd like to do this in a decent way, so I can actually learn something, so I don't mind :) (Could take a couple of days though)
<lifeless> dvheumen: cool
<dvheumen> lifeless, and you can expect a pm after I get how the lower level hook works ;)
<dvheumen> Tnx guys, I'm gonna go find my bed, it's pretty late/early in the Netherlands
<poolie> cheerio
<lifeless> dvheumen: just ask here - if I'm asleep or whatever I'll see it, but someone else may answer too
<poolie> thanks for working on this
<dvheumen> okay, no prob, bye
<dcoles> poolie: Looks like something isn't working for bzr-svn
<dcoles> `http_proxy=... bzr -Dhttp info http://bazaar.launchpad.net/~bzr/bzr/trunk` works
<dcoles> `http_proxy=... bzr -Dhttp info svn+https://clir.googlecode.com/svn/trunk` does not :S
<dcoles> I guess it depends on how bzr-svn's transport works
<poolie> dcoles: maybe you need to set https_proxy?
<dcoles> poolie: If that works I'll feel very silly. :p
<dcoles> Uh.. no dice. *sigh*
<poolie> hm
<poolie> maybe this is a limit in the svn libraries we're calling into
<poolie> anyhow you could file a bug
<dcoles> Just found https://answers.edge.launchpad.net/bzr-svn/+question/101399
<dcoles> So yes, that might be the case
<dcoles> poolie: Ok, so the trick is you have to set it in ~/.subversion/servers
<dcoles> I understand why (since subversion ignores http_proxy, yay!), but a bit obscure to find
<dcoles> Aaaaand... awesome! That works. Thanks for your help poolie
<poolie> great
<poolie> dcoles: see bug 534794
<ubottu> Launchpad bug 534794 in bzr-svn "svn connections should inherit proxy settings" [Low,Triaged] https://launchpad.net/bugs/534794
<dcoles> Haha. I was about to complain that the FAQ entry for 'behind a proxy' was a bit poor, but then again jelmer only created it 31 mins ago :p
<dcoles> But yes. Look forward to that feature.
<lifeless> poolie: bug 534724 - I think you've sidetracked it
<ubottu> Launchpad bug 534724 in bzr "Large Repository.insert_stream_1.19 call when pushing new stacked branch with no new revisions" [Medium,Confirmed] https://launchpad.net/bugs/534724
<lifeless> poolie: its not about new branches, its about trivial commits on existing branches
 * wgrant was going to say that.
<wgrant> Although the initial push is slow too, that wasn't why I filed it.
<lifeless> wgrant: I think you added confusion by including a full test case :)
<lifeless>  / example
<wgrant> lifeless: Yeah, I considered clarifying that after I filed it, but elected not to :/
<R-H> Just testing
<R-H> Changed my nick but I thought it was harder than that
<Peng> Who what? Changing your nick takes a /nick.
<Peng> Aside from dealing with the registration, which is an additional 50 seconds of work (mostly reading NickServ's help)
<chx> how can i make a file the same as it is in lp:drupal ? my tree has a real lot of various changes so lp:drupal is not really a parent or anything...
<bob2> is it a parent or not?
<lifeless> chx: bzr revert -r branch:lp:drupal FILENAMe
<chx> oh tricky
<chx> thanks
<chx> never knew the revisionspec could contain a branch:
<chx> one always learns
<lifeless> bzr help revisionspec
<chx> lifeless: bad news, the Drupal community decided on git :( I am using bzr at my workplace still.
<lifeless> :(
<R-H> Peng: where do I issue the /nick command? Terminal, my IRC client?
<bob2> your irc client
<bob2> since it's an irc command
<R-H> does anyone else see it or just the server?
<SamB_XP> we see the change of nick happen
<SamB_XP> we don't see this
<SamB_XP> /nick not_SamB
<R-H> so if I type /msg nickserve register ... you don't see it?
<SamB_XP> indeed
<SamB_XP> which is good, or we'd know your password!
<R-H> but you just saw it???
<SamB_XP> nope!
<SamB_XP> I just know that that command takes a password
<R-H> Cool, got it changed. Thanks
<Peng> R-H: /parting the channel and /quitting the server are unnecessary, although it is nice to test that your auto-identify command still works.
<R-H> Peng; Good to know. Just was exploring around the client really.
<vila> hi all !
<codygman> I'm doing the bazaar in 5 mins tutorial, and bzr diff isn't showing differences
<donri> codygman, the changes you have made since the last commit, are they made in committed files?
<donri> what does "bzr status" give
<codygman> one second
<codygman> i deleted it and redid the mini tutorial
<codygman> donri: here you go
<codygman> http://dpaste.com/169810/
<codygman> oh wait, you can only look at differences before commit then?
<codygman> aha... how would you look at differences between commits?
<donri> bzr diff -rX..Y
<idnar> or bzr diff -cN
<donri> as i suspected, you didn't make any changes *since the last commit* :)
<donri> that's the default for diff and status: changes made since committing
<idnar> -rX..Y shows you the changes between revision X and revision Y, -cN shows you the changes made in revision N
<codygman> rofl silly mistakes.. they always happen
<donri> codygman, "help" is a useful command also, e.g. bzr help diff
<codygman> yeah.. i did that actually
<codygman> reading man now
<codygman> does bzr have a release folder, or a place where I can put only working versions?
<donri> maybe you want branches, or tags?
<codygman> you mean once I verify that my changes didn't break anything, I can commit them to a certain brance?
<codygman> branch*
<donri> branches are separate lines of development, usually sharing past commits; tags are named commits. (does these definitions apply to bazaar, people?)
<idnar> codygman: in a lot of projects, each new feature / bug fix / whatever will be made on a branch, and then merged to "trunk" once it's ready (for example, the code might have to go through a code review process, or whatever)
<codygman> alright.. that's what i'm wanting to do.. I don't want to upload module and brake everything.. lol
<bob2> donri: yes
<en1gm4> hi all
<awilkins> codygman, It's just social convention in Bazaar as well as SVN (I'm inferring that you are coming from SVN)
<codygman> actually i'm coiming from no version control.. but have read more about SVN than others
<donri> what do you mean by uploading, though?
<codygman> well after my module has been updated and I know it works
<codygman> i'll upload it to my djangos custom-modules direcotry
<codygman> directory
<en1gm4> in a project I'm working on there is a pre-commit  test used like bazaar plugin, the problem is that each developer has to link or copy that plugin in ~/.bazaar, is there any way to distribute it in the <branch>/.bzr ? or some repo setting?
<Peng> en1gm4: Not really -- general arbitrary code execution is considered unwise. :P
<Peng> en1gm4: There is work on doing it in a more-safe way, and it might even be usable, but I don't know.
<awilkins> en1gm4, I'm getting security-hives about a project that just distributes serialized objects in the VCS folder for later deserialization and execution...
<donri> codygman, you should automate your deployment (with e.g. fabric) and have pip pull dependencies from a requirements.txt file, where you can list the path to your module's bazaar branch
<codygman> ahh alright.. i've been looking at fabric
<codygman> thanks donri, think its time for me to shutdown the shell tonight though
<donri> you rest that overworked brain!
<acezar> hi. i have a corruption problem with bzr branch. for some reason, when i branch almost all line with "foo: stuff $bar" become "foo$bar". i can figure if it's a bug or if there is a functionality that i don't know
<acezar> i have no plugins and this is the same with either version 2.0.4 or 2.1.0
<Peng> acezar: "bzr plugins" doesn't list anything?
<Peng> acezar: Are you using some incredibly bizarre file system?
<Peng> acezar: I'm suspicious you may have keyword replacement enabled.
<acezar> i have now fastimport launchpad netrc_credential_store news_merge as plugins. fastimport was'nt installer when i tested. the others are installed as default (i use archlinux)
<acezar> i suspected keywords too but cant find it
<acezar> i work whith sshfs mounted volumes
<acezar> is there any keymord replacement when the keywords plugin is not installed?
<Peng> acezar: The keywords extension uses the content filtering feature built into bzr, but that doesn't do anything by default.
<Peng> Honestly, I've got no idea. :-\ Probably something obvious, but...
<acezar> is the keywod plugin is installed in the repository when used once? it was present on the first branch opration
<Peng> acezar: Ah. No, but the changes it made won't be automagically reverted. Does "bzr diff" show these changes?
<acezar> no
<Peng> um.
<Peng> I don't know much about how content filtering works. :-\ It's possible it does do something permanent.
<acezar> i found
<acezar> the keywords plugin did somthhing to the repository. i don't know what, but a fresh repository witch as never seen the plugin branch perfectly
<acezar> the keywords plugin seems to leave somthing event when uninstalled
<Peng> Oh.
<Peng> Here's what might have happened: someone disabled the keyword plugin, did not revert the changes it had made, and then accidentally committed them.
<Peng> Now they're just normal data. You could use annotate to see what it happened and revert the damage.
<acezar> i dont think. there was a trunk branch exported from cvs. when branched this to test some files were corrupted not the trunk. the keywords plugin was installed (bzr explorer windows). then we try to do the same without the plugin. corruted again
<acezar> so i tryed on my own computer commandline archilux. same result
<acezar> so we tryed to restart from scratch. export form cvs no plugin installed. then branch. no more problems
<Peng> Huh.
<Peng> You said "CVS", so my brain is shutting down to prevent contamination. ;P
<acezar> lol
<bytee> hi! does anyone know if there's an app that can graph bzr commit histories ? i.e. something good for making charts as to who's committed the most in the last year?
<Peng> It's entirely possible something weird happened between the keyword plugin and the CVS converter.
<Peng> bytee: I dunno. Ohloh.net probably does.
<Peng> bytee: If by "graph" you mean "ASCII list", the bzr-stats plugin should be able to do that.
<bytee> Peng: ah ok. let me try bzr-stats
<neaj> hi all .. how do i time-travel my working directory back to revision 2?
<Peng> neaj: bzr revert -r 2
<Peng> neaj: bzr update -r 2 (if your bzr is new enough)
<Peng> neaj: You can also "bzr cat -r 2 some/file" if you just want an old version of one file dumped to stdout
<Peng> neaj: You could even make a new branch, "bzr branch -r 2 some_branch time_travel"
<neaj> Peng: bzr: ERROR: no such option: -r
<neaj> that's for update
<neaj> Bazaar (bzr) 2.0.4
<neaj> won't revert throw away intervening commits?
<neaj> it's a big ol' tree i want to time travel
<Peng> neaj: I guess bzr 2.0.4 isn't new enough, then. :P Must be new in 2.1.
 * neaj kicks Jaunty
<neaj> doing revert ..
<Peng> neaj: What do you mean by "throw away intervening commits"? Revert just meddles with the contents of the working tree; it doesn't change any meta data.
<neaj> phase:comparing files 43229/45619
<neaj> Peng: ah, cool
<Peng> neaj: Even "update" will only meddle with the working tree's contents and meta data; it won't change the branch
<neaj> Peng: i thought reverted reverted a commit to make it like it never happened
<Peng> neaj: uncommit does that
<neaj> Peng: yes, that's what i would expect from update
<Peng> neaj: If you mean "completely remove all traces of it from history".
<neaj> OK, now revert left me with 1000s of files which it's refusing to delete because they're not empty
<neaj> how do i go back to "now" now?
<neaj> how can bzr tell me "Tree is up to date at revision 6." if i just did a 'bzr revert -r 2'?
<neaj> trying bzr revert -r 6
<Peng> neaj: "bzr revert" if you did revert, or "bzr update" if you did update, or "bzr pull -r revid:something" if you did bzr uncommit or bzr branch. :D
<cayblood> I'm getting an error trying to run bzr after installing the Bazaar-2.1.0-2.1 package for OSX: http://gist.github.com/326509
<Peng> (Just FYI, you can find that revid with bzrtools' "bzr heads" command. bzr uncommit will also tell you.)
<neaj> got about a million like this: Conflict adding file zeocluster/src/theme.  Moved existing file to zeocluster/src/theme.moved.
<Peng> Yikes.
<Peng> ("bzr pull . -r revid:something", I should have said.)
<Peng> (Unless you did "bzr branch". Anyway this is off-topic.)
<neaj> i just did the revert commands i pasted
<Peng> neaj: Did it mention any conflicts when you did the original revert?
<neaj> well, you & i pasted
<neaj> yes, revert left me with 1000s of files which it's refusing to delete because they're not empty
<neaj> those were reported as conflicts
<neaj> and now going back to now they were all reported as conflicts again
<Peng> neaj: Right. You had files that bzr isn't tracking (text editor backups, .pyc files, compiled code, etc.), so it refused to delete the directories. Now it's trying to create the directories, but they don't exist, so it's unhappy again.
<Peng> Err, sorry.
<Peng> but they already exist*
<neaj> that doesn't make sense ;-)
<neaj> if it isn't tracking them, how can it be trying to create them?
<neaj> it was tracking them alright
<Peng> When you did "bzr revert -r 2", it deleted all of the stuff it tracked. However, you had files it wasn't tracking lying around, so it couldn't delete all of the directories it wanted to.
<Peng> Now you're doing "bzr revert" and it wants to create those directories -- because it tracks them -- but it's finding that directories with the same names already exist and gets unhappy.
<Peng> (Bazaar tracks directories as first-class objects, just like files.)
<Peng> I'm sorry, but I don't know of a good magic cleanup button for this.
<cayblood> Anyone have any idea what the problem is here? http://gist.github.com/326509
<cayblood> Error I'm getting is "'module' object has no attribute 'SIGWINCH'"
<neaj> Peng: it's OK, it's a sandpit for learning bzr ..
<Peng> cayblood: Oh shoot. Other people have been reporting that too.
<Peng> Err, wait, they might have been on Windows though.
<Peng> cayblood: What OS?
<cayblood> OSX
<Peng> Oh, duh, shoulda looked at the paths...
<cayblood> snow leopard, to be precise
<cayblood> Been trying to get this working with  various versions of python and bzr for a couple days now
<cayblood> running into various problems.
<Peng> cayblood: Bazaar assumes that the SIGWINCH signal exists on all non-Windows platforms. Perhaps it is mistaken.
<cayblood> Finally decided to go with the a plain vanilla setup, remove macports and just try to get the built-in python working
<cayblood> I think it is mistaken
<cayblood> let me investigate
<Peng> Well, the error message states quite obviously that OS X doesn't have that signal, or at least Python doesn't think it does.
<cayblood> Looks like there is support for SIGWINCH in OSX: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/is_term_resized.3x.html
<cayblood> But maybe python doesn't expose it?
<cayblood> I mean, maybe Python is not making the right declarations or something? Just a guess
<Peng> Python should expose it.
<Peng> AFAIK, anyway. But it obviously isn't.
<Peng> There may be a Python bug here, but this is definitely something bzr can fix as well -- it could exclude OS X, or actually check whether SIGWINCH exists instead of assuming based on the OS. You should file a bug.
<vila> cayblood: try: python -c 'import signal; print signal.SIGWINCH'
<cayblood> jussec
<Peng> Err, good point.
<vila> Peng: I tried the above on OSX 10.6.2 and it worked
<Peng> Awesome.
<cayblood> Peng: Here is the result:
<cayblood> http://gist.github.com/326518
<Peng> As a workaround, you can pretty easily hack bzrlib/osutils.py:watch_sigwinch to just return or something.
<Peng> cayblood: Just to be sure, could you: python -c 'import signal; print signal.__file__'
<vila> cayblood: try changing your current dir (wild guess)... hehe like Peng said :)
<cayblood> Could it be a problem with the built-in python version? Apparently it's 2.4.6
<Peng> Maybe.
<cayblood> vila: changing current dir did nothing
<vila> if your PYTHONPATH includes '.' or '' the current directory is searched for modules, environment bug
<Peng> cayblood: What about the command I asked you to run?
<vila> python -v ?
<cayblood> Peng: I got 'module' object has no attribute '__file__'
<vila> I've got python-2.6.1 here
<vila> and AFAICT, it's a stock install
<cayblood> vila: hmm weird
<Peng> cayblood: OK.
<cayblood> vila: only thing I can assume is that my python was not upgraded when I upgraded to Snow Leopard, but I highly doubt that
<Peng> So you _are_ getting the right signal module (almost certainly python -c 'import signal; print signal' would confirm it for sure).
<cayblood> jussec
<Peng> certainly;*
<cayblood> Peng: I get <module 'signal' (built-in)>
<Peng> cayblood: Yeah, OK.
<cayblood> I can check what version of python is running on my colleagues' machines. Jussec...
<Peng> Python's signal module is about as simple as it can be: #ifdef SIGWINCH
 * vila needs food
<cayblood> Looks like fresh installs of snow leopard have 2.6.1
 * Peng has pizza! :D
<neaj> bzr branch -r 2 PlonePIMS-ready PlonePIMS-ready-r2 # <- this worked fine
<neaj> mv PlonePIMS-ready PlonePIMS-ready-orig
<cayblood> For some reason mine has 2.4.6. I will investigate further and see if I can start from a clean baseline.
<neaj> bzr branch -r 6 PlonePIMS-ready-orig PlonePIMS-ready-r6 # <- bzr: ERROR: Not a branch: "/home/jean/PlonePIMS-ready-orig/".
<neaj> ?!
<Peng> neaj: ls PlonePIMS-ready-orig
<Peng> neaj: Maybe it already exists, so your branch is at PlonePIMS-ready/PlonePIMS-ready-orig
<Peng> Err, other way around, sorry.
<Peng> neaj: PlonePIMS-ready-orig/PlonePIMS-ready
<neaj> nope
<cayblood> looks like macports reared its ugly head
<Peng> neaj: ls PlonePIMS-ready-orig/.bzr
<Peng> neaj: Sure you aren't in the wrong directory?
<neaj> lecking again ..
<neaj> checking, sorry ..
<cayblood> for some reason my messages are vanishing from my irc window. is this getting through?
<Peng> cayblood: Yes.
<neaj> cayblood: yes
<cayblood> \/usr\/bin\/python was really pointing to macports (2.4 version)
<Peng> Oh, nice.
<cayblood> Had to backslash this dir because it was being interpreted as a regex
<Peng> cayblood: Maybe your IRC client was assuming it was a command because it starts with /.
<cayblood> yeah probably right How can I escape that?
<Peng> cayblood: Depends on the client.
<cayblood> Not start a command with slash?
<Peng> cayblood: Often something like //foo, / /foo, /say /foo.
<cayblood> ok
<Peng> cayblood: Or that, yes.
<Peng> cayblood: Which client?
<cayblood> colloquy
<neaj> Peng: yay! it was indeed something like you suspected. thank u ..
<Peng> neaj: Oh, whew.
<Peng> cayblood: Ah, dunno about that, sorry.
<Peng> (Some clients are even smart enough to recognize file paths and send them through without you having to do anything extra.)
<cayblood> Yay!!! Switching to python 2.6.1 fixed the problem
<Peng> cayblood: So...this is a MacPorts bug. :D
<cayblood> This happened because I was trusting the macports python_select utility, which wasn't really choosing the version of python that I was telling it to.
<cayblood> But it silently failed.
<Peng> Fun.
 * Peng files a bzr bug. Though actually fixing it would be just as easy...
<maxb> Is there documentation on per-file merge configuration? Specifically is there any better way of stopping bzr-builddeb's debian/changelog merger being used other than --no-plugins?
<jelmer> maxb: there is a configuration option somewhere
<maxb> indeed... :-)
<maxb> If only I could find where
<jelmer> maxb: try "deb_changelog_merge_files = "
<maxb> aha, thanks
<vila> maxb: file bugs so it can be improved too
<jam> morning vila
<vila> morning jam !
<jam> jelmer: ping
<jelmer> hey jam, vila
<vila> jam: I just made tests pass for bug #531967... that was quite a journey :-/
<ubottu> Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967
<jam> hey jelmer. I'm working on refactoring some of the pack-collection internals so that we can re-use some of the logic for other stuff
<jam> (like bzr-search, annotate cache, etc)
<vila> jam: I'll clean up a bit and submit a proposal
<vila> jelmer: hey
<jelmer> jam: ah, neat
<jam> I wanted to check and see if I understood what you were thinking for the bzr-svn/git/hg maps
<jam> vila: it certainly seemed more involved than one might expect
<jam> jelmer: so are you essentially just looking for a (key,value) index, or do you need real content?
<jam> A pack file is generally, 'generic data' storage, + indexes into that
<jam> and I'm wondering if you just need the last bit, or the whole thing?
<jelmer> jam: for all three we need key/value indexes, bzr-svn additionally also needs generic storage for the "svn log" cache
<vila> jam: well, the most annoying part is that deleting a path always win and left no trace, so restoring the other side was... tricky (especially since that shouldn't be versioned anymore)
<jam> jelmer: what would the key be for retrieving the log data?
<jelmer> jam: a revision number
<jam> so you would cache the svn log -r X keyed by UUID + X ?
<jam> (UUID probably being implicit)
<jelmer> jam: We currently have one directory per UUID and that seems to work quite well, so the UUID would indeed be implicit
<jelmer> jam: yeah
<Peng> This could be relevant for Loggerhead too, though I don't know the details.
<jelmer> jam: all of this stuff is write-once, once a particular key is set its value will never change
<jam> jelmer: sure, the issue is just figuring out how tweeze apart our current design
<jam> currently RepositoryPackCollection knows what indexes are there, etc.
<jam> And I think we want a more abstract "there is some data" and "there are some indexes"
<jam> and if all you have is indexes
<jam> figuring out when they need to be repacked
<jam> needs a knob to figure out what data is there
<jam> etc
<jam> anyway, I think I have a handle on the requirements
<jam> just need to keep working away at it.
<jelmer> jam: Cool
<jam> Peng: potentially, though I'm not really sure how loggerhead is doing its caching, and whether it would really want to store it in yet another structure
<Peng> Me neither. :D
<jelmer> jam: I'm not very familiar with the way packs/indexes are managed at the moment so I'm just trying to provide you with sufficient data :-)
<jelmer> jam: Actually, I did work on a pack-based cache for bzr-git a while back, lp:~jelmer/bzr-git/index-based
<jam> jelmer: yeah. I'm quite familiar :) Though I'm trying to also improve some bits
<jam> taking some ideas from bzr-search, etc
<jelmer> jam: if you're wondering what sort of calls bzr-git needs to do on indexes that code should give you a good idea
<jam> jelmer: what is the 'X' ?
<jam> ah, just a placeholder
<jelmer> jam: yep
<jam> you could probably have used ''
<jelmer> jam: no, '' raises an exception somewhere
<jam> interesting
<jam> jelmer: so basically, you created indexes, but just never combine them in that code, right?
<jelmer> jam: yeah
<mrand> Howdy.  I pushed a change, but it is not showing up on launchpad.  Could anyone tell me what I did wrong?  http://pastebin.org/107411
<jam> so for what you need, that is actually pretty easy
<jelmer> jam: each time you pull from git you end up with a new index file
<jam> you can use "for index in self._index._indices: index.key_count()"
<jam> to determine if/when you want to rebuild
<jam> and then just
<jam> self._index.iter_all_entries() => self._builder.add_node()
<jam> I would actually consider doing:
<jam> if num_indexes > 20: rebuild
<jam> and just grow from 1 => 20, then pack down to 1
<jam> you could be 'smarter', but I honestly don't expect huge overheads there
<jelmer> jam: I tried to steal the code from bzr-search for repacking, but it was too much code to duplicate imo
<jam> maybe I'm wrong
<jam> jelmer: yeah, bzr-search is doing lots of other stuff
<jam> and I find the code pretty confusing
<jam> mostly because it is handling "indexes" which are stored as the *data* in a pack, which is then indexed, and then the pack files themselves are indexed
<jelmer> jam: How hard would rebuilding be ? Or could we perhaps have a helper function in bzrlib to ship the rebuilding off to ?
<jelmer> jam: ahh
<jam> jelmer: you aren't rebuilding content
<jam> so rebuilding the indexes
<jelmer> jam: no wonder I had trouble understanding that code
<jam> is just iterating over what you have and adding them to a new builder
<jelmer> jam: ah, ok
<jam> jelmer: something like: http://paste.ubuntu.com/391802/
<Peng> mrand: 1.) Launchpad doesn't allow you to do lp:~user/project/directory/branch. It's a flat namespace, just lp:~user/project/branch.
<jelmer> jam: thanks! I'll give it a try this evening. It'd be really nice if we can get rid of the other cache backends.
<Peng> mrand: Secondly, for the successful push, you left off the "lp:", so it actually pushed to a local directory.
<mrand> Peng: oops!  Thanks.
<Peng> mrand: bzr push lp:~mrand/mythplugins/fix-repeated-file-ext-511653 or something similar
<mrand> Peng: bzr: ERROR: Invalid url supplied to transport: "lp:~mrand/mythplugins-trunk/fix-repeated-file-ext-511653": No such project: mythplugins-trunk
<Peng> mrand: That's exactly what it says -- the project is called "mythplugins", not "mythplugins-trunk".
<mrand> I thought that --create-prefix would take care of the project part.
<mrand> oh, I didn't realize it validated that.  Ok.
<mrand> worked.  Thanks Peng!
<Peng> :D
<RobOakes> Hi, does anyone know how to continue a bzr push request?  I was making an initial commit to launchpad with a big SVN repository (23990 revisions).  The bzr client stalled halfway through and I *really* don't want to start over from scratch.
<RobOakes> The error message says something about finish_writing / finish_reading ...
<RobOakes> The initial error was: The medium 'SmartSSHClientMedium(connected=True, username=u'robertsoakes', host='bazaar.launchpad.net', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<Peng> Yeah, the data got nuked.
<RobOakes> Alternatively, is there a way to do a "shallow" push, similar to a shallow checkout.  The repository has some 15 years of commits, and I only need the most recent history.
<Peng> RobOakes: I don't think you can do that. Using shared repositories or stacked branches, you'll only have to push it once, though.
<RobOakes> Okay.  I was afraid of that.  This particular push had been running for nearly 24 hours, and I was hoping that I wouldn't lost all of that time.
<RobOakes> I guess I should try and convert it locally, then try and push the resulting branch.
<Peng> For what it's worth, you can push part of it at a time, e.g. "bzr push -r 500; bzr push -r 1000; ..."
<Peng> That way it'll be less catastrophic if it fails.
<RobOakes> Oh, that's a really good idea.  Thanks, I didn't realize ou could do that.
<RobOakes> (Still painfully new to Bazaar, but I really like it so far.  And the GUI released last month is *awesome*)
<vila> jam: damn, collateral failing test :-/
<jam> vila: need help?
<vila> jam: I think I understand the problem and know the solution, the needed help is more in the teddy bear area :)
<jelmer> ???
<jam> well, cuddle up, and let Teddy know what you need
<vila> So, on path conflicts, when one side delete the item and the other rename it, the bug was that you couldn't do --take-other, the file-id was gone and the item too
<vila> so I fixed that by leaving .OTHER item (resp .THIS when sides are reverted) and just version that when --take-other is involved
<vila> but now, there is one failing test because for *files* we appear to create 2 conflicts in that case, one path conflict and one content conflict and now both want to create a .OTHER file
<vila> The solution seems to be to *not* create a path conflict for files...
<jam> vila: so for files, we would probably have only 1 conflict if they didn't actually change the content, but just deleted (vs rename), however you can certainly have renamed + modified vs deleted
<jam> however, if both sides rename a file
<jam> that certainly should be a *path* conflict, regardless the content of the file
<jam> right?
<jam> tbh, I'm not sure why a path conflict needs a .OTHER file, versus just having the file_id around in the conflict list
<vila> as soon as you have a deletion I'm pretty sure a content conflict is created
<vila> this sounds more in line with what we do elsewhere, that way, if the user modifies it, that's taken into account
<vila> Doesn't make a lot of sense for dirs, but for symlinks it does
<vila> Also, creating several conflicts for the same file-id/path raises many UI issues: what if the user resolve one ? Should the other be resolved at the same time ?
<jam> vila: http://paste.ubuntu.com/391853/
<vila> The failing test above just exhibit another aspect: helpers for several conflicts on the same path
<jam> only a path conflict
<jam> you only get contents conflict if there was a modification vs a deletion
<jam> so helpers for multiple conflicts is problematic
<jam> but that doesn't mean there *aren't* multiple conflicts
<jam> rename + mod can conflict with a different rename + mod
<jam> it is a bit problematic, but i think we need to present both problems
<vila> right, so my fix is incorrect :-/
<vila> hmm
<vila> And I still haven't all the needed tests for all conflicts to cover my decisions :-/
<vila> At least with the ones I've added the problems become more apparent
<vila> jam: So, another possible fix is to use a different suffix than OTHER...
<jam> so why do you need .OTHER?
<vila> or no helper at all..
<jam> (or .THIS)
<jam> why can't the helper say "oh in that tree it had content X, lets restore it"
<jam> well "content X at path Y"
<jam> it *feels* like the problem is that the Conflict record doesn't include enough information for you
<jam> why not fix it there
<jam> oh, and of course we need to see what happens with older clients in these circumstances
<vila> ha ! Because I don't want to break backward compatibility *now* ? :)
<jam> vila: isn't adding .OTHER going to break it a bit?
<jam> (if you don't version the file, then you don't know its file_id anyway)
<jam> if you have a path, then you can use other_tree.path2id() to get the file_id
<vila> it breaks one test, but I handled file-id None to detect older conflict objects
<jam> if you don't have a path or a file_id, how do you know there is a problem...
<vila> jam: hehe, for the later, I discover the problem by adding a tests dir_deleted, dir_renamed and realized I hadn't enough info to resolve it cleanly
<vila> hence I filed bug #531967
<ubottu> Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967
<vila> synchronicity....
<vila> jam: so without the helpers, I have to find back the right revision tree by iterating tree.get_parent_ids(),
<vila> I'm a bit worried about what could happen if there are more than two parents...
<jam> vila: you are pretty far off in edge-case land
<jam> I wouldn't worry too much about perfect resolution for a missing directory after merging a 2nd parent
<jam> (having to use --force)
<jam> vila: besides, what does '--take-other' really mean if you have multiple OTHERs?
<jam> what if the conflict was that parent 2 conflicted with parent 3
<vila> it means the other at the time of the conflict generation
<jam> tbh, I would rather not trust the actual content of a file on disk
<jam> rather than grabbing in from the repo
<vila> so for THIS, the rparent is the first one, no problem
<vila> right, but we are resolving anyway, not committing yet
<jam> echo new content > foo.OTHER, #oops, bzr resolve --take-other
<vila> bzr remerge foo
<jam> in my undereducated opinion, relying on crums being left in the working tree isn't a great way forward
<jam> crumbs
<jam> it could work
<jam> and don't let the best prevent better
<jam> just doesn't feel ideal
<vila> ok, I'll go the no-helper route and see
<jam> vila: I certainly feel that you've gotten more exposure to this area. So if you feel strongly, don't let me overrule you
<vila> on this particular point no, outside view is good, I ran into too many bumps to get there to trust my final solution
<vila> as being the most.... appropriate instead of ad-hoc :)
<vila> I had the feeling that resolve actions had to remain simple, but this delete stuff may just be the exception for good reasons
<jam> vila: it is possible that we don't want a helper, but I also get the feeling that this is the sort of place where people will be the most confused
<jam> partially because our ContentsConflict sort of sucks
<jam> it doesn't tell you "conflict because you modified X and X was deleted"
<jam> it just says "conflict"
<jam> This came up when I was fixing some of the per-file graph issues for mysql
<vila> yeah, that's part of what I want to address, I just get diverted by this bug
<jam> not only did we have invalid conflicts, they told users basically nothing
<jam> I worked on the former
<jam> vila: oh, and you've probably already spent more than enough time on it ,given its chance to occur, etc.
<vila> yet, I wonder if this bug is not a cause of multiple adds: "Oh, my file is gone, let's bzr add it again"
<jam> finding a resolution would be nice, but don't let it block you too much
<jam> at least, IMO, this could be an XFAIL case
<vila>  yeah, I partly blame 'test after' being harder and taking more time than 'test before' :-P
<jam> i still do a bit of both
<jam> especially when exploring an area
<jam> as I don't really know what I want to test before I get there
<emmajane> jml, ping?
<emmajane> jml, define "hanging"?
<emmajane> jml, your site is created...
<jml> emmajane, w/ Chrome, nothing happens after the submit button changes to "Creating..."
<jml> emmajane, works fine on firefox
<emmajane> jml, *nod* thanks.
<emmajane> jml, We think it may be an issue with the way webkit handles button disabling.
<emmajane> thanks. :)
<jml> emmajane, my pleasure.
<emmajane> jml, I owe you a bug sometime. ;)
<emmajane> no wait. Beer. I owe you a beer. ;)
<jml> emmajane, :D
<emmajane> gah. You and your blacked out faces on twitter. /me was too quick on the reply, jml :)
<jml> emmajane, I need more time
<emmajane> generally in the world?
<jml> to do things like change avatars
<jml> move my blog off blogspot
<jml> come up with a new theme
<emmajane> jml, ah yes.
<emmajane> jml "personal branding" time?
<jml> emmajane, yeah, that.
<emmajane> jml, If you figure out where that time comes from, can you let me know? I could do with some of it too.
<jml> emmajane, will do.
<emmajane> jml, ta :)
<emmajane> ok. lunch time.
<vila> jam: meh, from a tree treansform, I get a DirStateRevisionTree for one parent tree but I can't get my hands on a deleted entry as it appears to be blocked by the dirstate one:
<vila> [('a', '', 0L, 0, ''), ('a', '', 0L, 0, ''), ('d', '', 0L, 0, 'other')]
<vila> jam: I want the 'd' in the third tuple ('other'), I get the 'a' in the second tuple
<vila> jam: id2path and path2id give the expected results... is that a bug ?
<jam> vila: it is certainly possible there is a DSRT bug
<jam> are you sure you have the tree for the third parent?
<vila> 'other' is the expected revid, and id2path/path2id are correct for my file-id (i.e. it exists)
<vila> what do you mean by third ?
<jam> what does DSRT._get_parent_index() return
<vila> 2
<vila> meh
<jam> so I think it is "working, basis, merge_parent"
<jam> as for the indexes
<jam> I'm trying to understand what you mean by "deleted entry" are you trying to "_get_entry()" ?
<jam> or Inventory[file_id] or ?
<vila> I got it from: tt._tree.get_parent_ids()[-1]
<vila> I got the DRST tree that is
<jam> vila: you wouldn't get a tree from 'get_parent_ids()'
<jam> you mean "_tree.revision_tree(tree.get_parent_ids()[-1])" ?
<jam> regardless
<vila> yeah, right, sry, tt._tree.revision_tree(revid)
<vila> yeah
<jam> I still don't know what you mean by "I can't get my hands on a deleted entry"
<jam> what is "entry"
<vila> self._get_entry(file_id=file_id)[1]
<jam> vila: doesn't that need to be [2] ?
<vila> as used in kind()
<jam> or more accurately
<jam> [_get_parent_index()]
<jam> specifically, _get_entry(...)[1] is getting the value in the *basis* tree, IIRC
<jam> maybe I'm thinking wrong
<jam> just a sec
<jam> unfortunately, there are multiple _get_entry() possibilities :(
<jam> oh, and why are you using that anyway ?
<jam> certainly you shouldn't be doing "tree._get_entry()"
<vila> http://paste.ubuntu.com/391926 for context
<vila> jam: because it's called by transform.create_from_tree
<vila> which I use to restore the old content
<jam> so, I'm pretty sure DSRT.kind is broken, but I don't have proof yet
<jam> looking at it, I'm pretty sure that _dirstate._get_entry()  is supposed to return the row for that record
<jam> for the tree specified, but it includes all records
<jam> it will take a bit to explain
<jam> DirState._get_entry(tree_index)
<jam> returns a record
<jam> for the file_id + path that matches in the given index
<jam> well, parent 'offset'
<jam> however, that record should include the info for *each* parent
<jam> and the issue is that entry[1][0] is going to always return the kind in the WT
<jam> I think it should be
<jam> http://paste.ubuntu.com/391931/
<jam> this is one of the major problems using tuples + lists as your data structure
<jam> I really need to drop into pdb to know for sure
<vila> jam: that seems correct, using 2 instead of 1 makes the mirror test fail,
<vila> using _get_parent_index make both tests succeed
<jam> rows in dirstate
<jam> are stored using
<jam> (dirpath, name, file_id) keys
<jam> so the lookup returns the row matching that for the given tree
<jam> but the 'value' is the whole role for all records
<jam> so a renamed object shows up in 2 rows
<jam> with an 'r' record in certain columns
<vila> jam: should I file a specific bug ?
<vila> err
<jam> looks like a bug to me
<vila> what could be the consequences in your opinion ?
<jam> Tree.kind() returning the wrong value for objects which change kind
<jam> however, note that we don't really use Tree.revision_tree() for anything other that Tree.basis_tree()
<jam> *today*
<jam> other than
<jam> And we are planning on getting rid of the extra parent trees being cached in the Dirstate file in the next dirstate revision
<vila> well, except for merge, revert and friends no ?
<jam> nope
<jam> merge + revert only care about the basis tree
<jam> generally
<jam> well, your new revert starts caring about other trees
<vila> oh, because they use trees that aren't cached in the dirstate so they get correct ones ?
<jam> new *resolve*
<jam> vila: right, the tree cached in the dirstate is currently not 100% correct for objects that aren't the basis tree
<jam> but they aren't really used :)
<jam> but for merge, that tree isn't in the dirstate yet
<vila> yup
<vila> and wasn't when I use that code to create the helpers :)
<jam> (note, I think the data stored is correct, but obviously we have a bug)
<jam> we basically decided that caching parent>basis is not wortwhile
<jam> !=basis
<vila> hehe, I knew I was in a mine-field I just didn't realized how big it was :)
<jam> we should have fast enough access to RevisionTrees in chk formats
<vila> sure
<jam> and we don't really need it for *status*
<jam> the only place it would have been a win is for 'commit.record_iter_changes()' after a merge
<jam> but IIRC we solved that without using a multi-way iter_changes
<jam> we had *thought* we wanted iter_changes against multiple parents, but we never implmeneted it
<jam> thus we have cruft that we never use
<jam> and is scheduled for removal :)
<jam> except now *you* are trying to use it :)
<jam> it is very useful for *basis* because we want to compare working vs basis often, and do it based on path
<jam> for the rest, we tend to compare based on file_id anyway
<jam> and RevisionTree does that well
<vila> jam: well, I don't use it explicitly I just ask for a revision tree from a working tree :)
<jam> vila: that will raise NoSuchRevision if it isn't present
<vila> I don't care whether it's cached or not (yet and may be never)
<jam> long discussion a while ago
<vila> in the DRST ?
<jam> in WT4
<vila> Argh, should I go to the repo instead ?
<jam> http://paste.ubuntu.com/391940/ line 10
<jam> so... if you are going to be going to the basis tree, I'd use WT.basis_tree()
<jam> otherwise, *I* would go to the repo
<jam> but certainly file a bug
<vila> ok, I'll fix that then, not worth leaving such a controversial code in place
<jam> prob high priority, except we've had that bug for a long time, and nobody has hit it :)
<vila> I'll do
<vila> well, we have the fix...
<jam> but we need a test, etc
<jam> and it shows test coverage holes
<jam> that we don't have tests against a DSRT that isn't the basis, etc
<jam> (should be a tree_impl test)
<jam> etc
<jam> and all of that probably isn't worth your time
<jam> espec at 8pm
<jam> :)
<vila> 7pm but I'm EODing anyway
<jam> well, I figured by the time you actually wound down...
<jam> as for "needs a test"
<jam> it doesn't really
<jam> it *should* have one, but it is clearly broken
<jam> and I'd rather have it fixed than tested
<jam> vila: Probably worth a tiny amount of time to add a test, but prob also a fair amount of work to get it covered properly.
<vila> jam: I'm pasting that discussion in the code and look at it tomorrow first thing
<jam> k
<vila> the test are passing again so I have a better fix for #531967 anyway
<vila> I'll go with the repo for the final version and address the DRST bug in parallel
<vila> jam: thanks again
<jam> k
<jam> vila: I'm glad you're working on it, shame to uncover so many chained bugs
<vila> jam: but the more bugs I uncovered the more confident I became, that's the good side of the story,
<vila> I'm pretty sure I've run into some others without realizing it in some explorations I did for this fix
<vila> ...or not, TT are not obvious, sometimes they are really painful to use, sometimes they just magically works very simply...
<lifeless> moin
<codygman> would it be recommended to make an svn of my entire website?
<Kohlrabi> no, a bzr :)
<JFo> how would I list any uncommitted changes for perusal?
<JFo> so that I can see them in a terminal
<IslandUsurper> bzr status
<IslandUsurper> bzr diff
<IslandUsurper> JFo, ^^
<JFo> thanks much IslandUsurper
<IslandUsurper> "bzr help commands" is your friend :)
<jpds> JFo: I like bzr commit --show-diff too.
<JFo> thanks jpds
<JFo> I'll check that out
<poolie> hi there
<dvheumen> hi
<poolie> hello dvheumen
<dvheumen> that's a coincidence, I just got here :)
<poolie> how did you go with the tests?
<dvheumen> I finished up a test that  I think it's decent enough
<dvheumen> I've pushed the branch, so you can have a look if you're interested
<dvheumen> https://code.launchpad.net/~danny.vanheumen/bzr/bug-498409-bzr-revert-takes-a-branch-lock
<poolie> sure
<poolie> you can propose a merge if you think it's ok
<dvheumen> I was thinking of waiting until the higher level test is complete too
<dvheumen> and I've got a question about the merge process actually
<poolie> ?
<poolie> sure, what is it?
<dvheumen> I started with this patch on the 2.0 branch, with the idea that it could be merged with earlier branches if needed
<poolie> right
<dvheumen> but just out of curiosity I tried to merge with bzr.dev, and this 1 line fix actually conflicts :P
<dvheumen> so how do you go about if I would propose this branch for merging and it's actually conflicting. Because if I would merge changes between 2.0 and 2.2, then it wouldn't be suitable for merging in 2.0 anymore
<poolie> just propose it to 2.0
<dvheumen> not that I want it too or so, I'm just curious how you would approach this thing :P
<poolie> and whoever eventually merges it to bzr.dev will fix the conflicts
<poolie> they're probably just mechanical not conceptual conflicts
<poolie> if you wanted to do it yourself
<poolie> make a separate branch off bzr.dev, merge your thing, fix the conflicts, then propose that for bzr.dev
<poolie> but it's not really worth it because we regularly merge all of 2.0->2.1->trunk anyhow
<poolie> so it will happen implicitly
<poolie> however
<dvheumen> okay
<poolie> this approach might be good if eg you want to write the tests in a really different way in trunk if for example there was better infrastructure there
<dutchie> is there anything like "git grep" for searching for content in past revisions?
<poolie> https://launchpad.net/bzr-search
<poolie> dutchie: ^^
<lifeless> morning poolie
<dvheumen> hey lifeless
<lifeless> hi dvheumen
<dvheumen> lifeless, can you give me a hint for those higher level locking hooks? so I can have a look at those
<lifeless> dvheumen: well they don't exist; I was saying we could write them
<dvheumen> ah okay, that's fine too. But in that case it'll probably be a different branch, so I'll propose the current one for merge
<lifeless> yup
<lifeless> I need new shorts. Just saying.
<poolie> !
<dvheumen> hehe, luckily no web cam support for IRC :P
<lifeless> thread at the bottom is unwinding, tickling the back of my legs :)
<dvheumen> lifeless, could you give an idea on what you have in mind? Maybe something like the lock helpers used in the per_branch locking tests?
<lifeless> dvheumen: something like the lock.Lock.hooks, but for objects-that-are-lockable rather than locks themselves.
<lifeless> there are a few shades of meaning here too -
<lifeless> write locks
<lifeless> read locks
<lifeless> tree-only write locks
<lifeless> critical section locks (only taken as part of implementing some method)
<dvheumen> yep, I get the idea, that sounds good
<lifeless> Tree objects, Branch object, Repository objects
<lifeless> maybe others.
<dvheumen> looking at those at the moment
<lifeless> back shortly; grabbing subway :)
<dvheumen> okay
<poolie> igc, is there a good guide that answers https://answers.launchpad.net/bzr/+question/103773 about bzr and svn?
<dvheumen> poolie, thanks for your help. The branch is now proposed for merging into 2.0. I'm going to give the higher level lock hooks a try
<poolie> cool, thanks
<poolie> it may help if you add to testing.txt too
<poolie> i saw you took my sample text yesterday
<poolie> explaining it to other test developers may help get the api nice
<poolie> btw i don't know if you saw on the list but we're going to have a sprint fairly near you in may
<poolie> in Brussels
<dvheumen> I did see that mail come by
<dvheumen> do you think it'd be useful for me to have a look there?
<dvheumen> don't get me wrong, it sounds interesting
<dvheumen> but I don't have that much experience with python and such ... on the other hand, ... it's in May, i may have learned a lot by then :P
<dvheumen> is this sprint all week? 'cause I may come and visit one day
<dvheumen> one day ==> a single day
<dvheumen> poolie, do you want me to put the additional information about testing in the same branch? and only some information about what I used, or also the part you proposed yesterday?
<poolie> dvheumen: coming for one day would be fine, and yes, i think you'd find it fun/useful
<poolie> dvheumen: if it's just a bit more documentation the same branch is fine
<slangasek> I'm looking to extend bzr-email to support adding arbitrary extra headers to the outgoing mails, as specified in .bazaar/locations.conf
<dvheumen> okay, I'll do that
<slangasek> (required for integration with the Debian PTS)
<slangasek> is there a convention for multiline values in locations.conf that I should be following?
<slangasek> (since ideally, this should support adding more than one header...)
<james_w> slangasek: python-configobj is used to parse it, so the documentation of that may provide some clues
<slangasek> james_w: looking, thanks
<slangasek> oh, haha, it uses """ to mark multiline values :)
<lifeless> slangasek: as james_w says :)
<lifeless> slangasek: you could encode something differently if you wanted, but I'd go with the config obj standard by default
<slangasek> indeed
<slangasek> I just didn't know what the standard was - now I do :)
<slangasek> though, I see it also supports a list syntax; maybe that would be more idiomatic than making it a multiline variable and split()ing in my code..
<lifeless> well, what are you doing
<slangasek> adding a new 'post_commit_headers' option that can contain one or more headers to be added when sending the mail
<lifeless> please don't call it post_commit
<lifeless> as bzr-email also does emails on push and pull and so on
<lifeless> revision_mail_headers
<lifeless> slangasek: what will be in these headers.
<slangasek> that seems to be inconsistent with all the other options currently used?
<slangasek> lifeless: whatever one specifies in the config
<lifeless> slangasek: yes, but what will be in the settings someone usng it with debian PTS sets
<slangasek> post_commit_to, post_commit_mailer, post_commit_push_pull...
<lifeless> slangasek: its different yes
<slangasek> lifeless: X-PTS-Approved: 1
<lifeless> slangasek: that the old ones are misleading/confusing is not a good reason to make new ones the same.
<jelmer> lifeless: and whose fault is that ? :-P
<lifeless> mine
<lifeless> which is why I get to say the name for the new ones ;)
<slangasek> heh
<poolie> lifeless https://bugs.edge.launchpad.net/malone/+bug/535390 would have saved me embarrassment :/
<ubottu> Launchpad bug 535390 in malone "show duplicate status changes inline on page" [Undecided,New]
<slangasek> lifeless: so when will the other variable names be fixed?
<lifeless> slangasek: possibly never, though we could add aliases to look up better names and fallback.
<lifeless> slangasek: so, X-PTS-Approved:1 - thats all ?
<lifeless> slangasek: would it make sense to have that added by bzr-builddeb ?
<lifeless> poolie: heh, and me some enamel :P
<slangasek> well, IMHO, it's worse to have 3 vars using the old scheme and 1 using the new scheme than to have 4 using the old naming scheme - more misleading, but less confusing to users trying to navigate from scratch
<slangasek> lifeless: bzr-builddeb> hum, how would it add it?
<lifeless> slangasek: the names are only discoverable by docs anyway, so I don't think it makes any odds there. Nevertheless, if you want to write it the same, thats fine.... I can change when I merge it to trunk.
<slangasek> do you think it's not generally useful to let users add headers?
<lifeless> slangasek: I'm fine with the feature; I'm speculating that we can do a better job for this use case than manually setting a variable based on the branch URL.
<lifeless> slangasek: but I can't really think about it as you haven't opened up much about the project/logic
<lifeless> :)
<slangasek> my use case is that, when pushing to a particular branch, I want emails to be sent to the PTS (using the special address that triggers the PTS 'cvs' keyword for the package)
<lifeless> ok
<slangasek> to send mail there, you either have to send the mail from a debian.org machine, or use the s3kr1t X-PTS-Approved header
<lifeless> and should these replace or be done in parallel normal notification mails for the branch ?
<lifeless>                                                             ^to
<slangasek> and I don't see a way to have a mail hook run on the server side when pushing to the repo, so I'm configuring this all client-side
<slangasek> lifeless: what normal notification mails?  the ones generated by bzr-email?
<lifeless> right
<slangasek> it's one and the same
<spiv> Good morning.
<slangasek> [bzr+ssh://bzr.debian.org/bzr/pkg-samba]
<slangasek> email = Steve Langasek <vorlon@debian.org>
<slangasek> post_commit_to = samba_cvs@packages.qa.debian.org
<slangasek> post_commit_mailer = smtplib
<slangasek> post_commit_push_pull=True
<slangasek> post_commit_headers=X-PTS-Approved: 1
<lifeless> slangasek: yes, but is that byb design or ease-of-doing-this
<lifeless> slangasek: do you have skype?
<slangasek> no, sorry
<slangasek> is what part by design?
<slangasek> I have bzr-email installed for precisely this
<lifeless> a regular phone? I'd like a little more bandwidth to clarify this, then I can switch focus
<slangasek> sure, sec
<dorins> Hi all. When I 'bzr pull' from a svn branch I get garbage in a specific revion that gets pulled. 'bzr pull' doesn't report any errors and 'bzr check' doesn't find any problems either.
<igc> morning
<dorins> I'd report a bug but I don't know what info I could attach to the bug report. Is there any documentation on how to report a bug?
<dorins> I can reproduce the issue, but I'm not sure how to get bzr to output debug info while I reproduce it so that I could attach it to the bug report
<igc> poolie: I'm yet to file that RT ticket. I'm happy to do it though I'm not sure exactly what to ask for
<igc> poolie: is installing on escudero enough? Or does it need to go into a chroot as well?
<poolie> on phone
<poolie> probably needs to be in the chroot on escudero
<poolie> because hardy may be too old
<igc> poolie: hardy looks ok fwiw: http://packages.ubuntu.com/hardy/python-feedparser
<wgrant> poolie: That bug isn't about pushing a new branch. It's about pushing a new revision to an existing stacked branch.
<jelmer> 'evening igc, poolie, wgrant
<igc> hi jelmer
<wgrant> Morning jelmer, poolie, igc.
<jelmer> is there any chance either of you could review https://code.edge.launchpad.net/~jelmer/bzr/remote-addinvdelta/+merge/20846 ? I've got one "approve" vote already, but from somebody is not a reviewer
 * slangasek seconds jelmer's request
<slangasek> fix my git-import, plz :)
#bzr 2010-03-10
<dvheumen> lifeless, about the locking behaviour we talked about yesterday. That special case 'LockResult(file:///tmp/testbzr-J2pcy2.tmp/.bzr/branch-lockc4au55ppz8wdym11z1aq)', you can never get this if you install your own hook, right? (i.e. you will only find it if you use _lock_actions directly)
<lifeless> dvheumen: you can get it, but only if you install your hook before creating a bzrdir
<dvheumen> aha okay, so that's the idea. Okay in that case I'll add that case to the documentation too.
<dvheumen> bzrdir is the '.bzr' directory right?
<dvheumen> so in essence a newly created checkout/branch/repository
<poolie> jelmer: so feed-pqm worked for you, it seems?
<spiv> dvheumen: bzrdir is the .bzr directory, yes
<jelmer> poolie: no, unfortunately the email it generated in the end was rejected because of the gpg signature
<poolie> huh
<poolie> the signature was invalid?
<lifeless> dvheumen: yes
<lifeless> is feedpqm in the bzr-pqm plugin
<lifeless> ?
<jelmer> poolie: I'm not sure - it's very cryptic in its error messages: "PQMException: 'Failed to verify signature: gpgv exited with error code 1'
<jelmer> "
<jelmer> lifeless: it's in hydrazine
<poolie> jelmer: :/
<poolie> what if you pipe it through gpgv yourself?
<poolie> could it be that you have multiple secret keys and it's using the wrong one?
<jelmer> No, I'm sure this is the right key
<jelmer> it seems like it might be related to the from address - does pqm rely on that ?
<poolie> i don't know
<jelmer> (feed-pqm uses the email address to do a proper CC but it doesn't override the actual from address)
<lifeless> jelmer: the key's primary UID *I think*
<poolie> that could well be the problem though
<lifeless> jelmer: check the code.
<lifeless> lp:pqm
<poolie> so you could try forwarding the message from the right from address and see what happens
<poolie> lifeless: feed-pqm is i presume what you were just asking me about
<jelmer> lifeless: Thanks, but I've wasted too much hours of my life in pqm source code already :-)
<lifeless> poolie: nope
<lifeless> poolie: the queue API stuff you found
<poolie> it uses the queue api
<lifeless> good
<jelmer> poolie: Things seem to work quite a bit better if I use bzrlib's email API
<jelmer> poolie: Are you opposed to having hydrazine depend on bzrlib for sending email ?
<poolie> nup
<poolie> it's probably much better to do that
<jelmer> awesome; one mp coming up :-)
<poolie> i'd like to teach it to ignore mps from people who can merge their own
<poolie> thanks
<lifeless> poolie: I think its great to have it  submit other ppls mps ;)
<jelmer> poolie: yeah, I agree that'd be nice (except for the current user, of course)
<poolie> or we could do that
<poolie> but it gets more into 'almost ready' vs 'actually read'
<poolie> ready*
<mwhudson> jelmer: are you using hydrazine to triage bugs?
<mwhudson> because all you comments are coming wrapped in "s
<jelmer> mwhudson: yes
<jelmer> mwhudson: oops, I was assuming I had to quote arguments to the comment command :-)
<jelmer> mwhudson: thanks, I'll avoid that from now on
 * jelmer thinks he also added a comment '--help' somewhere
<poolie> heh
<poolie> is that working again?
<poolie> for a while most bug operations were broken because of an etag bug
<poolie> but it was marked critical so maybe it's fixed
<poolie> i guess adding a comment would still work
<jelmer> I did get "precondition" exceptions on some changes
<jelmer> other than that it worked quite well
<james_w> I think the CP may have gone through today
<james_w> but I'm not sure if that was production/edge
<poolie> heh, i see your "--help i'm trapped in a bug" message :)
<poolie> also for some reason it no longer exits cleanly on ^D
<poolie> um
<poolie> i'd like to have a way to go into $editor to add a comment
<poolie> probably most easily done by calling bzrlib
<poolie> igc is https://bugs.edge.launchpad.net/bzr/+bug/524162 still open in bzr itself?
<ubottu> Launchpad bug 524162 in bzr "bzr-explorer don't work if installing by bzr-2.1.0 standalone installer." [Critical,Confirmed]
<igc> poolie: yes. It's waiting on https://code.edge.launchpad.net/~ian-clatworthy/bzr/plugin-packaging-524162/+merge/20858 being reviewed and landed
<poolie> k thanks
 * igc lunch
<parthm> poolie: does the bzr-grep textfile.text_file approach for checking binary seem reasonable to you? https://bugs.launchpad.net/bzr-grep/+bug/531336/comments/4
<ubottu> Launchpad bug 531336 in bzr-grep "bzr grep does not handle binary files cleanly" [High,Fix released]
<poolie> parthm: isn't there something in osutils or similar to already do this?
<poolie> oh obviously that's what you're doing
<parthm> poolie: yes. i am just using a bzrlib implementation.
<poolie> yes that looks good then
<parthm> poolie: ok. thanks.
<poolie> hi igc, lunched?
<poolie> igc are you already doing something similar to bug 534320
<ubottu> Launchpad bug 534320 in bzr "Disable plugins for given command" [Undecided,New] https://launchpad.net/bugs/534320
<echo-area> hello, is there any explaination of stacked branches besides the documentation?
<echo-area> the secion "using stacked branches" in the bzr manual doesn't explain it well, and many examples in it don't work
<spiv> echo-area: those docs are the best I know of, but I'm happy to answer questions here
<spiv> echo-area: the primary use case is pushing to a server where a trunk already exists (so most of your branch's revisions are already on the server), but you don't have write access to that repository
<spiv> echo-area: so you can push (using the --stacked and --stacked-on options, or specially configure the remote .bzr directory) just the revisions unique to your branch to the server.
<spiv> echo-area: launchpad for instance creates those specially configured .bzr directories automatically, so if I push a new branch to ~spiv/bzr/..., it will automatically be stacked on the bzr trunk.
<echo-area> spiv: but I can't commit to a stacked branch
<spiv> echo-area: yes, unfortunately :(
<spiv> That's bug 375013
<ubottu> Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013
<spiv> We'd like to fix that, but it will be a surprisingly large amount of work :/
<spiv> Oh, does the "Using stacked branches" doc suggest that you can commit to a stacked branch?  Eek :(
<spiv> That is confusing, I'm sorry.
<echo-area> spiv: that's the main source of my confusion.  I've created a stacked branch, by following the documentation, via the command "bzr branch --stacked source branch"
<echo-area> spiv: but after making some changes, I can't commit them, nor can I push them.
<spiv> echo-area: Right, because of that bug.
<spiv> So, if you want to commit, you can't use a stacked branch yet, sorry :(
<spiv> I'll submit a clarification to the docs now
<spiv> In the meantime you'll probably be better off using a shared repository and unstacked branches.
<echo-area> spiv: umm, stack branches aren't usable before we can commit to it, are they?
 * fullermd suspects stacking should be rather more hidden...
<spiv> echo-area: There are uses for branches that don't involve committing to them
<lifeless> and pushing is different to committing
<spiv> echo-area: e.g. the scenario I described earlier (pushing to a server that has a suitable repository for stacking-on, but that you do not have permissions to write to)
<lifeless> which is in fact why you can't commit to stacked branches.
<SamB_XP> I just don't worry too much about stacked branches unless they make things go too slowly when I try and push something to launchpad ...
<parthm> hello. i am planning to suggest the lp:parrot owner to upgrade the repo format to 2a. whats the suggested way to upgrade an lp branch. l believe lp:parrot is an svn imported branch.
<parthm> https://launchpad.net/parrot
<spiv> I think the owner of the branch can click an "upgrade format" button in the web UI now.
<parthm> spiv: thanks. i will suggest that.
<echo-area> spiv: I have not reproduced that scenario successfully yet.  I did this:
<echo-area> bzr init-repo --no-trees test-repo
<echo-area> bzr init test-repo/trunk
<echo-area> bzr init-repo test-branch
<echo-area> bzr branch test-repo/trunk test-branch/trunk
<echo-area> cd test-branch/trunk   <-- and work here, commit
<echo-area> then I did (in test-branch/trunk)   bzr push --stacked ../../test-repo
<echo-area> I got messages like these:
<echo-area> Ignoring request for a stacked branch as repository already exists at the destination location.
<echo-area> All changes applied successfully.
<echo-area> Pushed up to revision 4.
<parthm> hmm. i did suggest lp:parrot to upgrade the branch http://groups.google.com/group/parrot-dev/browse_thread/thread/1cc2f0bbb18b76fc
<echo-area> but as I made another branch of test-repo/trunk, I didn't see the new revisions unique to test-branch/trunk
<parthm> but i see the branch owner listed as 'VCS Imports' https://code.launchpad.net/~vcs-imports/parrot/trunk so is the upgrade to be done by the project owner or branch owner?
<parthm> lp:parrot project owner is ~parrot-dev while branch owner is ~vcs-imports.
<spiv> echo-area: that's not the scenario I was referring to
<spiv> echo-area: because in that scenario you can (and did) push directly into the original repo (test-repo)
<spiv> echo-area: I'm referring to a case like a server shared by several developers, but only one (or perhaps a non-human system account, like a gatekeeper bot) has access to the integration branch everyone branches off
<echo-area> spiv: should I make test-repo a stacked branch, and so that pushing onto it is the same as pushing to the stacked-on branch of test-repo?
<spiv> echo-area: e.g. if the trunk is on /srv/project/trunk on a host, and /srv/project is a repo made with init-repo, but you don't have access to write to /srv/project
<spiv> echo-area: but you can read from it, so you can do e.g. "bzr branch sftp://host/srv/project/trunk local-branch", work on that, and then push it up with "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/home/myuser/my-branch"
<spiv> echo-area: in that case making local-branch will still copy the full history, but you don't have to push the full history back to the server, you use stacking to point to the history the server already has
<spiv> (and also you don't waste space on the server by keeping a second copy of the history)
<spiv> echo-area: does that make sense?
<echo-area> spiv: I'm reading and understanding.  It definitely makes sense.  Thanks
<spiv> Cool.  Glad I could help :)
<spiv> It's an optimisation that most people don't need, I think.
<lifeless> thumper: will lp crash if we set merge proposal queue fields using APIs ?
<lifeless> 'try it' is a good answer.
<vila> hi all !
<echo-area> spiv: please take a look at this, does it elaborate the scenario you mentioned:
<echo-area> bzr init-repo test-repo
<echo-area> bzr init test-repo/trunk
<echo-area> bzr init-repo stacked-repo
<echo-area> bzr branch --stacked test-repo/trunk stacked-repo/trunk
<echo-area> bzr init-repo local
<echo-area> bzr branch test-repo/trunk local/trunk
<echo-area> cd local/trunk   <--- work here
<spiv> echo-area: it doesn't make much sense to create a stacked branch in a shared repo (i.e. a directory you've made with init-repo)
<echo-area> (in local/trunk)  bzr push ../../stacked-repo/trunk
<echo-area> spiv: so a stacked branch is better put in its own directory?
<spiv> (I guess I can imagine uses for it, but it's certainly not how I would choose to explain it)
<spiv> echo-area: I'd ignore init-repo entirely, really
<spiv> echo-area: (for explaining how stacking works, not in general)
<spiv> I'm not sure what you're asking, exactly.
<spiv> I guess you're trying to test your understanding of stacking by constructing a scenario that uses it?
<echo-area> spiv: in your last example, "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/home/myuser/my-branch", are the following statements true or not?  1) sftp://host/home/myuser/my-branch contains the full history too; 2) only the local revisions that have not been synced will be transfered during that push, the previous history will come from my-branch on host; and 3) full history will be tran
<echo-area> sfered in a normal push.
<echo-area> spiv: kind of.  I want to figure out the things not explained explicitly in your example, hoping to help myself fully understand stacked branches
<spiv> 1) no, it only contains the history not in the stacked-on location (plus some small overhead), b) yes, only the history not already in sftp://host/home/myuser/my-branch and not already in its stacked-on location is pushed, 3) it depends; full history is transferred in a normal push when there is no shared repository (or that shared repository is empty or otherwise contains none of the relevant history)
<echo-area> spiv: so sftp://host/home/myuser/my-branch is a stacked branch too?
<spiv> To clarify for 3, I mean a normal *initial* push.  Obviously subsequent pushes to the same branch don't have to re-transfer data that was already transferred.
<spiv> echo-area: what do you mean "too"?  I think that's the only stacked branch in my example.
<spiv> echo-area: oh, I see I made a silly typo in my example
<spiv> echo-area: that command ought to have been "bzr push sftp://host/home/myuser/my-branch --stacked --stacked-on=sftp://host/srv/project/trunk"
<spiv> echo-area: I guess that was rather confusing!
<echo-area> spiv: should be  bzr push --stacked --stacked-on=sftp://host/srv/project/trunk sftp://host/myuser/myproject, right?
<spiv> echo-area: right
<echo-area> spiv: whoa, I think I understand that now.  Thank you!
<echo-area> spiv: I think your example is the one that clarifies much about stacked branches.  Maybe you can add it to the documentation.  What do you think?
<spiv> echo-area: or you could :)
<spiv> Patches are always welcome :)
<spiv> More seriously, I'm finishing up for the day, and will likely to have forgotten by tomorrow, so please file a bug asking for that, feel free to paste my IRC comments into it.
<echo-area> spiv: okay, let me try to write one.  I'll do what you said.  Thank you very much.
<spiv> echo-area: Btw, <https://code.launchpad.net/~spiv/bzr/stacked-commit-doc-update/+merge/21024> is the patch I wrote to that doc earlier.
<echo-area> spiv: ok
<spiv> echo-area: thank you, feedback on docs are very welcome, and offers to write them even more so!
<thumper> lifeless: I don't advise it
 * igc dinner
<lifeless> thumper: is staging sufficient to tell if its a problem?
<thumper> lifeless: probably, but what are you trying to accomplish?
<lifeless> thumper: streamline landing stuff
<thumper> lifeless: I can't guarantee it won't be a problem
<thumper> lifeless: but staging should be good enough
 * lifeless makes a memo
<thumper> lifeless: if I lock a working tree for writing, does that take a lock on the branch as well?
<lifeless> thumper: yes
<lifeless> thumper: lock_tree_write will lock the tree only (and take a read lock on the branch)
<thumper> lifeless: I'm trying to write a test that uses a working tree
<thumper> lifeless: and I want some files in that working tree
<thumper> is build_tree_contents the right thing to use?
<thumper> it doesn't seem to take enough params
<thumper> using TestCaseWithTransport
<lifeless> self.build_tree_contents([(path1, content1), (path2, content2)])
<lifeless> there are a few similar thigns
<lifeless> if you want versioned files, you need to also add them
<thumper> lifeless: does that only work if you use make_branch_and_tree with '.'?
<thumper> lifeless: also, where are the internal methods for working out if a fileid is a directory? or binary?
<lifeless> thumper: just adjust the paths
<thumper> ok
<lifeless> tree.inventory[fileid].kind - internalish
<lifeless> tree.kind() or something like that - public
<thumper> ta
<vila> thumper: alternatively, you can provide a transport to build_tree_contents, damn, no, you can't, that works for build_tree only, shame
<vila> but if you're ok with arbitrary content and have a tree from make_branch_and_tree, you can then use transport=tree.bzrdir.root_transport and you don't need to prefix your paths anymore
<thumper> I'm having trouble finding the options for return values for tree.kind()
<lifeless> vila: if you want arbitrary, MutableTree.set_file_content is better
<vila> thumper: 'file', 'directory', 'symlink', 'absent'
<lifeless> thumper: osutils._kind IIRC
<thumper> it'd be really helpful if that was part of the docs for the method :)
<thumper> someone told me that bzrlib uses looks for a null withing 'x' amount of the content to determine if a file is binary
<lifeless> thumper: patches loved
<thumper> is that method public(ish)?
<lifeless> yes
<lifeless> tis in osutils
 * thumper looks again
<vila> lifeless: set_[file_]content ENOTFOUND
<lifeless> vila: meh; look at MemoryTree using tests.
<vila> thumper: bzrlib/textfile.py ?
<lifeless> ah yes
<lifeless> thumper:  ^
<thumper> ta
<thumper> reading now
<lifeless> vila: sanity check: bzrlib.textfile.check_text_path is bust
<lifeless> vila: or perhaps just unclear
<vila> lifeless: as in not mentioning that it checks the *content* of the path ?
<lifeless> well
<lifeless> looking at it, it looks like it calls a generator and discards it
<lifeless> which isn't generally useful
<spiv> It calls an iterator and discards it, but happily the constructor of the iterator contains the relevant check.
<lifeless> it would be clearer, I think as
<lifeless> 'if '\x00' in f.read(1024): raise BinaryFile()'
<spiv> So, a little unclear, but given the overall simplicity of the module not a big deal either.
<thumper> what is the right way to call check_text_path with a path and a working tree?
<lifeless> spiv: I hope you and Mary will be available on the 27th
<thumper> the method assumes the path is relative to the current working dir
<lifeless> thumper: tree.get_file() -> check_text_file
<thumper> lifeless: in my test, I want to have fines in the tree
<thumper> lifeless: how do I add the files ?
<thumper> tree.add() ?
<thumper> smart_add perhaps
<lifeless> tree.add([path, path], [id ,id])
<lifeless> usually
<lifeless> or smart_add(['pathtotree']) if you just want versioned
<lifeless> but at this point I'd smell aa case where branchbuilder might be ready
<thumper> branchbuilder?
<lifeless> yah
<lifeless> self.make_branch_builder('relpath')
<lifeless> grep for make_branch_builder in bzrlib.tests; its not well described yet
<thumper> ok
<thumper> prolly not tonight
<thumper> 'tis getting late
<mwhudson> remember to add the root as the first thing you do with the branch builder
<mwhudson> or you will get very confused
 * thumper puts laptop down
<spiv> lifeless: we are, yeah
<lifeless> google invites ftw
<lifeless> spiv: ^
<parthm> vila: ping
<vila> parthm: pong
<parthm> vila: hi. i have closed most of the review comment on https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691
<parthm> vila: regarding, the testing, i updated the tests  as we discussed the other day ( http://pastebin.com/CKhiAgL4 ) but it seems a regular user doesn't have permissions to chown ( http://pastebin.com/ZPk2XGvv )
 * bialix waves hi all
<parthm> vila: i am out of ideas on the testing front.
 * vila waves back at bialix
<vila> parthm: weird
<vila> argh, my X server is... acting weird too
<vila> ha, no, it was only FF
<parthm> vila: how do you suggest we take this forward? the earlier _dummy_chown approach seems reasonable to me as os.chown is the lowest layer.
<vila> parthm: if chown can't be used, then it's sure sign that *not* using it in tests... shows why it should be used in tests :)
<parthm> vila: :-)
<vila> ... that's the first time I see chown failing in a directory where I have write access... did posix changed overnight ???
<parthm> vila: i am not sure :-) ... generally i tend to use chown with sodo so i never really tried this before.
<parthm> s/sodo/sudo
<parthm> vila: i have also updated https://code.launchpad.net/~parthm/bzr/262450/+merge/19483 as per the review comments. so do i need to resubmit that?
<vila> parthm: as a rule, if you modify a branch, you just push again and then check that the status is 'Needs review'
<parthm> vila: thanks. i will do that.
<vila> parthm: then you nag the patch pilot if nothing occur :)
<parthm> vila: sounds like fun :-) so  i will nag poolie this week.
<parthm> vila: so for https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691 should i just put it up for review for now? we can discuss it further over review.
<parthm> its 'work in progress' now.
<vila> parthm: as you feel, we at least to understand why os.chown doesn't work or your fix won't either anyway
<parthm> vila: yes. we do have a better understand of the tests now. will do that. thanks.
<parthm> regarding https://code.launchpad.net/~parthm/bzr/262450/+merge/19483 i have updated the code based on your comments. feel free to relook at it anytime :-)
<parthm> vila: hmm. you raise a good point. normally chown won't work so a user foo can't chown to bar. however in this case we are going to chown to based on the containing folder which would be users home (and owned by the user).
<parthm> so that should work i think. unfortunately we don't seem to have a thorough way of testing it.
<vila> parthm: it would be quite risky to introduce untested code especially code for .bzr.log and .bazaar access...
<parthm> vila: i agree. i does seem somewhat brittle. i will set the status to 'Needs Review' in case there are any more ideas. i would be happy to work some more if something comes up or we can reject it.
<vila> parthm: sounds fine, don't forget to mention the chown problems you encountered in a comment
<vila> a comment on the merge proposal I mean
<parthm> vila: will do that.
<parthm> vila: thanks for taking the time to review this.
<jml> does bzr have a shorthand for doing 'bzr merge -r N..(N-1) .'
<jml> in svn, I think you can do 'svn merge -c -N .'
<jml> where N is a revno
<parthm> jml: if you want to merge a specific revision then '-r N' should work IIRC.
<jml> parthm, unmerge
<jml> parthm, I want to revert a particular revision
<parthm> jml: ah. :-) maybe 'bzr revert -r N'? I haven't tried it though.
<spiv> jml: I suppose -r N..before:N
<spiv> jml: which is shorthand if N is sufficiently long :)
<spiv> jml: I think a --reverse/-R switch would probably be a reasonable addition to 'bzr merge', although I haven't thought about it carefully.
<spiv> We already use -c as shorthand for -r (N-1)..N
<spiv> jml: I'm off to bed... if you like the -R idea please file a bug asking for it :)
<jml> spiv, ok
<spiv> (And if you think it should be --backwards or --unmerge or something instead, do bikeshed in the bug report as appropriate)
<awilkins> Best place to report packaging bugs still the bugs for bzr?
<jelmer> awilkins: hmm?
<jelmer> which packaging specifically?
<awilkins> Windows
<awilkins> The current 2.1.0-2 package contains bug 526740
<ubottu> Launchpad bug 526740 in bzr-xmloutput "XML-RPC service broken by bzr-2.1" [High,Fix committed] https://launchpad.net/bugs/526740
<awilkins> I guess bzr-windows-installers
<parthm> hello. i am trying to create a series 0.0.1-final for lp:bzr-grep. i have already created series 0.0.1-final via web ui.
<parthm> when i try to push my trunk (with tag 0.0.1-final) to lp:bzr-grep/0.0.1-final I get the error bzr: ERROR: Invalid url supplied to transport: "lp:bzr-grep/0.0.1-final": 0.0.1-final has no default branch.
<parthm> what am i missing?
<bialix> partm: you need to create a bracnh first, then assign it via series interface
<bialix> there is no magic lp:bzr-grep/0.0.1-final branch created when you created a series
<bialix> so just push to lp:~user/bzr-grep/0.0.1-final first
<bialix> then assign this branch as *the* branch for the series
<bialix> not vice versa
<bialix> parthm: ^
<parthm> bialix: I knew I was missing something silly :P thanks. that worked out fine.
<bialix> silly milly
<rioch> I have a file listed as modified in bzr status, but the filename has a * after it, which I don't normally see. What does that mean?
<Peng> rioch: Exec bit changed.
<Peng> I think.
<rioch> ahhhh yeah that's true I did a chmod as well :)
<Peng> I'm pretty sure the * is explained somewhere
<slangasek> lifeless: doing the needful on the extra_headers patch; stuck now because I can't figure out how to *run* the test suite to verify that the test works :)
<swathanthran> i have a local bzr checkout of emacs. where should i look to know which url it is pointing too?
<swathanthran> i had a try through the .bzr directory but found nothing useful..
<jelmer> swathanthran: try 'bzr info'
<jelmer> slangasek: "bzr selftest bzrlib.plugins.email"
<slangasek> jelmer: thanks :)
<swathanthran> jelmer: http://bzr.savannah.gnu.org/r/emacs/trunk/ is this trunk "proper" at the moment?
<slangasek> oh neat, my patch makes *other* tests fail :)
<slangasek> tests are great!
<swathanthran> jelmer: assuming it can be said by looking at there or something..
<swathanthran> bzr: ERROR: No WorkingTree exists for "http://bzr.savannah.gnu.org/r/emacs/.bzr/checkout/". and bzr: ERROR: No WorkingTree exists for "http://bzr.savannah.gnu.org/r/emacs/trunk/.bzr/checkout/". as i tried bzr update http://bzr.savannah.gnu.org/r/emacs/ and bzr update http://bzr.savannah.gnu.org/r/emacs/trunk
<swathanthran> bzr update says Tree is up to date at revision 99318.
<swathanthran> bzr pull does it:)
<jelmer> swathanthran: specifying a URL to 'bzr update' will try to update that remote URL :-)
<swathanthran> uh:) i thought it the opposite way:)
<vila> slangasek: 'bzr selftest -s bzrlib.plugins.email' should be faster
<vila> slangasek: you can also do 'bzr selftest -s bp.email -s bt.<the other failing tests>'
<vila> slangasek: 'bp' and 'bt' are known shortcuts
<slangasek> vila: ok, cheers :)
<Peng> (FYI, 'bzr selftest foo' loads the entire list of tests and then filters it. 'bzr selftest -s foo' only loads those tests starting with the module 'foo'.)
<vila> slangasek: I'm not sure what you're working on, but be aware that part of the plugin has been moved to bzr-core but the plugin still has that code (mostly the smtp connection stuff from memory)
<vila> slangasek: But if you're modifying something else, no worries
<jelmer> 'evening vila
<slangasek> vila: hum, I'm adding a new feature to the plugin, and basing my work on lp:~bzr/bzr-email/trunk/; where would I see that things have moved?
<vila> jelmer: hey  :)
<vila> slangasek: nothing has moved from the plugin yet, that's the point :-/ Some code has been taken from there, put in core, and enhanced there
<slangasek> ok... :)
<vila> slangasek: let me check
<slangasek> vila: lp:~vorlon/bzr-email/extra-headers/, if you want to comment on the appropriateness
<slangasek> but lifeless mentioned nothing to me yesterday about this code moving :)
<vila> slangasek: ok, so you should be fine :)
<vila> slangasek: hmm, smtp_connection.py seems to have diverged, I can't be more precise at first glance
<slangasek> ok
 * vila looks at lp:~vorlon/bzr-email/extra-headers
<vila> slangasek: hmm, well, it's late, but it looks like your additions will be welcome in bzrlib/email_message.py ...
<vila> slangasek: bah, one more thing to backport from the plugin ...
<slangasek> vila: mumble; well, I'm at least going to wait until lifeless is satisfied with the merge on bzr-email first
<slangasek> vila: fwiw, this patching is all tied to moving the Debian Samba team off of svn, greatly simplifying the workflow we discussed at UDS :)
<vila> slangasek: sure, that's what I meant. I didn't imply you had to do the backport
<vila> slangasek: great news, thanks
<kjcole> Is there a way to get bzr to eliminate unnecessary .bzr/ files?  (Say, for example, in the case of using rsync or scp independently of bzr with different versions of bzr, or upgrades that didn't quite go as planned.)
 * kfogel is away: bbiab
<lifeless> slangasek: bzr selftest email
<lifeless> slangasek: or, to be a bit faster, the less discoverable 'bzr selftest -s bp.email'
<slangasek> lifeless: done - merge request resubmitted.  Good morning :)
<lifeless> slangasek: good morning :)
<xeviox> can somebody help me understanding the bzr 2a format?
<xeviox> I've seen that there is a folder called "branch" that holds basic information like the last revision
<xeviox> I've also seen that there is a "repository" folder that seems to hold the data
<xeviox> as far as I can understand the contents are stored in the "packs" subfolder of "repository"
<Peng> xeviox: Some data is stored in the indices as well.
<xeviox> ok
<Peng> FWIW, the basic meta dir format (.bzr/branch, .bzr/repository, .bzr/checkout) has been around for ages.
<xeviox> how is the information stored in indices and packs?
<Peng> Cleverly.
<Peng> .bzr/repository/{packs,indices} have existed since pack-0.92, though the actual format has changed several times.
<xeviox> it seems to be compressed, but I don't see using what ..
<Peng> zlib.
<xeviox> are you a developer of the project?
<Peng> Not really.
<xeviox> k
<xeviox> anyways thanks for the background info :D
<Peng> It's not super-simple, and even if I wasn't half-asleep, I don't know all of the answers.
<xeviox> so there is some metadata in front of the data, any idea what it is?
<Peng> There is documentation, at the very least in the code, developer docs and mailing list.
<Peng> Look up btrees, packs and groupcompress.
<xeviox> "records" look like "gcblz\n324\n442\nData...
<xeviox> Peng: ok I'll check
<xeviox> the problem is that the project is very complex
<xeviox> and my skills in python are very basic :(
<xeviox> I just try to build up a readonly script in php
<xeviox> as there a few people that want to share there codes but couldn't use bzr on their webpages ..
<Peng> Trying to re-implement bzr is not a fun task.
<xeviox> Peng: sure :), but I hope that a read-only script is not that hard ..
<Peng> It is that hard. :P
<xeviox> :(
<Peng> What exactly are you trying to build?
<xeviox> I just want to build a script that is able to "read" a bazaar respository
<xeviox> a little web interface for bazaar
<xeviox> as there is nothing that is usable with php only
<xeviox> maybe I'm able to release a working solution for one format and encourage others to help to support more ..
<lifeless> xeviox: there is a xml interface to bzr; you are probably better off using that than reimplementing the core in php
<poolie> hello all
<xeviox> lifeless: the problem is that people can't use it at their webserver without installing bzr ..
<lifeless> 'seems reasonable to have bzr installed to use bzr' :P
<poolie> yeah
<poolie> is it hard to install?
<poolie> i guess python can be hard
<fullermd> That's SO 20th century...
<ronny> poolie: every sane linux distribution ships recent bzr packages, so its absolutely easy to install
<mneptok> and not only every sane distro, but even Gentoo.
<ronny> mneptok: i'd argue that gentoo is sane
<mneptok> ronny: ah, so you work for an electricity company. ;)
<ronny> mneptok: no, but i support carbon-free global warming
<mneptok> ronny: hmmm ... does Gentoo have a SPARC port?
<ronny> no idea
<mneptok> that would get the job done.
<ronny> haha
<ronny> i prefer crowdsourcing (read everyone please install gentoo - i want the snow outside gone tommorow)
<mneptok> $ emerge spring
<ronny> \o/
<poolie> oh hi ronny
<poolie> amazingly enough some people still use other OSs
<jelmer> whoa, using the indexes to store the cache for bzr-git is *significantly* faster
<dvheumen> is anyone familiar with the class _RelockDebugMixin and for what it is used?
<dvheumen> i mean, i can read the comments, but is it actually *super* important, or just for the occasional debugging?
<dvheumen> (_RelockDebugMixin can be found in lock.py)
<lifeless> jelmer: which indices?
<jelmer> lifeless: the bzr Btree indexes
<lifeless> jelmer: custom use of ?
<jelmer> for a certain definition of custom
<jelmer> I'm just using their public API but storing different keys of course
<lifeless> jelmer: right
<jelmer> in .bzr/repository/git
<lifeless> a la bzr-search
<lifeless> yes, our btree's are pretty good
<jelmer> yeah, but without actual content in packs
<lifeless> content schmontent
<poolie> dvheumen: it certainly sounds like it's for debugging
<poolie> why?
<poolie> well, you can see it is in fact mixed in to man yclasses
<poolie> so we shouldn't break it
<poolie> and -Drelock is useful
<jelmer> lifeless: So, lsprof shows the amount of time spent deal with the cache is now ~1%, down from >20%
<lifeless> jelmer: awesome
<lifeless> brb
<jelmer> Although adding repack triggering will increase it a bit once I add that
<dvheumen> I'm exploring the classes around branches, trees and repository objects. I've got this idea to create a super class of which all derive, where this super class contains those high-level lock hooks, but in the case of the Repository class this class is in the way :P
<lifeless> dvheumen: I don't think thats a particularly good idea.
<dvheumen> and it seems feasible to put this functionality in the same super class as the lock hooks
#bzr 2010-03-11
<lifeless> dvheumen: subclassing is a very big hammer
 * lifeless really has to duck out; I'll be back
<dvheumen> lifeless, but otherwise I'm probably implementing almost the same code three times
<dvheumen> (i think)
<dvheumen> also, is it "a very big hammer" in python, or in object oriented languages in general?
<bob2> general
<jelmer> dvheumen: I think Rob also means that changing that now will be a fairly big change with a lot of consequences
<dvheumen> even though most classes derive from 'object'?
<dvheumen> sorry guys, but I'm trying to form a picture here of what the complications are
<bob2> they derive from object for hysterical raisins
<bob2> it's for backwards compatibility in python 2.x - deriving from object gives you a 'new style' class, which adds some features, but is subtly incompatible with old-style ones
<dvheumen> okay, I'll read up on that
<bob2> well, you don't have to, you can just always inherit from object if not inheriting from anything else (for bzr, at least:)
<dvheumen> bob2, true, but I like some background info, helps with the thinking :P
<bob2> google descrintro for the whole shabang
<dvheumen> k, tnx
<dvheumen> aha ... I see some other complications with my idea ... okay, back to the drawing board :P
<poolie> actually i do think having a common Component class is a good idea
<poolie> but we should be very careful what goes in it
<poolie> at least saying "there is a common interface" is a good idea
<dvheumen> hey, don't steal my idea now ;)
<dvheumen> any candidates that you want to put in there?
<spiv> .bzrdir is probably the most obvious common attribute.
<dvheumen> ah right :P
<lifeless> back
<lifeless> caffeined up
<spiv> Possibly the logic for opening them (so reading .bzr/$component/format files and finding the right implementation from a registry) and initializing them.  But even then some of that is just common to bzr native components, not foreign ones (e.g. SvnRepository)...
<lifeless> dvheumen: the code in question is something like lock. 'invoke_lock_callback(self)' though
<dvheumen> lifeless, yeah, I know
<dvheumen> it's much easier than I was previously thinking
<lifeless> note that many external formats *don't have* components
<lifeless> in fact our older formats aren't split into neat little orthogonal elements
<lifeless> so while  I like the idea of a Component for things that are Components, Branch per se isn't a Component, IMO
<lifeless> BzrBranch4+ could be
<dvheumen> lifeless, I'm gonna try something in the coming days and then I'll get back to you
<lifeless> cool
<dvheumen> bye
<poolie> oops
<jelmer> igc: hi!
<igc> hi jelmer!
<lifeless> poolie: oops?
<jelmer> igc: lp:bzr-website is pack-0.92 at the moment, is there any reason it's not upgraded yet?
 * maxb has just finished using bzr-rewrite to rebase a branch based on a bzr-hg import of a hgsubversion import of a svn branch onto a bzr-svn import of the svn branch. How's that for a brainteaser :-)
<igc> jelmer: nope. Feel free to upgrade it :-)
<jelmer> maxb: :-))
<jelmer> igc: Ok, thanks!
<wgrant> I can't 'bzr pump' with bzr 2.1.0 and pipeline 2.1 r157 (the latest on the 2.1 branch).
<wgrant> bzr: ERROR: exceptions.AttributeError: 'RevisionTree' object has no attribute 'branch'
<lifeless> wgrant: -Derror please
<wgrant> lifeless: http://paste.ubuntu.com/392911/
<lifeless> ugh, soo many spans
 * lifeless tries without wget
<lifeless> wgrant: ok, its a bug in the new merge hook facility
<lifeless> wgrant: and you have a merge hook enabled for your branch - possibly builddeb
<wgrant> lifeless: You can also add '/plain'
<wgrant> lifeless: Ahh.
<lifeless> please file a bug, its something we'll need to do a 2.1.1 for
<wgrant> lifeless: Summary?
<jelmer> igc: done
<igc> jelmer: thank-you!
<lifeless> ConfigurableFileMerger does not support merging with this_tree a revision tree
<lifeless> or something
<lifeless> include the backtrace of course
<wgrant> right.
<wgrant> lifeless: Bug #537041
<ubottu> Launchpad bug 537041 in bzr "ConfigurableFileMerger does not support merging with this_tree a revision tree" [Undecided,New] https://launchpad.net/bugs/537041
<lifeless> also please include the output of bzr hooks for the merge_file_content point
<wgrant> lifeless: Just NEWS, but it's on the bug now.
<lifeless> thanks
<lifeless> if you wanted to patch it
<wgrant> I would, if it's simple.
<lifeless> minimall would be to guard the attribute access, and if it fails, try for a global config instead
<lifeless> better still would be a test showing that that works.
<thumper> poolie: ping
<thumper> lifeless: hi
<lifeless> hi
<thumper> I bumped into a friend I hadn't seen for ages
<thumper> he manages a programming team now
<lifeless> cool
<thumper> I asked about what they use for version control
<thumper> he said CVS and Subversion
<thumper> but they are looking at DVCSs
<thumper> I asked if he'd like me to come in and give a talk
<thumper> he was very enthusiastic
<thumper> so I have something next Tuesday at 10:30 am
<thumper> would love some help with a talk outline
<thumper> I'm sure there'll be questions about git as they are looking around now
<lifeless> sure
<thumper> so I'd like some bullets
<lifeless> uhm
<thumper> :)
<lifeless> what language do they use
<lifeless> what ide if any
<thumper> bzr-explorer will be a good one
<thumper> perl
<lifeless> what platform
<spiv> thumper: bullets?  Don't shoot potential users! :)
<thumper> all he asked was "does it work on mac os"?
<lifeless> ok, cool
<thumper> lifeless: heard of AD instruments?
<lifeless> yeah
<thumper> data capture
<thumper> analytics
<lifeless> I suspect I know your friend :)
<thumper> john
<lifeless> mmm, no. But I definitely know *someone* there. I think.
<lifeless> anyhow, thats not important
<lifeless> key points are going to be -
<lifeless> we build and test macos X
<lifeless> explorer
<lifeless> python for extensability
 * thumper nods
<lifeless> single site?
<thumper> at this stage as far as I'm aware
<thumper> they want good merging :)
<lifeless> so, you can talk about ease of migration
<lifeless> stay with the same workflow, ease into distribution
<lifeless> merging is great
<lifeless> very very hookable in 2.1
 * thumper nods some more
 * igc lunch
<parthm> hello. regarding bzr-grep bug #536688 i wanted to check if anyone had any opinions. i am ok with either options.
<ubottu> Launchpad bug 536688 in bzr-grep "Default behaviour should recursively search versioned files" [Undecided,New] https://launchpad.net/bugs/536688
<parthm> --recurse is closer to POSIX grep while recurse by default is similar to hg and git.
<lifeless> I'd recurse by default
<lifeless> ls doesn't, but it used to, and I think we made a mistake making it not do it by default
<spiv> I agree, recurse by default.
<fullermd> I always run ls twice since it stopped recursing.
<spiv> Plain old grep doesn't have the advantage of knowing 'these files are all part of the one project', but bzr does.
<parthm> fullermd: :-)
<parthm> sounds fine to me. i will go with recurse as default and add a --no-recurse option.
<parthm> there is already a --from-root.
<parthm> if we go with recursive grep and user sets 'grep=grep --no-recurse' as an alias, how can (s)he override it from command line.
<parthm> do we need an explicit --recurse option or does the option processing framework do some magic?
<lifeless> parthm: our option stuff automatically does --recurse if you have --no-recurse, I think.
<parthm> lifeless: that sounds fantastic. i will go ahead with the --no-recurse.
<parthm> thanks everyone for your inputs.
<poolie> hi spiv, are you around?
<poolie> how are things?
<spiv> Yeah, I'm around.
<spiv> Things are going pretty well.  It's amazing how much easier it is to cope with the email load working 3 days a week rather than 2 :)
<spiv> I'm catching up on in-progress work that had started to accumulate.  Oh, and I'm glad I'm subscribed to the 'answers' for bzr, it's much more active than I had realised.
<poolie> yes it is
<poolie> i thought you were all just slack for not answering them ;-)
<poolie> i just put up an mp to plot that too
<vila> hi all !
<fullermd> Oh, vila's around.  Must be bedtime.
<vila>  :)
<codygman> is there an option to exclude certain filetypes in bazaar?
<codygman> when adding
<codygman> wait..  im just now seeing ingore list
<codygman> wow.. bzr remove actually deletes files doesnt it?
<bob2> yes
<bob2> unless you ask it not to
<codygman> rofl i freaked for a second
<codygman> then found revert
<codygman> and thanks.. i was just trying to get it to stop VC'ing some files
<codygman> so could i just use the --keep flag to do that?
<codygman> bzr remove ./lib --keep
<lifeless> yes
<codygman> thanks lifeless
<lifeless> vila: hey
<lifeless> vila: I put it to you that 'Conflict: can't delete lptools because it is not empty.  Not deleting.' is the largest cause of merge conflicts.
<lifeless> vila: and there is a bug about it, suggesting a lost+found approach, amongst other things.
 * vila nods
<lifeless> vila: if you were to fix this, I would be extremely excited.
<vila> It's definitely on the radar
 * lifeless bounces, gently.
<vila> A pretty big spot even
 * lifeless bounces faster.
<vila> I realized yesterday that 'bzr clean-tree' is kind of a workaround in some cases in the mean time
<lifeless> by the time you know you need it ..
<vila> sure, workaround is an optimistic way to talk of the problem :]
<vila> s/of/about/
 * lifeless wafts activation energy at vila
 * vila receives that gratefully
<quicksilver> vila: where is the canonical place to download DVC these days?
<vila> quicksilver: I'm not of any change there (I didn't upgrade it for a while though), let me checl
<quicksilver> there was some confusion about which repo to use last time I checked
<quicksilver> which was a while ago, I admit
<vila> http://bzr.xsteve.at/dvc/
<vila> I currently miss 48 revisions 8-}
<quicksilver> Forbidden
<quicksilver> You don't have permission to access /dvc/ on this server.
<vila> quicksilver: huh ? Where did you get that ? I just pull -v
<quicksilver> oh, OK.
<quicksilver> and you run straight out of the repo?
<quicksilver> or you copy the elisp files somewhere?
<vila> quicksilver: I run from the repo but I have a ++build there where I run make
<vila> quicksilver: I set that up so long ago I'm not even sure I still use it though
<quicksilver> :)
<vila> let me check another install
<quicksilver> ah well I better find a machine I have bzr on. I'm stuck on a temporary windows box :(
<vila> quicksilver: ouch
<vila> windows is the only OS I've yet to address in my versioned setups...
<quicksilver> mostly I just run emacs and putty and firefox and ignore the rest of the system
<quicksilver> I dont' try to program on it (I do that via ssh and a linux box)
<vila> I use the stock emacs there without any customization which has... some surprising results when confronted with my muscle memories :)
<quicksilver> hmm I don't know if I will want to do this after all
<vila> firefox on windows ?? Wow, I don't even make my windows VMs visible on the internet :)
<quicksilver> I just remembered that vc-bzr is really really painful over plink
<quicksilver> I imagine dvc will be as bad.
<vila> branch locally :)
<quicksilver> well new hard disk arriving today. Hopefully won't be long now.
<vila> quicksilver: not running make in ++build seems to work (as in no messages under emacs), but that doesn't mean it used the right versions either...
<vila> quicksilver: anyway, I think to remember you need to compile dvc before using it which require auto<something> and getting that on windows...
<vila> quicksilver: I *had* some instructions about installing/setting up dvc, but I can't find them anymore :-/
<vila> . o O (Well done for versioning all that setup stuff, well done really :-( )
<vila> hmm, may be it's because the dvc INSTALL file seems to cover it (including using ++build which is a rather unusual dir name for me)
<vila> quicksilver: so basically: autoconf; cd dvc; mkdir ++build; cd ++build; ./configure ; make
<vila> quicksilver: see the INSTALL file in short :)
<vila> ha, found these notes back, yeah, they are obsolete, I now use instructions from the dvc INSTALL file
<vila> :)
<quicksilver> :)
<Keybuk> bzr diff --using meld seems to be broken
<Keybuk> the diff still ends out mostly on stdout :(
<spiv> Keybuk: works ok for me, just the "=== path/of/file ===" lines end up on stdout
<spiv> (even with --no-plugins, --using is a builtin feature these days)
<Keybuk> spiv: I get the diff
<Keybuk> in fact, I get some diffs
<Keybuk> then sometimes meld pops up with the diff of just *one file*
<Keybuk> you close it, you get more diff on stdout
<Keybuk> interesting
<Keybuk> the diff is for added files
<Keybuk> (on stdout)
<spiv> Huh!
<spiv> That sounds like a silly bug.
<spiv> It is annoying that it only pops up meld for one file at a time.
<spiv> It's rapidly approaching my bedtime, so please file a bug report.
<cbx> Hey, I'm a newbie to version controls, and was wondering if all the code ends up in the trunk folder ?
<cbx> I have a live website I'm running, and would like to use that as the main branch. I can access that by FTP
<amitk> Hi all, What are the bzr commands to reorder a set of bzr commits while making some modifications to each commit (after a review cycle)
<beuno> amitk, bzr-rewrite
<beuno> it's a plugin
<amitk> beuno: hmm, apparently not in karmic
<xeviox2> what is stored in the "indices" folder of an repository?
<xeviox> s/an/a
<beuno> amitk, http://wiki.bazaar.canonical.com/BzrPlugins
<jelmer> amitk: it's still named bzr-rebase in karmic
<xeviox> does bzr use one .pack file for each file in the repository?
<beuno> xeviox, no, packs combine many revisions
<amitk> jelmer: rebase doesn't seem to do what I want. I don't want to rebase revisions r4..410 to another branch. I want to be able to export r4..r10 separately, fix the problems in each commit and reapply to a new branch. Does that make sense in bzr?
<jelmer> amitk: Hmm
<jelmer> amitk: Perhaps fastexport does what you need?
<amitk> jelmer: not from it's help
<xeviox> beuno: ok thanks, as far as I understand there are records stored in the .pack files and each record is compressed using zlib, correct?
<beuno> xeviox, yes
<xeviox> beuno: ok, looking at the records it seems that a blank line is used as a separator between the records. Each record has 3 lines as header. The first is a string showing the compress lib (e. g. gcb1z for zlib), the 2nd and 3rd are numbers, what are they for?
<jelmer> amitk: is there a particular reason you would like to modify the existing revisions rather than just fix the branch itself?
<beuno> xeviox, I don't know that much detail
<beuno> lifeless does, not sure if he's still around
<xeviox> beuno: thanks for the help :D
<xeviox> lifeless: ping
<beuno> xeviox, http://doc.bazaar.canonical.com/latest/developers/packrepo.html
<amitk> jelmer: I don't want all the the mistakes I make to go out in the final set of commits that I ask to be merged
<xeviox> beuno: thanks :D
<amitk> jelmer: I wonder if my workflow is unsuited for bzr
<xeviox> k, I'll come back later, thanks for the help :D
<jelmer> bob2: have you seen http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/2010-March/002925.html ?
<Stavros> hi
<Stavros> does anyone know where plugins are installed by default in ubuntu?
<Stavros> there's a bzr-notify running
<jelmer> Stavros: usually /usr/share/pyshared/bzrlib/plugins/*
<Stavros> ah, thanks
<Stavros> hmm, anyone know why bzr-notify would be running? i don't have that plugin as such
<jelmer> bzr-notify is not a plugin, it's a separate app
<jelmer> it lives in /usr/bin/bzr-notify
<Stavros> oh
<maxb> Stavros: It is a daemonm, and is started by /etc/xdg/autostart/bzr-notify.desktop
<Stavros> i don't see it in the packages i installed, how can i remove it?
<jelmer> Stavros: it's part of bzr-gtk
<Stavros> ah, thanks
<Stavros> jelmer: i removed that and it's gone, thanks
<JamieBennett> I'm having problems with a "bzr branch" complaining about a publickey permission problem and I can't see what it is (most likely a simple user error). Is there any way to get a debug log message of what is happening?
<Breaking_Pitt> what means this? I can't find any info -> bzr --no-plugins
<jelmer> JamieBennett: Hi; Usually it's easiest to see if you can use sftp to the same host
<jelmer> Breaking_Pitt: I'm not sure I understand your question?
<JamieBennett> jelmer: what can I do to test this? I thought it was a key issue but looking at my launchpad page and doing a gpg --list-keys it seems I have the right key on this system
<jelmer> JamieBennett: try connecting to launchpad using 'sftp -vv bazaar.launchpad.net'
<loxs> is there some tool that can show statistics on who committed what portion of the code?
<jelmer> loxs: you can use "bzr annotate" (or "bzr qannotate") to see who was responsible for what lines of the code in a particular file
<loxs> jelmer, yeah, I know that, but this doesn't solve my problem :)
<jelmer> loxs: "bzr stats" (from the bzr-stats plugin) will print a list of how many commits every committer has made
<JamieBennett> jelmer: seems its trying to log me in as jamie rather than jamiebennett, mmm
<jelmer> JamieBennett: ah, sorry - you might need "sftp -vv jamiebennette@bazaar.launchpad.net" in that case - bazaar knows your username but sftp doesn't
<loxs> hmm, thanks I'll check bzr-stats
<SamB_XP> probably can fix that with something in .ssh ?
<sjamaan> Hi
<JamieBennett> jelmer: http://pastebin.ubuntu.com/393336/
<jelmer> JamieBennett: is any of the ssh keys reported by 'ssh-add -l' listed on your lp page?
<Breaking_Pitt> i don't know what means the flag --no-plugins
<jelmer> Breaking_Pitt: See "bzr help global-options"
<jelmer> Breaking_Pitt: basically it prevents Bazaar from loading any of the plugins (see "bzr plugins" for a list of available plugins)
<Breaking_Pitt> ok jelmer
<Breaking_Pitt> tthanks
<jelmer> Breaking_Pitt: yw
<JFo> jpds, that --show-diff has really come in handy lately, thanks for recommending it.
<jpds> JFo: No problem.
<jelmer> maxb: hi
 * kfogel is away: switching consoles for a bit, back soon
<speakman> morning folks
<jelmer> hi speakman
<speakman> I don't really get the "loom" thing. And I'm not really sure what's the difference between a SCM and Quilt either. Any tip of documents to read about it?
<speakman> (actually I'm a little confused about what's a proper workflow in bzr using launchpad and a random bunch of people in a very-early stage in a new project)
<jelmer> speakman: a VCS records history - quilt or loom allows you to work with inter-dependent changesets that can be modified
<speakman> jelmer: but how does that differ from branching?
<jelmer> speakman: revisions don't change, quilt patches do
<lifeless> beuno: ?
<speakman> oh... but... patches becomes revisions..?
<jelmer> I think I might not be the best person to explain this.
<jelmer> sorry :-/
<lifeless> speakman: you're using launchpad and bzr?
<speakman> jelmer: it's ok :-D
<speakman> lifeless: yes we do
<lifeless> speakman: great. So, do whateever you like with bzr: it tries to keep out of your way.
<lifeless> speakman: ignore looms; ignore quilt
<speakman> lifeless: yes, I've been using bzr for a couple of years by now :)
<speakman> But there are still some workflows I just can't figure how to do "right"
<lifeless> looms are for distro folk collaborating on won't-be-merged stuff
<lifeless> speakman: ok, I got the wrong bit of the stick :). Can you tell me about the workflow that isn't working for you?
<speakman> First; I'm currently the only one with write permission to the projects primary target branch. Other contributors makes their own branch of that branch and do their work on their branch. But when finished with one feature (with all revisions pushed to ~username/projectname/my-new-feature and a merge requests sent) how do they get on with the next feature? Re-branching the primary target branch once again?
<lifeless> speakman: sure
<lifeless> speakman: they could fairly easily do 'bzr pull lp:project --overwrite'
<lifeless> speakman: or if they have a shared repo setup, 'bzr switch trunk; bzr pull'
<speakman> shared repo setup..?
<speakman> never heard of "switch"...
<lifeless> do this somewhere innocuous
<lifeless> bzr init-repo --no-trees project
<lifeless> cd project
<lifeless> bzr branch lp:YOURPROJECT trunk
<lifeless> bzr checkout --lightweight trunk working
<lifeless> cd working
<lifeless> now, to make a feature branch:
<lifeless> bzr switch -b newfeature
<lifeless> # hack hack hack, can push etc
<lifeless> # back to trunk
<lifeless> bzr switch trunk
<lifeless> # new feature
<lifeless> bzr swich -b newfeature2
<lifeless> #back to feature1
<lifeless> bzr switch feature
<luks> (btw, you can do that in one step: bzr branch --switch trunk newfeature2)
 * speakman is practising as we speak... hold on
<lifeless> luks: not with the same magic path lookup, last I looked.
<lifeless> luks: we should get it doing that though
<luks> oh
<speakman> is this documented somewhere? it really sounds useful, and I even didn't know about it!
<lifeless> sure is
<speakman> this looks especially useful in python projects, where the path is part of the module namespace
<speakman> anyone of you worked with Django?
<lifeless> not really
<lifeless> jelmer: how did you go on bug references?
<speakman> however -- in general, python projects relies on the current working directory name. Using bzr all branches have their own working dir name.
<mtaylor> jelmer: hey there... any thoughts on when a new bzr-builddeb package is going to be released to the ppa?
<jelmer> lifeless: for commitfromnews ? Haven't spent any more time on it yet
<jelmer> mtaylor: hey
<lifeless> jelmer: I might do a yak shave this morning then.
<jelmer> mtaylor: No idea, I'm not sure who's doing the PPA uploads - do you know?
<lifeless> ping john ferlito
<lifeless> via mail
<jelmer> lifeless: that'd be awesome - did you see my wip branch?
<lifeless> jelmer: no
<mtaylor> jelmer: I don't ... I just know that I can't install bzr-builddeb on my debian build machine without it breaking bzr
<lifeless> jelmer: I was going to start o bzr core with a new hook
<lifeless> I do _so_ love commitfromnews
<mtaylor> jelmer: should I just install from lp:bzr-builddeb?
<lifeless> mtaylor: join the bzr packing team and fix the ppa ;)
<mtaylor> lifeless: heh. I'd never thought about doing that :)
<jelmer> mtaylor: Yeah, I'd either ask johnf for an update or switch to lp:bzr-builddeb
<mtaylor> jelmer: cool
<mtaylor> thanks!
<mtaylor> jelmer: branching bzr-builddeb worked
 * mtaylor now wants a command "bzr branch-plugin" which translates "bzr branch-plugin builddeb" into "bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb" ...
<jelmer> mtaylor: talk to Beuno :-)
<speakman> Is shared repo a way to work around this python issues?
<speakman> Or should every python project have a "container" directory (where the setup.py usely exist)
<speakman> questionmark... :)
<lifeless> mtaylor: write it ;)
<lifeless> speakman: I don't know what your python issues are
<mtaylor> lifeless: I don't want it that badly - I want it sort of in the "I'd really like for someone to walk over and hand me a plate of freshly baked cookies" sort of way
<lifeless> mtaylor: I've started trying to aggressively yak shave
<chx> how can i revert on a lightweight checkout of a bzr:// ?
<chx> it says Transport operation not possible: readonly transport
<lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/lptools/lp-project/+merge/21124 was last nights
<lifeless> chx: its a bug, its fixed in trunk I believe
<chx> lifeless: wow
<mtaylor> lifeless: BOO YAH
<lifeless> or if not in trunkm then the patch is getting reviewed at the moment
<chx> checking out bzr/trunk is not fast.
<speakman> lifeless: 22:11:23 < speakman> however -- in general, python projects relies on the current working directory name. Using bzr all branches have their own working dir name.
<speakman> "from myproject.modules import MyClass"
<lifeless> chx: have you done lp-login ?
<lifeless> speakman: most python projects have myproject as a directory at the top of their branch
<speakman> lifeless: ok. that's how to solve it?
<speakman> (it's a pinax based project I'm currently into btw)
<chx> lifeless: how can i convert my tree into something revertable instead?
<lifeless> bzr reconfigure --branch should do it
 * beuno hides
<djmeltdown> just came to get some help...but a reinstall of the software fixed my problem...so ill just say hi!
<lifeless> jelmer: so, where is your branch?
<jelmer> lifeless: https://code.edge.launchpad.net/~jelmer/bzr-commitfromnews/extractbugnumbers
<lifeless> ok
<lifeless> I'll see about getting the bzr infrastructure togetherr
<jelmer> yarrr
<speakman> Doing on-the-fly conversion from <RepositoryFormatKnitPack1> to (remote). source
<speakman> This may take some time. Upgrade the repositories to the same format for better performance.
<speakman> what's that? "(remote). source" ?
<lifeless> launchpad
<speakman> how do I upgrade + pushing back?
<lifeless> you can use bzr info -v to find out mor details
<speakman> oh
<lifeless> there is an upgrade button on the launchpad branch page
<speakman> oh! cool :D
<speakman> If I set a big group as "Review Team" on a branch -- they still can't push to that branch can they?
<jelmer> hmm, no poolie today?
<lifeless> poolie has a day off
<lifeless> speakman: that is correct
<jelmer> lifeless: I'm trying to decide if he meant bb:tweak for https://code.edge.launchpad.net/~jelmer/bzr/export-use-tree-timestamp/+merge/20865
<lifeless> yes
<jelmer> (since he voted "Needs Fixing")
 * kfogel is away: machine fan cleanup; back later
<jelmer> maxb: hi
<maxb> hello
<jelmer> maxb: I've merged your range inclusion patch for bzr-rewrite
<maxb> I saw, thanks
<maxb> btw, one of the other things I'm working on is making rebase-foreign process its revisions in proper toposort order instead of the weird line-following algorithm it currently has. Do you know why it currently does what it does instead of just toposorting?
<jelmer> maxb: hysterical raisins? It just uses the other rebase infrastructure
<maxb> fair enough. I need to comb through my "random hackery to just make this work" branch and pull out a change for submission
<jelmer> maxb: btw, I noticed you added explicit handling of 'hg-v1:' to pseudonyms; that shouldn't be necessary since bzr-hg has always set the converted-from revision property
<maxb> My conversion was svn -> hgsubversion -> bzr-hg :-)
<jelmer> maxb: I mean this change: http://bazaar.launchpad.net/~maxb/bzr-rewrite/hg-papt-rebase-foreign/revision/180
<jelmer> maxb: those revids are already extracted in the call to foreign.foreign_vcs_registry.parse_revision_id() later in that function
<poolie> hi jelmer
<poolie> would you like to be patch pilot next week?
<jelmer> hey poolie
<poolie> it doesn't have to be a very big job but it does seem good to have one particular person driving it
<maxb> jelmer: I had the same underlying revisions from path A: [svn ---(bzr-svn)---> bzr] and path B: [svn ---(hgsubversion)---> mercurial ---(bzr-hg)---> bzr] and I needed the two end results to be considered pseudonymous
<jelmer> poolie: I wouldn't mind being patch pilot for a week, but I'm at lean training and a sprint next week so that week isn't ideal
<poolie> heh, ok, maybe later
<poolie> someone else? spiv/igc?
<jelmer> maxb: Yes, that would still be the case without that change
<igc> morning poolie
<poolie> hi there
<jelmer> maxb: ah, nevermind
<poolie> i'm not really here today
<jelmer> maxb: I see now you're using timestamps
<maxb> jelmer: Yes, tortuous, isn't it :-)
<jelmer> poolie: happy birthday btw :-)
<poolie> thanks :)
<maxb> And in a later revision I changed it because the timestamps didn't work because somewhere they'd become DST-shifted on one of the legs
<maxb> Anyway, the hacks to the pseudonyms function are very much specific to a particular branch that needed weird rebasing
<maxb> But I have bugfixes to other bits of rebase-foreign which I will polish and submit
<lifeless> poolie: shoo :P
<lifeless> poolie: wasn't it yesterday?
<jelmer> lifeless: I'm in Europe :-)
<poolie> it was
<poolie> today is Martin Day (observed)
<lifeless> \o/
<poolie> lifeless: do you want to pilot next week perhasp?
<lifeless> poolie: no thanks
<jelmer> maxb: I guess I shouldn't look at branches that haven't actually been proposed for merging yet :-)
<maxb> jelmer: Not if you expect them to actually be applicable for merging :-)
<lifeless> poolie: I'm still rotated, and I only just managed to get 3 hours of personal time in the last 3 or so weeks to do coding stuff.
<poolie> np, i understand
 * jelmer continues with maxb's rebase-merges branch
<lifeless> poolie: add to that that I'm travelling next week
<maxb> thanks
<spiv> poolie: I happy to do it if no-one else does, although I wasn't planning to do it until I was back full time.
<spiv> poolie: enjoy Martin Day (observed) :)
<lifeless> ok, cue music, time for another yak shaving session
#bzr 2010-03-12
<thumper> lifeless: do you have some time to talk?
<lifeless> sure
<lifeless> how would you like to talk?
<lifeless> thumper: ^
<thumper> lifeless: voice probably
<lifeless> ok
<lifeless> skype me baby
<thumper> ok, just getting a game down for maia
<bob2> jelmer: yeah, replied
<thumper> lifeless: trying to skype, no answer
<lifeless> thumper: sorry missed it
<mwhudson> jelmer: you around by any chance at all?
<jelmer> mwhudson: somewhat :-)
<mwhudson> jelmer: awake enough to talk about bzr-hg and incremental imports at all?
<mwhudson> or just a basic grounding in mercurial concepts i guess
<jelmer> mwhudson: Yeah, though planning to get some sleep soonish
<jelmer> mwhudson: anything in particular you'd like to know?
<mwhudson> jelmer: hm, i guess i'd like to know what remote.branches(unknowns) returns
<mwhudson> this seems to be a use of the word 'branch' i don't usually use
<mwhudson> is a branch a run of commits with a single parent?
<jelmer> mwhudson: IIRC yes
<jelmer> mwhudson: so that allows you to mainly worry about merge commits and not waste any roundtrips on simple ones
<mwhudson> jelmer: ok, that makes some kind of sense
<mwhudson> jelmer: i like the ample docstrings and meaningful variable names in the mercurial source btw
<mwhudson> </sarcasm>
<jelmer> :-)
<mwhudson> jelmer: so unknowns takes a set of revision ids and returns ... what?  the branches that contain the unknown revisions ?
<mwhudson> er
<mwhudson> remote.branches
<jelmer> my memory is failing
 * jelmer grabs the mercurial source
<james_w> jelmer: dude!
<james_w> yet more great patches!
<jelmer> james_w: hey!
<jelmer> mwhudson: unknowns the variable contains a set of revisions we have yet to fetch the branches for
<mwhudson> it seems branches for each revision walks back until it reaches a rev with 2 or 0 parents
<mwhudson> each *passed* revision
<jelmer> mwhudson: when we fetch a branch we check if we know the base of that branch - if we do we know we don't have to check that branches' parents - the revisions we have to fetch are in between the base and the head of that branch
<jelmer> mwhudson: which revisions we need from that branch we figure out later using a binary search
<mwhudson> ok, this is starting to make sense
<blunted> anyone familiar with the bazaar api?
<jelmer> blunted: somewhat
<blunted> i cant figure out how to get the url of a branch from its object
<lifeless> branch.base
<mwhudson> jelmer: i still don't get where we can decide to limit the revisions we fetch
<mwhudson> i guess it's going to make the function quite a bit more complicated
<blunted> thanks much, the documentation i've found doesn't seem to include attributes... maybe i'm missing something
<jelmer> mwhudson: I'm sorry, I might've been more optimistic about that when my brain had lost the impression of what this function is doing :_)
<mwhudson> jelmer: heh heh
<jelmer> mwhudson: we definitely can't do much before the binary search
<jelmer> mwhudson: yeah, I think it'd indeed be too hard
<jelmer> mwhudson: it's a pity though, because you'll still have to process a lot of data you're going to discard later
<mwhudson> jelmer: i don't really understand how all the revisions from a completely unseen branch end up in the returned set :/
<jelmer> mwhudson: branches that aren't seen at all are already present locally
<mwhudson> jelmer: i mean a branch where neither head nor root are present locally
<mwhudson> it seems to me at some point you need to add all the revs from between(head, root) to the returned set
<jelmer> mwhudson: the returned set isn't a set of revisions to fetch, it's the set of tips that's missing
<jelmer> hmm
<jelmer> I should get some sleep before I talk more nonsense
<mwhudson> jelmer: oh
<mwhudson> jelmer: yes, probably sleep is good :-)
<jelmer> that last sentence (<jelmer> mwhudson: the returned set isn't a set of revisions to fetch, it's the set of tips that's missing) is gibberish
<mwhudson> jelmer: noted
<jelmer> g'night!
<mwhudson> jelmer: talk you you on your monday i guess
<jelmer> mwhudson: yeah, happy to continue discussing this then - I guess it's not really urgent until the majority of the imports are fixed anyway?
<mwhudson> jelmer: no not really
<mwhudson> jelmer: it would be nice to make the code that passes limit= in the puller uniform across branch types
<mwhudson> but that's no big deal
<Emzzzz> http://imggmi.info/DSC-1268362455.jpg/ do my tits look big?
 * igc lunch
<spiv> I started a bit early today, so I'm off.  Happy weekend everyone!
<vila> hi all !
 * igc dinner
<sjamaan> Hi
<sjamaan> I get this error message in my apache log:  No handlers could be found for logger "bzr"
<sjamaan> What's causing this?
<evanton> how do I purge a file completely from a bzr repository? I believe that doing bzr remove will leave traces of the file in older revision (please correct me if I'm wrong), so this doesn't suffice
<bob2> yes, with difficulty
<evanton> I believe it at least makes sense to expect for such a feature from bzr, because it's file-based
<bob2> hm, it's not very file based
<evanton> it would be harder for git, because excluding a file would change the sha checksum for that revision snapshot totally
<bob2> that's not to do with file-ness, that's to do with identifying revisions based on content hashes
<bob2> you can use fast-export/import for this, I think
<bob2> or rebase
<sjamaan> evanton: It has more to do with the fact that people already have the full history in their own branches
<sjamaan> If you kill a revision afterwards, their branch will be inconsistent with the master branch
<evanton> sjamaan: not a problem in my case, since the branch is unique, but I see your point
<evanton> I was thinking about building a branch mirror revision by revision, from the moment when the file I want to purge was included
<evanton> and just recommiting each revision without including that file
<evanton> does this make sense?
<sjamaan> I get this error message in my apache log:  No handlers could be found for logger "bzr". What's causing this?
<gour> i'd like to use bzr with LP, but still keep using darcs for local development. now i'm curious if it is possible to configure bzr-explorer to use bzr-fast-import on certain repo and then push branch to LP. similar when pulling from LP (using fast-export) ?
<gour> i'm not sure whether hats in explorer are working here
<gour> I read http://bazaarvcs.wordpress.com/2010/03/01/bazaar-explorers-killer-feature article but do not see docs about adding one's own hats
<sjamaan> After installing the bzr desktop bundle on OS X, I don't see any new apps under Applications, and "bzr explorer" says "unknown command".  How do I open the explorer on OS X?
<gour> sjamaan: what bzr plugins says?
<sjamaan> gour: Just a sec
<sjamaan> gour: It lists qbzr, but not explorer
<gour> sjamaan: then it's not installed (properly)
<sjamaan> gour: Then what can I have done wrong?  I simply downloaded the desktop bundle and clicked through its installer
<sjamaan> I retried using custom installation, but that doesn't make a difference
<gour> sjamaan: i do not know mac, but maybe it's not part of bundle?
<sjamaan> gour: I don't know mac either (helping out a colleague), but the docs all point to the bzr download page, and say you should download the desktop bundle as it contains explorer
<sjamaan> "The latest Bazaar 2.x application bundles for OS X include Explorer. In some cases, you still need to install Qt binaries separately. See http://wiki.bazaar.canonical.com/MacOSXDownloads for details."
<sjamaan> [http://doc.bazaar.canonical.com/explorer/en/install-osx.html]
<gour> hmm
<sjamaan> There's only one desktop bundle too, only for the previous release
<sjamaan> Luckily the OS X version matches my colleague's OS X version
<gour> :-)
<sjamaan> jeez, if I understand correctly the bundle is broken in some way and you need to go download a new version of the Qt SDK from the Trolltech site
<sjamaan> WTF
<sjamaan> [ http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac ]
<gour> :-/
<sjamaan> Or pay up and upgrade to 10.6, coz that works
<sjamaan> :)
<sjamaan> That SDK is 550 Mb
 * sjamaan wonders how others were able to get bzr working on their macs
<sjamaan> It's not exactly obvious
<huntz0r> Was wondering if someone could give me a real quick answer (not been able to find this out on the docs).  How can I "unstage" files or rather reset the current working tree? (I think that's the terminology)
<hmeland_> huntz0r: I think you're looking for "bzr revert".
<huntz0r> Thats the one!!  Cheers hmeland_!
<BjornW> I'm looking for a howto for using bzr and I find the documentation not in depth enough. Is there another source available with more info?
 * SamB_XP hands BjornW a pair of 3D glasses
<gour> BjornW: what did you try?
<BjornW> I'm trying to setup a workflow for 2 people where one is on Windows and I'm on Ubuntu.
<SamB_XP> BjornW: and ?
<gour> BjornW: you can use it as both are on the same machine
<BjornW> What I would like to achieve is have 1 master branch and merge from our local branches
<SamB_XP> does the 'dozer have an SSH account on your machine ?
<BjornW> SamB_XP: nope
<SamB_XP> or on some machine you both have accounts on?
<BjornW> SamB_XP: I think we can setup a server
<SamB_XP> it's really quite simple to use bzr over ssh ... did you look at the wiki ?
<SamB_XP> oh, and if by some chance the project you are (going to be) working on happens to be open source, you could just use launchpad instead of setting up your own server
<BjornW> SamB_XP: would love to use LP, but this is not my project and the other person does not want to make this floss :(
<SamB_XP> fear not -- that would only simplify it a teensy bit
<SamB_XP> well, I mean, once you get the permissions set up on the server so that you can both push to whatever branches you keep there
<SamB_XP> the issues involved are really no different from those you see with darcs or git, except that bzr works a lot better on Windows than I remember darcs working there :-)
<SamB_XP> BjornW_: getting anywhere ?
<BjornW_> SamB_XP: I'm now setting up my server. Just created a bzr repo
<BjornW_> Trying to fix this issue for future collaboration as well :)
 * gour is quite satisfied with darcs, but will use bzr for publishing branches on LP
<SamB_XP> BjornW_: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial says that setting the permissions on a directory to "02770" should keep everything bzr puts under the directory group-writable
<SamB_XP> at least, if you use bzr+ssh:// and not sftp://
<sjamaan> :(
<SamB_XP> sjamaan: ?
<sjamaan> It looks like my attempt to switch our company over to bzr has failed
<SamB_XP> oh
<SamB_XP> what are you using now ?
<sjamaan> svn
<SamB_XP> could be worse!
<sjamaan> True :)
<sjamaan> The GUI situation for OS X is horrible
<SamB_XP> I heard about a professor who was making everyone in his class use CVS, and called the use of the CLI "unprofessional"!
<sjamaan> heh
<idnar> wait, what CVS GUI were they using then?
<sjamaan> tortoise?
<sjamaan> It's pretty good
<SamB_XP> I think he was suggesting they use, say, Emacs' integration
<sjamaan> haha
<idnar> Tortoise is Windows only, isn't it?
<BjornW_> SamB_XP: thanks!
<SamB_XP> idnar: er ... maybe ?
<sjamaan> idnar: yeah
<sjamaan> Most schools are still 100% windows
<BjornW_> SamB_XP: how can I use a different user with bzr+ssh? Something like bzr+ssg://anotheruser@myserver.com/repos/trunk?
<BjornW> bzr+ssh
<BjornW_> how can I branch from a branch only a specific directory? Is this even possible?
<jelmer> BjornT: no, this (partial checkouts) is not supported (yet)
<NfNitLoop> What do people in here generally use to handle 3-way merging when you encounter conflicts?
<NfNitLoop> and how do you integrate w/ kde?  I remember last time I did this trying to call kdiff...
<NfNitLoop> and it would open the .THIS, .OTHER, and .BASE files...
<NfNitLoop> Hrmm.  I guess I'm just a n00b at 3-way merging in general.
 * NfNitLoop does some more googling.
<jelmer> NfNitLoop: I'm pretty sure there is some integration for things like kdiff in qbzr
<jelmer> but I have no experience with them
<NfNitLoop> jelmer: so it does.  Thanks.
<NfNitLoop> Apparently I was just missing the point where 3way merge tools don't bother copying the modified .THIS over the versioned file for you.  I assumed I was doing something wrong. :p
<NfNitLoop> Oh well, it ended up being trivial anyway.  (My changes win!)  :p
<aspidites> i can't seem to find a way to check out an earlier revision
<jelmer> aspidites: bzr branch -r<revnum>
<Peng> "bzr branch -r 123" "bzr revert -r 123" "bzr update -r 123"
<Peng> Depending on what you want.
<aspidites> jelmer: wow. that easy? how did i not see that. Thanks!
<Peng> "bzr checkout -r 123" too! :D
<aspidites> btw, is there a preferred method of resolving conflicts? doing "bzr merge" "bzr resolve filename" is what got me in this situation in the first place
<aspidites> adding a bunch of <<<<'s and >>>'s to the file in question.
<NfNitLoop> aspidites: the preferred method is to actually resolve your conflicts before running 'bzr resolve filename'.
<NfNitLoop> resolve just *marks* the file as resolved, a human (i.e.: you) still has to make sense of the differnces and choose how to integrate them.
<NfNitLoop> This is not unique to bzr, by the way.  SVN and CVS have this same behavior.
<NfNitLoop> There are a couple ways to actually do the resolving, though.
<NfNitLoop> 1)  Read the file and remove the >>>> <<<< bits, making sure what code you leave in is how you want the merge to go.
<NfNitLoop> 1b) then run bzr resolve.   do that on all files.  Then do 'bzr commit' to finish your merge.
<NfNitLoop> Or 2)  Use a GUI 3-way merge tool for more complicated merges.   as jelmer recommended to me earlier, qbzr has some integration for that.
<NfNitLoop> so I did:  bzr qconflicts.   Double-clicked on each of my conflicts, merged changes in my GUI diff viewer.  Copied the .THIS file over the versioned file, then ran 'bzr resolve'.
<aspidites> NfNitLoop: thanks, i will try that
<aspidites> so if i understand correctly, the >>>'s etc are added during a merge to note conflicts. i then decide after sifting through the files which changes i want to commit, then do resolve on each of those files?
<Peng> aspidites: You edit the file somehow to what you want, and then you use "bzr resolve" to tell bzr that you've resolved the conclits.
<Peng> Err.
<Peng> conflicts*
<Milo-> hey, I made a commit, and then pulled and had some conflicts which I couldn't handle at that time of day, so I did 'bzr revert', which for some reason removed my commit and all the changed made with it
<Milo-> how do I undo revert?
<Milo-> I know the files are reachable, since I had commited
<Milo-> just like bzr uncommit lets you undo, so can bzr revert be undone?
<NfNitLoop> Milo-: Did you do a 'bzr pull --overwrite'?
<NfNitLoop> or a 'bzr merge'?
<Milo-> actually, bzr update, checked my logs..
<NfNitLoop> ah, this is a bound branch?
<Milo-> yes
<Milo-> wasn't bound when I committed.
<NfNitLoop> right, so you had local commits, then did an update, got conflicts, then reverted...
<NfNitLoop> Hrmm.
<Milo-> yup
<NfNitLoop> did you do any commits after that?
<Milo-> no
<NfNitLoop> that's good. :p
<NfNitLoop> what does 'bzr status' say?
<Milo-> says clean
<NfNitLoop> Hrmm.  Sounds like revert is acting differently on bound branches?   *reads*
<Milo-> well, clean as in I have a lot of uncommitted changes, mainly binaries and such
<Milo-> ahhh meh
<Milo-> there is "dir.moved"
<Milo-> I failed to see that .moved earlier:)
<NfNitLoop> likely what you'll have to do is find the old commit in your log, resurrect it as a new branch, and merge those changes back in.
<Milo-> Don't know how to get that commit from the log, since it is not visible
<NfNitLoop> it's not in ~/bzr.log?
<Milo-> oh, didn't know about such log :
<NfNitLoop> yeah, so when you update a bound branch, it tries to merge your stuff with upstream.  When you reverted...
<NfNitLoop> well, usually revert only reverts files, did you do revert --forget-merges too?
<Milo-> just 'bzr revert'
<NfNitLoop> or do you have pending merges in your 'bzr status'?
<Milo-> not according to bzr status
<lifeless> NfNitLoop: 'bzr revert' will discard pending merges. 'bzr revert .' won't.
<lifeless> just FYI
<Milo-> ah
<NfNitLoop> oh?  Is that new?
<Milo-> that explains it
<lifeless> NfNitLoop: no
<NfNitLoop> Huh.  I guess maybe I added the '.' when I ran it before without realizing.
<lifeless> NfNitLoop: revert with no args reverts everything; revert of any path only reverts that path
<Milo-> there were no harm done when it nuked some of my source code
<NfNitLoop> Milo-: so when you ran revert, it reverted to upstream's branch.
<Milo-> yeah seems so
<NfNitLoop> and you no longer have a reference to your commit in your history.
<NfNitLoop> so you have to go pluck it out of your log.
<Milo-> no need
<Milo-> I Only had spent 40 minutes on that feature anyways
<Milo-> re-made the whole feature with better quality in less than 10 minutes :P
<NfNitLoop> hehe.
<NfNitLoop> that's how you'd get around that, though.
<Milo-> came here to ask how it is done, in case I actually need something like that in the future
<NfNitLoop> without the log... I'm not sure what you would do.
<NfNitLoop> anyone else have a suggestion?
<fullermd> heads
<NfNitLoop> fullermd: ah, handy.
<NfNitLoop> I figured there was a tool like that, but hadn't poked around bzrtools enough to find it.
<Kamping_Kaiser> wow... i'm impressed with bzr-svn, merged in new changes without me doing anything.
<Kamping_Kaiser> jelmer: thanks :)
<NfNitLoop> Kamping_Kaiser: isn't it awesome?
<Kamping_Kaiser> NfNitLoop: it just is.
<NfNitLoop> We use SVN at work and I use bzr for all my local branches for just that reason.
<NfNitLoop> Well, plus I don't have to pollute the central repo w/ all my branches.
<NfNitLoop> And when our SVN server goes down I can keep on working. :p
<Kamping_Kaiser> :)
<Kamping_Kaiser> interesting. patches are replayed on top. wondered where the -rewrite dependency came from
<NfNitLoop> Kamping_Kaiser: it depends on how you do your development.
<NfNitLoop> but bzr-svn will warn you if they're not going to be linear when you try to push back to svn.
<Kamping_Kaiser> NfNitLoop: I only deal with r/o svn repos, so i haven't had a chance to encounter that yet
<NfNitLoop> Oh.  Then I'm not sure what you meant by "patches are replayed on top".
<NfNitLoop> (or, for that matter, "the -rewrite dependency.")
<Kamping_Kaiser> NfNitLoop: bzr-svn in debian recommends bzr-rebase (which iirc is now bzr-rewrite)
<Kamping_Kaiser> NfNitLoop: and i was mistake about the replay, the changes were merged, but they don't have a commit associated with them
<wgrant> Kamping_Kaiser: If the branch you merge from doesn't exist on the svn server, then its revisions can't be recovered when you check out trunk again.
<wgrant> It results in a so-called 'ghost' revision.
<Kamping_Kaiser> wgrant: itdoes exist - i pulled it with svn into its own branch, and with bzr into a branch i modify
#bzr 2010-03-13
<NfNitLoop> Kamping_Kaiser: Hrmm.  Oh, did you just have local changes in your working copy (but not committed) and 'bzr up' updated them?
<NfNitLoop> that's pretty standard.
<Kamping_Kaiser> NfNitLoop: its standard to merge upstream changfes without a commit if the working directory has unommited chagnes?
<Kamping_Kaiser> oh, i see what you mean
<Kamping_Kaiser> if you are ahead of trunk, it pulls down chagnes but doens't commit
<marv> how's bzr loom coming along? the documentation (especially http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt) make it sound like if i make a wrong move i could screw the whole quilt up
<marv> how well would it work to track say, around 30 separate patches? I'm currently doing it in git and with topic branches for each patch, and a branch where everything is merged together.
<marv> thinking of switching it to bzr, and wondering if i should try loom or keep it as topic branches
<marv> i'm also wondering if you can use loom with bound branches
<fullermd> Well, I don't use loom.  But I don't see how it would help you with 30 _separate_ patches.  It would fit with a stack of 30 patches, depending on each other in sequence.
<marv> a few of them are related or at least touch the same pieces of code, but a lot of them touch separate pieces of the code and are independent of each other
<fullermd> A loom is basically a single stack.  So, if you have 2 or 3 branches that build on each other, a loom could be useful there.  But it would be more of a distraction when they're not.
<marv> ok, thanks for the advice
<fullermd> Of course, you can mix&match.  If you've got 5 branches that build on each other, that's one loom here.  Another 3 that build on each other, a second loom here.  A dozen that are independent, there's a dozen branches over there...
<marv> yeah but then i have to teach anyone who works on those about the loom commands, and since they aren't normally required no one will know how to use them, doesn't sound worth the effort
<fullermd> Oh, you have to deal with other _people_.  I've located your problem   8-}
<fullermd> A loom with N threads doesn't do anything you can't do with N branches; just automates following some of the steps.  So you don't necessarily lose a lot without them.
<marv> well, if i don't deal with other people, then I have to do everything myself. and I don't scale very well.
<fullermd> I understand that if [a subset of] what you want to do fits them, the added convenience can be handy.
<fullermd> Yeah.  Just adds fuel to my belief that the universe should be sent back with a failing grade for this beta.  Maybe they'll fix that in the final release...
<marv> dealing with other people is a large part of my motivation of trying to switch to bzr from git. have you ever tried to teach people used to svn how to use git? and not just any git, but a git repo with 30+ feature branches, a master that follows upstream, and several branches with everthing merged together?
<Supertanker> Oh hey, using BZR 2.x is way faster than 1.x :P
 * Supertanker is like, super smart for realizing that
<Solipsist> i got a problem on mac, qbzr cannot find pyqt even though the correct version is installed
<fullermd> Are you sure it's installed for the same version of python as bzr is using?
<Solipsist> i got two instances: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-pyqt4 and /Library/Python/2.6/site-packages/PyQt4
<Solipsist> the latter is the more recent one
<fullermd> The former sounds like a build location.
<fullermd> See `bzr version`, and look at what it says it's using for the python interpreter and library location.
<Solipsist> http://pastebin.com/N5ttQFSz
<fullermd> Looke like a different python to me.
<Solipsist> yeah it's using the Python i installed from macports
<fullermd> Well, PyQt is.  bzr isn't.  Or maybe it's vice versa.
<Solipsist> i followed this guide, (installing for 2.6 instead of 2.5 though, rest i followed the guide to the point): http://blog.webgamic.nl/tag/qbzr-mac/
<Solipsist> how do i fix it?
<fullermd> Dunno.  I don't Think Different   8-}
<Solipsist> ill try install pyqt using macports, might sort it
<fullermd> As a guess, I'd try using the stdlib dir bzr is looking at (well, with '/site-packages' appended) for all those -d's, and using its full python path, and see if that works.
<Solipsist> how do i change stdlib dir?
<fullermd> I'd guess that's what the -d's on those command lines refer to.
<Solipsist> $ sudo ln -s /Library/Python/2.6/site-packages/* .
<Solipsist> just symlinking them from the /Library location to the location where macports put Python sorted it
<fullermd> Mmph.  That sounds like a nasty ugly hack that'll come back to bite you.
<Solipsist> likely yeah, once i update the macports package
<Solipsist> sorts the problem now, will have to install bzr from source and not use the macports package as its obviously antiquated
<Solipsist> another day, another lesson - lol, thanks for you help
<fullermd> np  :)
<Arrrgh> official site claims that there is a Visual Studio plugin for bzr but I can't find any download, who knows where
<Arrrgh> it is?
<jelmer> arrrgh: launchpad.net/bzr-visualstudio IIRC
<jelmer> I think it's unmaintained at this point thouh :_/
<Arrrgh> I'd like to see even outdated plugin. but there is no any downloadable file
<jelmer> Arrrgh: there's a bzr branch you can download
<Arrrgh> where?
<jelmer> https://code.edge.launchpad.net/~hartke/bzr-visualstudio/banquet.status
<jelmer> (linked from the "branches" page on the bzr-visualstudio project page)
<Arrrgh> I can't branch, it says"bzr: ERROR: Not a branch: "D:/projects/third-party/lp:bzr-visualstudio/"", what's wrong?
<jelmer> what command are you running exactly?
<jelmer> do you have the launchpad plugin installed?
<Arrrgh> so I need a special plugin for launchpad. ok, thanks
<jelmer> Arrrgh: it should be included with Bazaar
<jelmer> Kamping_Kaiser: that's great to hear, thanks :-)
<slestak> Hi guys
<slestak> question, i really want to version some src that lives on an aix box.  with the dependency we have on the aix build on a special py build, i cannot install it
<slestak> what i want to know is if it is a bad idea to version an smb share of the items
<slestak> thoughts?
<jelmer> slangasek: using bzr over smb should work ok
<jelmer> s/slangasek/slestak/
<slestak> k, ive started googling to see if there is prior discussion.
<slestak> one concern i had is the .bzr might be touched by both linux and win32 clients.  locally running bzr doesnt do that.  that is the potential weak point in doing this
<slangasek> jelmer: but not over nfsv4! :)
<slestak> smb has gotten so pervasive and easy, i dont even consider nfs
<bronger> I'd like to user "bzr split", however, it always says "To use this feature you must upgrade your branch to a format which supports rich roots".  "bzr info" says that I use branch format 7.  What should I do?  Every "bzr upgrade" I tried ended with "ERROR: The branch format Meta directory format 1 is already at the most recent format".
<Peng> bronger: What version of bzr are you using? What repo format are you using?
<bronger> Repo is version 6.
<Peng> bronger: It's the repo format that matters here, not the branch format.
<Peng> Although that error message is not very obvious.
<bronger> "Packs 6".
<bronger> bzr 2.0.2.
<Peng> bronger: Not Packs 6 Rich Root?
<bronger> No, only "packs 6".
<Peng> Then I guess it's not a rich-root format?
<bronger> I don't know.  I do an upgrade in the shared repo directory.
<Peng> Wait wait. bzr 2.0.2? That should upgrade you to 2a by default.
<bronger> So which option should I give?
<Peng> You don't have to give an option. Something is going wrong. Either you're not really using bzr 2.0.2, you already have upgraded to 2a, or you're upgrading the wrong location.
<Peng> What does "bzr info" on the branch say?
<bronger> Format:
<bronger>        control: Meta directory format 1
<bronger>   working tree: Working tree format 6
<bronger>         branch: Branch format 7
<bronger>     repository: Repository format 2a - rich roots, group compression and chk inventories
<bronger> (After I did the repo upgrade)
<Peng> OK then. So you should be all set.
<bronger> Okay, thank you!
<Kamping_Kaiser> I just managed to get bzr[ rebase] to explode. http://paste.debian.net/63990/ . should i file a bug on bzr or rebase? the message says bzr, but i'm unsure
<Kamping_Kaiser> s/rebase/rewrite i guess, since i'm uzing the bzr branch
<maxb> Kamping_Kaiser: On bzr-rewrite. The message is generic
<Kamping_Kaiser> maxb: cheers
<Kamping_Kaiser> sigh. launchpad login issues. i'll try again later
#bzr 2010-03-14
<jelmer> lifeless,jam: Any idea what could cause BTreeIndex.add_node() to become tediously slow after a while ? It's spending all its time in _spill_mem_keys_and_combine()
<C-S> what does this error in launchpad mean: Unexpected form data.
<C-S> It appears always, when i try to log in using firefox
<Kamping_Kaiser> C-S: it means launchpad is broken - i see it too
<C-S> Kamping_Kaiser: this is a mess, as it does not work since many weeks.
<C-S> Kamping_Kaiser: so, I usually login using opera
<Kamping_Kaiser> C-S: really? just now is the first time i've seen it
<Kamping_Kaiser> C-S: i wonder ...
<Kamping_Kaiser> C-S: it means launchpad requires cookies to log in
<C-S> Kamping_Kaiser: But I don't have a cookie when I login for the first time.
<Kamping_Kaiser> C-S: if i tell FF to allow cookies for launchpad.net i get 3, and can log in.
<Kamping_Kaiser> 2 for lp.net, and 1 for login.lp.net
<C-S> Kamping_Kaiser: let me try this...
<C-S> Kamping_Kaiser: does not work. I get the cookies but still the same error as before.
<Kamping_Kaiser> C-S: hm guess you'll have to ask in #launchpad
<C-S> Kamping_Kaiser: thanks so far...
<Kamping_Kaiser> C-S: i only deal with LP when bzr breaks, so i don't know much about it ;)
<C-S> Kamping_Kaiser: don't worry, I don't use LP very often anyway.
<lifeless> Kamping_Kaiser: you can file via email
<lifeless> jelmer: it means you have a large index, and its spilling to disk to avoid thrashing; then it combines the disk indices when you finalise.
<jelmer> lifeless: any idea why it slows down the process so much ?
<lifeless> serialisation, gz compression
<jelmer> It's at least a factor 1000 slower than initially
<Kamping_Kaiser> lifeless: i'll go and check the docs, i can never remember the format LP uses
<jelmer> lifeless: ^
<lifeless> jelmer: yes
<lifeless> jelmer: there may be something odd going on, but writing the index is a big chunk of the effort involved
<jelmer> lifeless: I hope there is..
<jelmer> lifeless: At first I can process ~30 revisions per second, after that it's more like one revision every minute
<jelmer> lifeless: it's not just one moment where it's flushing stuff to disk, it appears to be doing it continually
<lifeless> jelmer: lsprof it
<lifeless> I'd offer to look at it, but am flat out at the moment
<lifeless> jelmer: it's meant to flush strips of increasing size
<lifeless> and recombine them with expontential backoff
<jelmer> lifeless: No worries, thanks for pointing me in the right direction.
 * Kamping_Kaiser emails in his bug reports
<Kamping_Kaiser> jelmer: sorry about the dupe report on -rewrite
<jelmer> Kamping_Kaiser: no worries - any chance you can mark them as such?
<Kamping_Kaiser> jelmer: sure.
<shakaran> Hi, I trying to use bazaar on Windows and I get this error when dowload a branch: Authentication (publickey) failed.
<shakaran> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
<shakaran> I run puttygen and pageant, but it dont work
<shakaran> and the public key for launchpad says that it is invalid
<shakaran> I generate my key with ssh-2 RSA
<shakaran> some help?
<shakaran> please, I'm stuck with this
<shakaran> I made! The tutorial on lauchpad is very incomplete. You need put images. I only need copy the open-ssh key from text box.
<shakaran> how I can have symlinks with bazaar on windows?
<luke-jr> where does bzr-svn identify what it thinks is the first revision of a branch?
<wbruce> Is there a command that can be used to find out what revision a revisionspec would point to?
<wbruce> (kind of like rev-parse in git)
<mwhudson> wbruce: 'bzr revision-info <revspec>' ?
<wbruce> mwhudson: thanks!
<lifeless> mwhudson: its the weeken man :P
<mwhudson> lifeless: and so not the time to be digging in to bzr-hg bugs?
<lifeless> mwhudson: :)
<jelmer> luke-jr: it's the revision that created the path that is the root of the branch
<keshav> Hai I am Keshav from India. i have a few questions about bzr, specifically grub2 related info
<keshav> Any way to stop bzr from tracking the x-bit of files in a repo?
<parthm> hello. do test names for plugin tests cases 'def test_xxx' have need to differ in the first N characters or something?
<parthm> i find that some of my tests are silently skipped i.e. they don't show up in the count.
<parthm> changing the name fixes that. but its difficult to know which tests are ignored without knowing the exact behavior.
<luke-jr> jelmer: yes, I noticed that. I'm looking for where that is calculated/detected so I can fix it.
<jelmer> luke-jr: What needs to be fixed about it?
<luke-jr> jelmer: our project used projectname/{tags,branches,trunk} and projectname has undergone renames multiple times
<luke-jr> bzr-svn persists in treating the last rename as the initial revision
<luke-jr> currently the structure is projectname/{tags,branches,trunk}/subproject/
<jelmer> luke-jr: in that case, was it really a rename ? Not just the revision where projectname/trunk/subproject was actually created?
<luke-jr> but if 'subproject' were followed backward, it would eventually inherit from originalprojectname/trunk
<luke-jr> jelmer: yes, it was renamed from 'armagetron' to 'armagetronad'
<jelmer> luke-jr: so "svn log" on the same URL you check out with bzr-svn reports the full history?
<luke-jr> bzr-svn works if I create armagetronad{/{tags,branches}} and svn cp each tag/branch/trunk individually
<luke-jr> jelmer: yes
<jelmer> luke-jr: I'm not sure I follow
<luke-jr> actually, no :(
<jelmer> luke-jr: the project is private?
<luke-jr> jelmer: no
<luke-jr> https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk is the current trunk
<luke-jr> https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/armagetronad actually
<luke-jr> if I 'svn log' in *that* checkout, it does successfully go back to svn r1
<jelmer> and you're checking out https://armagetronad.svn.sourceforge.net/svnroot/armagetronad/armagetronad/trunk/armagetronad ?
<luke-jr> jelmer: that's what the bzr branch would be based on, yes
<luke-jr> and that's what 'svn log' shows the full history of as well
<jelmer> luke-jr: see r4609
<jelmer> luke-jr: in that revision the branch root is created from scratch
<luke-jr> jelmer: but the branch itself is not
<luke-jr> so the question is, where is bzr-svn making this (incorrect) assumption that it is the first revision? where do I need to modify the code? :P
<jelmer> luke-jr: I'm looking at what bzr-svn is actually doing..
<luke-jr> jelmer: where is it actually doing that? :)
<jelmer> luke-jr: if this has to be modified it can't be merged into bzr-svn itself without a mapping change
<luke-jr> I'm expecting a mapping change as a result of the earlier revisions being processed
<luke-jr> shouldn't affect non-affected branches though afaik
<jelmer> but it would collide with existing imports
<luke-jr> for affected branches, yes
<luke-jr> I'm expecting to need to write an old-branch upgrade script of some sort
<luke-jr> (would be convenient if we can set some revprops on r1 that tell bzr-svn to use the bzr trunk's fileids when possible, tho)
<jelmer> luke-jr: how do you mean?
<luke-jr> I mean I understand that fileids are based on the initial revision where bzr-svn sees the file, so making older revisions available will by default change those...
<jelmer> right
<luke-jr> ideally, we might be able to set a bzr:fileids revprop on r1 or such to preserve the bzr trunk's fileids, but that's not neccessary
<luke-jr> bbiab
<jelmer> but that's part of a larger problem, all file ids and revision ids would/could change with a new mapping format
 * luke-jr can't even try w/o knowing what part of the code handles that stuff
<jelmer> it's mostly in revmeta.py
<jelmer> luke-jr: Hmm, I actually get an error on that URL when running bzr log against it directly
<luke-jr> jelmer: ok? :P
<luke-jr> jelmer: RevisionMetadataBrowser.do never seems to run? :(
<jelmer> luke-jr: depends on the situation in which you're running it..
<luke-jr> branch?
<lifeless> moin
<poolie> hello all
<Peng> Hi. :D
<igc> morning
<poolie> hi igc
<poolie> how are you?
#bzr 2011-03-07
<vila> hi all !
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.0 is officially out ! (RM: vila)
<geekosopher> immediately after I branch any lp repo to one of my hd partitions (outside /home), 'bzr st' shows all files of the repo in 'modified' category, and 'bzr diff' shows all file names with '(properties changed: -x to +x)' appended to them
<Peng> Is this some fun file system?
<geekosopher> the hd partition in question is set to automount by adding a line in fstab file
<geekosopher> its vfat
<Peng> Lovely.
<vila> geekosopher: OS/version/file system involved ? This sounds like the underlying fs doesn't handle the exe bits properly
<geekosopher> vila: kubuntu/10.10/vfat
<geekosopher> Peng: that sounds like 'no'
<geekosopher> *no solution
<geekosopher> i tried changing the file system permissions, but either nothing or umask=0*** gives above error
<maxb> I seem to recall seeing a bug about this? Yes, it's more or less expected behaviour for bzr on vfat on linux
<geekosopher> and anything other than 0** causes inaccessibility
<geekosopher> yes, this is typical of bzr only, git is working fine
<maxb> Obviously it would be nicer if bzr ignored the modifications, but it's not behaving that unsurprisingly, given the underlying FS *has* modified the perms from what was in the repository
<geekosopher> explicitly doing chmod is not working either
<geekosopher> like 'chmod -x <repo directory>
<maxb> Well, no, it wouldn't. The vfat fs is incapable of storing permission information.
<geekosopher> >.<
 * geekosopher wondering how bzr works on windows
<geekosopher> oh yes, windows wouldn't even have permissions stuff
<Peng> Windows has the execute bit, which is all Bazaar tracks.
<geekosopher> hmm
<vila> geekosopher: not to mention symlinks...
<Mez> is there anywhere a good into ro using bzrlib?  I want to create a quick script that emails people about uncommitted changes in their branches.  But would prefer to do it using bzrlib rather than system calls.
<jam> hey vila, I haven't gotten a chance to /wave at you in your timezone yet :)
<vila> jam: hey !!!
<jelmer> :)
<jelmer> 'morning jam, vila
<jelmer> vila: welcome back, I hope you had a nice vacation :)
<vila> jelmer: wonderful !
<jam> well, afternoon here, I hope :)
<jam> either that, or I'm *really* confused
<jelmer> jam: You're not :)
<vila> :)
<jelmer> Mez: I don't think there's anything like that, but this should get you started:
<jelmer> Mez: from bzrlib.workingtree import WorkingTree; wt = WorkingTree.open("."); changes = wt.changes_from(wt.basis_tree())
<Mez> jelmer: yeah - had just found that in the documentation.
<Mez> Though for some reason, taht doesn't show files that have been created, but not added.
<jelmer> Mez: wt.unknowns() will list those files
<jam> geekosopher: on Windows, we know that we can't trust the fs, so we use the executable bit from the basis inventory. We don't have a good way to know that the FS is vfat, AFAIK.
<jelmer> jam: We could add a check to see if we can set the executable bit correctly, like we do with case sensitivity
<vila> jelmer: +1
<jam> jelmer: case sensitivity only has to stat an existing file with a different path
<jam> not actually do a mutation operation
<jam> like chmod
<jam> consider readonly systems
<jam> It might be reasonable to check that during update, though
<Mez> jelmer: what are delta.unchanged and delta.uncommitted for /
<jam> I don't really want to do it on every 'bzr status'
<jelmer> jam: fair enough
<Mez> sorry, delta.unversioned
<jam> Mez: unchanged == files that are versioned that have not changed
<jam> only available if you pass include_unchanged
<jelmer> jam: Perhaps just a setting in .bzr/checkout/checkout.conf that gets autoset upon checkout creation?
<vila> jam: you can't have a wt on a readonly fs and run into the problem geekosopher is mentioning (IIUC)
<jam> unversioned are files that exist, but have been marked for removale (such as with 'bzr rm')
<jam> vila: I can do the checkout onto vfat, and you can run bzr st
<jam> and you'll very likely have the problem
<jam> because vfat only has 1 global user and group
<jam> for the whole mount
<jam> because linux fakes it
<vila> jam: but that's not readonly then
<jam> vila: it *is* readonly for you
<jelmer> jam: We could rely on the fact that vfat always sets +x, and we never normally set it on e.g. .bzr/format, but that is.. dubious
<jam> jelmer: right, a setting that gets set during a write operation would be ok for me
<jam> jelmer: it doesn't, it sets the files to whatever you set in /etc/fstab
<jam> I think the default includes +x
<jam> but I often reset it to 0644
<jam> because I don't want everything to be +x
<jelmer> ah, I didn't realize you could override it
<jam> user, group, mode bits are all mount-time flags
<vila> jam: right, but that's not what geekosopher is encountering
<jam> jelmer: https://code.launchpad.net/~dmitrij.ledkov/bzr-keywords/more-keywords/+merge/23626 are you just proxying for him?
<vila> jelmer: the problem with a setting in a conf file is that it won't be updated if the whole tree is copied on a different fs (well, until the next update...)
<jam> vila: my point is that there are a lot of remaining edge cases
<jam> doing it 1 time during "initialize()" would handle a lot ofthem
<jam> doing it during mutating operations would handle most of the rest
<jam> so "bzr revert" could detect it.
<jelmer> jam: I don't think I follow, I was just commenting on the MP.
<jam> jelmer: I got an email "You have been requested to review the proposed merge of ..." with your name on it
<jam> I was trying to figure out wether you were proposing it for him, or what
<jelmer> jam: ah
<jelmer> I added bzr-core as reviewer, as Ian was previously the owner of lp:bzr-keywords
<jam> jelmer: https://code.launchpad.net/~jelmer/bzr/blackbox-upgrade-formats/+merge/51297
<jam> for that one, I approved, but didn't look too closely
<jam> I assume it is the same tests, just switching to knits, and adding one that upgrades from a fake format
<jelmer> jam: Yeah, though changing the existing one that tested upgrading from a non-metadir format to a metadir format rather than adding a new one.
<vila> jam, jelmer: Except for my huge mail backlog, are there events/decisions I should be aware of ?
<jelmer> jam: There were already tests for e.g. just repository format upgrades
<jelmer> vila: not that I recall
<jam> vila: poolie was gone 2 weeks ago, and is gone again this week, so not a lot of big policy decisions going on
<jam> We have a couple "Critical" bugs now, poolie was kind enough to set one and then leave :)
<jam> I'll probably work on the repack inventories one soon.
<jam> Just trying to finish getting my launchpad+loggerhead stuff flushed out of the pipe, first
<vila> ok, thanks for the summary !
<jam> jelmer: I'm getting OOPS trying to send email to launchpad. I'll try to submit to you directly.
<jelmer> jam: ok
<jam> jelmer: I think that is everything except for the repository_vf check_reconcile tests
<jam> I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos.
<jam> so it sounds more like some missing abstractions.
<jelmer> jam: Thanks!
 * maxb grimaces at python-central deprecation notice
<maxb> that's going to make PPA builds fun
<jelmer> jam: All of our current reconciliation seems specific to VersionedFiles, so while I think reconcilation would apply to e.g. Subversion repositories it would be for completely different issues.
<jelmer> maxb: Yeah - for everything except Natty (and Maverick?)
<maxb> I wonder if we drop Hardy support once Natty is out. It'll be at partial-EOL state then (server only0
<maxb> Still, someone probably still wants bzr core for it
<jam> maxb: so is that python-central vs python-support?
<maxb> python-central vs. dh_python2
<jam> which itself was from python-support way back when
<maxb> the latter being something new that I have not learnt about yet
<jam> something like dapper
<jam> which did, indeed, cause some large headache in its time
<jam> lovely we get to revisit them
<jelmer> at least we now have a single python module support mechanism rather than 2
<kyleN> Hello. I seem to have a lock file on LP that prevents me from pushing a branch. Can anyone assist me?
<kyleN> I have tried bzr break-lock locally before pushing and running it with a bzr+ssh:// url to the server branch. still cannot push.
<Peng> It's always possible someone really is using the branch, of course.
<Peng> If not, "bzr break-lock bzr+ssh://..." should take care of it.
<kyleN> it has been locked since Saturday and I think I am the only one working on the branch right now
<vila> jam: why is bug #716777 against bzr ? Did you mean loggerhead or history-db instead ?
<ubot5> Launchpad bug 716777 in Bazaar "history-db should handle OperationalError: database is locked" [Critical,Confirmed] https://launchpad.net/bugs/716777
<jam> vila: it should be against loggerhead, yes
<jelmer> jam: did you have any thoughts on the per_repository_vf MP?
<jelmer> (the one that is a prerequisite for the check_reconcile MP)
<jam> (3:00:52 PM) jam: jelmer: I think that is everything except for the repository_vf check_reconcile tests
<jam> (3:01:11 PM) jam: I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos.
<jam> (3:01:19 PM) jam: so it sounds more like some missing abstractions.
<jam> maybe I missed a patch in there, though
<jelmer> jam: I mean https://code.launchpad.net/~jelmer/bzr/per-repository-vf/+merge/51150 rather than https://code.launchpad.net/~jelmer/bzr/per-repository-vf-reconcile/+merge/52283
<jam> jelmer: locally, the diff is empty
<Peng> /1/6
<jam> but seems to be populated in the web ui
<Peng> eep
<jelmer> Peng: Hi :) Or whatever the proper response to that is :)
<Peng> The peroper response is "Peng, learn how to type your aliases properly!"
<Peng> Hi, but I was just checkin' IRC before giving the laptop -- and maybe myself -- some sleep. Bye. <3
<jelmer> g'night
<jam> jelmer: It seems ok, but since you aren't removing any tests, I'm not really sure what it is getting you. Just the precursor to moving stuff over?
<jam> the config is all correct
<jelmer> jam: It's moving a couple of tests to per_repository_vf, so those will no longer run against bzr-svn/bzr-git/bzr-hg
<jam> jelmer: there are no '-' lines that would indicate that
<jam> at least, that I can see
<jam> certainly it does add some tests
<jam> but none are removed from elsewhere to be "moved"
<jam> anyway, time to pick up my wife. I *think* things are ok, but I think I also need to think about implications in the long term.
<jam> I'm a bit worried about us expecting new functionality is working, only to have the tests not testing against all implementations they should be, etc.
<jelmer> jam: Those tests need to be moved rather than copied, I'll update the MP.
<jelmer> jam: That's one of the reasons I've added the format attribute tests and made the format attributes default to None, so format implementations explicitly have to indicate whether they support something.
<jelmer> I'm not sure what to do about code that relies on functionality that is a part of the VersionedFileRepository API but not of the smaller Repository API, it would be nice to somehow check that sort of thing.
<jelmer> s/it would be/I agree it would be/
<tgall_foo> users of bzr-git  :  what's the syntax to pull from a branch of a remote repo (IE from other than master)
<jelmer> tgall_foo: That's not possible at the moment, as there's no UI in Bazaar for addressing colocated branches
<jelmer> It's high on my todo list to finish that work. In the mean time, you can import all branches in a repository using "bzr git-import"
<tgall_foo> thanks jelmer
<tgall_foo> jelmer, followup,  I guess I was expected bzr git-import then to do an effective bzr branch for all the remote git branches..   after the bzr git-import least down the new refs directory it's empty
<jelmer> tgall_foo, it creates workingtree-less branches
<jelmer> tgall_foo, try running "bzr log" in one of them
<jelmer> tgall_foo, you can pull from them, or create a working tree by running "bzr checkout ."
<tgall_foo> thanks jelmer
<teamgbc> hey all
<jelmer> hi teamgbc
<teamgbc> i'm new to bzr
<teamgbc> and i want to do something simple, but for i'm having trouble
<teamgbc> i got bzr installed on 2 machines.... and one is supposed to be server
<teamgbc> but i can't connect ( get a project source) from the server
<teamgbc> i'm reading through some documentation, but i'm getting lost in the links
<teamgbc> i've gone through the setup tutorial
<teamgbc> when i do bzr push --create-prefix sftp://localhost/teamgbc/
<teamgbc> i get bzr ERROR not a branch '/home/teamgbc/"
<teamgbc> just wondering if there is some tutorial somewhere
<teamgbc> that exists for almost complete newbies
<jelmer> teamgbc, have you seen http://doc.bazaar.canonical.com/bzr.dev/en/?
<teamgbc> i guess i was thinking that i placed the trunk inside var/www
<teamgbc> if i, i should be able to access the files via http...
<teamgbc> Jelmer, yup i've gone through it a little, and ended up starting it all with bzr explorer
<teamgbc> and followed the tutorial for that
<teamgbc> i guess i should just start over eh?
<jelmer> sorry, distracted there for a bit
<jelmer> teamgbc: pushing to sftp://localhost/teamgbc/ will push to /teamgbc on your local machine
<teamgbc> so how am I supposed to reach my server then?
<teamgbc> i'm going to go back through the initial tutorial and do everything via the command line
<teamgbc> then i'll come back if i have issues, better than waste anyone's time
<jelmer> teamgbc: well, localhost is your local machine :)
<teamgbc> cheers jelmer, much appreciated
<teamgbc> sorry
<teamgbc> haha
<teamgbc> i mean i was trying /192.168.1.107
<teamgbc> which is the server in the local network
<jelmer> teamgbc: it'll push to the /teamgbc directory on that machine, are you sure that's where you want to push?
<teamgbc> interesting, no, that doesn't make much sense
<teamgbc> hah
<teamgbc> ok, i'm going to run through the command line tutorial.  I though the GUI would be easy enough to just create the trunk in a specified directory
<teamgbc> and then type in that director location in the remote machine
<teamgbc> to access the source or  open the remote location
<teamgbc> thanks jelmer
<dpm> hey jelmer, around?
<jelmer> dpm: Hi David
<dpm> jelmer, thanks a lot for merging my branch
<dpm> I was wondering if you've got a few minutes if we could set up translations in the LP project
<jelmer> np, thanks for adding i18n support in the first place
<jelmer> dpm: Sure
<dpm> ok, cool, so it's basically here -> https://translations.launchpad.net/bzr-gtk/+configure-translations . The first thing is to set permissions, focus, and a couple of other things. My recommendations:
<dpm> * Launchpad
<dpm> * trunk
<dpm> * launchpad-translators
<dpm> * Restricted
<jelmer> what's the difference between Launchpad and Ubuntu translators?
<dpm> The reason I suggest to assign it to the Launchpad Translators group is simply because bzr-gtk is not an Ubuntu-specific project, so Launchpad Translators makes more sense
<dpm> they are simply two translation groups
<dpm> a translation group contains translation teams, one per language
<dpm> and they take care of translating particular projects
<dpm> Launchpad Translators is an umbrella for translating any project hosted in Launchpad for translation
<jelmer> ah, ok
<dpm> Ubuntu Translators, the same, but for any project specific to Ubuntu, or for the distro itself
<jelmer> Thanks - I've configured that page with the settings you suggested
<dpm> cool, let me see what the next step is, probably translation imports
<dpm> ah, yeah, imports for the trunk branch
<dpm> So here: https://translations.launchpad.net/bzr-gtk/trunk/+translations-settings I'd suggest simply choosing "Import template files"
<dpm> That will import the bzr-gtk.pot template in the branch and expose it in the UI every time you update it and commit it
<dpm> I'd also recommend updating it and committing it at least a few days before a release, so that translators see the latest strings and have time to translate it
<dpm> (but that's got nothing to do with the settings, just a suggestion)
<jelmer> dpm: done
<dpm> cool thanks, so now for the final step: automatic exports, to get translations committed automatically to a branch of your choice
<dpm> You simply have to choose the branch where you want them committed here: https://translations.launchpad.net/bzr-gtk/trunk/+link-translations-branch - you can have a separate branch (if you want to keep it separate and merge it back to trunk regularly) or the main branch (if you just want to let LP do the right thing and forget about committing translations, and if you don't mind having automatic commits in the tree)
<dpm> * A caveat: you might hit bug 407260 when trying to choose the branch, but it's got an easy workaround: "At the moment, team-owned branches don't work as expected. To work around this, make yourself the owner of the branch, set it as the translations branch, and then make the team the owner of the branch again."
<ubot5> Launchpad bug 407260 in Launchpad itself "Translations export branch can't be team-owned" [High,Triaged] https://launchpad.net/bugs/407260
<jelmer> hmm
<jelmer> for the moment I'm more comfortable with a separate branch
<dpm> sure, just laying out the options. You should choose the workflow that best suit your needs
<dpm> suits
<jelmer> dpm: Cool - set
<dpm> then I think we're all done \o/
<dpm> I'll be testing it in the next few days, thanks!
<jelmer> you - thanks for adding i18n support to bzr-gtk :)
<jelmer> s/you/you too/
<dpm> no worries, my pleasure :)
<jelmer> dpm: I guess it's still an issue that bzr itself doesn't support i18n? I.e. errors and warnings may come directly from bzr
<dpm> oh, yeah, I hadn't thought of that. I'd be happy to help on that as well, but I'm not sure there are any plans to i18n'ize bzr?
<dpm> Has this ever been discussed at all?
<jelmer> I'm not aware of any. There's an open bug somewhere..
<dpm> At least SVN is internationalized, we could aim to beat that as well :)
<jelmer> https://bugs.launchpad.net/bzr/+bug/83941
<jelmer> with a comment from myself from 2007 :)
<jelmer> it's been discussed offline a couple of times. From what I recall the main concern is that adding i18n support should not have a performance impact
<jelmer> blindly gettexting all strings that might be user visible will add a significant overhead, as some of those get raised pretty often but are then not shown to the user
<jelmer> it's not impossible but needs some thought
<dpm> yeah, that's what I thought that'd be the main concern. AFAIK, gettext is really fast, so I don't think it should incur a performance drop, but only tests can tell
<dpm> well, I'll be happy to have a go at it and submit a MP for i18n'izing bzr itself, and then you guys can have a look.
<jelmer> that'd be awesome
<dpm> I don't know when though, but I'll definitely look into it
<vanguard> is there some way to save push/merge locations with a name like "origin" like one can in git?
<jelmer> I think the bzr-bookmarks plugin is intended to work like that
<vanguard> jelmer: k, I'll check it out
<vanguard> can I check out some revision without loosing everything after that revison?
<maxb> sure
<LeoNerd> The version that a checkout is at doesn't have to be the head revision in a branch...
<vanguard> LeoNerd: So I do it the same way as in git, with a checkout command?
<LeoNerd> bzr co -r123
 * LeoNerd dosen't know git
<LeoNerd> I find it odd... people in here asking abuot git, people in #vim asking about emacs...
<LeoNerd> You can't just presume that people in #{$TOOL} would understand references to $OTHERTOOL  :)
<vanguard> LeoNerd: People asked about some distro in #kubuntu ... that is the way it works. And where should I go if I want to get optinions from people who have experience with bzr and git?
<LeoNerd> Ah, well one -and- the other, is a different problem again
<jasonlife> How can I update my module to a old revision ?  "bzr update -r xxx" doesn't work..
<maxb> jasonlife: doesn't work?
<jasonlife> yes..
<maxb> explain
<jasonlife> after I do this, I just checked revno, but it is still same..
<jasonlife> "bzr  revno" show the same as before
<jasonlife> and bzr log shows all the logs too..
<maxb> please pastebin a transcript of the commands and responses
<jasonlife> maxb: so, "bzr update -r xxx" should work.. right?
<maxb> yrs, it should
<maxb> yes, even
<jasonlife> I will try this again and I will paste them again..
<jasonlife> ok.. thanks..
<maxb> though it's a relatively new feature
<maxb> what is your bzr version?
<jasonlife> oh
<jasonlife> 2.1.0
<mtaylor> given two branch urls, is there an _easy_ way to determine if one is contained within another?
<jasonlife> "bzr --version" shows 2.1.0
<jasonlife> it happens on both 2.1.0 and 2.1.1
<jasonlife> when I run "bzr update -r xxx" , it actually revert the files to old revision, but "bzr revno" and "bzr log" shows the current revno and logs..
<knighthawk> help I'm trying to prevent having to go back to svn. My team has been adapting pretty well to bzr however we have 3 party programmers who aren't used to bazaar and are running into major problems. at the heart of my problems is that they are using eclipse and the eclipse plugin doesn't seem to work all that well.
<knighthawk> I guess I'm looking for idea's on the best way to handle this. (I don't want to go backwards) but I may have to set something up so that the 3rd party can use subversion. I keep hearing about a svn-bzr bridge will this help me any?
<knighthawk> how hard is it to move a bzr repo over to hg?
<beuno_> knighthawk, pretty easy
<beuno_> there's a bzr-hs plugin
<beuno_> *bzr-hg
<beuno_> and there's fastimport, which is probablt best for a one-time import
<knighthawk> thanks. I don't really know hg but it looks like if I switch now. I might be able to keep all the things I like about bzr and use their eclipse plugin.
<jelmer> bzr-hg isn't really useful for bzr->hg, only for hg->bzr
<fullermd> jasonlife: 'bzr revno' shows the revno of the _branch_; 'update' affects the _working tree_.  Try 'bzr revno --tree'.
<jasonlife> fullermd: thank you very much
<jelmer> lifeless: hi
<lifeless> hi
<jelmer> lifeless: I've been meaning to move get_{branch,workingtree,repository}_transport from ControlDir to BzrDir, as they don't really make sense for foreign formats.
<jelmer> lifeless: Do you think that would that make sense? John mentioned you might have had another goal with them other than using them for metadir component initialization / opening.
<lifeless> I have no idea
<lifeless> check plugins all work as part of your pre-proposal-qa, and I'm sure you'll find any issues
<jelmer> lifeless: of course
#bzr 2011-03-08
<methods> can i do partial commits ?
<methods> of a file
<mwhudson> methods: i think there is a plugin, bzr-interactive, that lets you do that
 * mwhudson afk for a spell
<chx> hi. i am trying to find documentation on bzr-git but there is not much. how would you check out http://drupalcode.org/project/drupal.git/log/refs/heads/6.x this branch?
<chx> nevermind
<jelmer> 'morning
<bialix> mgz: are you here?
<bialix> hi all
<mgz> morning bialix.
 * fullermd waves at bialix.
 * bialix waves at fullermd :-D
<bialix> morning mgz
<bialix> mgz: can you refresh my memory about standalone bzr.exe: if it don't want to start because of missing msvcrxx.dll then one needs to install redist package from microsoft, right?
<mgz> yes, though we still need to work out exactly what circumstances that happens in so we can fix it properly
<mgz> so far, we've had a bug report from someone on win2000, and one from someone on server 200..8?
<bialix> I have something similar on XP machine
<mgz> this is unhappy, xp should really work.
<bialix> what redist package I need? for which VS? 2005 or 2008?
<bialix> that's not on my own computer< I'm trying to help other man
<mgz> python 2.6 builds against 2008... I'd need to look up the exact minor version of the dll it needs.
<mgz> just uninstalled my all-in-one bzr copy annoyingly
<bialix> on the microsoft site there are simple redist and sp1
<bialix> I suspect I need plain one
<mgz> that's what I remember.
<mgz> (the normal one, not sp1)
<bialix_> ok, I'll try that
<Manikandan1> bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 111] Connection refused
<jelmer> garr, I keep trying to do things only to find out maxb has already done them in the last 15m
<fullermd> The obvious solution is to sneakily reset his clock...
<jelmer> I was considering getting up 20 minutes earlier, but I guess that works too :)
<maxb> :-)
<maxb> I'm not entirely sure getting up has anything to do with it, considering I'm still in bed
<vila> LOL
 * bialix waves ta vila
 * vila waves to all :D
<jam> hi all
<jelmer> MoggÃ»h John :)
<jam> jelmer: huh, it always sounds more like "Morgen", but hey, I'm still trying to figure out the pronounciation of Dutch words.
<jam> Waalre ==> valgre
<jam> etc.
<vila> nexuiz-data still running on jubany... no significant output in logs/nexuiz-data either... weird
<jam> vila: from how long?
<vila> since 2011-03-01 20:23 utc
<jam> anyone have a feeling about how far back I should port 437003
<jam> bug 437003
<ubot5> Launchpad bug 437003 in Bazaar "Failure to autopack because of 'missing inventories'" [Critical,Confirmed] https://launchpad.net/bugs/437003
<jam> I was thinking 2.2, but I'm open to suggestion
<vila> spiv's fix was backported to 2.0 no ?
<jelmer> jam: It varies, this is the Hague dialect
<vila> jam: is there significant problems if you target 2.0 ?
<jelmer> it would be nice to get it into 2.0
<vila> s/is/are/
<jam> vila: my whole world crashes
<jam> unfortunately
<jam> but I'll see what I can do :)
<vila> jam: I think the main issue is that people keep running into it (I think there was yet another report since yesterday), so if we can target 2.0, we are better prepared to deploy it for all users involved (modulo poolie being able to SRU 2.3/2.2/2.1/2.0 ...)
<vila> jam: huh ? :D
<jam> I'm not 100% sure how stable the code in this area has been since 2.0, it was quite a while ago...
<jam> vila: just being silly. I can probably do 2.0 just fine
<vila> :)
<jam> since we aren't SRUing back that far by default, it didn't seem important
<jam> but I can do it
<vila> I still hope we will be able to SRU 2.0 once we sort out the other ones
<jam> what still has 2.0 that is under SRU, though?
<jam> hardy?
<vila> jam: but if you want to start with 2.2, you could still look at backporting if needed
<vila> jam: hardy is 1.3, but lucid is 2.1
<vila> karmic is 2.0.. so we may never SRU there...
<maxb> I can't see why we would backport anything further back than 2.1, at this point
<jam> maxb: because we rock!
<jam> mostly because that is where the bug started, and we may as well fix it there, rather than backporting
<maxb> well, if it doesn't incur any extra effort, good
<fullermd> See, if you'd just gotten jelmer to do it instead, maxb would have had it done 15 minutes ago   :p
<maxb> but, if we don't know of any extant distribution that would make use of it, there may be no point (unless it's essentially free to start fixing in 2.0)
<jam> maxb: at *this* point, it looks essentially free
<jam> we can always land and not release
<jam> or skip landing
<jam> etc
<jam> vila: care to discuss the fix. I have 2 options
<jam> 1) See that we have the inventories in another pack file and stop there
<jam> 2) Go ahead and pull those inventories, which will also require pulling in the associated chk bytes pages
<jam> I like the idea of having things all together when reasonable.
<jam> But it does feel a bit like chasing the rabbit down the hloe
<jam> hole
<jam> note that we *don't* pull in the associated texts
<jam> see line 452 of groupcompress_repo.py
<jam>         # XXX: We don't walk the chk map to determine referenced (file_id,
<vila> I don't know enough about the details, but I share the feeling that things should stay together
<vila> jam: if the bug (as it seems) is really confined to autopack (a reproducing test would be nice) then (1) seems to be the way to go no ?
<vila> jam: or does it also occur in weird stacked scenarios ?
<jam> vila: it is the minimally invasive form, yes
<jam> vila: it seems to be *caused* by stacking
<jam> but not in the "weird stacking scenarios" sense.
<vila> I ~see
<jam> In normal fetches, we always send the inventory with the revision, so there would be no reason for them not to be in the same pack file
<jam> but with stacking, we may send inventories for revisions we don't send
<jam> also, the suspend/resume features end up creating multiple pack files for one logical pack
<jam> sorry logical  fetch
<vila> is it a case where some constraints should be relaxed while the logical fetch is processed or do we end up we several pack files ?
<jam> vila: we end up with several pack files.
<jam> suspend writes it to disk
<jam> in the uploads dir
<jam> resume marks it for final inclusion in the 'packs' directory
<vila> and they get repacked before inclusion in the 'packs' directory as one pack file ?
<jam> vila: no
<jam> they just get renamed into place
<jam> often the first push is huge
<jam> and the second is small
<vila> hmm
<vila> jam: I don't quite get how we end up with missing inventories when we "may send inventories for revisions we don't send"...
<vila> and what do you call revisions in this context
<jam> vila-afk-lunch: still there?
<jam> ping me when you get back
<vila-afk-lunch> jam: I will
<jdobrien> is there a way to change the pull location of a branch you have pushed to LP so bzr pull will just get it from LP without having to specify the location?
<jam> jdobrien: bzr pull --remember ?
<jdobrien> jam? how will that changed the pull location
<jam> jdobrien: bzr pull --remember lp:the-new-place
<jdobrien> ahh
<jdobrien> jam thanks!
<jdobrien> jam I was looking everywhere but there :)
<jam> jdobrien: happy to help
<jelmer> would "bzr config push_location lp:the-new-place" also work nowadays?
<jam> jelmer: I think you need at least an "=" in there
<jam> it also would end up using 'lp:' each time, and not the expanded url
<jam> not sure what else
<jam> would differ
<jelmer> jam: ah, right
<jam> so yes, *but* :)
<jelmer> id=4, tests=34971, failures=2363, skips=3794
<jelmer> getting close to that 35k mark :)
<jelmer> http://samba.org/~jelmer/bzr-alltests.html
<jam> jelmer: that is running against all plugins, or what?
<jelmer> jam: Against a lot of the plugins: bisect  builddeb  builder  bzrtools  cia  cvs  dbus  email  explorer  fastimport  git  grep  gtk  hg  keywords  loggerhead  loom  mtn  pipeline  pqm  qbzr  search  service  svn  upload  webdav  xmloutput
<jam> jelmer: mtn? I didn't think the models would be close enough to actually be supported.
<jelmer> jam: the mtn module is as trivial as the bzr-cvs plugin
<jelmer> ie it just installs a Prober and tells you "please try mtn fast-export and bzr fast-import" if you try to open
<jam> interesting
<bob2> hah
<vila> jam: back
<jam> (11:55:42 AM) vila: jam: I don't quite get how we end up with missing inventories when we "may send inventories for revisions we don't send"...
<jam> we'll start from there
<jam> Example, Revisions A, B, C, D
<jam> A B C are in the base repository
<jam> D is in the target repository
<jam> "stacked"
<jam> if D is in the stacked repo, then so is the inventory for C
<jam> Say we push this somewhere else that only has A B
<vila> jam: because it's the parent ?
<jam> vila: right
<jam> A => B => C => D
<jam> If we push to somewhere that has A B
<jam> then we will send D rev+inv, C inv. Then suspend, then resume and send C rev
<jam> At which point D + C's inventory are in one pack file, but we may do an autopack just involving C's rev pack
<jam> vila: https://code.launchpad.net/~jameinel/bzr/repack-missing-inventories-437003/+merge/52544
<jam> If you want a semi-hackish way of triggering the condition
<jam> also, vila, did we decide to copy NEWs entries when doing stable updates to multiple releases?
<jam> I'm always unsure about the state of that
<vila> we stopped duplicating NEWS entries
<jam> since we may or may not do releases in sync anymore, I was thinking to copy the entries
<jam> Notably, 2.0.7 may never see the light of day
<vila> the RM should ensure that any release includes fixes from lower series
<jam> I *didn't* like it when I was releasing 3 branches simultaneously every month
<vila> that is, the fixes known when releasing
<jam> but  I'm pretty sure we've backed off on that
<vila> yup
<vila> what I do (as RM these days) is ensuring that lower series have been properly merged up
<vila> there is one merge that is a bit trickier (can't remember if it's 2.1 or 2.2) where you had to make sure you don't include irrelevant news entries
<vila> jam: "The test also isn't a permutation test. It might apply vs most Pack based repositories, but I can't guarantee it."
<vila> jam: how hard would it be to dig a bit more there ?
<jam> vila: harder than I feel is warranted
<jam> vila: especially for a backported fix
<vila> jam: which means 0.92 can still exhibit the bug ?
<jam> I could possibly be convinced otherwise for newer releases
<jam> vila: you mean format 0.92? Uses very different logic
<vila> Oh ! Right
<jam> doesnt try to match Inventories to Revisions
<vila> I'd be fine with a permutation tests for 2.4 only
<vila> hmm
<vila> so you mean only 2a is really affected then ?
<jam> vila: by that specific bug? yes
<vila> jam: great
<jam> at least, I think so
<vila> already approved
<jam> its the only one that really matters, anyway :)
<jam> the bigger question is what happens when 3a comes out
<jam> but since that is indefinitely postponed...
<vila> which means we need some way to express that a test apply to a set of formats
<vila> jam: if you could put these tests in a dedicated class with a comment explaining the issue that would be awesome to start with
<vila> well, they already are :)
<jam> vila: any other comments you want to take back?
<vila> :)
<jam> self.fail() seems sufficient to say "this should never happen"
<vila> yeah, could be
<vila> yeah, got a bit scared by the size of the test at first
<jam> understandably
<jam> I tried to make sure the bulk of things were in "make" helpers
<jam> so you could clearly see it was complex because of setup
<jam> not because of assertions
<vila> I think for such bugs you can't avoid having a complicated setup
<vila> yup
<jam> and I made sure to re-use those helpers for some extra testing
<jam> like real-missing inventories, etc
<vila> yup, may be my "nice tdd there" didn't express enough congratulations :)
<vila> but it's a nice piece you put there
<jam> well, some of it was TAD, but I did make sure to trigger the failure before fixing it.
<vila> A == After ?
<vila> D == before then :D
<jam> Test After Development. I did the first test TDD, I did the "but make sure it still fails when it must" afterwards.
<jam> especially for bugs, I tend to do close to TDD
<jam> since I have something I want to reproduce
<jam> for dev work, it varies, because I don't always know what I'm looking for right away
<vila> yeah, the usual argument ;)
<jam> and I've had a lot of trouble trying to work out performance related fixes and testing
<vila> I don't really buy it because I  successfully TDDed on several exploratory works, it means more test refactoring but also gives me more confidence about test coverage
<vila> jelmer: reagrding bug #713240
<ubot5> Bug 713240 on http://launchpad.net/bugs/713240 is private
<vila> O_o
<jelmer> I can't access that page
<jelmer> ah, neither can ubot5 :)
<vila> jelmer: regarding bug #731240
<ubot5> Launchpad bug 731240 in Bazaar Hg Plugin "opening over http in dumb mode fails in selftest" [Medium,Triaged] https://launchpad.net/bugs/731240
<vila> that's better (first typo after more than a work day and a half... something weird is going on ;)
<vila> jelmer: our HTTP test server supports range requests, not sure what is going on here
<jelmer> hmm, that's odd indeed
<vila> jelmer: and which test is failing ? I can't reproduce locally with bzr-hg trunk and -s bt.per_branch.test_branch
<vila> jelmer: ha, lazy loading and --start-with interfering ?
<jelmer> I guess so
<jelmer> It should be bzrlib.tests.per_branch.test_branch.TestBranch.test_open_containing
 * vila scratches head, even 'bzr selftest bzrlib.tests.per_branch.test_branch' (aka without -s) 
<vila> hmm, *really* installing the plugin may help
<vila> indeed
<vila> you mean bzrlib.tests.per_branch.test_branch.ChrootedTests.test_open_containing ?
<jelmer> Ah, yes
<jelmer> wtf, BzrBranchFormat4 can be used in a metadir?
<vila> jelmer: bug #731240 is a bug in the bzr HTTP test server ;)
<ubot5> Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,In progress] https://launchpad.net/bugs/731240
<jelmer> vila: ooh, nice catch :)
<vila> painful to track down and quite surprising, but as I commented in the bug report, it's still valid
<vila> well, painful... because I didn't know the bzr-hg and hg internals to be honest
<jelmer> ah
<jelmer> jam: do you know if it's intentional that BranchFormat4 also works in meta dirs?
<jelmer> well, s/works/can be initialized/
<vila> jelmer: hehe, look at this (http_server.py line 149): # FIXME: RFC2616 says end is optional and default to file_size
<vila> *He* knew it !
<jam> jelmer: there was a meta-dir version before knits, IIRC
<jam> so yes, it was intentional
<jam> I'm pretty sure there was a *very* short lived Weave metadir
<jelmer> jam: it doesn't have a get_format_string() implementation though
<jelmer> jam: so it's write-only
<jam> odd
<jam> That would be repository Weave anyway
<jam> the Branch wouldn't matter
<jam> jelmer: if it is write-only, then there is no reason to support it
<jam> since it couldn't be read
<jelmer> ok
<jelmer> a couple of tests seem to rely on the existing behaviour, but they don't reopen branches after they've been created
<jam> jelmer: then my guess is that it is an accidental by product of permutations and isn't meant to work
<jelmer> jam: you mentioned yesterday you were happy to see https://code.launchpad.net/~jelmer/bzr/blackbox-upgrade-formats/+merge/52275 land ?
<jam> jelmer: yes
<jam> must have been one of the rejections I didn't catch
<jam> marked approved
<jelmer> jam: thanks !
<vila> jelmer: NameError: global name 'RemoteHgBranchFormat' is not defined
<vila> jelmer: can you stop some typo there ?
<vila> jelmer: or tell me where it's defined ?
<jelmer> vila: fixed
<vila> jelmer: in trunk ?
<vila> indeed
<vila> then I've got a fix for #713420
<vila> pffft
<vila> bug #731240 (double tyop above, triple if you count the missing 'bug' ;)
<ubot5> Launchpad bug 731240 in Bazaar "opening over http in dumb mode fails in selftest" [Low,In progress] https://launchpad.net/bugs/731240
<jelmer> vila: hmm?
<jelmer> ah
 * jelmer finishes reading through ~2k failing tests
<vila> jelmer: here is the mp: https://code.launchpad.net/~vila/bzr/731240-range-parsing/+merge/52573
<jelmer> I've filed bugs for all the different issues I've encountered, most failing ones are due to missing VersionedFiles.add_lines() implementations though
<vila> jelmer: hehe, that's far too much, better fix the most important one first :)
<jpds>  /go #pse
<jelmer> vila: \o/ I'll have a look
<vila> jelmer: what ? you need to read them all to find the most important one ? Where is your crystal ball ?
<jelmer> vila: I wish the test suite could tell us ;-)
<jelmer> 5 FAILURES (1 severe, 2 important, 2 minor)
<vila> hmm, good idea !
<vila> jelmer: here is the mp for that:  https://dreamcode.launchpad.net/~vila/bzr/731240-range-parsing/+merge/52573
<vila> err
<vila> jelmer: here is the mp for that:  https://dreamcode.launchpad.net/~vila/bzr/1-dwim/+merge/42
<jelmer> hehe
<jelmer> vila: is "bytes=-" allowed?
<vila> no, let me test that :)
<tacone> may any good soul remind me how to create a prefix like lp: ?
<jelmer> vila: there are two spaces in this line: +        self.req_handler =  RequestHandler(None, None, None)
<jelmer> tacone: It's a DirectoryService, you can register a custom one in a bzr plugin
<vila> jelmer: blame my shaking hand ;)
<tacone> urgh. do i have to distribute a plugin to all my devs ? :)
<vila> tacone: better than asking them to *write* one ;)
<tacone> villa: +1
 * tacone mispells nicknames
<vila> np
<tacone> any other way to shorten a sftp long url ?
<jelmer> tacone: Well, you'll have to get *something* to them
<vila> tacone: can you elaborate a bit about what kind of aliasing you're after ?
<jelmer> perhaps bzr-bookmarks can be used for this sort of thing?
<tacone> maybe, i'm looking it up right now, is it in the repos ?
<vila> the subject comes back regularly enough that we may investigate how to generalize *something* to the point where you could use it via some configuration
<vila> tacone: yes... lp:bzr-bookmarks ;)
<jelmer> tacone: There aren't any packages, if that's what you mean
<tacone> ok
<jelmer> who is ADHB?
<vila> jelmer: abentley
<vila> jelmer: what is easier in the hg config API ?
<abentley> jelmer: Hi.  Aaron David Heuer Bentley here.
<jelmer> abentley: Ah, it's you!
<vila> Heuer and Bentley, talk about a luxury name ;D
<jelmer> vila: the API doesn't confuse me in Hg :)
<abentley> vila: :-)
<vila> jelmer: haha, ok, but that doesn't tell me much ;)
<vila> jelmer: as in : I'd like our new config API to be easy for users and devs alike, so all inputs are welcome and... now is a good time ;)
<tacone> is still Olive the supported GUI ?
<vila> well, it's hard to say that there is *a* supported GUI
<jelmer> tacone: qbzr/bzr-explorer are probably a better choice at the moment
<vila> Olive has been spun off from bzr-gtk, bzr-explorer was intended to support both gtk and qt but has been adopted by the qbzr devs. There seem to be more interest in qbzr than bzr-gtk but both projects are still active, Olive... is a different matter and could certainly benefit from some love...
<tacone> i'm taking a look to bzr-explorer, thanks
<vila> jelmer: is https://code.launchpad.net/~jelmer/bzr/weave-plugin/+merge/51301 still reviewable ? (You mentioned BranchFormat4 a bit earlier)
<jelmer> vila: sortof.. I'm splitting it up further to make it more reviewable
<vila> jelmer: ok
<jelmer> vila: review of https://code.launchpad.net/~jelmer/bzr/branch4-no-metadir/+merge/52575 would be great though :)
<vila> jelmer: I'm on https://code.launchpad.net/~jelmer/bzr/per-repository-vf-reconcile/+merge/52283
<jelmer> vila: ah, cool
<jelmer> vila: I'm not sure I understand your comment on per-repository-vf - the scenarios should be applicable for all files in this directory
<vila> jelmer: when poolie introduced the .scenarios attribute, the idea was to reduce the distance between the test classes and the parametrization
<vila> jelmer: in your case, ISTM, the distance is too big
<vila> jelmer: if the scenarios needs to be shared, I don't have a problem leaving them in __init__, but they can still be referenced from the scenarios attribute
<vila> jelmer: if they are *not* shared, then I would prefer for them to *not* be in __init__ (for the other submission)
<vila> jelmer: and when I reviewed the first mp, there was only 1 file in the dir ;)
<jelmer> vila: What do you refer to by scenarios attribute here specifically?
 * jelmer suspects there's a concept he's missing here
<vila> jelmer: see test_http.py for examples
<vila> jelmer: yeah, it's possible you didn't see poolie's work there, it still has to be fully deployed
<jelmer> I inspired my existing code by bzrlib.tests.per_repository
<vila> jelmer: grep for load_tests_apply_scenarios
<vila> jelmer: roughly: the idea is to define an attribute on the test class instead of defining a specific load_tests function
<vila> jelmer: the implementation proposed by poolie has been working pretty well so far
<jelmer> there will be a lot of scenarios in this case though, in multiple files
<jelmer> vila: Do you mean just setting "scenarios = all_repository_vf_format_scenarios()" on each of these classes?
<vila> jelmer: right, I haven't into the details and maybe your proposal is good enough to land, but if you could have a look at this new organization I've got the feeling that the parmetrization could be clearer
<vila> jelmer: may be, may be not, a common base class could work too, I don't remember if you could easily redefine (and enrich) for a daughter class
<vila> jelmer: as said above, there was only one file for the first mp hence my comment
<vila> jelmer: for the second mp, if the scenarios are not reused elsewhere then put them in the file that use them
<jelmer> vila: fair enough
<vila> jelmer: mainly the scenarios attribute helps putting the scenarios closer to the tests that use them which is the main point of my comments
<smthomas> does anyone know if it is possible to allow one version controlled branch inside another version controlled branch? I have a folder structure like /modules and /modules/abc in which I would like to keep the abc a separate branch but also commit the entire modules directory for easier deployment on my we server. When I initialize a branch in the modules directory it ignores the other version controlled folder.
<smthomas> web server*
<vila> smthomas: you want nested trees which is not implemented yet
<vila> smthomas: the container branch will ignore the contained branch for now
<smthomas> vila: ok thanks, any idea when nested trees will be implemented (for future reference)?
<vila> smthomas: no estimate for now as the bzr devs focus on other features but it's an highly desired feature nevertheless...
<smthomas> vila: yes I agree with that as I would like to be able to use it, thanks again for the help
<vila> smthomas: you know about the bzr-upload and the bzr-push-and-update plugins right ?
<vila> smthomas: the above are for deployment
<vila> smthomas: but there are also other plugins that try to address the nested trees feature (and I forgot their name, once *again* !)
<vila> bialix will kill me :-/
<smthomas> vila: no I do not, I will have to do some research. I am fairly new to bzr. I have been using it for awhile but not much for deployment yet
<vila> bzr-externals ?
<vila> https://launchpad.net/bzr-externals yeah, sounds like it
<vila> smthomas: you may give it a try too
<jelmer> vila: what about something like this: http://bazaar.launchpad.net/~jelmer/bzr/per-repository-vf/revision/5688
<vila> jelmer: exactly !
<vila> err
<vila> except for the first line in the patch, do you really need to do that ?
<vila> in tests/__init__.py
<jelmer> I don't think we would discover that test file otherwise
 * jelmer tries
<jelmer> yeah, without that line we don't run the tests in bzrlib.tests.per_repository_vf.test_repository. Previously the loader.loadTestsFromModuleNames call took care of that
<vila> then may be just a boilerplate load_tests in __init__
<vila> I realize the per_xxx tests are not *that* regular either :-/
<vila> oooooh noooo, bazaar-commits@lists.canonical.com thinks I'm spamming ???
<jelmer> vila: what about http://bazaar.launchpad.net/~jelmer/bzr/per-repository-vf/revision/5689 ?
<vila> argh, no, it's even worse ! That's my own ISP !!!
<jelmer> vila: bazaar-commits@ still exists ? :)
<vila> jelmer: indeed !
<chx> another bzr-git question, how do you update your import of a git repo?
<jelmer> chx: running bzr git-import again
<chx> ah!
<chx> tricky.
<chx> and bzr dpush in that directory, right?
<chx> where the shared repo is
<chx> and finally, how you create a new git branch w/ bzr-git?
<jelmer> chx: "bzr init" will create a new git branch
<jelmer> chx: bzr dpush in which directory?
<chx> jelmer: do you do bzr init in refs/heads?
<chx> jelmer: i have a directory (shared repo) resulting from bzr-import
<jelmer> chx: no, just in the root of the repository
<jelmer> chx: That's a bzr repository, creating something there won't help you get it into git
<jelmer> chx: What are you trying to do exactly?
<chx> jelmer: many things :) i try to use bzr-git in place of git... :)
<chx> jelmer: Drupal moved to git from cvs and i tried git and i am ... well. i'd use bzr-git instead. just there isnt much docs.
<LeoNerd> Last time I tried bzr-git it didn't have the ability to operate on the bizarre multiple-branches-in-one-place model that git uses
<jelmer> chx: Contributions in that area would be welcome :) I guess at the moment there are mainly caveats, otherwise it should work like bzr itself
<jelmer> LeoNerd: it has that capability nowadays, but bzr's UI doesn't actually provide you with the ability to use that yet
<chx> jelmer: ok i will ask questions and write a blogpost for docs. Deal?
<jelmer> chx: WFM :)
<LeoNerd> Ah OK
<vila> maxb: bananas...
<maxb> I like bananas. Bananas are good.
<vila> yeah and testables !
<chx> jelmer: http://ex.privatepaste.com/bd99cc1e46
<jelmer> chx: the git:// protocol is anonymous, so using that to push will probably not work
<jelmer> you probably want to push to a git+ssh:// URL, or a local Git repository
<vila> jelmer: fixreleased+milestone, not fixcommitted, kthksbye :-p
<jelmer> garrr
<jelmer> anyway, time to move..
<jelmer> chx: I'll be back online in ~30m
<wart___> hi folks.  i did a bzr branch lp:widelands and a network fail caused me to ctl-c.  now when i try bzr branch lp:widelands it won't resume, but says that the directory widelands exists.
<wart___> is there a way to resume?
<wart___> i tried a couple of things icould think of e.g. cd widelands; bzr pull
<wart___> no luck
<wart___> it'd stink to rm -rf and start over since i got 200M of the 400M
<vila> wart___: AFAIK, it stinks
<maxb> wart___: Hi. Could you pastebin the result of running "find .bzr -ls", to help understand the status of the partial branch?
<vila> wart___: you should file a bug, I don't think we have one asking for pull to be resumable
<vila> wart___: alternatively, if you network connection often fail, you could pull by chunks by specifying increasing revnos
<vila> s/you connection/your connection/
<wart___> maxb: http://pastebin.com/fN1kbTiT
<wart___> well this is about the 4th time its done it to me so how do i specify increasing revnos?
<vila> wart___: bzr branch -r<revno> ; bzr pull -r<revno>
<maxb> wart___: Ah. As you can probably infer from the lack of large files there, nothing has been stored.
<jhunt> Hi all - I've made a tweak to lp:~ubuntu-desktop/gdm/ubuntu. I want to push my branch to lp:~jamesodhunt/... somewhere but can't find a path bzr is happy with (either complains about distro series, or just EPERM)...?
<chx> jelmer: hi
<chx> jelmer: that crashed
<chx> jelmer: http://paste.pocoo.org/show/350399/
<jelmer> hi chx
<chx> jelmer: bzr import git://git.drupal.org/sandbox/chx/1085438.git ; cd 1085438.git/ ; bzr init new-branch ; cd new-branch ; bzr dpush  git+ssh://git.drupal.org/sandbox/chx/1085438.git
<jelmer> chx: Hmm, the repository does not have a HEAD branch?
<chx> jelmer: the repo is empty
<jelmer> chx: The repository will need an empty branch first
<chx> jelmer: so it needs to be git cloned first :( ?
<jelmer> chx: That's one of the limitations of dpush at the moment
<jelmer> chx: *Something*, an empty branch is fine first
<jelmer> s/first/too
<chx> jelmer: so --- i need to use git first?
<jelmer> chx: for the moment, yep
<jelmer> chx: Was I talking with you about bzr-git on answers.lp.net earlier?
<chx> jelmer: no
<jelmer> ah, ok
<jelmer> Let me find the bug # again then
<jelmer> chx: it's bug 731336
<ubot5> Launchpad bug 731336 in Bazaar "dpush doesn't create new branches" [Medium,Confirmed] https://launchpad.net/bugs/731336
<chx> jelmer: http://paste.pocoo.org/show/350426/
<chx> jelmer: wait, it does not create new branches at all? ah!
<chx> jelmer: i see, i see
<chx> jelmer: so for new branches we need git :/
<jelmer> chx: you need to use git on the remote side to create the repository anyway
<chx> heh that's automated :)
<jelmer> ah, ok
<jelmer> wb chx
<chx> jelmer: so we cant really expect that any time soon 731336 gets solved :( ?
<jelmer> chx?
<jelmer> it's on the list of things to fix, though it should be trivial to work around at the moment
<chx> is it/
<chx> how so?
<jelmer> chx: the first time you work with a git repository, push to a local repository first and then push that using git to the remote server
<jelmer> chx: so if you're in the bzr branch you'd like to dpush, run something like:
<jelmer> git init /tmp/tmprepo; bzr init /tmp/tmprepo; cd /tmp/tmprepo && git push HEAD:master git+ssh://..../host
<jelmer> then later you can just "bzr dpush git+ssh://..."
<chx> jelmer: sorry for dropping -- so how can be worked around the branch create bug?
<jelmer>  chx: so if you're in the bzr branch you'd like to dpush, run something like:
<jelmer>  git init /tmp/tmprepo; bzr init /tmp/tmprepo; cd /tmp/tmprepo && git push HEAD:master git+ssh://..../host
<jelmer>  then later you can just "bzr dpush git+ssh://..."
<chx> jelmer: i will try
<chx> jelmer: it's not that easy to be honest as i start from cloning / bzr-importing a remote repo
<jelmer> chx, if you start from cloning / bzr-importing a remote repo then this is not necessary
<chx> jelmer: ??????
<jelmer> chx: this is only for creating a new branch
<chx> jelmer: yes but git repositories contain many branches?
<chx> jelmer: what i have tried here was to create a new git branch.
<jelmer> chx: bzr can only address the "current" branch at the moment, see bug 380871
<ubot5> Launchpad bug 380871 in Bazaar "Allow imports of non-master branches when pulling from git repositories" [Medium,In progress] https://launchpad.net/bugs/380871
<jelmer> the only way you can work around that is to use a local git repository as a proxy
<chx> jelmer: this all is extremely confusing
<jelmer> chx: To summarize: git has multiple branches in a single location
<chx> jelmer: i barely speak git , it's a major pita that i am now forced to use it, i hoped bzr-git will save my hide but it just adds more compliexity :(
<chx> jelmer: yes
<chx> jelmer: i understand git branches (or i hope i do)
<jelmer> chx: Bazaar only supports a single branch per location at the moment, even with bzr-giut
<chx> yes i understand that too but i hoped that with shared repository this can be fixed
<chx> this is http://www.eecs.harvard.edu/~cduan/technical/git/ what i understand of git.
<jelmer> chx: A shared repository doesn't help in that regard
<chx> :(
<jelmer> chx: It sounds like what you really want is a fix for bug 380871
<ubot5> Launchpad bug 380871 in Bazaar "Allow imports of non-master branches when pulling from git repositories" [Medium,In progress] https://launchpad.net/bugs/380871
<chx> i have no idea what a no master branch would be
<chx> i just wanted to create a new git branch from bzr-git :(
<jelmer> chx: all the git branches except for the HEAD branch are non-master branches :)
<chx> i see.
<jelmer> I've updated the title of bug 380871
<ubot5> Launchpad bug 380871 in Bazaar "support for colocated branches" [High,In progress] https://launchpad.net/bugs/380871
<chx> i might be an idiot -- but why do we need to colocate them?
<jelmer> chx: that's what git does
<chx> it's perfectly fine for me to "unpack" them , say git_repository_name/branches/branchname
<chx> i mean, even bzr git-import creates a refs dir
<jelmer> chx: if you do a push to a git repository the branches there are colocated, that's the way it is
<chx> there yes
<chx> but can't that be made into a bzr-git internal problem? :)
<jelmer> chx: Internal problem how? Fixing that is what that bug report is about.
<jelmer> an alternative would be a "bzr git-push" command that supports a --branch argument to specify the target branch
<jelmer> but I'd rather focus the effort on fixing this properly
<chx> on git-import copy the existing branches somwhere (isnt that what refs does ? ) and record somehwere bzr-git specific what happened in the shared repo and on dpush reverse the operation: take every bzr branch and send them as one git repostiroy
<jelmer> chx: that's at least as much work as fixing that bug I mentioned earlier
<jelmer> and less elegant of a solution
<chx> i see
<chx> i can pick from shooting myself in the left or the right foot
<jelmer> chx: hmm
<jelmer> chx: are you running bzr-git from trunk?
<chx> jelmer: yes
<chx> i can either use git whch i am not yet capable of or i can use bzr-git where bzr is not yet capable of :)
<chx> jelmer: and bzr 2.3.0
<jelmer> chx: I could give you a very ugly hack to use an environment variable
<chx> ugly hacks++
<jelmer> not now, but ping me tomorrow and I'll have a look
<chx> sure.
<chx> thanks, see you later
<spiv> Good morning.
#bzr 2011-03-09
<Stavros> hello
<Stavros> is there a way to have bzr store branches in the same directory and switch uncommitted changes too?
<Stavros> basically, colocated branches but with shelving
<lifeless> bzr switch should just do that
<Stavros> lifeless: last i tried, switch didn't switch uncommitted changes, was that added?
<Stavros> lifeless: nope, it doesn't
<lifeless> what do you mean by switch uncommitted changes then ?
<lifeless> for me, it keeps uncommitted changes in the tree, so I can commit them to another branch.
<Stavros> oh
<Stavros> i mean shelve them in the branch
<Stavros> so i can have uncommitted changes per branch
<Stavros> for example, i'm working on feature 1 but it's half done
<lifeless> so, standard shelve is in the working tree
<Stavros> yes, but per-branch
<lifeless> the pipeline plugin adds a shelf per branch as well
<Stavros> hmm
<Stavros> nothing that will automatically shelve everything on swich, though?
<lifeless> pipeline does when working with a pipeline
<Stavros> is pipeline good? i found it a bit confusing
<lifeless> some folk love it
<Stavros> what i want to do is work on feature1, switch to feature 2 even if 1 is half finished, work on 2, switch back to 1 and finish and commit 1
<lifeless> its quite polished at the use case it aims to solve (a series of feature branches tackling one large problem)
<Stavros> right now i have to do some complicated shelving
<Stavros> ah
<Stavros> hmm yes
<Stavros> maybe this is what i need, then
<lifeless> Stavros: what about just committing?:
<Stavros> i don't like committing half-working things :/
<lifeless> work on feature 1, commit, switch to feature 2, work, commit, switch to feature 1, *uncommit*, keep working.
<Stavros> i don't trust me to remember to uncommit :/
<Stavros> good solution if you're not ocd, though
<lifeless> a shelf per branch would be a good facility for core I think, perhaps file a bug ?
<Stavros> i will, thanks
<Stavros> i'll try pipeline in the mean time
<Stavros> shouldn't i post a feature request rather than a bug?
<lifeless> Stavros: there is no difference
<Stavros> ah, thanks, i'm filing one now
<lifeless> Stavros: bugs.launchpad.net/bzr
<vila> hi all !
 * fullermd waves at vila through the lightning.
<vila> :)
<jam> morning all
<jam> MoggÃ»h, jelmer (though you're probably not up yet :)
<jam> morning vila
<vila> hey jam !
<jam> so vila, what are you working on these days? Still poking at the package importer mostly?
<vila> I've been catching up with mails and reviews so far, I will focus on the p-i again now
<vila> jam: oh, and 2.3.1 should have been released last week so I need to catch up with that too
<jam> well, give it a sec, since I have a patch progressing through the stack :)
<vila> jam: did you merge your fix up to trunk for the missing inventories ?
<vila> hehe
<jam> I'm up to 2.3
<jam> which is where you get NEWS conflicts because of the split-out
<vila> jam: I intend to work on 2.3.1 tomorrow only, I'd like to summarize all the mails about which plugins are carried by which distros first
<mr-russ> Hi, I'm reading the smart http server documentation and setting up mod_python method of using http smart server.  Where do I find bzr-smart.py?
<mr-russ> running ubuntu 10.04
<vila> mr-russ: which doc are you reading ? bzr-smart.py doesn't appear to be part of the bzr sources
<Peng> It's more or less part of the docs.
<Peng> Last I checked.
<mr-russ> yeah, that was my complaint really.  http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/http_smart_server.html
<mr-russ> but there is no way to easily find the source from that page.
<mr-russ> after 10-15 minutes googling, I think https://lists.ubuntu.com/archives/bazaar/2006q4/020376.html  has the details I need.
<Peng> mr-russ: But the source is in that page.
<Peng> mr-russ: Copy and paste it.
<mr-russ> thanks, excuse the dumb moment.
<Peng> It's not ideal, of course. Maybe someone should stuff them all in contrib/ or somethuing.
<mr-russ> yeah, it would be nice to have an example as part of the bzr doc when you apt-get.
<mr-russ> I'm about to find out what I need to do to get modpywsgi installed.
<jam> vila: on the plus side, it seems this was the only patch that needs merging-up
<jam> so you've kept the branches fairly in-sync
<vila> :)
<mr-russ> modpywsgi seems difficult to find, links don't work.
<jam> mr-russ: http://code.google.com/p/modwsgi/ ?
<vila> mr-russ: :-/ patch welcome !
<jam> if you can give updates to the docs, that would be great
<mr-russ> what branch would I checkout?
<vila> for http://doc.bazaar.canonical.com/bzr.dev/ it should be the bzr trunk itself
<mr-russ> so there is no python file, I need an apache module now?
<vila> and then follow the path from the url doc/en/user-guide, once there, there should be a .txt corresponding to the .html
<vila> mr-russ: could very well be the case, that's why we generally encourage the use of bzr+ssh
<mr-russ> okay.  I was trying to keep away from having server accounts for each user.
<vila> shudder
<vila> yeah, that's the other missing bit...
<mr-russ> what does lp use under the hood?
<vila> ssh :)
<mr-russ> I understand the authentication issues I think
<vila> mr-russ: for lp you authenticate with one of your registered ssh keys
<mr-russ> maybe I'll switch back to ssh.  But is there a tute on restricting the ssh commands users can run?
<Peng> LP doesn't use an ordinary sshd server, though.
<vila> mr-russ: as in restricting the ssh command to bzr ?
<mr-russ> yes.
<mr-russ> you can only use bzr over ssh, no account login at all.
<vila> oh, it's in ~/.ssh/authorized_keys IIRC
<vila> let me check
<mr-russ> yes, with the funny commands out the front.
<mr-russ> It's getting those commands right that is always painful.
<vila> indeed (searching for an example)
<mr-russ> I think I may have gone that route first if I found a clear example.
<mr-russ> I'm branching bzr now, so I'll see how I go with doc patches.
<mr-russ> I've not used bzr with launchpad before, how does patch contribution work?
<vila> mr-russ: so, in the general case: branch; hack hack; commit; push lp:~<lpname>/<project>/<meaningful-branch-name>
<vila> mr-russ: 'bzr lp-open' will open the pushed branch page from where you can select: 'propose for merging'
<mr-russ> cool.
<mr-russ> I'm sure it's easy when I get the hang of it.
<vila> mr-russ: for bzr you will need to go thru http://www.canonical.com/contributors
<mr-russ> Oh the joy of the legal world :)
<vila> mr-russ: yeah, the whole process is pretty easy, there is also 'bzr lp-propose' which further simplify some steps but I don't use it myself (for... various uninteresting reasons) so I can't comment precisely there
<vila> mr-russ: yeah :-/ There is a work in progress to satisfy more people but as often with legal it takes time
<mr-russ> http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/
<mr-russ> does that look right for the bzrssh server setup?
<spiv> mr-russ: looks highly plausible
<vila> roughly yes, I'm not sure about the options restrictions (but they shouldn't harm) and I can't find back my example locally (I could swear I used one at some point :-/)
<spiv> mr-russ: see also contrib/bzr_ssh_path_limiter in the bzr source tree
<vila> spiv: hey !
<spiv> Hey :)
<mr-russ> I"m still waiting for my branch to finish downloading, not the greatest performance
<mr-russ> I'll see if the lucid package installed contrib.
<vila> mr-russ: I don't think contrib is ever installed (apart from the bash completion stuff though...)
<mr-russ> that's what I'm seeing on my server.  waiting for branch to complete.
<vila> mr-russ: so you server is lucid, you know you can use the stable ppa to get newer releases right ?
<mr-russ> no.  As a standard kind of user, I use what's packaged by default.  That way it's 'supposed' to be support for 3-5 years.
<vila> mr-russ: lucid provides bzr-2.1.1 while the ppa will gives you bzr-2.3.0 (and the associated plugins)
<mr-russ> I usually upgrade with all LTS releases though.
<vila> the stable PPA will support LTS as well
<mr-russ> but LTS does not support the PPA :)
<vila> the PPA content ?  no :)
<vila> but *we* do :)
<mr-russ> That is not what the average user will expect.
<mr-russ> I will consider upgrading once I actually have this working neatly.
<vila> via SRUs we may be able to provides 2.1.4 for lucid, but we are not there yet
<mr-russ> too many things that I and others are used to with SVN.
<vila> mr-russ: and what clients are you using ?
<mr-russ> lucid.
<mr-russ> all lucid at the moment.
<mr-russ> command line bzr mostly.
<mr-russ> I'm hoping to convince my work to switch from svn to bzr in the next year.  But that will require evaluation of windows tools, particularly with regard eclipse and a setup for ssh for users, possibly against AD.
<vila> right, so, indeed, if you start using the PPA you'd better deploy it everywhere too, no urgency
<vila> AD ?
<vila> active dir
<mr-russ> So I have a lot of learning todo before I can encourage them towards that stance.
<vila> sry
<mr-russ> Active Directory. ldap windows.
<vila> right, so we don't support 2.1 on windows, only the most recent stable release (2.3)
<vila> this shouldn't be a problem
<vila> but if you'll get better performance with 2.3
<vila> s/if//
<vila> mr-russ: no pressure, just presenting the options
<mr-russ> okay, that will go with we use RedHat as a server and I'm sure it has and older version of bzr.
<mr-russ> ah the joy of learning new stuff.
<vila> hehe
<vila> right, I've heard rumors about some bzr packaging on rh but I've never been able to get a contact there, pointers welcome !
<mr-russ> Well, I've backed back to using bzr+ssh, much easier.  No tricks with folder permissions when new branches are created?
<vila> mr-russ: no, as  long as you use a single user on the server
<mr-russ> We only have a regular education support contract and an account manager, so I'm not sure I can help you a lot with RH contacts.
<vila> err
<vila> as long as the same user owns the branch and is used to ssh connect, no permissions tricks are needed
<mr-russ> I've created a bzr group.  added relevant users to it, and set all permissions to group rw(x).
<vila> mr-russ: no worries, but if you find some bzr packages for rh or centos or fedora, whatever, I'd be happy to hear about it
<mr-russ> now when anybody pushes a new branch, will group stuff get set correctly, or do I need to set some sticky bits or something like that?
<mr-russ> vila: If I find anything or progress down that path, I'll report back.
<vila> mr-russ: right, but the ssh server filters the group permissions bits IIRC which is the source of all the problems
<vila> mr-russ: thx
<vila> mr-russ: so the ssh setup is generally easier when a single user is created on the server and collect all authorized user keys
<fullermd> Or use a real OS with simpler FS semantics   8-}
<mr-russ> oh.
<vila> fullermd: you mean... Windows ?
<fullermd> You'll still need to correct on pushing new branches.  The perms in the repo for new data are preserved, but new branches just run off umask.
<mr-russ> so user a single user account on server with shared ssh key, lock down to relevant command only and all the commit names are managed by bzr itself?
<mr-russ> and bzr won't mess with permissions/ you can't set a different umask for that folder?
 * mr-russ feels so out of his depth
<vila> mr-russ: the commits always occur on local hosts and as long as you can push to a server, you can push your own commits or anybody else's
<vila> mr-russ: think of it as a user with different roles, each role is associated to a key
<vila> mr-russ: you give keys to users that can push to the server
<vila> mr-russ: and you define a single user on the server for this role
<mr-russ> ssh account developer has (x) ssh keys that can run bzr.
<vila> on the server, yes
<mr-russ> All developers on remote boxes  use;  bzr push bzr+ssh://user@my-bzr-server/path/to/bzr/branch/
<mr-russ> where user is the common user.  Their ssh key is of course already setup properly.
<vila> with an appropriate ~/.ssh/config you can even use bzr push bzr+ssh://my-bzr-server/path/to/bzr/branch/
<mr-russ> I just wish I could short circuit the /path/to/bzr/branch to /branch.
<mr-russ> I think I need to write a tutorial for this kind of setup.
<vila> bzr+ssh://my-bzr-server/~/project/branch/
<vila> '~' will expand to the ssh user home directory on the server
<mr-russ> the URL I sent before fixes taht.
<mr-russ> as the command forces the folder for you.
<mr-russ> http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/
<vila> mr-russ: http://paste.ubuntu.com/577750/ is an excerpt of my ~/.ssh/config
<mr-russ> I think I have found a winning configuration.  Thanks all for your help.
<vila> mr-russ: good !
<mr-russ> and after 3 years of trying to really understand dvcs and how to set it up, I think I'm finally over the line.  I'm sure I'll find some merging issues and fun ahead.  But we are much further down the load.
<mr-russ> s/load/road/
<mr-russ> So if I created a tutorial on a central bzr setup as we have discussed, should it go in bzr/doc/en/tutorial?
<vila> mr-russ: sounds like it, that would be awesome !
<catphish> is it possible to create a shared / default branch.conf?
<vila> mr-russ: may be check in admin-guide too
<vila> catphish: what's your use case ?
<catphish> eg. repo.conf or just plain bzr.conf
<vila> catphish: there is a work in progress to allow that
<catphish> well i am setting up some hooks, and i want them to run on all branches in a particular  repository
<mr-russ> vila: can I send the contributor form to you, or to Mr Pool?
<vila> catphish: see configurations.txt in lp:~bzr-core/bzr/devnotes for an almost up-to-date description
<vila> mr-russ: poolie
<vila> mr-russ: err, yeah, Martin Pool
<mr-russ> yes, I know poolie is Martin Pool :)
<catphish> thanks vila, bazaar.conf will probably do, i was really hoping to do it per-repo
<vila> catphish: me too :)
<vila> catphish: but out of curiosity (and to help ensure your use case is addressed in the future), can you tell me what kind of feature you're implementing with these hooks ?
<catphish> vila: i run a repository hosting service, and i am using the post_change_branch_tip hook to update a log when people push
<catphish> now, i could use a single hook globally, however in every other SCM, hooks are defined per-repository
<catphish> i can't define it per-branch easily because users can dynamically create branches within their repository
<catphish> my hook currently reads the name of a shell script from the [hooks] configuration parameter and executes it
<mr-russ> vila: I've sent the agreement, so that mean magic happens and my contributions will be considered for merging?
<catphish> so ideally, for compatibility with the way other SCM's work, I would like to be able to define the [hooks] configuration per repository
<vila> mr-russ: yup, poolie should process it and from there we will land your contributions after reviewing them
<mr-russ> thanks.
<mr-russ> vila: what's the ppa address?
<vila> https://launchpad.net/~bzr/+archive/ppa
<vila> the various ppas are described at https://launchpad.net/bzr
<mr-russ> and it's stable, even though it's labelled for developers?
<mr-russ> okay, reading that page says it's stable releases.
<vila> mr-russ: oh, it's labeled for 'Bazaar Developers' because they are the maintainers not the targeted users
<catphish> i am having problems with locking
<catphish> bzr: ERROR: No such file: '/data/repos2/b5/70ff4d-c20f-d082-210b-d51b37b6bb92/default/.bzr/branch/lock/held'
<catphish> a directory that quite clearly does exist
<jelmer> hi catphish
<catphish> hi
<jelmer> catphish: when do you get that error, what are you trying to do?
<catphish> jelmer: http://paste.codebasehq.com/pastes/xpt7u0ga7152
<jelmer> catphish: is it perhaps a path that exists remotely?
<catphish> it DOES exist remotely, see the ls
<jelmer> catphish: sorry, I missed that that was on the remote host
<jelmer> catphish: This is probably a bug in the smart server, can you file a bug report?
<catphish> ideally i'd like to be able to confirm whether it's a bug in my http server first
<jelmer> catphish: It could be, but I think a bug in the bzr smart server is a lot more likely
<catphish> jelmer: the error certainly implies an error in the smart server
<catphish> the file it is complaining about clearly exists
<jelmer> jam: Goeiesmorgens!
<catphish> where do i report it?
<jam> jelmer: when you sleep in, boy do you sleep in :)
<jelmer> jam: :)
<jelmer> catphish: it might be that the path is being sent across the wire and the bzr client tries to access it locally
<catphish> good point
<catphish> i'm using a sucky old client
<catphish> will try upgrading first
<jelmer> jam: I'm having fun with the CommitBuilder.. do you know what fast deltas are, and why they are a reason for avoiding record_iter_changes() ?
<jam> jelmer: dirstate can compute deltas quickly, and 2a can store deltas quickly
<jam> so rather than build the whole inventory
<jam> and save it
<jam> we build a delta and apply it
<jam> it was slower in pre-2a
<jam> and didn't handle merge commits for a while
<jam> I think that has been fixed
<jam> but I'm not positive
<jelmer> ah, thanks
<jam> I'm pretty sure record_iter_changes is the recommended path right now
<jelmer> jam: at the moment we seem to use record_entry_contents() if the repository format supports nested trees, the commit has excludes or if the format doesn't support fast deltas /and/ there is more than one parent
<jelmer> The last condition is the one you mentioned, I assume?
<catphish> jelmer: i think i found my problem by looking closer at the protocol log
<jam> I'm not sure what is ANDed and what is ORed in that statement
<jam> but sure
<jam> I trust that you're looking at it more closely than I
<jam> we don't support it with nested trees, because it isn't well defined
<jam> so no work was actually done on it
<jelmer> filter_iter_changes() does actually handle kind == 'tree-reference' though, strangely enough
<jam> jelmer: that doesn't mean that all the other bits of the stack do
<catphish> jelmer: the smart protocol was being sent this by my http server: ["rename", "default/.bzr/branch/lock/held", ".bzr/branch/lock/broken.8y5qi3f3qq5hft5r28km.tmp"]
<jelmer> jam: right
<catphish> the branch name wasn't appended to the second parameter, the error it returns is misleading
<jelmer> jam: anyway, it seems like the only thing that really matters for me is the exclude parameter, the others can't be triggered for foreign formats.
<jam> jelmer: well, if you want to implement --exclude handling for record_iter_changes, I'd be ok with that
<jelmer> catphish: Ah, I see
<jam> I think there was some discussion about how it should be done
<jam> that it should be passed into iter_changse
<jam> rather than filtered on top, etc.
<catphish> i guess my code that injects branch names needs to be a little more intelligent
<jelmer> catphish: you're running a custom http server?
<catphish> jelmer: yes
<catphish> it just accepts http requests and passes them on to bzr serve --inet
<catphish> unfortunately because my url structure contains a repo and a branch, it is necessary to inject the branch name into commands
<catphish> right now i just have (ruby code): command[1] = branch + '/' + command[1] if branch
<catphish> assuming the second parameter is always a path
<catphish> unfortunately the smart protocol isn't all that well documented, so i'm not sure which commands have more than one path as parameters
<catphish> though i'd appreciate it if anyone who knows could tell me :)
 * jelmer isn't all that familiar with the smart protocol either, unfortunately
<catphish> i can just address them as i find them
<catphish> looks like my original problem is fixed anyway :)
<ChrisCauser> Hi guys, have I come to the right place for bzr-svn help?
<catphish> probably
<ChrisCauser> catphish Thanks
<catphish> by the way, is this room affiliated with canonical and launchpad directly?
<ChrisCauser> Basically, I'm getting weird things with bzr 2.4 dev and was wondering if anyone had seen it before?
<ChrisCauser> $ bzr commit
<ChrisCauser> Committing to: svn+https://SVN_REPO
<ChrisCauser> modified FILES
<ChrisCauser> bzr: ERROR: Layout CustomLayout([PATH_FROM_SVN_ROOT],[]) does not support custom branch paths.
<ChrisCauser> Argh, stupid formatting
<vila> catphish: not per se, but many people haunt the same channels
<ChrisCauser> Basically, If I checkout a svn repo, I get the error above
<ChrisCauser> If I unbind it and push to it, there is no error
<ChrisCauser> Does anyone know what I'm doing wrong? The svn layout is indeed a little strange
<catphish> i wasn't really sure how closely bazaar was tied to canonical and to launchpad
<catphish> but it's not really important
<jelmer> ChrisCauser: PATH_FROM_SVN_ROOT is not the path you have checked out?
<ChrisCauser> jelmer: Apologies that wasn't clear.  the svn root is at SVN_ROOT. I checkout SVN_ROOT/masterfiles/production and PATH_FROM_SVN_ROOT comes up as ['masterfiles/production']
<jelmer> ChrisCauser: but "bzr commit" says "Committing to SVN_ROOT" ?
<ChrisCauser> jelmer: No. It says "Committing to SVN_ROOT/PATH_FROM_SVN_ROOT"
<jelmer> ChrisCauser: hmm, that's odd. Do you perhaps have push_merged_revisions enabled? Does the branch have tags?
<ChrisCauser> jelmer: It's a pretty bog standard bazaar install. The checkout is fresh so has no tags. Interestingly, I have a second svn repo that I'm committing to just fine which has a standard trunk/branches/tags layout
<jelmer> ChrisCauser: Can you try that commit again with BZR_PDB=1 set and pastebin a backtrace?
<vila> catphish: bzr is a GNU project for which Canonical is the copyright holder
<ChrisCauser> jelmer: Thanks for that. It has entered the debugger but the lines prior to that are at http://pastebin.com/3fX6dTQP
<catphish> that's fine then, it was primarily the integration with launchpad that concerned me, seemed that a bit of a commercial injection
<vila> catphish: look harder :) 1) launchpad is free software, 2) the integration is done via a single plugin (bundled with bzr core though)
<catphish> vila: that's cool, it hadn't occurred to me that LP was free / multihomed :)
<catphish> i won't concern myself then
<vila> catphish: see https://launchpad.net/launchpad, licence: GNU Affero GPL v3
<catphish> i did :)
<catphish> thanks
<vila> hehe
<catphish> how do i read global config? right now i am using TreeConfig to read branch config but it doesn't fall back to the user or system config
<catphish> Just Config?
<jelmer> catphish: bzrlib.config.GlobalConfig
<jelmer> ChrisCauser: can you run "bt" in the python debugger and pastebin the output?
<ChrisCauser> jelmer: http://pastebin.com/Ak7e0m2N
<catphish> jelmer: sorry to be dumb but how do actually use the GlobalConfig class to read a config option?
<jelmer> catphish: GlobalConfig().get_user_option('bar') IIRC
<jelmer> ChrisCauser: hmm, that's odd. It's trying to push a non-mainline revision for some reason. What does "bzr missing SVN_URL" report?
<catphish> jelmer: works like a charm, thanks
<ChrisCauser> jelmer: I appear to get back the entire history of the repo. There is an svn revno right up to the point I see my first [merge]. Could this be a clue? I have two branches which I merge via bzr locally and push to svn separately. Any merges I have done purely in svn don't seem to have revno: number [merge] written on them.
<jelmer> ChrisCauser: yes, that's probably related. Was the branch you're working in currently based on the remote svn repo?
<jelmer> ChrisCauser: Is there a difference in any way between the local and the remote commits reported by "bzr missing"
<jelmer> ?
<ChrisCauser> jelmer: So basically I had two branches, development and production. I branched both of them and merged back and forth and pushed to the svn repo.
<ChrisCauser> jelmer: On the same machine, but in a completely new bzr repo, I have checked out the production branch and it seems to have checked out the branch but the missing command reports that the 200 commits I have made on svn are not commited locally yet I have 200 identical commits locally.
<ChrisCauser> jelmer: There are no local commits as yet. This is a fresh checkout that I haven't changed.
<catphish> jelmer: it appears that the problem with my http server isn't as simple as i thought, the bzr client is (sometimes) sending duplicate identical HTTP requests at once
<catphish> so it sends 2 lock requests, the first succeeds and the second one of course fails
<catphish> i'm sure there's a reason, just can't see what it is :(
<jelmer> catphish: is there any reason for using a custom http server rather than e.g. just apache with wsgi?
<catphish> yes
<vila> catphish: highly suspicious, there shouldn't be multiple lock requests coming from a bzr client
<vila> any gentoo packager around ?
<jelmer> ChrisCauser: can you spot any differences in the revisions present locally and remotely?
<catphish> i'll get a full packet dump and see if i'm doing something to upset it
<vila> http://packages.gentoo.org/category/dev-vcs?full_cat seem to imply (I'm a gentoo noob) that 2.3.0 is not available (hardmask). What's the rationale ?
<jelmer> vila: They filed some bugs earlier about several plugins not having a compatible release with 2.3 out yet
<vila> jelmer: ho ! thanks. Now that you mention it...
<ChrisCauser> jelmer: I've just realized, when you say SVN_URL, is that the path to the SVN_ROOT or does it include the path? If it includes the path then bzr is reporting that the branch is up to date.
<jelmer> ah, hmm.. time for my afternoon tea!
 * jelmer runs off
<jelmer> ChrisCauser: including the path
<jelmer> ChrisCauser: even in the original branch?
<ChrisCauser> jelmer: Hope you have a nice tea! I'm afraid there is no original bazaar branch as I suffered data loss.
<jelmer> ChrisCauser: I was just teasing vila since he was going to ask me about doing a bzr-svn release...
<vila> jelmer: haha
<ChrisCauser> jelmer: Ooops. Sorry
<vila> jelmer: I haven't made the connection yet, but I plan to freeze 2.3.1 tomorrow, be ready ;-D
<jelmer> ChrisCauser: I mean, the original branch in which you tried to run "bzr commit"
<ChrisCauser> jelmer: Oh, there is now only one bzr branch checked out at the moment, the "production branch." I originally had on my last computer two branches "production" and "development" (both in svn) which have now gone and these were the ones that I merged back and forth
<jelmer> ChrisCauser: Hmm, ok
<jelmer> I wonder why it's trying to commit to a non-mainline branch then
<jelmer> the change you're trying to commit, what sort of change is it?
<ChrisCauser> jelmer: I've just tried to check out the development branch and that is causing another error on checkout: http://pastebin.com/XrQmAQet (hopefully nothing too incriminating here ;) )
<jelmer> ChrisCauser: but it still did the checkout I presume (those are just warnings)?
<ChrisCauser> jelmer: Yes, it still did the checkout
<jelmer> ChrisCauser: the change you're trying to commit, what sort of change is it?
<ChrisCauser> jelmer: It happens on modifying, adding and removing
<jelmer> ChrisCauser: any merges involved?
<ChrisCauser> No
<jelmer> ah, I see what's happening
<jelmer> ChrisCauser: this is a regression caused by bzr 2.4
<jelmer> ChrisCauser: please file a bug
<ChrisCauser> jelmer: Brilliant :) Will do.
<ChrisCauser> jelmer: Is there any information that will help describe the situation?
<jelmer> ChrisCauser: bzr-svn doesn't implement Branch.import_last_revision_info_and_tags(), which was added recently
<jelmer> hmm, Branch.import_last_revision_info_and_tags doesn't make sense
<jelmer> ChrisCauser: can you try trunk?
<ChrisCauser> of bzr-svn or bzr?
<jelmer> ChrisCauser: bzr-svn
<ChrisCauser> jelmer: :-$ I'm having a bit of difficulty here. I got a "AttributeError: 'SvnBranch' object has no attribute 'source'" when I commited to the same checkout and when I checkout a new branch and commit I get an invalid http code (401)
<ChrisCauser> jelmer: Did I not supply enough flags to the setup script?
<jelmer> ChrisCauser: I've committed a fix, please try again
<catphish> does anyone know if bzr with http has problems with keepalive? i'm pretty sure it tries to send requests down connections that have already been closed
<vila> catphish: it's been a very long time since we had reports about problems with keep-alive
<vila> catphish: you can use -Dhttp on your bzr client commands to get a debug output of all requests
<vila> catphish: the output should go to ~/.bzr.log IIRC
<catphish> yeah, i tried that, the duplicates i'm seeing don't appear there
<catphish> but i see them in a packet dump
<catphish> so i'm a little confused at the moment
<vila> weird
<vila> do you have some proxy may be ?
<catphish> will post some info if it persists
<catphish> i do have a proxy, which was my first suspicion, but the duplicate requests are visible at the client too
<vila> catphish: if -Dhttp doesn't output the faulty request, bzr is out of the equation
<vila> err
<vila> what do you mean by 'visible at the client' ?
<catphish> i mean, wireshark on my client shows 2 http requests to lock a repo
<catphish> one at the end of a kept-alive http session
<catphish> and another at the start of a new http connection
<catphish> however i will confirm that and get some logs and evidence together to make sure i'm not being stupid
<catphish> i have no doubt it's the result of one of my proxies, but i need to establish exactly why
<catphish> vila: actually the duplicate http requests do show up in the http log
<vila> catphish: ha ! now we've got something :)
<catphish> but the response doesn't appear
<catphish> http://paste.codebasehq.com/pastes/sxze691xetsn
<vila> catphish: can you pastebin the relevant part making sure you remmo... you're too fast :)
<catphish> i didn't remove my auth details
<vila> catphish: argh, change your password, the Auth header is only lightly protected
<catphish> i know that all too well
<vila> ok
<catphish> brb
 * vila should really obfuscate these headers...
<catphish> seems wise
<vila> catphish: can you paste a bit more ?
<catphish> sure
<fullermd> Bah.  Silly diff algorithm, picking the wrong bit of code to leave in place.
<vila> fullermd: ha, one of those cases, painful heh ?
<catphish> http://paste.codebasehq.com/pastes/64m6nvijy788
<fullermd> The "oh crap, why and how did I delete that important code?!" sudden-panic is particularly fun.
<vila> :)
<catphish> passwords changed, dunce cap applied
<vila> :)
<vila> err, didn't I just say that ?
<vila> catphish: so, the first thing that catch my eye is that the keep-alive is reset far too early (at 92 !)
<catphish> vila: what's odd is that the request is sent, the reply is received (at least to the packet sniffer on my pc), but bzr misses the reply and opens a new connection to send the request again
<vila> ha crap, the pieces I'm searching for are logged only when _debuglevel is set
<vila> catphish: can you edit bzrlib/transport/http/_urllib2_wrappers.py for a test /
<vila> ?
<catphish> sure
<catphish> but you'll need to guide me in the right direction since i'm not a python developer
<vila> there is a DEBUG variable at the top the file set to 0, setting it to 3 will give us more data
<vila> no worries, you just have to change 0 to 3 :)
<vila> hmm, is upgrading to bzr-2.3.0 an option too ?
<catphish> wow
<catphish> that's a lot of info
<vila> I don't remember related fixes since 2.1.1 but it's quite old so I may be wrong
<vila> catphish: I don't remember the details, but 3 should output a lot about proxies but only once whereas 2 will output for requests but not significantly more than -Dhttp
<ChrisCauser> jelmer: Thank you so much. That did the trick wonderfully. I can now checkout and commit to an svn repository.
<vila> catphish: concretely, I suspect some transient error trigering a resent of the same request
<catphish> i have a full log now
<catphish> just going to clean the passwords and paste it
<vila> catphish: in your case, it could be that the request went through to the server but we still get what looks like a transient error
<catphish> Received exception: [BadStatusLine('0\r\n',)]
<vila> urgh, the infamous :(
<catphish> you know it well?
<vila> catphish: more or less, it generally means a bug somewhere else :-/
<vila> catphish: the status line is something like 'HTTP/1.1 200 OK' , if we got a bad one... it could mean we didn't consume the socket content properly
<catphish> i wonder if it's bad handling of the chunked encoding
<catphish> since all responses end with 0\r\n
<catphish> it may have still had 0\r\n in the buffer from the previous request
<catphish> and read it as the start of the next response
<vila> catphish: that would trigger with the second request then
<catphish> vila: http://paste.codebasehq.com/pastes/eaoht6hslbts
<catphish> there's the log snipper
<catphish> *snippet
<vila> where is that 'reply:' coming from ?
<catphish> http://paste.codebasehq.com/pastes/49osq8c9otx7
<catphish> that's the data on the tcp socket
<catphish> only the bottom is relevent (the lock_write) request
<catphish> but the response appears the same as the others, nothing unusual
<vila> catphish: I mean, did you type that or is it coming from bzr ?
<catphish> from bzr
<vila> grep 'reply:' returns no matches
<catphish> what are you grepping?
<vila> the bzr sources for 2.1.1
<catphish> you're right, but i can see it clearly on my screen
<vila> ho ! probably from httplib itself
<catphish> 'send:' doesn't appear either
<vila> hmm, what python version are you using ?
<vila> confirmed, from httplib when debuglevel is set (via DEBUG)
<catphish> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
<vila> hmmm
<vila> 0\r\n is an empty chunk no ?
<catphish> correct
<catphish> more than that, it's the end of the response
<vila> one possible cause would be that the server issues an empty chunk wrongly (as in bzr doesn't expect it), but we've never encountered such servers...
<catphish> empty chunks are necessary as far as i know
<catphish> they mark then end of the chunked response
<catphish> http://en.wikipedia.org/wiki/Chunked_transfer_encoding#Encoded_response
<catphish> The response ends with a zero-length last chunk: "0\r\n" and the final "\r\n".
<vila> sure, but what if the sever is sending two of them instead of one
<vila> catphish: just throwing ideas there
<catphish> it's not on this occasion
<vila> catphish: ok
<catphish> i sent the raw tcp dump
<vila> where ?
<catphish> http://paste.codebasehq.com/pastes/49osq8c9otx7
<catphish> that's just one tcp connection
<vila> wow, I missed that
<catphish> specifically the one that is terminated prematurely
<catphish> you see it send the successful response at the end
<catphish> the one that is never received by bzr
<vila> indeed, so you got that from the server side ?
<catphish> no
<catphish> packet sniffer on the client
<vila> O_o
<catphish> it's 100% what the http library is seeing
<vila> waitaminute
<catphish> :)
<catphish> i'd love to hear that my server is doing something dumb
<vila> the status lines appears at the end of the lines in a weird form
<vila> hmm
<vila> may be just some formatting wart of the packet sniffer but...
<catphish> the response status lines are just on the same line as the end of the request
<catphish> because technically there is no \n between them
<vila> well, they don't travel in the same part of the socket either
<catphish> unfortunately i had no way to colour in the data in each direction
<vila> yup
<catphish> you have to assume where they client and server packets start and end
<catphish> "....d16:Software version5:2.1.1es...!l25:Branch.get_stacked_on_url1:.ee" << end of request
<catphish> start of response >> "HTTP/1.1 200 OK"
<vila> catphish: so from the send:/reply: in the full trace you should be able to match that no ?
<vila> ha, well, no
<vila> httplib will only tell you that it read the headers but nothing about the body
<vila> so, try setting DEBUG to 9
<catphish> eek ok
<vila> don't worry, only 1 2 3 9 are used
<vila> 9 will output a bunch of crap once at the beginning and then the bodies (well, some bodies IIRC :-/)
<catphish> ok
<catphish> i'll try it
<vila> more precisely the bodies that the higher levels didn't consume...
<vila> ... damn, that's silly, we are indeed searching for a case where bzr fail to consume such bory remains :(
<catphish> i don't think that made any difference to the log
<vila> catphish: did you see any 'Consumed body:' ?
<catphish> no
<vila> I'm a bit lost :-/
<vila> catphish: looking at the modifications in _urllib2_wrappers *after* 2.1.1, I don't see clearly connected modifications but some may apply...
<vila> catphish: what os are you using on the client and the server ?
<catphish> ubuntu 10.04
<catphish> 32 and 64 respectively
<catphish> the server is actually an apache2 proxy and a backend server
<vila> shudder... nothing weird there
<vila> catphish: anyway, there is a PPA you can use to upgrade both: https://launchpad.net/~bzr/+archive/ppa
<catphish> it's a complicated arrangement, which is why i'm focusing this discussion on what the client sees
<vila> catphish: sure, and you're doing well, it's just that remote debugging is.... hard :-/
<catphish> the server is running 2.3.0 from easy_install
<vila> catphish: and the extensions get compiled with easy_install ?
<catphish> i honestly don't know
<vila> not that this should make a difference...
<catphish> i haven't needed any
<vila> catphish: oh yes you need them :)
<catphish> why?
<vila> catphish: otherwise we use the python fallback implementation and the performance suffers
<catphish> ah
<vila> catphish: the ppa is the next best thing after the official Ubuntu releases
<vila> catphish: you just need to do 'sudo add-apt-repository ppa:bzr/ppa' and you'll get the repository added
<catphish> not sure what best to do
<catphish> interestingly if i disable keepalive at the server side, the client receives the connection: closed header and sends another request anyway
<catphish> maybe i'll just try the ppa and tell customers to do the same
<catphish> i'm also trying to get my post_change_branch_tip hook on the server running when i push over http
<catphish> but hopefully that won't be a problem
<vila> catphish: right, without keepalive, the things are far simpler, no need to babysit the socket content (but that's not enough evidence to confirm a bug in the bzr client side there :-/)
<vila> catphish: https is not involved here right ?
<catphish> no, i pulled that ages ago because it was totally broken with my version
<catphish> the same problem exists with the 2.3.0 ppa version
<vila> installed on both client and server ? (just checking)
<catphish> no, the server is running the 2.3.0 from easy_install
<vila> hmm, shouldn't be relevant
<catphish> but that's almost entirely irrelevant since the http stuff is done in ruby
<catphish> and in apache
<catphish> well definitely a server problem
<vila> catphish: ? why ?
<catphish> because i can't be the only person using the smart protocol over http
<vila> oh no, you aren't
<catphish> and since i'm using the lastest version, something must be different about my server
<catphish> not a bug necessarily
<catphish> but something about my server that bzr or the http library doesn't like
<vila> catphish: try pinging spiv, he's in AU times and should arrive later, I'm about to EOD myself
<catphish> where are you?
<vila> catphish: what is the most troubling for me is that your tcp dump looks fine
<vila> catphish: france
<catphish> ah ok
<catphish> definitely home time then :)
<catphish> i thought my tcp dump looked fine, and i don't do any of the keepalive or chunked encoding myself so i trust that it's correct
<vila> catphish: spiv should be able to validate this stream better than me
<vila> catphish: you mean your server do something between the bzr server and the client ?
<catphish> in my case the 'bzr server' is just "bzr serve --inet"
<catphish> and there's a ruby server sitting in front of it, with an apache proxy
<catphish> one day i'll explain why that is
<vila> but in this case you're just relaying the bytes right ?
<catphish> correct
<lifeless> uhm
<lifeless> so bzr+http:// uses a different encapsulation to bzr://
<catphish> the only thing i interfere with is the request, prepending the branch name to any paths
<jam> vila: it is very funny to still see you online at 7pm my time. but I realize, you never were very good at stopping by 5/6 :)
<vila> jam: :)
<catphish> vila: i will try getting rid of the chunked encoding
<catphish> there's no need for it
<lifeless> catphish: you probably need to get a wsgi service up and forward to that, not to bzr serve --inet
<catphish> lifeless: i hope i don't need to do that
<catphish> since my implementation works well, apart from these randomly dropped http sessions
<jam> lifeless: I believe he wants to use a ruby server
<lifeless> jam: sure, you can do that
<vila> catphish: worth a try, we don't it need it AFAIR but I think it's handled by httplib so we shouldn't care either... but may be not
<lifeless> jam: I'm just trying to remember the exact framing changes for bzr over http
<catphish> i think the problem is in httplib personally
<catphish> chunked should never be necessary
<catphish> vila: thanks very much for taking so long to help debug and tracing it to the 0\r\n
<vila> catphish: always happy to help (TM by jam ;)
<catphish> vila: setting a content-length prevented my http server from using chunked encoding
<catphish> and... it works
<catphish> now just to get the hook working and i have a fully working service :)
<vila> catphish: huh, how stupid ! I didn't check the Content-Length !
<catphish> content-length is not required for chunked encoding, they're mutually exclusive
<catphish> but apparantly one works and the other doesn't :)
<catphish> so that'll do
<catphish> i prefer sending content-length anyway, much simpler approach
<vila> catphish: indeed, I used chunked encoding so long ago I forgot it *is* targeted at unknown length contents :-D
<catphish> anyway i must get home
<catphish> thanks again :)
<guest> hello, I have a question on hooks and was wandering if someone could have time to help ...
<lifeless> ask away
<guest> together with source files I have a compiled file versioned as well, so need to not forget to compile before commiting
<guest> so was thinking, can it be done in a hook (pre_commit etc) or I'll have to do it outside in a batch running compiler first then bzr commit?
<lifeless> guest: you are storing the compiled versions in bzr?
<guest> yes
<lifeless> if you run 'bzr help hooks | less' and look for 'start_commit
<lifeless> '
<lifeless> that hook runs before bzr starts calculating the commit
<lifeless> so it can change things however you like
<guest> aha, I was just reading that, figured pre_commit is not good since it already has deltas, so start_ commit is the way to go. great, thanks a lot :)
<briandealwis> hi jelmer.  I saw yesterday that you might try to add an env var to specify remote branch names in bzr-git?
<Stavros> hello
<Stavros> can someone explain the pipeline plugin to me? it looks like it does exactly what i want, but i don't get all the pumping
<beuno> Stavros, have you seen: http://www.youtube.com/watch?v=HujoyGSq8n4
<Stavros> i haven't, i'll watch that now, thanks
<Stavros> hmm, that video mentions the same things as the docs
<Stavros> basically what i want is colocated branches with uncommitted changes being stored in the branch
<Stavros> which is exactly what pipes do
<Stavros> but with colocated branches i can merge into trunk whenever i finish a feature in a branch
<Stavros> whereas pipes always go from top to bottom
<Stavros> which is what i don't understand, what sort of workflow needs things to go from top to bottom?
<shakaran> Hi, I have a bzr repository, but I want merge a commit from a svn repository. It is possible? I try with bzr-svn merge -c 419 svn_url_repo, but it don't work
<shakaran> I am doing a:
<shakaran> svn diff -r 419 snv_url_repo
<shakaran> For get the diff, but this is tricky, someone with better solution?
<jelmer> re
<jelmer> briandealwis: hi
<briandealwis> hi jelmer
<jelmer> briandealwis: It's a gross hack so I won't add it to bzr-git itself, but I'm looking at providing a patch that does that
<briandealwis> that's cool, jelmer.  I hurt my brain trying to figure out git's push command line.  Gross hacks are preferrable.
<briandealwis> I currently use Eclipse's EGit to do pushes :)
 * jelmer wished there were some more people to help with eclipse-bzr :-/
<mr-russ> eclipse has a git plugin?
<mr-russ> I wish that too.
<mr-russ> I'd like to make use of eclipse-bzr.  But my python and java skills don't exist.
<briandealwis> mr-russ: yeah.  They're moving to git.
<briandealwis> mr-russ: There are two Eclipse projects: JGit, equivalent to Dulwich, and EGit, providing Eclipse tooling
<mr-russ> Oh, that's going to hurt.  Good eclipse support makes the game different.
<briandealwis> mr-russ: the good news is that the EGit tooling reflects Git.  My thoughts were that if bzr-git can push to branches, then BzrEclipse may be a happy medium.
<briandealwis> Gerrit looks pretty nice too.
<lifeless> briandealwis: which 'they' are moving to git?
<jelmer> eclipse itself I think?
<briandealwis> lifeless: There's a concerted effort to move all Eclipse projects to Git.
<lifeless> briandealwis: oh, interesting.
<briandealwis> Almost all projects are currently either still CVS or Subversion
<wolfpack> Hey, Can bzr push the code on launchpad with http protocol? I am working behind http proxy and cannot make ssh connection.
<spiv> wolfpack: no, Launchpad doesn't run the bzr service over http
<wolfpack> spiv: but branching is allowed! So is there any options to work on the projects?
<wolfpack> any other option *
<spiv> https://bugs.launchpad.net/launchpad/+bug/165087
<ubot5> Ubuntu bug 165087 in Launchpad itself "Launchpad should offer a bzr+http smart server" [Low,Triaged]
<spiv> wolfpack: you can sometimes convince http proxies to carry SSH traffic
<wolfpack> spiv: How?
<spiv> If you're using Ubuntu, try installing the 'corkscrew' package and using that
<spiv> It can help to have an SSH server of your own somewhere listening on port 443 (i.e. the HTTPS port)
<spiv> Otherwise, I don't know that there's much you can do.
<wolfpack> Are you referring to this "http://omappedia.org/wiki/Using_bzr_and_launchpad_behind_a_proxy "
<spiv> wolfpack: I hadn't seen that link before, but those instructions look reasonable
<wolfpack> spiv: Well, I tried that but that does not works :(
<spiv> Your proxy is probably restricts access to ports other than 80 and 443 then :(
<wolfpack> thanks for helping .
#bzr 2011-03-10
<briandealwis> I'm having strange locking problems on MacOS X where bzr is complaining about a lock being held â but it's the same process
<briandealwis> This is with 2.3.0
<briandealwis> I have a branch bound to another branch, that is itself bound to another branch
<briandealwis> It's complaining trying to acquire a lock to the third branch
<spiv> That sounds like a familiar issue
<spiv> I'll see if I can find a bug report about that
<mgz> If there's something horribly wrong in my last post to the list, someone please correct me.
<spiv> briandealwis: it might be related to https://bugs.launchpad.net/bzr/+bug/412223, but I think there's something specific to 2.3.0 because I think there's been a small spike in reports of it happening
<ubot5> Ubuntu bug 412223 in Bazaar "bzr up locks master branch" [High,Confirmed]
<spiv> briandealwis: I can't find an obvious bug about it though, so I guess file a new report.  Maybe we've regressed in how we handle a bound branch of a bound branch?
<briandealwis> spiv: I don't think that's right.  At least all my branches are local and fully-qualified
<briandealwis> And I just unbound the second level, and it's still occurring.
<briandealwis> Weirdness.
<spiv> Indeed!
<briandealwis> spiv: hmm, I'll have to dig into this tomorrow.  It doesn't seems to only happen with a particular branch pair
<spiv> briandealwis: ok.  I think the contents of the .bzr/branch/branch.conf files would be particularly interesting
<briandealwis> spiv: the only thing that's different is that I have some post-commit hooks to trigger a hudson build
<spiv> Oh, and the traceback, of course :)
<briandealwis> How do I force a branch back to a previous version?  "bzr pull . -r â1" doesn't seem to do itâ¦
<lifeless> jelmer: when you are around
<lifeless> https://bugs.launchpad.net/loggerhead/+bug/728691
<ubot5> Ubuntu bug 728691 in loggerhead "loggerhead NoSuchRevision: KnitPackRepository exception" [Undecided,Incomplete]
<briandealwis> ah, âoverwrite it the key: "bzr pull . âoverwrite -r â4"
<spiv> mgz: replied :)
<spiv> briandealwis: yep, --overwrite
<jelmer> lifeless: hi
<jelmer> lifeless: hmm
<mgz> spiv: aha, there was a generic method, thanks. what's still not clear to me is what initialisation steps need/should really be done first.
<jelmer> lifeless: Is there actually any reason for that method to use revision_trees() rather than get_revision_delta() ?
<lifeless> jelmer: good question
<lifeless> jelmer: that may be addressed by jams historydb work
<spiv> mgz: just bzrlib.initialize(), IIRC
<lifeless> with bzrlib.initialze(): do stuff
<briandealwis> spiv: I put the branch.conf and .bzr.log at http://pastebin.com/cmv6ZWqv
<briandealwis> spiv: I thought it might be related to a plugin, but doesn't seem to be
<mgz> is that true even with hooks? you can't use run_bzr like that because it doesn't know about the commands, do any of the command objects themselves depend on hooks that aren't installed by default?
<lifeless> mgz: there is an entry point for running commands that adds the bzr-internal command hooks
<lifeless> mgz: its what the bzr script calls
<mgz> but it's not part of initialize.
<lifeless> right
<lifeless> commands.install_bzr_command_hooks
<lifeless> which is called by run_bzr_catch_errors
<lifeless> and run_bzr-catch_user_errors
<lifeless> which is called by main()
<lifeless> mgz: start with bzrlib.commands.main()
<mgz> one of the important bits there seems to be _register_builtin_commands which doesn't have a public alternative as far as I can see.
<lifeless> nope
<spiv> briandealwis: hmm, could you add -Dlock to the command line and paste the .bzr.log from that?  That should tell us where the locking is happening.
<lifeless> mgz: thats more plumbing :)
<lifeless> mgz: if you want to use the inbuilt command dispatch, calling main() is the key
<briandealwis> spiv: log at http://pastebin.com/68x4VM1n
<briandealwis> spiv: oops, that didn't work
<briandealwis> spiv: sorry, try this: http://pastebin.com/JptmhQUT
<ovnicraft> hello, i found this plans http://doc.bazaar.canonical.com/developers/colocated-branches.html for 2.4 what is the state of this ?
<spiv> ovnicraft: jelmer has the most up to date info I think
<spiv> ovnicraft: IIRC, most if not all of the core infrastructure in the code now exists
<spiv> ovnicraft: so what's left is mainly the UI
<ovnicraft> we have problems with all modules in our repo each module/directory has dependencies each other i was thinking in a module to manage this and canc clone just the dep
<ovnicraft> i need colocated for this ?
<ovnicraft> can*
<beuno> lifeless, ping
<lifeless> beuno: hi
<beuno> lifeless, hey!
<beuno> so, I got into loggerhead hacking again
<beuno> trying to get this tarball thing proposable
<beuno> I've got it working
<lifeless> have you looked at launchpad_loggerhead? thats the glue we use to run lh in lp
<beuno> now, I'm trying to figure out what the best way to make it easy for LP to turn it off
<beuno> I haven't in 2 years I think
<spiv> ovnicraft: there are some existing plugins that may help you
<lifeless> beuno: you should
<beuno> lifeless, where can I grab that from?
<ovnicraft> spiv, maybe a clue
<lifeless> beuno: because we'd turn it off from there, whatever the mechanism - we'd be adding the hook or $whatever
<lifeless> beuno: lib/launchpad_loggerhead
<spiv> ovnicraft: bzr-colo, bzr-colocated, bzr-scmproj
<beuno> lifeless, that assumes I have the LP tree  :)
<lifeless> beuno: yes, yes it does
<beuno> lifeless, lets pretend I don't
<lifeless> beuno: we have loggerhead running on lp
<lifeless> bazaar.launchpad.net/~launchpad-pqm/launchpad/devel
<lifeless> beuno: I hear you can browse via it
<ovnicraft> spiv, yes i am checkin' bzr-colo so i need your opinion here to manage this if i am clear
<beuno> sounds like en evil technology
<ovnicraft> managing dependencies using colocated and write a plugin
<lifeless> ovnicraft: easiest way to make it fast is to setup one, or perhaps several, shared repositories
<lifeless> ovnicraft: then use bzr-scmproj - the repository will cache data locally for you
<spiv> ovnicraft: I agree with lifeless; my guess is bzr-scmproj will either do what you want or be a good starting point for building what you want.
<ovnicraft> sound ok  i want to do something like bzr branch lp:project --myproj-modulename
<ovnicraft> and maybe gets another modules
<ovnicraft> like bzr pull --myproj-anothermodule
<spiv> ovnicraft: I wouldn't think colocated branches would be a natural fit for managing a collection of different modules and their dependency relationships.  It seems to me that colocated branches are better suited to tracking multiple versions of a single project (e.g. to have all of bzr 2.0, bzr 2.1, bzr 2.2, bzr 2.3 and bzr trunk branches).
<ovnicraft> in that ways looks better so the problem is when cloning (if plugin exists) need just a copy from module and their deps
<ovnicraft> and can pull more modules
<beuno> lifeless, up for a loggerhead review?
<beuno> anyway, sleep now
<beuno> jam, if you happen to be around, https://code.launchpad.net/~beuno/loggerhead/export-tarball/+merge/52797
<beuno> oooops
<beuno> this branch has things committed it shouldn't
<beuno> gar... in the first revision
<beuno> ok, really sleep now
 * beuno waves
<spiv> vila: hmm, 16 package imports failing due to LockContention?  That seems odd.
<vila> spiv: not fully there yet, but didn't bzr get upgraded on jubany ?
<vila> spiv: there have been a few bugs around LockContention lately (one in particular has to do with connection reuse in builddeb ?)
<vila> ok, I'm in, spiv ?
<spiv> vila: there's an rt for upgrading bzr on jubany, but it hasn't been done yet IIRC
<spiv> rt 44398
<vila> bzr version says 2.3b5 (which in itself is pretty weird, why b5 ???)
<vila> ha right, so this points to bug #726854 which indeed mentions reusing transports (I didn't dig that though)
<ubot5> Launchpad bug 726854 in SABnzbd "Upgrading queue from 0.5.x to 0.6.0 can fail" [Critical,Fix released] https://launchpad.net/bugs/726854
<spiv> vila: specifically I saw LockContention on a local branch, though
<spiv> vila: http://package-import.ubuntu.com/status/udev.html#2011-02-24%2020:39:43.444410
<vila> grr bug #726584
<ubot5> Launchpad bug 726584 in Ubuntu Distributed Development "flash-kernel import fails apparently mismatching maverick and natty branches" [Undecided,New] https://launchpad.net/bugs/726584
<vila> *local* branch ? Urgh
<maxb> vila: Hi. I think I'll rename bzr.webdav now, since there have been no objections
<vila> maxb: please do ! Sorry I didn't find the time to do it myself :-/
<maxb> not a problem
 * vila is still fighting to unbrick a natty vm...
<maxb> nothing too vital trapped inside it, I hope?
<vila> no, it's ok
<vila> what is a 'held package' ?
<spiv> A virtual brick?
<vila> update-manager is telling me: E:Error,pkgProblemResolver::Resolve generated breaks, this may be caused by help packages...
<vila> spiv: :)
<maxb> vila: A held package is one which has been placed on hold in aptitude or dpkg by the local sysadmin, to prevent automatic upgrades
<vila> urgh, I can't remember doing that, how can I find it or them ?
<maxb> dpkg -l | egrep ^h
<vila> empty :-/
<spiv> I guess held packages aren't the problem then!
<maxb> My general advice on encountering any sort of dependency chaos is that the interactive curses mode of aptitude is a wonderful tool :-)
<vila> ha, let me try that
 * vila restores last backup
<vila> the nice thing with vms is that they are easy to restore, just use the whole disk backup :)
<vila> ok, that's 6GB, but still :D
<jam> morning vila, evening spiv
<vila> hi jam
<mr-russ> out of curiosity, what tools to bzr developers use for development?  vi, eclipse or something else?
<lifeless> mr-russ: depends on the dev
<lifeless> mr-russ: most are vim, at least one is emacs
<jam> mr-russ: If I was using an idea, it would probably be Wing. Lots of good stuff there, but their VI-mode was lacking
<jam> It might have gotten better since
<jam> it was a year or two ago
<jam> IDEs can be great, but VIM just rocks as a text editor
<mr-russ> I've just never found a comfortable tools on linux that feels like I'm doing things fast.  vi is pretty good, but my skills ain't brilliant, especially with shortcuts for going into functions and back, like ctags
<jam> ^]
<jam> or you're saying you know that but don't feel great with using it?
<jam> Once you have vim muscle memory, it is pretty hard to use another editor, IME
<soren> jam: I'd love to see you write code: wing - Galaga-like arcade game
<jam> WingIDE
<jam> http://wingide.com/
<soren> Aw, that's no fun at all.
<jam> soren: but yes, that would be pretty awesome
<jam> squashing bugs in real time, baby
<vila> maxb: unbricked ! I had to reinstall the vbox additions which confused me for a bit though
<vila> maxb: thanks for the aptitude trick !
<mok0> "Branch to merge into, rather than the one containing the working directory." Does anyone understand that? I don't
<mok0> (from bzr merge --help)
<vila> mok0: yes, almost everybody :)
<vila> mok0: by default you merge in the directory you're working
<mok0> vila: ah, yes I see :-)
<mok0> vila: that help text could be better though :-)
<vila> mok0: if, for whatever reason, you want to merge into *another* directory than the current one, you use -d
<vila> mok0: certainly
<mok0> vila, I'd prefer (cd ../otherdir ; bzr merge )
<vila> mok0: so you don't need -d
<mok0> vila: right
<vila> mok0: but if you have a good idea for a better phrasing, patch welcome !
<mok0> vila: patch? That would take me an hour
<mok0> vila: I can submit a bug
<vila> bzr branch lp:bzr ; hack hack, bzr commit ; bzr push lp:~<lp_login>/bzr/better-merge-help ; bzr lp-propose ; done
<vila> mok0: sure, a bug is a good starting point
<mok0> vila: I could try. Never hacked on bzr before
<mok0> vila: heh lp is down
<vila> mok0: ooohhhhhh, paaaaaaaaiiiiinnnn
<mok0> vila: actually, what I was looking for is a "dry-run" switch for merge
<vila> mok0: db upgrade in progress, should be back in ~90 minutes at max :-/
<vila> mok0: --preview
<vila> mok0: http://identi.ca/launchpadstatus for tracking lp status
<mok0> vila, oh, thanks. I got so puzzled at the -d switch I didn't discover that...
<vila> mok0: :)
<vila> mok0: almost all bzr commands accept a -d switch
<mok0> vila: I am slowly trying to become a more sophisticated bzr user. Not doing too well ;-.)
<vila> mok0: take your time ;)
<mok0> vila: I guess the -h texts are not the best avenue for that endeavour
<mok0> vila, will --preview give me an indication of potential conflicts?
<vila> mok0: well, they should. They are supposed to help... May be not the newcomers that may be better served by http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html but still
<mok0> Because sometimes I'd like to put off a merge if there are conflicts
<vila> yes, --preview will tell you about conflicts
<mok0> vila, I've read those docs many times
<mok0> vila: but my brain is old and fragile
<vila> yeah, brains tend to become fragile when you get old, but they are also supposed to be more effective ;)
<mok0> vila: perhaps what I need is a reference-manual type document, with examples
<mok0> vila: effective? I guess... I am still going pretty ok at 10% capacity :-)
<vila> wow, indeed, if you're able to discuss with *me* at 10% capacity, that's surely a good sign :D
<mok0> vila: the tutorials are fine for getting started, but they never give you the full story
<vila> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/index.html then ?
<mok0> vila, perfect! Bookmarked!
<vila> http://doc.bazaar.canonical.com/bzr.dev/en/ is the starting point
<mok0> vila, one problem I meet in my daily workflow is this:
<vila> or even http://doc.bazaar.canonical.com/en/ (except there is currently a bug there, 2.3 being the stable version, the links are valid, only the numbers are wrong)
<mok0> I have upstreams subversion branch mirrored on LP. I have a packaging branch off that
<mok0> upstreams branch contains a whole bunch of stuff that doesn't get into the distribution tarball ("make dist" tarball")
<mok0> to avoid getting a huge .diff.gz file, I have deleted everything from the packaging branch that does not go into the dist tarball
<mok0> that normally works fine, but when upstream has edited one of the "un-needed" files, I get conflicts
<vila> :-/
<mok0> I just need to resolve them, but it is a drag
<mok0> Most of the time, the merge goes smoothly, but I'd like to check if a merge would generate conflicts ahead of time. So perhaps --preview can help me there
<vila> There are several works in progress to address that, including the ability to specify either globally or on a file-by-file basis that you don't care about modifications to deleted files
<vila> --preview should help
<mok0> vila: ultimately, we shouldn't have to rely on tarballs for source packages, but...
<vila> you should also be able to say 'bzr resolve --take-this <file>' to resolve the conflict where <file> is involved
<vila> mok0: that's call UDD, see https://wiki.ubuntu.com/DistributedDevelopment
 * mok0 goes off to bzr reference manual to see :-)
<mok0> vila: yeah, I've been tracking that now and then, but much of it goes over my head.
<vila> mok0: then this needs to be fixed
<vila> not your head...
<mok0> vila: It is my religious belief that the packaging branch should be a child of upstream
<mok0> vila: and some of the current practices are not like that AFAIU
<mok0> vila: as like having debian/ in its own branch
<vila> mok0: <cough> I'm (still) not a seasoned packager myself, but I'd like to get there and yes, the idea is that upstream should be a parent branch
<vila> mok0: yup, we hope to get away from this practice as soon as it becomes *easier* to *not* use it
<mok0> vila: I also haven't grasped looms yet, which seems to be central in the whole patch thing
<vila> mok0: looms are discussed indeed but needs some polish to be fully usable
<mok0> vila: ... unfortunately 3.0 (quilt) seems to have consolidated the way patches are treated
<vila> mok0: think of looms as a stack of branches with upstream at the bottom
<mok0> vila: sort of like git?
<mok0> git branches?
<vila> no, git branches are more like colocated branches where you switch from one branch to the other without any enforced relationship between them
<mok0> vila: I guess I should just try looms. I've put it off, because I've read (like you said) that looms "need some polish"
<vila> colocated branches help using a single working tree when ... it matters. It can be because it's expensive to maintain (lots of compilations), it can be a convenience
<vila> mok0: they need polish for the udd case, I use them daily myself
<mok0> I see
<mok0> Perhaps I should just try them. Doesn't it add another layer of complexity?
<vila> mok0: you can think of them as an alternative to quilt (IIUC) where each patch is turned into a branch (and as such get an history)
<vila> mok0: it depends on your workflow
<mok0> vila: hm, that sounds useful. I use quilt a lot
<mok0> vila: I am patching upstreams code quite a lot, and I keep all my changes in quilt patches
<vila> I use looms when I want to work on a bug feature for a long time and create threads for pieces I can submit for inclusion in trunk
<vila> s/bug/big/
<mok0> vila: threads? Uh-oh, another concept.. :-)
<mok0> vila: so, can I use looms in one branch and not another?
<vila> mok0: a loom is composed by threads, a thread is just a funny name for a branch but with a name and a position in the loom
<vila> mok0: yes, you can go from branches to looms
<mok0> vila: so looms replace branches?
<vila> mok0: one part that need polish in looms is when you want to collaborate on looms, merging looms is... not implemented yet for example
<mok0> vila: ah, so they're for personal use
<vila> well, technically they are a branch format
<vila> mok0: in their actual state, they are safe to use for personal use, there are some rough edges when you try to share them
<mok0> vila, so I can make a child branch and turn that into a loom?
<vila> mok0: pipelines are an alternative that some people prefer
<vila> yes
<vila> bzr loomify
<vila> err
<mok0> vila: and what will LP say to that?
<vila> For example, when I start a loom, I do:
<vila> bzr branch lp:bzr new-stuff
<vila> cd new-stuff; bzr nick bzr.dev # to track trunk
<vila> bzr create-thread stuff
<vila> from there I have two threads in the loom, I'll use the 'stuff' one to develop my new feature and commit there
<vila> when I want to resync with trunk I do: bzr switch bzr.dev ; bzr up-thread
<vila> err
<vila> when I want to resync with trunk I do: bzr switch bzr.dev ; bzr pull -v ; bzr up-thread
<mok0> vila: "up-thread" ?
<vila> the pull will update by base thread to the current version of trunk and 'up-thread' will merge my changes onto this new trunk
<vila> it's a command provided by the loom plugin
<vila> and lp knows about looms so you can push there like any other branch
<mok0> vila: it does sound a bit like a git-like  workflow
<mok0> vila: beneath a bzr branch
<vila> mok0: you mean rebase ?
<mok0> vila: no, I mean like having a stack of branches in a single directroy
<vila> AFAIK with git you get a *set* of branches, not a stack
<mok0> vila: ah yes, that's true
<mok0> vila: so with threads, you can only merge "down" ?
<vila> well, up :)
<mok0> :-D
<mok0> vila: and when you do that, the stack becomes lower?
<vila> well, the pointer goes up
<vila> each thread is fully included in the upper ones
<mok0> vila: but the bottom two threads will then be identical?
<vila> if they are you use combine-threads to delete the upper one, it means you don't carry changes anymore in this thread
<vila> it happens when the changes have landed on trunk
<mok0> vila: It's starting to dawn...
<vila> it's a bit like maintaining a series of patches except you keep track of the history (roughly)
<mok0> vila: that sounds very useful
<mok0> vila: I should "just try it"
<mok0> vila: so I am maintaining my patches in quilt in the packaging branch. Where should I have the looms though? In "trunk" or in "ubuntu"?
<vila> mok0: vast question :)
<mok0> vila: I was afraid so :-)
<vila> mok0: the current theory is that you work in a loom with the following threads (starting from bottom): upstream, debian packaging, ubuntu packaging
<vila> now, for the quilt patches, you can also add one thread by patch
<vila> and that's where the discussion is roughly as there are various ways to handle the quilt patches with or without threads
<mok0> vila: but when you do "bzr builddeb" you need the debian/patches directory to be populated
<vila> mok0: and I can't say much more on the topic as I don't know quilt :-/
<mok0> vila: quilt just manages a stack of patches
<vila> mok0: you'll need a better packager than me to answer this one ;D
<mok0> perhaps bzr builddeb know how to deal with looms
<vila> mok0: the idea is that it's better to work with the patches applied than working with diffs of diffs
<vila> mok0: not yet (AFAIK)
 * maxb eeps at the size of scrollback.... what's the unanswered question, and can I help? :-)
<vila> mok0: but the plan is to teach builddeb to (hand waving) make it easier :D
<mok0> vila: I think just needs to try it
<vila> mok0: maxb is a *far* better packager than me for one ;)
<mok0> vila: that would be cool. But of course packaging policies are decided in Debians dungeons
<mok0> maxb: we are discussing packaging using looms
<mok0> maxb: and I am asking more questions than 20 geniuses can answer :-)
<maxb> Yes it's all a bit of an unresolved question
<maxb> I think some people see a utopia where quilt series get mapped into looms, such that you keep history of the patch series too
<mok0> maxb: I described my branchs 25 minutes ago (10:38 my time)
<maxb> *gah*, I am being summoned afk, sorry
<mok0> maxb: ah
<mok0> maxb, let me copy-paste a bit
<mok0> maxb, http://paste.ubuntu.com/578269/
<mok0> maxb:  I also asked vila on advice for maintaining my patches and we discussed looms
<maxb> On the subject of the pastebin, that's a tricky one.
<maxb> I think bzr core could use some way of being told that files are being deleted and you really don't care what upstream does with them from then on
<maxb> However, you might be interested in using bzr-builddeb
<maxb> If, instead of merging normally from the upstream import, you use its merge-upstream command, it will not only help you track what is in the tarballs, but will embed pristine-tar metadata in the packaging branch such that original tarballs can be rebuild from it
<maxb> It goes like this:
<maxb> bzr merge-upstream --version upstream-version path-or-url-to-upstream-tarball path-or-url-to-upstream-import-branch -r tag:the-tag
<maxb> When you do this, bzr-builddeb will commit the contents of the tarball, associating it as a merge commit with the revision in the upstream import branch specified by the -r switch
<mok0> maxb: but I really think as a matter of philosophy that the packaging branch should be a child off upstreams branch
<catphish> morning
<maxb> As for the looms, I'd be tempted to loomify the packaging, and simply not bother with a quilt series at all
<mok0> maxb: ah, didn't read your last comment properly
<maxb> I would use debian/source/options to put dpkg into single-debian-patch mode
<mok0> maxb: but I need a quilt series once the package is created?
<maxb> mok0: ish. your series can contain a single monolithic patch
<mok0> maxb: single-patch mode?
<mok0> ah
<mok0> maxb: like the old diff.gz file
<maxb> googling for reference, one moment
<maxb> Point number 4 in http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/
 * mok0 looks
<mok0> maxb: I've been avoiding 3.0 (quilt) ... I think it sux
<catphish> i'm struggling to understand what initiates the execution of post_change_branch_tip hooks
<maxb> This mostly makes it unsuck by making it behave like 1.0 :-)
<catphish> i have configured one, and if i commit or push locally, it is executed, but if i push to the server remotely it is not
<mok0> maxb: I like the idea of debian/ in a tarball, but it is really unmanageable that unintentional changes to your source tree finds their way into debian/patches. That really sucks
<mok0> maxb: I usually do a quick lsdiff -z ...diff.gz to check that nothing but debian/ is added
<maxb> catphish: Your hook is installed for the user that the server is executing as?
<mok0> maxb: with 3.0, I need to unpack the debian tarball and go look
<catphish> yes
<catphish> i am executing with -Dhooks
<catphish> but that doesn't tell me that they're trying to be executed
<catphish> http://paste.codebasehq.com/pastes/0177vm21a108
<catphish> it works if i push to the same repository locally, but not remotely over bzr serve --inet
<vila> jelmer: before I forget: it would be nice if you could add an entry in the what's-new for 2.4 about the bunch of changes related to both the weave-as-plugin and the foreign plugins being better tested
<vila> jelmer: may be more than one entry in fact;D
<catphish> vila: any idea who i should talk to regarding hooks?
<catphish> i'd read the code if i were just a little smarter
<vila> catphish: lunch time right now, bbl (I'm freezing 2.3.1 though)
<vila> catphish: but first things first, make sure you get the right code on the server when testing for hooks and remember that paths may be different (if you use them to parametrize your hooks)
<catphish> ooo 2.3 1 :)
<catphish> right code?
<catphish> anyway enjoy lunch
<catphish> i'd enjoy lunch more if i were in france i think
<jelmer> vila: Sure
<jelmer> vila: weave as a plugin hasn't really landed (yet) though
<vila> jelmer: last I looked at the mp I understood you wanted to push some more changes or split it, should I look again ?
<vila> catphish: hehe, back, very quick lunch, light, but prepared by my daughter which gave it this invaluable love touch ;)
<catphish> :)
<jelmer> vila: Yeah, that's still the case (unless you feel like reviewing a 4k-line branch :))
<vila> jelmer: not *that* much ;)
<vila> catphish: ok, so given your pastebin it looks like the code is in the right place, to be extra sure, you can try 'bzr plugins -v' on the server to check which plugins are seen there
<catphish> yeah it shows up in bzr plugins
<vila> catphish: there may still be some env variations between your shell and your server but if the log comes from the server, you should be good
<catphish> that log i pasted it generated when pushing through the web server
<vila> ok, so I don't know the shellhooks plugin, how do you associate actions with branches there ?
<catphish> http://paste.codebasehq.com/pastes/5ngeu2bx9wxb
<vila> hmm, the author's name rings a bell <sarcasm> :D
<catphish> lol
<catphish> i rearranged it to be a little simpler for my needs
<catphish> and if i push locally between 2 directories, the hook runs
<vila> right, so the idea there is that the hook is always called and pass the basedir to the shell script ?
<vila> locally == on the server
<catphish> correct
<catphish> the plugin isn't installed on the client machine
<vila> hey ! if you push locally you don't involved the server code no ?
<catphish> that's also correct
<catphish> pushing locally between dirs on the server is 100% bzr code
<catphish> ie. "bzr push /path/to/repo"
<vila> hmm, so you probably don't use the right hook or the hook is not implemented correctly server-side
<vila> ok, so the doc explicitly mention the server for post_change_branch_tip
<spiv> Possible gotchas: 1) environment you're running 'bzr serve --inet' in might see different plugins?  2) paths the server sees might not be what you expect (chroot transports and such)
<vila> spiv: the plugin doesn't filter the paths, it just pass them to the called shell command (AFAICS)
<spiv> I'm about to go to bed, but hopefully that's enough clues for vila to work with :)
<vila> hehe
<spiv> vila: what happens if the transport.base is 'chroot+1234://...'?
<vila> spiv: that the ones I started with but thanks for confirming :D
<catphish> ooh...
<vila> wow: return !
<catphish> that'll probably be it!
<catphish> i assumed it would get file:
<vila> catphish: here you are, the plugin doesn't suit your needs, the hidden assumption is that it's used only for the client for local paths
<spiv> In the API it's not too hard to go from a chroot-decorated transport to the underlying file path
<spiv> The shellhooks plugin probably ought to do that on behalf of the shell commands though.
<catphish> i can easily rework the plugin now i know what the problem is
<catphish> (assuming that's what the problem is :))
<vila> catphish: no, add a print, but as spiv said, you probably get {chroot|filtered}-12321://
<catphish> does that mean i'll never actually get the real path?
<catphish> hopefully the API will let me extract it
<spiv> Yes, the API will let you unwrap that.
<spiv> I forget the exact details.
<vila> catphish: you won't get the real path, probably a relative path from the base dir with some decorations in front of it
<catphish> thanks both!
<catphish> i'm happy to hack away at it now i know where to start
<spiv> (Perhaps the API is not as convenient as it should be, but it's definitely possible)
<vila> catphish: we did faster than yesterday ;)
<spiv> Thinking of yesterday, I read the IRC logs about your bzr+https problem
<vila> catphish: I should have listened harder when you first mentioned chunked encoding, sry about that
<catphish> yes, thanks for being so helpful!
<spiv> The TCP dumps were a bit mangled (non-ascii bytes replaced with '.'s) but there was nothing obviously wrong
<catphish> that's yes to doing faster than yesterday, not yes you should have listened ;)
<catphish> well thanks both, i don't think i'd have got there on my own!
<spiv> I would in the first instance suspect your custom http->bzr server glue as having a bug, though.
<spiv> But that's just a wild guess because there just isn't enough information to diagnose :(
<vila> spiv: that was using a chunked encoding which our http stack is *not* ready to handle
<spiv> I'm glad the Content-Length workaround helped.
<spiv> vila: really?!
<vila> seems so
<spiv> vila: Which part/s?
<spiv> I'm a bit sceptical of that, if that's true I would have expected problems before now.
<catphish> chunked encoding combined with keepalive seemed to kill the http library after about 10 requests
<vila> spiv: we *don't* use chunked encoding ourselves
<spiv> I realise we mostly retrieve static files where the server can easily determine the content-length before it starts sending the body
<catphish> which isn't a serious problem since it just opens a new connection and tries again, but if the request happens to have been a lock...
<spiv> vila: the smart server has at some point, IIRC...
<spiv> vila: (when conveyed over http)
<vila> hmm
<catphish> though in the future i'd prefer to be able to stream the response rather than buffering it to calculate the content-length
<vila> Yesterday, I started with the assumption that we were supporting the chunked encoding and was proved wrong.
<catphish> well chunked encoding works
<spiv> vila: and to avoid buffering potentially the entire repo contents in memory it's basically necessary.
<catphish> it just randomly fails
<catphish> right now i have to buffer the whole response
<vila> Since then, I seem to remember that for properly supporting 1.1 we have to clean up the socket when all the data is not consumed and to do so I'm pretty sure we rely on Content-Length
<catphish> from what i could see, the closing 0\r\n is left in the read buffer sometimes
<catphish> but since i'm not a python dev i'll stop talking now
<spiv> catphish: do you have a trace of that somewhere we can see it?
<catphish> yes
<spiv> cool, file a bug with that attached.
 * spiv -> bed
<vila> spiv: the other cause can be a smart client not consuming properly some server response
<spiv> vila: not with v3
<vila> spiv: that was v3...
<catphish> http://paste.codebasehq.com/pastes/eaoht6hslbts
<catphish> that's the smallest representation of the problem
<spiv> Two things spring to mind: a) v3's unit tests are very thorough about stuff like 'consumes whole response', b) even if it wasn't, the HTTP layer ought to be robust against that anyway.
<catphish> sadly what happens is that the request gets sent twice
<spiv> catphish: beautiful, thanks
<vila> spiv: well, the robust part is to close, open a new connection, re-send the request
<vila> spiv: that failed because the request was a lock and properly processed on the server :)
<spiv> catphish: it probably doesn't reveal anything, but the previous request-response pair might be interesting to see too
<spiv> vila: no
<catphish> no?
<spiv> vila: you can robustly consume and entire chunked http body
<spiv> vila: at which point the channel is clear for the next message
<spiv> s/and entire/an entire/
<vila> may be
<spiv> (assuming the headers didn't specify Connection: close or whatever, of course)
<vila> I'm not sure the layer get enough info to know that
<catphish> spiv: http://paste.codebasehq.com/pastes/49osq8c9otx7
<vila> but in theory yes
<spiv> vila: which layer?
<catphish> if you really want to get your hands dirty
<catphish> that's the tcp stream
<vila> the http transport
<catphish> sadly it's ascii and not coloured properly
<catphish> but it shows what happened
<vila> for get_bytes() and readv() we let the higher layer handle the socket content
<catphish> the final request there is the one that failed (the write lock)
<vila> get_file() not get_bytes() of course
<spiv> vila: I think that's a tractable problem
<vila> sure
<spiv> (ITYM 'get' not 'get_file')
<spiv> vila: HttpTransportBase.get already reads (and so buffers!) the entire reponse
<vila> spiv: isn't there a FIXME there ?
<vila> yes there is...
<spiv> Sure that'd be nice to improve, but that's not *this* problem :)
<spiv> readv is of course more complex, but basically the solution is the same:
<spiv> If a caller issues a new request before you've finished reading the last response you only have a few options:
<vila> indeed, see response.py
<spiv> 1) raise an error (HPSS does this)
<spiv> 2) assume no further consumption of the existing response will happen and just read and discard the contents (and cause errors if someone does keep trying to use that ReadVFile or whatever)
<spiv> 3) read and buffer the remainder of the pending response so the existing call works before issuing the next request.
<spiv> 4) assume pipelining
<spiv> (and possibly risk deadlocks)
<spiv> 5) make a new connection
<spiv> Of all those, for bzrlib I'd be most tempted by 2 or 3.
<spiv> Anyway, really bedtime now.
<vila> yeah, sweet dreams :)
<catphish> night :)
<mok0> vila, maxb, thanks for your help!
<vila> :D
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.1 is frozen, installer build time ! (RM: vila)
<vila> jelmer: *now* you can make a bzr-svn release ;-)
<vila> jelmer: preferably one compatible with 2.3 ;-D
<jelmer> vila: I'm on it :)
<vila> \o/
<jelmer> I also just submitted three MPs for the weave plugin
<vila> ha ha
<vila> ok, I'll switch to that RSN :)
<bialix> hey all
<bialix> hi vila
<vila> _o/
<bialix> I thought the spring is coming, but you're freezing releases, heh!
<vila> time-based ! And this one was delayed because I was in vacations ;)
<bialix> cool
<bialix> vacation!
<bialix> I've tried to make joke with spring and freeze, but I'm bad in English jokes
<vila> oh my, I missed it :)
<bialix> there is very cold these days ;-)
<bialix> nm
<bialix> just wanna ask strange question
<bialix> I've just realized that bzr info shows location is quite strange order: push first, parent second. why so?
<bialix> *blink*
<bialix> very strange
<bialix> vila: re windows installer: Gary is really very busy with his work. I'm not sure he'll be able to do one
<vila> ok
<bialix> and I've lost my installa-fu some time ago :-(
<bialix> vila: can you ask jam to do the installer?
<vila> bialix: jam moved from US to EU, he's in out TZ now :)
<bialix> \o/
<vila> bialix: I think you wake him up from his nap by making his laptop ring :-D
<bialix> jam have a ring now?
<vila> bialix: as such, he may be too grumpy to jump on the offer ;)
<bialix> :-D
<vila> bialix: no idea, I'm making silly jokes
<jam> I'm awake now, but I've got a pretty big stack on my plate
<jam> we tried to rollout a new system on launchpad and 2 of my patches "failed"
<bialix> morning jam
<vila> jam: you're jinxed :-/
<jam> Empathy doesn't seem to ring like Pidgin did, but it does pop up a little Notifier for me.
<jam> or maybe my music is too loud :)
<rvba> Hi, I started hacking on lp:devel where I really should have on lp:db-devel ... I created a branch from lp:db-devel now but I need to pull my changes from my old branch (based on lp:devel).
<vila> SAY WHAT ?
<rvba> Should I export a patch and apply it manually or is there a more clever way to do this with bzr?
<jam> rvba: I'm pretty sure you can just merge across
<jam> db-devel is supposed to be a superset of devel, aiui
<jam> cd db-devel-based-branch
<rvba> jam: ok, I'll try this then, thx
<awilkins> rebase, cherry pick
<jam> bzr merge devel-based-branch
<awilkins> or merge
<jam> rvba: you may want to look at the diff, (bzr diff) and make sure you aren't bringing tons of unrelated devel stuff in
<jam> but I think you'll be ok
<jam> rvba: note, I had lots of trouble with devel vs db-devel as well
<bialix> awilkins: or replay, that's one you haven't mentioned ;-)
<jam> so don't feel too bad. double-mainlines is hard to keep straight for new contributors
<awilkins> bialix, That's a new one on me
<rvba> jam: ok, thanks I'll see how it goes
<bialix> awilkins: why? ah, yes, jelmer said it's hidden
<awilkins> Was it written to support the replay semantics that SVN supports?
<bialix> awilkins: honestly, I have no idea what svn does. replay just replays commits, it's part of rebase (rewrite) plugin
<jelmer> replay needs more polishing before it's exposed
<jelmer> awilkins: what replay semantics does svn support that e.g. bzr merge doesn't?
<awilkins> I think it just names the thing it uses for svnsync "replay" in some way
<jelmer> the replay in svnsync is just an optimized implementation of regular "svn up"
<maxb> vila: bzr-fatimport, eh?
<vila> maxb: hehe, fixed in my branch, I saw the typo after sending the email :D I was wondering if/when someone will notice :)
<vila> for once, the tyop *is* the joke ;D
<fullermd> I figured it was like a signature, so we'd know it was from you  :p
<vila> ha ha, no, for those cases I just add 'crocodile' somewhere to catch true readers ;)
<fullermd> 'minds me of years back in school, where some friends and I had a running thing where, any time we gave a speech or wrote a paper, we had to include the phrase "aluminum siding" in it somewhere.
<fullermd> Ideally in such a way as to not raise eyebrows.  It was entertaining.
<vila> https://code.launchpad.net/~jelmer/bzr/lazy-bzrdir/+merge/52844 makes my head spin :-}
<jelmer> vila: in what way, just the different registration functions?
<vila> fullermd: oh, this game is still heavily practiced there, one variation is called ... business loto or something
<vila> jelmer: the relationships between probers, control dirs, formats, the @classmethods and the base class calls via the class name instead of super()
<jelmer> vila: basically what's involved here is:
<jelmer> - The list of control dir formats, used by the test suite (ControlDirFormat._formats)
<vila> jelmer: I'm sure it's clearer when you're deep in the code ;)
<jelmer> - The list of known BzrDir formats (e.g. everything that has a unique string for .bzr/format) (BzrProber.formats)
<jelmer> - controldir.network_format_registry
<jelmer> and then there's BzrDir.register_format() which is a convenience wrapper to register a new bzrdir format, which takes care of registering it in the prober and in the control dir.
<vila> haa
<vila> worth a dev doc then (which is what I'm asking in my review ;)
<fullermd> Nah, just ship jelmer in the tarball   ;>
<vila> no way
<vila> a clone may be ?
<fullermd> Some people might accidentally make a checkout instead of a clone and wind up changing the original...
<vila> jelmer: hmm, but what do we really need ? A helper and a doc or a better doc and no helper ?
<jelmer> fullermd thinks I should be treated like a wild-west criminal? :-P
<jelmer> tar and feathers..
<fullermd> Just so, my fine feathered friend   O:-)
<jelmer> vila: I think the helper is useful, it gets called in quite a few places (even though it's just two lines)
<fullermd> (actually, tarring and feathering was an Eastern thing...)
<jelmer> fullermd: not according to the Lucky Luke comics I read!
<vila> jelmer: I'm trying to think like a newcomer here... (which I'm not... or am I ?)
<jelmer> fullermd: Or are you going to claim they're not historically accurate?
<fullermd> Ah, well then.  Far be it from me to gainsay such authority.
<vila> fullermd: +1 on jelmer readings
<jelmer> vila: hmm
<jelmer> vila: I wonder if we could perhaps do away with the ControlDirFormatRegistry
<jelmer> ehm
<vila> jelmer: it may just be a public/private thing to disambiguate but I;m not sure
<jelmer> the ControlDirFormat._formats registry
<fullermd> It was practiced during the Whiskey Rebellion, frex, which predated the existence of the West by some time.
<fullermd> Thus endeth fullermd's Random Historical Digression for the day   :p
<jelmer> fullermd: :)
<jelmer> vila: so, I see to alternatives to make the current situation simpler
<jelmer> vila: we could either add Prober.known_formats() and use that to discover the available control dir formats
<jelmer> or perhaps kill the helper in BzrDirFormat.register_format() and just have BzrDirProber.register_format() do what that helper does at the moment.
<jelmer> or moving BzrProber.formats to BzrDirFormat.subformats and killing any helpers on BzrProber
<vila> how many probers exist ?
<jelmer> vila: there's one that covers all local bzr formats, one that covers all bzr remote formats, one for local svn, one for remote svn, one for git, one for hg
<vila> right, so a given format can be associated with only one prober
<jelmer> my only concern with adding BzrProber.known_formats() is that a prober isn't necessarily that tightly coupled to a particular format
<jelmer> vila: exactly
<vila> and the main aim of a prober is to create format *objects* from a given transport
<jelmer> yep
<vila> So I'll tend to make it the main (or even only) entry point ro register a format
<vila> hmm
<jelmer> (well, currently from a given transport. In the future it could perhaps support creating format objects from a HTTP options reply, etc)
<vila> yeah
<vila> that was my 'hmmm' content ;)
<vila> I was thinking about tests too
<vila> so may be we should keep a separate registry and build the prober from the registry
<jelmer> I'm not sure I follow
<jelmer> we already have a registry for the available probers
<vila> and in that case, registration should transit via the prober
<vila> format registration
<jelmer> ah, so basically Prober.known_formats() ?
<vila> may be, I'm not sure I understand the implications
<jelmer> reconsidering this, I think that might indeed be the sanest solution
<jelmer> as it would in fact remove the need for both ControlDirFormat.register_format and BzrDirFormat.register_format.
<vila> ha ! I like that ;)
<vila> still not sure I follow every detail but this ^ sounds godd :)
<vila> jelmer: also seeing BzrDirFormat.register_format directly calls ControlDirFormat.register_format rang a hard-to-override bell
<vila> jelmer: sorry for the confusing/confused review but this code is really.... delicate
<jelmer> vila: np, you're absolutely right that this is confusing at the moment so I'm glad we could come up with a way to make it a bit simpler
<vila> jelmer: the other registries you introduced made the code clearer without doubt, here... this seems... incomplete ? It's hard to express, I feel you're going in the right direction but
<vila> I don't want to block this mp either if you think it's a good step, may be the whole approach should be rethinked
<vila> I still have the feeling that there should a simpler way and that this code didn't anticipate all today's usages
<vila> jelmer: but putting weave into a separate plugin should help anyway, so I'm +42 on your work
<jelmer> vila: thanks :)
<jelmer> vila: I've pushed a newer version (minus updated tests, etc). Can you tell me what you think of this alternative?
<vila> sure
<vila> jelmer: it leaves a better taste in the mouth now ?
<vila> err s/now/no/ ?
<vila> jelmer: why do you need to use a set() in known_formats() ?
<jelmer> vila: :)
<jelmer> vila: Just in case more than one prober returns the same format
<vila> does it make sense or would this be a bug ?
<vila> yeah, it could make sense
<jelmer> I think it would make sense. I don't want to tie the formats to particular probers too heavily.
<vila> even if it doesn't today one can imagine various ways to get to the same format
<vila> ok, so that needs a comment and some basic tests but I like it far better
<vila> if only because it removes a comment mentioning  a circular import ;)
<jelmer> vila: Which comment regarding a circular import?
<vila> 	-# registered. Putting it in remote.py creates a circular import problem.
<jelmer> vila: the one with regards to RemoteBzrDirFormat should no longer be valid
<vila> indeed, you've deleted it
<vila> or was it already deleted in the previous version ?
<jelmer> I think there's a communication mismatch here somewhere.. the comment no longer applies so why should it be kept in?
<vila> jelmer: I said: "I'm glad you deleted that comment"
<vila> oh,
<jelmer> ah, " ok, so that needs a comment and some basic tests but I like it far better" was what threw me off :)
<vila> I'd like you to *add* a comment about why you're using a set in known_formats()
<vila> yeah, I just realized while re-reading that I was referring to two different comments :)
<vila> to make matter worse one didn't exist and the other was deleted :)
<vila> confusion guaranteed !
<jelmer> vila: I think the other issue is that of deprecation
<jelmer> vila: I'd prefer to just get rid of these methods rather than deprecating them first, as it's very hard to provide backwards compatibility and the few users we have of the current mechanism can be patched to do the right thing.
<vila> yeah :-/
<vila> 2.4b1 will get out next week (IIRC) so we need to check bzr-loom too
<jelmer> bzr-loom shouldn't be affected as it doesn't introduce a new bzrdir format
<vila> ooh ! right !
<vila> so, just get in touch with the bzr-{svn|hg|git} plugin authors then
<jelmer> :)
<vila> jokes aside, I'm fine with getting rid of the methods, but it would be better to bring the subject on the list :-}
<vila> We may still encounter users that will upgrade bzr without upgrading the plugins so *they* need to get at least a proper error message
<vila> otherwise your karma will suffer (the real one, not the lp one ;)
<jam> vila, jelmer: I would like us to deprecate them in the short term, we can remove them after 2.4b1, that gives a small window for compatbility
<vila> jam: I think jelmer's point is that only bzr-{svh|hg|git} are using them and that he's willing to help the respective authors handle the compat in the plugins themselves (which I suspect is easier) rather than trying to do it in bzr, hence my compromise to at least blow up with a meaningful error message (which should also be easy to implement)
<vila> all in all, I'm all in favor of minimizing the effort for all parties involved
<wolfpack> I was working on a project and the main branch is there on launchpad. There is other developer who has branched the code and I have my one branch. I cannot push the branch because of network firewall. I can only upload the patch. How will the syncing of the code will take place as both us will be changing the code ?
<vila> wolfpack: simple things first:
<vila> wolfpack: if you can provide a read-only access to *your* branch, then your co-worker can push to lp and read from you
<vila> wolfpack: that's enough to provide you both access to all the needed data
<vila> wolfpack: otherwise, you can keep the trunk on lp and send bundles to your co-worker and it publish them on lp (after setting a mirror of your branch where he can apply the bundles)
<wolfpack> vila: Will this thing work?-> I will pull co-worker's branch after he pushes it, while continuing my work. After that I will upload the patch.
<vila> wolfpack: bundles are produced with 'bzr send', you  send one when you're ready to publish your changes and it will contain all the changes you've made
<vila> wolfpack: yes, upload my patch == send a bundle
<vila> except that the bundle can contain merges, commits and all the associated metadata (message, author, revision-ids, etc)
<wolfpack> vila: So sending bundles does not require ssh connection?
<vila> wolfpack: bundles are a bit more delicate to deal with if you can't share a public branch, but since you have lp to host multiples branches, you're fine
<vila> wolfpack: you send a bundle by *mail*
<vila> wolfpack: or any other mean, it's a text file
<wolfpack> vila: Thanks
#bzr 2011-03-11
<glyph> is there a 'bzr st --no-ignore' or equivalent?
<beuno> glyph, maybe bzr ls --ignored?
<spiv> glyph: there's the separate 'bzr ignored', but I guess you're after what bzr thinks of all files in a given directory?
<spiv> (if so, 'bzr ls' with various flags is probably the way to go)
<spiv> glyph: Also, '--no-ignore' is pretty much what bzr st already does: show no ignored files ;)
<glyph> spiv: "no ignores" not "no ignored" :)
<glyph> spiv: I want a complete enumeration of all files, with none of them ignored, to do something programmatic (in a shell script) to a bzr working tree.
<spiv> glyph: bzr ls -iVuR, perhaps with added -v
<spiv> And -0
<spiv> What's the something, out of interest?
<glyph> huh.  What's 'V' mean in that output?
<glyph> spiv: revert for reals
<glyph> spiv: an operation which, curiously, no version control system implements
<spiv> glyph: 'bzr revert && bzr clean-tree --detritus'?
<glyph> spiv: <3
<spiv> :)
<glyph> nope, still doesn't quite work
<glyph> it doesn't delete '.moved' directories, apparently.
<glyph> oh wait, no, it works
<glyph> I just wanted 'bzr clean-tree --unknown --detritus --force'
<spiv> (FWIW, the 'V' in that output means 'versioned', I think)
<spiv> (not that you care now :)
<glyph> wait no... 'bzr clean-tree --ignored --unknown --detritus --force'
<glyph> why isn't that the default
<glyph> you could make the default behavior be invoked via 'bzr clean-tree --not-really'
<spiv> By default it deletes unknowns.
<spiv> While leaving potentially valuable ignored files.
<spiv> Arch had a sometimes useful distinction between 'junk' (always safe to delete) and 'precious' (not versioned, but don't delete automatically)
<spiv> I occasionally wish we'd kept that, although I think probably that level of complexity probably does users more harm than good.
<spiv> And of course no categorisation is ever perfect: sure .pyc files are almost always junk or explicitly versioned, but maybe you don't want your vcs to randomly delete .o files that are expensive to rebuild.
<spiv> Except when you do...
<spiv> Anyway, I'm glad I've saved you from some shell scripting :)
 * spiv -> lunch
<glyph> hrm
<glyph> you may have saved me even more than you thought
<glyph> does this work for svn too?
<spiv> Probably!
<glyph> Haha it does
<glyph> _rad_
<glyph> oh crud, except there _are_ like 2 dotfiles I want to not delete
<spiv> glyph: easy!
<spiv> Just copy those files to /tmp and back :P
<spiv> glyph: actually, if you want to be slightly cunning,
<spiv> glyph: 'bzr revert; bzr add .dotfile1 .dotfile2; bzr clean-tree --yadda-yadda; bzr rm --keep .dotfile1 .dotfile2'
<glyph> spiv: Cute.
<spiv> There's no point doing the add before the revert, of course :)
<glyph> spiv: I already implemented the other thing, but I might switch to that.
<spiv> (The --keep is redundant in this case too, but explicitness and paranoia doesn't hurt)
<glyph> spiv: you forgot the last 'bzr revert', too ;)
<spundun> hi all... quick question
<spundun> if I do bzr checkout URL
<spundun> or I do bzr branch URL wd; cd wd; bzr bind URL
<spundun> it seems to have the same effect
<spundun> am I understanding that right?
<spundun> change the first version to bzr checkout URL wd
<glyph> spundun: Yes.
<glyph> spundun: 'bzr checkout' is an alias for creating a bound branch to make it easier on people who are familiar only with svn.
<glyph> If you just s/bzr/svn in your commandlines, everything basically works if you don't think too hard about it :)
<spundun> ah, ok
<spundun> I find the concept weird that I create a branch using bzr branch URL, and then within that branch I can just do bzr push URL, then I'm not reall a branch anymore, I'm the trunk :/
<spundun> by I, I mean my branch
<glyph> spundun: But it is a branch: if you commit to it, it won't get committed to trunk.  You could push it somewhere else on the server, if you didn't want to push those revisions to trunk.
<spundun> yes, I get that. But somehow in my mind, I shouldn't be able to push my branch back to the trunk, I should have to merge it or something...
<glyph> spundun: consider: bzr get ...:.../trunk; cd trunk; hack hack hack; cd ../; mv trunk my-feature-branch; bzr get ...:.../trunk; cd trunk; bzr merge ../my-feature-branch
<spundun> ok
<spundun> I guess the more I think about it, the more I'll get used to the idea
<spundun> or something like that
<spundun> thanks glyph
<glyph> spundun: another way to think of it is that initially, a branch is a perfect copy of the thing it's a branch of.  you can push/pull between them to re-synchronize them, assuming they haven't diverged.  A merge is only necessary to resolve the conflict that occurs when two branches go in two different directions.
<glyph> trunk isn't "special", it's just a branch in a particular place that you've socially agreed is important to a project.
<spundun> right, ok
<jam> morning all
<vila> oops, morning jam et all ;)
<jam> I thought it was "et al"
<vila> jam: do you know how doc.bazaar.canonical.com scripts are handled ?
<vila> argh, yes, it *is* et al
<vila> thinko between english, french and latin ;)
<fullermd> Just blame it on a typo.  We'll all believe you   :p
<vila> hehe
<vila> are 'al' and 'all' pronounced the same in english ?
<bob2> no, latter is more like awl
<fullermd> Not out of my mouth..
<fullermd> But 'al' isn't English, so it's a trick question, really...
<bob2> it's a (short) name ;
<bob2> )
<jam> bob2: I've always pronounced "et al" as in "pet" "all"
<jam> And I agree more like "awl"
<jam> doesn't mean I pronounce it correctly
<bob2> hm, I say et al(lan)
<bob2> possibly people are too polite to correct me ;p
<jam> http://www.thefreedictionary.com/et+al.
<jam> says it is supposed to be "et alii"
<jam> or et alia
<vila> let's add some confusion: 'etal', in french, is where butler cut the meat ;)
<bob2> I have even less idea how to pronounce et alli!
<vila> bob2: probably like Italy ;)
<bob2> haha
<vila> mass_import.py up to 812M resident memory, "something" is leaking or python is *really* bad to manage its heap
<lifeless> 'manage'. lol.
<jam> vila: 812MB for the driving script seems pretty excessive
<vila> in other news nexuiz-data is still happily running at 100% CPU without producing any data in its log :-/
<vila> jam: right, even 100M would seem excessive...
<vila> lifeless: was the joke targeted at python or at my poor english (I guess the former but just checking) ?
<jam> vila: python, as I understood it
<jam>  /wave lifeless
<lifeless> python
<lifeless> hai :)
<vila> I can't remember if mass_import was already consuming that much memory when running for weeks before my driver changes...
<vila> jam: any idea about poking at a running python script with meliae ?
<jam> vila: if you can get a pdb console, you can get in with meliae
<jam> I think there are some gdb tricks you can pull ,but none that I really know
<vila> k, thanks
<jam> I think Andrew mentioned using gdb to interrupt, then set trap at the trace function
<jam> and then install pdb at that point
<jam> that way you know you aren't interrupting the middle of a python OP code, etc.
<vila> I think we should just kill this import then and try to reproduce the issue locally
<jam> spiv^^?
<jam> vila: you mean nexuis?
<vila> yup
<jam> if you had console access, bzr already installes SIGQUIT => pdb
<jam> but I don't think you have console access to the builder process
<vila> given it has been spawned from a cron script, I doubt I can get console access yes
<vila> the disturbing fact is that the log file hints that we are in the middle of a bzr operation
<vila> a commit
<jam> vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log.
<vila> 10 days to process a commit is probably considered excessive too :)
<jam> It wouldn't be hard to create if you think it would be helpful
<jam> vila: we may be inefficient, but 10 days is a little rediculuous
<jam> I would say 1 hr is max, even for nexuis-data
<vila> oh, sorry, I've been slightly exaggerating, it's 99% CPU not 100
<fullermd> Oh, shucks, you made a new release...
<jam> vila: well in that case, it is clearly not blocked :)
<vila> jam: :)
<vila> fullermd: yeah, by the way, any hint about why bzr-duilder is packaged for FreeBSD ?
<fullermd> 'cuz C-S packaged it.
 * fullermd glances at logs.
<fullermd> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/149891
 * vila has no idea who Control-Super is...
<jam> Better than Meta-Super, that guy is a jerk
<vila> I'm pretty sure it requires some debian dependencies...
<vila> if not Ubuntu dependencies for that matter
<LeoNerd> jam: He recently escaped
<vila> LeoNerd: ha ha
<vila> using an alternate exit ?
<vila> . o O (Slowly but inexorably emacs progresses on all fronts ;)
<fullermd> If you're all through bucking around...
<vila> Sawhorse Saw"horse`, n.
<vila>  A kind of rack, shaped like a double St. Andrew's cross, on
<vila>  which sticks of wood are laid for sawing by hand; -- called
<vila>  also buck, and sawbuck.
<vila>  [1913 Webster]
<vila> I'm so much informed now :(
<vila> no idea about what a *single* St Andrew's cross is...
<fullermd> It's half of a double St. Andrew's cross.
<vila> interesting google images results... http://www.google.com/search?client=ubuntu&channel=fs&q=St.+Andrew%27s+cross&ie=utf-8&oe=utf-8
<vila> I meant the union jack flag origin of course..
<vila> adding double to the search terms amazingly returns images with... two crosses... how smart... NOT !
 * fullermd declines to enquire into where vila's mind wanders...
<lifeless> 'double rainbow'
<vila> what with the old mails spam from lists.ubuntu.com ?
<catphish> morning
<vila> _o/
<catphish> _o/ high five
<catphish> you'll be relieved to know that i don't need any help today, everything is working nicely :)
<vila> yeah !
<catphish> hopefully i'm finished with being a pain for now
<vila> hehe, you're not a pain, this channel is here to provide help ;D
<catphish> and very helpful it is :)
<catphish> by the way, my implementation is for http://www.codebasehq.com/
<vila> why doesn't it mention bzr then :-p
<catphish> because it's not ready yet
<vila> good, better than the opposite :)
<catphish> we're making a bunch of changes, some of which are announced
<catphish> bzr support is not announced, just going to surprise people with it
<catphish> plus i wanted to be sure it was going to work
<jml> jelmer_: I saw your email to ubuntu-devel about showing authors
<jelmer_> jml: I've heard the same concern Dave come up a couple of times before. What do you think?
<jml> jelmer_: It reminded me of things I've wanted to do with bzr-stats
<jml> jelmer_: get # of landings rather than # of commits.
<jml> jelmer_: and it would make 'bzr log' way more useful for PQM-managed projects
<jelmer_> jml: Yeah, indeed
<jml> hmm.
<jml> I wonder how interesting it would be to do it in a plugin
<jml> jelmer_: fwiw, I'd propose this output: http://paste.ubuntu.com/578777/
<jelmer_> jml: I think we should have all the magic in place to do it in a plugin
<jelmer_> "bzr log --format=boo"
<jelmer_> that would be an interesting experiment
<jelmer_> maxb: Do you have any thoughts on how we should deal with the dh_python2 transition ?
<jelmer_> maxb: I guess we could either create separate recipes for the older distro series, or patch all of them to avoid dh_python2.
<jelmer_> maxb: I'd prefer doing the first, otherwise we'll end up doing the patching forever.
<vila> jml, jelmer: Are you talking about adding authors at commit time or extracting them at log time ?
<jml> vila: extracting at log time
<vila> as jelmer mentioned there are perfs issues (so far) and in the context of pqm, I think adding the authors at commit time would make far more sense no ?
<jelmer_> vila: I think that would use up precious space in the revision text for some projects, and it wouldn't help with historical and foreign data
<jelmer_> if it's too much of an issue I think a cache would be the best approach
<vila> hmm
<vila> jelmer_: I was talking about *always* adding authors, only for projects that want it (and I was thinking plugin there, not core)
<vila> s/was/*wasn't*/
<vila> !
<jam> vila: if you have -n0, then you have the information easily available
<vila> sure, I thought the issue was to *not* use -n0 nor the implied perf penalty
<jam> vila: without it, perf is going to suck quite a bit more, in semi-common cases
<vila> and ISTR that adding author in pqm context was mentioned in the past too
<jam> determining non-common ancestors is pretty hard
<jam> and doing it over-and-over again for each rev is pretty bad
<vila> yeah but one day we'll have to fix that once and for all
<jam> vila: could you do that tomorrow?
<vila> it's on my TODO list, but pretty much at the bottom unfortunately
<vila> I just find it annoying that we keep spending time on workarounds :(
<maxb> jelmer_: I've not thought about it - I'm planning to study the situation and form an opinion over the weekend
<jelmer_> maxb: ok, I'll hold off for a bit then
<jelmer_> jam: Did you see my followup to https://code.launchpad.net/~jelmer/bzr-email/drop-pre-0.15/+merge/49628 ?
<jam> jelmer_: approved
<jelmer_> jam: Thanks
<jam> I did see it, but just didn't have anything else to add. "approve of the rest" covered my feelings, though it wasn't explicit
<awilkins> Do people think that branching  a working tree at a given revision should branch from that revision even if it's not the tip of the branch for that working tree?
<jelmer_> jam: ah, ok
<jelmer_> awilkins: That's a tricky one
<awilkins> e.g.   bzr update -r N # where N is less than P which is tip revision ; bzr switch -b newbranch ; bzr revno # emits P not N
<jelmer_> awilkins: It would be useful to warn the user in that situation.
<jelmer_> awilinks: That said, I think it might require opening the dirstate file to figure out the revno of the working tree
<awilkins> jelmer_, A valid story would be - I bisected to find a bug, now I want to branch the revision that introduced it to fix it ala DaggyFixes
<awilkins> jelmer_, Probably, I know that qlog does something to work out the current revision because it marks it in the log
<awilkins> jelmer_, For switch -b it must be doing it anyway because it merges the new branch (at HEAD) to the one you have so you end up with a working tree of HEAD
<jelmer_> awilkins: Yeah, but not for e.g. "bzr branch <remote-location>"
<awilkins> jelmer_, No, I don't think that is intuitive
<jelmer_> awilkins: So, I think it makes sense to warn the user if they try to branch from a location where there are both a working tree and a branch with the tip out of sync
<awilkins> jelmer_, I think I'm really only thinking about local branches and lightweight checkouts
<jelmer_> awilkins: I don't think we should be inconsistent in the way we treat local and remote branches
<awilkins> jelmer_, I agree that's a useful warning ;  I found the idea that once I had updated my lw checkout to a particular revision that switch -b would branch that revision to be intuitive and the result (branching the HEAD of the branch bound to the checkout) to be understandable but disappointing
<jelmer_> awilkins: Is there a particular reason why you're only switching your working tree rather than your working tree *and* your branch tip ?
<awilkins> The -b implies that I'm creating a branch tip and switching to it
<awilkins> Or are we driving at different things? My work setup is typically lightweight checkouts
<jelmer_> yes, but why do you use "bzr up -r" ? It causes the working tree tip and the branch tip to be different
<awilkins> In this case, I am bisecting somewhat manually
<awilkins> I have located the revision with the bug in it and wish to start a new branch with this revision at it's tip so I can fix it
<jelmer_> ah, hmm
<jelmer_> so perhaps we should allow you to do something like "bzr switch -b newbranch -rtree:"
<awilkins> I was just going to suggest bzr switch -b newbranch -r `bzr revision-info` ; but apparently revision-info does not respect dirstate
<jelmer_> awilkins: it has a --tree option
<awilkins> jelmer_, Aha, that's nice
<maxb> A dirstate-based revspec would be lovely though
<maxb> especially for access to pending merge tips
<jelmer_> yeah
 * jelmer_ files teh bug
<awilkins> Ah, and switch -b -r does not behave as you'd want
<jelmer_> yeah, please file a bug about that
<awilkins> $ bzr switch -b -r 201 fix-update # Tree is up to date at revision 233.
<jelmer_> well, you'd want an argument to -b
<jelmer_> ah, you have - sorry
<awilkins> Ack
<awilkins> Ah, yes, not an arg to be, arg to command
<awilkins> It doesn't respect the revision argument for either case, branching or non-branching
<mgz> <jam> vila: We've talked about a SIGUSR1 or SIGHUP handler that would just dump "traceback.format_tb()" into .bzr.log. <- there's still a good chance this would kill the ongoing operation, given how dodgy signals are
<vila> mgz: true and hi !
<mgz> and SIGTERM already dumps the current stack as it exits, right?
 * mgz waves at vila
<vila> hmm, that would at least gives us a hint...
<vila> fullermd: I'd like to install sphinx for some tests, but it seems it's available only for py27 :-/
<vila> fullermd: I don't want to play around with 2 different versions of python on my babune slave, so, is bzr packaged for 2.7 and if not when/why/what ?
<vila> ha, finally the true jelmer is back...
<jelmer> heh
<jelmer> I had a nouveau freeze :-/
<vila> hmpf
<awilkins> Are the docs on the website in the main source tree? I've spotted a bug asking for some clarification in the Visual Sourcesafe docs I wrote but I can't remember where the doc sources are ....
<maxb> doc/... :-)
<jelmer> awilkins: most of the docs live under doc/en in lp:bzr
<vila> awilkins: it depends, but doc.bazaar.c.c are mostly in... too slow for jelmer :)
<jelmer> vila: and for maxb :)
<vila> errk, didn't even saw this one ;D
<vila> on the other hand, the shortest answers came first :)
<awilkins> Yeah, can't find http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html there though.
<awilkins> I should know, I wrote it
<awilkins> Gah
<jelmer> heh
<vila> parent branch: http://bazaar.launchpad.net/~bzr/bzr-migration-docs/trunk/
<awilkins> Aha
<vila> jelmer: thanks for the review !
<jelmer> vila: np
 * jelmer resubmits his lazy-bzrdir branch
<jelmer> maxb: Hmm, weren't all the issues with running the bzr-dbus testsuite on a buildd fixed now?
 * jelmer is still getting failures building for sid
<maxb> Well, the recipe build seems happy
<maxb> Got a link to the sid buildlog?
<jelmer> there isn't one - I'm building locally
<jelmer> I'll pastebin
<jelmer> maxb: http://pastebin.ubuntu.com/578852/
<maxb> ah, I remember that test, that's the one which tries to connect to a dbus session bus running outside the context of the build
<maxb> http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk/revision/47 was my attempt to skip it when appropriate
<maxb> I guess my "when appropriate" check isn't working out quite right for you
<jelmer> actually, I see what's happening
<briandealwis> spiv: I've been seeing if I could duplicate that strange locking problem.  Doesn't work on a cooked up example.  But it always happens with a particular branch.  -Dlock doesn't show anything out of the ordinary (to me).  Are there any other debug switches I could try?
<jelmer> briandealwis: I bet spiv's asleep
<jelmer> briandealwis: if this is a bzr+ssh:// issue you were trying to debug -Dhpss might help
<briandealwis> ah, he's showing green
<briandealwis> It's a local issue.
<briandealwis> I have two branches, p1 and p2 that have a common ancestor.  Trying to push from p1 to p2 results in a strange self-locking problem
<jelmer> maxb: fixed it by starting a temporary dbus session
<briandealwis> I wasn't having this problem in 2.2.x; maybe I'll try some bisecting.
<mgz> briandealwis: what's the bug number?
<briandealwis> mgz: haven't filed a bug yet, sorry.
<briandealwis> mgz: will do that next
<briandealwis> mgz: finally filed as bug 733350
<ubot5> Launchpad bug 733350 in Bazaar "LockContention error when pushing to a bound branch" [Undecided,New] https://launchpad.net/bugs/733350
<jelmer> vila: Thanks for the review, I'll add some docstrings.
<jelmer> vila: it's not just bzr-svn that adds itself to the beginning of the server prober list, bzr-hg and bzr-git do as well
<vila> jelmer: thanks for your persistence there ;)
<vila> jelmer: one more reason to discuss a saner scheme, the issue has existed for far too long
<vila> jelmer: and even if your work allows more lazy loading, ISTM that bzr-svn users still pay a penalty when they work with bzr branches only right ?
<jelmer> vila: they do an extra OPTIONS request when talking over http, but that's all at this point
<jelmer> I added some hacks to do that OPTIONS request over the existing HTTP connection, rather than building up a new connection.
<vila> jelmer: and you manage to not load any modules that won't be needed if the probe fail ?
<vila> . o O (I'm tired, I'm sure this could expressed in a simpler way :-/)
<jelmer> vila: yes, that's the point of the probers. the prober implementations live inside the plugin __init__ and only load the actual stuff when they find something
<vila> ha ok, so the lazy loading addresses the remaining issues then
<vila> jelmer: about the OPTIONS stuff, wibni (once you land you hacks in core ;) the smart server was adding its own option too ?
<jelmer> vila: what's wibni ?
<vila> Wouldn't It Be Nice If ? or did I mangled that ?
<mgz> briandealwis: is that info at the bottom for the trunk branch? if so, the push branch value is odd, try editing .bzr/branch/branch.conf to remove it
<jelmer> vila: no, you didn't... just an acronym I didn't know yet :)
<briandealwis> mgz: you're right, I made a mistake: it's from the workspace branch
<jelmer> vila: Yeah, it'd be nice to add an OPTIONS entry for the bzr smart server.. though we should probably still support the POST request in case the user is e.g. using a cgi script
<briandealwis> mgz: I've been able to reproduce the issue from a synthetic branch â it hinges on tags
<vila> . o O (There you are, people are so used to your tyops that they see tyops even when you type correctly)
<mgz> okay, in which case the odd thing is is *also* thinks it a checkout of backup?
<mgz> that's not intended surely
<vila> jelmer: sure and for older clients too, but still
<mgz> tags being what's broken seems likely, spiv added some new behaviour there.
<briandealwis> mgz: I bind "trunk" to "backup", where "backup" exists on a different drive.  So pushes to "trunk" are backed up
<mgz> but the fix for you should probably just be editing a conf file.
<mgz> briandealwis: but what is 'workspace'? A normal branch? a checkout?
<briandealwis> mgz: a normal branch
<mgz> the info posted is of a checkout.
<briandealwis> mgz: now I'm confused :)
<mgz> `bzr info` on workspace should say it's parent branch is trunk, and have no checkout bits
<mgz> `bzr info` on trunk should have no parent branch, and say it's a checkout of backup.
<mgz> `bzr info` on backup should just say it's a normal branch.
<briandealwis> mgz: I was right originally: it was from "trunk"; that was info carried when branching from my original branches
<briandealwis> mh	
<briandealwis> mgz: I removed the stray info, and it makes no difference
<briandealwis> mgz: I'll add a synthetic example that demonstrates the bug in a sec
<mgz> ah, you've got one now?
<briandealwis> mgz: yeah â it's all about pushing with tags
<briandealwis> mgz: I used bisect to identify the problematic commit.  if you look at it, it adds some locking.
<mgz> yup, I can repo too with that.
<vila> jelmer: I'm very tempted to give you the green light to land all the weave-in-a-plugin stuff
<jelmer> vila: \o/ Did you see the intermediate branch, bzrdir-weave ?
<vila> jelmer: since you raise an error if the old_register_format is used, the worst that can happen is that people running trunk will have to revert if they encounter issues
<vila> jelmer: did you see my reviews ;)
<jelmer> clearly I haven't :)
<vila> jelmer: and I'm sure you will be motivated to fix any bugs if that's the case
<jelmer> yeah, of course
<briandealwis> mgz: I tacked on the example
<mgz> yup, that's similar to what I got to fail.
<vila> jelmer: with 2.4b1 close to freeze, I tend to prefer landing now than wait for a second review which will requires more effort from the reviewer than your own efforts to fix the hypothetical fallouts
<vila> mgz: any progress on https://code.launchpad.net/~gz/bzr/create_delta_index_memoryerror_633336/+merge/52251 ?
<jelmer> vila: sounds good to me - most of it is just moving code around now anyway
<vila> mgz: I didn't review closely but I was wondering if your actual fix was already viable ?
<mgz> yeah, I'm going to give in and rewrite those two functions to take **struct and return a code rather than *struct
<mgz> it's a bigger change, but there's no point trying to keep a limited api when they need sensible error handling.
<vila> mgz: ha ! Yeah, when you're tired to override, using distinct objects help express better semantics ;)
<mgz> darnit, what's the trick for getting the mainline rev a dotted rev was merged in? I always forget it and give up and use qlog instead.
<vila> mainline: ?
<mgz> http://paste.ubuntu.com/578908/ <- and the number of times I do this as well, env-variables is particularly painful
<vila> mgz: bzr help topics
<mgz> yeah, but `bzr help topics | grep env` is just as annoying to type every time
<vila> mgz: which is itself mentioned in 'bzr help'
<vila> oh
<mgz> so, I try and remember and get it wrong a few times.
<mgz> why, for instance, is 'environmental' abbreviated, but 'variables' is not?
<vila> yeah, this needs to be reworked, revisionspec is another bad example
<maxb> It should probably be 'environment-variables' with an alias of 'envvars'
<vila> or may be bzr-guess could be extended to handle help topics and merge in core
<vila> merge*d
<vila> I thought Parth worked on a bit on that at some point...
<mgz> ^thanks, mainline works, presumably new in 2.2 or 2.3 though.
<vila> yup, I'd say 2.3
<mgz> right, I need some food, then I'll write a little code.
<vila> mgz: mah, my memroy was bad, help topic guessing has been *disabled* in revno... 2 :-(
<jelmer> vila: argh, test isolation failure :-(
<vila> jelmer: caught by pqm ?
<jelmer> vila: yep
<vila> which branch ?
<jelmer> vila: lazy-bzrdir
<vila> k
<jelmer> vila:  bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server happens to fail because the returned control dir suddenly has its repository format set to 2a
<jelmer> the cause seems to be the fact that we now run the per_controldir tests against RemoteBzrDirFormat
<vila> ah
<vila> why do you suspect an isolation issue ?
<jelmer> vila: I can reproduce it locally. "./bzr selftest -s bt.test_remote" succeeds, "./bzr selftest -s bt.per_controldir -s bt.test_remote" fails
<vila> arg
 * jelmer wonders what the best approach is to debug this sort of thing
<vila> they are all painful
<vila> :)
<jelmer> is there any particular function that gets called after each test?
<vila> probably, never tried that approach though
<vila> what I generally do is establish a list of tests including the failure and bisect it
<maxb> jelmer: Concerning bzr-rewrite packaging - is it correct to drop the "Replaces: bzr-rebase" whilst retaining the Conflicts?
<vila> jelmer: as an aside, just trying to run bzr with my current trunk of bzr-hg crashes with NotImplementedError: <bound method type.known_formats of <class 'bzrlib.plugins.hg.HgProber'>>
<vila> --no-plugins time is back :-/
<vila> seems to be in bzrlib.tests.per_controldir.test_push.TestPush
<jelmer> vila: Can you try again with trunk?
<vila> try what with which trunk ?
<vila> don't lose focus on the crash, different people will have different issues, we'll see later :)
<vila> bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty
<vila> ./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server
<vila> is enough to reproduce
<vila> puzzling
<vila> as often with isolation issues...
<jelmer> vila: I think I found the test isolation issue
<vila> yes ?
<jelmer> one of the fallback cases for RemoteBzrDirFormat modifies the RemoteBzrDirFormat in-place
<jelmer> in some of the other cases we use .__class__() to create a new copy and modify that
<vila> evil
<jelmer> ./bzr selftest --no-plugins -s bzrlib.tests.per_controldir.test_push.TestPush.test_push_new_empty -s bzrlib.tests.test_remote.TestBzrDirCloningMetaDir.test_current_server passes in bzr.dev for me
<jelmer> since you mentioned bzr-hg earlier, are you sure you mean with --no-plugins ?
<vila> pass for bzr.dev here
<vila> even without --no-plugins
<vila> crash in the lazy-bzrdir without --no-plugins
<vila> revo 401 for bzr-hg
<vila> jelmer: gotta go, happy hunting :-}
<fullermd> vila: *yawn*
<fullermd> vila: py27 was actually switched to the default earlier this week...   I haven't pulled the switch yet.
<fullermd> vila: 'member you're _building_ via ports, so it's not a question of 'packaged against'; it builds against whatever you've got installed.  So switching to 2.7, and rebuilding py* and bzr (maybe 1 or 2 other bits?) would do the job.
<vila> fullermd: thanks ! My notes from the py26 upgrade says: http://paste.ubuntu.com/578954/
<vila> fullermd: so, IIUC, I should do the same, I may a bit for things to settle down in ports no ?
<fullermd> Pretty much, just s/26/27/ and s/25/26/ all 'round.
<vila> k
<vila> I should really go now, gf is waiting ;)
<fullermd> It should probably be OK, else they wouldn't have pulled the default switch.
<vila> k, I'll do a vm backup first anyway
<catphish> evening
<catphish> does anyone know how i might go about converting a filtered-139770606741392:// url to a real path?
<jelmer> hi catphish
<catphish> hi jelmer
<jelmer> catphish: I have no idea, where are you getting that URL from?
<catphish> your code ;)
<jelmer> I doubt it's *my* code :)
<catphish> the (c) has your name in lol
<catphish> anyway, its changeBranchTipParams.__dict__['branch'].base
<catphish> in a hook
<jelmer> catphish: hmm, which file is that?
<catphish> shell-hooks
<jelmer> oh, that's just coming in from an external source e.g. a smart server
<catphish> correct
<jelmer> it's unrelated to the shell hooks plugin
<catphish> your original hook didnt support the changeBranchTipParams hook
<catphish> so i don't suppose it ever came accross data from an external push
<catphish> anyway it's branch.base
<catphish> and it returns: filtered-139770606741392:///default/
<jelmer> I think it predates the changeBranchTipParams hook
<catphish> makes sense
<catphish> i assume it's a type of chroot
<jelmer> yep
<catphish> do you have any thoughts how i might map it to the real path?
<jelmer> have a look at branch.root_transport
<jelmer> it's probably some sort of special transport that wraps the actual transport
<catphish> hmm, i don't see branch.root_transport
<catphish> ah, its a PathFilteringTransport
<maxb> I was looking at this stuff just recently
 * maxb tries to remember things
<catphish> i'm a little confused by why instance methods accept self as the first parameter, i'm not a python developer but that seems odd
<maxb> catphish: Unlike most languages, Python chooses to pass the instance reference as an explicit first parameter, which is conventionally called self
<maxb> Rather than defining a special keyword for it
<maxb> I suppose you could call it "this" instead of "self", but then anyone else reading your Python code would look at you very strangely
<catphish> so it is normal to call: object.method(object)
<catphish> ?
<maxb> No, when you call it, magic happens, and the reference is provided implicitly
<catphish> i understand :)
<maxb> Or, to be slightly more truthful, when you reference object.method, what you get is not the raw method object, but is a *bound* method - a wrapper that inserts the object reference before passing on the call
<catphish> ok
<catphish> PathFilteringTransport seems reluctant to give up its absolute path
<catphish> when asked, it raises filtered-140259821971344:///default/.bzr/branch is not a local path
<maxb> I am investigating a possibility....
<catphish> thanks
<catphish> ah, external_url perhaps
<maxb> yes
<catphish> awesome
<catphish> external_url returns a raw file:// url
<catphish> sexy
<maxb> :q
<maxb> oops
<maxb> catphish: note that external_url() may return a readonly+file:// url if the server is running in readonly mode
<catphish> good to know
<catphish> though in my case that will never happen
<catphish> since a read won't trigger my hook
<catphish> but i might as well write the plugin to handle it
<catphish> all working now, thanks
#bzr 2011-03-12
<zyga> hi
<zyga> is bzr join --reference documented anywhere?
<lifeless> its not supported yet
<zyga> lifeless, thanks, my eager friend found this command and managed to get some trees joined by reference but he could not push to a remote server so I started looking
<zyga> lifeless, what's the recommended tool to create a workspace out of multiple branches today?
<lifeless> probably bzr-scmproj
<zyga> lifeless, thanks
<XTF> Hi. What's the difference between bzr and bazaar on LP?
<maxb> XTF: Between https://launchpad.net/bazaar and https://launchpad.net/bzr ?
<beuno> XTF, bazaar is the super-project, which includes all its plugins and such, and bzr is just the client
<magcius> Is there something like rebase that will help me get two sequential commits that are independent fixes to be both on top of another branch?
<magcius> I'm a git user. I apologize in advance for any misused terminology.
<LeoNerd> replay?
<LeoNerd> merge?
<magcius> not quite a merge
<magcius> I have A-B-C. I want A-B and A-C.
<LeoNerd> Ah.. that's slightly awkward.
<magcius> bzr: ERROR: unknown command "replay"
<LeoNerd> You can arrive at A-B and A-C', where C' is a new commit containing the same change as C
<magcius> Sure, that works.
<magcius> C is going to contain some changes of B.
<LeoNerd> But it has its own different identity for 'missing' purposes
<magcius> Because they may have similar fixes.
<magcius> OK. So how do I do that?
<LeoNerd> bzr branch -r[revno of A] newBranch; cd newBranch; bzr replay -r[revno of C] ../pathToOldBranch
<magcius> where do I get bzr replay?
<maxb> It is part of the bzr-rewrite plugin
<LeoNerd> Er.. hrmmm. A fun and curious question
<LeoNerd> I don't see it in my list
<magcius> OK.
<maxb> It is a hidden comman, because jelmer says it needs a bit more polish before it goes fully public
<magcius> Thanks maxb and LeoNerd.
<maxb> * comand
<maxb> * command !
<LeoNerd> Ahhhh
<magcius> bzr: ERROR: Not a branch: "/home/jstpierre/Source/loggerhead/loggerhead-b/".
<maxb> LeoNerd: oh, seeing you here reminds me - were you thinking of going to any of the May bzr sprint?
<magcius> do I have to mkdir first?
<magcius> aha, bzr branch . -r432 loggerhead-b worked
<LeoNerd> maxb: Wasn't planning on, no.. what is it?
<maxb> I'm not entirely sure - was going to send an email asking for a bit more detail
<magcius> is there a command that will show the changes in the current revision?
<maxb> But given it's not far from Pimlico tube, it seemed worth considering :-)
<maxb> magcius: diff?
<magcius> is there a quick command for it?
<magcius> bzr diff -r-1... or something
<maxb> bzr diff -c-1
<magcius> aha
<maxb> is the same as -r-2..-1
<magcius> so
<magcius> uh
<magcius> replay didn't work, it just blindly made changes
<magcius> can I amend that commit to fix it up?
<magcius> some changes that I made in B that are required aren't in C
<maxb> Sounds to me like you should 'bzr merge -c whatever' the changes into a new branch
<magcius> huh?
<maxb> Something like
<maxb> cd ../loggerhead-b
<maxb> bzr merge -c 434 $OLDPWD
<magcius> sure
<magcius> see, there's no merge conflict or anything
<magcius> there's just two independent features
<magcius> they both have some shared changes
<magcius> I'd like to have both revisions share those changes, so I can put up a branch quickly and easily
<magcius> erm, put up two branches
<magcius> one for each feature
<magcius> This is where I would use git rebase or git commit --amend.
<magcius> and feature branches
<maxb> rebase == yuck
<magcius> It's useful to have a clean history.
<jelmer> magcius: What i generally do in cases like that is to create two copies of that branch with the two features
<maxb> No, it's useful to have a forged history :-p :-)
<jelmer> then in both I uncommit the changes, shelve the ones I don't need and commit in each branch
<maxb> git commit --amend == bzr uncommit; bzr commit
<magcius> that sounds painful
<jelmer> magcius: it's basically the same thing as what you're doing
<magcius> uh
<magcius> so I'm using bzr shelve
<magcius> how can I make the current change smaller?
<magcius> There's two independent changes in there. I want to shelve one of them. It's asking me about the whole thing.
<jelmer> unfortunately there's no way to split chunks atm
<magcius> ...
<magcius> all this is doing is getting in my way
<magcius> so, what's the workaround here?
<magcius> So... anybody got any more suggestions for me to fumble around and fail again with?
<magcius> It's not a particularly hard problem: I want 'fix for bug A' and 'fix for bug B' in two separate branches.
<magcius> I'm at "HEAD, fix for bug A, fix for bug B" right now.
<maxb> So, that's really simple then
<magcius> OK.
<magcius> Lay it on me.
<maxb> bzr branch lp:loggerhead fix-for-b
<maxb> cd fix-for-b
<maxb> bzr merge -c revno-of-b-fix:../existingbranch
<jelmer> maxb: : ?
<maxb> no?
<magcius> bzr: ERROR: Requested revision: 'before:434:../' does not exist in branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/loggerhead/
<maxb> oh, right
<maxb> bzr merge -c revno-of-b-fix:../existingbranch ../existingbranch
<jelmer> maxb: Is the :../existingbranch bit really necessary?
<maxb> jelmer: um, possibly not. I'm a bit fuzzy about what branch revspecs resolve themselves against. Sometimes it seems to be the operative branch, sometimes the current directory
<jelmer> maxb: Which ones /don't/ use the operative branch?
<maxb> Something which bit me at some point in the past :-)
<maxb> So, dh_python2.... I'm currently leaning toward packaging up some sort of shim that enables the unmodified sid packagings to build unmodified on older distros
<ScottK> If you're worried about trying to backport to lucid, you could probably come up with a backport of python-defaults that would be safe.
<maxb> yeah, lucid would probably be easy
<maxb> But currently we go all the way back to hardy
<ScottK> I don't think hardy would be much harder.
<ScottK> As long as you only backport stuff that affects buildilng with dh_ptyhon2 it should be safe and dh_python2 works with python2.5.
<maxb> It does sound doable
<maxb> Though we'd also have to sort out a problem with python-central that only seems to show up on hardy - it tends to fail to remove its symlinks when a package is being upgraded away from using python-central
<jelmer> re
#bzr 2011-03-13
<lifeless> maxb: thats probably because the maintainer script to clean them up is not present in the new package
<jelmer> maxb: hmm, I'm not sure I follow
<jelmer> maxb: some sort of shim?
<jelmer> hmm, odd
<jelmer> Bad Gateway error during recipe build :_/
<beuno> hi vila!
<beuno> any bzr devs around?
<vila> beuno: hey. No, I'm not really there, just relaunched xchat
<beuno> :)
<jelmer> hey beuno
<beuno> hey jelmer!  happen to be bored?  :)
<beuno> I'm working on a branch to add downloading tarballs to loggerhead
<beuno> lifeless pointed out that saving them to a dir to serve them isn't super optimal, but it seems I don't really have an (easy) choice with the way things are set up in bzr
<beuno> wanted some smarter eyes to confirm
<beuno> *download tarballs of revisions _from_ loggerhead
<beuno> bzrlib.export.export only takes a path
<jelmer> yeah, it seems like we should be able to improve on that
<jelmer> though we should watch out for keeping lp:linux tarballs in memory, too
<beuno> right
<beuno> I started digging in bzrlib, and it's not trivial to change this
<jelmer> it looks like there already is some support for writing to stdout
<beuno> oh?
<jelmer> '-' is treated specially
<jelmer> in bzrlib.export.tar_exporter
<beuno> ah
<beuno> interesting, I missed that
<jelmer> this might also be a good moment to fix some other related issues
<jelmer> bug 513752 and bug 711226
<ubot5> Launchpad bug 513752 in Bazaar "cannot export a zip archive to stdout" [Low,Confirmed] https://launchpad.net/bugs/513752
<ubot5> Launchpad bug 711226 in Bazaar "deterministic output for tar.gz exports with --per-file-timestamps" [Medium,Confirmed] https://launchpad.net/bugs/711226
<jelmer> (also cases where it would help if the exporters could write to an arbitrary stream rather than a specific file)
<beuno> hm, if I specify -, it creates a dir called -   :/
 * beuno nods
<jelmer> you need to specify the format I think
<beuno> right, that seems to work
<beuno> well, "work", now I need to capture stdout and stream that
<beuno> I suspect this may be harder to actually deploy on launchpad, though
<jelmer> beuno: urgh
<jelmer> beuno: we should just factor the relevant code out of bzrlib.export.tar_exporter
 * beuno nods
<beuno> doesn't seem too hard, it's just quickly getting out of hand  :)
<lifeless> beuno: a temp *file* would be ok
<lifeless> beuno: its a persistent temp dir I was whining about
<beuno> lifeless, ah, hi lifeless   :)
<beuno> lifeless, well, that makes things much simpler
<lifeless> a temp file will clean up when its closed
<beuno> lifeless, ok, so I'll fiddle with this stdout approach for a bit so at least I have it handy, and then change it to use a tmp path
<lifeless> beuno: tmp *file* specifically - tempfile.TemporaryFile
<beuno> lifeless, ack
<maxb> jelmer: So, what I was thinking was either a straight backport of dh_python2, or a fake dh_python2 executable or debhelper sequence file that would run pycentral instead
<maxb> Either way, a solution which does not require modifications to each package's packaging
<jelmer> maxb: sounds reasonable
<beuno> lifeless, so, since bzrlib.export only really takes a path, it seems I'd need to poke at bzrlib in order to use a TemporaryFile
<beuno> or capture stdout and write to this new tempfile
<beuno> or...  maybe this temp file has a path, which I guess it would
<beuno> of course it does
<lifeless> beuno: you may need to change bzrlib.export
<lifeless> beuno: TemporaryFile doesn't have a name
<lifeless> NamedTemporaryFile is not crash proof
<beuno> lifeless, no, but NamedTemporartFile... ah
<lifeless> NTF depends on __del__
<lifeless> if we kill the process - not unheard of :P - it will leak and slowly mess up /tmp
<jelmer> beuno: fwiw I've got a branch which should let you do what you need
<beuno> hmeland_, w00t!  that's great
<beuno> er
<beuno> jelmer, I meant  :)
<beuno> although, it kinda sucks for this feature to depend on a future bzr
<jelmer> it factors out the bit of bzrlib.export.tar_exporter that writes to the tarball, so it requires you to pass in a tarfile.tarfile object and a tree
<beuno> I guess I could hack in using stdout for older bzr versions, and the cleaner one for newer ones
<maxb> jelmer: Hi. Shall I file bugs to have the ftpmasters update the overrides for qbzr and wikkid, both of which got override disparity emails on their most recent uploads, or is that on your todo list?
<jelmer> maxb: Oh, I don't think I have seen those.
<maxb> jelmer: they went to you@debian.org and pkg-bazaar-maint@lists.alioth
<jelmer> maxb: wikkid probably should be web
<maxb> I think in both cases the package has it right
<jelmer> maxb: yeah
<maxb> i.e. wikkid s/vcs/web/ because its defining characteristic is being a wiki
<jelmer> maxb: if you can file bugs that'd be great
<maxb> will do
<jelmer> beuno: https://code.launchpad.net/~jelmer/bzr/export-tgz-711226/+merge/53183
<jelmer> hmm, like Launchpad Bazaar has an interesting definition of "easy" when it comes to bugs
<beuno> jelmer, \o/   thanks, I'll take a peak in a little while
<lifeless> beuno: 'peek'
<spiv> Morning folks
<arjenAU> mm-mysql: hey mark!
<jelmer> spiv: mÃ¸rning!
<spiv> jelmer: hÃ¯ :P
<maxb> jelmer: btw, I've just committed "Take 02_external_configobj out of debian/patches/series because it causes tests to fail." to the daily-ppa branch. Any thoughts on what we do about that for Debian?
<jelmer> maxb: submitting the fix to the python-configobj package
<jelmer> it's on my todo list but I haven't had time to do it yet
#bzr 2012-03-05
<vila> hello all !
<wgz> morninh vila
<vila> wgz: hey !
<poolie> vila, hi
<vila> poolie: hey !
<mgz> morning
<hno> how do I show the complete log messages of pending merges (merged but not yet committed)?
<quicksilver> bzr st -v
<quicksilver> ?
<hno> that gives the first line only.
<quicksilver> hno: good question.
<jelmer> hno: I'm not entirely sure how to do that either; 'bzr qlog' can show that info
<hno> jelmer, qlog can show uncommitted log info?
<jelmer> hno: yep, by default it will do so
<quicksilver> when your GUI tool can access information the commandline tools cannot, something has gone wrong with the abstraction layers ;)
<jelmer> quicksilver: :)
<jelmer> quicksilver: it's all exposed in the API, mostly just not exposed through the cli frontend
<quicksilver> yes, I recognise that
<quicksilver> so I didn't really phrase my objection correctly
<quicksilver> but in an ideal world the CLI client would, by definition, expose all the API functionality
<quicksilver> so shell script hackers can cobble together workflows
<quicksilver> maybe such people should just be python hackers.
<mgz> ...an ideal world consists of shell scripts cobbled together?
<jelmer> quicksilver: well, it is somewhat exposed
<quicksilver> almost
<jelmer> you can do "bzr st --show-ids" and then feed the resulting revision id into "bzr log -rrevid:REVID"
<jelmer> that's basically what qlog does, except it does it for you and in a graphically more pleasing way
<quicksilver> mgz: an ideal world consists of shell scripts joined orchestrated by fragments of elisp.
<quicksilver> jelmer: hmm, yes. Good!
<abentley> jelmer: daily builds of pqm are broken, but I can't even see what when wrong this time: https://code.launchpad.net/~bzr/+recipe/bzr-pqm-daily
<abentley> jelmer: Ah, looks like someone forced builds.
<jelmer> abentley: I don't think that happens just on forced builds
<jelmer> it also happens when the PPA queue is backlogged I think
<abentley> jelmer: I hadn't heard of that.
<jelmer> I've seen it happen quite regularly
<abentley> jelmer: Okay, we should probably fix it to drop identical requests.
<lamalex> is there a means for reverting the changes introduced in a previous commit?
<LeoNerd> merge backwards? replay backwards? uncommit?
<LeoNerd> pull from a previous version?
<jelmer> :q
<mgz> LeoNerd: in other words, lots of ways :)
<mgz> you probably want, to eg revert all changes introduced in revision 3, `bzr merge -r3..2`
<mgz> lamalex: ^
<lamalex> indeed, that's what i was looking for. i can never remember how the -r argument works
<mgz> merging the reverse of a rev does take a little mental leap
<jelmer> mgz: I think we should have a somewhat easier way to do this, it's a question that comes up quite regularly
<quicksilver> I normally go for bzr revert -r2; bzr commit -m "Reverting back to state of code from revision 2"
<quicksilver> is the merge version better?
<quicksilver> unless I do it before anyone cares about the history, in which case I go for bzr push --overwrite ;)
<mgz> well, the problem is there really are a bunch of different things people will want
<mgz> I'm not sure how well it'd boil down to a new friendlier command
<mgz> your revert method quicksilver is no good when there have been subsequent changes
<quicksilver> oh, I see "un-cherry-pick"
<LeoNerd> Surely cherry-unpick ?
<mgz> and reverse merging a revision also may not be the right thing if you want to reinclude that change later
<jelmer> quicksilver: yeah, 'bzr merge --reverse -c -4'
<quicksilver> yes, I normally start with  bzr diff -r2..3 | patch -p0 and then fiddle things until that works
<quicksilver> but I know vaguely that merge is better because of things diff can't represent.
<quicksilver> (why isn't there yet a recognised successor to diff for things which diff can't represent?)
<smoser> so what is the correct "UDD" way to store quilt 3.0 ubuntu branches ?
<jelmer> smoser: what do you mean with UDD in this context? for recipe usage?
<smoser> no
<smoser> separate.
<jelmer> UDD doesn't have anything special for quilt branches at the moment
<smoser> i have a package (euca2ools) that i previously managed quilt 3.0 and basically tried to force ignoraing of .pc in in version control
<jelmer> there has been talk about using bzr-looms to represent quilt packages
<smoser> i thought aht i had see barry mention improved behavior for quilt 3.0 branches somewhere.
<jelmer> yeah, newer versions of bzr-builddeb have improved support for merging branches that contain quilt patches
<smoser> ah.
<smoser> ok.
<smoser> so maybe i should just give up and let .pc be versioned
<smoser> i reallydislike that 'bzr diff' shows you diff of .pc files
<smoser> oh, and thakn you for your help on my recipe on mailing list also
<jelmer> personally, I keep patches unapplied for quilt packages that I maintain and I don't version the .pc directory
<jelmer> smoser: I guess it wouldn't be too hard to get 'bzr diff' to ignore changes under .pc/
<smoser> but then you can't rely on the importer to do that for you
<smoser> if you bzrignore the .pc
<smoser> each time it does the import for you, it screws things up
<smoser> at least i couldn't (iirc) cget it to actually respect my .bzrignore
<jelmer> it doesn't, as the contents of the udd branch is supposed to reflect what's in the archive
<smoser> right. so then i had to remmeber to push there each time.
<smoser> and if someone else uploaded...
<smoser> then issues.
<smoser> so i didn't like that
<smoser> i was hoping there was somethign better now.
<jelmer> there have been improvements with regard to quilt, but that's all related to merging of branches containing quilt
<jelmer> not with regard to the importer
<jelmer> personally, I think udd branches shouldn't have the quilt patches applied by default; that's hard to change now though
<smoser> i think i agree with you on that.
<smoser> but its just a pain if osmeone else updates and uploads
<smoser> then i ended up with broken importer i think.
<smoser> i dont know.
<smoser> it seemede like no easy way to get what i wanted
<smoser> so i'm apt to stop fighting bots
<jelmer> smoser: in what way is it a pain?
<jelmer> just because of the noise in 'bzr diff' ?
<smoser> i guess that was my largestt grevence.
<smoser> s/bad spelling/good spelling/
<jelmer> smoser: can you perhaps file a bug about that against bzr-builddeb?
<smoser> how would htat be a builddeb bug ?
<smoser> oh. does it have hooks. on 'bzr diff' ?
<jelmer> yeah, bzr-builddeb lso has the various hooks to improve the merging of branches that contain quilts
<smoser> jelmer, i think i'm not going to open a bug.
<smoser> its not straight forward
<smoser> bcause sometimes you'd wan tot see the .pc files in diff
<smoser> sometimes you wouldn't
<smoser> jelmer, there is no way to tell the importer that it should not store patch files applied, is there ?
<jelmer> smoser: I don't think you would ever want to see them, as long as they're consistent with what's in debian/patches/
<jelmer> smoser: no, there isn't any way to tell the importer that AFAIK
<smoser> yeah, i guess "as long as they're consistent with what's in debian/patches"
<smoser> but if you just import a patch, you'd potentially want to see that you updated those files.
<jelmer> smoser: wouldn't that show up as a change to debian/patches/X too though?
<smoser> it would, yes.
<smoser> but how else would you know to commit those files
<smoser> as they're being verisoned, you should commit them.
<smoser> (ie, if you were going to commit and push, rather than just let the importer do it)
<jelmer> if we're hooking diff, we can hook commit too
<jelmer> in other words, we should consider .pc/ metadata I think
<jelmer> metadata that we should keep up to date, but preferably not bother the user with
<smoser> ok
<smoser> its not a bug report i'm pround of
<smoser> proud of
<smoser> vbut
<smoser> bug 947337
<ubot5> Launchpad bug 947337 in bzr-builddeb (Ubuntu) "bzr diff with bzr-builddeb should ignore .pc changes in .pc" [Undecided,New] https://launchpad.net/bugs/947337
<smoser> (ie, not proud because it has no easy recreate or example)
<jelmer> heh, fair enough
<jelmer> it's a bug report though, not your phd thesis :)
<jelmer> thanks
<Rcart> hey there
<Rcart> I want to add a apport hook for mpd and downloaded the apport package
<Rcart> but the branch (bzr branch ubuntu:apport) is out-dated
<Rcart> when I do bzr update in the branch, it says up to date
<jelmer> Rcart: please file a bug against the udd project in launchpad
<Rcart> jelmer: great. Working on...
<Rcart> jelmer: "udd" does not exist in Ubuntu.
<jelmer> Rcart: it's not a package but a project, see http://launchpad.net/udd
<Rcart> yeah, but when I try to send the bug claims about that error
<Rcart> then I don't select a package before send it?
<jelmer> Rcart: actually, it seems for apport you probably want lp:apport
<jelmer> (rather than ubuntu:apport)
<jelmer> Rcart: https://bugs.launchpad.net/udd/+filebug
<Rcart> jelmer: bzr lp:apport works
<Rcart> jelmer: bug 947451
<ubot5> Launchpad bug 947451 in Ubuntu Distributed Development "apport branch OUT-OF-DATE" [Undecided,New] https://launchpad.net/bugs/947451
<Rcart> jelmer: thanks for your help (:
<poolie> hi all
<poolie> hi wgz?
<wgz> hey poolie
<bsd> Hi abentley.  Is there are way to export a patch for a particular pipe as a merge directive or something more solid than a patch?  I was wondering about file/directory moves and deletionsâ¦ kinda like a shelf?
<abentley> bsd: You should be able to export a merge directive with -r ancestor::prev
<jono> hi all
<jono> I just merged in a branch and deleted a directory (which was not required anymore) and bzr is complaining that it can't remove the dir as it is not empty
<jono> yet the directory is deleted
<jono> how can I fix this?
<jono> nevermind, fixed it
#bzr 2012-03-06
<jelmer> hi wgz, poolie
<vila> hi all !
<mgz> morning!
<poolie> vila, mgz, jelmer, hi
<wgz> shall we get the hangout started?
<poolie> yep
<wgz> I want to hear how the skiing was vila :)
<vila> hehe, bad during a deep learning phase and just great when I decided to enjoy it ;)
<jelmer> rats, forgot about the call
<wgz> http://lwn.net/Articles/485162/
<vila> jelmer: thanks for your attention to details ;)
<m1sc> hi. i've setup loggerhead, i am able to load the webinterface, but it fails to load a random selection of resources like .js files etc. (loggerhead 1.18.1)
<jelmer> m1sc: how are you running loggerhead?
<m1sc> jelmer: /srv/bazaar/loggerhead/serve-branches --host 127.0.0.1 --port 8082 --allow-writes --prefix /bzr/devel/ repos/devel/
<m1sc> (behind apache proxy - same behaviour without proxy..)
<jelmer> m1sc: does it work without the prefix perhaps?
<m1sc> jelmer: let me check..
<m1sc> jelmer: seems like the proxy is the problem - apparently some GET requests don't get through.. (at least serve-branches is logging only those requests for files not "missing")
<abentley> vila: it seems b.get_config().set_user_option('pqm_email', 'PQM <pqm@example.com>') doesn't work in bzr.dev r6480.  Do I need to explicitly save or something?
<vila> abentley: hmm, if pqm_email has been migrated to use config stacks, then only config stacks should be used to access it
<vila> abentley: more precisely: if the writes are done by config stacks, they may be delayed and the old config reads will miss the updates
<abentley> vila: this is test code that worked with 2.5
<vila> abentley: config stacks are available in 2.5
<mgz> abentley: try unlocking the branch
<abentley> vila: I know.
<abentley> mgz: the branch isn't locked AFAIK
<mgz> depending on how your test is written, you may want that to flush the changes
<mgz> there's an mp from vila where he changed a bunch of test cases that may be a useful reference
 * vila nods
<mgz> most of them could just be simplified, a few needing a bit of an extra dance
<vila> abentley: or re-open the branch ?
<abentley> vila: I'm re-opening the branch, and it's not seeing the value I wrote.
<vila> abentley: meh, I need to see more code then
<abentley> vila: It's bzr-pqm, test case test_lpland.TestSubmitter.test_set_message
<vila> but set_user_option() has not been changed so it should save
<abentley> vila: Sorry, that should be test_lpland.TestSubmitter.test_make_submission_email
<vila> no make_submission_email in pqm revno 85
<vila> ghaaa
<vila> 84
<abentley> vila: It's in 89.
<vila> abentley: it works if you s/get_config().set_user_option/get_config_stack().set/
<abentley> vila: that's nice, but bzr-pqm supports bzr 2.4 and earlier, so it won't work for this.
<jelmer> abentley: bzr-pqm already has some code that looks as bzrlib.version_info - any reason that wouldn't work here?
<abentley> jelmer: It would certainly be possible to add more compatibility code.  But this looks like a bug, esp. since it worked in 2.5
<vila> abentley: well, avoiding IOs means caching values, that's what you run into, you don't lock the branch for writing but still modifies its config, I don't remember production code allowing that and I had to fix several tests that were relying on the branch being writable
<abentley> vila: I believe set_option locks and unlocks.
<vila> the config file only, not the branch
<vila> and set_user_option also read and write the whole file
<vila> which is what we want to avoid
<abentley> vila: 1742: self.branch.lock_write()
<vila> ECONTEXT
<abentley> vila: bzrlib/config.py:1742: self.branch.lock_write()
<vila> ha, right, yes, that's what I was saying, this will read and write the whole file ignoring the the fact that the option has been migrated and should use the new code
<vila> you can't mix the two code paths for the *same* option
<abentley> vila: You said "you don't lock the branch for writing but still modifies its config, I don't remember production code allowing that".  This is production code that allows that.
<vila> right, that part was wrong :)
<vila> and the lines before 1742 also mentions that the approach used here needs to be fixed
<abentley> vila: Yes, but it's written by you, so it's no surprise it agrees with you :-)
<vila> hehe
<abentley> vila: the point is, I'm writing a value, then reading it, and it's not working.  If we really should not be using set_user_option, then it should be deleted from the API.
<vila> in ideal world, yes, but it cannot be removed until all plugins migrate to the config stacks
<abentley> vila: If it's not removed, then it needs to co-exist with config stacks properly.
<vila> well, avoiding IOs means caching values
<vila> you use one API to set and a different one to read
<abentley> vila: That may be, but the branch is unlocked, and I haven't accessed any config stacks when I write.
<wgz> I was under the impression the old apis would function as before,
<wgz> and the benefits to fewer config disk reads would be limited to code using the new interface
<abentley> vila: If you can't use one API to set and a different one to read, then the API should be removed.  Otherwise, people are going to do it by accident or laziness.
<wgz> if a (non-bogusly written) test is failing with the old interface, how sure are we plugins won't also break?
<vila> I think what happens here is that 'pqm_email' is read with the new API
<vila> wgz: we can't be sure but that's the first report I hear about where it fails
<vila> Overall, we *read* options in 99% of the cases and migrating an option to the config stacks should be done for both the code and the tests
<vila> the alternative is a big switch day which has been vetoed long ago
<vila> it's also why I landed this change in 2.6 so we have a full cycle to debug the issues
<wgz> that seems fair
<wgz> we do want a way to write config tests that will work across multiple bzr versions though realy
<wgz> jelmer: (unrelated to anything) wasn't there some bug related to bzrdir got imported? I'm now failing to find it or remember the details.
<abentley> wgz: pqm-submit has its own implementation of config stacks to provide compatibility with 2.4 and lower.  This doesn't seem ideal.
<wgz> abentley: indeed not.
<vila> wgz: avoiding the caching issues can be avoided by writing tests that don't try to cache branch/tree objects or expect them to not cache any config values
<jelmer> wgz: yes, bzrlib.workingtree didn't import bzrdir for a while
<wgz> mostly plugins that support multiple versions haven't switched yet (and some don't have tests...) but a way to get the benefits without breaking too badly would be really good
<jelmer> wgz: that meant that if you didn't run bzrlib.plugin.load_plugins() you might end up trying to open a control directory while the format handler for .bzr/ wasn't yet registered
<jelmer> wgz: for that reason, we now explicitly import bzrlib.bzrdir from bzrlib.branch, bzrlib.repository and bzrlib.workingtree
<vila> wgz: my understanding is that you run into this issue only if you mix the two code paths for the *same* option and modifies it (naively) with the old code path
<wgz> jelmer: ah yes, that was it, thanks, gmail search let me down.
<wgz> bug 905218
<ubot5> Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Critical,Fix released] https://launchpad.net/bugs/905218
<jelmer> wgz: we could move the probers out of bzrlib.bzrdir into bzrlib.bzrformats or something (and leave the actual implementation in bzrlib.bzrdir); that would allow us to access foreign formats without loading any of the bzr-specific code
<jelmer> s/any/barely any/
<wgz> that would be neat.
<wgz> vila: that seems quite likely during transition
<vila> wgz: which part ?
<wgz> mixing up old and new config calls on the same option
<vila> *and* modifies the option ?
<vila> early enough to fall into the trap ?
<vila> not in a test ?
<wgz> having some clear guidelines on The Right Way seems useful
<vila> yup
<abentley> vila: _get_config_store seems to remember cache the BranchStore, but the BranchStore doesn't seem to care about locks.  Could this be the cause of the problem?
<abentley> vila: I think it should not set self.conf_store for unlocked branches, or perhaps it should be needs_read_lock.
<vila> abentley: more likely the issue is that the branch does not clear the cached config when unlocking when that was deliberate to avoid a read at the next option access
<vila> remove the second when
<abentley> vila: I thought I saw code to clear it in Branch.unlock.
<vila> hmm, I see self.conf_store.save_changes() in unlock (branch.py line 2564)
<abentley> vila: Maybe it should be in Branch._clear_cached_state ?
<abentley> vila: Yeah, but I don't actually see it clearing it.
<vila> because clearing it lose half of the optimization, save_changes() already read/write the file, throwing it away it a waste
<abentley> vila: if you don't clear it when you really unlock the branch, you run the risk of using stale data, don't you?
<abentley> vila: If the branch is being locked for the right duration, it shouldn't throw away the optimization, I would think.
<vila> hmm, sounds convincing... but I expect more test bugs in that case
<abentley> vila: Also, it looks like you're calling save_changes on every call to Branch.unlock, even if the branch has been locked multiple times.
<abentley> vila: If so, you are doing more I/O than necessary.
<abentley> vila: Though this may be theoretical since setting config is rare.
<vila> if there is no changes there is no IO but the other point is worth investigating
<vila> I thought unlock was protected by some other mean but imbw
<abentley> vila: right.  To do extra IO, you'd need to Branch.lock_write(); Branch.get_config().set(); Branch.lock_write(); Branch.get_config.set(); Branch.unlock(); Branch.unlock()
<abentley> sorry, s/get_config/get_config_stack/
<vila> yeah, if unlock is always called, I thought there was some mechanism to call it only for the outer call but I don't see the relevant code (or I'm confused by another implementation)
<abentley> vila: Or another case would be Branch.lock_write(); Branch.get_config_stack().set(); Branch.lock_read(); Branch.unlock(); Branch.get_config_stack.set(); Branch.unlock();
<abentley> vila: I believe Branch.unlock will actually get called, but "if not self.control_files.is_locked" prevents action if we haven't actually unlocked.
<vila> in any case, save_changes() should be called *before* the real unlocking happen
<abentley> vila: most definitely.
<vila> oh crap the texinfo/sphinx issue is still pending for bzr.dev
<mgz> vila: yeah. Gordan worked around it by renaming the bzr bundled texinfo.
<vila> neat
<abentley> vila: Here is a  test that demonstrates the caching problems: http://pastebin.ubuntu.com/871738/
<vila> abentley: thanks
<vila> I always known that there are issues with caching the config values, the real question has always been: which use case will it break ?
<vila> s/known/knew/
<vila> In practice, once you open a branch in read-mode, another process can open it in write mode and change the config values, is there a case where we should care ?
<abentley> vila: Arguably when we read-lock the branch, we should cache all cacheable values.
<vila> abentley: right, the old code didn't do that, the new one does
<vila> but that doesn't give us a use case where it breaks :)
<abentley> vila: No, it doesn't do it when we read-lock the branch.
<abentley> vila: It does it afterward.
<vila> ha, right
<vila> yeah
<vila> but it's very early (stacked_on_location)
<vila> or some other option
<abentley> vila: But that's *before* we read-lock the branch.
<vila> mwhahahah
<vila> even worse :)
<abentley> vila: I've been wanting us to open all branches in locked mode for years.
<abentley> vila: e.g. Brach.open_read_locked(), Branch.open_write_locked().
<vila> the fact that we didn't encounter bugs around this (yet) hints that it's not that vital either
<abentley> vila: I recall hitting plenty of bugs that this would have solved.
<vila> but I agree it would be far cleaner
<vila> ha
<vila> did you file some ?
<abentley> vila: But like I say, it's been years.
<abentley> vila: I think it would also fix the bug I'm showing here.
<vila> right
<abentley> vila: Well, it would if we cleared the store on unlock.
<vila> the fact that we can use unlocked branches means many tests just did that
<vila> yeah
<vila> If no test fails doing that it's a no-brainer
<vila> abentley: can you file a bug and I'll look into it tomorrow ? (too many juggling eggs right now)
<abentley> vila: For sure.  I was going to land a couple of expectedFailure tests.
<vila> abentley: there are several bugs (not clearing, saving only for the outer call) but a single one should do for the discussion about the balance between some caching and no caching at all
<vila> abentley: deprecating set_user_option for already migrated options may be an option too
<vila> already migrated == registered
<abentley> vila: deprecation implies that it works, but you shouldn't use it.  This is a case where it doesn't work.  Because you can call set_user_option, and then invoke code that does get.
<vila> abentley: strictly speaking, yes, I was thinking about a warning to guide people during the migration
<vila> abentley: the check is cheap and the output would help
<abentley> vila: IMO, we expect APIs to break during betas, so we should just remove set_user_option.  Keeping it around is unnecessary pain.
<vila> abentley: that would mean breaking all plugins that still use the old API, sounds a bit painful too
<vila> a bit *too* painful even
<abentley> vila: Well, maybe in this case, but in general, removing APIs is going to break all plugins that use it.
<vila> especially given that *setting* options programatically (sp?) is the exception rather than the norm and the bug is triggered only when you mix both APIs
<vila> both APIs for the *same* option
<abentley> vila: I dunno.  There are certainly going to be plugins that set options and then expect bzrlib to respect them.
<vila> so far you can still use both APIs as long as you don't mix them which is a softer path for migration (but jelmer already said he was for deprecating the old config during the 2.6 cycle while I was targetting 2.7)
<abentley> vila: I don't think it's practical to avoid mixing them, because you can use config stacks indirectly via bzrlib.
<vila> abentley: I'm not that sure about that, options are rarely set by plugins themselves, *users* set options
<abentley> vila: In which case, it shouldn't be to painful to remove set_user_option? :-)
<vila> hehe
<abentley> vila: AFAICT, self.branch.get_config_stack().set('foo', 'bar') does IO.
<vila> abentley: yes :-/
<vila> abentley: but
<vila> b.lock() ; b.get_config_stack().set('foo', 'bar') doesn;t until b.unlock()
<vila> this was changed during the review as it made easier to use
<vila> s/made/made it/
<abentley> vila: I'm doing it in a locked branch.
<vila> <cough> It's what the bug you're about to file is about now ? :)
<vila> s/now/no/
<vila> s/if self.conf_store is not None/if self._control_files._lock_count == 1 and self.conf_store is not None/
<abentley> vila: Well, this is the fact that branch.unlock unconditionally does IO
<vila> s/unconditionally/if there are changes to save/
<abentley> vila: Right.  BranchStack.set is needs_write_lock, so it implicitly does Branch.unlock.
<vila> abentley: yup and it should *not* trigger save_changes() if the branch is already locked, that's a bug
<vila> abentley: then, save_changes() itself will trigger an IO *only* if there have been changes since the last read
<abentley> vila: Right.
<vila> abentley: it's unfortunate I missed the save-on-last-unlock part given how many tests failed during this change :-/
<vila> abentley: I will add the missing tests while fixing this
<vila> abentley: but the plan is definitely to *not* write until the last unlock
<abentley> vila: this means Branch.get_config_stack.set() will interoperate with Branch.get_config.get_user_option correctly.
<vila> indeed
<abentley> vila: Until the bug is fixed.
<vila> indeed again, which is why I expect for test bugs
<vila> the weird thing is that I'm pretty sure there are some hpss test that should have failed if each set() was trigerring an IO, but maybe the remote branch object does calls the branch.unlock() only for the outer unlock...
<vila> abentley: EOD here, thanks for the feedback
<abentley> vila: np
<abentley> vila: Bug #948344 and #948339
<ubot5> Launchpad bug 948344 in Bazaar "BranchConfig and BranchStack do not interoperate correctly" [Medium,Triaged] https://launchpad.net/bugs/948344
<ubot5> Launchpad bug 948339 in Bazaar "BranchStack caching misbehaves" [Medium,Triaged] https://launchpad.net/bugs/948339
<sarrvesh> I need help with pulling a branch using bazaar.I tried executing the command bzr branch lp:ubuntu/unity-greeter
<sarrvesh> in terminal
<sarrvesh> but I got the following error message
<sarrvesh> Agent admitted failure to sign using the key.
<sarrvesh> Permission denied (publickey).
<sarrvesh> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<sarrvesh> Agent admitted failure to sign using the key.
<sarrvesh> Permission denied (publickey).
<sarrvesh> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<sarrvesh> How do I overcome this?
<sarrvesh> Please help
<jelmer> hi sarrvesh
<sarrvesh> hi
<jelmer> sarrvesh: it sounds like you haven't set up a SSH key but have specified your launchpad login with "bzr lp-login"
<sarrvesh> no but I pasted my ssh public key into launchpad
<sarrvesh> any idea how to overcome this?
<jelmer> sarrvesh: do you have your ssh key added locally?
<jelmer> Did you tell bzr about your launchpad login name using "bzr lp-login" ?
<sarrvesh> yea i did
<sarrvesh> first i did bzr whoami "name <email_id>"
<fullermd> The error message sounds like something with the agent.
<sarrvesh> then i did bzr launchpad-login <username>
<thomi> Hi everyone - I'm having an issue related to bzrlib - in sloecode we do this:  "to_transport = repo.user_transport.clone('trunk')" in order to create a repo for a new project, but I get this exception: AttributeError: 'CHKInventoryRepository' object has no attribute 'user_transport'
<thomi> however I think this is because the repositories on disk may have become corrupted. Any hints as to what that exception means, and how I can fix it?
<lifeless> bzrlib version skew I suspect
<thomi> so... the repositories were created with version X, but the system has version Y installed?
<lifeless> thomi: so your *code* was created for version X and your *code* doesn't work with version Y
<thomi> lifeless: I see, that makes more sense. :)
<thomi> Thanks
<thomi> ok, so my code uses bzrlib v2.5, but doesn't work with ver 2.1. At least now I know what the issue is
<richo> I'm looking for a unicode version of the bzr logo- like Â± for git or â¿ for hg. Is there such a thing?
<lifeless> probably not
<jelmer> I'm sure there must be a unicode symbol for merging traffic ?
<richo> that's what I thought
<richo> but I spent ages looking through glyph tables and didn't find anything, thought it might be easier to just ask
<jelmer> U+26D7 is in the right sort of area
<spiv> â¤ perhaps?
<spiv> Or â¤´
<jelmer> â
<spiv> That's a very tidy rendering of 2, 6, D, and 7 inside a rectangle :P
<jelmer> not here, here it is rendered as â :P
<jelmer> I guess you're using a different font than I am
<spiv> Inconsolata, but it typically falls back to another font if necessary for a particular glyph
<spiv> But I am on a lucid system.
<jelmer> ah, ok
<jelmer> you're running gooboontoo?
<spiv> I'm not sure it has quite that many "o"s in it :)
<james_w> U+26D8: BLACK LEFT LANE MERGE sounds promising
<spiv> Bikeshedding: Unicode Edition!
<jelmer> spiv: I'm sure you mean ð²shedding
<spiv> REPLACEMENT CHARACTERshedding?  Yes, yes I do!
 * mwhudson is failing at fonts for this conversation too
<jelmer> me too actually
 * mwhudson is amused by the way the character map applies bold and italic to unrendered characters
 * jelmer quickly closes Character Map before he finds more unicode characters representing things like KISSING CAT FACE WITH CLOSED EYES
<mwhudson> i now have a bold, italic 2, 6, D, and 8 in a box!
<jelmer> mwhudson: I wonder what a bold bicycle looks like :P
<SamB> jelmer: I think that one is made using several JIS characters
<SamB> the cat one
<jelmer> ah
<richo> damn, this charset doesn't have glyphs for any of those :
<richo> :(
#bzr 2012-03-07
<mgz> morning all
<jelmer> yo yo yo
<vila> helli hello
<LarstiQ> moin
<mgz> hey LarstiQ
<LarstiQ> hey mgz :)
<jelmer> mgz, vila: I'm taking a long lunch break today, and will work a bit into the evening
<mgz> whoops
<vila> jelmer: enjoy !
<jam1> vila, jelmer: I was just getting a traceback trying to do "bzr lp-open lp:...", is that a known bug?
<jam1> (on Windows, it gives an error about the certificate path)
<vila> bzr version ?
<vila> and running from sources or installer ?
<jam> vila: sources, bzr.dev 6446
<jam> vila: http://paste.ubuntu.com/873049/
<jam> it is true that /etc/ssl/... doesn't exist, but I wouldn't expect it to on Windows.
<vila> jam: try again with trunk
<vila> jam: reading the release-notes should also give you most of the details
<jam> vila: I was just getting a traceback, and wanted to check if it was known before reporting it.
<abentley> jelmer: I have a merge request for bzr-pqm up that fixes daily builds.  Do you mind reviewing it?  Should I be asking gz?  https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233
<vila> jam: k, several issues related to making urllib the default https implementation has been fixed
<jam> vila: well, I've never installed pycurl :)
<jam> but sure
<jam> I just upgraded and get:
<jam> $ bzr lp-open lp:~jameinel/u1db/c-pysync
<jam> Not checking SSL certificate for xmlrpc.launchpad.net: 443
<jam> Opening https://code.launchpad.net/~jameinel/u1db/c-pysync in web browser
<jam> so it looks like it at least handles not finding the certificates
<vila> jam: well, my remark also implied actually verifying the ssl certs
<vila> jam: I don't remember the details but I think it doesn't verify on windows if it can't find the ca certs
<vila> jam: i.e. now you know you're insecure :)
<jam> vila: sure. It never used to verify them, which if it can't, it can't. The bigger thing is not giving a huge traceback one way or another. :)
<jam> I'm not particularly worried about a MitM collecting my xmlrpc lookups to launchpad to expand lp: urls.
<vila> jam: yup, lack of feedback from people running from sources on windows is to blame here I think ;)
<jam> vila: well, I'm running source all the time, just not doing "bzr up" quite as often.
<jam> and certainly, I rarely do "bzr lp-open lp:.." because usually "bzr lp-open" without arguments doesn what I want.
<jam> and *that* doesn't fail, because I have public_branch = http:... set.
<vila> haaaa
<vila> I was wondering how you could have avoided the issue for so long ;)
<vila> jam: it means even an heavy user like you doesn't use https that much... interesting
<jam> vila: I use https almost constantly
<jam> it wasn't failing for a lot of other cases
<jam> because we do client side resolution for most things
<jam> apparently lp-open doesn't
<vila> jam: well, you *don't* use it that much or you would have encounter the issue sooner
<jam> vila: well, I use https, I apparently don't use xmlrpc+https via bzr
<vila> hmm, weird, I don't remember specific fixes for xmlrpc...
<vila> and  your traceback is clearly in urllib
<jam> vila: urllib as triggered from xmlrpc
<jam> but sure, I push/pull via ssh
<jam> so I don't use bzr transport over https for much of anything
 * vila nods
<vila> exactly why I found it interesting, most of the traffic for lp goes to the smart server these days so https is less used than I thought
<jam> vila: well certainly whatever doesn't go to the smart server would end up going to plain http and not https
<jam> and has been that way for a *long* time
<jam> I do believe https://bazaar.launchpad.net exists now, *but* it only servers Loggerhead, and not the static files, IIRC
<jam> you can go to: https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes or http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes and get the same content
<jam> but you can only go to http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format
<jam> https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format is a 404
<abentley> mgz: Could you please review https://code.launchpad.net/~abentley/bzr-pqm/config-stack-fixes/+merge/96233 ?
<santagada> anyone has an idea why I keep getting bzr killed when trying to branch lp:openobject-addons/6.1 on ec2?
<santagada> it is a huge repo but I don't see why this happens
<mgz> abentley: sure
<mgz> santagada: OOM?
<LarstiQ> santagada: do you have access to syslog?
<LarstiQ> vila: heya, can you see if there might be backlogged mail for me from the list, or should I ask a sysadmin?
<mgz> vila is in the set of admins so he should be able to see (jelmer and I are not though)
 * LarstiQ nods
<vila> LarstiQ: let me look
<vila> . o O (Which of the 16423 unread mails in the 104 mailboxes will give me the right url...)
<vila> LarstiQ: bazaar ml ?
<LarstiQ> vila: https://lists.canonical.com/mailman/admin/bazaar ?
<LarstiQ> vila: ueah
<LarstiQ> vila: I had to rush moving my vm, and had a missing mx for too long
<vila> LarstiQ: nope, nothing from you
<vila> errr, wait, all I can see there is mail blocked for unsubscribed people, that's not what you're after right ?
<LarstiQ> vila: no, I'd be something like 'bounces' or undeliverable email
 * LarstiQ tries to look at a mailman interface
<vila> mailman/admin/bazaar/members?letter=l says you're still subscribed
<LarstiQ> vila: ok, that's good
<vila> with your dyndns.org address that is
<LarstiQ> vila: yeah. That is why it went wrong ;). I'm trying to retire it this month
<LarstiQ> ok, so now just need to figure out why I can't even get a password reminder delivered
<santagada> LarstiQ, yep
<santagada> mgz, good catch
<vila> and the bounce settings seems sane: Mailman notify you, the list owner, when bounces cause a member's subscription to be disabled? (Yes) and Mailman notify you, the list owner, when bounces cause a member to be unsubscribed? (Yes)
<LarstiQ> good
<LarstiQ> vila: thanks!
<santagada> yep, the oom is killing the process
<santagada> is there any way to tell bzr to not use 600mb of ram?
<santagada> bzr 2.4.1 here
<santagada> is bzr 2.5b6 better in this regard?
<santagada> and the homepage of bzaar is pointing to the old blog... last post is about the move
<mgz> santagada: depends how the memory is being used
<mgz> what's near the end of .bzr.log before getting killed?
<santagada> mgz, where is this file?
<mgz> `bzr version` will tell you
<mgz> it's perfectly possible for a big branch to use 600mb and repacking tends to trigger maximum usage
<santagada> mgz,  456.915  24 bytes left on the HTTP socket
<santagada> mgz, so I guess... it was downloading it still
<mgz> ...I did mean a bit more context, but yeah, that looks like it was during fetching
<mgz> so, try branching not over http would be tip #1
<vila> ... and jelmer and I fixed some issues with http buffering (but was it in 2.5 or on trunk...)
<mgz> so, bzr+ssh if possible
 * vila nods
<vila> bzr+ssh should behave better
<santagada> but it shouldn't be doing that right?
<mgz> the way dumb transports work though, you still end up loading large chunks of remote packfiles and doing operations, which is bad for really big branches
<santagada> using 600mb of memory just for buffering a download
<santagada> will try bzr+ssh
<mgz> it's more the loading large chunk of pack, decompressing it, and trying to do stuff that adds up
<santagada> I thought http was not a dumb transport anymore...
<mgz> people have in the past had problems with a single mistaken revision, present in the repo but actually removed from the branch,
<mgz> that was large but compressed really well,
<santagada> to use ssh I need to do bzr launchpad-login, and that is it?
<mgz> and http is dumb enough that if it happens to fetch that section of the packfile because parts either side are needed,
<mgz> it basically dies to the decompression bomb
<mgz> santagada: yup, provided you have a local ssh key registered with launchpad
<santagada> isn't there a way to do anonymous ssh?
<santagada> I know how ridiculous this sounds, but is just a read
<mgz> making people have ssh setup is a pain, particularly for non devs, but it then makes a bunch of other sticky problems just work
<santagada> mgz, it is a server machine that is only downloading code... so having a ssh key there is kind of a security problem
<santagada> I will create a fake launchpad login then
<santagada> :)
<santagada> could be called anonymous or download-only
<wgz> it doesn't need to be *your* key
<santagada> wgz, it needs to be a key that is attached to a user right?
<wgz> though, the account you register it with does then give write access to that key for all the projects the account has access to
<santagada> wgz, so I should create my own anonymous account for it to work :)
<wgz> but for instance, ~bzr-pqm is not a human but has a key
<santagada> sorry for being a d*ck. it's just that launchpad+bzr drives me mad from time to time
<santagada> like, why the hell this repo is 500mb
<wgz> that too is probably a good question :)
<santagada> I would bet on a mixture of bzr repos being big and human error
<wgz> there's certainly a culture of "just stick everything in svn" that some people have carried over to bzr
<wgz> which... can be a bad thing
<santagada> well the repo has 150 mb of text in it. still I don't think the repo for some years should be 500mb
<vila> last time people did measurements bzr repos sizes were in the same range than git
<santagada> vila, I will try to convert this one to git
<vila> santagada: let us know the results
<jelmer> abentley: sure, I can have a look oif mgz hasn't yet
<abentley> jelmer: he got it, but thanks.
<wgz> feel free to look anyway :)
<santagada> vila, its going to take 40 minutes... but let's see
<wgz> jelmer, for bug 949093
<ubot5> Launchpad bug 949093 in Bazaar "bazaar and subversion clashed" [Undecided,New] https://launchpad.net/bugs/949093
<wgz> wait, no, misread, he does have his own sv libraries installed
<wgz> *snv
<wgz> ...
<wgz> *svn
<wgz> so what we ship with the all-in-one installer is new enough?
<sledges> hello
<sledges> is there an equivalent of a git commit hash in launchpad, so that e.g. linaro kernel binaries would contain a string somewhere in a binary pointing to an exact state of the source it was compiled from?
<santagada> isn't bzr+ssh supposed to be faster? It is both slower in terms of speed on launchpad (10x slower) and is transfering the same ammount of data
<santagada> wgz, vila: the process got killed again, was downloading the repo from bzr+ssh and used all the memory again
<santagada> last line on the log "550.219  fetching: <SearchResult search:(set(['odo@openerp.com-20120307095627-8e2pf7955wg0jsoo']), ['hmo@tinyerp.com-20081124140910-4mqqv4qzd2rasrst', 'sma@tinyerp.com-20090924065200-nwj675pes1mole3d', 'fp@tinyerp.com-20090122131004-s39c7drfwbm8kggw', 'olt@tinyerp.com-20090126152714-d24104dspg0pyi8h', 'stephane@tinyerp.com-20090130202409-7dp454o39h2lo2pf', ...], 32283)>"
<santagada> any other ideas on how to make it not use <repo size> ram when branching?
<mgz> sledges: depending on what you want, the revid is an option
<mgz> santagada: there are various cases where bzr+ssh isn't quicker, mostly because both sides do CPU work when splatting bytes is sometimes enough
<mgz> santagada: try `bzr branch -r100 BRANCH` then `bzr pull -r200` and so on
<sledges> mgz, I have kernel image "Ubuntu 2.6.38-1401.4-linaro-lt-mx5 2.6.38.8" from official ubuntu-11.10-preinstalled-desktop-armel+mx5.img.gz booting fine on i.MX53QSB, but its source compiled on my HOST halt after "Uncompressing kernel..." (same .config, and only minor gcc version difference) ? (source took from:  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/linux-linaro-lt-mx5/precise/revision/3
<santagada> mgz, yep bzr+ssh seems to be transfering the same ammount of data, and ssh in launchpad ssems to be 10x slower than http
<santagada> mgz, what does bzr branch -r100 do?
<mgz> gets the first 100 revs.
<santagada> seriously that bzr don't do any file buffering and I will have to do it manually?
<mgz> sledges: I'm not following... there are lots of reasons compiling the same stuff locally could break for you
<mgz> are you trying to submit a bug report with enough details for someone else to repo, or change the current build process in linaro?
<mgz> santagada: it mostly helps narrowing down specific problem revisions
<sledges> mgz, I'm not asking you to fix my build problems, I am explaining why I need the revid you now mentioned; now how can I fish it out from the only binary I have..
<mgz> clearly doing it manually isn't more efficient that what bzr does internally
<sledges> in #linaro I've been told that launchpad source state revision might not be the one that was put into ubuntu preinstalled img
<mgz> sledges: you'd need to ask the linaro guys how they tag their kernels, I'm not involved with that
<santagada> mgz, bzr is using ram to fetch the repository... I don't think it is one particular revision that makes it use 600mb of ram
<mgz> unless their build process explicitly embeds some unique indentifier, there's no reason to suspect you could pull one out of their binary
<sledges> mgz, Git has the hash tag for every commit, I came here to ask you whether there is an equivalent (see my original question)
<mgz> what gets put in the binary is part of the build process, not the version control system though
<mgz> nothing in bzr puts revision identifiers in other people's makefiles
<sledges> thank you, that answers my question
<mgz> it may well be done as a matter of course, but it's not something I'm aware of how to retrieve for projects I don't know the details of
<santagada> mgz, bzr is downloading all revisions even if I say bzr branch -r 100
<santagada> ahh it was downloading everything because I went back to use http. now on ssh it did branch only the first n revs
<mgz> santagada: without actually debugging it in detail, all I can do is offer suggestions, there are methods of getting exactly what is held in memory, but the reaper gets in the way of that
<mgz> 100 revs at a time sucks, but does at least rule out certain classes of problem
<santagada> mgz, I will do 10000 at a time now
<mgz> ...dear god, how big is this thing? :)
<santagada> 40k revs
<mgz> ehehe
<santagada> its a 500mb repo
<mgz> most 500mb repos are just from people versioning huge trees
<mgz> the emacs-class ones that actually have decades of history are rarer
<santagada> this is the case
<santagada> 150mb of text files of tons of different things
<mgz> anyway, it's probably worth filing a bug/posting to the mailing list about your woes today anyway
<santagada> and translated to tons of languages using the launchpad tool
<mgz> it's good to have a record of what problems people run into in practice
<santagada> mgz, I don't feel like doing that when you see bugs like this marked as wont fix
<santagada> mgz, https://bugs.launchpad.net/launchpad/+bug/493389
<ubot5> Ubuntu bug 493389 in Launchpad itself "launchpad should offer anonymous bzr+ssh" [Undecided,Won't fix]
<mgz> well, won't-fix would not be the case here, but a short post about with the rev stats and what you tried and how it failed is probably of more use
<mgz> as fuzzy bugs are less useful than just shared knowledge about where problems still exist
<santagada> I still think it is not a fuzzy bug, bzr seems to be loading the whole repo in memory while fetching
<mgz> I can believe we have room to improve general memory usage for trees as deep as yours still, and people may have more insight
<mgz> "whole repo in memory" isn't really a diagnosis, as that's not what bzr actually does
<mgz> it probably is holding the entire revision graph in memory, and caching chunks of packfile in uncompressed form
<mgz> and probably some other things too
<mgz> but that's not the same as just reading all the compressed bytes from disk and leaving them referenced
<mgz> right, I started this VM half an hour ago, I really should start using it...
<santagada> mgz, so why doesn't it first download the whole repo to .bzr and only then start building the revision graph/doing stuff with the data?
<santagada> the fetch phase should use very little ram
<santagada> I was able to get it using bzr branch --stacked lp:openobject-addons/6.1 addons
<mgz> ideally fetching would just splat bytes over the network
<santagada> but only using bzr+ssh, using http it downloads the whole repo anyway
<santagada> mgz, exactly
<mgz> the reason it doesn't is it's doing lots of work for the other common case, where you only want a subset of revisions from the repo
<mgz> which is generally the case for updates, and with launchpad and stacking, is alwasy true even for initial fetches
<mgz> stacking on a remote branch is probably not what you want by the way.
<santagada> --stacked proved to be a really bad idea when you need to do anything with the repo later as everything is done on the network
 * mgz won that race here :)
<santagada> so --stacked is a big no on development. but for this particular case (deployment) its ok I guess
<santagada> I will only be doing bzr update here
<mgz> right, as would just export be perhaps?
<santagada> but really bzr branch should be much smarter
<mgz> rather than stacking, you could just do a checkout
<mgz> which is a bit less voodoo.
<santagada> mgz, what is the difference between branch --stacked and checkout?
<mgz> though... both those want the 2.5 fixes on launchpad
<santagada> mgz, I thought the only diff between branch and checkout is that checkout make the branch bounded to the parent
<mgz> a (lightweight) checkout knows the branch lives somewhere else, a stacked branch just falls back to a different location if it can't find a revision locally
<santagada> export would not work because we would generally want a faster deploy, and doing a pull+update is usually faster than a whole repo copy
<mgz> but as said, both have pretty bad network behaviour, some of which is fixed in bzr 2.5
<santagada> mgz, in practice what is the difference?
<santagada> that description seemed to mean the same
<mgz> a checkout has consistent semantics and performance
<santagada> so it always look on the network, and stacked sometimes do?
<mgz> (currently consistently bad with 2.4 though)
<santagada> I will take stacked any day of the week for anything :)
<santagada> mgz, I'm wondering, which would you use on the deployment use case?
<mgz> for your case you probably do just want a branch copy, so maybe stacked is sort-of-mostly okay, it's historically been buggier though
<mgz> ^hm.
<mgz> rsync probably :)
<mgz> I'm not sure, there are mixed priorities on deploying from vcs and the things I've needed to do it for have been small enough that it mostly hasn't mattered.
<mgz> I think there's been some past discussion on the mailing list on the topic.
<mgz> I'll see what I can dig up once I get this build started
<mgz> ...I just got email from github about checking ssh keys after the compromise
<mgz> am failing to pin the keyword on the donkey
<mgz> thought "deployment" would pull up relevent threads... what other terms are used...
<kkrev> I ran cygwin update and am getting this all the sudden: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable.
<mgz> if you run `ssh -V` in your cygwin shell what do you get?
<kkrev> Actually I think the issue is something else. I get that on pull, but branching from the ssh hosted repository works fine. This is the pull error: 8 [main] python2.6 1412 child_info_fork::abort: unable to remap _chk_map_pyx.dll to same address as parent (00B70000) - try running rebaseall
<kkrev> there is no rebaseall command
<mgz> that's... not a good sign
<mgz> so, as a workaround you can probably move the compiled extention out of the way
<mgz> but the cygwin packagers would probably appreciate a bug report
<mgz> some cygwin internal machinery is going wrong with one of our (optional) compiled extensions basically
<mgz> could be a bug with cygwin's C runtime or with cython, is unlikely to be a bzr issue though
<kkrev> the error wasn't lying about running 'rebaseall'. that's a cygwin thing. http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebaseall/
<kkrev> it works fine after that. I was just confused by assuming rebaseall was a bzr thing.
<mgz> ah, so it's upgrade specific?
<mgz> I guess they don't have a good mechanism for updating older packages when they change their core dll
<kkrev> right. I had to reboot the machine and run that rebaseall command. no idea exactly what it does, but I assume it updates some dll registry.
<mgz> well, as long as it works now :)
<mgrandi> i'm having trouble with locks and pushing to github, its worked before, but now it seems to be creating a lock and then saying its locked by someone else, when that person is myself
<mgrandi> http://bpaste.net/show/24741/
<mgrandi> relevant info in the log file: http://bpaste.net/show/24742/
<mgrandi> i need to push this code to github >.>
<poolie> hi all
<mgrandi> hey
<mgrandi> did you see what i posted?
<mgrandi> above?
<poolie> mgrandi, no
<mgrandi> i'm having trouble with locks and pushing to github, its worked before, but now it seems to be creating a lock and then saying its locked by someone else, when that person is myself
<mgrandi> 14:35 mgrandi
<mgrandi> http://bpaste.net/show/24741/
<mgrandi> 14:36 mgrandi
<mgrandi> relevant info in the log file: http://bpaste.net/show/24742/
<poolie> hm
<poolie> this sounds familiar
<poolie> are you on 2.5.0?
<poolie> i guess, then, file a bug against bzr-git
<mgrandi> 2.5b6
<mgrandi> ok, any idea on how to get this work temporarily? >.>
 * jelmer waves
<mgrandi> bzr-git got updated recently, maybe i'll try updating that
<jelmer> mgrandi: hmm, that's odd
<mgrandi> yeah. it worked fine before
<mgrandi> but then i did it today, it repacked the repo
<mgrandi> and now it seems to be repacking it when it doesn't need it, and then gets caught in the lock condition
<jelmer> mgrandi: I'll have a look when I get back home
<mgrandi> ok. i should be around, ask if you have any questions
<mgrandi> i am trying with the latest version of bazaar and bzr-git
<mgrandi> annnd same thing
<spiv> Only if he wants to give the tute sober.
<spiv> Oops, wrong window!
 * spiv quickly reads scrollback to see if that might have made accidental sense
<mgrandi> no
<mgrandi> you didnt =P
 * jelmer tries to make sense of the word 'tute'
<spiv> Short for "tutorial"
<mgrandi> how is it short if tutorial has no e in it haha
<spiv> Because the magic abbreviation pixies declare it to be so!
<mgrandi> bah. got me there.
<mgrandi> anyway, jelmer, any idea on how to get around this temporarily? i kinda want to push to github real fast >.>
<jelmer> mgrandi: I would try reverting back to an older version of bzr-git temporarily
<jelmer> I'll have a look at the issue when I get back home, which should be in anbout 30 min
<mgrandi> ah
 * jelmer is in a train with a attery that is about to run out
<jelmer> my laptop;
<jelmer> 's battery that is, not the train's
<mgrandi> i shall be here!
#bzr 2012-03-08
 * mgrandi waits for jelmer
<jelmer> mgrandi: I'm here
<mgrandi> yay!
<mgrandi> i have to leave fairly soon so i was wondering if you had any input so i could file a bug report or something
<jelmer> mgrandi: perhaps just file a bug report ? I don't have anything yet
<jelmer> mgrandi: did reverting to an older verison help?
<mgrandi> 0.6.5 of bzr-git says unsupported url
<mgrandi> bzr: ERROR: Unsupported protocol for url "git@github.com:mgrandi/PythonScripts.git,branch=master"
<jelmer> try git+ssh://git@github.com/mgrandi/PythonScripts.git
<jelmer> what about 0.6.7 ?
<mgrandi> 0.6.7 still had the problem
<mgrandi> with the locking
<jelmer> hmm, perhaps the bug is related to bzr itself in that case, 0.6.7 is already a pretty long time ago at this point
<mgrandi> 0.6.5 has the same lock problem
<mgrandi> and yeah, whatever version i was using before, was working fine, it just stopped working today when it seemed that bzr did a repack
<mgrandi> before it pushed to github
<jelmer> hmm, hang on
<jelmer> did you perhaps add tags recently for the first time in a while?
<mgrandi> no, i dont think i have any tags
<mgrandi> unless the git repo has them or something
<mgrandi> (i dont see them if i do a qlog)
<jelmer> I don't see any on github either
<jelmer> mgrandi: is your local branch bound?
<mgrandi> yeah, its bound to my ftp server (bazaar)
<jelmer> I suspect that's related
 * jelmer digs a bit deeper
<jelmer> mgrandi: is it a lightweight checkout?
<mgrandi> it is not
<jelmer> mgrandi: managed to reproduce it
<jelmer> mgrandi: any chance you can file a bug?
<mgrandi> yay! and what should i report it against, bzr-git or bzr
<jelmer> mgrandi: bzr-git I think
<jelmer> not entirely sure yet
<mgrandi> i'll report it against bzr-git for now
<mgrandi> jelmer: reported here: https://bugs.launchpad.net/bzr-git/+bug/949557
<ubot5`> Ubuntu bug 949557 in Bazaar Git Plugin ""Unable to obtain lock" error when using bzr dpush" [Undecided,New]
<mgrandi> however, i must go get food and go to the gym, you can contact me through the bug report if you need more information =)
<mgrandi> later~
<jelmer> ... and fixed
<jelmer> g'night all
<poolie> night jelmer
<mgrandi> jelmer: i saw that you fixed the bug we were talking about earlier and i tried it and it works =) thanks
<vila> hi all !
<mgz> morning all!
<vila> mgz: ;)
<mgz> and how are you this morning vila?
<poolie> hi all
<poolie> not really here
<vila> fine thanks, I slept far before 4:00 in the morning unlike yesterday ;)
<vila> mgz: and thanks for the windows installers, I'll release 2.5.0 officially later today
<apw> in ubuntu, i am all of a suddent 1) seeing an onscreen progress window for command line pushes, and 2) finding it gets stuck on the screen forever.  is the first expected and the second known?
<vila> apw: never heard about that, you mean some gtk/kde progress window right ?
<apw> yeah some gtk type little cylon wizzer
<vila> apw: 'bzr plugins -v' paste ? This may be caused by some plugin... in which case 'BZR_DISABLE_PLUGINS=gtk:qbzr' will confirm... but that's really a wild guess
<apw> https://bugs.launchpad.net/bzr/+bug/949798
<ubot5`> Ubuntu bug 949798 in Bazaar "bzr-notify leaves a rogue status throbber on screen after bzr push completes" [Undecided,New]
<vila> apw: in any case, it's not from bzr itself AFAICT but worth being investigated
<vila> apw: not a notification dialog right ?
<vila> meh, notification thing :)
<apw> http://paste.ubuntu.com/874298/
<apw> vila, the box literally has a 1in wide cylon style progress 'indicator' which zips back and forth like a mad thing
<apw> when i find out how to kill it ... i shall take great pleasure in doing so
 * vila blinks
<apw> vila, i think its coming in as a side effect of having bzr-gtk installed, that has always had expected side effects like giving you notification bubbles for command line pushes; also really annoying
<mgz> that's kinda funny
<vila> hmm, I had trouble *getting* notifications (which I like ;) but there should be a trick to disable them
<vila> but I only get notifications messages for a few seconds, never any progress stuff
<apw> vila, its 'brand new' as in i think i got it in the last day or two max
<vila> hmm, can't reproduce while pushing a branch new branch on lp :-/
<vila> apw: where did you push ?
<apw> vila, to launchpad
<apw> vila, do you have bzr-gtk installed?  pretty sure that is required to trigger the fun
<vila> yup, running from trunk though
<apw> hmmm ... only appears to be triggered when you have something to push too, when it says 'no new reviews or tags to push' it doesn't appear
<vila> apw: as a workaround, try killing bzr-notify
<vila> apw: (I'm still in the dark as I can't reproduce :-/)
<apw> vila, will do
<vivekimsit1> hii
<vivekimsit1> I have a diff file which contains diff of more than one files who can I use that diff file to apply a patch ..?
<vila> vivekimsit1: if no renames are involved then 'patch' is the command you're searching for I guess
<vila> jelmer: ping, is one of the foreign plugins adding a '/changes' to the end of an url for probing purposes ?
<jelmer> vila: no, that seems more like a loggerhead artefact
<vila> k, thnks
<jelmer> (what are you tracking down?)
<vila> a weird redirect issue in bug #924727
<ubot5`> Launchpad bug 924220 in Bazaar "duplicate for #924727 ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
<vila> rhaaa, not the duplicate (which is ~abusive)
<vila> jelmer: did you read about apw issues earlier (~1 hour ago) ? Can https://code.launchpad.net/~sinzui/bzr-gtk/ui-factory/+merge/94866  be related ?
<jelmer> vila: if you mean bug 949798, I don't see how that could be related
<ubot5`> Launchpad bug 949798 in Bazaar GTK+ Frontends "bzr-notify leaves a rogue status throbber on screen after bzr push completes" [High,Confirmed] https://launchpad.net/bugs/949798
<vila> jelmer: I don't see *how* for now, but may be a progress window wasn't displayed before and now is
<vila> (under circumstances I can't reproduce though :-//)
<apw> vila, i've never seen these progress frobbers until just the last day or two maybe
<vila> apw: but (except for bzr-notify), you're not using any g* command right ?
<jelmer> ah, bzr-notify uses open_display, which sets the ui factory
<jelmer> that makes sense
<jelmer> I'll ask Curtis about this
<apw> vila, right i see them when i bzr push from the command line directly
<mgz> I can belive curtis fixing bugs made some previously broken misfeature accidentally work
<vila> jelmer: yeah, something like that, so my guess (uneducated and therefore guaranteed to be at least half bogus) is that some progress is triggered and never closed. But for bzr-notify, it should just *never* display a progress
 * vila nods @ mgz
<jelmer> vila: right, so I think this is a regression from the ui-factory branch
<jelmer> as I think you suggested :)
<vila> yeah
<vila> not a regression per se, I agree with mgz
<jelmer> vila: it is a regression, the Gtk UI factory didn't use to display anything if there was no active window registered
<vila> probably making some old broken code works better and as such reveals an older bug
<vila> kk
<vila> the mistery (to me) is still that I can't reproduce
<jelmer> vila: are you running bzr-notify from bzr-gtk trunk?
<vila> yes
<jelmer> vila: not just bzr-gtk, but bzr-notify too?
<jelmer> and did you log out and back in again after updating bzr-gtk?
<vila> yes, I have a ~/bin/bzr-notify pointing to the trunk version
<vila> no :)
<vila> I'm trying to get rid of my backlog mail before releasing to avoid missing some known issue
<vila> which is how I discovered curtis work (which I welcome ;)
<jelmer> vila: btw, it seems like quilt is generating different contents for .pc/ in newer versions
 * jelmer thinks that might be a good excuse to move to not shipping .pc/ in udd branches
<vila> jelmer: I have little experience there but when did it start ?
<jelmer> vila: I think one of the quilt packages in Debian sid
<vila> jelmer: as in: last week, last month ?
<jelmer> vila: no idea
<jelmer> vila: this came up in #ubuntu-devel yesterday
<jelmer> vila: it shows up in precise
<jelmer> if you pop all quilt patches and push them, you end up with a bunch of .timestamp files in .pc that weren't there previously
<vila> :-/
<jelmer> vila: I think we should get bzr-builddeb to a point where bzr can deal with quilt patches transparently (like looms) and then change the default in UDD to not apply patches by default.
<vila> jelmer: i..e. apply patches in the wt only, sounds nice. I'm unclear about how far we are from that (I thought we were already there ;)
<jelmer> vila: we can automatically apply patches on checkout/update and make sure they aren't applied on commit
<jelmer> vila: if we do that, we still see the changes in 'bzr diff' and 'bzr status'
<vila> right, forgot that, lack of practice :-/
<vila> I need a break, bbl
<abentley> mgz: Could youl please review https://code.launchpad.net/~abentley/bzr/config-cache-bugs/+merge/96227 ?
<ubot5`> Ubuntu bug 81798 in democracyplayer (Ubuntu) "duplicate for #96227 [apport] democracyplayer crashed with TypeError in __new__()" [High,Fix released]
<abentley> ubot: don't be silly
<mgz> abently, sure, I had a look at that
<mgz> tests look good, only thing I wasn't sure on was where they should live
<abentley> mgz: thanks.
<mgz> and generally I'd write expected failure tests as...
<mgz> for instance, if I know that f() currently returns 1, but it should return 2
<mgz> self.expectedFailure("...", self.assertNotEquals, 1, f())
<mgz> self.assertEqual(2, f())
<mgz> so the diff for the fix is just deleting the expectedFailure line
<mgz> but that's mostly useful in more complex cases than this
<smoser> jelmer, are you expectin to get bug 923688 into ubuntu soon ?
<ubot5`> Launchpad bug 923688 in bzr-builddeb (Ubuntu) "bzr crashed with AttributeError in tree_unapply_patches(): 'DirStateRevisionTree' object has no attribute 'last_revision'" [High,Triaged] https://launchpad.net/bugs/923688
<smoser> i've hit it several times when trying to merge things.
<mgz> smoser: 2.8.3 is tagged and in unstable, so it presumably just needs to filter through into precise
<smoser> mgz, well., at this point in cycle *someone* would have to ask for a sync, right?
<smoser> what does "in unstable" mean ?
<smoser> duh.
<smoser> sorry.
<smoser> i looked at pts record for bzr (not bzr-builddeb) and saw no 2.8.3 there.
<mgz> smoser: syncing now.
 * mgz claims credit for jamespage's work
<smoser> thats always good
<smoser> i make it a habit
<mgz> :)
<abentley> mgz: Okay, I can change the expectedFailures to calculate the result in a separate statement.
<mgz> abentley: do you have feelings about where the tests should be? I thought in config, but looking at the existing tests in both places your current pick seems more appropriate
<abentley> mgz: I think making them branch-related makes sense because they are related to the per-branch caching.
<jelmer> smoser: I'll request a sync
<mgz> jelmer: doing it now
<abentley> mgz: updated.
<jelmer> mgz: not sure I follow?
<jelmer> mgz: (it's already been synced)
<abentley> mgz: I've made the changes you requested.  Anything else?
<mgz> ah. er... link to lp bug in comment?
 * mgz approves
<abentley> mgz: Comment in the code or on the merge proposal?
<mgz> both would be good.
<abentley> mgz: sure thing.
<Noldorin> hey folks
<Noldorin> jelmer, wgz
<jelmer> hi Noldorin
<Noldorin> how's things going?
<jelmer> alright, how are you?
<Noldorin> okay thanks
<Noldorin> jelmer, some good news re: windows support. i rememebr this applying t oa certain bzr bug which i forget...
<Noldorin> "import" as well as all python filesystem functions now correctly resolve junctions on windows
<Noldorin> i.e. directory symlinks
<jelmer> Noldorin: ah, neat
<Noldorin> next release of py2.7 i believe
<Noldorin> i submitted this bug some time ago, and they've been working on it :-)
<jelmer> yeah, I remember you mentioning that
<Noldorin> jelmer, forget which bzr bug(s) it applied to, but at least you know now
<mgz> ...next release of 2.7? really? there is no symlink support in 2.7
<Noldorin> mgz, sure there is. python has supported windows symlinks on files and (very dodgily) on directories for a while now
<Noldorin> but it will finally be fixed, most importantly for "import" in the next revision
<Noldorin> 2.7.x
<Noldorin> http://bugs.python.org/issue6727
<mgz> so, that's not actually symlink support, that only landed on py3k
<mgz> it does work around a bug in the msvc runtime though, which is like what you ran into
<mgz> I'm not sure it's the same issue without comparing them though
<mgz> I think your problem related to rename? this is in stat related.
<Noldorin> mgz, nah it says 2.7
<Noldorin> which onee you looking at? :-P
<Noldorin> i get the notifications
<Noldorin> have for ages
<LarstiQ> Noldorin: nice detective work on that bug
<Noldorin> cheers
<mgz> Noldorin: I'm looking at the 2.7 source, and it's not there :)
<Noldorin> mgz, then take it up with the dev. Jason Coombes i htink
<Noldorin> he explicitly said he's making it for the next 2.7 release
<Noldorin> ha
<abentley> vila: it would be nice if "configure" was an alias for "config".
<mgz> that fix is in 2.7
<mgz> but it concerns a particular issue with stat and junctions, not the symlink plumbing
<Noldorin> yes that's what i mean :-P
<Noldorin> didn't say anything about plumbing heh
<mgz> and it doesn't change any of the functions on the path you had problems with
<Noldorin> hmm?
<Noldorin> i was talking about imports
<Noldorin> i think you're thinking about a different bug i had
<mgz> Noldorin: ah, perhaps
<Noldorin> yeah i've had lots of problems with symlinks :-)
<Noldorin> one of which you were involved in
<Noldorin> the winapi and its interop with python can be very dodgy sometimes
<Noldorin> due to various winapi "features"
<Noldorin> heh
<mgrandi> hu
<mgrandi> hi*
<mgrandi> is launchpad broken? i keep getting urls like https://bugs.launchpad.net/~markgrandi/null
<mgrandi> and then when i go back i get the 404 error pge
<mgz> sounds like bug 897277
<ubot5`> Launchpad bug 897277 in Launchpad itself "Going to +bugs results in incorrect URL location" [Low,Triaged] https://launchpad.net/bugs/897277
<mgrandi> hmm
<mgz> in general, disabiling javascript means launchpad works properly,
<mgrandi> yeah im using opera too
<mgz> (though don't let anyone hear me say that)
<mgz> and #launchpad is the right place to complain
<mgrandi> and yeah, it works in chrome, so it might be an opera problem
<mgz> well, it's a launchpad javascript bug
<mgz> tell #launchpad about it
<mgrandi> actually it seems like a opera bug
<mgrandi> http://my.opera.com/community/forums/topic.dml?id=1303132
<mgz> o, actually there are more details now
<mgz> that's nice.
<mgrandi> if you look there, it seems the html5 history thing
<mgrandi> launchpad uses some js library, and it says that one method can return null as the url
<mgrandi> which opera doesn't ignore
<mgrandi> so its either a yui bug or an opera bug, probably both, so yeah
<mgrandi> it works fine if you just don't hit the back button ever =P
<mgrandi> anyway mgz, since we were working on https://bugs.launchpad.net/bzr/+bug/864217, do you think thats related to the problem someone posted ot the mailing list about getting OOM while branching?
<ubot5`> Ubuntu bug 864217 in Bazaar "MemoryError when repacking repository with large numbers of revisions " [Medium,Confirmed]
<jelmer> mgrandi: I wouldn't be surprised if that's related
<mgrandi> i still need to work with mgz or someone to trace that out, since debugging stuff on windows is...hard
<mgrandi> i have not tried it on linux or mac but yeah.
<mgrandi> but thx for the fast turnaround on that bug jelmer, turns out that it actually already pushed to github (when it was getting hung up on the lock), but at least it now exits cleanly!
<jelmer> mgrandi: yeah, it was failing while pulling changes back into the master branch
<mgrandi> ah
<mgrandi> i noticed it was a one line change, so yay
<jelmer> mgrandi: well, a one line code change and 10 lines of test :)
<wgz> sorry mgrandi, hit the wrong button leaving in a hurry for the bus
<mgrandi> nah tis fine
<wgz> didn't seem to be directly the same thing, as it was an OOM during fetching, not on repacking
<wgz> but no doubt some of the same things that are sitting in memory are the same
<wgz> we should have another go at tracing your one some evening
<SRay> Hi, I'm part of a project and I'd like to use Bazaar in connection with a decentralized server. Now we can't exchange IPs manually everytime and that's where DHT come into play. However it appears nobody wrote such an implementation as of yet. Am I mistaken? Is this possible or am I missing some aspect?
<mgrandi> wgz, yeah, this weekend might be good, our timezones are weird so you are on at weird times for me
<LarstiQ> mgrandi: what timezone are you in?
<mgrandi> usa/arizona/phoenix
<LarstiQ> ah, UTC-7. That explains things :)
<mgrandi> utc - 7 without dst
<mgrandi> arizona is special :>
<LarstiQ> :)
<mgrandi> its sunny 300+ days a year
<mgrandi> we don't need to save daylight haha
<mgrandi> i take it most of you guys are on the other side of the earth!
<SRay> Depending on what you regard as the other side :P
<SRay> If it's Europe for you then yes :D
<mgrandi> rather, on the other side of the ocean
<SRay> ^^
<SRay> It really sucks in terms of communication that there's such a big difference in time.
<fullermd> I figure if I can't drive there, it's the other side of the world  ;p
<SRay> :P
<fullermd> 'course, you never know.  Some smartass might build a bridge across the Bering Strait and screw up my whole worldview...
<SRay> I like bridges :D
<mgrandi> might be able to drive there, isn't there a bridge between alaska and russia? you can see your house from there after all
<mgrandi> (ha ha)
<SRay> hehe
<LarstiQ> mgrandi: Finland for me, so across an ocean yes :P
<SRay> Germany here ^^
<mgrandi> and now i'm on the phone with india-adobe trying to resolve key issues. *waits*
<SRay> XDDDDDDDDDDDDD
<fullermd> Well, that's sure to fail.  But then, the time probably doesn't matter much either way on that one   :p
<mgrandi> "my name is jeff, how may i help you" your name is not jeff don't lie to me
<SRay> ^^
<SRay> hm still got a question: Anyone knows an "easy" way to use Bazaar decentralized? Somehow you or Bazaar gotta know the IP of the project member(s) to pull and commit, but how if there's no tracker nor central repository?
<jelmer> SRay: not that I'm aware of
<jelmer> SRay: I think this isn't really a bzr-specific problem
<mgrandi> shouldn't you have a server that hosts the repository?
<wgz> having one well-known place to coordinate from is useful
<mgrandi> and then people branch from that and then merge to it, etc
<wgz> you can still work in a decentralised fashion without everyone being able to access everyone else's machines
<jelmer> sray: you'd probably want just some sort of flexible host lookup mechanism
<SRay> jelmer: right but in connection with Bazaar since I want the version control XD
<fullermd> If only there were some sort of system to be like a directory, to turn human-readable names into IP addresses...   :p
<wgz> mgrandi: lets try this weekend, my evening is your morning :)
<mgrandi> have a server on your local network
<SRay> mgrandi: true, but someone's gotta pay it :S
<mgrandi> its not hard to have a computer just hooked up to the network and have your router forward a host name to it or something
<mgrandi> hell i have a computer from 1998 with a 1tb drive in it =P
<jelmer> SRay: right, but if you have a host name lookup mechanism in place (like mns) then bzr will work work just fine
<SRay> mgrand: yup I could do that, but that sneaky thing consumes energy non-stop :P
<SRay> jelmer: sounds interesting, do you have a link?
<SRay> *mgrandi:
<SRay> mgrandi: appart from costing money, just think about the environment :P
<jelmer> SRay: https://en.wikipedia.org/wiki/Multicast_DNS
<fullermd> Environment, pah.  What'd the environment ever do for me?
<mgrandi> yeah, although a computer that is just a hard drive would not use that much power.
<SRay> jelmer: thx I'll take a look.
<mgrandi> video cards are what take most of the power in a computer =P
<mgrandi> and not to mention modern hard drives shut them self off if not used after a while, or the OS does that
<SRay> mgrandi: yeah my parents still don't wanna pay that xD. (I'm still a student and with all the hours I have to stay at university there isn't really enough time to work q_q. And they don't wanna substract it from my pocket money neither :S)
<fullermd> Yes, that's why they wear out in 3 months from spinning up and down all the time   :p
<SRay> ^^
<mgrandi> fullermd: the amount of 'head turn offs' are something in like the low millions
<fullermd> Couple hundred thousand.  And those wear out REAL quick when it spins down and up twice a minute.
<mgrandi> that a hard drive is rated for, and most of the time they still work after that so, thats like 5+ years,
<SRay> mgrandi: I'd be curious to know how much your server consumes though. Maybe if it was cheap enough I could finally convince them unless the look up service doesn't work out.
<mgrandi> well yeah, the OS shouldn't be spinning it down twice a minute though
<mgrandi> (ubuntu was doing that, which caused a big snafu)
<fullermd> That's not the OS spinning it down; that's the drive spinning itself down.
<mgrandi> i do need to get a wattage/hour meter, its probably not that efficient since its so old but yeah
<fullermd> Anyway, that's not going to save meaningful power unless you can spin it down for, like, 12 hours at a block.
<mgrandi> then i'm confused on what controls the hard drive, the hd itself or the OS :o
<fullermd> An idle spinnign drive doesn't burn much more'n a watt or two.  That's like 1 kWh a month.
<mgrandi> true
<LarstiQ> SRay: you might be able to pool up on a vps
<LarstiQ> SRay: or use `bzr send` to do the exchaning via email
<LarstiQ> SRay: or use a service like dyndns to provide the name -> ip mapping
<SRay> LarstiQ: Thx for the hint checking it out too. The mDNS sounds like it's meant for local handshake only. the bzr send would mean though that it has to be made manually everytime isn't it? as for dyndns: I thought about that aswell, but it would mean that everyone has to set up his router to automatically send the IP to DynDNS unless....there would be an application which could do it aswell (at startup e.g.)
<mgrandi> dyndns usually has a program that runs on the computer
<mgrandi> that updates the ip
<mgrandi> so if one person's computer has the repo, then you just use whatever.dyndns.org/bzr/branch/whatever/trunk
<LarstiQ> SRay: what has to be made manually with send?
<SRay> LarstiQ: Open the email?
<SRay> or not?
<LarstiQ> SRay: well, I would suggest inspecting the bundle before applying it to your local branch
<LarstiQ> SRay: but you can completely automate it
<SRay> Yup I'd like that.
<SRay> Make it similar to Dropbox (with an additional program of course or also just scripts)
<SRay> (I'll probably need a program e.g. made in Java with listeners and stuff)
<LarstiQ> if you have dropbox then a simple python-inotify script might do the job
<SRay> unless there are already programs which automate all the tasks with bzr
<SRay> uh, i have no clue about python, but java should do the job aswell isn't it?
<mgrandi> what are you trying to do again?
<SRay> setting up a distributed repository for a game project
<mgrandi> i dont really thing you need to automate anything
<mgrandi> you just need to somehow connect to a computer that has the repo, somehow
<mgrandi> i think you are making it harder then it should be
<SRay> might be, but quite some ppl on the project might not be that tech savy (I've been working together with ppl on a Mod which uses SVN) and that often causes problems.
<mgrandi> all you need is one computer that is local or something that acts as the repository and then you can just use that
<mgrandi> whether its using dyndns or an ip or what, you can even turn it off when you all leave or something
<SRay> ah the project is with ppl over the internet.
<SRay> and we have no fix working times.
<mgrandi> well, why not use something like launchpad?
<SRay> cause launchpad requires the projects to be open-source
<SRay> q_q
<SRay> or we'd have to pay
<mgrandi> does no one have a ftp
<SRay> i think same goes with git or sourceforge
<mgrandi> server?
<SRay> nope
<mgrandi> its like 5 dollars a month =P
<SRay> i know XD
<mgrandi> you gotta pay something =P
<SRay> well if only our PCs would be used to upload and download it should work.
<SRay> it should work like peer to peer
<SRay> see RetroShare
<SRay> or Bittorrent
<mgrandi> not really...
<mgrandi> the repo is always changing, uploading it using any sharing site or whatever isn't going to work :>
<SRay> yeah that's the problem
<SRay> with Bittorrent
<SRay> however not with RetroShare
<mgrandi> you would be reuploading stuff every time something changed in the database
<mgrandi> that is going to be a pain in the butt.
<mgrandi> repo*
<mgrandi> seriously, someone can afford a cheap ftp server, 5 dollars a month is nothing
<mgrandi> save yourself the pain =)
<SRay> i wonder how much space would the FTP server provide for 5 $ a month?
<mgrandi> mine says "infinite"
<mgrandi> but its obviously limited, within reason.
<SRay> D:
<bob2> win115
<mgrandi> i highly doubt any thing you upload there will make them yell at you
<mgrandi> unless you run a huge website like reddit/github that probably goes through a gb/tb a day
<SRay> well no. it would be only for our game project. hmm which is your provider if I may ask?
<SRay> FTP server provider
<mgrandi> bluehost
<mgrandi> however, they charged me for all 3 years at once
<mgrandi> which was 300 dollars, but still 5 dollars a month
<mgrandi> you might be able to do a smaller number of months but yeah
<mgrandi> i feel this would be an issue with any version control system, you just have to have a common place to hold the repository and whatnot, even if its decentralized, and espeically if it is centralized (svn, etc)
<SRay> it'd be an option if someone would pay for it. (my parent's surely won't and my project member (only one active so far but other on demand as soon as we finally finished the concept and storyline) probably couldn't afford it neither). it's not even sure we gonna be able to sell this game :S. huh? how comes  300 $ for 3 years where they say 5$ per month? 5$ per month would result in 180$ for 3 years D:
<mgrandi> i just checked my billing history
<mgrandi> $250.20 for web hosting (3 years), the domain name and domain name privacy
<SRay> you're sure it wasn't 5$ per month the first year only?
<LarstiQ> SRay: you can also take a look at say, http://www.comparevps.com/
<mgrandi> 3 years is 36 months, 3 * 6 (which i think is what it was, 6 dollars not 5) is 216
<mgrandi> plus the domain which was like 10 dollars and stuff, 350 sounds right
<mgrandi> 250*
<mgrandi> hell, if you are that hurting for space i'll let you use mine haha
<mgrandi> i'll just give you a folder and some accounts or whatever
<SRay> like this it sounds right! hehe cool this would be so great! if we make any money with the game we could refund you afterwards :D. but are you sure this doesn't violate the polycies?
<SRay> *policies
<SRay> the lowest price for a VPS seems to be 3,95$ a month according to comparevpns
<SRay> *vps
<SRay> Ok ppl. Thanks a lot for you input! I'll see which option we'll take.
<poolie> hi all
<wgz> hey poolie
<jelmer> hi poolie, wgz
<wgz> jelmer: can I do anything to help on the gsoc front tomorrow?
#bzr 2012-03-09
<SRay> Hey, anyone knows, what's up with bzr-2.5.0-2-setup.exe ? I can't find it on launchpad, the link on the bzr download page is leading to a non-existant file.
<wgz> my bad, changed -2- to -1-
<wgz> -d
<wgz> I fixed the page now, as some kind soul sent an email about it.
<wgz> okay, bed for me.
<SRay> hehe ^^ good night
<SRay> thx for fixing
<SRay> Hey btw the link to the homepage from this IRC is broken. It guides you to: http://bazaar.canonical.com>
<SRay> > is recognized as part of the hyperlink
<bob2> nah
<poolie> hi vila
<poolie> wow i should go
<vila> hey poolie, yeah you should ;)
<vila> I think I've found the issue with the docs: lp:bzr-alldocs
<vila> that's where the templates are defined, the cron job should run in a couple of minutes, we'll see if I got it right
<vila> ha crap, I can never read cron entries correctly (mins then hours, not the opposite of course)
<mgz> morning all
<vila> _o/
<vila> yak yak yak :-/
<jelmer> vila is having fun with the razor?
<vila> kind of ;)
<vila> trying to reproduce a nth issue with generating the docs I'm back to bug #940164
<ubot5`> Launchpad bug 940164 in Bazaar "texinfo is supported by sphinx under precise leading to test failures" [High,Confirmed] https://launchpad.net/bugs/940164
<jelmer> ah :-/
<vila> which means it's more problematic than I hoped
<vila> whoever was RM for 2.4 and didn't document the *full* list of naughty details to get the doc right will... err, never mind
<vila> jelmer: by the way, did you notice the bug about ssl cert checking the wrong site for the proxy ?
<jelmer> vila: yeah, I did see that :-/
<mgz> I'm reasonably sure it's xmlrpc specific
<mgz> the launchpad plugin has its own transport stuff that probably just needs fixing
<vila> not sure about that, I suspect a mismatch in the urllib implementation, I bet because the connection to the proxy is seen as https when it's http
<vila> and I did make no typo there \o/
<vila> as usual, I'd be happy to be proved wrong ;)
<mgz> there was no error when doing an operation through the proxy just on any old https url
<mgz> only for the lp: resolving step
<mgz> hm, need a proxy that supports CONNECT and passthrough to test it, annoyingly twisted
<mgz> does not
<mgz> http://twistedmatrix.com/trac/ticket/237
<mgz> I guess writing that wouldn't be hard, but then I'd not sure if the bugs were in that or bzr
<vila> \o/ look 'ma, http://doc.bazaar.canonical.com/bzr.dev/en/ says what's new in 2.6 \o/
<vila> and http://doc.bazaar.canonical.com/en/ is not broken anymore
<vila> and we can generate .info files too
<mgz> good job vila
<mgz> just posted some extra info in the https bug
<vila> good job mgz ;)
<vila> bug # again ?
<mgz> bug 944696
<ubot5`> Launchpad bug 944696 in Bazaar "Certificate error on launchpad xmlrpc server with HTTPS_PROXY set" [Critical,Confirmed] https://launchpad.net/bugs/944696
<vila> right, reinforce my suspicion that we verify the wrong host, could as simple to fix as s/host/orig_host/ somewhere
<vila> unless the check is not in the right place which will require more harm twisting
<vila> err, arm twisting ?
<vila> whatever, more work :)
<mgz> yeah, there's a proxied_host attribute one stack level up that probably does the right thing
<vila> right, this one (not orig_host)
<mgz> apart from writing a test case ;_; that's probably all that's needed
<vila> funny how I remembered a name I replaced...
<vila> yeah, I never found the steam to write a proxy test server
<lamalex> what type of an object is a push_result/
<vila> mgz: https://code.launchpad.net/~vila/bzr/940164-native-texinfo/+merge/96796 while you're still PP :-D
<mgz> heh
<vila> lamalex: it's documented in bzrlib/push.py but roughly you can think about it at collecting various infos about the push operation
<vila> Can you believe my keyboard batteries died exactly when I was typing 'Enter' after the msg above...
<lamalex> haha
<mgz> ccing doxxx on that review just so he can glance at it, given he had to dive into tex stuff a little when doing the 2.5.0 mac installers
<vila> mgz: texinfo can *generate* both tex and info but for us it doesn't matter as we generate latex with sphinx with a different builder
<vila> mgz: but I should have a look at how Gordon avoid the issue (thanks for the reminder)
<mgz> he renamed our texinfo builder for sphinx to something else,
<mgz> so it didn't class with their new one :)
<vila> right, so he will encounter a trivial to resolve conflict :)
<vila> hmm, trivial with 'bzr resolve --take-other' probably ;)
<vila> yup, one-line patch to be deleted, thanks for ccing him if only for the heads-up
<mgz> so, apart from that conf.py stuff being a duplicative mess, which isn't the fault of this branch, the change looks good
<lamalex> what about parsing the push location, i guess branches like ~user/project/branch are specific to launchpad? maybe launchpadlib would have parsing bits for that
<mgz> lamalex: it does
<lamalex> mgz, hint as to where?
<vila> mgz: yeah, and don't mention that the Makefiles in the doc/xx dirs are copied from doc/en ...
<mgz> lamalex: see bzrlib/plugins/launchpad/lp_directory.py
<vila> I was shocked when trying to propagate my change in doc/ru to find it there already :)
<mgz> it has a few local bits, and talks to an xmlrpc server if it needs to
<vila> mgz: the whole sphinx setup is a mess being the result of stuff generated by sphinx itself + duplicated afterwards...
<lamalex> mgz, can i import this into another plugin?
<lamalex> import bzr.plugins.launchpad?
<mgz> +lib but yes... you probably just want to resolve lp: automatically though?
<vila> lamalex: *parsing* the push location ? What are you after ?
<mgz> which happens in _register_directory on import
<lamalex> vila, getting the project name out of the push
<vila> risky
<lamalex> when when pushed to lp:~alexlauni/unity/mydumbfeature getting unity
<vila> push_location can be lp:bzr
<lamalex> i realize i could just string parse
<lamalex> but yah, there's also lp:bzr but bzr is a project- so i was hoping that lp lib had this already figured out and i could just piggy back
<vila> stepping back further, why do you need the project name ?
<vila> lamalex: 'cause there is also ubuntu:bzr and ubuntu:~vila/ubuntu/precise/bzr/my-feature or something (can't never remember the order)
<vila> err, lp:~vila/ubuntu/precise/bzr/my-feature
<lamalex> well those are sort of outside our specific use
<vila> k
<lamalex> vila, we want a push hook that creates a jenkins job for continuous integration on our projects
<lamalex> when a dev pushes his/her branch to LP we want a jenkins job created to start running the test suite during the development life of the branch
<lamalex> then our merge bot will have a hook to delete the job when the branch gets merged
<vila> nice
<lamalex> yah
<lamalex> very slick ;)
<lamalex> so we want the project name for naming the job
<lamalex> i guess i can just use the branch name though
<lamalex> it's not that important and just sounds a lot simpler
<lamalex> will avoid conflicts
<lamalex> ill just do that
 * vila nods
<vila> lamalex: I'd be very interested in a such a plugin myself ;)
<lamalex> vila, are you a canonical employee by chance?
<vila> exactly, by chance 8-)
 * jelmer waves
<jelmer> vila: should we get rid of the curl backend in 2.6 or 2.7 ?
<vila> well, for peace of mind, I would target a removal at the *end* of 2.6 to make sure we "got them all" (those pesky little forgotten details turning into bugs ;)
<vila> hmm
<vila> end of 2.6 == release 2.6.0
<vila> a test failing at this point should be easy to write no ?
<jelmer> what sort of failing test?
<vila> until then, "install pycurl" is an easy workaround to davise
<vila> advise
<vila> one asserting that we had removed the pycurl backend
<vila> now that urllib is the default backend nobody should be using it right ?
<mgz> jelmer: did you work out what the bzr-builddeb issue on precise was? I didn't get the same issue here, and the ppa dailies also seem to be different issues
<vila> speaking of ppas, any news from maxb lately ?
<mgz> (and today I don't know where to find the error)
<mgz> vila: hm, nope, and various of our advertised ones are pretty out of date
<vila> yup, maybe he'll be willing to pass the torch... I know he had some handy scripts which would be good to use
 * maxb is around.... ish
<vila> maxb: \o/
<vila> maxb: can we help each other to bring our ppas up to date in a "let's do it one step at a time" mode ?
<jelmer> mgz: yeah, that's on my todo list
<mgz> can you paste/forward/something me the build output?
<jelmer> mgz: was directed at me?
<mgz> jelmer: yes, telling me where to look would also work if it's recorded somewhere
<jelmer> mgz: the build failure is on the launchpad package page for bzr-builddeb
<vila> maxb: starting by finding a time when we can talk briefly :-D
<mgz> jelmer: thanks, so it is... looked at that page and didn't manage to navigate to the right place
<leo2007> I heard about a plugin to handle ChangeLog merge conflicts. Any idea what is it called?
<jelmer> hi leo2007
<leo2007> hi
<jelmer> see 'bzr help changelog_merge'
<leo2007> where is location.conf?
<jelmer> leo2007: ~/.bazaar
<jelmer> locations.conf
<leo2007> bzr help changelog_merge says location.conf
<leo2007> typo?
<jelmer> it says locations.conf here - perhaps that was fixed recently
<leo2007> ok, I am running 2.4.2
<wgz> bajoing
<mgrandi> hiii
<lamalex> hi, why would get_push_location be returning none when i'm pushing somewhere??
<lamalex> and there's a push location in bzr info
<mgrandi> not sure :<
<lamalex> ha
<lamalex> nice
<lamalex> it /should/ be working though?
<lamalex> push_result.target_branch.get_push_location() should be giving push_location
<lamalex> right/
<mgrandi> im not too familiar with the source code (yet), but itprobably should
<mgrandi> does it only return it if its remembered?
<lamalex> I can only get it to return None
<mgrandi> see what it does if you do bzr push <whatever> --remember
<lamalex> same
<lamalex> None
<james_w> lamalex, you are looking for the place that the target branch would push to by default?
<lamalex> james_w, I'm writing a post-push hook and im looking for the place it was pushed to
<james_w> ah, hmm
<james_w> lamalex, you want to know the URL for reporting?
<lamalex> no im going to parse the launchpad project out of it
<lamalex> which will be used to create a jenkins job
<mgrandi> maybe one of the bzr developers can chime in if they are here
<james_w> lamalex, push_result.target_branch.user_url is what you want I think
<lamalex> still seems like a bug that get_push_location() returns None pretty much exclusively
<lamalex> but yeah- that works
<lamalex> thanks
<lamalex> :)
<james_w> lamalex, get_push_location() is looking at where the target branch would push to if you ran "bzr push" in it
<james_w> lamalex, and if it's on Launchpad it probably doesn't have that set
<james_w> that's my guess at least
<lamalex> james_w bzr info shows a push a brnach though
<james_w> lamalex, "bzr info lp:whatever" ?
<lamalex> im doing bzr push lp:whatever from a working branch
<james_w> right
<james_w> and "bzr info" will return lp:whatver
<mgrandi> does whatever you are calling get_push_location on the branch you have locally or the branch you pushed to?
<james_w> but push_result.target_branch.get_push_location() is like running "bzr info lp:whatever"
<james_w> if that returns a push branch then I'm clearly talking nonsense
<lamalex> AH
<lamalex> got it
<lamalex> right
<lamalex> tricky
<mgrandi> so push_result is referring to the branch you just pushed to?
<james_w> mgrandi, it's an object that is passed to a post_push hook, and has references to the source_branch and target_branch that were involved in the push
<mgrandi> ah
<mgrandi> so target_branch is launchpad or something, gotcha
#bzr 2012-03-10
<cody-somerville> What does this mean?? bzr: ERROR: Start revision not found in left-hand history of end revision.
<vila> cody-somerville: presumably from 'bzr log', you asked for a revision range for which the link between the revisions is not trivial, fixed in later bzr releases (I'd say >= 2.5)
<cody-somerville> I'm running 2.5b2
<vila> right, I'm not fully here, could be b5 or b6 or even 2.5.0
<vila> what is from bzr log ?
<vila> which revision range did you use
<vila> using a larger one can work around the issue, there is a way to escape (can't remember it right now, may be -n0 ?)
<vila> which setup are you using to end up with 2.5b2 ? Can't you upgrade ?
<vila> cody-somerville: I will be there for only a few minutes :-/
<cody-somerville> I'm doing bzr log -r 95.1.16..96
<vila> Does -n0 help ?
<cody-somerville> vila, no change
<vila> can't upgrade ?
<vila> I fixed that bug in anger as it was really a stupid limitation but now I can't remember the work around :-(
<cody-somerville> I'm using bzr from beta ppa. I'm on maverick.
<cody-somerville> err
<cody-somerville> natty
<vila> grrr
<vila> an alternative would be 'bzr qlog'
<vila> iirc correctly, the issue is related to mixing simple revnos (96) and dotted revnos (95.1.16)
<cody-somerville> interesting
<cody-somerville> 'bzr log -r 85.1.1..' produces same error
<cody-somerville> -n0 fixes that one though
<vila> yup, the invisible revno after '..' is the current one
<cody-somerville> ah
<cody-somerville> r85.1.1 lives under r92 :/
<cody-somerville> err
<cody-somerville> r91
<vila> qlog (from the qbzr plugin) is the best I can think of
<vila> gtg, sorry for all the trouble :-/
<cody-somerville> cheers
<vila> cody-somerville: that's bug #904744 so fixed in 2.5b5
<ubot5`> Launchpad bug 904744 in Bazaar "bzr log -r bzr-2.5b3..bzr-2.5b4 fails" [Medium,Fix released] https://launchpad.net/bugs/904744
<vila> fixed 3 months ago and not available to you, epic fail :-(
<mathrick> hi
<mathrick> $ bzr branch git://github.com/brutall/brut.apktool.git apktool
<mathrick> bzr: ERROR: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.
<mathrick> halp?
<mathrick> aka, bzr branch doesn't have any option to control the format it will use
<mathrick> and bzr pull from that repo to an init'd development-subtree branch fails with   File "bzrlib\branch.pyo", line 180, in open
<mathrick> TypeError: open_branch() got an unexpected keyword argument 'possible_transports'
 * mathrick pokes jelmer gently
<LarstiQ> mathrick: bzr-git and bzr versions out of sync?
<mathrick> hmm
<LarstiQ> mathrick: you can pass --standalone to branch in order not to use the containing repo
<LarstiQ> mathrick: I'd hope that it would then pick a suitable format to store things in
<mathrick> well, it's not a repo I was trying to branch to
<LarstiQ> gah
 * LarstiQ runs into stable vs testing issues installing dulwich
<LarstiQ> squeeze-backports to the rescue
<LarstiQ> hrmf
<LarstiQ> mathrick: so I'm having some trouble reproducing due to other hurdles
<mathrick> LarstiQ: yeah, fortunately I don't really need to do a whole lot of git there, so I just installed real git and cloned it that way
<LarstiQ> mathrick: but if you could confirm with --standalone to be absolutely certain, then I would argue it is a bug
<mathrick> sure
<mathrick> yes, same thing with --standalone
<LarstiQ> mathrick: do you want to report it, or shall I?
<mathrick> I'd appreciate if you did
<LarstiQ> sure thing
<mathrick> thanks
<LarstiQ> mathrick: in the process of gathering some more data, I'll tell you the bug number when I've filed it
<mathrick> k
<LarstiQ> mathrick: https://bugs.launchpad.net/bzr-git/+bug/951494
<ubot5`> Ubuntu bug 951494 in Bazaar Git Plugin "branching a standalone branch complains that the repository does not support submodules" [Medium,Confirmed]
<LarstiQ> mathrick: in terms of code, I think the problem is that the initial branch is made before we discover that submodules are present
<LarstiQ> mathrick: I don't know how involved it is to detect that first
<mathrick> right
<LarstiQ> mathrick: the other option would be for bzr-git to default to a subtree aware format, not sure about that either
<LarstiQ> jelmer: ^^
<jelmer> hi mathrick, LarstiQ
<jelmer> see my comments on the bug report - we don't really want to silently create branches in experimental formats
<SinnerNyx> hello, i'm new to bazaar. I have an SFTP server, and I was told that this is all I would need to start using bazaar. I'm on windows and I downloaded the bazaar windows package, which says it comes with tortoisebzr (which i figure to be similar to tortoiseSVN), but I can't find where I can start the program or make a repository?
<beuno> SinnerNyx, have you looked at the tutorials?
<beuno> http://doc.bazaar.canonical.com/bzr.2.5/en/mini-tutorial/index.html
<SinnerNyx> beuno, sorry, I thought those explained the CLI
<beuno> SinnerNyx, ah, they do, but I guess it's easy to translate to the GUI
<SinnerNyx> beuno, thats good except i'm asking where the GUI is...
<SinnerNyx> how would I start the gui for instance?
<beuno> ah
<beuno> I wouldn't know on Windows, sorry
<SinnerNyx> beuno no worries. How is it on your system?
<beuno> let me see if I can dig up some docu
<beuno> entation
<beuno> oh, I've been using the CLI for too long  :)
<SinnerNyx> lol
<SinnerNyx> fair enough. To be honest I'm about to make a repository for my team of 3, and the other 2 aren't the most technical
<SinnerNyx> so I'm avoiding CLIs as much as possible
<beuno> SinnerNyx, for setting things up, you can use the CLI
<beuno> and then to interact, use the GUI
<SinnerNyx> that's fine, but I need to figure out the GUI first. I want to see if it's appropriate and usable by my team
<beuno> SinnerNyx, there's also this: http://doc.bazaar.canonical.com/explorer/en/
<beuno> seems to have a nice tutorial: http://doc.bazaar.canonical.com/explorer/en/tutorials/foss-contribute.html
<SinnerNyx> sweet, this looks good actually
<SinnerNyx> thanks alot beuno
<beuno> np
<SinnerNyx> ok so now I'm trying to init a repo. I've done it and it says: http://pastebin.com/7LjLymFy
<SinnerNyx> how do I now make this available on my SFTP server?
<jelmer> SinnerNyx: you want to create a branch, rather than a repo (which is just a working environment)
<jelmer> SinnerNyx: once you create a branch, push it to somewhere on your sftp server, "bzr push sftp://yourserver/some/location/branch"
<SinnerNyx> Ok, I am clearly outclassed here, I'll need to read more about repos
<SinnerNyx> jelmer, so I'd make a repo on the server?
<SinnerNyx> jelmer, I'm not understanding, from what I'm reading I want to make a repo as a 'trunk' and then upload that to the server
<SinnerNyx> or else make a trunk on the server and update it with my source
<mathrick> SinnerNyx: offtopic question: brony?
<SinnerNyx> mathrick: lol, no idea what or who that is
<mathrick> that means no then :)
<SinnerNyx> i figured as much :p
<SinnerNyx> sorry for the newb questions, but i've never really had to set up a repository on my own before
<mathrick> SinnerNyx: http://en.wikipedia.org/wiki/MLP:_FiM#Internet_following . I highly recommend watching it, but as I said, it's terribly offtopic. It was just that your nickname suggested you might be that.
<SinnerNyx> LOL, what the...
<mathrick> jelmer: obviously that's not what I had in mind, but the problem is that it tells you to create a branch in a format with subtree support, and that's not at all possible using the current UI, as far as I can tell
<mathrick> jelmer: I'll check what got out of date here and try the init + pull route, and if it works, then it would probably be prudent to suggest that in the error message
<mathrick> AFAIK, development-subtree is not the only format to support nested trees
<SinnerNyx> mathrick, over my head
<mathrick> SinnerNyx: there's a fanfic called "past sins" where the main character is called Nyx. That's why I thought you might be a brony. But even if you aren't, it's still not too late. Just watch MLP: FiM, it's more than awesome :)
<mathrick> *"Past Sins" even, to use the title capitalisation
<SinnerNyx> lol, thanks mathrick
<SinnerNyx> hilarious, thanks mathrick. i'll stick to trigun
<jelmer> SinnerNyx: sorry, was away for a bit
<SinnerNyx> no worries, had an interesting conversation about "My Little Pony" :P
<jelmer> SinnerNyx: you want to make a branch as a trunk ("bzr init foo"), not a repository (which is merely a central location where version control data is stored)
<jelmer> hah, I was wondering what MLP was the TLA for..
<SinnerNyx> lol
<jelmer> mathrick:  you can create a branch with subtree support using 'bzr init --development-subtree'
<SinnerNyx> so jelmer, I did an init, and it worked I think. but now how do I get it up to my sftp server? I can't get it to connect. bzr: ERROR: Unable to connect to SSH host orcaweb.zapto.org:4489; Error reading SSH protocol banner
<jelmer> Odd_Bloke: oh, that's odd - does 'sftp -p 4489 orcaweb.zapto.org' work?
<jelmer> argh
<jelmer> SinnerNyx: oh, that's odd - does 'sftp -p 4489 orcaweb.zapto.org' work?
<jelmer> Odd_Bloke: sorry!
<SinnerNyx> jelmer: first which port should i use? explicit ssl or implicit?
<mathrick> jelmer: yes, that's what I did, although it failed with some errors suggesting bzr-git being out of sync with bzr. However, that's 1) not possible from the `bzr branch` UI 2) not at all obvious from the error message, especially for someone who is trying to just clone a repo without necessarily being intimately familiar with bzr
<mathrick> jelmer: I assume that what you have in mind is init manually, then pull, right?
<jelmer> mathrick: yes
<SinnerNyx> jelmer, I'm on windows. no sftp command
<mathrick> then I think the error message should say so
<SinnerNyx> winscp can connect fine if that makes any difference
<jelmer> mathrick: I wonder actually, if we perhaps just shouldn't have that message say "sorry, repositories with submodules aren't supported yet" rather than hinting people to use experimental formats
<jelmer> SinnerNyx: ah, yeah - that's what I was wondering
<mathrick> jelmer: but there are more subtree formats than just development, no?
<jelmer> mathrick: no, there's only development subtree formats at the moment
<jelmer> SinnerNyx: and you're using using sftp in winscp, rather than plain ssh (with e.g. scp) ?
<SinnerNyx> o snap. i see the problem I guess. I'm using FTP with explicit SSL and implicit SSL ports. so Should I just try to connect with ftp://orcaweb.zapto.org?
<jelmer> SinnerNyx: ah, yes - ssl with ftp is a different thing than SFTP (which is a protocol tunneled over SSH)
<SinnerNyx> oops, sorry jelmer
<mathrick> jelmer: oh, I know I've used subtrees way before 2a was introduced with the then-development format. What happened to all that?
<mathrick> jelmer: also, what about the 'git' format?
<jelmer> mathrick: subtrees have never been in any stable formats as far as I know
<mathrick> ah
<SinnerNyx> jelmer: I tried the explicit port and it gave me: 530 Have to use explicit SSL/TLS before logging on. So I'm trying the implicit port but it's taking a long time...
<jelmer> mathrick: the git format is the format used by git (which does support submodules to some degree, but doesn't support other things like revision ids, file ids or revision properties)
<jelmer> SinnerNyx: no worries; I don't think bzr supports FTP over SSL though
<SinnerNyx> :(
<SinnerNyx> so an sftp server is an ssh server that tunnels to a regular ftp server or that has an ftp server on it?
<SinnerNyx> ?
<jelmer> SinnerNyx: it's not really ftp - just "a" protocol for transferring files that's part of SSH
<jelmer> the name is a bit confusing
<mathrick> jelmer: and the git format is a real git tree (ie. would support submodules) or just something that's "git" from bzr's perspective?
<mathrick> SinnerNyx: and for extra points, you can actually run SFTP over things that aren't SSH at all, though it's not a very popular option
<SinnerNyx> http://pastebin.com/8FypuyAp
<SinnerNyx> bug report?
<SinnerNyx> didnt see that coming
<SinnerNyx> jelmer so what kind of secure quick server can i put up that will let me host a bzr repo?
<SinnerNyx> or branch...
<SinnerNyx> or whatever
<mathrick> jelmer: oh wait, I missed your reply, sorry
<jelmer> mathrick: it's a real git tree, but while it supports submodules it lacks support for some other things
<mathrick> right
<jelmer> SinnerNyx: A SSH server should work
<mathrick> it's a pity the nested trees have been in the work for such a long time. It's a very useful feature
<jelmer> mathrick: there has been some progress on it recently, we have a roadmap (that I still need to put into bzr.dev)
<mathrick> any chances of it landing in 2.5, or is it clearly a 2.6(+?) thing?
<jelmer> SinnerNyx: a bug report would be nice (though mostly we just shouldn't print a traceback in this case but a simple error message)
<jelmer> mathrick: it definitely won't be in 2.5, as 2.5.0 is already out
<jelmer> mathrick: I think 2.6, yes
<mathrick> oh, I haven't been paying attention :)
<mathrick> cool then
<SinnerNyx> jelmer was that directed to me?
<jelmer> SinnerNyx: yes, the bit about the bug report (from your pastebin)
<SinnerNyx> kk
<mathrick> jelmer: also sometimes I feel like all I've seen in bzr was bugs (I certainly have uncovered more bugs than I'd like) and not working code, but that's probably because I've started using bzr way back. And anyway the impression always disappears when I try to use other VCS, where the bugs are designed in :)
<mathrick> *cough*git*cough*
<SinnerNyx> jelmer i'm confused
<SinnerNyx> filezilla claims to be able to handle sftp...
<SinnerNyx> so is that the wrong 'sftp'?
<mathrick> jelmer: commented on the bug
<jelmer> mathrick: :)
<jelmer> mathrick: thanks
<jelmer> SinnerNyx: is filezilla your server?
<SinnerNyx> jelmer indeed
<jelmer> SinnerNyx: it probably won't be listening on the same port as ftp though
<SinnerNyx> I have two ports set up. the first is explicit SSL/TLS. The other is implicit SSL/TLS
<SinnerNyx> that's all I know.
<mathrick> SinnerNyx: sftp generally uses port 22, ie. the ssh port
<mathrick> jelmer: does that kind of message sound sensible to you?
<jelmer> mathrick: That message is more correct for your case, but the original was more appropriate for other situations (e.g. when you have a clone of a git branch and a pull operation would pull in submodules that have recently been introduced upstream)
<mathrick> hmm
<mathrick> well, it'd still work in that case
<mathrick> ahh, I see what you mean
<jelmer> mathrick: I think at this point it might be better to just say "sorry, submodules don't work" instead of suggesting to users that they somewhat do only to find out that stuff breaks later
<mathrick> fair enough
<jelmer> admittedly the original message is pretty bad because it just tells users to upgrade, rather than making a note about the consequences of using development-* formats
<jelmer> mathrick: did it work ok for your git repo?
<mathrick> ah, I didn't have the time to fix it yet
<mathrick> will report back when I do
#bzr 2012-03-11
<Pikkachu> doesn't bazaar keep track of hidden files in windows?
<Pikkachu> no output for bzr diff && bzr status when I changed some files to be hidden
<bob2> it doesn't version permissions and modes aside from executableness
<Pikkachu> ah ok
<Pikkachu> thanks
<bob2> well, at least in the past anyway
<wgz> thanks for the ppa updates maxb
<LarstiQ> hmm, http://wiki.bazaar.canonical.com/UserPreferences doesn't seem to work
<LarstiQ> that or the login functionality
<wgz> try again, for some reason the wiki has been flakey recently
<LarstiQ> wgz: I think my problem is due to moving wiki infrastructure. It redirects me to ubuntu-sso, which I don't have.
<LarstiQ> wgz: do you know how I can contact the responsible sysadmins?
<wgz> not really, I presume asking in the internal #is channel someone would tell me, but not sure over the weekend
<wgz> probably just posting something the the bazaar list is the best idea
<fullermd> Eh, the wiki login went all wonky for me years back when it switch to bouncing through LP, and never recovered (at least, not so's I noticed).
<LarstiQ> wgz: right, I'll do that when I'm out of ideas
<jelmer> LarstiQ: you do have ubuntu-sso, it's just the same as the launchpad logins
<LarstiQ> jelmer: it has a different set of email addresses
<LarstiQ> jelmer: so it looks like there is at least _some_ divergence
<jelmer> oh, that's odd
<jelmer> IIRC the Launchpad SSO and Ubuntu SSO are just the same thing
<LarstiQ> jelmer: from where I sit I'd guess they took a copy of my data at the time
<LarstiQ> but that may well be far off the mark :)
<maxb> LarstiQ: Launchpad SSO and Ubuntu SSO are the same thing.  BUT Launchpad and Launchpad SSO are not, and each have their own list of emails
<maxb> Yes, this is mad.
<maxb> It's an unfortunate result of separating SSO whilst attempting to avoid upsetting people who would be upset by Launchpad depending on not-Launchpad something
<LarstiQ> maxb: aaah
<LarstiQ> maxb: also from a ux perspective, when I'm already logged into launchpad, having ubuntu-sso prompt for credentials makes it seem different
<maxb> It's a bit of an UX disaster all round :-/
<maxb> There is a special perversity to *Single* Sign On *Doubly* Branded
<LarstiQ> heh :)
<jelmer> hmm, when did GPGStrategy grow into the 10-feet monster that it is?
<antono> yo!
<antono> how can i create local colocated branch in bzr 2.5 ?
<antono> git checkout -b new_branch == bzr ... ?
<jelmer> antono: "bzr switch -b new_branch"; though it should be noted that colocated branches are still experimental and unpolished
<antono> jelmer: i want to try it anyway
<antono> jelmer: thanks!
<antono> jelmer: it works :) all other workflow stays the same as before?
<antono> one problem. when i switched to new branch then bzr branches does not show previous trunk
<jelmer> antono: right, that's one of the things that's still unpolished
<jelmer> the first time you switch to a colocated branch you probably want to run "bzr switch -b trunk"
<antono> exactly what i did :)
<antono> not sure what will be remote repository for trunk now
<antono> jelmer: how can i merge one colocated branch to another?
<jelmer> antono: "bzr merge file:.,branch=someotherbranch"
<jelmer> antono: eventually it should be "bzr merge co:someotherbranch"
<antono> jelmer: last one looks better
<antono> jelmer: thanks
<LarstiQ> jelmer: or possibly `bzr merge someotherbranch` even?
<jelmer> LarstiQ: possibly, though we need to watch out for ambiguity
 * LarstiQ nods
<LarstiQ> sinzui \o/
<wilx> Hi.
<wilx> Can I move branches/directories inside a repository into sub-directories while keeping them ok/functional?
<wgz> yep.
<wilx> Cool. Thanks.
<maxb> Hmm, interesting. The dulwich test hang on lucid/maverick is client.fetch_pack(...) blocking forever on a socket read
<maxb> looks like I can get away with building dulwich on maverick just by deleting the tutorial doctest
<wgz> hm, doctests strike again
#bzr 2013-03-04
<GeorgeJ> HEllo folks!
<GeorgeJ> I've got to work on a project that's written in Bazaar. How does one import a Bazaar repo into git, and eventually merge changes that are in a remote bazaar repo?
<jelmer> GeorgeJ: the easiest thing to do is probably to use fastimport
<GeorgeJ> jelmer: Thanks. I'm giving https://github.com/termie/git-bzr-ng a spin.
#bzr 2013-03-06
<bigjools> is there a way of specifying a particular co-located branch in the submit_branch config in locations.conf?
<bigjools> and in fact how to make push_location work for colo branches, since it doesn't seem to append the branch name to the location like it does for normal branches
<janimo> is there a good solution for continuosly mirroring a bzr repo from LP to a git repo?
<pfsmorigo1> hi, is there a way to umcommit all my local commits?
<pfsmorigo1> *uncommit
<jelmer> pfsmorigo1: I guess in theory 'bzr up && bzr revert' will do that
<LeoNerd> Define "local commits". What makes one more local than another?
<pfsmorigo1> LeoNerd: I mean the commits from my local branch...
<jelmer> pfsmorigo1: Generally we use local commits to mean commits made with 'bzr commit --lock' in bound branches
<pfsmorigo1> jelmer: oh I see
<maxb> s/--lock/--local/
<jelmer> maxb: euhm, yes :-)
<jelmer> maxb: also, hi! What are you up to these days?
<maxb> Still in London, and reluctantly watching git gain mindshare at work :-/
<jelmer> maxb: :-(
 * jelmer is in London too these days
<maxb> Not that I'm actually working with git myself much, I just seem to have ended up running the internal hosting infrastructure :-)
<LeoNerd> Ah, hi maxb.. LTNS
<maxb> Yes indeed - get yourself to HitW one of these weeks! :-)
<LeoNerd> Yesyes.. I know...
<LeoNerd> Perhaps I'll drag jelmer along one day too.. He sits about 3 desks from me ;)
<fullermd> It's like watching a bunch of plutonium atoms start clumping together, working toward critical mass  :p
<maxb> Heh, it really is a small world sometimes :-)
<fullermd> Lucky I'm safe on the other side of the pond...
<jelmer> HitW?
<KombuchaKip> Can anyone recommend a decent graphical Python debugger, besides WinPDB, that handles python 3?
#bzr 2013-03-07
<efes> Hello ( :
<efes> I'd like to create my local repository from read only branch. At the same time I'd like to create an another branch to keep my sources in different branch than project's main. Do I need "bind new branch to parent location" option?
<vila> jelmer: I'm using bzr-gtk trunk (where bzr-notify has been removed). Yet, I get notifications (good) and those weird progress bars hanging around (bad).
<vila> jelmer: It puzzles me that I still get notifications but can't find what I did to retain them across their removal from bzr-gtk trunk.... Any idea ?
<vila> jelmer: wtf... 'bzr-notify is /usr/bin/bzr-notify' on raring ?
<vila> ooohh, bzr installed system-wide relying on bzr-gtk installed system-wide, no wonder I couldn't find anything relevant when running bzr from sources, ok, thanks for the help :-D
<vila> jelmer: and bzr-dbus getting in the middle of the mess right ?
<Pegasus_RPG> Hello. I'm trying to create a new branch that is _not_ stacked on trunk. how can I do that?
<Pegasus_RPG> (It contains a totally separate set of files but they're related to the main project)
<Pegasus_RPG> Just doing bzr push lp:~me/project/newbranch keeps stacking it on lp:~me/project
<vila> Pegasus_RPG: it's lp deciding to stack but that should be harmless for you, are you planning to stack on *another* branch at some point ?
<vila> Pegasus_RPG: harmless as in: "since you're pushing revisions that are unrelated to the trunk ones, you don't use the trunk ones"
<Pegasus_RPG> I'm not
<Pegasus_RPG> okay, so nothing to worry about?
<Pegasus_RPG> (bzr reconfigure --unstacked doesnt' seem to have any effect, BTW)
<vila> Pegasus_RPG: if you *really* want to get rid of the stacking on your newly pushed branch you can (once it's created) do: <interrupt> no, nothing to worry </interrupt>
<vila> bzr config -d lp:<new branch> --remove stacked_on_location
<vila> bzr config -d lp:new branch> before and after the command above to ensure you get it right
<Pegasus_RPG> ok thank you
<jelmer> vila:yeah, there are a fair number of open issues with bzr-notify :-(
<jelmer> vila: we discussed removing it altogether, did that not happen?
<jelmer> vila: ah, r794
<jelmer> probably hasn't made it into the debian/ubuntu package yet
<vila> jelmer: I breifly tried to debug but couldn't find how to get a pdb prompt to understand who is spawning the progress bar. I have a vague feeling the fix is probably one line to tell the offending code to use a silent pb...
<vila> jelmer: yup, that's my feeling as well, but since I'm stubborn sometimes I still like to be able to toy around with it ;)
<vila> jelmer: so there are really two things: how to properly remove bzr-notify for everybody and how to make it available locally to me so I can fix it ;)
<vila> jelmer: I'm of course a teeny bit more interested by the later but I won't mind helping for the former ;-D
<jelmer> vila: for the first, get one of the debian packagers to merge a new upstream snapshot :)
<jelmer> vila: for the second, I guess you can just reverse merge r794 ?
<vila> jelmer: and uninstall the system-wide versions ?
<vila> jelmer: and... I miss the step to activate it locally for my dbus session (instead of the system one)
<jelmer> vila: using the local dbus session requires James Henstridge's bzr-dbus branch
<vila> jelmer: lp:~jamesh/bzr-dbus/kill-broadcast-daemon ??
<jelmer> vila: yeah, that'sit I think
<vila> jelmer: ok, thanks, I know what/where to look next
<jelmer> vila: I think there were conflicts if you try to merge it into lp:bzr-dbus trunk nowadays though
<vila> jelmer: yup, I saw your review, thanks
<vila> jelmer: I understand I new a bit more fluency with dbus and that may just be the right exercise
<fullermd> Somehow, this puts me in mind of "I've been wanting to learn a bit more about conducting open-heart surgery, and these chest pains I've been having all week seem like the perfect opportunity!"
<jelmer> fullermd: I'm not sure if a broken bzr-dbus is quite as life-threatening.
<fullermd> But it's not as cool to dig into either.
 * vila feels warmer reading fullermd writing about me and his heart ;)
<jelmer> vila: Does bzr-dbus actually still work ?
<vila> jelmer: err, I get notifications with the versions installed system-wide in raring, not sure that answers your question though ;)
<jelmer> vila: I guess that is a yes.
#bzr 2013-03-08
<jelmer> moin
<xnox> jelmer: will you be at the hackfest tomorrow at your offices? =)
<jelmer> xnox: yep, see #launchpad-dev :)
<xnox> jelmer: I'm not on #launchpad-dev =)))) only #launchpad . I'm not l33t enough for launchpad-dev, will catch up on irclogs.u.c
<jelmer> xnox: hah, you should be :)
<DrFredPhD> Could anyone help me fix bzr timing out during a checkout?
<DrFredPhD> please?
<bsd> Hi everybody.  Is there a way to relax bzr's locking?  I'm trying to use it to update a branch across a VMware shared folder and get an error:
<bsd> LockContention: Could not acquire lock "/Volumes/VMwareSharedFolders/d1/.bzr/checkout/dirstate": [Errno 45] Operation not supported
<mgz> bsd: don't do that? bzr is happy with multiple branches, have a copy inside the vm and a copy outside, rather than trying to share across a filesystem protocol that isn't trustable
<bsd> mgz: it's a huge branch, and I like to keep VMs as throw-aways (lost data a few times).  I'm using the VM to update via a restrictive VPN that effectively disconnect my machine
<mgz> even a checkout over a local loopback would be too expensive?
<alchemyst> hi all! I need some help, it's my first time trying to set up a versioning system and i'm doing something wrong...
<alchemyst> i googled this error but i got no info at all:  bzr: ERROR: Generic path error:
<alchemyst> i'm an ape the error is this one: bzr: ERROR: A control directory already exists:
<alchemyst> thanks anyway, i'll try again tomorrow
#bzr 2013-03-09
<alchemyst> Hi all! I'm trying to set up a bazaar versioning on an ftp but i get an error when i try bzr init ftp://user@server/folder, the error is the following: "bzr: ERROR: A control directory already exists:"
<lifeless> alchemyst: and does it ?
<alchemyst> ...nope...no folders inside
<lifeless> alchemyst: no .bzr folder? They are hidden by default
<alchemyst> i know...but "ls -la" should do...
<lifeless> interesting
<lifeless> you could try --use-existing-dir, but I wonder whether you have a 'special' FTP server of some sort
<alchemyst> yup you're right
<alchemyst> i'm trying to put it up on my router's ftp
<alchemyst> i didn't think it was a problem...
<SamB_> heh
<SamB_> you mean one of those little boxes with the strange operating systems?
<alchemyst> yes, and with usb port to support storage from usb
<alchemyst> i just felt like "why not?" XD
<SamB_> well, I guess you still don't know "why", but you do know the "not"
<alchemyst> certainly...i guess if i could host one on my pc and upload it in block...but that would ruin a little the purpouse of the experiment...
#bzr 2013-03-10
<SunilJoshi> hello, i am getting difference in my files as properties changed: -x to +x.... any idea about this?
<SunilJoshi> i hv a dual boot Windows 7  + ubuntu, repos was originally checked out in windows and i am using the same in ubuntu.. now
<vila> wow, 3 minutes waiting for an answer is too much ? Allo ? This is IRC ;)
<vila> SunilJoshi: Don't do that then.
<vila> SunilJoshi: bzr can hide the differences in the underlying file systems involved only if you don't lie to him pretending you're always using the same one.
<vila> *to it (bzr)
<vila> SunilJoshi: The root cause here is that even when bzr tells the file system to *not* change the 'x' property, said file system silently ignores bzr request.
<vila> SunilJoshi: So use different working trees, even if they share the same branch.
<vila> LarstiQ: Back to this "better diff" en emacs. I just remembered that 'e' is in dvc-diff buffer spawn an ediff session for the file at point. That may be closer to what you were after.
<vila> s/is in/in/ s/spawn/spawns/
<quotemstr> What's the easiest way of moving all uncommitted changes in one bzr working copy over to another working copy?
<ali1234> commit them?
<ali1234> if you really really want you can bzr diff > ../mypatch and then patch -p0 < ../mypatch
<lifeless> quotemstr: cd $another; bzr merge $one --uncommitted
<LeoNerd> Oooh.. merge --uncommitted :)
<LeoNerd> I was going to suggest shelve, move the shelf, unshelve. But that looks neat too
<quotemstr> lifeless: Thanks
#bzr 2014-03-03
<achiang> question on how bzr handles history and binary objects - let's say i have a repo where someone committed 100 jpgs in the first commit and it takes an excessively long time to clone. now, many commits later, if we bzr rm those jpgs, will the main branch still take ages to pull from LP?
<beuno> achiang, it will for the first time, yes
<beuno> achiang, they are there forever and ever*
<beuno> *unless you do something icky like rebase and break compatibility with existing branches
<achiang> beuno: are there any tricks i could play?
<achiang> hm
<achiang> rebase
<achiang> yeah
<achiang> can you bzr pull without grabbing all the history, perhaps?
<achiang> maybe something related to "shallow" ?
<beuno> achiang, I don't believe partial history was ever implemented
<beuno> maybe a lightweight checkout
<beuno> maybe
<achiang> does bzr even have rebase?
<achiang> bzr help says no
<beuno> not by default
<bob2> not built in
<beuno> there's: http://wiki.bazaar.canonical.com/Rewrite
<bob2> bzr-rewrite
<beuno> achiang, keep in mind once you rebase, all existing branches out there are incompatible/unmergeable
<achiang> ugh, yeah
<achiang> it might be better to do a rebase and then create a brand new branch
 * beuno nods
<achiang> beuno: but what if the existing branches out there are only "leaf" branches... that is, i do not expect any incoming MP's from them?
<beuno> achiang, then it shouldn't matter
<beuno> they won't be able to pull anymore without doing something like --overwrite
<achiang> beuno: could an existing leaf branch still successfully pull from lp:project ?
<achiang> ah
<achiang> a one-time --overwrite for the 1 or 2 people with the branch
<beuno> yeah, all the answers around this are going to to suck  :)
 * beuno nods
<beuno> if it's a small amount of people, it's manageable
<achiang> changing the branch name isn't fun either
<achiang> we actually have more consumers of that
<beuno> achiang, well, if you create a new branch, LP maps whatever to lp:projectname
<beuno> so I think that would be fine
<achiang> (but they have ephemeral environments and do brand new pulls every time)
<achiang> oh, that's interesting
<beuno> lp:projectname is a symlink, in that sense
<achiang> got it
<achiang> so i currently have 'trunk' and lp:project maps to trunk
<achiang> if i were to create say... trunc, i could remap lp:project to trunc?
<achiang> could i then delete trunk
<beuno> well, you have ~someteam/someproject/trunk
<achiang> and rename trunc => trunk?
<beuno> yes
<achiang> (the trunc is short for truncate, which is what i want to do with those jpegs ;)
<achiang> puns! everywhere!
 * beuno regrets helping
<achiang> boo
<achiang> so this is interesting
<achiang> the giant blobs were all added in literally -r 1
<achiang> but nothing else from -r 1 has survived over time
<achiang> so i wonder if that means my rewrite command will be easier, since nothing from that bad commit even remains anymore
<beuno> achiang, yeah, it may be easier to rewrite and chop off the first commit
<achiang> how do i install this plugin?
<bob2> note that everyone still needs to reclone
<achiang> bob2: noted
<beuno> achiang, IIRC, you throw it in ~/.bazaar/plugins
<beuno> just branch it in there
<achiang> ah, ok
<jelmer> achiang: please be warned that bzr-rewrite is a little bit rough around the edges
<achiang> jelmer: define "rough" ?
<jelmer> achiang: its UI is a bit clunky, and there there are some open issues around how it rewrites branches
<achiang> mmm...
<achiang> now that i've discovered that -r 1 is my bad commit, perhaps i should restate my question/problem: how might i clone a bzr branch with everything *but* the first commit?
<achiang> or Nth, commit, since in reality, i want everything from -r 4 onward
<jelmer> achiang: there isn't really a way to do that
<jelmer> you can do a lightweight checkout or a stacked branch to work around it
<jelmer> the revision will still be in your history, it just won't be pulled down to your local disk
<achiang> maybe i'll just experiment with rewrite for a bit and see how far it gets me
<beuno> o/ jelmer
<jelmer> hey beuno!
<achiang> jelmer: so briefly, what would the syntax of bzr rebase be here? i'm trying to grok the help you wrote but it's not clicking.
<jelmer> beuno: long time no see - how are things?
<jelmer> achiang: you probably want something like run "bzr replay -r2..-1 /path/to/original/branch" from a newly inited branch
<achiang> jelmer: will things get screwed up if i'm inside a repo?
<beuno> jelmer, things are good!  busy busy busy, so that doesn't seem to change over time  :)  You?  I heard rumours you moved to London voluntarily
<jelmer> achiang: no, it will not change any existing revisions - just add new ones
<achiang> jelmer: ok, thanks. i'll give it a shot
<jelmer> beuno: :) What are you hacking on these days?
<jelmer> beuno: I did indeed, working very close to the old C offices :)
<beuno> jelmer, as good of a view?   I'm doing a bit of everything nowadays, but the Ubuntu click appstore is probably the most exciting one
<jelmer> beuno: It's pretty much impossible to beat that view. :-)
<jelmer> beuno: Cool - that's the mobile side of things?
<beuno> jelmer, well, it's the future of everything!  but currently works best on phones and tablets, yes
<ychaouche> Hello !
<ychaouche> Is there a way to search in log messages ?
<jelmer> ychaouche: yes, bzr-search
<ychaouche> thanks jelmer
#bzr 2014-03-04
<rysiek|pl> ohai
<rysiek|pl> I keep getting this error:
<rysiek|pl> bzr: ERROR: Certificate error: no appropriate commonName or subjectAltName fields were found
<rysiek|pl> when trying to branch https://dudle.inf.tu-dresden.de/privacy/
<rysiek|pl> thing is, the certificate seems OK
<rysiek|pl> no idea why bzr keeps throwing this error at me
<fullermd_> Maybe it doesn't haev a full chain back to a trusted root?  I don't know whether that would cause a different error...
<rysiek|pl> fullermd_: well, you can check the site for yourself
<rysiek|pl> fullermd_: seems proper and fully trusted to me on 2 browsers
<fullermd_> Right, that's browsers.  Is bzr using the same set of roots, and has it the same chain available?  I have no idea.
<rysiek|pl> me neither :/
#bzr 2014-03-06
<fullermd_> LeoNerd: Y'know that LP says that pangoterm is GPL3, but the in-tree LICENSE is MIT/X?
<LeoNerd> Huhhh..oops
<LeoNerd> I should fix that
<fullermd_> Alternately, you could swap the 2 every month, just to keep people on their toes   ;)
<LeoNerd> Haha
#bzr 2014-03-07
<bePolite> Please can someone help me the the bzr equivalent to git stash
<bePolite> I am trying to revert the changes I made to a repository
<LeoNerd> Wow, nobody awake?
<LeoNerd> (the answer is  bzr shelve  for reference)
<_mj> https://answers.launchpad.net/bzr-explorer/+question/245103
<_mj> can anybody please help me with this ?
#bzr 2015-03-02
<xterm> Hello, I'm witnessing a locale problem that, for the life of me, I can't get rid of. I'd appreciate any help: http://ix.io/gFo
<fullermd> I'd sorta expect it to be case-sensitive.
<fullermd> (to say nothing of hypen-sensitive)
<xterm> I dropped the '-' out of desperation, the preliminary tests were purely `en_US.UTF-8` all over the place.
<fullermd> Other way around   :)
<fullermd> locale -a says the system knows about "en_US.utf8".  That's not gonna compare favorably with you asking for "en_US.UTF-8".
<xterm> So after further debugging, it turned out that the problem comes from this ZSH theme https://github.com/robbyrussell/oh-my-zsh/blob/master/themes/nicoulaj.zsh-theme#L33 on that specific line. Enabling 'bzr' prompted that error to occur inspite of the locale not changing between themes. I don't know the solution, but i just dropped that entry from enable, and all works well.
<sambuddhabasu1> can someone tell me how to use bzr through an http proxy?
#bzr 2015-03-03
<Rashi007__> hi
<Rashi007__> i am getting "proxy https launchpad.net, Realm :'Squid proxy-caching web server' username " error
<Rashi007__> can someone hep?
<sambuddhabasu1> can someone give me a brief demo of bazaar?
#bzr 2015-03-04
<wret> HI, i am getting "ssh_exchange_identification: Connection closed by remote host" error while accessing branch bzr lp:mailman
<Utal> Permission denied (publickey).
<Utal> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<Utal> Permission denied (publickey).
<Utal> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Utal> i am faching this problem while making ak local brunch
<Utal> can anybody help
<LeoNerd> Looks like fairly standard ssh key issues
<Utal> LeoNerd, how to solve that
<LeoNerd> Utal: Play with SSH
<LeoNerd> If the ssh(1) command works, then bzr will work
<LeoNerd> It's nothing to do with bzr
<Utal> LeoNerd, i dont have much idea on ssh can you suggest some
<LeoNerd> Huh?
<LeoNerd> ssh name-of-host
<LeoNerd> See if it works
<LeoNerd> use more -v
<LeoNerd> Check .ssh/id_*
<LeoNerd> Check .ssh/authorized_keys on the far side
<LeoNerd> Check all the usual things you'd check to make ssh work between two machines
<LeoNerd> That has nothing to do with bzr
<Utal> LeoNerd, ssh name-of -host does not work
<LeoNerd> Right. So make that work
<Utal> LeoNerd, how to do that
<LeoNerd> I listed many things
<LeoNerd> Go ask anyone
<LeoNerd> Seriously, anyone.
<LeoNerd> This is basic ssh-101 stuff.. nothing to do with bzr
<Utal> LeoNerd, thanks
#bzr 2015-03-06
<dsmythies> I have branched a package, and so have a local copy. I build it with:
<dsmythies> bzr builddeb -- -S -us -uc
<dsmythies> However, now I want to do a clean build, but I can not figure out how to do it. Can someone here help?
<dsmythies> I have been using "/usr/share/doc/bzr-builddeb/user_manual/building.html" as a reference.
#bzr 2015-03-07
<dsmythies> I see that I should have been doing this:
<dsmythies> bzr builddeb -- -us -uc
<dsmythies> Thanks anyway.
#bzr 2015-03-08
<elico> I want to count the lines of code in a repository and I have tried to search with google but yet to find a way to do that. any shortcuts about it?
<elico> For now the trunk code files lines stands on 716,867 !!!
<uelo> Is it possible to push a development branch as the first branch to launchpad?
#bzr 2016-03-11
<__marco> Hi! Can you please what [chroot-*:] in ~/.bazaar/locations.conf means?
<__marco> http://docs.buildbot.net/current/manual/cfg-changesources.html#p4source
<__marco> (scroll just few lines up)
<__marco> Sorry, I try again
<__marco> Hi! Can you please *explain me* what [chroot-*:] in ~/.bazaar/locations.conf means?
<fullermd> Maybe something LP related.
<__marco> Strange that they used a such obscure syntax in a guide
<fullermd> Mm.  Well, I don't know anything about buildbot...
