#bzr 2008-01-28
<Verterok> moin
<lifeless> abentley: walked in the door this morning
<abentley> I got back in Toronto last night.
 * Odd_Bloke smells the beginnings of a lifeless/abentley duet.
<abentley> Odd_Bloke: I actually do write songs.  If we're doing for an ABAB rhyme scheme, some possible rhymes are "warning", "scorning" and "a-borning"
<lifeless> abentley: I think yawning
<brink_> Time to turn off the light.
<igc> bbiab
 * igc lunch
<abentley> jelmer: IMO, hard links are not a problem, even if the files they refer to are in the same directory.  Operations that change files through TreeTransform always perform a safe replacement-- they don't overwrite file contents.
<abentley> So they automatically break hard links when the linked files are modified.
<igc> bbl
<piem> hi all
<piem> how should i move a repository from my laptop to my server?
<snod> with push
<snod> the exact protocol depends how you can connect to your server (sftp, ssh, ftp)
<piem> snod: so i should bzr push foo://, then rm local repo, and then bzr checkout foo:// ?
<snod> Ã¶hm
<snod> why do you want do delete your local repo?
<piem> snod: because i want to move it, as in cp + rm :-)
<piem> if i don't move the old branch away, i don't know how to merge from the updated branch i pushed earlier
<lifeless> 'bzr merge'
<snod> is it possible with bzr, to substitute some variables in a file you're commiting with the the revno for example?
<Kinnison> https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion
<snod> thank you
<piem> Kinnison!! :)
 * piem hugs Kinnison
 * Kinnison hugs piem. Ãa va?
<piem> bien! and you?
<Kinnison> pas mal.
<quik__> hey folks
<quik__> if I bzr push to an sftp location
 * rjek awaits the rest of the question :)
<quik__> I try to checkout from the location to grab the code ... I get "bzr: ERROR: Not a branch: "
<quik__> how can I pull a copy of my code, similar to svn export in subversion?
<quik__> and it puts bzr: ERROR: Not a branch: /home/ben/test/sftp:/myserver.com/projects/projectname
<quik__> yet my command was
<quik__> bzr checkout  -r 1 sftp://myserver.com/projects/projectname
<quik__> rjek: any ideas?
<snod> i think the path is wrong
<quik__> I copied it from where I pushed the repo
 * rjek is interested in why there's sftp:/myserver in the path in the error.
<rjek> Which is entirely wrong.
<quik__> how else would I check it out
<quik__> ?
<dato> is paramiko installed?
<quik__> no.
<dato> install it :)
<dato> you need it to use sftp
<quik__> I installed bzr with apt-get
<snod> but how could you push it to a sftp location without the lib?
<quik__> I guess it would help if it had it as part of the package
<dato> snod: maybe he pushed from a different machine
<quik__> correc
<quik__> correct*
<quik__> after installing paramiko I got "bzr: ERROR: unknown branch format: Bazaar Branch Format 6 (bzr 0.15)"
<quik__> so I guess I have different versions..
<quik__> that really blows
<dato> you have < 0.15?
<quik__> Bazaar (bzr) 0.92.0 and bzr (bazaar-ng) 0.8.2
<quik__> between the two system
<dato> 0.8 is very old
<quik__> its ubuntu packages
<dato> but if you really can't upgrade
<quik__> I could install from source I guess
<snod> na
<quik__> snod: how can I skip the silly error?
<Ng> fwiw, the bazaar website has packages for ubuntu of more recent versions
<snod> quik__: triy one of these https://launchpad.net/~bzr/+archive/
<snod> the repositories listed on the mainpage don't have the latest version
<snod> (for ubuntu)
<snod> there is backport for debian stable on backports too
<quik__> yey
<quik__> that worked.
<quik__> I updated it to 1.0-rc1
<mikl> What is the best web-frontend for bzr? Still loggerhead?
<ubotu> New bug: #161082 in bzr-svn "very hard to get going on windows" [Medium,In progress] https://launchpad.net/bugs/161082
<encompass> is there some documentation on how to setup your work to be ready to packaged?
<encompass> sabdfl: greets
<sabdfl> hey encompass
<encompass> Have you seen my latest work?  http://launchpad.net/memaker
<encompass> It's going to be a part of macslows brilliance
<igc> night all
<encompass> igc: gn
<encompass> I want to build packages of memaker, and ubuntu-motu told me there was a way to easily beuild packages with bzr...
<encompass> this sounds interesting, how is this done?
<encompass> The reason I ask is that we have no packagers and it would be nice if we did, or had some way of doing it easily ourselves
<jelmer> encompass: have a look at the bzr-buildpackage package
<jelmer> sorry, bzr-builddeb
<encompass> jelmer: thanks... that is a start :D
<mtaylor> encompass: bzr-builddeb is the best thing in the world
<mtaylor> abentley: you're running hardy, right? do you get segfaults when trying to run /lib/cpp ?
<abentley> mtaylor: I'm running Gutsy.
<mtaylor> oh
<mtaylor> hrm
 * mtaylor is going crazy
<andersson> encompass: Make deb-template with command dh_make (Think you find it in package devscripts) Make the package "CDBS" = Common Debian Build System. Then you're on your way
<andersson> + have a look at how to make a "native" package with bzr-builddeb as mtaylor said
<Nice27> hi
<slangasek> is it ok to ask questions here about bzr best practices wrt packaging branches on launchpad.net?
 * slangasek skips a pebble across the placid IRC channel
<jelmer> I think so, though launchpad-related things may be more appropriate in #launchpad
<dato> oh, slangasek, heh
<slangasek> jelmer: well, my question is in regards to https://wiki.ubuntu.com/BzrMaintainerHowto, which seems to somewhat punt on the question of using bzr-svn for registering packaging-only bzr branches
<slangasek> I'm unsure whether this is worth the effort, vs. just maintaining an ubuntu branch if I don't expect to be merging much from debian (it's for a package that the debian maintainers consider obsolete)
 * jelmer has a look at that wiki page
<jelmer> slangasek: It shouldn't be much of an effort to start with a branch imported from svn
<slangasek> well, ok
<jelmer> I don't see why you would necessarily have to register the upstream debian branch
<slangasek> but if I wasn't working with the packaging-only svn branch, I guess I would probably do a branch for the full source tree?
<jelmer> you can just "bzr branch svn://url-to-debian-package/ ubuntu"; cd ubuntu; hackety-hack; bzr push lp:...
<slangasek> right - but if I'm going to do that, maybe it's better to branch from the upstream source, do a one-time add of all the debian packaging, and bzr push?
<slangasek> (I'm increasingly disenchanted with packaging-only branches myself)
<jelmer> slangasek: There doesn't appear to be a consensus about whether to use packaging only bzr branches
 * jelmer prefers the full tree, but I know various people here who use packaging-only branches
<slangasek> jelmer: ok, setting aside the consensus -- are there good /tools/ for working with packaging-only branches? :)
<slangasek> i.e., how does one handle patch systems within a packaging-only branch in a non-suck manner?
<jelmer> well, you can use dpatch or quilt like you're used to
<slangasek> yes, but to actually manipulate the patches within, the parent dir of your packaging branch needs to be a source tree
<jelmer> You can rename the branch to "debian" and put it in the source tree and manipulate the patches that way
<jelmer> I've never done that though, this is one of the reasons why full source trees work better
<slangasek> right - I've done that in the past, I think it sucks because it means moving my checkout around every time I'm unpacking a new upstream version
<slangasek> (hmm, not that there's likely to be a new upstream version of this package either, but still :)
<jelmer> another way to use a full-source bzr branch and be able to merge from the debian packaging-only svn branch is to use "bzr join"
<slangasek> o-ho
<slangasek> that sounds like what I was just about to ask for :)
<slangasek> so then I can bzr branch the upstream, bzr branch the debian subdir, and bzr join?
<jelmer> yep, that's the idea
<slangasek> awesome
<slangasek> yes, /exactly/ what I was going to ask for :-)
<jelmer> and "bzr merge <debian-svn-url>" will still work then and do the right thing
<jelmer> you'll have to use the rich-root(-pack) format for this to work
<slangasek> bzr branch seems to (reasonably) decline to branch from the debian subdir though
<slangasek> bzr: ERROR: /grub/trunk/debian is not a valid Subversion branch path.
<jelmer> try removing ~/.bazaar/subversion.conf and trying again
<jelmer> that'll be fixed in bzr-svn 0.4.7
<slangasek> cool, seems to be working
<jelmer> abentley: Hmm, I just stated that merging will work here but I'm doubting now. Will it?
<abentley> jelmer: haven't read the context.
<jelmer> abentley: merging from a branch with a root id that is not a root id in the branch that we're merging into
<jelmer> abentley: but is present (as regular directory)
<abentley> That should work just fine.
<jelmer> sweet
<slangasek> ok, the join fails because of a wrong repo format...  bzr upgrade says I'm at the most recent... how do I get a tree that's dirstate-with-subtree as required by 'join'?
<dato> upgrade --rich-root or --rich-root-pack (if you're on pack-0.92) would be best
<dato> upgrade --dirstate-with-subtree is the other option, but it's experimental and shouldn't be needed, as per what jelmer said
<slangasek> works, cheers
<dato> (nb, rich-root requires >= 1.0, -subtree >= 0.15)
<jelmer> time to make rich-root-pack the default..
<abentley> It's a bit disturbing to see people using join, since that's a hidden command.
<jelmer> abentley: I thought join was considered stable now
<jelmer> abentley: and only join --reference was still experimental?
<abentley> Join without --reference is the only thing that's experimental.
<jelmer> but join --reference is only usable with with-subtree formats, no?
<abentley> But I haven't made --reference hidden, so the whole command's hidden.
<abentley> jelmer: true, it's only usable with -subtree.
<jelmer> abentley: is there a negative missing in your previous line?
<jelmer> s/without/with/ I mean
<abentley> jelmer: no, but "it" refers to "--reference"
<mtaylor> if I have a repo with tons of branches
<mtaylor> and I want to upgrade to rich-root-pack
<mtaylor> do I need to upgrade each branch, or will upgrading the repo do it?
<jelmer> abentley: so which bit became stable when you added the rich-root format?
<dato> mtaylor: just the repo, for this one upgrade
<jelmer> abentley: I vaguely recall there as some nested-tree feature that became non-experimental
<abentley> jelmer: join-by-value has been stable since before I implemented subtree formats.
<abentley> join-by-reference is still experimental.
<mtaylor> dato: awesome. thanks
<jelmer> abentley: Ahh, so there was actually a negative missing
<jelmer> abentley: thanks
<abentley> A negative missing from what?
<jelmer> "19:25 <abentley> Join without --reference is the only thing that's experimental."
<abentley> Oh, yes, that should be "with"
<jelmer> abentley: If we would hide --reference, would you be ok with making "bzr join" visible?
<abentley> But when you mentioned my "previous line", I thought you meant 01:26:50 PM) (abentley: jelmer: true, it's only usable with -subtree.
<abentley> jelmer: sure
<jelmer> ahh, sorry
<jelmer> I think slangasek's use case is one of the areas where by-value nested trees can be very useful
<jelmer> s/areas/examples/
<abentley> I haven't seen his use case, but I can well imagine there are uses for join.
<abentley> It's just upsetting when people are just randomly using things you've hid to protect them.
<jelmer> sorry, I didn't know join was still hidden
<jelmer> I'll see if I make that patch to hide --reference
<abentley> Cool.  I'm not sure whether Option supports a hidden flag.
<abentley> Btw, the "split" command is not hidden now.  That may be what you were thinking of.
<jelmer> ah - yep, that may be what confused me
<jelmer> I tend to think of them as complementing each other
<RainCT> Hi
<RainCT> I need a fast way to know what the current revision of a local branch is (for a script). What do you recommend?
<RainCT> cat .bzr/branch/last-revision   ?
<aidos> hi everyone
<aidos> i'm currently trying to switch from svn to bazaar, and i have a couple of questions
<aidos> any bzr gurus around?
<jelmer> aidos: hi
<aidos> hi jelmer. can i bother you then? :)
<jelmer> RainCT: "bzr revno" ?
<jelmer> aidos: just ask your question, I'm sure there's somebody who can answer
<aidos> jelmer: ok
<RainCT> jelmer: Ah :). But cat + cut is faster, is there anything I should know that makes 'bzr revno' better?
<aidos> so here's one of my main problem: I 've set up a bazaar repo with different project at the root, each of them with it's own /dev /trunk /merge as suggested in the bazaar documentation
<jelmer> RainCT: it works across formats
<dato> RainCT: it's resilient against branch format changes
<aidos> how can i retrieve all the trunks of all the projects without having to do a branch for each project ? like a "bzr multi-branch"
<RainCT> jelmer, dato: okay, thanks :)
<aidos> because in SVN i had all these projects in the same repo, so a svn checkout got me all the sources I needed. but i figured it 'll be pretty stupid and broken to put all the projects in the same branch in bazaar, but now i kinda really annoyed....
<aidos> sorry for the long reads :)
<jelmer> aidos: I don't think there's any way to do that yet
<jelmer> I've actually complained about that as well
<RainCT> aidos: if you use Launchpad and Ubuntu, if all the branches are owned by the same team, I think there's a a script in package ubuntu-dev-tools that does this.. I'm not sure thought.. let me check
<aidos> sadly my projet is not open source, so launchpad is not a option :)
<RainCT> ah :(
<jelmer> RainCT: that sounds interesting
<aidos> yeah. but thanks. I guess i'll write my own script then
<aidos> and is nested branch an option?
<aidos> nested branchES*
<RainCT> jelmer: it's there. get-branches (by dholbach) :)
<jelmer> aidos: by-reference nested trees are still experimental
<jelmer> RainCT: hmm, unfortunately I'm on Debian..
<RainCT> jelmer: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/
<aidos> jelmer: have you come up with any other tricks to solve that?
<jelmer> aidos: you can use something like rsync
<lifeless> moin
<aidos> jelmer: true. hadn't thought of that.
<aidos> jelmer: or even simply sftp ? since that's what i'm using with bazaar.
<dysinger> need to ask a question about shared repositories.  If I create one and then check some branches out into it and etc....  Should I do --no-trees or is that something for a shared repo on a server like git clone --bare ?
<dysinger> I think that's right
<asabil> dysinger: yes
<dysinger> ok
<asabil> the --no-trees is to be used on servers willing to save some disk space, by not having any tree in the repository
<dysinger> So If I am going to push multiple sibling branches to a server via sftp, should I create a shared repo --no-trees on the server for them to leverage pack-sharing ?
<jelmer> RainCT: the default ubuntu-dev-tools branch has syntax errors in get-branches
<RainCT> really? xD
 * RainCT never tried it..
<asabil> dysinger: a shared repo yes, --no-trees should be ok to reduce the disk space usage
<dysinger> kthx
<asabil> dysinger: also maybe you want to push over bzr+ssh:// instead of sftp://
<dysinger> ok
<dysinger> As long as I have bzr on the server ssh is more efficient that way ?
<asabil> that will require you to  install bzr on the server though, but will make the push damn faster
<dysinger> isn't ssh:// the same ?
<dysinger> (same as bzr+ssh:// ?)
<asabil> not sure if ssh:// exists
<dysinger> ok maybe I am thinking of git
<lifeless> we don't support 'ssh://' urls, just bzr+ssh
<lifeless> ssh:// indicates you want a terminal
<lifeless> whereas we want a bzr process on the other end
<dysinger> ok
<jelmer> and it would be very confusing since we support bzr+ssh:// and svn+ssh:// :-)
<jelmer> one day also git+ssh:// hopefully..
<asabil> that's something I always liked about bzr : true extensibility
<dysinger> I like the extensibility too - that and the windows compat are +2 for me - I use mac and linux but there is always one person on windows on my team.
<dysinger> Jelmer - did you enter the bug on subversion for the certificate acceptance problem we found with subversion 1.5 / bzr-svn stable ?
<dysinger> Could you send me the link so I can watch it?
<dysinger> I am using a hacked bzr-svn stable with the provider commented out of transport.py
<dysinger> It seems to work but I still get asked for authentication everytime even though "svn info xxxx" has already cached it (FYI)
<dysinger> Another common problem I have been seeing is that some svn projects have a structure where the trunk is on trunk/projectname but then the branches are just named branches/this-or-that and tags tags/some-version.   It seems bzr-svn thinks trunk/project name is a single-trunk and can't deal with the tags or branches.  If I change it to be branching-scheme trunk then the branches and tags work but I cant update trunk ever again with it like tha
<jelmer> dysinger: I've just fixed that in the 0.4 branch
<dysinger> the provider thing?
<jelmer> dysinger: No, the last problem you mentioned
<dysinger> ah - do I need to change my subversion.conf ?
<jelmer> dysinger: It'll allow you to branch in those situations but won't allow merging between those branches unless you explicitly set the branching scheme
<jelmer> I haven't looked into the SSL certificate bug yet
<dysinger> okthx
<lifeless> jam: http://unicode.org/notes/tn5/#FCD may interest you
<lifeless> jam: http://osdir.com/ml/network.gnutella.limewire.core.devel/2003-01/msg00000.html claims that FCD is what OS X use, all claims of NFD aside
<jam> lifeless: thanks for the pointer, but I'm about 90% sure that Mac isn't FCD
<jam> Specifically, the FCD link claims that:
<jam> A-ring          (A)(ring)          NFC, FCD
<jam> u'\xb5' is valid NFC and FCD, but I'm sure it isn't valid on Mac
<foom> hfs+ hardcodes a table
<foom> see http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties
<dysinger> Is there a gitk or tig -like program for bzr to review in detail each commit with a diff window?
<jelmer> dysinger: bzr viz ?
<bialix> jam: help needed
<lifeless> hi bialix
<bialix> hi lifeless
<bialix> is it possible to cancel merge request in PQM queue?
<bialix> lifeless: ^
<bialix> too late. heh
<dysinger> looks like my question was discussed here http://www.nabble.com/Gitk-for-Bzr--td14855458.html
<dysinger> how would I grab bzr viz ?  home page ?
<dysinger> I can't see much from google or search on bazaar's home page
<bialix> dysinger: look for bzr-gtk
<dysinger> ah
<bialix> see http://bazaar-vcs.org/Plugins
<bialix> it's called bzrk
<dysinger> I know it's not important but I would like to see some sort of tig-like UI for the console.
<dysinger> I don't want to install GTK / bzr-gtk with mac ports - mac ports sucks.
<ubotu> New bug: #186829 in bzr-webserve "problem occurred in a Python script" [Undecided,New] https://launchpad.net/bugs/186829
<dysinger> TIG is a ncurses interface to GIT that simple and easy - let's you browse branches / history / diffs etc.
<dysinger> anyway
<dysinger> Plus then I would have to run X just to fire up bzr-gtk on mac too
<dysinger> I know you guys are on Ubuntu full time so my comments are not important.  :)
<dysinger> But having a ncurses UI is awesome IMO
<asabil> dysinger: yes it would be awesome, the issue is basically that ncurses is not that nice to program with
<dysinger> I live in the terminal
<asabil> dysinger: maybe you can try bzr-gtk in the mean time, or try qbzr
<asabil> or you can install loggerhead on one of your servers and use the webview
<dysinger> both of those have huge dependencies if you aren't already on linux
<asabil> dysinger: osx ?
<dysinger> y
<asabil> macports works for me
<dysinger> well half and half - I am on ubuntu on the other half
<bialix> what about Urwid framework for this stuff?
<asabil> dysinger: you can also try loggerhead
<dysinger> ok
<asabil> it is web based
<dysinger> urwid looks good
<dysinger> I wish I was a python guru - I'd try to whip something up
<dysinger> but - *cough* - ruby, jruby, java, etc has me busy already.
<bialix> I'm thinking about porting Urwid on Windows
<bialix> because ncurses is not working on Windows
<asabil> hmm urwid looks great
<bialix> we try to use it in our linux project
<igc> morning
<beuno> lifeless, ping
<beuno> well, anyone else who has a few minutes, I want to blog about how people should upgrade from knits > packs, to make it a bit more widespread and would like a review before I mis-inform planet ubuntu  :D   http://www.pastebin.ca/876675
<beuno> igc, maybe you'd like to take a crack at it?  :D
 * igc looks ...
<beuno> (blog post has links to stuff and all that, just not sure how to make drafts visible for others)
<Odd_Bloke> beuno: In (01), you effectively say 'while bzr devs know about packs'.  You probably want to add something to the effect of 'most normal users may not'.
<Odd_Bloke> Also, some people using bzr-svn may be using rich-root-pack or somesuch and not realise that they're already using packs.  You may want to change "(or anything different than format: pack-0.92)" to "(or anything without 'pack' in the name)".
<Odd_Bloke> Or just add a disclaimer somewhere about bzr-svn. :p
<igc> beuno: the first sentence needs to be clearer I think
<igc> I'm also not 100% sure about how to upgrade shared repos ...
<igc> I think you need to upgrade each branch using the repo, not just run upgrade on the repo
 * igc checks ...
<beuno> right, first phrase needs clearing, yes. On it!
<beuno> Odd_Bloke, yes, although I want to keep it as simple as possible, so I might have to add a warning for bzr-svn users
<beuno> might end up being too confusing
<lifeless> beuno: there is documentation about all this, in doc/developers/pack.txt or something like that
<beuno> igc, according to the doc, shared repos are updated that way: http://doc.bazaar-vcs.org/latest/developers/packrepo.html#upgrading-an-existing-branch-or-repository-to-knitpack-format
<igc> beuno: checking the doc, just upgrading the repo looks ok, at least if all branches are > 0.17
<beuno> lifeless, I'll take a look at it now
<beuno> does the text seem sane enough?   I'd also like to see if it can go on planet bzr and on planet debian  :D
<igc> beuno: to get your blog included on Planet Bazaar, email or ping poolie
<beuno> lifeless, seems that's where I got the information from already
<igc> beuno: by "go to the branches folder", I assume you mean "go to the branch's folder", i.e. the folder for the branch
<igc> otherwise sweet
<beuno> igc, that's right. Fixed too
<beuno> lifeless?  you're the pack-man :p
 * beuno also knows lifeless is on planet debian, which would have it posted on all 3 major planets
#bzr 2008-01-29
<jelmer> lifeless: hmm, it may be more useful to have that pqm than I thought after all
<jelmer> lifeless: I found myself looking for the revision to match a particular merge request, and now it looks like we have a test regression
<beuno> (btw, thanks igc and Odd_Bloke, :D)
<igc> np
<Odd_Bloke> beuno: :)
<lifeless> beuno: I'll have a read a little later
<lifeless> jelmer: kk
<beuno> lifeless, great, thanks!   I'll wait then, no real hurry.
<lifeless> beuno: perhaps mail me the link so I don't lose it ;)
<beuno> lifeless, on it's way
<poolie> hello lifeless, welcome back
<Aloha> i like the webpage. very clean & simple
<poolie> Aloha, which one?
<Aloha> the bazaar mainpage
<ubotu> New bug: #186876 in bzr-svn ""The file id FOO is not present in the tree" on svn-import" [Undecided,New] https://launchpad.net/bugs/186876
<jelmer> w00t, the python-subversion memory leak bug has finally been fixed in hardy
<spiv> jelmer: neat!
 * igc food
<ubotu> New bug: #186920 in bzr "bzr launchpad does not handle proxy when used for name resolution " [Undecided,New] https://launchpad.net/bugs/186920
<ubotu> New bug: #178772 in trac-bzr "Must use datetime for trac 0.11" [High,In progress] https://launchpad.net/bugs/178772
<igc> bbiab
<ubotu> New bug: #116659 in trac-bzr "Phantom changesets in timeline" [Medium,Triaged] https://launchpad.net/bugs/116659
<rcohen> is http://bazaar-vcs.org/KnitMerge an accurate depiction of the current merge algorithm used by bzr?
<poolie> rcohen, it's approximately correct for merge --knit
<poolie> it is not the default merge algorithm
<rcohen> ah, what's the default algorithm?
<rcohen> the knit algorithm looks very similar to the codeville merge algorithm
<poolie> a 3-way merge
<poolie> it is
<rcohen> which i have some experience with
<rcohen> is the 2-way diff done directly between the 2 sides, or is a match done against the knit/weave first and then lined up?
<poolie> i'd have to check the code
<poolie> but i believe it is done on the text first
<poolie> so it will be more forgiving of accidental convergence
<poolie> which aiui cdv is more paranoid about
<poolie> um
<poolie> it's been suggested that we should make this the default merge type
<rcohen> codeville does the former
<rcohen> (hi, i wrote most of codeville)
<rcohen> though i think the latter would have some advantages
<poolie> i wondered :)
<rcohen> i've become a big fan of convergence
<rcohen> as it has this nice side effect of cherry-picking just working, even if someone produces a diff and applies it to a different branch
<rcohen> the codeville algorithm has had some small tweaks, but it definitely supports accidental convergence
<rcohen> you'll have to tell me if this is accurate, but i believe the biggest difference between what cdv does and the knit merge is that cdv tracks spaces between lines instead of lines themselves
<rcohen> this was done to catch line removals without adds
<lifeless> rcohen: you may find --lca interesting
<rcohen> since you have a weave, i think you can actually make some improvements over what codeville is doing
<rcohen> not that the codeville merge is bad or anything :) been working very well in practice
<lifeless> back later
<rcohen> hmm, i guess you handle the deleted lines when you determine line ancestry on both sides, so that's kosher
<rcohen> my gut feeling is that you'd do better by matching the 2 sides against the weave instead of directly against each other
<rcohen> matching directly introduces a less precise resolution step which can cause some problems
<rcohen> these usually show up when files have their contents reordered or something does a cut-and-paste job and makes minor modifications
<rcohen> s/something/someone/
<rcohen> off the topic of merging, does bzr support '...' globbing (like in perforce) or something like it?
<rcohen> '...' is like '*' but recurses through subdirectories
<poolie> rcohen, merging is kind of swapped out for me
<poolie> yes, **
<rcohen> very nice
<rcohen> it's ok, i happen to have paged a bunch of it back in today
<rcohen> it was swapped out for quite a while there
<poolie> do you work at/on bittorrent too?
<rcohen> not anymore
<rcohen> i never contributed much in terms of code
<rcohen> still not sure how i feel about being management
<poolie> same here
<rcohen> i just wanted to poke my head in, looks like bzr is shaping up nicely
<poolie> yes
<rcohen> and i'm glad at least one other project cares about a sane UI :)
<poolie> performance seems to be pretty good now, and other things are coming along
<poolie> launchpad.net hosting is becoming quite popular, and its ui should keep improving too
<poolie> i guess you're in the us? we're having a developer conference in london in march, if you happen to be nearby
<rcohen> i'd love to visit london again, but sadly i doubt it'll happen
<rcohen> i'm in san francisco
<rcohen> you in lexington?
<poolie> no, i'm in Sydney
<rcohen> how does networking performance compare?
<poolie> better than hg and git over plain http, according to ian's measurements
<poolie> and fairly good for the smart server, though we still have more to do for avoiding round trips
<rcohen> the server also implements access controls?
<poolie> yes
<poolie> are you interested in getting involved? or in using bzr?
<rcohen> you don't use client-side SSL certificates or anything crazy like that, do you?
<rcohen> possibly
<poolie> no, normally people use ssh
<poolie> we use paramiko on windows so you don't need an external ssh client
<rcohen> i haven't had much spare time for quite a while, which is why codeville has been in bug fix mode for a long time
<igc> rcohen: see http://doc.bazaar-vcs.org/bzr.dev/developers/lca-merge.html (if you haven't already) for abentley's write-up on lca merge
<Aloha> how do you make files that are under version control not under version control anymore?
<Aloha> i know its not bzr rm. i learned that the hard way
<rcohen> i'll take a look at it, though i'm not a huge fan of 3-way merges because they end up not using a lot of good history information
<TFKyle> Aloha: bzr rm --keep?
<Aloha> TFKyle, thnx
<TFKyle> (oh, also bzr revert I think might do it they're newly added)
<Aloha> how do you guys handle debian directory of projects you're working on? do you include it or exclude it?
<mtaylor> Aloha: I include it and use bzr-builddeb
<TFKyle> for the one project I've debianized I include it
<Aloha> mtaylor, whats bzr-builddeb do?
<mtaylor> Aloha: bzr-builddeb will split it out for you so you can still have an "orig" tarball and a then your debian stuff
<mtaylor> Aloha: it's got a few different operational modes
<mtaylor> Aloha: but including the debian source in your source branch is definiltely something it handles easily
<Aloha> my program isn't really functional if it not a package because it looks in /usr/share/pixmaps for images
<Aloha> i do dh_install to move them there
<mtaylor> Aloha: yeah - I'd include the debian dir then
<Aloha> mtaylor, thnx
<mtaylor> Aloha: but I'd still look in to bzr builddeb ... it'll make things easier on it
<mtaylor> on you, rather :)
<Aloha> mtaylor, cool i'll research it
<mtaylor> Aloha: don't konw if you've played with it, but there's also a tool called debcommit which will let you make changelog entries and then use them as your commit message
<mtaylor> (somes in devscripts, I think)
<Aloha> mtaylor, i use dch for my changelog
<mtaylor> Aloha: yup
<mtaylor> Aloha: so once you do that, you just do a debcommit
<Aloha> mtaylor, cool thnx
<mtaylor> and it'll read the new changelog entires and do a bzr commit for you with the new changelog entires as the message
<mtaylor> so you don't have to do it twice
<TFKyle> wonder if it'd be reasonable to autogenerate a changelog from bzr history
<TFKyle> though that wouldn't handle distribution/etc.
<mtaylor> might be... MySQL does that from bk sources for its changelog
<mtaylor> I like the drive-the-bzr-history from the changelog approach though myself... but I'm a debian bigot, :)
<TFKyle> thing I dislike about that is you have to be on a debian system to make commits unless you do it manually
<mtaylor> yes
<mtaylor> that is true
<Aloha> why wouldn't you be on a debian system? ;)
<mtaylor> but then... I hate not being on a debian system
<mtaylor> :)
 * TFKyle doesn't use debian personally, except when he's making debian packages :D
 * mtaylor shudders
 * Aloha luvs debian
 * mtaylor has heard of such people
<Aloha> do you use gentoo?
<TFKyle> yep
<Aloha> freaking masochist
<mtaylor> that's what I'm saying
<mtaylor> but you know - whatever makes you happy!
 * TFKyle loves gentoo, except the politics of course
<mtaylor> well, I think the politics blow everywhere
<Aloha> amen
<TFKyle> though, I have to admit, it isn't quite as bad as the Canadian House Of Commons/Question Period :P
<Aloha> canada in general blows ;) j/k
<Debolaz> I used to use Gentoo, but eventually dropped it. I didn't like the idea of pushing out updates to the stable portage branch that bricked the system if you didn't answer correctly to questions in the upgrade phase, and gave no suggestion to what the "right" answer was except in some reply to a forum message hidden in the depths of oblivion.
<Odd_Bloke> Canada's not even a real country, right?
 * TFKyle has been using ~arch since forever personally
 * Odd_Bloke used Gentoo until he accidentally hosed his system, then used Ubuntu until he realised that Debian was both better _and_ newer. :p
 * TFKyle disagrees with that, but meh
<Debolaz> Gentoo seems to have looked at FreeBSD, and tried to replicate it for Linux but completely missed the big picture.
 * mtaylor recently tried to apt-get dist-upgrade from gutsy to lenny on one of his machines
<mtaylor> didn't really work out
<mtaylor> at all
<TFKyle> havn't really given debian/ubuntu that much testing though, dislike the idea of not having rolling updates
<mtaylor> system totally unusable
<Odd_Bloke> TFKyle: I use unstable, so I do get them.
<mtaylor> I wish ubuntu had an unstable
<mtaylor> or a rolling unstable
<Odd_Bloke> mtaylor: There's gutsy-proposed or somesuch, which may or may not do something along those lines.
<mtaylor> Odd_Bloke: yeah... not quite the same though
<mtaylor> Odd_Bloke: I miss the good-old days of apt-get upgrading every morning
<Debolaz> I keep trying Linux distributions, but I always end up coming back to FreeBSD.
<Odd_Bloke> Ubuntu's rolling unstable would have to be Debian unstable. :p
<mtaylor> Odd_Bloke: :)
<mtaylor> Debolaz: I hear that from people, and I've tried FreeBSD, but I don't like it for the same reason I don't like Gentoo...
<mtaylor> which is that I don't want to compile mozilla or openoffice or X
<mtaylor> ever
<Odd_Bloke> To be fair, Gentoo has binary packages to avoid painful compilations.
<mtaylor> that, and I'm used to linux, so many of the freebsd file locations seem weird to me
<mtaylor> Odd_Bloke: fair enough
 * TFKyle is compiling oo.o right now, just for the heat though :P
<mtaylor> Odd_Bloke: it did not back when I used it last
<Odd_Bloke> And the first two of those three I don't think I have installed on any of my Debian systems.
 * mtaylor has to have openoffice for work
<TFKyle> -48C with the windchill outside
<mtaylor> TFKyle: good god man.
<mtaylor> TFKyle: are you on the north pole?
<TFKyle> mtaylor: nope, Regina, Saskatchewan, pretty close to the US
<Odd_Bloke> http://chris-lamb.co.uk/2008/01/05/debian-packages-sorted-by-build-time-and-build-space/ shows how bad OO.o compilation is. :p
<Aloha> i'm in hawaii its like 70F heh
 * Odd_Bloke prefers Abiword.
<Debolaz> mtaylor: Well, there are elements which FreeBSD and Gentoo has in common that might be undesirable for many people. But what I want is a system with a consistent design that has every aspect of it well documented. I don't *want* to compile things from source, and I do think the ports and binary package system leaves a few things to be desired. But I feel the good outweighs the bad in the case of FreeBSD.
 * Aloha prefers gedit
<Debolaz> While Gentoo doesn't really have any adventage aside from a large collection in portage.
<Odd_Bloke> Well, that's a lie.  I prefer LaTeX, but for those times when people demand really ugly documents, I prefer Abiword.
 * mtaylor _prefers_ emacs
<Odd_Bloke> As for text editor, vim is clearly the best.
<Odd_Bloke> Crap, now we have to fight at dawn.
<mtaylor> damn
<mtaylor> I'm too tired for that
<mtaylor> can we just both agree that nano is annoying every time it starts?
<Aloha> Odd_Bloke, gvim ;)
<mtaylor> and that we both wish it wasn't the default editor alternative
<Debolaz> joe++ # Best damn editor ever. ;-)
<Odd_Bloke> mtaylor: Indeed.
<Debolaz> emacs # Nice OS, bad editor
<mtaylor> Debolaz: I totally agree about the consistent design part
<Odd_Bloke> joe/joe++ experience required.
<TFKyle> nano's a bit too suckish imo, it gets the job done in some cases but using it as your main text editor would suck
<mtaylor> Debolaz: which is the thing I like about debian, too, and one of the places where I think Debian and FreeBSD are similar
<Aloha> i got a bug i think
<TFKyle> its syntax highlighting isn't that great even when enabled imo
<mtaylor> Debolaz: I try to explain this to RH-using folks and they just don't seem to get it
<Aloha> when i do apt-get install bzr it installs 1.01~gutsy1
<mtaylor> TFKyle: nano has syntax highlighting?
<Aloha> but...
<mtaylor> Aloha: where are you installing from?
<TFKyle> mtaylor: newer versions do, though it's disabled by default unless you enable it in the config file iirc
<Aloha> mtaylor, where?
<Aloha> but apt-cache show bzr shows Version: 0.90-1
<Debolaz> I feel certain Linux distributions thinks it's perfectly ok to put things randomly in /opt, /var, /usr/local, etc etc, without any reasoning for what goes where except "it felt right at the time".
<mtaylor> Aloha: yeah. 1.01~gutsy1 is old
<mtaylor> Aloha: apt-cache show bzr will show you multiple versions
<mtaylor> Aloha: scroll back further
<mtaylor> you're seeing the one from gutsy itself at the bottom of the list
<mtaylor> Aloha: but you should add deb http://ppa.launchpad.net/bzr/ubuntu gutsy main to your sources
<Aloha> mtaylor, ok thnx
<Debolaz> mtaylor: Hehe, RH and SUSE are on my banlist for systems I admin.
<Aloha> Rh is ok. only because centos came out of it
<mtaylor> Debolaz: I wish I could say the same
<Odd_Bloke> RHEL is used by the CS department here, and it's pretty painful.
<mtaylor> Debolaz: but I'm a consultant for MySQL, so I have to touch whatever they're running
<Odd_Bloke> NFS and DNS randomly fail, and RH have been completely unhelpful as far as support goes.
<Aloha> my VPS runs centos
<mtaylor> if it _has_ to be redhat based, Centos isn't bad
<mtaylor> although I have to say RHEL5 took a major step forward by actually learning from Centos
<mtaylor> rather than just sticking with the RH status quo
<poolie> mtaylor, we're moving from putting those packages on bazaar-vcs.org to ppa
<mtaylor> poolie: good. so is bazaar-vcs going to point to the ppa now?
<poolie> i'll just change the web page now
<mtaylor> sweet
 * Debolaz should make an effort to learn bzr if he intends to keep hanging around in this channel. :-)
<Aloha> was bazaar created by canonical?
<poolie> i need to also work out how/whether to redirect the existing archive
<poolie> Aloha: and friends
<Aloha> poolie, everyone? ;)
<mtaylor> poolie: good luck with that! :)
<mtaylor> Debolaz: might not be a waste of your time :)
<Aloha> how do i get the key from bzr ppa?
<Debolaz> mtaylor: Hehe. I am in doubt if I'll be replacing git anytime soon, but learning is never a bad thing. Especially since everyone keeps saying how fantastic bzr has come lately. :)
<mtaylor> Debolaz: I think that if git is working fine for you, then great
<TFKyle> bzr's been fantastic for quite a while :P
<mtaylor> Debolaz: but I'm personally thrilled with bzr's ability to work with non-bzr systems too
<mtaylor> makes migrating or running heterogenous GREAT
<poolie> Aloha, there is no key for it at the moment, but it's meant to be coming soon
<poolie> like in the next launchpad release
<Aloha> poolie, ok cool
<Debolaz> My main complaint about git is the horribly weird frontend tools. Made it really difficult to understand the system at first.
 * TFKyle wonders when lp will allow people to kill packages from their ppa
<Debolaz> I'd be using mercurial if mercurial had been better with the thing you pointed out there, working wih non-mercurial systems.
<Debolaz> Git actually works well against subversion, which is an important feature for me.
<Aloha> bzr push seems kind of an aggressive adjective heh
<bob2> "bzr politely-request-you-take-these-updates"
<igc> night all
<lifeless> bzr take-it-rough
<mtaylor> bzr be-my-bitch
 * mtaylor wants to make a bzr-plugin that provides dirty aliases for all the builtins
<TFKyle> that shouldn't be too hard to do
<mtaylor> thinks it would take all of 20 minutes to write
<lifeless> mtaylor: https://launchpad.net/bzr-cheap-taiwanese"
<lifeless> ?
<mtaylor> mostly just from the time spent copying and pasting stuff
<lifeless> mtaylor: its python; do it on the gly
<lifeless> *fly*
<igc> no plugin required - just use aliases :-)
<mtaylor> lifeless: sure... but I have to actually type in the names of commands and the aliases for them
<TFKyle> hmm, monkeypatch stuff so the old commands don't work anymore :P
<bob2> not sure that would be coc-compliant!
<Odd_Bloke> TFKyle: As regards deleting PPA packages, I thought I saw something in the most recent LP release notes about now being able to do that.
<Odd_Bloke> I don't use PPAs myself, so I don't actually know that this is the case. :p
<TFKyle> I think they've added the capability to the backend, but nothing in the frontend, though i havn't looked for a few weeks
<poolie> thumper just posted an alias plugin, like in the shell
<TFKyle> s/frontend/ui/
<poolie> yes, it was just annouce
<TFKyle> ah, it is there, cool
 * thumper should email the patch to the list
<bronson> Can anyone point me to docs on how to maintain an integration branch in bzr?
<bronson> I have a few upstream svn branches that I'd like to occasionally import into different directories in my bzr tree.
<bronson> No need to keep full svn history in bzr; I just need to pull down the releases every month, mash them together, and build a single app out of them.
<bronson> Can bzr do this?
<Odd_Bloke> bronson: Do you need to keep the different upstream versions in your version control at all?
<bronson> Odd_Bloke: yes, because I need to be able to tweak them and bring my patches forward.
<bob2> that's what bzr-load-dirs was for
<bob2> I think bzr import does the same thing
<bronson> bob2: bzr svn-import?
<bronson> Doesn't that create an entire repository?
<bob2> no, "bzr import"
<bronson> bzr: ERROR: unknown command "import"
<bronson> Do I need 1.1?
<bronson> I'm on 1.0.
<bob2> hm, maybe
<bob2> it doesn't do what I thought it does, though, so never mind
<Odd_Bloke> 'bzr import' is part of bzrtools.
<bob2> ah, ok
<bob2> https://lists.ubuntu.com/archives/bazaar/2006q2/012039.html is how to do it
<bob2> shame no one has automated it yet
<Odd_Bloke> http://paste.pocoo.org/show/24401/ is the help for it.
<bronson> Ick, that's a lot of manual labor.
<bronson> Guess I'll have to keep using svn/piston.  :(
<bronson> How would I do this in bzr if svn wasn't a part of the picture?
<bronson> Let's say libst and libtu were maintained as bzr branches... I'd like to include them directly in my app.
<bronson> Is there an easy way to import upstream libst into a local/libst in my app's repo, then pull changes using regular bzr commands?
<bob2> config-manager
<bronson> Hm, interesting.
<bronson> I'll have to play with it.
<Odd_Bloke> bronson: You could have a bzr branch for your stuff, which contains other bzr branches.
<Odd_Bloke> But this wouldn't ensure that the revisions of the sub-branches would be the same everywhere.
<bronson> But reading the docs, config-manager has an icky, tla sort of feel to it...
<bronson> I could be wrong.
<bob2> haha
<bob2> it may perhaps date from that era
<Odd_Bloke> bronson: Posting to the list might help you out, as you'd be able to describe the scenario in more detail and more eyes will see it.
<bronson> True.  I was hoping this was an easy question.
<bronson> Guess not.  Oh well.
<bronson> I'll hit the list if I can't find easily another vcs that will do it.
<bronson> Thanks for your help.
<Odd_Bloke> bronson: No worries.
<poolie> bronson, this is handled by the subtree feature
<bronson> poolie: that sounds promising.
<poolie> please post to the list and someone can give you a pointer
<Aloha> how do you create release tarball with bzr?
<Kinnison> Aloha: bzr export foo-1.0.tar.bz2 /path/too/foobranch
<Kinnison> Aloha: is one option
<Kinnison> Aloha: personally I use autoconf and automake and do 'make dist' :-)
<Aloha> i don't have those though. my program is Ruby
<Kinnison> does ruby not have some kind of distribution maker?
<Aloha> Kinnison, maybe i'm not sure
<Kinnison> python has distutils
<Kinnison> perl has Makemaker
<Kinnison> I'm sure ruby must have something
<mtaylor> ruby has makemaker
<Aloha> i'm asking in #ruby-lang
<asabil> I think it is rake
<asabil> Aloha: ruby has rake iirc
<Debolaz> Makemaker is ugly. :(
<deepjoy> Hi I notice that the bazaar website is not updated very frequently. is there anywhere else that the current developments are captured?
<deepjoy> I'd like to volunteer time to help distribute this information if that would help?
<zurgutt> Hi folks, im new to bzr.  Im wondering if several branches can be created under one main working directory, each containing number of not overlapping subdirs?
<bob2> zurgutt: no (if I understand you correctly - several branches, not containign any files or dirs with the same name, checked out in the same directory)
<zurgutt> essentially groups of subdirs belong to separate projects and id like to be able to work with one group as unit, commit it etc
<Odd_Bloke> deepjoy: Most of the development work takes place on the mailing list, as well as in the bug and specification management parts of Launchpad.
<bob2> it'd be neat if someone was willing to do a weekly "bzr traffic" news thing
<zurgutt> one solution offered was to symlink those groups of dirs under separate workspace dirs elsewhere and there create branch for each.  Im just trying to make sure im not missing any simpler way of doing this, named branches or whatnot :)
<deepjoy> odd_bloke: cool I'll subscribe to the mailing list and try doing that for a few weeks
<deepjoy> I think a non-python/bzr intricacy level information is required for popular uptake
<Odd_Bloke> What sort of stuff would you expect to see in the news thing?
<bob2> new formats and their level of experimentalness, that changes at least once a week
<deepjoy> feature dissection from a layman's perspective. e,g, "bzr+http needs verb addition" translates to "bzr over http performance improvements"
<deepjoy> does that make sense?
<Odd_Bloke> How useful would that be on a week-by-week basis?  It seems more likely that something of this ilk when a new release happens might be more effective/useful...
<deepjoy> thats why I though the website was a better place to put such information
<Odd_Bloke> I dunno, I think it's too transient to go on the website.
<Odd_Bloke> Perhaps a blog post talking about a new version (i.e. paraphrasing the interesting parts of the NEWS file) might work.
<Aloha> how do you install branch into current directory without creatingnew directory?
<Aloha> how do you install branch into current directory without creating a new directory?
<Aloha> like if i wanted to do bzr branch http://bazaar.launchpad.net/~tjgillies/shakabuntu-surf/devel <current directory>
<bob2> "bzr co http://blah/ ." works, while branch does not
<bob2> so you could co, then "bzr reconfigure" it to a branch
<ubotu> New bug: #186975 in bzr "cannot rename files to names with slashes" [Undecided,New] https://launchpad.net/bugs/186975
<Aloha> i push a checkout back to devel or does it need to be a branch?
<Aloha> i'm trying to have an upstream working directory and a package working directory and i'm trying to sync their files
<Aloha> because i'm upstream and maintainer
<ubotu> New bug: #187008 in bzr-svn "bzr-svn try to use too long knit name incompatible with Windows filesystem" [Undecided,New] https://launchpad.net/bugs/187008
<gmb> Is it possible to specify a port when performing a bzr operation over sftp?
<dato> gmb: have you tried sftp://host.com:4444/path ?
<gmb> dato: I've tried it, but there is much sitting there and doing nothing going on :/
<lifeless> it should work
<gmb> Hmm.
<lifeless> tcpdump for the win
<gmb> Ah.
<gmb> No, wait, my balls up.
<gmb> It might be working now... the fact that my connection has slowed to a crawl suggests so...
<gmb> Thanks.
<lifeless> :)
<bialix> jelmer: hi
<jelmer> bialix: Hey
<bialix> I'm playing with bzr-svn and I'm stuck
<bialix> C:\work\Temp\scmrtos.repo>bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/trunk/
<bialix> bzr: ERROR: /trunk is not a valid Subversion branch path.
<bialix> See 'bzr help svn-branching-schemes' for details.
<jelmer> try removing subversion.conf and try again
<jelmer> appears to work fine here so far
<jelmer> subversion.conf in the bazaar config directory, not sure where that is on Windows, but I'm sure you do :-)
<bialix> it's strange because bzr branch svn+http://scmrtos.svn.sourceforge.net/svnroot/scmrtos/ works fine
<jelmer> that's because that's probably the first url you tried
<bialix> but it ends with branch containing trunk, branches, tags subdirs
<jelmer> bialix: if you remove subversion.conf, you should be able branch /trunk again
<bialix> also I have similar problems with trac-hacks.org svn repo
<jelmer> branching scrmtrtos trunk works fine here
<bialix> yeah, after deleting subversion.conf it does
<bialix> jelmer: overall it seems that bzr-svn standalone installer verison works fine
<jelmer> bialix: cool
<jelmer> bialix: does the test suite run ok?
<bialix> I just don't understand all limitations of svn support
<bialix> I don't run it
<bialix> yet
<jelmer> I would be interested in seeing the output when you get around to that :-)
<bialix> test suite output?
<jelmer> yeah
<jelmer> I suspect there will be at least some failures
<bialix_> jelmer: when I try to branch another branch from scmrtos svn repo I get the same error.
<bialix_> again delete subversion.conf?
<bialix_> something really weird going on here, IMO
<jelmer> bialix: what path are you trying to branch exactly?
<bialix_> um, wait
<bialix_> no, sorry, operator error
<bialix_> now it works fine
<bialix_> does bzr-svn allows to create new branches in svn repo?
<jelmer> yes, using the "svn-push" command
<bialix_> tags is used as branches or they mapped to bzr tags?
<jelmer> tags are used as branches for now
<bialix> jelmer: one more question please. do I need bzr-svn plugin installed all the time to work with branched svn trunk?
<jelmer> bialix: no, not at all
<jelmer> only when interacting with svn
<bialix> ah, ok, cool
<jelmer> (pulling/merging from svn or pushing to svn)
<bialix> indeed cool
<ubotu> New bug: #187037 in bzr-gtk "gpush fails with unsupported operand type(s) for /: 'float' and 'NoneType'" [Undecided,New] https://launchpad.net/bugs/187037
<vila> abentley: ping
<abentley> vila: pong
<bialix> vila: bonjour
<vila> I'm working on bug #123363 and TransformPreview always leaves garbage in /tmp
<ubotu> Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363
<vila> bialix: hi :)
<bialix> comme ca va?
<vila> the trick is that we can't call finalize() because no lock is held
<vila> bialix: bien, merci :)
<abentley> vila: I don't follow.
<vila> ok, TransformPreview.__init__ does limbodir = tempfile.mkdtemp(prefix='bzr-limbo-')
<vila> but never deletes it
<vila> note that *I* added prefix='bzr-limbo-' to ease tracking the leaks
<abentley> Why isn't there a lock on _tree?
<vila> you tell me :)
<vila> none of the tests in test_transform.py use locks
<vila> as I'm not familiar with the code I'm not sure TransformPreview.__init__ should take a read_lock on _tree
<abentley> I think it wouldn't hurt.
<abentley> vila: The tests don't use locks, but TreeTransform had always taken out locks for itself.
<abentley> I'd recommend taking out a read lock on _tree.  Does that suit you?
<vila> I'll give it a try but I came across the problem with no previous knowledge on TransformPreview, so I trust you :)
<vila> abentley: that worked
<abentley> Great.
<abentley> Sorry about leaving refuse behind :-)
<van_hack_> hi, can anyone help me move an existing bzr repo to a central server?  the docs assume I'm starting from cvs
<luks> van_hack_: bzr push?
<van_hack_> luks: does the remote branch already have to exist for that to work?
<luks> no
 * van_hack_ tries it
<van_hack_> luks: seems to be working, slowly. thx
<fjalar> hi all.. I set up a central repository (lock-step) but I am getting all sorts of permissions issues when 2 users try to commit or access files
<fjalar> it write the file with that user's name and their own group by default
<fjalar> and then the other user can't get to it.. is there a way to fix?
<schierbeck> fjalar: you're using sftp, right?
<fjalar> yes
<schierbeck> that's it
<schierbeck> it fucks things up
<schierbeck> try using bzr-ssh
<fjalar> ahhh
<fjalar> is it bzr checkout bzr-ssh://user@host:port/repos/...?
<radix> you can definitely use bzr reasonably with multiple users even if you use sftp. Make sure the shared repo and everything under it is g+rwXs
<radix> fjalar: bzr+ssh
<fjalar> ahh so kinda like svn+ssh for svn
<fjalar> ok
<radix> right.
<schierbeck> radix: i thought that didn't work with the sftp plugin?
<schierbeck> perhaps it's been resolved
<radix> schierbeck: it's not really a problem with the bzr sftp plugin.
<schierbeck> okay
<radix> it's just unix permission semantics.
<schierbeck> i'm off then :)
<radix> take it easy!
<ubotu> New bug: #163858 in bzr "bzr-svn cannot check out lintian repository" [Medium,Triaged] https://launchpad.net/bugs/163858
<fjalar> does bzr save strange unix permissions of the files being checked in.. themselves?
<fjalar> I noticed checking out a file just gave it 755 permissions
<jelmer> fjalar: bzr doesn't track file permissions
<jelmer> except for the executable bit
<fjalar> so there's no metadata telling it what permissions to use.. like tar uses?
<fjalar> hmm. maybe I'm better off with rsync, but I need the versioning control.. :-/
<jelmer> you may want to use metastore
<jelmer> which allows writing the metadata to a file
<fjalar> is that a bzr plugin?
<jelmer> no, it's a standalone app
<fjalar> oh I see :)
<jelmer> it should be trivial to write a plugin once bug 185772 is fixed
<ubotu> Launchpad bug 185772 in bzr "Ability to set two authors for a commit" [Wishlist,Triaged] https://launchpad.net/bugs/185772
<jelmer> uhm
<jelmer> I mean bug 186422
<ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged] https://launchpad.net/bugs/186422
<fjalar> where can I find metastore? google search is useless.
<jelmer> http://david.hardeman.nu/software.php
<fjalar> it looks like a git thing
<fjalar> ahh thanks
<jelmer> it's vcs-independent
<fjalar> cool! this looks perfect. Thanks!
<fjalar> ahh.. Joey Hess has worked on metastore. I know he's checked his $HOME into a concurrent versioning system before... :D
<fullermd> radix: No, it's a problem with sftp because the sftp server strips g+s, so new directories get made with the wrong perms.
<radix> oh. I guess that's openssh's sftp server's fault?
<fullermd> Yah.
<fullermd> (I dunno if it's just openssh, or all sftp servers, but...  does anybody use anything but openssh's?  ;)
<schierbeck> i knew i remembered correctly!
<schierbeck> boo-yaa!
<schierbeck> :)
<fullermd> Sadly, you're only allotted one correct remambrance a week...
<schierbeck> yup :(
<schierbeck> still, totally worth it
<vila> abentley: thanks for the quick notice (still laughing)
<abentley> hehe.
<CardinalFang> Hi all.  If you merge from a bundle and don't commit, and then add stuff, can you unmerge the merge cleanly and still keep your changes?  Perhaps "bzr diff > x; bzr revert; patch <x; patch -R bundle" ?  Is that the best way?
<abentley> CardinalFang: Is this actually a merge directive that contains a bundle?
<CardinalFang> Yes.
<abentley> Okay, so the merge directive lists the revision ids that were used.
<abentley> So you should be able to do bzr merge -r revision_id..base_revision_id
<abentley> But I'd make a copy and do it on that.
<CardinalFang> abentley, Won't that add a new changeset that is the reverse?  I thought that wouldn't expunge the difference.
<abentley> I don't know what you mean by "add a new changeset".  Bazaar doesn't have a concept of changesets.  This is just a cleaner way of changing the contents of your tree than using patch.
<CardinalFang> Sorry, s/changeset/revision/
<CardinalFang> Ah, "bzr revert --forget-merges"?
<ubotu> New bug: #187106 in bzr "bzr from standalone installer has poor performance on Vista" [Undecided,New] https://launchpad.net/bugs/187106
<rcohen> is there documentation on the knit file format?
<abentley> rcohen: There is a fair amount of documentation in http://bazaar-vcs.org/bzr/bzr.dev/bzrlib/knit.py but it isn't very polished.
<rcohen> maybe you could answer this without me digging
<abentley> Try me.
<rcohen> does the knit format allow regenerating a particular version without having to read from the beginning?
<abentley> Yes.
<rcohen> does it do this in a way similar to hgs revlogs?
<abentley> Knits store snapshots, and they have index files.  So you can read the snapshot, then apply a few patches.
<abentley> I don't know much about revlogs.
<rcohen> revlogs do basically that
<rcohen> and the knit is used to determine line ancestry?
<abentley> The knit stores an ancestry graph for its particular file.
<rcohen> and does the index tell you how many patches it takes to get from one snapshot to the next?
<rcohen> check that, you probably can get that from the ancestry graph
<LeoNerd> It's not patch based
<abentley> Technically, yes, but why would it matter?
<rcohen> you can optimize merge algorithms using that information
<abentley> LeoNerd: It doesn't use unified diffs, but it does have its own patch format.
<rcohen> sometimes it may require sacrificing some accuracy, but if you can start from a snapshot of a common ancestor it "shouldn't"
<rcohen> minus resolution errors
<abentley> rcohen: You're aware that we no longer use knits as our default format, right?
<rcohen> i saw something about that, but the knit weave is still there as an option
<rcohen> and sounded like at least some people think it should be the default
<abentley> I think you've got something confused.
<rcohen> very likely
<rcohen> :)
<abentley> "knit merge" is an algorithm that uses annotation information to perform a merge.
<rcohen> sorry, yes, i meant "knit merge", not weave
<rcohen> is the knit merge working on top of the current pack-like format?
<abentley> The pack formats don't include annotation information.  That makes the original knit merge too expensive to perform.
<rcohen> ah, what were the advantages to switching off of the knit format?
<abentley> Speed, speed, write-once operation, lockless operation.
<abentley> I've written a revised knit merge that determines whether lines are new based on sequence-matching the uncommon ancestors.
<abentley> Even that is pretty slow.
<rcohen> not surprising
<abentley> So I've written LCA merge.
<abentley> Which I think would be a good default.
<rcohen> it looked like it behaves like 3-way in many cases
<rcohen> which is fairly crude as far as history awareness goes
<rcohen> and can go horribly wrong if you don't choose your ancestor carefully
<abentley> LCA merge doesn't have "an ancestor".
<abentley> It uses all the LCAs.
<abentley> So it doesn't suffer the problems 3-way has with criss-cross.
<rcohen> that comes at the expense of not using any ancestors for the initial matchup between the 2 sides to be merged
<rcohen> which can introduce its own problems
<abentley> There's some truth to that, but I think it's a very practical approach.
<abentley> Knit merge doesn't use ancestry information for the initial matchup either.
<rcohen> i know, cdv merge doesn't either
<rcohen> it can cause problems :)
<rcohen> i honestly don't know what that will do in lca merge
<rcohen> would have to think about it
<rcohen> but i get nervous about weakening what 3-way merge does
<rcohen> also, 3-way and lca don't have the convergence property which i've become fond of
<rcohen> but to do that right you really need to be able to get at full history information quickly
<Skfarek> hi
<abentley> rcohen: In what sense is that weakening what 3-way does?
<rcohen> 3-way always sounds simple, but the devil is in the details
<rcohen> i believe you would normally match against the ancestor, not directly between the 2 sides
<rcohen> actually, i would have to defer to the monotone folks on that, because they have put a lot of energy into tightening up their implementation
<abentley> In 3-way, after you've matched against base, you typically match against the 2 sides, to avoid conflicts in the ABA case.
<rcohen> matching against base gives you some concept of line ancestry
<rcohen> only doing a direct match loses that information and can result in incorrect matches
<abentley> True, but matching against base can also cause incorrect matches.
<Skfarek> guys, how can i contact with anyone from summer of code/bazaar ?
<abentley> It's really six of one, half a dozen of the other.
<rcohen> yes, well, i never said 3-way was truly history aware
<rcohen> in general, i believe that matching against base will give better results
<rcohen> resolution errors are always possible (unless you hook into the editor, though i would dispute even that) the point is to minimize them
<abentley> Skfarek: I have no idea who's organizing that.
<jelmer> Skfarek: is the SoC already on for this year?
<abentley> Skfarek: you could just send a message to Martin Pool or the mailinglist.
<abentley> rcohen: Well, I see now what you meant, and I don't think it's a significant problem.
<abentley> Patience sequence matching does a great job of resolution.
<rcohen> i know, but cdv has been using that for a while and it still comes up
<mtaylor> if I do branch._get_base()
<mtaylor> that gives it to me in url form
<mtaylor> is there any decent/simple way to get it in filesystempath form
<mtaylor> (ConfigObj doesn't seem to like urls)
<abentley> mtaylor: We use URLs all over the place in our config files.
<Skfarek> jelmer: not yet
<mtaylor> abentley: yes... but do you use them to instantiate a ConfigObj?
<Skfarek> abentley: thx
<mtaylor> abentley: c=ConfigObj(os.path.join('file:///home/mtaylor/src/bzr-plugins/trunk/','.bzr-mysql','default.conf'))
<mtaylor> isn't so much happy
<abentley> mtaylor: No.  We retrieve the file, then instantiate ConfigObj with it.
<mtaylor> ah
<rcohen> i wonder if it's possible to generate a minimal knit on demand and cache it for merge purposes
<abentley> mtaylor: if you're using a Branch, you'd better be using transports to access its data.
<mtaylor> abentley: it actually should be WorkingTree rather than Branch, now that you mention it
<abentley> mtaylor: Does this plugin's configuration change according to the working tree?
<mtaylor> abentley: yes. or it could
<abentley> rcohen: Knit merge is a misnomer.  It just needs annotations, and we're planning to restore fast annotation support in a future pack format.
<rcohen> ah, excellent
<mtaylor> abentley: the one bit it a PluginBranchConfig class based on something similar from bzr-builddeb which allows you to put versioned config info into the branch itself, hopefully in a "safe" manner
<mtaylor> abentley: so that I can have a version of bzr-email that reads the commit-to address from the branch rather than from local config files
<abentley> rcohen: That said, I've found LCA merge gives better results than knit merge.
<abentley> I don't really get it, but I need to get some actual work done.
<rcohen> alright, thanks for indulging me
<abentley> rcohen: BTW, you asked about documenttion of knits.  But if it was knit merge you were after, there's a description here: http://bazaar-vcs.org/KnitMerge
<rcohen> already saw the knit merge description
<rcohen> i'm actually in favor of full weaves (or equivalent full history information) not just file annotations, but don't let me drag you back into a discussion if you have work to do
<awmcclain> Is branching significantly faster over the smart server than http or ssh?
<dato> awmcclain: over bzr+ssh you're already using the smart server (not over sftp://, though)
<awmcclain> Okee doke. In a workflow where there's a monolithic mainline, do people usually keep an updated local clone of the mainline and then make branches from that?
<awmcclain> I'm just curious because our repository (~150 MB, ~460 revs) takes > 3 minutes to download and I'm trying to sell bzr to my team.
<luks> awmcclain: yes, branching from a local mirror of the mainline is probably the most common approach
<luks> you usually use a shared repository, so you store/download those 150MB only once for all branches
<awmcclain> Right. If you branch from the local mirror, you have to make sure the mirror is at tip, right?
<fullermd> Well, not _necessarily_.
<awmcclain> So workflow for making a new feature would be update local mirror -> branch local mirror
<luks> you don't really have to
<awmcclain> Or does it get handled automatically?
<luks> but it's nicer to work against the current mainline
<awmcclain> Oh, right, you could branch on your old version, but then you'd have more possible merges
<abentley> rcohen: For merging purposes, full weaves are great.  But we couldn't get decent performance out of them, and there were also safety concerns because the weave is constantly being rewritten.
<luks> some people prefer to use checkouts for the mainline
<awmcclain> luks: Sounds like svn to me... how are "checkouts" different than "branches"?
<luks> they are "bound" to a remote branch
<luks> and it the checkout is out of date, it will complain when you try to commit to it
<luks> so you know that you have to update
<luks> s/and it/and if/
<awmcclain> luks: So you "checkout" a local working copy from a remote server?
<luks> more or less
<awmcclain> But then you lose the benefit of having a local feature branch, right?
<luks> no
<abentley> rcohen: I did come up with an append-only format that represented weaves: http://www.aaronbentley.com/weavediff
 * awmcclain scratches his head
<Odd_Bloke> awmcclain: A local branch created using 'bzr branch' will work fine, so don't worry too much about the alternatives. :)
<awmcclain> Maybe it's better if I describe what I'm looking for... I want each developer to be able to make local branches very quickly (w/o having to wait 3 minutes for the repo to dl)
<luks> awmcclain: you get that with almost every possible configuration
<fullermd> awmcclain: I work that way.  I have a local checkout of the trunk, that I work directly in for trivial stuff.  And I branch off it for larger stuff, which I then merge in/commit.
<luks> the only exception would be "lightweight checkout", but you don't have to worry about that
<Odd_Bloke> awmcclain: Do the developers have commit access to the primary branch?
<awmcclain> Odd_Bloke: Yes.
<awmcclain> But I must have set it up incorrectly, because *each* local new branch I make takes forever.
<awmcclain> fullermd: That makes sense.
<Odd_Bloke> awmcclain: You're, presumably, not using a shared repository.
<awmcclain> I guess not. ;)
<Odd_Bloke> "bzr init-repo foo && cd foo && bzr branch http://mainline/trunk" should do the trick.
<awmcclain> And that's on the mainline server.
<awmcclain> I'm assuming.
<Odd_Bloke> Nope, that's locally.
<awmcclain> Ah.
<awmcclain> So how does the local repository keep up-to-date?
<Odd_Bloke> bzr will find the repository at foo whenever you create a new branch, and use it instead of creating a standalone repo.
<Odd_Bloke> awmcclain: bzr pull
<Odd_Bloke> In foo/trunk
<awmcclain> Ok. Perfect. So workflow would be (for, say, working on a new feature), bzr pull, then bzr branch foo-feature
<awmcclain> Then you'd merge into your local repo
<awmcclain> and push the changes to mainline?
<Odd_Bloke> awmcclain: Starting in 'foo', 'cd trunk; bzr pull; cd ..; bzr branch feature-branch' would give you a shiny new up-to-date feature branch.
<Odd_Bloke> awmcclain: Precisely.
<Odd_Bloke> To clarify, your local 'trunk' branch.
<Odd_Bloke> A repository, in bzr terms, is just a place where revisions are kept.
<awmcclain> Ah, sorry. Still wrapping my head around non-svn terms.
<Odd_Bloke> :)
<fullermd> Or you could use a checkout, and update/commit instead of pull/push'ing the mainline changes.
<fullermd> It's something of a wash, but I find the enforced lockstepping on trunk to be an advantage.
<awmcclain> I'll take a look at that on the site.
<Odd_Bloke> awmcclain: Another thing to note is that, when merging back to trunk, it makes sense to update trunk and then merge trunk into the feature branch, do any conflict resolution there (rather than in trunk) and then merge the ready-resolved feature branch into trunk.
 * snod feels dizzy because he can't follow :)
<awmcclain> And bzr+ssh is the preferred method of pushing/pulling (updating/committing) from local trunk branch to mainline, right? I've found that serving the mainline using bzr:// gives me no status when doing branch on my local machine
<awmcclain> Odd_Bloke: Right. That way you're not screwing around with trunk... all your merging happens in your feature-branch.
<fullermd> I usually just merge into trunk.  If it ends up getting a lot of conflicts, I can always 'revert' it and go off to do it in the branch.
<Odd_Bloke> awmcclain: I don't have any experience with bzr:// so I'm not really the best person to help you out there.
<Odd_Bloke> bzr+ssh:// will certainly do fine, assuming everyone has an SSH account.
 * Odd_Bloke is about to disappear for a server reboot.
<Odd_Bloke> BBIAB
<awmcclain> Thank you all for your help!
<sistpoty> Hi, I just tried to commit a single file back to LP using "bzr ci style.css", which however seemed to hang forever... known bug? (1.0-1)
<james_w> hi sistpoty.
<sistpoty> hi james_w
<beuno> sistpoty, you still need to specify a message in your editor
<james_w> I haven't heard of that. Are you using a checkout/bound branch?
<beuno> does "bzr ci -m'Message' file.css" hang too?
<sistpoty> beuno: no, the editor didn't even spawn... I also tried -v, but it didn't give any output :(
<yacc> Me wonders if it's possible to specify commits with bzr interactivly like with darcs => commiting only part of the file change at once?
<sistpoty> james_w: checkout, I can look at the exact command I used ;)
<james_w> sistpoty: see if there is anything interesting at the end of ~/.bzr.log when it is hanging.
<sistpoty> bzr co bzr+ssh://sistpoty@bazaar.launchpad.net/~revu-hackers/revu/trunk <-
<james_w> yacc: no, but you can do something similar with the shelf plugin from bzrtools.
<yacc> james_w: ?
<sistpoty> james_w: wow, this is huge (with -v)... there is at least one traceback in there
<james_w> sorry all, I've got to run.
<james_w> hopefully someone else can help the two of you.
<sistpoty> http://pastebin.ubuntu.com/3983/
<james_w> If not please post to the list, or hang around for an hour or three.
<yacc> sistpoty: start by pasting it into rafb.net/paste
<sistpoty> (there's much more in there...)
<james_w> sistpoty: you don't have something silly set in $EDITOR or $BZR_EDITOR do you?
<beuno> sistpoty, I've tried it here ant ir works fine either way
<beuno> sistpoty, does "bzr ci -m'Message' file.css" hang too?
<sistpoty> james_w: $EDITOR is vim
<sistpoty> beuno: let me check
<james_w> sistpoty: not too silly then.
<james_w> bye all.
<sistpoty> beuno: oh, false alarm... it does continue after some time... now I've got an editor
 * beuno waves at james_w 
<sistpoty> cya james_w
<beuno> sistpoty, great then  :D
<sistpoty> heh :)
<beuno> sistpoty, I would recommend bumping up to 1.1 if you can
<Odd_Bloke> yacc: 'bzr (shelf|shelve|unshelve)' from bzrtools let's you temporarily remove hunks from your working tree, that might work for you.
<beuno> less chance of hitting a bug  ;)
<sistpoty> beuno: once it's in hardy, sure :)
<sistpoty> hehe
<sistpoty> thanks for your help!
<beuno> sistpoty, it is: https://edge.launchpad.net/~bzr/+archive
<beuno> and you're welcome
<yacc> Odd_Bloke: Well, I can live as is, I just wonder how well bzr handles merging compared to darcs or git?
<bialix> evening
<bialix> I'd like to talk about lazy_import
<beuno> evening bialix
<bialix> evening beuno
<bialix> I want to use modulefinder.py to obtain dependencies graph for bzr plugins, but I'm stuck with our lazy_import hack
 * bialix wonder who is the author of standard python library's modulefinder.py
<bialix> jelmer, are you here?
<jelmer> bialix, hi
<bialix> evening jelmer, I have selftest svn results
<bialix> Ran 722 tests in 1764.281s
<bialix> FAILED (failures=11, errors=63, known_failure_count=3)
<bialix> 1 test skipped
<bialix> I'll send the test.log
<jelmer> bialix: thanks, that'd be useful
<bialix> many tests are reported about 'Permission denied: unable to remove testing dir xxx'. Looks like someone don't bother to close files in testing dir
<jelmer> yeah, we're probably not closing the repository
<bialix> it's annoying to see this junk, but nothing realy bad here
<bialix> sent
<jelmer> thanks
<jelmer> some of the other errors appear to be related to the executable bit and symlinks
<bialix> executable bit is preserved inside inventory on win32, but disconnected from real fs
<bialix> symlinks... I have win32symlinks plugin installed. what special support of symlinks bzr-svn needed?
<jelmer> bialix: it doesn't need any special support
<jelmer> it does some tests importing/pushing symlinks in svn
<bialix> ups, sorry. I was thought that I have it installed, but in fact no. I repeat the test with this plugin
<jelmer> thanks
<jelmer> is there some other way I should be accessing the execable bit?
<jelmer> WorkingTree.is_executable() seems to rely on self._inventory
<jelmer> how do you change the executable bit on Windows?
<bialix> I do this in x-bit plugin
<bialix> I change executable bit directly in inventory
<bialix> http://codebrowse.launchpad.net/~bialix/bzr-x-bit/trunk/annotate/bialix%40ukr.net-20070328093543-blbtmf3k7jp6bmsd?file_id=__init__.py-20060516204016-5be79f11e31f2cb7
<jelmer> ahh
<bialix> inv_entry.executable
<jelmer> I'll provide a custom implementation of _is_executable_from_path_and_stat_from_basis
<durruti> Hi folks, bzr newbie question for you: is it possible to create a branch from a remote, commit some revisions locally, and not propagate those back to the parent branch?
<bialix> yes
<Odd_Bloke> durruti: Yes. :)
<durruti> Cool
<durruti> right now I use SVK for this, but push and pull are broken
<durruti> I have to manually use âsvk smergeâ and specify the base revision
<durruti> such a pain, I want to try bzr in the hopes the âbzr pushâ will be all thatâs needed
<bialix> you need to push back to svn server?
<durruti> yep
<bialix> then you need bzr-svn plugin in addition to vanilla bzr
<durruti> Actually I would rather switch the remote server to bzr, but yeah Iâll take it one step at a time
<durruti> looking at the docs, I see there are two ways to accomplish keeping changes to one branch: ârebasingâ and âbzr pushâ (with a prior âbzr mergeâ)
<ubotu> New bug: #187162 in bzr "bzr diff -r submit: on subversion branch fails" [Undecided,New] https://launchpad.net/bugs/187162
<durruti> is that right?
 * bialix don't quite understand question
<jelmer> bialix: I think I've fixed the executable bit
<jelmer> bialix: Can you check?
<bialix> maybe tomorrow
<bialix> I'm going to bed
<jelmer> ok
<jelmer> g'night
<bialix> jelmer: with win32symlinks plugin the results is: FAILED (failures=14, errors=60, known_failure_count=3)
<bialix> I'll send you the log tomorrow. g'night
<durruti> bialix: OK, imagine the following: A live website on a remote server. The website is a versioned in bzr. I wish to code features locally and offline, but I need to change config.php for my specific local server. I donât want those changes to ever make it back to the remote server
<durruti> dâoh... gânight then :D
<jelmer> bialix: at least 20 more tests should be fixed by the commit I just did
<bialix> nice
<dlee> [3
<dlee> oops
<ubotu> New bug: #187169 in bzr "Partial commit with mv and rm under it will royally hork up" [Undecided,New] https://launchpad.net/bugs/187169
<CardinalFang> "hork" is a fun word, you hosers.
<fullermd> It's descriptive   :P
<poolie> good morning
 * fullermd waves at poolie.
<Verterok> hi poolie
<beuno> hey poolie, thanks for solving the planet thingie  :D
<poolie> it's ok now?
<poolie> that's good
<lifeless> silly link outages
<poolie> me too
<poolie> also, i put hardy on my x61s and its network support seems a bit flakey
<fullermd> Well, I broke dirstate, so my day's complete   :)
<poolie> yeah thanks for that
<poolie> fullermd, feel free to triage them when filing bugs
<poolie> and thanks for the repro script
<fullermd> It was looking at me funny.  I had to put it back in its place.
<igc> morning
<fullermd> I think it's actually 2 bugs; one the commit, and the other the [abc] ordering that messed up stat.
<fullermd> But I couldn't easily separate them, so...
<fullermd> Fixing the commit one will probably mask the stat one, so it may be best to work bottom-up in fixing   :|
 * fullermd should add a note along those lines while he's thinking of it.
<fullermd> Huh.  'reconfigure' doesn't have a mode to turn a branch standalone <-> repo?
<fullermd> I thought I remembered that being added...
<fullermd> I guess the mind is the first thing to...  to...  the first...  I forget.
<Peng> It was mentioned/suggested on the list recently.
<CardinalFang> Should it be legal to have a push location on a remote host (via bzr+ssh) be a symlink to a valid location?
<CardinalFang> ^location^directory
<CardinalFang> Er, Should it be legal to have a push location on a remote host (via bzr+ssh) be a symlink to a valid directory?
<CardinalFang> I'm trying to decide if this is a bug.
#bzr 2008-01-30
<lifeless> poolie: landline is diverted, ping me I ring you
<chiefinnovator> hi all, how can I find out what revision a file was added?
<lifeless> bzr log file
<chiefinnovator> bzr: ERROR: Path does not have any revision history: PyRSS2Gen.py
<chiefinnovator> maybe it was never added?
<bob2> bzr log --line filename | awk '{print $1}' | sed -e s/://
<chiefinnovator> If I put a new file in the directory and do a commit, does it get added automatically?
<lifeless> chiefinnovator: no
<lifeless> chiefinnovator: you need to run bzr add
<chiefinnovator> ohh
<lifeless> chiefinnovator: you can use --strict on commit to have bzr error if you have un-added files
<bob2> perhaps we could have some sort of regexp that designates a "source" file
<bob2> and automatically add them
<lifeless> bob2: hi tom, I see you've changed your nick
<bob2> chiefinnovator: or add "[ALIASES]\ncommit = commit --strict" to ~/.bazaar/bazaar.conf
<chiefinnovator> thanks
<lifeless> bob2: we don't need an explicit include regexp because we have an explicit exclude one
<mtaylor>   File "/usr/lib/python2.5/site-packages/bzrlib/graph.py", line 48, in <module>
<mtaylor>     class DictParentsProvider(object):
<mtaylor>   File "/usr/lib/python2.5/site-packages/bzrlib/graph.py", line 56, in DictParentsProvider
<mtaylor>     @symbol_versioning.deprecated_method(symbol_versioning.one_one)
<mtaylor> AttributeError: 'module' object has no attribute 'one_one'
<mtaylor> hm
<mtaylor> that's no fun
<mtaylor> nm... I think I know what the problem is... maybe...
<lifeless> mtaylor: interesting
<mtaylor> lifeless: so, I got that from having a running bundlebuggy and then upgrading bazaar out from underneath it
<Solarion> what is "rich-root" format?
<fullermd> It emails your credit card number to your sysadmin.
<bob2> it stores information about the branch root (.)
<bob2> in practice, "it's the branch format you need to use bzr-svn"
<ubotu> New bug: #187207 in bzr "commit reports error when a file has been moved and then removed in the same revision" [Undecided,New] https://launchpad.net/bugs/187207
<Solarion> bob2: danke
<bob2> (or rich-root-pack)
<lifeless> always go for rich-root-pack over rich-root
<bob2> both seem a lot slower for pulling from a pack repository than regular pack
<Solarion> how does one select rich-root-pack over rich-root?
<lifeless> yup
<lifeless> different code path
<bob2> like orders of magnitude
<lifeless> bob2: thanks :)
<bob2> Solarion: --rich-root vs --rich-root-pack to bzr init-repo/upgrade
<bob2> hah
<lifeless> Solarion: but only use --rich-rooot if you are using bzr-svn
<lifeless> bob2: I worked quite hard to make packs fast :)
<Solarion> lifeless: I am indirectly
<Solarion> this is a branch of my working branch
<bob2> lifeless: yeah, I've noticed :) is rich-root-pack going to be able to inherit much of that work?
<fullermd> Actually, I imagine it does, if it's pulling rrp->rrp.  It's p->rrp that doesn't get the benefit.
<bob2> hm
<fullermd> (that's just a guess, of course)
<jelmer> --rich-root-pack should be as fast as --pack-0.92 I think
<jelmer> it only uses a slightly different serializer
<mwh> jelmer: so loggerhead actually already supports file path/revision number based urls
<jelmer> mwh: oh ok
<jelmer> mwh: what url format should I use?
<mwh> there is no way to know this without reading the source though
<mwh> jelmer: i can't remember :/
<mwh> i think you just put the revno where the revid would be
<mwh> and append the path
<bob2> pulling bzr.dev into a rich-root-pack repo is about 50% slower than into a pack one, and throws a missing revision error
<mwh> so it's like http://loggerheadroot/annotate/$revno/file/path
<jelmer> bob2: Right, I mean from rich-root-pack to rich-root-pack
<bob2> jelmer: ah
<jelmer> bob2: Anything that converts between formats is probably going to be slower (because you need to deserialize and reserialize)
<bob2> ah - pack to rich-root is like 50x slower
<fullermd> pack->knit (which r-r is) is probably real slow, since is has to generate the annotations...
<bob2> ahhh
<jearl> So what's the point of rich-root and rich-root-pack?
<lifeless> bob2: don't pull bzr.dev into rich-roots yet anyhow, see the bug on lp about inventory sha corruption
<bob2> ah
<bob2> is it possible to get bzr log to show diffs?
<bob2> or did I imagine that
<skwashd> hi all
<skwashd> any idea why ubuntu is shipping an uninstallable version bzr-svn in gutsy?
<mtaylor> skwashd: why is it uninstallable?
<skwashd> cos it depends on 0.91 yet the version of bzr in gutsy is 1.0.1
<mtaylor> I think that's the version of bzr from bazaar-vcs.org
<skwashd> \bzr-svn: Depends: bzr (< 0.91~) but 1.0-1~gutsy1 is to be installed
<mtaylor> gutsy doesn't have 1.0 to the best of my knowledge
<bob2> it's in gutsy-backports
<mtaylor> did you add the bazaar-vcs.org apt sources to your sources.list?
<mtaylor> ah
<bob2> but an updated bzr-svn is not
<mtaylor> well then.
 * mtaylor recommends the bzr ppa ... but that's not really the question here, so he'll shut up now :)
<skwashd> mtaylor: ok i will try that
<bob2> skwashd: if you can live with older bzr, sudo aptitude install bzr=0.91, or what mtaylor said
<mtaylor> which will give you bzr 1.1.0
<pooliex61> mtaylor, you're the second person to mention this
<pooliex61> could you file a bug on launchpad please?
<beuno> quick question. What is used to output messages with line breaks in bzr?  been pokng around but I can't find any examples
<skwashd> great now i have bzr 1.1 installed
<skwashd> next issue :)
<skwashd> i have 2 svn repos ... i want to be able to merge from one to the other ... can bzr handle that?
<abentley> bob2: you imagined it, but feel free to make your dreams reality.  The API for diffing is pretty straightforward.
<bob2> hehe
<igc> bbiab
<abentley> fullermd: that's a planned feature, but not here yet.
<bob2> abentley: hm, do you think it'd be more reasonable to show diffs for each (nested) revision, or just leaves?
<lifeless> bob2: I proposed log -vv to do this on the list a week or two ago
<abentley> bob2: I use log-format=short, because I don't want to know about nested versions.
<lifeless> bob2: patches for the win
<bob2> ah
<bob2> lifeless: hah, missed that, but that's the command I was trying
<lifeless> log -v -> status
<lifeless> log -vv -> diffs
<lifeless> as abentley says, get it working :)
<abentley> So I don't know what someone using log-format=long would want.
<fullermd> If bob2 touches the code, that means he gets all wishlists for the output forever, right?   ;)
<lifeless> for long, I would like to see the diff against each left hand parent
<bob2> fullermd: the bikeshed will remain unpainted
<lifeless> hmm
<lifeless> or
<lifeless> possibly better
<abentley> Either that, or that shade of puke green that Tom's so fond of.
<lifeless> the diff against the next output revisions
<lifeless> abentley: zouch
<bob2> haha
<lifeless> abentley: you should be careful now; as an employee of The Evil Corporation(TM) you are now ripe for abuse and slander
<bob2> (I was looking for the diff that showed why bzrlib.fetch.Fetcher was removed and broke the fetch command)
<abentley> lifeless: oh fun.
<lifeless> bob2: actually for diffs its easy: do the same diff that log -v does status off
<lifeless> s/off/of/
<lifeless> bob2: that way, we can just change both at the same time if so desired
<abentley> lifeless: +1
<abentley> oh, btw: did BB send you an error message for your bb:discuss-please ?
<lifeless> yes
<abentley> Sorry about that.  But I'm glad the error reporting's working.
<lifeless> oh I was expecting something of the sort :)
<bob2> heh, perhaps it is time to remove legacy_lf
<bob2> lifeless: I can't quite figure out what you mean by "do the same diff thsat log -v does status off"
<fullermd> Do the diff relative to the revision that it does the stat relative to for the filenames affected.
<bob2> right
<bob2> hm
<abentley> Oh good grief!  I didn't even know we *had* a "get_deltas_for_revisions" method.
<lifeless> abentley: didn't you add that ?
<lifeless> abentley: btw, thats the sort of method I expect repo's to specialise :)
<poolie> lifeless, i'm off the phone etc, but i guess you'regone
<poolie> or anyhow you should go, soon
<lifeless> heh
<lifeless> you had a phone day huh?
<poolie> yeah
<poolie> one more mail, then it's either you or the bike :)
<lifeless> on your bike
<lifeless> lets talk tomorrow avo
<lifeless> 3ish
<poolie> fine with me
 * lifeless is about to wow
<poolie> enjoy
<ubotu> New bug: #187267 in bzr "UnicodeDecodeError with non-ASCII character in filename" [Undecided,New] https://launchpad.net/bugs/187267
<vila> jelmer: ping, got a workaround for the infamous '_' used for gettext in bzr-gtk clashing with bzr selftest
<jelmer> vila: ah, nice
<jelmer> vila: any chance you can send an email to the bzr-gtk list?
<vila> jelmer: :) That's the bit I was searching, my last patch to bzr-gtk is so old I can't remember the workflow :)
<vila> jelmer: is there a bug on lp or that ?
<vila> s/or/for/
<jelmer> I'm not sure
<jelmer> it's a bit quiet in bzr-gtk land at the moment
<vila> jelmer: Ok, I'll  file one then
<ubotu> New bug: #187280 in bzr "Running 'bzr -log -r branch:../other_branch' raises ReadOnlyError" [Undecided,New] https://launchpad.net/bugs/187280
<Toksyuryel> bzr rocks ^_^
 * Toksyuryel just wanted to say that
<vila> Toksyuryel: thanks :)
<ubotu> New bug: #187283 in bzr-gtk "bzr selftest bizarre errors related to '_''s gettext" [Undecided,New] https://launchpad.net/bugs/187283
<jelmer> vila: are you going to post the workaround too ? :-)
<vila> jelmer: sure :) Finishing the mail, I needed the bug number before hand :)
<vila> jelmer: sent
<jelmer> thanks :-)
<muffinresearch> The bazaar site has a list of projects that use bazaar http://bazaar-vcs.org/WhoUsesBzr. Is this up to date and does anyone have any other good examples of  large projects/companies using bazaar?
<quik__> hey folks
<quik__> the bzr mac port seems to always be broken
<quik__> is there anything that I should know?
<Peng> Well, the developers are all goths from Mars.
 * Peng gets booed off the stage.
<beuno> Peng, hehehe, it's early/late in the morning/evening for jokes that complex  :p
<quik__> I reckon they might be. firstly they have a special deb-source for ubuntu. then the ports never work
<quik__> ubuntu universe, like the rest of the world uses.. is WAY out of date
<beuno> ubotu, last time I heard they had make a dmg for OSX for 1.1 that seemed to work fine. Where are you downloading from?
<beuno> argh
<beuno> s/ubotu/quik__
<brink_> _quik:  I just installed 1.1 on OS X.   You have to have xcode installed.   Otherwise some of the dependencies crash and burn.
<quik__> I just installed leopard and xcode 3.0 on this laptop yesterday
<brink_> Not trusting xcode 3.0, I did 2.5.
<snod> did youz try macports?
<quik__> it installed a few weeks ago on two other machines that are on the same..
<quik__> yes, always macports
<brink_> Me too.
<snod> okay, because that worked for me, though I'll have to stick with tiger and Xcode 2.5
<brink_> You should also uninstalled and clean the dependencies.  I did  that after it failed.
<brink_> Then it worked.
<brink_> Too bad xcode isn't available via macports.
<quik__> I think apple think that macports is a bastard child that dirty developers use
<quik__> I can't understand that its not built into the os or even installed with xcode
<Mythos> Hi!
<Mythos> I would like to ask something about the smart server!
<Mythos> I have set up a smart server through inetd with --directory=/home/lala/bzr-repo which is my repository
<Mythos> So bzr branch bzr://host/branch1, where branch1 a branch in my repo, works ok.
<Mythos> But trying to push changes through bzr push bzr+ssh://login@host/branch1 throws the following error
<Mythos> bzr: ERROR: Parent directory of bzr+ssh://login@host/branch1 does not exist
<Mythos> And I can push only if I give the full path, like:
<Mythos> bzr push bzr+ssh://login@host/home/lala/bzr-repo/branch1
<Mythos> Why I can't just bzr push bzr+ssh://login@host/branch1?
<snod> my guess, because your logging in via ssh you don't use the smartserver from inetd
<Mythos> Probably you are right, because I also can't branch with  bzr branch bzr+ssh://login@host/branch1
<Peng> Yes.
<Mythos> bzr: ERROR: Not a branch: "bzr+ssh://papadako@groogle.csd.uoc.gr/branch1
<Peng> bzr+ssh sshes in and runs "bzr server".
<Peng> And its paths are relative to the root of the server.
<Mythos> Ok. So I can't do anything about it, right?
<Mythos> Relative paths are smaller than full paths.
<snod> perhaps a chrooted ssh enviroment could work
<Peng> Well, not easily, anyway.
<Peng> What he said, or maybe the contrib/bzr_access script, or some sort of ssh configuration.
<Mythos> Ok. Thank you!
<Peng> Well, if you have root access, you can put your repos in /srv/bzr or something.
<Mythos> Yep, this could also work
<Mythos> One more question..
<Mythos> Related to the webserve.
<Mythos> Last change for each branch, shows 38 years....
<Mythos> See http://groogle.csd.uoc.gr/bzr/
<Mythos> Like it does not read info from the branch.
<vila> 38 years ago is 1970, i.e Unix epoch or (time == 0), I'll check file last modification time and time itself on the server...
<Mythos> Time on the server is fine
<Mythos> Wed Jan 30 17:20:15 EET 2008
<Mythos> http://groogle.csd.uoc.gr/bzr/groogle-2007 for example shows correct info
<Mythos> It is the main page showing 38 years.
<Mythos> Also I hit a bug in http://groogle.csd.uoc.gr/bzr/terrier-devel
<Mythos> <type 'exceptions.IndexError'>: list index out of range       args = ('list index out of range',)       message = 'list index out of range'  0
<Mythos> in templater.py
<muffinresearch> The bzr vs hg page on the wiki mentions bazaar having integration with bugzilla out of the box. Can any one point me in the direction of documentation on this feature?
<abentley> muffinresearch: bzr help bugs
<muffinresearch> Excellent thanks for that
<ubotu> New bug: #187330 in bzr "Commit failed with attribute error" [Undecided,New] https://launchpad.net/bugs/187330
<ubotu> New bug: #187342 in bzr "'bzr add --verbose' quietly ignores subdirs with their own .bzr" [Undecided,New] https://launchpad.net/bugs/187342
<nebuchadnezzar> hello
<nebuchadnezzar> I want to use a shared repository on a remote server to keep configuration files, but I want a process on this server to use this configuration.
<nebuchadnezzar> I planned to make a 'rsync in the after commit hook' but I think there is a better solution
<asabil> push-and-update ?
<nebuchadnezzar> something like that yes
<nebuchadnezzar> it doesn't seems to work over sftp :-/
<nebuchadnezzar> debian sid bzr 1.1~rc1-1
<nebuchadnezzar> ok, push-and-update is a plugin
<nebuchadnezzar> asabil: thanks, I'll test this, but I wonder if it can works with merge ?
<abentley> nebuchadnezzar: If you're doing merges, you should always do them locally anyhow.
<ubotu> New bug: #187349 in bzr ""bzr branch" throws MemoryError" [Undecided,New] https://launchpad.net/bugs/187349
<nebuchadnezzar> abentley: ok, thanks
<nebuchadnezzar> arf, it need bzr on the remote side, ok
<b0ef> ehlo
<b0ef> I get a criss-cross merge
<b0ef> is even bzr merge --weave ../foobar supposed to tell me "criss cross merge encountered"?
<abentley> Yes.
<b0ef> but I can expect that everything is fine?;)
<abentley> If you have no conflicts, you can.
<abentley> Criss-cross refers to the context in which you're doing the merge.  --weave just changes how you do the merge in that context.
<b0ef> right, I'll just --weave and criss-cross fingers, then;), thanks
<abentley> If you've got a recent Bazaar, --lca is faster and should give better results than --weave.
<b0ef> abentley: thanks, I'll try
<dato> I did a --lca the other day, and it didn't gave me a conflit where I was expeting one
<dato> expecting
<dato> and well, between the two possibilities, it didn't do the one I wanted
<b0ef> no, I don't have any conflicts; it's just that I read that I might loose some history
<abentley> dato: Okay, if you can send me details I'd appreciate it.
<dato> sure, hang on
<dato> abentley: I mailed you a recipe
<abentley> dato: Thanks.  I've followed it, but NEWS produces conflicts whether I specify --lca or --merge3.  The output is identical.
<dato> abentley: I think I said TODO, not NEWS?
<abentley> Oh, my bad.
<dato> ok
<abentley> Yes, I confirm the difference in TODO.
<abentley> However, I'll point out that --weave has the same problem as --lca for cases like this.
<abentley> So I still think --lca is better that --weave, it's just not better than merge3 for this case.
<dato> oh, indeed. I couldn've sweared I got a conflict with --weave.
<dato> but you're right
<dato> could've
<abentley> I'll see what I can do to ensure conflicts in this case.
<dato> ok, thanks for taking a look
<abentley> Thanks for the report.
<lifeless> moin
<james_w> hi lifeless.
<james_w> safely back?
<lifeless> yup
<abentley> Safe for who? (ducks)
<lifeless> :-
<jam> lifeless: ping
<james_w> jam: hi
<jam> hi james_w
<james_w> jam: I got 550 Administrative prohibition when sending to your email account, did I do something to offend your mail server?
<jam> hmm. I haven't seen Administrative prohibition, I've do have a greylist that asks people to try sending again after a while
<jam> you might just try re-sending your email
<jam> which is usually enough to get past the greylist
<fullermd> Greylist certainly shouldn't 5xx, though.
<james_w> jam: I assume you will get it via the list, so it's no loss.
<jam> I admit to not being a mail guru, but I'm thinking it was giving 4xx
<jam> james_w: well, I have no-dupes turned on, so I may not
<fullermd> Hate that option.  Hate mailing lists that set it by default.
<james_w> jam: looking in my logs it seems I also got a 450 Client host rejected: cannot find your hostname, [89.145.97.141]
<m3thos> why is a reverse dns failure a motive to reject a host ?
<jam> fullermd: it works very well for me
<fullermd> It's not rejected, it's deferred.
<jam> fullermd: it might be rejected
<jam> I get a lot of spam
<fullermd> ('course, presumably the sending host will stop trying eventually)
<jam> The grey-list should be asking them to resend later
<jam> but if I can't do a reverse lookup
<jam> it may consider you suspect
<fullermd> It's still 4xx'ing.  It won't get as far as the greylist checking then.
<jam> # Reject sender hostname without DNS A or MX record, permit sasl users,
<jam> # permit $mynetworks, check for permit/reject in /etc/postfix/access.
<jam> #
<jam> smtpd_sender_restrictions = reject_unknown_sender_domain,
<fullermd> You wouldn't want to 5xx a PTR lookup failure, since that can be transient.
<jam>         permit_sasl_authenticated, hash:/etc/postfix/access
<fullermd> I find it easier to have all my restrictions in _recipient_restrictions; that way I can avoid repeated lookups, and have the precedences all the way I want 'em.
<lifeless> jam: pong
<fullermd> (of course, it's also 28 lines long, which may seem excessive...)
<james_w> jam: ah, it's a different host that sends the 550
<lifeless> m3thos: spammers
<fullermd> But anyway, that error james_w pasted is from reject_unknown_hostname, not a sender call.
<jam> lifeless: I wanted to pick your brain a bit about bug #187169
<ubotu> Launchpad bug 187169 in bzr "Partial commit with mv and rm under breaks dirstate" [Critical,In progress] https://launchpad.net/bugs/187169
<lifeless> sure
<james_w> it hits your secondary MX for the retry, and get's the 550.
<jam> So the first issue is that we have a rename and a file underneath that directory is deleted
<jam> I checked with the old "knit" format
<jam> and under that condition
<jam> we would get a renamed foo => bar to be committed
<jam> but the delete would still be pending
<lifeless> bleep
<jam> I think it is arguable which should happen (since the user script deletes it *after* the rename), but we can preserve either behavior
<jam> So the failure of "update_basis_by_delta" is that it expects you wouldn't be renaming a file to a "deleted" target
<lifeless> it sounds like we are creating an invalid delta?
 * fullermd would absolutely expect the delete to be committed, FWIW.
<jam> lifeless: well, the old code would have created a new record which is marked as already deleted
<fullermd> (short of a commit --no-recurse or some such option)
<jam> fullermd: there is a small problem in detecting that it happened, but I do understand your point
<fullermd> I wouldn't expect the order of operations to matter, just the state when you 'commit'.
<lifeless> fullermd: interesting topic, but orthogonal
<jam> fullermd: sure, it is more that when you delete the file after the rename, the way it is stored makes it a little bit trickier to tell that it should be affected by the partial commit
<lifeless> fullermd: perhaps we can focus on the bug-in-hand
<jam> lifeless: anyway, the update_basis_by_delta code assumes that the target won't be marked "absent"
<lifeless> jam: so we have /deleted-path (A, F)
<lifeless> and we issue a rename in the delta ? /deleted-path -> /renamed-deleted-path
<lifeless> but rather than getting (A, R(/deleted-path))
<jam> it borks
<jam> with "invalid ..."
<jam> and then stops processing the delta
<jam> which borks future operations because the rename was only partially applied
<lifeless> ok
<lifeless> so lets do two things here
<lifeless> lets make this transactional
<asabil> is bzr-svn able to handle https repos ?
<asabil> like google code ?
<lifeless> mark the dirstate as in-memory-fucked, and refuse to write it out
<lifeless> asabil: yes
<asabil> hmmm then what is wrong :
<jam> asabil: I *think* you have to connect to it with the raw svn client first
<jam> so that it can save the credentials
<asabil> Unable to handle http code 401: expected 200 or 404 for full response.
<jam> and then use "svn+https://"
<lifeless> asabil: thats in the faq I believe
<asabil> oh ok thanks
<fullermd> This may or may not be related to bug 187207, too.  The trigger and symtoms are a bit different (not partial, second commit succeeds, stat doesn't fail), but it's a similar dirstate errror.
<ubotu> Launchpad bug 187207 in bzr "commit reports error when a file has been moved and then removed in the same revision" [Undecided,New] https://launchpad.net/bugs/187207
<asabil> so https is basically "half" supported
<jam> asabil: AFAIK it is a problem with the SVN bindings not exporting the right stuff so that we can handle authentication prompts
<asabil> okidoki
<jam> which I think might be fixed in newer python-subversion bindings, which means it is also fixed in newer bzr-svn
<jam> but I'm going from hazy memory of conversations with jelmer
<jelmer> should work with all versions of python-subversion
<jam> jelmer: I thought you couldn't authenticate to svn+https
<jelmer> but you may have to prefix the url with "svn+" otherwise bzr-svn never sees the connection
<jelmer> jam: You can, if you let svn do it for you
<jam> using svn+?
<jam> or you have to connect using svn one time and save the auth
<jelmer> jam: or with python-subversion 1.5 bzr-svn can prompt you
<jam> jelmer: that is what I thought, which is what I was trying to get across
<jelmer> jam: sorry, I just read the line that said "jelmer" because that's the bit xchat highlighted
<jam> lifeless: so, back to our thread.... I agree about marking the dirstate as IN_MEMORY_BROKEN
<jam> how would you handle renaming an absent record?
<jam> At first I thought about just skipping the error check
<jam> but it seems to complain later on, too
<lifeless> so the record is not included in the delta
<lifeless> erm rephrase
<lifeless> a delta that has a rename with a child that is absent
<jam> (the first error is when it goes to process the delete side of the rename, it expects the file to have existed, the second error is when it goes to add the record, it expects the target path to already exist)
<lifeless> [/foo->/bar], and /foo/quux is marked absent
<lifeless> is that the situation ^ ?
<jam> lifeless: correct
<lifeless> so expanded we get [/foo/quux, /foo, /bar, /bar/quux] as the order of paths we touch
<lifeless> or thereabouts
<lifeless> hmm, so the question is 'is it valid to rename a deleted file'
<lifeless> if we say 'no' then we have to fix commit to spider out file ids properly
<lifeless> rather than the current broken code
<lifeless> this is quite easily actually, with dirstate
<lifeless> and I think that failing to commit the delete is definately a bug
<jam> I'm curious if there would be another way to trigger this
<jam> such that update_basis_by_delta should really handle it
<jam> but otherwise I agree with you
<lifeless> I think foxing the corruption is sufficient for now - if another case turns up we'll get a bug report :)
<abentley> lifeless: fwiw, I think it should valid to rename a deleted file.  TreeTransform is explicitly designed to support that.
<lifeless> abentley: in terms of historical trees though, this shows up as a rename and no delete
<abentley> I would hope it would show up the same way as the reverse order would.
<abentley> i.e. rename, delete.
<lifeless> abentley: the delete is being skipped by commit
<lifeless> abentley: so the delta does not include the delete
<jam> lifeless: that, and if it did show the delete, it would show up as only a delete
<lifeless> jam: right, but that would be correct and ok
<jam> ie, it would show "old/b" deleted, not "old/b renamed to new/b" and "new/b" deleted
<asabil> http://pastebin.be/8696
<asabil> bzr exception with bzr-svn and google code
<james_w> jam: I think that is just as accurate assesment of what happended.
<jam> asabil: now there is an interesting path: /svn/!svn/vcc/default
<james_w> jelmer: ^ have you seen that before?
<asabil> jam: yep :) google code seems funky
<james_w> asabil: https://lists.ubuntu.com/archives/bazaar/2008q1/036473.html
<james_w> asabil: svn proplist https://waf.googlecode.com/svn/trunk/
<asabil> oki
<asabil> but this doesn't happen in the beginning
<asabil> it happens at the end
<asabil> and with an svn co
<asabil> I get this after it is finished
<asabil> svn: REPORT request failed on '/svn/!svn/vcc/default'
<asabil> svn: REPORT of '/svn/!svn/vcc/default': 200 OK (https://waf.googlecode.com)
<asabil> is it possible to convert an svn checkout into a bzr branch ?
<jelmer> asabil: "svn co" (no bzr involved) also fails?
<jelmer> asabil: Please file a bug against google code
<asabil> jelmer: yes, but I can continue using an svn up
<jelmer> asabil: still, that means there's a bug there
<kjcole> qbzr plugin on the mac broke "bzr commit" ("bzr qcommit" still works.)
<jelmer> asabil: a server bug most likely (googlecode uses a custom svn backend)
<kjcole> (Error is "bzr: ERROR: [Errno 13] Permission denied")
<jelmer> asabil: you can convert from a svn checkout to a bzr branch but it will use the same code patrh
<jelmer> and will make the same requests to the svn server
<asabil> oki :'(
<kjcole> I just installed both today on a mac.
<luks> how could installing qbzr cause "Permission denied"?
<lifeless> the full backtrace may help
<lifeless> check ~/.bzr.log
<kjcole> luks I dunno.  I may be misinterpreting things as I hadn't tested much on the mac.
<kjcole> lifeless, luks I just posted the log to launchpad
<kjcole> lifeless, luks (under qbzr bugs)
<luks> kjcole: the first commit was `bzr commit -m '...'` or `bzr commit`?
<luks> the bug doesn't look qbzr related to me at all
<luks> it has trouble launching the editor
<kjcole> luks, bzr commit
<luks> and it started an editor?
<kjcole> luks, I've got my default editor set to emacs, which works fine on ubuntu (except that it doesn't delete the temp log file).  It appeared to work on OS X as well...
<luks> check ~/.bazaar/config.conf
<luks> er, ~/.bazaar/bazaar.conf
<kjcole> luks, http://pastebin.ubuntu.com/4015/
<luks> what happens if you remove the editor = "" line?
<kjcole> luks, qbzr put in everything after the email line when I did the qconfig
<luks> yes, that's probably the problem
<luks> does it work if you remove it?
<kjcole> luks, which is why I never thought to look at it.  So, that would be a qbzr bug?  (Removing now...)
<kjcole> luks, that was it.
<luks> ok, I'll try to convince ConfigObj to remove it instead of clearing it
<kjcole> luks, if I decided to enter a value there, what's it looking for?  full path to my editor of choice?
<luks> just the command name would be fine, if it's in PATH
<kjcole> luks. thanks.
<kjcole> P.S. what about command line arguments?  (for example "nano -bkw"?)
<luks> no idea, try it :)
<kjcole> Heh.  ;)
<kjcole> luks, FYI It seems to work fine with the arguments.
<james_w> The tarball of 1.1 on launchpad doesn't correspond to the tree of the last revision on the 1.1 branch. Should we release a 1.1.1 to fix this?
<james_w> see bug #187330 for the details
<ubotu> Launchpad bug 187330 in bzr "Commit failed with attribute error" [Undecided,New] https://launchpad.net/bugs/187330
<igc> morning
<james_w> morning.
<jam> igc, poolie : meeting now?
<igc> I'm on
<igc> jam: poolie is still on a call apparently
<ubotu> New bug: #187452 in bzr "Graph.find_differences() is confused by shortcuts" [Medium,Triaged] https://launchpad.net/bugs/187452
#bzr 2008-01-31
<luislavena> hello everybody.
<luislavena> anyone had experience installing bzr on a shared host?
<poolie> yes, sure
<luislavena> poolie: dreamhost, bluehost or site5?
<poolie> oh, huh
<poolie> none of those
<poolie> why not use launchpad.net?
<luislavena> poolie: is for a private project
<luislavena> poolie: been pushing via ftp and pulling via http, but these dumb protocols are a bit slow.
<poolie> are you using a pack repository?
<luislavena> yep, pack-0.92
<luislavena> with 1.1
<luislavena> sorry, bzr 1.1
<luislavena> freshly created repos :)
<beuno> luislavena, I'm not sure you can install python apps on shared hosts
<beuno> (I'm fairly sure you can't unless it's a virtual server or the likes)
<luislavena> beuno: thank you
<luislavena> beuno: maybe something like this
<luislavena> beuno: http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html
<beuno> luislavena, ah, seems pretty straight forward
<luislavena> beuno: I'll need to check if the dependencies can be installed in the same way, since I've 2.4.3 available and only tested bzr with 2.5.1
<beuno> if you're allowed to install stuff in your home, for the most part, those same steps should work
<beuno> luislavena, bzr works fine with python 2.4X
<luislavena> beuno: thank you for the info
<luislavena> beuno: is there a way I can see if everything works as expected ? (selftest?)
<beuno> luislavena, yeap, bzr selftest
<fullermd> Uff.  Not a particularly kind thing to do...
<Odd_Bloke> fullermd: What in particular?
<luislavena> fullermd: yes, I know... will make the shared host a nightmare to other users.
<fullermd> Odd_Bloke: running 'selftest' on a shared webhost?
<poolie> because of cpu usage?
<poolie> run it niced...
<poolie> or run, say 'selftest command'
<poolie> sorry, i mean 'blackbox'
<fullermd> cpu, disk...   last time I ran it, it made my workstation crawl for about 40 minutes.
<fullermd> Still negotiating the restraining order my hard drive filed at the time...
<luislavena> fullermd: hehehe, no problem, the InstallationFaq contains pointers on how to check for the missing dependencies.
<luislavena> so far, the shared host lack all of them :P
<luislavena> I'll see if I can install them like bzr...
<luislavena> (on $HOME)
<Odd_Bloke> fullermd: Ah, OK, I was thinking more generally.
<bob2> ffworked fine on dh for me
<luislavena> bob2: how did you handle the dependencies? ElementTree, pyramiko, etc?
<fullermd> Well, you don't need paramiko unless you're sftp'ing _out_ from there.
<bob2> aelementree is python, as is paramiko, and what fullermd  said
<bob2> you could probably even get bzr+http working, I think they do fastcgi
<lifeless> revie requested: http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E
<luislavena> bob2: how bzr+http will handle authentication?
<bob2> poorly!
<lifeless> bob2: uhm
<lifeless> luislavena: it should handle it fine
<luislavena> lifeless: thank you :)
<luislavena> but anyway, it fails to compile the c part of bzrlib
<luislavena> so I think this shared host is not as good as other ;-)
<bob2> hm, I was reading the bzr+http docs yesterday, and it looked like you couldn't control what people could write to
<lifeless> bob2: thats access control not authentication
<lifeless> bob2: bzr+http delegates authorisation and authentication to apache and makes no direct effort at access control
<bob2> touche
<fullermd> Well.  Access control is a subset of authorization...
<lifeless> fullermd: bup
<lifeless> fullermd: bah, nup, its not
<lifeless> fullermd: its a subset of AAA, but other than that you can have any one without the other two
<fullermd> The third A in AAA is 'accounting', though.
<bob2> but it's not possible to have differing read and write authorization with bzr+http yet, right?
<lifeless> bleh, my brain has clearly faded
<fullermd> Dirstate does that to ya   ;)
<lifeless> bob2: depending on what granularity you want, yes or no
<lifeless> bob2: in a single repository, we still depend on VFS access for some methods, so any access to the data base implies full data visibility
<fullermd> I would phrase it as "bzr+http delegates authentication to Apache, and abdicates authorization to merely be contingent on authentication".
<lifeless> bob2: but you can certainly split read and write access in a couple of ways - you can run the server with different parameters via the apache config to block writers
<fullermd> The usual suggestion for that is "read/only bzr+http, read/write bzr+https with HTTP auth"
<lifeless> not sure why you'd split the protocol
<lifeless> but whatever
<fullermd> Well, that makes the URL's almost the same on both sides.  Gives you SSL where you're sending auth info over the wire.
<lifeless> digest auth ftw; or has that not landed yet ?
<fullermd> Well, it would also prevent a MitM when you were pushing data.  If anybody still bothers trying to carry those out.
<lifeless> digest supports body signing
<lifeless> plus sign your commits kthxbye
<lifeless> igc: I wonder if I can borrow you for http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E
<igc> lifeless: sure. Meant to get to it yesterday.
<igc> I'll move it to the top of my review list
<igc> (ahead of thumper's one)
<thumper> :(
<luislavena> guys, there is no feed generator that can hook push and commit?
<luislavena> branchfeed seems old and don't work.
<lifeless> luislavena: my plugin should still work
<luislavena> lifeless: can you point me to the branch?
<lifeless> one sec
<luislavena> lifeless: thank you
<lifeless> branchfeed is what I called mine lol, I had to re-read it
<luislavena> lifeless: the one here doesn't work:
<luislavena> https://code.launchpad.net/~bzr/bzr-branchfeed/trunk
<luislavena> it's supposed to generate a feed in .bzr/branch/branch.atom, but no file get generated.
<lifeless> https://bugs.edge.launchpad.net/bzr-branchfeed/
<lifeless> could you file a bug please
<luislavena> lifeless: will help you if I run the plugin selftests?
<lifeless> is the plugin installed on your client or server?
<luislavena> client, doing everthing locally and sometimes using smart server.
<lifeless> yah, I can't look at this right now
<lifeless> please file a bug with as much info as you can gather
<luislavena> lifeless: yeah, sure. thank you again :)
<luislavena> lifeless: done :)
<ubotu> New bug: #187479 in bzr-branchfeed "BranchFeed don't generate atom feed after commit or push" [Undecided,New] https://launchpad.net/bugs/187479
<luislavena> guys, another silly question, but i cannot find a way to verify the signed commits
<luislavena> there is sign-my-commits and re-sign, but no verify-signed-commits or something similar.
<lifeless> poolie: perhaps https://code.edge.launchpad.net/~mbp/bzr/dev should be registered, its a dupe with https://code.edge.launchpad.net/~bzr/bzr/trunk
<lifeless> luislavena: yah, someone was working on it
<luislavena> lifeless: good to know, the check_signature and create_signatures configuration options works?
<luislavena> (branch based and globals)
<luislavena> ok, it seems so, just wanted to be sure :)
<abentley> lifeless: is get_data_stream_for_search meant to have ordering restrictions?
<lifeless> abentley: no more so than the get_data_stream api it replaced
<abentley> They both have prefixes with lists of versions after them.
<abentley> I'm not sure whether a prefix is allowed to be repeated.
<abentley> The use of prefixes suggests that the designer wasn't expecting the prefix to change frequently.
<lifeless> I don't think the current code or tests prevent that
<lifeless> the goal was a single namespace for all data atoms
<abentley> Since ('a')['b'], ('c')['d'] isn't all that helpful.
<abentley> But in packs, I would expect the prefix to change at least twice per revision.
<lifeless> why?
<abentley> If you read from the beginning.
<lifeless> oh right
<lifeless> currently on sftp I do four readv's per pack
<lifeless> each readv linear sorted
<lifeless> (for fetching this is)
<abentley> Cool.
<lifeless> that seems a reasonable tradeoff in simplicity/speed - it lets us keep the read revision, read inventory, read texts etc sequence
<abentley> Oh, I see.
<lifeless> which means we don't copy unreferenced data, can sanity check etc
<abentley> But revisions and sigs are fulltexts, so it wouldn't hurt to read them at the same time as inventories.
<abentley> No additional memory cost, at least.
<lifeless> and transactional inserts into the repository means we can just flush to disk
<lifeless> abentley: right, it can certainly be tweaked; howver the sigs and revisions are in different indices to the inventories
<lifeless> so if we were trying to optimise memory more we would actually be dropping index content from memory after grabbing the data for that index
<abentley> Yes, I suppose it makes sense to do each index in turn.
<lifeless> I haven't had any breakthough thoughts about storage/repository; I will reply to the thread though and see if we can get a good compromise; I _do not_ want to prevent improvements
<abentley> Even though we haven't agreed on the structure for Storage, I think that we can agree that an implementation of iter_files_bytes that reads each pack only once would be a win.
<lifeless> abentley: oh for sure
<abentley> So I'm going to look at restructuring the knit-building code to support that.
<lifeless> abentley: great; I hope you'll find its already half way tere
<lifeless> *there*
<lifeless> I split out the 'get data' stuff to a KnitAccess helper a ways back
<abentley> Oh, I've been wondering what that thing was.
<lifeless> so PackAccess knows how to get stuff from an arbitrary key
<lifeless> by mapping the key which is (index, key)
<lifeless> through the index to get an actual pack file
<lifeless> KnitAccess maps likewise but to a single file the .knit file
<lifeless> this gives KnitData as simply providing the logic for combining hunks etc
<abentley> Hmm.  Somewhat different approach than I was thinking, but it could work.
<lifeless> and KnitIndex maps into a combined index for packs, which filters out the fileid prefix
<lifeless> so what I have been thinking about doing is
<lifeless> adding a file id prefix to the standard knit code
<lifeless> which the existing KnitIndex stuff would enforce as always being the file id the index is for
<lifeless> and the pack index mapper would just stop filtering out the file id prefix
<lifeless> thus giving the existing iter_versions etc stuff the ability to deal with many file ids at once
<lifeless> anyhow, I'm rambling - this is what I had in my head, not the only way to do it :)
<abentley> Well, it's interesting.
<abentley> I basically already have the code to map a bunch of requested knit entries to their pack transport/name/offset/size.
<abentley> So I was thinking about doing that part up front.
<lifeless> the map code should a single index iter_entries query really :)
<abentley> Basically via the iter_raw_items variation on get_data_stream.
<abentley> Yeah, I like that.
<lifeless> the thing I like about extending knit is that the combining logic does not get duplicated, or have to move
<lifeless> so improvements there will still help anything thats roughly delta combining related
<abentley> The downside is you can't retrieve everything in a single read.
<lifeless> hmm? sure you can
<lifeless> get_raw_records
<lifeless> used by read_records_iter_raw
<lifeless> so read_records_iter_raw is already multiple-file-id ready, as long as the _Access object it has been given is
<abentley> By everything, I meant fetching files, revisions, inventories and signatures all at once
<lifeless> oh right
<abentley> You can achieve that by adding a prefix, I think.
<lifeless> hmm, if we guarantee that the indices contain enough data
<abentley> You then wind up with something very close it Storage.iter_raw_items.
<lifeless> I like the idea of getting get_data_stream and insert_data_stream
<abentley> s/it/to
<abentley> lifeless: I think you were cut off: "I like the idea of getting get_data_stream and insert_data_stream"
<abentley> But I'll mention that if we get the inventory first, we can do fetch and build_tree at the same time.
<lifeless> yup
<lifeless> fetch currently puts the inventory before all texts
<lifeless> for locality of reference its grouped too
<lifeless> not really cut off; just not finished
<Aloha> whats the difference between a branch and a trunk?
<weigon> Aloha: one starts with a b, the other with a t. That's pretty much it.
<Aloha> weigon, whats the point of differentiating?
<weigon> Aloha: "trunk" is svn-speak for the main-development-branch
<Aloha> weigon, so why have more than one branch?
<fullermd> Trunk is a branch that you call trunk.
<weigon> Aloha: release-branches, feature-branches, merge-branches, ...
<weigon> in bzr-world everything is a branch, everyone has it's own repository.
<Aloha> weigon, so whats the difference between feature branch and release branch?
<weigon> Aloha: I think the best example is taking a look how the linux kernel-development works
<fullermd> Pretty much the difference between a water glass and a milk glass...
<Aloha> why would my project have more than one branch? different parts of it go in different branches?
<weigon> Aloha: no, put sometimes you have to release something to users|customers
<weigon> and they call you 6 month later about a bug and you are already working the next big release
<Aloha> weigon, so you can pull up the source code from that release and work on the bug?
<weigon> ... and fix it for that release to build a new release (1.0.1), while you are still doing your main-dev in "trunk" for the 2.0 release
<weigon> if you want to implement a new feature and want to write a Proof-of-Concept you will commit it not to trunk, but to a feature branch.
<weigon> if it works well and matures, you merge the new feature back into trunk
<Aloha> weigon, so your source code that you edited would be in 1.0-dev branch and your release would be in 1.0.1-release?
<weigon> if it doesn't work out, you only have to trash your work, not the work of others that are in the main-dev branch
<Aloha> weigon, gotcha
<weigon> if you do it right, the main-dev branch is always in release quality
<weigon> everything unstable is in feature branches until it is well tested and can be merged over
<Aloha> weigon, gotcha
<weigon> Aloha: that means proper test-cases, unit-testing, ...
<Aloha> weigon, do you have a seperate branch for debian packages? or do you make those from release tarball?
<weigon> Aloha: debian packages are built aside anyway.
<Aloha> weigon, aside?
<weigon> Aloha: scroll down on http://packages.ubuntu.com/feisty/net/hostapd
<weigon> Source Package: hostapd, Download: [dsc] [hostapd_0.5.5.orig.tar.gz] [hostapd_0.5.5-3.1.diff.gz]
<weigon> it is always a the original tar + a diff that includes the build-files for debian
<Aloha> weigon, i know but the files uses to build the original tarball, does anyone keep a debian branch knowing that that branch will only be used to build packages?
<Aloha> s/uses/used/
<ubotu> New bug: #187593 in bzr-webserve "list index out of range" [Undecided,New] https://launchpad.net/bugs/187593
<ricardokirkner> hi. I just installed the bzr-svn plugin (I am running fedora core 7). However, when I try to check out an svn branch, I get an error telling me that the url is not a branch. The cmd 'bzr selftest svn' failed, but I cannot make out what the problem is. Can anyone help me out here, please?
<ricardokirkner> the error I get is '_get_location_config() takes exactly 1 argument (4 given)'
<ricardokirkner> ok, I found out the error. I relates to bzr-svn not being able (yet) to check out from webdab
<ricardokirkner> webdav
<jelmer> ricardokirkner: bzr-svn supports webdav yet
<jelmer> ?
<awilkins> Can anyone tell me the significance of .~1~ files in my BZR trees?
<LeoNerd> They're files left behind by 'bzr revert'
<LeoNerd> When you 'bzr revert' it moves your locally-changed file to .~1~ in case you wanted to keep it, before overwwriting it with a clean copy
<awilkins> Aha, thanks
 * awilkins executes ls -r -inc *.~1~ | rm
<dato> awilkins: there is bzr clean-tree --detritus, from the bzrtools plugin. try it with --dry-run first.
<jelmer> info je
<jelmer> info jelmer
<jelmer> whoops
<jelmer> sorry
<alefteris> after i upgrade my launchpad branch using sftp://<username>@bazaar.launchpad.net/~username/project/branchname, what should i do to my local working copy?
<beuno> alefteris, upgrade it too
<beuno> and, reconcile both
<beuno> bzr reconcile sftp://<username>@bazaar.launchpad.net/~username/project/branchname
<alefteris> i was reading this http://beuno.com.ar/archives/48, it mentions that I should recogline only if there is a problem.. is reconcile a dangerous operation?
<beuno> alefteris, oh, then I have to correct it
<beuno> you *must* do reconcile
<alefteris> :)
<beuno> alefteris, no, it isn't
<beuno> upgrade might be
<alefteris> ok thanks
<beuno> alefteris, I changed it a few hours ago, can you see if it's clearer now:  http://beuno.com.ar/archives/48
<beuno> (upgrade, on the other hand, already does it's own backup before doing anything, so all operations are fairly safe)
<synic> hey folks.  does this mean anything to any of you?
<synic> [projects]$ bzr branch  bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/ exaile
<synic> bzr: ERROR: Could not install revisions:
<synic> sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2
<beuno> synic, what version of bzr are you using?
<synic> 1.0.0
<beuno> synic, you might want to use http to branch
<beuno> (and, is that your user in LP?)
<synic> well, I'm trying to branch because a pull failed with the same error
<synic> yes, that's my LP user
<alefteris> beuno, you used to have a "check" step before the upgrade, its not actualy needed?
<beuno> alefteris, not really, if you have knits, it isn't required
<beuno> I also moved reconcile to _after_ upgrading
<beuno> it's million times faster
<beuno> synic, let me try and branch it
<synic> yeah, I just installed bzr 1.1 and same error
<beuno> I get 0 revisions
<synic> uh, there are a lot more than 0 revisions
<beuno> hmmmm
<beuno> LP is reporting problems with the branch...
<synic> great.
<beuno> synic, can you do: bzr reconcile  bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main
<beuno> has the branch been upgraded lately?
<synic> well, I didn't do it (I wouldn't even know how), but one of the other devs may have done something
<beuno> synic, try and run reconcile, and I'll ask in #launchpad if anyone can help
<synic> running it now
<beuno> ah, you already did...
<beuno> let's give reconcile a try first
<synic> whew, reconciling isn't the speediest operation, heh ;-)
<synic> beuno: ok, yeah, it's still broken.
<beuno> synic, argh...   I suspect it's a LP problem
<synic> bummer
<beuno> lifeless, jam, abentley, any ideas on why https://code.launchpad.net/~exaile-devel/exaile/main  might be broken?
<abentley> Broken how?
<beuno> abentley, it doesn't branch
<beuno> 0 revisions
<beuno> and LP reports it has a problem
<beuno> synic already ran reconcile on it
<beuno> and still nothing
<beuno> (nobody seems to be available in #launchpad)
<beuno> I see there is a broken character in the last commit message
<beuno> but I'm not sure if that can cause LP to go crazy
<beuno> (codebrowse also breaks: http://codebrowse.launchpad.net/~exaile-devel/exaile/main/files)
<synic> yeah, but on all the revisions, not just the last one (I don't know if that means anything)
<beuno> synic, I think it basically mean LP can't ready from the branch either
<synic> hrmm
<abentley> Yeah, you can see the "branch has errors" thing on the page
<beuno> abentley, so... how can this be solved?   push --overwrite from a healthy copy?
<abentley> It's also in format 5, which is a bit odd.
<abentley> Did you upgrade it?
<abentley> or did you push from an upgraded branch?
<beuno> synic, can you find out what the last dev did?
<synic> I'll have to wait until he gets online
<abentley> But I can confirm that revision-history is empty, so Bazaar is correctly interpreting that.
<synic> I'm not real excited to hear that :)
<beuno> synic, maybe the branch was upgraded and not reconciled
<beuno> do you have a healthy copy locally?
<beuno> (even if a bit out of date)
<synic> I have one at home.  I've been trying to log in and get it, but I can't get in for some reason
 * synic thinks of where there might be another
<synic> ah, I have one on exaile.org, but I'm not sure how old it is.
<beuno> synic, just so we can check what storage format you have and narrow it down to "someone upgraded recently and broke stuff"
<synic> ok, yeah, I found it.  How do I check?
<beuno> synic, bzr info -v | grep 'repository'
<synic> bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n'
<beuno> synic, ah, so it's packs. And you're using some old bzr version
<synic> on exaile.org, yeah.  It's 0.90
<synic> I'll upgrade, if it won't hurt anything
<beuno> synic, I would recommend upgrading it to 1.0 (or 1.1 even)
<synic> k, doing that now
<beuno> you should try and get a hold on the last dev that uploaded
<beuno> see if he can fix his locla copy
<beuno> if not
<beuno> find the latest healthy one you can find
<beuno> to 'bzr reconcile;
<beuno> s/;/'
<beuno> and then add the changed files
<synic> ok
<beuno> commit
<beuno> and move on  :D
<beuno> make sure everyone is using bzr 1.0+, and have upgraded their local branches
<beuno> I just blogged on how to upgrade a few days ago: http://beuno.com.ar/archives/48
<abentley> beuno: I'm trying to get more info on this, but no luck so far
<beuno> abentley, great, thanks!   synic can you stick around for a while and see if we can dig a bit deeper?
<synic> yeah
<dacresni> how do i get bzr 1.0 on ubuntu?
<synic> might be a bit before the other dev signs on
<synic> if he does at all
<synic> he's in australia, I'm in utah
<dacresni> thanks
<beuno> dacresni, you can get the latest from: https://launchpad.net/~bzr/+archive
<synic> bzr info -v | grep repository repository: Packs containing knits without subtree support
<synic> that's after the upgrade.
<dacresni> i c
<beuno> synic, good. I would run 'bzr reconcile' on it now
<dacresni> thanks beuno
<beuno> dacresni, no problem!  :D
<synic> beuno: it says "no repository present".  Ack, it's a checkout, not a branch.  Rats.
<beuno> synic, you can use 'bzr unbind' to make it into a branch, although I'm not sure who it's parent is
<synic> it's parent is the broken branch
<beuno> synic, I believe unbind won't call the parent at all if it's a regular checkour
<beuno> s/checkour/checkout
<synic> heh, it's a --lightweight
<beuno> aaargh
<beuno> not your lucky day...
<synic> no, no it isn't.
<beuno> well, I'd find out what kind of beer abentley likes then  :p
<abentley> You could try doing bzr reconfigure --branch, though.
<synic> in the checkout?
<abentley> synic: yes.
<synic> k
<dacresni> I like irc so much more than forums, its so much harder to search for what you wnt
<abentley> That assumes that upstream actually has the necessary revisions.
<dacresni> c ya
<abentley> bzr reconfigure replaces bind, unbind and remove-tree.
<abentley> Though I suppose you probably want reconfigure --tree.
<dacresni> hey, back
<dacresni> had a bit of a "problem with the package
<dacresni> well, i just wan'ted to fix my commit signing process
<dacresni> it responded gpg: problem with the agent - disabling agent use
<dacresni> bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']"
<dacresni> is this a bzr issue or a gpg issue
<dacresni> ?
<dacresni> beuno are you still there?
<beuno> dacresni, yes, although I haven't used gpg signing in bzr
<beuno> have you signed any commits yet?
<dacresni> i tried
<dacresni> no i haven't
<beuno> do you have your key setup with gpg?
<dacresni> i think so
<dacresni> i followed the instructions on the pgp site
<dacresni> i mean gpg
<dacresni> and those of the bzr site linked from bzrVSgit
<dacresni> the one http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/
<beuno> dacresni, and you've setup the email to use to sign commits?
<dacresni> im using this localy
<dacresni> so no
<beuno> dacresni, does:   gpg --list-keys    print out your key?
<dacresni> hmm
<dacresni> yes
<beuno> and that's the same email address you have configure in "bzr whoami"?
<dacresni> pub something
<dacresni> uid, my info
<dacresni> accept for the comment
<dacresni> o wait
<alefteris> beuno, the upgrade prosedure at a launchpad branch sure takes a while :)
<dacresni> ok, so i put my whole name
<dacresni> thanks i guess ill be fixing that
<beuno> alefteris, ah, yes, large branches + remote access are always fun to watch  :D    The upgrade is worth it though!
<beuno> dacresni, np
<dacresni> shouldn't it not use the comment?
<dacresni> thats kind of silly
<dacresni> i have 2 keys, one at home and one at work
<beuno> dacresni, that's why you can specify your email on ~/bazaar/, so it can find the key you want
<dacresni> i c
<dacresni> ok, so i added the comment to my email,
<dacresni> thats probibly going to screw up my patch emails should i use them in the future
<dacresni> email not valid
<dacresni> seriously, does anyone know how that works? does it really compare the entire line? or could it exempt the comment?
<beuno> dacresni, I haven't used it really. jelmer, I believe I've seen you play around with signing commits?
<dacresni> dang, i wonder if that came from intering the pass fraze to often
<beuno> dacresni, sorry, everyone seems busy today
<dacresni> 'ts ok
<dacresni> it seems the probliem with pgp
<dacresni> there seems to be a problem with the aigent
<jelmer> beuno: yep, I'm signing most of my commits
<dacresni> could you help
<jelmer> dacresni: is there a particular reason you'd like to sign commits ? There is no way to verify signatures yet afaik
<dacresni> well,
<dacresni> i was trying to get my boss to use it
<jelmer> dacresni: Should be a matter of setting "create_signatures = always"
<dacresni> but first i need to get the security features workign
<dacresni> o yeha
<dacresni>  thats already there
<dacresni> otherwise it wouldn't be asking me to  sign would it?
<jelmer> dacresni: right, so what exactly is your question ? :-)
<jelmer> that should be all there is to it.
<dacresni> why isn't gpg working, sorry it seems to be a problem with the agent
<jelmer> dacresni: Have you got gpg working outside of bzr ?
<dacresni> just now, no
<dacresni> i'll give you the error message
<dacresni> gpg: problem with the agent - disabling agent use
<dacresni> bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']"
<jelmer> dacresni: Did you create a key earlier?
<dacresni> but first i need to find out yes
<jelmer> dacresni: Also, there is no added security in signing revisions at this point..
<dacresni> yes i created the key
<dacresni> oy,
<jelmer> Does "gpg --clearsign <somefile>" on the command-line work?
<dacresni> same issue
<dacresni> gpg: problem with the agent - disabling agent use
<jelmer> the agent is optional
<dacresni> and then proseads
<dacresni> well, this is kind of confusiong
<jelmer> that's just a warning, it should work fine without the agent as well
<dacresni> sorry
<dacresni> confusing
<dacresni> it did work, (im finding that i've already commited something"
<dacresni> but bzr still exits with an error
<jelmer> it does the signature after the commit
<dacresni> was this resolved in later version?
<dacresni> well let me see
<jelmer> so if the sign fails you will still have a revision, it just won't be signed
<dacresni> well
<dacresni> i can't find the revision comment
<dacresni> that IS a problem
<jelmer> dacresni: it's not in "bzr log" ?
<dacresni> nope
<dacresni> has anyone else experienced this problem
<dacresni> ?
<jelmer> dacresni: What problem specifically?
<jelmer> not being able to sign revisions?
<dacresni> i will disable the signing but, not being able to comment revisions
<dacresni> thats a problem
<jelmer> dacresni: What do you mean with "comment" revisions?
<dacresni> let me see if disableing signing allows my comments to be saved
<jelmer> dacresni: Not being able to specify a commit message?
<dacresni> well,
<dacresni> theoreticly yes but, if its not saving my comments, it snot saving my revisions
<dacresni> i want to know if this ever happened in a more recent version
<dacresni> im using, just now, 1.1.0 sorry
<dacresni> i thought i was using 094 like i was an hour ago
<jelmer> dacresni: What do you mean with comments? commit messages?
<dacresni> "the package gave me errors in debian"
<dacresni> yes the commit messagese
<jelmer> dacresni: Does it ask you for a commit message or do you specify one on the command line?
<dacresni> its been fixed after signing was disabled
<jelmer> ok
<dacresni> it asked for a commit message
<dacresni> this is interesting behavior no?
<alefteris> beuno, upgrade finished, ole :)
<jelmer> dacresni: It simply doesn't add a revision for me if the sign step failed
<beuno> alefteris, yay!   Now reconcile should be fairly quick
<dacresni> thats what's happened for me
<dacresni> i just didn't look at it like that
<jelmer> dacresni: That's correct.
<dacresni> so where is the branch where they are implementing the security?
<dacresni> the revision signing?
<jelmer> dacresni: Revision signing has been supported for a long time
<jelmer> afaik nobody has started working on signature verification yet
<dacresni> ps this didn't happen at home, on my mac. i dont think
<dacresni> here im using ubuntu
<jelmer> dacresni: what exactly didn't happen on your mac?
<dacresni> at home, macports on a g5
<dacresni> it worked as normal
<dacresni> i installed macgpg
<dacresni> then added the line to my bazaar config
<jelmer> dacresni: It's gpg that's misconfigured on your Linux machine
<dacresni> then i signed some local commits, and it worked
<dacresni> probibly
<jelmer> I'm quite sure it is
<dacresni> i do believe the probem was with gpg
<dacresni> this is why i straddle between mac and linux
<dacresni> linux you have democracy issues and mac you have monarchy issues
<dacresni> like that dtrace issue... perhaps i should use solarus
<jelmer> dacresni: There are more userfriendly frontends for gpg on Linux
<dacresni> but how can any work if gpg has issues
<jelmer> They can take of configuring gpg for you
<dacresni> so what does that/
<dacresni> ?
<jelmer> what do you mean? Examples of programs?
<dacresni> yes, please
<dacresni> first, whats this agent the error speaks of?
<jelmer> dacresni: seahorse is one
<jelmer> dacresni: gnupg's agent program
<jelmer> dacresni: I don't use it but apparently you've got it configured
<dacresni> but what is the agent in reference to gnupg
<dacresni> and why did mine screw up
<brink_> Am I somehow getting Bazaar from the wrong universe?   On Windows and OSX I'm at 1.1.0   On Ubuntu the most recent version from apt-get seems to be 1.0.0.candidate.1.    Is my Ubuntu installation messed up?
<jelmer> dacresni: You may want to ask in the gnupg channel
<jelmer> dacresni: I suspect it's something similar to ssh-agent
<jelmer> but for gpg
<jelmer> dacresni: Still, why are you so keen on setting up signing revisions? There's no point in doing so at this time and Bazaar may have better integration with apps like seahorse in the future.
<dacresni> i c
<dacresni> well, i wanted to get some kind of security so that this app is comparable to git in some other way other than workflow flexablility
<Peng> brink_: Get it from PPA.
<Peng> brink_: https://launchpad.net/~bzr/+archive
<jelmer> dacresni: revision signing won't get you any security at all at this point. it may help you verifying the integrity of now signed revisions in the future
<dacresni> well, ok
<dacresni> the only reason why i look at this project more closely than git is because it's all done in one language
<dacresni> instead of 5
<jelmer> dacresni: I agree it's a useful feature though
<dacresni> 1 being c
<jelmer> dacresni: bzr is written in python...
<dacresni> no i mean one of gits language being c
<jelmer> ah, ok
<brink_> Peng:  Thanks.  I'll give it a try.
<Peng> Wait, so signed revisions aren't verified?
<dacresni> yup
<Peng> That...sucks.
<dacresni> i would like it if it varafied the integrity of the signature before its accepted to the tree on bzr servers
<dacresni> i guess we'll have to settle for ssh
<dacresni> not that that's a bad thing
 * Debolaz still has a fondness for the simplicity of git's design.
<dacresni> hmm
<dacresni> im curious of what that is
<jelmer> Debolaz: in what way is git simpler than hg or bzr?
<dacresni> i mean, simple is linus's style but how is git siimple
<jelmer> the way the commands work?
<dacresni> the security model itself
<dacresni> '
<dacresni> ?
<Debolaz> The commands are horribly complex.
<dacresni> exactly
<Debolaz> But the fundamental ideas that git is based on are very simple.
<dacresni> and those are?
<jelmer> Debolaz: I don't see that those ideas are so different from the ones in bzr or hg though
<dacresni> the decentralization model bzr copy
<jelmer> dacresni: bzr is older than git...
<Debolaz> Everything is an object in a filesystem, named after its content. Every branch is simply a file pointing to an object. When you update, you just make new objects and write the name of the head tree object to the branch file.
<dacresni> really?
<dacresni> i didn't know that
<Peng> Also, the DVCS model is older than either bzr or git..
<jelmer> Debolaz: The only thing that's different there is that bzr doesn't name a file after its contents but uses a pseudo random id
<Debolaz> It could easily be reimplemented with a few shell scripts. Horribly inefficiently implemented, but still very simple in concept.
<dacresni> ? git could be reimplemented in a few shell scripts?
<jelmer> Debolaz: I still don't see what's so fundamentally different.
<dacresni> so mw is out to lunch"?
<jelmer> I think it's dinner, rather
<dacresni> its only 1
<dacresni> o wait
<dacresni> never mind
<Debolaz> jelmer: Well, I never made the claim that it was fundamentally different. But it is different, and it is simpler. Granted, I know very little about bzrs internal workings, but even if what you say is the only big difference in storage, then that still increases complexity by some bit.
<rcohen> some complexity is necessary to get efficiency and features
<rcohen> git's original storage model was horribly space inefficient
<Debolaz> Yes it was. But very simple.
<jelmer> Debolaz: Using ids rather than file contents to identify files doesn't impact the complexity of the storage layer all that much
<jelmer> Debolaz: And you've still failed to mention a reason why it's simpler.
<rcohen> simple and unusable for the primary use case
<rcohen> i'm not sure what's so admirable about simplicity if it doesn't do what you need
<Debolaz> jelmer: You lose the ability for renames to be detected by design for instance. You have to track this differently somehow (Possibly using hashes, but then you're back at square one again).
<dacresni> well, this has been the argument between git and bzr before, storage format
<Debolaz> Let me again emphasize that I'm not saying anything bad about bzr here, I barely know bzr. :)
<jelmer> Debolaz: bzr tracks renames explicitly rather than inferring them using complex algorithms that have to determine whether one file was a rename of another.
<rcohen> it's highly debatable whether automatically detecting file renames is a good idea
<dacresni> it might because not could cause duplicity
<rcohen> it can do really bad things in the worst case, and a lot of effort is put into making sure that the worst case for a merge algorithm isn't all that bad
<jelmer> Debolaz: Right, I'm not saying git is bad or there are no reasons for picking git over bzr either. I just don't understand why you claim git is simpler...
<fullermd> CVS is simpler yet; we should switch   :)
<jelmer> rcohen: yeah, I agree. It's usually better if you can predict when it's not going to work
<jelmer> fullermd: :-)
<jelmer> rcohen: Finding the right way to track file identity is hard though
<jelmer> rcohen: bzr uses file ids, but they only allow you to track renames, not e.g. copies
<rcohen> i'm a big fan of doing it explicitly
<rcohen> i don't think supporting copies is all that useful
<rcohen> the point of doing it would be that whatever merge algorithm would be aware of it
<rcohen> in my experience, a user would use the copy when they wanted to split a file
<jelmer> copies can be useful when splitting files
<fullermd> I'm a lot more interesting in splits and joins.  But copies you can kinda get for free with those mechanisms, so...
<rcohen> which, if you then tried to merge across it, would cause horrible conflicts and ambiguity
<Debolaz> jelmer: Because I gave the complete description of how the fundamental of git works above, and I do not think bzr or hg can be described with as few lines. git is a simple design. Possibly at the cost of efficiency, userfriendlyness (Yeah, I agree about the commands being less than idea), and other things. Bzr might be better at those things and yes, I agree those things are a higher priority for most users.
<jelmer> Debolaz: the description you just gave above almost matches bzr and hg
<rcohen> Debolaz: the point is that in order to be useful even git has taken on extra complexity
<rcohen> Debolaz: by comparing git "conceptually" to the implementations of bzr and hg you're comparing apples and oranges
<Debolaz> jelmer: I know there are significant differences from it at least for hg. Simply naming a revision by a SHA1 ID is not the same thing as actually storing the content in a file with that name. The former might be a part of something significantly more complex.
<Debolaz> But I guess we can agree to disagree, I don't want to make this turn into a flamewar. :)
<jelmer> Debolaz: yeah, let's do that :-)
<fullermd> Shucks.  I was just making popcorn...
<jelmer> rcohen: Yeah, merges would be an interesting problem for splits
<jelmer> rcohen: but it would be awesome if we could get that working
<rcohen> jelmer: believe me, i've thought a lot about it
<rcohen> there be dragons
<Debolaz> However, I would like to make a point about automatic detection, not neccesarily about renames. Whenever something isn't automatically detected, or enforced a certain way, users will screw it up. I think the most notable example of this is subversion branching.
<jelmer> rcohen: :-)
<jelmer> rcohen: even without proper merge support being able to represent copies would be nice though
<jelmer> rcohen: since we get that data when we import from other version control systems
<rcohen> jelmer: it's hard to say what should happen without merge support
<rcohen> let's say your merge doesn't know anything about copies and the system pretends that the full history applies to both files
<rcohen> now, you didn't really want a copy, you wanted a split
<rcohen> so you go ahead and delete half of each file
<rcohen> in another branch, someone modified the file
<rcohen> then you merge that branch in
<rcohen> suddenly, you've got a massive conflict in the file which deleted that section
<jelmer> rcohen: ouch, yeah, that would be a problem
<rcohen> now let's say you didn't want to split, you really wanted a copy (because you're into cutting and pasting, who knows)
<jelmer> Debolaz: yeah, leaving out the concept of a branch really hurt Subversion
<rcohen> someone in another branch modifies the file
<jelmer> Debolaz: and it hurts bzr-svn now, since it has to guess what users consider a branch
<rcohen> you merge that branch in, both files get the merge, but you only wanted the "original" to get the change
<foom> is there a way to create a branch in an svn repository using bzr?
<foom> i tried bzr push but it threw an error at me
<jelmer> foom: try "bzr svn-push"
<rcohen> one of the big problems is that there are conflicting use cases for copy
<jelmer> foom: I haven't gotten round into implementing it in "bzr push" yet
<foom> aha, thanks. :)
<rcohen> i could make you even more afraid if you wanted to support a separate "split" command :)
<dacresni> thats like telling telling a species with no eyes that something is red
<jelmer> rcohen: I was about to suggest that :-)
<jelmer> rcohen: Actually, we already have a split command, but it splits trees, not files
<dacresni> thats only a little inefficient
<rcohen> jelmer: let's take an easy case for split, the top and bottom halves of a file each go their own way
<abentley> beuno: The error message we have is Could not install revisions: sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2
<rcohen> jelmer: what happens if in another branch someone adds content at the place where the file was split?
<rcohen> jelmer: it gets worse if there are conflicts at the split point
<abentley> beuno: I realize you've already seen something like that.
<jelmer> rcohen: Representing that conflict in the file(s) would be the tricky bit.
<rcohen> jelmer: it's not so much the problems with the merge algorithm and the UI
<Debolaz> jelmer: I've had to extend git-svn for the same reason. It makes the ideological but foolish assumption that the subversion users know what they're doing. :)
<rcohen> s/and the UI/as the UI/
<jelmer> rcohen: Perhaps create conflicts in both files, adding a conflict in both cases and a comment?
<jelmer> rcohen: I see your point though
<rcohen> jelmer: also remember that was the easy case :) files can be split in other bizarre ways which may not be detected properly or are partial copies, etc etc
<jelmer> Aaron has also explained some other issues potential issues with merges after copy earlier
<jelmer> Even without merge, I think copy could be still be quite useful though
<jelmer> for "bzr log" and "bzr annotate"
 * fullermd seconds.
<jelmer> and just for roundtripping
<rcohen> so just an annotation in the history which says "this file was copied from that file"?
<rcohen> but not actually used for anything
<jelmer> rcohen: Well, only when looking at the history of a file
<jelmer> rcohen: Do you know whether Subversion supports merges across copies?
<rcohen> not offhand, though i doubt it
<abentley> rcohen: A day after you expressed reservations about LCA not doing resolution against the base initially, a user found the problem with that; it doesn't emit conflicts when one side deletes a line, but the other changes it.
<abentley> rcohen: But in my defense, knit gets that wrong too.
<rcohen> abentley: ah, knit can be made to do that correctly :)
<rcohen> there's a subtle difference in how cdv and bzr implement the algorithm
<rcohen> in cdv, the annotations are on the space between the lines, which catches deletes
<abentley> rcohen: Yeah, I know.
<abentley> But even if you're even if you're versioning the lines, suitable historical info will let you catch that case.  I'm pretty sure weave handled it, and I believe I can extend LCA to handle it, too.
<rcohen> yes, weave should handle it
<rcohen> if you are going to add annotation information to the pack format in the future, that may be worth keeping in mind
<abentley> rcohen: Do you know offhand whether annotation of the lines can be cheaply transformed into annotation of the edges?
<rcohen> i understand that there are practical tradeoffs to be made, you obviously don't want to show the between-line versioning to users when they use the "blame" command so it would be extra info
<rcohen> i don't think so
<rcohen> i haven't really looked into it, it may be possible to store a small set of differences and otherwise make it automatic
<rcohen> abentley: if you have a fast way of determining whether i change came after another, then i think only the deletes would get lost
<abentley> Pity deletes are the reason we're interested in edge annotation :-)
<rcohen> yeah :) but storing the standard annotation plus a little extra deletion info might work
<abentley> Anyhow, I'm interested in edge-base merging generally because I believe it can do moves within files, and between files.
<rcohen> there be dragons
<rcohen> i'm currently more interested in improving the UI for conflicts
<rcohen> there are some conflicts which are difficult for users to resolve
<rcohen> for instance, someone deletes a big section of code, someone else makes a 1 line change to it
<fullermd> That one bits me with some regularity   :|
<rcohen> the poor merging user is left to stare at these 2 huge blocks of code and figure out what's different and why
<dacresni> how does git handle it?
<dacresni> i mean, thats what comments are for
<dacresni> to tell why
<dacresni> in both revision comments and inline comments to the code
<abentley> rcohen: Oh, I certainly have bigger fish to fry than that.
<fullermd> Comments don't help when I'm staring at 1 line of code, and 80 lines of code, where I took that one line from the 70-some that were on the other side last time, and have no idea which were added.
<rcohen> abentley: i've come to consider UI a big fish
<abentley> That is, I don't plan on implementing edge merging soon.
<abentley> I agree that UI is more important.
<abentley> You get quickly diminishing returns with merge algorithms.
<rcohen> now, if your merge algorithm has annotation information, it should be possible to call out the 1 line which caused the conflict for the user
<dacresni> it sounds like you can't tell when either line was added or subtracted or which
<rcohen> abentley: absolutely agreed on diminishing returns, fun as it is to work on merge algorithms
<rcohen> i've got another crazy idea about doing per-conflict virtual common ancestors
<rcohen> i came up with it in the context of weaves, but it may be possible to fit it into other merge algorithms
<brink_> Is there a way that version-info could somehow be inserted into my code automatically?
<brink_> A revision number would be fine.
<cliechti> i have a low power/low resources hardware where a wiki like moinmoin uses too much memory. so i thought i could use a bazar repository there, with a working copy on the server. i'd then run docutils over that copy to generate my HTMLs. so, is there an easy way to run update and a script when i push my local repo to the server.
<cliechti> i could write a plugin, but is there a hook that is executed on the server when i do a push?
<dato> cliechti: maybe you'd like to take a look at http://ikiwiki.info, a static wiki "compiler". it's recently gained (or is about to gain) bzr support.
<cliechti> dato: ok, that's the direction i'm thinking of, but it seems that ikiwiki is using perl, so it is the wrong language with P for me ;-) and i'm having my nice ascii art to svg plugin in docutils :-)
<dato> cliechti: I'm completely a python person myself, but am quite happily using ikiwiki for my personal site. ymmv.
<beuno> abentley, did you find out anything about that broken branch (FYI, it's not really mine, I was just helping out and got curious)
<abentley> Kinda.  I'm on a call right now.
 * synic perks
<beuno> abentley, no hurries
<igc> morning
<Rolly> Hi all. I keep getting an AttributeError: 'module' object has no attribute 'ssl' error when I try to branch any https:// url. Here's the bzr output: http://p.caboo.se/private/x2dbvkbelnrngdsscb9s1w
<Rolly> does anyone have a clue? I have googled to no avail
<beuno> Rolly, seems you're missing a dependency
<Rolly> you think it's a python problem, or a bzr problem?
<Rolly> I am clueless when it comes to python, I'm afraid
<beuno> Rolly, neither, you're probably missing some package
<beuno> let me check
<Rolly> thanks :)
<mwh> looks like your python doesn't have ssl support
<mwh> which is a little strange
<mwh> Rolly: what os are you on?
<Rolly> yeah, I just saw this: http://paltman.com/2007/11/15/getting-ssl-support-in-python-251/
<Rolly> I'm on a debian etch box
<Rolly> w/ python2.4 installed from apt
<mwh> maybe you need to install python-ssl or something
<beuno> yeap, svn2bzr doesn't seem to require any special dependencies
<mwh> _however_
<mwh> in this case just branch from http://bazaar.launchpad.net/~niemeyer/svn2bzr/trunk
<Rolly> cheers, I didn't think of that
<mwh> that's what the url you were trying to access would have redirected you to
<Rolly> installing the ssl 1.13 python package didn't work
<Rolly> I would try to install python 2.5 from source, and use that. But I'm afraid to bork anything on this box that depends on python 2.4 :p
<mwh> there's not usually much reason to install things from source on debian...
<mtaylor> Rolly: install python2.5 packages?
<Rolly> mtaylor: I did, but the system python (`which python`) remains my old 2.4
<Rolly> mwh: probably, but I'm mystified by the package system. For example, how would I go about reconfiguring my existing python 2.4 install? I have no idea
<Rolly> mwh: actually, http://bazaar.launchpad.net/ redirects to https://bazaar.launchpad.net/
<Rolly> :(
<cliechti> mwhudson: do you have something to do with lag.net (loggerhead homepage)? the last two development link at the bottom of the page do not work properly
<mwhudson> no
<rolly> cool, I fixed my problem with just "apt-get --reinstall install python2.4"
<rolly> :)
<rolly> Hmm, there's a problem with svn2bzr. I have to comment out "import bz2", because that's part of Python now. But then bzr crashes with global name 'bz2' is not defined in lines like this: self._tree_cache[str(revno)] = bz2.compress(marshal.dumps(tree, 2)).
<mtaylor> rolly: why do you need to comment out import bz2?
<rolly> because if I don't, I get ImportError: No module named bz2
<mtaylor> rolly: that's because you don't have it then...
<rolly> I think I read somewhere that bz2 is part of python
<mtaylor> it is
<bob2> that would be because it is NOT part of python :)
<mtaylor> but you still need to import it
<mtaylor> to use it
<rolly> Ah ok
<mtaylor> mtaylor@solace:~$ python2.4
<mtaylor> Python 2.4.4 (#2, Jan  3 2008, 14:46:35)
<mtaylor> [GCC 4.2.3 20071223 (prerelease) (Ubuntu 4.2.2-4ubuntu3)] on linux2
<mtaylor> Type "help", "copyright", "credits" or "license" for more information.
<mtaylor> >>> import bz2
<mtaylor> >>> bz2.__file__
<mtaylor> '/usr/lib/python2.4/lib-dynload/bz2.so'
<mtaylor> but that file is in the python2.4 package
<mtaylor> what python is your bzr trying to use?
<rolly> 2.4.1
<mtaylor> head -1 `which bzr`
<rolly> #!/usr/local/bin/python
<mtaylor> ah. installing python from source are we?
<rolly> that's 2.4.1
<mtaylor> ok, so that python install doesn't seem to have bz2
<mtaylor> is your bzr also in /usr/local/bin - like, you build/installed it from source?
<rolly> hmm... that is obviously not the python I just reinstalled via APT. That was 2.4.4 I'm sure
<mtaylor> right
<rolly> I did build bzr from source
<mtaylor> that would be in /usr/bin/python
<mtaylor> ok.
<mtaylor> so that means it's also in /usr/local/bin/bzr, right?
<rolly> correct
<mtaylor> any particular reason for installing from source? or that's just the way you did it?
<mtaylor> rolly: you're running debian testing, right?
<rolly> and also correct that /usr/bin/python can import bz2
<rolly> :|
<rolly> mtaylor: I don't think so. How do I check?
<mtaylor> cat /etc/debian_version
<rolly> 4.0
<mtaylor> apt-cache show bzr | grep Version
#bzr 2008-02-01
<rolly> Version: 1.1~rc1-1
<rolly> Python-Version: 2.4, 2.5
<rolly> Version: 0.11-1.1
<rolly> Python-Version: >= 2.4
<mtaylor> just do apt-get install bzr
<mtaylor> that'll get you the latest and greatest bzr
<rolly> Gotcha. that will use the correct python right?
<mtaylor> well, yes
<mtaylor> but your _path_ will still use /usr/local/bin/bzr
<mtaylor> so I'd get rid of that
<mtaylor> just delete it
<rolly> will do
<mtaylor> you might want to kill your /usr/local/bin/python* too
<rolly> That sounds risky
<bob2> did you specifically want a non-Debian python installed, or were you just trying to get bzr working?
<rolly> That old python was installed on the system by a previous BOFH
<bob2> ah
<mtaylor> oh. well in that case just leave it
<mtaylor> but know that whenever you just run python, it's going to pick that one up first
<mtaylor> which is almost never going to be what you want
<mtaylor> so you might want to alter your path to not use /usr/local or something
<mtaylor> or just be explicit
<bob2> and it will probably break other Debian python software
<rolly> jesus chr*st
<bob2> (e.g. anything else that uses the "bz2" module :)
<mtaylor> rolly: I'd also send a death gram to the previous BOFH :)
<rolly> hehe, it's horrible. It's like he encrusted python into this system
<rolly> I just replaced /usr/local/bin/python with a symbolic link to the right one, and I'll start keeping a tally of broken python programs :p
<rolly> hooray, svn2bzr works now
<mtaylor> YAY
<rolly> \o/
<rolly> So yesterday I asked a question about creating non-propagating revisions, but I framed it poorly. Now I found a diagram that explains exactly what I'd like to do in bzr ---> http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository
<rolly> see operation 'b' in that diagram? "Marking r7@branches/a to be blocked. From this point on forward, this change set shall not propagate anywhere."
<rolly> Can that be done in bzr?
<LeoNerd> I'd like a "telepathy" option to 'bzr blame'.. It's good at telling me what change I made six months ago, but unfortunately it fails to explain the logic of my reasoning on why I thought it was a good idea
<rolly> hah :)
<LeoNerd> I wrote about the fact that two methods have to be called in a particular order, only I can't now see why... they look independent...
<beuno> poolie, lifeless, I'm working on the automatic plugin suggestion bit, and I have a conceptual question I can't seem to resolve on my own
<beuno> (basically, ping :p)
<Odd_Bloke> When using bzr-svn, how do I authenticate when pushing to an https:// URL (Sourceforge, in this case)?
<jelmer> Odd_Bloke: See the bzr-svn FAQ
<Odd_Bloke> jelmer: Oh yeah.  I scanned the page but somehow managed to completely miss that entry. /o\
<Odd_Bloke> jelmer: Thanks. :)
<cliechti> are hooks executed on the server side when i do a push using ssh+bzr?
<lifeless> man jetlag kills
<lifeless> poolie: want a call ?
<lifeless> beuno: pong
<beuno> lifeless, I'm going to have an XML file with all available plugins bundled with bzr so users don't need internet connection to use the command-not-found bit. What I'm not really sure is where to locate it within the bzr directory structure so it's accesible even if you run bzr from source
<lifeless> beuno: I don't understand why you need that file
<lifeless> beuno: we know what commands the user /has/
<lifeless> beuno: everything else is unknown.
<jelmer> cliechti: afaik they're all client side at this point
<beuno> lifeless, not for the new spec. You wouldn't know what commands uninstalled plugins provide, so I'm going bundle an XML file with that information (which will be available to update later on on user request)
<lifeless> beuno: in my head there are three states for a command: found locally, not found locally, not found locally and found in a directory service
<lifeless> beuno: I don't like the idea of a static file in bzr itself; it _will_ bitrot.
<cliechti> jelmer: yeah it looked like that. the push+update plugin also does a separate ssh connection. and a rss generator plugin sneaks in the rss file into the .bzr folder of the server, but no code execution there
<beuno> lifeless, so how do you suggest I handle this?   Make bzr download an updated XML file the first time the user hits a not-found command?   doesn't seem sensible to me  :D
<cliechti> ET software? that phones home? ;-)
<beuno> I would like to ship with bzr a list of official plugins that can be suggested
<beuno> so I believe this would be a new state for a command
<jelmer> beuno: Couldn't this rather be in a separate plugin, just like is done for the bash/zsh scripts?
<jelmer> beuno: E.g. just make core bzr provide a "Command not found" hook
<beuno> jelmer, yes and no. It can if it's not going to be part of the core. If these bits _are_ going to be in the core, then I have to have a DB already available
<beuno> as lifeless suggests in: https://lists.ubuntu.com/archives/bazaar/2008q1/037066.html
<beuno> a big part will be in the core
<lifeless> jelmer: I think the core mechanism of this should in the core, so that it gets loved as much as possible
<lifeless> beuno: I'm entirely happy with having the directory services be plugins
<jelmer> lifeless: I have no problem with the add-plugin, list-plugins, etc commands as part of core
<lifeless> beuno: in fact, perhaps the plugin for installing plugins in a particular manner also is the directory service for that manner
<lifeless> beuno: e.g. you want to write a 'checkout to install' style plugin - cool. That plugin can use a xml file if you want.
<jelmer> lifeless: however, I would really like to see the plugin that provides access to the "trusted repository" as a plugin (no objection if it's shippedinthe standard tarball)
<lifeless> I want to write/see a plugin that installs from debs
<mtaylor> ^^++
<lifeless> so it needs at minimum a mapping from plugin name to deb
<lifeless> and adding a mapping of command to plugin at the same spot seems reasonable at first glance
<lifeless> jelmer: I agree thats what I am saying - the mechanism to install things should be plugins, the UI and core logic should not
<jelmer> lifeless: Ok, then we're on the same line.
<jelmer> Thanks :-)
 * beuno thinks
<lifeless> I see a plugin for finding and installing to ~/.bazaar/plugins/, a plugin for installing via debs, a plugin for installing via easy_install, a plugin for installing via rpm's, and one for whatever gentoo call their packages
<lifeless> beuno: the directory service is a dynamic thing
<lifeless> beuno: in fact, one interesting case is 'command not found' -> 'new bzr supplies it'
<beuno> lifeless, ah, yes, that's interesting to provide too
<beuno> which would require bzr to download on some sort of regular basis the updated DB
<beuno> I'm a bit confused on having the code for checking if a plugin is available for a command in the core, but having the actualy db as a plugin
<beuno> although it does make sense in some level
<beuno> I was thinking of shipping a db file with bzr, and then just update to the users ~/.bazaar dir
<beuno> make the plugin first check in the ~/.bazaar dir, and if not, fall back into the a default location
<beuno> one think going around in my head was to serialize the db to a file so it can be accesed faster than parsing XML each time
<beuno> s/think/thing
<jelmer> lifeless: I wonder if we could do that with tracebacks..
<jelmer> lifeless: "The bug you just hit has been fixed in a newer version of bzr"
<lifeless> beuno: in the core it will be something like: for provider in providers: try: plugin_name = provider.command_name_to_plugin_name(); except LookupError: continue; raise InstallableCommand(provider, plugin_name)
<lifeless> jelmer: cute
<lifeless> beuno: I would expect the debian packaging to make sure that only the install_via_deb provider is present
<beuno> lifeless, so the db of plugins will be provided by each provider (with checkout plugin installed by default in bzr)
<lifeless> approximately
<lifeless> we'll also want branch/repo/tree formats to be supplied
<lifeless> and others
<lifeless> eventually
<lifeless> wouldn't it be nice if rather than 'unknown format ... needs 1.4' you got 'unknown format ... needs 1.4' Lookup support for this [Y/n]
<beuno> heh, yes
<lifeless> hit Y, and get 'upgrade bzr to the current release 1.6 which supports this'
<lifeless> but lets stay focused
<lifeless> missing commands
<beuno> I suddenly have 100x times more things in my head than before (which wasn't little)
<beuno> ok
<beuno> well, I just have one concern
<beuno> which is more of short-term problem
<beuno> I'd like to implement this in stages
<AfC> "This bug has been fixed in a newer version of $software, so go upgrade already" would be awesome :)
<beuno> first stage would just tell the user the command is available in a plugin, and the URL where it's located
<lifeless> beuno: I think thats a second or third stage
<beuno> second stage, installing it with the checkout plugin
<beuno> lifeless, ok. What's the first stage then??
<lifeless> beuno: first stage is to my mind the bzrlib core being done, with no providers present
<beuno> lifeless, so it would check for providers, and not find any  (useless to the actual users)
<lifeless> beuno: which means UI and appropriate lookup facilities, the add-plugin or whatever its called command being present, remove-plugin likewise
<lifeless> beuno: this is important as it is a likely common corner case (some folk will not want this facility)
<lifeless> then second stage is write a plugin which can identity other plugins
<lifeless> it can on add-plugin 'foo' print out 'the home page for foo is XXX, please follow the README/INSTALL instructions there'
<lifeless> and you can refine the plugin further from there
<lifeless> but at the same time jelmer/james/dato can be writing a deb based version of the same thing
<lifeless> my point is that bzr itself probably never needs to know 'the url homepage' or anything like that
<lifeless> all be needs to know is 'plugin X is supplied by provider Y for the problem of 'missing command Z''
<beuno> lifeless, so each provider will have it's own db of available plugins?
<SmileyChris> if I "python setup.py install" the newest version of bzr-svn, do I have to go and manually remove the old egg or will bzr find and use the newest one?
<lifeless> beuno: surely that has to be the arrangement, not all plugins are available to .debs at the moment, and someone may package an older/newer version of a plugin with different commands than the one in e.g. rpms
<lifeless> SmileyChris: I really don't understand eggs, they seem to do very strange things.
<lifeless> SmileyChris: its why I don't use them, and just put plugins in ~/.bazaar/plugins - e.g. ~/.bazaar/plugins/svn
<beuno> lifeless, ok. And we would ship the checkout (native) plugin by default, so we would already have a DB available. And, when another provider is installed as a plugin, it should somehow specify "check me first", so we can fall back to checkouts if it's not provided as a .deb  (which is very likely to happen often)
<beuno> if that's the case, my only concern would be how each plugin would keep it's DB updated
<lifeless> beuno: thats up to the plugin surely
<lifeless> the easiest way to make tricky decisions is to get someone else to make them
<beuno> lifeless, ok, you got me  :p
<beuno> alright, that works for me
<lifeless> (I'm not entirely sure we would ship any plugin by default). But we certainly could have a 'bundle' release for non-distro users that adds e.g. bzrtools and checkout-plugin and whatnot
<beuno> I can have all the core bits in there
<lifeless> (any plugin that does this I mean)
<beuno> lifeless, if we don't ship the plugin by default, most users will miss out on the command-not-found bit
<beuno> ("most users" is a wild un-educated guess)
<beuno> I'm thinking what gets shipped in the standard bzr tarball
<beuno> which is what propagates to the distros and all those weird places
<beuno> so all the code will be in place, but no db of known plugins will be available
<beuno> lifeless, I'm off to get some dinner, but I'll be back in a short while to keep on working on this
<ubotu> New bug: #187916 in bzr "bzr crashed on 'bzr branch'" [Undecided,New] https://launchpad.net/bugs/187916
<lifeless> beuno: yet, on a debian system you don't want user-installed plugins, you want deb installed plugins with dependencies
<poolie> lifeless, though, that might be strange if bzr itself was installed from source
<poolie> i would say it should match the method used for the current bzr process
<poolie> probably
<abentley> I have to say I'm a bit dismayed by the whole idea.
<abentley> Haven't we got enough package tools already?
<poolie> well, i think just suggesting the right thing would be a good start
<abentley> Yeah, that seems okay.
<abentley> Actually installing the plugins via various package systems seems like it could cause a lot of confusion.
<abentley> Especially if platforms like Ubuntu support 3 install methods.
<abentley> And while I love using apt or synaptic, there are tons of plugins that aren't packaged.
<poolie> right
<poolie> ideally, we'd automatically package all of them, but that would take some time
<beuno> back
<beuno> lifeless, I'm thinking most plugins don't/won't have dependencies, so the per-distro installing will be more of an exception than a rule
<beuno> I'd actually prefer to focus this as a feature of the core, recommending plugins by default in any type of installation, with checkouts being the default way of installing them
<beuno> and have the per-distro installations be a "maybe in the future someway" sort of thing
<beuno> this way we guarantee it works in all platforms
<beuno> and we have control over the end-result
<beuno> making optional plugins necessary to make all this work will end up missing most of the targeted users:  the ones that don't want to install them manually
<abentley> poolie: And then there's my hax plugin, which isn't even spelled right ... ;-)
<beuno> and also depend heavily on per-distro setups
<beuno> so, I need to solve this before I continue hacking on it. How/where/when to place the available plugins DB
<ubotu> New bug: #162368 in bzr-svn "bzr branch fails with foreign filenames" [Medium,Fix committed] https://launchpad.net/bugs/162368
<ubotu> New bug: #174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,Fix released] https://launchpad.net/bugs/174947
 * beuno goes on and works on it as a plugin with minimal code in the core, and prepares himself for future refactoring
<ubotu> New bug: #181790 in bzr-svn "NoSuchId traceback when branching a svn repository" [Medium,Fix released] https://launchpad.net/bugs/181790
<ubotu> New bug: #183853 in bzr-svn "bzr status crash w/ svn checkout" [Medium,Fix committed] https://launchpad.net/bugs/183853
<rolly> bzr is a delight to work with, after months of fighting svk
<ubotu> New bug: #183361 in bzr-svn "bzr-svn on a branches not working" [Medium,Triaged] https://launchpad.net/bugs/183361
<jelmer> argh, jaj for mass bug changes in the middle of the night
<jelmer> I just accidently changed 10 bzr-svn bugs to be against bzr
<jelmer> sorry
<lifeless> jelmer: you know you can just change the product back
<lifeless> jelmer: you don't have to mark it as invalid in bzr
<jelmer> lifeless: what's the command for that?
<jelmer> lifeless: I added a product by accident
<lifeless> oh
<jelmer> lifeless: in this case
<lifeless> I'm not aware of a 'remove this reference' thing; there should be though :)
<lifeless> BjornT: ^
<jelmer> I usually just mark as invalid
<lifeless> which is basically noise ;)
<jelmer> yeah
<lifeless> I mean, its equally invalid on all products:)
<jelmer> that memory bug in python-subversion was at some point reported to exist in 10 products
<keithy_> beginner seeking help
<lifeless> hi keithy_
<keithy_> I started a local repo using cd dev; bzr init
<lifeless> I'm just cooking lunch, but ask the questions and someone will answer you sortly :)
<keithy_> then on a remove mc I try
<keithy_> then on a remote mc I try bzr checkout --lightweight ssh://keith@squeak.warwick.st/dev
<jelmer> igc: is there some way with usertest to benchmark different bzr storage formats?
<keithy_> and I get "not a branch"
<jelmer> keithy_: try bzr+ssh rather than ssh
<keithy_> ?
<jelmer> bzr+ssh://keith@squeak.warwick.st/dev
<jelmer> as a url
<keithy_> oh oops I did
<keithy_> then on a remote mc I try bzr checkout --lightweight sftp://keith@squeak.warwick.st/dev
<jelmer> keithy_: and /dev is actually a repository on that host??
<keithy_> its my working dir
<igc> jelmer: yes ...
<keithy_> and I did bzr init in it
<igc> jelmer: let me think how best to do that
<jelmer> keithy_: You have to specify the path to your homedir as well
<lifeless> igc: we were benchmarking packs vs knits in the past
<keithy_> which home dir?
<lifeless> igc: that approach worked well
<lifeless> keithy_: the path after the hostname is an absolute path
<keithy_> yes
<igc> lifeless: yes, though that was 2 different branches
<lifeless> keithy_: e.g. sftp://keith@squid.warwick.st/home/keith/dev  ?
<keithy_> ah
<jelmer> keithy_: you are versioning the special files in /dev ?
<lifeless> igc: so create two branches of .dev? :)
<igc> jelmer: I'd add a user parameter holding options to init-repo in InitialImportTask
<keithy_> why an absolute path?
<lifeless> keithy_: so that you can refer to e.g. /srv/ and /var - where people often have repositories
<keithy_> ic
<lifeless> keithy_: on sftp you can use /~/ to get into your home dir, that is not implemented for bzr+ssh yes.
<lifeless> s/yes/yet/
<jelmer> igc: ah, ok
<jelmer> I'll give that a try some time, thanks!
<igc> then I'd pass in the file format using the --config-file options
 * jelmer is interested in testing the performance of various bzr-svn versions
<igc> jelmer: that's how I test various networking protocols
<igc> and it works well
<keithy_> great its working
<keithy_> ok next question
<keithy_> I have a directory of files
<keithy_> and I want a commit to always include all of the files in that directory
<keithy_> without having to manually add them, they may change frequently
<igc> jelmer: my wrapper script for testing networking scenarios - http://rafb.net/p/prTgqd10.html
<lifeless> keithy_: we don't have a facility for that yet; we have an open bug to have a --automatic flag to commit to automatically add and delete files
<keithy_> a flag on commit will not doit
<keithy_> I want to version the files of an oodb
<keithy_> but they change
<lifeless> keithy_: well with that flag you could add an alias of commit to commit --automatic ;)
<keithy_> I dont want to automatic everything
<keithy_> just that one dir
<lifeless> ok
<lifeless> well its doable via a plugin but there is no canned feature for this
<keithy_> I thought that bzr add blah/
<keithy_> should do it
<lifeless> bzr add blah/ adds the current content
<lifeless> it does not trigger an automatic add on every operations
<keithy_> as I found out
<keithy_> k next question
<keithy_> having checkedout whats the easiest way to push changes back
<lifeless> well checkouts work like svn/cvs
<lifeless> so when you commit they are recorded in the place you checked out
<lifeless> you need to push and pull when you've made a new branch (using bzr branch)
<keithy_> ah so the master is the origina
<keithy_> I dont understand branch yet
<keithy_> so...
<keithy_> I have  dev as the repo on one mc
<keithy_> and I check out to a second
<lifeless> you're in the squeak world obviously :)
<lifeless> perhaps an analogu will help
<keithy_> then any commits on the second are sent to the dev mc
<keithy_> I develop in squeak, and version my images in bzr
<lifeless> a squeak image is a bit like a branch: you can change it (by journalling your actions)
<keithy_> then I use the checkout to deploy to the webserver
<lifeless> you can take a copy of it to get an identical image
<lifeless> and that can then change further; or you can take your journalled actions from your first image and apply them to the second to end up with an updated and now identical image
<lifeless> so if you are using a checkout to deploy, your deploy process will be to run 'bzr update'
<keithy_> on the server
<lifeless> yes
<lifeless> because you need the working files update
<lifeless> *updated*
<keithy_> and if I fix a bug on the server and want to send the result back upstream
<keithy_> thats a straight commit?
<abentley> beuno: Still around?
<lifeless> well, by using a checkout you don't really have upstream/downstream - so yes, just commit
<keithy_> wow thats great
<keithy_> better than mercurial
<keithy_> -)
<lifeless> :-)
<lifeless> you can work the same as you would in mercurial, in fully distributed mode. But we found that there are things where distributed does /not/ make sense.
<keithy_> a leightweight remote working dir
<lifeless> so we made it a choice for the user
<keithy_> right so I can scrap using unison as well
<keithy_> cool!
<beuno> abentley, yeap
<rolly> silly question: there's no authentication possible with the smart server, right?
<beuno> playing around with registrys
<lifeless> rolly: the smart server itself does not do authentication
<lifeless> rolly: we let apache or ssh do that
<abentley> beuno: My best theory is that this branch was recently upgraded to packs, but never reconciled.
<lifeless> abentley: errors on push/pull ?
<abentley> Yes.
<lifeless> sftp/smart server/local  ?
<rolly> lifeless: gotcha, but how do I NOT serve via HTTP?
<lifeless> rolly: sorry I don't understand your question
<beuno> abentley, ah, yes, was my guess too. No way of fixing it though, right?
<lifeless> beuno: sftp/smart server/local ?
<rolly> I would like my smart server to be accessible via ssh, but not via http
<lifeless> rolly: so just don't make the directory visible over http :)
<rolly> Oh, I'm not using apache
<lifeless> rolly: or don't configure up the smart server on http. it takes explicit actions to make it visible over http
<abentley> beuno: Do you have write access to it?
<rolly> But "bzr serve" starts a listening port
<beuno> abentley, no, I don't.  synic, still around?
<lifeless> rolly: yes, thats on the bzr:// port though. If you want it working over ssh you don't have to do anything special at all
<lifeless> rolly: just install bzr on the server and you're done
<beuno> lifeless, pushed to launchpad. It really doesn't have much to do with me as I'm just trying to help out someone. Don't really know how/what went on.
<abentley> Anyhow, you can run bzr reconcile on it now.
<abentley> Or synic can, or whatever.
<lifeless> beuno: they should bzr reconcile it remotely
<keithy_> after I did my checkout, can I rename the directory?
<lifeless> keithy_: sure
<keithy_> and I could move it?
<rolly> lifeless: argh, sorry. All that I was saying about http://, I meant bzr://. I would like to restrict access via bzr:// and only allow bzr+ssh://. Sorry
<lifeless> keithy_: yup
<abentley> The http version actually a copy, and in this case, it's a failed copy.
<keithy_> great!
<lifeless> rolly: thats trivial; don't run bzr serve :)
<rolly> Oh... duh :D
<lifeless> rolly: you have to do stuff to make bzr:// work - by default it doesn't run anywhere :)
<rolly> Had a mental roadblock there, thanks
<rolly> yeah :p
<lifeless> np
<lifeless> I don't think we explicitly say anywhere that we don't dopen stuff etc
<lifeless> beuno: they should also upgrade the branch; its at branch5, not branch6
<lifeless> beuno: I suggest they do 'bzr upgrade sftp://b.l.n/~....' and 'zr reconcile sftp://b.l.n/~/
<beuno> lifeless, they did reconcile
<beuno> didn't fix it
<beuno> abentley, aaah, ok ok, it's been tweaked then
<beuno> well, synic, ^
<lifeless> so hang on a second
<lifeless> its in pack on the public mirror of lp
<lifeless> this means a pull from the master repo worked
<lifeless> using bzr 1.0 as thats what lp is running
<beuno> lifeless, it didn't work before. abentley, did you fix anything?
<abentley> beuno: No, I don't have those kind of super cow powers.
<lifeless>  bzr branch http://bazaar.launchpad.net/~exaile-devel/exaile/main
<lifeless> Branched 0 revision(s).
<beuno> ah, so it's still borken
<beuno> lifeless, they did run reconcile on it
<beuno> and it didn't fix it
<abentley> lifeless: Exactly.
<lifeless> its got no revision history
<abentley> The http version doesn't.
<abentley> I think the quarrantine version probably does.
<lifeless> abentley: true; hmm, does lp create the branch and then pull; if so blech
 * beuno has to go
<lifeless> beuno: get them to talk to us
<beuno> lifeless, ok, synic is the man
<lifeless> beuno: if they ran reconcile locally it won't fix the remote one
<lifeless> synic: ping
<beuno> lifeless, he did run it remotely
<lifeless> beuno: so we need to be really quite sure of whats going on
<lifeless> beuno: also, there should be an error in the lp web page if it was faulting
<synic> lifeless: it was remotely
<abentley> lifeless: does reconcile work over bzr+ssh?
<beuno> lifeless, agreed. synic, lifeless is your man
<synic> k
<lifeless> abentley: it should I think, but for surety I'd try sftp
<lifeless> synic: can I talk you though some python ?
<synic> yeah - I'm running reconcile remotely again... should I stop it?
 * abentley has no idea how the branch puller works.
<lifeless> synic: nah, let it finish
<synic> alright.
<lifeless> synic: we can do this in another window
<synic> ok, I've got one open
<lifeless> thumper: ping; errors on code.* branches - does everyone see them? (please say yes)
<lifeless> $ python
<lifeless> >>> from bzrlib.branch import Branch
<lifeless> >>> b = Branch.open('sftp://<your branch url here')
<lifeless> >>> b.lock_read()
<lifeless> >>> print b._format
<lifeless> paste the output of the last line
<synic> Bazaar-NG branch format 5
<thumper> lifeless: what's up?
<lifeless> >>> b.last_revision()
<synic> sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2
<lifeless> thumper: https://code.edge.launchpad.net/~exaile-devel/exaile/main shows no error in mirroring, but the mirrored branch has no revision history
<abentley> lifeless: Essentially yes, it does a branch followed by a pull.
<thumper> lifeless: right, this is the branch I talked to abentley about this morning
<thumper> bzr info on the remote branch raises an error
<lifeless> thumper: so I'm asking if the reason we don't see errors could be UI madness rather than 'no error occuring'
<thumper> lifeless: I confirm ui madness
<thumper> will fix on edge soonish
<abentley> Who's saying we don't see errors?  I posted an OOPS to you!
<thumper> abentley: the UI is not showing the error text
<abentley> True.
<thumper> that madness
<lifeless> abentley: yes the errors are available for developers; but folk like beuno that want to help don't have access there
<lifeless> abentley: so we should allow the community to share their expertese
<lifeless> synic: ok, thats good.
<lifeless> synic: whats the exact reconcile command you ran ?
<synic> bzr reconcile  bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/
<lifeless> synic: ok
<synic> it's still running
<lifeless> synic: back in python
<lifeless> >>> from bzrlib.repository import Repository
<lifeless> >>> r = Repository.open('bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/')
<lifeless> >>> r.lock_read()
<lifeless> >>> ids = r.all_revision_ids()
<lifeless> >>> len(ids)
<synic> 1628
<lifeless> >>> print r._format
<synic> <RemoteRepositoryFormat>
<lifeless> heh
<lifeless> r._ensure_real()
<lifeless> print r._real_repository._format
<synic> <RepositoryFormatKnitPack1>
<lifeless> ok
<synic> reconcile done.
<lifeless> cool
<lifeless> exit that python shell
<synic> alright
<lifeless> now
<lifeless> cd /tmp
<lifeless> bzr branch sftp://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/ tmp-main
<lifeless> oh, and separately, 'bzr upgrade sftp://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/'
<lifeless> (your branch object is still branch5, not branch6
<synic> bzr: ERROR: Could not install revisions:
<synic> sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2
<lifeless> can you pastebin the full backtrace from your ~/.bzr.log
<lifeless> synic: do you have a local copy of this that is working well ?
<synic> yes
<synic> http://rafb.net/p/2UgHVp51.html
<abentley> lifeless: I thought you were saying there was no indication of errors.  I think everyone agrees that having the error details would be handy.  It's even awkward for me to get those error details, much less community people.
<lifeless> abentley: thats cool; we're on the same page now
<lifeless> synic: oh, what version of bzr are you using ?
<synic> 1.1
<synic> just upgraded today.
<lifeless> ok, heres what I think is happening
<lifeless> the branch history includes a revision id not in the repository
<lifeless> we can test this
<lifeless> python
<lifeless> >>> from bzrlib.repository import Repository
<lifeless> >>> r = Repository.open('sftp://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/')
<lifeless> >>> r.lock_read()
<lifeless> >>> r.has_revision('sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2')
<abentley> lifeless: cat-revision FTW
<synic> False
<lifeless> abentley: I have the internal api branded on the inside of my skull
<lifeless> synic: ok, this hypothesis is proved :)
<synic> nice
<abentley> Do we know the revision's in the history, not just the ancestry?
<lifeless> abentley: given the error its the branch tip
<abentley> That's curious.
<lifeless> abentley: its raised from missing_revision_ids(ID)
<lifeless> synic: but lets dig a little further
<lifeless> >>> from bzrlib.branch import Branch
<lifeless> >>> b = Branch.open('sftp://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/')
<lifeless> >>> b.last_revision_id()
<synic> AttributeError: 'BzrBranch5' object has no attribute 'last_revision_id'
<abentley> lifeless: bzr revision-history FTW
<lifeless> abentley: shrug
<lifeless> synic: sorry, drop the _id()
<lifeless> abentley: I find it easier when passwords etc are involved to be using a stateful instance
<synic> sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2
<lifeless> right, the tip revision id is not in the repository
<lifeless> synic: can you bzr push your good local copy to the remote repository please
<synic> well, it's not completely up to date
<lifeless> synic: your local one ?
<synic> probably a few revisions behind.  He pushed a couple yesterday and the day before
<lifeless> synic: this should fix itself if he pushes now
<synic> hehe, if only he'd sign on.
<synic> but ok, I can wait
<synic> ... wait, so I can push now anyway, and at least the repo will be usable, and then if he pushes, it'll be up to date
<synic> ?
<lifeless> yes
<synic> ok, cool
<lifeless> as long as you have sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2 in your branch and repository
<lifeless> you can check that the same way ;)
<synic> hrmm, yeah, it says the branches have diverged, and to merge
<synic> at which point I get the same error
<lifeless> right
<lifeless> you don't have the tip
<synic> ok, so plan is:  just wait for him to push again
<lifeless> are you sasongko ?
<synic> no.
<lifeless> are you are <arolsen@gmail.com> ?
<synic> yeah
<lifeless> you know, you guys probably want heavyweight checkouts for this shared branch
<lifeless> it will avoid commits like  1518. By  Adam Olsen <arolsen@gmail.com>   on 2008-01-03
<lifeless>     merging
<synic> ok, that's what we'll do from now on
<synic> thank you very much for your help
<lifeless> np
<synic> oh, how do we avoid this in the future?
<synic> was it an upgrade or something?
<abentley> synic: Bazaar is designed not to cause this kind of problem in the first place.  I'd really like to hear what happened.
<abentley> Your problem was basically that the branch was updated to point to a revision that wasn't in the repository.
<abentley> But we always put the data in the repository first.
<abentley> And we update the branch after that.
<synic> hrmm, well I'll talk to Johannes when I can get ahold of him, and if he noticed anything strange happened, I'll let you guys know
<synic> he's usually on every day, I'm not sure where he is today.
<abentley> Ask him if he uses rsync.
<abentley> And have you guys upgraded recently?
<lifeless> abentley: can't use rsync against lp :)
<abentley> Well, that's good.
<abentley> I suppose it's possible he ran a copy locally or something.
<abentley> I'm just trying to think of a likely operation that would update the branch before the repo.
<lifeless> yah
<lifeless> poolie: So pulling that 100 mainline revisions
<lifeless> poolie: we have a cache hit rate of 22%
<poolie> (here)
<lifeless> I'm going to chase a few thoughts down, see if I can increase that
<lifeless> and 5 round trips
<lifeless> conceptually, if I get that up to say 70 or 80 %
<lifeless> and bzip2 the content
<lifeless> it should get down to 2 rt at most
<lifeless> neat, my register-branch fix has landed
<Peng> Can you do random sftp stuff to Launchpad?
<igc> have a good weekend all
<lifeless> Peng: not really
<poolie> Peng, it's not supported
<ubotu> New bug: #187988 in bzr-webserve "Time is 38 years" [Undecided,New] https://launchpad.net/bugs/187988
<awilkins> jelmer?
<jelmer> awilkins: hi
<awilkins> jelmer: I can't seem to use bzr-svn ; it keeps saying "not a branch", even for bzr svn-branching-scheme --set <url>
<jelmer> awilkins: What URL are you trying to access and what do you have the branching scheme set to?
<awilkins> URL is svn+http://commsg1lds.npfit.nhs.uk/svn/mim/trunk
<awilkins> Branching scheme is set to nothing because it produces the error when you try to set it
<awilkins> (domain isn't accessible outside our intranet I'm afraid)
<jelmer> What error does it produce exactly when you try to set the branching scheme?
<awilkins> bzr: ERROR: Not a branch: "svn+http://commsg1lds.npfit.nhs.uk/svn/mim/trunk".
<awilkins> This is bzr-svn 0.47 (pulled from the repo).
<jelmer> You can only set the branching scheme on the repository
<jelmer> not on a branch
<awilkins> Ah, right, it's a repository level variable?
<jelmer> you probably want svn+http://commsg1lds.npfit.nhs.uk/svn/mim
<jelmer> you should be able to check out /trunk without messing with the branching scheme though
<awilkins> Same again
<awilkins> Tried the root of the repo, same error
<awilkins> Client is win32 bzr 1.1.
<awilkins> server is windows apache 2.0 SVN 1.4.3
<jelmer> awilkins: Does "bzr selftest svn" work ok?
 * awilkins sets it off
<jelmer> This may be a windows-related problem
<awilkins> Yeah, I tried mirroring a different SVN repo on my Ubuntu laptop at home and it worked fine
<awilkins> The test is just sitting there not eating CPU time.
<jelmer> doesn't give a progress indicator?
<jelmer> It can take some time to run
<awilkins> It's only printed the banner to STDOUT (got as far as C:\Python25\lib\site-packages\bzrlib (1.1.0 python2.5.1.final.0)"
<awilkins> Not responding to ^C either
<awilkins> Looking at the files it was loading, I think it got stuck somewhere in xmloutput, I'll move that folder
<awilkins> It's hitting "Unable to open an ra_local session to URL" errors now
<awilkins> [42/728 in 209s, 35 errors, 1 failed]
<awilkins> I'm guessing something isn't right :-)
<awilkins> Lots of those 180001 errors
<jelmer> awilkins: what python-subversion bindings are you using?
<jelmer> the latest from the wiki?
<awilkins> jelmer: I'm running the patched ones (installed the official ones and unpacked the patched ones over the top)
<jelmer> awilkins: It looks like the bindings you have installed didn't link against bdb?
<awilkins> THe bindings from here : http://home.comcast.net/~klight/bzr/
<jelmer> hmm, those should work ok
<awilkins> DO you use bdb repositories for the test, or just hte default>?
<jelmer> we use the default
<awilkins> The default has been FSFS for some time
<jelmer> Any chance you can upload the output of the test run somewhere?
<jelmer> I also did this with bialix a couple of days ago and thought most of the errors on Windows were fixed..
<awilkins> Does the output get logged because I didn't redirect it anywhere.
<jelmer> no, it doesn't afaik
<jelmer> you'd have to redirect it
<awilkins> It all looks like the same error
<awilkins> ERROR: bzrlib.plugins.svn.tests.test_repos.TestSubversionRepositoryWorks.test_format ('Unable to open an ra_local session to URL', 180001)
<jelmer> Without the full backtrace (printed at the end of the test run) that error isn't very useful
<awilkins> Ah, well, when it finally finibzr plguins
<awilkins> Oops
<awilkins> Would a single test run from a python interpreter be sufficient?
<awilkins> As you said, it takes some time
<awilkins> jelmer: I have that trace if you want it uploaded somewhere
<jelmer> awilkins: Yeah, that would be useful
<awilkins> http://filebin.ca/sgsgjc/svntest.zip
<jelmer> awilkins: thanks
<awilkins> It does look like a bindings problem
<awilkins> Maybe
<jelmer> ah, it's one of the test functions that's going wrong..
<jelmer> Yeah, this explains why you would get that NotBranchError
<jelmer> strangely enough bialix was able to Kevin's bindings without problems
<awilkins> Is this to do with the "short" path wrangling that's going on?
<jelmer> I don't know
<awilkins> Weird suggestion ; my user profile is not on the same drive as my PYTHON_HOME
<jelmer> I don't think that should matter
<jelmer> I'm afraid you're on your own here though, I don't have windows here atm :-/
<awilkins> I'm looking .... IDLE makes a sorry debugger next to Eclipse or Visual Studio :-(
<ubotu> New bug: #188042 in bzr "workflow improvement. bzr locked whilst uploading, can't bzr add." [Undecided,New] https://launchpad.net/bugs/188042
 * awilkins hangs himself from a noose composed of recycled fibres from printouts of the VB6 code he is debugging.
<TFKyle> who in their right mind would print code out? :P
<lixomancem> Hello. I was taking a look at Bazaar and checking its features and how it worked, but there is something I couldn't find any info on and would like to ask here. Does Bazaar have a feature like SVN's "externals"? I.e., a folder inside a branch that actually represents a branch of another repository, and that is updated from that repository when I run the update command on the whole thing? If...
<lixomancem> ...so, where can I read more about this?
<beuno> lixomancem, AFAIK, that's not available yet. We're still waiting for nested trees feature to get polished for wider use, which would be a requirement for something like that
<beuno> of course, I'm fairly sure you can do some black magic with plugins
<lixomancem> Alright, thank you for your answer. I believe I'd rather wait for support for that kind of thing on bzr instead of trying plugins for that.
<ubotu> New bug: #188089 in bzr "relies on sha1 for inventories" [Undecided,New] https://launchpad.net/bugs/188089
<lixomancem> Just out of curiosity: is there any work being done on a Windows GUI? Not that I need one, but I can't get my company to use bzr unless there is one.
<beuno> lixomancem, you _do_ have the eclipse plugin, but I'm not sure if that's what you're looking for
<lixomancem> Hmm I didn't know about that one. Not exactly what I'm looking for, but I'll take a look at it. Thanks.
<beuno> lixomancem, np
<LeoNerd> bzr log --line >some-file   truncates the lines at 80 columns with "...".. How can I make it not do that?
<dato> LeoNerd: COLUMNS=3000 bzr log --line >some-file
<dato> or, for portability, `env COLUMNS=...`
<LeoNerd> Ah :) That got it, thanks
<mthaddon> can someone help me out - just trying to get the status of a bzr tree in python using bzrlib - must be missing something simple
<mthaddon> I've tried bzrlib.show_tree_status(path), but no luck
<luks> get the status in what form?
<mthaddon> in the same way that I would from "bzr st" from the command line, for instance
<mthaddon> basically I just want to see if there are uncommitted changes
<luks> tree.changes_from(tree.basis_tree()) will get you lists of changed files
<luks> or you you want actual text output?
<mthaddon> what's the "tree" object?
<luks> *do
<luks> a result of e.g. WorkingTree.open(path)
<luks> or WorkingTree.open_containing(path)[0]
<mthaddon> sorry, I'm really basic here - I'm doing "import bzrlib" but don't see WorkingTree as a module of bzrlib
<james_w> bzrlib.workingtree.WorkingTree
<luks> from bzrlib.workingtree import WorkingTree; tree = WorkingTree.open('.'); print tree.changes_from(tree.basis_tree())
<mthaddon> great, thanks!!
<noblex> hi, is bzr-gtk 0.93 compatible with bazaar 1.1?
<rolly> works for me on Windows
<n[ate]vw> can bzr set the PYTHONPATH for an ssh connection like it can set the BZR_REMOTE_PATH ?
<dato> n[ate]vw: I don't think so, but you could set remote_path to a local executable wrapper that sets it, and execs bzr, if you really need it
<n[ate]vw> sounds like a good solution, though I might just install system-wide and be done with it
<abentley> n[ate]vw: bzrlib doesn't have to be in your PYTHONPATH if the bzr executable is directly above it.
<n[ate]vw> abentley: interesting. it complained about bzrlib the first time, but not the second
<n[ate]vw> might have to go that route, looks like bzr wants to install in /usr/local/bin, which isn't in the ssh path
<n[ate]vw> or maybe this is all moot, since I just learned the difference between .bash_profile and .bashrc. I can just amend the PATH/PYTHONPATH to my user install
<abentley> n[ate]vw: bzr doesn't have to be installed, btw.  You can just unpack the tarball and run it from there.
<n[ate]vw> abentley: doesn't installation pre-compile some stuff, though?
<n[ate]vw> basically, the deal is that OS X doesn't come with a /usr/local, and so I typically just install things to a custom prefix (since I have to modify path anyway)
<abentley> It does, but that stuff is optional.  And you can compile it in place, too.
<n[ate]vw> how would I compile in place?
<abentley> make
<n[ate]vw> heh, easy enough
<n[ate]vw> probably better to just keep intalling it in /Users/Shared/dev instead of having my path point to ~/Downloads, though :-)
<ubotu> New bug: #188198 in bzr "Network outage results in unrecoverable interruption during svn+http:// branch" [Undecided,New] https://launchpad.net/bugs/188198
 * awilkins waves at ubtou
<jelmer> awilkins: See the bzr-svn FAQ for a workaround of the bug you just filed
<jelmer> awilkins: sorry, please look at the bug I just linked your bug report to
<awilkins> jelmer: Aha, thanks for that.
<awilkins> jelmer: The problems I was having earlier seem to have evaporated ; maybe it's just my weird repo layout at work
<awilkins> I'm not trying to branch the same repository here.
<jelmer> awilkins: not the same repository?
<jelmer> you mean the repository that was giving trouble was different?
<awilkins> jelmer: Yes, the repo I was having trouble with "not a branch" errors is an internal one.
<jelmer> awilkins: The testsuite also failed so there's definitely something broken in your setup
<awilkins> jelmer: pycurl respets the IE proxy settings (if bzr-svn uses pycurl for HTTP traffic)?
<jelmer> no idea
<awilkins> It appears to, I had to go into IE options and switch off proxy to branch this repo from home.
<awilkins> The selftest doesn't run, but I've just managed to branch a repo here.
<awilkins> jelmer: I think I found the problem with the tests ; file:// urls on windows still have to start with a / (so they end up as file:///d:/stuff
<awilkins> Well, one problem
<rolly> To move a standalone branch into a --no-trees shared repository, is it sufficient to just copy it over with my OS?
<Peng> If you just copy it over, you'll copy over the branch's copy of the repo too.
<Peng> It would be better to "bzr branch" into the repo.
<rolly> Ah, yes. Thanks Peng
<Peng> You might also be able to manage something with copying it over and using "bzr reconfigure".
<Peng> "bzr branch" ensures that the shared repo has all of the revisions in the branch and sets it all up correctly, but you'll have to set the branch's parent again.
<rolly> It's an empty shared repo, and I'm adding the "top-most" branch parent
<rolly> hm, I tried bzr reconfigure -v --branch ., and the result was an error ("already a branch"). But branching worked fine. Thanks again Peng
<hsn_> any work on Netbeans BZR plugin?
<jelmer> hsn_: No, afaik not
<awilkins> jelmer: I fixed up that ra_local problem in the tests, and found a couple of other potential problems
<jelmer> awilkins: Ah, cool
<awilkins> jelmer: Some of the code is using os.name instead of sys.platform == 'win32' (os.name == 'nt). And those links have to start with a slash on win32, not a drive letter.
<jelmer> awilkins: ahh
<awilkins> it;s like there's a magic "root" above the drives
<awilkins> Still getting errors, but not the same boring error for every single test.
<jelmer> this is 0.4.7 ?
<awilkins> Right, I don't have enough battery (laptop or brain) to stay awake.
<awilkins> This is 0.4.7 (pulled to r 877 from the 0.4 branch)
<awilkins> Lots of "permission denied" on removing test directories.
<awilkins> But that isn't causing failures or errors
#bzr 2008-02-02
<jelmer> awilkins: any chance you can file a bug with that patch attached before you go to sleep?
<awilkins> jelmer: Hmm, this is odd ; bzr update says tree is up to date, but there's a huge diff
<awilkins> smore like it - diff -r 877
<jelmer> awilkins: what do you expect "bzr update" to do?
<jelmer> it only makes sense if you have a bound branch
<awilkins> I was expecting it to update my working tree to the latest revision in the repository
<jelmer> it will only do that if you used "bzr co"
<jelmer> if you used "bzr branch" to create the branch you need to use "bzr pull"
<awilkins> No revisions to pull , my tree is at 877 but my repos is at 891 ; hence a huge diff unless I specify 877
<jelmer> awilkins: A repository doesn't have a tip, not sure I'm following...
<awilkins> The source in my working tree (plugin folder) is at 877 (release 0.4.7)
<awilkins> But the repo has revisions up to 891 (HEAD)
<awilkins> If I diff the tree, it includes reverse diffs all the way back to 877
<awilkins> Launchpad is fubar
<jelmer> Where do you diff against?
<jelmer> Also, what do you mean by repo?
<awilkins> The revisions in the .bzr folder (it's a standalone branch)
<awilkins> bzr log -r -1.. shows revision 891
<awilkins> But the source is at 877
<jelmer> "bzr revno" gives 891 ?
<awilkins> ItYes
<awilkins> The source being at 877 was intentional, I wanted the release tag
<jelmer> Ah, you ran "bzr update -r877" or something?
<jelmer> or perhaps "bzr revert -r877" ?
<awilkins> bzr pull -r 877 I think
<awilkins> Maybe revert
<jelmer> revert would do that
<jelmer> if you can send in a diff against 877 that would help too
<awilkins> jelmer: sorry, downtime, ignored my battery warning for too long.
<awilkins> Back up again now
<jelmer> welcome back :-)
<awilkins> #188233
<jelmer> thanks
 * jelmer waits for ubotu to announce
<awilkins> Grr, I've reverted up to 891 and now gnu patch won't apply
<ubotu> New bug: #188233 in bzr-svn "PATCH : fix some win32 testing issues" [Undecided,New] https://launchpad.net/bugs/188233
<awilkins> Hooray for ~1~ files
<rolly> Hm, if I make several revisions to a branch, how can I merge those changes to a parent branch without losing the original commit messages?
<rolly> SVK has "--verbatim --incremental"
<jelmer> rolly: Just use "bzr merge"
<jelmer> bzr log will then show the merged revisions indented
<rolly> I can't, because there is a revision that must not be propagated
<rolly> i have to specify a range
<jelmer> rolly: that would be a cherrypick
<jelmer> rolly: tracking cherrypicks is not supported yet
<rolly> OK thanks
<rolly> This puts a damper on my plans for world domination
<rolly> :p
<awilkins> Do the merge and reverse merge the "bad" revision?
<awilkins> jelmer: Do you prefer bzr send output or bzr diff?
<rolly> That would be only slightly better
<jelmer> awilkins: bzr send please
<rolly> I'm just going to have to refactor this code so there aren't any "special" files that can't be propagated
 * awilkins attaches
<awilkins> Ah, the old "special" files with the CEO's password in.
<rolly> yep yep
<rolly> nuclear launch codes
<jelmer> awilkins: For "bzr send", you have to commit ifrst
<jelmer> you now attached an empty bundle :-)
<awilkins> I wondered why it was so short, I was really impresed :-)
 * awilkins attaches a patch with stuff in it
<jelmer> thansk, merged
<mtaylor> is there a roadmap/timeframe for 1.2?
<awilkins> https://launchpad.net/bzr/1.2/
<mtaylor> awilkins: thanks
<rolly> Say, what are the *.~1~ files? No mention of them in the reference guide
<mtaylor> anybody know what this means: "not updating child fraction"
<jelmer> mtaylor: A progress bar issue
<Peng> rolly: "bzr revert".
<rolly> Peng: thanks
<rolly> (handy feature)
<homerj> floam likes to touch himself at night
<homerj> don't listen to him
<floam> can bazaar automatically throw the current revision into files at some spot I wish somehow?
<floam> god damn it
<rolly> automatically? there are hooks you can use
<Peng> floam: There's no built-in support for keywords like $Id$ though.
<floam> rolly: I just meant, magically have a number pop up in some file under version control without having to call bzr revno or anything
<floam> Peng: ok, thanks
<rolly> Oh I misread you. Something like CVS then eh
<Peng> floam: Yeah, currently you have to do something like execute "bzr revno" in your Makefile.
<floam> yeah, I was doing that. It just means I need to think a bit harder, because I was hoping the number would be there when my users run a setup.py. I'll just need to keep a static file in the distribution with the number in it
<homerj> floam, things popping up and thinking "harder" is what leads yourself to touch yourself at night
<rolly> That's a bit of stretch
<floam> ...
<mtaylor> dude. I walked in on the wrong conversation
<awilkins> rolly: ~1~ files are "revert" leftovers
<awilkins> jelmer: I have a new trace from bzr seltest svn on win32 if you want it.
<awilkins> Not that you have a windows box :-)
<awilkins> jelmer: The major error now appears to be that the support for is_executable relies on the inventory, but it's being called in the read_inventory routine (in add_file_to_inv)
<Stavros> hello
<Stavros> i am thinking of using bzr for regular backups
<Stavros> does it only keep the diffs of changed files, or the whole files?
<james_w> Stavros: diffs.
<Stavros> even for binary files?
<james_w> Stavros: yes, but the diffs are not very efficient in that case. They can be very suboptimal in fact.
<Stavros> ah hmm
<Stavros> and it keeps the history locally as well, so it wouldn't be very efficient for large files, correct?
<james_w> Stavros: you can use a local checkout that only stores the history remotely, but requires network access for operations that query history or make changes (e.g. commit)
<Stavros> james_w: checkins query history for diffs, don't they?
<james_w> well, the commit has to put the data on the server, so it has to have the network access.
<Stavros> before putting the data, doesn't it have to read the old ones to see what's changed?
<james_w> yep.
<Stavros> that's a bit much... but i guess my current rsync setup also does it
<Stavros> oh hmm no, rsync is per-file
<james_w> Stavros: it knows which files have changed, do it only has to find the old versions of those ones.
<Leonidas> hi
<Stavros> oh aha
<Leonidas> is there a way to create a branch "inline", that is to have multiple branches in the same directory?
<james_w> Leonidas: no, that is not currently possible.
<james_w> Leonidas: or do you mean use the 'git' workflow of having one tree for multiple branches and just switch the tree.
<Leonidas> james_w: oh, thats a pity. I wanted to do a feature branch, but making it in a new directory would be a lot of work because webserver configurations would need to be changend
<Leonidas> james_w: yaeh, I want to do something like in git - switching the branch with git checkout
<james_w> Leonidas: ah, you can do something like that with a bit of work using checkouts and the 'switch' command.
<james_w> you basically create two treeless branches elsewhere on the filesystem and then have a checkout in the location you want and use 'switch' to jump between the branches.
<james_w> I think there is a 'cbranch' command in bzrtools that makes this a bit easier as well.
<Leonidas> james_w: ah, ok. Does not look too pretty, but this sounds good.
<Leonidas> james_w: I also found http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout
<Stavros> how would i go about doing local checkouts?
<Stavros> or is that what "co" or "bind" does
<Stavros> ?
<james_w> Stavros: exactly. You need to use co --lightweight to have the history only stored remotely.
<Stavros> ah, thanks
<james_w> Stavros: you can also see the reconfigure command which might help if you have branches already.
<Leonidas> james_w: as far as I see, cbranch is quite what I was looking for - thanks, I'll give it a try :)
<simony> Hi, I am using the ppa apt repository, but it complains about the crypto-key. Can I add ppa's key to my apt keys? Where can I find it?
<james_w> simony: good question. Does it complain on update or install?
<simony> james_w, on install
<james_w> simony: and it says it doesn't have the public key, or that they are unsigned?
<simony> it says: Install these packages without verification [y/N]?
<simony> (and also, before it says: WARNING: The following packages cannot be authenticated!)
<james_w> simony: I think this is https://bugs.launchpad.net/soyuz/+bug/125103
<ubotu> Launchpad bug 125103 in soyuz "ppa archives are not signed" [High,Confirmed]
<james_w> simony: so I guess that there is no public key to import to solve the issue.
<Stavros> can't you ignore crypto warnings on apt-get??
<Stavros> minus the second question mark
<james_w> (sorry, I haven't used PPAs, so I don't really know what the solution might be).
<james_w> simony: #launchpad might be able to give you a better answer.
<simony> I can ignore them, yes. Was hoping not to :-) Thanks
<james_w> Stavros: I think there is --allow-unauthenticated, but that is just the same as typing yes, so it doesn't really solve the problem.
<Stavros> ah
<jelmer> re
<jelmer> awilkins: Yeah, I would be interested in seeing that output
<dato> jelmer: hi. when I branch with bzr and svn-psh to a svn repository, it seems to get one spurious revision. see revs 423-424, and 415 in https://forja.rediris.es/svn/csl2-minirok for an example.
<dato> jelmer: I would've expected 424 to be 423 (that is, cp+that change already)
<jelmer> dato: Hi
<jelmer> dato: Please file a bug :-)
<jelmer> This does look like a bug, indeed.
<awilkins> jelmer: http://filebin.ca/nzoebw/bzr-svn-win32-test.zip
<jelmer> awilkins: Thanks
<jelmer> awilkins: The _inventory bit should be fixed in newer revisions
<awilkins> Was just about to mention it :-)
<jelmer> awilkins: I've just committed another revision that should help fix the executable bit
<jelmer> awilkins: Any chance you can run selftest again on a newer revision?
<awilkins> Sure
<awilkins> There's a lot of "permission denied" problems cleaning up temp dirs, but not fatal
<awilkins> And not really a bzr-svn test problem ; it's in the base test class
<jelmer> Well, the cleanup probably fails because those files are still open by bzr-svn
<awilkins> I see that a lot on *nix code that gets ported to win32
<awilkins> svk has a load of gaffes like that too.
<awilkins> I guess it's just a lot less graceful about unlinking files
<jelmer> It's the difference between unlinking and deleting I think
<dato> jelmer: there's another minor thing that I don't know if you've noticed, or consider it "candidate for fixing".
<jelmer> unlinking (as happens on POSIX) allows you to remove a path while there are still people who have the file that path refers to open
<dato> jelmer: if you give the bzr commit message with the editor instead of -m, in the svn log always appears an empty trailing line in the log, even if there wasn't any in the editor.
<awilkins> Yeah, windows doesn't let you do that.
<awilkins> I'm not sure which OS behaviour I like best, to be honest
<jelmer> dato: I think it's svn that does that
<jelmer> dato: bzr-svn doesn't add trailing whitespace
<dato> ah, maybe svn unconditionally adds a \n
<jelmer> awilkins: both have their advantages I guess
<dato> jelmer: maybe you could strip one \n at the end of the message?
<jelmer> If the \n is added unconditionally, sure.
<jelmer> please file a bug though :-)
<dato> ok
<ubotu> New bug: #188353 in bzr-svn "Branching with bzr and svn-push'ing produces a spurious revision" [Undecided,New] https://launchpad.net/bugs/188353
<awilkins> jelmer: http://filebin.ca/kqujcc/bzr-svn-win32-test2.zip
<jelmer> thanks
<bronger_> Is it possible to delete the parent info from a branch?
<awilkins> Not sure what you mean.
<bronger_> I had my project in an SVN repo.  With "bzr branch", I created a local branch.  WIth push, I created a copy of it on Launchpad.  This still has the SVN set as its parent.  Now I wonder whether I can detach it from the SVN.
<luks> you can remove it from .bzr/branch/branch.conf, but the parent location doesn't really mean the branch is "attached" to the SVN
<bronger_> So it doesn't do any harm?
<luks> you mean removing it or keeping it?
<bronger_> Keeping it.
<luks> not at all
<bronger_> Okay, thank you.
<BlogueroConnor> hello, I want to publish (push) into a ftp directory, but, my username have a '@' in the username (that is typical for a shared hosting) and bzr don't  understand it.
<dato> BlogueroConnor: try push ftp://you%40domain.com@server.com
<BlogueroConnor> %40 is like @?
<BlogueroConnor> encoded?
<BlogueroConnor> will try it
<BlogueroConnor> YES. it worked!
<BlogueroConnor> But I think there is an error in this tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<BlogueroConnor> because I tried...
<BlogueroConnor> bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject (with my data of course)
<BlogueroConnor> but I got:
<BlogueroConnor> bzr: ERROR: Target directory XXX already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<jelmer> BlogueroConnor: bzr will only push a branch to a directory that doesn't exist yet or is empty
<jelmer> BlogueroConnor: the tutorial about that bit looks ok to me
<BlogueroConnor> jelmer, but this directory is empy. (it was, now I used the --use-existing-dir and it worked)
<BlogueroConnor> jerlmer: I can give you an ftp account in my site for you to see.
<BlogueroConnor> Now I understand
<BlogueroConnor> the problem was that I was using mysite.com instead of mysite.com/branchname, because the user I was using, had direct access to mysite.com/branchname when you log in (the base directory of that user is branchname, so I dont have to specify it there).
<bkc> I'm a longtime svn user. I used svn2bzr some months back on a repository, and now I need to merge changes from svn into my bzr working set.
<bkc> bzr merge <svn url> doesn't work.
<bkc> do I need to bzr branch <subversion> then merge that new branch into my existing bzr branch?
<rolly> does bzr merge -r n..m <svn url> work?
<jelmer> bkc: that only works with bzr-svn
<jelmer> bkc: not with svn2bzr
<bkc> yes, I have bzr-svn already installed. I just used svnimport to create the original bzr import
<bkc> I guess bzr co svn doesn't support https
<jelmer> bkc: "bzr svn-import" != svn2bzr
<jelmer> if you used svn2bzr to create the original import, you can't use bzr-svn now
<jelmer> bkc: bzr-svn should support https fine
<bkc> ok, so I guess I need to diff3 by hand for every file then?
<bkc> there have been changes in the bzr repository and the subversion one, I need to get the subversion changes into bzr
<jelmer> You could try "rebasing" first
<bkc> regarding bzr-svn with https, I have an https url to a subversion repository. How do I check it out using bzr?
<bkc> I have a svn password on it, but I've already used svn info to cache the password
<jelmer> bkc: You should be able to just use the https url
<jelmer> bkc: If that doesn't work, please pastebin the error
<bkc> I tried bzr branch https:// ... and I get bzr: ERROR: Invalid http response for https:/ .. tal2xslt/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jelmer> bkc: Try prefixing the URL with "svn+"
<bkc> svn+ .. I get SubversionException: ("Undefined tunnel scheme 'https'", 125002)
<jelmer> bkc: Your local svn libraries aren't build with SSL support
<jelmer> I think
<jelmer> what version of bzr-svn are you using?
<bkc> the subversion client, or the bzr build?
<jelmer> it could also be caused by using a version of bzr-svn < 0.4.3
<bkc> yeah, it's 0.4.1-1 I'm on feisty  using standard packages
<bkc> but maybe I could svn co, then use bzr merge from the svn checkout directory?
<jelmer> bkc: a .svn directory doesn't contain any historical data
<jelmer> it will still have to go to the server and that will fail
<jelmer> if it is at all possible, I would recommend upgrading to a newer version of bzr-svn
<bkc> I'm worried about breaking bzr-tools, which I need for eclipse
<jelmer> the bzr-eclipse plugin you mean?
<jelmer> I thought that only depended on bzr-xmloutput plugin
<bkc> yes, apparently the version I have calls out to bzrtools
<bkc> maybe my plugin is old..
<jelmer> beuno: ping
<johnny_> hi, what is the best way to covert a cvs repository to bzr
<johnny_> especially if you have just have checkouts :)
<johnny_> the cvsps document seems to imply that you need server side access, since it doesn't support :ext: or :pserver:
<Aviator> where can i find resources on embedded bzr?
 * johnny_ has never even heard of that
<Aviator> to quote: "If you want intelligent version control embedded into your application or content management system, Bazaar has the architecture you need."
<johnny_> sounds like you can use it as a lib
<Aviator> or backend
<Peng> You can do "import bzrlib".
<Aviator> and fiddle with it?
<Peng> bzrlib is the entire codebase.
<Peng> The "bzr" script is just a little bit of startup code.
<Aviator> and then go where?
<Aviator> theres a lot of submodules
<johnny_> Aviator, gonna have to read the pydocs i assume
<bob2_> Aviator: http://bazaar-vcs.org/Integrating_with_Bazaar might be a start
<bkc> call me stupid. I have a checkout of an lp branch I host. I have committed my changes, but how do I upload the changes back to lp? lp's page still doesn't show my revs.
<bob2> if it's a checkout, they're uploaded on commit
<bkc> oh .. they finally shows up. I guess a commit on a checkout doesn't require a push.. just slow
<bob2> right
<bkc> thanks, I'm still trying to get the hang of bzr vs svn
<bkc> jelmer: thanks for your help too.. was a good time to learn how to use kdiff3
<bob2> "bzr log sftp://bazaar.launchpad.net/foobarbaz" will probably show them instantaneously
<johnny_> so, is there a way to import a cvs repository without the full cvs root?
<bob2> I think https://launchpad.net/bzr-cvsps-import works over the network
<johnny_> this page says it doesn't support :ext: or :pserver: http://bazaar-vcs.org/CVSPSImport
<bob2> hm, right
<beuno> jelmer, pong
<beuno> johnny_, bzr-eclipse doesn't depend on bzrtools at all
<beuno> just bzr-xmloutput
<johnny_> huh ? bz-eclipse ?
<johnny_> why did i say anything about bzr-eclipse
<beuno> johnny_, ahm, sorry, wrong person
 * beuno should read backlogs more carefully
<jelmer> beuno: why does bzr-xmloutput depend on bzrtools then?
#bzr 2008-02-03
<Peng> Yikes, importing bzrlib.lazy_import imports 70 modules.
<Debolaz> Does bazaar distinguish between author and committer?
<jelmer> Debolaz: yes
<Debolaz> jelmer: So I could export a patch for someone to commit, and it would automagically credit me as the author even though they committed it? Emphasis on the automagic part here.
<jelmer> Debolaz: No, you can use --author to specify a different author when committing somebody elses patch
<jelmer> or you can use "bzr bundle" to create a patch that contains the metadata
<jelmer> which somebody else can then "bzr pull"
<jelmer> or "bzr merge"
<rolly> Hm, I'm testing push-and-update and I get an error:
<rolly> running "ssh user@example.com:2233 bzr update /var/docs/example.com/trunk/"
<rolly> bzr: ERROR: [Error 2] The system cannot find the file specified
<rolly> But there's nothing in either the local .bzr.log or the remote .bzr.log
<rolly> The command "bzr update /var/docs/example.com/trunk/" works fine, if I run it in my remote shell. Anyone have a clue?
<rolly> Oops, maybe I need to install push-and-update on the remote side too
<rolly> n/m, there is indeed an error in the .bzr.log
<rolly> ah... Windows doesn't have 'ssh'
<beuno> jelmer, it shouldn't depend on it
<beuno> where are you seing it does?
<jelmer> bkc was saying he was worried upgrading bzrtools would cause bzr-xmloutput to break
<beuno> ah, well, it shouldn't
<muffinresearch_> Can anyone point me in the direction of docs for the nested-trees functionality?
<bob2> there's http://bazaar-vcs.org/NestedTreeSupport
<brink_> Bazaar retains history when file is renamed.  Is there a way to retain history when a file is split?
<bob2> not as yet
<lifeless_> don't you hate it when your brane won't quiesce
<wingo> greets! is there any way to get bzr.dev via bzr:// ?
<Odd_Bloke> wingo: I don't believe so, no.
<Odd_Bloke> Why?
<wingo> Odd_Bloke: i was just updating a checkout from two or three months ago, and it was running really slowly
<luks> that's probably because bzr.dev was upgraded to packs and your branch is in knits
<wingo> luks: probably so
<wingo> i'm doing a fresh checkout and it's running much faster
<ubotu> New bug: #188684 in bzr-webserve "UI Improvement?" [Undecided,New] https://launchpad.net/bugs/188684
<alecw1> How do I find out which version of bzr I'm using?
<luks> bzr --version
<alecw1> luks: thanks.
<wjl> I'm switching a lot of my projects from mercurial to bazaar, but I really miss mercurial queues (gives quilt-like behavior, integrated with mercurial). Are there any plans for a mq-like plugin from bazaar? Or is there another way to get this functionality (besides hundreds of feature-branches) using bazaar that anyone can suggestion?
<mwhudson> there's 'looms'
<mwhudson> but i'm not totally sure what they do or how they work :)
<wjl> I saw a mention of that somewhere, but couldn't find a link -- any idea where that is being developed?
<mwhudson> no, come to mention it
<mwhudson> maybe it's not released yet
<mwhudson> lifeless should know
<wjl> okay, maybe I'll do a little more searching, and if I don't find anything I'll ask on the mailing list
<mwhudson> good idea
<wjl> okay, looks like https://wiki.ubuntu.com/NoMoreSourcePackages was where I saw it mentioned
<wjl> JFYI
<wjl> I can't tell from that page if it's just an idea, or a real project
<mtaylor> wjl: I believe there is something like quilt coming
<mwhudson> it certainly exists
<wjl> Right now, to port from Mercurial w/ MQ, I'm using Bazaar + Quilt, but it's a little clunky.
<lifeless> yo
<wjl> looms sounds like it would be / will be great, I just am not sure where it's development is at
<lifeless> its basically a concept for now
<lifeless> we're hoping to have it be more in a few weeks
<lifeless> but there is other stuff to do first; like network performance
<wjl> I'd love to help, once there is a first cut to try -- I have quite a few projects using MQ that would be interesting to try converting at some point
<wjl> Anyway, I'll keep using mercurial and bzr+quilt for now, and keep my ears open for loom developments. =)
<lifeless> cool
<igc> morning
<rcohen> for something like quilt, i have written several tools in the past which do basically the same thing and come to the conclusion that patches are a horrible storage format
<rcohen> my latest attempt stores whole pre- and post-images and uses 3 way merge
<rcohen> which is much easier on the user than having to deal with .rej files
<rcohen> http://codeville.org/fst/
<rcohen> it's got some very basic integration tools for a VCS, but probably not enough
<rcohen> anyway, whoever is working on loom, feel free to steal ideas, code or pick my brain on the subject
<fullermd> What you really need to do is embed darcs to handle that stuff   ;)
<rcohen> that's certainly one approach
<simony> I killed a bzr process and it left the repo locked. Can I safely remove the lock directory?
<mwhudson> simony: there's bzr break-lock for that
<simony> thanks
<simony> break-lock seems to hang as well
<simony> at least breaking that didn't leave it locked
<mwhudson> strange
<mlh> simony: what sort of fs are you on?
#bzr 2009-01-26
<RAOF__> spiv: Sensible laptop!
<spiv> RAOF__: :)
 * spiv -> lunch
<thumper> jelmer: ping
<jelmer> thumper, pong
<thumper> jelmer: how goes the bzr-git import stuff?
<thumper> I was just looking at your samba page for dulwich
<jelmer> thumper, so, dulwich (our underlying git library) has seen a release yesterday
<thumper> I knew there would have been a reason for the name of the library
<thumper> but I didn't know what it was
<thumper> :)
<jelmer> thumper, :-)
<jelmer> thumper, I've also frozen the current mappings
<thumper> jelmer: have you changed the generated rev ids to use v1 rather than experimental?
<jelmer> so if you use current bzr-git to do an import it won't break in the future (barring bugs, of course)
<jelmer> thumper, yep
<thumper> cool
<thumper> I'll move our plans along then
<thumper> has there been a release of bzr-git officially?
<jelmer> not yet
<thumper> planned one?
<jelmer> there's some regression that broke remote branching that I'm working at fixing at the moment
 * thumper nods
<thumper> jelmer: can I get you to email me when you have a release?
<jelmer> after that I hope to do a 0.1 release
<thumper> we'll work on the git imports for LP on that
<jelmer> thumper, yeah, np - I'll cc you on the announcements
<thumper> ta
<thumper> fantastic
<solitude`> hey, I'm very new to versioning clients, I have bzr installled... i'm wondering what approach I should use for making a CMS for users to login and see the files and edit them... Like, do I make a php script/page that connects to the bzr server to modify/update the different files??
<solitude`> Because I need some sort of interface for staff members to edit the site, and folks are saying to use subversion for that, but bzr looks less complex.... am I on the right path?
<thumper> so you are writing a content management system?
<solitude`> yeah
<solitude`> I wrote on in PHP last summer but ran into a roadblock when I was trying to figure out how to let staff members edit differnt files/pages of the website, and now I hear that this is the best approach
<thumper> well, bzr is written in python
<thumper> so you could either call into python at the system command level...
<thumper> or use the python bzrlib somehow
<thumper> although from PHP, I don't know how
<solitude`> well I know some python, and I know how to pass variables between python and PHP
<thumper> unless someone has embedded python into PHP recently
<thumper> :)
<solitude`> I just make a simple python socket and have PHP connect to that , kinda like sql
<thumper> python socket?
<solitude`> yeah, a python script that listens on a port and runs on the server
<solitude`> so the python script could communicate with bzr
<thumper> ok, well, you could have your python script accept "commands" with text and have that script use bzrlib
<solitude`> bzrlib = bzr, right?
<solitude`> I'm still figuring out bzr :)
<solitude`> I just wanna make sure I'm approaching this correctly
<thumper> bzr is the command line tool
<thumper> bzrlib is the python library behind it
<solitude`> hmm
<thumper> bzr comes with bzrlib
<solitude`> don't you just need the command line, to make any changes??
<thumper> you could do it that way
<thumper> but you don't need to
<solitude`> i see
<thumper> to be honest, it may be your quickest way of getting something working
<solitude`> just using hte command line?
<solitude`> or the bzrlib
<thumper> yes, to start with
<thumper> yes commandline
<solitude`> okay
<solitude`> What does bzrlib offer that command line doesnt?
<thumper> complete program flexability :)
<solitude`> okay, I'll have to look into that once I get the basics of bzr down and the CMS
<solitude`> thank you thumper =)
<thumper> np
<bialix> does LarstiQ around?
<bialix> hey guys, when typically LarstiQ hanging there? (timeframe)
 * bialix will try later
<sadmac> how do I set the email address that shows up with my commits?
<spiv> sadmac: "bzr whoami"
<sadmac> spiv: figured it out. thanks
<vila> hi all
<bialix> bonjour
 * thumper looks around for someone to upload bzrtools into the ~bzr PPA
<speakman> hi folks! Is there any way to undo a pull, which has screwed up the log?
<spiv> speakman: you can pull -r SOME_REV --overwrite
<spiv> speakman: but what do you mean by "screwed up the log"?
<speakman> it replaced the log mainline with the log of the log of the branch which has some strange merges and stuff
<speakman> what I wanted to do was a merge.
<spiv> Ok.  So yes, bzr pull as I said above to bring the branch back to the point it was at before.
<speakman> can I use -r -1 for it?
<spiv> speakman: pull -r -1 would be a no-op
<spiv> Oh, unless you mean to pull -r -1 of some other copy of the branch onto your copy.  That would work.
<spiv> But if you don't have another copy, then you'll need to look at the log and and find where the mainline stops being what you wanted (i.e. commits from someone else).  That's the point at which the other branch diverged from yours, and so you want to go back to that revision.
 * spiv -> dinner
<speakman> It did work, thanks alot.
<spiv> speakman: great.  glad I could help.
<Lo-lan-do> I'm still struggling to find a way to get git and bzr to cooperate... I may be missing something, but I can't seem to get it working.
<Jc2k> Lo-lan-do: ?
<Jc2k> are you playing with bzr-git or something else..
<Lo-lan-do> I tried bzr-git and git-bzr.
<Jc2k> bzr-git doesnt have push yet, but bzr branch should work against git://
<Jc2k> i think it can only get the master branch, tho
<Jc2k> i think there is a git-import to get the full repository
<Jc2k> push should come soon. i've been working on some parts of it in dulwich
<Lo-lan-do> I managed a branch, but when I added a commit into the git dir then I couldn't branch it again.
<Jc2k> oh?
<Jc2k> what error?
<Lo-lan-do>   File "/home/roland/.bazaar/plugins/git/dulwich/dulwich/repo.py", line 223, in _get_object
<Lo-lan-do>     assert len(sha) in (20, 40)
<Lo-lan-do> (AssertionError)
<Jc2k> oh cripes.
<Jc2k> dont suppose the git repo is online somewhere?
<Lo-lan-do> It's a clone of git://git.debian.org/apt-build/apt-build.git
<Lo-lan-do> (I took a random reasonably-sized one :-)
<Lo-lan-do> Then I added a simple commit inside.
<Lo-lan-do> Might be relevant: I upgraded to git 1.6 after the cloning.
<Jc2k> hmm, i cant imagine they changed the object format in 1.6
<Lo-lan-do> Dunno.  When I tried to push (earlier), bzr complained about not finding a .git/inventory file or so.
<Jc2k> yeha, push isn't implemented at all. most of the pieces are there for dpush i think, just need to tie it all together.
<Jc2k> Lo-lan-do: did you do the simple commit with git or bzr?
<Lo-lan-do> git
<Jc2k> hmm
<Jc2k> i can reproduce, at least :]
<fullermd> Sheesh, get a room.
<Lo-lan-do> I'm off to lunch, but I'll be back soon :-)
<CaMason> hi guys. I've got an SVN repo with some projects in, and I'd like to create a bzr branch from one of the specific folders in that SVN repo
<CaMason> any hints on how to do that? I tried bzr branch /srv/svn/myrepo/myclient/project/ but got an error about different rich-root support
<fullermd> You're trying to branch it into an existing repository, which isn't rich-root capable.
<fullermd> You need to do it into a new repository (standalone would quality), or change your existing repository to rich-root, which you probably don't want to do since it will shove all the branches in it through the trapdoor.
<CaMason> what does the rich-root do?
<Lo-lan-do> CaMason: I think it allows bzr to track information on the root directory, whereas non-rich-root formats only track it for the files inside.
<Lo-lan-do> But I'm far from being an expert in these matters.
<Lo-lan-do> Jc2k: Any timeframe for a working push?  Weeks?  Months?
<fullermd> Roughly that, yah.
<CaMason> ok. well, they way I have my folders set up is, I have a shared-repo (no trees) per client
<CaMason> then there are project folders, then the branches inside of that
<CaMason> either way, do I need to make a shared repo with rich root support
<fullermd> Well, you could make a separate shared repo for it, sure.  Or you could just make it standalone.
<CaMason> there's no branches in that particular repo atm
<fullermd> (probably have to make it elsewhere then move it in place for that; there's no easy way offhand I know of to make it standalone from the start without doing a lot more rather annoying steps along the way)
<Lo-lan-do> Jc2k: By the way, I upgraded the git plugin (and installed dulwich) and the bug seems to have gone away.
<CaMason> will rich-root cause me any problems with normal bazaar projects? (or other cons?)
<Jc2k> Lo-lan-do: interesting..
<Jc2k> Lo-lan-do: im just merging head into my branch so i guess it will go away for me in a sec to
<Jc2k> too
<Lo-lan-do> Well, since I'm tracking your branch....
<Lo-lan-do> I was hopeful when I saw a log message by jelmer stating "Let's implement push", but no such luck.
<Jc2k> that was me in dulwich
<Lo-lan-do> Oh, right, sorry.
<Jc2k> in theory dulwich would support push right now, but the stuff to assemble a push is missing for a git repo and for a bzr repo
<Jc2k> i was working a git implementation in dulwich to make sure the API is up to scratch, then i was going to start on the bzr one. assuming jelmer doesnt beat me to that :)
<oleavr> hi. is there an easy way to replace the parent location for a number of branches? like, some way to clear it off a branch and specify it in locations.conf
<Jc2k> hey oleavr :)
<oleavr> morn Jc2k :) how's it going?
<Jc2k> goood thx :) yourself?
<james_w> oleavr: http://theironlion.net/blog/2009/01/13/using-bazaar-launchpad-making-pushing-easy/
<james_w> check the bit there about configuring locations
<fullermd> CaMason: Rich root support is a trapdoor.  Revisions made with rich root support can't be used in non-rich-root repositories.  So you don't want to move any branch of a project into rich-root unless you're prepared to move EVERY branch of that project (anywhere) into rich root.
<oleavr> Jc2k: nice :) pretty good. what are you hacking on these days?
<oleavr> james_w: thanks, but I've tried that already.. 'bzr pull' still pulls from the parent location ('Using saved parent location')
<oleavr> james_w: so I need some way to clear that remembered value so the one in locations.conf gets used
<Jc2k> oleavr: i've been toying with bzr-git lately (wrote a git server than stores its stuff in bzr)
<Jc2k> oleavr: reading branch.py, looks like there should be a parent file in the .bzr dir for your branch
<oleavr> Jc2k: awesome! asabil told me about that project. sounds really neat!
<fullermd> Only if you have a very old branch.
<oleavr> Jc2k: aha, thanks! *looks*
<Jc2k> otherwise it goes through the normal config stuff
<Jc2k> and i guess there would be a branch.conf too
<Jc2k> /instead/
<oleavr> hmm, branch.conf seems to be the culprit
<Jc2k> it looks like you can branch.set_parent_location(None) to unset it
<Lo-lan-do> Jc2k: Could the git server be installed as /usr/bin/git, for remote usage through ssh?
<oleavr> yay, simply just setting parent_location in locations.conf did the trick (thought I tried that already)
<Jc2k> ah, good.
<Jc2k> Lo-lan-do: bzr-git ships with bzr-receive-pack and bzr-upload-pack scripts to symlink in place of git-receive-pack and git-upload-pack
<Lo-lan-do> Lovely.  Do they already work?  That would really make my day :-)
<Jc2k> theoretically :)
 * Lo-lan-do gives it a try
<Jc2k> but the mappings need more love before it can handle bzr revisions
<Jc2k> atm it can only handle git revisions
<Jc2k> (its easy to get a sha1 off a git revision, but to get it off the bzr revision i'd have to scan the entire history of that revision)
<Lo-lan-do> Oh, so gitâbzr one-way again :-/
<Jc2k> yeah.
<Lo-lan-do> I'm almost to the point where I'd like to say "We're using bzr.  Deal with it."
<Lo-lan-do> Problem is that there are three of us, one a bzr user, one a git user, and one who doesn't care.  And I don't have any particular moral authority to impose bzr.
<Jc2k> both should work real soon.
<Lo-lan-do> Nice to know, because we're on a wobbly standing currently, without any public SCM so far.
<CaMason> is there any way I can make an SVN repo into a bzr branch without rich-root support?
<Lo-lan-do> I don't think so.
<fullermd> Not with bzr-svn anyway; it uses rich roots.
<CaMason> not that.. I want to migrate this svn repo branch to a bzr branch
<CaMason> so I can leave SVN behind
<james_w> try bzr-fastimport
<CaMason> just reading up about that now
<CaMason> is it a plugin? The docs just say "grab the latest source"
<CaMason> seems so
<james_w> yeah, you can "bzr branch lp:bzr-fastimport ~/.bazaar/plugins/fastimport"
<CaMason> I can't see any docs on how to use it properly. I'd need to filter the repo as I only want one of the folders inside of it
<james_w> well, it has two parts
<james_w> svn-fast-export that exports the SVN repo to a text stream
<james_w> and then bzr fast-import that imports that stream in to a bzr branch
<james_w> you can edit that stream in the middle if you like
<CaMason> ah right
<james_w> bzr help fastimport
<james_w> may give some documentation
<CaMason> yes it does, but it says to check on the web for further docs, which don't exist
<CaMason> I assume fast-import-filter would be helpful though
<CaMason> would be good to try exporting to a file first then. I'll see if I can figure how to use fast-export-filter.py
<james_w> yup
<CaMason> fast-export.py sorry
<CaMason> ok I'm getting there. Getting an error that I'm looking up
<CaMason> "Can't open file '/srv/svn/clients/db/revs/154': too many open files"
<jelmer> CaMason, what is the problem with rich roots?
<CaMason> I don't know, I was told it was a 'trap door'. All I would like to do is create a sole-branch out of a folder in an SVN repo, and keep it as an SVN branch
<jelmer> CaMason, that's correct - you can't downgrade from rich root to the current default format, but rich root will be the default format at some point in the future
<CaMason> oh right
<CaMason> well this bzr repo is empty at the moment, so could I just re-create it as rich-root, then do a bzr-svn branch into there?
<jelmer> yep
 * CaMason tries that
 * Lo-lan-do cries
<Lo-lan-do> You can track a git branch in bzr with bzr-git, and a bzr branch in git with git-bzr, but when you do a round-trip the revision-ids are different so the branches have no common history :-(
<jelmer> yes, the two are incompatible
<CaMason> jelmer: thanks for that, I seem to have imported my svn branch successfully :)
<CaMason> and it's now a bona-fide bzr project
<CaMason> no more .svn pollution :)
<Lo-lan-do> And your working copy is smaller while containing your whole history.
<CaMason> the main thing is I can now work on this project whilst on the train :)
<CaMason> and I love that about bzr
<CaMason> svn died on me twice this-morning when I deleted a file manually. It hates that
<Lo-lan-do> jelmer: Is that something that can be fixed with the push support in bzr-git, or will stuff be forever split?
<rkistner> i'm having trouble with a lock
<rkistner> when i try to push my branch to launchpad, i get the error "Unable to obtain lock lp-46722000:///~ralf-kistner/pidgin-mxit/main/.bzr/branch/lock"
<rkistner> locked 67 hours, 23 minutes ago
<Jc2k> Lo-lan-do: bzr-git will eventually have full two-way support, introducing git-bzr is always going to introduce pain tho.. unless we have some kind of 'bzr upgrade' to fix a git-bzr branch..
<rkistner> but when i try to break the lock with "bzr break-lock lp-46722000:///~ralf-kistner/pidgin-mxit/main/.bzr/branch/lock"
<Jc2k> Lo-lan-do: i dont know enough about git-bzr, though
<rkistner> i get the error Could not acquire lock "(remote lock)"
<Jc2k> rkistner: thats a known bug with the error message (fixed recently i think)
<rkistner> ok
<Jc2k> rkistner: i think you want bzr break-lock lp:~ralk-kistner/pidgin-mxit/main
<rkistner> thanks, that worked
<rkistner> what would cause the lock in the first place?
<Jc2k> a write operation that was interrupted
<Jc2k> (i think, not my area of expertise tbh)
<Lo-lan-do> Jc2k: Great, thanks :-)
<jelmer> svn-upgrade has some code that could be factored out to supported rebasing a git-bzr-based branch on a bzr-git based branch
<Lo-lan-do> Next question... can one (or will one be able to) access other branches than "master" with bzr-git?
<jelmer> Lo-lan-do, not yet, for this colocated branches in bzr would have to be supported first
<jelmer> I sent a spec for this to the mailing list a while ago
<Jc2k> Lo-lan-do: the server part can expose multiple branches, tho
<Lo-lan-do> jelmer: Interesting
<Goosey> Hello, I am helping to solve [Bug 320968] and was asked to do "bzr init -Dtransport" to write a ".bzr.log". I did this but I do not see the log file. Am I doing anything wrong?
<ubottu> Launchpad bug 320968 in bzr-svn "bzr init in the base of a subversion checkout crashes" [Undecided,New] https://launchpad.net/bugs/320968
<jelmer> Goosey, bzr will always be writing this file (every time it runs) but I'm not sure where it's located on Windows
<jelmer> on Linux it's in your homedir
<Goosey> Ah ok, i will look where it may be..
<james_w> "bzr version" tells you I thin
<Goosey> yes it does
<Goosey> i have it, thanks :)
<speakman> My bzr is saying "No handlers could be found for logger "bzr"" all the time. Any changes lately?
<Odd_Bloke> speakman: Do you get it with '--no-plugins'?
<speakman> yep
<rbriggsatuiowa> how do I change the push branch in bzr info?
<Odd_Bloke> speakman: I have no further thoughts on the matter. :p  Someone else'll know what's up.
<speakman> rbriggsatuiowa: bzr push --remember sftp://new.place.com/somewhere ?
<speakman> Odd_Bloke: ok, thanks for trying. This is really annoying though :)
<speakman> This = It's
<speakman> it's also very verbose, showing every output twice and one of them with both pid, timestamp and debug level:
<speakman> [12133] 2009-01-26 16:49:42.154 INFO: added src/pkt.c
<speakman> added src/pkt.c
<rbriggsatuiowa> speakman: thanks
<speakman> Odd_Bloke: rm -f ~/.bzr.log*  did it
<Odd_Bloke> speakman: Weird.  Possibly worth filing a bug.
<speakman> there already are a few regarding the same issue, that's where I found the solution. :)
<Odd_Bloke> speakman: Fair enough. :)
<Ng> in the output of bzr info, what's a submit branch?
<beuno> Ng, where "bzr send" will compare against
<Ng> beuno: has it appeared because I merged at some point? I've never seen it before and never used send
<beuno> Ng, yeah, it's usually where you branch from IIRC
<NfNitLoop> yeah, that one confuses me too.
<Ng> fair enough. I tend to merge from branches that only exist for short periods, which is what I found a little confusing
 * Lo-lan-do loves the new branch aliases
<NfNitLoop> ... branch aliases?
<Lo-lan-do> :bound, :parent and :push
<NfNitLoop> oh, handy.   can we make custom ones? :)
<Ng> beuno: thanks :)
<Lo-lan-do> No idea, and they're not even particularly documented anyway.
<Lo-lan-do> But I like to be able to "bzr missing :bound".
<luks> NfNitLoop: no, but there is https://launchpad.net/bzr-bookmarks
<fullermd> Wuff.  Unshelve sure doesn't like the new progress bar stuff...
<aruetten> hello everybody, sorry if now follows a boring question. I got a branch of a projekt from launchpad by using bzr lp:/<project_name> and I did some changes in there. What is the right way to commit my changes for my personaly and not to copy them back to LP?
<luks> bzr commit
<aruetten> so simple? ok and when i want to put my changes up to LP bzr push will be the right?
<luks> right
<aruetten> thanks
<ollie> one thing about bzr that is really buggy me. I want a config file to exist in my repository but I need it to be ignored when i do a checkout as the settings are local
<luks> does *any* VCS have a solution to that?
<ollie> so when a new developer does a checkout they need to get the config file but then when they edit the config file it needs to be ignored
<luks> what I normally do is version the default version of a config file
<luks> and the developer has to copy/modify it
<ollie> yeah
<ollie> but i can't ignore a versioned file
<ollie> and then when a do bzr up i get conflicts
<luks> ollie: no, I meant that you version foo.conf.default and ignore foo.conf
<ollie> oh i see right that makes sense
<ollie> thanks :)
<LarstiQ> hmm, no bialix
<Goosey> jelmer, ping!
<jelmer> Goosey, pong
<Goosey> jelmer, I figured IRC may be more rapid than the buglog whenever you are interested (ref to #320968)
<jelmer> Goosey, yeah
 * Lo-lan-do discovers bzr-email
 * Lo-lan-do discovers bzr-cia too
<jelmer> :-)
<jelmer> Goosey, Did you see my last reply?
<Lo-lan-do> jelmer: You should make a bzr-allplugins package, it'll make life simpler for everyone :-)
<jelmer> Lo-lan-do, bzr-cia is already packaged
<Goosey> jelmer, last reply from you I have is your request for the -xml logs on the smaller revision set
<Lo-lan-do> I think you mean bzr-email... I just aptitude-installed -email, but rmadison doesn't mention -cia.
<Goosey> jelmer, I made a reply to that, but as I said in my reply I don't think I can share those log files directly due to NDA
<jelmer> Lo-lan-do, it's in cia-clients
<jelmer> Lo-lan-do, along with the git/svn/etc CIA plugins
<Lo-lan-do> Oh, sorry.
<jelmer> Goosey, I'm not sure what's going wrong exactly
<jelmer> Goosey, it looks like a bug in subversion, but I can't really tell
<jelmer> Goosey, are the subversion you're using directly and the one bzr-svn uses the same?
<Goosey> jelmer, the same repository, you mean?
<jelmer> Goosey, no, the instance of the subversion libraries that's being used
<Goosey> jelmer, I am not sure about that. I am using the precompiled 1.11 windows binaries for the bzr-svn side, do you know I command I can use to query the svn version?
<jelmer> Goosey, bzr-svn will report it in the .bzr.log file
<Goosey> jelmer, bzr-svn: using Subversion 1.5. and.. 1.5.5 for my direct SVN client
<jelmer> Goosey, what's the minor version of the svn used by bzr-svn ?
<jelmer> it should print 3 digits
<Goosey> jelmer, ah sorry, 1.5.4
<lifeless> moin
<LarstiQ> moin lifeless
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<lifeless> jelmer: dulwich isn't reconstructing texts quite right for me
<jelmer> oh?
<lifeless> jelmer: in bzr-compressbench
<lifeless> jelmer: http://bazaar.launchpad.net/~lifeless/+junk/bzr-compressbench
<lifeless> grab that
<lifeless> its got a _very_ minimal versionedfiles implementation for dulwich
<lifeless> I take a pack repo, fully pack it
<lifeless> then construct a dulwich.pack.Pack on that pack
<lifeless> I can get out a plain text
<lifeless> and maybe a two-or-three delta (not sure where it breaks), but doing a full benchmark run EFAIL
<jelmer> and this works ok using e.g. git itself?
<lifeless> yes
<lifeless> the dulwich VF is subclasses from a 'invoke git as a subprocess' VF
<lifeless> have a look at the code, its pretty straight forward, and in true benchmark style no tests :P
<jelmer> What sort of failure do you get?
<lifeless> keyerror I think
<lifeless> grab the code, edit the repo reference, run --delta git --delta dulwich --limit 100000000
<lifeless> and you'll see
<lifeless> back shortly, eating
<jelmer> lifeless, runs fine so far
<lifeless> jelmer: garh
<lifeless> jelmer: in which case, you can see how you stack up speed wise :)
<jelmer> lifeless, yeah, that bit is useful - thanks :-)
<lifeless> I use git for the compression because I want to see how big it is
<lifeless> but the git decompression has fork and datastructure warmup overheads, so I wanted to see 'native' decompression and see if it was faster
<igc1> morning
<hsn_> i am geting error: Unable to load bzr-svn extensions - did you build it? - bzr1.11 on windows using python installer
<jelmer> hsn_, did you install bzr-svn manually ?
<hsn_> jelmer: no. i deleted python and reinstalled python and bazaar again, its fresh install
<hsn_> there is directory sitepackages\bzrlib\plugins\svn - should i delete it?
<hsn_> deleting svn directory fixed problem
<Goosey> jelmer, my repo seems to be cursed. I was messing with Mercurial and after 'hg init' 'hg add' 'hg status' on the root my checkout my montitor started flashing to black
<Goosey> it is as if a demon was angered. A digital demon.
<jelmer> Goosey, the only thing I can think of that would explain this is if the svn folks fixed a bug in svn 1.5.5
<LarstiQ> can anyone read http://www.ukr.net/mta/err.html#enduser?62.216.7.157 ?
 * LarstiQ has trouble mailing bialix :(
<jelmer> LarstiQ, Yes
<jelmer> LarstiQ, it's Ukranian :-P
<LarstiQ> jelmer: :P
<LarstiQ> jelmer: so what does it tell me to do mail bialix? hmm?
<jelmer> LarstiQ, he was asking around for you here this morning I think
<LarstiQ> yeah, I noticed, but he wasn't here when I got back
<jelmer> LarstiQ, have you tried google translate?
<LarstiQ> jelmer: he emailed me too
<_mathrick> hiya
<jelmer> hi _mathrick
<LarstiQ> jelmer: oooh, it does Ukrainian
<_mathrick> a buglet I just noticed: bzr get bzr+ssh://path/to/a/lightweight-checkout fails because it refers to the parent branch as a plain pathname, which is then interpreted locally
<_mathrick> known?
<LarstiQ> jelmer: aha, it doesn't like my reverse dns
 * LarstiQ sent a message via launchpad and hopes that gets delivered
<LarstiQ> and now, to bed
<jfroy|work> jelmer: quick update on 0.5, no explosions so far. still watching my steps, but it is promising
<LarstiQ> jelmer: can I provide more info on bug 320113?
<ubottu> Launchpad bug 320113 in bzr-svn "svn-upgrade fails with a KeyError (in rebase generate_transpose_plan)" [Undecided,New] https://launchpad.net/bugs/320113
<jelmer> of course :-)
 * LarstiQ rephrases
<LarstiQ> jelmer: what needs to happen to move it forward? :)
<jfroy|work> LarstiQ: hum, does one need to run that command when moving to 0.5?
<jelmer> LarstiQ, is there any reason you're using svn-upgrade at all rather than just doing a clean branch ?
<jelmer> svn-upgrade should only be necessary for branches that are not yet in svn
<LarstiQ> jfroy|work: not per se
<LarstiQ> jfroy|work: but I want to use the new mappings, and branches based on the old ones don't interact with new ones. Which is very nice in that I can (and already do) have some branches be 0.5 based without biting other 0.4 based ones.
<LarstiQ> jfroy|work: however, I'd like to switch some current 0.4 ones if possible, other options would be removing them all, and just branching again
<jelmer> LarstiQ, ah, that makes sense
<jelmer> I hadn't considered that use case
<LarstiQ> jelmer: which use case?
<lifeless> jelmer: so it works without crashing for ou
<lifeless> you?
 * _mathrick regrets there's no way to branch only the history concerning specific files
<jfroy|work> So it is actually possible to concurrently use 0.4 and 0.5 on the same svn repository? I assume as long as the same "branch" is not accessed with both.
<LarstiQ> jfroy|work: yes, no
<asabil> hi all
<LarstiQ> jfroy|work: I use 0.5 and 0.4 for different 'branches' in svn, that works fine.
<LarstiQ> jfroy|work: I've also used 0.4 and 0.5 on the same branch, that also works.
<jfroy|work> LarstiQ: :o
<asabil> I am writing a plugin that involves iterating over all the "commits" from an input branch, and reapplying them on another output branch
<jfroy|work> jelmer: tip of the hat
<jfroy|work> I was worried about that.
<LarstiQ> jfroy|work: but then gets me into 320113 if I try to svn-upgrade a 0.4 one
<lifeless> asabil: isn't that rebase?
<asabil> I amnot very familiar with the bzr internals, can someone point me to a starting point please ?
<asabil> lifeless: not really, I want to rewrite the whole branch
<LarstiQ> jfroy|work: what you can not do, is communicate between the 0.5 and 0.4 branches directly with bzr. The communication has to go through svn.
<lifeless> asabil: yes, replay (in the rebase plugin) can do that
<asabil> I need to get access to the commit data
<jfroy|work> LarstiQ: right, because they likely will have divergent histories
<asabil> like the commit message and the state of the tree
<LarstiQ> jelmer: so the reason I'd like svn-upgrade, is that I don't know what my colleagues have done, and telling them to 'bzr svn-upgrade' would be easier than trying to manage it in a different way.
<LarstiQ> jfroy|work: yup, their revisions are always different.
<lifeless> asabil: anyhow, I'd look at the rebase code; or the graft code
<asabil> ok thanks
<lifeless> asabil: historic data is available via repository.revision_tree() and repository.get_revision()
<asabil> okidoki
<alf> hello all, as I was browsing the bugs I stumbled on bug #318604
<ubottu> Launchpad bug 318604 in bzr ""bzr diff" after "bzr push" does not display changes" [Undecided,New] https://launchpad.net/bugs/318604
<alf> and I got really confused about what is happening
<_mathrick> mathrick@hatsumi:~$ bzr st .emacs
<_mathrick> bzr: ERROR: .emacs is not in the same branch as .emacs
<_mathrick> what?
<_mathrick> I got this after bzr failed mid-commit due to dbus plugin failing
<LarstiQ> _mathrick: dbus failing, luckily, is post-commit
<LarstiQ> _mathrick: but it is a very sucky failure mode
<_mathrick> it still managed to bork my repo
<alf> the answers seem to find the bug invalid but I don't understand why is this
<LarstiQ> _mathrick: your working tree might be out of date
<LarstiQ> _mathrick: at least, this is from my experience
<_mathrick> LarstiQ: no, I updated it after it told me to
<LarstiQ> _mathrick: ah, bah
<lifeless> _mathrick: thats interesting
<lifeless> _mathrick: the stage it fails at is after the commit, before the update
<lifeless> _mathrick: so just 'bzr update' should unwedge things
<_mathrick> lifeless: I already did
<_mathrick> that came *after* the up
<lifeless> _mathrick: is .emacs a subdir ?
<lifeless> or a symlink?
<_mathrick> no
<_mathrick> yes
<_mathrick> oh, right
<lifeless> alf: what are you  trying to do?
<asabil> anyone here able to branch the graft plugin ?
<alf> lifeless: the bug as I understand it is: have branch X on machine A, make a copy of it (eg bzr branch) on machine B
<alf> lifeless: change/commit something in A and push the changes to branch on machine B
<LarstiQ> asabil: I do know the graft code has bitrotted
<alf> lifeless: if after push the user enters "bzr diff" in the branch on machine B nothing is printed
<lifeless> alf: thats normal
<asabil> LarstiQ: yes probably, but this looks to me like a bzr.dev bug
<lifeless> alf: 'diff' shows the current changes made in the tree - and no changes have been made on machine B
<asabil> BzrDir.sprout is called with an invalid keyword argument
<lifeless> alf: I believe 'bzr st' will tell you that the tree is out of date and should be updated
<LarstiQ> asabil: TypeError: sprout() got an unexpected keyword argument 'source_branch'
<asabil> yes
<asabil> same issue here
 * LarstiQ goes to bed
<alf> lifeless: is 'tree' something different from the set of files that are in the working directory?
<lifeless> asabil: pastebin it ?
<jelmer> LarstiQ, sorry
<jelmer> LarstiQ, I need to look into this code again, it's been a while
<lifeless> alf: its that set yes
<jelmer> LarstiQ, I'll get back to you
<lifeless> asabil: the full backtrace from ~/.bzr.log please
<asabil> yep wait a second please
<LarstiQ> jelmer: thanks
<asabil> lifeless: http://pastebin.com/d726b27c6
<asabil> removing the extra argument solves the problem btw
<alf> lifeless: bzr diff shows the changes in the tree with respect to what?
<lifeless> alf: to the basis tree
<alf> lifeless: which is different from the branch tip?
<lifeless> alf: it can be
<lifeless> alf: the branch tip is the last commit made to the branch. working trees also know the last revision they were set to (and any pending merges done too)
<lifeless> alf: the basis tree then, is the last revision the tree was set to - e.g. by 'commit' 'uncommit' 'pull' or 'push' - but the latter three operations can only change the tree when they are run locally, because remote operations introducing conflicts is bad
<lifeless> so we don't alter working trees over the network
<alf> lifeless: if I understood correctly the basis tree is stored as text (the tree contents) somewhere in .bzr/ , not only as a plain revision number
<lifeless> asabil: I think its very old format bitrot, or possibly a plugin. I'll look deeper - but could you please file a bug
<asabil> lifeless: sure, but the issue is obvious isn't it ?
<lifeless> alf: the basis tree inventory is stored in .bzr/checkout, the file texts are stored in the repository (usually .bzr/repository)
<asabil> lifeless: BzrDir.sprout () doesn't take the source_branch keyword argument, since it's the self
<lifeless> asabil: I don't know what command line options you used for instance. Bug reports are good :).
<lifeless> if you don't want to file a bug report, thats fine, I'll try to figure it out how to reproduce later.
<lifeless> but if you could file one it is extremely helpful to capture the data
<lifeless> as for the problem - the fix might be easy, but I needto track down - why didn't tests catch it, are there other old formats suffering the same issue, etc
<asabil> lifeless: ok, done: bug #321695
<ubottu> Launchpad bug 321695 in bzr "bzr branch fails with "sprout() got an unexpected keyword argument 'source_branch'"" [Undecided,New] https://launchpad.net/bugs/321695
<lifeless> thanks!
<asabil> yw
<alf> lifeless: I can't understand why we can't change just the remote basis tree (.bzr/checkout not the working tree) when doing remote operations?
<alf> lifeless: would that lead to any conflict?
<lifeless> alf: it would mean that it no longer matched the content of the users tree
<lifeless> alf: for a file F
<lifeless> there is a current basis Fb, and there is the one in the tip Ft, and the one the user has been editing, Fu
<lifeless> if the user has made changes, Fu != Fb
<lifeless> if you tell the tree that Fb is now Ft, then the user will see changes from Fu to Ft, which conflates their intended edits with the changes from Fb to Ft
<lifeless> this is bad because it makes it harder for them to accomodate the changes made by [Fb,Ft) in Fu
<lifeless> much better to let them merge or revert at their own discretion
#bzr 2009-01-27
<Peng_> The progress bars showing bandwidth usage is very cool, but why did it take 2.2 MB to download half a dozen revisions? :(
<Peng_> ...OK, a dozen revisions.
<lifeless> Peng_: from a 1.9 format repo? if not, its because the index layer in < 1.9 is quite inefficient (which is why it was replace)
<lifeless> alf: is bzr not doing something you want it to?
<alf> lifeless: I would just expect bzr diff to inform me that the tree is not in sync with the branch tip (as bzr status does)
<Peng_> lifeless: Ah, right. (It was bzr.dev.)
<lifeless> alf: ah! So the reason bzr diff doesn't do that is that its not really relevant to diff - diff is about textual changes, not overall status
<lifeless> alf: diff also doesn't show pending merges for instance
<alf> lifeless: I have (finally) understood what is going on and its necessity, I must however admit it is a bit unintuitive because of the difference in behaviour between local/remote push
<RaceCondition> is it possible to use the bzr command inside a virtualenv that has been activated?
<RaceCondition> right now it seems to me that no, but maybe there are workarounds
<lifeless> whats a virtualenv?
<RaceCondition> hmm, it works on the root level of a virtualenv, but not in a subdirectory that is a python module...
<RaceCondition> lifeless: it's a Python tool for creating virtual environments for Python installations/apps
<davidstrauss> What happens if you branch from a loomified branch?
<lifeless> davidstrauss: you get a loom
<lifeless> davidstrauss: with the state of the last record of the loom
<lifeless> RaceCondition: bzr should just work regardless, unless you're only copying in some of the bzr modules
<lifeless> RaceCondition: what error do you get?
<RaceCondition> lifeless: that bzr cannot find bzrlib
<RaceCondition> the cause of this issue is pythonpath actually
<RaceCondition> http://dpaste.com/113360/
<lifeless> RaceCondition: 'python -c "import bzrlib"'
<RaceCondition> it's different depending on which folder Python is run
<RaceCondition> I guess it's a Python matter/queston, not a bzr one
<lifeless> seems likely to me
<RaceCondition> mercurial is having the same issue
<lifeless> both hg and bzr use lazy imports
<lifeless> how does virtualenv decide what to copy in ?
<RaceCondition> lifeless: I dunno
<RaceCondition> I'm neither a Python nor a virtualenv expert
<lifeless> my guess is the lazy import nature
<alf> lifeless: Thank you for the explanation, it has been very helpful
<lifeless> alf: my pleasure
<RaceCondition> lifeless: nope, it's because sys.path actually does not contain what needs to be there
<jfroy|work> jelmer: ah, svn-upgrade is what I need if I want to move to bzr-svn 0.5 while keeping existing branches around, correct? My situation is a "trunk" branch in Subversion, a local trunk mirror Bazaar branch and a set of local and remote Bazaar branches created from that local trunk branch.
<jelmer> jfroy|work: Only for your local branches that are not in svn
<jfroy|work> none of them are besides trunk
<jfroy|work> jelmer: and what is the correct procedure? upgrade bzr-svn, wipe the cache, nuke my local trunk, re-checkout from svn, then svn-upgrade all the local trunk branches?
<ronny> *sigh*
<ronny> jelmer: i hit a whole new kind of hell now that i dont only want to have a view on stuff like branches but also getting them from remotes in the various possible flavours
<jelmer> ronny, hi
<jelmer> jfroy|work, no need to wipe the cache (unless you've used experimental versions of bzr-svn 0.5)
<jelmer> jfroy|work, no need to re-checkout from trunk
<jelmer> jfroy|work, I wouldn't use svn-upgrade atm, pending LarstiQ's  bug
<jfroy|work> OK
<ronny> jelmer: i cant find any reasonable model that fits all ways of bzr to get a repo/branch/workdir
<jfroy|work> jelmer: so I can just update bzr-svn and move along?
<jelmer> ronny, is your current interface definition up somewhere?
<ronny> jelmer: no
<jelmer> s/definition/design/
<ronny> jelmer: the whole checkout vs branch vs dir branch in repo is kina nasty cause bzr is the only one that is that "complex" there
<jelmer> ronny, I don't think it's complex
<jelmer> ronny, you basically have branches and trees, either of which can be present
<jelmer> working trees always have a pointer to some branch
<jelmer> that's it basically
<ronny> jelmer: still, hg, git, darcs do all of that more simple
<jelmer> ronny, more simple in what regard?
<lifeless> gits index is approximately our tree
<ronny> 1 repo, 1 workdir, 1 way to get it
<jelmer> ronny: Bazaar is the same, 1 branch, 1 work directory - there's also only one way to get it if you ignore checkouts
<jelmer> (which I think make sense if you do abstraction like that)
<lifeless> git can do naked repos and trees without repos too
<lifeless> you have to set environment variables though :)
<ronny> jelmer: it gets nasty as soon as i want to track multiple remote branches in a single repo
<jelmer> hi nevans
<jelmer> ronny, How would you do that in darcs?
<lifeless> ronny: I'd just ignore the repo, its not meant to be semantic; its all about branches
<lifeless> s/its/they are/
<ronny> repos are kinda important, at least for monotone, git and hg
<ronny> but those dont have brnaches as subdirs within repos, but as semantic entities
<lifeless> ronny: all quite different though
<lifeless> git branchs are refs in a repo; hg branches are unmerged revs in a single repo, and monotone branches are non-signed revs
<lifeless> bzr branches are revision ids
<ronny> lifeless: but they exist as actual entities in the fs
<lifeless> ronny: yes, thats a key design point
<lifeless> ronny: it gives them unique URL's
<ronny> lifeless: but adds massive amounts of complexity to deal with for me
<lifeless> ronny: in what way
<ronny> and i think its important enough to deal with
<lifeless> if its adding complexity for our users, we may need to change this, so I really would like to understand
<ronny> lifeless: it makes getting a repo + branches really different from the others
<lifeless> why worry about the repo
<lifeless> why not 'get branches'?
<jelmer> perhaps some background is required here
<ronny> im intrested in sets of branches
<ronny> not just one
<jelmer> ronny, this is for your work on a vcs abstraction library, right?
<ronny> jelmer: yeah
<jelmer> lifeless, ^
<lifeless> I'd ffigured that much :P
<ronny> and bzr always manages to look the most complex from *my* point of view
<ronny> at things where the others have one oblivious way i see 3 different ways that are all valid
<lifeless> its true that there are many combinations bzr supports; I think you'll find that git and hg both support the same things bzr does, but not as clearly in the UI
<ronny> and the whole standalone branch vs dir branch in repo vs checkout is my most nasty thing i see
<lifeless> which suggests to me that what jelmer said is very applicable - there is no need to represent everything in your library
<lifeless> ronny: how is it nasty for you?
<lifeless> (I'm not an ELIZA bot honest)
<ronny> lifeless: it seems very complex
<ronny> i learned dvcs with monotone
<lifeless> ronny: tree.branch.repository
<lifeless> ronny: three objects, left->right dependency so if you have tree, you always have branch and repo
<ronny> so git/hg feel rather natural, but bzr is kinda alienating
<ronny> this is mostly related to having n ways instead of just one
<lifeless> ronny: but git has more than one way! and so does hg
<lifeless> ronny: so I *fail* to understand that commend
<ronny> lifeless: git/hg have only clone there
<ronny> i fail to see how that can be more than one way
<lifeless> ronny: uhm, sounds like there are wires crossed.
<lifeless> ronny: are you talking about how to get a branch, or about the way things can be laid out on disk ?
<ronny> lifeless: how to get a branch
<ronny> or better a set of them
<lifeless> 'bzr branch' is the only command in bzr to get a branch
<lifeless> and we don't have a UI for getting a set of branches at the moment, not in the core
<ronny> a clone in git/hg (or sync in monotone) always gets me the stuff thats currently up - including tracked branches
<ronny> bascially i get my set of branches, then work on them like i need to
<lifeless> well, hg doesn't do branches in a way thats friendly to that, but sure, git does
<ronny> for me it makes no sense to limit dealing with them to exactly one at a time
<lifeless> I'd use loom or jelmers colocated plugin to do that in bzr, if I felt the urge
<ronny> colocated?
<lifeless> jelmer wrote a plugin that gives something approximating git branch management
<lifeless> I didn't think darcs did sets of branches either
<lifeless> codeville either
<jelmer> lifeless: Speaking of which, I'm still interested in feedback on the spec for that :-)
<lifeless> svn doesn't
<ronny> lifeless: darcs is kinda different
<lifeless> jelmer: on my todo
<jelmer> lifeless, cool, thanks!
<ronny> and svn is just a workdir, the branches are always remote
<lifeless> ronny: but remote branches are one per url, and a 'repo' may have thousands of unrelated things in it
<lifeless> ronny: svn's branch management is actually quite similar to bzr IMO
<lifeless> except in bzr they are typed rather than free-form (which is fugly)
<ronny> lifeless: local+remote vs only remote
<lifeless> ronny: URL based, which is all I'm talking about
<lifeless> 'bzr branches' -> list of branches
<lifeless> etc
<ronny> lifeless: i dont actually care about url's, all i need is a name
<lifeless> ronny: branch.get_nick() I think is the API, that will give you the name
<tro> lifeless: is that plugin called loom?
<lifeless> tro: which plugin?
<ronny> lifeless: thats not my issue here, its the n ways to get the thing set up as well as the different fs layout
<tro> the one that jelmer wrote to approximate git branch management
<lifeless> ronny: you say there are n ways, but I only know of one way to get a branch to work on.
<lifeless> ronny: which is 'bzr branch'
<jelmer> tro, it's bzr-local-branches
<lifeless> tro: no loom is for patch management; ^ is jelmers
<tro> ah, ok
<jelmer> tro, it mainly does multiple branches in one dir though, no tracking of remotes like git
<ronny> hmm, so its just as powerfull as hg bookmarks
<tro> that would work for me, i think. my use case is that i've got a large project that takes like 30 mins to setup in my IDE. it's not fun to branch around into separate directories because of that
<ronny> hmm
<lifeless> tro: you do know about 'bzr switch' yes ?
<tro> lifeless: yes, it's what i use, but then i have to think about where to put the repository. then when i wanna switch i have to remember what the branches are called
<tro> maybe all i need is a plugin with a "switch history"
<ronny> reminds me, i'll have to implement "switch" support too
 * igc lunch
<lifeless> tro: I see. What I generally do is just have the repo at ~/src/project, then branches under that are cheap
<tro> so i could do "bzr switch -1" to go back to the previous see branch
<tro> seen*
<lifeless> tro: for C projects I just checkout --lightweight one branch to 'working' and then swtich from there
<lifeless> tro: thats a nice idea
<tro> i'll see if i can do something about it :)
<lifeless> tro: perhaps the bookmarks plugin could grow that, writing something to the tree
<tro> i'll take a look at the bookmarks plugin, thanks
<ronny> hmm
<ronny> i'll ignore checkouts and figure a good way to deal with repos + branch dirs
<thumper> where has bzr shelve put the shelf now?
<tro> thumper: i think it's inside .bzr/checkout/shelf , if it's a checkout, anyway
<thumper> can I just move that to another checkout?
<lifeless> probably
<thumper> yep, it works
<lifeless> statik: ping
<statik> lifeless: hi
<lifeless> abentley: replied to our thread; hoping we can get consensus before you crash
<lifeless> statik: mailed you about ack ;)
<statik> lifeless: yeah, just saw it. i'll have to try bzr-search out again, but this week might be pretty tough. i'm on the wrong side of a deadline, and flying to london on saturday
 * statik pulls the latest trunk of bzr search
<abentley> lifeless: Quite a while 'till we crash, but I doubt we'll get consensus.
<lifeless> abentley: ah. Well I want to make sure I don't cause problems for lp or bb. As long as I know what those constraints are I'll be happy
<abentley> lifeless: Well, the nub of it is that I don't believe there are sane default paths for plugins.
<abentley> lifeless: There are sane paths for given clients, but they'll vary based on circumstance.
<lifeless> abentley: I believe the default should be what bzr does, because that is least confusing for users of bzrlib.
<abentley> lifeless: I believe the default should be to do nothing, because that has the least potential to explode when the user's system bzr is upgraded.
<abentley> I think that bzrlib.plugins is, itself, confusing.  Because it doesn't behave the way other packages do.
<lifeless> abentley: how does it behave differently?
<spiv> I'm a little bit uncomfortable about bzrlib doing that, it feels a bit too much like assuming bzr is the only client.  I don't feel strongly about it, it just makes me slightly nervous.
<lifeless> spiv: qualify 'that' please.
<abentley> lifeless: Importing from bzrlib.plugins imports things from directories other bzrlib/plugins
<lifeless> abentley: thats standard python functionality
<lifeless> abentley: the __path__ in the module controls the search
<lifeless> we used to have some really complex stuff, but I unified it with default python logic some time ago
<abentley> lifeless: I know how it works.  It's still unlike every other package I've encountered.
<lifeless> ok
<spiv> lifeless: doing things at import time, basically.  I think this case is likely to be just fine, it's just the sort of thing worries me slightly :)
<abentley> It is magic.
<lifeless> it was fine for years. I think a totally different change borked things
<spiv> Whatever we do, we should clearly document both how to get a typical bzr plugin path, and how to do something different that will make e.g. launchpad feel safe.
<abentley> lifeless: To me, that totally different change brought the problems with default paths to the fore.
<abentley> lifeless: That's why I submitted a patch to stop loading default paths, instead of reverting the other change.
<spiv> I am a little curious about the use case for "import bzrlib.plugins.FOO" without first telling bzrlib to configure the plugins path.  Just interactive convenience?
<lifeless> spiv: sane default, interactive convenience
<lifeless> I'd say load all plugins by default too but that makes me twitch too. (Not to mention that there is a bootstrap issue trying to do --no-plugins if we did that).
<spiv> Right, loading all plugins by default conflicts with being able to write other than bzr on bzrlib.  (And even conflicts with bzr itself, as you say.)
<spiv> Whereas this proposal just sets some configuration a certain way by default... It's still a bit weird that "import bzrlib.plugins.FOO" won't work, but "import bzrlib.plugin; import bzrlib.plugins.FOO" will.
<spiv> Or is bzrlib.plugin always imported by bzrlib?  I guess it is.
<lifeless> spiv: loading bzrlib.plugin doesn't set a path either
<lifeless> spiv: importing bzrlib.plugins sets a path of ['.'] basically, because thats what python does
<jamesh> it might be useful to have an API like "load this one particular plugin using the same logic to find it as load_plugins() does"
<jamesh> given that "import bzrlib.plugins.FOO" won't find everything
<lifeless> jamesh: there is such an api - 'import bzrlib.plugins.PLUGIN'
<lifeless> jamesh: what won't it find?
<jamesh> lifeless: I've had problems using that to find plugins in ~/.bazaar/plugins.  Has that been fixed since then?
<lifeless> jamesh: did you file a bug? They are asserted to be the same
<jamesh> lifeless: if they are under bzrlib/plugins, things work as you describe
<jamesh> lifeless: I didn't know that it was a bug.
<lifeless> jamesh: were you acting as a bzrlib client?
<jamesh> lifeless: yes.
<jamesh> if by that you mean a Python program that imports bzrlib
<lifeless> jamesh: then this is likely exactly the bug I'm talking about
<lifeless> jamesh: starting in (I think) 1.11, you have to manually set the plugins path. Which is what I want to back out.
<jamesh> lifeless: hmm.  I've got bzr-1.10 here
<lifeless> jamesh: does bzrlib/__init__ contain a call to set_plugins_path()?
<jamesh> lifeless: no
<lifeless> ok, then it was 1.10 that this got changed in
<lifeless> diff __init__.py with 1.9 :)
<asabil> what would be the best way to iterate over the revisions of a branch starting from revision 1 and preserving the merging history ?
<asabil> seems like branch.get_history () only returns the mainline rev-ids
<asabil> s/get_/revision_/
<lifeless> you'll need a topological sort
<lifeless> and you have to rewrite most of the merged nodes too because they may refer to nodes you are rewriting
<lifeless> anyhow,the tsort module is your friend
<nDuff> ooh
 * nDuff wonders if bzrlib.tsort.TopoSort is faster than the topological sort in the NX graph library he's using elsewhere.
<lifeless> nDuff: worth giving it a spin
<lifeless> abentley: /win 51
<lifeless> bah
<lifeless> abentley: I'd really like to get something that won't break lp/hitchhiker/bundlebuggy etc. I *will* be putting up a patch though, so please help me to put one up that doesn't break those other tools.
<lifeless> also, freenode fail. yay
<rockstar> abentley, you're not around are you?
<vila> hi all
<sohail> bzr version 1.11, bzr update => *** Bazaar has encountered an internal error.
<sohail>  _unpack_entry() got an unexpected keyword argument 'entry_cache'
<sohail> any ideas?
<spiv> sohail: pastebin a full traceback?
<spiv> sohail: also, maybe try --no-plugins.
<sohail> spiv, will do
<sohail> spiv, can you access https://bugs.launchpad.net/bzr/+bug/321765
<ubottu> Ubuntu bug 321765 in bzr "When executing bzr update, get error: _unpack_entry() got an unexpected keyword argument 'entry_cache'" [Undecided,New]
<spiv> sohail: looks like a bug!
<spiv> congrats ;)
<sohail> spiv, groan...
<sohail> workaround possible?
<sohail> hmm
 * sohail notices no bzr stash
<sohail> ah bzr shelve
<spiv> sohail: looking...
<spiv> sohail: that's a strange one.  I can't see the cause by reading the code, but I'd expect to be able to.
<sohail> spiv, yep
<sohail> I was looking at the code too
<sohail> no idea
<igc> hi vila
<vila> hi Ian !
<spiv> sohail: can you print the type of self in that failing _unpack_inventory method?
<sohail> spiv, ok
<sohail> spiv, so you mean print type(self) yeah?
<spiv> Right.
<spiv> igc, vila: good evening
<sohail> <class 'bzrlib.xml5.Serializer_v5'>
<sohail> that doesn't help!
<spiv> Heh, no.
<spiv> I guess I was forgetting that you were using --no-plugins, so it was hardly going to be otherwise.
<sohail> spiv, I think I may have got it?
<sohail> it should be inheriting from v7 not v6
<spiv> No, I don't think so.
<spiv> Besides, Serializer_v7 defines _unpack_entry with the same signature.
<sohail> no, v6 does not have the cache parameter
<sohail> b/c v6 inherits from v8
<spiv> You must be looking at a different 1.11 than me...
<sohail> I must be...
<sohail> hm.. wtf
<spiv> Because in mine, v6 inherits from v8 (as you say), and v8 defines _unpack_entry with the same signature as v7.
<sohail> wt
<sohail> f
<sohail> I'm using bzr from ppa or something
<sohail> I wonder if it didn't uninstall properly
<sohail> doh that must have been it
<sohail> spiv, I think that's it!
<sohail> gigantic PEBKAC
<spiv> sohail: phew :)
<sohail> wait... still checking
<sohail> yep, all good
<sohail> geez
<sohail> thanks spiv
<spiv> sohail: maybe file a bug about the packaging? :(
<spiv> Oh, d'oh, you already closed your bug just before I did :)
<sohail> spiv, no what happened was that I had the ubuntu version of it
<sohail> switched to ppa before uninstalling
<sohail> and presumably THEN removed it (or something)
<sohail> but still... it shouldn't have royally screwed up like that
 * sohail shrugs
<spiv> Yeah, neither the ubuntu or the ppa versions should do that.
 * sohail unshelves and continues
<spiv> First time I've heard of it happening!
<sohail> I'm pretty sure I did something wrong
<sohail> so unless it happens again, I'm happy
<spiv> Ok :)
<sohail> bzr shelve is quite cool
<hno> bzrtools needs to be updated in launchpad ppa.
<Lo-lan-do> Can the rebase plugin help move revisions between "unrelated" branches?
<Lo-lan-do> Use case: after the GForgeâFusionForge fork^Wrenaming, we're considering starting with a mirror of the previous SVN repository.
<Lo-lan-do> Same contents, same history, but different repo UUIDs and therefore different bzr revision ids.
<Lo-lan-do> But I'd like to graft the previous branches onto the trunk based on the new SVN repo.
<Lo-lan-do> I suppose rebase could help, but I fear it would complain about unrelated branches.  And the doc doesn't help me much.
 * Lo-lan-do tries with --onto
<Lo-lan-do> Doesn't seem to work :-/
<asabil> Lo-lan-do: try to run bzr replay
<Lo-lan-do> Aha!
<asabil> it is a hidden command from bzr-rebase
 * Lo-lan-do tries that
<Lo-lan-do> Not working either.  I get conflicts :-(
<jelmer> asabil, Lo-lan-do: replay and rebase are in essence the same thing, just different UIs
<CaMason> Is it possible to utilise 'external' branches within a project, similar to svn:externals ?
<Odd_Bloke> I just updated to bzr HEAD and am impressed with the new pull output.  So kudos to whoever did that. :)
<Odd_Bloke> jelmer: Do you have your subvertpy packages available anywhere?
<jelmer> Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/bzr-svn/debian
<jelmer> ehum
<jelmer> Odd_Bloke, yes, http://people.samba.org/bzr/jelmer/subvertpy/debian :-)
<jelmer> Odd_Bloke, there's also packages uploaded to the subverpty PPA and NEW
<jelmer> CaMason, that's nested branches, which have been stalled for a while
<Odd_Bloke> jelmer: Yeah, I saw them in NEW.  But I don't want to have to wait. :p
<asabil_> how can I create a commit with 2 parents using bzrlib ?
<jelmer> Lo-lan-do, the problem is that the file ids are still different even if the revision ids are not
<jelmer> Lo-lan-do, bug 231674
<ubottu> Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674
<jelmer> asabil: You can specify the parent ids to the commit function
<Odd_Bloke> jelmer: Thanks. :)
<jelmer> asabil_: You can specify the parent ids to the commit function
<jelmer> Odd_Bloke, just "bzr builddeb http://people.samba.org/bzr/jelmer/subvertpy/debian" should build you a package
<asabil_> ok thanks jelmer
<hsn_> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<asabil> can someone help me with this code: http://pastebin.com/m315e7782
<asabil> after a while I get the following error:
<asabil> bzr: ERROR: Working tree is out of date, please run 'bzr update'.
<hsn_> http://paste.ubuntu.com/110254/ - i can not get bzr shelve work in 1.10 or 1.11, it reports same error
<asabil> hsn_: run bzr break-lock
<Lo-lan-do> jelmer: That makes sense.  I guess I'll go the old way then, and apply diffs by hand.
<hsn_> asabil: it doesnt help, after breaking lock i will get could not obtain lock error again
<vila> jelmer: did you see my comment on bug #256612
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612
<jelmer> vila, could we do password prompting for 401 responses?
<vila> err, we already do password prompting for 401, are you asking for *user* prompting instead ?
<vila> jelmer: anyway, that would be a different problem, 256512 is about getting the credentials from svn when we connect to a svn server
<jelmer> vila: ah, I wasn't aware we did password prompting already
<jelmer> I'll have a look at the svn side of things
<vila> I'm pretty sure we fail right now because we have no *user* to provide which a svn credential store plugged into authentication.conf *can* provide
<vila> from there bzr can prompt for password, fail its probe, fall back to bzr-svn probe, which finally can succeed
<vila> That's the scenario you and I identified months ago for which there was no good solution. Remember that ?
<hsn_> my error is same as this: https://bugs.launchpad.net/bzr/+bug/305006 - so its currently fix commited to devel bazaar version?
<ubottu> Ubuntu bug 305006 in bzr "shelve fails with "Could not acquire lock"" [Undecided,Fix committed]
<asabil> jelmer: any idea about my code ?
<jelmer> vila, yeah
<jelmer> asabil, which code?
<asabil> http://pastebin.com/m315e7782
<asabil> I am trying to rebuild a branch from another branch
<asabil> in the same way that bzr-rebase does
<asabil> and it fails when it encounters a merge
<jelmer> any reason for not just using rebase?
<jelmer> asabil, How does it fail?
<asabil> jelmer: I am trying to write bzr filter-branch
<jelmer> asabil, ah, cool
<asabil> it fails asking for update to be ran
<asabil> when I add tree_to.update () before the commit
<asabil> it fails with conflicts
<jelmer> asabil, why whould you be calling update() ?
<asabil> jelmer: its asks for it
<james_w> I don't think you actually need to *do* a merge do you?
<asabil> james_w: I just copied what bzr-rebase does
<james_w> do you not know what the tree of the revisions is supposed to look like at each point?
<asabil> I do know
<james_w> you can just put the tree in that state and use "tree.set_parent_ids()" and then commit in that case
<asabil> james_w: and how can I put it in that state ?
<asabil> sorry I am not yet familiar with theses apis
<james_w> well, that depends on where you get the information from
<james_w> presumably you check out the old revisions tree
<james_w> apply the filter-branch transform on it
<james_w> and then commit the result
<asabil> I just need the no-transform case for now
<asabil> I will find my way later
<james_w> for a merge it will be the same thing, but you set an extra parent or three on the working tree before committing
<james_w> ok, just checking it out and committing
<james_w> though I see your point now, I'm not sure what the API is for checking out the old revision tree in to the new working tree
<james_w> vila: is RedirectRequested something new?
<asabil> that's what I am looking for
<vila> james_w: no
<vila> james_w: I think it's even pre-1.0...
<james_w> vila: hmm, my transport.do_catching_redirections code appears to have just broken
<james_w> e.get_target_url()
<james_w> AttributeError: 'RedirectRequested' object has no attribute 'get_target_url'
<vila> wow, where are you using such code ?
<LarstiQ> vila: is ~/.netrc supposed to work for regular sftp:// and bzr+ssh:// usage yet?
<james_w> vila: in a plugin(ish)
<vila> james_w: ouch, I may have broken backward compatibility then, but on the other hand there was several bugs there
<james_w> I need to follow some launchpad redirects to get the librarian url for some files I need
<james_w> vila: no problem, this code is only running in one place, so it's not difficult to fix
<james_w> vila: do you know off-hand what the new way of doing that would be?
<vila> james_w: give me a minute to page-in the code
 * vila 's memory acess times is in the minute range... what a shame
<james_w> vila: thanks. I can search if you are busy with something else
<jelmer> vila, what sort of settings should I expect in the credentials dictionary ?
<vila> james_w: bzr diff -c3903 in trunk should be the most helpful for you
<vila> jelmer: you mean when credential_store.decode_password is called ?
<jelmer> vila, yeah
<james_w> vila: perfect, thanks
<vila> you should have host, user, password, the later can be None,
<vila> optionally path can be present and scheme could be there too
<jelmer> vila, what about realm?
<vila> jelmer: you get the section defined in the authentication.conf file, if the user put a realm, you get it
<jelmer> vila, yeah, but the HTTP implementation will be prompting my credentials provider
<jelmer> vila, ideally without a section in authentication.conf
<vila> jelmer: I don't parse that
<jelmer> vila, So when a user connects to a svn http server, the http server will send back a 401
<jelmer> that will prompt bzr to look for credentials
<vila> the http client will then query authentication.conf
<jelmer> and will ask all the credentials providers for credentials for that server
<vila> that's not how it works
<jelmer> ok, in that case I misunderstood
<vila> The user decides where he wants to put his credentials, he declares that through authentication.conf
<vila> There is no way to say: spread my credentials here and there
<jelmer> so the user can't use more than one credentials tore?
<vila> He can, but only one by section in authentication.conf
<vila> Actually that's wrong: "There is no way to say: spread my credentials here and there"
<vila> That's even the purpose of authentication.conf, I should have say: we don't query credential stores blindly, the user tell us how
<jelmer> that just means the user has to edit authentication.conf for every svn repository they connect to
<jelmer> even if they already have credentials for that repository in ~/.subversion/
<vila> Well, authentication.conf uses a 'first match wins' rule, so you can define a fallback section with svn as the credential store
<jelmer> yes, but in that case you can't really use netrc as well
<vila> ...except you'll need the actual url in that case (or usr/host/realm/path already splitted)
<jelmer> vila, I would expect the netrc credentials provider to do the splitting in that case
<vila> jelmer: meh, the nertc provider is onvoked only if people mentioned it in authentication.conf
<jelmer> vila, Yeah, but I think that's wrong too
<jelmer> one of the nice things about netrc is seamless integration, and being able to use your existing stored credentials
<jelmer> having to set things up in authentication.conf per host just defeats that
<vila> you can set things up by scheme, host, host+port, many combinations exists
<vila> you can set things up by scheme, host, host+port, many combinations exist
<LarstiQ> aha
<vila> That's the whole point of authentication.conf, it can even be used for smtp
<LarstiQ> I have to mention netrc in authentication.conf?
 * LarstiQ tries that
<jelmer> yes, but the point is that you have to set up something in authentication.conf, most likely for each host
<LarstiQ> jelmer: I use [DEFAULT]
<vila> scratch that 'most likely' :-)
<vila> There is more than one way to use it :)
<jelmer> vila, I don't think it's that easy to scratch
<vila> You can even set by domain
<LarstiQ> vila, jelmer: so if I understand it correctly, it would be nice to try the svn credential store for svn, even if not explicitly mentioned in authentication.conf, but that is not currently possible?
<jelmer> I have different usernames on different hosts, and even some hosts with and without Subversion
<jelmer> LarstiQ, yes
<jelmer> LarstiQ: and for the netrc store
<LarstiQ> vila: scheme won't work for bzr-svn because you can't distinguish http bzr and http svn?
<jelmer> LarstiQ, yes
<vila> LarstiQ: yes
<vila> jelmer: you can even set by user/host
<jelmer> vila, yes, but that requires configuration in authentication.conf
<jelmer> which is unnecessary imho
<LarstiQ> vila: it is not clear to me from http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html how to tell authentication.conf to use .netrc
<vila> jelmer: explicit is better than implicit for credentials, especially since we are not trying to address storing crentials securely, delegating that to extrenal credentials stores
<LarstiQ> brb, will check the code after that
<vila> and since that will be externalized, user must have control over it
<LarstiQ> vila: yes but, for svn, isn't it rather obvious to try the svn credential store always?
<vila> LarstiQ: So because svn is a special case we should change the general case ? Or should we provide some hook for svn purposes instead ?
<vila> jelmer: the whole purpose of authentication.conf is to give user control over which credentials to use when, if you don't need that, fine, don't use it, but leave the user the option to use it
<LarstiQ> vila: I don't think svn is a special case actually. For ssh/sftp, I'd also expect to try ~/.ssh/config
<jelmer> vila: it means users will *still* be confused when they try to use https://
<vila> LarstiQ: ssh is out of scope as said in the spec :)
<jelmer> vila, also because it doesn't prompt for a username
<vila> jelmer: prompting for user is a different problem, it can be wprked around so far by specifying the user in the url, so we can neglect it in this discussion
<LarstiQ> vila: ah hmm, does that explain why my [DEFAULT] authentication.conf setting is not helping me with sftp:// ?
<vila> LarstiQ: did you try -Dauth ?
<LarstiQ> (it does actually work for bzr-svn)
<LarstiQ> vila: no, good point
 * LarstiQ goes off and tries
<jelmer> vila, that's more specifically where this bug is about imho
<jelmer> vila, if you specify a username atm you'll just be prompted a couple of times
<LarstiQ> vila: 0.592  Using authentication section: 'DEFAULT'
<LarstiQ> 0.720  ssh implementation is OpenSSH
<jelmer> no 401 error
<LarstiQ> vila: not really helpful
<jelmer> hi poolie
<vila> LarstiQ: if you try to use auth.conf for passwords you should get a warning, using for users should work
<LarstiQ> vila: I get no warning.
 * LarstiQ is on bzr.dev r3958
<vila> LarstiQ: Strange, I'm a bit lost here, I *think* either the ssh client thinks it can authenticate without password or should query auth.conf and issue a warning
<LarstiQ> vila: I'll try to debug it further
 * LarstiQ afk for a bit
<vila> jelmer: regarding "if you specify a username atm you'll just be prompted a couple of times", that's the precise point I want to address, the yse should be queried at most once
<vila> once the http connection is set, we should be able to share it without having to prompt again
<LarstiQ> right
<LarstiQ> vila: but, I'd like to be prompted again if I mistype my password. Though not infinitely.
<jelmer> vila: That's not what this bug report about though, it's about users getting "Unable to handle 401" when they are trying to contact a authenticated http server and are not specifying a password.
<vila> Whether that can be achieved in a single bzr command may be a bit ambitious right now, but at least issuing an svn command should populate some credetial store that can then be resued y bzr
<jelmer> vila: bzr-svn will already use authentication.conf
<vila> jelmer: the point is to have a svn-specific credential store that can *provides* the credentials that svn knows about
<vila> that's where netrc is an *example* on how to implement one for svn
<jelmer> vila: the point of this bug report? in that case the bug report would be "bzr asks for a password more than once"
<vila> ghaa, let's start again
<jelmer> vila: There's no point in having a svn-specific credentials store with the current API; the use in having that would be seamless integration, but that's pointless if there's additional configuration required.
<vila> jelmer: I agree we disagree: I think there is value in having the ability to say "I want to use svn credentials for these sections, not for these" if only as a way to get rid of cruft
<jelmer> vila: I see *some* use in that, I don't think that's what this High-importance bug is about
<vila> jelmer: I'm not *against* allowing bzr-svn to be a fallback for authentication.conf if you want seamless integration
<vila> That's two different use cases
<jelmer> ok
<vila> jelmer: When we diagnosed the root cause together, the consensus (as I remembered it) the bug was that bzr was stopping to query other formats because it couldn't authenticate
<jelmer> I think we can agree about that, actually - I still don't think this is the "unknown 401 response" bug
<vila> that is the cause I try to address here, not querying for user is another bug in my mind
<vila> and it appears my mind is wrong
<vila> since bug 216614 is a duplicate, I thought it was still stnding on its own
<ubottu> Launchpad bug 216614 in bzr "should not immediately abort of .bzr/format can't be opened (dup-of: 256612)" [Undecided,Incomplete] https://launchpad.net/bugs/216614
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,In progress] https://launchpad.net/bugs/256612
<jelmer> ah, ok
<jelmer> I'll open a separate wishlist bug about allowing to query other stores without additional configuration
<jelmer> does that sound reasonable?
<vila> so if we can't share these credentials, the user is prompted, the result thrown away before svn provides the right ones automatically and we still get bug reports :)
<vila> jelmer: sounds reasonable *too*
<vila> At least we could discuss it separately
<jelmer> vila: Yeah, I think that would be a good idea
<vila> jelmer: pfew :)
<jelmer> vila: Ok, I've got the credentials store implemented
<vila> jelmer: So, to clarify, my initial question regarding my comment... lol
<vila> exactly, thanks,
<jelmer> vila: I'm not seeing any of the other keys from my section in authentication.conf
<vila> where ?
<jelmer> vila, it would be nice to get the realm the http server sends available somehow
<vila> right, I may have been wrong in my previous comments, that can be considered a bug in the actual implementation
<vila> it should provide more context
<vila> i.e. the actual url (and realm for http) for which the query is done
<jelmer> yeah, that would be nice - Subversion uses the realm as key, so I need that to do the querying
<jelmer> should I file a bug about that?
<vila> right, just checked it, the actual implementation provides only user and section name (that can be used to get the whole section if needed) but it should also provides the actual context
<vila> jelmer: yes, do so, I'll fix asap
<vila> in fact I think it's buggy for netrc too, the tests are probably too restrictive
<vila> jelmer: apart from the realm what is used for the key ?
<jelmer> vila: realm and optionally username
<vila> no host ? no path ?
<vila> no port ?
<vila> no scheme ? :-)
<jelmer> vila: sorry, host/port as well
<jelmer> they're included in the realm in a specific format
<vila> ok, host/port/realm and no path then ?
<jelmer> e.g. "<http://svn.collab.net:80> Subversion Committers"
<jelmer> yeah, no path
<vila> ok, good
<vila> So that you can use different user by using different realms and you don' care about path
<jelmer> vila: I also think the keyring support in GNOME would be another good candidate for Bazaar querying all credentials stores
<jelmer> vila: Since that will require you to confirm (using a GUI thingy) when you're using one of its credentials
<vila> jelmer: I'm going step by step here because I've yet to define how we want to *save* credentials from bzr
<vila> If you can imagine querying them all to *find* credentials, you don't want to do that to save them
<jelmer> yeah, that makes sense
<vila> And if you want to be explicit about where to save them, not doing it to find them will lead to surprising behaviors
<jelmer> well, it would depend on the ordering you use I guess
<jelmer> Subversion would be a candidate for fallback credentials - you should never have to store new credentials there
<vila> I try to take the most paranoiac users into account there, that means being explicit
<jelmer> and it would only have to be queried if all else has failed
<vila> jelmer: agreed for svn being a fallback
<jelmer> vila: For gnome-keyring I would personally want to use that as an alternative to authentication.conf, so not using authentication.conf at all
<vila> jelmer: once we figure a way to handle the explicit cases, finding ways to make them implicit should be easy
<vila> but, yes, back in the early days of auth.conf, I looked into gnome-keyring and OSX keychain as credential stores and I realized they have different APIs so I tried to provide a single point where any user will have a minimal setup to do in auth.conf. making the minimum == 0 is the holy graal :)
<vila> For example, I can imagine people going from svn to bzr on the same host yet wanting to use different users for their svn repo and their bzr repo
<vila> I can also imagine they want to *keep* the same user though
<jelmer> vila: They should be able to differentiate by including the username in the URL
<vila> jelmer: yes, but we want to get away from embedding user in urls so that people can share urls
<vila> :)
<jelmer> vila: ah, hmm
<jelmer> ok, my SubversionCredentialsStore works if I hardcode scheme, port, host and realm \o/
<vila> jelmer: sorry, I should have told you that :-/
<vila> errr, no, I think I don't understand *why* that succeeds in fact :)
<jelmer> (this is with configuration in ~/.bazaar/subversion.conf)
<jelmer> argh
<jelmer> (this is with configuration in ~/.bazaar/authentication.conf)
<jelmer> I've hardcoded those variables in config.py, not in the configuration file
<vila> ha, good :)
<vila> So that means you know how to *query* svn credentials ! Great, that's the part I missed !
<phinze> so how do you #bzr people maintain your local file structure
<phinze> specifically, how do you organize mirror and task branches
<jelmer> I have one repository per project
<jelmer> and then various branches in there, mixing mirror and task branches (usually I name the mirror branches after the people they're from)
<phinze> so all your branches just sit in the root of the local repo then?  you don't mirror the directory structure of any shared repo
<jelmer> phinze, no
<jelmer> phinze, I mean yes to your first question, no to the second
<phinze> jelmer: yeah sorry making it difficult for you :)
<phinze> okay, so are your mirrors branches or checkouts
<jelmer> vila: Yeah, I did the work for that already a bit earlier.
<jelmer> phinze, branches
<phinze> sounds good, thanks for giving me a use case :)
<vila> jelmer: where can I have at look at that ? 0.4 ? 0.5 ?
<jelmer> vila: 0.5, auth.py
<vila> jelmer: thanks
<jelmer> vila, if you need a good test repository: http://chaina.tigris.org/svn/chiana/trunk
<jelmer> (user: guest, password: guest)
<vila> jelmer: great, copying that in due place
<tro> why is it that branching is so much faster in git than in bzr? is it because git doesn't do any copying?
<Jc2k> tro: you need to give more context than that
<tro> Jc2k: just a simple branching op. git is almost instant. bzr takes a while. does git not make any copies of WT files?
<Jc2k> if you dont use a shared repository branching is like git clones with --local --no-hardlinks
<Jc2k> and if you dont use a shared lightweight copy then it copies the WT files
<Jc2k> so its a double hit
<tro> oh i see. what's a shared lightweight copy? a lightweight checkout from a shared repo?
<Jc2k> yes
<tro> my use case is windows with a large tree (i think around 10k files). so no hardlinks :(
<Jc2k> make sure your share repo has --no-trees, or you'll still get duplicated WT's and it will be slow
<Jc2k> *shared
<tro> right. that's what i've got.
<Jc2k> then it should be quick
<tro> so a lightweight checkout/switch would be faster, right? my shared repo is local.
<Jc2k> yes
<tro> thx
<Jc2k> theres a plugin somewhere to help you with this layout.. let me find you the link..
<Jc2k> tro: https://lists.ubuntu.com/archives/bazaar/2009q1/051801.html
<Jc2k> tro: that plugins gives you a 'start' command which is like branch and switch in one swoop
<tro> oh cool. thanks.
<Jc2k> tro: also http://theironlion.net/blog/2009/01/23/more-advanced-bazaar-concepts/
<Jc2k> (tho that post is a little different to what you want, you can adjust it easily enough)
<poolie> jam, if you're around, re debug flags
<jam> morning poolie
<poolie> did you mean you wanted me to add a new test, or just that i might have broken an existing one?
<jam> poolie: sorry, I thought you might have broken an existing one
<poolie> i might
<poolie> i ran the obvious tests, doc, help etc
<luke-jr> jelmer: 0.5 rc 2 anytime soon? :/
<jelmer> luke-jr, 3 more bugs to fix
<luke-jr> :/
<jelmer> luke-jr: Nothing should be blocking you from using the 0.5 branch though..
<luke-jr> it's not packaged
<jelmer> luke-jr, Not packaged for what?
<luke-jr> Gentoo
<luke-jr> crap, none of those 3 look easy enough for me â¹
<luke-jr> actually, I was assuming the Triaged
<jam> poolie: "test_osutils.py" around line 1504
<jam> poolie: TestResourceLoading.test_resource_string
<jam> also, poolie, what do you think about the "remove whitespace bandaid" patch. Should we land it now or wait for a release?
<poolie> i think now
<poolie> ah you're right
<fullermd> Hm.  Progress bar seems to have some interactions with commands that print out stuff while they're running through the bars.
<fullermd> e.g. running info on the main bzr.dev branch.
<ollie> ahh i am going around in circles with bzr mv bzr: ERROR: Could not move awards_entry_form.php => awards_entry_stage1.php: system/application/views/forms/awards_entry_stage1.php is already versioned.
<fullermd>   repository branch: http://bazaar-vcs.org/bzr/bzr.dev/
<fullermd> \      1kB @    0kB/s
<fullermd> Related branches:
<fullermd> ollie: Well, if the new location is already a versioned file, you can't move an old file to the same place.
<fullermd> What are you wanting to accomplish?
<ollie> bzr rm --keep awards_entry_stage1.php: system/application/views/forms/awards_entry_stage1.php
<luke-jr> jelmer: any ETA on those 3 bugs?
<ollie> bzr mv --after system/application/views/awards_entry_form.php system/application/views/forms/awards_entry_stage1.php
<ollie> bzr: ERROR: Could not move awards_entry_form.php => awards_entry_stage1.php: system/application/views/forms is not versioned.
<ollie> don;
<jelmer> luke-jr, about a week probably
<ollie> don't get it firstly it tells me it is already versioned so i guess it needs to be unversion
<ollie> so i unversion it and it tells me it is not versioned!
<luke-jr> :/
 * fullermd frowns.
<luke-jr> jelmer: happen to recall the rev that fixed the bug I need?
<jelmer> luke-jr, I'm not sure which bug that was, sorry
<jelmer> luke-jr, you should be able to just checkout bzr-svn in your ~/.bazaar/plugins
<luke-jr> jelmer: somethign about it not liking tags
<ollie> fullermd: i have renamed a file so i want to tell bzr the file has moved so i keep its history
<luke-jr> jelmer: cd ~/.bazaar/plugins && bzr co lp:bzr-svn ?
<jelmer> luke-jr: Yeah
<fullermd> Note that it's talking about the dir the second time, not the file.
<fullermd> Doesn't seem to make sense...
<ollie> but i can't version a dir without adding its contents..
<fullermd> Well, of course you can.  You just can't version its contents without versioning it.
<fullermd> So if _entry_stage1.php were versioned, forms/ would have to be.  But you only unversioned the .php (unless you're skipping steps in the explanation), so forms/ should still be.
<luke-jr> jelmer: after renaming it to 'svn', 'bzr branch' errors out immediately
<ollie> cracked it :)
<ollie> so i have to unversion each file manually
<ollie> but keep the dir versioned
<luke-jr> http://pastebin.com/m7f856376
<fullermd> Right.  Can't move into a dir that isn't versioned.
<luke-jr> jelmer: curiously, I don't see the warning on line 79 anywhere
<jelmer> luke-jr, I've pushed a fix
<jelmer> luke-jr, http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<luke-jr> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.5/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<jelmer> luke-jr, you'll need to use "bzr branch" rather than "bzr co"
<jelmer> (I thought that bug was fixed?)
<luke-jr> :/
<luke-jr> oh, maybe 'bzr pull' doesn't work in a 'bzr co'
<luke-jr> which makes sens
<fullermd> Well, I'm pretty sure it _works_...
<jelmer> ah, in that case it makes sense
<fullermd> Just doesn't do what you're trying to do in this case   :p
<jelmer> if you run "bzr pull" it will try to update the master branch as well
<jelmer> and you don't have write access to the master branch
<luke-jr> âº
<luke-jr> ugh, bzr branch is so slow
<Lo-lan-do> Use git then.  Oh wait, you can't, git people don't care about interoperability.
<luke-jr>   File "/home/luke-jr/.bazaar/plugins/svn/__init__.py", line 100, in <module>
<luke-jr>     from bzrlib.plugins.svn import format, revspec
<luke-jr> ImportError: cannot import name format
<jam> poolie: care to chat a bit about the code.python.org email?
<jelmer> luke-jr, Please have a look ~/.bzr.log
<luke-jr> jelmer: curiously, the ~/.bazaar one seems to break the main install too
<luke-jr> jelmer: it says the same thing
<luke-jr> should I remove the system bzr-svn?
<jelmer> luke-jr, pushed another fix
<jelmer> luke-jr, any chance you can try with that (pushed to the samba.org location)
<luke-jr> curiously, I couldn't even 'bzr info/pull' without moving it out of the plguins dir
<luke-jr> jelmer: ok, now I get bzr-svn: at least subvertpy 0.5.0 is required
<luke-jr> jelmer: subvertpy is part of bzr-svn tho ;)
<jelmer> luke-jr, no, it's a separate package these days
<luke-jr> it was in rc1 :/
<jelmer> luke-jr, Yes, but no longer
<luke-jr> lp:subvertpy ?
<jelmer> luke-jr, yep, or one of the tarballs
<luke-jr> ugh, it won't work from ~/.bazaar/plugins
<jelmer> no, subvertpy isn't a plugin
<jelmer> you need to install it
<luke-jr> it's not packaged
<luke-jr> any reason it won't work if I put it inside plugins/svn/ like it used to be?
<jelmer> I removed the support in bzr-svn for supporting that - it extended the python system path, slowing imports down
<luke-jr> sigh
<jelmer> Lo-lan-do, is there any chance of having a newer bzr installed on alioth?
<luke-jr> ok, reverted that
<luke-jr> Unable to load plugin 'svn'. It requested API version (1, 11, 0) of module <module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 7, 0), and the maximum is (1, 10, 0)
<luke-jr> :/
<jelmer> luke-jr, yes, you need at least bzr 1.11
<luke-jr> sigh
<jelmer> luke-jr: alternatively, you can wait for bzr 1.12 and bzr-svn 0.5.0 to be released/packaged
<luke-jr> â¦
<luke-jr> if I wait for those do I get copy support? ;)
<jelmer> (-:
<luke-jr> it's a pain to push, svn checkout, svn commit, pull, all just to make a copy :/
<luke-jr>   File "/home/luke-jr/.bazaar/plugins/svn/__init__.py", line 159, in lazy_register_optimizers
<luke-jr>     if _optimizers_registered:
<luke-jr> NameError: global name '_optimizers_registered' is not defined
<luke-jr> (this is in my bzr-svn test stuff, branch of a file:/// URI
<fullermd> Man, I hate trying to read diff when a lot of binary files are involved   :(
<jelmer> luke-jr, one sec
<jelmer> luke-jr, that's caused by my ad-hoc fixes for you earlier
<luke-jr> heh
<Lo-lan-do> jelmer: I'm fine with backports in general, but I'm a bit iffy about using stuff from experimental on etch.
<jelmer> luke-jr, please try again
<luke-jr> jelmer: fwiw, that error exists even with a regular svn+http thing
<jelmer> luke-jr, sorry, forgot to push. pushing now
<jelmer> luke-jr, yeah, it was just a typo I introduced
<jelmer> Lo-lan-do, I can upload to backports if that helps
<jelmer> luke-jr, r2412
<luke-jr> ok, it's trying now
<luke-jr> jelmer: so is there plan for per-file revisioned metadata for bzr?
<luke-jr> or perhaps more appropriate for copy-simulation would be per-file unrevisioned metadata, but that's easily simulated by not changing it ;)
<jelmer> luke-jr: there already is per-file revision metadata (e.g. name, executable bit). There are no plans for per-file custom revision metadata.
<luke-jr> i c
<luke-jr> so how would you store extended attributes? ;)
<luke-jr> jelmer: branch successful
<luke-jr> now if only copies worked, I could drop the constant VPN link ;)
<jelmer> heh
<beuno> deos anyone know hot so use bzr+ssh in a different port?
<pickscrape> Does anyone have any idea when bzrtools 1.11 will make it into the PPA?
<fullermd> beuno: bzr+ssh://foo:12345/some/path/ ?
<pickscrape> beuno: is what fullermd said doesn't work, could ~/.ssh/config help at all?
<pickscrape> s/is/if/
<Lo-lan-do> jelmer: That would be nice, yes.
<beuno> fullermd, ay...  thanks
<aboSamoor> HI, my bandwidth is very bad and it disconnects frequently I got this message after breaking a push process "If you're sure that it's not being modified, use bzr break-lock lp-46717904:///~rmyeid/+junk/code/.bzr/branch/lock"
<fullermd> (in checking it myself, I discover that ssh doesn't die very quickly if you point it at a SMTP-speaking port   :P)
<Peng_> aboSamoor: "bzr break-lock lp:~rmyeid/+junk/code"?
<aboSamoor> Peng_: Thanks very much. so why the message add number to the lp ?
<garyvdm> aboSamoor: It's logged as bug 250451
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/250451/+text)
<garyvdm> https://bugs.launchpad.net/bzr/+bug/250451
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed]
<garyvdm> Hi - Is there a way to increase the allowed number of Concurrent Requests for the smart protocol?
<garyvdm> Let me explain why: In qbzr I'm now displaying the transport activity. When the transport activity gets updated, I call processEvents, which causes the QT event loop to cycle.
<garyvdm> I was testing this with Andrews branch that displays the transport activity for the smart protocol. (http://people.ubuntu.com/~andrew/bzr/traffic-smart/)
<garyvdm> So if qbzr is loading somthing, and you do something else though the user interface that causes something else to be loaded, to get a TooManyConcurrentRequests error.
<asabil> anyone knows the API to use in order to copy an old revision tree into a new working tree ?
<jelmer> asabil: rebase has a function to do a complete revert
<jelmer> asabil, you can do a "set_revision()" call followed by that call
<asabil> jelmer: maybe my question wasn't clear
<asabil> as I said earlier I am working on filter-branch for bzr
<asabil> and I just want to create a new branch based on an old branch with no transform operation for now
<asabil> I just don't know how to recreate new commits identical to the ones from the source branch
<asabil> but with a different revid
<james_w> asabil: revert is the correct operation I guess
<james_w> revert is "set the working tree to be the same as this revision tree"
<asabil> hmm ok
<asabil> so I should use the code from bzr-rebase ?
<james_w> give it a go
<asabil> oki thanks for the help
<james_w> or just lookup what the revert builtin does
<asabil> ok thanks
<jelmer> asabil: I would imagine bzr-rebase and bzr-filter-branch share a lot of code, I think it makes sense to have them in the same plugin
<jelmer> (maybe we'll need to rename that plugin)
<asabil> jelmer: yes they will, but I am still experimenting for now :)
<asabil> I would be really happy to add filtering to bzr-rebase
<asabil> I am not very familiar with the bzrlib APIs
<fullermd> How are you defining what to adjust in the filtering process?
<asabil> it is not really filtering
<fullermd> (from a user perspective, I mean)
<asabil> but more like copy-and-modify
<asabil> for now I would like to be able to apply a filter on commit messages to rewrite them
<asabil> fullermd: not sure if I answered your question :)
<fullermd> Not exactly, no.  I mean "How do I as a user of filter-branch specify what to change?"
<asabil> I will probably go for the same solution as git-filter-branch
<asabil> something like
<asabil> bzr filter-branch source destination --message-filter="sed -i -e 's/hello//'"
<fullermd> Ah.
<asabil> it is not optimal, but still, it will be useful enough for most users I guess
<fullermd> I have this occasionally-recurring idyll that it would be kinda fun (in my CFT of course) to try designing a somewhat VCS-agnostic grammar for describing history rewrites like that.
<asabil> hmm, that would be a good idea indeed
<fullermd> (at least general enough to handle the general class of DAG-history VCSen, anyway)
<fullermd> Yah.  Could be pretty useful.  And I think it'd be a fun thing to play with.
<fullermd> I currently have it scheduled to do after I deal with some more urgent things on my todo.
<fullermd> Which means it's currently scheduled for spring 2075...
<asabil> rofl
<bialix> you're immortal I guess
<fullermd> I am indeed.
<fullermd> So far, so good.
<bialix> anybody saw LarstiQ here today?
<fullermd> 6 hours ago or so...
<bialix> heh
<bialix> fullermd: did you made bzrtools package for FreeBSD?
<fullermd> I didn't make it, but I'm the current maintainer of the port, yah.
<fullermd> (packages are auto-built from the port; I don't have any direct control over that)
<bialix> yeah, thank you. I know you're take care about bzr @ FreeBSD
<bialix> so  have the luxury to use bzr at my hosting
<bialix> I have the luxury
<fullermd> It's 'cuz I'm too impatient to wait for someone else to get around to updating it when new releases come out   ;)
<bialix> can you suggest me the link for bzrtools @ FreeBSD? so I can nag my hoster to install it
<fullermd> It's in ports/devel/bzrtools/, next to bzr at devel/bazaar-ng/
<bialix> oh, indeed. I'm not very smart
<bialix> great
<fullermd> The bug thread earlier today about the package depends in Ubuntu did make me think about whether the graphviz depend should be on by default...
<fullermd> Maybe I'll flip that next time there's a release.
<bialix> what's the filter-branch discussed here earlier?
<bialix> asabil?
<asabil> james_w: using tree.revert complains about unversioned files
<asabil> bialix: a small proof of concept plugin, to be able to generate new branches from an old branch
<asabil> by applying transforms
<bialix> asabil: does your code public already?
<asabil> (changing commit message, removing files ...)
<bialix> I'm interesting in such plugin
<asabil> no it is not working at all yet
<jelmer> asabil, Did you try the complete_revert () from rebase?
<asabil> I am still diving into the bzrlib APIs
<jelmer> fullermd, I've already done that for Debian
<asabil> jelmer: I am not sure how to use it
<bialix> I need the way to factor some subdir out of the branch
<jelmer> fullermd, since it was pulling X libraries on servers, etc
<asabil> why does it take newparents as a parameter ?
<bialix> but instead of split I'd like to copy only relevant history
<bialix> asabil: does your plugin will allow this?
<asabil> jelmer: for revision 1, the parents is []
<asabil> bialix: it is inexistant yet, I will release it asap
<fullermd> jelmer: Yah, that was what I was reading   ;)
<bialix> yep, I understand. I'm just trying to understand what it will an what it won't
<asabil> bialix: it is more of the other way around, but it will sort of allow you to do such things
<jelmer> asabil, it resets to the contents of parents[0] and sets the other parents as pending merges
<asabil> jelmer: and how to handle the 1st commit ?
<jelmer> asabil, the empty tree you mean?
<jelmer> asabil, [NULL_REVISION]
<asabil> doesn't work
<asabil> ERROR: Reserved revision-id {null:}
<jelmer> oh, that would need special casing then I guess
<jelmer> revision_tree() ?
<asabil> jelmer: ok I special cased it and it does work :)
<asabil> thanks a lot
<asabil> I will just need to make the tree.commit () shut up
<asabil> and it will be awesome
<jelmer> asabil, any chance you can send a patch for that to bzr-rebase?
<asabil> thanks a lot :D
<LarstiQ> bialix: heya
<asabil> jelmer: the special casing for complete_revert ?
<bialix> heya!
<jelmer> asabil, yeah
<jelmer> hey LarstiQ
<asabil> yes sure, will do
<asabil> I just have to run right now
<jelmer> ooh, LarstiQ and bialix here at the same time
<asabil> will work on it this evening
<asabil> ttyl
<jelmer> asabil, thanks!
 * LarstiQ starts up his mail client
<bialix> asabil: I've read help on git-filter-branch
<LarstiQ> bialix: did you get my mail in the end?
<bialix> yes, this morning
<LarstiQ> cool, I wasn't sure it would actually be delivered
<bialix> --subdirectory-filter <directory>  -- that's what I need for scmproj
<bialix> why not?
<bialix> jelmer: btw, the text from ukr.net was in the Russian actually. but there is very small difference
<jelmer> bialix, ah, sorry
<bialix> brrrr, why you said sorry?
<LarstiQ> bialix: and got your reply, thanks
<bialix> LarstiQ: I'm very interesting to know about nested-by-reference
<bialix> how the reference is stored? can you nest already nested trees?
<jelmer> bialix: In case I had offended by confusing the two.
<bialix> oh, no
<bialix> nonono
<bialix> no offence
<jelmer> ok :-)
<bialix> actually my native language is Russian
<nua> anyone recognise this error: "bzr: ERROR: Server sent an unexpected error: ('error', "invalid literal for int() with base 10: 'None'")" ??
<LarstiQ> bialix: I have to page in the knowledge of how this works exactly again
<bialix> if this possible, please
<bialix> am I understand correctly that nested-by-values are stored in the parent dirstate?
<bialix> dirstate of child tree -> parent dirstate
<LarstiQ> iirc, nested by value includes the file graph of the child in the parent's graph
<LarstiQ> so that would get into the dirstate, yes
<bialix> so the graph is recalculated?
<LarstiQ> but this is all airi, too long not looking at it
<LarstiQ> bialix: the join and split commands should be in bzr core for a while now, I don't think that code is too different
<bialix> may be I'll try to describe my problem wuth scmproj, so universe supermind can suggest something?
<bialix> with
 * LarstiQ nods at bialix 
<bialix> scmproj tries to operate with "project" as set of branches
<bialix> it's like a cheap emulation of nested trees
<bialix> hi amanica!
<AmanicA> hi guy
<bialix> but I'd like to put some smaller project into other bigger megaproject
<bialix> and call it subproject
<bialix> but what if my subproject also has inside another subproject?
<AmanicA> (bailix are you talking to me or did I join a conversation halfway?)
<bialix> I've thought idea or implementation of nested tree "by reference" will give me some klue
<bialix> clue, sorry
<bialix> I'm talking to LarstiQ, and to universe supermind here
<AmanicA> cool :)
<LarstiQ> bialix: nested-trees has a CompositeTree, that allows for a nesting of subtrees more than one level deep, which you seem to be running into?
 * LarstiQ believes lifeless wasn't too fond of that solution
<bialix> I guess so
<bialix> my subprojects always will be nested by reference, IIUC
<LarstiQ> yeah, that makes sense
<bialix> there is another nasty problem I can't figure out yet: recursion
<LarstiQ> oof
<Lo-lan-do> jelmer, Jc2k: I've been wondering about the colocated branches and bzr-git, thinking about the possibility of interacting with several git branches from bzr.
<LarstiQ> bialix: is it needed? If not, it should be possible to disallow it?
<bialix> LarstiQ: I guees bzr can detect recursion by TREE_ROOT id?
<bialix> LarstiQ: what's exactly? to dissalow
<Lo-lan-do> Assuming push-to-git is completed soon, could one use branch renames in git to interact with various git branches in the same git repo?
<bialix> disallow
<bialix> I can disallow nested subprojects, but I think it will be bad
<Jc2k> Lo-lan-do: i think so.. as a temporary hack until we can properly do colocated branches..
<bialix> LarstiQ: CompositeTree implementation in your branch only? or in bzr.dev too?
<LarstiQ> bialix: in my branch only
<LarstiQ> bialix: there are still bugs in there
<LarstiQ> bialix: like, moving a file across subtree boundaries
<bialix> that's nightnare problem
<Lo-lan-do> Jc2k: That's cool, since we could just script something that renames each git branch to master, then push/pull into it, then rename it back.
<bialix> nightmare
<bialix> LarstiQ: how the branches are changed after join?
<LarstiQ> bialix: I meant disallowing recursion, at add time you should be able to figure out, with TREE_ROOT, wether you're looping, and if so, don't add it
<LarstiQ> bialix: join and split are for by-value
<bialix> LarstiQ: it's not my case
 * LarstiQ nods
<bialix> bzr join has option --by-reference
<LarstiQ> ah right
 * LarstiQ is more familiar with the bzrlib side of things
<bialix> no, sorry, just --reference
<LarstiQ> bialix: and as I said, it has been a while, but I would be very happy to get it back on track
<LarstiQ> bialix: you're providing excellent stimulation to work on it :)
<Jc2k> Lo-lan-do: well people desperate enough could, i dont think we'd want to ship anything quite so.. unique! :D
<bialix> LarstiQ: it will be great
<LarstiQ> bialix: so thank you for that
<bialix> me?
<Lo-lan-do> Jc2k: The point is to allow me and the git guy to work on the same project without the SVN wart in the middle.
<LarstiQ> bialix: yes, thank you for motivating me
<Jc2k> Lo-lan-do: yeah, it would be ideal for you
 * bialix still don't understand how the nested tree will work under the cover
<AmanicA> bialix: so is this recursion problem about finding the parent project?
<bialix> yes
<LarstiQ> bialix: the most relevant code is bzrlib/composite_tree.py (and bzrlib/tests/test_composite_tree.py) btw
<lifeless> moin
 * bialix going to run bzr branch
<lifeless> Jc2k: you had questions for me
<LarstiQ> bialix: adding a subtree: tree.add_reference(subtree)
<lifeless> LarstiQ: I was fine with the solution as a stepping stone; but loading all the trees always doesn't scal
<AmanicA> bialix: why cant we just split /x/y/z into ('x','y','z') and then chop off one, check, repeat?
<LarstiQ> bialix: iirc, some of the semantics were still up in the air. One thing jelmer wants for example is ala svn:externals, "give me HEAD of that library over there"
<LarstiQ> lifeless: ok. And agreed.
<bialix> AmanicA: umm?
<AmanicA> bialix we can use path.split(/x/y/z) to get ('x','y','z')
<Jc2k> lifeless: oooh. umm. for one of them, see the bzr-hookless-email thread on ML
<bialix> LarstiQ: my plugin now working exactly this way
<AmanicA> bialix: then we can move up one by one and check if it has a .scmproj
<lifeless> Jc2k: I saw; I'm curious why smart server hooks didn't do what you need - but hookless polish is nice too
<bialix> amanica: let's imagine you already have some megaproject
<bialix> amanica: and then you add it to another megaproject as subproject
<bialix> we need to catch recursion at fetch/checkout operations
<Jc2k> lifeless: i presumed that doing a lot of stuff in smart server hooks would mean more time until the user at the end of bzr push could resume hacking, and thats why hookless existed
<AmanicA> bialix: so that they don't contain each other..
<bialix> amanica: actually, I'd like to keep all metainfo about subprojects (even nested) inside parent control dir
<lifeless> Jc2k: hookless exists because smart server hooks are recent
<lifeless> brb
<LarstiQ> and because not all sites run the smart server
<AmanicA> bialix: so you don't want to assume that all subprojects are in a subdir of its parent project?
<bialix> LarstiQ: your branch is indeed old! it gave me upgrade warning
<LarstiQ> bialix: yes :(
 * bialix still branching...
<LarstiQ> bialix: I've started to merge bzr.dev back in
<Jc2k> lifeless: so there are hooks and smart server hooks..?
<LarstiQ> bialix: I'll upgrade the branch format when I push that
<bialix> amanica: we need the way to mark subprojects as such
<AmanicA> bialix: then we so while we walk the subproject tree, we just keep a cache of visited projects, and don't add them again.
<bialix> either we keep their own .scmproj all around (a-la .svn) or we keep everything inside parent .scmproj
<bialix> AmanicA: but how we detect visited projects?
 * bialix guess scmproj should force usage of rich-roots
<AmanicA> bialix: I think each project/subproject should have its own .scmproj
 * Lo-lan-do guesses rich-roots really should be enabled by default
 * bialix too
<bialix> but it's the trap door, and this is pain in the ass
 * LarstiQ would like to have rich-root default, or a way to get data from rich-root to non-rich-root
<LarstiQ> bialix: yeah :/
 * bialix too
<Lo-lan-do> Well, it depends on what there is to gain on the older side of the trapdoor.
 * bialix guesses fast-import can help here
<AmanicA> bialix: I don't know where the proj tree traversal code is, I can play with it I might understand better
<fullermd> I think the last concensus was that the fence would be jumped with the repo format with new inventories, since that require rewriting $LOTS anyway.
<bialix> AmanicA: there is no traversal code yet
<bialix> it should be in the run_actions loop
<bialix> as the resursive call
<bialix> I really need to figure out how to store subproj info first
<kfogel> So what is "rich-root"?  Doing a search for it on bazaar-vcs.org turns up two links, neither of which explains it.
<AmanicA> bialix: so when/if you actually run into this, call me up and we can figure it out. I'm sure we will be able to.
<bialix> Anybody wanna throw in me rotten tomatos?
<bialix> well, we are already here
<lifeless> Jc2k: smart server hooks -> hooks fired on the server, same interface, same registration, just needs a client that knows to tell the server 'run now'
<fullermd> A root that engages in oppression and exploitation of the proletariat, of course.
<bialix> I'd like to keep the subprojects info in the .scmproj/subproj/<NAME>
<AmanicA> :)
<bialix> fullermd: LOL
<bialix> I'm born in the USSR
<lifeless> kfogel: the root node was treated specially in early bzr, which we think was a mistake
<bialix> I've born
<LarstiQ> kfogel: rich-root formats store an extra bit of metadata, namely the fileid of the tree root
<AmanicA> bialix: just because of the recursion problem?
<lifeless> kfogel: rich-roots correct that and have them treated normally.
<bialix> I guess svn has the ID too
<lifeless> kfogel: in principle the root of a rich root could be a file or symlink even :P. in PRINCIPLE.
<lifeless> brb fooding
<bialix> AmanicA: no, just to make the entire project looks flat
<kfogel> lifeless, LarstiQ: um.  Thank you.  But, as a user, what does "rich-root" mean to me? :-)
<Jc2k> lifeless: right. and if you wanted to do stuff for each revision that just got inserted, it would block the user that is pushing until it finishes?
<AmanicA> bialix: I'm hoping that we can avoid it, but its your call.
<LarstiQ> kfogel: pain.
<AmanicA> ditto
<bialix> WDYM: it's my call?
<LarstiQ> kfogel: a concrete problem with non rich-root formats, is that if you want to do nested-trees, you have two entries that have the same fileid, 'TREE_ROOT'
<LarstiQ> kfogel: so with rich-root, each would have their own unique id
<AmanicA> bialix: its your decision
<bialix> you don't like it? why?
<LarstiQ> kfogel: bzr-svn makes use of rich-roots (I believe because it can/wants to split and join trees)
<fullermd> Another is that it means you can't do a root pivot, if bzr had a root pivot command.
<AmanicA> bialix: I don't want the subproject info in the parent project's special dir
<bialix> but we need to mark somehow subproject as such
<bialix> how?
<Lo-lan-do> LarstiQ: I thought it's because it stores additional metadata as properties of the root dir, but I might be talking nonsense.
<AmanicA> bialix: we can have a section in project.cnf
<AmanicA> .cfg
<bialix> for backlinks?
<bialix> it's bad idea
<bialix> we version control this file
<bialix> so we need to use local config
<AmanicA> bialix: I think its good
<LarstiQ> Lo-lan-do: quite posisble, I'm a bit detached from the actual bzr-svn usage
<LarstiQ> kfogel: now, all this is fine and good.
<AmanicA> to version what subprojects are part of the superproject
<bialix> but then you'll get subproject as standalone project and this backlink will be there forever?
<LarstiQ> kfogel: except, non rich-root formats can't represent this information, so when someone branches of a non-rich root, then upgrades, their work can no longer flow back.
<LarstiQ> kfogel: which I think is a major PITA
<Lo-lan-do> LarstiQ: I'm trying to get detached too, but I'm stuck with it until bzr-git gets push support.
<bialix> AmanicA: well, we already should explicitly point at subproject in the megaproject config
<etenil> Hello
<LarstiQ> etenil: hello
<AmanicA> bialix: I mean the magaproject needs to know of its subprjects, not backlinking it
<kfogel> LarstiQ: I started half understanding that, toward the end...
<bialix> AmanicA: look please at the bug https://bugs.launchpad.net/bzr-scmproj/+bug/313150
<ubottu> Launchpad bug 313150 in bzr-scmproj "project comands for local project checkout should be possible to run from subdir" [Medium,Confirmed]
<AmanicA> ok
<kfogel> LarstiQ: (not trying to play-act the part of stubbornly ignorant user -- I really am struggling to understand when/how to use/care about rich-root.)
<etenil> I'm using bzr with tortoise-bzr for work but a lot of features are missing. What GUI is the most advanced for windows currently?
 * LarstiQ nods at kfogel 
<bialix> etenil: if you need standalone GUI -- bzr-gtk then
<LarstiQ> kfogel: right now, I'd say, stay away from them, unless you know you need them.
<bialix> if you can live with command-line -- QBzr then
<etenil> bialix: even for windows?
<AmanicA> bialix didnt we discus having a --me-only option?
<pickscrape> Does anyone know when bzrtools 1.11 will hit the PPA?
<bialix> etenil: bzr-gtk? yes
<AmanicA> (or something like that)
<bialix> etenil: for bzr-gtk see http://bazaar-vcs.org/WindowsInstall
<etenil> bialix: thanks a lot, i'll give it a try. Some of my colleagues are allergic to the command line
<bialix> etenil: I'm very happy with FAR
<LarstiQ> etenil: I'd go with QBzr (which tortoise uses under the hood too)
<bialix> it's more than just command-line
<LarstiQ> etenil: what features are you missing?
<bialix> AmanicA: --me-only?
<bialix> I don't remember
<AmanicA> bialix: some option to say that we run command for this subproject only
<bialix> etenil: what is missing for you in TBZR?
<etenil> LarstiQ: conflict resolution, update to a previous revision
<bialix> AmanicA: yes, it's make sense
<etenil> revert only a file
<etenil> this kind of thing
<AmanicA> bialix: that bug is important for me too
<AmanicA> (to get fixed)
<bialix> AmanicA: this bug is main confusion for me and subprojects
<bialix> if we put subprojects as is we need the way to somehow mark them as subprojects
<bialix> but then one can just copy the subproject by hand and things will be broken
<bialix> this is *the* problem
<bialix> LarstiQ: may I ask you to look at my plugin in the near future and say me what you think?
<LarstiQ> bialix: yes
<bialix> I need more feedback
<LarstiQ> bialix: my day off is wednesday, I have some prior commitments, but I intend to spend time on nested-trees and scmproj both tomorrow
<bialix> one guy call it "clunky". but I don't understand what it means
<LarstiQ> bialix: other than that, I will be on vacation in Finland 10-18 february, so also more time for these things
<bialix> mmmm, vacation!
<LarstiQ> bialix: clunky is similar to cumbersome
<LarstiQ> (visiting my girlfriend actually)
<bialix> you're happy
<bialix> LarstiQ: but what it means exactly? what's wrong?
<bialix> it's the only a word
<LarstiQ> bialix: I'm also a non-native, let me look up how to describe this differently :)
<bialix> no
<bialix> I mean: this means that guy don;t like something
<bialix> but I need to know what exactly
<bialix> something in the design? or in the implementation?
<LarstiQ> bialix: yes, it is a feeling/impression that it is not elegant
<bialix> or main idea is clunky?
<LarstiQ> ah, that I don't know
<LarstiQ> is his comment public?
<LarstiQ> 'clunky' by itself isn't very useful feedback
<bialix> yep
<bialix> I need more helpful feedback
<bialix> even negative one
 * LarstiQ nods
<LarstiQ> bialix: I'm going to try to apply it to some of my branches from work tomorrow.
<LarstiQ> and will report my experience
<lifeless> kfogel: rich root means 'a one way upgrade that propogates to all users of a project'
<lifeless> kfogel: thats about it
<bialix> oh, your branch is cloned
<bialix> LarstiQ: I hope we will have better scmproj implementation in the Feb
 * garyvdm wishes he could use python 3.0's nonlocal feature.
<LarstiQ> bialix: I started reading the current docs/devel.text and docs/howto.txt, is that knowledge going to get obsoleted?
<bialix> docs/devel.txt: we are working on new project.cfg format and new layout of .scmproj
<bialix> some new docs available at http://bazaar-vcs.org/ScmProj/ (under the horizontal bar)
<LarstiQ> bialix: k
<kfogel> lifeless: one thing that it took me a while to get through my head: bzr's storage format and transport format are intertwingled.  That is, in many systems the format on the server side can be independent of the format on the client side.  But in bzr, the client gets whatever the server has, and (apparently?) doesn't do automatic downgrade/conversion if client is a lower version than server?
<bialix> LarstiQ: main idea of new config: everything is optional
<Lo-lan-do> kfogel: There's a question of losing information if the client isn't able to represent it.
<lifeless> kfogel: well, the only system I know of that is truely seperate is hg; git uses its local pack format, cvs uses its delta format etc
<lifeless> kfogel: anyhow, many operations in bzr use a VFS rather than smart verbs, mainly due to 'TODO'. (Clearly working over plain http is all VFS based, as is local disk, so diminishing returns apply to structuring those operations that also perform well on their own)
<kfogel> lifeless: no, CVS's server-side storage is actually independent of the client (they just look similar); SVN is also independent.
<kfogel> Obviously, any time a server sends something a client can't represent, there's going to be a problem :-).
<lifeless> kfogel: they may be defined as being independent; having written a CVS parser though, I am pretty sure they are the same :)
<kfogel> lifeless: ?  Server just sends diff format to the client.  The diffs are not actually the same ones that appear in the RCS files, usually.
<kfogel> (not that any of this matters for bzr, so maybe I should shut up :-) )
<lifeless> kfogel: depends on the verb you call, you can ask for the whole rcs file
<lifeless> kfogel: IIRC - I'll dig it up if it really interests you
<kfogel> no, it definitely does *not* interest me :-)
<lifeless> kfogel: (its in cscvs's CVS module
 * LarstiQ grins at kfogel 
 * kfogel looking as uninterested as possible
<kfogel> lifeless: I believe you! :-)
<lifeless> :P
<lifeless> check up, I could well be wrong. I just don't think I am :)
<LarstiQ> aaanyway
 * LarstiQ goes home
<bialix> LarstiQ: bye
<bialix> I'll read your code, hope will have more specific question tomorrow
<LarstiQ> bialix: most of it is still Aaron's code, I didn't actually do all that much
<bialix> LarstiQ: where add_tree method lives?
<fullermd> I think mtn's wire format is completely divorced from its storage as well.
<LarstiQ> bialix: add_reference?
<bialix> ah, yes
<bialix> mu bad
<lifeless> fullermd: opposite - its a merkle tree
<lifeless> fullermd: so there is a canonical representation you need chained hashes all the way down - doing it without it being precalculated (e.g. your native format) -> expeeeensive
<lifeless> mtn syncing is closer to bittorrent than anything else :)
<fullermd> Well, I meant in the sense that it comes off disk, is converted to a different format, sent across the wire, converted to a different format, then blatted onto disk.
<fullermd> It doesn't just stream all the bytes coming off the network into a file (or DB record), like git sending whole packs, or bzr doing its VFS thing.
<fullermd> (at least, AIUI)
<lifeless> well sure
<lifeless> but bzr doesn't do that either in a manner of speaking :)
<fullermd> Well, no.  That's why it's not fast enough  ;p
<fullermd> Or alternately, it does too little to be real fast, and too much to be real independant of the far side format...
<nua> Hi, trying to get someone set up on a shared repo and they are using windows. I want them to use bzr+ssh:// but they can't seem to log in and the ssh key they generated in putty me looks different to mine :S ...its all numbers only
<lifeless> fullermd: my point is that independence is not about disk representation so much as how much of the stack you depend on to write a lookalike server. e.g. for git you need chained hashes to infinity. Same for hg and mtn.
<nua> any help would be great :D
<lifeless> nua: well, there is a faq about windows and ssh I think, on the bazaar-vcs.org website
<nua> we've been following that :s, says nothing about the keys
<bialix> nua: where you host your repo? at windows or linux?
<fullermd> lifeless: OIC.  That would be a somewhat different axis than occured to me in scanning my scrollback.
<nua> bialix: linux
<kfogel> Why does https://lists.ubuntu.com/archives/bazaar/2009q1/051589.html say "An embedded and charset-unspecified text was scrubbed..." instead of having the body of my message?
<bialix> putty generate keys in its own format
<bialix> nua: you need to convert it to linuc format
<nua> bialix: ah ok, how do I do that?
<lifeless> kfogel: not sure; ask a sysop?
<bialix> puttygen has the menu option for this IIRC
<kfogel> lifeless: ok, thx
<bialix> nua: main menu -> conversion -> export oen ssh key
<bialix> open ssh
<bialix> why for open_branch hook is designed? what's use case?
<lifeless> bialix: policy control for smart servers
<bialix> can it be used for ACL?
<lifeless> if you raise an exception the branch can't be opened, so yes. Though it might look a little ugly as-is
<bialix> to prevent read/write access?
<bialix> what is policy control then?
<lifeless> currently just setting the stacking information
<lifeless> but its wide open for extension if you have something you want it to do
<bialix> I need access control
<bialix> setting up ssh on windows is not funny
<bialix> another way (as I understand) is using Apache
<fullermd> With what assurance level?
<bialix> I will be very happy to have built-in ACL support in bzr smart server
<fullermd> I mean, as long as VFS support is enabled, any access control short of the hard root is pretty soft.
<lifeless> bialix: once we get VFS disabled I too am interested in ACL's
<lifeless> fullermd: write-ACL is easier
<lifeless> fullermd: just prohibit writes until ACL check passed
<fullermd> That would still only protect you at repo boundaries.
<lifeless> fullermd: and outside that you're chrooted anyhow, and we shouldn't write to non repostuff at all with acl's on
<fullermd> Right, but I mean as soon as you're OK'd to do anything in a given repo, you can pretty much to anything to anything in that repo.
<bialix> kfogel: it's nice story: http://bazaar-vcs.org/Scenarios/PrivateShare :-D
<kfogel> bialix: uh, please feel free to whip that one into shape :-)
<bialix> I'm not native English speaker
<kfogel> Hmmm, while we're at it, what is our commit email story?
<kfogel> So far, all the systems I've seen for generating commit mails run on the individual developer's machine.
<lifeless> kfogel: install bzr-email on the server, use bzr server and client 1.8 or newer (if I recall the version correctly)
<kfogel> *nod*
<Lo-lan-do> I thought there was one hook called on the server?
<lifeless> Lo-lan-do: its the same hook
<lifeless> Lo-lan-do: see the most recent bzr-email commit, I changed hooks and thus it works ;)
<Lo-lan-do> Haven't started bzr-email so far, but will do at some point.
<Lo-lan-do> Er, haven't started *using* it.
<kfogel> lifeless: the real issue (not one we should try to solve now) is probably that there are two distinct concepts: a "checkpoint" and a "commit" (or a "commit" and a "merge", or something).  What devs do with their local branches are usually checkpoints; when they pull or push a set of changes, the result is a merge, and (on the master branch) that's what should produce a so-called commit email, IMHO.
<lifeless> kfogel: yes, thats what I describe does
<lifeless> kfogel: though some projects want continual integration, others want stronger qa, etc etc
<kfogel> lifeless: "that's what what I describe does"?  (just checking that I'm parsing right)
<lifeless> bzr-email on the server will trigger emails on push/uncommit/commit to the branches its set to notify on
<kfogel> lifeless: so the comments near the top of https://savannah.gnu.org/support/index.php?106612 (comments #4, #5, #6, #7) are confused, and I should tell the Savannah admins that bzr-email does what we want?
<lifeless> Jc2k: re blocking the user - 'maybe'. Some hooks want to block the user. Others want to be async; the hook interface specifies whether things are pre-or-post - pre should block, post shouldn't.
<lifeless> reading
 * bialix waves bye
<lifeless> ciao bialix
<Jc2k> lifeless: so post hooks run after the bzr client has been and gone?
<kfogel> lifeless: so if I push N commits into branch B, and bzr-email is set to trigger email, one email will go out, containing the cumulative diff of the N commits, not N diffs nor N emails, right?
<lifeless> Jc2k: implementation vs interface :P
<lifeless> Jc2k: I'm saying that having post hooks on the server run via e.g. dbus, or threads, or fork, is all permitted
<lifeless> Jc2k: though ones that want to give feedback to the user naturally have to block the UI
<Jc2k> right..
<lifeless> anyhow, like I said, hookless polish is nice
<lifeless> for folk wanting to use e.g. sftp for hosting where server side hook firing is much harder
<ronny> oh, heh - yay - i just figured how to exactly to deal with bzr in anyvc
<Jc2k> in that case use case, reusing Branch.hooks is probably the right thing to do, even if the PostBranchTipChange behaviour is slightly different
<Jc2k> (2 branch tip changes could become a single event)
<lifeless> Jc2k: yeah, I don't really see any reason to have different interfaces
<lifeless> unless things really are different
<Jc2k> lifeless: yeah, it was only a worry if there was a use case for using this (out of process) instead of using the hooks in process. if i use Branch.hooks, the hook would happen in-process and out-of-process
<Jc2k> but it sounds like you'd never want out-of-process (hookless) when you have the smart server
<lifeless> Jc2k: there is a similar concern with client and server hooks
<nua> my friend is trying to connect to a shared repository hosted on linux from his windows machine using tortoise-bzr and now we only get the following error: bzr: ERROR: Server sent an unexpected error: ('error', "invalid literal for int() with base 10: 'None'")
<ollie> is there a way to do a cat of a specific file at a specific version?
<lifeless> we want some things to run on the client, but not if the server will run *the same hook*; and the server has to have the plugin active to meet that check - its unsolved today :P
<nua> the only way to fix it is to delete the repo, bzr init again and push from my machine
<lifeless> ollie: bzr cat -r X path
<ollie> lifeless: thanks :)
<lifeless> beuno: please give me scroll bars back : http://bazaar.launchpad.net/~bzr/bzr-email/trunk/revision/39
<asabil> jelmer: http://pastebin.com/m6c2e8a0d
<asabil> does this look good ?
<jelmer> asabil, yeah
<lifeless> spiv: ping
<asabil> cool
<lifeless> spiv: when did you activate post_change_branch_tip in the server?
<Lo-lan-do> asabil: Is that the thing which will allow a rebasing onto an unrelated branch?
<Lo-lan-do> Ah, no, sorry.  Misread.
<asabil> :)
 * Lo-lan-do goes back to bickering about bzr-svn and bzr-git
<jelmer> uhoh
<jelmer> should I be expecting a flood of bug reports?
<Jc2k> jelmer: i have one, but i cant decide wither its bzr or bzr-git :P
<Lo-lan-do> jelmer: Not yet, and I'll probably try to fiddle with stuff first.
<Lo-lan-do> jelmer: I'm trying to bzr checkout (or branch) a copy of the old svn repo, and I get "NoSuchRevision: KnitPackRepository() has no revision foo"
<Lo-lan-do> I suspect tricks with the repo's uuids.
<Lo-lan-do> I'll probably end up doing svnadmin dump | filter.pl | svnadmin load to remove old bzr-related properties from the SVN repo, unless you're confident it won't help.
<lifeless> Jc2k: file it on bzr-git then
<Jc2k> lifeless: should repo.gather_stats work if there is no history yet?
<jelmer> Lo-lan-do, no, that may very well help
<jelmer> Lo-lan-do, is this the same repository you filed that debian bug about?
<spiv> lifeless: hmm
<jelmer> Jc2k, ah, that bug
<jelmer> Jc2k, that's both a bzr and a bzr-git bug
<Lo-lan-do> jelmer: I think it's another one obtained from the first one, or from the same source.
<lifeless> spiv: its hard to tell; I think thats a bug
<spiv> lifeless: probably 1.6, I think the Branch.set_last_revision_ex verb was the key
<jelmer> Jc2k, bzr should be allowing a *completely* empty repository and bzr-git should be mentioning NULL_REVISION
<Lo-lan-do> jelmer: svn://scm.fusionforge.org/fusionforge if you want to give it a try.
<kfogel> lifeless: re my earlier question -- I'd like to pass along the answer to savannah admins:
<kfogel> lifeless: so if I push N commits into branch B, and bzr-email is set to trigger email, one email will go out, containing the cumulative diff of the N commits, not N diffs nor N emails, right?
<spiv> lifeless: (I think it had perhaps briefly worked during a 1.4 rc, but an apparently unrelated change had stopped the client from using the necessary verb, or something like that)
<spiv> lifeless: I agree that that's a bug
<lifeless> Jc2k: is inotify support in bzr-hookless trunk?
<lifeless> kfogel: 1 email
<lifeless> kfogel: it might be ugly, patches appreciated.
<lifeless> s/might/probably is/
<Jc2k> lifeless: there is inotify in bzr-hookless-email and in my pluginified hookified version in lp:~johncarr/+junk/bzr-watcher
<lifeless> Jc2k: cool
<lifeless> Jc2k: https://savannah.gnu.org/support/index.php?106612
<kfogel> lifeless: great.  That might even be a patch I can do, but at least this is enough for Savannah admins to get started.
<Jc2k> lifeless: i was under the impression that hookless-email had had inotify for yonks
<lifeless> Jc2k: my bad- your mail confused me :)
<Jc2k> i fail at english :(
<Jc2k> jelmer: if i want to implement dpush, GitRemoteBranch.dpull is where i should start?
<Jc2k> jelmer: i've been thrown off by GitRemoteBranch.__init__ doing a fetch :\
<jelmer> Jc2k, I'm already working on dpush, to make sure we can push dulwich back into git..
<jelmer> I'm working on local though, not remote
<Jc2k> ah
<Jc2k> i'll leave it alone for now then
<Jc2k> jelmer: does dpush rebase post-push to alter the revision ids?
<jelmer> Jc2k, yes
<Jc2k> jelmer: so if i hack on branch a, then branch that (as b) and hack on that, then dpush a.. i wont be able to merge b into a?
<Jc2k> (unless i dpush first)
<jelmer> Jc2k, yes
 * Lo-lan-do finds the SVN::Dumpfilter module for Perl
<Lo-lan-do> That's probably going to make my life easier :-)
<Lo-lan-do> But not tonight.  /me â sleep
<asabil> very quick and dirty, will probably get rewritten someday: lp:~asabil/+junk/bzr-filter-branch
<asabil> ouch
<asabil> it doesn't work :/
<igc> bbl
<lifeless> jelmer: what did you need VirtualVersionedFiles.iter_lines_added_or_present_in_keys for ?
<lifeless> jelmer: (it should _never_ get called unless you are claiming to have xml backend storage)
<jelmer> lifeless, somebody had created a branch stacked on a svn branch
<jelmer> lifeless, and was running "bzr stacked_branch new_branch"
<lifeless> so bzr format stacked on svn format; branching from the bzr format
<lifeless> hmm
<jelmer> lifeless, it works with that function
<lifeless> eep
<lifeless> ok
<lifeless> I'm not sure how you can tell what xml format to expose
<lifeless> stacking is still _very_ format specific; I'm guessing you lie about your serialisation type?
<jelmer> lifeless, I've just hardcoded it to a particular version at the moment
<jelmer> lifeless, without that, I can't do versionedfiles *at all*
<jelmer> as Repository.inventories and Repository.revisions use it
<jelmer> lifeless, this is one of the reasons I've been asking about a more generic stacking API :-)
<lifeless> jelmer: I think you need to write it :)
<lifeless> jelmer: I'd like to see it too, but ETIME.
<jelmer> lifeless, I was afraid that's what you were going to say :-)
<lifeless> jelmer: did you have any idea why the compressbench thing worked for you?
<lifeless> jelmer: also, could you paste me a comparison of knit<->git<->dulwich using that
<jelmer> lifeless, do you remember the arguments?
<lifeless> --delta git --delta dulwich --delta knit
<lifeless> oh, and --limit if you have a really big repo, otherwise it will use all the inventories
<jelmer> ok
#bzr 2009-01-28
<jelmer> lifeless: http://pastebin.ubuntu.com/110595/
<jelmer> lifeless, Knit fails
<jelmer> ValueError: I/O operation on closed file
<lifeless> oh
<lifeless> edit bzrlib/knit.py
<lifeless> change the order of the lines in the cleanup test helper
<lifeless> your limit needs to be at least 2.5 orders of magnitude bigger
<lifeless> its in bytes
<lifeless> so thats 100K, 10M is on the small side of useful
<jelmer> oh ok
<lifeless> 100M is ok, 1G is great
<asabil> is pulling from launchpad over http broken ?
<jelmer> I'm sure 1G will kill my laptop the way dulwich works
<lifeless> jelmer: 100M then :)
<lifeless> asabil: shouldn't be, are you having trouble?
<asabil> yes
<nua> just looking at how to create a working tree on the server we have a shared repo on, I've attached a plugin to 'post_change_branch_tip' on the server, which calls push_result.branch.update(), but it doesn't appear to have created any files ...any tips?
<lifeless> asabil: its working for me
<asabil> can you branch http://bazaar.launchpad.net/~asabil/libcore/trunk
<lifeless> nua: you want push_result.branch.bzrdir.open_workingtree().update()
<nua> lifeless: thanks, I'll give that a go :)
<lifeless> nua: branches don't have files :)
<alf> hello, are there any recent benchmarks (eg including btree index) vs older versions vs other DVCSes?
<nua> lifeless: I must admit the terms confuse me... I'm sure I'll get the hang of this!
<alf> asabil: I branched just fine (bzr 1.11)
<asabil> weird
<asabil> I am using the latest bzr.dev
<lifeless> nua: repository -> history storage. branch -> a single line of development [sequence of revisions]. workingtree -> thing with your files on disk
<lifeless> asabil: I branched that fine
<nua> lifeless: hmm, the call you just recommended gives me an error: "...not a local path"
<lifeless> asabil: what error are you having though ...
<asabil> Invalid http response for http://bazaar.launchpad.net/%7Easabil/%2Bjunk/corelib/.bzr/repository/packs/8ae3694b85ab02e2205240ecfa8e4e7e.pack: Expected a boundary (4HBADSmH0_z:3H2yCsdl) line, got ''
<lifeless> asabil: thats almost certainly a broken proxy in the middle
<asabil> stupid network operator
<asabil> thanks lifeless
<lifeless> we managed to find a bug in squid with bzr, which was extremely surprising
<nua> lifeless: thanks for your help, think I should sleep now... bye all
<lifeless> (a ways back now). So I wouldn't be surprised to find other proxies with issues
<asabil> I have no idea about where and how they proxy stuff
<asabil> I am surprised that an ISP does so
<lifeless> many ISP's intercept HTTP across the board
<lifeless> cisco and other vendors have dedicated protocols to assist doing this.
<lifeless> you could try http+urllib://...
<asabil> ok will do thanks
<lifeless> slightly different code
<lifeless> might behave differently
<asabil> doesn't help
<asabil> this seems to be a transparent proxy I am behind
<lifeless> can you pastebin the server headers from 'wget -S http://bazaar.launchpad.net/%7Easabil/%2Bjunk/corelib/.bzr/repository/packs/8ae3694b85ab02e2205240ecfa8e4e7e.pack -o/dev/null'
<asabil> lifeless: http://pastebin.com/d524bf570
<lifeless> asabil: nothing obvious, which probably just means its a commerical intercepting cache :(
<asabil> that's what I guessed
<asabil> and wget works perfectly with it
<lifeless> well its a full range request
<lifeless> if you wanted to sniff the http requests bzr is making and capture the failing one, I'd be happy to eyeball it and see if it really is broken, or if you've magically found a bug relating to packet arrival or some such
<asabil> yes I can make a wireshark dump
<spiv> I think -Dhttp might capture a lot of stuff too, but obviously wireshark will work too.
<asabil> lifeless: you want the whole dump file ?
<jelmer> lifeless, looks like, uhm
<jelmer> lifeless, there is "some" room for improvement in dulwich
<jelmer> http://pastebin.ubuntu.com/110601/
<asabil> lifeless: http://people.freedesktop.org/~asabil/bzr-branch.dump
<tjs> G'day, just wondering if there is any way to write a server side hook for a bzr repo. I've taken a look at the user guide which links to bzr-push-and-update but that still seems to be something you install on the client.
<beuno> lifeless, why did you loose the scrollbars?
<lifeless> beuno: horizonal ones
<lifeless> beuno: I can't see my full left<->right text in the diff
<lifeless> tjs: just write a Branch.post_tip_change hook
<beuno> lifeless, so drop the auto-wrap?
<lifeless> beuno: it isn't wrapping
<beuno> lifeless, ah, it's curring off a chunk of the last word?
<tjs> lifeless: where does that go?
<tjs> somewhere in the repo's .bzr dir?
<spiv> tjs: write a plugin
<lifeless> beuno: yes
<lifeless> beuno: my browser is about 800 wide, my screen is 1280
<spiv> tjs: that installs a hook function for post_change_branch_tip on Branch.
<lifeless> tjs: plugins are bzr-wide, but you can consult branches for 'should I act here' if you want
<beuno> lifeless, gotcha. I have it on my list, will see if I can get to theme tweaking soon
<lifeless> asabil: looks like garbage in the stream
<lifeless> asabil: if you look at it, it has a reasonable range header, then cruft, then the bazaar format marker, then more noise
<lifeless> it should be mime/multipart
<tjs> lifeless, spiv: ok, thing is I'm comming from the SVN world of 'install hooks in hooks dir in the repository'. I get that bzr supports adding plugins on the client side ~/bzr/plugins/. but I'm not sure how to add a plugin to the repository (on a different server, not where the client is run) that would get executed when someone pushes via bzr+ssh
<lifeless> asabil: or, perhaps I'm using the wrong tool to view :P
<lifeless> asabil: what did you capture with?
<tjs> I want to avoid distributing a plugin to everyone using our repo
<tjs> is that possible?
<asabil> wireshark
<lifeless> tjs: same as any plugin - either in ~/.bazaar/plugins/NAME of the account running the bzr command, or in bzrlib/plugins/NAME of the install of bzrlib
<spiv> tjs: install the plugin on the server
<lifeless> tjs: (which most plugins' setup.py does automatically)
<tjs> ok
<tjs> well that makes more sense
<tjs> :)
<lifeless> tjs: if you have multiple user accounts on the box, you'll want the latter option
<asabil> lifeless: I don't see the problem
<lifeless> asabil: yeah, I wasn't decoding properly
<lifeless> asabil: so the content looks ok but truncated
<asabil> is it truncated ?
<asabil> to me it looks correct
<lifeless> its truncated
<lifeless> you can tell because its a multipart byte range
<lifeless> http of a single range uses a different representation
<lifeless> multipart is used for multiple sections being answered; but there is only one section contained in the response
<asabil> hmm, I see 2
<asabil> lifeless: don't you see the string G/8(76f=Y3=hJv=GZ(Or
<lifeless> this is what a single part response looks like:
<asabil> 3 times ?
<lifeless>     Content-Range: bytes 0-180/181\r\n
<lifeless> Range: bytes=0-41,433-2408\r\n is what was asked for in the final request
<lifeless> so we should get 1.5K of data more or less
<lifeless> oh, did you tell wireshark to capture all the packet data? by default it only grabs 500 bytes or so
<asabil> I see Range: bytes=0-41,3824-10459
<asabil> they are full
<Peng_> jelmer: ping?
<asabil> I didn't limit the size of the packets
<jelmer> Peng_, yo
<Peng_> Hi.
<lifeless> asabil: ok
<asabil> ah now I see
<asabil> I wasn't looking at the same request sequence
<asabil> lifeless: are you using asynchronous sockets ?
<Peng_> jelmer: Small thing, but in check_subversion_version(subvertpy), I think the "subvertpy" argument is unused.
<lifeless> asabil: yes, but the main program flow is synchronous, so you shouldn't see overlap on the wire
<lifeless> f that makes sense :)
<lifeless> I'm just installing the gui wireshark, I had tshark already but having a little trouble making sure I'm looking at the right stuff
<asabil> yes, but I have been bitten by the same kind of issue in python width asynchonous sockets a while ago
<asabil> and with the same network (at my parents place)
<lifeless> asabil: ah
<asabil> never managed to figure out the problem
<tjs> oeor
<tjs> pqm looks interesting
<lifeless> so the backend is in a thread I think
<lifeless> I'm not sure if its selected on or just blocking read() calls are made
<lifeless> vila will know
<asabil> oki
<lifeless> its just installing
<jamesh> lifeless: last week you were asking about the valgrind patch I did for Python.  Here is the bug I attached it to: http://bugs.python.org/issue2422
<lifeless> jamesh: thanks!
<asabil> lifeless: thanks a lot for your help
<jamesh> requires the valgrind headers to compile, but has no runtime dependency
<lifeless> asabil: so
<lifeless> frame 91 asks for 0-41,433-2408
<lifeless> 92 is an ack
<lifeless> 93 has content
<lifeless> 94 is an ack
<asabil> (you can right click and select follow TCP stream :p)
<lifeless> 95 is a single segment with *just* the range 0-41 in it
<lifeless> (oh guis, I don't get those :P)
<lifeless> 98 is a FIN/ACK
<jelmer> jamesh, it doesn't appear to have changed recently - is there any chance of it making it into 2.6?
<lifeless> anyhow
<lifeless> I can think of two reasons
<lifeless> one is that the content that is arrived is bad, and bzr is dropping the connection
<lifeless> the other is that the content is truncated and bzr is getting a read()->length 0 indicated EOF and closing it
<lifeless> the latter is what I think is happening
<lifeless> async sockets will give 0 when read on if they are not ready-to-read though
<lifeless> its a bad signalling API :(
<asabil> are they set to NON blocking ?
<lifeless> checking
<lifeless> bzrlib/transport/http/* if you're interested in the guts
<asabil> oki will check too
<lifeless> readv() is the programming API to this bzr's fetch code uses
<lifeless> could you run bzr branch..., and get the backtrace from ~/.bzr.log please
<jamesh> jelmer: I haven't pushed it much recently.  I'd be surprised if it got into a 2.6.x release.  More likely 2.7/3.1
<jelmer> jamesh, ah, ok
<asabil> lifeless: sure
<asabil> jelmer: http://pastebin.ca/1320146
<asabil> oups
<asabil> sorry
<asabil> lifeless: http://pastebin.ca/1320146
<lifeless> asabil: I suggest adding
<lifeless> import pdb;pdb.set_trace() inside the if block
<lifeless> if boundary_line != '--' + self._boundary + '\r\n':
<lifeless>     import pdb;pdb.set_trace()
<lifeless> in bzrlib/transport/http/response.py
<lifeless> then we can inspect the failure interactively
<lifeless> e.g.
<lifeless> pp self._file
<asabil> oki
<asabil> lifeless: I am inside pdb
<lifeless> alrighty
<lifeless> pp self._file
<lifeless> pp boundary_line
<vila> pp self._boundary
<lifeless> its a vila! yay.
<lifeless> vila: have you followed the problem?
 * vila yawns
<vila> lifeless: only half awake, but yes, I read the backlog
<asabil> (Pdb) pp self._boundary
<asabil> '1f1EePYnnXErcjN2PFX5'
<asabil> (Pdb) pp self._file
<asabil> <addinfourl at 178238732 whose fp = <socket._fileobject object at 0xa821ed4>>
<lifeless> ok, so it is a socket
<vila> pp boundary_line
<lifeless> vila: do you know, are the urllib sockets in blocking mode ?
<vila> lifeless: yes, we do blocking read on the http socket
<asabil> ''
<asabil> that was the output
<lifeless> vila: ok. So the symptoms are basically that we're seeing content truncated exactly at the end of the first content range in this particular file - repeatedly
<vila> asabil: grr, of course, we want the previous value of it please
<lifeless> vila: other multipart requests seem to work earlier on
<lifeless> vila: its a while loop on '\r\n' - it won't be interesting :)
<asabil> vila: not sure I am following :D
<vila> I agree with your first diagnosis, feels like a bogus proxy
<vila> asabil: it was a joke :)
<lifeless> asabil: can you do
<lifeless> pp self._file.read()
<vila> ''
<asabil> ''
<asabil> :D
<lifeless> ok, just checking it wasn't going to magically work :)
<vila> lifeless: well tried...
<lifeless> if it was a race condition with received content it may have worked :)
<lifeless> pp self._file.fp.fileno()
<lifeless> pp self._file.fp.closed
<lifeless> pp self._file.fp.mode
<asabil> *** AttributeError: AttributeError("Response instance has no attribute 'fileno'",)
<vila> pp self._start, self._size
<asabil> False
<asabil> 'rb'
<asabil> (0, 42)
<lifeless> this is all consistent with correct state in bzr/python
<lifeless> an unclosed socket that is getting no more bytes from the source
<asabil> I guess it is a broken proxy
<lifeless> do you have a lp account? you can branch from bzr+ssh://<rest of url the same>
<asabil> yes lifeless I can
<lifeless> cool
<asabil> I was just trying to help fixing this problem if it was a bug
<lifeless> yeah
<lifeless> thank you - I'm pretty convinced that its not.
<lifeless> but it would be a pain to be behind that ISP
<asabil> but it seems like it is my ISP
<asabil> it is largest ISP in Morocco :)
<lifeless> are they responsive to client requests?
<lifeless> I'd be happy to help them diagnose this - be good to get it fixed
<asabil> I can try to call them
<lifeless> the fact other ones work suggests its a corner case in their environment
<asabil> but not sure if the call center would understand
<lifeless> frame 71 starts a sequence that works
<lifeless> multipart handled correctly
<lifeless> yah, you probably need level 2 support :(
<vila> lifeless: you mean in that bzr-branch.dump ?
<lifeless> vila: yes
<vila> I can't find a failing one :-/
<lifeless> vila: the last one
<lifeless> frame 91
<asabil> but why does bzr open a second http connection
<asabil> for the last pack request
<lifeless> asabil:  connection: close
<lifeless> thats an instruction to start a new connection
<lifeless> its bogus, probably an apache bug
<lifeless> well, its kindof bogus
<vila> wow, the file is only 2603, never saw a proxy choke on small files like that
<lifeless> arguably standards compliant
<lifeless> vila: what is interesting to me is the FIN from the client, which is odd
<lifeless> but clearly we reproduced with pdb - you get 0 length reads at that point in the file
<lifeless> possibly worth a trivial test
<lifeless> like python, import socket, s = socket(address); s.write(request-from-branch.dump), s.read()
<vila> lifeless: FIN from the client.... I encountered that once... but can't remember the details
 * vila falling asleep finally
<vila> cu tomorrow
<asabil> gnight
<lifeless> thats very odd ><
<lifeless> asabil: care to do an experiment ?
<asabil> lifeless: sure
<lifeless> http://paste.ubuntu.com/110624/plain/
<asabil> lifeless: I get 1448 bytes
<lifeless> oh, I found a bug in my test
<lifeless> the HTTP/1.1 should be on the same line as the GET
<asabil> 443 bytes
<lifeless> ok
<asabil> well including everything
<lifeless> paste the repr(p) here?
<asabil> oki
<asabil> here or pastebin ?
<lifeless> either
<lifeless> 443 bytes is small :P
<asabil> 'HTTP/1.1 206 Partial content\r\nContent-Type: multipart/byteranges; boundary="BShaWCvE2DQy\'=s2Wasr"\r\nDate: Wed, 28 Jan 2009 02:16:56 GMT\r\nServer: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g\r\nLast-Modified: Fri, 21 Nov 2008 14:05:05 GMT\r\nETag: "1ff4876-a2b-45c3388336640"\r\nAccept-Ranges: bytes\r\nVia: 1.1 bazaar.launchpad.net\r\nConnection: close\r\nAge: 0\r\n\r\n--BShaWCvE2DQy\'=s2Wasr\r\nContent-Type: text/pl
<asabil> ain\r\nContent-Range: bytes 0-41/2603\r\n\r\n'
<lifeless> interesting!
<lifeless> thats clearly truncated
<lifeless> I get 2619 bytes
 * asabil thanks his ISP
<asabil> but why did the previous request work ?
<asabil> I mean the one that wasn't even valid http
<lifeless> it didn't really, it was http/0.9 or so
<asabil> oh oki
<lifeless> http://paste.ubuntu.com/110628/plain/
<laughyn1nj4> is anyone about?
<lifeless> sure
<laughyn1nj4> got a strange error in bzr today
<laughyn1nj4> can anyone help me?
<lifeless> this could take a while if you prompt at each step :P just ask away
<laughyn1nj4> ok ... wtf does this mean
<laughyn1nj4> ERROR:The API for "<Module 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo'> is not compatible with "(1, 10, 0)". Â It supports versions "(1, 11, 0)" to "(1, 11, 0)".
<laughyn1nj4> brb
<lifeless> asabil: try that updated version, see if it works better
<lifeless> laughyn1nj4: you have an old bzr-svn or bzrtools
<lifeless> laughyn1nj4: probably bzr-svn
<laughyn1nj4> hmm ... must have re installed with an old version of bzr?!?  no other explanation?
<laughyn1nj4> are there backwards compatabliity issues if your repo was made using an older version, and now you're using a new one?
<lifeless> its confusingly formatted, but that is definitely a plugin API compatibility check failing
<lifeless> nothing to do with your repo format
<laughyn1nj4> alls i did was do bzr add
<laughyn1nj4> a simple add
<laughyn1nj4> from the command line
<laughyn1nj4> ok... thanks i'll chekc into it
<lifeless> like I say, its nothing to do with your projects/repo formats etc
<laughyn1nj4> thanks much
<lifeless> you can verify this easily by running 'bzr --no-plugins <something>' - e.g. 'bzr --no-plugins st'
<lifeless> asabil: still there?
<igc> abentley: pqm is falling over on test_shelve_one for me - http://rafb.net/p/oMY0jZ54.html. I don't think it's my problem? I certainly can't reproduce the test failure in my integration branch
<abentley> igc: I'm rather distracted atm
<igc> abentley: np
<igc> I wonder if the pqm environment (Python version, etc.) has changed lately?
<lifeless> igc: shouldn't have
<lifeless> spm: ^^
<lifeless> igc: looks like gc occuring during the blackbox test
<spiv> igc: hmm, a failure involving a __del__, that might mean just bad luck.
<lifeless> igc: your patch may either be the problem, or just have pushed the gc timing to cause the symptom
<spm> lifeless: I'm not aware of anything?
<lifeless> spm: didn't think so :)
<spiv> igc: try inserting a gc.collect() in the base setUp and tearDown, perhaps.
<igc> spiv,lifeless: ok, I'll try that. Thanks.
<spiv> igc: I think there's a high probability of this being a race condition in the tests that only shows up if gc happens at the wrong time.  Doing gc.collect() for each test is somewhat likely to notice the problem closer to the cause.
<igc> spiv: so to confirm, add gc.collect() to bzrlib/tests/__init__.py/TestCaseWithTransport/setUp()? I could add it just to the shelve tests if that was better and/or less intrusive?
<spiv> igc: I think it's likely to be due to a test run sometime before the test that's being failed.
<spiv> igc: so I'd add it to *every* test, by modifying TestCase
<igc> spiv: and any risk of slowing down the test suite much?
<spiv> igc: roughly twice as slow, IIRC :(
<spiv> It'd be nice to have a flag to turn this on for debugging, but it's too costly to be worth it as the default.
<spats> oh my goodness! bzrlib is so easy to use! thumbs up, +1, and +1 on the +1!
<spiv> spats: :)
<lifeless> spats: cool! what did you do with it, if I may ask?
<spats> oh, nefarious things. we're adding some commands to bzr in a plugin that do useful things for our developers here - branch from a central trunk into a task branch and check it out locally, that sort of thing.
<lifeless> spats: cool, glad you're liking the experience
 * igc lunch
<vila> hi all
<igc> hi vila
<igc> vila: any chance of a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4972C8CE.8000205%40internode.on.net%3E today?
<vila> igc: I'm still catching up with mail, that one is already marked in my box as needing re-read (in fact three mails are marked in that thread)
<vila> I was hoping than jam or lifeless will answer your last question about split invs adding delete infos to the per-file graph, but my guess is that it still doesn't
<igc> vila: np
<vila> igc: I also have a draft regarding -n/--levels I should send (but no review of the code yet)
<etenil> Hi there
<etenil> I'm having difficulties running bzr-gtk n windows
<etenil> I can't find any way to start the interface...
<etenil> oh, I can use bzr olive actually
<asabil> lifeless: sorry, I got disconnected yesterday
<asabil> and now branching over http works
<asabil> I guess it was a problem with my ISP
<awilkins> etenil: All the "g" commands are gtk equivalents of the CLI ones
<awilkins> gcommit, gconflicts, etc.
<etenil> i found my way around
<etenil> my colleagues are VERY allergic to the console (they're windows users)
<awilkins> I like qbzr better but it currently has no conflict viewer
<awilkins> I'd also like it to support external diff viewers
<awilkins> So I just use gconflicts and the rest of my GUI needs are qbzr
<etenil> is it possible to use an external program to solve conflicts?
<etenil> and which one is best in windows?
<awilkins> etenil: Yes, this is what gconflicts does, by default it uses meld
<awilkins> etenil: I use Beyond Compare 3 Pro (payware, but cheap for what it does)
<etenil> is meld available on windows?
<awilkins> etenil: There's TortoiseMerge, KDiff, all sorts
<etenil> tortoise merge looks like what i need
<awilkins> WinMerge
<etenil> how can i specify to olive to use winmerge or tortoise merge?
<awilkins> gconflicts has a box for the path to the executable
<etenil> would it remember the one I choose or do i need to specify it every time?
<awilkins> I have a patch that lets you feed it a template that hasn't made it into the codebase yet, but it's probably required to get some Windows programs working properly
<awilkins> Yes, it saves it to the config files
<etenil> ok
<etenil> that sounds good
<etenil> just need to try then ;-)
<luks> hm, an equivalent of gconflicts seems trivial to implement
<awilkins> luks: It can't be that hard, it's only 193 lines of code.
<awilkins> Well, my patched one is
<awilkins> I've added a few lines so you can use a template for a parameter for which app to start
<awilkins> Not all windows apps like the argument style you get from passing a list to popen
<luks> awilkins: do you mind showing me the modified version? in the future it should be integrated into https://bugs.launchpad.net/qbzr/+bug/247976 but for now I might use a simple gconflicts-like app launching
<ubottu> Launchpad bug 247976 in qbzr "Support external diff programs" [Wishlist,In progress]
<etenil> How can I resolve a conflict in bzr-gtk?
<etenil> I didn't see the command anywhere on the interface
<etenil> could you help me?
<etenil> How can I resolve a conflict in bzr-gtk?
<LarstiQ> etenil: `bzr gconflicts` I suppose?
<etenil> no I mean form olive, the interface of bzr-gtk
<etenil> I can merge manually with an external tool, but I still need to run bzr resolve after that
<etenil> I couldn't find any button for this one
<LarstiQ> I have no clue what the status of Olive is, but it is not 'the' interface of bzr-gtk
 * LarstiQ would think most people use the different commands by themselves
<etenil> well, probably you don't HAVE to have it on the interface for your users to use it...
<etenil> I'd really appreciate if it was possible to do it
<LarstiQ> etenil: I agree with that. I'm just saying, since afaik most people either start commands from the commandline, or use shell integration, Olive doesn't see as active development as the individual gcommands
<etenil> would it be easy to implement a button to resolve conflicts?
<LarstiQ> etenil: so while it would be nice to have the alternative, Olive, complete also, that might not be the best way forward for you
<LarstiQ> etenil: if you can confirm gconflicts does what you think it should, then yes, popping up gconflicts from Olive should be easy.
<LarstiQ> etenil: if gconflicts does not do enough, that needs to be improved (first, I'd argue)
<etenil> well, I do use the CLI, but the other users I serve think it sucks, and in a company environment, I don't feel like giving them the finger T_T
 * LarstiQ nods
<LarstiQ> etenil: I get that.
<etenil> sorry, don't mean to be rude with you
<LarstiQ> etenil: Olive's conflict support would just be gconflict though, so that needs to work first.
<etenil> would it be possible to run "bzr resolve" after the external merge tool has exited?
<etenil> if it would be trivial, I could modify the python script for that
<etenil> what do you think?
<LarstiQ> etenil: running it is trivial, I'm not sure it's the right thing to do.
<etenil> well, that'd be an improvement already
<LarstiQ> etenil: not if it resolves too much.
<etenil> it can run only on the current file
<etenil> ie: bzr resolve <file>
<LarstiQ> etenil: yes, if after the closing the external merger you are actually done.
<LarstiQ> etenil: if it is a complex conflicts case, you may well not be.
<etenil> is it possible to put a button on olive's interface then?
<LarstiQ> etenil: if it wasn't external, you could have a "resolved/resolve" functionality, and then run it
<LarstiQ> etenil: sure
<etenil> would it be hard?
<LarstiQ> etenil: with external, it is harder to tell
<LarstiQ> etenil: no
<etenil> I've never used gtk with python
<etenil> that would be the best solution in my opinion
<etenil> are you knowledgeable about python LarstiQ?
<LarstiQ> etenil: I know my way around.
<etenil> ok, I'll ask you if I get stuck
<LarstiQ> ok :)
<etenil> is that ok?
<etenil> thx
<etenil> do I need to import a module to be able to resolve conflicts?
<etenil> I have a menu item, but I need to run the command now
<etenil> and I'm not sure how
<luks> awilkins: FYI qbzr trunk@585 now contains qconflicts, but only as useful as gconflicts, so probably not much :)
<LarstiQ> etenil: have a look at how it opens a diff window for example
<LarstiQ> etenil: and then have a look at conflicts.py for the definition of the conflicts window
<LarstiQ> etenil: and __init__.py for cmd_gconflicts
<etenil> well, what I just need to run the resolve command and print its output, no?
<LarstiQ> etenil: for that, see what cmd_resolve from bzrlib.conflicts does
<etenil> ok
<etenil> er
<etenil> I have found the command, but I need to pass the tree to it
<etenil> not sure where to find it
<etenil> ok
<etenil> will try out
<etenil> I did it!!
<etenil> cool
<etenil> is it ok to send back my changes on launchpd?
<Lo-lan-do> jelmer: I'm sorry for intruding again, but... help!
<jelmer> Lo-lan-do, np
<jelmer> Lo-lan-do, what's up?
<Lo-lan-do> I filtered out all the bzr:* properties from the repo
<Lo-lan-do> $ bzr branch filtered2/trunk f2+bzr
<Lo-lan-do> Initialising Subversion metadata cache in /home/roland/.bazaar/svn-cache/9d84d37e-dcb1-4aad-b103-6f3d92f53bf6
<Lo-lan-do> bzr: ERROR: The branch filtered2/trunk has no revision None.
<igc> night all
<jelmer> Lo-lan-do, can you put that repo online somewhere?
<jelmer> 'night Ian
<Lo-lan-do> Sure
<jelmer> igc: Thanks for the reviews
<jelmer> igc: Looking forward to trying out your log improvements (-:
 * Lo-lan-do de-does the filtering on the server
<jelmer> Lo-lan-do, hmm, that exception handler triggers in too many situations
<Lo-lan-do> s/de-does/re-does/
<Lo-lan-do> Urgh, apparently some bzr:* properties are still there.
<Lo-lan-do> Damn, they're *revision* properties and not file properties :-(
<Lo-lan-do> Fortunately I think I can filter that out without doing the dump|filter|load routine.
 * Lo-lan-do tries again
<Lo-lan-do> Slightly unrelated question: can specifying a newer format when branching accelerate the branching process?
<Lo-lan-do> What seems to take time here is the "copying revision 1968/5459" stuff.
<jelmer> Lo-lan-do, yes, 1.9-rich-root will be faster because it's got faster indexes
<Lo-lan-do> Right.  I'll try that for the next try then :-)
<ToyKeeper> ... it would be terribly nice if bzr had a way to destructively edit history.
<ToyKeeper> Like dump / edit / reload in svn.
<ToyKeeper> I have a tool in a closed-source repo that I want to open up, but I'd need to edit any sensitive data out of the history.
<nevans> ToyKeeper: you can certainly uncommit (and rebase, using the rebase plugin).  That would probably get you what you want.
<nevans> dunno if someone has made any filter script/plugin to automate what you seem to be looking for.
<ToyKeeper> I've also wanted to do things like split a branch subdir, with history, into the root of a new branch.
<nevans> bzr help split :)
<jelmer> ToyKeeper, check out "bzr split"
<ToyKeeper> I know it would invalidate all the revision IDs, but that's not really a problem.
<nua> having a real nightmare with this error: http://pastebin.com/m7387496f, it keeps appearing after I've used a repository for a while, this time it occured after commiting .bzrignore
<ToyKeeper> Last I checked, 'split' didn't do what I was looking for.
<ToyKeeper> (the opposite of merge-into, basically)
<jelmer> nua, please file a bug
<nevans> split retains the old history.  that could be a problem if you are looking to open source a closed source package but retain the history.
<jelmer> nua: (I have no idea what's happening, but that way the problem should get some attention from those who do)
<jelmer> hi nevans
<nevans> heya jelmer
<nua> jelmer: will do, but if anyone knows a workaround let me know, I really need repo access so we can update!
<ToyKeeper> The use case for the "opposite of merge-into" feature is something like...  say a project includes a lot of themes, and someone wants to break a theme into its own repo without the rest of the project history.
<ToyKeeper> Or, if several projects were incorrectly kept together in one branch, and someone later wants to clean it up by splitting them.
<jelmer> ToyKeeper, ah, split keeps the history nideed
<jelmer> ToyKeeper, that operation will always require breaking revision ids
<ToyKeeper> That's perfectly acceptable.  :)
<ToyKeeper> I'd like to keep the timestamps and log messages, but I expect revision IDs to break.
<luks> some kind of filter for the bzr-fast-export output should do the job
<ToyKeeper> Hmm, that's a thought.
<ToyKeeper> That might work for the opening-a-closed-project case too, though I'm not sure it's worth the effort.  It may be better to just use the latest as a new first version, instead of editing sensitive data out of hundreds of patches.
<jelmer> asabil is working on a filter-branch command that should do something like this I believe
<asabil> jelmer: I pushed an initial branch
<asabil> but something is wrong
<asabil> the commits are empty :/
<Lo-lan-do> Over-enthusiastic filter?
<ToyKeeper> For the remove-sensitive-history case, it might be easier to import it into darcs, edit patches, then convert back.
<asabil> yep
<ToyKeeper> Rebase at least should take care of simpler things like removing a revision entirely, like if someone adds a huge binary which shouldn't be there.
<Lo-lan-do> jelmer: Success!
<Lo-lan-do> jelmer: The branch completed :-)
<Lo-lan-do> I therefore present the world with http://pastebin.com/f539dd4ff a filter for "svnadmin dump|filter|svnadmin load" that removes all bzr:* properties from an SVN repo.
<jelmer> Lo-lan-do, in this particular case I think just the bzr:base-revision / bzr:revision-id revision properties would've sufficed
<Lo-lan-do> Well, it didn't hurt, and since we changed repos we might as well start from a clean state.
<jelmer> Lo-lan-do: yeah, of course
<jelmer> hmm, those version numbers in the ppa are a bit crazy: 0.5.0~rc2~bzr2391-1~bazaar1~jaunty1
<asabil> jelmer: you were talking about calling set_revision() before calling complete_revert() yesterday
<asabil> could you please explain a bit ?
<hazmat> is there any reason bzr asks users to try and understand 10 different repo formats, and doesn't just default to the latest stable format?
<hazmat> ie.. just choose the one with the best performance
<asabil> backward compatibility
<hazmat> for an init or init-repo command? can't that assumed to be new dev? or you mean compatiblity across distributed clients?
<asabil> accros distributed clients
<LarstiQ> hazmat: if you just `bzr init/init-repo` it won't ask about formats and pick the default
<hazmat> it picks the oldest (0.9.2) .. when there are newer faster versions
<asabil> for example if you create a repo using the 1.9 format, bzr-1.5 clients will definitely have problems with it
<LarstiQ> hazmat: 0.92 is still the default
<LarstiQ> hazmat: which would be 'latest stable format' from a compatibility standpoint
<hazmat> is there some sort of project/dev policy in place to update that default, or is bzr stuck on 0.9.2 for ?
<asabil> hazmat: 0.9.2 is not the oldest btw
<LarstiQ> hazmat: the default has been bumped several times, we are not stuck on 0.92 (no extra .) forever
<hazmat> cool. thanks for the info.. just wanted to give bzr the best  opportunity to impress with speed improvements.. cheers
<asabil> LarstiQ: could you btw please explain the duality rich-root vs non-rich-root ?
<Lo-lan-do> What, again?
<LarstiQ> hazmat: right, you can trade compatibility for speed, if you know who is going to interact with your stuff, you may choose to do so
<asabil> never got an explanation for that one :D
<hazmat> and wondering about the conflict for simplicity when compared to the complexity of all  the --help options on commands like init/init-repo
<LarstiQ> asabil: we went over it yesterday with kfogel
<asabil> oh oki
<asabil> let me see the log
<asabil> thanks
<LarstiQ> asabil: if that doesn't make it clear, feel free to ask again
<Lo-lan-do> (Might be worth a place in the docs or on the wiki)
<LarstiQ> Lo-lan-do: yeah
<LarstiQ> hazmat: maybe we shouldn't display all the formats there by default
 * LarstiQ makes his first scmproj project
<hazmat> hard to say.. but it feels like a case of leaky abstractions.. ditto for rich-root.. end user conceptualization of rich-root.. is to use bzr-svn do magic x
<sidnei> hazmat:  fwiw, i've been bitten by the default repo format too. it's trivial to upgrade to later formats though, just a 'bzr upgrade --<version>' away. i agree that it should probably default to a later version, or at least give you more hints about how to do so.
<Lo-lan-do> jelmer: Am I right that current versions of bzr-svn don't use svn properties anymore?
<jelmer> Lo-lan-do: not sure I follow?
<jelmer> Lo-lan-do, svn file properties you mean?
<sidnei> one issue is that the next format after 0.92 is 1.6, which is not even 6 months old yet
<Lo-lan-do> Ah, yes, it's stored in revision properties now I guess.
<Lo-lan-do> I was wondering why I didn't see anything in an svnlook diff :-)
<Lo-lan-do> Great, so I'm back with a working bzr-svn setup on the new repo, yay :-)
<sidnei> LarstiQ: maybe the help for init-repo should refer to 'bzr help current-formats', that text looks a lot more clear
<LarstiQ> sidnei: yes. Although a place for old formats is probably needed as well.
<sidnei> LarstiQ: that would be 'bzr help other-formats'
<LarstiQ> sidnei: done well, I'd support merging a patch that makes the init-repo/init help less overwhelming
<LarstiQ> sidnei: ah, good :)
<LarstiQ> sidnei, hazmat: care to write a patch/file a bug for this?
<asabil> can someone with deep bzr knowledge help me with filter-branch please ?
<LarstiQ> asabil: I don't know if I can help, but ask your question.
<asabil> I followed jelmer's advice by using some code from bzr-rebase
<asabil> I am ablt to rebuild the history graph
<asabil> but all the commits are empty
<asabil> the code is in lp:~asabil/+junk/bzr-filter-branch
<LarstiQ> asabil: entirely empty? No log, no file deltas?
<asabil> there is a log
<asabil> but there are no deltas
<kfogel> https://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3#comment-639
<kfogel> I've asked for details on how he ran those experiments.
<jelmer> kfogel, thanks, interesting link
<jelmer> the brisbane-core branch should fix that last benchmark
<kfogel> jelmer: might want to follow up saying that
<LarstiQ> asabil: hmm, the command line has something like --unchanged ('pointless' in bzrlib iirc), you're not doing that I suppose?
<asabil> no not at all
<LarstiQ> asabil: I'm currently a bit too winded up to actually look at the code, sorry
<asabil> no problem LarstiQ, I am not in a hurry anyway
<asabil> thanks for your help
<awilkins> vila: ping?
<vila> awilkins: pong
<awilkins> vila: Ran into an auth error in 1.11
<LarstiQ> vila: Aha! I got .netrc to serve up a password. I had to change some code though, since it tries credentials['host'] but that key isn't present
<vila> LarstiQ, awilkins: respect the yellow line please except if you're sprinting together :-)
<awilkins> Is there a sprint on?
<LarstiQ> vila: unrelated afaik, though we could have stumbled on the same thing at the same time
<awilkins> Ah
<vila> LarstiQ: kidding :)
<vila> awilkins: go ahaead :)
<LarstiQ> vila: I was making good on my promise from yesterday that I'd look further into .netrc ;)
<vila> LarstiQ: bug filing or patches welcome anyway
<awilkins> http://pastebin.ubuntu.com/110884/
<awilkins> The value of header on the break line is "NTLM"
<vila> well, that's not supported anyway :-/
<LarstiQ> vila: will do
<awilkins> vila: Yes, I'm not sure why it's using NTLM, I don't think it's configured that way
<awilkins> But it may be our proxy sticking it's beak in
 * awilkins turns off proxy in IE
<vila> awilkins: that's your server :) But if you can write a test to reproduce the problem , I'd welcome that warmly
<awilkins> Aha, when I turn that off, the header is 'Basic realm="webds1lds"'
<vila> awilkins: by the way, since that's a 407 error, that's indeed your proxy
<awilkins> So I guess the split is splitting on " " by default
<awilkins> (Python noob)
<vila> the problem is that NTLM seems to be unsplittable...
<awilkins> Yes, I thought so
<vila> i.e. if the header is only 'NTLM' this can't be split into scheme == 'NTLM' and raw-auth = ''
<jelmer> that reminds me, I wanted to look at supporting WWW-Authenticate: Negotiate
<vila> jelmer: isn't it the same thing ?
<awilkins> Does urllib2 support PAC scripts?
<awilkins> I get the error when I configure a fixed proxy in IE even if it's configured to ignore local addresses, but if you disable that and just set the PAC script it works ; is this because it's reading the PAC script and going "DIRECT" or is it because it can't use them.....
<sidnei> it doesn't support PAC scripts, afaict.
<vila> awilkins: I'd be surprised if urllib2 supported PAC scripts...
<awilkins> Likewise, must just be because I turned off the manual proxy
<vila> awilkins: how comes you find the problem only today ?
<awilkins> I don't push to this server from this network location often
<awilkins> And I've been running 1.9 too
<vila> oh, ok, that's worth reporting as a bug anyway mentioning the traceback and the value of header on the break line
<awilkins> Looks like we need an NtlmAuthRequestHandler in http_utils.py
<awilkins> I've got a bit of code for detailed stack dumps with parameter values somewhere
<vila> awilkins: even if it justs refuse to authenticate, yes, that will be a good start
<vila> or you may define it  just in test_http.py for a start
<vila> igc: ping, I have bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict failing since a couple of days/weeks and no idea on how to fix it (the test is 3 lines long but the failure output is 800 lines long giving me little hints :-/)
<jelmer> vila, NTLM is one of the backends of "WWW-Authenticate: Negotiate"
<jelmer> vila, I'm mainly interested in kerberos, which is the other one
<vila> jelmer: thanks for the precision
<jelmer> We'll need custom code to deal with both of them
<xnox> Hello everyone =D I thought a saw somewhere randomly that ipython can be used as shell, but so that it keeps bzr imported to improve invocation time
<xnox> Can anyone point me to the right place?
<Lo-lan-do> xnox: No need for ipython, just run "bzr shell"
<Lo-lan-do> (In the bzrtools plugin)
<xnox> ok. But ipython integrates incredibly nicely into emacs......... sigh
<xnox> but do you think it is possible to merge the two?
<Lo-lan-do> I may be mistaken about what you call ipython...
<Lo-lan-do> Isn't it the Microsoft reimplementation of Python over the .net thingy?
<xnox> no
<awilkins> ipython is a shell
<awilkins> IronPython is the CLR implementation of Python
<Lo-lan-do> Oh, sorry, I'm confusing it with ironpython.
<Lo-lan-do> Then I'm afraid I don't know :-)
<xnox> Lo-lan-do: ipython is multi-threded + python interpreter on streroids
<santagada> xnox: you want to import bzr on ipython and still use ipython for python development?
<santagada> I don't know but seems like a bad idea
<xnox> I use it a lot with nympy+scipy+matplotlib which can do resource hungry calculations in a more user-friendly way (+ it opens gui windows with graphs)
<santagada> ok but mixing two programs that were not made to work together is flaky
<xnox> santagada: and use it as my default shell
<xnox> santagada: there is a launchpad profile for ipython already with uses launchpadlib
<santagada> the whole idea of modern operating systems is protected memory (well ignoring sing#)
<santagada> even if it exists I would not trust it with my code :)
<xnox> I haven't tried it but you can query launchpad for bugz and people
<santagada> ok
<santagada> I'm not saying that using it with ipython is bad
<santagada> I'm saying that mixing it with another completely unrelated program is a bad idea
<santagada> using it for work
 * xnox already runs emacs for email, irc, shell, ipython and what not =D
<santagada> for example, numpy might be corrupting memory
<santagada> after all it is a c extension
<xnox> I see your point
<santagada> xnox: all those were made to be used together
<xnox> hmmmmm
<santagada> xnox: and you can have a subshell in emacs with protected memory and all to run bzr shell
<xnox> santagada: I'll do that then
<LarstiQ> as a vi and ipython user, I wouldn't mind some bzr support in ipython
<santagada> xnox: and I will some day learn emacs :)
<santagada> I mean really learn emacs
<LarstiQ> xnox: any idea where you saw that?
<xnox> LarstiQ: seriosly I can't remember and I've already searched all my browser history
<xnox> santagada: funny you should say this. I've learned emacs by accident and it was a reason why I've switched to ubuntu
<santagada> xnox: I'm a textmate user right now, but I use emacs from time to time
<xnox> santagada: I needed good TexLive installation and a good Latex editor. I've googled and Auctex came up (part of emacs). I managed to install a half broken texlive and a half broken emacs on my mac. Then someone told me "it's all in the repos in Ubuntu" and I'm like really????? So that's why I've tried Ubuntu in VM.... to run emacs =DDDD
<santagada> it still amases me the python indentation that emacs does and the html mode is also impressive
<xnox> santagada: textmate is HOT
<santagada> there is a bzr plugin somewhere, do anyone knows who is responsible for it?
<santagada> because it is not on the textmate plugin repository and it should really be there if there is any intention to be used by a lot of people
<xnox> santagada: and then it can't wrap lines backwards. So if you have a paragrah and you strart deleting lines on the say 3 row it will not automaticly join the 3rd line back up
<xnox> santagada: I thought textmate came prepackaged with it.....
<LarstiQ> santagada: it is not listed on http://bazaar-vcs.org/IDEIntegration eitehr
<santagada> xnox: textmate comes with a lot of plugins, them you can install the svn plugin repository that brings many more
<santagada> LarstiQ: http://bazaar-vcs.org/TextMateBundle
<LarstiQ> santagada: ah, could you check that out and add it to IDEIntegration and TextMate plugin list if it's still alive?
<santagada> LarstiQ: it is not... last updated in 2007
<santagada> maybe I can improve it
<LarstiQ> santagada: ah. Contact the author?
<santagada> LarstiQ: I will contact Jeremy Wilkins... let me see if I can find John Whitley
<santagada> LarstiQ: can you find its registering email on Bazaar wiki?
<LarstiQ> awilkins: Jeremy Wilkins doesn't happen to be related to you?
 * xnox lol
<LarstiQ> santagada: you could try bangpath.org@gmail.com
<LarstiQ> santagada: but as the entire site seems MIA, maybe that doesn't work either
<LarstiQ> santagada: aha, whitley@acm.org
<LarstiQ> santagada: if that does not work, the Internet can not help him.
<santagada> I will mail those guys to see if they want to continue the work somewhere or anything like that
<LarstiQ> santagada: cool, thanks
<santagada> LarstiQ: done
<santagada> LarstiQ: do you know if anyone tried to run baazar on top of some other python implementations?
<santagada> I could give a try on pypy... though I think that paramiko is not supported
<LarstiQ> santagada: I'm not aware of such a feat
<jelmer> monodevelop bzr does some ironpython stuff I think
<Lo-lan-do> Can one disable display of progress bars for bzr operations?
<Lo-lan-do> I'd like to run a bzr update in a cron job, and only see the errors.
<Lo-lan-do> (-q doesn't help)
<jelmer> Lo-lan-do, there is an environment variable, not sure how it's called
<Lo-lan-do> Thanks, I'll look it up.
<Lo-lan-do> BZR_PROGRESS_BAR=none :-)
<LarstiQ> Lo-lan-do: also see bug 320035
<ubottu> Launchpad bug 320035 in bzr "progress bar is shown regardless of the --quiet option" [Low,Incomplete] https://launchpad.net/bugs/320035
<xnox> thanks ubottu that was quick!
<jpds> !thanks | xnox
<ubottu> xnox: You're welcome! But keep in mind I'm just a bot ;-)
<xnox> ubottu: stop pretending
<ubottu> Sorry, I don't know anything about stop pretending
<santagada> LarstiQ: there isn't a --batch for bzr?
<santagada> it should
<santagada> I'm working with the svn client daily and I really hate its support for being used on the command line
<xnox> ubottu: really? are you like psychotherapist in emacs?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
 * xnox thinks ubottu should marry emacs psychotherapist
<santagada> well if it was made in python it would be much easier to just use the api directly... but there is people who doesn't use python...
<xnox> santagada: there is pymacs a two way interface between python and elisp which is as close as you can get =D
<LarstiQ> santagada: what would --batch do?
<santagada> LarstiQ: don't ask for anything and don't be fancy on output (like progress bars)
<santagada> if it would also turn strictier error messages the better
 * vila thinks xnox is weird... what will the children of ubottu and emacs psychotherapist will look like....
<LarstiQ> santagada: ah. I don't think so.
<LarstiQ> santagada: but BZR_PROGRESS_BAR=none and -q get you a long way
<LarstiQ> santagada: prompts could happen on push/pull/update/commit (the latter on checkouts), uncommit
<santagada> LarstiQ: svn at least has --non-interactive
<santagada> turn every prompt to an error
<santagada> the problem is that sometimes svn fails silently
<LarstiQ> santagada: I haven't had use for --batch or --non-interactive, but I think it would be merged
<santagada> LarstiQ: --batch was something I asked about, does it really exists?
<LarstiQ> santagada: in bzr? No
<santagada> LarstiQ: ahh ok
<LarstiQ> !summon bialix
<ubottu> Sorry, I don't know anything about summon bialix
<jelmer> jam, ping
<jam> jelmer: pong
<jelmer> jam, How should I be using deprecated_list ?
<jelmer> (since I would have to create SPEC_TYPES on demand)
<jam> SPEC_TYPES = symbol_versioning.deprecated_list()
<jelmer> ahh, ok
<jam> and then later on, consult SPEC_TYPES as part of finding a matching prefix
<jam> either that, or override .append() and make it actually forward to register
<jelmer> I'll do the latter, that keeps the deprecated stuff in a single place
<LarstiQ> are there any other scmproj users around? I'm struggling a bit with how to use subprojects
<kfogel> If I did 'bzr init-repo', and now want to do it over with the --1.9 or some other option, can I just rm -rf .bzr?
<santagada> kfogel: I'm not sure, but I guess yes, why would it not be the case?
<kfogel> santagada: makes sense to me
<santagada> kfogel:
<santagada> ops
<kfogel> Anyone know if I should use --1.12-preview, or just --1.9?
<santagada> kfogel: why would you use --1.9?
<kfogel> (I'm testing bzr performance on a large tree -- the Emacs conversion from CVS -- so it's okay to use modern formats).
<santagada> kfogel: speed?
<kfogel> santagada: I just assume higher is better.
<kfogel> santagada: AFAIU, the only reason --1.9 isn't the default is for compat reasons, right?
<santagada> kfogel: bzr help current-formats
<santagada> and bzr help formats
<santagada> and other-formats
<kfogel> santagada: thank you.
<santagada> kfogel: If I understood correctly 1.9 is the fastest stable format
<kfogel> But as a user, I don't want to have to know this stuff... :-).  I just want to get "whatever the best format is for a team who will all be using the latest bzr".
<santagada> kfogel: but if you are benchmarking for a future migration then I think testing the newest kid on the block is also an option
<kfogel> IOW, the only reason I'm even thinking of --1.9 is because I understand that it would be the default were it not for compat concerns.
<kfogel> santagada: well, the future migration may happen before 1.12 comes out, so 1.9 is probably my best bet.
<LarstiQ> kfogel: bzr upgrade --1.9?
<santagada> kfogel: help formats has a simple algorithm to choose the repo version :)
<kfogel> LarstiQ: thank you
<kfogel> santagada: thanks, reading now
<LarstiQ> kfogel: might need some care on tree/branch/repo format distinctions, possibly.
<LarstiQ> kfogel: there is alos `bzr reconfigure` for slightly different usecases
<santagada> LarstiQ: what kfogel told is that he has not made any commits, so upgrade or deleting and recreating would be the same right?
<kfogel> LarstiQ: so I'm doing 'bzr init-repo' here, and then I'm going to clone an already-existing branch into it (bzr://bzr.notengoamigos.org/emacs-merges-ce/master/)
<LarstiQ> kfogel: oh you just have a repo?
<LarstiQ> santagada: yeah, should be.
<kfogel> LarstiQ: I'm creating a repo, into which I'm going to pull/mirror this branch.
 * LarstiQ nods at kfogel 
<kfogel> The branch is 1.9, so maybe that answers my question.
<kfogel> hmmm
<kfogel> I might be saying "branch" where I mean "repository".
<kfogel> sigh
<kfogel> I was going to point you at the mail from the person who created that repos, but the emacs-devel@ mailing list archive is broken in such a way as to omit exactly his messages.
 * kfogel .oO Why is everything at GNU always in a half-broken state?
<LarstiQ> hey, the Hurd is not half-broken! :)
<santagada> :)
<kfogel> http://paste.lisp.org/display/74430
<LarstiQ> kfogel: what does -ce stand for?
<LarstiQ> are the two the same, apart from 0.92 vs 1.9?
<kfogel> I'm a little unclear on the difference between a repository and a branch in this context.  Jason Earl has created a test conversion of Emacs CVS tree; that's the bzr://bzr.notengoamigos.org/emacs-merges-ce/master/ referred to above.  So do I 'bzr init-repo --1.9 emacs-repo' locally and then 'cd emacs-repo' and then 'bzr branch bzr://bzr.notengoamigos.org/emacs-merges-ce/master/ emacs-merges-ce-master', or something like that?
<kfogel> LarstiQ: I'm not sure why he chose "ce" to refer to the 1.9 version.
<kfogel> Common Era?
<santagada> kfogel: creative enhancement?
<james_w> kfogel: that'll work
<LarstiQ> kfogel: that'll work
<kfogel> Personally, I can't stand that abbreviation when used in scholarly publication, because it loses information.  But hey, if Jason is doing test conversions for us, I'll make an exception!
<kfogel> LarstiQ, james_w: cool, thank you
<LarstiQ> kfogel: I think the entire repo would be 1.9 though, since it's mainly a repository format afaik.
<james_w> there is a bit of confusion caused by the fact that there are formats for repositories (dealing with revisions storage), branches (tags and the like) and working trees (how the basis tree is stored amogst other things), but they are all wrapped up in to common formats
 * LarstiQ nods
<james_w> so --1.9 refers to a format for each object
<pickscrape> Does anyone know when bzrtools 1.11 will hit the PPA?
<LarstiQ> kfogel: in the case that Jason had provided a standalone branch, `bzr reconfigure` would be a tool to make it into a shared repository.
<kfogel> james_w: thank you.  Yes, sometimes that confusion leaks out to user-land.
<james_w> kfogel: yeah, it's unfortunate. In an ideal world it would be transparent.
<LarstiQ> pickscrape: I don't. Do you know who the uploader is?
<pickscrape> Currently apt won't let me upgrade to bzr 1.11 without uninstalling bzrtools first.
<kfogel> LarstiQ: so a standalone branch is basically a branch that contains its own mini-repository in its .bzr dir?
<kfogel> james_w: amen
<LarstiQ> kfogel: exactly.
<pickscrape> LarstiQ: bzr 1.11 was uploaded by mbp
<LarstiQ> pickscrape: and bzrtools 1.10?
<pickscrape> LarstiQ: By jameinel
 * LarstiQ reads ppa.txt
<kfogel> LarstiQ: do you know the hysterical raisins behind the situation?  I confess it worries me that pretty much every time someone goes to switch a project over to bzr, or start something new in bzr, the first thing they have to do is enter into this long consideration of (and often discussion of) storage formats and whether or not to make a full repository.
<LarstiQ> kfogel: I'm frankly surprised at people considering formats. I personally stick with whatever is the default unless I have a very good reason.
<pickscrape> Yes, that's what we did too
<LarstiQ> kfogel: but someone today noted that the init/init-repo help lists all the formats
<LarstiQ> kfogel: That might be a source of the people considering formats, I think moving them away and instead referencing the topics formats, current-formats and other-formats would be better.
<LarstiQ> kfogel: another reason people consider formats might be interopability with bzr-svn, since that uses a non-default format.
<santagada> LarstiQ: if you have a repository as big as emacs I think considering the fastest one avaliable is important, as the help formats says
<kfogel> LarstiQ: Unfortunately, when large (many files, big files, deep history, whatever) projects are considering switching, they have to consider formats, or run into performance issues.
<LarstiQ> santagada: true
<kfogel> LarstiQ: yes, that's another cause
<kfogel> LarstiQ: agreed, about just referencing the formats/current-formats/other-formats help from the option help in init-repo
<LarstiQ> kfogel: does `help formats` carry a decision tree? It should
<LarstiQ> ah, it does (in bzr.dev at least)
<santagada> LarstiQ: yes... help formats is really well written
<LarstiQ> kfogel: do you think `help formats` helps to diminish the long considering/discussing?
<mm-mysql> Hey, does anyone know if --fixes=... creates metadata anywhere? If so, how does one see it, I don't see it come up with "bzr log --long"..
<kfogel> LarstiQ: once one knows about 'help formats', it is a great help!
<kfogel> But the hurdle is having to think about formats at all.
<LarstiQ> mm-mysql: yes, it does
<kfogel> Once the user is there, the lossage is already huge, and 'help-formats' can only mitigate it.
<LarstiQ> kfogel: right. On that topic, I don't feel too qualified.
<santagada> kfogel: if help formats were the first place anyone would go to find out more about formats I think it would be a minor problem before some point in the future when a faster repository format is the default, don't you think?
<LarstiQ> I know I switched to fsfs after the nth time of bdb breaking on me.
<LarstiQ> mm-mysql: let me have a lookg
<LarstiQ> mm-mysql: I know launchpad uses the information, and some trac hooks too
<kfogel> LarstiQ: you mean in svn?
<mm-mysql> LarstiQ: okay...thanks
<LarstiQ> kfogel: yes, sorry
<kfogel> santagada: having to think about repository format at all is a major problem, I think.  But it'll be solved once a) the best format is the default, and b) format interop is better.
<kfogel> LarstiQ: yeah.  Fortunately, fsfs is the default and no one has to think about BDB these days unless they're doing something very unusual.
<LarstiQ> mm-mysql: `bzr help bugs` mentions it is stored in the revision property, but not how to get at it, looking at more code
<LarstiQ> kfogel: yeah, when I switched bdb was still default
<kfogel> LarstiQ: long time ago! :-)
<Lo-lan-do> jelmer: I'm happy to find myself able to work on the svn repo through bzr again, but I'm back into performance problems.
<Lo-lan-do> http://pastebin.com/d59b55836 for a timing
<jelmer> Lo-lan-do, was there a bug open about this yet? If not, please file one
<jelmer> Lo-lan-do, I would like to get this fixed, but I'd like to get 0.5 out first, otherwise I end up maintaining 0.4 and 0.5 in parallel
<santagada> Is bzr already able to serve a repo using svn's protocol? that was mentioned on the python scm migration thread
<LarstiQ> kfogel: yeah, I started using svn on 0.11 or something?
<jelmer> santagada, somewhat
<jelmer> santagada, It's not production ready yet
<jelmer> santagada, but some commands (e.g. svn log) are supported
<Lo-lan-do> jelmer: I'll file a bug, sure.
<kfogel> santagada, LarstiQ: not bad: http://paste.lisp.org/display/74432
<kfogel> LarstiQ: wow, looooooong time ago
<LarstiQ> kfogel: you has a branch :)
<LarstiQ> kfogel: not important, but you know you could `bzr init-repo --1.9 emacs-bzr` and save a mkdir step?
<kfogel> LarstiQ: yes, knew, thanks
<kfogel> LarstiQ: I put some other notes in there too; didn't show that in the transcript as it can't possibly affect anything, right?
<kfogel> (they're unversioned)
<LarstiQ> kfogel: you've lost me. You have unversioned files in the emacs-bzr repo, or in the emacs-merges-ce-master branch?
<LarstiQ> log only reads historical data, so I would be very surprised if that affected anything
<kfogel> LarstiQ: 'mkdir emacs-bzr; cd emacs-bzr; emacs mynotes.txt; bzr init-repo --1.9 .; ...'
<Lo-lan-do> jelmer: Would you remind me of the magic monster sequence of -D flags I should use?
<LarstiQ> kfogel: unless you get in the territory of 'it was in the file cache and had to be swapped out first', but I think we can ignore that
<jelmer> Lo-lan-do, I usually only use -Dtransport
<Lo-lan-do> 'kay
<jelmer> Lo-lan-do, oh, -Dcache may also be useful
<kfogel> LarstiQ: now I'm doing a 'bzr log --long -v'
<LarstiQ> kfogel: I know we can be finicky about creating a bzr object in a non-empty directory, I don't think init-repo minds though.
<kfogel> and wondering what the difference between -v and --long is (that is, wondering if one is a superset of the other)
<kfogel> LarstiQ: *nod* thanks
<LarstiQ> kfogel: -v adds a list of files touched in the revision
<kfogel> LarstiQ: that wasn't the actual order anyway
<LarstiQ> kfogel: so it needs to act on more information than just displaying the log
<LarstiQ> kfogel: -p and -v should have the same cost on reading/parsing I think.
<kfogel> LarstiQ: conceptually, some people may think of the list of changed files as *part* of the log, the same as all the other metadata associated with the log
<santagada> jelmer: is there any plans to support http repository access for svn clients?
<jelmer> santagada, that's already supported
<LarstiQ> kfogel: right. commit message only > add status output > diffstat > full diff
<nua> is .bzrignore depreciated?
<santagada> jelmer: to serve to svn clients? cool, can I read more about it somewhere?
<jelmer> santagada, oh, you mean the server side?
<LarstiQ> kfogel: displaying/needing progressively more data from left to right, all can be considered the "log of changes"
<santagada> jelmer: yep
<jelmer> santagada, no, there's no work going on to suppport that
<kfogel> LarstiQ: yeah, that's how I think of it
<LarstiQ> nua: not at all. `bzr ignore/unignore` are preferred ways to interface with it though.
<LarstiQ> nua: if you just made it by hand, you might want to `bzr add` it
<LarstiQ> kfogel: I disagree with people pasting all that information into the commit message though.
<nua> LarstiQ: ok thanks, it appears to work for me, I was just suspicious as after commiting it to a shared repo the repo died on us. could of course be unrelated
<LarstiQ> kfogel: the pyglet project for example has (not all of them luckily) commits where the log includes the full diff.
<sidnei> jelmer: barry mentioned somewhere that the server might start supporting svn clients soon
 * LarstiQ finds that unreadable
<kfogel> LarstiQ: !!
<LarstiQ> nua: unrelated, I'm rather sure.
<kfogel> that's insane
<jelmer> sidnei, the http server?
<LarstiQ> kfogel: yeah.
<sidnei> jelmer: he wasn't very specific.
<LarstiQ> sidnei: launchpad, or svn-serve?
<jelmer> sidnei, I have put some effort into supporting the native svn protocol (not http)
<jelmer> sidnei, and that's not very far away
<sidnei> jelmer: that might have been what he was referring to then
<sidnei> santagada: so i guess that answers your question
<santagada> yep
 * LarstiQ runs to the supermarket for groceries
<LarstiQ> if bialix shows up, I've been busy with scmproj today and have ~400 lines of raw notes, the main problem I don't know how to solve is how to use subprojects
<LarstiQ> bbl
<theAdib_> hello: what does does answer to bzr pull means? (I did a bzr branch bla days ago)
<theAdib_> adib@nbdel171:~/Projekte/libgnupdf$ bzr pull
<theAdib_> Using saved location: http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk/
<theAdib_> http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/ is permanently redirected to
<theAdib_> bzr: ERROR: No repository present: "http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk/"
<thumper> theAdib_: it seems that the repo is at http://bzr.savannah.gnu.org/r/pdf/libgnupdf/
<thumper> theAdib_: are you missing something? redirected to what?
<kfogel> LarstiQ: this has been running for at least half an hour I think: time bzr log --long -v > log-long-verbose.out
<theAdib_> thumper: I only wanted the files from http://bzr.savannah.gnu.org/lh/pdf/libgnupdf/branches/trunk/files and not the additional directories branches/trunk in my local file system
<thumper> theAdib_: sure
<thumper> theAdib_: what have you done so far?
<theAdib_> thumper: I only build and run the test suite
<thumper> theAdib_: so you did a `bzr branch what?`
<theAdib_>  bzr branch http://bzr.savannah.gnu.org/r/pdf/libgnupdf/branches/trunk libgnupdf
<jelmer> hmm
<jelmer> vila, pqm seems to hang on a request from you
<theAdib_> thumper: I took this from http://www.gnupdf.org/Dev:Newcomers .
<thumper> theAdib_: and then you did a bzr pull?
<theAdib_> I will remove everything and start again ....
<thumper> theAdib_: I'm trying this too to see what I get
<thumper> theAdib_: no, don't do that yet
<theAdib_> Yes I did bzr update and after bzr pull
<mtaylor> lifeless: upgrading from pack-0.92 to 1.9, there are local operations that should become quicker, right?
<theAdib_> thumper: btw I work here an Ubuntu 8.10
<theAdib_> adib@nbdel171:~/Projekte/libgnupdf$ bzr version
<theAdib_> Bazaar (bzr) 1.6.1
<theAdib_>   Python interpreter: /usr/bin/python 2.5.2
<theAdib_>   Python standard library: /usr/lib/python2.5
<theAdib_>   bzrlib: /usr/lib/python2.5/site-packages/bzrlib
<theAdib_>   Bazaar configuration: /home/adib/.bazaar
<theAdib_>   Bazaar log file: /home/adib/.bzr.log
<thumper> theAdib_: sure, since it looks like you have a standalone branch, you shouldn't need to do an update after the pull
<thumper> theAdib_: as the pull will update the working tree
<thumper> theAdib_: you should get a message like: Tree is up to date at ...
<theAdib_> pull will synchronize my branch with the original source even I modified my branch?
<thumper> theAdib_: if you have committed to the branch locally, you should get a warning about diverged branches
<thumper> theAdib_: if you have uncommitted changes, I think it updates and merges and will let you know of conflicts
<theAdib_> I did not commit anything
<fullermd> kfogel: Interesting set of benchmarks, that.  Nice contrast to the more common "make a history with 1..5 revisions and make claims about performance"
<kfogel> fullermd: when I look at the in-progress log, it's going incredibly slowly.  It's only back to March of 2008 so far.  The Emacs history goes back to 1985!
<fullermd> Oh, the log -v?  Yeah.  That's "special".
<santagada> kfogel: I think cvs is from around 1984 no?
<fullermd> On bzr.dev, log --long >> /dev/null takes a bit under 30 seconds for me.  Last time I tried it with -v, it was like 15 minutes or so.
<fullermd> kfogel: I walk talking about that URL you pasted earlier today.
<kfogel> fullermd: not sure which of several URLs you saw
<kfogel> santagada: cvs from 1986, but RCS predates CVS
<santagada> kfogel: cool, so you have history from before cvs...
<kfogel> santagada: we do, yep
<kfogel> santagada: Most people don't know it, but Emacs was originally written in ancient Babylonian times on base-60 machines.
<Lo-lan-do> And before RCS... CPOLD?
<kfogel> heh.  I think RCS was Emacs' first vcs.  Unless sccs, maybe.
<Lo-lan-do> (...by people with 24 fingers)
<OltreIrc`16561> hello
<OltreIrc`16561> !list
<ubottu> Hi! I'm #bzr's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<thumper> :)
<thumper> perhaps he was wanting people to reply?
<fullermd> kfogel: The DVCS Roudnup one.
<kfogel> fullermd: ah yeah, thanks
<sidnei_> my guess was that emacs was literally 'written', as in handwritten. that was a close guess then.
<fullermd> Written?  Why write, when we have chisels and all the free stone we could want?
<fullermd> bialix: LarstiQ was looking for you about an hour ago with scmproj notes.
<LarstiQ> and I've just returned myself
<LarstiQ> fullermd: thanks :)
<bialix> fullermd: hi!
<fullermd> Synchronicity   :)
<bialix> LarstiQ: heya
<LarstiQ> bialix: evening!
<LarstiQ> bialix: did you also just buy toilet paper? ;)
<bialix> fullermd: thanks, you're my favorite immortal
<bialix> :-D
<bialix> no, dinner with daughter
 * bialix reading backlog
<bialix> what is !summon?
<bialix> LarstiQ: I gues you can ask AmanicA about scmproj
<LarstiQ> bialix: summon means 'ask to come'. !summon is then an attempt to ask the bot/internet to make you appear :)
<bialix> LOL
<LarstiQ> sometimes it works, but maybe that is random chance ;)
<bialix> Ubootu is not wizard then
<AmanicA> hi
<bialix> :-)
<bialix> Hi!
<LarstiQ> AmanicA: hello
<bialix> LarstiQ: subprojects actually in the active development
<AmanicA> hi LarstiQ, bialix
<LarstiQ> bialix: ah ok
<LarstiQ> bialix, AmanicA: I've got a 'libraries' scmproj with 11 branches from a svn repo, that worked nicely after I figured out how to get it there.
<bialix> nice
<AmanicA> cool
 * LarstiQ would now like to include that in a different project that has 3 components itself, and then the libraries subproject
<bialix> you're using bzr-svn
<LarstiQ> bialix: are subprojects supposed to work yet?
<bialix> :-)
<bialix> more or less
<LarstiQ> bialix: yes, I considered branching them from svn myself first, but I figured, why not let scmproj do it!
<LarstiQ> bialix: only minor point with bzr-svn is that I had set FORMAT in [COMPONENTS], but it didn't carry over to the sub components
<bialix> I think jelmer and J2ck very close to make bazaar people more happy with bzr-git
<bialix> all components are independent
<LarstiQ> but I have lots of notes I can distill out into bugreports/patches
<bialix> that's great
<bialix> AmanicA, LarstiQ: while our new layout is not shaped yet I can code subprojects support (experimental) based on old spec. What you think?
<LarstiQ> bialix: right. But BRANCHES and RELPATH seem to only need to be set in [COMPONENTS] if they're the same for every component (RELPATH = {COMPONENT} suits me fine)
<AmanicA> yes
<LarstiQ> bialix: how much work do you think that would be?
<bialix> LarstiQ: hmm, do you want to say it will be useful to specify default format in COMPONENTS section?
<AmanicA> then we would have a basis for further work
<LarstiQ> bialix: yes
<LarstiQ> bialix: assuming it can be overriden?
<bialix> LarstiQ: an old spec does explicitly disallow nested subprojects
<LarstiQ> bialix: one level deep works for me I think
<bialix> so it should be as easy as one sleepless night
<LarstiQ> bialix: and if I hit that limit, I know I have to just specify all components again, I can do that if that is how it is
<bialix> LarstiQ: yes, all defaults can be overriden
<LarstiQ> bialix: cool
<bialix> AanicA: yes, basis sounds great
<LarstiQ> bialix: I don't want to give you sleepless nights, but if it's not too much trouble I'd appreciate subprojects :)
<bialix> AmanicA: ^ , sorry
<LarstiQ> kfogel: yeah, log -v is too slow :(
<bialix> actually the core is already there
<bialix> it's run_action method
<AmanicA> bialix, how stable is the config file format? can I start using hacking on it yet?
<bialix> new format?
<AmanicA> that format branch
<LarstiQ> bialix: is [SUBPROJECTS] needed? It's missing from the default project.cfg
<AmanicA> bialix (I'm not in a hurry, but I may have some time next week)
<bialix> AmanicA: to make the sketch of subprojects I'll use old format (from trunk branch). New format is good enough, just "everything is optional" is not implemented
<bialix> LarstiQ" [SUBPROJECTS} ?
<bialix> sorry
<bialix> typo
<bialix> I'd like to defer them right now
<bialix> there is much smaller set of options for subprojects
<AmanicA> bialix : I thought you would rather branch lp:~bialix/bzr-scmproj/format-change/
<LarstiQ> bialix: get_subproject and set_subproject seem to index on it
<bialix> AmanicA: but I guess LarstiQ uses trunk
<LarstiQ> bialix: I did, but if I should use a different branch, I'll switch
<AmanicA> bialix: I'm just scared that to merg it into format-change later might be more effort
<bialix> wait a sec guys
<AmanicA> bialix: but if you think the changes are isolated enough, it should be fine
<bialix> AmanicA: I guess so.
<AmanicA> bialix: its up to you as your the one thats going to merge it:)
<bialix> LarstiQ: will you be there some time? I'll look into the code
<bialix> :)
<LarstiQ> bialix: I'll be here till ~23.00 CET
<bialix> 1 hour?
<LarstiQ> at least, I always plan to go sleep at time, doesn't always work
<LarstiQ> bialix: yes
<bialix> that's ok, I need some time and I'll give some answers about subprojects
<LarstiQ> cool
<bialix> LarstiQ: if you want to summon me then it's better to use jaber/googletalk/icq rather than IRC
<LarstiQ> bialix: aah, good to know
<LarstiQ> bialix: you have some method of reading irc backlog even though you're not on-channel?
<bialix> irclogs.ubuntu.com
<LarstiQ> check
<bialix> but it's usually 2 hours late
<fullermd> Darn timezones.
<LarstiQ> bialix: it explains how you could reply to things I said :)
<bialix> no, the script itself is working by cron Iguess
<fullermd> It's a little known fact that there are actually timezones that never get anything until several hours after it should get there.
<bialix> LarstiQ: :-D
<fullermd> For instance, everybody I need things urgently from mysteriously lives in them...
<LarstiQ> fullermd: :)
<bialix> fullermd: :-D
<fullermd> At the moment, there are several that are days off, even.  Luckily, in those cases, the alleged "urgency" is on their side, so it's Not My Problem.
<bialix> LarstiQ: "~400 lines of raw notes" -- wow
<bialix> LarstiQ: ping
<bialix> LarstiQ: I'll try to make something workable, though our new format/ new layout should be better here
<LarstiQ> ~.
<LarstiQ> bialix: those notes include pasted output of scmproj commands, so I didn't write a lot of prose ;)
<LarstiQ> bialix: ok
<bialix> LarstiQ: I guess today I'd better look at your notes
<LarstiQ> jelmer: are you sure 82086 is fixed?
<jelmer> bug 82086 ?
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Fix released] https://launchpad.net/bugs/82086
<LarstiQ> bialix: they're currently in a very raw state, I ask questions that I later answer and such
<bialix> LarstiQ: that said I'm better to ask the question and write some code at morning
<bialix> or maybe answer the questons
<LarstiQ> bialix: fine with me too
<jelmer> LarstiQ, yeah, you're right. Thanks
<jelmer> lifeless, ping
<lifeless> pong
<jelmer> lifeless, pqm hangfs
<jelmer> *hangs
<lifeless> pqm.ubuntu.com?
<LarstiQ> jelmer: I didn't check all of that spree intensively
<jelmer> pqm.bazaar-vcs.org
<lifeless> k
<lifeless> is it hung now?
<jelmer> lifeless, yes
<jelmer> for a couple of hours on "Wed Jan 28 17:03:20 2009 UTC: Vincent Ladeuil <v.ladeuil+lp@free.fr>, '(vila, jam) Make merge_content lca aware' "
<LarstiQ> jelmer: bug 294479 I'm also not sure of
<ubottu> Launchpad bug 294479 in bzr "Vast number of round-trips pushing stacked branch" [High,Fix released] https://launchpad.net/bugs/294479
<jelmer> LarstiQ, crap, you're right. thanksd
<lifeless> spm: I'm going to peek
<jelmer> I'll check the others again as well I guess
<lifeless> spm: multiple reports of this
<LarstiQ> jelmer: ok, let me know if I should do a more indepth check too
<jelmer> LarstiQ, launchpad didn't actually send me any sort of notification though :-(
<LarstiQ> jelmer: about the changes you made? I got ~60 emaisl
<jelmer> LarstiQ, yeah
<jelmer> I'm still waiting for them
<Lo-lan-do> (It's all an evil plot by me so you'll fix my bugs first :-)
<lifeless> spm: mail -s Rev... (pid 7014) is blocking pqm
<lifeless> spm: can we *not* kill it but rather debug it
<lifeless> jelmer: pqm isn't hanging per se; sending mail is blocking
<james_w> lifeless: hey, are you in Berlin next week?
<spm> lifeless: yerrrs. but we're kinda a bit busy with the prep for the LP rollout atm. But will do what I can?
<lifeless> james_w: no; have metric tonnes of bzr code to get done
<james_w> lifeless: shame, but I look forward to the output :-)
<lifeless> spm: ok, well please unhang it for now, but the next hang this really needs debugging
<spm> lifeless: can we hold for another hour or 2?
<lifeless> well, commits to bzr trunk are blocked
<spm> is that a yes or no? :-)
<lifeless> jelmer: ^ please answer yes or no :P
<spm> Hahahahahaha :-D
<jelmer> no :-)
<jelmer> I think we need a multi-threading PQM and patch order analysis
<spm> oki, unblocked and should all start working again shortly
<AmanicA> jelmer: did you run some script or something to close all those bugs?!
<AmanicA> jelmer: did you run some script or something to close all those bugs?!
<AmanicA> jelmer: did you run some script or something to close all those bugs?!
<AmanicA> jelmer: did you run some script or something to close all those bugs?!
<AmanicA> (sorry if I repeated myself but somethings up with my irc client)
<LarstiQ> bialix: I'm really sleepy, I'll talk to you tomorrow
<bialix> me too
<bialix> good night
<LarstiQ> sleep well
<bialix> :-)
 * bialix waves bye to all
<jelmer> lifeless, still there?
<jelmer> lifeless, I'm pondering about introducing ControlDirFormat and using a separate registry for them
<sewmyheadon> Hi Folks!  Been using BZR for the last three months (migrating from SVN) and have a boneheaded question: I've setup five local repos for projects and would like to change the directory name in which they reside.  What's the best way to 'move' or rename the containing directory without harming things?  Thanks!
<jelmer> sewmyheadon, simply renaming them using mv
<sewmyheadon> I think I found my answer here: https://answers.launchpad.net/bzr/+question/25535
<sewmyheadon> jelmer - thanks a bunch!
<xnox> I've used Olive to see what it looks like and what it does. Played with it until it crashed =D now the bzr tree is locked. How can I unlock it?
<xnox> Errno 11
<phanatic> xnox: bzr break-lock from the command line
 * xnox feels like he is doing a bank job
<xnox> phanatic: bzr: ERROR: The lock for '/home/dmitrij/src/libsword/dima' is in use and cannot be broken.
<xnox>  
<lifeless> beuno: thank jml please :)
<jelmer> lifeless, you already mention a hypothetical ControlDir and ControlDirFormat class in bzrdir.py at the moment - was that intended to just be a superclass of BzrDir and BzrDirFormat?
<lifeless> yes
<lifeless> the generic logic not tied to.bzr
<jelmer> Ok
<jelmer> lifeless, does it sound reasonable to just add that superclass for now, providing the same interface that BzrDir right now implements?
<lifeless> sure, I mean the reason I haven't is that there aren't obvious benefits other than a sort of clarity
<lifeless> and it will need tests etc
<jelmer> hmm
<lifeless> so I'd be glad to have it there; if its absence is causing you a problem definitely do it. But if having it won't actually help you, well - its your time :)
<jelmer> yeah, I think I'll just look at making BzrDir.register_control_format() use a registry
<lifeless> jelmer: isn't it already?
<jelmer> lifeless, no, it's a list
<lifeless> oh hmm
<lifeless> I used a list for ordering
<jelmer> lifeless, it's the last thing blocking bzr-svn's __init__ to just being a list of register_lazy() calls
<jelmer> *from
<lifeless> ok
<lifeless> so this object that is in the list could be a lazy object
<jelmer> similar story for bzr-git and bzr-hg (that one will save a lot of time)
<jelmer> If ordering matters I guess I should keep it a list
<lifeless> probing costs
<lifeless> old obsolete formats shouldn't be probed before current [thats internal to the bzr specific ones atm] but also .bzr should be probed before .svn/.it/.hg
<spiv> Yeah, I agree with lifeless.
<lifeless> a ListRegistry would be useful
<lifeless> transports need this too
<jelmer> hmm
<lifeless> but I think its done specifically for transports today rather than generically
<jelmer> So I could use _LazyObjectGetter and _ObjectGetter from registry, but they're private at the moment
<lifeless> that just means they are not stable IMO
<lifeless> consenting adults - its ppython
<jelmer> I always get confused by what _ means
<lifeless> it means nothing
<lifeless> python fails so epically here you can basically ignore it
<lifeless> a thing without _ is 'public stable supported and maybe deprecated' in bzr. Something with '_' is not (public and stable and supported)
<spiv> I could have sworn bzr imbued a leading _ with meaning that's relevant to plugin authors?
<jelmer> lifeless, yeah, that bit I do get - it's clear for external API users. It's a bit more vague for internal or plugin users
<lifeless> spiv: we try, but I think we fail
<jelmer> lifeless: So I take it to mean it's fine to use those objects from bzrlib.bzrdir ?
<lifeless> concretely
<spiv> jelmer: hmm, I think of plugins as external API users.
<lifeless> concretely we have no way to discriminate between 'I used this for impleentation noone else gets to play'
<lifeless> and between 'this is not to be used outside of bzrlib because its subject to change'
<lifeless> so really, you need to read docstrings to decide
<lifeless> the key thing is that if you use something with _ you need to be willing to deal with it changing or being told that its not supported to you get to pickup both pieces
<lifeless> which boils down to 'be a consenting adult'
<lifeless> lifes too short :)
<lifeless> spiv: I agree that plugins are external users - but they have the same needs as much of the in-bzrlib code - to reuse things the author didn't expect reuse to occur on
<lifeless> Aaron has expressed a desire not to incur tech debt or migration costs for code he doesn't consider 'done', which came up in a discussion around what _ really means
<spiv> Oh definitely.  Plugins are great at finding places where our public+stable+supported API needs improvement :)
<lifeless> spiv: thats one side of the coin :)
<spiv> Hmm.  It is nice to avoid tech debt.  But it's also nice to enable sexy plugins...
<jfroy|work> lifeless: This will be an unusual, out of the blue question which you may not know the answer to, but here goes: who at Canonical should someone contact about Bazaar?
<lifeless> spiv: so sexy plugins should use what they need; and if they care file bugs asking for the things they use to be made into stable apis. But don't block on the api existing - thats a chicken n egg situation
<lifeless> jfroy|work: well, any of us are good starts. What can I help you with ? :)
<spiv> lifeless: right.  But at that point a "not done" API has magically turned into something that starts to incur a bit of tech debt for someone (possibly us, possibly the plugin author).
<lifeless> spiv: my point is that on the bzrlib side it doesn't have that debt: the plugin author using it has the onus of dealing with changes until the thing is made stable
 * spiv nods
<LaserJock> is there a reason why the ~bzr repo has been inconsistent for a bit?
<lifeless> LaserJock: ?
<LaserJock> lifeless: I've been unable to upgrade bzr/bzrtools/bzr-svn for a couple weeks
<LaserJock> it keeps wanting to remove bzrtools and/or bzr-svn
<lifeless> oh you mean the ppa?
<LaserJock> yeah, the ~bzr one
<lifeless> heh, repo terminology conflict :P
<LaserJock> sorry, was perhaps not clear
<LaserJock> oh, right, too much overloading
<LaserJock> ;-)
<lifeless> I'm not sure
<lifeless> jam: ?
<lifeless> probably a on uploaded bzrtools and bzr-svn or something
<jam> lifeless: I believe Martin failed to build the extras like bzr-svn and bzrtools when he built the bzr-1.11 package
<LaserJock> I know often bzr will get updated and it takes a while to get bzrtools/bzr-svn updated
<jelmer> I uploaded bzr-svn a couple of days ago
<jelmer> I mean yesterday
<LaserJock> yeah, it looks like right now it's blocking on bzrtools
<thumper> something in the last few days of bzr updates has made it impossible over the smart server
<thumper> especially to launchpad
<thumper> I'm not sure what it is
<thumper> but it was taking over an hour (I killed it) to pull udpates
<thumper> when there wouldn't have been much
<thumper> is this just me or are others effected?
<spiv> thumper: it's news to me, at least.  What's the -Dhpss trace look like?
<fullermd> Casual use in the last few days didn't show anything up to me.
<asabil> lifeless: did you see my message ?
<lifeless> asabil: oh thanks
<lifeless> asabil: did you see my updated test?
<asabil> no, I got disconnected yesterday
<lifeless> http://paste.ubuntu.com/110628/plain/
<asabil> lifeless: 1171 bytes
<asabil> and branching over http works now
<thumper> spiv: I'm going to privmsg a pastebin as it has some sensitive stuff in it
<lifeless> asabil: 1171 is still short :(
<asabil> I guess one of their proxy wasn't working correctly
<asabil> heh
<asabil> oups sorry
<thumper> spiv: it may just be my freaking ISP
<thumper> spiv: I've been having some issues with disconnections on IRC
<thumper> spiv: however I did manage to stream a big bzr branch over http at almost 4meg/sec
<asabil> lifeless: 1448 + 1171
<asabil> sorry, didn't count the 1st chunk
<lifeless> asabil: ah cool
<lifeless> asabil: thats good
<asabil> :)
<asabil> thanks a lot for your help and patience
<lifeless> bzr is close to my heart :)
<asabil> hehe :)
<fullermd> The angioplasty of version control.
<thumper> spiv: I'm investigating my local network speed, it seems to be somewhat fuxored
<spiv> thumper: interesting; it got the start of a readv response, but didn't get the body of it
<asabil> if someone with some free time can help me with bzr-filter-branch I would be more than happy
<spiv> thumper: the largest .six file in that repo is < 3MB, so I doubt the server got bogged down with buffering it
<spiv> thumper: so yeah, I suspect network issues.
<asabil> the code is in lp:~asabil/+junk/bzr-filter-branch
<asabil> it rebuilds the history graph correctly, but the commits are empty
<asabil> no deltas
 * thumper doesn't really want to talk to stupid ISP help desk :(
<lifeless> asabil: so this is meant to be a git-filter-branch lookalike ?
<asabil> lifeless: yes
<asabil> but better
<asabil> :p
<asabil> since it's for bzr
<lifeless> so I'm curious why you are building fresh rather than reusing rebase
<asabil> it will probably be merged with rebase
<asabil> it is still experimental
<asabil> I talked to jelmer about it yesterday as well, for the merge with rebase
<asabil> (and maybe have some kind of bzr-history-manipulation plugin)
<asabil> I am still trying to dive into the bzrlib APIs
<mwhudson> is there a ui for "make this branch not stacked" yet?
<mwhudson> something on reconfigure?
 * mwhudson looks
<mwhudson> seems not
 * fullermd . o O (bzr topple?)
<mwhudson> snort
<mwhudson> anyway, the python command line is all the ui _i_ need :)
<lifeless> asabil: is it unit tested?
<asabil> lifeless: nop, not at all
<lifeless> k, well I probably won't look then :P - I know rebase's unit tests, and would be inclined to add this sort of thing there
<asabil> as I said, for now, it is a way for me to explore the bzrlib apis
<lifeless> ok, cool
<asabil> but I am a fervent lover of tdd, so don't worry
<asabil> I just need help understanding how history information is represented in bzr
<lifeless> there are various docs scattered around
<lifeless> most of the library talks about apis for history rather than actual representation
<lifeless> http://bazaar-vcs.org/Classes
<sohail> hi, I want to do some parallel development on version+1 with my bzr repo... how do I do it without creating a copy of everything?
<lifeless> sohail: do you mean you want two branches but only one working copy?
<sohail> lifeless, that would be ideal
<asabil> oh thanks lifeless
<lifeless> sohail: assuming you have a branch today, you just need to seperate out the branch and tree
<lifeless> sohail: so ...
<lifeless> cd $branch
<lifeless> bzr push ../b1
<lifeless> bzr push ../b2
<sohail> what what...
<lifeless> bzr bind ../b1
<sohail> I'm lost already
<lifeless> then hack hack hack, commits will be going to ../b1
<lifeless> when you want to switch, 'bzr switch b2'
<lifeless> and you'll be on the b2 branch, hack hack hack here, commits go to b2
<sohail> ok so I have (on another machine) /home/sohail/bzr/code/master
<sohail> I have done bzr clone $THAT_REPO here
<sohail> where does bzr push ../b1 come from?
<lifeless> well you need two branches
<lifeless> so if master is one of the branches
<lifeless> you still need to create a second
<lifeless> that is seperate from your working copy
<sohail> but my repo is gigantic
<lifeless> ok
<sohail> are you saying I need to create another copy (i.e., the second branch?)
<lifeless> if you have a huge repo we need to be a little bit more complex
<lifeless> is there a repository at /home/sohail/bzr/code on the other machien?
<sohail> I have a "main" repository at server:/home/sohail/bzr/code/master that I push to
<lifeless> thats a branch
<lifeless> did you setup a shared repository for that ?
<sohail> nope
<lifeless> ok, lets do that, its only a couple commands
<lifeless> can you ssh in there?
<sohail> yep
<lifeless> do so, and please psate the result of 'bzr info master'
<sohail> ok I'm there
<sohail> Location:
<sohail>   shared repository: /home/sohail/bzr
<sohail>   repository branch: master
<sohail> I guess it is shared...
<lifeless> ah - there is a shared repo :)
<lifeless> cool
<sohail> what does that mean anyway
<sohail> nm, I'm reading please continue
<lifeless> it means that the history store - the thing that gets big with all your commits :) - is shared across multiple branches
<lifeless> bzr branch master $NEWBRANCHNAME
<lifeless> this should be subsecond
<sohail> still going...
<lifeless> ok when it finishes
<lifeless> cd $NEWBRANCHNAME
<lifeless> bzr info
<sohail> still going hehe
<sohail> ok here comes the paste
<sohail> Repository tree (format: pack-0.92)
<sohail> Location:
<sohail>   shared repository: /home/sohail/bzr
<sohail>   repository branch: .
<sohail> Related branches:
<sohail>   parent branch: /home/sohail/bzr/code/master
<lifeless> bzr remove-tree .
<sohail> done
<lifeless> what happened here is that your repository is set to create working trees, but you don't need one here, you just want the branch data
<sohail> nice
<lifeless> so you should have an emptyish directory (only having .bzr)
<sohail> yep.. 44k
<lifeless> ok
<lifeless> now, back on your other machine
<lifeless> do you want to work disconnected ?
<sohail> not usually
<lifeless> ok
<lifeless> so the simplest thing then is just to go to your clone that you made
<lifeless> and run 'bzr bind $URL_OF_MASTER'
<sohail> done
<lifeless> now, when you do a commit, it will go immediately to master on the other machine
<sohail> ah
<sohail> sweet
 * sohail was getting tired of commit && push :-)
<lifeless> to change the target you can run 'bzr branch $NAME_OF_NEW_BRANCH'
<lifeless> sorry
<lifeless> s/branch/switch/
<sohail> ok so if $NEWBRANCHNAME was next, I do bzr switch next
<lifeless> e.g. 'bzr switch next'
<lifeless> yes
<lifeless> and you can switch back with 'bzr switch master'
<sohail> done
<sohail> sweet
<sohail> maybe I should rename that to be... current
<lifeless> you can give switch any url you want, but short names are looked up adjacent to the current target
<davidstrauss> Can I reorder threads in bzr loom?
<sohail> so how would I merge between them?
<lifeless> sohail: bzr switch master; bzr merge url_of_next; bzr commit -m 'merge next'
<sohail> thanks lifeless
<sohail> am I set?
<lifeless> yah
<lifeless> read up on this stuff if yo ulike
<sohail> you are a saint
<sohail> I tried
<sohail> is there a bzr book like the svn book
<sohail> oh one more thing, is it possible to see which commits would get merged? It would make a changelog easier
<lifeless> bzr st -v
<lifeless> after doing the merge before committing
<thumper> spiv: my network was slowed to dial-up, which may have been part of the problem
<sohail> great
<sohail> thanks lifeless
<spiv> thumper: ah :)
<lifeless> davidstrauss: there isn't really a ui for it today; it is effectively a cherrypick though - so
<lifeless> bzr create-thread new-lower
<lifeless> bzr merge -r thread:one_below_old_upper..thread:old_upper .
<lifeless> bzr commit -m "merge old -upper"
<lifeless> bzr switch old-upper
<lifeless> bzr remove-thread
<lifeless> (roughly that; do a record first, so you can revert-loom if you mess it up :)
<davidstrauss> lifeless: thanks!
<davidstrauss> lifeless: remove-thread?
<davidstrauss> lifeless: that command does not exist
<lifeless> combine-thread
<davidstrauss> lifeless: after reverting the changes, i assume
<lifeless> davidstrauss: uhm maybe :P
<lifeless> housekeeping wise what you want to achieve is
<lifeless> - merge the higher thread into a new lower one, and propogate this up through all the threads that didn't previously have the higher ones content
<lifeless> - tell the thread immediately above where the higher thread was that it still has the content of the moved thread
<lifeless> - remove the old higher thread as its now a meaningless placeholder
<davidstrauss> Is there a way to collaborate on looms?
<davidstrauss> Looms seem to not replicate over push
<lifeless> absolutely - bzr record; bzr push URL
<lifeless> the thing missing today is 'bzr merge LOOM' cause noone has gotten around to it :(
<lifeless> the data structure has space for it though
#bzr 2009-01-29
<davidstrauss> lifeless: record gives me an internal error
<davidstrauss> lifeless: I'm using the 1.11 package for OS X
<lifeless> davidstrauss: thats odd
<lifeless> does 'bzr selftest loom' pass?
<davidstrauss> lifeless: Also on very late code on CentOS 5
<davidstrauss> lifeless: i'll try
<davidstrauss> lifeless: All tests pass
<lifeless> file a bug please
<lifeless> jelmer: reviewed your patch - I don't think it works
<jelmer> lifeless, it seems to work fine here - or do you mean it's not lazy?
<lifeless> I don't think it achieves your goal
<lifeless> because formats are probed
<lifeless> it will be probed anytime a miss occurs on a .bzr dir
<lifeless> I think that bzr-svn has to provide a lazier format object
<lifeless> jelmer: do I make sense?
<jelmer> lifeless: yeah, I see your point
<jelmer> lifeless, The probe functions are pretty lightweight already though
<sohail> lifeless, in the instructions you gave me for branching, do I always have to log on to the server to create a branch in that manner?
<lifeless> then what would be gained by this?
<lifeless> sohail: not at all, I wanted ot check the repo because of your size concerns
<lifeless> sohail: just 'bzr branch url_to_master url_to_new_branch'
<sohail> ah
<sohail> and then remove-tree?
<lifeless> won't be needed remotely
<sohail> cool
<sohail> thanks
<lifeless> np
<lifeless> jelmer: so, you said in your mail that this would let us not load all of subversion
<lifeless> jelmer: do your probe functions check that svn is _possible_ before loading svn?
<lifeless> e.g. t.has('.svn')
<jelmer> lifeless, hmm
<lifeless> irrelevant for http
<lifeless> but for local..
<jelmer> lifeless, yeah, my patch just saves an imports in some cases
<jelmer> lifeless, they actually check for isinstance(transport, LocalTransport) and transport.has(".svn")
<lifeless> jelmer: and the import that is saved, is it of svn itself, or bzrsvn ?
<jelmer> lifeless: bzr-svn/subvertpy
<lifeless> so you could move the probe pre-checks into __init__, avoiding that import always except when it may really be a svn tree
<jelmer> not sure I follow
<jelmer> what do you mean by pre-checks?
<jelmer> ah, sorry
<jelmer> the import that is saved is just the import of the file that the BzrDirFormat derivatives are in
<lifeless> I've bb:rejected based on this conversation
<lifeless> I think that if bzr-svn is importing to much still, the change at this point needs to be in bzr-svn
<lifeless> or
<lifeless> the change to the format code would need to be rather different
<jelmer> hmmok
<davidstrauss> lifeless: https://bugs.launchpad.net/bzr-loom/+bug/322557
<ubottu> Launchpad bug 322557 in bzr-loom "Missing revision error on pushed loom" [Undecided,New]
<davidstrauss> lifeless: enjoy :-)
<lifeless> jelmer: basically the probe code has to be assumed to be executed; the bzr-svn probe is 'is it local, and is there a .svn, and does svn recognise it'
<lifeless> jelmer: the first two checks do not need to import subvertpy or anything; only the last check does
<jelmer> lifeless, Yeah, I see your point, I'm still just wondering whether the change isn't worth it
<lifeless> I think the change adds complexity without gaining anything in general
<lifeless> and its misleading to people because it will claim to be lazier than it really is
<lifeless> davidstrauss: looking
<jelmer> lifeless, it seems like my real beef is with bzr-hg anyway
<jelmer> as 75% of the time of running "bzr ls" is in mercurial
<lifeless> ouch!
<lifeless> well, all-in-__init__ is maybe not such a good idea :P
<lifeless> otoh is it import time
<lifeless> or something else
<jelmer> readconfig() is apparently 62%
<jelmer> from mercurial.ui
<lifeless> whee
<jelmer> lifeless, other than that, I now seem to have a bzr-svn that loads just __init__ and format
<lifeless> jelmer: excellent
<jelmer> lifeless, is there any reason we're *disabling* mercurial's demandload thingie?
<lifeless> jelmer: yeah, it broke
<lifeless> jelmer: there is a bzr-git thread on the list
<lifeless> from Timmie
<lifeless> spiv: bug 322299 smells like server autopack to me
<ubottu> Launchpad bug 322299 in bzr "bzr starts raising error on all actions after usin repo for a while: # ValueError: invalid literal for int() with base 10: 'None'" [High,Confirmed] https://launchpad.net/bugs/322299
<spiv> lifeless: yeah, it does seem like server-side autopack is failing, but the root cause still isn't obvious
<davidstrauss> Is it possible to pull a set of branches at once?
<lifeless> multipull I think
 * jelmer pulls bzr-foreign into yet another bzr plugin
<thumper> jelmer: what's the bzr-svn command to push back to svn?
<jelmer> thumper, pushing into an existing branch: "bzr push"
<jelmer> thumper, to a new branch: "bzr svn-push"
<thumper> hmm..
<thumper> jelmer: docs say that http is supported for svn writes using webdav
<jelmer> thumper, yep
<thumper> jelmer: does bzr-svn support https webdav writes?
<jelmer> thumper, yep
<thumper> ok
<thumper> I'm trying to help someone on #nzpug
<thumper> jelmer: could I get you to pop in perhaps?
<jelmer> sure
<spiv> igc: I just got hit by the same unrelated test failure on PQM (LockableFiles.__del__ in blackbox.test_shelve) as you.
<jelmer> spiv, fwiw, I've seen that issue as well
<jfroy|work> I have an existential question.
<spiv> jfroy|work: There is no spoon.
<jfroy|work> Why does bzr encode ~ as %7E?
<jfroy|work> That is all.
<spiv> jfroy|work: hmm, probably because urllib.quote does.
 * jfroy|work wants prettier URLs.
<jfroy|work> Time to write a patch.
<spiv> jfroy|work: although bzrlib.urlutils explicitly tries to declare that ~ isn't to be escaped I guess there are some places that don't go through those code paths.
<spiv> Hmm, actually, bzrlib.urlutils.escape will do that too, it doesn't take the _url_dont_escape_characters/_url_safe_characters sets into account.
<spiv> It basically just relies on urllib.quote.
<spiv> So I guess that's why.
<spiv> igc, jelmer: I guess it's to do with the UserWarnings that I get from blackbox.test_shelve when I run the tests on my laptop
<spiv> ("was gc'd while locked" warnings from test_shelf_order, test_shelve_no_message, test_shelve_one)
<jfroy|work> spiv: I didn't expect you to dig that deep. Thanks for the info.
<spiv> jfroy|work: not a problem
<thumper> jelmer: thanks for your help
<jelmer> thumper, np
<spiv> igc, jelmer: I think I've figured out the cause of the intermittent pqm failure, patch sent.
<igc> hi all
<spiv> igc: I sent a patch that should fix that odd PQM failure.
<spiv> igc: it happened to me too :)
<igc> spiv: awesome. just approved the patch btw
<spiv> Yay :)
<sohail> lifeless, there?
<lifeless> apparently
<sohail> cool!
<sohail> more branching questions
<lifeless> shoot
<sohail> so now I am on another machine and did bzr switch next
<sohail> but I don't seem to have the latest changes...
<lifeless> is the commit you want listed in 'bzr log' ?
<sohail> yeah
<sohail> ok... sorry for pinging you, pebkac
<sohail> bug in the code
<sohail> hee hee
<spiv> Hooray for easy questions :)
<sohail> :-)
<lifeless> sohail: np
<Peng_> jelmer: Do you still support running bzr-svn 0.4 with bzr.dev? If so, could you fix the SPEC_TYPES warning? (I think I'll switch to 0.5 anyway though.)
<vila> hi all
<lifeless> yo
<vila> igc: did you see my ping about usertest ?
<vila> spiv: Yeah for your fix regarding test_shelve, got bitten by it yesterday too
<spiv> vila: that makes lots of us, then :)
<vila> I re-submitted immediately in anger and it went through :-)
<vila> So I knew it was transient but I had no time to go further...
<igc> vila: I missed that ping sorry
<vila> igc: ping, I have bzrlib.plugins.usertest.tests.test_blackbox.BlackboxTests.test_usertest_strict failing since a couple of days/weeks and no idea on how to fix it (the test is 3 lines long but the failure output is 800 lines long giving me little hints :-/)
<vila> igc: no problem, I have an history at my fingertips :)
<igc> vila: I'll take a look soon
<vila> igc: thanks in advance :)
<igc> vila: thanks for the reviews btw
<vila> np
<vila> Since jam gave a tweak for faster log, I didn't review, but I agree with him globally
<vila> igc: Especially the part where he said: "it seems like it would make sense to create a class
<vila> definition, and turn them into 'self.XXX'." mwhahahahaha
<vila> :)
<Peng_> 2899 KB to download the latest ~25-30 revisions of bzr.dev. I wonder how much bandwidth btrees would save overall?
 * igc dinner
<Lo-lan-do> Um, why does bzr viz on a bound branch try to contact the server?
<Lo-lan-do> Shouldn't it only use the local history?
<luks> probably to check what's the latest revision of the branch
<spiv> Lo-lan-do: someone else reported that bug recently, I think
<spiv> It might also be something silly like looking up the branch nick.
<bialix> LarstiQ: I was over optimistic yesterday. Morning is smarter than evening. I'd prefer to implement subprojects for scmproj on top of new format and new layout. That said subpprojects will be there in a couple of weeks. Sorry. I hope you can play with scmproj without subprojects some time.
<fullermd> That's why I do all my work in the evenings; things are so much easier and get done faster  ;)
<bialix> hehe
<bialix> you never sleep, do you?
<fullermd> Sleep is for wimps.
<fullermd> Happy, healthy, well-rested wimps, but wimps nonetheless!
<bialix> :-D
<beniwtv> hi.. is bzr:// read-only? It complains it can't commit because of that :(
<bialix> bzr server --allow-writes
<fullermd> But it's ususally used pure read-only since there's no access control on it above the IP layer.
<beniwtv> fullermd: Access control doesn't matter really, it's just a small office server, and you can only access it from the office
<fullermd> Well, strictly speaking, it DOES matter; you've just got it taken care of   :)
<beniwtv> bialix: Works, thanks :)
<ollie> hello I have done a bzr push to a remote server. the  ssh'd in and done bzr st and get bzr: ERROR: No WorkingTree exists for
<ollie> how do i turn this into a working tree
<luks> bzr checkout .
<ollie> i have done this before but can't remeber what i did
<ollie> luks: perfect thanks
<ollie> if i now do some changes on the server e.g. the config file then do a bzr push later from my laptop will my server changes be overwritten?
<luks> no, the working tree won't be overwritten at all
<luks> and bzr push will complain that it can't update the remote working tree
<ollie> ok so then i could do bzr up right from the server
<ollie> ah ic
<ollie> so bzr push is really only for a one off
<ollie> whats the best way to deploy to a live server then?
<luks> bzr push is for pushing bzr data
<luks> you can use the bzr-push-and-update plugin if you are using bzr+ssh and you want to automatically update the checkout
<luks> and there is a bzr-upload plugin to just upload the actual files, not bzr data
<ollie> yeah i remember seeing that before
<ollie> i have the situation where i have a dev server and then a live server where clients add files via a cms.
<ollie> developers work on dev clients works on live via cms
<ollie> but i need to take developers changes to live
<ollie> at the moment i have dev and live as checkouts of a repository but i am sure this is not the best way to do it
<ollie> i can't find all that much info about web dev workflow using bzr via google
<ollie> which is odd
<santagada_web> ollie: there is some info on bazaar wiki
<santagada_web> ollie: I think that your production server should be deployed with bzr-upload...
<ollie> is there away to get rid of bzr push info e.g. bzr info shows related branches
<ollie> which i no longer want
<Lo-lan-do> I didn't find a proper way to do that, you'll need to edit the .bzr/branch/branch.conf file and remove the lines.
<awilkins> Hey, anyone else notice that bzr ls --unknown is listing paths to STDERR or is that just me?
<phinze> i heard that loggerhead has no way of displaying information about tags... is this true?
<phinze> whoa; just realized that if i have a branch diverge while i'm running tests, and i'm forced to merge the commits that slipped in with myself (therefore making them subrevisions of my commit) that when I push I can actually *reduce* the overall branch revno
<AmanicA> phinze: in the version of loggerhead I run, I don't see tags
<bialix> phinze: you would be interested in using append-only branches
<Lo-lan-do> phinze: Yeah, non-linear history can lead to interesting results :-)
<Lo-lan-do> (And you don't want to trust the revno anyway)
<bialix> grrr, why launchpad still cannot upgrade hosted branches?
<bialix> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<bialix> :-/
<bialix> I should use sftp URL?
<AmanicA> phinze: it seems tag support is still under development: https://bugs.launchpad.net/loggerhead/+bug/246739
<ubottu> Launchpad bug 246739 in loggerhead "tags are not available" [Wishlist,Confirmed]
<Peng_> bialix: sftp should work. bzr+ssh might with a new enough bzr?
<bialix> sftp does not work either
<bialix> I'm running official bzr.exe 1.11
<bialix> rats rats rats
<Peng_> Ah. Sorry, then.
<Lo-lan-do> Did you specify a format explicitly?
<bialix> no
<AmanicA> hi bialix, don't you ever work/sleep :)
<bialix> bzr upgrade sftp://bialix@bazaar.launchpad.net/~bialix/bzr-x-bit/trunk
<Lo-lan-do> I suggest you give it a try :-)
<bialix> you know something?
<Lo-lan-do> bzr upgrade --format=1.9-rich-root sftp://qjsdfq
<Lo-lan-do> I know nothing, but I suspect that upgrade without an explicit format might try to upgrade to the most recent *default* format, and the newer ones haven't been made the default yet.
<bialix> yep, my bad
<bialix> this branch is already upgraded
<bialix> but my local branch was not
<bialix> hence my confusion
<bialix> but error message is confusing
<bialix> why it told me about meta-directory?
<bialix> AmanicA: hi
<bialix> AmanicA: here 17:01
<AmanicA> hi
<AmanicA> here too
<bialix> why I should sleep?
<AmanicA> because you didn't last night?
<bialix> :-) no, I fall asleep after conversation with LarstiQ
<AmanicA> :D
<bialix> !summon LarstiQ
<ubottu> Sorry, I don't know anything about summon LarstiQ
<bialix> :-P
<AmanicA> and I hear he also fell asleap after that conversation
<bialix> hehe
<bialix> scmproj is better soporific ever
<AmanicA> sweet
<bialix> what you think about my latest subproj idea?
<AmanicA> sounds good
<bialix> ok
<AmanicA> I'm glad I could convince you :)
<AmanicA> an I didn't even have to build a prototype
<AmanicA> I'll really try to get some of those lp-bugs ticked off soon
<AmanicA> (to get then new format out sooner)
<bialix> I'm working on new format today, have some free time
<bialix> the main problem is rewriting of docs
<AmanicA> great thanks
<sewmyheadon1> Hi Folks, anyone here use bzr with Dropbox?
<sewmyheadon1> Or, can you think of any reason why bzr wouldn't work with Dropbox?
<santagada_web> sewmyheadon1: you plan to use it for yourself or to share the data with other people?
<sewmyheadon1> santagada_web: Myself, basically. I access my Dropbox from both a desktop and laptop and wonder if I'm using bzr on both, could I have my branch/repo setup in Dropbox?
<rockstar> Can someone please get the bzrtools package for 1.11 into the PPA?
<santagada_web> sewmyheadon1: I can't think of anything that might go wrong, if you are not in the middle of a commit while dropbox is copying stuff
<santagada_web> I don't know how bzr does locking during commits
<santagada_web> but I would guess dropbox would not copy them correctly
<sewmyheadon1> Thanks santagada!  I think we'll give it a spin and see if/how it works.
<santagada_web> sewmyheadon1: dropbox copying is manual right?
<santagada_web> sewmyheadon1: it doesn't start the backup automatically right?
<sewmyheadon1> santagada_web: It's strange.  Dropbox creates a folder in your home dir and, when you copy files into it, it uses WebDAV (I think) to copy these files into 'the cloud,' which is the storage they use on Amazon servers.  When you use another machine that's connected to the same DBox account, Dropbox checks periodically to make sure your files on the new machine are up to date, and will copy down any changes automatically.
<sewmyheadon1> So you could use Dropbox on twenty machines all connected to your Dropbox account and each machine will poll your local and remote Dropbox folders periodically looking for changes and auto sync.  Make sense?
<sewmyheadon1> You end up with local files on each machine connected to Dropbox.
<kfogel> hunh.  Can't install bzr in home dir, using exactly the instructions in INSTALL:
<kfogel> http://paste.lisp.org/display/74497
<kfogel> And this grep finds no results in the tree:
<kfogel> find . -type f -print | xargs grep "must supply either"
<bialix> kfogel: "must supply" error from python distutils lib
<kfogel> bialix: thanks
<bialix> kfogel: though I don't have enough experience with linux home install
<bialix> try to read: python setup.py install --help
<kfogel> bialix: exactly what I'm doing now :-)
<bialix> khm
 * bialix shuts up
<kfogel> bialix: what does "khm" stand for?
<bialix> *cough*
<bialix> never mind
<kfogel> bialix: ?? :-)
<kfogel> bialix: if it's offensive, I won't take offense.  I just like to keep my acronym collection up to date.
<bialix> my native language is russian
<bialix> sorry
<bialix> I don't want to say something bad
<kfogel> bialix: heh.  Okay.  Well, thanks for the clue about distutils lib.
<bialix> it was translations from russian
<kfogel> bialix: now you've made me *really* curious
<bialix> I guess in English you using only hmm
<kfogel> aaaah
<kfogel> yes
<bialix> "hmm"
<kfogel> variable number of "m"s
<kfogel> hmmmmmmmmmmmmmmmmm
<kfogel> hmmmmmmmmm
<bialix> khm it's hmm + cough
<kfogel> hmmm
<kfogel> got it
<bialix> when you don't want to say something
<kfogel> slightly more sarcastic, maybe, than "hmm"?
<bialix> it depends on context I guess
<bialix> in this case it was harmless, my hint about --help was too late
<bialix> sorry
<kfogel> oh, nothing to apologize for
<kfogel> My debugging is not going very well.
<kfogel> Argh, why is it that every time one tries to do X, one must first debug three prerequisites of X?
<kfogel> (I'm just whining, you can ignore that.)
<santagada_web> kfogel: yak shaving
<kfogel> santagada_web: sigh, yeah
<kfogel> So does 'python setup.py install --home ~' work for you?
<james_w> kfogel: it might be that bzr's use of distutils breaks --home
<james_w> you could perhaps use --prefix instead, but I imagine that leaves a less desirable structure
<vila> kfogel: I think I use $HOME instead of ~ (but never tried for bzr though....)
<vila> I used --prefix $HOME too
<kfogel> james_w: --prefix errored too, though in a different way
<james_w> oh
<kfogel> vila: I tried with "/home/kfogel" already, which is what $HOME and ~ both expand to
<bialix> kfogel: just to be sure, what say: `python -V`
<kfogel> bialix: Python 2.5.2
<bialix> good
<bialix> IIRC bzr's C-extensions required explicit options
<kfogel> vila: in theory, it should *never* make a difference whether you say ~ or $HOME or /home/yourdir -- the program can't tell the difference, since the shell expands it.
<bialix> something like python setup.py build_ext ... install ...
<bialix> I guess jam can say more
<bialix> jam: ping
<vila> kfogel: I agree with the principle :) I was trying a cheap shot... just in case
<kfogel> vila: heh
<bialix> kfogel: why you need to *install* bzr?
<kfogel> vila: let me put it this way: if that made a difference, I'd have something much, much larger to debug.
<vila> kfogel: just for perspective, why do you want to install in your $HOME ?
<kfogel> bialix: so I can use it from anywhere
<kfogel> vila: because it's a shared system and we'd prefer not to install dev code system-wide
<bialix> you can just make symlink for bzr script
<kfogel> bialix: I think I'm about to back down to that.  But will it load the right libs?
<vila> kfogel: I was just about to say the same than bialix :)
<vila> kfogel: it should
<bialix> "the same than bialix" -- English is hard language
<kfogel> I.e., if /home/kfogel/bin/bzr is a symlink -> /home/kfogel/src/bzr/bzr.dev-trunk/bzr, when I run it will it load the right libs from the latter dir, instead of from the system dir (which will be bzr 1.11)?
<vila> I have 4 or 5 such symlinks in my ~/bin
<vila> bialix: I wanted to recommend symlink, just like you :)
<vila> kfogel: yes
<bialix> vila: yes, I understand
<kfogel> vila: it seems to yes (once I did 'hash -r')
<kfogel> I guess I'll just do that.
<vila> hash.... I hate it
<bialix> kfogel: what say: python -c "import sys; print sys.path"
<kfogel> http://paste.lisp.org/display/74499
<kfogel> bialix: ^^
<bialix> first entry '' -- IIRC it means current script dir
 * bialix mutters: kfogel can try to install bzr at home with easy_install
<kfogel> bialix: oh, I've got a working solution now, so I've timed out :-(.  This was all on the way to doing another more important thing.
<kfogel> It's a pity bzr's homedir install recipe is (apparently) broken, but if I stop to fix that, then something else doesn't get done.  You know how it is.
<bialix> it's ok
<fullermd> kfogel: Err?  Shells don't always expand ~.  Only when it's at the start of a word.
<fullermd> % echo --prefix=~/foo
<fullermd> --prefix=~/foo
<kfogel> fullermd: yes, but barring that
<kfogel> fullermd: there are ways to suppress ~ and $ expansion.  But assuming they *are* expanded, the program cannot tell.
<maxb_> kfogel: oh dear, have I coaxed you into venturing into problematic territory?
<kfogel> maxb_: heh!  Hi there.
<kfogel> Yes, but you were still right.
<kfogel> (didn't know you hung out here, maxb_)
<maxb_> Only recently. Ubuntu's incredibly keen on bzr, I figured I'd see what all the fuss was about :-)
<kfogel> maxb_: it's good.  I'm not an expert yet, but starting to grok it.
<jelmer> rockstar, nice work on the graphstats command :)
<rockstar> jelmer, Thanks! http://media.theironlion.net/etc/graphstats-bzr.dev.png
<bialix> AmanicA: finished rewrite of the project.cfg doc
<rockstar> That's bzr.dev  It's a godo demonstration of the obvious shortcomings of the prototype.
<jelmer> rockstar, It would be nice if it could not print labels for people who have contributed less than 0.5 % or something
<rockstar> jelmer, yea, I plan on doing something like that.
<jelmer> rockstar, since I get a lot of text that overlaps for some projects
<bialix> AmanicA: format-change branch revno.180. If you will want to look
<james_w> that pqm chap looks pretty useful prolific
<rockstar> jelmer, I think what I'd like to do is create a new project and use the same concepts from bzr-stats, but implement them differently.
<rockstar> james_w, :)
<jelmer> rockstar: I don't think this would be bad to have in bzr-stats actually
<rockstar> jelmer, I'm more interested in an API for generating statistics and less of a plugin.
<rockstar> I assume I'd make some sort of plugin ui for it, but that's not something I much care about.
<rockstar> jelmer, so unless you (and jam) aren't opposed to be going to town on bzr-stats itself, it might be better to start a new project.
<rockstar> s/be/me
<jelmer> rockstar: I'm certainly not opposed to that
<rockstar> jelmer, I also noticed that the API needs some updating.  It's got a lot of code that broke in 1.6  :)
<rockstar> I guess it's a plugin that not many people use.
<jelmer> rockstar, which branch of the plugin are you using?
<jelmer> I'm not seeing any problems and I use it regularly with bzr.devc
<rockstar> jelmer, trunk.
<rockstar> jelmer, try `bzr ancestor-growth`
<jelmer> ah, yeah
<jelmer> that breaks here as well
<jelmer> the only commands I use are stats and credits
 * fullermd thinks he filed bugs around there...
<rockstar> jelmer, I have breakage on credits as well
<rockstar> jelmer, nevermind, I thought I did.
<fullermd> Oh, not on a-g.  Just on credits and committer-stats.
<jelmer> lp:bzr-stats is what I package for Debian/Ubuntu
<pdragon> i just did an update from launchpad to my local repository and it found a conflict in a binary file. Which of the files (BASE, OTHER, THIS) is the new file from launchpad and which is the original I had locally before?
<Lo-lan-do> I think OTHER is the one from the repo, THIS is yours, and BASE is probably their latest common ancestor.
<pdragon> ok. i was leaning towards OTHER as the new one since it has the largest file size. wasn't sure on the original though
<Lo-lan-do> But don't trust me, I try to avoid binaries and conflicts when I can.
<pdragon> yeah, i'm really not sure why there is a conflict
<fullermd> Very complex geopolitical forces were at work.
<dwt> jelmer: Hey, are you there?
<jelmer> dwt, yes
<dwt> Great. :)
<dwt> I am trying to check out a directory from my svn server at https://ipx11390.ipxserver.de/svn/mhaecker/open-source/nsNet/trunk/ with the newest version of bzr and bzr-svn (just branched from http://people.samba.org/bzr/jelmer/bzr-svn/stable/
<dwt> It works fine, but when I run bzr check afterwards in the checkout it dies with an exception
<Peng_> Oh, wow. I was just thinking about pinging jelmer too. :P
<dwt> :)
<dwt> Do you want to take a look at it directly or should I just file it as a bug?
<dwt> (It seems pretty reproducibly as I just created a new user, installed a new bzr and gave my repo a try after somebody complained to me that he was unable to work with the repo he had after pulling from my svn)
<dwt> Oh, and I did a checkout of this repo with an older version of bzr (1.09 I think) and that one works fine, so this looks like a regression
<jelmer> dwt, seems to work fine here
<jelmer> with bzr-svn 0.5
<dwt> I just branched from http://people.samba.org/bzr/jelmer/bzr-svn/stable/
<dwt> maybe that is the wrong location?
<jelmer> dwt, that's the 0.4 branch
<dwt> I see
<dwt> Let me check for the new url on the website, then I can retry with the new branch
<Peng_> dwt: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/ for 0.5 (and you need subvertpy)
<Peng_> dwt: http://people.samba.org/bzr/jelmer/subvertpy/trunk/
<jelmer> Peng_, what were you about to ping me about?
<dwt> Oh, that is no longer included?
<Peng_> jelmer: Well, for one thing, I was gonna file a bug about the svn-v4 revision IDs being used in tags on that svn-v3 branch.
<dwt> thanks Peng_
<Peng_> jelmer: Also, one one branch (lighttpd-1.4.x, as always), bzr-svn 0.4 gives the latest revision an svn-v3 ID, but 0.5 gives it an svn-v4 ID. Is that supposed to happen?
<jelmer> Peng_, yes
<Peng_> jelmer: ...Why? :P
<jelmer> Peng_, What would you suggest would happen?
<Peng_> jelmer: About what? The tags or the second thing?
<jelmer> Peng_, the second thing
<Peng_> jelmer: Well, I wouldn't expect it to create 1129 svn-v3 revisions and then one svn-v4, when past versions created all svn-v3.
<jelmer> Peng_, it created svn-v3 revisions because those were revisions pushed from bzr-svn
<Peng_> jelmer: So 0.5 will create svn-v4 IDs, except for revisions created by bzr-svn 0.4? And it just so happens that 99.9% of this branch falls under that?
<jelmer> Peng_: Yes
<Peng_> OK.
<jelmer> Peng_, revisions created by bzr-svn 0.5 and their ancestors
<jelmer> *0.4
<Peng_> Right.
<AmanicA> bialix: thanx, I'll look a little later (I was away a while)
<bialix> AmanicA: ok, it's already there
<bialix> I'm starting working on everything is optional part
<Peng_> jelmer: Well, I filed bug 322856. I hope it's coherent, and you don't mind. :P
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/322856/+text)
<Peng_> Nice, ubottu.
<dwt> jelmer: I have some trouble getting the bzr-svn 0.5 branch to work here... Maybe you could help?
<dwt> I installed subvertpy via easy_install
<dwt> (after I failed with the direct checkout and install)
<dwt> but it seems it is not recognized by the svn plugin
<jelmer> what doesn
<jelmer> t work
<jelmer> ?
<dwt> bzr selftest svn
<dwt> fails with this line
<dwt> cannot import name revspec_registry
<jelmer> dwt, you need bzr.dev
<dwt> which I am pretty sure belongs to subvertpy
<dwt> uh..
<dwt> ok
<dwt> Is there a version of bzr-svn 0.5 that I can use against bzr 1.11?
<dwt> It's no real problem for me to go to bzr.dev
<jelmer> dwt, not at the moment
<dwt> but my collegue is not very versed in shell. :/
<jelmer> I guess I could make that bit optional
<dwt> that would be super awesome. :)
<dwt> (I'm going to fetch something to eat, and will be back in about half an hour)
<Lo-lan-do> dwt: I use r2420, seems to work
<Lo-lan-do> (Last commit before 1.12 became mandatory :-)
<dwt> back
<dwt> Lo-lan-do: :) Well, that's an option
<jelmer> 1.11 should work again now as well
<dwt> Thanks a lot jelmer!
<dwt> is this http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<dwt> the right location to pull to get 1.11 compatibility?
<dwt> (because I only get "no revisions to pull." when I try to)
<jelmer> dwt, sorry, my link went down
<jelmer> pushing again now
<dwt> Thanks  a lot
<davidstrauss> Is there a way to clean up storage of revisions from deleted branches from shared storage?
<Lo-lan-do> Hmm.  I don't know if it's the lazy loading or whatever else, but I am now able to get bzr info results in 0.6 seconds.  Nice speed improvement :-)
<Lo-lan-do> And bzr status in 1.1 seconds in a large-ish tree.  Congrats!
<jelmer> Lo-lan-do: bzr-svn will also do complete lazy loading if you have bzr.dev
<Lo-lan-do> Not yet, but I'll be expecting 1.12 with great enthusiasm :-)
<Lo-lan-do> "using experimental bzr-svn mappings; may break existing branches in the most horrible ways"
<Lo-lan-do> Should I rollback to r2420?
<jelmer> Lo-lan-do, it should've always printed that
<Lo-lan-do> I never saw it.
<jelmer> Lo-lan-do, perhaps the new lazy importing fixes have just fixed the warning printing
<jelmer> but nothing has fundamentally changed
<Lo-lan-do> Okay.
<Peng_> Yeah, I don't think it's been printing the warning for a while now.
<Peng_> (And it is now.)
<orev_> hi, trying to get my head around the bzr concept.. if I make a bunch of changes in a branch, and commit each one along the way, then push those changes to a central server, will the central server see all of the commits individually, or does it only see the push as one commit?
<orev_> not sure if my terminology is right, I'm mostly familiar with svn
<jpds> orev_: The former.
<jpds> You can make as many commits as you like, it'll appear on the server exactly as 'bzr log' shows it.
<orev_> ah, cool.  so if I were to have a job that committed every hour, for example, then push to the central once a day, from the central I will be able to see commits from each hour?  just wanted to clarify with an example
<jelmer> orev_: Yep
<orev_> cool
<orev_> thanks
<LarstiQ> bialix: I'm home
<bialix> LarstiQ: good evening
<bialix> I wrote you in the morning, I can repeat if you don't have log
<bialix> in short: subprojects will wait some time
<LarstiQ> bialix: I'll check my backlog. Ok, I'll write out the components then.
<bialix> in the irclogs it's around 10:57
<bialix> sorry for inconvenience, but I think I should finish new format stuff first
<LarstiQ> that's ok
<bialix> so I don't to rewrite subprojects support twice
<LarstiQ> bialix: I have aline from you around 11:57 in my away log, was that it?
 * LarstiQ nods
<LarstiQ> bialix: that makes sense, and I can wait.
<LarstiQ> I just wasn't sure if they were supposed to work or not, before we talked yesterday.
<bialix> subprojects should help to make very big hierarchical projects
<bialix> LarstiQ: they planned, but not implemented yet
 * LarstiQ goes make some dinner
<bialix> bon appetite
<bialix> and perhaps bye
<jam> vila: ping
<jam> I want to chat quickly about your fix for bug #277537
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Fix released] https://launchpad.net/bugs/277537
<vila> jam: pong
<davidstrauss> This gives me an error: bzr branch bzr://vcs.fourkitchens.com/drupal/7-fic 7-fic-cvs-patch
<davidstrauss> bzr: ERROR: No such file: ('trigger.info-20081206090157-hohh42o0mhstvdpe-503', 'bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py')
<vadi2> Is there a way with bzr-gtk to browse the revisions of one file?
<jelmer> vadi2, not at the moment
<vadi2> alright
<luks> time to install qbzr :)
<luks> me hides
<vadi2> what is the command there?
<luks> bzr qlog path/to/file
<luks> or bzr qblame path/to/file
<lifeless> hi
<vadi2> luks: thanks for the tip, but it doesn't display the file at that revision, only the commit notes and affected files
<vadi2> but, I did find out what revisions was it changed at, so that helps.
<luks> oh, maybe I misunderstood the original question then
<vadi2> yes, I'd like to browse the file as the different snapshots
<luks> there is qbrowse for browsing the whole tree at any revision
<vadi2> yes, but I want a specific file only
<luks> and it can launch a window that shows the file in that revision
<davidstrauss> lifeless or jelmer: can you help me with the error I posted above?
<james_w> hi lifeless
<davidstrauss> It is making our Drupal developers not so happy.
<kfogel> whoa.  On my brand-new ubuntu box, 'cd bzr.dev-trunk; sudo python setup.py install' fails, ending in:
<kfogel> bzrlib/_patiencediff_c.c:1239: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âinit_patiencediff_câ
<kfogel>   Failed to build "bzrlib._patiencediff_c".
<kfogel>   Use --allow-python-fallback to use slower python implementations instead.
<kfogel> error: command 'gcc' failed with exit status 1
<kfogel> I can use the suggested flag, but... I wonder why it won't build on this box, yet builds fine on my debian box.
<ronny> jelmer: when will subvertpy hit the ubuntu pkg repos and can it use replay?
<jelmer> ronny, it can use replay
<jelmer> ronny, It's in Debian's NEW queue at the moment, I hope to get it into jaunty
<ronny> any chance to get it into intrepid?
<jelmer> ronny, intrepid is already out, it's hard to change now :-)
<jelmer> there is a PPA with the latest subvertpy though if you want to install it on intrepid
<ronny> ok
<ronny> jelmer: is there a win32 port somewhere around?
<jelmer> ronny, there isn't one published, but it should build on win32
<jelmer> it built on Windows when it was still part of bzr-svn
<ronny> im considering porting anyvc's svn support to it
<jelmer> cool
<mwhudson> vila: you still here?
<vila> mwhudson: yup
<jelmer> dwt, any luck?
<dwt> yes!
<dwt> It worked great
<jelmer> cool
<dwt> Now I need to convert my collegue to the current version and the trunk of the plugin
<dwt> and we should be able to run with it. :)
<jelmer> dwt, bzr-svn should work with bzr 1.11 again now fwiw
 * awilkins just changed the version requirements and it worked
<awilkins> jelmer: Who's built subvertpy on win32 so far?
<jelmer> awilkins, not sure if anybody has tried since I split it out of bzr-svn
<awilkins> jelmer: The win32/python installers still don't have the extensions built, I have to delete the svn plugin after it runs or my users will moan :-)
<LarstiQ> davidstrauss: does that happen for everyone branching it?
<davidstrauss> LarstiQ: yes
<davidstrauss> LarstiQ: Revision 521 introduced the corruption
<davidstrauss> LarstiQ: He's using the Windows client
<LarstiQ> davidstrauss: ok, it happens here too.
<LarstiQ> davidstrauss: it seems to happen in the working tree creation stage.
 * LarstiQ runs reconcile
<davidstrauss> LarstiQ: reconcile runs fine
<davidstrauss> LarstiQ: even on the server branch
<LarstiQ> davidstrauss: indeed. Next up, check.
<dwt> jelmer: Yes I was very happy to be able to upgrade to head again
<davidstrauss> LarstiQ: That fails.
<dwt> :) Thanks for that
<jelmer> awilkins: Is anybody aware those extensions aren't built?
<jelmer> dwt, you're welcome
<LarstiQ> davidstrauss: I'm not well versed enough in inventory to debug this.
<awilkins> jelmer: I would imagine that anyone who ever installs the win32/python build is aware, because it bugs you for every command regardless
<awilkins> jelmer: But in terms of build team, probably not.
<awilkins> jelmer: 'cause it's been like that since it started to be included in the win32 package
<davidstrauss> LarstiQ: Is there someone else who could look at it?
<awilkins> Maybe I'm the only person who uses the python build?
<awilkins> I like it because I can hack my live Bazaar, which is naughty but functional
 * awilkins sumbits a bug
<LarstiQ> davidstrauss: I agree lifeless would be a very good candidate. It's around his wakeup time now.
<LarstiQ> davidstrauss: there are some extra revision after 521, how did people manage that?
 * LarstiQ tries a lightweight checkout
<davidstrauss> LarstiQ: I'm going to move my repaired branch to 7-fic and move the broken one to 7-fic-broken
<LarstiQ> davidstrauss: repaired?
<davidstrauss> LarstiQ: I took a good branch, merged changes to 520 and patched in changes 521-525
<davidstrauss> LarstiQ: Merging anything 521 or later corrupted the branch
<LarstiQ> aha
<davidstrauss> LarstiQ: I've moved the branches now
<davidstrauss> The corrupted one is at bzr://vcs.fourkitchens.com/drupal/7-fic-broken
<lifeless> hi davidstrauss
<davidstrauss> lifeless: hi
<lifeless> davidstrauss: I have a little analyser I may get you to run
<davidstrauss> lifeless: great
<lifeless> but first, I need some food - will you be on in 15 ?
<davidstrauss> lifeless: yes
<lifeless> cool
<davidstrauss> lifeless: I PMed you with my email address so I can get the utility.
<jelmer> lifeless, when you're back
<jelmer> lifeless, any idea what fs encoding pqm has?
<lifeless> yes
<lifeless> C
<lifeless> I think
<lifeless> or utf8
<lifeless> it runs in cron
<jelmer> hmm
<jelmer> So I guess I can't test os.readlink() with non-ascii characters there then..
<lifeless> davidstrauss: http://paste.ubuntu.com/111461/plain/
<jelmer> (it's definitely not utf8)
<lifeless> change the path at the top appropriately
<jelmer> lifeless, thanks
<lifeless> jelmer: well the test should be guarded for windows etc too :P
<lifeless> jelmer: see other non-ascii tests
<davidstrauss> lifeless: do i run this from the branch root?
<lifeless> edit the 'ccan' string to the path to the branch
<davidstrauss> lifeless: ok
<davidstrauss> lifeless: I get ": No such file or directory", even after configuring ccan
<lifeless> can I see the full error please
<davidstrauss> [straussd@web3 ~]$ ./check_repo.sh
<davidstrauss> : No such file or directory
<davidstrauss> That is the full error
<lifeless> its a python script :P
<lifeless> try 'python check_repo.sh'
<davidstrauss> ah, ok
<davidstrauss> there we go
<davidstrauss> [straussd@web3 ~]$ python check_repo.sh
<davidstrauss> Checking 645 revs of 648
<davidstrauss> ghost revisions: set([])
<davidstrauss> missing texts(altered by) total: 3186 set([])
<davidstrauss> related file details for missing keys:
<davidstrauss> scanning for all references to missing keys
<davidstrauss> lifeless: that's it
<lifeless> it finished?
<davidstrauss> lifeless: yes
<lifeless> ok
<lifeless> and this was the problem branch ?
<davidstrauss> lifeless: yes
<davidstrauss> lifeless: would you like a tarball of the branch?
<lifeless> no thanks :)
<lifeless> does 'bzr check' pass in the branch?
<davidstrauss> lifeless: no
<davidstrauss> if (self.text_sha1 != tree._repository.texts.get_sha1s([key])[key]):
<davidstrauss> KeyError: ('trigger.info-20081206090157-hohh42o0mhstvdpe-503', 'bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py')
<davidstrauss> that's what i get from check
<lifeless> ok
<davidstrauss> you can download the branch from http://straussd.fourkitchens.com/7-fic-broken.tgz
<lifeless> what that discrepancy means is that there is a revision in the repository, *not* referenced from the branch, which for some reason does not have that file delta
<lifeless> what format is the branch?
<davidstrauss> lifeless: [straussd@web3 7-fic-repaired]$ bzr upgrade
<davidstrauss> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<lifeless> davidstrauss: 'bzr info'
<davidstrauss> Standalone branch (format: pack-0.92)
<lifeless> davidstrauss: in what way is it broken
<lifeless> [I know check fails, but what user operation fails/goes wrong]
<davidstrauss> lifeless: Try branching from bzr://vcs.fourkitchens.com/drupal/7-fic-broken
<lifeless> interesting, thats in tree building
<lifeless> I think I can tell you what has gone wrong in the past
<edgimar> If I branch a trunk repository, make some changes to it, and then pull new changes from the trunk (merging), then it looks like the new-changes get merged into my changes, and not the other way around (from the revision numbers in the log command).  Is that right?
<lifeless> edgimar: thats because you merged from the trunk
<lifeless> edgimar: so of course they should show as merged into your branch
<edgimar> How do I make it so that I am merging into the trunk, instead of the other way around?
<lifeless> hang on
<lifeless> you said trunk -> your branch
<lifeless> do you mean your branch -> trunk ?
<edgimar> I guess I mean that it's my branch of the trunk -- but..
<edgimar> I thought you could have multiple branches in the same directory with bzr.
<edgimar> Or not?
<davidstrauss> lifeless: ping me when you're ready to talk again
<edgimar> So, in principle, I could switch from one branch to another, which would just update the working-directory contents.
<lifeless> you can certainly have one working dir and use it to edit different branches, using the switch commands to switch between them, or using pull --overwrite to turn one branch into a mirror of any other
<davidstrauss> lifeless: I have to get back to Drupal.org upgrading stuff
<lifeless> davidstrauss: yeah sorry, back with you asap
<lifeless> edgimar: yes - 'bzr help switch'
<lifeless> edgimar: 'push' and 'pull' make mirrors
<lifeless> edgimar: so if you 'push' somewhere, it will end up an exact mirror of what you had in front of you
<edgimar> lifeless: ok, so let's say I have 'my branch', which shares the same history as the trunk up until rev. 100, where I have made a change.  I want to merge that change into the trunk, and push it to the trunk.  So, what are the logical steps I need to follow to do that?
<lifeless> edgimar: imagine that I own trunk
<lifeless> edgimar: I would 'bzr merge your_branch; bzr commit -m"merged edgimar"; bzr push <public_mirror>'
<ronny> anyone aware if bzr can run on ironpython/jython/pypy?
<dash> ronny: quite unlikely
<LarstiQ> ronny: jelmer though there was some ironpython going on with monodevelop iirc
<dash> ronny: very few python programs run unmodified on them.
<lifeless> edgimar: so, if you are owning trunk as well, you would do the same thing - cd $trunk, mege, commit, push-to-public
<lifeless> edgimar: the complication is you want to have only one working copy at a time; this is easy, and there are two ways to do it: I'll describe the fully manual way so you can see the bits, then the shortcut
<edgimar> lifeless: ok, but if I don't have 'the trunk' repo on my machine, does it make more sense to branch it into a new directory, or is there a nice way to use my existing branch and just create a new 'trunk' branch within that directory?
<dash> edgimar: bzr keeps each branch in a separate directory
<dash> but branches and working copies aren't the same, as lifeless appears to be about to explain :)
<lifeless> edgimar: so if you do push your current branch somewhere (could be in the same repo, or $wherever), you can do the following sequence, starting from 'I'm done and I want to get this in trunk'
<edgimar> lifeless: quite honestly, I say this because it is painful sometimes having to wait so long to branch something from launchpad, and if I can share the common history in my existing branch, it'd be fabulous...
<edgimar> lifeless: ok, go ahead with what you were planning to say.
<lifeless> edgimar: bzr push $my-branch; bzr pull --overwrite $trunk; bzr merge $my-branch; bzr commit -m 'merge my-branch'; bzr push $trunk
<edgimar> lifeless: ok, got it.  So, the trick is to first duplicate my branch locally, then overwrite it with the trunk.
<lifeless> right
<lifeless> now, like I say there is a shortcut
<lifeless> what it needs is that local duplicate to start with
<lifeless> (doesn't even have to be local)
<lifeless> so starting from the same point you are at today, with trunk on lp, and your local diverged copy
<lifeless> bzr push ../$my-branch
<lifeless> bzr bind $trunk
<lifeless> bzr update
<lifeless> (this will do a merge). resolve conflicts if needed
<lifeless> bzr commit -m "Merged my-branch"
<lifeless> then, to go back to your local copy, bzr switch ../$my-branch; bzr pull $trunk
<lifeless> this converts your current local branch into a 'checkout' which can act like cvs/svn with a master location changes are pushed to on commit, and knows about mainline commits etc
<edgimar> Why do you need to go back to your local copy in this case?  Can't you always just use bind?
<lifeless> sure
<lifeless> you can bind and unbind
<edgimar> ok, I'll look more into it for the details.   Thanks for the help.
<lifeless> np
<ronny> hmm, the reexecute setup wont work on jython - no os.execvp (bzr line 45)
<lifeless> davidstrauss: so
<davidstrauss> lifeless: back
<lifeless> davidstrauss: that revision isn't in your repository
<spiv> ronny: and it'd try to execute a non-jython python anyway...
<lifeless> davidstrauss: but there is a text compressed against one of the versions of it
<davidstrauss> lifeless: ok
<lifeless> do you have other branches?
<lifeless> ones you might have been editing on 2008/12/06
<lifeless> if we can find the branch with rev bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py
<lifeless> we can fix this trivially
<lifeless> you can use 'bzr cat-revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py' as a quick test for whether a branch has that revision in its repo
<lifeless> while you look I'm going to peek a little more deeply
<_Andrew> I've checked out a copy of my project and I have modified it for a completely new project, how do I make sure this different project is no associated with the old project?
<lifeless> _Andrew: what do you mean?
<_Andrew> Well I modified the old project for a new project however when I make a commit on this new project it's asking me for my password I use to upload to launchpad.
<lifeless> if you did 'bzr checkout FOO' then when you commit it will commit to 'FOO'
<lifeless> you should use 'bzr branch' if you want to make a new branch of something
<_Andrew> is there a command I and use to "branch" it now?
<_Andrew> I can use**
<lifeless> you can convert the checkout to a normal branch by running 'bzr unbind'
<_Andrew> ah thanks, that's what I am looking for. Is there a command to use which can check this information?
<lifeless> bzr info
<_Andrew> ok, it says stand alone tree, is this correct?
<lifeless> thats our default, yes
<_Andrew> ok, thanks a lot
<lifeless> np
<davidstrauss> lifeless: I get this from catting the rev: "bzr: ERROR: The repository file:///srv/bzr/repo/drupal/7-fic-broken/.bzr/repository/ contains no revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py."
<jelmer> abentley: Hi
<abentley> jelmer: hi
<jelmer> abentley: All my submissions to merge@code.launchpad.net seem to be causing trouble for launchpad
<jelmer> Am I doing something wrong?
<abentley> Do  you have an oops id?
<awilkins> davidstrauss: Suddenly missing repository?
<jelmer> abentley, e.g. OOPS-1125CEMAIL2
<davidstrauss> awilkins: pardon? it seems mostly just like some corruption
<awilkins> davidstrauss: Ok, I had a problem recently where the entire repository vanished - might have been a stray shell command but I never pinned it down
<abentley> jelmer: Do you have an older one?
<davidstrauss> awilkins: I have not encountered that issue.
<jelmer> abentley, yes, OOPS-1118CEMAIL9
<abentley> jelmer: It looks like your merge directives have no source branch.
<abentley> jelmer: LP currently can't use the bundle from a merge directive.
<abentley> So you should use --no-bundle.
<jelmer> abentley: Ah, ok
<jelmer> abentley: Thanks!
<abentley> jelmer: Fixing that is my current task.
#bzr 2009-01-30
<abentley> jelmer: You might want to look at https://dev.launchpad.net/Code/BzrSend
<thumper> abentley: some nicer errors might be nice :)
<lifeless> jelmer: ping
<lifeless> jelmer: did you see the thread asking for bzr-git help ?
<jelmer> abentley: ah, cool
<abentley> thumper: I suppose, but soon it will not be an error.
<lifeless> davidstrauss: in all your branches?
<thumper> abentley: :)
<jelmer> lifeless, hi
<jelmer> lifeless, no, I'll have a look now, thanksw
<davidstrauss> lifeless: I've only tried that in the problem branch.
<lifeless> davidstrauss: please try your other branches
<lifeless> the file in question - modules/trigger/trigger.info
<davidstrauss> lifeless: I can't pull that revision from any branch.
<davidstrauss> lifeless: i can access trigger.info from older branches
<lifeless> davidstrauss: you checked cat-revision for that rev in all your branches?
<lifeless> davidstrauss: did you have anything odd happen two days ago? all the references to the missing revision start on the 28th of jan
<lifeless> was it a loom branch
<lifeless> (I'm trying to track down the reason this happened)
<davidstrauss> lifeless: I didn't hear any reports of problems
<davidstrauss> lifeless: And "bzr check" runs fine on yesterday's branches
<lifeless> brb
<lifeless> back
<davidstrauss> lifeless: the branch works properly through rev 520
<lifeless> davidstrauss: yes, thats consistent with my analysis
<lifeless> davidstrauss: something cause bzr, in rev yched-20090128232212-lnh21io5dqaikdeo, to insert a reference to a text version that isn't in the branch, coming from a revision you don't appear to have
<lifeless> that commit was done by yched
<davidstrauss> lifeless: yes, and he uses a windows client over bzr+ssh
<davidstrauss> lifeless: i've emailed him to ask the specific version
<lifeless> spiv: ping
<lifeless> davidstrauss: also any plugins, and did he have *any* issues - confusing behaviour, a merge he cancelled, etc - at that time
<davidstrauss> lifeless: he has whatever is packaged with the windows bzr installer
<davidstrauss> lifeless: and he's using a checkout/update/commit workflow
<davidstrauss> lifeless: the server-side is running bzr 1.11
<davidstrauss> lifeless: on RHEL 5
<spiv> lifeless: pong
<lifeless> spiv: please read the discussion david and I have been having
<davidstrauss> lifeless: I haven't heard if Yves did or encountered anything unusual.
<lifeless> davidstrauss: regardless; there is a bug here, if it was commot we'd see this all the time, so its uncommon / corner case
<spiv> lifeless: Hmm.  Summary: missing revision, there's a text delta against that rev, the missing revision was created on windows over bzr+ssh?
<lifeless> its a pretty serious bug to introduce bad references like this
<lifeless> spiv: missing rev; the inventory in rev yched-20090128232212-lnh21io5dqaikdeo adds a reference to [1-or-more] texts added by the missing rev
<lifeless> rev yched-20090128232212-lnh21io5dqaikdeo was pushed to the server by the windows client over bzr+ssh
<davidstrauss> spiv: The branch is downloadable from http://straussd.fourkitchens.com/7-fic-broken.tgz
<lifeless> davidstrauss: let me know when he gets back to you
<lifeless> davidstrauss: I'll start looking at the code he's running at that point to see if I can find a potential cause
<davidstrauss> lifeless: Sounds like a plan. :-)
<spiv> lifeless: An interesting issue...  and the second one involving bzr+ssh & windows in the last week.
<lifeless> spiv: I smell a commit issue for the inventory data; but I also am concerned about the smart server letting this in
<spiv> Well, the smart server is still mostly acting like a VFS server as far as pack data goes.
<lifeless> isn't there a ref check now ?
<spiv> Hmm.  I think the client is still doing that, I'll refresh my memory.
<spiv> Yeah, the Packer on the client still does _check_references.  After that point the autopack occurs (and may be done via RPC), but the InterPackRepo code path leading to _check_references is the same for HPSS and non-HPSS.
<lifeless> spiv: so, somehow this passed the check
<lifeless> likely because the rev being added doesn't add the ref; but the mismathc between inv content and rev parents led to a skew
<lifeless> I'm really wondering if there is a third party commit code involved
<lifeless> something in bzr-gtk or qbzr perhaps
<spiv> That's an interesting thought!
<lifeless> because of course the core code is bugfree ;P
<spiv> :)
<lifeless> markh: what does gui commits on windows do
<markh> um - the qbzr plugin calls "bzr commit" as a subprocess, if that is what you are asking
<lifeless> ok, so we should have the command line in bzr.log
<davidstrauss> lifeless: He may be using TortoiseBzr
<markh> davidstrauss: Tortoise uses qbzr
<davidstrauss> lifeless: There's also a chance he's using the Eclipse extension
<lifeless> davidstrauss: we'll know soon enough :)
<davidstrauss> I'm mostly concerned that the smart server allowed this.
<lifeless> davidstrauss: so are we ;)
 * spiv goes back to working on a truly smart push...
<davidstrauss> lifeless: Yves is running Tortoise Bazar 0.1 / bzr 1.9
<lifeless> did he notice anything out of the orderinary?
<lifeless> can we get his bzr.log
<davidstrauss> lifeless: He didn't mention anything unusual.
<markh> ok, looking a little more, qbzr actually executes a sub-process with a command-line that looks like 'bzr qsubprocess commit ..." - the qsubprocess command still just does a "normal" checkout or whatever sub-command is issues, but qsubprocess allows for progress info to be sent back IIUC
<lifeless> davidstrauss: please ask him explicitly
<davidstrauss> lifeless: Where is bzr.log for Windows clients?
<markh> davidstrauss: in "my documents"
<lifeless> bzr --version lists the location
<davidstrauss> lifeless: I've asked him.
<lifeless> davidstrauss: thanks
<lifeless> I want to be clear - I don't think hes done anything wrong; this is a software issue we just need to fine the bug
<davidstrauss> lifeless: of course :-)
 * igc lunch & doctor appointment
<thumper> lifeless: I'm assuming this is known about: /home/tim/.bazaar/plugins/loom/revspec.py:64: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12.
<jelmer> thumper, yeah, John posted a patch to the list
<lifeless> and I approved it :P
<thumper> cool
<thumper> is it on trunk yet?
<_Andrew> I just made this diff on a file but I feel like it's not generated the patch correctly on one file because it's removed a ton of code I haven't edited and then added it back in. Should I report it as a bug?
<lifeless> _Andrew: you can if you like, but diff is actually really hard to get 'right' all the time: oftimes when we get a report like that we can track it down to the alternative being larger or less useful - but not always
<lifeless> _Andrew: you probably moved an anchor line from below to above the code that got shown as a delete+add
<lifeless> _Andrew: we do care about making diff as useful as possible
<_Andrew> You might be right..
<_Andrew> one second let me revert the change and add what I changed
<_Andrew> My fault..
<_Andrew> I ran one of the files through qt designer which changed it all
<_Andrew> Thanks for all the help.
<tjs> anyone know what a bad protocol version marker would be?
<tjs> bzr: ERROR: Received bad protocol version marker: '2428\nbzr message 3 (bzr 1.6)'
<spiv> A good protocol version marker would be "bzr message 3 (bzr 1.6)\n"
<spiv> This is over bzr+ssh?
<tjs> yes
<spiv> Can you reproduce with -Dhpss?  What version on the server?
<tjs> bzr -Dhpss ci -m "testing"
<tjs> bzr: ERROR: Received bad protocol version marker: '1772\nbzr message 3 (bzr 1.6)'
<tjs> 1.6.1 on both
<tjs> although the server was created at 1.3.1
<tjs> I tried doing a bzr upgrade on the server and it says its all up to date
<spiv> tjs: what does the log file (~/.bzr.log) show for the -Dhpss command?
<lifeless>   tjs you have noise from somewhere
<spiv> Interesting that it's so consistent (4 bytes each time)...
<spiv> Do you have any plugins on the server that would write to stdout?
<tjs> aah
<tjs> possibly o.O
<tjs> one sec
<spiv> Hmm, perhaps bzr serve should smash sys.stdout to discourage that...
<spiv> Er, bzr serve --inet, I mean.
<tjs> crisis averted
<tjs> *halo*
<tjs> thanks guys
<spiv> tjs: bzr+ssh doesn't care about stderr, so you can abuse that if you want ;)
<tjs> was just some debugging cruft, is there a way to use pdb in a hook script?
<spiv> You can do the usual "import pdb; pdb.set_trace()" trick.
<spiv> It won't work so well if it's running on the remote end, though...
<spiv> (Incidentally, hitting SIGQUIT, usually C-\, will drop you into the debugger too)
<Peng_> jelmer: Congrats on the release (candidate). :)
<sohail> lifeless, there?
<sohail> well anyone actually...
<sohail> I am trying to see what the changes are between two branches
<sohail> via merge /path/to/dev/branch
<sohail> this only merges the last checkin...
<spiv> bzr merge will merge all changes that aren't already in your branch.
<spiv> You could also do bzr diff -r -1..branch:/path/to/dev/branch
<spiv> But typically "bzr merge --preview /path/to/dev/branch" is what you want.
<sohail> spiv, but that's just it
<sohail> there are more changes that are not being merged
<sohail> for example, I made some changes to the 'website' directory in my 'next' branch, yet when I switch to master and merge from next... nothing
<spiv> What does "bzr missing /path/to/dev/branch" report?
<sohail> spiv, "You are missing 1 revision"
<sohail> I have no ide ahow
<sohail> I never merged
<vila> hi all
<sohail> spiv, I am looking at bzr log
<sohail> all the checkins are to branch nick: next
<sohail> yet some of the changes are actually in my master branch already
<sohail> wtf
<sohail> ah spiv I think I may have figured it out... I had the working copy bound to /path/to/master
<sohail> so I guess when I did bzr switch next, it was still submitting to master?
<sohail> weird
<spiv> sohail: bzr switch changes the branch that the working copy is bound to.
<sohail> spiv, then what's going on?
<spiv> No idea.
<sohail> this sucks...
<sohail> I need to do a release but wanted to work on some next version stuff!
<sohail> oh well... bed time :-(
<igc> have a good weekend all
<aquarius> I've inadvertently bzr rm'd an (empty) folder (called "tmp") in my branch. I did it a while ago, and I'd like to get it back. "bzr revert tmp" complains that tmp is not versioned (which it isn't, because I bzr rm'd it). How do i get it back? I could just bzr add it again, but that seems wrong...
<edgimar> If I did a 'bzr merge <otherbranch>' on a given branch, and now 'bzr st' shows 'pending merges', how do I "call off" the merge, and go back to how it was before I had typed 'bzr merge'?
<Lo-lan-do> edgimar: bzr revert
<edgimar> Lo-lan-do: I think I tried that -- are there special flags to add to it?
<Lo-lan-do> aquarius: bzr revert, too :-)
<Lo-lan-do> edgimar: Not as far as I know
<aquarius> Lo-lan-do: bzr revert will just remove everything changed since my last commit, won't it?
<aquarius> Lo-lan-do: and bzr revert tmp says that tmp isn't versioned
<Lo-lan-do> aquarius: Correct.  If you want to save some of these changes, you might try to shelve them, then revert the rest, then unshelve.
<edgimar> Ok, maybe the problem was that I specified something like '*' as an argument, and should have had no arguments.
<Lo-lan-do> edgimar: Possibly, yes.
<Peng_> By default, I think revert only removes pending merges when you don't specify any files. That's what the --forget-merges argument is for. :)
<aquarius> Lo-lan-do: aha, I removed it in r570. So, bzr merge -r 570..569 will reverse that merge, yes?
<Lo-lan-do> aquarius: Ah, if you've committed the removal, then yes, you'll need to do something like that.
<Lo-lan-do> revert only reverts uncommitted changes :-)
<aquarius> Lo-lan-do: yep :)
<aquarius> Lo-lan-do: OK, confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong?
<kiko-zzz> Lo-lan-do!
<kiko-zzz> good to see you here
<Lo-lan-do> aquarius: Not sure... it may be a different syntax.
<Lo-lan-do> kiko-zzz: Hi :-)
<Lo-lan-do> kiko-zzz: How are things?
<kiko-zzz> how's bzr working for you?
<kiko-zzz> I'm great. a bit sleepy
<kiko-zzz> busy this week with a plan for bzr :)
<Lo-lan-do> It's working great for me, and I'd love to have time to learn how to hack it in order to fix a few problems I still have.
<kiko-zzz> Lo-lan-do, hey, if you have some time free talk to me :)
<Lo-lan-do> Free time.  Haha.
<aquarius> I am very confused. bzr log -v -r 570 shows that all I did in that revision was remove tmp/. But bzr merge -r 570..569 changes a load of other files. What am I doing wrong?
<kiko-zzz> aquarius, interesting -- in what revision did those files change?
<aquarius> kiko-zzz: I don't know...
<aquarius> kiko-zzz: probably 571 (I did a merge from trunk then)
<kiko-zzz> aquarius, try changing the revisions in your merge command slightly and seeing if something makes sense
<aquarius> kiko-zzz: it doesn't seem to. (This is more complex because 571 was the merge from trunk, so loads of files that I have nothing to do with changed...but merge -r 570..569 does not seem to be everything from trunk.)
<edgimar> If I committed something before setting my username properly (with 'whoami'), can I go back and change the username of the commit?
<kiko-zzz> edgimar, bzr uncommit and commit
<edgimar> ok, so uncommit will leave the working directory in the state right before it was committed?
<kiko-zzz> and shelve if you don't want to lose that
<kiko-zzz> yes
<kiko-zzz> exactly
<kiko-zzz> aquarius, I can totally reproduce what you are saying
<kiko-zzz> aquarius, I'm not sure exactly why it happens, but I can tell you this
<edgimar> kiko-zzz: what if I committed more than one revision?
<kiko-zzz> edgimar, uncommit, shelve, uncommit, shelve, etc
<edgimar> ok. thanks.
<aquarius> kiko-zzz: aha! I have worked it out, because I was stupid. bzr merge -r 570..569 .
<aquarius> I was unmerging from trunk, not from myself. forgot the . on the end :)
<kiko-zzz> aquarius, heh, but tricky eh?
<kiko-zzz> might be worth filing a bug
<kiko-zzz> okay, time for some cycling
<kiko-zzz> before I go pumpkin :)
 * kiko-zzz waves and will bbl
<aquarius> kiko-zzz: I shall do, although it may be closed with EYOUARESTUPID :)
<kiko-zzz> aquarius, /msg me the bug number so I make sure it doesn't ;)
<edgimar> kiko-zzz: It seems that doing uncommit / commit requires you to re-enter your commit message and doesn't retain the original commit time -- is there a way to *only* change the username?
<kiko-zzz> edgimar, well, you're asking to rewrite history. there may be a history rewriting plugin but I don't know 100%
<kiko-zzz> need to run, ttyl
<Kinnison> edgimar: by uncommitting, you're asking bzr to forget about your commit. So it does indeed forget username, message, etc.
<Kinnison> edgimar: If you really want that behaviour, write yourself a script. It's not behaviour I'd imagine the bzr team wanting to promote
<etenil> Hello
<etenil> I have yet another problem with bzr on windows
<etenil> I can't locate where the configuration files are
<luks> bzr version
<etenil> Oh got it
<etenil> man, it's easier on GNU/Linux
<balor> During disconnected operation I committed code to a local branch "bzr ci --local".  If I "bzr update" will that propogate to the non-local branch it was checked out from?
<aquarius> james_w: arf :)
<james_w> aquarius: I couldn't resist
<balor> aquarius: Long time no see.  Happy birthday.
<james_w> ah, happy birthday aq
<james_w> balor: I'm not completely sure, but I believe it won't propagate at update time
<balor> james_w: hmmm.....
<aquarius> balor, james_w: cheers :)
<balor> aquarius: Which reminds me that I should go up north to spill another pint on you some time soon.
<bialix> etenil: `bzr qconfig` may help
<aquarius> balor: when you're around here, say the word :)
<spiv> balor: no, bzr update will turn the local commits into pending merges in your working copy.  When you do "bzr commit" they'll propagate to the master branch.
<balor> spiv: Will they commit with the commit messages I've previously given them?
<balor> spiv: i.e. the changelog entries
<Lo-lan-do> Nope, they'll commit as one revision merging all your local commits into one.
<balor> hmm....
<balor> Is there any way to get all my local commits to commit to the master branch?
<Lo-lan-do> Unless you rebase them on the updated tree, but I'm not sure how to do that (I believe it is possible though).
<Lo-lan-do> Yes, rebase :-)
<spiv> balor: all the commits will still be there, but not on the mainline.
<spiv> You could probably "bzr unbind" and then "bzr push" to push them as mainline commits, assuming the master hasn't diverged.
<balor> spiv: I think I may just push them up to a new location and use that as the new mainline
<Lo-lan-do> And if it has diverged, then unbind, rebase, push, bind.
<spiv> Lo-lan-do: er
<spiv> Lo-lan-do: well, I guess.  Or just merge the master back in and push.
<Lo-lan-do> (If you want the individual commits to still appear linearly)
<spiv> I personally wouldn't worry so much about which commits are mainline and which aren't.
<spiv> They're all still there, whether they're on the left-hand side of the graph isn't really a big deal generally.
<Lo-lan-do> spiv: I sometimes do, when mainline is stored on SVN.
<spiv> Ah.  Poor you :)
<Lo-lan-do> Yeah.
<etenil> I've got a silly windows problem to start olive
<etenil> I have made a shortcut to 'bzr olive', but it always shows the terminal windows to which the program is attached
<etenil> is there any way around?
<Kinnison> Is there a known issue with bzr-git right now?
<Kinnison> I branched it to take a look, but bzr whinges:
<Kinnison> __init__() takes exactly 2 arguments (1 given)
<Kinnison> which appears to be caused by the last line in mapping.py
<jelmer> Kinnison, you need bzr.dev
<jelmer> lol
<jelmer> Format <HgRepositoryFormat> for file:///home/jelmer/hg/dovecot/.hg/ is deprecated - please use 'bzr upgrade' to get better performance
 * jelmer fixes bzr-hg
<vila> jelmer: :-)
<Kinnison> jelmer: I just did pull in my bzr.dev
 * Kinnison boggles and tries again
<Kinnison> No revisions to pull
<vila> jelmer: regarding bug marked as fixed released for bzr-gtk, there seemed to be consensus on the ML, should we start to apply it now ?
<jelmer> Kinnison, oh, and I should be pushing to lp:bzr-git rather than my private bzr-git branch
<jelmer> Kinnison, sorry
<Kinnison> should I re-pull bzr-git ?
<jelmer> Kinnison, pushed, please repull bzr-git
<jelmer> yep
<jelmer> vila: yeah, I think so
<vila> ok, great
<Kinnison> What is dulwich and where do I get it?
<jelmer> Kinnison, it's a Python module that implements the git file formats/protocols
<jelmer> Kinnison, there's a PPA at launchpad.net/~dulwich
<jelmer> Kinnison, the performance sucks a bit at the moment, so I wouldn't try it on the Linux kernel but it should be fine for smaller projects
<bialix> jelmer: I'm interesting in bzr-git. I'll try to start test it on win32. Do you have any particular advices?
<jelmer> bialix: Ah, cool! I would be interested to hear about portability or other bugs you encounter
<bialix> I don't have any particular git project I want to track. Do you have any testing one or I need to create local repo?
<Kinnison> jelmer: amusingly I hadn't read that performance warning and wandered off to branch linux-2.6
<Kinnison> jelmer: It crashed
<santagada> the guys that where developing the bzr textmate bundle don't whant to continue to develop it. If I were to work on it do you guys think using the bzr api is a better idea or using the bzr client is ok?
<homy> Hi! I'm using ubuntu intrepid and the launchpad bzr ppa.
<santagada> how could I show progress bar is I use the bzr client?
<homy> Since some time, I can't update the bzr package: Update manager always prompts me to do a "partial update", as bzr can't be installed.
<santagada> homy: you are having problems with bzr-tools right
<homy> ?
<homy> santagada: how do I find out if that's the case?
<santagada> homy: I think noone updated it yet... the last 2 days people came here all the time complaining about it
<santagada> homy: you can search for bzr-tools on synaptic I think...
<bialix> bzrtools (without dash, IMO)
<santagada> bialix: thanks :)
<bialix> at least it's the official name
<homy> yes. The square is green. The square next to bzr is green but has a star
<vila> santagada: what bzr version are you using ? There is a new pb implementation under work in bzr.dev
<santagada> vila: pb?
<santagada> what is that
<vila> progress bar
<santagada> vila: I plan to develop the textmate bundle to work with the released bazaar... or when is 1.12 going to be released?
<vila> the rc should be out next friday or something
<santagada> homy: bzrtools is 1.10 right? and bzr can be updated to 1.11
<santagada> vila: so I should probably target it
<vila> santagada: what is textmate ?
<santagada> vila: one of the most used text editors for osx
<jelmer> bialix, a good one is e.g. etckeeper
<vila> santagada: I thought is was emacs, sorry about that :)
<homy> santagada: bzrtools: installed version = latest version = 1.10.-1~bazaar1~intrepid1 bzr: installed version 1.10-1~bazaar1~intrepid and latest version 1.11.1
<jelmer> bialix, bzr branch git://git.kitenet.net/etckeeper
<jelmer> Kinnison, whoa :-)
<bialix> jelmer: ok
<santagada> vila: I think the order is: textmate, bbedit, aquamacs, vim
<jelmer> Kinnison, Hopefully that should be fixed soon, there are just two places where we do things *really* inefficiently
<vila> santagada: so regarding pb, it depends a lot on how you interface between textmate and bzr
<santagada> vila: I was plaining to use the bzr client directly thru shell scripts
 * bialix hope etckeeper don't have versioned symlinks
<Kinnison> jelmer: http://rafb.net/p/881AAH60.html
<Kinnison> jelmer: if it's something you know, I'll wait. otherwise if you want, I can file a bug.
<homy> help?
<vila> How do you "program" (?) textmate ?
<jelmer> Kinnison, please file a bug
<santagada> homy: you have to wait
<vila> santagada: by the way, I thought Xcode was the most commonly used...
<santagada> homy: while bzrtools is not updated
<santagada> vila: xcode is not a text editor... well emacs isn't either :)
<santagada> vila: tm uses shell scripts mostly
<homy> Is there any particular reason for bzrtools not being up-to-date in the ubuntu ppa?
<Kinnison> jelmer: filed: #323190
 * bialix mutters bzr-git and dulwich could be married with scmproj
<santagada> homy: ppa I think is updated by people... and some people didn't update it
<jelmer> Kinnison, thanks
 * Kinnison goes back to git for now
 * Kinnison sobs
<santagada> homy: why he didn't I don't know... but doing debian packages is a hard process
<bialix> jelmer: what is the right way to run selftest fro dulwich
<bialix> ?
<bialix> s/fro/for/
<santagada> jelmer: the PPA packages are not automated or are they?
<jelmer> bialix, e.g. "trial dulwich"
<bialix> trial?
<jelmer> bialix, it's part of twisted
<bialix> oh, no
<speakman> hi folks, i'm having trobles using trac-bzr on freebsd. Is there a better channel for this issue?
<jelmer> bialix, I think there are other test runners as well, but don't know any others off the top of my head
<bialix> if there is nothing unusual in dulwich test suite I can port my own runner, if you dont mind
<bialix> speakman: I'm using trac-bzr, but on Windows
<jelmer> bialix, I'd rather keep it as generic as possible
<speakman> I get "AttributeError: 'int' object has no attribute 'isdigit'" when running latest trac-bzr (from trunk today) and Trac 0.11.2, bzr 1.11 (how do I check bzrlib version?)
<jelmer> speakman, please file a bug
<speakman> >>> bzrlib.version_info
<speakman> (1, 11, 0, 'final', 0)
<homy> ok, so I guess I'll just have to wait.
<bialix> jelmer: how test runner will make the dulwich test suite less general?
<bialix> or generic, whatever
<santagada> speakman: int has isdigit right?
<santagada> speakman: try it in python
<bialix> isdigit seems to be string method
<speakman> heh, didn't look that far. Strange! Python is 2.5 btw
<santagada> speakman: (1).isdigit() or int.isdigit()
<santagada> bialix: right again
<santagada> speakman: it is a function from string, bialix is right
<speakman> The line of the error is 213 in backend.py: "if rev.isdigit():"
<santagada> speakman: paste your full traceback somewhere
<jelmer> bialix: basically dulwich just uses the standard unittest python module that's included in python itself
<speakman> santagada: will do, w8
<jelmer> bialix, so any test runner that can use that should work
<bialix> jelmer: yes, I understand
<bialix> I have a simple test runner implementation so one can run `python setup.py test`
<santagada> speakman: I think you should open a ticket on the bzr bug tracker...
<jelmer> bialix, ah, ok
<jelmer> bialix, That's of course useful :-)
<speakman> http://pastebin.com/m609db24c
<bialix> jelmer: something wrong: ImportError: No module named dulwich.protocol
<speakman> santagada: bzr or bzr-trac ?
<santagada> speakman: good question
<santagada> speakman: I'm thinking it is a problem with the trac integration
<bialix> rats
<santagada> but let me look
<bialix> jelmer: I've put dulwich lib inside git plugin directory because I'm running bzr.exe
<santagada> speakman: it is a problem with tracbzr
<bialix> and this import does not work for me: from dulwich.protocol import Protocol, TCP_GIT_PORT, extract_capabilities
<santagada> speakman: what is it by the way? it is a plugin for versioncontrol for trac? where can I find its homepage?
<jelmer> bialix, Yeah, you'll probably need to have it in PYTHONPATH
<bialix> jelmer: oh, yes. we have similar trick in qbzr
<speakman> Changing repository_dir to point at parent dir killed the error..!
<santagada> speakman: maybe there is someone on #trac that could help you
<speakman> santagada: https://launchpad.net/trac-bzr
<bialix> jelmer: I'll send you a patch shortly
<santagada> jelmer: isn't you the author of trac-bzr?
<bialix> jelmer: in qbzr we put additional libs in the _lib directory. if I'll use the same approach for bzr-git -- it'll be ok for you?
<jelmer> bialix, as long as it doesn't modify sys.path
<bialix> it indeed modified sys.path
<bialix> but only if user run bzr.exe
<jelmer> hmm
<bialix> there is no way otherwise
<jelmer> bialix, Can you send me the patch? I'm not completely sure about this, but I'll have a look
<jrwren> trac-bzr looks cool! wish lp was free :)
<speakman> This seems to fixed it. I'll just keep it like that.
<bialix> jelmer: for bzr.exe sys.path points only to bundled libs in exe's library.zip
<jelmer> santagada, I seem to be the maintainer by default
<santagada> jelmer: good luck fixing speakman bug :). I might be abble to help
<bialix> jelmer: it will looks something like this: http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk/annotate/head%3A/lib/__init__.py (lines 23-25)
<santagada> I don't know anything about bzr but I do understand trac code
<jelmer> bialix, Ah, that looks reasonable
<nDuff> hmm -- I was just plugging Bundle Buggy in #qemu (as there's been talk on the mailing list on wanting a patch-tracking system), and Patchwork [http://ozlabs.org/~jk/projects/patchwork/] came up as an SCM-agnostic competitor; I didn't actually know there were other tools in the same space.
<jelmer> nDuff, I think bzr used patchwork for a while
<jelmer> nDuff, it doesn't track when things have been merged though, exactly because it's SCM agnostic
<jelmer> santagada: trac-bzr mainly needs a testsuite :-(
<gnomefreak> can someone tell me why im getting this error? http://pastebin.mozilla.org/612641
<santagada> jelmer: why not just reuse trac testsuite?
<jelmer> gnomefreak, you can't push to http locations
<jelmer> santagada, That doesn't setup bzr repositories, etc
<gnomefreak> i used the lp:
<gnomefreak> oops wriong link
<gnomefreak> thanks
<santagada> jelmer: adapting version_control/tests/svn_fs.py for bzr doesn't seem impossible...
<speakman> There's alot more bugs with trac-bzr. Nonworking URLs to files in specific revisions seems common. I might get back to help out fix some of it, but I'm currently in a hurry.
<speakman> Thanks alot for your time!
<jam> vila: ping
<vila> jam: pong, can we talk now or a bit later ? (I need to switch machine if we talk)
<santagada> speakman: this seems to be a problem with having evolving versions of trac and bzr and not having automated test cases... it probably works for some versions of bzr and trac :|
<bialix> jelmer: bzr selftest git fails very quickly: http://pastebin.com/m516466ff
<jelmer> bialix, can you be more specific ? :-)
<speakman> santagada: yes, probably. My other installations works pretty good.
<bialix> jelmer: that's all I get
<speakman> (another thing is the null: revision which keeps showing on top on Timeline.)
<jelmer> bialix, Any chance you can file a bug ? I'll have a look at it later
<bialix> it seems like bzr test suite crashed
<jelmer> santagada, that still means somebody has to put effort in, and I doubt it would be much quicker than writing a testsuite for bzr from scratch
<bialix> I don't have usual stack trace in the end
<santagada> speakman: file a bug on trac-bzr
<santagada> jelmer: maybe
<jelmer> hmm, lazy commands already landed !
<jelmer> I never noticed
<bialix> jelmer: bug 323207
<ubottu> Launchpad bug 323207 in bzr-git "`bzr.exe selftest git` fails" [Undecided,New] https://launchpad.net/bugs/323207
<jelmer> bialix, thanks!
 * bialix pushing the branch with bzr.exe support patch to lp
<bialix> jelmer: the patch: https://code.launchpad.net/~bialix/bzr-git/bzr.exe/+merge/3258
<santagada> speakman: did you reported your bug on trac-bzr?
<speakman> santagada: sorry, no time for that at the moment :(
<speakman> santagada: will get back to it later, or other bugs (there are some in that package)
<speakman> now have to leave, thanks for your time
<sohail> lifeless, awake?
<jelmer> hi rockstar
<jelmer> hi rocky
<rocky> heyo ;)
<jelmer> Peng_, thanks!
<rockstar> jelmer, turn my tab blue...
<jelmer> rockstar: Sorry :-)
<rockstar> jelmer, :)
<rockstar> jelmer, for the bzr-stats changes, should I request a review from you?
<jelmer> rockstar: yeah, from either me or John
<jelmer> perhaps we should create a team for bzr-stats. are you in the bzr developers team?
<rockstar> jelmer, I don't think so.  I don't think I've made many contributions to bzr.
<jelmer> rockstar, I've created a bzr-stats team that now owns bzr-stats; you should be able to request review from that team
<rockstar> jelmer, can you set the default review team for lp:bzr-stats to be that team?
<jelmer> rockstar, how do I do that?
<rockstar> jelmer, I did it.
<bialix> jelmer: dulwich/test/__init__.py uses only test_objects, test_repository and test_pack as modules for testing. but test_index and test_object_store are not. should I update this?
<Jc2k> bialix: thats fixed in my branch already (i added another test as well)
<bialix> Jc2k: I'd like to add test runner for dulwich. What is your branch?
<Jc2k> bialix: you mean instead of make check?
<Jc2k> my branch is at lp:~johncarr/dulwich/git-serve
<bialix> (shy) yes, sir
<Jc2k> i think jelmer has merge it, but maybe not pushed yet
<bialix> like this: http://bazaar.launchpad.net/~bialix/intelhex/trunk-w-tags/annotate/head%3A/setup.py (lines 75-99)
<bialix> I don't have twisted
<Jc2k> ah i see
<Jc2k> i use nosetests instead of twisted
<bialix> do you think my test runner will be too much of trouble for you and jelmer?
<bialix> though it's optional
<Jc2k> its not up to me, but i have no objections to it.
<bialix> what it means "up to me"?
<Jc2k> its not my decision
<bialix> jelmer said: "ah, ok". so I'll prepare the patch then
<kfogel> Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")?
<ubottu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715
<kfogel> I ask because 'bzr log -v' (the obvious workaround) is too slow.
<kfogel> I can't think of any other workarounds, but maybe someone here can?
<sohail> I need help... I have two branches, master and next... I was doing work in the "next" branch by switching to it.. However when I switch back to the master branch, the next changes are in this branch! The log however says that the changes were made to branch nick "next". So lost.. Help... please...
<nua> how can I get a machine readable log from bzrlib? Do I have to write a log formatter?
<kfogel> Can anyone think of a workaround for bug #97715 ("bzr log DIR should show changes under DIR")?
<ubottu> Launchpad bug 97715 in bzr "bzr log DIR should show changes under dir" [Medium,Confirmed] https://launchpad.net/bugs/97715
<kfogel> I ask because 'bzr log -v' (the obvious workaround) is too slow.
<kfogel> I can't think of any other workarounds, but maybe someone here can?
<Goundy> Hi. Quick & noob question:
<Goundy> I've two branchs: mainline (main branch) and working (the branch I work on)
<Goundy> When I do changes and commits on my working branch then I call: cd ../mainline && bzr merge ../working
<Goundy> but I figured out that I lose all commits I did on my working branch
<luks> you do not lose them
<Goundy> luks well yes I know
<Goundy> But what I want to do is to apply changes on mainline and also commits with commits messages I wrote while commting in working
<Goundy> Is there a way to do that ?
<luks> are you planning to remove the working branch after merging it?
<jelmer> kfogel, I don't think there is a good way to work around that. brisbane-core will be *some* help I think
<Goundy> luks no I just work on it everytime, and use the mainline one to apply patchs... etc
<kfogel> jelmer: thanks
<luks> Goundy: then there is no good way
<Goundy> ha :/
<luks> Goundy: there is a way if you don't mind destrying the working branch
<Goundy> luks well no way ^^
<Goundy> thank you :-)
<luks> but if you intend to continue to work in it, it would cause problem
<luks> +s
<Goundy> I see yea
<Goundy> luks then is there a good & quick way to specify commit message for each change ?
<luks> btw, what I meant was "bzr rebase ../mainline && cd ../mainline && bzr pull ../working"
<luks> Goundy: specify?
<luks> where?
<Goundy> luks well atm I do: bzr commit -m "my message"
<Goundy> and this message applies to all my changes
<jelmer> kfogel, are the emacs-related bugs tagged in launchpad, or is there a list of emacs-related bugs?
<Goundy> for example if I want a different message for each file is there another way than bzr commit  /path/to/file/file.c -m "message" ?
<kfogel> jelmer: look for "emacs-adoption" tag, I think
<luks> I don't know, I personally use qcommit which is a window that allows me to select files and type the message
<luks> easier to pick which files you want to commit, but probably not what you are looking for
<Goundy> luks I hate UI for DVCS softwares ^^
<Goundy> but thanks for the tip ;)
<luks> well, it's easier than typing and tab-completing the filenames
<kfogel> jelmer: I've just add bug #246891 to that list, and see this comment:
<ubottu> Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] https://launchpad.net/bugs/246891
<santagada> usually I also hate the gui for all vcs
<kfogel> https://bugs.edge.launchpad.net/bzr/+bug/246891/comments/8
<ubottu> Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed]
<santagada> but during commit they help a lot
<Goundy> luks sure but I really think DVCS shouldn't be used through GUI front ends... that really sucks
<Goundy> And sometimes you get hard bugs I hate that ><
<luks> Goundy: what's so special about DVCSes?
<Goundy> luks DVCSes are fine but not GUI front ends written for them that's it
<Goundy> well not all DVCSes are cool of course (CVS and SVN -> trash :P)
<Goundy> And that was the troll of the day \o/
<LeoNerd> Eh. CVS isn't so bad, really... It's very clear upfront about what it can and can't do. Of the things it can do, it does very well
<Goundy> heh might be true but as I said: that's a troll :P
<Goundy> personnaly I was using svn, but once I discovered bazaar >_<' I really liked it ! that's an awesome release
<Goundy> Fast, simple and powerful (nothing missing)
<kfogel> jelmer: hunh.  In launchpad's bzr bug tracker, I just did "Search: Enter bug ID or keywords:" and entered "emacs-adoption".  Now, I *know* there's at least one bug with that tag, because I just tagged 246891 with it, and there should be four others from before as well.  But nothing came up.
<jelmer> kfogel, if you go to the "bugs" tab in zbr
<kfogel> jelmer: ooooooh
<jelmer> there's a list of links on the right with tags
<kfogel> advanced search
<kfogel> So "tags" are different from "keywords".
<kfogel> yeah, found it
<sohail> anyone have an idea about: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/51820
<davidstrauss> lifeless: I have Yves's bzr.log when you're ready.
<mtaylor> lifeless: so... bzr uncommit gives me a confirmation dialog
<mtaylor> lifeless: bzr revert, on the other hand, happily just works
<mtaylor> lifeless: except that sometimes I've accidentally hit enter after the word revert when I just meant to revert one file
<mtaylor> and have lost an entire tree's worth of changes
<mtaylor> perhaps a config option to turn on revert confirmation dialogs?
<garyvdm> bzr uncommit has a way to undo - bzr revert doesn't
<mtaylor> Goundy: so, there's a patch to gcommit that allows per-file commit messages
<mtaylor> damn
<mtaylor> just missed him
<kenichi> is there a flag or something to tell bzr-email to send from the server vs. from the client?
<kenichi> i have two identically configured servers and branches.  committing to a branch on one sends email from the server process itself (apache), committing to a branch the other sends (or tries and fails) from the client.
#bzr 2009-01-31
<mrooney> Any particular reason bzr needs a lock to do a [c]diff?
<mrooney> I frequently find that I am committing and forget something about a change, so try to do a diff in another terminal, but I can't :[
<mrooney> and if I exit I lose the commit message so far
<lifeless> mrooney: yah there is a file that commit writes to that diff needs to read
<lifeless> we will fix this, but for now 'commit --show-diff'
<mrooney> lifeless: thanks I'll give that a try!
<mrooney> huh I typo'd it to --show-dif and it still worked, interesting
<mrooney> lifeless: aw man no --show-cdiff :)
<mrooney> I guess most things might not support that anyway
<jonnydee> hi :) -- can anybody tell me why I get a "bzrlib version doesn't match the bzr program" on intrepid with bzr-1.11?
<jonnydee> no?
<nDuff> jonnydee, probably means what it says -- perhaps you have either a bzr program or a copy of the library sitting around somewhere from an old install.
<Peng_> "bzr version" will help tell you where everything is
<jonnydee> but the strange thing is that I uninstalled all bzr related things and I made sure no bzrlib existed. but after I install bzr-1.11 again I get the same error...
<jonnydee> The message is "bzrlib from ['/usr/lib/python2.5/site-packages/bzrlib'] is version (1, 11, 0, 'final', 0)"
<nDuff> jonnydee, then your bzrlib is fine, but your bzr executable is old
<jonnydee> but I get bzr from "deb http://ppa.launchpad.net/bzr/ubuntu intrepid main"
<Peng_> jonnydee: grep _script_version `which bzr`
<Peng_> Can't out-of-date extensions also cause error messages like that?
<nDuff> Peng, ...hmm -- I think you're right.
<jonnydee> Oh, this one returns:
<Peng_> Err, plugins. Oops.
<jonnydee> _script_version = (1, 9, 0)
<jonnydee> if bzrlib.version_info[:3] != _script_version:
<Peng_> jonnydee: Then you've got an old copy of the bzr script around somewhere. 'which bzr' to see where. Or maybe the deb is broken...
<jonnydee> Peng_: You are right. I've got a bzr in my ~/bin folder...
<Peng_> Well, there you go.
<jonnydee> Thank your very much Peng_ and also to  nDuff. What a shame... I'm sorry...
<GPH-Laptop> 10.4 doesn't get any love anymore :(
<GPH-Laptop> Mac OS X, that is
<xnox> Hello everyone. Two branches don't have no common ancestor and I can't figure out how to specify base revision. I've tried -r X -r Y and -r X Y and it fails =(
<xnox> Saying extra arguments
<xnox> or still unspecified base revision
<LarstiQ> xnox: trying to do what?
<xnox> I have two branches, one from me and one from the other guy. We were doing very similar things from scratch (debian packages). Now I want to merge our two branches and create mainline to base our future work on.
<LarstiQ> xnox: you could try `bzr merge -r0..-1 path/to/other/branch`
<xnox> But to merge one into the other I need to specify a base revision (according to the error message).
<xnox> LarstiQ: Thanks that worked!
<nebuchadnezzar> hello, after upgrading bzr to 1.11, I try to upgrade a branch from svn to 1.9-rich-root, and now I can not pull any more, I have "branches have diverge use merge" and when merging I get no common ancestor :-/
<nebuchadnezzar> any hints ?
<LarstiQ> nebuchadnezzar: could you pastebin the commands and their output?
<LarstiQ> nebuchadnezzar: also, why did you decide to upgrade to 1.9-rich-root?
<nebuchadnezzar> LarstiQ: to give it a test
<alf82> hello, I have a workflow question with bzr/launchpad. Let's say you have the 'trunk' branch used for development and you release eg 0.1
<alf82> and create a 0.1 series/branch. Where do you continue development then? On the trunk and merge the changes into the 0.1 branch once in a while
<alf82> or on the 0.1 branch and merge the changes into trunk every now and then?
<LarstiQ> alf82: there are multiple things you could do. In general, I'd say you'd release 0.1 and don't touch it after that.
<LarstiQ> alf82: could you explain your situation a bit more?
<LarstiQ> nebuchadnezzar: how's that pastebin coming along?
<alf82> LarstiQ: Well, I have a 'trunk' branch which has been the main (and only) development branch so far (except for feature branches).
<alf82> The project is at the point of its first 0.1 release and I don't know exactly how to handle that. Should I create a separate 0.1 for the development
<alf82> of the 0.1.x series?
<LarstiQ> alf82: do you expect 0.1.x and trunk to diverge a lot?
<alf82> LarstiQ: no
<LarstiQ> alf82: say, Samba 3 and 4 both have active development and releases at the same time
<LarstiQ> alf82: I'd just stick with trunk then
<alf82> LarstiQ: ok, that's what I was thinking. In LP does it make sense to register a 0.1 series that also uses the 'trunk' branch?
<alf82> LarstiQ: or I shouldn't use series at all?
<LarstiQ> alf82: I haven't checked lp's docs on series in a while, but Bazaar uses a series per release to group release candidates and possibly bug fix releases
<nebuchadnezzar> LarstiQ: http://pastebin.com/m5616edd9 <-- I try with a pack-0.92-subtree branched-from-svn
<LarstiQ> alf82: so all regular activity goes on on trunk
<nebuchadnezzar> http://pastebin.com/d499880c <-- here is what the merge output too
<LarstiQ> nebuchadnezzar: your merge uses a different location than the pull
<LarstiQ> ah no, I was looking crooked
<nebuchadnezzar> ;-)
<LarstiQ> nebuchadnezzar: if you look at `bzr missing` output, they don't share any revision, right?
<LarstiQ> nebuchadnezzar: I find it very unlikely this has anything to do with 1.9-rich-root
<LarstiQ> nebuchadnezzar: more with a change in bzr-svn, or the path you're pointing bzr-svn at
<LarstiQ> nebuchadnezzar: you're using bzr-svn 0.4?
<nebuchadnezzar> LarstiQ: I'm downgrading bzr to 1.5
<LarstiQ> nebuchadnezzar: that too, should not have any impact.
<nebuchadnezzar> LarstiQ: I downgrade bzr to 1.5 and bzr-svn to 0.4, pull wored
<nebuchadnezzar> worked
<LarstiQ> nebuchadnezzar: before you downgraded, what bzr were you using?
<LarstiQ> ehm
<LarstiQ> bzr-svn
<nebuchadnezzar> 1.11
<nebuchadnezzar> from debian experimental
<nebuchadnezzar> 0.5
<nebuchadnezzar> 0.5.0~rc1+bzr2300-1
<LarstiQ> nebuchadnezzar: if you were using 0.5rc[12], then yes, it produces different revisions than 0.4 does.
<LarstiQ> nebuchadnezzar: so, nothing to do with bzr 1.11 or 1.9-rich-root. This is purely bzr-svn 0.4 vs 0.5
<nebuchadnezzar> ok
<nebuchadnezzar> LarstiQ: my cfengine3 repository is pack-0.92-subtree
<LarstiQ> nebuchadnezzar: that's fine, but the format has no impact on the issue you were experiencing
<LarstiQ> nebuchadnezzar: see UPGRADING from bzr-svn 0.5
<nebuchadnezzar> ok, thanks
<LarstiQ> nebuchadnezzar: basically, to be faster/smarter, 0.5 introduces new svn-revision-to-bzr-revision mappings
<LarstiQ> in order to use those, it has to be incompatible with prior mappings. You can optionally chose to use the old mappings, but you won't gain any of the advantages of the new one then.
<LarstiQ> It is possible to use a 0.4 and a 0.5 client at the same time against svn, but you can not interact directly between the bzr branches created that way
<nebuchadnezzar> LarstiQ: I saw that in the documentation, thanks
<nebuchadnezzar> bzr svn-upgrade and now it's ok
<LarstiQ> nebuchadnezzar: cool
<nebuchadnezzar> thanks
<alf82> LarstiQ: thanks for the tips (yeah, a little delayed, I know)!
<bialix> LarstiQ: hi
<LarstiQ> bialix: hello
<bialix> I'm curious about your opinion on scmproj
<LarstiQ> bialix: I condensed the notes a bit, but am still not entirely done. So I'll just give you the raw thing (with repetitions et al) and the more condensed thing
<LarstiQ> bialix: I think it could be very useful for me.
<bialix> that's ok. I moving new format forward
<bialix> unfortunately new format will introduce many changes
<bialix> and ATM we don't have auto-upgrade
<LarstiQ> bialix: In your config-manager comparison you state you need more than organizing branches. I'd be interested to hear what you need more. (So far, what would be harder to do with nested trees is the ALT style config switching)
<LarstiQ> evening kfogel
<bialix> well, config-manager != nested branches
<bialix> or nested trees, perhaps
<LarstiQ> sorry, I made a thought leap there
<bialix> I think without ability to work on the entire project -- it's just many branches accidentally put in one directory
<bialix> I want to run status, commit, diff, log forthe entire pject
<bialix> project, sorry
<LarstiQ> bialix: right, nested trees do that
<LarstiQ> and where they don't, have it as a design goal
<LarstiQ> but progress has been lacking, scmproj has more steam going for it to accomplish those goals
<bialix> LarstiQ: if there will be already implemented nested trees -- unlikely I'll start this plugin
 * LarstiQ nods
<bialix> also, I simply don't understand how nested trees will be stored on the server
<LarstiQ> bialix: scmproj does have features I think are harder to do with a different solution
<bialix> you said about graph recalculation
<LarstiQ> bialix: that was for by-value trees
<LarstiQ> bialix: so yeah, scmproj is here right now, and that's a big plus
<bialix> yes, and I think nested by ref has bigger sense for me and my use cases
<bialix> but I can't grok their internal details yet
<bialix> LarstiQ: and I hope when nested will be supported in bzrlib, I can use them from scmproj
<LarstiQ> bialix: cool
<LarstiQ> bialix: mail sent
<bialix> big thanks
 * bialix bbiab (dinner)
<bialix> LarstiQ: wow, this notes are VERY useful. Big thanks
<LarstiQ> bialix: much obliged :)
<LarstiQ> bialix: the thoughts in my head concern your question about 'clunky'
<LarstiQ> bialix: I can sort of see his point, but I haven't yet found how to clearly explain that.
<bialix> yes, I think now I understand "clunky" better
<bialix> my plans for 0.4.5 are to change many "clunky" points
<bialix> and as AmanicA mentioned: better catch and report internal errors
<LarstiQ> bialix: one thing that would be nice, is that if there is enough information in the general sections, I wouldn't need to have a seperate section for each component.
<AmanicA> hi
<LarstiQ> AmanicA: evening :)
<bialix> Ð¿ÑÐ¸Ð²ÐµÑ
<bialix> hi dude
<AmanicA> :)
<LarstiQ> bialix: you'll see in my project.cfg there is a lot of repetition, and the notes you'll see a KeyError on 'mqueue'
<bialix> LarstiQ: I think very soon I'll be ready to show new config format. There is many improvements. I'll use your notes and convert them to bug reports to work on
<LarstiQ> bialix: ok :)
<bialix> I hope in the mid of Feb
<bialix> generic [COMPONENTS] section was suggested (and implemented IIRC) by AmanicA
<bialix> we need just bring there more options
<bialix> LarstiQ: yeah, I see your point. In the components sections you have only FORMAT = rich-root-pack; :-)
<bialix> I've filed this as bug 322499
<ubottu> Launchpad bug 322499 in bzr-scmproj "[COMPONENTS] section should support default values for FORMAT and VCS options" [Low,Confirmed] https://launchpad.net/bugs/322499
<LarstiQ> bialix: yeah, in this case all the components are rather uniform, yet I still like having them as seperate branches
 * bialix nods
<bialix> LarstiQ: one side question: you said: "I made a thought leap there"; what it means: "thought leap"?
<LarstiQ> bialix: skipping (talking about) several steps in a thought process
<LarstiQ> bialix: so to amend that: I read the config-manager vs scmproj, and that made me think of nested-trees vs scmproj
<bialix> :-)
<bialix> I have such comparison
<bialix> but it's incomplete
<LarstiQ> bialix: from talking to you, I know what I wanted to know
<bialix> http://bazaar.launchpad.net/~bialix/bzr-scmproj/format-change/annotate/head%3A/docs/vs-nested-trees.txt
<bialix> may be I'm wrong about initial configuration in the nested trees. but I'm still don't read all sources
<LarstiQ> bialix: unfortunately, at work I've been switched to coding Java Server Faces (entirely seperate cient project), so I don't have as much opportunity to try scmproj on our regular work stuff
<bialix> ok, np
<bialix> LarstiQ: I hope you still can share some knowledge about nested trees
<bialix> nevertheless of java faces
<LarstiQ> bialix: of course, I just need to look everything up :)
<LarstiQ> bialix: I'm interested to hear what abentley is planning
<bialix> :-)
<LarstiQ> bialix: what do you mean with 'the initial configuration'?
<bialix> LarstiQ: this is related to my lack of understanding of nested by ref. How user can recreate nested project from standalone branches?
<bialix> if these brances hosted on the central server, for example
<LarstiQ> bialix: Right
<LarstiQ> bialix: there are still open questions here I think
<bialix> before bzr I've used CVS very heavily. And we're used CVS modules too
<bialix> so my project.cfg in some sense used my knowledge about CVS modules. May be this knowledge prevent my understanding of some nested ideas
<bialix> in the end I'm just reinventing the wheel
<KintaroHoe> Hi everyone
<KintaroHoe> I've a question I need to install a bzr server in the office I work for
<bialix> hi
<KintaroHoe> They use windows and I'm unable to find a documentation that explain how to do all of this :/
<bialix> I'm windows guy
<KintaroHoe> I'm trying to play with bzr init-repo... but unable to do checkouts
<bialix> what's the problem actually?
<KintaroHoe> bialix: Well I want to install a server to host the office projects and I don't know how to do this :/
<bialix> you need local only server?
<KintaroHoe> yes
<KintaroHoe> a LAN server
<bialix> it will not be visible outside the local network?
<KintaroHoe> bialix: indeed
<bialix> so you need to install bzr as usual from any of official installer
<MattCampbell> I want to use bzr and bzr-svn to manage my modifications to an open-source package that uses SVN for its version control, with the intention of contributing at least some of these changes back upstream.  Is there a recommended workflow for doing this?
<KintaroHoe> bialix: yes I have it
<bialix> then select where you want to keep your branches
<KintaroHoe> bialix: okay and then ?
<bialix> then you need just adding to auto-start section the command: bzr serve --allow-writes
<bialix> and specify working directory for this command to the location where you want to keep your branches
<bialix> that's basically all
<KintaroHoe> bialix: what auto-start sectiopn ?
<bialix> Start -> Programs -> Auto-...
<KintaroHoe> ah yeah ok
<KintaroHoe> bialix: but now how ti initialize branches in server side ?
<bialix> sorry, I'm using Russian Windows, I don't remember how it named in English
<KintaroHoe> because I do: mkdir dir and then bzr init dir
<KintaroHoe> but when I checkout it says not a branch
<bialix> you need to work with your server with bzr:// url
<KintaroHoe> I don't understand this
<MattCampbell> bialix: I think you mean Start -> Programs -> Startup
<KintaroHoe> yes
<KintaroHoe> I get it for the autostart
<bialix> yes, I think it is
<KintaroHoe> but now I don't know how to create my projects and project branches in server side
<bialix> let's say your server has name SERVER or IP: 192.168.1.1
<MattCampbell> KintaroHoe: Since I came in late to this conversation, can you explain what you're trying to do?
<KintaroHoe> ok
<KintaroHoe> MattCampbell: all I want is hosting projects in bazaar for the office I work for
<bialix> you can execute from any other machine (or locally): bzr init bzr://SERVER/branch-name
<KintaroHoe> they uses windows
<KintaroHoe> bialix: ah ok
<bialix> everything as local work, but you should use bzr:// urls
<KintaroHoe> bialix: ok
<MattCampbell> KintaroHoe: It would probably be easier if you used Linux on the server.
<MattCampbell> Then you can just use sftp or bzr+ssh with regular Unix accounts.
<CaMason> hi guys.. for some reason, a load of bzr_log.random files have started appearing in my working copy
<bialix> heh
<bialix> KintaroHoe: one note about startup
<KintaroHoe> MattCampbell: I can't my boss doesn't want a linux that(s the issue
<bialix> windows works just fine!
<KintaroHoe> windows sux but I'm forced to use it
 * bialix shuts up
<MattCampbell> I'm not bashing Windows in general; it's a fine desktop OS.
<MattCampbell> KintaroHoe: What version of Windows is the server running?
 * LarstiQ looks up
<KintaroHoe> MattCampbell: XP
<KintaroHoe> MattCampbell: is there a document that explains how to set up a bazaar server for projects ?
<MattCampbell> I'm looking; I don't need it myself, but now I'm curious.
<LarstiQ> KintaroHoe: what bialix said I'd say
<LarstiQ> KintaroHoe: you mention you can't checkout, could you please give more context (pastebin full command plus output)?
<LarstiQ> KintaroHoe: with the information at hand it is hard to tell what is going on.
<MattCampbell> The only problem with putting the server in the Startup group is that then the server will only be available while someone is logged into the Windows box.
<bialix> MattCampbell: I'm running it as servicwe
<bialix> service
<MattCampbell> bialix: How do you do that?  Do you use servany or something similar, or is there a special bzr executable for that purpose?
<bialix> so it works just fine
<bialix> srvany
<MattCampbell> Oops, I did misspell that.
<bialix> here instructions: http://groups.google.com/group/ru_bzr/web/bzr-serve---windows-2k-xp
<bialix> they're in Russina
<bialix> Russian
<bialix> use babelfish or google translate service
<MattCampbell> I've used srvany before.  What user should the service run as? (e.g. System, LocalService, NetworkService)
<LarstiQ> MattCampbell: you don't perchance have commit access to the upstream svn?
<bialix> I don't remember. My server at work, and now I'm home
<MattCampbell> LarstiQ: No; that's why I want to use bzr and bzr-svn, because SVN vendor branches seem like an ugly hack.
<MattCampbell> So I would be sending patches of some kind back upstream.
<LarstiQ> MattCampbell: right
<LarstiQ> MattCampbell: so then the most important part is probably how upstream likes to work
<LarstiQ> MattCampbell: I didn't test against svn, but you could use `bzr send`
<MattCampbell> bialix: Your Windows bzr server requires authentication and is used by multiple developers, right?  I wonder how you manage user accounts for the bzr server in that setup.
<LarstiQ> MattCampbell: large chance that's not exactly what upstream wants though
<bialix> no
<bialix> builtin bzr server does not provide ACL support
<bialix> we have very small dev group
<bialix> so I should not be paranoid about other people
<bialix> and I always has backups if something will going wrong
<MattCampbell> LarstiQ: I suppose most projects want plain diffs, often attached to bug tracker entries, from non-committers.
<bialix> though I'd like to have some sort of ACL there
<LarstiQ> MattCampbell: that, or mailing lists, yes.
<LarstiQ> MattCampbell: but do they want one big rollup patch? Or one patch per bzr commit? Or rebased into logical units?
<LarstiQ> MattCampbell: bzr-rebase might also be of use to you
<MattCampbell> FWIW, the specific project is TightVNC.  I haven't even started making my changes yet, but I want to make sure my workflow is right from the start.
<MattCampbell> I haven't even had any contact with that project yet; I'm just starting out.
<MattCampbell> So I guess I start with "bzr branch http://vnc-tight.svn.sourceforge.net/svnroot/vnc-tight/trunk/ tightvnc", then make my changes, committing to my local branch after each change is done.
<MattCampbell> Then I can think about how to give them back.
 * LarstiQ nods at MattCampbell 
<MattCampbell> Is bzr-svn meant to use this way, i.e. to contribute back to a project that uses an SVN repository in which you're not a committer?
<LarstiQ> MattCampbell: I don't think it's the original use-case, but it's certainly valid.
<bialix> KintaroHoe: I think you should start using bzr without any server. Any shared folder on your server is fine
<MattCampbell> So the original use case is a project that wants to migrate from svn to bzr?
<bialix> he's left.
<MattCampbell> I suppose Windows file sharing is the most natural solution in a Windows-only office where everyone is on the same LAN.
<bialix> me too
<MattCampbell> I was going to suggest using an SSH or SFTP server, such as VShell (commercial) or Cygwin sshd.
<MattCampbell> LarstiQ: Thanks for at least re-assuring me that I was on the right track.  My biggest fear when using version control is always that I'll start out doing things the wrong way.
<LarstiQ> MattCampbell: I'd guess the original use case is using bzr to commit to an svn repo where others still use svn.
 * svn-up just realized he might get kicked because of his nickname
<LarstiQ> svn-up: nah, that won't happen
<MattCampbell> I didn't think this crowd was that antagonistic toward svn.
<LarstiQ> we're not.
<LarstiQ> I might at times lament some of it's shortcomings that make my life difficult, but that's all :)
 * bialix waves bye
<MattCampbell> Now I just have to learn how to set up bzr-svn under Windows.  I'd prefer to just use my Ubuntu VM (yes, Windows is the host), but I'm going to be working on a Windows program.
<LarstiQ> MattCampbell: bzr-svn is included with the windows installer
<LarstiQ> at least the standalone .exe one
<MattCampbell> LarstiQ: Cool, thanks.
<MattCampbell> downloading version 1.11-1 of that now.
<MattCampbell> I'm curious about the state of IDE integration for Bazaar.  In other words, is Bazaar yet as "code monkey" friendly as Subversion?
<LarstiQ> MattCampbell: I'll wager a 'no' to that.
<LarstiQ> MattCampbell: I believe the Eclipse support is most advanced.
<LarstiQ> MattCampbell: http://bazaar-vcs.org/IDEIntegration
<visik7> nothing about Xcode :(
<LarstiQ> http://bazaar-vcs.org/Integrating_with_Bazaar for those willing to work on support for their favorite environment :)
 * LarstiQ is a vim user himself
<MattCampbell> Mind you, I don't use an IDE, even on Windows; currently I use vim plus command-line tools.  But I might soon be working with people who are used to an IDE.
<LarstiQ> although I've had to start using netbeans since last week
<LarstiQ> MattCampbell: right, which one?
<LarstiQ> MattCampbell: there is Tortoise, which builds on Qbzr
<MattCampbell> Probably Visual Studio.
<MattCampbell> Then again, a lot of the software I've written for my employer (I'm currently the lone programmer) is in dynamic languages such as Python, Lua, and PHP.
<MattCampbell> So I don't really know what IDE would be a good fit.
<MattCampbell> but that's off-topic here.
<MattCampbell> Hmm, I was thinking ActiveState Komodo would be a good choice; now I see it has built-in Bazaar support
<LarstiQ> does it? cool :)
<MattCampbell> Well, at least the IDEIntegration page says so.
<LarstiQ> It's in the 5.0 release notes too
<MattCampbell> To my shame, my company is just starting to use version control.  Our new project manager wants to use SVN, and I've been debating whether to persuade him (and the CEO) of Bazaar's benefits or just use SVN.
<MattCampbell> I think we should at least use bzr to manage modifications to open-source packages that we use.
<LarstiQ> MattCampbell: you said you were the lone coder, does that hold true for this situation?
<MattCampbell> I won't be the lone coder much longer.
<MattCampbell> (So I have a lot of work to do to transition from lone coder to team.)
<MattCampbell> But I may very well be the only one making modifications to upstream open-source projects, at least for a while.
<LarstiQ> MattCampbell: ah ok
<MattCampbell> I gather that the bzr Windows installer doesn't include bzr-rebase.
<LarstiQ> MattCampbell: probably not
<CaMason__> Guys, any idea what these log files are? bzr_log.number~
<mrooney> Is there any easy way to delete a branch on LP, I typo'd in my push
<mrooney> or is that a #launchpad question?
<jelmer> I think there is a  bin icon you can click
<jelmer> but in general this sort of question is more appropriate for #launchpad
<mrooney> jelmer: okay, thanks :)
#bzr 2009-02-01
<eferraiuolo> I have a question about using the contrib/bzr_access script
<eferraiuolo> Invocation: bzr_access <bzr_executable> <repo_collection> <user>
<eferraiuolo> do you have to call this with every user?
<eferraiuolo> I'm confused about the "user" param; I though the config file would handle the user stuff
<eferraiuolo> I guess it get it now, when a user logs-in the bzr_access command is ran
<beekor> Hi ya'll.  I'm new at VCS type stuff, and am a bit lost.  I'm aiming for the Centralized Development model in the userguide.  I got my directory all init'd on the server part, and did a Checkout to make the directories on my user machine.  I committed a change on my machine, now I'm trying to figure out how to get it back to the server.
<beekor> I did a Merge, but it says Nothing to do.  so that makes me thing that's not correct.
<AfC> $ bzr push
<AfC> {shrug} We don't really do centralized development, so I don't know what the User Guide is recommending about that these days.
<beekor> yeah I tried a push, but that gave me conflicts.
<beekor> What format do you all use then ?
<beekor> I'm just one guy trying to work at 2 computors.
<beekor> so i commit then i push.  okay.  hmmm
<AfC> beekor: we have a number of contributors all of whom have branches; I also act as a gatekeeper as I'm the only one who can publish to the project's public 'mainline' branch, so people send me bundles if they want their work considered for merging and publication (as part of the project).
<beekor> gotcha.  I'm still working through the terminology a bit here.
<AfC> Straight forward DVCS, except that people have been living with the crippled centralized modality of CVS & Subversion heritage that the decentralized world all seems a bit horrible and scary.
<beekor> this is my first foray into any of the VCS programs at all.
<AfC> It's not, really, but it takes a bit of getting used to. In my experience, decentralized has entirely been worth getting people up to speed with, but for very small changes it can be a bit fiddly.
<AfC> (and given that most people's first interactions are for small deltas, all the fiddling about seems excessive. This is not an unreasonable first impression)
<beekor> so basically, i Merge to update my branch(?) from the server, and then Push to update the server of my changes that I've Commit-ed ?
<AfC> um
<beekor> haa
<AfC> you get a branch from the server
<beekor> i don't liek that um.
<beekor> okay.
<AfC> you then make changes
<AfC> you commit
<beekor> im with ya so far.
<AfC> you can then push to the server.
<AfC> HOWEVER
<AfC> if the server has since diverged from when you branched,
<AfC> then you cannot push
<AfC> (or, if you were sitting on the server, you could not pull)
<beekor> was that my conflicts  that I got?
<AfC> and (again, from the server side) you would have to do a merge instead of a pull
<AfC> beekor: probably
<beekor> k
<beekor> hmm.
<AfC> Now. Bazaar has a notion called "bound branch" which you can (perhaps deliberately, perhaps inadvertently) create with
<AfC> $ bzr checkout
<AfC> instead of
<AfC> $ bzr branch
<AfC> the *only* difference
<AfC> between the two (bound in the first case, unbound in the second)
<AfC> is that with a checkout (bound branch) you cannot commit to the local branch unless the commit first succeeds on the other [typically remote] branch.
<AfC> which turns out to be the "centralized" model we're used to from CVS.
<AfC> for people who are accessing our public 'mainline' for which not a one of them have write access to,
<AfC> this means that they in effect get a read-only local copy [mirror, even] of the upstream project.
<AfC> they can then branch that locally to have a copy they can work in.
<AfC> This tends to be a useful approach
<beekor> okay.  so to work on my user machine, i originally did a Checkout.  maybe that is a source of my issues.  I will try with a Branch
<AfC> beekor: http://java-gnome.sourceforge.net/4.0/get/#source describes this, although it may not be interesting to you
<AfC> beekor: other than this bound bit
<AfC> (and it literally is a boolean, there's nothing else on disk that differentiates them)
<AfC> there is no difference between a checkout and branch. A "checkout" in Bazaar *is* a branch
<AfC> with some extra constraints thrown in
<beekor> okay.
<AfC> (and you can always unhook that constraint with
<AfC> $ bzr unbind
<AfC> )
<AfC> so the real issue
<AfC> is deciding how you want changes to flow.
<AfC> this has little to do with Bazaar, actually
<AfC> if you are only moving changes (ok, revisions, actually)
<beekor> now, i should only have to checkout/branch initially.  after that, i stay updated with Merge.  is that correct ?
<AfC> in one direction
<AfC> and assuming you have constant always on write access to the other side, and just want the other side to always be what's local
<AfC> then a local branch bound to the remove one will do you fine.
<AfC> there were a lot of "always" in that last sentance.
<beekor> ha.
<AfC> If you're working independently on both sides then you'll have to be more careful
<AfC> s/careful/deliberate/
<AfC> but if you only ever work locally and are just pushing deltas up to a server
<AfC> then a) no need for it to be a checkout and b) push will always work
<beekor> okay.
<AfC> [or, ssh server && bzr pull]
<AfC> [assuming access works in the other direction, which it usually doesn't]
<AfC> So that's about all you're getting out of me pro bono.
<AfC> If you think about all that you'll probably find your way.
<AfC> The fact that you created divergence on the server side indicates lots of things, but I imagine you'll be able to play with it from here.
<beekor> well that's a lot of free info, i'd say.
<beekor> not a lot that I understand at this point, but that's my issue.
<beekor> i will save this conversation and refer to it laterwise.
<beekor> thanks for the help.  i do appreciate it.
<AfC> beekor: one last thought: people tend to overcomplicate things.
<beekor> hahaha.
<nielsbom> Anyone know a good introductory screencast for bzr? (and yes I googled)
<LarstiQ> nielsbom: emmajane might have done one
<nielsbom> LarstiQ: I saw those two :)
<nielsbom> They were good, but I would like some more.
<LarstiQ> nielsbom: what would you like to see?
 * LarstiQ attempts flashing his bios
<nielsbom> LarstiQ: well I have trouble visualizing/envisioning how bzr merges files
<nielsbom> LarstiQ: and I'd like to know how it works before I start using it :)
<LarstiQ> nielsbom: perfectly? ;)
<nielsbom> LarstiQ: well somewhat :)
<nielsbom> LarstiQ: I can stand a bit of black-boxxines
<garyvdm> nielsbom: do you understand how 3 way file merges work?
<nielsbom> garyvdm: nope
<jelmer> LarstiQ, ping
<nielsbom> Ow btw a more concrete question (and a noob one) how can I set up my hosted server so that I can push a revision to it?
<garyvdm> nielsbom: This explains it nicely in the context of vcs
<garyvdm> http://www.ericsink.com/scm/scm_file_merge.html
<nielsbom> (just ftp?)
<jelmer> LarstiQ, can you check whether bug 320113 is fixed?
<ubottu> Launchpad bug 320113 in bzr-svn "svn-upgrade fails with a KeyError (in rebase generate_transpose_plan)" [Undecided,Incomplete] https://launchpad.net/bugs/320113
<LarstiQ> jelmer: I can.
<LarstiQ> jelmer: do you want me to do that now?
<jelmer> LarstiQ, yeah, if possible
<jelmer> LarstiQ, I'm pondering about releasing 0.5.0 today
<garyvdm> nielsbom: You can push your revisions to ftp, but it won't update the working tree in the ftp dir
<LarstiQ> nielsbom: just ftp works, although it is ahorrible protocol, use sftp if you can
<LarstiQ> jelmer: ok, let me see
<LarstiQ> jelmer: I don't suppose you can help me flashing my bios? ;)
<nielsbom> garyvdm: "won't update the working tree in the ftp dir", but what good does it do then? (in the case that I want to push code to my server?)
<jelmer> LarstiQ, you're still trying to do that ? :-)
<garyvdm> nielsbom: you can use the upload plugin to upload a tree.
<garyvdm> nielsbom: Note that this is not a working tree - so you shouldn't edit the tree, and you can commit it.
<nielsbom> garyvdm: can or can't?
<garyvdm> Sorry - can't
<nielsbom> right
<garyvdm> nielsbom: It works well if you are using bzr to vc a website.
<nielsbom> garyvdm: but what is the best practice if I want to push local code to my server using FTP? (or is there another step after using the upload plugin?)
<Peng_> No SFTP or SSH access? :X
<garyvdm> nielsbom: Just use upload.
<nielsbom> garyvdm: yes I want to VC a website
<LarstiQ> jelmer: different laptop
<nielsbom> garyvdm: sorry that I don't seem to understand but if I use the upload, it does not update the working tree right? How can I make that happen?
<LarstiQ> nielsbom: bzr-upload
<nielsbom> Ow and I might have SSH to my server, that would simplify matters, right?
<LarstiQ> jelmer: do I need a new version of rebase too?
<LarstiQ> nielsbom: yes
<jelmer> LarstiQ, yes
<LarstiQ> jelmer: this is on my Acer Aspire One, where I'd like to use an SD card, but for some reason the bootable images hang before I get to the flashing part
<garyvdm> nielsbom: Yes - if you have ssh access - then use https://launchpad.net/bzr-push-and-update
<LarstiQ> jelmer: the last commit of rebase is funny: 'Fix bug #.'
<Peng_> nielsbom: If you have SSH access and bzr is installed (or you can install it, which should be easy enough).
<Peng_> nielsbom: At the very least, SFTP > FTP, even if (with bzr) there isn't any difference.
<nielsbom> garyvdm: just checked: no SSH or SFTP
<nielsbom> garyvdm: my host is pretty cheap, so no wonder
<Peng_> Cheap isn't an excuse for that.
<LarstiQ> jelmer: could you not raise a bare ImportError in check_subversion_version()?
<nielsbom> Peng_: true...
<Peng_> Wait, I'm still paying like $7 a month for some SSHless web hosting account I haven't touched since 2006...
<nielsbom> garyvdm: but after I upload a tree to my server using FTP, how can I change that to be the working tree?
<nielsbom> Peng: $7 is quite a lot
<nielsbom> Peng_: I pay EUR 25 a year and I get quite a lot (but no SSH)
<LarstiQ> jelmer: KeyError: 'svn-v4:cd2972fe-eb09-0410-94ea-d8feb256cc61:trunk/kmx:8048'
<Peng_> nielsbom: That's on top of the $30 for non-sucky hosts I do use (mostly). :P
<garyvdm> nielsbom: You don't need to make it a working tree.
<nielsbom> Peng_: ouch, but then again, you probably make some nice $$$ or :) :) :) of off it too, right?
<Peng_> nielsbom: Certainly not. But it's fun!
<nielsbom> garyvdm: is that because the upload plugin just uploads it without the need for there being bzr on the server?
<garyvdm> nielsbom: bzr-upload will uploads the dirs/files that are the latest version in bzr to your ftp dri
<nielsbom> Peng_: if it's worth it, it's worth it
<garyvdm> nielsbom:yes
<nielsbom> garyvdm: ok now I understand, thanks
<garyvdm> https://launchpad.net/bzr-upload
<nielsbom> garyvdm: but this _can_ get problematic with multiple people committing right? Then I'd have to use classic VC right? (Check out first...)
<garyvdm> nielsbom:
<LarstiQ> nielsbom: I'd recommend seperating versioning from deployment.
<garyvdm> nielsbom: No - there is a solution for that.
<jelmer> LarstiQ, what should I do instead of raising an importerror?
<LarstiQ> jelmer: fold the warning into the importerror?
<LarstiQ> jelmer: ie, raise ImportError("Need at least subvertpy 0.6.1, got 0.6") instead of raise ImportError
<LarstiQ> jelmer: that way I can see what is wrong just by looking at the stacktrace.
<nielsbom> LarstiQ: garyvdm: So I use one testing server (with VC) and one live server to which I deploy (from test to live). Me and other developers then use the testing server to commit our changes. Is that a correct way?
<LarstiQ> nielsbom: having live and testing servers is good practice.
<LarstiQ> nielsbom: but I'd personally commit locally and deploy to testing from there, as well as deploying to live from there.
<nielsbom> LarstiQ: So code and commit locally. Deploying to test: local --> test. Deploying to live: local --> live.
<LarstiQ> nielsbom: that is what I would do, yes.
<nielsbom> LarstiQ: ok understood, thanks for your help, and garyvdm: too!
<jelmer> LarstiQ, fixed
<LarstiQ> *glomp*
<garyvdm> LarstiQ: that implies nielsbom would become a gatekeper?
<LarstiQ> garyvdm: I'd keep that workflow for everyone involved. But maybe it can be done better?
<nielsbom> garyvdm: well unless other people also have the right to upload to live right?
<garyvdm> LarstiQ: or should he have a rule that uploads must be from the central repo?
<LarstiQ> garyvdm: I'll try top rephrase
<LarstiQ> the point I find icky is versioning a 'live' (test in this case) site directly, instead of using a deployment mechanism
<nielsbom> LarstiQ: do I understand correctly that you advise against using bzr as a deployment tool (my sites aren't that critical btw)
<nielsbom> LarstiQ: (question mark)
<LarstiQ> nielsbom: not exactly. The bzr-upload plugin I find is a good deployment tool.
<LarstiQ> nielsbom: you are correct that I wouldn't have any bzr branches there.
<garyvdm> nielsbom: This is my suggestion: lets say you have a group of devs - create 2 branches that are shared, one for you testing server, one for you live server.
<LarstiQ> nielsbom: but there are multipel ways to do things, I believe garyvdm is going to tell you  about a workflow I wouldn't feel comfortable using :)
<garyvdm> Then use the bzr-upload --auto option on each of those branches.
<garyvdm> So when a dev pushes to say your test branch, bzr-upload will upload the latest version of that branch to your test server.
<garyvdm>  LarstiQ: why?
<LarstiQ> garyvdm: I'm in fullermd's camp. Our minds seem to require a more formal division between versioning and deployment.
<nielsbom> garyvdm: I think I understand :)
 * garyvdm thinks deployment control requires versions control - thats why old version control systems were called "software configuration management"
<luks> requires != is :)
<Ycros> deployment branches ftw
<jelmer> LarstiQ, still there?
<jelmer> hi abentley
<LarstiQ> jelmer: yes
<jelmer> LarstiQ, what happens if you try with the patch in http://samba.org/~jelmer/tmp/assert.diff applied?
<LarstiQ> jelmer: the assert is triggered
<jelmer> LarstiQ, can you change it to return None if has_revision() returns False ?
<LarstiQ> and then run it I assume :)
<jelmer> yup, that's the idea
<LarstiQ> jelmer: it completed
 * LarstiQ runs missing against his fresh 0.5 branched copy
<nielsbom> <3 meta VC on a VC project :-)
<LarstiQ> jelmer: hmm, now missing blows up
<jelmer> LarstiQ, how?
<LarstiQ>   File "/home/wouter/.bazaar/plugins/dev/svn/mapping3/__init__.py", line 293, in _parse_revision_id
<LarstiQ>     return (uuid, branch_path, int(srevnum), scheme)
<LarstiQ> ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade'
<LarstiQ> jelmer: which is the revision we were having trouble with
<jelmer> LarstiQ, What argument are you specifying to svn-upgrade?
<LarstiQ> jelmer: right, other operations blow up as well
<LarstiQ> jelmer: nothing
<LarstiQ> just `bzr-experiment svn-upgrade`
<jelmer> LarstiQ, what is the pull location of that branch?
<LarstiQ> jelmer: svn+ssh://source/home/wouter/tmp/kmx_svn/trunk/kmx
<jelmer> LarstiQ, so the strange thing seems to be that that revision should exist in the svn repository but it doesn't
<abentley> jelmer: Hi.
<LarstiQ> jelmer: I'm not entirely sure what you mean with that.
<LarstiQ> jelmer: obviously svn rev 8048 exists.
<jelmer> LarstiQ, and that was a round-tripped revision?
<LarstiQ> jelmer: the bzr-svn metadata, I don't know how that meshes.
<LarstiQ> jelmer: yes
<LarstiQ> jelmer: from 0.5
<jelmer> LarstiQ, ah, I think I understand what the problem is here
<LarstiQ> jelmer: and I can make fresh branches with 0.4 and 0.5 both, that is not an issue.
<LarstiQ> jelmer: ok :)
<LarstiQ> hey jdub!
<jelmer> Hi Jeff
<jdub> morning
<jdub> hey jelmer
<LarstiQ> jdub: that's a long time ago.
<LarstiQ> abentley: heya
<jdub> thanks heaps for fixaging that bug :-)
<abentley> LarstiQ: Hey.
<LarstiQ> abentley: you mentioned we should talk?
<abentley> LarstiQ: Yeah.
<jdub> jelmer: the fix has prompted me to ask for a tip though ;-)
<jelmer> jdub: Np, thanks for bringing it to my attention before I released 0.5.0
<jelmer> jdub, uhoh
<abentley> I'll be working on Nested Trees once I finish what I'm currently working on.  Maybe this week or next.
<LarstiQ> abentley: ok
<abentley> LarstiQ: I didn't realize you were working on them too.
<jdub> jelmer: i have a repo with a couple of svn bits in it (trunk, branch) and a bzr branch... now i've upgraded the svn bits, the bzr branch needs rebasing.
<jdub> jelmer: how do i do that sanely? :-)
<abentley> LarstiQ: Where are they at?
<LarstiQ> abentley: I hadn't been, but recent requests prompted me to start looking again.
<abentley> LarstiQ: Ah, okay.
<abentley> LarstiQ: There does seem to be a lot of interest.
<LarstiQ> abentley: haven't actually done much since yet, other than paging code into my head and fixing some conflicts.
<LarstiQ> abentley: well, and looking at scmproj
<jelmer> jdub: the bzr branch basically contains the svn branch with some extra bzr revisions on top?
<jdub> jelmer: yeah
<abentley> LarstiQ: Yeah, I'm going to be looking at svn externals to try and see what they did right and wrong.
<LarstiQ> abentley: cool
<jelmer> jdub, backing up that bzr directory and then running "bzr svn-upgrade <svn-repository-url>" should fix that
<jdub> ahar
<jdub> ok, will try
<jdub> ta :-)
<abentley> LarstiQ: Should we try to work together on this?
<LarstiQ> abentley: I'd like that. Whatever the case, I defer to your lead.
 * LarstiQ doesn't want to get in abentley's way
<abentley> Thanks.  It will certainly be a great help to start from your fixed-up version.
<jdub> jelmer: hrm, what should that url be?
<LarstiQ> abentley: I'll try to get a recent bzr.dev merge done this week
<jelmer> jdub, the URL of root of the subversion repository
<abentley> LarstiQ: Cool.
<jdub> jelmer: so one level above trunk?
<LarstiQ> jelmer: the repo root, or the branch root?
<jelmer> repository root
<jelmer> yeah, generally that would be one level above trunk
<jdub> eg. bzr svn-upgrade http://svn.automattic.com/wordpress/ ?
<jelmer> "svn info <some-svn-url>" will tell you the repository root
<jelmer> jdub, yep
<abentley> LarstiQ: IIRC, there are a bunch of commands that need updating to work with nested trees, and merge probably needs to be re-done.
<jdub> ok, i get sweet traceback action :-)
<LarstiQ> abentley: move is still having problems atm
<abentley> LarstiQ: Also, a new branch format with a better mechanism for specifying the locations of nested trees.
 * LarstiQ nods at abentley 
<abentley> LarstiQ: Ah, okay.
<jelmer> jdub, whoa, can you please pastebin the traceback?
<abentley> LarstiQ: I think the first priority, once we get a clean merge, is to get as much merged back into trunk as we can.
<jdub> jelmer: ah, ok
<jdub> http://pastebin.ubuntu.com/112494/
<abentley> We'll probably want to split it up into a loom, so that the patches aren't crazy-long.
<LarstiQ> abentley: that sounds good, I'll need to lookup how to work with looms.
<jdub> jelmer: oh, my rebase is up to date with trunk
<jdub> as of just before this discussion ;-)
<jelmer> jdub, Do you have the latest bzr-svn?
<abentley> LarstiQ: Looms aren't very good for collaboration at this point, so that's probably a task for one person.
<jdub> 0.5.0~rc2-1~bazaar1~intrepid
<abentley> We should quickly get back to having a branch with unmergeable changes, and then we can work on that.
<jdub> (using bzr and friends from the beta ppa)
<jelmer> jdub, you'll need the tip of http://people.samba.org/bzr/jelmer/bzr-svn/0.5, which matches the updates I made to rebase
<jdub> jelmer: can i just check that out into .bazaar/plugins as with rebase?
<jelmer> jdub, yep
<jelmer> hmm, deja vu - didn't you also run into svn-upgrade bugs at the last major release of bzr-svn?
<LarstiQ> abentley: ok
<jdub> yeah, but they were beyond fixage due to local braindamage
<jdub> so i dumped those
<jdub> oh, and this is actually a different repo (wp.org rather than wpmu)
<LarstiQ> jelmer: make a not in the bzr-svn release docs, 'ask jdub to give it a testrun'?
<LarstiQ> note, bweh
<jdub> edge case is my middle name(s)!
<abentley> LarstiQ: The next things I'll be working on are to make it possible for the nested-tree format to be our default.
<abentley> LarstiQ: So, making working trees not automatically detect nested trees, and fixing the sha1-rewriting issue.
<jdub> jelmer: oh rock! that was fixed and fast :-)
<jdub> jelmer: thanks heaps
<jelmer> jdub: np
<jelmer> LarstiQ, I also found the real issue behind your bug
<LarstiQ> abentley: this eek you mean, or after we're at a state of unmergeable changes?
<LarstiQ> jelmer: is it fixed yet? :)
<abentley> LarstiQ: I think after the unmergeable changes, but it's fluid at this point.
<LarstiQ> k
<jdub> ooh, this is interesting:
<jdub> jdub@sliver:~/src/wordpress/wpsu/masspress$ bzr unshelve 1
<jdub>  M  wp-content/plugins/vipers-video-quicktags/vipers-video-quicktags.php
<jdub> bzr: ERROR: A nested progress bar was not 'finished' correctly.
<abentley> LarstiQ: Is http://bazaar-vcs.org/NestedTreeProgress accurate?  I think we should have a wiki page listing outstanding tasks, so that we can claim them.
<LarstiQ> abentley: no, it's not accurate.
<LarstiQ> abentley: agreed on the breaking up work, claiming, and public progress report.
<LarstiQ> abentley: I don't think the page has drifted too much
<abentley> LarstiQ: Okay.  If you could polish it, that would be helpful, since you know the current status better than me.
<LarstiQ> abentley: I will need to keep paging things into my head. I'll start with updating the current devel branch location.
<jdub> jelmer: thanks again... night all!
<abentley> LarstiQ: Thanks.
<CaMason> hi guys. I'm getting "bzr_log.TAqjxu~" style files in my working copy every time I commit
<jelmer> LarstiQ, please try again with current bzr-svn
<LarstiQ> CaMason: any other warning/error? Hints in ~/.bzr.log?
<jelmer> LarstiQ, (throwing away the previous branch created with svn-upgrade)
<LarstiQ> jelmer: yeah
<LarstiQ> jelmer: still get ValueError: invalid literal for int() with base 10: '8048-svn4-upgrade'
<jelmer> LarstiQ: Is this in a completely new repository, etc?
<LarstiQ> jelmer: good catch
<LarstiQ> branching outside of that repository now
<ronny> how can i undo the last commit?
<jelmer> ronny, bzr uncommit
<ronny> thx
<LarstiQ> jelmer: svn-upgrade, completes, log doesn't give any errors, but missing blows
<Goundy> hi
<Goundy> quick & noob question (again) :P : well I've two branches @local: mainline and working
<Goundy> I work on working and then merge into mainline and then do push on mainline
<Goundy> now I want my working branch to become the main branch
<Goundy> to avoid commiting with same messages twice
<Goundy> How can I do that ? and thanks
<garyvdm> cd mainline
<garyvdm> bzr pull ../working
<garyvdm> If I understand you correctly
<Goundy> garyvdm and then I can delete mainline by rm -rf mainline right ?
<LarstiQ> ehm
<garyvdm> No - Ok - I thought you wanted to do this once off
<Goundy> garyvdm well please let me explain again (sorry I've a small experience with DVCS)
<LarstiQ> Goundy: are these two the only branches in play, or are there more?
<Goundy> that's why I'm getting hard to explain what am doing. Well I'll reexplain :P
<Goundy> LarstiQ am going to reexmplain :P
<Goundy> I've a branch on launchpad it's called: aures
<Goundy> and it's a development branch.
<Goundy> at first I did checkout on this branch to get a local copy
<Goundy> and then I did: bzr branch aures working
<Goundy> So I always work on "working" (useless yea :/)
<Goundy> and then I do: cd aures && bzr merge && bzr push
<Goundy> So I use working when coding and I use aures to push up
<Goundy> So now I want to be able to do PUSH through "working"
<Goundy> and I want to kick out aures
<garyvdm> cd working
<Goundy> (kicking local aures and not these on launchpad)
<garyvdm> bzr pull ../aures                 (to make sure that you have the latest in working)
<garyvdm> cd ..
<garyvdm> rm aures
<garyvdm> errr rm aures -r
<Goundy> yea
<Goundy> that's all ?
<garyvdm> cd working
<garyvdm> bzr push lp:aures
<garyvdm> deleting aures on you hdd won't touch whats on lp
<garyvdm> that's all
<Goundy> garyvdm doesn't work man :/
<Goundy> it recreated the branch aures when I did push >_<
<garyvdm> ok - you will need to do this the first time:
<garyvdm> bzr push lp:aures --remember
<Goundy> garyvdm rox ! thank you very much
<garyvdm> Pleasure Goundy.
<Goundy> :)
<Goundy> bazaar is really > svn
<Goundy> damn, what a powerful release >_>
<kfogel> whoa.  bzr selftest has the tests specified just by prefix, e.g.:
<kfogel> LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v test_status 2>&1 | sed -e 's/^/[ascii] /'
<kfogel> runs all the tests whose names begin with "test_status", such as test_status_nonexistent_file()
<jelmer> kfogel, I think the argument is a regex
<kfogel> jelmer: ah, that's possible too, let's see
<kfogel> LC_CTYPE= LANG=C LC_ALL= ./bzr selftest -1v 'status_.*existent' 2>&1 | sed -e 's/^/[ascii] /'
<kfogel> yup
<kfogel> that runs the same test
<kfogel> jelmer: oddly, though, it seems to run the same test twice.
<kfogel> e.g.:
<jelmer> kfogel: Is the name exactly the same ?
 * kfogel waits for test output to appear
<kfogel> jelmer: oh
<jelmer> it can be running the test against two different bzr formats
<kfogel> never mind
<jelmer> or something like that
<kfogel> two different tests
<lifeless> moin
<kfogel> [ascii] running 2 tests...
<kfogel> [ascii] ...tatus.BranchStatus.test_status_nonexistent_file   OK                 174ms
<kfogel> [ascii] ...tus.CheckoutStatus.test_status_nonexistent_file   OK                  51ms
<kfogel> [ascii] tests passed
<jelmer> hey lifeless
<kfogel> jelmer: actually, that test is only defined once, in bzrlib/tests/blackbox/test_status.py (class BranchStatus).  But that file *also* defines class CheckoutStatus(BranchStatus), and therefore the test gets run twice when requested once.  I have no idea if this is a desired result or not :-).
<jelmer> kfogel, Yeah, that would be desired
<jelmer> kfogel, you should be able to specify the full test name
<jelmer> bzrlib.tests.blackbox.test_status.BranchStatus.test_status_nonexistent_file
<jelmer> to run just that test
<kfogel> jelmer: thanks
<lifeless> kfogel: its two tests :P
<lifeless> kfogel: tests are namespaced
<lifeless> kfogel: you could do Branch.*status_none as a pattern also
<kfogel> lifeless: the idea is that bzr might behave differently in a branch vs in a checkout?
<kfogel> lifeless: IOW, write all the tests once, but run them in two different scenarios
<kfogel> (I may be using wrong terminology: I mean "bzr might behave differently in the presence/absence of a working tree" I guess)
<lifeless> kfogel: the status command looks at both the tree and the branch
<thumper> morning peoples
<lifeless> though looking at CheckoutStatus its a little superficial, some specific tests for out of date detection would not go astray
<kfogel> thumper: morning
<kfogel> lifeless: hmm, okay.  It's not blocking me or anything, I'm just trying to understand the test suite better.  I get the feeling it sort of grew by accretion.
<lifeless> :p yes we wrote tests roughly at the same time as the code
<lifeless> we've also increased support capability slightly behind when it was needed
<kfogel> Hey, anyone remember what's preferred in python these days, 'file()' or 'open()'?  http://docs.python.org/library/stdtypes.html#file-objects seems to imply that 'open()' is what the cool kids do nowadays.
<lifeless> open()
<kfogel> lifeless: thanks
<lifeless> its clearer
<paroneayea> I'm not sure I get branches in bazaar.  Are they supposed to be subdirectories, or am I doing something wrong?  Also, how do you list all branches in bazaar?
<kfogel> paroneayea: I'm not a bzr expert, but I think 'bzr branches' will show you all the branches ('bzr help commands' is what told me that).  In my way of working so far, it's common to put branches in subdirectories -- that is, one subdir for each branch -- but I'm not sure you have to do it that way.  Have you read the Users Guide?
<kfogel> Also, comparing http://bazaar-vcs.org/Scenarios/OneOffContribution with http://bazaar-vcs.org/Scenarios/RepeatedContributions might give you some idea of the relationship between branches and repositories.
<paroneayea> kfogel: yeah, I'm trying to look at the user's guide but I didn't see it describing the way subdirectories work and stuff
<paroneayea> I'm used to the git idea
<paroneayea> where you have all these branches but you only see one at a time
<lifeless> paroneayea: we are looking at changing this; the git layout seems pretty popular
<lifeless> it clicks better for enough folk
<lifeless> anyhow
<kfogel> paroneayea: you can do that in bzr too, it's not actually so different (that is, have a bunch of branches present in your repository locally, and only be viewing one at a time in the actual checked out tree, using the 'bzr switch' command).
<lifeless> yes, one directory per branch at the moment [unless you use a plugin that changes that]
<kfogel> I hope someone else here will correct me if I make any wrong assertions.
<kfogel> paroneayea: it's more a matter of bzr having a different default right now, that's all
<paroneayea> ah.  Okay, this conversation helps
<lifeless> kfogel: you do know about the brisbane-core project yes?
<paroneayea> lifeless: do you know of such a plugin?
<kfogel> lifeless: I know about it, but I think I might only know about some of the performances speedup stuff going on there.  Is it about more than that?
<lifeless> paroneayea: yes, the colocated-branch plugin jelmer put together
<lifeless> paroneayea: its not really polished, but its a usable proof of concept
<lifeless> also 'bzr-loom' does something similar (its similar to topgit)
<lifeless> [or rather topgit is similar to it :P]
<lifeless> kfogel: re bug 246891
<LarstiQ> paroneayea: a similar workflow can be achieved with `bzr cbranch` and friends from bzrtools, but some people dislike having branches be actual filesystem objects
<ubottu> Launchpad bug 246891 in bzr "bzr log -v is slow" [High,Confirmed] https://launchpad.net/bugs/246891
<kfogel> lifeless: yes, thanks -- I'd heard people mention brisbane-core.  But is it scheduled to land at a particular time?
<lifeless> kfogel: as soon as we can :P
<lifeless> kfogel: its more that there is very little we have identified as 'doable' to improve performance on tree delta operations (both -v and subdir-contents in log require that) without it landing
<kfogel> lifeless: can't come soon enough for me (and GNU Emacs :-) )
<paroneayea> well anyway, I will keep following bazaar... it has a much cleaner command set than git.  But for now it's too much of a disruption for me to have the multiple subdirectory branches in my workflow, so I think I'm sticking to git for now
<paroneayea> thanks for the help :)
<LarstiQ> paroneayea: even with switch?
<paroneayea> LarstiQ: well, maybe I should look at it some more.  But it's confusing, there's not much documentation on this workflow in bazaar.  I can't tell if it's safe to remove subdirectories and whatever
<lifeless> paroneayea: to remove a branch, rm -rf it
<paroneayea> lifeless: but that won't remove it from the database?
<LarstiQ> paroneayea: your pointer in the revision DAG is gone, but if you know the revision (tagged it, it's a head, or written it down) you can resurrect the branch
<LarstiQ> paroneayea: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout 5.5.3, but I see that should be updated
<LarstiQ> paroneayea: afaik it is possible to just use `bzr switch sibling` if the branch currently checked out is a sibling of where you want to switch to
<LarstiQ> paroneayea: (if it was a standalone branch, it would be entirely gone)
<lifeless> paroneayea: in git terms, the ref is contained in the .bzr/branch/ of each branch
<lifeless> paroneayea: so rm -rf removes the ref; the revision won't propogate anywhere
<lifeless> there is a gc plugin I think
<lifeless> paroneayea: are you concerned that old branches will take up space? or get lost? or ..
<Lo-lan-do> lifeless: Assuming I'm concerned about the space, is there already an answer?
<LarstiQ> Lo-lan-do: it depends on the situation. Standalone branches? rm -rf the branch and the space is reclaimed.
<Lo-lan-do> Nah, shared repository :-)
<LarstiQ> Lo-lan-do: shared repo? Are there other branches using the same revisions? Then there is no space lost.
<LarstiQ> Lo-lan-do: Shared repo and no branches use the revisions anymore?
<LarstiQ> ah.
<LarstiQ> Lo-lan-do: that would be the case where a `bzr gc` would make life easier.
<Lo-lan-do> My potential use case is that I pushed a branch to the wrong repo.
 * LarstiQ nods
<LarstiQ> Lo-lan-do: I'm not aware of anything that automates that much.
<LarstiQ> Lo-lan-do: making a new repo and branching over what you want to keep is a bit of a hassle.
<LarstiQ> Lo-lan-do: you're at fosdem, right?
<Lo-lan-do> It can be scripted, probably, but I see.
<Lo-lan-do> Not yet, but I intend to go, yes :-)
<LarstiQ> Lo-lan-do: it shouldn't be hard to write up an initial version of that command.
<LarstiQ> Lo-lan-do: right :p
<LarstiQ> Lo-lan-do: so if you're interested in doing that, I suggest we work on that?
<LarstiQ> Lo-lan-do: the remove-revisions plugin already does removal
<Lo-lan-do> I never hacked bzr itself; if you think that might provide a gentle first step, then I'm all in favour.
<Lo-lan-do> Then I may be able to help bzr-git :-)
<LarstiQ> Lo-lan-do: I think it should be fine.
<Lo-lan-do> Great :-)
<lifeless> so the challenge in writing 'gc' correctly is prevent concurrent insertions into the db
<lifeless> like git, bzr is multi-writer
<lifeless> git uses the refs as a way to handle gc AFAICT
<Lo-lan-do> Isn't there a repository-wide lock?
<lifeless> Lo-lan-do: insertions are done in a 2-phase operation; phase 1 prepares the insertion, phase-2 commits it
<lifeless> there is a lock for phase-2, but its short-lived, and doesn't prevent phase-1
<lifeless> so to do a gc, you need to: prepare a phase-1 operation that will insert a new pack containing the non-gc'd elements of all the packs that have things to be gc'd.
<lifeless> other writers doing a phase-2 insertion before you will succed, so in your phase 2 you need to check you are not dropping anything referred to by packs added during the gc.
<lifeless> its not terribly hard, but its plumbing not porcelain
<lifeless> (if someone has added a ref, abort the gc)
 * LarstiQ intended to be far less subtle in the first go
<lifeless> in fact, as a cheap start, you could simply abort the gc if the packs list has changed; that would be safe and correct-enough
<LarstiQ> Lo-lan-do, lifeless: I sent a mail to the list stating our intention.
<luke-jr> how do I get 'bzr merge' to do a real merge when cherrypicking?
<luke-jr> it only wants to do a diff+patch for me â¹
<Lo-lan-do> luke-jr: I don't think it's doable right now.
<luke-jr> -.-
<lifeless> luke-jr: what do you mean 'real merge'
<luke-jr> lifeless: one that 'bzr status' shows
<lifeless> cherry picks don't join the graph
<lifeless> by definition
<luke-jr> "pending merges:"
<lifeless> if you cherry pick adjacent to a merged revision, it will be treated as a normal merge
<luke-jr> what does that mean?
<luke-jr> I want to merge a bugfix from trunk..
<luke-jr> but I don't want to merge trunk's enhancements
<luke-jr> seems like a pretty common use case
<lifeless> and it should work fine
<luke-jr> no, it just modifies the working copy and doesn't note it as a merge at all
<lifeless> I think what you are missing is that 'log' doesn't show the merge revision, right?
<luke-jr> I would hope merges are more than mere log changes
<lifeless> merges do one thing with a few implications. They set the 'parent' pointer in the revision graph
<lifeless> that pointer, as it is in git and hg and pretty much everything, is a transitive pointer in a DAG
<luke-jr> â¦
<luke-jr> whatever that means
<garyvdm> lifeless: What will happen if you cherrypick a revision, and later try to merge it. Will you have a conflict, or does bzr know that it has allready been merged?
<lifeless> garyvdm: our merge code tries quite hard to make that not conflict unless you further changed it
<luke-jr> I just want it to show up as it would if I committed to the oldest valid branch and merged those upward
<lifeless> luke-jr: ok, right now you can't
<luke-jr> sigh
<luke-jr> can I get the log to look as if I did?
<lifeless> I was trying to explain, but you seem uninterested
<lifeless> I'll be back in a bit
<luke-jr> I just want it to work, I don't really care about the details as to how or why
<LarstiQ> luke-jr: you could include the log messages of the cherry picked revisions in your commit, does that help?
<luke-jr> LarstiQ: you mean manually?
<LarstiQ> something like bzr ci -m "Merge bugfix foo.\n `bzr log -r x..y`"
<luke-jr> sigh
<luke-jr> guess that works
<LarstiQ> luke-jr: what about that isn't good enough? Would you be satisfied if the commit included those log messages automatically?
<LarstiQ> luke-jr: or, and this is why I'm asking and where lifeless was going afaics, do you actually require the revision graph to be altered there?
<luke-jr> I have no clue wtf the reivison graph is
<LarstiQ> luke-jr: ok. Could you then either explain what it is you want, or listen to an explanation of how things work?
<garyvdm> Pending merges indicated that the revisions graph is going to have extra stuff....
<luke-jr> LarstiQ: I just want it to work as if I had made my changes in 0.1 and merged that into 0.2 and trunk
<LarstiQ> luke-jr: the problem is, "as if I had made my changes" has lot of implications, most of them probably not relevant to you
<LarstiQ> luke-jr: making it work that way requires a lot more effort, and hence will be finished on a larger timeframe
<LarstiQ> luke-jr: knowing which parts you care about make it easier to do something about it.
<davidstrauss> luke-jr: This is a highly dangerous approach to version control systems: "I just want it to work, I don't really care about the details as to how or why"
<davidstrauss> luke-jr: It's like getting on the road without knowing traffic rules and only caring about "getting there."
<garyvdm> "An SCM tool is not like a clock.  Clock users have no need to know how a clock works inside.  We just want to know what time it is.  Those who understand the inner workings of a clock cannot tell time any more skillfully than the rest of us.
<garyvdm> An SCM tool is more like a car.  Lots of people do use cars without knowing how they work.  However, people who really understand cars tend to get better performance out of them." - Eric Sink
<LarstiQ> both not actually the thing at hand imo.
<davidstrauss> LarstiQ: My point is that the question he's asking may not serve his long-term interests.
<LarstiQ> without eloborating it is impossible for me to tell what luke-jr wants, not knowing requirements makes writing software hard.
<LarstiQ> davidstrauss: good point
 * LarstiQ needs to go to sleep
<LarstiQ> night
<davidstrauss> LarstiQ: night
<garyvdm> night LarstiQ
<davidstrauss> lifeless: ping
<lifeless> davidstrauss: hi
<davidstrauss> lifeless: would you like the bzr.log from our beloved windows committed?
<davidstrauss> committer*
<lifeless> davidstrauss: uhm, remind me of the situation, I'm embarrased but its paged out
<davidstrauss> lifeless: This is the smart server repo corruption we discussed last week
<lifeless> oh yes
<lifeless> the content-from-unmerged-rev one
<lifeless> yes that log is a good starting point
<lifeless> did we open a bug ?
<davidstrauss> lifeless: how should i get it to you?
<davidstrauss> lifeless: i don't think so
<lifeless> either email me, robert@canonical.com
<davidstrauss> lifeless: i think it would be wise to open a formal bug report
<lifeless> or if we can open a bug, even a private one if there is other stuff in the log, and attach it there
<davidstrauss> lifeless: nothing to hide here
<davidstrauss> lifeless: this is all Drupal GPL development
<lifeless> then a bug would be best
<lifeless> as it lets other devs chime in
<davidstrauss> lifeless: posting it now
<lifeless> thanks
<davidstrauss> lifeless: https://bugs.launchpad.net/bzr/+bug/324100
<ubottu> Launchpad bug 324100 in bzr "Content from unmerged revision breaks branch" [Undecided,New]
<davidstrauss> I wish launchpad would assume the bugs I post "affect me too"
<mwhudson> you could make the bug about that as affecting you i guess :)
<mwhudson> s/make/mark/, sigh
<davidstrauss> It would be awesome to have a Firefox plugin to browse bzr repositories when I click a bzr:// link.
<lifeless> doesn't bzr-gtk install a bzr:// handler?
<davidstrauss> It might, but I'm on OS X.
 * garyvdm adds that to qbzr todo
<lifeless> ah
<davidstrauss> I have an Ubuntu VM open, so I can certainly try it.
<davidstrauss> How can I get a Bazaar sticker for my laptop?
<lifeless> thats a good idea
<lifeless> I don't htink we have them at the moment
<davidstrauss> Or maybe a very covertly technical bumper sticker?
<bob2> "my other car's a version control system"
<davidstrauss> bob2: Insurance would be cheaper if accidents had "uncommit"
<lifeless> oh nice
<bob2> hah, that's close to NRMA's current campaign
<lifeless> spiv: http://launchpadlibrarian.net/21885424/bzr.log if you're interested
 * spiv looks
<lifeless> 3.7MB
<lifeless> davidstrauss: do you remember, I think it was rev 521 broke it ?
<davidstrauss> lifeless: yes
<davidstrauss> lifeless: that ought to go into the but
<davidstrauss> bug*
<lifeless> done
<davidstrauss> lifeless: thanks
<lifeless> beuno: is verterok around?
<lifeless> spiv: I see update, status, info, commit-on-bound-branch
<lifeless> but the update appears to be a no-op, checking further
<lifeless> jelmer: would you consider making 4587.877  Unable to open <bzrlib.transport.local.LocalTransport url=file:///C:/Program%20Files/xampp/htdocs/drupal_test_7_fic/modules/field/field.form.inc/> with Subversion: Unable to open an ra_local session to URL
<lifeless> jelmer: be only shown with -Dtransport?
<lifeless> davidstrauss: can you get the user, to cd to C:/Program%20Files/xampp/htdocs/drupal_test_7_fic/
<lifeless> davidstrauss: and run
<davidstrauss> lifeless: his repo has been overwritten with the fixed upstream one
<lifeless> davidstrauss: damn, did he keep a backup?
<lifeless> or did he overwrite using 'pull' ?
<davidstrauss> lifeless: i'm guessing he ran "update" from my fixed repository
<davidstrauss> lifeless: and that probably wiped out the troublesome revisions
<lifeless> no they will be there
<lifeless> so, 'bzr cat-revision bzr@web3fourkitchens.com-20081206090158-z4ejks27ylqpj0py'
<lifeless> this is assuming he did update/pull
<lifeless> as long as he didn't rm the thing, they will be candidates for gc, but not actually removed
<lifeless> davidstrauss: AFAICT there is no reason for his tree to have magically grown references to that revid
<lifeless> davidstrauss: he hasn't run merge, in the timespan of the log
<davidstrauss> lifeless: I'll ask him to run it.
<lifeless> he has run update, but that will be grabbing from the master branch - he has a checkout, rather than a seperate branch
<davidstrauss> lifeless: Actually, I'll ask him for a zip file of his working copy, including .bzr stuff.
<lifeless> davidstrauss: good idea
<davidstrauss> lifeless: Email is perhaps the highest latency remote shell in the world.
<beuno> lifeless, hi!  I don't see him on any of the normal channels of communication  (plus, I'm in Brazil)
<lifeless> beuno: trying to track down a nasty commit bug; I want to ryle out the xmlcommit etc commands
<lifeless> davidstrauss: except on windows, where you can send them a script to run, and it will just run it :)
<davidstrauss> lifeless: yes, but i can just copy his checkout to a windows VM I have
<davidstrauss> lifeless: oh, just got the joke
<beuno> lifeless, I haven't looked at the code since he did the rpc thingie. I'll poke him if I see him around. Is there a bug #?
<lifeless> davidstrauss: :P
<lifeless> 324100
<lifeless> beuno: ^
 * beuno looks
<spiv> lifeless: I don't see any obvious red flags in that log file.
<lifeless> spiv: indeed
<sproaty> whenever I use push and it asks for my password, I have to press "deny" first before it'll accept it
<sproaty> I'm typing the same password 4 times, nothing - press deny then it'll work :/
<lifeless> sproaty: what url do you push to ?
<sproaty>  sftp://sproaty@bazaar.launchpad.net/~sproaty/whyteboard/development/
<lifeless> e.g. sftp/ftp/bzr+ssh/lp/ ?
<spiv> sproaty: do you use some sort of SSH key agent?
<lifeless> sproaty: ok, bzr itself doesn't manage passwords for tht
<lifeless> sproaty: so its your OS/ssh client
<sproaty> ah
<spiv> Also, bazaar.launchpad.net's SSH/SFTP server doesn't ever accept passwords.
<sproaty> well I used ssh to get some key to upload to launchpad
<sproaty> so it's probably asking for key verification?
<spiv> (And says so at the SSH protocol level)
<davidstrauss> sproaty: It's probably your SSH key agent implementation.
<davidstrauss> sproaty: actually
<spiv> So if it's asking for your LP password, then your SSH client is buggy.  Or maybe it's asking for a passphrase to unlock your private key, but it doesn't sound like it.
<davidstrauss> sproaty: It's probably your SSH client making a crappy attempt to get a password instead of trying your key first.
<davidstrauss> sproaty: Some broken SSH clients assume you'll always need to submit a password.
<sproaty> OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
<lifeless> sproaty: what is the exact question it asks you
<lifeless> sproaty: the title of the window, everything
<sproaty> erm I dunno, I closed them...should I push again to see?
<sproaty> well actually, don't want to commit a change with no changes
<fullermd> Just trying to push (even when there's nothing to push) will make it try to connect.
<davidstrauss> sproaty: your only other option is to leave us guessing
<fullermd> Or pull, or missing.  Doesn't much matter; it just needs to get as far as doing the SSH connection.
<davidstrauss> sproaty: And I doubt this is a problem with your core OpenSSH implementation. It's likely a problem with some GUI wrapper.
<sproaty> it seems to have saved the password for a while.
<lifeless> sproaty: next time it comes up, grab a screen shot
<sproaty> gotcha
<lifeless> sproaty: then cut the dialog out of it and you can show it to us :)
<sproaty> It did seem different to ubuntu's root password prompt thingy
<davidstrauss> sproaty: as it should be
<sproaty> :)
<sproaty> I'm not sure what SSH client I have.
<lifeless> theres a keychain thing in gnome these days
<lifeless> I don't like it :P
<sproaty> I may have installed one the other day
<kfogel> I'm writing blackbox tests for some new status output, and noticed that assertStatus() and assertEqual() helpers (used in bzrlib/tests/blackbox/test_status.py) assume that status lines will be printed in a certain order.  That is, even though bzr could often choose any order for path statuses to be printed, it seems as though the tests assume the order will always be the same.  Anyone know if that's on purpose, or just an accident of how bzr i
<kfogel> s written?
<lifeless> sproaty: its there by default
<lifeless> kfogel: assertEqual is deliberate
<lifeless> I don't recall about assertStatus
<lifeless> status doesn't do most things in arbitrary order though
<kfogel> lifeless: assertStatus() is just a wrapper around assertEqual
<lifeless> kfogel: could you expand on what you are doin
<kfogel> lifeless: finishing issue #306394
 * kfogel waits for the bot
<kfogel> okay
<kfogel> bug #306394
<ubottu> Launchpad bug 306394 in bzr "bzr status should not ignore all other command line arguments when passed a non-existent file" [Undecided,Confirmed] https://launchpad.net/bugs/306394
<kfogel> lifeless: see Ian's mail, referred to from a comment at the end of that bug
<kfogel> lifeless: larger context: this is one of the bugs that was an annoyance for GNU Emacs; it's the least important of the bugs tagged with "emacs-adoption", but it's the one I can fix... and I hate to start something and not finish it :-).
<lifeless> fair enough
<lifeless> so why does emacs ask about unversioned files
<mlh_> a bit OT but do any DVCs support having the repo on one disk and the checkout/tree on another?
<spiv> Oh man.  This is like the mailing list thread all over again ;)
<lifeless> mlh_: bzr does
<mlh_> oh nice
<lifeless> spiv: the risk of going on leave is that you miss things
<mlh_> I thought'd have to hack it with ln -s /some/mirrored/disk/.bzr /some/fast/disk/.bzr
<spiv> lifeless: :)
<lifeless> spiv: right now there is at least one patch I'm really unhappy with in bzr; I'm feeling motivated to prevent more
<kfogel> lifeless: I'm not sure.  I prefer the new, non-aborting behavior anyway, so if it makes some Emacs VC maintainers happy too, then great.
<spiv> lifeless: FWIW the thread started on Dec 23, and has "306394" in the subject, and was ~35 messages.
<lifeless> spiv: so the import thing
<kfogel> lifeless: oh, were you referring to this patch above ("...motivated to prevent more")
<lifeless> kfogel: indeed
<lifeless> kfogel: not saying its wrong, saying I have motivation to examine
<lifeless> this is probably unhealthy
<kfogel> lifeless: sure, understood
<lifeless> cause mesh gatekeeping doesn't scale
<spiv> lifeless: IIRC, Aaron was pretty skeptical about accomodating this behaviour (on the basis that emacs should just "bzr st" the whole tree?), but Martin thought it was reasonable.  Hopefully I'm not misrepresenting the thread too badly...
<lifeless> I'm with Aaron
<kfogel> however, it  might be better (for the future) if re-exams would happen before the implementor does the work... :-)  (I.e., we had a discussion about it, rough consensus seemed to be that more of us want it than don't want it)
<lifeless> whole tree status is much faster that status-per-file or status-per-dir
<kfogel> spiv: I think Aaron's reasons had nothing to do with Emacs (as they shouldn't).
<kfogel> I was arguing for the new behavior on the basis that it's better anyway, and I think those who agreed agreed on that basis.
<lifeless> and in fact, status-per-dir is much faster than 'status-of-these-files-that-happen-to-be-all-in-the-same-dir'
<spiv> kfogel: s/emacs/programs invoking bzr/ :)
<kfogel> Aaron was arguing that it's worse, also independently of programs invoking bzr.
<lifeless> kfogel: yes, and provisionally, I agree.
<kfogel> lifeless: can you expand?
<kfogel> (you mean you agree with Aaron, right?)
<lifeless> kfogel: yes.
<lifeless> kfogel: listing a path is an explicit request from the user that it's status be obtained
<kfogel> lifeless: sure, we all agree on that
<lifeless> you can argue then, that 'absent and never versioned' is simply the status of a named-missing-and-never-versioned-path
<kfogel> lifeless: some people just think that "nonexistent" is a legit status, right
<lifeless> but you can also argue that its likely a typo
<kfogel> lifeless: in which case, instead of aborting the whole rest of their status, we can just print out the paths at the end with "nonexistent:" or "X"
<lifeless> kfogel: we should still exit with error though
<lifeless> kfogel: because status != 2 implies commit-is-safe
<lifeless> kfogel: unpacking a little, 'status X not erroring implies commit X will not error either'
<kfogel> lifeless: hmmm.  Is that true/important?  Do people or programs really behave that way?
<lifeless> with the caveat on partial-commits-of-merges being a technical limitation we want to get rid of, not a ui goal
<kfogel> lifeless: *nod*
<lifeless> well, the more special cases, the harder the system is to learn, it becomes more modal and less inferrable
<lifeless> currently there is a very strong mapping between what makes status error and what makes commit error
<spiv> lifeless: https://lists.ubuntu.com/archives/bazaar/2008q4/051045.html is Martin's thoughts in that thread on exit status, btw
<lifeless> spiv: yes, precisely
<kfogel> lifeless, spiv: so you think error code 2 or 3?
<lifeless> kfogel: 3 probably
<kfogel> lifeless: (when you said "status != 2" earlier, I assumed you meant "status != 0"...)
<kfogel> oh
<kfogel> lifeless: nm
<lifeless> 0 is no-change, 1 is changes, 2 is unrepresentable changes, 3 is error
<kfogel> 0 is nothing changed, 1 is something changed, 2 warnings, 3 err
<kfogel> right
<lifeless> I'm fine with status doing additional work, but I do believe that status absent-unversioned file should be an error
<lifeless> you can render that however you like
<kfogel> lifeless: ret code 3 sounds reasonable to me
<lifeless> but, and I suspect that this is in the thread somewhere, it should still look like an error to the user
<lifeless> kfogel: why do you say status outputs in arbitrary order/
<kfogel> lifeless: if we use the current (in my branch) output, plus ret code 3, then we have: "non-existent is represented as just another status, but still returns error to retain the mapping with 'bzr commit' "
<kfogel> lifeless: not arbitrary, just the same every time
<lifeless> kfogel: you were expressing surprise or something
<kfogel> lifeless: sort of.  I was expressing surprise more that the test suite actually tests this behavior (for example, it could expect certain status lines in the output, but expect them in any old order... instead, it expects them in exactly a certain order).
<kfogel> lifeless: well, also surprise at the actual order
<kfogel> lifeless: for example:
<kfogel> If I do 'bzr status --short FILE_B FILE_C' and they're both modified, they'll get printed in that order.  But take off the --short, and they show up in the reverse order.
<lifeless> kfogel: are those the exact file names?
<kfogel> lifeless: well, the answer to that is complicated.
<kfogel> Yes, in my tests (but my test has more changed than that).
<kfogel> No, in the manual test I ran just now using README and INSTALL in the bzr top level.
<kfogel> so try this: make trivial changes to README and INSTALL.  Then do 'bzr status README INSTALL', then do 'bzr status --short README INSTALL'.
<lifeless> kfogel: --short is a little odd there IMO
<lifeless> but I never use it so shrug :P
<lifeless> normal status is alpha output per dir
<kfogel> lifeless: I've run into a bunch of idiosyncracies like that.  I'm not sure the effort of detailing them all is important, but they surprised me.
<lifeless> kfogel: well, you could alter --short to be alpha sorted rather than iterating the list it was given
<kfogel> lifeless: I could, but ... opportunity cost.  There are bigger fish to fry; even #306394 is a bit questionable in that regard, although it's so close that might as well just finish it.
<lifeless> sure
<kfogel> no one *really* cares about status output order, in real life :-)
<mlh_> lifeless: what's that feature called - standalone trees?
#bzr 2010-02-01
<RyNy_> How do I connect from my local machine via ssh with a key to my remote server?
<igc> hi all
<lifeless> hi igc
<igc> hi lifeless
<igc> lifeless: back in Oz?
<lifeless> nope
<lifeless> platform sprint in portland
<spundun> hi all
<spundun> I'm on mac snow leopard and I tried to install bazaar
<spundun> through the .pkg file
<spundun> but I can't find anything installed
<spundun> what files am I looking for?
<spundun> I can't find anything called qbzr
<spundun> the file I downloaded is Bazaar-2.0.4-1-desktop.pkg
<RyNy_> I got it to work on 10.5.8. I'd do a google search. i came across support for 10.6 somewhere recently
<spundun> RyNy_: I got the 10.6 binary from here: http://wiki.bazaar.canonical.com/MacOSXDownloads I thought it'd work
<spundun> 10.6 seems to be officially supported by bazaar, from what I gathered from the link above.
<spundun> I think the problem is with their packaging.
<spundun> maybe the install script is failing somehow
<RyNy_> spundun: I've really been strugging with bzr on my mac here. I got shell integration and after much struggle got the GUI, Explorer to work. But I can't figure out how to ssh to my server with a private key. I just found out that there is a plugin for Eclipse IDE
<RyNy_> Have to say their documentation is really lacking
<spundun> I'm trying to install the macports version in parallel
<spundun> which one did you get working?
<RyNy_> For the GUI I got Explorer working
<RyNy_> I posted this help doc: https://answers.launchpad.net/bzr/+question/99421
<spundun> thanks, I'll lok at it.
<spundun> gtg now.
 * igc out for a bit - bbl
<yojimbo-san> In a pre_commit hook, how can I determine the absolute filename of an item from tree_delta?
 * igc dinner
<Kamping_Kaiser> bugger, bzr-builddeb contains cia commands
<Kamping_Kaiser> no, my checkout isprobably broken
<Kamping_Kaiser> no, my checkouts brokeen
<Kamping_Kaiser> pebkac as usual :)
<jelmer> lifeless: is bazaar's pqm using the NEWS conflict resolver yet?
<quicksilver> doh. my subscription attempt expired
<quicksilver> apparently you're not allowed to wait two weeks before cliking the link
<asabil> hi all
<asabil> is there any hook for when the working tree is updated ?
<asabil> to be able to fix this bus: https://bugs.launchpad.net/bzr-externals/+bug/485494
<ubottu> Ubuntu bug 485494 in bzr-externals "bzr-externals does not do the right thing for lightweight checkouts" [Undecided,Won't fix]
<maxb> asabil: `bzr hooks`
<maxb> Which, uh, crashes for me. Nice.
<asabil> same here
<LeoNerd> Me too
<LeoNerd> bzr: ERROR: exceptions.AttributeError: 'InfoHooks' object has no attribute '_callable_names'
<asabil> same error
<maxb> ah well, `bzr --no-plugins hooks`
 * maxb plays hunt the evil plugin
<asabil> maxb, yep, and there is not hook for when the tree is updated
<maxb> !blame bzr-svn
<jelmer> maxb: It's a bug in bzr
<jelmer> maxb: it just happens to only be activated when there's more than one hook loaded
<maxb> oh. yuck :-)
<napster> If there are more than one developer, how the source code is managed? I'm new to bzr too...
<maxb> napster: Try this document for an introduction to some of the possible ways to work: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/bazaar_workflows.html
<napster> maxb, just got it from #launchpad... tnx anyway... ;)
<keithhub> i've got a bzr checkout of trunk from a svn repo -- if i make a commit on the bzr branch, should i be able to see the subversion revision assigned?
<radoe> If I have a branch of a svn repo by the help of bzr-svn, is there any way to have tags in this bzr branch and push commits back to the svn repo? I have no need to push the tags back, the can be bzr-only.
<jelmer> radoe: bzr branch will automatically pick up the tags if you use the standard trunk/branches/tags layout in svn
<jelmer> radoe: and bzr-svn supports pushing back into svn
<radoe> jelmer: maybe I misinterpreted this error message: bzr: ERROR: Tags not supported by SvnBranch('file:///home/ralf/SVNREPO/bzr-test'); you may be able to use bzr upgrade.
<jelmer> radoe: in that situation, bzr-svn doesn't know where to push tags to
<jelmer> radoe: you need to tell it the layout of the svn repo before you can push
<RyNy_> Anyone know how to connect using ssh and a private key to a server?
<mzz> RyNy_: on what os? on linux bzr should end up just invoking ssh, so if that is configured to do so, so will bzr
<mzz> RyNy_: configuring an alias in ~/.ssh/config for the host and options you need may be necessary, I think
<lifeless> jelmer: no
<lifeless> jelmer: 2.1.0 isn't released yet:P
<RyNy_> mzz: sorry, I meant to say in the GUI Explorer. I currently have an alias ~/.ssh/config. I'm on OS X
<RyNy_> I did install paramiko too
<mzz> RyNy_: sorry, I know virtually nothing about mac
<radoe> jelmer: may I request your help than? For tests I start with an empty svn repo with standard tags/trunk/branches layout, see http://pastebin.ca/1774416 what I did exactly...
<radoe> jelmer: I created a bzr repo with svn-import, tagged trunk and simply tried to push it back.
<jelmer> radoe, that looks correct
<jelmer> radoe, the push command you mentioned earlier didn't push to /trunk though
<radoe> jelmer: Yes, the earlier one was a different test, after your hints I created a svn test repo in tags/trunk/branches layout and tried again.
<radoe> jelmer: ahh, I see. The tag in fact *gets* pushed back to to svn, even "bzr push" does emit a message "No new revisions to push.". After this message at first I thout nothing has happened during the push...
<radoe> jelmer: sorry for the confusion with two different tests. And after the "No new revisions to push" message in my second test I simply did not expect that anything had happened...
<jelmer> yeah, bzr's UI probably should mention the number of changed tags or something like that
<radoe> jelmer: exactly.
<RyNy_> mzz: no worries. Anyone have any experience with Bazaar Explorere?
<DaffyDuck_`> How do I get an old revision of a file?
<DaffyDuck_`> Ah, "cat".
<yjmbo> In a pre_commit plugin, how do I get the full pathname of a file from tree_delta?
<jelmer> yjmbo: I think you can feed it to the abspath() method on the working tree that you have
<james_w> wasn't there a "bzr-land" plugin that did a merge and put the parents the other way round to normal?
<james_w> I would like to make use of it
<lifeless> mthaddon: https://lpstats.canonical.com/graphs/LaunchpadOpenBugs/ is showing zero for the lp code bugs
<lifeless> mthaddon: I suspect it doesn't refer to 'launchpad-code' instead using the old launchpad-bazaar or something
<maxb> james_w: I thought it was conjectured, not written?
<james_w> maxb: that may be right, thanks
<jelmer> vila: hey
<jelmer> vila: The merge proposal you just put up has a conflict in NEWS
<lifeless> james_w: wed morning or afternoon ?
<jelmer> vila: oh, and it's set to Rejected now - ignore me :-)
<vila> jelmer: how ironic :D
<jelmer> vila: :-)
<james_w> lifeless: morning suits me fine
<lifeless> james_w: scheduled in for me
<james_w> thanks
<mattl> hey... is there a way i can have every checkin send an email to a list?
<mattl> without configuring something on the client
<rubbs> mattl: try this under change notification: http://wiki.bazaar.canonical.com/BzrPlugins
<mattl> rubbs: is that something each developer would need to install though?
<rubbs> mattl: you could create a smart server that has something like that installed, if you need something with a little more beef you could try PQM (in the section right below change notification)
<rubbs> mattl: also look at this for your "server" http://doc.bazaar.canonical.com/test/en/admin-guide/hooks-plugins.html
<mattl> i have a site that checks out the trunk every 5 mins... i wonder if i could just add something to that
<rubbs> mattl: it shouldn't be too hard to use hooks for that then. I'll dig up the link
<devmod> Hello
<mattl> rubbs: thanks.
<mattl> devmod: hey
<rubbs> mattl: http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/hooks-help.html?highlight=hooks
<rubbs> devmod: hello
<devmod> I was reading the bzr user guide, and I am not sure I understand "Backing up task branches", where do u exactly back this up?
<rubbs> devmod: can you send a link to the page that you are talking about?
<devmod> rubbs, http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/organizing_branches.html
<devmod> last paragraph
<devmod> basically, i want to be able to keep  a copy of my task branches somewhere (to access it from my laptop maybe? to sync between dev machines, and as a backup)
<rubbs> I'm not entirely sure of the best way, but you could create a different location for your task branches in a central location and bind to them.
<lifeless> mattl: you can install bzr-email on the server
<rubbs> I'm not sure if anyone else here has a better idea.
<lifeless> mattl: and as long as you use bzr+ssh it will Just Work
<devmod> maybe im just too svn minded
<devmod> everyone doesnt mind having only local copies of in-progress fixes ?
<rubbs> devmod: if I have a long term branch. I'll push it to a central location( like LP) and keep it there under it's own branch
<rubbs> but to be honest, my workflow is such that my fix branches are very short lived (a few commits at most)
<devmod> yeah that is what i was thinking as well
<devmod> not sure how bazaar would apply to new projects in which tasks are going to be considerably longer
<rubbs> I'd just push those up to the back-able location in a seperate directory.
<rubbs> keep them in a similar location, but ultimately separate
<devmod> and then when u want to go back to the original repo , u just merge back ?
<rubbs> yep
<rubbs> so for example:
<devmod> (new to bzr in general, so exact cmds escape me atm)
<rubbs> you have a shared repo that contains trunk.
<rubbs> next to trunk is task1 and task2
<rubbs> when you are done with task2, you go into main and do a "bzr merge task2"
<rubbs> and that will merge all your changes from task2 into trunk/main
<rubbs> (sorry used two different names there but meant trunk the whole time)
<devmod> yes
<rubbs> (instead of main)
<rubbs> is that what you mean?
<devmod> and to create then? starting from trunk?
<devmod> (im confused about the "unbind" part)
<rubbs> yeah, so to start you would (from just outside of the trunk dir) "bzr branch trunk task3"
<rubbs> well, with this workflow, you can more or less forget the bind
<rubbs> you just have to push and pull to your local...
<devmod> ohh ok
<rubbs> is this making sense at all?
<devmod> i believe so
<devmod> it almost feels liek it wasnt intended to work that way
<rubbs> bzr is really fexible by design. There isn't a whole lot that it wasn't intended for.
<devmod> and when i merge the branch back into the trunk, will the trunk now contain all log info from the branch as well?
<rubbs> As long as you stick true to using bzr as only a history tracker, and not a content delivery system, then you pretty much are using it as designed ;)
<rubbs> yes,
<rubbs> this is the beauty of bzr (and hg and git too)
<rubbs> you keep ALL your history
<devmod> i see
<rubbs> if you want to see what that looks like you can run a log command on the bzr branch on lp.
<rubbs> so if you have qlog installed (default on windows and apt-get install qbzr on Ubuntu) you can run "bzr qlog lp:bzr"
<rubbs> that will open a gui window and show you what a typical log looks like for a merged branch workflow similar to what we are talking about
<devmod> i see
<rubbs> if you give me a few minutes I can whip up a short tutorial on how to work it for you...
<rubbs> on the workflow we discussed, and then we can tweak it to fit your needs
<devmod> i was just wondering what workflow fit our approach the best
<devmod> we used to use svn
<devmod> so i have this concept of making branches for my own dev which are backed up somewhere
<rubbs> so you need some sort of central place (backup and collaberation) and you want to be able to use local commits, but have the option to back them up too, right?
<devmod> right
<rubbs> ok, cool. give me about 5 minutes, I'll whip up something, and you can review it. Then we can see if we can tweak it to make it best for you and your needs. does that work?
<devmod> absolutely thanks
<rubbs> np... brb
<bjp> hey, is there a workaround for this bug: https://bugs.launchpad.net/loggerhead/+bug/447229/
<ubottu> Ubuntu bug 447229 in loggerhead "Checking out branches from a shared repo results in 'No repository present' error" [Medium,Triaged]
<Peng> bjp: Well, you could use "bzr branch nosmart+http://whatever"
<rubbs> devmod: http://pastebin.com/m3000dec2
<rubbs> not very pretty but you should be able to figure it out.
<Peng> bjp: I thought that had been fixed, and I can't reproduce it with Loggerhead's trunk.
<devmod> rubbs, thanks!
<rubbs> np
<Peng> bjp: Have you experienced the bug yourself? Can you try upgrading to Loggerhead's trunk (lp:loggerhead)?
<bjp> Peng: nosmart+http gives me another No repository present error
<bjp> yes i'm working on getting around the bug right now
<bjp> I haven't tried using the trunk, can i run serve-branches from the branch directory w/out installing it?
<Peng> bjp: bjp Yes.
<bjp> new error: "An attempt to access a url outside the server jail was made"
 * Peng dies.
<bjp> wait let me try something
<mwhudson> bjp: what version of bzr are you running?
<mwhudson> that sounds like a no-fixed bug in bzr
<bjp> 2.0.4
<mwhudson> hmm
<Peng> bjp: What's the path of your repository, and what's the path you're having Loggerhead serve?
<bjp> i just tried serving the root of the shared repository /opt/repository
<rubbs> devmod: I'll brb, so if you have questions for me, go ahead and ask, but it may be a minute or two before I respond. Just FYI.
<lifeless> mthaddon: Chex: are either of you on duty atm ?
<devmod> rubbs, sure np thanks again
<lifeless> we need the review team for  https://code.edge.launchpad.net/~bzr-pqm/bzr/2.1 set to bzr-core please
<rubbs> devmod: back fyi
<lifeless> elmo: https://code.edge.launchpad.net/~bzr-pqm/bzr/2.1
<bjp> i also tried using loggerhead as a plugin with 'bzr serve --http' but got this bug: https://bugs.launchpad.net/loggerhead/+bug/492614
<ubottu> Ubuntu bug 492614 in loggerhead "bzr serve --http cannot find module loggerhead.util" [Undecided,New]
<lifeless> elmo: set the 'review team' to ~bzr-core please
<elmo> lifeless: done
<lifeless> sweet, thanks
<yjmbo> Can someone give me a bit of pre_commit plugin help? I am passing tree_delta path names to an external command, but I need absolute pathnames; where do I find the correct prefix?
<mkanat> yjmbo: I think it's in branch._transport.base.
<mkanat> yjmbo: If you want the branch path.
<yjmbo> yep, that sounds plausible ... let me try it ...
<yjmbo> mkanat: ok, as a complete newbie to bzr plugins, how do I get that value? "print branch._transport.base" gives "'module' object has no attribute '_transport'"; I cargo-culted "branch.Branch._transport.base" by looking at the hook registration, but I get "type object 'Branch' has no attribute '_transport'" ... I know I'm missing a large chunk of assumed knowledge, but what is it? :-)
<bjp> Peng: are you able to get it to function correctly with a shared repository?
<mkanat> yjmbo: params.branch
<mkanat> yjmbo: That's the branch object.
<Peng> bjp: Yes.
<mkanat> yjmbo: It might be params.branch.repository._transport.base. I don't recall off the top of my head.
<mkanat> yjmbo: Also, I think that the assumed knowledge is the bzrlib API docs.
<bjp> Peng: i posted a comment on that bug, how is your setup different?
<yjmbo> :-) I've tried for a while, that's a lot of docs with very few examples! However, I'll try some more until I get it. I looked at a load of plugins, but even the ones that seem to be doing the same task as me are far more complex, and doing things in a far different manner ...
<Peng> bjp: The fix for that jail bug landed in bzr 2.1.
<Peng> bjp: (It's bug #348308, FYI.)
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Fix released] https://launchpad.net/bugs/348308
<mwhudson> Peng: oh, that's sucky
<Peng> mwhudson: What?
<mwhudson> i guess at least 2.1 is nearly out
<mwhudson> Peng: that the jail bug isn't fixed in the 2.0 branch
<Peng> MaAh.
<Peng> Ah.*
<Peng> Mann, I don't want to be dealing with these bugs anymore. I'd even forgotten most of that bug number!
<Peng> (It's not because of that, but I'm going AFK.)
<devmod> rubbs, that was pretty clear :) One last thing, to update my task branch I merge the trunk into it ?
<rubbs> devmod: yes and no. If you need to get something from trunk, then yes, you merge the trunk into it, but because you merge branches you don't need to update your working tree the same way you do when you work with SVN.
<rubbs> when you merge, it merges your changes into the trunk... even if the trunk is further ahead than you are
<rubbs> if there are conflicts it will tell you and then you resolve them... very similarly if you were using SVN
<devmod> ohh i see
<rubbs> so, merging the trunk in to update is usually unnecessary
<rubbs> hopefully that makes sense
<bjp> shewt, that means i needs 2.1
<bjp> and there prolly aren't any .deb packages of it yet
<rubbs> http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu there is a 2.1 ppa
<maxb> There is a PPA which is supposed to contain 2.1 but does not, you mean :-/
<rubbs> oh, I didn't know.
<rubbs> maybe the nightly one?
<rubbs> seems like that would be risky though
<maxb> I'd imagine that ought to be 2.2 by now
<bjp> heh yea, i'm running this on my server box
<bjp> i don't update it a lot, but bzr is one of it's main functions, so i'm not sure if the daily ppa would be a good idea or not
<rubbs> seems weird that the beta ppa doesn't have 2.1... since it's in beta. Is someone working on that?
<maxb> I made noises that I might, if I get some time
<maxb> No one said they were working on it
<rubbs> damn
 * maxb afks
<bjp> the topic says 2.1rc is gold ><
<asabil> hi all
<asabil> what is actually missing to add support for nested trees ?
<lifeless> asabil: engineering time
<lifeless> asabil: probably several weeks at a minimum of a practiced dev
<asabil> lifeless, I see
<lifeless> the actual specifics of what hasn't been imlementedI don't recall offhand
<mathrick> hiya, I was just branching trying the famous Emacs repo, and it is indeed very resource-intensive, even on 2.0.3, which is already supposed to be much better
<mathrick> so how come it hits over 500M resident mem with mostly linear history? Does bzr need to keep the whole tree in memory when branching?
<lifeless> mathrick: do you have the C extensions?
<mathrick> most probably, any particular package I should look for?
<lifeless> python -c 'import bzrlib._dirstate_helpers_pyx'
<mathrick> no errors, so yes I guess
<mathrick> lifeless: so, is it supposed to take less with C extensions?
<lifeless> much less
<lifeless> unfortunately jam isn't online at the moment, he has been doing the most memory use analysis
<lifeless> linear history doesn't really matter either way; its likely just the size of the data set in use: we write indices at the end of the process.
<mathrick> lifeless: aha, so no hope for, umm, just pulling things and dumping them to disk?
<lifeless> oh we do for the bulk of data
<lifeless> but the indices are written at the end
<mathrick> I see
<lifeless> we're reducing memory use release by release though
<lifeless> you might try 2.0.4
<mathrick> I know, previously it was known as the pull that would kill your machine without fail :)
<mathrick> so 2.0.x are already better in that it works and fits in some 550M and generally finishes in a reasonable time
<lifeless> poolie: are you up ?
#bzr 2010-02-02
<mkanat> poolie: http://twitter.com/mkanat/status/8520484742
<lifeless> mkanat: thanks, I've reweeted :P
<mkanat> lifeless: Yay. :-)
<mathrick> oh nice
<mathrick> how big is the repo?
<mkanat> mathrick: Oh, um, about 7000 revisions on trunk.
<mkanat> http://bzr.mozilla.org/
<mathrick> aha, that's pretty modest
<mkanat> Yeah, not enormous.
<lifeless> its not how big it is :P
<mkanat> lol
<igc> morning
<bjp> bzr support https?
<Kilroo> Can you be more specific?
<bjp> i was trying to find a bug report i saw earlier
<bjp> it was throwing an error because I am using a self-signed certificate for an internal https server
<bjp> https://bugs.launchpad.net/bzr/+bug/82086
<bjp> that one
<ubottu> Ubuntu bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged]
<bjp> it's marked as fixed released a long time ago
<bjp> oh it was changed
<dcoles> G'day
<dcoles> I was wondering if anyone could offer some advice for storing file modification times along with file contents in bazaar.
<lifeless> dcoles: perhaps some context on why?
<lifeless> if it is for e.g. make, then 2.1 will do better for you
<dcoles> Sure. I'm trying to use bazaar as a way to track modifications on a website using wget --mirror. I'm mainly interested in the Last-Modified header which gets stored in the mtime of the file.
<lifeless> AfC: you pung
<lifeless> dcoles: so, the closest you could get would be to script bzr via the python api to do one commit per timestamp you see, of only the modified fiels with that timestamp (using a fuzz factor to group changes)
<lifeless> AfC: sms me.
<lifeless> -> food
<AfC> lifeless: I think I was looking to see if you were coming into Sydney for Beer last Friday. I've subsequently gathered you're out of town
<dcoles> Hmm... I guess that's one option. Would I be able to add it as metadata to the file, say, just before commiting the changes?
<Kilroo> I never metadata I didn't like.
<dcoles> Kilroo: Something similar to `svn propset` would likely suit my purposes, but I don't think I've seen a way to access it via the bzr command.
<dcoles> Might just be easier to generate a 'last-modified' file and track the changes in that instead.
<Kilroo> If you don't want it any more granular than that, couldn't you just look at when you committed?
<dcoles> Well I really wanted to know the server side 'last-modified' of the html files rather than when I mirrored the file. If it turns out to be too hard I guess I'll just run the mirror script each day and have to be satisified with just a 'day' resolution.
<Kilroo> What I meant was, if you only get as specific as when that one file was last modified, then you're only going to get one modified time per commit. If you aren't committing shortly after making changes I suppose it could be significant to know when that one file was changed instead of when you committed, but I didn't think of that at first.
<dcoles> Oh. I see what you mean.
<james_w> ('need at least bzr 2.1.0rc2 (you use %r)', (2, 2, 0, 'dev', 1))
<james_w> that seems wrong to me?
<dcoles> Kilroo: wget with --mirror sets the file timestamps to what ever the server says for 'last modified', so there could potentially be a few different modification times
<Kilroo> But not for the one file you were going by.
<Kilroo> Or did you mean make a file and record the last-modified times for everything else IN it as text?
<dcoles> Yes.
<Kilroo> Gotcha. That makes me wonder two things.
<dcoles> `ls -l` or something a little less hackity
<Kilroo> First, does wget output the last modified times as it processes the files.
<Kilroo> ...and that was my second suggestion.
<Kilroo> Heh. I actually have been working on setting up something at work to let me use a combination of rsync and bzr to pretend that the stuff we still have on plain ftp is version controlled. Modified times hadn't even occurred to me.
<Kilroo> The experience has, however, convinced me that all our log files should be kept above the web document root to make version control easier, instead of just for all the other reasons I'd already had.
<dcoles> Kilroo: Alas no. I'd pondered just dumping stdout, but it only mentions if a file is 'newer' or 'not modified'
<dcoles> It'd be really easy if it was on a local machine, but it's a small external website we need to keep tabs on.
<dcoles> While the original intent was for me to check by hand, sounds like a great thing to have automated.
<dcoles> Anyway. Thanks for the advice. Given me a few more ideas to play with. :)
<Kilroo> I'd probably go with putting the modtimes into a text file after every sync and versioning that, if you can't find a convenient way to set custom metadata in bzr. And submit a ticket suggesting that the ability to track that be added, although I think typically in a version controlled environment most people are going to care more about the commits.
<RyNy_> what's the best practice for registering a project with Launchpad? I have a Drupal site that I want to user vc with but it is large ~2gb.
<lifeless> RyNy_: what do you mean by 'best practice'
<RyNy_> I think I figured it out. I was wondering how much of the drupal install I should I send to LaunchPad. I suppose only the files that I change.
<lifeless> well if you are making a branch of drupal, surely you'd upload it to the drual namespace :)
<mathrick> why does the beta PPA have any versions newer than 2.0.1?
<mathrick> *doesn't
<RyNy_> no, my changes have to do with personal configuration changes: new modules, or server configurations
<RyNy_> does anyone have workflow tips for managing a LAMP server with bazaar
<RyNy_> Do I create a branch for the whole server?
<bob2> what are you planning to put in bzr?
<RyNy_> I've never used a vc before. I like the idea but am wondering how much of the server should go in vc
<bob2> depends what you're doing
<RyNy_> Do I initialize the whole server?
<bob2> you don't put / in bzr
<RyNy_> just what I'm working on?
<bob2> the source code for your app might be in version control, and etckeeper is great for /etc
<bob2> er, the source code for your app should always be in version control, but you might not deploy to servers using version control
<RyNy_> I'm changing some of the config files in LAMP and then my cms
<bob2> "LAMP"'s pretty vague
<bob2> but putting the config files under version control (if they're not in /etc already) is a good idea
<vila> hi all
<vila> mathrick: lack of man power or automation, take your pick :-/
<mathrick> vila: well, possibly, but it goes directly against what the links from the Download page tell you (it explicitly lists 2.1.0bX)
<vila> mathrick: I'm pretty sure there is a thread about re-thinking the whole experience there on the mailing list
<mathrick> aha
<vila> mathrick: '[rfc] focus on Ubuntu updates rather than PPA packaging'
<vila> mathrick: the underlying problem is about being able to put a working set of bzr + plugins there without running into broken PPAs where one plugin breaks with a new bzr version
<vila> mathrick: your input and use case could only help the debate, so please reply there
<mathrick> vila: unfortunately that's not possible today and I don't know if I'll manage to squeeze it into the upcoming days :\
<vila> mathrick: then rest assure that the problem is known
<vila> s/assured/
<mathrick> mhm, thanks
<vila> mathrick: just for the record, are you using the beta PPA ?
<mathrick> vila: I have it added to sources, but that doesn't do much, because the Karmic debs are newer
<vila> mathrick: I see. But what are you interested in exactly: getting newer stable versions or something even newer ?
<mathrick> vila: trying out 2.1.0rcs, because I wanted to see how that performs on the Emacs repo, which hits 550MB resident mem in 2.0.3
<mathrick> so yes, I want something even newer
<vila> mathrick: hmm. But bzr.dev and building the extensions from source is not attractive to you I presume... OS ?
<mathrick> Ubuntu
<vila> plugins ?
<mathrick> vila: it's not because I've done it in the past, and it's a pain to keep track of things yourself. With .debs I can just push a button and go do something else
<vila> mathrick: I know what you mean.... I have >10 setups maintained here but most of them can do with stable releases
<vila> mathrick: so, there is little for you *today* but as we approach 2.1.0final, there should be a way
<mathrick> yeah, that can wait
<vila> little == bzr.dev
<mathrick> anyway, thanks, I need to go do something else now
<vila> mathrick: more precisely lp:bzr/2.1
<vila> mathrick: you're welcome, enjoy your day :D
<mgedmin> um, I can't seem to figure out how to resurrect a file removed in revision 74
<mgedmin> actually just the equivalent of 'svn up -r SOMEOLDREVNO' would suffice
<mgedmin> bzr cat -r 73 path > path kinda works
<maxb> I'd be tempted to try merge
<asabil> mgedmin, bzr revert -r 74 file ?
<mgedmin> tried it, got an error (path not versioned or some such)
<mgedmin> ended up doing bzr cat ; bzr add
<mgedmin> so now it's kinda difficult to test "correct" solutions
<henninge> Hi, I may be missing something obvious but I cannot find documentation on bzrlib. Got a clue for me? ;-)
<asabil> mgedmin, that's weird, it works here
<mgedmin> actually I tried bzr revert -r 74 subdir/file1 subdir/file2
<Peng> henninge: The source code is well-documented, and there's probably some starter info in the developer docs. There's also an API site somewhere, but I assume it's just generated docs.
<beuno> henninge, http://doc.bazaar.canonical.com/bzr.dev/en/
<Peng> D:
<Peng> Err, :D *
<mgedmin> yeah, it should've worked, according to bzr help revert
<asabil> mgedmin, both file1 and file2 are deleted ?
<asabil> also is subdir versionned ?
<mgedmin> rev 74 deleted a whole bunch of files, two of them by mistake
<mgedmin> the subdir still exists and has files
<asabil> try to revert each on separately ?
<mgedmin> ah, I just realized I could've got a sort of an equivalent of "svn up -r 73" by doing bzr branch -r 73 ...
<henninge> beuno: Thanks. I've been there and that's all about using "bzr" from the command line. But in pyhton scripts I want to import from bzrlib. I think I'll just browse the code like Peng suggested. ;)
<mgedmin> well, thanks anyway
<Peng> henninge: bzrlib/builtins.py is a good place to start, since it's where commands are implemented.
<Peng> henninge: So, if you're trying to automate a command or something, you can just steal the code. :D
<quotemstr> bzr is crashing with an internal error referencing "Unknown kind 'relocated'"
<ronny> quotemstr: what bzr revision, what are you doing
<quotemstr> I have a branch at emacs/c++1x and I'm trying to merge from emacs/trunk.
<quotemstr> So with CWD in emacs/c++1x, I run 'bzr merge', and get the above error.
<quotemstr> It's bzr 2.0.3.
<quotemstr> What actually happened was that I ran 'merge' once, got a bunch of conflicts, then ran 'bzr revert .'.
<quotemstr> Then when I tried to merge again, I started getting that error.
<quotemstr> And now it's just pegging the CPU meter, spinning while checking 'bzr check'.
<Peng> Yeah..."bzr check" will not be fast on emacs.
<bialix> henninge: http://wiki.bazaar.canonical.com/Integrating_with_Bazaar
<bialix> henninge: http://starship.python.net/crew/mwh/bzrlibapi/
<bialix> hth
<maxb> That's a useful wiki page. I think I might add a mention of enable_default_logging and ui_factory, unless anyone knows they are covered elsewhere?
<ovnicraft> hi folks, i get peding merges how i can commit them?
<rubbs> ovnicraft: so you've done the merge, and you just want to commit?
<ovnicraft> yes
<ovnicraft> when i try to commit, tell me bzr: ERROR: Selected-file commit of merges is not supported yet:
<ovnicraft> yet: myfile
<rubbs> oh, you can't do a commit of just one file after a merge. just do a commit without any files listed. so like this "bzr commit -m "merged in things""
<ovnicraft> and i get warning conflict tag: tagfromproject, is posible solve that?
<rubbs> mmm... I'm not sure how to resolve a tag conflict.
<rubbs> maybe someone else here can help
<Peng> bzr pull --overwrite probably will (along with the other, potentially more dangerous things it does).
<devmod> morning
<devmod> Could anyone clarify what does it mean for a repo to have or not have a working tree?
<Peng> Repos don't have or not have working trees. Branches do, though.
<Peng> Well, that is, repos never have working trees.
<devmod> sorry branches*
<Peng> devmod: A working tree is, ehh, uh, when it creates copies for all of your files so you can edit them and commit and whatever/
<Peng> devmod: Sometimes you don't need one -- e.g. a central branch on a server
<devmod> i guess I understand what they are, just not sure when am I supposed to have them
<luks> when you need to 'work' with the branch
<luks> as in, edit files and commit changes
<luks> you don't need to have a working tree when you are using the branch only as a revision storage
<devmod> ohh ok got it
<devmod> This is possible because Bazaar supports (and recommends) creating repositories with no working trees (--no-trees).
<devmod> that gave me the idea that repo have or not working trees
<Peng> That just controls the default setting for branches created in that repo.
<devmod> but Peng says they never do
<devmod> ok got it
<Peng> BTW, you can create or remove a working tree with "bzr co" and "bzr remove-tree".
<Peng> There is no command to change the repo's default, but you can touch/rm .bzr/repository/no-working-trees.
<devmod> ok thanks its clear now
<luks> I think you can do it with bzr reconfigure, but I never know how to use that command
<Peng> Maybe.
<Peng> I've been using bzr longer than reconfigure has existed, and I haven't learned it well. :P
<luks> I think that's not the problem :)
<luks> I've managed to learn new commands
<luks> but reconfigure is ... "special" :)
<Peng> Indeed.
<bjp> does bzr use urllib for http and pycurl for https?
<bjp> by default
<muffinresearch> Given that format 2a doesn't support subtrees what's the most current subtree compatible format? From "bzr help other-formats" it looks like development-subtree is the one, is that correct?
<MvG> Hi! bzr push over sftp is causing me trouble: http://dpaste.com/153770/
<MvG> First push seems to have hit some kind of timeout somewhere. Now it looks as if things were in some form of inconsistent state. How can I recover from this, short of deleting and reinitializing the repo?
 * MvG has to go AFK for a while, but would really love to read some advice when coming back.
<lifeless> muffinresearch: there are not any stable subtree formats
<lifeless> MvG: check using e.g. lftp whether the pack its trying to rename already exists in the packs directory
<lifeless> MvG: if it does, please file a bug - we should handle this case, and if you use bzr dump-btree repo/.bzr/repository/pack-names we can check if the new pack is actually referenced or not
<muffinresearch> lifeless: Are there likely to be in the future for nested trees?
<lifeless> once its finished, yes.
<muffinresearch> lifeless: ok, so if I want to experiment I can use development-subtree assuming I use bzr.dev?
<lifeless> sure
<lifeless> just understand we aren't making a strong commitment to whatever data you put in it at the moment ;)
<muffinresearch> lifeless: ok np!
<jelmer> kfogel, do you know if savannah is going to run the bzr smart server at some point?
<kfogel> jelmer: I'm sure they will at some point.  How soon that point is is anyone's guess.  They're actively looking for a volunteer to help them maintain bazaar on Savannah.  I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high.
<kfogel> jelmer: but, you know, if you've got a lot of spare time on your hands...
 * kfogel ducks
<jelmer> kfogel: :-)
<kfogel> jelmer: I'm only half kidding.  You'd be much more competent at it than I would be.  But if it's to be on Canonical time (which IMHO would be appropriate) then should obviously be discussed w/ manager.
<poolie> hello kfogel, jelmer
<jelmer> 'evening Martin
<kfogel> poolie: hey :-).  You know GNU is looking for a volunteer to help maintain Bazaar on savannah?
<kfogel> poolie: from backscroll:
<kfogel> <kfogel> jelmer: I'm sure they will at some point.  How soon that point is is anyone's guess.  They're actively looking for a volunteer to help them maintain bazaar on Savannah.  I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high.
<BasicOSX> I've read the info at Bug#302987 and Bug#437626 and I'm still not sure what is holding up a 2.0.2 backport to hardy. I've got some time to volunteer would that help move 2.0.2 into hardy? :-)
<MvG> lifeless: Now have an sftp connection. The 4c52ee0586adc8546ec9d26e89e64abc.pack it mentions does exist. Will now try the dump-btree...
<MvG> lifeless: bzr: ERROR: pack-names is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<MvG> lifeless: For compatibility reasons that's an 1.6 format repo. Maybe that's responsible in some way?
<MvG> lifeless: Got the pack-names by hand, and it seems that the pack in question isn't mentioned in the index.
<MvG> lifeless: I'd now go ahead file a bug report...
<lifeless> MvG: please do
<MvG> lifeless: I guess before I do I'll give current bzr.dev a go...
<gerard_> hey
<lifeless> MvG: no need, I can tel you its not fixed ;)
<MvG> lifeless: thx. bzr.dev is giving me a hard time just now, for reasons unknown...
<MvG> "bzr: ERROR: No module named testtools" in response to "bzr push".
<gerard_> hey
<jelmer> MvG: bzr.dev now depends on the testtools package
<jelmer> although I think it shouldn't need it for "bzr push" ...
<MvG> yippieh!
<jelmer> lifeless: is testtools required for more than just the testsuite ?
<lifeless> no
<lifeless> but I bet its a buggy plugin
<MvG> Want a bug report for that as well?
<lifeless> that is loading its tests on normal calls
<jelmer> MvG: please, with a backtrace
<MvG> bzr --no-plugins push was in fact the first I tried.
<lifeless> MvG: try bzr push --no-plugins
<lifeless> MvG: oh, ugh. please yes file a bug
<MvG> as I know bzr-svn complains about a version mismatch on a regular basis when used with the non-system bzr setup.
<MvG> How do I get the backtrace for this?
<lifeless> -Derror
<gerard_> anyone who exactly knows how WorkingTree.update works?
<lifeless> yes
<gerard_> I think I fixed the double merge problem now
<gerard_> but I don
<gerard_> 't exactly know how it works now
<gerard_> :p
<MvG> lifeless: thx. It's at http://dpaste.com/153798/ but will go into the bug report as well, once I manage to get that far.
<gerard_> it passes all selftests but I'm not sure that's enough
<jelmer> gerard_: how do you avoid the two merges?
<gerard_> jelmer: I don't, just do them in an order that will prevent the commits with itself
<gerard_> I just swapped the order the merges are performed around
<gerard_> and stop if there are any conflicts after the first merge
<gerard_> hmm, lets try that first sentence again
<lifeless> gerard_: why not just stop if the first merge conflicts?
<jelmer> gerard_: So you update the working tree to the local branch first
<gerard_> it stops when the first merge conflicts
<gerard_> jelmer: exactly
<MvG> What's the suggested way to give large numbers of people access to a smart server? Is there some setup that does so with a single system account, using ssh pubkeys to differentiate users with different permissions, the way some git servers work?
<gerard_> now what? do I push it to launchpad and add a merge request?
<gerard_> I guess it might be a good starting point for someone who actually knows what is going on
<gerard_> any need for cleaning up the commit messages? I guess there may be some in dutch still
<gerard_> lifeless: when you don't swap the order of merges around you have trouble rerunning the update command
<gerard_> as it is not clear anymore that the branch you wanted to update from was out of date
<gerard_> at least, that's what I guess was one of the problems I has
<gerard_> had
<gerard_> also, it was quite illogical to first see the conflicts with the master
<lifeless> hmm, I was sure it did local branch first
<lifeless> anyhow, local first, then stop if conflicts sounds fine to me.
<gerard_> anyway, I have only a faint idea of what's going on and why, but I added some tests for the double merge, and it passes those and the rest of the selftests
<gerard_> if something is still wrong it is also a bug in the tests ;)
<gerard_> I'll try to push to launchpad now ;)
<gerard_> ok, it's at lp:~gerard-/bzr/update
<gerard_> note that this is unrefined ;)
<gerard_> not ment for actually merging in
<gerard_> whoops, let me check it again... it failed a test
<MvG> lifeless: first issue reported as https://bugs.launchpad.net/bzr/+bug/516179
<ubottu> Ubuntu bug 516179 in bzr "bzr push confused by existing pack file" [Undecided,New]
<gerard_> ok, fixed
<gerard_> lifeless: would be great if you could take a look at it
<gerard_> and maybe explain why I sometimes need basis and sometimes the lca for the second merge...
<MvG> lifeless: And the other is https://bugs.launchpad.net/bzr/+bug/516183
<ubottu> Ubuntu bug 516183 in bzr "sftp transport module requires testtools" [Undecided,New]
<mkanat> mwhudson: ping. I wanted to talk a bit about removing the revision graph cache whenever you have a sec.
<gerard_> brb, fixing a flat tire
<jelmer> gerard_: uhm, you are hacking on bazaar while driving a car??
<mwhudson> mkanat: hi
<mkanat> mwhudson: Hey. :-)
<mkanat> mwhudson: Are you around for a bit?
<mwhudson> mkanat: i'm just starting work, so yeah :-)
<mkanat> mwhudson: Okay, cool.
<mkanat> mwhudson: So I've started to look into the possibility of removing the revision graph cache. I checked out bzr-historycache, and so on.
<mkanat> mwhudson: So, as I recall, loggerhead used to have a disk cache, but doesn't use it anymore (at least, not with serve-branches). Was there a reason we stopped using the disk cache?
<mwhudson> mkanat: no, it does
<mwhudson> it doesn't cache the revision objects themselves any more
<mwhudson> because bzr got so much faster that stopped making sense
<mkanat> Ahh, okay.
<mkanat> mwhudson: Right, there's basically no reason for us to cache anything other than the revno -> revid mapping, right?
<mkanat> mwhudson: Because if we have that for a whole tree, we theoretically don't even need the actual graph for most of the pages.
<mkanat> mwhudson: Because we could just numerically sort the revnos.
<mwhudson> it still caches files-changed info and the revno graph to disk
<mkanat> Oh, right, files changed.
<mwhudson> (quite possibly caching files-changed info with 2a branches isn't needed)
<mwhudson> mkanat: well, revno -> revid and revid -> revno
<mwhudson> mkanat: and a few other things, tbh
<mkanat> Ah, yeah, both ways.
<mwhudson> mkanat: look in history.py, the uses aren't hard to find
 * mkanat nods.
<mwhudson> mkanat: in particular i have no idea what get_merge_point_list is trying to do :-)
<lifeless> MvG: thanks
<mkanat> It seems like a lot of what we want to do really should be in bzr or in some plugin.
<mkanat> Though I can understand some cases where it's more appropriate for it to be in loggerhead.
<mkanat> mwhudson: I wonder if some of this is a holdover from hgweb.
<mkanat> mwhudson: BTW, have there been any more hangs with codebrowse? And is it actually still leaking memory?
<mwhudson> mkanat: it might well be hgweb hangover, yes
<mkanat> mwhudson: I think what I'll do is just try to remove the revision cache and then do some profiling, and see which of the slow code paths are actually necessary..
<mwhudson> mkanat: seems reasonable
<lifeless> mkanat: excellent
<lifeless> mkanat: its been on the 'would be nice' for some time
<mwhudson> mkanat: it does seem the loggerhead is hanging much less now, so that's good news
<mkanat> mwhudson: Cool. I haven't seen another hang reported in the log since the 19th.
<mkanat> I mean, in the bug.
<mwhudson> nothing in the incident log either
<mkanat> mwhudson: Cool.
<mkanat> mwhudson: What about the memory usage? I couldn't really reproduce a leak after about 10 hours of trying, the other day.
<mwhudson> it's using 1.2 gigs, which is a lot i guess but not crazy
<mkanat> Hmm. That does seem like a lot, though.
<mkanat> On my system it only uses about 300m.
<mkanat> I could make it grow to 1.5GB briefly (annotate a huge file) but it would shrink again.
<mkanat> mwhudson: That's 1.2B RSS?
<mkanat> *GB
<mwhudson> mkanat: yeah, 1.5 gig VIRT
<mkanat> Okay.
<mkanat> I'd be interested to know if that's growing or if it's just huge on launchpad for some reason.
<mwhudson> mkanat: i bet your loggerhead doesn't have 200k potential branches to look at :-)
<mkanat> mwhudson: Yeah, that's probably a lot of it.
<mkanat> mwhudson: The most I tested with was 50 branches.
<mkanat> Okay, I'm off to lunch.
<mkanat> BBIAB.
 * gerard_ is back
<devmod> Peng, coming back to my question if I had a workflow "repo - (trunk , branches - (fix2blah, fix3blah))" Would I want to have trees or not?
<rubbs> devmod: on your server, if you don't actaully do the work on it, wouldn't need trees.
<rubbs> when you branch from them to your local machine, it would auto matically create the trees for you
<rubbs> automatically*
<devmod> ohhh i get it now.. i thought it talked about how the repo behaved in general
<luks> it does
<rubbs> no it doesnt
<devmod> i mean it doesnt apply to users
<luks> the server repo is different from the local one
<rubbs> right, a server repo is usually created with the "--no-trees" option
<rubbs> but your local branches are really copies of that repo
<rubbs> but with trees
<devmod> got it
<rubbs> so when I branch from lp:bzr I get a working tree of bzr, but the server doesn't have a working tree. just the repo's history
<rubbs> cool
<luks> (for some workflows you might want to have non-tree branches also locally, but that's probably too confusing for now :))
<devmod> so on this doc, http://doc.bazaar.canonical.com/bzr.2.0/downloads/pdf-en/bzr-en-tutorial-centralized.pdf, when they talk about optimization do they refer to no-trees or trees
<devmod> "As an optimization, it is possible for related branches to combine their storage needs so
<devmod> that you do not need to copy around all of this history information whenever you create a new branch."
<luks> no
<devmod> % bzr init-repo --trees ~
<luks> it means that they share the same repository
<luks> which means that it will be stored only once if the branches have common history
<devmod> ok which has nothing to do with trees
<luks> correct
<luks> as Peng said, you can very easily remove or re-create the tree
<devmod> thanks
<devmod> yes
<luks> with bzr remove-tree and bzr checkout .
<luks> so you don't need to worry about that too much
<devmod> are there any advantages having a dedicated server vs using ssh?
<rubbs> yes
<luks> most people are using bzr+ssh
<luks> so ssh with bzr remotelly installed (as a command line app)
<rubbs> so, it doesn't have to dedicated (in that it's the only thing running) but using bzr+ssh will cause less network round trips
<rubbs> it's "smarter" so it will cause faster checkouts/branches
<devmod> i see
<devmod> i was also reading http://wiki.bazaar.canonical.com/SharedRepositoryLayouts?highlight=%28repo%29|%28shared%29#nested-style-project-branch-sub-branch
<devmod> in which they recommended having a separated repo for each project instead of a single repo containing all projects
<devmod> can u elaborate on why is that?
<rubbs> well, there is a few reasons
<rubbs> one, is just organizational, if you have a project, having a separate dir is just easier to "conseptualize" but this is the least important reason...
<rubbs> the big reason is that when you create a shared repo, all the history and meta data is stored in the shared repo.
<rubbs> this means that if you have two different (unrelated) projects sharing a repo, you get lots of inter-mixed data in the shared repo
<rubbs> this makes that repo ineffiecient
<rubbs> The more "similar" the contents of that repo is the more efficient (space and speed) it will be
<rubbs> so that means you can keep all your task branches and stuff in the same repo, but if you have a project for your web stuff, and you have a project for client stuff with totally different histories and directions of development, its best to keep those seperatied
<rubbs> separated*
<devmod> ohh i see ok makes sense
<rubbs> but if you have a project that as sub projects that share a lot in common, then you can keep them under the same repo (ie. Core web site and sister sites that share a lot of code)
<lifeless> it doesn't really make a lot of difference for most things
<rubbs> true.
<rubbs> just the more divergent your projects get under the same repo, the bigger that repo becomes.
<lifeless> same as two repos :P
<rubbs> I had a problem when I commited some history of an unrelated project in a shared repo, and then tossed out that project
<rubbs> my repo is still that much bigger, but I can't delete it because my other (good) history is still intermixed
<lifeless> you could implement the gc command for us ;)
<rubbs> gc?
<lifeless> garbage collect
<rubbs> ah,
<devmod> haha
<rubbs> I'm not much of a developer
<rubbs> I mostly write the docs... although I haven't contributed too much lately
 * rubbs looks down in shame
<devmod> so as the repo increase in size, the slower it will get u say?
<rubbs> well. yes and no
<rubbs> most operations would be fine, especially if you still have a local copy.
<rubbs> when you have a local copy, a pull would only have to pull the difference rather than the whole ting
<rubbs> thin*
<rubbs> thing* BAH
<rubbs> but things like bzr log will eventually take longer... as your repo grows. This is aproblem with all VCS's though
<rubbs> I'm not intimately aware of everything that is affected by large repos in the performance area. But things that have to go through the whole history and meta data will take longer when there are more things to go through.
<lifeless> rubbs: things that walk history won't be affected, only things that scan entire indices
<rubbs> ah, I stand corrected. Thank you
<lifeless> we get about a log200 scaling factor in our indices
<devmod> ohh ok great
<lifeless> so you need to increase the size by about 200 times to add another IO to index lookps.
<devmod> random question.. how do u pronounce bazaar ?
<devmod> nevermind
<rubbs> http://www.merriam-webster.com/dictionary/BAZAAR
<rubbs> oh, damn
 * mkanat is back.
<mkanat> mwhudson: So it's at 1.2GB, and it's been up for like, weeks now? I'd say that means there's no memory leak.
<mwhudson> mkanat: process has been running since the 30th
<mkanat> mwhudson: Oh.
<mwhudson> mkanat: certainly, i don't think it's a serious problem
<mwhudson> mkanat: it gets restarted every so often by logrotate
<mkanat> Ahh.
<lifeless> it got restarted when it shat itself last week
<lifeless> with the race condition in bzrlib
<mkanat> lifeless: Oh, is that what's hard-hanging it? Or was it just a crash?
<mwhudson> that was a 500 on every page
<mwhudson> (ish)
<mkanat> Oh, okay.
<lifeless> mkanat: https://launchpad.net/bugs/514090
<ubottu> Ubuntu bug 514090 in launchpad-code "KeyError in lru_cache when loggerhead is heavily loaded" [High,In progress]
<mkanat> lifeless: Ohh, yes, I've seen that.
<RenatoSilva> bzr commit --fixes=lp:123 --causes=lp:456, has anyone ever thought about that? :P
<Peng> Heh. Does anybody want credit for that? :D
<mkanat> And if you know in advance, frequently enough to need the feature, that you're causing a regression, then maybe you should take a different tack on development.... :-D
<RenatoSilva> maybe ubuntu would use --causes a lot :D
<RAOF> RenatoSilva: Even we tend not to upload things we know are broken :P
<Kamping_Kaiser> blink. nested merge conflicts? gnarly.
<EdWyse_Office> I don't suppose there's an option to limit the bandwidth usage is there? People are getting annoyed with me for filling the pipe while pulling a humongous repo.
<bob2> you could use the 'trickle' command
<EdWyse_Office> I'd never run across that one before. Thanks!
<EdWyse_Office> The last time I even cared to do this was back on dialup. :D
<Kamping_Kaiser> http://paste.debian.net/58496/ can someone suggest a solution to this conflicts situation? (bzr resolve says no conflicts to rsolve, but status lists 3 files)
<dvheumen> Hi ... I think I found a bug, but to confirm I'd like an answer to the following question: Are negative revision numbers allowed?
<mzz> I think I saw those used somewhere.
<mzz> but I'm hoping I was wrong.
<Kilroo> If I'm not mistaken, in most of the commands where you can specify revision numbers, a negative number means count backward from the current revision.
<dvheumen> yeah, that's right, now that you mention it, I knew that specific use case. I'm now talking about negative revision numbers in the log :P
<mwhudson> dvheumen: if that happens, reconcile will fix it
<mwhudson> (we don't know why the branch sometimes gets into this state)
<Kilroo> That I don't know about. I've been studying dvcs a lot but have had so little chance to use it that I haven't looked at a log yet.
<dvheumen> mwhudson, Is there some sort of a bug report about that? because the funny thing is ... I only get negative numbers if I don't expand the merge revisions with -n0
<mwhudson> dvheumen: i don't know
<mwhudson> dvheumen: yeah, that bit's expected
<mwhudson> for boring reasons that users shouldn't have to care about
<dvheumen> you said it's something with reconcile, I'll search for that
<mwhudson> dvheumen: reconcile will fix the branch
<dvheumen> tnx, didn't know that command :)
<idnar> you used to be able to cause a negative revision number by committing a merge as the first revision in a branch; but I think that doesn't happen anymore
<mwhudson> (it's a very simple corruption of the branch metadata)
<mzz> I vaguely recall bzr-builddeb's import-dsc using them.
 * mzz wanders off to check
<dvheumen> idnar, that's exactly what happened with 2.0.4
<mwhudson> idnar: ah yes, that rings a bell
<Kilroo> I should study the How Stuff Works more than I have
<idnar> I had a branch like that on Launchpad once upon a time, and nothing worked right :P
<idnar> dvheumen: I guess it's not fixed, then
<mzz> hmm, I don't see it now.
<dvheumen> idnar, apparently :P I'm trying to find the corresponding bug report now
<Kilroo> I had this kinda screwy idea the other day.
<Kilroo> It occurred to me to wonder whether one could write a bzr plugin that would store a content hash similar (but not really exactly analogous) to a git revision ID as metadata, and whether there would be any advantages to doing it.
<Kilroo> The answers I came up with for myself at the time were "maybe" and "probably not" respectively.
<dvheumen> Kilroo, sounds like some real deep thought :P
<Kilroo> Yeah, well, it was 2am and I was falling asleep.
<dvheumen> okay, there is a bug report on this issue, I've subscribed to it, so this makes it this tiny little bit more important :)
<dvheumen> Kilroo, well, aren't all the best ideas late at night?
<Kilroo> Sometimes. Unfortunately it's often difficult to think about them then.'
<Kilroo> At least for me.
<dvheumen> I'm trying to think of an advantage for your idea ... I haven't found one ... but then again, I'm not at all familiar with git, I just know the basic ideas.
<EdWyse_Office> It might be nice for lp or redmine so they could show the whole tree on a --no-trees repo
<EdWyse_Office> maybe?
<Kilroo> Well, I don't -think- it would help with tracking code moving from one file to another, but I thought it might theoretically be possible to get some of the advantages of some of git's operations that are fast because all they have to do is compare hashes.
<Kilroo> I couldn't think of anything that seemed like a convenient way to get that benefit though.
<Kilroo> I do think I've determined that the reason bzr can't branch from two of our subversion repos at work has to do with a single file, not the entire revision, though
<Kilroo> haven't determined which file, but I kinda got a clue when I couldn't put my local mirror of one of the servers that's still just on ftp into bzr because of a 16GB log file.
<Kilroo> Then I spent a few minutes being afraid of the 16GB log file.
#bzr 2010-02-03
<mkanat> What are "ghosts"?
<mkanat> Oh, revisions that don't actually exist in the repository but are listed as parent revids for a revision?
 * mkanat doesn't exactly understand how that's possible.
<Peng> Me neither. It sounds scary.
<mkanat> I'm not quite sure that's what they are--I was just trying to figure it out from the loggerhead code.
<Peng> That's what they are, AFAIK.
<Peng> Well, I don't know why you specifically said "but are listed as parent revids for a revision".
<Peng> I have no idea how you get ghosts -- most of them are probably remnants from the early days of bzr, and perhaps conversions.
<Peng> I really don't know any more about ghosts than you do, but you're definitely on the right track, at least. :P
<mkanat> Hahahaha, okay. :-)
<mkanat> Peng: Well, here's what loggerhead does to strip ghosts from a graph:
<mkanat> evision_graph[key] = tuple(parent for parent in parents if parent
<mkanat>             in revision_graph
<mkanat> (But of course, that first var is "revision_graph", not "evision_graph".)
<Peng> Hm, good point.
 * Peng shrugs
<mkanat> In bzrlib, is there a straightforward way to ask "what's the mainline revision that this merged revision belongs to" no matter how deep a merge it is?
<Peng> IIRC there's not.
<Peng> I'm dumb, so someone could easily prove me wrong, but don't be too hopeful.
<mkanat> Okay. But theoretically...I could just take the first part of the tuple, no?
<mkanat> (the dotted_revno tuple, that is.)
<Peng> Dotted revnos are based on where it branched *off*, not where it merged back.
<Peng> Actually, does Loggerhead have a data structure tracking that info?
<Peng> Or just revids and dotted revnos?
<mkanat> Peng: It has a *crazy* data structure tracking that info.
<Peng> :D
<Peng> If you want to know where it branched off, the revno will tell you that, yes.
<mkanat> Ah, okay. Yeah, I see that now. Yeah, no, I want to know where it was merged in, unfortunately.
<mkanat> And it seems to be the only reason we need that crazy data structure.
<wgrant> mkanat, Peng: I've seen ghosts where bzr-svn has been used to merge a branch into a Subversion repository. The branch revisions do not actually exist within the svn repo, so you get a ghost when you check it out again.
<mkanat> Oh, wow.
<mkanat> Foreign VCS == confusing. :-)
<mkanat> Wow, so I have to merge_sort the whole graph to know where a revision was merged in?
<mkanat> mwhudson: That appears to be the only reason that we have the revision graph.
<mkanat> (That is, that we have the graph cache.)
<mwhudson> weeeelll
<mwhudson> more or less yes
<mkanat> It seems like bzrlib ought to be able to tell me that more easily, but I'm really not finding a way.
<mwhudson> revision numbering (the way bzr does it) is slow
<mwhudson> mkanat: if you can, 'bzr log' would like to talk to you :-)
<mkanat> mwhudson: Hahaha, but doesn't it just do what I said above?
 * mkanat goes to go look.
<mkanat> See, in bzr log, it makes sense to merge sort the whole graph, because we probably want the whole graph.
<mkanat> But in loggerhead, it doesn't make any sense, because we just want to know where a single revision was merged in.
<lifeless> you need an ancestry oracle
<mkanat> lol
<mkanat> lifeless: So I assume that I'm correct then, and that's what I have to do, and there's absolutely no faster or simpler way?
<mwhudson> mkanat: it's currently a sad fact that to know where one revision is merged in, you have to look at ~the whole graph
<lifeless> mkanat: I wasn't joking, the data structure you need is an ancestry oracle
<mkanat> lifeless: I'm not familiar with that term....
<lifeless> oracles?
<mkanat> lifeless: Unless you mean the Greek kind, yeah.
<mwhudson> mkanat: an oracle is something that gives you answers
<mkanat> Ahh.
<devmod> if i have a branch inside a branch, will it be listed when looking at the main branch? or are they independent entities?
<lifeless> deparate
<lifeless> s/d/s
<devmod> ohh ok that explains it :)
<mkanat> lifeless: More like reverse ancestry.
<mwhudson> mkanat: http://en.wikipedia.org/wiki/Oracle_machine
<mwhudson> i was interested to read recently that you can prove that P != NP if you assume a particular oracle
<mkanat> Ha! :-)
<mkanat> Yes, that's what I need, is a "where did this thing merge into" oracle.
<bob2> send your revid on a postcard to lifeless
<mkanat> lol
<mkanat> lifeless: I assume that there is no such oracle in bzrlib, and that's why we have a crazy data structure in loggerhead to figure stuff like that out.
<mkanat> mwhudson: I suppose another option is to AJAX any operation that needs that information.
<mwhudson> mkanat: weeelll
<mwhudson> i'm not sure that's really an answer
<mkanat> mwhudson: Yeah, very possibly. I haven't looked through all the code to see where get_revids_from and get_merge_point_list are used.
<mwhudson> get_revids_from is conceptually pretty easy i think
<mwhudson> it's just recursively taking the left hand parent from a particular starting point
<mwhudson> get_merge_point_list i have no idea at all about :-)
<mwhudson> i think it can probably be taken away and replaced with something much more sensible
<mkanat> mwhudson: From what I can see in get_revids_from, though, we still need the _rev_info structure.
<mkanat> mwhudson: At least, if its doc string is accurate.
<mwhudson> hm, maybe i misremembered
<mkanat> Okay, yeah, get_merge_point_list can almost certainly be replaced with something simpler.
<mkanat> It's only used inside of get_changes.
<mwhudson> my memories are awakening slightly
<mwhudson> i think get_revids_from is like that for the case where you're showing changes to a particular file
<james_w> finding *a* point a revision was merged in is not hard, finding the point it was first merged is much more work
<mwhudson> so you get a sack of revids (those that change the file) but you want to show the mainline revisions that merged those particular revisions
<mkanat> mwhudson: Yeah, it's mostly used in get_file_view.
<mwhudson> ah ok
<mwhudson> there's something else that it would be really nice to achieve as a side effect of this stuff
<mwhudson> and that's aligning the apis in history.py rather more with the uses of said apis
<mwhudson> (after all, there aren't very many such uses)
<mkanat> You know, yeah, I was kind of thinking about that.
<lifeless> mwhudson: ciik
<mwhudson> lifeless: ?
<mwhudson> lifeless: is your right hand one key to the left?
<devmod> uhm what would a bzr repo structure look like for a project (done the bzr way) ?
<mwhudson> mkanat: it's not as bad as it used to be :-p
<mkanat> mwhudson: :-)
<mkanat> mwhudson: Was History written more as a generic representation and then brought to use afterward?
<mwhudson> mkanat: no idea
<mkanat> Okay.
<mwhudson> mkanat: as you said earlier, it's probably still got lots of hgweb in it
 * mkanat nods.
<mkanat> At the least, I could sane-iify _rev_info.
<mkanat> That might tell me a bit more about what information we're actually using from it.
<mkanat> Can I at least guarantee that the merged-in revno is higher than the first part of the dotted revno of the merged revision?
<mkanat> mwhudson: I think I need to do what you said, and really just figure out what we're actually using this info for, first.
<mkanat> That will probably have to happen tomorrow; today I've been working for like 10-ish hours now.
<mwhudson> mkanat: that would be very useful
<mkanat> mwhudson: Okay. :-)
<mwhudson> mkanat: though i'd meta-ize that even one more step
<mwhudson> mkanat: what do we WANT to use this information for?
<mwhudson> that may not be what we're currently doing :)
<mkanat> mwhudson: Oh, that's a good point too.
<devmod> any suggestion on how to checkout a project with symlinks on windows?
<bob2> what happens when you try?
<devmod> error lol
<devmod> bzr: ERROR: Unable to create symlink
<nicoInattendu> Hi, there  is bazaar command to list all the modified files ?
<nicoInattendu> like  bzr diff -r 37.., but who displays only modified files
<Kamping_Kaiser> status?
<Kamping_Kaiser> bzr help modified
<Kamping_Kaiser> Purpose: List files modified in working tree.
<Kamping_Kaiser> ?
<nicoInattendu> Ok thanks Is exctly why I needed.
<nicoInattendu> bzr status -r 37.. : Is exactly what I m looking for
<nicoInattendu> Thanks !
<vila> YES ! news_merge plugin works :D
<mneptok> vila: so i can push branches to CNN?
<vila> mneptok: not yet, we are still sorting out the deal. But you can pull in the mean time :D
<gerard_> hey
<gerard_> igc & other devs: maybe you could take a look at https://code.launchpad.net/~gerard-/bzr/update ?
<bialix> vila: do you have an URL?
<vila> bialix: for the news_merge plugin ? It's part of bzr.dev
<bialix> ok
<vila> bialix: hi by the way :D
<bialix> hi vila
<vila> bialix: it's more an example of a per-file merge hook and only apply to bzr, you need to add news_merge_files = NEWS in the relevant section of your locations.conf or in branch.conf
<bialix> ÑÐ»
<bialix> ok
<bialix> sorry
<vila> bialix: its aim is to avoid the usual conflicts in NEWS and I see it work live minutes ago :D
<bialix> vila: I understand what you talking about
<bialix> it's great
<bialix> is it possible to write my own mergers? without rocket sciense?
<bialix> e.g. for PO or XML files...
<vila> yeah, just have a look at it or the one we implemented for bzr-builddeb
<bialix> I'm not good in bzr-buildeb staff
<vila> hmm, both are extremely good ideas
<bialix> I hope there will be some simple way to plug-in extrnal utility
<bialix> vila: how's 2.1 going?
<vila> bialix: look at revno 399 in bzr-builddeb trunk, the parts you need are mostly in __init__.py
<vila> bialix: 2.1.0final should be cut tomorrow AIUI
<bialix> COOL
<bialix> this is good news
<bialix> custom mergers are part of 2.1, right?
<vila> bialix: yes
<vila> bialix: but 2.1.0rc2 has a bug which will be fixed in 2.1.0final
<vila> bialix: I merged the fix into bzr.dev though
<bialix> news_merge.py does not seems very simple though
<vila> bialix: plugging a merge algorithm is simple, the algorithm itself remains.... hard stuff
<bialix> yep
<bialix> may I suggest to provide an example of invoking external utility (like diff3) for merging?
<bialix> the signature is simply awful:  def merge_text(self, params):
<bialix> what is params?
<vila> it contains all the needed stuff: lines from both sides, your custom parameters (common to all the file merges invoked for the same tree)
<vila> I'm pretty sure it's documented at the hook level
<vila> bialix: search for MergeHookParams in merge.py
<bialix> ok
<jam> morning all
<jelmer> 'lo
<rubbs> morning
<vila> morning jam
<vila> How can I find the class a method is defined in from its callable ? self being the object and self.callable the method I'm interested in, self.callable.__class__ is the same as self.__class__ even if callable is inherited :-/
<vila> Hmm, well callable in the case I'm interested in is __init__ or __new__ if that may help
<jam> vila: http://paste.ubuntu.com/368238/
<jam> func.__self__.__class__
<vila> jam: that doesn't work if the method is inherited
<poolie> hi vila
<poolie> and jam
<vila> jam: let say B inherits from A which define methA, I'd like to get 'A' from B().methA
<poolie> vila, thanks for taking that sftp hook
<vila> hey poolie !
<jam> hi poolie
<vila> poolie: I'm trying to go a step further and move all test servers out of bzrlib.transport
<jam> vila: f.im_class ?
<vila> poolie: but I run into a problem when deprecating transport.Server
<poolie> vila, yay
<vila> I use a deprecated_method decorator but the message mention the daughter class which looks a bit silly
<vila> a deprecated_method on __init__ tha is
<vila> that
<vila> jam: no im_class there :-/
<jam> well, func.im_class seems to be the same as func.__self__.__class__ in my checking
<vila> __init__ may be harder to handle right than "normal" methods, I can try to check the class hierarchy for the presence of the said method but that sounds hairy and may not even be right
<vila> jam: are you trying on an __init__ method ?
<jam> vila: No, but regardless, I'm not really seeing anything to get at it
<jam> o.func.im_class == child
<vila> well, I think I'll punt and see if some reviewer has better ideas :D
<jam> you could always just manually deprecate something if you need to...
<vila> you mean inlining deprecated_method in my __init__ method ?
<poolie> vila, just inline a specific message
<vila> will do
<jam> is there an open bug that when bzr.dev gets updated it doesn't regenerate merge proposals?
<jam> poolie: just checking but: https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18489
<jam> should only have a small bit, right?
<poolie> jam, oops, i forgot to set the dependent branch
<poolie> if i resubmit it might update
<jam> poolie: well, I can just review locally
<poolie> i'll redo it
<jam> but your dependent branch landed
<poolie> try https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18527
<jam> and the diff is still the full diff
<poolie> yes i saw
<jam> poolie: yeah, small diff now
<jam> hmm... I often find the bzr version to be useful, it was nice to have a known location (scroll to the bottom). However, I can live with it being moved
<jam> why plugins before arguments?
<poolie> mm
<poolie> i could revert that
<jam> poolie: and why have APPORT_DISABLE in the selftest command, rather than in the TestCase setUp() ?
<poolie> it was a bit impulsive
<poolie> because the plugin list made the traceback scroll off the screen on my laptop
<poolie> jam, for the second, it's because you don'nt want to see it if there is eg a SyntaxError
<poolie> or ^C
<poolie> I already have it in setUp actually
<jam> poolie: ah, so you are just getting it disabled earlier...
<jam> anyway, if you feel it is nicer, fine with me
<poolie> i don't want apport to pop up if i ^c a test run
<poolie> and it does at the moment
<poolie> arguably we should not do that in any case actually
<poolie> hm
<jam> poolie: does it pop up if you ^C a normal command?
<jam> that doesn't seem ideal
<poolie> no it doesn't, does it
<jam> ^C log should *not* pop up an apport
<poolie> agree
<jam> though we have specific code there
<jam> which may catch it at a different level
<jam> the @display_command decorator
<poolie> in normal use it doesn't seem to pop up
<poolie> and it shouldn't
<poolie> well
<poolie> report_exception distinguishes ^c and various other things, and that should normally be on the path to report_bug
<jam> poolie: so it would seem odd that selftest would act differently here
<poolie> jam, actually i think perhaps for errors in selftest we want just a shorter display
<poolie> i'm not sure why
<poolie> it did happen
<poolie> perhaps i hit some narrow window
<poolie> actually i could have interrupted it even before it got to establishing our thing
<poolie> our except block
<poolie> so i might have been seeing the ubuntu-wide reporter
<jam> james_w: /wave if you're around
<Peng> poolie: Is https://code.edge.launchpad.net/~mbp/bzr/bzr-fail supposed to exist?
<Peng> poolie: crash.py links to it in a comment, but it 404s for me.
<poolie> hi peng
<poolie> Peng sorry it's ~mbp/+junk/bzr-fail
<jam> rockstar: for some reason I have recorded that we wanted a phone call today. Did I just write down the date wrong from when we talked 2 weeks ago?
<rockstar> jam, that was from when we talked a few weeks ago, methinks.
<jam> yeah, that's what I thought, but I just wanted to make sure
<lifeless> poolie: hihi
<jam> hey lifeless
<jam> odd to see you come online after me :)
<jam> well, depending on where you set the before/after threshold
<lifeless> jam: H :). I'm normally after you :)
<poolie> hi lifeless
<vila> blam
<vila> that was rude
<vila> welcome back all :-/
<poolie> ~.
<jam> vila: check your xp-32bits vm
<vila> LOL
<vila> jam: now, that's a private chat :D
 * vila pants on
<poolie> jam, hi, really away?
<poolie> igc, hi, around?
<vila> poolie: I'm about to EOD :) Moving all test servers out of bzrlib.transport ends up being a *masssssive* cleanup, the patch is ~4700 lines  but all tests are passing again...
<poolie> vila, hm
<poolie> is the bug in 2.1?
<vila> yup, but the patch for the bug is far smaller and already proposed
<poolie> i don't think that's a reasonable change to land there
<poolie> oh good
<vila> I'll target bzr.dev for the big one
<kfogel> this just happened to me:
<kfogel> <kfogel> adeuring: 'cd patches-view-mega-integration; bzr merge ../db-devel'
<kfogel> <kfogel> Warning: criss-cross merge encountered.  See bzr help criss-cross.
<kfogel> I now have 4 conflicts in the integration branch.  I can resolve them, but if I commit, and my integration branch is later merged to db-devel, will that screw up db-devel's history?
<kfogel> poolie: ^^
<kfogel> anyone? :-) ^^
<poolie> kfogel: no :)
<kfogel> poolie: thank you
<kfogel> poolie: So I got to this via the following route:
<kfogel>   cd patches-view-mega-integration
<kfogel>   bzr merge https://code.edge.launchpad.net/~intellectronica/launchpad/sort-by-patch-age  (which is based off p-v-mega-integration)
<kfogel>   bzr commit
<kfogel>   cd ../db-devel
<kfogel>   bzr pull
<kfogel>   (see many updates come down)
<gerard_> hey
<kfogel>   cd ../patches-view-mega-integration
<jam> poolie: I'm just back from lunch
<kfogel>   bzr merge ../db-devel
<kfogel> poolie: that's when I got the criss-cross merge warning.
<kfogel> poolie: if I had done this in the other order -- merged db-devel into p-v-m-integration first, and *then* merged intellectronica's branch, would that have avoided the warning?
<kfogel> (and more importantly, avoided the conflicts?)
<jam> kfogel: you merged sort-by-patch-age back into the branch it was based on, right?
<kfogel> jam: uh, right
<jam> #1 you could try "bzr merge --weave" to avoid the conflicts
<rubbs> gerard_: hey
<jam> My guess is that something merged into pvmi was also merged into db-devel
<jam> perhaps unrelated to what you were doing
<kfogel> jam: so the order in which I merged first sort-by-patch-age and then db-devel into p-v-m-integration is not itself an issue here, then?
<jam> kfogel: so the criss-cross happens when a feature branch is merged into 2 integration branches, which are themselves merged into eachother
<kfogel> jam: *nod*
<jam> 1 isn't enough to trigger criss-cross, but if it happens 2 times
<jam> then both of those feature branches are common ancestors
<jam> and we can't trivially pick one over the other
<kfogel> jam: I'm curious to know more, but we're on very tight deadline right now, so I have to retreat over to #launchpad-dev and just find a way to solve the problem.  As long as we can't screw up db-devel's history when we land, I'm happy.
<jam> kfogel: you won't destroy history, and most likely you will resolve the criss-cross
<jam> (so future merges won't complain)
<jam> but you may also try "bzr remerge --weave" etc
<kfogel> jam: thanks, I clearly need to read up on --weave
<kfogel> jam: so you're saying just resolving the conflicts will make the criss-cross problem go away for future merges?
<jam> kfogel: well, not resolving the conflicts, but landing a new merge which creates a new ancestor that can be used
<jam> which supersedes both of the old ancestors
<kfogel> jam: okay, that makes sense, thanks
<jam> I'm trying to look into some of the unicode failures for package-import, anyone know how to get the changelog for a given package?
<jam> (I'm trying to get debian/changelog for a source package)
<jam> Is it just apt-get source?
<EdWyse_Office> Is there a good way to hide the DOS window that starts with the windows GUI? The text that's displaying on it is confusing my co-worker.
<jam> oh, and how would one get the lucid package when you are in a karmic install...
<jam> EdWyse_Office: needs someone to update bzr, no easy way to do it as a user
<EdWyse_Office> Oh! There's an update for that? I just installed it last week from the latest windows build.
<jam> EdWyse_Office: no, I mean someone needs to do coding to make it happen
<jam> needs a change to the build script to build a target that doesn't use a console
<jam> sorry to be unclear about 'update'
<EdWyse_Office> That's okay. I don't have any machines with a windows compiler or I'd fix it myself.
<Noldorin> hi jelmer
<lifeless> jam: btw doing three-way inside debian/changelog sections is apparently critical
<lifeless> for udd
<mtaylor> ++
<mtaylor> lifeless: o hai
<lifeless> mtaylor: hi
<mtaylor> lifeless: if you have a sec... I'm trying to use bzr builder to test deb making in hudson, and I'm getting this: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-debian-packaging/232/console
<mtaylor> lifeless: I'm wondering if there's anything you can see in 3 seconds that I'm just stupid about
<mtaylor> the build recipe and the way I'm calling it are: http://pastebin.com/mde396ee
<lifeless> posssibly an old bzr-uilder
<jam> mtaylor: this is the error?:
<jam> E: drizzle: debian-changelog-file-contains-invalid-email-address hudson@(none)
<lifeless> you should grab my ppa watching builder branch too
<lifeless> set an environment variable in hudson for DEB_EMAIL
<lifeless> sorry DEBEMAIL
<mtaylor> lifeless: ok. I can do that bit ... what about the "file size not the same / file contents don't match errors" ?
<lifeless> get a newer bzr builder I think
<mtaylor> lifeless: k. will try that. thx!
<lifeless> mtaylor: in fact its a failure in the package import system too I think
<lifeless> so its probably dpkg fuckage we need to track down - are you running hardy or newer?
<lifeless> scratch that, similar not same
<mtaylor> lifeless: it's a squeeze box
<mtaylor> and I'm running lp:bzr-builder ... is there a better branch to follow here?
<lifeless> so two processes are reading the same tar a second or so apart and reading different lengths
<mtaylor> that's beautiful
<lifeless> no, unless you want my 'watch the ppa' code, so that you can build in a ppa rather than locally
<lifeless> I'd ssh in and try debuild
<mtaylor> eventually... but first I'd like to just get the local build working
<lifeless> local builds are harder :P
<mtaylor> heh. debuilds work just fine... generating source packages on the other hand...
<mtaylor> (expected one of drizzle_daily1.orig.tar.gz,...
<mtaylor> too bad there _is_ a drizzle_daily1.orig.tar.gz in the parent dir :(
<vila> It's too bad we don't have a quotes page for commit messages... Imagine:
<vila> I so hate TDD:
<vila> (mbp) turn off selftest globally in cmd_selftest
<vila> :D
<vila> of course poolie meant apport...
<james_w> hi jam
<blueyed> Can you tell me what magic bzr-builddeb does when using merge-upstream? It just committed rev4 on the "upstream"(?) branch, conflicted, but I don't know how to revert this, being on "the other"/regular branch at rev17. Can I switch manually to the "upstream" branch?
<blueyed> james_w: good you are around.. I've done bad things using builddeb.. first the question above.. and then: to fix importing a mangled upstream zip (where I had added debian/ myself apparently), it should be enough to merge a new upstream tarball again (which should then remove debian/) and re-add it after the merge again, correct? You can see it at lp:ubuntu/popfile
<james_w> whu
<james_w> first question "conflicted" means what?
<blueyed> after merge-upstream.. some files in debian/ are in a conflicted state (it wanted to remove them, but I had changed them already)
<blueyed> my plan is to revert, then move debian away.. merge-upstream (which may conflict again), but then it's easier to resolve, commit and add debian again.
<blueyed> also, I'm wondering what mark-uploaded really does (could not find an answer in the docs)
<Peng> vila: Don't forget "silly commit".
<james_w> blueyed: it tags with the version number
<Noldorin> hi
<Noldorin> i'm having trubling pushing to github using bzr-git
<Noldorin> C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+
<Noldorin> ssh://git@github.com:Noldorin/IRC.NET.git
<Noldorin> Permission denied (publickey).
<Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
<gerard_> Noldorin: did you register your public key with github?
<Noldorin> gerard_, i believe i have
<Noldorin> and it's in pageant...at least, it works with normal bzr
<Noldorin> https://github.com/account#profile_bucket
<gerard_> does pushing using git work?
<gerard_> Noldorin: I need to login, and I don't have an account there
<gerard_> I prefer gitorious myself
<Noldorin> gerard_, a normal git push does indeed work
<gerard_> does --verbose add anything useful?
<Noldorin> i'll take a look
<blueyed> james_w: I've now uncommitted just before the messup and redone the things.. it's probably very bad for the same reasons why rebase is bad, but should cause no problems, when uploading, does it?
<Noldorin> gerard_, nothing new there
<Noldorin> is there some bzr 2.0 equivalent of Dhtransport option?
<Noldorin> jelmer, hello?
<jelmer> Noldorin, hi
<Noldorin> hey
<mwhudson> jelmer: hello, found some failing git and hg imports just now...
<Noldorin> jelmer, was just wondering if you had a minute totake a look at a few more of my git/github problems
<jelmer> mwhudson, hey
<jelmer> Noldorin, sure, which ones?
<Noldorin> i'm still getting the "permission denied" error
<mwhudson> git: https://code.edge.launchpad.net/~vcs-imports/buildbot/trunk
<mwhudson> hg: https://code.launchpad.net/~vcs-imports/cython/latest
<Noldorin> jelmer, should be just a little bit up in your log
<jelmer> Noldorin: -Dtransport ?
<mwhudson> jelmer: amusingly the last two failures for cython are completely different...
<Noldorin> ah, i had the option wrong
<Noldorin> cheers
<jelmer> mwhudson, have you tried removing and re-adding the buildbot import ?
<Noldorin> jelmer, http://pastebin.com/m3efbfff4
<mwhudson> jelmer: admittedly, no
<jelmer> mwhudson, can you file a bug about the cython issue?
<jelmer> I don't think there is one yet
<mwhudson> jelmer: ok
<jelmer> Noldorin, you need to use a / rather than a : to separate the hostname and the path in a URL
<Noldorin> jelmer, oh. makes exactly no difference to the log output though :S
<Noldorin> same stack trace exactly
<Noldorin> for git+ssh://git@github.com/Noldorin/IRC.NET.git
<mwhudson> jelmer: https://bugs.edge.launchpad.net/bzr-hg/+bug/516758
<ubottu> Ubuntu bug 516758 in bzr-hg "cython import fails with unicode and infinite recurson" [Undecided,New]
<jelmer> mwhudson, thanks
<jelmer> Noldorin: I can connect just fine and get a proper error:
<jelmer> ERROR: Permission to Noldorin/IRC.NET denied to jelmer.
<Noldorin> hrm
<Noldorin> jelmer, what seems to be the problem then...bad installation?
<Noldorin> i thought i finalyl had a good installation after all the trouble last time :/
<jelmer> Noldorin, your ssh setup - can you connect to github manually using ssh?
<Noldorin> jelmer, how would i test that?
<jelmer> Noldorin: use a ssh client to try to log in
<Noldorin> if you remember, i'm on windows btw. but if i'm going to have to use cygwin, that is ok i guess
<Noldorin> k
<jelmer> Noldorin: how do you have your ssh key set up?
<jelmer> using pageant? If so, please try putty
<Noldorin> jelmer, it seems to authenticate, but the putty window closes before i can see properly
<Noldorin> yeah
<Noldorin> in pageant
<jelmer> ok, so the ssh side of things seems to work
<Noldorin> and i have paramiko or whatever set up
<Noldorin> yeah
<jelmer> and connecting to launchpad works too?
<Noldorin> yep
<jelmer> (over ssh, that is)
<jelmer> mwhudson: the recursive call thing seems weird
<Noldorin> jelmer, oh hmm
<Noldorin> seems there is a problem actually
<Noldorin> putty displays the output:
<Noldorin> Using username "git".
<Noldorin> Authenticating with public key "noldorin-dev@noldorin.com" from ageant
<Noldorin> Server regused to allocate pty
<Noldorin> ---
<jelmer> that seems right, you're probably not allowed shell access on github :-)
<Noldorin> ah
<Noldorin> jelmer, if you want me to add your public key on github, so you can try pushing to the project yourself, i'll be happy to do that
<Noldorin> jelmer, ?
<jam> hey james_w, I had some questions about the builddeb stuff
<jam> #1, I've started switching the per-file hook over to using debian_bundle, and then updating it to do a 3-way merge
<jam> But also, I poked around the Unicode handling.
<jam> which basically seemed... it doesn't very much
<jam> And I was wondering if we should be hacking python-debian, or bzr-builddeb for that sort of change
<jelmer> Noldorin: We can give it a try, but I doubt that'll fail.
<Noldorin> jelmer: would be helpful to see anyway, if you don't mind :)
<Noldorin> you just pushing anything from bzr-git....
<jelmer> Noldorin, see privmsg
<Noldorin> k
<jelmer> Noldorin, should be pushed now
<Noldorin> ok i'll check
<Noldorin> jelmer, you pushed from a bzr repo?
<jelmer> Noldorin, yep
<jelmer> ganieda:~/tmp/IRC.NET.git% bzr dpush git+ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> hmm, ok
<jelmer> so there's either something broken in dulwich/bzr-git on windows or an issue in your ssh setup
<lifeless> jam: python-debian
<lifeless> unless it seems bzr glue specific
<Noldorin> jelmer: hmm. maybe i should give up with windows and just get it working on cygwin?
<jelmer> Noldorin: to be honest, it's very hard to recommend anything without knowing exactly what's going wrong
<jelmer> Noldorin: have you asked on the bzr(-windows) mailing list?
<Noldorin> jelmer: could we have a go setting it up on cygwin at least perhaps?
<Noldorin> not yet...
<jelmer> I'm not the best authority on bzr-git on windows, since I don't run windows but I know other people have.
<Noldorin> jelmer, you are the best authority on bzr-git in general though :D
<james_w> jam: either works for me, I have commit rights for both
<jelmer> Noldorin: I'm not convinced this is a bzr-git problem though
<Noldorin> hrm
<Noldorin> jelmer: i'd like to at least try it out on cygwin though, and see from there, if you don't mind suggesting a few things :)
<jam> lifeless, james-w: so python-debian and bzr-builddeb sort of need to keep in sync. As to whether Block.author is a unicode or str object
<jam> because we can't have them both .decode
<jam> or neither :)
<jelmer> Noldorin: sure
<Noldorin> wait a sec: how does bzr-git get the ssh key?
<Noldorin> and authenticate
<Noldorin> does it do the paramiko/pageant stuff separetly?
<jelmer> Noldorin: it uses the normal functionality in bzr for using ssh
<Noldorin> jelmer, which means it's quite odd ssh auth is working fine normally, but not for bzr-git :S
<Noldorin> jelmer: well, i am getting the same error udner cygwin, but that's probably because it's using the windows path
<Noldorin> hrmmm
<Noldorin> jelmer, maybe there is some way to detect which key bzr-git is using?
<james_w> jam: I guess we should keep python-debian the same them so it doesn't break API for others
<jelmer> Noldorin: the login seems to work but the server hangs up
<Noldorin> hmm
<Noldorin> jelmer,anything to suggest then?
<jelmer> Noldorin, are you familiar with python ?
<jelmer> can you add a "print path" statement in dulwich/client.py, SSHGitClient.send_pack() ?
<Noldorin> jelmer: not really, but i've messed with it a *very small* bit, and program in other languages
<Noldorin> so  if you give me the code to paste, i'll be happy to do so :)
<Noldorin> ok
<Noldorin> will do
<Noldorin> so what's the exact line?
<jam> james_w: where do I file bugs against python-debian?
<jam> For example, passing an actual file or list of lines to Changelog causes it to add a newline to every line
<jam> and Version objects implement __eq__ but not __hash__ which means you can't really use them as dict keys
<jam> (you can get them out with the exact object, but if you try to use an equivalent one, it fails)
<Noldorin> jelmer,(?)
<jelmer> Noldorin: add "print path" as the first line in that function
<james_w> jam: against the debian or ubuntu packages
<jam> k
<jam> james_w: https://code.edge.launchpad.net/~jameinel/bzr-builddeb/changelog-parser/+merge/18557
<jam> Uses python-debian for parsing
<jam> and implement 3-way merge logic
<jam> (for the per-file merge hook)
<jam> though the diff may need to be updated
<mtaylor> bzr-builddeb question ... I'm trying a new packaging layout - namely the debian dir in a branch with the upstream code - but bzr-builddeb is still trying to download a tarball rather than creating one from the source tree... am I doing something competely stupid?
<Noldorin> jelmerkk
<Noldorin> jelmer, odd, nothing
<Noldorin> no printed output
<jelmer> Noldorin: sorry, my bad - it needs to be in fetch_pack
<james_w> jam: cool, thanks
<jelmer> Noldorin: Hmm
<Noldorin> jelmer, ok sure
<james_w> jam: though the strict= thing is why I am not sure about using it for the parsing
<jam> james_w: that's what you are doing for import_dsc...
<james_w> jam: yes, because we don't round trip
<Noldorin> jelmer, nothing still :S
<jam> james_w: though if you consider the non-parsing 3-way merge logic
<jam> I would think this would help improve changelog strictness
<jam> (be loose in what you accept, but strict in what you emit)
<jam> If you really wanted, we could set strict=True
<jam> and if we get an exception
<jam> we can fall back to the default merge logic
<jam> (we just need to return 'not_applicable')
<jam> Though I don't know what exceptions will be raised from python-debian
<Noldorin> jelmer:
<Noldorin>     def fetch_pack(self, path, determine_wants, graph_walker, pack_data,
<Noldorin>         progress):
<Noldorin>         print path
<Noldorin> that's the code
<Noldorin> no luck though
<Noldorin> jelmer, so it seems it's not even getting that far perhaps?
<jelmer> Noldorin: I'm quit sure it's getting beyond that point - see the backtrace
<Noldorin> hrmm
<Noldorin> then i have no idea why nothing is getting printed
<jam> james_w: 2 bugs submitted
<jam> (for python-debian)
<james_w> thanks
<Noldorin> jelmer: keep sending me as many tests to make in the python source as you like, i'll be happy to do so. :)
<mkanat> mwhudson: Off the top of your head, do you know what's up with this? http://bzr.mozilla.org/bugzilla/trunk/files
<jelmer> Noldorin, are you sure you
<jelmer> 're editing the right copy of dulwich ?
<mkanat> mwhudson: (I can't look at the logs on that server.)
<Noldorin> jelmer: yes, because if i create a syntax error, bzr picks it up
<mwhudson> mkanat: no
<mkanat> mwhudson: Okay.
<mwhudson> jelmer: yes
<Noldorin> jelmer?
<lifeless> jam: are you sure 471292 is a dupe?
<jam> bug 471292
<ubottu> Launchpad bug 471292 in bzr-builddeb "import-dsc fails on UTF-8 characters (dup-of: 508251)" [Wishlist,Confirmed] https://launchpad.net/bugs/471292
<ubottu> Launchpad bug 508251 in udd "Failure to import when decoding changelog authors" [Medium,Confirmed] https://launchpad.net/bugs/508251
<Noldorin> jelmer, interesting. it seems path is null/empty
<jam> lifeless: the former was reporting that it fails when the author name is not ascii
<Noldorin> since when i print "foo", it works
<jam> which is what bug 508251 is about
<lifeless> jam: ah but the source of the data is different I think
<lifeless> if you look at the crash file, 471292 is failing in import_upstream
<jelmer> Noldorin: Hmm
<lifeless> jam: I'm going to undup, I'm pretty convinced its separate
<jam> lifeless: I'm pretty sure it is effectively a dupe
<jelmer> Noldorin, what's the exact command you're running?
<jam> 471292 is because bzr-builddeb is trying to pass a plain str (not Unicode) as the author
<jam> the others are failing for effectively the same reason
<jam> it is parsing the Changelog but *not* decoding the entries
<lifeless> yes, but the source of the strings are different AFAICT
<Noldorin> jelmer: hmm? "print path"
<Noldorin> 'print "foo"' works
<jelmer> Noldorin: No, the bzr command
<Noldorin> oh sorry
<jam> lifeless: given the UnicodeDecodeError string, I'm pretty sure it is a failure to decode authors in both cases
<jam> you can be as picky about exact tracebacks as you like
<lifeless> jam: hmm, I gues what I want is to know that it is fixed; and I'm concerned that as a dup it won't get separately tested
<Noldorin> $ bzr dpush git+ssh://git@github.com/Noldorin/IRC.NET.git
<Noldorin> jelmerthat's it
<jam> lifeless: as yet, I don't really see how to properly test import_dsc, without just pushing it to james_w and having him run it on the importer...
<jam> (certainly there are unit tests, but testing with real-world data would be better)
<jam> I suppose eventually we'll get some real-world test cases
<lifeless> jam: I'll have a look at 471292 in a few minutes in more depth; if I can't see it using DEBEMAIL then I will redup it for you
<lifeless> ok ?
<lifeless> [I'm not trying to be picky about exact tracebacks]
<jam> If you feel it is a different source, feel free
<jam> It sure looked the same to me
<lifeless> ack
<Noldorin> jelmer: bit busy atm?
<jelmer> Noldorin, sorry
<Noldorin> it's ok
<jelmer> Noldorin: we'd have to debug where that path comes from
<jelmer> Noldorin, it should be extracted from the URL
<Noldorin> i see
<Noldorin> jelmer, well feel free to suggest anything. i'm here to do any necessary testing atm :)
<Noldorin> jelmer, i'm just stopped by my unfamiliarity with the lib mainly heh
<jelmer> Noldorin: you could try poking around in bzr-git's remote.py
<Noldorin> okies
<spiv> Good morning!
<Peng> Hi!
<lifeless> yo spiv
<Noldorin> jelmer, anywhere in particular?
<jelmer> _get_path
<jelmer> and the SmartTransport constructor
<Noldorin> ok, thanks
<Noldorin> jelmer, ok, so that path variable is getting set fine
<Noldorin> to /Noldorin/IRC.NET.git
<Noldorin> jelmer, i guess it's the interop with dulwich we want to look at next?
<Noldorin> jelmer: wherever that is :)
<lifeless> jam: I was wrong, redudped
<lifeless> james_w: please let me know when I can zap those debhelper branches
<james_w> http://package-import.ubuntu.com/status/ifenslave-2.6.html#2010-01-12 23:56:32.979164 would be a good failure to look at as well
<lifeless> james_w: run check on that?
<Noldorin> jelmer: i think we're on to something here... oh well, i'll catch you another time hopefully.
<james_w> lifeless: I don't have any of the trees to hand
<lifeless> could you make the system tar up failures like that?
<james_w> it keeps them around now
<lifeless> ok but we need access to the machine right ?
<james_w> yes
<james_w> I could put tarballs publically if you wanted
<james_w> wouldn't help this case though
<james_w> and I think there are more important things to do
<lifeless> sure
<lifeless> just a bit hard to investigate that one - it smells like local data/race issue
<doctormo> How would I get a branch at a sepcific revision or turn a branch back to specific revision? I want to test pull code, but I need to move it back once I've done my test.
<Peng> You want to pull something, mess with it a bit, then undo the pull?
<spiv> doctormo: 'bzr branch -r 1234 URL' will get a branch at a specific revision
<spiv> There are also ways to "turn a branch back to a specific revision", but the exact command depends on exactly what you mean by that.
<spiv> Possibly you just want "bzr pull -r 1234 --overwrite"?
<lifeless> spiv: + .
<Peng> Ah, didn't think of that.
<Peng> I was thinking "bzr merge", don't commit, then "bzr revert".
<lifeless> if you're writing test code though, just use a throwaway branch ;)
<doctormo> spiv: Thanks a lot!
<spiv> lifeless: ah right.
<spiv> lifeless, jam: Thanks for the ConfigurableFileMerger refactoring
<spiv> lifeless, jam: it looks like a much nicer API, although I don't yet understand how it avoids re-reading the config for each file to merge.
<spiv> Ah, I think I see.
<spiv> The active_hooks attribute.
<lifeless> spiv: each object maintains its own state
<lifeless> spiv: rather than putting the state on the Params, which wass new-per-file
<lifeless> spiv: are you back on deck ?
<spiv> lifeless: I am
<spiv> lifeless: yeah, I see now, the bit I was missing is that the hook objects aren't new-per-file anymore, just per-merge, which seems sane.
#bzr 2010-02-04
<doctormo> If I do a bzr pull, will it kill all changes done in this branch and revert it?
<doctormo> So if there are uncommited changes, or commited changes, they'll all be reverted.
<spiv> pull will never discard uncommitted changes.
<doctormo> spiv: But it will do away with commited changes?
<spiv> If you pull --overwrite to an older revision, then the later revisions will no longer be in that branch's ancestry, yes.
<lifeless> if they aren't in the new history, yes
<spiv> (The revisions will still exist in the repository, though)
<doctormo> spiv: I'm just trying to work out what I'm doing in my pull code, perhaps what I mean to do is not pull but merge.
<doctormo> What would you do if you had a parent directory that had moved forwards and you wanted to resync your working branch with it.
<maxb> If you did pull in that case, it would tell you 'branches have diverged'
<spiv> I'm not sure about "parent directory that had moved forwards", but generally speaking if I have a branch that I've made changes in, and I want to incorporate changes from elsewhere to the same branch, I would use 'bzr merge'.
<doctormo> s/parent directory/parent branch/
<maxb> It's hard to tell what you mean by 'resync'
<doctormo> Translating bazaar speak into something your holiday developer will understanding is making my terms diverge maxb.
<spiv> maxb: ('branches have diverged' is right if we assume the working branch has had commits made, rather than just uncommitted changes)
<maxb> a good point
<doctormo> So what i really mean is `bzr merge` when I have local commits and `bzr pull` when I don't have local commits (but local changes ok)
<spiv> doctormo: in relatively simple terms, if two people both have a copy of a branch, and they have made different commits to their copies, you probably want 'bzr merge' to combine those different changes.
<spiv> doctormo: there's "bzr merge --pull", btw, which automates "'bzr pull' if no divergence, otherwise 'bzr merge'"
<doctormo> spiv: I think I'll try and hook into builtins for that then, I had a bad time intergrating builtins into my threaded code though.
<spiv> doctormo: you can always take a look at the code to see how its implemented.
<spiv> doctormo: the code in builtins.py is mostly fairly readable
<doctormo> spiv: It is, but I'm feeling bad about copying bits out of it, like I'm removing all the checks.
<doctormo> http://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py
<doctormo> If interested, look at the do_action methods, I think they probably should be going through builtins.
<spiv> doctormo: perhaps you should be reusing some code from the bzr-gtk plugin?
<spiv> (or even the qbzr plugin?)
<spiv> They've both already wrapped lots of builtin actions into a GUI-friendly form.
<doctormo> spiv: I already am, as much as I could. But the problem is that I have really bad constraints because of nautilus.
<spiv> Ah ok.
<doctormo> It took me 3 weeks to work out how to get around those contrains too, I've lost an inch of hairline ;-)
 * spiv lunches
<igc> hi all
<spiv> hi igc
<igc> hi spiv!
 * spiv finishes up for the day
<vila> poolie: you broke my toy ! https://bugs.edge.launchpad.net/bzr/+bug/516934
<ubottu> Ubuntu bug 516934 in bzr "infinite recursion when apport is installed" [Critical,Confirmed]
<fullermd> Pfft.  Your toy is just too slow   :p
 * igc dinner
<poolie> hi vila
<poolie> hi igc?
<smartgpx> Greetings. Are there any Win32 supporters in - I've just encountered an odd crash that is making me feel panicky
<smartgpx> 'Out of the blue', > bzr explore has stated throwing a MS Visual C++ runtime error.
<smartgpx> Console reports "QVariant::load(QDataStream &s): type list unknown to QVariant." Nothing in .bzr.log
<fullermd> I presume that's Qt-related.
<smartgpx> Yes, so do I. But this is a setup.exe binary installer machine, so as far as I know the only Qt is in the bzr bundle
<fullermd> Which version?
<fullermd> (I have no idea what solutions might be BTW, so don't expect answers from me  :)
<smartgpx> freshly re-installed bzr2.1.0rc1-1.exe AFTER first hitting the problem
<smartgpx> other tools from the qbzr suite run OK. qlog, qplugins both look normal.
<smartgpx> Since re-installing from the binary installer doesn't fix it I'm fearing something is trashed in my OS. But what and how/why? AV scan running now!
 * bialix calls for Gary
 * fullermd isn't Gary  8-}
 * bialix waves at fullermd
<vila> smartgpx: Don't Panic
<vila> smartgpx: I don't know the details but igc mentioned some Qt compatibility problems citing QVariant, so at least the problem is not unknown
<vila> smartgpx: please file a bug against bzr-explorer though better a dupe than no report
<vila> bialix, fullermd : hey guys !
<fullermd> Oh, no, go ahead and panic.  It's good aerobic exercise.
<bialix> heya vila!
 * fullermd waves at vila.
 * vila checks its hitchhiker's guide about aerobic....
<bialix> smartgpx: what's up?
<vila> . o 0 (aerobic raises EBADFORCHOLESTEROL)
 * bialix thinks we have to upgrade windows installer to pyqt 4.7 so igc won't need to break backward compatibility at such high rate
<smartgpx> NO - I've been told to get my HDL levels down! bialix - summary on Bazaar ML
<bialix> HDL?
<smartgpx> High Density Lipids I think - 'Bad Cholesterol'.
<smartgpx> Bugged as Bug#516968
<fullermd> Lipoprotein to be precise.
<fullermd> (and actually HDL is the soi-disant 'good' variant)
<fullermd> So whoever wants you to get those levels _down_ is...   well...    are they in your will?   ;>
<bialix> ubottu: please tell me about bug #516968
<ubottu> Launchpad bug 516968 in bzr-explorer "'bzr explore' unexpectedly throwing MS Visual C++ runtime error at startup " [Undecided,New] https://launchpad.net/bugs/516968
<bialix> thank you!
<bialix> smartgpx: can you try to remove explorer.conf file?
<bialix> or something similar
<vila> fullermd: That should be obvious but how do I make a shell script change my current working directory ?
<fullermd> vila: Well, if I understand you, you don't, since a script (by definition) runs in its own process, and $CWD is an attribute of each process.
<smartgpx> CONFIRM that removing explorer.conf gets Explorer running again.
<bialix> close explorer, open again and you'll get a crash?
<fullermd> vila: So to change the $CWD of your current shell, it would have to run in that process, not external, with all that implies.
<vila> fullermd: so I have to . shell-script ?
 * fullermd nods.
<vila> rats, . `which shell` args.... how ugly :-/
<vila> funny I never encounter the problem before...
<smartgpx> Thanks to Simon Kersey for suggesting this.
<fullermd> Well, maybe you could reach into /proc and manually fudge in the other process's memory.  Is that less ugly?   ;)
<vila> fullermd: Brilliant !
<vila> :-P
<fullermd> Well, naturally.  I said it, didn't I?
<bialix> smartgpx: perhaps this is because explorer in big flux
<smartgpx> bialix - no, it re-runs OK. I didn't think to mention that I had been exploring the new preferences in r405!
<bialix> we need to test how smooth it will upgrade from 0.11.x to 1.0
<bialix> oh, sorry, just saw your mails in bzr ML
<bialix> smartgpx: anyway, thanks for testing bleeding edge changes and reporting!
<smartgpx> maybe it isn't a recent problem? Anyway, rebugged as #516976
<bialix> bug #516976
<ubottu> Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976
<vila> ubottu: pay attention please, when someone says #516976, just interpret it as bug #516976, thanks
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<vila> bialix: faster than me !
<bialix> :-)
<bialix> smartgpx: I will try to look on this today
<smartgpx> fullermd: [OT] thanks for making me re-think my knowledge of cholesterol! More reading required.
<fullermd> Amazing the things version control can lead you to thinking of   8-}
<igc> smartgpx: see my email on the Qt issue
<vila> fullermd: alias is my friend :D alias bzr-review='. `which bzr-review.sh`'
<bialix> hi igc :-)
<bialix> igc: we have to update explorer's setup.py otherwise your new fancy wear things won't go to installer/package. can we elaborate on this?
<igc> bialix: understood. On my list for tonight.
<bialix> ok
 * bialix working on preparing qbzr 0.18.1
<bialix> anybody seen garyvdm there these days?
<igc> bialix: I'm going to fix bug 516976 asap btw
<ubottu> Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976
<bialix> igc: that's will be nice. if you need quick testing ping me
<igc> shall do
<poolie> igc, +1 on that mail
<poolie> vila, testing.txt says it's _test_needs_feature=[...] but that seems wrong
<poolie> nm
<vila> what is... err
<poolie> i was confused
<poolie> vila, so you're going to delete the redundant 'requireFeature(Apport..)'
<vila> poolie: Yes, I deleted it from your test and keep it only in the deprecation test reproducing the bug
<vila> I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
<vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
<Kamping_Kaiser> AIUI, merging a single file into a bzr repo is the same as copying it from its original repo, because bzr only tracks commits, not files. have i got that correct?
<Kamping_Kaiser> when i say 'copying' i mean 'cp /this/file ./repo/'
<vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
<vila> s/It/Is/
<fullermd> Kamping_Kaiser: I think merge will preserve the file-id, but that's probably the only difference.
<Kamping_Kaiser> fullermd: i still have the files original bzr repo in future i can use the file id to track its history by searching in the old bzr repo?
<Kamping_Kaiser> *if i
<fullermd> Conceptually (though I don't think there's anything in the implementation to automate any of that)
<Kamping_Kaiser> hm, ok. its only a few dozen lines of shell, i might just reimpliment it this time. i'll come back and sook when i want something more complex ;)
<igc> bialix: please test preference saving in rev 407. bug 516976 ought to be fixed now
<ubottu> Launchpad bug 516976 in bzr-explorer "Saving preferences from Tools/Options inhibits future startup " [Undecided,New] https://launchpad.net/bugs/516976
<bialix> igc: revno 405 don't want to start at all for me. unicode error (again)
<igc> bialix: try rev 407
<bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517036
<ubottu> Ubuntu bug 517036 in bzr-explorer "explorer revno.405 cant start because of unicode error" [Undecided,New]
<bialix> igc: 407 starts but the console full of tracebacks: http://pastebin.com/m57981d80
<igc> bialix: delete the tools.xml file in your explorer directory and start the app again please
<bialix> https://bugs.launchpad.net/bzr-explorer/+bug/517040
<ubottu> Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New]
<bialix> igc: deleted. now I have unicode error again
<igc> bialix: pastebin?
<bialix> see it there https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/1
<ubottu> Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New]
<bialix> igc: ^
<bialix> igc: last time it was last month and you decide to move from text to pickle, or something similar
<bialix> again: this is bad idea to write localized text to conf files
<igc> bialix: well the history file doesn't need to be human readable. explorer.conf does need to be IMO
<bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/2
<ubottu> Ubuntu bug 517040 in bzr-explorer "revno 407 emits a lot of tracebacks to the console" [Undecided,New]
<bialix> igc: empty toolbars.xml was the raeson of element tree tracebacks
<igc> bialix: how did you get an empty toolbars.xml? Maybe that was there once but lib/extensions/__init__.py suggests it should always have content now
<bialix> igc: have no idea
<bialix> I don't edit anything by hands in explorer/ directory
<igc> bialix: I wonder what effort we should make to check bzr vs qbzr vs explorer compatbility?
<bialix> what do you mean/
<bialix> &
<bialix> ?
<igc> bialix: I'm seeing quite a few bugs with old explorer and new qbzr or vice versa
<bialix> rats
<bialix> I'd say in explorer 1.0 you need to force some minimal qbzr version
<bialix> I'm ok with this
<igc> what's the minimum bzr version for qbzr 0.18?
<bialix> there was check in explorer/__init__.py, is not?
<bialix> qbzr 0.18 intended to be used with 2.1
<bialix> but it should work with 2.0
<bialix> I can check, but I don't think we made any special changes in this area
<igc> bialix: I can't find that version check. Maybe we moved it?
<timour> Hi all, can someone suggest how to disable commit emails in a specific repository?
<bialix> igc: perhaps I've confused it with the check in qbzr itself
<timour> Specifically, I use etc-keeper with Bazaar, and I don't want commits in etc to be sent to the mailing list of my project.
<bialix> timour: do you have enabled mails in bazaar.conf?
<bialix> timour: take a look at locations.conf
<timour> bialix, yes
<bialix> the best place to enable things by directory level is locations.conf
<timour> bialix, so this is the config file where one can specify for what local repositories to send commit emails?
<bialix> igc: qbzr has check which insist we need bzrlib api >= 1.17
<timour> bialix, is this file in .bazaar?
<bialix> timour: yes
<timour> bialix, thanks a lot!
<bialix> check the docs on config files
<igc> bialix: what about the progress monitoring changes made in 2.1?
<bialix> I don't know
<bialix> I did not touch the code, garyvdm too. It seems we don;t support this feature yet
<bialix> of course Gary may know better
<igc> bialix: I thought garyvdm made some changes following poolie's changes to bzr core. Maybe none were needed?
<bialix> I cant say right now
<igc> bialix, re bug 517036, please try rev 409
<ubottu> Launchpad bug 517036 in bzr-explorer "explorer revno.405 cant start because of unicode error" [Critical,Confirmed] https://launchpad.net/bugs/517036
 * bialix pulling
<bialix> igc: fixed now
<bialix> thx
<igc> bialix: what does your toolbars.xml file look like?
<bialix> igc: now http://pastebin.com/m336afd8a
<bialix> I've removed it hour ago, this one created by explorer I suppose
<igc> bialix: yes, it will create one if missing
<igc> bialix: any other files just creaed there for you?
<igc> created
<bialix> checking with empty one now
<bialix> igc: if the file has size of 0 bytes it's not re-created with valid content then
<igc> bialix: right. It was the Unicode Error that was giving your a zero length file though :-(
<bialix> igc: http://pastebin.com/d68d7eac5 this is the files created if I remove explorer dir
<igc> bialix: that looks good to me
<bialix> ok
<poolie> hi all
<vila> poolie: hey
<vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
<vila> poolie: I said earlier: I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
<vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
<bialix> heya poolie
<poolie> vila, a bit less magical
<poolie> i was suggesting removing just ApportFetaure
<poolie> but either is fine
<vila> oh, ok, I'll tweak and merge then
<poolie> it was more just a  general comment about not doing too much work in deprecation
<poolie> i'll try to read your merge rfc and patch
<poolie> not sure when i will get uninterrupted time
<vila> poolie: ok, thanks
<poolie> yo ucan nag jam or igc
<vila> for the conflict handling one ? That's what my last comment was, wasn't it ? :D
<vila> oh, silly me, you can't see that, they are CCed
 * bialix -> lunch
<vila> gorgeous, clicking on the bug link in qlog opens my browser, nice one bialix/garyvdm
<bialix> it was luks
<bialix> something bad with lp right now
<vila> bialix: yup, oopsing all over the place :-/
 * bialix goes outside
<poolie> srsly?
<poolie> vila, which page?
<poolie> escalate it if it's persistent
<vila> poolie: just checked, mthaddon is restarting apps servers
<vila> They oops look like timeouts to me since refreshing succeed half of the time
<ddaa> Hello there
<ddaa> the rebase plugin works well to rebase to a newer version
<ddaa> but I cannot find how to make it rebase to an older version
<ddaa> my use case is backporting an independent patch that was committed on a feature branch
<ddaa> How can I backport one or several patch while preserving committer, date, etc, like rebase does?
<vila> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold
<vila> bah
<vila> meh, I can't change the topic anymore ? When did that occur ?
<poolie> ddaa, sorry, i don't know, it sounds like a bug/limit in bzr-rebase
<ddaa> hey poolie
<poolie> hi there
<poolie> vila, i'm nervous of landing such a large patch to 2.1
<poolie> also i can't understand your comment that
<poolie> ... oh, i see, you're saying it's too late to add testtools as a dependency
<poolie> and it is
<vila> yeah, but the patch isn't large, it's only because a lot of code has been moved, but I didn't change the moved code
<jelmer> ddaa: bzr replay should be able to do that
<poolie> right
<ddaa> jelmer: I tried tying that on the command line, and I looked on the bzr plugin guide, http://doc.bazaar.canonical.com/plugins/en/index.html, and I did not see any "bzr replay".
<ddaa> oops
<vila> poolie: well, I can understand the feeling about SRU, but almost nothing has been changed in the "code" most of the patch is related to the tests
<ddaa> actually, it works on the command line
<ddaa> jelmer: thanks jelmer, sorry for the noise
<jam> morning all
<jelmer> ddaa: np
<vila> morning jam http://instantrimshot.com/
<poolie> vila, did you see igc's mail asking jam to delay the rc?
<vila> no :-(
<poolie> so i think this should be ok for this too
<jam> poolie: well, to do an rc3 today, and to delay final to next week, yes
<jam> jelmer: something is wrong with lp:bzr-rewrite
<jam> it points to:
<jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
<jam> which points to http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred
<jam> but that branch doesn't exist
<jam> http://people.samba.org/bzr/jelmer/bzr-rebase/trunk does
<poolie> jam, well, specifically after bzr-explorer works
<jam> so lp:bzr-rewrite doesn't have 0.5.5 available
<poolie> s/works/releases 1.0
<poolie> jam/igc "Updated Bazaar 2.1.0 release plane"
<poolie> plaan*
<poolie> plan*
<poolie> laggy connection
<fullermd> Hm.  There isn't a bzrtools release to match 2.1 yet either.
<jelmer> jam: http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred exists here
<jam> I'd rather a release plane ...
<jam> hmm.. I was spelling it with 1 too few r's :)
<jam> however, the launchpad branch is still unhappy
<jam> Next Mirror: Disabled
<jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
<jelmer> I wished launchpad did exponential backoff on failures
<poolie> on import failures?
<jam> this was a mirror failure
<jam> probably had a 1 day outage, and got 5 hiccups in a day
<jelmer> poolie: mirror and import failures
<jelmer> jam: strangely enough I don't seem to have the authority to reenable the mirror
<vila> anybody knows how to change the topic ?
<jam> jelmer: neither do I
<jam> vila:  /topic ?
<poolie> jelmer: you should file a bug for the lack of ability to do that
<jam> I use pidgin and just double click
<jam> which opens a dialog
<poolie> vila, i'll try
<poolie> what do you want to add to it?
<jam> poolie: he's the PP this week
<vila> jam: I tried that but got : #bzr :You're not channel operator
<vila> poolie: s/igc/vila/ for pp
<jam> vila: I just got the same
<jam> that hasn't ever happened before
<vila> I was wondering if things have changed because of the recent storms
<jam> I wonder who locked down topics to only ops
<jam> Looking at the list, I don't think I see any ops ... ?
<maxb> I think it might have happened as part of the ircd upgrade
<fullermd> Maybe it was just fallout from the ircd change.
<vila> -Martinp23- Hi everyone. We've disabled the +S chanmode for the time being. Normally, +S blocks users from joining a channel if they aren't connecting with SSL. If you still see +S in your channel's modelist, it will have *no effect*. For the now, you will be unable to add or remove this mode. We'll have a more permanent resolution asap. We're sorry for the inconvenience caused by our earlier technical difficulties.
<vila> on 31/01 1:54
<fullermd> Yeah, but it's [probably] the +t that's in effect here.
<maxb> yes
 * fullermd has a dream that someday there will be an ircd that actually _documents_ all its stuff...
<maxb> abentley can op people. lifeless can bestow that ability upon others
<vila> maxb: where did you get that info ? 8-)
<maxb>  /msg chanserv access #bzr list
<maxb>  /msg chanserv help flags  -- for the definitions of the various privilege flags
<vila> ok, so someone on the access list just needs to /mode -t
<vila> abentley, lifeless: ^
<alf__> Hi all, I accidentally pushed a series of revisions to a (local) branch. Is there a way to remove those revisions from the branch?
<vila> alf__: push --ovwrwrite
<vila> alf__: push --overwrite
<vila> grr
<jml> poolie, http://robertcorr.com/2010/02/afact-v-iinet/
<alf__> vila: What should I push?
<vila> alf__: you tell me :D
<vila> alf__: the revision you want to be the tip of your remote branch
<alf__> vila: Yes ok, let me be more clear :)
<vila> alf__: if the branch is local, you can just go there and : bzr pull -r<the_good_one> --overwrite
 * vila applauses abentley 
<abentley> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone goldd
* abentley changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone goldd
 * vila applauses abentley 
* abentley changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone gold
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold
<alf__> vila: Ah, yes that is what I was looking for, thanks!
<poolie> hi abentley
<bialix> hi jam
<abentley> poolie, hi.
<gerard_> hey
<rubbs> gerard_: hello
<gerard_> anyone has some time to review https://code.launchpad.net/~gerard-/bzr/update/+merge/18464 ?
<gerard_> vila perhaps?
<gerard_> </NagMode>
<vila> gerard_: Just got promoted patch pilot, I'm cleaning up the easy bits first and will have a look
<vila> gerard_: thanks for your patience
<fullermd> poolie: "update --2a"?
<vila> fullermd: upgrade ?
<fullermd> I dunno which part of it he meant...
<gerard_> vila: that's ok
<gerard_> I just noticed the unused local "update_dash_r", don't mind that, will remove it tonight
<jam> fullermd: I think he actually needs to do 'reconcile' (though just of the branch), but I'm sort of staying away for now
<maxb> Yikes. branching a 2a branch locally without stacking or a shared repository feels slower than branching it over the network :-(
<doctormo> Hmm, I'm trying to work out why the cmd_revert in builtins is one of the few commands to not accept a directory input.
<doctormo> I presume it's because it uses tree_files(..) with default_branch instead
<doctormo> how do I use bzr to remove all unknown files?
<mzz> doctormo: see "bzr help clean-tree"
<doctormo> thanks mzz, worked like a charm
<poolie> igc i hope you didn't get up this early for my sake
<igc>  poolie: I'm about to grab some sleep actually. Getting up is planned for 6 hours from now :-)
<poolie> ok :)
<igc> night all
<rubbs> night
<poolie> night
<lifeless> moin moin
<jam> lifeless: /wave
 * jam away to lunch
<mkanat> james_w: You mentioned the other day that it wouldn't be too hard to get *one* point where a revision was merged in. What about getting *all* the points? Does that require graph walking?
<lifeless> mkanat: yes
<mkanat> Okay.
<lifeless> revsions point at parents. merged-in is children
<mkanat> Yeah.
<mkanat> And merge_sort is the only thing that will tell me where those children show up, right?
<lifeless> merge_sort is the sort we use for log
<lifeless> if you want revnos you need to use it (directly or indirectly)
<vila> lifeless: /wave
<vila> lifeless: what kind of dependency should be used for testtools in the bzr package ?
<mkanat> lifeless: *nod* And it's also the only built-in way to find out where a revision was merged in, right, other than walking the entire graph myself?
<lifeless> vila: arch independent  build depends
<lifeless> mkanat: no, there are iterators on branch and so forth
<mkanat> Oh, yeah, I see iter_merge_sorted_revisions.
<gerard_> hey
<gerard_> vila: need any help with the simple stuff?
<beuno> http://blog.digital-scurf.org/2010/02/04#comparative-publishing
<beuno> \o/
<MvG> http://doc.bazaar.canonical.com/bzr.dev/developers/plugin-api.html#metadata-protocol states that bzr_plugin_version should be "a version_info 5-tuple". Does that imply any restrictions on its format? Is there a relation with http://docs.python.org/library/sys.html#sys.version_info ? Not all plugins seem to follow the latter format, is that OK for new plugins as well?
<Peng> MvG: The restriction I know of is that it shouldn't make bzrlib._format_version_tuple() throw an exception. :P
<MvG> Peng: thx
<mwhudson> jelmer: ayt?
<maxb> I'm trying to locate the code that is responsible for post_change_branch_tip firing conditional on whether the tip actually changed when doing a "bzr pull", but firing unconditionally with a "bzr pull --overwrite" - can anyone help?
<maxb> ah, I think I've found it. GenericInterBranch.update_revisions
<mwhudson> mkanat: the revid_to_revno map is definitely not small enough to cache in memory for many branches :(
<mkanat> mwhudson: 100,000 revisions, that's going to be...what, maybe 512K of RAM?
<mkanat> Well, maybe more.
<mkanat> Maybe a few MB.
<mwhudson> and loggerhead can examine a few thousand branches...
<mkanat> mwhudson: We already are caching it in memory.
<mwhudson> mkanat: only 10 at a time
<mkanat> mwhudson: Fair enough.
<mkanat> mwhudson: But still, we could move the caching to the branch object.
<mkanat> mwhudson: And historycache.
<mwhudson> mkanat: loggerhead _used_ to cache a lot more in memory, and stopping it doing that helped the memory footprint immensely
<mkanat> mwhudson: I can imagine. :-)
<mkanat> mwhudson: I'm actually proposing that we cache less than we do now, BTW.
<mkanat> (Except my bit about the 100 branches.)
<mwhudson> i think using historycache makes a lot of sense though
<mwhudson> mkanat: also
<mwhudson> I imagine
<mwhudson> it'd be fairly safe to use the same branch object across all our
<mwhudson> threads.
<mwhudson> that sentence doesn't give warm fuzzy thoughts
<mkanat> mwhudson: Right, I was wondering about that. :-)
<mkanat> mwhudson: One possibility is to put locks around the places that aren't thread-safe.
<mkanat> mwhudson: One of the things I'm also trying to accomplish is building the caches lazily.
<mkanat> mwhudson: Because, for example, we don't need them at all to display ChangeLogUI, but they're built anyway, because we called History()
<Peng> With modern disk formats, how much does Loggerhead still need the caching?
<Peng> s/disk/repo/
<mwhudson> mkanat: +1 on that
<mkanat> Peng: I'm actually not sure.
<mwhudson> Peng: sorting the revision graph is still slow
<mkanat> Oh, yes, that is needed.
<mkanat> I am sure about that.
<Peng> How often does it really need the whole revision graph?
<mkanat> I did some testing--it takes about 4 seconds to run through iter_merge_sorted_revisions on a loggerhead devel branch.
<mkanat> Peng: That's exactly what I just researched.
<mkanat> Peng: It only needs it when it has to know where a revision was merged in or from.
<mkanat> Peng: So even if we just built the current cache lazily, we'd reduce building that part of the cache to RevisionLogUI and RevisionUI.
<mkanat> mwhudson: The only thread-unsafe thing I can imagine about using a branch read-only would be its internal caches.
<mkanat> mwhudson: Though of course there could be other things I don't know about.
<mwhudson> mkanat: i don't have any specifc worries
<Peng> mkanat: <3
<mwhudson> mkanat: just general ones :-)
<mwhudson> maybe it would be fine
<Peng> Yeah, "maybe it would be fine" in regards to thread safety _always_ ends well. ;P
<mkanat> mwhudson: Okay. But if we find out that it isn't, instead we can build those three simplified caches that I mentioned on-demand, instead of whenever we instantiate a History.
<maxb> What's the most lightweight way to ask bzrlib "Is this specific directory a branch?"
<mkanat> maxb: I think Branch.open?
<Peng> But that isn't necessarily lightweight, e.g. if it's a branch reference to a remote location, or maybe even a lightweight checkout.
<mkanat> maxb: You could check if it has a .bzr first, right?
<maxb> yeah, probably not worth that much code
<maxb> find_branches is out, because I want not to recurse
<mkanat> Yeah. Although I suppose that directory could be a repo, too, if it just has a .bzr in it.
<Peng> I've checked for .bzr/branch in the past, but it's evil.
<mwhudson> mkanat: yeah
<mkanat> Maybe BzrDir.open_branch? I dunnow.
<maxb> Ironically the reason I'm caring is because the existing code is finding git repositories that I don't want, since bzr-git is installed :-)
<mkanat> mwhudson: Okay. So I'll update the bug with that proposal.
<Peng> maxb: :D
<Peng> maxb: I'm sure it's possible to work around that, but I dunno how. You can check for some property of foreign branches that doesn't apply to real bzr branches.
<Noldorin> hi jelmer
<mkanat> mwhudson: With that adjustment, does the rest of the plan sound like what we want to do?
<maxb> What's the right API to turn a local pathname into an URL for Branch.open(...) ?
<mkanat> maxb: I've always just passed in the local pathname.... :-)
<Peng> maxb: IIRC there's something in urlutils, but if passing the local pathname works, just do that.
<Peng> If you don't care about errors caused by directories actually called "bzr+ssh" or whatever. :D
<mwhudson> urlutils.local_url_to_path
<mwhudson> er
<mwhudson> *from_path
<mkanat> mwhudson: Did you see my question above?
<mwhudson> mkanat: i think it sounds reasonable, yes
<mkanat> mwhudson: Okay, cool.
<knapsack> So my index is corrupt and I'd like to rebuild or repair it.
<knapsack> Unfortunately even the results of 'bzr dump-btree' on the indices aren't usable: bzr: ERROR: No such file: u'/home/knapsack/new/.bzr/repository/indices/e5041e9b52c7ccc987767381885f62eb.rix': [Errno 2]
<knapsack> Apparently this is referred to in the pack-names file, but doesn't exist. The repository itself is in a Dropbox folder, so may have been modified.
<knapsack> The answer at https://answers.launchpad.net/bzr/+question/96346 hasn't helped me, since I can't create any branches.
<knapsack> Any way for me to recover from this?
<lifeless> perhaps the file is in your dropbox history ?
<knapsack> Wow, lessee.
<knapsack> That worked.
<knapsack> Ever feel kind of embarrassed, but relieved and thankful at the same time?
<lifeless> Glad I could help
<lifeless> when you're in a crisis outsiders can often offer useful suggestions :)
<knapsack> lifeless: Absolutely. Thanks lifeless!
<lifeless> spiv: bug 517275 would be lovely to fix for james_w
<ubottu> Launchpad bug 517275 in bzr "bzrlib.merge do_merge has fragile cleanups" [Undecided,New] https://launchpad.net/bugs/517275
<spiv> lifeless: I'll take a look, sounds like my sort of thing :)
<mneptok> ugh. "fragile cleanups" reminds me i need to make a dentist appointment.
<lifeless> oh spiv, did I show you testrepository? I think you might have been on leave when I announced it
<spiv> lifeless: I think you mentioned it at least, although I haven't taken a look
<lifeless> spiv: ok, c ool
#bzr 2010-02-05
<mwhudson> hm
<lifeless> ?
<mwhudson> can't remember now :)
<mwhudson> oh right
<mwhudson> does anyone know git smart protocol well enough to use telnet to talk to a git server?
<lifeless> yes [I don't, but someone does]
<igc> morning
<buttons840> can i remove all unknown files from a directory?
<spiv> buttons840: bzr clean-tree
<buttons840> thanks
<jelmer> mwhudson, hi
<mwhudson> jelmer: hello
<mwhudson> jelmer: was poking at that libvdpau import failure
<mwhudson> jelmer: comments on the bug; i don't have any questions left any more :-)
<mwhudson> https://bugs.edge.launchpad.net/launchpad-code/+bug/445156 fwiw
<ubottu> Ubuntu bug 445156 in launchpad-code "vcs-import of libvdpau (git) fails: bzrlib.errors.BzrError: The remote server unexpectedly closed the connection" [Medium,Confirmed]
<jelmer> mwhudson, heh, ok
<lifeless> hmm, break-lock on lp failing to unlock.
<lifeless> mwhudson:d did lp recently have a rollout ?
<lifeless> bzr: ERROR: Server sent an unexpected error: ('error', "Cannot lock LockDir(lp-64863248:///~lifeless/tribunal/view-subunit/.bzr/branchlock): File exists: u'/srv/bazaar.launchpad.net/push-branches/00/04/a9/58/.bzr/branch/lock': [Errno 17] File exists: '/srv/bazaar.launchpad.net/push-branches/00/04/a9/58/.bzr/branch/lock'")
<mwhudson> lifeless: no
<lifeless> note that its failing to lock the *lock* dir, not 'held'
<mwhudson> well, unless spm is doing something with the cp i requested earlier
<lifeless> spm: ^
<lifeless> mwhudson: drwxr-xr-x    2 1001     1001         4096 Jan 14 03:54 lock
<lifeless>  ohh interesting.. note the lack of / between branch and lock on the first line.
 * lifeless wonders if someting messsy is happening
<mwhudson> jelmer: oh, i also remembered something i wanted to talk to you about
<mwhudson> jelmer: but i guess you are or at least should be asleep now; i'll send mail :-)
<jelmer> mwhudson, I'm actually still here
<mwhudson> jelmer: so about the incremental code import thing
<mwhudson> jelmer: i'm wondering about the best way to do it
<mwhudson> it's easy enough to go bazaar_tree.branch.pull(foreign_branch, overwrite=True, revno=local_revno + 1000) or something
<mwhudson> but you really need to know how many revisions there are in the remote branch so you can not error by overshooting and know when the import completed successfully
<jelmer> sorry, perhaps we should continue this over email indeed
<mwhudson> well, stop_revision = ...
<mwhudson> ok
<jelmer> I don't feel awake enough to think about this :-)
<mwhudson> fair enough :-)
<quotemstr> Wow.
<quotemstr> bzr check has been running on the Emacs repository for *three days*
<quotemstr> It's only about halfway done.
 * igc lunch
<twb> "bzr checkout --lightweight lp:dosage dosage" is still taking over two minutes to run.
 * spiv tries it
<twb> Is there any inter-repo caching or suchlike that I can enable?
<twb> I'm only checking out upstream sources so I can compile them -- that is, I only need to use bzr enough to say "get the latest working tree"
<spiv> Well, lightweight checkouts aren't designed to be very network efficient
<spiv> Which is a shame, but optimising that case hasn't been a big priority.
<twb> I'm using --lightweight because some years ago, I was told that was the most appropriate model for the workflow I described above.
<spiv> FWIW, it takes less than 43s for me.
<twb> spiv: you probably just have better throughput to lp
<spiv> Well, they might well be the most appropriate, but at the same time we might not have optimised your use case :(
<spiv> twb: possibly, although I'm on the other side of the world to the lp datacentre (I'm in Sydney, Australia)
<twb> I'm in .melb.vic.au, on internode ADSL2+
<spiv> exetel ADSL2 FWIW.
<spiv> I do see that bzr is making more round trips than it should, there is probably some low-hanging fruit there.
<spiv> Oh, are you using bzr+ssh or http?
<twb> spiv: I don't have an lp account, so I assume http
<spiv> i.e. have you run 'bzr lp-login'?  Ah.
<spiv> Ok, well that's going to be a large part of it.
<spiv> And there's probably not much improvement we can make in that case, really.
<twb> No worries.
<twb> I was just checking in to see if I was still doing it the bestest way
<spiv> Well, lp could provide a smart server over http, I suppose :)
<twb> I think hg does that by now
<spiv> But for plain http it's always going to be a bit slow.
<spiv> bzr has done it for ages, but for various mundane reasons lp hasn't deployed that yet.
<twb> Ah.  Stupid lp.
<twb> Does bzr employ a packing technique to speed up fetching over "dumb" protocols?
<spiv> (Partly because it's free and pretty easy to setup an lp account with an ssh key, so it's not hard to just use that and get all the benefits of bzr+ssh)
<twb> I do have an lp account, actually, I just haven't bothered to dig it out and tell bzr about it.
<twb> I only created it so I could talk to malone
<spiv> Not sure exactly what you mean by "a packing technique", but bzr does compress data and try to keep it in relatively few files in a way that reduces the number of roundtrips required to find and extract revision contents.
<twb> Well, supposing you basically have one file per revision, a "pack" will condense (say) all revisions between two tags into a single file.
<spiv> Right, we don't keep one file per revision, we generally keep roughly log(num of revisions) pack files.
<spiv> (Or something like that)
<spiv> e.g. look at http://bazaar.launchpad.net/~dosage-dev/dosage/trunk/.bzr/repository/packs/
<twb> The obvious benefit being that dumb protocols like HTTP are better at "give me that 10MB file" than "give me those 100 1kB files"
<spiv> Right.
<spiv> And bzr tries hard to use things like HTTP range requests where possible too.
<spiv> That particular repo has 833 revisions, but only 9 pack files as you can see.
<twb> How about HTTP/1.1 pipelining?
<twb> spiv: so the dosage guy could run some sort of "repack" command to improve new clone time?
<spiv> Not sure off the top of my head, although it might depend on whether you have pycurl installed or not (if not bzr uses urllib)
<spiv> twb: yes and no
<twb> Certainly libcurl can do pipelining, as long as you're using the "advanced" (not "simple") API.
<spiv> twb: in general, you can run 'bzr pack' to shrink a repo down to one pack file
<twb> (And running libcurl 7.19.1 or higher.)
<spiv> twb: but bzr autopacks regularly, so you shouldn't see a dramatic improvement from that most of the time
<twb> That's good to hear.
<spiv> twb: and in the case of a repo on Launchpad, the read-only copy of a repo you can see isn't the same as the writeable copy visible to the branch owner, so if the branch owner runs 'bzr pack' it won't affect the repo you're cloning from.
<spiv> (which is just a peculiarity of Launchpad, not bzr in general)
<spiv> And of course, if you're accessing a repo via the smart protocol, how many pack files there are is basically irrelevant.
<spiv> Because the client doesn't access them directly, it just asks the server to stream revisions to it.
<spiv> (Most of the time, but not for the 'checkout --lightweight' case yet because no-one has spent the time to optimise it like that yet...)
<spiv> twb: any other trivia about our internals I can help you with? :)
<twb> I think I'm good.
<twb> I tend to work mostly with git and darcs and hg, so it's interesting to compare notes.
<twb> Especially re. packing, since I'm involved in Darcs development and implementing packs is a goal for the next release.
<spiv> twb: yeah, they really are a massive performance win.
<spiv> twb: we didn't release 1.0 until a pack-based format was the default.
 * igc dinner
<vila> hi all
<lifeless> hi vila
<vila> hey lifeless, up late ?
<lifeless> yah
<lifeless> about to crash()
<vila> Is your sprint going well ?
<gerard_> bzr cleanhi
<gerard_> huh?
<gerard_> that bzr clean part must be from yesterday
<Toksyuryel> so is somebody gonna ban that guy or what
 * mneptok starts growing weary of this
 * mneptok jostles lifeless
 * mneptok summons staff
<Toksyuryel> You'd think with 123 people in the channel at least one would be on the access list
<jelmer_> none of them seems to be awake at the moment though
<jelmer_> poolie: ping
<chx> lifeless: hi
<vila> gerard_: jam should  review your patch soon (he's preparing 2.1.0rc3 so be patient :)
<gerard_> vila: good
<poolie> hello jelmer
<jelmer> poolie: hi - we were looking for an op to kickban welterde
<jelmer> poolie, he seems to be reconnecting every minute for the last couple of hours
<poolie> is it still happening?
<jelmer> poolie, just did :-)
<jelmer> poolie: depending on your client you should have a kickban command
<spiv> jelmer, poolie: if I'm reading /msg chanserv access #bzr list correctly, lifeless or abentley are your best bet.
<Peng> Well, so much for that.
<spiv> Ooh, K-Lined.
<AfC> I need disk space. Can I safely remove the 100s of MBs in .bzr/repository/obsolete_packs/ around and about?
<poolie> vila, i can be pilot next week if you want
<poolie> afc yes
<poolie> but only from tuesday
<poolie> maybe i'll just do it the week after
<jelmer> are imports from the upstream debian packaging branches considered part of UDD as well?
<jelmer> it's impossible to register imports for packaging branches at the moment :-(
<AfC> poolie: thanks
<Peng> AfC: It's only kept around in case the repo is packed and your computer loses power before the new files are written to the disk or something.
<vila> poolie: I'm ok to do it until Friday, you can start from there instead if that's fine with you
<vila> Friday next week I meant
<poolie> in other words the 12th?
<vila> exactly
<AfC> Peng: I had 700 MB across two projects where I'd done *nothing* but bzr-git checkout upstream. Brutal. Alas.
<maxb> Out of interest, if you ever did need to rescue a repository via moving in obsolete packs, what would you do with the pack-names file?
<Peng> maxb: My plan is to ask lifeless to summon a magic solution.
<maxb> heh
<Peng> Seriously.
<Peng> It'd be nice if obsolete_packs kept a copy of pack-names.
<napster> How to remove all the bzr tracked files from directory?
<sven_sandberg> hi! i'm pushing and pulling from a remote repo that uses format "1.14 or 1.9" (and bzr 1.17dev). locally, i'm using bzr 2.0.2 and repo format 0.92. would it be safe to upgrade to format 2a locally?
<jelmer> sven_sandberg, not unless you upgrade the remote repo to 1.14-rich-root or 2a
<sven_sandberg> jelmer, ok, thanks!
<Peng> You could upgrade to 1.9 or 1.14 for a mild performance and disk space improvement.
<sven_sandberg> Peng, thanks, i'll do that
<Peng> 2a would be much better, but you'd have to upgrade the remote repo too, as jelmer said.
<sven_sandberg> if i ask the maintainers to upgrade the remote repo to 2a, what is the minimal version that everyone else must upgrade their local repositories to first?
<rubbs> I believe it's >= 2.0
 * rubbs runs off to double check
<Peng> You'll need bzr 1.18 or so to interact with it.
<Peng> You could downgrade your repository all the way back to rich-root from, like, about 0.17, but that would be stupid, and you'd still need 1.18 to interact with the 2a repo.
<rubbs> I'd suggest everyone use 2.0 or above though. There are a lot of performance increases since that release.
<Peng> Indeed.
<rubbs> The current stable is 2.0.4
<rubbs> I've never had a problem with it.
<rubbs> and interacting with old repositories works just fine too.
<Peng> 2.0.4 mugged my parents when they were coming out of a restaurant!
<rubbs> ha
<sven_sandberg> Peng, rubbs, it wouldn't work to ask everyone to upgrade at the same time. is there a "safe path" of incremental compatible upgrades?
<sven_sandberg> like, would it work if everyone upgrade to 1.18, then remote upgrade to 2a, then everyone upgrade to 2a?
<Peng> The current format has poor roots. 2a has rich roots. So, no. Everyone has to upgrade to a rich-root format.
<sven_sandberg> Peng, ok
<sven_sandberg> Peng, are both directions problematic, or can i pull from poor to rich root?
<Peng> sven_sandberg: You can pull from poor to rich.
<Peng> sven_sandberg: It'll be a little slow, but whatever.
<rubbs> yes you can pull
<rubbs> but you can't push
<sven_sandberg> ok, good
<rubbs> and you can merge from poor to rich IIRC
<Peng> Rich root formats store a little bit of extra meta data, so it's impossible to push back to a poor format.
<rubbs> so you could almost create a mirrored rich repo
<rubbs> but you could run into some issues that way
<Peng> rubbs: Merging shouldn't be a problem. There might be stupid bugs breaking it -- I dunno -- but they could be fixed.
<rubbs> Peng: that's what I was thinking.
<rubbs> maybe as a "steping process" you could mirror any changes made in the poor to the rich. and make the rich the new target for dev. Until everyone has upgraded.
<rubbs> then you can just merge in the changes from the "old" repo
<rubbs> pretty messy though.
<rubbs> One thing to do might be to have everyone use the poor repo and start upgrading.
<rubbs> and say in two weeks the repo will be changed to the new format
<rubbs> that gives everyone some time to get upgraded
<rubbs> just some ideas
<Peng> Upgrading to rich roots is a pain no matter what. Hopefully we'll only have to do it once!
<sven_sandberg> rubbs, thanks. i think it wouldn't work when someone starts pushing from their rich trees though?
<sven_sandberg> i mean from the local rich trees. they'd have to push to the remote rich trees, so people who are still using poor wouldn't be able to access the changes
<rubbs> sven_sandberg: correct, my first idea actaully kind of sucks.
<rubbs> but you can force 2.x to use a poor repo
<Peng> sven_sandberg: You're correct.
<rubbs> so maybe get everyone to switch to 2.x but use poor local repos
<rubbs> until you are all ready to switch
<Peng> Sure, 2.0 doesn't automatically upgrade stuff.
<sven_sandberg> rubbs, do you mean bzr version 2.x or is there a repo version 2.x?
<maxb> Unfortunately unless you're specifically aware of the rich-root problem, it's incredibly easy to accidentally create a rich-root repository locally with 2.x
<Peng> It's worth noting that "bzr init-repo" and "bzr init" will use 2a by default.
<Peng> But you can do "bzr init-repo --dirstate" if you like painful old formats.
<Peng> Or, you know, --1.9 or whatever. :P
<rubbs> true
<sven_sandberg> rubbs, not sure i get it... do you mean it would work if everyone upgrade to bzr 2.x but keep repositories poor, then upgrade remote to 2a, then upgrade everyone's local repo format to 2a?
<rubbs> sven_sandberg: sorry I meant client (bzr) version 2.x
<rubbs> sven_sandberg: correct. Everyone upgrade clients to 2.x, but keep local and remote repos poor( this will take some coordination). Then when everyone has upgraded bzr, then upgrade the remote repo, then upgrade local repos
<rubbs> the problem comes that 2.x (bzr) will by default create a 2a (rich) repo. So you'll have to make it clear that if they wish to init a repo they ahve to explicitly make it a poor repo
<sven_sandberg> rubbs, cool! that actually seems doable. i think almost everyone is using a shared repository anyways, so we're never running bzr init
<rubbs> I'd run some backups too just to be safe
<MvG> FYI: I've just make a bzr-bash-completion release---the first ever, version 1.0.0.
<MvG> So anyone of you frequently using bash to enter bzr commands might consider getting a copy to get proper completion of command options.
<Peng> The danger is creating a new repo with "bzr init-repo".
<bialix> scary
<Peng> bialix: You had to use CVS?!
<Peng> Sorry.
<bialix> have used TortoiseCVS in the past
<bialix> hi Peng, and all bzr
<rubbs> sven_sandberg: I'd possibly clone everything to a test directory and do some testing with that workflow, but I think that should work.
<bialix> but I never created CVS repo with bzr init-repo
<rubbs> sven_sandberg: at least it should in theory. I'm pretty sure otherhave done it too.
<rubbs> bialix: hello
<bialix> hi rubbs
<Peng> bialix: I was just joking. What's scary?
<sven_sandberg> rubbs, good idea. yes, i'll suggest that
<sven_sandberg> rubbs, Peng, thanks a lot
<bialix> Peng:the first thing I saw when connected was: `The danger is creating a new repo with "bzr init-repo".` It was scary. What's dnager?
<bialix> *danger
<Peng> bialix: Ahh. From my client's point of view, you joined after I said that.
<Peng> bialix: The danger is that you'll unintentionally upgrade to 2a.
<bialix> no, I don't. I have format1 plugin
<Peng> Heh.
<bialix> yep, it's not funny
<poolie> vila, hi?
<vila> poolie: hey
<poolie> vila, does scriptrunner not allow whitespace before the commands?
<poolie> in other words they can't be indented?
<vila> possibly, I don't think there is a good reason for that though
<poolie> k
<vila> poolie: quick look at the code seems to even reveal that as long as the prefix is there ($) we shouldn't care about the leading spaces (we use split))
<vila> poolie: so just try indenting them leaving the $ at the beginning
<poolie> vila, also, is there something strange about its handling of blank lines_
<vila> poolie: they are ignored ?
<vila> poolie: they are ignored.
<vila> poolie: is that what you feel strange ?
<poolie> hm
<poolie> it looks like if there is a blank line in the output, the only way to make it match is to put a '...'
<poolie> which is a bit gross?
<vila> rhaaa, damn, I knew there was a trick about prefixing the *commands* instead of the output :-/
<vila> poolie: file a bug ?
<vila> poolie: looking at the code, there is another potential problem if # are needed in the input or the output lines (they will be considered as comments)
<vila> poolie: may be a good time to use a parser a bit less spartan and be able to report line numbers on errors too
<poolie> vila, i think giving a diff across the whole thing would be good
<vila> poolie: ECONTEXT
<vila> a diif of the script ? against what ?
<poolie> of the expected output against the actual output
<poolie> oh but i see what you mean
<poolie> at what point in the script did it fail?
<poolie> good question
<vila> yeah, I've already encountered ambiguous cases where only the *line* can help, and even there, ideally we are not interested of the relative line into the script but by the line in the file where the script is inlined with """ """
<vila> but once the first problem is addressed te second one is more about finding a python trick to avoid forcing the user to provide the starting line
<bialix> hi poolie, vila
<vila> hey bialix
<bialix> anybody knows the status of abentley work of adding less than hunk shelving support?
<poolie> vila, what do you think of https://code.edge.launchpad.net/~gerard-/bzr/update/+merge/18464
<abentley> bialix, it landed.
<bialix> abentley: I don't see it in 2.1.0rc1?
<vila> poolie: I asked jam to review it as I was surprised by the simplicity of the fix and was wondering if I was missing something obvious
<abentley> bialix, it landed in 2.1.0b3
<bialix> abentley: there is nothing in shelve --help, and interactive short help does not suggest anything
<bialix> what I'm missing then?
<abentley> You need to specify a "change_editor" in your config, e.g. "change_editor = vimdiff -fo @new_path @old_path"
<bialix> what this command line means?
<bialix> I don't use vimdiff
<bialix> is there some documentation on this feature available?
<bialix> or this feature is not supposed to be used by mere mortals?
<bialix> abentley: ^ ?
<bialix> anybody?
<abentley> bialix, "vimdiff -fo" is vimdiff-specific.  "@new_path" is replaced with the path of the new version of the file, "@old_path" is replaced with the path of the old version of the file.
<abentley> bialix, please give me a chance to answer your question before becoming frustrated.
<bialix> there is bug: if I press ? then long short help does not mention editor, and pressing e don't launch it. Should I file it?
<abentley> bialix, there isn't any documentation at the moment.  The feature is meant to be used by mere mortals.
<abentley> bialix, have you configured a change editor?
<bialix> I'm trying
<bialix> bzr traceback all the time
<bialix> because there is windows path
<abentley> If an editor is configured and e is not shown, that would be  a bug.
<abentley> specifically, change_editor must be configured for e to be shown.
<bialix> ok, I finally found the right combination for windows path and it launch winmerge for me.
<bialix> abentley: e is not expanded after I press ?
<bialix> see: Shelve? [yNefq?]
<abentley> bialix, you're right, the expanded help is buggy.
<bialix> after ?: Shelve? [(y)es, (N)o, (f)inish, or (q)uit]
<bialix> now I press `e` and it going for next hunk
<bialix> abentley: so I need to edit @new_path to the state I want it to be after shelving, right?
<abentley> bialix, right.
<bialix> I will file a bug about ?
<bialix> abentley: thanks for explanation
<abentley> bialix, np
<quicksilver> sftp branches in 30 seconds, bzr+ssh takes 4 minutes
<quicksilver> expected?
<quicksilver> I thought bzr+ssh was more efficient.
<bialix> abentley: https://bugs.launchpad.net/bzr/+bug/517652
<ubottu> Ubuntu bug 517652 in bzr "bzr shelve with editor support: short hunk help lists "e" but long help does not" [Undecided,New]
<vila> quicksilver: not expected file a bug with your .bzr.log, the server one and possibly some ls -lR of the .bzr/repository on both the client and server
<vila> quicksilver: which bzr version ?
<quicksilver> vila: 2.0.3 locally; just checking the remote version
<quicksilver> 2.0.2 remotely
<vila> quicksilver: repo format ?
<vila> quicksilver: repo format for client and server ?
<quicksilver> pack-0.92 hmm that's a surprise
<quicksilver> obviously this one is an old one we didn't upgrade yet
<vila> quicksilver: on both sides ?
<vila> quicksilver: see, bzr is nice with you, only it didn't find the right words, it was working happily instead ;-)
<quicksilver> ah ok
<quicksilver> so the thing is, sftp just uses the remote format
<quicksilver> so the sftp version was pack-0.92 locally
<vila> quicksilver: I think there is a warning now about conversions on-the-fly but it may be in 2.0.4 or even 2.1
<quicksilver> but bzr+ssh hybrises it
<quicksilver> hybridises it, I mean
<quicksilver> so the bzr+ssh ends up as unamed (1/6/6/knit)
<quicksilver> vila: I should upgrade it remotely and see if that helps?
<quicksilver> s/remotely/at the remote end/
<vila> certainly
<quicksilver> ok, doing that. Will report new results in a moment.
<poolie> vila, could you try to pilot it soon?
<vila> what ?
<quicksilver> vila: 7 minutes to upgrade! Now testing branching.
<gerard_> bye
<vila> poolie: which patch  ? gerard_'s one ?
<vila> hu ho, is that related ?
<quicksilver> vila: still looks slow. "372KB/s"
<lifeless> moin moin
<quicksilver> vila: sftp was attaining more like 12000KB/s; this is a local 100M network
<vila> quicksilver: ha ha !
<vila> quicksilver: ok, well, bzr+ssh is better than sftp when the bandwith and latency are... closer to the internet ones than a local one
<quicksilver> vila: OK, it's slightly better with the new repo format
<quicksilver> btu still a big difference
<quicksilver> 38 seconds for sftp, 3:14 for bzr+ssh
<vila> hmm
<quicksilver> over 3 minutes is a long time to copy a branch :-/
<quicksilver> I *am* in a shared repo locally, I guess that gives it a little more work to do.
<vila> quicksilver: I think it's worth reporting your numbers if only to help reproduce the case for a next round of performance tuning
<quicksilver> OK. Will do. Thanks.
<quicksilver> with a little care I suppose I can do initial branches via sftp and make commits/pushes via bzr+ssh
<vila> quicksilver: wait, if your local shared repo is already populated, branch should be fast and as fast for sftp than for bzr+ssh
<quicksilver> local shared repo should have all but one or two of the revisions, yes
<quicksilver> it was a "very similar" branch I was checking out
<poolie> vila, yes
<vila> wow, try -Dhpss and look at .bzr.log
<quicksilver> well, and for my second and subsequent checkouts *all* the revisions would be there
<quicksilver> after all, I just did one!
<vila> poolie: jam told me he'll review it yesterday
<vila> poolie: I'll check with him
<quicksilver> vila: I don't think my shared repo is working correctly.
<quicksilver> vila: how do I check?
<vila> bzr info
<poolie> he's away at the moment
<quicksilver> vila: I guessed :) but what is the magic word I'm looking for?
<vila> quicksilver: repository branch linbe
<vila> quicksilver: repository branch line
<vila> and shared repository line
<quicksilver> vila: OK. I think I broke it all. No idea how. Building a new repo which is really shared and testing again.
<vila> poolie: rats just found jam's mail :-/
<quicksilver> don't let the rats into your mail! They'll ruin it.
<vila> yeah add a comma after them :D
<poolie> :)
<quicksilver> vila: YAY
<quicksilver> vila: with shared-repos working properly it takes 7 seconds
<quicksilver> vila: (either sftp or bzr+ssh)
<vila> quicksilver: ha, better
<vila> quicksilver: you had standalone branches under your shared repo ?
<quicksilver> vila: my shared repo wasn't shared at all; no idea how I broke it
<quicksilver> vila: it's literally as if I accidentally rm -rf'ed the .bzr directory
<quicksilver> vila: quite mystified but I'm glad it all works now.
<vila> scary
<quicksilver> vila: thanks again :)
<vila> quicksilver: ;D
<lifeless> hi poolie
<lifeless> vila
<orattue> Hey, my repo is running revno 105. My web server checkout is running 99. I want to update to 102. bzr update can't be passed a revision number. I can't update a specific file to the latest revno like you can in svn. What's the best way to do this?
<gerard_> orattue: use merge?
<jpds> orattue: bzr [pull|merge] -r 102?
<gerard_> the latest development version adds -r support to update btw
<orattue> gerard_: yeah -r parameter on update is a really useful one
<doctormo> How can I check if a --fixes= has worked, before I upload the code?
<lifeless> doctormo: bzr log
<doctormo> lifeless: I can't see any fixes metadata in the log I'm seeing, what does it look like?
<lifeless> you may have a too-old bzr
<lifeless> or I may be imagining
<lifeless> hang on
<lifeless> fixes bug(s): https://launchpad.net/bugs/513432
<ubottu> Ubuntu bug 513432 in launchpad-code "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Critical,Confirmed]
<lifeless> ^
<doctormo> lifeless: So you check the bug in launchpad to see if the --fixes has been attached?
<lifeless> doctormo: huh? what are you asking
<lifeless> What I pasted was output from bzr log
<doctormo> lifeless: I've done a commit with --fixes=lp:123 and I want to confirm that the meta data for the fixes is there in my local repository
<lifeless> run bzr log and look for 'fixes bug'
<lifeless> if you have an old bzr this may not show
<lifeless> but its not something that *can* fail
<lifeless> it goes into the rev object, so commit fails if you have an unknown bugtracker
<doctormo> lifeless: Anything I can look at if I'm using an old bzr? 2.0.3 btw
<luks> if you have qbzr installed, try bzr qlog
<doctormo> thanks luks, that's shows fixes and shows my code didn't work :-D
<doctormo> luks: Are you involved in the devel of qbzr?
<luks> doctormo: kind of, I started the project, but I'm not very active anymore
<chx> hi. is there something like "glip, the git library in PHP, provides read and write access to Git repositories without using exec() or system() calls. Therefore it works on many shared web hosting accounts." for bzr? people want to push git and i need to push back :)
<NeverGone> hello
<NeverGone> somebody?
<rubbs> hello,
<rubbs> unfortunatly I have to go, but others here can help you if you have a question.
<NeverGone> :)
<doctormo> NeverGone: somebody isn't here, perhaps I can help?
<doctormo> luks: I wanted to remark upon gbzr's good design, it seems better than bzr-gtk and olive.
<NeverGone> my problem: bazaar and localised (hungary) windows
<doctormo> NeverGone: Such as? and are we talking about bzrgtk, bzr or bzrlib?
<NeverGone> http://ggg.pastebin.com/d65785178
<NeverGone> bazaar 2.0 and 2.1, standalone installer
<doctormo> NeverGone: According to that, you've not done a "bzr init"
<NeverGone> ?
<doctormo> NeverGone: Or it could be that bzr has freeked out because of the Ã³
<NeverGone> hm
<Paal> hi
<NeverGone> Paal: http://ggg.pastebin.com/d65785178
<NeverGone> this is error
<NeverGone> bazaar (or python) and localised windows
<NeverGone> i found: https://bugs.edge.launchpad.net/bzr/+bug/340394
<ubottu> Ubuntu bug 340394 in bzr "want an option to set the output encoding, especially on win32" [Medium,Confirmed]
<NeverGone> and https://answers.edge.launchpad.net/bzr/+question/63601
<NeverGone> but not help
<Paal> yes, but if I use the letters without accentuated, I have one other error message
<Paal> check this: http://drupal.pastebin.com/d2e55a864
<Paal> I try to use the Bazaar 2.0.4 stable
<NeverGone> good night...
<Paal> bye
#bzr 2010-02-06
<mwhudson> holy cow bzr-svn's "discovering revprop revisions" is slow
<meoblast001> hi
<meoblast001> i need some advice from you version control pros
<meoblast001> if you guys like to be called that
<meoblast001> i've been writing a program, it's about 20 commits in, written in C
<meoblast001> i just finished moving it to C++, would you guys recommend starting a whole new repository or just committing it to the current
<Peng> Are you, like, replacing the C version, or do they both exist at once?
<Peng> And...do they share any code at all?
<Peng> I mean, is it a rewrite from scratch, or a conversion?
<meoblast001> i'm replacing the C version
<meoblast001> it is a conversion, but i'm assuming >50% of the lines have been changed
<meoblast001> probably >80%
<meoblast001> regardless, they share the same concepts and design, just in C++ now
<Peng> Um, I'm about to go to sleep, and I'm honestly not sure.
<Peng> I could go either way. I'd probably keep it in the same branch.
<spiv> Without thinking about it hard, a) I'd probably just keep using the same repo (after all, why not?), and b) I doubt it matters much anyway.
<meoblast001> i know this will bloat the repository size a lot
<meoblast001> but history is good
<Peng> Yes, history is good.
<Peng> meoblast001: And unless this is a Linux kernel-sized project, relatively large history is still not very much.
<Peng> I mean, who cares if it's 120 KB instead of 70 KB?
<meoblast001> yeah
<spiv> I say point b) because 20 commits worth of history isn't really going to be that large in the long term so it's not going to bloat much at all, but at the same time hardly anyone is going to care about the first 20 commits in the long term either.
<spiv> Hence why I default a), because that's the path of least resistance :)
<spiv> (It'd be neat to have some way to measure how often old revisions *are* directly accessed...)
<meoblast001> spiv: since you already know what i'm doing, i have another question for you
<meoblast001> how would you word this commit
<meoblast001> "Ported to C++"?
<meoblast001> i can't think of words that can discribe this
<spiv> meoblast001: sure.  Or "rewrote", or whatever you feel describes the change adequately.
<meoblast001> spiv: is "port" an appropriate word for changing languages
<meoblast001> and i didn't completely "rewrite" it
<spiv> Appropriate enough.
<spiv> I don't think commit messages are something to sweat over, especially not in the early days of a project.
<spiv> You want something that will make some sense to you (or another person) that is looking back at 'bzr log', etc, for some reason.
<spiv> Or at least enough sense that they can say "oh, ok, that's not the revision I'm looking for".
<meoblast001> yeah, i'm sort of a perfectionist :P
<meoblast001> oh, one of you told me once that you had a hook that a BZR server runs to have an IRC bot alert about commits
<meoblast001> which of you was it
<meoblast001> i lost the file
<meoblast001> if i'm not here when whoever it was sees this, feel free to use memoserv
 * shyam trying to get a copy of color-theme project from savannah.. loggerhead seems down at savannah..:(
<shyam> bzr branch http://bzr.savannah.nongnu.org/r/color-theme says "http://bzr.savannah.nongnu.org/r/color-theme/ is permanently redirected to http+urllib://bzr.savannah.gnu.org/r/color-theme/ \n bzr: ERROR: Not a branch: "http+urllib://bzr.savannah.gnu.org/r/color-theme/"
<shyam> what could be the problem?
<shyam> i tried bzr branch sftp://username@bzr.savannah.nongnu.org/srv/bzr/color-theme where username is my savannah username though am not a member of color-theme project. that too said bzr: ERROR: Not a branch: "sftp://swathanthran@bzr.savannah.nongnu.org/srv/bzr/color-theme/".
<spiv> shyam: add 'trunk' to the URL
<spiv> shyam: if you look at it in a web browser there's no .bzr directory there, but there's a trunk directory which does have a .bzr directory
<shyam> uh! thats the last one thing i didn't do! visit the url in a browser!
<shyam> spiv: thanks!
<spiv> I just tested, and http://bzr.savannah.nongnu.org/r/color-theme/trunk/ works for me
<shyam> yeah, now it works here too
<shyam> is it usual to have a trunk subdirectory?
<shyam> it looks like for some other projects too..
<spiv> It's usual to have, or at least allow for, multiple branches for a project.
<spiv> So the structure of .../proj/branch is pretty common, and 'trunk' is a common name for the primary branch.
<shyam> oh ok.. but other projects do have a .bzr at bzr.savannah.nongnu.org/r/project-name/
<spiv> Do they have other directories too?
<shyam> yeah
<spiv> A .bzr directory doesn't necessarily mean there's a branch there, it can also be a "shared repository" for the branches inside that directory.
<spiv> (And the upcoming bzr 2.1 release should give a slightly more informative error if you do attempt to branch from a location that iss a repository and not a branch)
<shyam> yeah i saw a group of bug lists while scroogling for it..
<shyam> spiv: what is missing here? how to make it work on bzr.savannah.nongnu.org/r/color-theme ?
<chx> heya.
<gerard_> hey
<gerard_> how about I just add a "text" parameter to assertFileEqual?
<gerard_> I really don't care for \r\n most of the time
<gerard_> I guess I'll leave it until I run into problems on windows
<gerard_> #&^$*&^@# line endings
<gerard_> ;)
<bialix> gerard_: usually in test suite files created with binary flag and LF endings
<gerard_> bialix: oh good
<alefteris> hi all! I did a bzr pull a file didn't change because of wrong permissions, now I fixed the permissions, but can't get the file up to date, tryed bzr pull and bzr revert without luck
<alefteris> nevermint, bzr update did the trick
<gerard_> mmm, test driven development
 * gerard_ likes it
<justdave> if I have a branched checkout and I move an existing tag, is there a way to get that tag move to go upstream with the push?  It pushes all my revisions, but gives me an error that there's a tag conflict instead of pushing the tag change.
<jpds> justdave: bzr push --overwrite ?
<justdave> that works, thanks
<justdave> if I try to push and there's been other revisions upstream since I last pulled, will it error that I'm out of sync, attempt to merge, or overwrite the other revisions?
<Peng> "bzr push --overwrite" overwrites.
<justdave> yeah, that's why I was asking.  :)  So I want to be careful not to use that unless I know I have an otherwise up-to-date copy. :)
<Peng> Yeah. I'm not sure if there's a (simple) way to just overwrite tags while preserving revisions.
<RenatoSilva> if I merge 5 revisions, and use --forget-merges, will I get 5 new revisions in the main level or will them all be compacted as 1 single revision?
<RenatoSilva> RenatoSilva: the latter
<RenatoSilva> RenatoSilva: oh thanks
<lifeless> justdave: Peng: there isn't a 'push tags only' UI at the moment.
<Peng> Other than "scp -p .bzr/branch/tags". O:)
<mkanat> I wonder if scp works when the shell is bzr serve.
<mkanat> Probably does, I suppose.
<mkanat> There's always hitchhiker, if not.
<lifeless> scp won't
<lifeless> sftp will
<lifeless> (sftp is a subsystem)
<lifeless> although, its possible scp uses the sftp subsystem but I don't think it does
<lifeless> besides which, bzr won't work if bzr serve is the shell
<chx> heya
<gerard_> ahhh
<gerard_> I FINALLY understand the inner workings of bzr update
<gerard_> it only took two weeks
<gerard_> :p
<slestak> hi guys, I am trying to use the push_and_update plugin for a new repo based on the BazaarForWebDevs use case.
<slestak> i am running into the same issue as Sean from the bzr answers page
<slestak> i have don the initial import and update, however, new pushes are failing
<slestak> i have tried with --use-existing-dir but that didnt help
<slestak> new pushes say: bzr: ERROR: [Error 2] The system cannot find the file specified
<slestak> i have tried with the cached path, i have tried specifying the path with and without trailing slashes
<slestak> i have also tried with the plugin installed only locally and also with the plugin installed locally and remotely
<chx> oh nice, you have a parent_location in branch/branch.conf so nothing mandates a shared repo to be kept under one directory. Nice!
<chx> is it enough to edit just that one file and then I can move the directory freely?
<justdave> 15:02:16 < lifeless> besides which, bzr won't work if bzr serve is the shell
<justdave> ours is set up that way and it does.
<justdave> although technically, the shell is a python stub that launches bzr serve
<justdave> so whether scp would work would depend on that python stub I suppose
<justdave> it's run via ForceCommand in sshd_config, and if you're root it runs bash, and any other user gets bzr serve
<RyNy_> Hi, I issued a commit command after adding a directory and now Bazaar can't access the lock file for other commands.
<RyNy_> Get this error: Unable to obtain lock file:///.bzr/branch/lock
<RyNy_> Any ideas/help? The directory that I added was on LAMP and holds drupal.
<RyNy_> I'm using Terminal on my Mac to work with Bazaar on my server.
<RyNy_> The drupal folder that I added is 30MB in size.
<Peng> The branch is locked? Is bzr still running?
<RyNy_> I think so. I just broke the lock and tried the same commit and it seems to be hanging again.
<Peng> That'd explain it, yes. :P
<RyNy_> Do you know what's going on? Why is it hanging?
<RyNy_> This is the error I get:
<RyNy_> bzr commit -m "Added a bunch of modules"
<RyNy_> Committing to: /
<RyNy_> added var
<Peng> That's not an error. :P
<RyNy_> Is it just processing?
<RyNy_> How long does it take to add a directory that's 30mb in size?
<Peng> Dunno. Not that long.
<RyNy_> Before I broke the last lock it was running for 2 hours.
<Peng> Yeah, not that long...
<RyNy_> So, something weird is happening?
<Peng> Yeah. No idea what, though. Maybe an strace would help? Or various -D options?
<RyNy_> don't know those commands ...
<RyNy_> idea: can having 2 .bzrignore files screw things up?
<Peng> Bazaar only cares about /.bzrignore. I imagine it completely ignores others.
<Peng> RyNy_: Does .bzr.log contain anything interesting? Sorry, I don't know much about debugging this.
<Peng> RyNy_: What version of bzr?
<RyNy_> Bazaar 2.0.4
<RyNy_> This is the most recent entry in the log
<RyNy_> Sat 2010-02-06 23:39:22 +0000
<RyNy_> 0.080  bzr arguments: [u'version']
<RyNy_> 0.114  looking for plugins in /root/.bazaar/plugins
<RyNy_> 0.230  looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
<RyNy_> 0.287  encoding stdout as sys.stdout encoding 'UTF-8'
<RyNy_> 0.425  opening working tree '/'
<RyNy_> 0.472  Traceback (most recent call last):
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 842, in exception_to_return_code
<RyNy_>     return the_callable(*args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1037, in run_bzr
<RyNy_>     ret = run(*run_argv)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 654, in run_argv_aliases
<RyNy_>     return self.run(**all_cmd_args)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1052, in ignore_pipe
<RyNy_>     result = func(*args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3510, in run
<RyNy_>     show_version(to_file=self.outf)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/version.py", line 42, in show_version
<RyNy_>     src_revision_id = src_tree.last_revision()
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree.py", line 1789, in last_revision
<Peng> Eek
<RyNy_> sorry
<Peng> That's just from running "bzr version" (and apparently it failed somehow).
<RyNy_> Sorry, don't understand
<Peng> That log snippet isn't about the command that failed. It's just from running "bzr version".
<RyNy_> thanks, running commit again. It's hanging again. Here's the log. Look fine:
<RyNy_> 0.474  preparing to commit
<RyNy_> [32216] 2010-02-06 23:51:14.878 INFO: Committing to: /
<RyNy_> 0.482  Selecting files for commit with filter None
<RyNy_> [32216] 2010-02-06 23:51:14.943 INFO: added var
<RyNy_> Is there a way to "unadd" something from Bazaar
<Peng> RyNy_: bzr rm (which has an argument to not delete stuff), or bzr revert if it hasn't been committed yet.
<RyNy_> Thanks, so to remove a directory "var"
<RyNy_> bzr rm var
<Peng> Uh-huh. Or "bzr revert var" if it hasn't been committed yet.
#bzr 2010-02-07
<RyNy_> thanks, ok I reverted fine, but same problem. Added drupal and then tried a commit and it freezes.
<Peng> Hit Ctrl+C. What's the traceback, and what does .bzr.log contain?
<RyNy_> here's the log
<RyNy_> The logs 50 lines. Should I paste it?
<RyNy_> Ok, here it is. The directory I'm trying to commit is called "Pressflow:
<RyNy_> "Pressflow"
<RyNy_> Sun 2010-02-07 00:04:10 +0000
<RyNy_> 0.078  bzr arguments: [u'commit', u'-m', u'Pressflow added, initial commit']
<RyNy_> 0.121  looking for plugins in /root/.bazaar/plugins
<RyNy_> 0.227  looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
<RyNy_> 0.293  encoding stdout as sys.stdout encoding 'UTF-8'
<RyNy_> 0.432  opening working tree '/'
<RyNy_> 0.452  preparing to commit
<RyNy_> [32516] 2010-02-07 00:04:11.319 INFO: Committing to: /
<RyNy_> 0.481  Selecting files for commit with filter None
<RyNy_> [32516] 2010-02-07 00:04:11.393 INFO: added var
<RyNy_> 214.781  Traceback (most recent call last):
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 842, in exception_to_return_code
<RyNy_>     return the_callable(*args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1037, in run_bzr
<RyNy_>     ret = run(*run_argv)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 654, in run_argv_aliases
<RyNy_>     return self.run(**all_cmd_args)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 3058, in run
<RyNy_>     exclude=safe_relpath_files(tree, exclude))
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
<RyNy_>     result = unbound(self, *args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 197, in commit
<RyNy_>     result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
<RyNy_>     result = unbound(self, *args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/mutabletree.py", line 229, in commit
<RyNy_>     *args, **kwargs)
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 360, in commit
<RyNy_>     self._update_builder_with_changes()
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 633, in _update_builder_with_changes
<RyNy_>     self.work_tree, self.basis_revid, iter_changes):
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 637, in record_iter_changes
<RyNy_>     for change in iter_changes:
<RyNy_>   File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 654, in _filter_iter_changes
<RyNy_>     for change in iter_changes:
<RyNy_>   File "_dirstate_helpers_pyx.pyx", line 1410, in bzrlib._dirstate_helpers_pyx.ProcessEntryC.__next__
<RyNy_>   File "_dirstate_helpers_pyx.pyx", line 1683, in bzrlib._dirstate_helpers_pyx.ProcessEntryC._iter_next
<RyNy_>   File "_dirstate_helpers_pyx.pyx", line 1782, in bzrlib._dirstate_helpers_pyx.ProcessEntryC._loop_one_block
<RyNy_>   File "_dirstate_helpers_pyx.pyx", line 1107, in bzrlib._dirstate_helpers_pyx.ProcessEntryC._process_entry
<Stavros> hello
<Stavros> is there a way to export my current working tree as an archive?
<Stavros> sort of like bzr export, but for uncommitted changes
<Kamping_Kaiser> RyNy_: please don't paste like that in the channel
<RyNy_> sorry, what's the best way to share a log file??
<Stavros> RyNy_: dpaste.com
<RyNy_> Stavros: thanks, will use this from now on
<Stavros> any idea how i can export uncommitted changes?
<gerard_> Stavros: how about "bzr diff"?
<gerard_> Stavros: or did you only add files?
<Stavros> gerard_: i did add some files as well, yes
<Stavros> i'd like to transfer everything so i can continue working on a different machine
<gerard_> Stavros: you should push to a (private) branch then
<Stavros> i'd need to commit for that, and i don't want to commit unfinished work
<gerard_> Stavros: how often do you commit?
<gerard_> I usually commit twice every hour
<Stavros> as often as i'm done working on a feature
<Stavros> this one is a large one
<Stavros> usually it's not a problem
<gerard_> ok
<gerard_> how about you commit and then uncommit when you resume working?
<Stavros> doesn't that preserve my commit somewhere?
<Stavros> i always see uncommit mention something about a tip
<gerard_> yeah, you can "undo" an uncommit
<gerard_> the head is saved (bzr heads --all will show it)
<Stavros> hmm, can i remove it?
<gerard_> why would you?
<gerard_> it will not be pushed anyway
<Stavros> oh
<Stavros> that's fine then, thanks
<Stavros> so it's safe to store private info there?
<Stavros> say, if i accidentally include a password in a file
<Stavros> is it safe to uncommit or do i need to scrap the repo?
<gerard_> hmm
<gerard_> I think that uncommit and then pack and then removing the obsolete packs will also clean it up
<gerard_> I'm not too sure though
<Stavros> hmm, i'll try that and see, thanks
<RyNy_> Peng: Ok, I basically started over, deleted the .bzr directory and am able to commit fine now. Weird
<RyNy_> General question: is it ok to add a whole LAMP server under version control. At this point I'm not collaborating with anyone but want to use VC to checkpoint good known states of the LAMP install.
<RyNy_> Or would it be better to break up my add commands to individual directories?
<gerard_> RyNy_: it's all just textfiles right?
<gerard_> you can add them all in one go
<gerard_> it's not that useful to have a commit with only half of the files needed to run the thing
<RyNy_> gerard_: yes, all text files for now.
<RyNy_> I plan on running Drupal so there will be images sometime soon.
<gerard_> I think it's best to just put the configuration under version control
<RyNy_> I could use the .bzrignore file to ignore the images directory of Drupal
<gerard_> yeah it depends on if you want to be able to restore them....
<RyNy_> gerard_: thanks. so, I tried to add the whole server and got this error: http://dpaste.com/155621/
<RyNy_> I was having problems all day trying to add the same directory var/www/pressflow.
<gerard_> what?
<gerard_> that looks weird
<gerard_> adding dev/.udev/db/\x2fblock\x2fram0
<gerard_> you sure you are not adding /dev ?
<RyNy_> I tried to add the server and then it crashed.
<RyNy_> I was at / and issued the command bzr add
<gerard_> hmm, that's not what you want
<gerard_> I guess you'd just want to put /etc and /var/www under version control
<gerard_>  /dev contains the special files
<gerard_>  /dev/mem is a virtual file that points to your ram
<gerard_> quite hard to version control that one....
<gerard_> and there is lots more there
<RyNy_> I can't find that directory. Where's dev/
<Peng> RyNy_: Did you keep a copy of the old data? It would be nice if someone could debug it.
<RyNy_> Peng_: Yes
<RyNy_> Ok, I found dev it's at root. I will try to include that in the ignore file and see what happens
<RyNy_> Peng_: If you want the log let me know. Happy to post it somewhere.
<Peng> Adding your entire computer seems like a very bad idea.
<Peng> Aside from all the special stuff like /dev and /proc, who cares about /usr/lib?
<fullermd> Vesta?   8-}
<RyNy_> thx
<RyNy_> Sorry for the basic question, but I take it that /etc  gets customized a lot?
<Peng> Sure, versioning /etc is a good idea. Check out etckeeper.
<quotemstr> Oh my god.
<quotemstr> 'times' for bzr check: 3664m48.353s 1118m2.436s
<Kamping_Kaiser> o_0
<quotemstr> That's on Emacs.
<Kamping_Kaiser> wow
<lifeless> quotemstr: check is not tuned as much as [say] commit :)
<Peng> Also it has SETI@home embedded. ;-)
<Kamping_Kaiser> hehehe
<lifeless> Peng: something for everyone
<johnjosephbachir> how do i update a checkout to a particular version? (if that's possible). 'updated' does not have an -r options....
<Kamping_Kaiser> pull -r or merge -r?
<johnjosephbachir> okay
<johnjosephbachir> that will work for a checkout?
<johnjosephbachir> (i know, i should test it... i'm kind of in a jam right now is the thing)
<Peng> BTW, update recently gained a -r argument.
<Peng> (It's in 2.1.0rc1; dunno about 2.0.)
<johnjosephbachir> yay
<Kamping_Kaiser> oh, cool.
<Kamping_Kaiser> bzr help update still doesn't list it (in 2.1.0rc2)
<Peng> Ehh. It does for me.
<Peng> Maybe it's only in bzr.dev?
<Peng> (I mean, I'm on bzr.dev. I don't know exactly when it was added, but I thought it was maybe 6 weeks ago.)
<spiv> 2.1.0rc2 has update -r for me.
<Kamping_Kaiser> ah, i have 2.0.3. i'm mis-reading bzr-uilddebs error messag :s
<johnjosephbachir> let's say i'm at revision 100, and foo.txt was removed in revision 90. i want to restore foo.txt. what's the best way to do this?
<johnjosephbachir> i tried merge -r90..89 foo.txt, but bzr doesn't like that it doesn't see foo.txt in 100
<johnjosephbachir> nevermind, found a stackoverflow thread addressing this. (if anyone wants to see it, let me know)
<Kamping_Kaiser> johnjosephbachir: should include it here for the logs :)
<johnjosephbachir> http://stackoverflow.com/questions/1626507/bzr-restoring-a-deleted-file-after-some-commits-with-bazaar
<spiv> johnjosephbachir: bzr revert -r 90 foo.txt, IIRC
<johnjosephbachir> yep, worked like a charm
<gerard_> hi
<hicham> how can i checkout a certain revision of a bzr branch ?
<mzz> hicham: many things, including "branch", can take -r <revisionspecifier>
<hicham> mzz : thanks a lot !
<mzz> np
<napster> I made a mistake :)
<napster> $ bzr push lp
<napster> Created new branch.
<napster> What I meant to do is that bzr push lp:panther
<fullermd> Well, don't do that   ;p
<napster> fullermd, But I'm drunk!!! ;)
<napster> fullermd, Can I rollback??
<fullermd> Don't drink and DVCS.
<napster> fullermd, pls leave it, I need it to be rolled back
<fullermd> There's nothing to "rollback" per se.  You just created a branch you presumably don't need, so just rm it.
<napster> fullermd, How?
<fullermd> rm -rf?
<fullermd> It's just a filesystem directory.
<napster> fullermd, Thnaks a lot. I'm continue drinking....  thanks a lot dude... ;)
<Lo-lan-do> Hi all
<Peng> Using "rm -rf" while drinking can't be a good idea...
<fullermd> Ah, that's what backups are for...
<Lo-lan-do> Is there a way to manually remove revisions from a repo?
<Lo-lan-do> I think my repo has gotten corrupted somehow, probably due to someone doing non-standard stuff with bzr-svn and merges
<mwhudson> morning
<The_User> Heyho!
<The_User> Is it possible to create something like a bzr-session (an interactive mode/you can execute multiple commands)?
<bob2> bzr shell
<The_User> bob2: ah, my bzrtools installation was broken, thanks
#bzr 2011-01-31
 * spiv frowns at https://bugs.launchpad.net/bzr/+bug/709349
<poolie> spiv, welcome back
<spiv> Thanks!
<spiv> It's not every day that I see a 'bzr commit' autopack 28 files (7580) revisions and suddenly take 50 seconds more than I'm used to :)
<poolie> hi spiv!
<spiv> Hi poolie
<poolie> i guess you just passed a big round number
<spiv> It's a launchpad repository, so lots of big numbers ;)
<spiv> I'm just dealing with the review of https://code.launchpad.net/~spiv/launchpad/haproxy-for-twisted-services/+merge/46996
<poolie> mm, that's great
<spiv> The kanban board told me to! :)
<poolie> hooray
<poolie> that's like an ideal demonstration of something nice in twisted: that it's easy to just add an http status page
<poolie> i made some quite nice progress on lp:wrested on my flight back and last week
<spiv> I saw that post, it certainly sounds nice
<poolie> it makes it very easy to fan-out multiple requests, which really helps with latency
<poolie> ideally, the api it exposes would not require so many round trips
<poolie> eg to get the bug for a task or vice versa
<poolie> but, it's useful
<poolie> to be able to work around it, and it will probably always be useufl
<spiv> Yeah, definitely.
<jelmer> moin
<poolie> hi jelmer
<poolie> i see you're trying out +reviewed tags
<poolie> do you think it's worthwhile or is it just an experiment for the kanban?
<poolie> which i just updated btw
<poolie> oops, but from the wrong team
<jelmer> poolie: thanks :)
<jelmer> poolie: yeah, I tried them for a bit to see if it'd make by kanban more managable but it'd be nicer to just get rid of that column.
<jelmer> w00t, down to "only" 24 assigned bugs :-)
 * jelmer goes back to fixing more bzr-hg bugs
<vila> hi all
 * vila hates crashes to start weeks
<jelmer> salut!
 * vila blesses backups
<vila> jelmer: _o/
<jelmer> vila: that doesn't sound nice.. what crashed?
<vila> my main desktop, for mail and chat
<vila> I think I've got it all sorted up by now
<lifeless> vila: again ?
<vila> lifeless: not the same :)
<jelmer> vila: do you have any experience with python code coverage analysis in bzr?
<vila> jelmer: there is an selftest option to activate it, it was fixed for threads long ago, this summarizes my memories
<vila> jelmer: may be you have a more precise question ?
<jelmer> vila: I'm just curious how hard it would be to check the code coverage of e.g. the bzr-builddeb and bzr-hg test suites.
<vila> jelmer: run them with --coverage <dir>, inspect the corresponding files
<jelmer> vila: I'll give that a try - thanks
<spiv> jelmer: what vila said :)
<vila> --coverage is not specific to selftest
<spiv> --coverage is a global option, so it can be handy as a quick spot check for finding out which code paths are hit by any random command.
<jelmer> maxb: hi
<maxb> hi
<jelmer> maxb: I'm trying to update bzr-hg to work with mercurial 1.7, but it seems there've been quite a bit of API breakages. Do you know if there are any recommendations documented as to how to update to a newer hg API?
<maxb> hm, all I remember is that there is some commentary on api changes on the hg wiki
<jelmer> there is /ApiChanges, but it is incomplete
<jelmer> e.g. mercurial.changegroup.iterchunks disappeared but is not listed
<maxb> hmm, that's rather annoying - sorry, I don't have an answer
<jelmer> maxb: np
<maxb> Anyone know how to adjust the font size used in "bzr qdiff" ?
<johnf> Possibly dumb question, when adding a file to bzr, or at any commit. Is any ctime, or mtime meta data stored with the commit? ie can I tell when a file was originally created or only when it was committed?
<cbz> only when it was committed
<johnf> That's what I though, lawyers ask some funny questions :)
<cbz> it's not a bad idea though - but i guess it comes down to the fact that a vcs is primarily a version control mechanism rather than a backup mechanism
<maxb> For the classical use case of actually version-controlling *code*, no one cares about per-file timestamp
<pfarrell> hi. can anyone point me at where in the docs it talks about these '.~1~' files? unfortunately google doesn't recognise the string
<pfarrell> bzr seems to put them all over the place
<beuno> pfarrell, IIRC, they are generally created when you revert files
<beuno> as backups
<pfarrell> ah, ok
<pfarrell> that wasn't obvious to me
<pfarrell> thanks
<vila> pfarrell: bzr help revert
<farfromrefuge> hi everyone
<farfromrefuge> i am seeking help about bazaar explorer
<jelmer> hi farfromrefuge
<farfromrefuge> hi
<farfromrefuge> i am trying to customize bzr explorer by adding new toolbars and i was wondering if someone could help me
<farfromrefuge> there is an action i cant manage to add
<farfromrefuge> i dont event know if its possible
<farfromrefuge> i am trying to add "bzr mv --auto" as a button action
<farfromrefuge> and i cant get it to work
<jelmer> farfromrefuge: I dn't have a lot of experience with the bzr explorer source code
<jelmer> perhaps one of the qbzr folks (bialix, GaryvdM) can help?
<farfromrefuge> thanks i will ask them
<bialix> hey
<bialix> while testing bzr 2.3b5 I've discovered nice addtition to status
<bialix> 1 shelves exist. See "bzr shelve --list" for details.
<bialix> I wonder why "1 shelves exist". Is not it should be "1 shelve exists"?
<vila> 1 shelve(s) exist(2) :D
<vila> 1 shelve(s) exist(s) :D
<vila> grr
<bialix> hi vila
<bialix> typo ruins jokes, right?
<vila> indeed :)
<bialix> I'd like to provide the patch to fix this, it's pretty easy
<bialix> I hope it can be accepted for 2.3.1
<mgz> I hope you include an entire pluralisation framework in that patch.
<mgz> just in case we ever need to get it right in czech or something.
<bialix> gettext?
<bialix> oh, that's be toio easy
<bialix> oh, that's be too easy
<bialix> wait, we don't use gettext yet
<bialix> silly me
<mgz> nor is gettext actually any good for... well, anything really.
<mgz> but fun plural rules specifically.
<jelmer> mgz: it sort of does the job doesn't it?
<jelmer> emphasis on sort of
<bialix> hi guys
<bialix> happy to see you
<mgz> yes, I was being a little cruel. it's fine as a way of hacking some localisation on to an existing C program.
<jelmer> hey bialix
<bialix> mgz: I know
<mgz> and language bends, people are used to the sort of mistakes simplistic translation systems make.
<vila> mgz: or they learn english if only to translate back into it and get some idea of what has been lost in the translation :-/
<mgz> :)
<mgz> https://developer.mozilla.org/en/Localization_and_Plurals <- for anyone who wants to read up on the fun.
<bialix> which testools I need for bzr 2.3?
<bialix> lp:testtools is okay?
<bialix> mgz should know ^
<mgz> yup.
<mgz> you need 0.9.5 or later, which lp:testtools is.
<bialix> rats, python setup.py bdist_wininst: ImportError: No module named bzrlib.workingtree
<bialix> who wrote that setup.py %-/
<mgz> someone who expects all peoples of the world to have bzr installed :)
<mgz> I had a hack around it...
 * bialix should hack that too
<mgz> ah yeah, edit the script to set the version manually.
<bialix> bug filed https://bugs.launchpad.net/testtools/+bug/710736
<mgz>  -     version=get_version(),
<mgz>  +     version="0.9.5",
<bialix> oh
<bialix> 0.9.5 from tarball is not affected by that problem
<mgz> perhaps not, bug was worth filing anyway.
<bialix> I hope old way to file merge proposals still work (push to lp and use web interface to propose merge)
<samgee> I have the cia plugin installed and it's in the "bzr plugins" list, but for some reason it's not doing anything? Is there any way to sort of reload a plugin?
<jelmer> samgee: you need to configure it per project, it has to know what project on cia.vc to submit to.
<samgee> Yes, I did that. It was even working before. I have a feeling it has something to do with suspending my computer.
<samgee> It also didn't work when I initially installed it. After a while it started working. I don't know what I did.
<jelmer> there isn't any way to reload it - if it shows up in "bzr plugins" it should be installed
<samgee> Hm. Maybe I should try uninstall + reinstall.
<samgee> Crud. Still nothing.
<jelmer> samgee: I don't see why that would help
<jelmer> samgee: does running "bzr cia-project" in the branch where you're committing print anything?
<samgee> Yes.
<major> question, bzr baz-import created a pretty weird shared-repository layout..   Is this directory structure mutable?
<jelmer> major: yeah, you can move branches about freely (within the same shared repository)
<major> and I can shorten directory paths so long as the removed directory doesn't contain a .bzr directory within it right?
<jelmer> yeah
<major> excitement
<major> thanks
<samgee> jelmer, I uninstalled the distro package and branched lp:bzr-cia into ~/.bazaar/plugins and now it works.
<samgee> Not what I'm looking for though. Getting lp:bzr-cia first and then switching back to distro's version made it work a few days ago. Not so now.
<jelmer> samgee: That's odd - I wonder if the installation thing is a red herring, as the required hooks get registered at the same moment as the data in "bzr plugins"
<samgee> Back to bzr-cia in $HOME. Works again. Let's see what suspend does.
<samgee> Hm. Still works after suspend and hibernate. Then again, I don't remember having the problem with the one in $HOME.
<jelmer> samgee: I'd be really surprised if suspend actually has an effect on whether or not bzr-cia works
<samgee> I'm just clutching straws. I don't know what else it could be.
<samgee> I'm trying some things on another machine.
<poolie> hi all
<jelmer> 'morning poolie
<jelmer> james_w: Thanks again for all the reviews!
<james_w> np
<james_w> they are small and correct, easy to review :-)
<poolie> :) hi james_w
<james_w> hi poolie
<james_w> you're up early?
<poolie> i am
<poolie> i have an interview with the DMB to see if i can get PPU rights for bzr*
<poolie> i hope enough of them come to make it worthwhile
<james_w> ah, good luck
<jelmer> oh, that reminds me
<jelmer> james_w: I need to ask for another favor :)
<james_w> jelmer, sure
<samgee> jelmer, found it. I reverted lp:bzr-cia to rev 33: didn't work. Then rev 34: worked. So looks like distro's version is broken after all and I just got confused. Thanks for your time.
<jelmer> samgee: can you file a bug against the distro?
<samgee> jelmer, I might, but I doubt it will get much attention for Lenny with Squeeze nearing release.
<jelmer> samgee: it'd be great to get fixed for squeeze + 1 though
<jelmer> samgee: (I'm one of the maintainers)
<samgee> Ah. Well, cia-clients in Squeeze = 20100528. rev 34 is from 2008-02-12. I'm guessing it's fixed. :)
<lifeless> jam: is loggerhead trunk in 2a?
<jam>  lifeless: trunk is
<poolie> hi jam
<jam> hi poolie, you're up early
<jelmer> hey jam
<jam> hi jelmer, good morning
<jam> or, late evening?
<jam> late, late evening, I guess
<jelmer> jam: I was about to say, I think it's morning in .au but not for either of us :)
<jelmer> it's not too late, 9:30
<jam> jelmer: well, late enough that I shouldn't see you *come on* at this time :)
<jam> anyway, good to say hi
<poolie> hi, it is good to see you
<poolie> jelmer could bug 519709 and bug 692901 be the same?
<ubot5> Launchpad bug 519709 in Launchpad itself "Import fails with infinite recursion through _reconstruct_manifest_and_flags_by_revid" [High,Triaged] https://launchpad.net/bugs/519709
<ubot5> Launchpad bug 692901 in Bazaar Hg Plugin "Crash with KeyError in incremental mirroring" [High,In progress] https://launchpad.net/bugs/692901
<jelmer> poolie: yes, they are
<poolie> thanks
<jelmer> poolie: congrats :)
<poolie> thanks!
<poolie> you could do it too
<james_w> congratulations poolie
<speakman> how can I revert just one hunk in a file with many changes?
<speakman> (they're not committed yet)
<speakman> something like git's checkout -p
<james_w> bzr shelve --destroy <file>
<james_w> select the hunk that you want to disappear
<james_w> not sure if it writes a backup file first
<poolie> now i need to use it! :)
<speakman> shelve..?
<jelmer> poolie: I'm going to apply for the March meeting, I was too late this time around
<speakman> how do I split a hunk?
<james_w> speakman, shelve is a bit like git stash. It's used here as it has a mode to drop the changes rather than shelving them
<james_w> anyone know where the documentation for setting up an editor to use for editing hunks during shelve is?
<poolie> speakman, james_w: bzr help shelve says 'change_editor = PROGRAM @new_path @old_path'
<fenrig> Hi i'm looking for a good up to date guide of setting up bazaar on linux, but google doesn't seem to find much, could someone point me in the right direction?
<fenrig> Well setting up a bazaar server I mean :D
<speakman> poolie: which editor is to recommend?
<poolie> fenrig, there's an admin guide under docs.bazaar.canonical.com
<poolie> let me know what's missing/wrong in that and we'll fix it
<poolie> speakman, well, i'd probably use vimdiff, but meld would also be a good choice
<speakman> ok
<speakman> hm... will this work on 2.2.1?
<fenrig> poolie: I'm looking at your link right now but I don't seem to find where they explain how to set up a bazaar server
<speakman> bzr help shelve doesn't mention change_editor here
<james_w> speakman, it should work. The documentation was added after the feature
<fenrig> poolie: I can use "Serving Bazaar with Apache"??
<poolie> fenrig, if you want to publish things over http that's a good choice
<speakman> james_w: how do I set the parameter?
<lifeless> jelmer: hi; bug 308283 - open question fo ryou
<ubot5> Launchpad bug 308283 in loggerhead "start-loggerhead does not follow symlinks" [Low,Incomplete] https://launchpad.net/bugs/308283
<james_w> speakman, I believe you put it in ~/.bazaar/bazaar.conf in the [DEFAULT] section
<speakman> $ grep change_editor ~/.bazaar/bazaar.conf
<speakman> change_editor = meld
<speakman> under [DEFAULT]
<james_w> changed_editor = meld @oldpath @newpath
<james_w> changed_editor = meld @new_path @old_path
<james_w> change_editor = meld @new_path @old_path
<james_w> third time lucky
<jelmer> lifeless: I'll have a look
<jelmer> thanks for the ping
<jelmer> I would've missed it in the massive amounts of bug mail about loggerhead I received the last couple of days :)
<speakman> $ grep change_editor ~/.bazaar/bazaar.conf
<speakman> change_editor = meld @new_path @old_path
<speakman> still nothing...
<mkanat> lifeless: I'm glad you're doing bug triage for loggerhead. It might be best to assign it to somebody who's familiar with the codebase, though.
<james_w> speakman, you can't hit "e" at the shelve prompt?
<lifeless> mkanat: what do you mean? I'm reasonably familiar with the codebase - I wrote the search integration for instance
<webm0nk3y> I am getting a strange authentication error and a traceback on a laptop that was working: http://pastebin.ubuntu.com/560733/
<mkanat> lifeless: That would have been quite some time ago, the search integration.
<webm0nk3y> I don't want to file a bug unless I'm sure it's a real problem
<mkanat> lifeless: It's changed a fair bit since then.
<webm0nk3y>   OSError(13, 'Permission denied')
<speakman> james_w: oh, yes I can. Just didn't know :p
<james_w> speakman, ah, sorry, should have explained
<speakman> :D
<mkanat> lifeless: I think both jam and mwhudson have done work on it more extensively and more recently.
<lifeless> sure, but whats the functional problem
<lifeless> the whole LP team is doing triage
<spiv> james_w: looking at https://bugs.launchpad.net/udd/+bug/653307 quite a few BzrCheckErrors seem to have recurred after resetting the imports :(
<lifeless> mkanat: 'giving it to someone' would defeat the point
<mkanat> lifeless: Defeat what point?
<mkanat> lifeless: I don't see anybody but you doing loggerhead triage.
<lifeless> mkanat: the point of spreading it over the whole team
<mkanat> lifeless: Ah, but it's not being spread, you're doing all of it.
<mkanat> lifeless: At least for loggerhead.
<lifeless> mkanat: thats because I got it in shape for the team first, so they don't deal with backlog
<james_w> speakman, I can just see icu?
<lifeless> mkanat: whats the point here, what do you think is wrong?
<james_w> err, spiv ^
<speakman> james_w: ?
<james_w> speakman, sorry, wrong nick highlighted
<speakman> :D
<mkanat> lifeless: Well, one thing is that you're in charge of the team, so if you make some decision then other people will feel somewhat bound to follow it.
<speakman> btw, is it the "new" file that's getting shelved?
<speakman> (or destroyed)
<mkanat> lifeless: FWIW, I agree with most of your triage--most of those Undecided bugs were Low.
<james_w> speakman, if you run without "--destroy", make the changes, and then run "bzr unshelve --preview" you will see what was removed
<james_w> aka, I don't know
<speakman> :D
<spiv> james_w: they're categorised as slightly different errors: dsdo + 3 others, igaelic + 1 other, icu, autofs (maybe that one is new?)
<spiv> james_w: but are all BzrCheckErrors about missing CHK root keys
<james_w> :-(
<james_w> assuming we deleted all the branches then that's bad
<spiv> Yeah.
<james_w> spiv, have you tried recreating one of them locally?
<spiv> On the plus side I couldn't figure out how to reproduce before
<spiv> But now there's a narrower set of things to try...
<jelmer> lifeless: marked fixreleased
<spiv> james_w: not yet, but will today.
<lifeless> jelmer: thanks
<james_w> spiv: ./import_package.py --persistent-download-cache --no-existing --no-push <package>
<james_w> that should be an isolated import
<spiv> Thanks, that'll save me from figuring that out again :)
<spiv> Although the wiki pages are actually quite helpful.
<james_w> spiv, would it be useful to have a "--local" option, or similar?
<james_w> or to turn it around and have a "--service" option that is used on package-import.u.c
<james_w> so that developers don't have to remember these things?
<vila> spiv: you know that the p-i is running bzr-2.1.1 right ?
<jelmer> 'evening vila
<vila> jelmer: _o/
 * vila off
<jelmer> g'night
 * vila hopes so ;)
<jam> sleep well vila
<Ronnie> i have a problem merging 2 branches: https://code.launchpad.net/~ronnie.vd.c/loco-directory/570613 into https://code.launchpad.net/~loco-directory-dev/loco-directory/0.2 . It looks like a few files from rev 345 (urls.py and views.py) fail to merge
<Ronnie> those files show no conflict nor modified tag
<poolie> hi ronnie
<Ronnie> hey poolie
<Ronnie> poolie: i use these commands to merge http://paste.ubuntu.com/560746/
<poolie> i'm just trying it
<speakman> is there a way to make multi-branch merge? (octopus merge iirc)
<poolie> speakman, just do multiple merges; use --force to let them run even though there are uncommitted changes
<poolie> Ronnie, merge tells me about 4 conflicts and bzr conflicts tells me about 4 too
<poolie> i didn't run the intermediate commands though, only the merges
<Ronnie> poolie: yes, it gives indeed 4 conflicts. i can resolve these. but none of them is related to the files urls.py and views.py from r 345
<Ronnie> the intermediate commands are not important to run, it just fills the database
<poolie> Ronnie, it looks to me like urls.py is the same in both branches
<poolie> isn't it?
<Ronnie> poolie: my bad, i mean the views.py and urls.py in the folder /loco_directory/events/
<Ronnie> http://bazaar.launchpad.net/~ronnie.vd.c/loco-directory/570613/revision/345 and http://bazaar.launchpad.net/~loco-directory-dev/loco-directory/0.2/view/head:/loco_directory/events/urls.py
<lifeless> mkanat: https://dev.launchpad.net/BugTriage is the process I'm following
<mkanat> lifeless: Okay.
<lifeless> mkanat: we want 0 untriaged bugs so that we know an engineer has assessed all our bugs
<mkanat> lifeless: Fair enough.
<mkanat> lifeless: The Launchpad project as a whole is definitely yours to run as you see fit to run it, and as you have a broad view and knowledge on it, you would certainly be more qualified to make decisions about the policies for Launchpad as a whole than I would be.
<lifeless> well its flacostes, I'm just a caretaker :) - but sure.
<mkanat> lifeless: Yeah, but I figure that day to day, the major technical stuff is all you. :-)
<lifeless> mkanat: me and my closest 30 friends :P [seriously]
<mkanat> lifeless: :-)
<mkanat> lifeless: Yeah, I just meant that the buck stops with you for most technical things. :-)
<lifeless> by which I mean that I'm an enabler/tie breaker, and should only rarely be setting specific things
<mkanat> lifeless: That sounds more like an ideal though than the way things actually run now, though, no?
<lifeless> mkanat: I think it runs that way
<mkanat> lifeless: Fair 'nuf. I don't know too much about Launchpad day-to-day.
<lifeless> mkanat: try keeping up with the output of 30 folk :)
<jam> lifeless: I think mkanat's point is that I've never seen someone else on the LP team triage 50 bugs in a day on a project I'm subscribed to
<mkanat> lifeless: Yeah, that's why I don't read most of launchpad-dev.
<lifeless> jam: there was a very significant backlog
<jam> lifeless: I'm not denying it, but saying "it is part of the team", but you're the one who actually steps up to the plate time and again
<bdrung> poolie: bug #402814 matters the most IMHO. i had to work around it for vlc: https://code.edge.launchpad.net/~videolan/vlc/master.manual
<ubot5> Launchpad bug 402814 in Launchpad itself "Importing revisions with submodules is not supported" [Wishlist,Triaged] https://launchpad.net/bugs/402814
<jam> I've seen poolie do it, and jelmer, but not "generic person" in launchpad teams
<jam> but I'm also not subscribed to all of lp, so I might miss when someone else does it
<lifeless> jam: :) - well, in this case sure. I think that there's possibly a measurement bias here
<lifeless> sinzui for instance, is a questions + triage fanatic
<jelmer> Curtis rocks
<poolie> jam: do what?
<poolie> triage?
<Ronnie> poolie: are you already able to reproduce my problem above?
<poolie> Ronnie, looking
<jam> poolie: triage lots of bugs
<poolie> it does seem to me that the lp devs are very quiet compared to bzr people
<poolie> Ronnie, sorry, i need to do something else now
<poolie> can you please file a bug explaining what you expected would happen?
<Ronnie> poolie: thx for your help. Where can i file the bug, lp?
<poolie> bugs.launchpad.net/bzr/+filebug
<radix> I'm trying to push an earlier revision onto a branch that has a later revision with --overwrite, but it seems to just be ignoring me with "No new revisions to push"
<lifeless> radix: is bug, fixed in 2.4 I think
<radix> ah, okay, thanks
<Ronnie> bug filed: https://bugs.launchpad.net/bzr/+bug/710969
<mkanat> poolie: My theory would be that folks who start open source and become corporate are more likely to use the community tools than people who start corporate and go open source.
<lifeless> mkanat: doesn't explain launchpad :)
<mkanat> lifeless: Ah, well, LP itself started as a corporate project.
<lifeless> it did, but the developers didn't.
<mkanat> lifeless: None of them?
<lifeless> There are two sets you might mean, the original crew, and the current devs
<lifeless> I don't know the detailed history of the current crew, though I know many well enough to say they are open source folk first
<lifeless> the original crew were all open source heads - folk like spiv, me, etc
 * mkanat nods.
<mkanat> All of you are pretty involved in using the community tools, too.
 * mgz requests the code from lifeless' skull
<poolie> hello mgz
<mgz> hey poolie.
<poolie> mkanat, i'd generally agree, but what's that in connection to?
<mkanat> poolie: Oh, you were commenting on how the LP devs are very quiet compared to bzr people.
<poolie> oh i see
<maxb> Ronnie: I see what is happening here. bzr is doing what it has been told to do correctly.
<poolie> yes, i think that does explain some of it
<maxb> Ronnie: The problem is that "Michael Hall" has committed a bad merge in the past, which reverts some of your changes
<poolie> so then it's not so much community tools, as community mores or customs
<mkanat> poolie: That makes sense, yeah.
<Ronnie> maxb: is there a way to resolve this, or should i make a diff and copy the contents myself by hand into the merged branch?
<poolie> maxb, you can invalidate bug 710969 if you're happy with that answer
<ubot5> Launchpad bug 710969 in Bazaar "Merge did not work as expected" [Undecided,New] https://launchpad.net/bugs/710969
<maxb> Ronnie: That would work, though there's probably a more bzr-ish way to do this
<maxb> Do you use "bzr qlog" by the way? It's probably the best way to examine and visualise what has happened here
<Ronnie> maxb: never heard of that command
<Ronnie> oh, it isnt installed default
<maxb> oopsie, I am falsely impugning "Michael Hall" here
<maxb> Ronnie: Actually, *you* reverted your own changes
<Ronnie> maxb: how did i do that, and in what revision. how can i see such ' mistakes' ?
<maxb> revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt "User syncing should now work"
<maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 570613 branch, you reverted most of the changes. Later, the 570613 branch got merged into the upstream branch
<maxb> So, there's now a revision merged to trunk which says to bzr "I know about those changes, and they're backed out"
<Ronnie> maxb: i think i understand...
<maxb> Right, so I think the best way to get out of this is as follows:
<Ronnie> those were one of my first real uses of bzr and didnt always use new folders for other branches. My workflow has impoved lately.
<maxb> First you merge the revision *before* the revert into your current branch. So by that I mean you merge revid:peter.puk@gmail.com-20101219212247-c3sq6z9sh7tbsflj into your 570613 branch
<maxb> Then you merge the revision that did the revert i.e. revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt into your 570613, branch, but you revert the revert before committing - i.e. "bzr revert ." - the . is important
<maxb> it says to revert the tree, but not the what-I-have-merged metadata
<maxb> By doing this you are telling bzr "I know about this revert, but I've decided I don't want it to happen"
<maxb> After which you should be in a position to consider doing the original merge you were intending
#bzr 2011-02-01
<maxb> Ronnie: I've pushed the result of those three merges to lp:~maxb/loco-directory/710969-example in case an example is helpful
<Ronnie> yes, an example could be very usefull
<Ronnie> ill have a look
<maxb> When I said:
<maxb> < maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 570613 branch, you reverted most of the changes. Later, the 570613 branch got merged into the upstream branch
<maxb> I got some of the numbers wrong
<maxb> I should have said:
<maxb> So, at some point in the past, you merged your 570613 branch into your 611304 branch. Then, on your 611304 branch, you reverted most of the changes. Later, the 611304 branch got merged into the upstream branch
<spiv> vila: I didn't know that, thanks for mentioning it.  I don't *think* there's any obviously relevant bug fixes since then, but it's possible...
<Ronnie> maxb: i had difficulties to read the log (history viewer from a nautilus plugin) but i think i get it. but i dont know what commands to use te revert it
<Ronnie> i normally only work with the branch, merge, status commands, and sometimes the resolve
<maxb> Ronnie: I would very much recommend installing bzr qlog
<Ronnie> maxb: do you have a link, branch for that?
<maxb> Ronnie: ubuntu?
<Ronnie> yep
<maxb> 'apt-get install qbzr'
<maxb> And yes, it will probably want to install megabytes of libqt*, but I find it to be worth it, for the ease with which it lets you understand complex merging
<Ronnie> nah, i had already the qt libs
<maxb> Ronnie: I've appended the commands I used to bug 710969
<ubot5> Launchpad bug 710969 in Bazaar "Merge did not work as expected" [Undecided,Invalid] https://launchpad.net/bugs/710969
<Ronnie> maxb: is ci a shortcut for commit
<maxb> yes
<Ronnie> ah, thx
<Ronnie> hmm, i did not find qlog more informative than bzr-gtk history viewer (did you ever try that one?)
<maxb> It's an abbreviation for "Check In" - which is actually quite silly, as it's a hold-over from the dark ages of locking VCS, but people still use it because it's short :-)
<maxb> I have used bzr viz. I found bzr qlog quite superior, due to its flexible expanding and contracting of branches
<Ronnie> maxb: at the command:  "bzr merge -r revid:peter.puk@gmail.com-20101219212501-141eds74nzwexdlt ../0.2/"  it shows some errors. should i resolve these now, or do all the other commands first?
<maxb> hmm. It did not show errors for me
 * maxb rechecks
<maxb> oh, conflicts, not errors
<maxb> The next command "bzr revert ." will get rid of them
<Ronnie> maxb: yea, conflicts
<Ronnie> http://paste.ubuntu.com/560793/
<Ronnie> oh, ok
<Ronnie> maxb: thx it works like expected
<maxb> np
<poolie> lifeless, did you already reset loggerhead trunk to 1.18?
<lifeless> no
<lifeless> was waiting on the 2a update to pthe pqm branch
<lifeless> which happened just recently
<lifeless> i couldn't sensibly push/compare etc before then
<vila> hi all !
 * fullermd flops at vila.
<vila> ;)
<poolie> hi there vila, fullermd
<vila> hey poolie !
<poolie> vila, i should stop for the day i guess
<poolie> how are things with you?
<vila> poolie: fine, setting up a local package importer, going through the hidden dependencies, should be usable today (with its associated ppa)
<poolie> ah, good
<poolie> it's already in a ppa, or you're going to make one?
<poolie> i looked a bit at https://bugs.launchpad.net/loggerhead/+bug/701329
<poolie> and we learned a bit, though not yet what the final answer is
<vila> I just created a new one to stop misusing my own (still private to me so far but allowing to track the precise versions)
<poolie> vila, actually can you give me a quick call at home?
<vila> sure
<vila> gha, phone battery empty, just a sec
<fullermd> Battery?  But, phones get all their power from the 4 little copper wires going into them...
<vila> fullermd: 4 ? We do fine with 2 around here... :D
<vila> damn, totally missed this one, 2 for power and 2 for line which is why it failed >-)
<fullermd> Well, OK, only 2 technically needed for single-line basic working.  But I don't remember the last time I saw a 2-conductor cable going into 6P2C connectors, so...
<vila> connectors... we still have old phone plugs with 8 wires here (but rj11 is 6 right ?)
<fullermd> 6P4C as a rule.
<fullermd> Though now that I double check, my desk phone actually has an integral cable that's 6P2C.  Cheap bastiches.
<vila> can't you just settle on international standards for once... :-P
<fullermd> Hey, we adopted International Morse over American.  What more do you want?   :p
<vila> metric system ?
<fullermd> I tried drinking 473 cc's of beer once.  Didn't taste near as good as a pint.
<vila> Oh I don't mind pints, but mphs are a booby-trap, I keep trying to jump out of cabs at 30...
<fullermd> You just gotta roll.
<sobersabre> hi, I am confused a bit.
<sobersabre> I have a bzr tree, let's call it /tree1
<sobersabre> I also have another tree /somewhere/tree2
<sobersabre> I want to reach /somewhere/tree2/tree1
<sobersabre> when all history from tree2 and tree2 are preserved.
<sobersabre> how do I translate this into bzr operations ?
<sobersabre> is it possible ? what possible problems may occur ?
<fullermd> cd /somewhere/tree1 ; bzr branch /tree1 ; bzr join tree1 ; bzr commit
<fullermd> That's basically equivalent to cd /somewhere/tree2 ; bzr merge -r0..-1 /tree1 ; [move all files into tree1/ subdir] ; bzr ci
<sobersabre> fullermd: you've confused tree1 and tree2.
<fullermd> (not exactly, but conceptually it gets you in the right territory)
<sobersabre> fullermd: I understood yer 1st remark.
<sobersabre> I got lost on the 2nd.
<sobersabre> if I am merging tree2 into an empty tree1 ... what am I achieving ?
<sobersabre> I mean you suggest to create a copy of the tree /somewhere/tree2, in /somewhere/tree2/tree1 ?
<fullermd> Mmm.  If I'm backward on tree1 and tree2, I don't understand what you're saying...  it certainly sounds like you're wanting to put tree1 (and all its history) in a subdir of tree2.
<sobersabre> true.
<fullermd> Then...   oh, I typo'd "/somewhere/tree1" for tree2 right at the start there.
 * fullermd blames vila.
<sobersabre> let's make is easier in naming: /1 is a tree. /d/2 is a tree. I want to have: /d/2/1/
<sobersabre> fullermd: what is vila.
<fullermd> An evil spirit that inhabits #bzr and screws with my typing.
<vila> well, for my defense, I'd point out that sobersabre also confused 1 and 2 in: " when all history from tree2 and tree2 are preserved." :-D
<sobersabre> vila: true :)
<sobersabre> so, if I translate it:
<fullermd> It's in your defense that you're screwing with HIS typing as well as mine?   :p
<vila> well, let say I'm quite generous and love to share my tyops
<sobersabre> cd /somewhere/tree2 ; bzr branch /tree1; bzr join tree1; bzr ci -m "join-a-tree"
<sobersabre> vila: I've never seen your tyop. can you share ?
<fullermd> Yes.  'join' is roughly equivalent to 'merge' into a subdir.
<vila> sobersabre: you're new here right ? Just you wait and you'll see my tyops soon enough ;)
<fullermd> So you wind up with a merge commit, with the whole history of tree1 off on the RHS.  Except that from tree2's perspective, it all happens inside '$ROOT/tree1' instead of '$ROOT'
<sobersabre> hm.
<sobersabre> I did an experiment.
<sobersabre> I WANT the history of tree1
<sobersabre> so I rephrase: I have /path/tree1, /path/tree2. I want to have /path/tree2/tree1  so that now have both files from /path/tree1 in /path/tree2/tree1, AND the history of /path/tree1 is inside the history of /path/tree2 (if I run bzr log)
<fullermd> Yes, that's why you're join'ing.
<sobersabre> oh, I see.
<sobersabre> If I run bzr log -n0, THEN I see merged stuff.
<sobersabre> cool
<sobersabre> very nice.
<vila> sobersabre: give a try to 'bzr qlog' from the qbzr plugin too
 * fullermd always wonders if he should pronounce that "cube-zor"...
<sobersabre> fullermd: call it 'cuby'
<sobersabre> q b
<vila> cude-zor sounds right, but then, I'm not a native speaker so me and accents...
<fullermd> It brings to mind many long hours wasted playing Q*bert.
<jelmer> maxb: hi
<jelmer> maxb: what does that recent MP change exactly?
<maxb> jelmer: You asked for some added docstrings
<maxb> Oh, wait. bzr MP or bzr-svn MP ?
<jelmer> maxb: bzr-svn mp
<jelmer> maxb: I don't see any new docstrings in the MP email
<maxb> hmm. I pushed... I thought. Let me check
<maxb> They're on LP
<maxb> but for some reason it's not representing my additional pushed revision in-line in the comment flow of the MP
<vila> maxb: there is probably a bug around that, I notice it randomly
<jelmer> maxb: got it now, thanks
<jelmer> vila: There have been some bugs related to file id rewriting in working trees after dpush recently
<jelmer> vila: it uses tree transform, which is still a bit obscure to me. I was wondering if you could have a look to double-check I'm using the API correctly?
<vila> jelmer: urgh, yeah, I can try, but I've been notoriously bad at that myself (though I learned a few tricks in the process)
<vila> jelmer: where should I look ?
<jelmer> vila: bzrlib/foreign.py, function update_workingtree_fileids()
<vila> in trunk ?
<jelmer> yep
<jelmer> though it hasn't changed since 2.1 I believe
<maxb> jelmer: Oh, btw, i have an Approved dulwich MP, is that just wsiting for next time you do work on dulwich, or do you need amything more from me there?
<jelmer> maxb: I'll have a look
 * jelmer wished there was a good way to see all the MPs he was involved with
<jelmer> maxb: that's already been merged
<maxb> huh
<maxb> silly lp, then
<Tak> I'm really surprised LP doesn't have that
<vila> jelmer: so, f, p, c, v, d, n, k, e is a bit obscure :) But more seriously, the doc string says update the file-ids, but I don't see how you acquire the file-ids from the other tree,
<jelmer> maxb: the revision was dpushed, so it can't use the revision id to see when the MP was merged
<maxb> ah
 * jelmer should put some more time into proper roundtripping support in bzr-git
<vila> jelmer: oh, 'f' is the file-id, so target_tree.iter_changes() should provide them
<jelmer> vila: Aaron wrote that code originally, and it's worked fine before
<jelmer> vila: I'm not entirely sure how then :)
<jelmer> vila: ah :)
<maxb> btw in the dulwich case I filed a bug on, some revision ids hadn't been dpushed either
<vila> jelmer: so, this code looks correct to me, but often with tt, combining multiple operations is where the problems start, do you have a specific one problem with this code ? Or when it's used in conjunction with some other operations ?
<vila> jelmer: the tt seems to be local to the function though
<jelmer> yeah, it's all in this function
<jelmer> vila: bug 707761
<ubot5> Launchpad bug 707761 in Bazaar "'versioning no contents' tree transform error during dpush" [High,Triaged] https://launchpad.net/bugs/707761
<vila> haaa
<vila> jelmer: right, so based on tt.new_file(), you probably need a tt.create_file(contents, trans_id) in *some* cases
<vila> emphasis on some, hilarity ensues
<vila> jelmer: "some" may be when the newly versioned file doesn't exist under the right? path in wt
<vila>  ?
<jelmer> ah, hmm
<vila> jelmer: you will need more tests for update_workingtree_fileids() it seems :-/
<jelmer> vila: thanks
<vila> jelmer: sounds likely ?
<jelmer> vila: yeah, somewhat
<vila> ok
<pfarrell> is there a bzr equivalent of svn:externals? If I check out one bzr repository, it automatically checks out another?
<jelmer> pfarrell: not in the core (yet). there are some plugins that provide similar functionality, such as bzr-externals
<pfarrell> jelmer: oh, right, thanks.
<vila> hmm, http://launchpadlibrarian.net/63287267/buildlog_ubuntu-hardy-lpia.pristine-tar_1.11ubuntu1~pkgimport1_MANUALDEPWAIT.txt.gz
<vila> fails on debhelper(inst 6.0.4ubuntu1 ! >= wanted 7.0.50)
<vila> I suspect I'm running into an issue known by maxb... Is https://launchpad.net/~bzr/+archive/builddeps part of the asnwer ?
<vila> answer
<vila> except the later includes only debhelper-7.0.13
<jelmer> vila: is there any reason you actually need debhelper 7.0.50 ?
<jelmer> as opposed to an older version, I mean
<vila> jelmer: no idea, this is required by pristine-tar, do you suggest I should try to lower the requirement and see ?
<vila> jelmer: hardy has debhelper 6.0.4, -backports has 7.0.13 as does bzr-builddeps, so lowering to 7.0.13 and add bzr-builddeps as a ppa dependency ?
<maxb> vila: most dh7 stuff does actually require 7.0.50
<maxb> look for override_* targets in rules
<maxb> they are the most common reason
<vila> maxb: two occurrences for pristine-tar: override_dh_auto_configure and override_dh_auto_clean
<maxb> right, so you do need a later debhelper than backports provides
<vila> maxb: can debhelper be upgraded >= 7.0.50 in https://launchpad.net/~bzr/+archive/builddeps ?
<vila> maxb: I'm pretty sure I'll have to add it as as dependency to https://launchpad.net/~vila/+archive/pkgimport anyway
<maxb> ah so we've stopped trying to sru pristine-tar for jubany?
<vila> maxb: that's different, I'm trying to setup a local package importer and doing so track what is needed
<vila> maxb: I thought prisitine-tar has been upgraded on jubany anyway, I didn't know about an sru for it...
<maxb> you can find a suitable debhelper in mercurial-ppa/builddeps
<vila> maxb: could you copy it to bzr.builddeps ?
<vila> maxb: could you copy it to bzr/builddeps ?
<vila> maxb: or will it break everything there ?
<maxb> I think it should be pretty safe
<maxb> The only reason I did not before was that I did not have a need
 * maxb blinks at bzr-package-importer being a package
<maxb> Doesn't it just run from the branch in production?
<vila> maxb: blame me
<vila> maxb: I'm creating it right now to track what is ~used in production
<vila> maxb: it is *not* used by jubany
<maxb> ok
<maxb> Well, I don't have any specific objections to copying debhelper 7.0.52 to bzr/builddeps - except that there's been no requirement for it for anything built in the ~bzr PPA so far. Perhaps you could just copy it to vila/pkgimport directly?
<vila> maxb: yup. I was going to do exactly that
<maxb> Although, wouldn't your project be easier, and more representative of production, if you based on lucid?
<vila> maxb: well, jubany is hardy right now...
<maxb> *blink*
<maxb> I am confused. Or perhaps I misunderstood. I thought the whole point of considering SRUing pristine-tar to lucid was to get it to jubany
<jelmer> I don't think there is any intent to do a SRU?
<vila> meh, no idea, as I said, I'm not aware of the SRU, any pointer ?
<maxb> Somewhere there was a mention by (I think) james_w that we should do a backport. I filed a backport request bug, which got declined on the basis that it should be a SRU instead
<maxb> oh, it's in an import failure bug
 * maxb looks
<vila> maxb: jubany currently uses 1.11ubuntu1~0.IS.8.04
<jelmer> maxb: are you sure that's for the package importer?
<maxb> Oh. That's recent, then
<vila> maxb: yes, less than 24h
<maxb> Evidently someone got tired of waiting and did an IS backport instead
<vila> maxb: jam will know the details
<maxb> bug 695108
<ubot5> Launchpad bug 695108 in lucid-backports "Backport pristine-tar 1.11ubuntu1" [Undecided,New] https://launchpad.net/bugs/695108
<maxb> bug 653301
<ubot5> Launchpad bug 653301 in Ubuntu Distributed Development "Packages failing due to pristine-tar not being able to reconstruct their tarball" [High,Triaged] https://launchpad.net/bugs/653301
<vila> maxb: right, so s/24/13/
<vila> maxb: right, so s/24h/13h/
<jelmer> ah, so it affects general bzr-builddeb as well
<vila> as a related note, should add bzr-builddeb to the bzr ppa(s?) ?
<vila> s/add/we add/
<jelmer> yeah, probably
<vila> *blinks*
<vila> It *is* in bzr/ppa but for jaunty/karmic/lucid only...
<maxb> vila: That typically means that maverick+ is already at the latest upstream release
<jelmer> it's about time we do another bzr-builddeb release
<vila> maxb: of course, silly me ! Thanks
<maxb> Oh, and it's not there for hardy because we're have to backport python-debian, and it didn't seem worthwhile
<vila> maxb: very good exercise for me :)
<maxb> meh, hardy is ancient
<maxb> I wonder when PPAs are discontinue support for Jaunty
<maxb> ^ going to
<vila> maxb: but that's what jubany uses *today*, on the other hand may be I should check what is the target for migrating jubany (probably lucid) and just works from there...
<maxb> What does the importer need builddeb for?
<jelmer> maxb: it uses a bunch of the tarball importing code from bzr-builddeb
<maxb> ah
<maxb> oh, duh, I should have remembered that
<vila> ok, confirmed, so I'll target lucid instead and see how it goes
<deepestthought42> hi all! I'm evaluating how to best use bzr for revision control at my company. We have a medium sized Visual Studio Project that depends on a few binary files, which seldom change. Is there a way to just copy the files on branch/merge (direction depending on timestamp) commands , without having them version controlled ? Thanks!
<jelmer> hi deepestthought42
<Tak> deepestthought42: from my research, no current dvcs has "good" handling of large, versioned binary files
<vila> spiv: are you *sure* 2.1.1 is not relevant when bug #522637 has been fixed in 2.1.3 ?
<ubot5> Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637
<vila> mwahaha, bzr-builddeb package imported failed leading to out-of-date branches on lp which I use to create my own
<jelmer> hehe
<deepestthought42> I feared as much , but thanks anyway. We'll probably end up putting them under vc.
<vila> deepestthought42: what do you call large (# and size of the largest) ?
<deepestthought42> vila: I do not think I said how large they are ;) but the complete build folder has about 350 MB (Debug, release builds etc.) -- the real "problem" is that changed binaries crop up in the status/diff/merge and they probably slow the system down (not sure on that),
<vila> oh right, sry, but why don't you *ignore* the binaries (via 'bzr ignore') i.e. don't version them and they won't appear in status/diff/merge
<deepestthought42> not all of them need to be build (and can be by all developers)  every time but need to be present.; so a copy would suffice for them; we probably will have a folder for the stable binaries and version them and ignore the unstable ones
<vila> ha... Well, your call, but mixing production and version control has known deficiencies, keep in mind that bzr will change the timestamps of the files it modify so rebuilding an old version should only rebuild the files related to the modified files
<vila> In practive, devs will have to build the whole project once and then rebuild only the needed parts, even when working on old versions
<deepestthought42> vila: you're right, this solution is not without problems -- but when completely ignoring the binaries, we would have to copy them by hand on every branch etc.
<vila> deepestthought42: you want to try 'bzr switch' then so you can reuse the same working tree for several branches
<vila> deepestthought42: but you're the judge, just mentioning some different ways to address the issue
<deepestthought42> vila: i know and thank you for your help :)
<fenrig> Could someone give me good guide on howto set up a bazaar server over http on linux?
<AfC> fenrig: do you mean "just access a branch over HTTP" or the magic bzr+http integration?
<fenrig> AfC: uhm bzr+http is where bzr doesn't get whole files but just the diff lines?
<cbz> no
<fenrig> :o uhm okay
<AfC> fenrig: bzr always does that (sic) regardless.
<AfC> fenrig: ie, it Does The Right Thingâ¢ as it should. You rarely need to second guess it.
<AfC> fenrig: have you got SSH access to the web server in question?
<fenrig> AfC: ow okay I compare GIT a lot with BZR.
<fenrig> AfC: I have yes :)
<AfC> fenrig: if so, just push your branch there via bzr+ssh://
<AfC> fenrig: and then you can just point people at http://...
<AfC> [there's also a sftp:// for pushing if you can't install Bazaar on the server]
<fenrig> but then http acts like a read only branch?
<fenrig> AfC: Do u guys have a super good guide, so I can try it out on a VM?
<AfC> fenrig: yes
<fenrig> AfC: :p could you please give it to me :D
<AfC> I said yes to "read only"
<jam> maxb, vila: you rang?
<AfC> Maybe someone else could lend this person a hand? Rumour has it Bazaar has good documentation, but apparently they haven't been able to find it :(
<vila> jam: morning jam, maybe, long ago, let me check :)
<maxb> jam: There was a discussion about pristine-tar for jubany, but I think we got everything clarified in the end.
<vila> ha, yeah, pristin... what maxb says :)
<jam> maxb: lamont was kind enough to backport the natty pristine-tar and install it on jubany
<jam> it didn't fix everything, but it fixed a lot of them
<maxb> fenrig: Please clarify: you want to do write-access to branches over http? You want to browse branches like you see at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ?
<fenrig> maxb: no with loggerhead is fine :) but then I need to have ssh+bzr to commit changes?
<vila> fenrig: there is nothing to configure for bzr+ssh except for the ssh access
<jam> vila: looks like it went from ~92 to 14 failing packages
<maxb> fenrig: Many people prefer bzr+ssh for commit because a ssh-agent is often a more convenient way to cache your authentication safely than a password
<vila> fenrig: not even a vm, you can try with bzr+ssh://localhost
<vila> jam: yup, well done, I didn't look closely but had a ~60 rough estimate
<fenrig> :D okay maybe someone could point me to a good guide on how I have to do this (and please don't give a ubuntu specific cause I use arch linux)
<vila> fenrig: just try: 'bzr push bzr+ssh://localhost/~/a-new-shiny-one'
<fenrig> vila: I mean how to setup a server :p
<vila> fenrig: I meant: just try
<vila> fenrig: there is no server to set up !
<maxb> If you have a running sshd, and bzr installed, that's all you need.
<maxb> Does anyone fancy dispatching https://code.launchpad.net/~maxb/bzr/ppa-doc-update-2/+merge/48101 to PQM? (it's already approved)
<fenrig> so let us say :) just to understand i do :o
<fenrig> bzr push bzr+ssh://root:localhost/~/a-new-shiny-one
<vila> maxb: done
<maxb> thanks
<fenrig> where does the folder goes to?
<fenrig> in /root/a-new-shiny-one?
<vila> root:locahost ? You mean root@localhost ?
<fenrig> vila: yeah sorry XD
<vila> fenrig: hmm, don't use root for that, just try with your regular user
<fenrig> yeah I know using root bad idea, but it's for understanding the semantics :o where does the repo folder go to?
<vila> ~ is replaced with the user home directory yes
<mgz> jelmer is launching a DoS on my inbox...
<vila> fenrig: the *branch* is created there, creating a new repository or re-using an existing one (you may want to read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief)
<vila> mgz: hey !
<fenrig> vila: so i could find all the source code files in "/root/a-new-shiny-one"?
<vila> mgz: yeah, it's a new kind of Ddos: single attacker, multiple targets :)
<mgz> :)
<vila> fenrig: no, you won't find the working tree, only the history (branch [+ repository])
<mgz> maybe I should blame launchpad instead, does it really need to send me email for tag changes.
<fenrig> vila: how do you mean (your url says: "page does not exist,...")
<vila> fenrig: most of the time working trees are useless on servers, if you need a working tree there, look for the bzr-push-and-update or bzr-upload plugins depending on your use case
<vila> fenrig: try again, I copied the URL from my browser
<fenrig> vila: there was a ")" behind it sorry xD
<vila> argh, sry for that
<fenrig> vila: don't mind it :D
<fenrig> bzr is easier to setup than git isn't it?
<cbz> yes
<cbz> mostly
<cbz> and easier to work with mostly
<fenrig> cbz: the "bzr whoami" command gives you a name on your client :) so If I and my friend use diff whoami's but we use the same ssh user there should still be a difference in bzr?
<vila> fenrig: whoami is used at commit times, not at push time
<fenrig> :o so the diff will we marked with the whoami?
<vila> fenrig: yes, whoami set the committer
<fenrig> I'm following thui
<fenrig> *this guide: and he creates a user like this => useradd --create-home --home-dir /var/local/bzr --shell /usr/lib/sftp-server bzr (on ubuntu)
<fenrig> why is he setting the home-dir to be /var/local/bzr?
<fenrig> http://wiki.flexion.org/BazaarServer.html
<vila> fenrig: no idea, but given he mentioned hardy and doesn't use the smart server, I'll forget about it
<fenrig> vila: :o where do I have to find a proper guide then?
<vila> fenrig: you can use bzr over sftp, but you don't have to.
<vila> nowhere
<vila> there is no guide to setup an ssh smart server because there is no setup
<vila> as maxb said earlier: install sshd and bzr and you're done
<fenrig> yeah okay :o
<fenrig> but I want to make one bzr ssh user for this :o
<vila> from there it's only ssh config, nothing specific to bzr (at least to start with)
<fenrig> called (tadam) bzr
<vila> jfdi
<vila> it's not a bad idea as you will be able to set its .ssh/authorized_keys to control who can push there
<fenrig> when doing "bzr push bzr+ssh://bzr@192.168.56.101/~/a-new-shiny-thingy-one"
<fenrig> gives me a : "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if ..."
<fenrig> but loggin in with
<fenrig> ssh bzr@192.168.56.101 works perfectly :o
<vila> fenrig: try 'ssh -vv bzr@192.168.56.101' to debug ssh issues
<vila> ha, hmm
<fenrig> vila: ssh -vv bzr@192.168.56.101 works :o logging in and all :o
<fenrig> vila: but I'm using a modified "shell" => /usr/lib/ssh/sftp-server
<vila> don't do that then
<vila> bzr will send the right ssh command, you're getting in its way here
<fenrig> vila: what's the command to change the shell of a user XD
<vila> how did you modify the shell ?
<fenrig> u configured it using adduser
<fenrig> *I
<fenrig> (sorry)
<vila> by following the guide I told you was wrong ? :D
<fenrig> I only followed it on the adding bzr user :$
<vila> dunno the specific command on your os, *I*'d modify it by editing /etc/passwd
<vila> or you can delete the user and re-create it or create another one
<fenrig> vila: change it to /bin/bash?
<vila> whatever is the default on your system
<jam> vila, fenrig: the command is often just "chsh" for change shell
<jam> You often can run chsh without needing root
<jml> jelmer: are you retagging all of the bugs?
<jelmer> jml: I'm tagging the ones that haven't been tagged yet and closing/duping where possible
<jml> jelmer: ahh, ok.
<jelmer> jml: Sorry about the mail. I'm sure you get plenty already ;)
<vila> . o O (Yeah, that's the idea, bounce them all to jml !)
<jml> jelmer: no worries. it's just an unusually high number today
<jelmer> vila: at least he's somebody who can make sure that launchpad bug notifications get fixed :)
<vila> jelmer: you get the idea ;)
<vila> james_w: ping
<james_w> hi vila
<vila> james_w: hey ! wow, that was fast ;)
<james_w> I've been sitting here all day waiting for your ping
<vila> I've set up a local package importer (with --no-push), and I'm trying to add some packages to it
<vila> :)
<vila> I tried add_import_jobs.py but it timeouts
<james_w> times out doing what?
<vila> so my question is: is there another way to add a package (a single one to start with :)
<james_w> ./requeue_package.py should do it
<vila> it says package has not failed, oh, --force ?
<james_w> yeah
<vila> yeah !
<vila> james_w: thanks, I'm unblocked
<cr3> how can I branch a project in launchpad on system that doesn't have any access to bazaar.launchpad.net? if I can access the system by ssh, can I push a local branch to the system in a way that can be merge on the same remote system later?
<james_w> cool
<vila> cr3: if you have an ssh access to a system that have an ssh access to b.l.n, why not set up an ssh tunnel ?
<cr3> vila: I did that once, I was hoping for another solution :)
<fenrig> vila: changing shell worked :D
<vila> cr3: hehe :)
<vila> fenrig: finally !
<vila> cr3: so, anyway, as long as you do the merge on 'system' you can still push there from wherever works for you
<vila> cr3: you don't need a working tree in the branch you're pushing to as long as you have one where you merge this branch
<vila> s/you don't need/don't use/
<cr3> ssh -g -R 50022:bazaar.launchpad.net:22 system; bzr branch bzr+ssh://localhost:50022/...
<vila> james_w: add_imports_jobs.py is the canonical way to bootstrap the importer or something else ?
<james_w> vila, that's what adds all the jobs as new packages are uploaded :-)
<vila> james_w: so it's run from a cron job ?
<james_w> yep
<vila> ok
<vila> oooooh here is the crontab :)
<fenrig> howdo I download a full branch?
<fenrig> no with pull right?
<beuno> fenrig, "bzr branch"
<fenrig> thx :D
<bregma> hey all, I keep having a problem with bzr merge-upstream deleting my debian directory in my packaging branch ... any ideas what I've done wrong?
<maxb> bregma: It sounds like the best way to explain would be to provide instructions for someone to repeat your steps
<bregma> hmm, okay, I'll try to describe what I've done...
<bregma> I have a packaging branch for my package that I created by branching my package, then I added packaging (the debian/* files) and committed...
<jelmer> bregma: does your previous upstream revision perhaps contain the debian/ directory?
<bregma> .. I then did a bzr mu, which kindly removed and readded all my upstream files and updated the debian/changelog...
<bregma> .. debcommit, fix some packaing problems, debcommit, good to go
<fenrig> should I add my user for bzr+ssh to the group users or should I create a new group for it (bzr for example)?
<bregma> ... now, I have a new upstream release... I use uscan to get the tarball, then do a bzr mu, referencing my upstream repo, and the mu removes the debian directory and fails because there is no debian directory
<bregma> I have other projects that use bzr mu OK, but I tried bootstrapping this one on my own and now I get fail
<fenrig> should I add my user for bzr+ssh to the group users or should I create a new group for it (bzr for example)?
<fenrig> Hi :o
<fenrig> how do i specify the port if the port of ssh is another then the default (22)
<fenrig> bzr --create-prefix bzr+ssh://bzruser@192.168.1.1:8888/~/project ?
<fenrig> I've got it sorry xD
<maxb> bregma: It would be a lot easier to understand if you just pointed us to the branch and tarball in question
<bregma> maxb, indeed, branch lp:~utouch-team/utouch-compiz/ubuntu and use uscan to grab the tarball
<bregma> ... and the upstream branch is lp:utouch-compiz
<maxb> bregma: ok, could you say the exact bzr mu command you are running?
<maxb> Well, first things first, this packaging branch is pretty screwed up
<maxb> In fact, I think you should throw this packaging branch away and start afresh
<bregma> heh, OK, how should I start?
<maxb> Was 0.1.1-0ubuntu1 an actual upload to a PPA or something?
<bregma> yes
<bregma> .. except UNRELEASED was tweaked to natty for the PPA upload
<maxb> That shouldn't be possible with a debian/change.... ah
<maxb> OK, so here's what I would do
<maxb> I'd start a new branch branching from -r tag:v0.1.1 of the upstream branch
<maxb> I'd use bzr import-dsc to import the 0.1.1-0ubuntu1 package precisely as it is in the PPA
<maxb> then I'd check the tags and ensure that the imported package was tagged "0.1.1-0ubuntu1", and the upstream version was tagged "upstream-0.1.1" -- probably needing to add that second one manually
<maxb> At that point, I'd manually copy across the debian/ directory from the old packaging branch, and commit those changes
<maxb> And *then*, I'd go to do a merge-upstream, and expect it to work
<maxb> oh, and when I copied across the debian/ directory, I'd avoid reverting the old changelog entry to UNRELEASED, just for clarity's sake
<bregma> OK, I am trying all that, I will post results
<bregma> ok, good news, I merged my new release OK and can continue from here, but I still have a problem bootstrapping a packaging branch for use with merge-upstream ... is there a godd resource for that that somewhere that I've missed?
<maxb> The simplest way that I know of is to simply branch the upstream branch at the last release, do "bzr tag upstream-VERSIONNUMBER", and add and commit a debian/ dir.
<speakman> is it possible to create a set of patch files, one for each commit, of the last five commits?
<maxb> for i in `seq 1 5`; do bzr diff -c -$i > patch-$i.patch; done
<speakman> omg...
<speakman> then it won't be named by commit message?
<jelmer> speakman: generally when transferring revisions it's down as a bundle file, which can contain multiple revisions and their metadata
<speakman> jelmer: how do I cherry-pick commits into (or out of) a bundle?
<speakman> and how do I inspect a bundle?
<jelmer> speakman: generally you'd pull it into a branch and then work from that branch
<jelmer> there has been some work to be able to treat a bundle as a branch as well, but that's nowhere near complete yet
<speakman> ok
<speakman> how do I uncommit a specific commit?
<jelmer> speakman: "bzr uncommit"
<speakman> any commit?
<jelmer> you can only uncommit from the tip
<jelmer> with -r you can uncommit until a specific revision
<speakman> can I cherry pick from a branch?
<speakman> without merge is preferred
<jelmer> you can cherrypick a revision with "bzr merge -c REV"
<mwhudson> jelmer: wow, i have a LOT of bugmail from you!
<jelmer> mwhudson: sorry!
<mwhudson> it's ok, it's easy to skim :)
<speakman> maxb: crazy, your one-liner created *large* patch files. But doing exactly the same manually works.
<mwhudson> some of my branches on launchpad appear to have become corrupted
<mwhudson> pushing fails with
<mwhudson> bzr: ERROR: Server sent an unexpected error: ('error', "Cannot lock LockDir(lp-87934032:///~mwhudson/offspring/path-independence/.bzr/branchlock): File exists: u'/srv/bazaar.launchpad.net/mirrors/00/06/3f/75/.bzr/branch/lock': [Errno 17] File exists: '/srv/bazaar.launchpad.net/mirrors/00/06/3f/75/.bzr/branch/lock'")
<mwhudson> info says this:
<mwhudson> Shared repository with trees (format: unnamed)
<mwhudson> Location:
<mwhudson>   shared repository: bzr+ssh://bazaar.launchpad.net/~mwhudson/offspring/path-independence/
<mwhudson> does this ring any bells with anyone?
<jelmer> mwhudson: that suggests the branch has disappeared
<jelmer> what happens if you remove that lock?
<mwhudson> jelmer: the .bzr/branch directory is there
<jam> mwhudson: but if the 'lock' directory is missing, we'll fail oddly trying to create something underneath it
<jam> (namely .bzr/branch/lock/pending-XXXX eventually renamed to .bzr/branch/lock/held)
<mwhudson> jelmer: when i fixed another branch by rmtree-ing .bzr/branch/lock with hitchhiker, it worked
<jam> mwhudson: rmtreeing everything *under* lock seems ok
<mwhudson> jelmer: i guess _something_ has gone missing which makes bzr think there is no branch there
<jam> but deleting 'lock' itself is dangerous
<mwhudson> but in fact, there are bits of a branch there
<jam> mwhudson: right, I think the branch is still there, just that the lock dir is gone, and we don't create it on demand
<mwhudson> jam: lock is empty
<jam> but it does exist?
<mwhudson> jam: i think you're reading the error backwards
<jam> mwhudson: it says "FileExists" but I don't trust our error codes for many things
<mwhudson> the error is complaining that the lock dir is already there when it tries to create it
<mwhudson> jam: oh heh
<mwhudson> jam: the lock dir is there, yes
<mwhudson> what has to be there for bzr to think there's a branch there?
<mwhudson> .bzr/branch/format is there
<spiv> The ".bzr/branchlock" part of that error is intriguing.
<mwhudson> as is
<mwhudson> branch.conf
<mwhudson> format
<mwhudson> last-revision
<mwhudson> lock
<mwhudson> tags
<jam> mwhudson: yeah, I'm in on sftp right now
<mwhudson> spiv: hm yeah
<spiv> That's possibly just an error not being serialised for the wire very well, though.
<poolie> hi spiv, jelmer,
<mwhudson> spiv: yeah, locking over http appears to get the same sort of erro
<jelmer> 'morning spiv, poolie
<mwhudson> russel appears to have had the same issue as me though: http://osdir.com/ml/bazaar/2009-10/msg00072.html
<mwhudson> ah
<mwhudson> the branch is stacked on a branch that has changed url
<mwhudson> i suggest the error reporting is not perfect here?
<jelmer> mwhudson: you have high standards for error messages.
<speakman> Is it "bzr rewrite" or "bzr rebase" these days?
<poolie> jelmer, you flooded my mailbox :)
<speakman> Now I've moved some lines in a file, but bzr think I've moved all the other lines which makes a very confusing diff. How can I change how bzr detects changes?
<poolie> speakman, it prefers to synchronize on unique or unusual lines
<speakman> but it doesn't reflect my actual change
<speakman> is there a way to change the behavior+
<jelmer> speakman: bzr rewrite
<poolie> not built in
<poolie> you could use an external diff
<jelmer> poolie: I get that a lot today :)
<vila> jelmer: I caught up, send me more :-P
<vila> spiv: in case you missed it:
<vila> spiv: are you *sure* 2.1.1 is not relevant when bug #522637 has been fixed in 2.1.3 ?
<ubot5> Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637
<jelmer> vila: hehe
<jelmer> vila: Thanks for those followups, btw
<vila> jelmer: thanks to you for the triaging !
<mgz> I wrote an imap script in the end, to keep up...
<mkanat> poolie: Hey, I finally wrote up that email about my community research as a blog post: http://www.codesimplicity.com/post/open-source-community-simplified/
<peitschie> mkanat: thats a very nice write-up!
<mkanat> peitschie: Thanks!! :-)
<peitschie> mkanat: out of interest.... how long did it take to put together all the data and do the analysis?
<mkanat> peitschie: For the Retaining part, I'd say a few weeks.
<mkanat> peitschie: A lot of the graph analysis I did in one day, but then correlating it to what was happening at the time was more difficult.
<mkanat> I also generated the graphs in a *lot* of different ways to make sure that I wasn't mis-reading the data.
<mkanat> peitschie: The "removing the barriers" stuff I'd say was more an obvious fact that just became apparent after 5 years on the project and everybody being confused about how they should start.
<poolie> jelmer, i was wondering how you were retagging things, and how/whether you found it worthwhile
<jelmer> poolie: the main reason I'm retagging is to get a bit of an idea of what's still out there in terms of bugs and to make it easier to find related bugs when working on a specific topic later.
<jelmer> poolie: I'm mainly tagging based on the top-level commands in which something occurs, if that's significant or otherwise the protocol / format / platform that it's related to.
<poolie> are you using the web ui?
<poolie> i think the tags are accurate and useful
<poolie> i have mixed feelings about whether it's worth going through and gardening them
<jelmer> As well as a few overall themes (udd, ui, foreign, ...)
<poolie> but as a way to page it into your head it's quite good
<jelmer> poolie: I've got a lplib script that finds interesting bugs for me to look at, and feeds them to chromium
<poolie> ah, interesting
<poolie> can you share it, maybe on launchpad@lists?
<jelmer> sure
<jelmer> it's only 5 lines though, so not terribly interesting :)
<poolie> it's just "all bugs" or "bugs without tags?"
<AfC> mkanat: Excellent post. I have passed it along and have already started thinking about what we can apply to our project.
<poolie> or you have some local state of ones you're already seen?
<mkanat> AfC: Awesome, thank you! :-)
<AfC> mkanat: My work is an order of magnitude smaller, but I've observed similar patterns.
<poolie> jam: https://bugs.edge.launchpad.net/kanban
 * mkanat nods.
<jelmer> poolie: it's bugs without interesting tags (uninteresting tags being things like "apport")
<mkanat> AfC: I think it's macrocosmic and microcosmic too.
<mkanat> AfC: You could probably apply it to "the open-source community as a whole," too.
<AfC> mkanat: the one I found particularly bell-ringing was "what can I do", and I'm not sure we actually answer that
<AfC> mkanat: barrier to entry stuff was a big deal early on when I was learning to be a maintainer, too
<mkanat> AfC: Yeah, for me too. :-)
<AfC> No one ever tells you abut that part
<mkanat> AfC: Yeah. I think the only reason I became a long-term part of the project was that I entered with a defined long-term goal.
<mkanat> That was my own goal.
<poolie> jelmer, and then you just get 20 browser tabs or whatever to overlap the page load times?
<jelmer> poolie: More like a 100, but yeah :)
<mkanat> AfC: Also, I was naturally very meticulous and willing to accomplish that long-term goal as a series of smaller steps.
<AfC> mkanat: (not horn blowing) the second half of http://blogs.operationaldynamics.com/andrew/software/java-gnome/love-your-work.html you'd see that I have quite the "high" standard for getting code in, and you can imagine the knock on effect of that.
<mkanat> AfC: Hahaha, I totally do too!
<mkanat> AfC: People have often complained that the review process was too hard. But nobody complaints that the code sucks, anymore. So....
<mkanat> AfC: And as I said in the blog, nobody cited the *difficulty* of the process as their actual reason for *leaving*.
<AfC> mkanat: one of my problems (I think I will blog this today) is that people turn up "what can I hack on" and I tend to reply "um, maybe you should try *using* the library first. Then we can talk about what you might do to help improve it"
<AfC> mkanat: yes, that was interesting too
<AfC> mkanat: though in the Apache world, no one has any difficulty with code review at all. So sometimes people don't expect pushback. Anyway.
<mkanat> AfC: Ahh. :-)
<mkanat> AfC: Yeah, I do think that developers should be users first.
<AfC> mkanat: I'm pretty happy not to follow the Apache worldview, but it does have knock-on consequences
<mkanat> AfC: Yeah.
<mkanat> AfC: The system we have in Bugzilla is that certain people can CTR in modules that they "own", but everybody else, it's RTC.
<mkanat> (For everybody else in the channel who doesn't work on Apache, that's "Commit Then Review" vs "Review Then Commit".)
<mkanat> Also, our stable branches are always RTC.
<AfC> Interesting difference in the 3rd generation DVCS world: it's commit, then submit for review, then merge[d by maintainer]
<AfC> (==RTC, but :))
<jam> mkanat: interestingly, people *have* cited the difficulty of the process as the reason for leaving the launchpad group
<jam> :)
<mkanat> AfC: Haha, yeah.
<mkanat> jam: That's interesting. I would have dug a bit and asked them if their reviews had been *faster* if they'd have felt differently about it.
<mkanat> I did quite a bit of responding to the survey answerers to understand everything about what they were saying.
<jam> mkanat: as one of the outsiders suffering the q, reviews is one thing, actually getting the whole steps from 'write some code' until 'it is deployed in production' can be a huge q of things.
<jam> depends on the size of the hack
<mkanat> jam: Yeah, I certainly found that frustrating, when trying to get loggerhead deployed on LP.
<mkanat> jam: I think the whole process of submission to "get it into the product" is what needs to be sped up for every project, ideally.
<jam> mkanat: right. because even if I hack on Evolution or whatever, how long before I actually get to use that on my machine...
<jam> (without having to run manually compiled binaries indefinitely.)
<mkanat> jam: Totally.
<mkanat> jam: It's easier for something written in a dynamic language.
<mkanat> jam: Particularly for a web app that people can run themselves.
<mkanat> jam: They can just "bzr pull" and they have their fix.
<jam> mkanat: a lot of that depends on the design of the app, and how it can be run
<jam> run from source
<mkanat> But even in that case, getting the actual release out is a big deal.
<mkanat> jam: Yeah, totally true.
<jam> needs to be configured and installed, etc.
<mkanat> jam: That's one reason why I've always worked to make it easier and easier to install Bugzilla, too.
<mkanat> jam: But something like bzr or launchpad, you realistically need to see a release before you can actually use your feature.
<jam> mkanat: I run from bzr.dev constantly
<jam> but launchpad def needs a rollout
<mkanat> jam: Yeah.
<mkanat> jam: Although most people aren't going to use an unstable version of a VCS, because it's so important.
<dev001> hi.  i'm using lp:bzr/2.3.  today's update of plugins squawks abt 'Installed Bazaar version 2.3.0dev6 is too old to be used with plugin "Bzrtools" 2.4.0.', where I've been tracking lp:bzrtools.  so, a switch to 'other' bzrtools branch is called for, i s'pose.  which branch?
<dev001> ping abentley
<abentley> dev001, pong
<dev001> abentley: hi.  ^^^ re: "your" (well, at least you're the maintainer :-)  ) bzrtools ?
<dev001> am i stuck 'inbetween' API upgrades, or is a branch switch called for?
<abentley> dev001, if you want to track trunk branches, you should track both the trunk of bzr and bzrtools.
<dev001> abentley: nah, i got warned off bzr trunk a while ago.  so if i'm tracking bzr/2.3, which bzrtools?
<dev001> trunk worked for awhile ...
<dev001> but, apparently no longer
<abentley> dev001, I happen to be in the middle of creating a 2.3 branch, but I don't guarantee I'll do that for future releases.
<abentley> dev001, if you're not tracking trunk, you might be better off with packages.
<dev001> abentley: your point's noted.  but a number of issues were addressed solved in bzr/2.3 for me, per admonition from in here.  or are you suggesting packages for *plugins/extension* with bzr/2.3 branch?
<poolie> hi abentley, afc, mkanat
<mkanat> Hey poolie. :-)
<abentley> dev001, I'm suggesting packages for bzr 2.3 and bzrtools.
<abentley> poolie, hi.
<dev001> abentley: hm.  catch22, then.
<abentley> dev001, why?
<dev001> abentley: simply (admittedly, naively), the move from bzr pkgs to bzr/2.3 branch was something i did cuz told in here to do so (whining abt some such problem; the migrate fixed it).
<dev001> so prior-necessity dictates (dictated?) the bar/2.3 branch
<dev001> er, bzr
<abentley> dev001, I don't think that packages of bzr 2.3 would introduce any problems that the 2.3 branch doesn't have.
<abentley> dev001, anyhow, lp:bzrtools/2.3 now exists..
<dev001> abentley: heh, well there's THAT solution!  thanks :-)
<abentley> dev001, np
 * dev001 appreciates NOT having to use git muchly! ;-)
<dOxxx> jelmer: I think I've received nearly a 1000 emails today, courtesy of you via launchpad.
 * maxb wonders if poolie is still around?
<maxb> If so, could you nod at https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885 and possibly send it to PQM?
<poolie> maxb, hi
#bzr 2011-02-02
<maxb> Do we know the estimated release date of bzr 2.4 yet?
<maxb> aligned with Ubuntu o-series?
<poolie> maxb: yes, ~2 months before Otty
<abentley> jelmer, ping
<poolie> so august
<poolie> maxb: nod for 2.1
<poolie> on the phone at the moment
<lifeless> jelmer: I'm curious what adding tags like ssh to bugs with ssh in the title helps with
<jelmer> abentley: hi
<jelmer> lifeless: being able to find bugs that are related to ssh (as opposed to bugs that happened to occur over ssh)
<abentley> jelmer, I was having trouble testing bzrtools under 2.7 due to https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/654826 but I think I've got it licked.
<jelmer> abentley: ah, cool
<poolie> maxb, thanks for your mail; that's fine with me
<dOxxx> anybody familiar with qt around here?
<dOxxx> and pyqt?
<dOxxx> I have a very perplexing error with a most unhelpful traceback: TypeError: 'sip.methoddescriptor' object is not callable
<maxb> poolie: great - when the change lands on 2.1, I'll put up a MP for merging 2.1 into 2.2, and so on and so on
<spiv> dOxxx: sounds like something somewhere is trying to invoke a method on a class rather than an instance.
<dOxxx> spiv: so this is where the traceback is unhelpful or, very weird:
<dOxxx> Traceback (most recent call last):
<dOxxx>   File "C:\dev\qbzr\mergetools\lib\commands.py", line 175, in run
<dOxxx>     ret_code = getattr(main_window, "return_code", None)
<dOxxx> i.e the getattr is triggering the error
<spiv> Perhaps main_window.return_code is property?
<spiv> s/is/is a/
<dOxxx> spiv: the only mention I can find of it assigns it as a normal instance attribute
<dOxxx> I suspect that this is due to a recent change in sip
<dOxxx> "Added support for theÂ __getattribute__,Â __getattr__,Â __setattr__Â andÂ __delattr__Â methods."
<spiv> Hmm, could be.
<dOxxx> SubProcessWindowBase(object) sets the return_code field, but then getattr is being called on SubProcessWindow(SubprocessWindowBase, QBzrWindow). So I'm guessing mixing in the Qt class is breaking the getattr
<dOxxx> ugh
<dOxxx> and naturally RiverBank Software doesn't provide older versions of PyQt for download.
<dOxxx>  /facepalm
<poolie> hi spiv
<spiv> Hi poolie
<poolie> spiv, is there an RT for the production changes for bug 702024?
<ubot5> Launchpad bug 702024 in Launchpad itself "Restarting codehosting SSH server drops existing connections" [High,In progress] https://launchpad.net/bugs/702024
<lifeless> poolie: yes
<lifeless> poolie: its 4th from top
<lifeless> 40480
<poolie> got it thanks
<poolie> just talking to spm about making it more concrete
<lifeless> poolie: FWIW I'll be driving it through
<lifeless> its right in the middle of the nodowntime project
<poolie> great
<poolie> i'm just trying to make sure things don't drop
<poolie> there is a gap between the code train and the losa platform
<lifeless> I'm glad you're interested
<lifeless> I don't really see that gap
<lamont> https://launchpad.net/~bzr/+archive/beta <-- why no dapper love here?  it's still got 4 months of support left.....
<lamont> so... given 2.3.0~beta5... how can I tell if someone has already run "bzr whoami --branch" ??
<poolie> lamont, cat .bzr/branch/branch.conf
<lamont> poolie: my fallback was: if grep -q "^email " .bzr/branch/branch.conf
<poolie> lamont, do we still have dapper machines active?
<lamont> no
<lamont> that was mostly troll
<poolie> k
<poolie> "why no hppa builds? :-("
<lamont> they were running hardy
<lamont> bzr init causes branch.conf to be created, yes?
<poolie> yes
<lamont> see /pm?
 * spiv wonders if doc.bazaar.canonical.com is slow because of connectivity woes or if it's actually just really slow
<spm> spiv: i think something funky with au internets is up tbh. I'm seeing odd slowness and pauses... everywhere.
<vila> hi all !
<fullermd> 'morning.
<vila> yeah, Open bugs # went below 1900, well done jelmer :)
<fullermd> Ooh.  Does that mean I need to break more things?
<vila> Not necessarily :) But we should be able to catch you faster :-p
<vila> spiv: pfew, I'm glad this was relevant, somehow I felt I was using only bad medias to convey this piece of wisdom to you (IRC while you were asleep, bug comment during jelmer flood, etc ;)
<spiv> vila: I cope ok with message floods, apparently :)
<spiv> Open bugs below 1900?  Way to go robot^Hjelmer!
<vila> ;)
<maxb> https://code.launchpad.net/~maxb/bzr/launchpadlib-service-root-api-compat/+merge/47885 is "review approved" but not "merge approved" - anyone got a moment to click it over to approved and send to pqm?
<poolie> sure
<poolie> maxb, do you have access?
<maxb> pqm? no
<poolie> if you're sure the consensus is it's approved, feel free to set it yourself
<poolie> i'll feed it in now
<maxb> well, I'm basing the conclusion on your irc comment :-)
<poolie> ok, it's running
<poolie> thanks for persisting
<maxb> np :-)
<maxb> Just want to get started on the 3 subsequent merges to higher series whilst it's all fresh in my mind
<maxb> and thanks for the reviewing
 * maxb returns to monster bugmail inbox :-)
<vila> . o O (monster... says the user from jabberwock...)
<poolie> hi vila
<poolie> indeed
<vila> hey poolie,so, 2.2.3 is in -proposed ?
<vila> :)
<poolie> sadly not today
<poolie> the rts moved along a lot though, as did my understanding of how that would work
<vila> ELINK
<poolie> we have some rt tickets open asking for deployment of a few things
<poolie> like forking lp-serve
<vila> ha !
<poolie> i think they are now more likely to ascend into heaven
<vila> the holy bitbucket ?
<poolie> so that plus weeding out a thousand mails
<jelmer> hey poolie, vila
<vila> Look at the bright side: this bits will reincarnate in even better software :-}
 * jelmer ducks
<poolie> i hope you have a good view of them in your head now
<poolie> if you do, that's great
<poolie> i don't know if retagging for the sake of it is all that good
<poolie> finding dupes is good though
<poolie> and already-fixed bugs
<poolie> and our open-bugs graph dipped noticeably
<jelmer> poolie: The flood of email is a bit unfortunate :-/
<poolie> that's the only problem with it really
<poolie> a web dashboard would be better
<poolie> especially if it had a concept of a 'seen' bit
<vila> yup, nice dips on the graphs
<vila> as a rough estimate I think if jelmer can continue at this rhythm, he should finish in ~1 month ;D
<maxb> Actually as a result of the flood of email I've noticed one bug is closable and another is probably easily fixable by me
<maxb> So it has its upsides too :-)
<poolie> it's kinda useful to see old bugs again
<poolie> i'm not sure if the ratio is worthwhile
<poolie> i'm getting to the bottom of my mailbox and seeing robert's preceding flood
<poolie> i am Queensland :)
<jelmer> :)
<poolie> ok i'd better go
<poolie> have a good day
<jelmer> thanks, have a nice evening :)
<vila> have a nice evening poolie
<maxb> oh headdesk
<maxb> this maverick SRU is having a cursed life
<maxb> 2.2.3 has a regression in the launchpad plugin
<jelmer> maxb: :(
<vila> maxb: which one ?
<vila> I was pretty sure I ran all the tests for 2.2.3...
<maxb> vila: But there are no tests that exercise talking to launchpad, are there :-/
<vila> maxb: shudder.. no :-/
<vila> maxb: what is the regression ?
<maxb> it doesn't work. period
<lifeless> that sounds like a regression
<maxb> AFAICS, anything that tries to talk to the launchpad web service just fails, because the URLs are wrong
<vila> maxb: check your settings, the babune maverick slave uses 2.2.3 and pull from lp every day
<lifeless> vila: pull != web service
<vila> lifeless: with launchpad_username set ?
<maxb> launchpad_username is not relevant here.
<maxb> We mean "bzr lp-propose" and friends, which authenticate over oauth
<vila> then be more specific, lp: is resolved by the lp plugin
<maxb> yes, but not via the web service :-)
<maxb> that goes via the xmlrpc service :-)
<vila> then what goes via the web service ?
<maxb> lp-mirror, lp-propose, lp-find-proposal
<maxb> The launchpad plugin is a bit scary
<maxb> There's the legacy bits which go via the xmlrpc interface in lp_registration.py
<maxb> Then there are the new bits going via the lazr.restful service
<maxb> And then there is the checking of lp-login, which goes via the web *site*
<maxb> Oh, and for further confusion, any attempt to use the lazr.restful service first starts by instantiating an xmlrpc service object in order to obtain the launchpad instance name from
<maxb> mad mad mad
<fullermd> All we need to do is add an EDI interface now...
<vila> lp-propose seems to be working from here
<maxb> that's odd. Is it possible that it's only obtaining a new oauth token that's broken?
<vila> ha, no, the infamous '1.0'
<vila> maxb: bug #707075, err wait, you're already the assignee
<ubot5> Launchpad bug 707075 in Bazaar "lp-propose fails with a 404 error" [Undecided,In progress] https://launchpad.net/bugs/707075
<vila> maxb: but then it's not a regression, the bug has been there for quite some time no ?
<vila> maxb: or was it triggered recently by some lp change ?
<vila> maxb: in any case, this doesn't sound like a good reason to delay 2.2.3 SRU, this *won't* be fixed in 2.2.3, this *can* be fixed in 2.2.4
<vila> maxb: ha, right, just got your mail for the mp
<vila> maxb: I can reproduce the bug with 2.2.2, so that's not a regression
<maxb> *blink*
<maxb> what?
<maxb> But, the edge service root was correct?!
<vila> hence the suspicion against lp itself
<maxb> no, the bug does not reproduce with 2.2.2 here
<vila> *blinks*
<vila> Oh ! wrong terminal :-/ Sorry
<maxb> The bug always existed in the url config within bzr for talking to lp production - but not edge. Therefore, it only became a problem when we switched to talking to production
<vila> ha !
<maxb> Ultimately I blame launchpadlib for doing a sucky job of api compatibility
<vila> maxb: approved with a tweak. ping me when I can land
<maxb> vila: hmm. I kind of said that in the NEWS already?
<vila> maxb: not the bit about *production*  url config being broken
<vila> but not edge
<vila> I didn't understand until you mentioned that
<maxb> "This was a regression exposed by the switch away from Launchpad's edge platform, in bzr 2.2.3." was my attempt to explain that difference
<vila> yes, but at first I was wondering why edge has been working but not production
<vila> the answer is that production never worked but wasn't used
<vila> which in turn explain why switching away from edge exposed the bug
<maxb> ok, how about "This was a latent bug in bzr's communication with Launchpad's production instance, which only became a problem when the default instance was switched from edge to production in bzr 2.2.3." ?
<vila> perfect !
<vila> maxb: and this can't be fixed in 2.0 why ? (I'm sure you mentioned it but can't find it back)
<vila> lp_api didn't exist in 2.0
<maxb> yup
<maxb> plus, the bug doesn't trigger with the launchpadlib in karmic, either
<vila> >.<
<vila> yeah for early adoption ;)
<maxb> vila: pushed, though lp is being sluggish about updating the mp diff
<vila> yup
<vila> but good enough to feed pqm
<vila> done
<maxb> woot, thanks
<maxb> i'll do 2.2 -> 2.3 at lunch
<vila> maxb: cool
<jml> jelmer: hi
<jml> jelmer: if you have commented on a bug in the last day or so and have desired me to read it, can you let me know explicitly? I've been a little bit zealous in archiving bug mail from you recently.
<AfC> Why is everyone complaining about bugmail from Jelmer?
<maxb> Obviously you're not subscribed to bzr bugmail :-)
<maxb> He is on a tagging/triaging rampage :-)
<maxb> I skimmed 450 bugmails this morning
<AfC> Crtl+A Ctrl+D baby
<AfC> "Internet Kill Switch" :)
<jelmer> jml: hi
<jelmer> jml: No, there wasn't anything in the last day.
<jml> jelmer: thanks.
<mgz> "71 messages edited tags only and were marked as seen"
 * mgz does an evil laugh
<mgz> worth it too, got one more bug marked fixed from reading the ones that actually included comments.
<mgz> bug 523989 is annoying. launchpad should just normalise the field.
<ubot5> Launchpad bug 523989 in Launchpad itself "=C2=A0 cluttering the mailed diff when changing a bugs description" [Low,Triaged] https://launchpad.net/bugs/523989
<AdamDV> How can I resolve/clear all conflicts? I have a bunch (around 20) conflicts that were just due to some stupid line changes, and I've since fixed the files and deleted the .moved .tTHIS .OTHER etc. Went to commit, and it says theres conflicts.
<mgz> `bzr resolve`
<maxb> Suppose I wanted to make an incompatible API change in bzr.dev within bzrlib.plugins.launchpad.lp_api - would that be ok?
<maxb> or should I care about maintaining compatibility
<vila> maxb: you should care :-}
<maxb> vila: for code in a plugin?
<maxb> I guess to phrase it another way: does anyone know of bzr plugins *depending* on the bzr launchpad plugin
<vila> no idea, but not knowing what compatibility you want to break, I tell you the rule :)
<maxb> lp_api.login parameters, basically
<maxb> But, I could get around it by having a parameter that can either be a lp_registration.LaunchpadService (old) or a string (new)
<maxb> so I should do that
<maxb> I suppose
<vila> yup and deprecate the former
<vila> james_w: so, I'm back to the timeout problem. The issue is trying to get the published sources since the last import,
<james_w> and given there was no last import that's going to be a lot of sources
<vila> exactly
<vila> and since the API provides only create_since_date, we're doomed
<vila> that's your primary source for package names right ?
<james_w> it's supposed to use very small batches, but I guess the reduction in timeout means that either those batches aren't small enough again, or that the overhead is so high that the batch size doesn't matter
<james_w> that's the primary source of new uploads
<james_w> there is list_packages.py to just get package names, but it uses the same APIs
<vila> james_w: well, in my case, there never was a successful import so that's *all* published sources
<vila> hehe
<james_w> right
<james_w> so you could claim there was an import 10 minutes ago
<vila> right and that will catch up.... at O time ;)
<vila> good enough for my tests but we won't be able to start an importer from scratch, may not be a big deal but I should still file a bug about it I think
<maxb> vila: As far as providing an import service, importing new services from a specific date would be fine. So, you'd need to combine that with some other routine which compared latest-publication-in-archive with latest-publication-in-branch for all published packages
<maxb> And, you'd only need to do that if you felt you couldn't just allow people to notice out-of-date imports
<vila> maxb: the issue here is to establish the list of package names without lp blowing up
<maxb> vila: cheat and download the apt Sources files? :-)
<vila> *blink*
<vila> they are downloaded... but when
<maxb> I'm suggesting that if you wanted to bootstrap an importer you would download the Sources file for each distro-pocket and force an individual importer run for each discovered package name
<vila> maxb: doesn't sound like cheating to me... but a good way to seed an importer. *Then* it can rely on published sources to discover the new ones, james_w ? sounds correct ?
<vila> maxb: got you
<maxb> But, you would only need to do this to catch imports missed by the importer installation you were replacing
<maxb> james_w: btw, might you have a chance to consider bug 694818? It relies on getting "what's actually useful in production" knowledge from your head :-)
<ubot5> Launchpad bug 694818 in Ubuntu Distributed Development "Bitrotted scripts in UDD import-scripts source tree" [Undecided,New] https://launchpad.net/bugs/694818
<james_w> vila, that's what I did when I started it
<james_w> maxb, I saw it, does it need input from me?
<james_w> I think it's a good idea
<james_w> you want to know which ones can be deleted?
<maxb> james_w: I was assuming you were the best person to rule what was obsolete and what might need updating to work with the new store
<maxb> I thought you might be holding on to some bits intending to update them when you next needed them
<james_w> I'll take a look
<james_w> basically if they haven't been updated yet then they aren't useful :-)
<maxb> thanks
<lamont> BZR_PLUGINS_AT=bzrtools@/build/buildd/bzrtools-2.3.0 /usr/bin/bzr selftest -s bp.bzrtools
<lamont> bzr: ERROR: Couldn't import bzrlib and dependencies.
<lamont> I suspect that bzrtools has missing build-deps
<lamont> where does bzrlib come from?
<lamont> seems to be "bzr"
<lamont> james_w: any chance you want to look at a buildlog for me?
<maxb> iiuc, the bzr script is supposed to execute in a python which has bzrlib and friends in its library directory
<tsdh> Hi. On http://doc.bazaar.canonical.com/plugins/en/pager-plugin.html a pager plugin is listed for bzr.  I'd really like to use that.  But the homepage that is linked from there contains only an empty directory.  Is there another way to get it?
<maxb> tsdh: The "empty directory" is actually a bzr branch
<tsdh> maxb: Oh, so I should clone that URL to get the plugin?
<maxb> yes
<tsdh> Yep, that does the trick.
 * tsdh feels like an idiot...
<LeoNerd> Most webservers just don't display the .bzr directory in the bare index page
<jaypipes> hi all, does bzr docs have anything similar to http://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html? I'm trying to get a difference of what a bzr branch/tag name can contain vs. a git tag name...
<lifeless> jaypipes: tags are unicode pretty much anything except newlines and 0x00
<james_w> lamont, sure
<lamont> james_w: figured it out
<lamont> totally my fail
<james_w> ok
<lamont> which was complicated by the hardy version working despite my screwup
<jaypipes> lifeless: cheers. thx Robert
<lifeless> lamont: hey
<lifeless> lamont: so if you're playing with packages ATM; whats the current python-subunit in CAT?
<lamont>    subunit | 0.0.6-1~bazaar1.0.IS.8.04 |     hardy-cat | source, all
<lamont> which interestingly means all of the lucid boxes have 0.0.5-1
<lamont> unless the machine was upgraded.
<lifeless> lamont: yeah, this is breaking praseodymium pretty hard.
<lifeless> lamont: We need 0.0.6 for lucid
<lamont> lifeless: I take it this is you saying "that needs to be fixed, promote 0.0.6-1~bazaar1.0.IS.8.04 to lucid-cat"?
<lifeless> lamont: is it that easy?
<lamont> actually, we have 10.04 version in lucid-cat-proposed --> trivial
<lamont> if I upgrade it on pras, can you tell that it's all better trivially?  (and is it broken enough to jfdi?)
<lifeless> lamont: there may be a dep on testtools, but I imagine your toolchain will take care of whinging if you're going ot break stuff
<lifeless> lamont: its broken enough that whenver a pqm merge fails, pqm barfs to stderr, packs its toys up, and goes home.
<lamont> lifeless: chroot or in the real root?
<lifeless> lamont: real
<lamont> not pqm dchroot?
<lamont> so... upgraded in the real root
<lamont> 0.9.6-0~bazaar1.0.IS.8.04 <-- python-testtools came for the ride
<lifeless> lamont: sweet, thank you!
<lifeless> mbarnett: ^ I think we just saved you a bunch of time
<lamont> mbarnett: and poke me about testing and such before I make that global, kthx
<lifeless> lamont: to test it I'll get a broken merge thrown at pqm from lp
<lifeless> lamont: I'm sure it will be no worse than it was
<lamont> heh. thanks
<lamont> pls do though
<lifeless> lamont: I'm arranging that now in #launchpad-dev
<lifeless> lamont: the basic symptom has been we go into testfix, merge disappears
<lamont> nice
<lamont> for eye-stabbing values of "nice"
<lifeless> right
<lifeless> and pqm mails out a whine to the errors list
<lifeless> pqm-errors or something; its where pqm's cron mails to
<mbarnett> lifeless: whee!
<poolie> hello all
<jelmer> g'morning poolie
<poolie> hi jelmer
<lamalex> Hey, I've sort of backed myself into a spot I'm not sure how to get out of. I merged a branch into mine, and as I was typing bzr commit to commit the merge, i got a kernel panic and had to reboot. I forgot to commit when i came back and have been hacking for quite a while with all of those changes from the merge uncommited
<lamalex> i want to separate my changes from the merge, is there any way to really do this?
<lamalex> and  my other question is why doesn't bzr just do a commit after a successful merge?
<fullermd> Well, you could make a copy of the branch and redo the merge by itself...   then try pushing that new rev onto your existing branch and seeing if update DTRT, or try using merge --uncommitted the other way, or do a manual diff of the working trees...
<poolie> lamalex, what i would do is:
<poolie> make a second working directory, re-do the merge in there, commit that
<poolie> pull that into your original working directory
<lamalex> poolie, that's what I did
<lamalex> well, maybe
<poolie> that will insert the merge revision underneath your later changes
<poolie> and then only the later changes will be seen as uncommitted
<poolie> great
<Noldorin> how can i find out what branch the working copy is currently bound to>?
<bob2> bzr info
#bzr 2011-02-03
<Noldorin> bob2, thanks
 * spiv blinks
<spiv> $ bzr st
<spiv> modified:
<spiv>   doc/en/_templates/index.html
<spiv> ignored:
<spiv>   doc/en/_templates/index.html
<lifeless> \o/
<AfC> Remind me not to use the version spiv is running...
<spiv> Bug 712209 filed.
<ubot5> Launchpad bug 712209 in Bazaar "bzr status reports a file as both modified and ignored" [High,Confirmed] https://launchpad.net/bugs/712209
<spiv> AfC: tip of lp:bzr, of course :)
<spiv> AfC: but it appears to affect 2.2 too.  2.1 seems ok.
<poolie> hullo spiv
<fullermd> spiv: bug 587506
<ubot5> Launchpad bug 587506 in Bazaar "Mentioning of ignored named files is overzealous" [Medium,Confirmed] https://launchpad.net/bugs/587506
<spiv> fullermd: thanks!
<fullermd> (it also, AIR, shows up in the commit template; not sure if there's an extant bug about that.  But I presume it's all the same code causing it everywhere anyway)
<spiv> fullermd: I'd expect so
<poolie> "ian.clatworthy@internode.on.net has been removed from bazaar-commits." :-(
<spiv> :(
<spiv> I noticed earlier today he has four branches on https://code.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS
<spiv> I'm going to take a look and try to either abandon them or do something with them.
<poolie> that'd be good
<poolie> spiv i guess the things that most need review are actually yours
<spiv> poolie: yeah
<spiv> As it's the start of a cycle I wonder if I should land them, especially given they've already had some review.
<lifeless> spiv: does your haproxy thing for codehosting also make it wait to shutdown for things to finish ?
<lifeless> spiv: if so, what method of shutdown were you expecting?
<spiv> lifeless: yes, and SIGTERM or SIGINT
<spiv> (which are the default signal handlers twisted installs)
<lifeless> spiv: could you join #launchpad-ops for a bit ?
<spiv> Sure
<lifeless> thanks
 * maxb hugs mod_wsgi
<maxb> One quick installation of bzr smart server + loggerhead, no extra daemons beyond the apache, 70 lines of config total :-)
<maxb> and that only because I decided I wanted a custom logging arrangement any ended up copypasting part of bzrlib.trace
<poolie> nice
<maxb> hmm
<poolie> maxb, if you have notes on how to do it i'd like to add that to the docs or the blog
<poolie> though, pehraps 70 lines could be improved upon
<maxb> well, that's including a full apache <VirtualHost> block and two wsgi hooks, each with ~7 lines of imports
<maxb> hah, nice
<maxb> Now I've mounted the loggerhead and the smart server sharing the same URLs
<maxb> I have to have two urls, one for read-only and one for read-write, though
<maxb> Now, if the smart server could map 'read only transport' errors into 401 http responses, that would be awesome, because then I could do anonymous-read/authenticated-write on a single URL
<lifeless> file a bug
<maxb> ugh, it's 5am, I should stop playing with wsgi :-)
<spiv> maxb: ...and start drinking whiskey instead? :)
<maxb> Nah, I've already had some port tonight
<peitschie> you mean last night :P
<maxb> or possibly both
<peitschie> maxb: whoah... snapps!
<peitschie> or is it schnapps =D
<vila> hi all !
<jelmer> moin
<vila> jelmer: hey !
<jelmer> vila: did you see Charlie's comment on the NoWhoAmi bug ?
<vila> yes
<jelmer> vila: When is 2.3 scheduled exactly?
<vila> freeze today
<vila> 2.3.0
<jelmer> hmm, ok. so if we want to get it in it should be done today?
<vila> but I may freeze 2.2.4 first
<vila> done and approved... which seems a bit of a hurry :)
<jelmer> It'd be nice to get that one fixed so launchpad can deploy 2.3
<vila> I smell controversy and regressions around this topic :-/
<vila> basically there are two class of users competing for one default value/behaviour for opposite reasons,
<vila> newbies that don't understand the implications and admins who don't care about these implications
<jelmer> vila: I think the use of mailname is reasonable, and we could still warn if we end up using the mailname
<jelmer> I'm sure we can find a better middle ground than we have at the moment :)
<vila> I seem to remember that the warning lead has been explored at one point but it seems to be the most reasonable one to try now ;)
<vila> . o O (daggyfix for features should tell us this kind of thing instantly...)
<jelmer> vila: Did we really have a warning at some point? I remember somebody saying that in Dallas as well, but I don't remember it.
<vila> jelmer: still, deploying on lp is only part of the issue, I'm pretty sure they want on lucid...
<vila> jelmer: I don't remember discussing the subject in Dallas, so that should have been someone else ?
<vila> jelmer: it may have been discussed in the mp and never landed
<jelmer> vila: yeah, I don't think that was with you
<vila> I think the issue with the warning is that explorer/GUI users may not get it
<vila> on the other hand, GUIs *should* guide the users on this particular issue
<jelmer> vila: Yeah, agreed
<vila> so let's do the warning and put the burden on GUI devs :D
<jelmer> I think it's very clear how a GUI should deal with this - just prompt the user and suggest a username.
<jelmer> vila: I also think we should bring back the functionality to guess a username, so it can be used by the GUIs as a suggestion, and so it can be used when we need a username for e.g. a lock or "bzr blame"
<vila> jelmer: good point, but it's a separate issue
<vila> haa, what I meant is:
<vila> - yes, valuable work has been invested in guessing, let's share it with GUIs
<vila> - don't mix the warning stuff with the guessing stuff
<vila> or may be I'm wrong and instead the warning stuff *is* (or should) be based on the guessing (I don't remember the code in detail)
<jelmer> vila: I agree, they're related but separate issues
<vila> right, the pain point today is for admins, let's do the warning first and *then* let's address the guessing,
<vila> the former may be targeted  at 2.1 (unless it's too hard) while the later can be done in trunk
<vila> this way the admins can get their cake on lucid
<vila> pending sru for 2.1 yada yada
<vila> maxb: your fix for bug 707075 is required for 2.2 whatever launchpadlib version is used right ?
<ubot5> Launchpad bug 707075 in Bazaar 2.4 "lp-propose fails with a 404 error" [High,Fix released] https://launchpad.net/bugs/707075
<vila> maxb: (trying to see if it can be backported in the packaging branch for 2.2.3 or if we really need a 2.2.4 for other distros)
<Tak> which subproject is launchpad "bugs" ?
<mgz> malone.
<maxb> vila: Correct, it is required for any launchpadlib >= 1.5.5
<vila> busted (I didn't hope much ;)
<vila> jelmer: tracking a test failure in bzr-builddeb I end up with a test failure in bzr-svn: http://paste.ubuntu.com/561900/
<vila> jelmer: do I need svn itself installed ? (I have bzr-svn/1.1 python-subvertpy from bzr/ppa (0.7.5))
<jelmer> vila: no, that's actually a known failure at the moment
<jelmer> there's an open bug about it
<vila> ha, ok, thanks
<vila> jelmer: some builddeb test require bzr-svn or fail (they should check the plugin is there instead, I'll fix), but I know have a failure due to a late change in revno 3510 AttributeError: 'Revision' object has no attribute 'mapping'
<vila> s/know/now/
<jelmer> vila: as far as I know none of them really require bzr-svn, because I don't have bzr-svn installed in the environment I run the tests.
<vila> jelmer: even the one that includes 'svn in their name in test_merge_upstream ?
<vila> s/one/ones/
<vila> circa line 80
<vila> jelmer: introduced ~08/2008 ;)
<vila> jelmer: http://paste.ubuntu.com/561919/ , so the issue is that the test fakes a Revision object but not a ForeignRevision one :-/
<jelmer> vila: ah, hmm
<jelmer> vila: yeah, bzr-svn recently started looking at rev.mapping
<vila> yeah, no worries, it's a test bug I'd say
<vila> how do I create this attribute to mean it comes from svn ? (value)
<jelmer> vila: you'd need to get it from the bzr-svn mapping registry
<vila> darn, complex object ?
<jelmer> vila: well, I guess you could mock one if you wanted to
<vila> hmm, they are compared for equality so mocking...
<jelmer> the mapping object isn't compared, but the .vcs one is
<jelmer> the .vcs bit you should be able to get from bzrlib.foreign.foreign_vcs_registry.get("svn")
<vila> jelmer: did the trick, thanks
<vila> jelmer: yet, it's weird you don't see the failure when svn is not installed, are you sure you don't get it from somewhere unexpected ?
<jelmer> vila: hmm, actually.. I might have it but just an older version
<jelmer> vila: are you fixing this bug, or should I have a look?
<vila> jelmer: now I'm fixing a bug in bzrlib.tests.ModuleAvailableFeature :-/
<vila> shudder... no way I could force a dependency on bzr.dev to bzr-builddeb isn't it ?
<jelmer> vila: ideally not
<jelmer> vila: it makes backporting a pain
<jelmer> other than that I don't really think it's a big deal
<vila> I will find a way to split the fixes
<fax8> hi guys, I do have my sources updated to the latest revision
<fax8> how do I get them as in a previous one
<fax8> ?
<jelmer> fax8: hi
<jelmer> fax8: I'm not sure I understand the question - you'd like to see the contents of a previous revision?
<jelmer> vila: fwiw there's already a MP open for the zipfile issue
<vila> jelmer: trying to run selftest will all plugins I get >100 failures, if disable svn I get 0
<vila> jelmer: ha, rats
<jelmer> (~jelmer/bzr-builddeb/712180-zipfile-python2.6)
<jelmer> vila: all foreign branch plugins trigger errors unfortunately
<vila> ok, np, just making sure you knew about it
<jelmer> it's on my list of things to work on (testsuite improvements for foreign plugins in general), but I haven't gotten to it yet
<vila> jelmer: your patch for zip if far more complex than mine :D
<jelmer> well, it actually makes the zip file a proper file :)
<vila> mine doesn't ?
<jelmer> I thought it just added some bytes into the file?
<fax8> jelmer: yeah.. I do have all the files updated to reversion X ... I want that all becames as in reversion X-Y.. how can I do so?
<vila> jelmer: writestr accepts zinfo_or_arcname, you went for zinfo, I went for arcname (AFAUI)
<jelmer> vila: ah, ok
<vila> fax8: there are various ways to achieve that, it depends on what you want to do *after(
<jelmer> vila: I guess we should take the smaller version of it then (but still close the bug #)
<vila> jelmer: yup, I'm trying to check that using arcname is not a recent addition
<fax8> vila: I don't wanna commit anything.. just see how the were (can't use bzr cat)
<vila> fax8: why not create a new branch then: from <current> (where you are) : 'cd .. ; bzr branch current -r-2 new'
<vila> but generally you look at the diff: 'bzr diff -r-2'
<vila> or the status: 'bzr st -r-2'
<vila> so you don't touch your working tree and its uncommitted changes
<vila> jelmer: I checked zipfile.writestr for python2.[456], three different versions all accepting the simpler one proposed above but varying slightly implementing yours.
<jelmer> vila: I'm not particularly tied to my solution, happy to go with yours.
<vila> ok, I'll steal the bug then ;)
<vila> jelmer: hmm, there is a debian dir there, how is the changelog handled ? Should I add an entry (or are tests not worth it) ?
<jelmer> vila: actually, since this is a regression that's never been in a release I'm not sure if a changelog entry is worth it
<vila> ok
<fax8> vila: thanks.. I did know about the branch solution.. I just wanted to switch to an older snapshot.. not needed to create a branch
<vila> bzr pull -r2 then
<vila> bzr pull -r-2 then
<jelmer> more specifically, "bzr pull -r-2 --overwrite ."
<fax8> that did it .. thank you
<vila> jelmer: I start the freeze, no mp for the whoami warning ?
<jelmer> vila: nope, sorry
<jelmer> we can probably cherry pick it after its landed though
<vila> np
<vila> we ?
<vila> as in lp ?
<jelmer> yeah
<vila> k
<jelmer> I'm keen to see a newer bzr deployed on lp, as it'll help with recipe builds (being able to use stacking, for example)
<vila> I'd prefer merging up from 2.1 if you target that, but since I won't be the one doing it, you're the judge ;)
<mgz> exec vila? really? why not just check sys.modules first?
<vila> and they need a proper whoami there ?
<jelmer> vila: there among other places
<vila> mgz: I was wondering who will mention that first, spiv, jam or you ;)
<mgz> :D
<vila> jelmer: ok
<jelmer> mgz: exec is what we use to load plugins, too
<jelmer> so it doesn't seem that bad to use it here as well
<vila> honestly, I thought about checking sys.modules *after* submitting and then wondered if some edge cases would be covered...
<mgz> yeah, it's not really that evil as it's just tests, but I get heebies about running some interpolated string
<vila> mgz: nothing with running interpolated strings.... as long as you understand what they contain :D
<mgz> well, we can trust test authors not to write ModuleAvailableFeature("sys; something_evil")
<vila> right, worth mentioning in the mp, checking sys.modules should be enough here anyway plus I forgot to add tests
<vila> s/mp/review/
<mgz> I will add a little note.
<mgz> done, typed in some (untested) code that might work.
<mgz> ...and has at least two errors, which just makes life more fun.
<vila> mgz: :)
<mgz> jam gets one prize.
<jelmer> 'morning jam
<maxb> jelmer: Hi, I have a question about bzrlib.plugins.launchpad - You recently added qastaging support - I was intending to refactor it to rely on launchpadlib for all its list-of-launchpad-instances support, but the versions of launchpadlib currently in ubuntu don't include qastaging. How would you feel about me addressing this by conditionally monkeypatching launchpadlib.uris ?
<jelmer> maxb: hi
<jelmer> maxb: what's the issue with the current way of retrieving the URLs?
<maxb> That we currently maintain two separate lists of launchpad instances within bzrlib.plugins.launchpad, and, except for the addition of qastaging, launchpadlib has all the data we need in the launchpadlib.uris module
<jelmer> can't we just keep a single list in bzrlib.plugins.launchpad ?
<maxb> I'm aiming to reduce the amount of launchpadlib functionality duplicated within bzrlib.plugins.launchpad.
<maxb> So, I was thinking of something along the lines of:   if 'qastaging' not in launchpadlib.uris.service_roots: launchpadlib.uris.service_roots['qastaging'] = 'https://api.qastaging.launchpad.net/'
<jelmer> maxb: monkey patching is duplicating code as well
<maxb> Yes it is, but in the net reduction in duplication should be pleasing
<maxb> Yes it is, but in *this case* the net reduction in duplication should be pleasing
<maxb> The monkeypatching will be confined to four lines, and will allow all the rest of the code to use public launchpadlib apis for the rest of the URL manipulation
<jelmer> it's about the same amount of code to cope with it sometimes being missing at the moment
<jelmer> perhaps I'm missing something here :)
<jelmer> abentley: hi
<abentley> jelmer, hi.
<jelmer> abentley: I'm looking for a way to walk over the ancestors of a revision but processing them in increasing distance from my current tip
<jelmer> abentley: is there anything in graph that allows me to do that?
<abentley> I don't think we have that specifically.  We have a breadth-first traversal.
<abentley> jelmer, does Graph._make_breadth_first_searcher do what you need?
<jelmer> abentley: it seems to, but it's also private
<jelmer> find_descendants sort of seems to do what I need, except in the wrong order
<abentley> jelmer, I don't understand how it can be the wrong order if it uses make_breadth_first_searcher and make_breadth_first_searcher works for you.
<abentley> jelmer, nm.
<abentley> jelmer, what about iter_ancestry?
<jelmer> abentley: I need to exclude a particular key and its ancestry
<vila> jelmer: log needs that for --exclude-common-ancestry
<vila> jelmer: see branch.iter_merge_sorted_revisions
* 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: spiv | 2.3.0 is frozen. Release plugins ! Build installers ! (rm vila)
<jelmer> \o/
<vila> jelmer: what's the landing policy for bzr-builddeb ? push when mp is approved ? 2 votes ? something else ?
<jelmer> vila: merge revision for branch when there is approval
<vila> jelmer: locally, and push to trunk ?
<jelmer> vila: yeah
 * vila slaps fingers for working in trunk
 * jelmer wished there was a "bzr merge --into" command
<jelmer> to say merge my branch into that one, with a particular message, rather than merging that one into mine
<vila> but... you need a working tree (if only for the conflicts)
<vila> merge is a serious operation you know, you can't just drop it on some random branch !
<vila> ;)
<jelmer> that's fine, I don't mind using the current one
<vila> oh, you mean --swap-parents ?
<jelmer> yeah, that's all I care about really :)
<vila> (don't search, it doesn't exist but has been mentioned several times)
<jelmer> I did search :)
<vila> sry :-/
<vila> jelmer: test failures fix pushed
<jelmer> vila: \o/
<vila> jelmer: and for bug status, committed and the RM mark them fix released ?
<jelmer> vila: yep
<jelmer> at least that's what I've been doing, hopefully james_w can correct me if I'm wrong :)
<vila> nah, looks fix-released when landed, but... https://launchpad.net/bzr-builddeb/+series isn't super clear 8-)
<vila> or fixreleased when mentioned in changelog ?
<vila> :D
<vila> anyway, landed, marked fixed :)
<james_w> I always used to do "commited" and then "released" on release, but it's kind of shaky given that it's a native package that I have sometimes uploaded to Ubuntu directly
<vila> james_w: ack
<vila> hmm, code import failures mail flood, that reminds me about adding a host monitor for the package importer (lp is done, debian is unreachable, etc) to avoid this kind of issue
<vila> s/done/down/ hee, that wasn't a joke ! Why did the tyop gnome keep jumping on my fingers !
<james_w> oh hey, Debian release due. That's going to require some co-ordination with the importer and Launchpad
<poolie> good morning
 * jelmer waves
<poolie> hi jelmer; what are you up to now?
<james_w> poolie, drowning me in merge proposals :-)
<james_w> but I imagine that jelmer sustains 12 other activities while doing that
<poolie> :)
<jelmer> poolie: I swear, the VCS imports emails are not my fault :)
<poolie> :)
<poolie> vila, still awake? we should consider doing a new 2.2.x soon i think, to get the sru going
<vila> poolie: yup, the question is: for what value of soon, I thought about it and whether it should be before 2.3.0 but decided that the later was more important
<vila> poolie: now, the second question is: ;)
<vila> poolie: should I freeze tomorrow or leave a bit of time to packagers,
<vila> poolie: but since we use pindependant branches and ppa, there is not a huge incentive to delay
<vila> poolie: so I probably freeze 2.2.4 tomorrow unless someone objects
<vila> jelmer: ha ! not your fault ! Who else can generate such amounts ?
<vila> :-p
<vila> OMG ! 23:20 local time ! The jetlag fairy is after me again or what ?  Back to the bed ! Back to the bed !
 * jelmer grins
<jelmer> vila: g'night :)
<maxb> speaking of independent ppas - do we really? normally I would start constructing 2.3.0 in proposed now, which would preclude 2.2.4 in PPA
<fullermd> Bed?  The sun isn't even up yet!
<vila> maxb: ouch, on the other hand, 2.3 will become the new stable, so all is really needed for 2.2.4 is bzr itself which you could upload directly (or blame the one who fixed the only bug there ;)
<vila> maxb, vila (note to self): may be worth documenting
<poolie> vila, also, i'd like to choose a good release name with you
<poolie> something fun, exciting, and meaningful
<poolie> hi jaypipes
<vila> hehe
<jaypipes> poolie: heyo :)
<vila> poolie: for 2.2.4 or 2.3.0 ? And could we do that tomorrow (argh, admin required for family bug :-/)
<jaypipes> poolie: ty for your quick response on those bugs/questions
<poolie> you're welcome
<poolie> vila, 2.3.0 tomorrow sounds' ok; let's not miss the natty boat
<fullermd> 'natty boat'?  What an odd release name   :p
<mgz> that's a natty boat you're paddling fullermd.
<mgz> what's happening with 2.3 and the no whoami case? I thought I read rumblings of wanting to change the behaviour there again.
<poolie> hello mgz
<poolie> i'd like to change it to use /etc/mailname if it's present
<poolie> i guess this missed 2.3.0 but it could make 2.3.1 in natty, possibly
<poolie> it seems to be quite a pain point for people doing automatic commits or using bzr to record /etc
<mgz> that sounds fine.
<mgz> just want to keep coverage where there's really no id, running as www-data and such like already has a few oddities.
<fullermd> No update to bookmarks plugin for 2.3   :(
#bzr 2011-02-04
<poolie> fullermd, is it broken or just not loading?
<fullermd> bzr: ERROR: exceptions.AttributeError: 'GlobalConfig' object has no attribute '_get_filename'
<mgz> looks like r5395, which appears to try and keep compat, wonder why it broke.
<mgz> ask vila tomorrow fullermd.
<fullermd> Oh, cool.  I'll tell him you made me pounce him first thing   ;)
<dOxxx1> good evening...
<dOxxx> jelmer: Are r302-305 of bzr-fastimport compatible with bzr 2.3.0? I'm currently building r301 with the mac installers. Can I update it to r305?
<poolie> hi d0
<poolie> dOxxx,
<dOxxx> hey poolie
<dOxxx> poolie: do you know the state of bzr-fastimport compatibility with bzr 2.3?
<dOxxx> there hasn't been a release since 2009 :P
<poolie> i don't know
<poolie> it was somewhat of ian's own project, though it is obviously useful to have generally
<poolie> jelmer expressed an interest in looking after it
<dOxxx> I see
<poolie> lifeless, what is 'pipefile in makefile'
<lifeless> pipefail sorry
<poolie> ah
<lifeless> *if* you make bzr selftest --subunit exit with nonzero
<lifeless> then you'l *also* need to set pipefail
<lifeless> otherwise the exit code will be ignored and swallowed by the pipeline
<poolie> if we make it exit nonzero, we should no longer need a pipeline afaics
<poolie> or do we?
<lifeless> thats an option too
<lifeless> depends on whether you want a human summary or not
<lifeless> pqm can interpret subunit for you these days
<lifeless> [which is another thing you might want to do in tarmac)
<poolie> so...
<poolie> does pqm do anything with the selftest.log file, or is that just there so we can run subunit-stats on it?
<poolie> or another way to ask is, what is the interface expected by pqm?
<poolie> just that you'll emit subunit to stdout?
<lifeless> pqm looks at stdout
<lifeless> and at the overall exit status
<maxb> Urgh, transition from python-central to python-support in 2.3.0-1 packaging. That'll be fun. I'll need to do something special for hardy IIRC
<maxb> dOxxx: bzr-fastimport 305 is in sid. I think you may safely assume that that means it's compatible with 2.3.0
<maxb> but yes, a release would be nice :-)
<maxb> FWIW my list of things that appear to need releases based on the ppas is:
<maxb> bzr-fastimport bzr-gtk bzr-loom bzr-rewrite  bzr-svn python-fastimport qbzr
<spiv> james_w: https://bugs.launchpad.net/udd/+bug/653307 just gets more and more confusing and alarming
<james_w> erk
<james_w> any idea how that could happen?
<spiv> james_w: in general, yes, but as I said in comment #7 I don't see any suspicious code at all
<james_w> hmm
<spiv> james_w: the way it generates commits seems completely typical and kosher
<james_w> spiv, you re-imported that package from nothing?
<spiv> I haven't, but I thought all the affected packages had all their branches deleted?
<spiv> Or rather, I did reimport locally, and with no trouble
<spiv> Although it's almost impossible to imagine seeing this problem during a signel, intial import run.
<spiv> Because that all happens in a single, shared inventory.
<spiv> s/inventory/repository/
<james_w> yeah, we deleted all the branches, but didn't re-import with the newer bzr
<james_w> so I wonder if it's still a fixed bug?
 * spiv rereviews the fixed bugs in 2.1 vs now
<spiv> (because it's not the non-canonical one that had seemed likely, although I'm very glad we aren't using that version of bzr anymore!)
<spiv> james_w: is there an easy way to do a local test run of just importing squeezy and then a second run to import sid?
<james_w> spiv, I don't think so
 * spiv hmms
<spiv> james_w: I'm still puzzled by the Feb 2010 timestamps on the files in the supposedly-deleted-then-recreated branches, too.
<james_w> spiv, why's that?
<spiv> james_w: well I'd expect Jan 2011, as that's when the new branches were pushed to LP?
<james_w> spiv, true
<james_w> spiv, are you talking about working tree files after a checkout, or the branch/repo files on LP?
<spiv> Repo files, e.g. look at http://bazaar.launchpad.net/~ubuntu-branches/debian/squeeze/dsdo/squeeze/.bzr/repository/packs/
<james_w> hmm
<james_w> 2010, you're right, that doesn't make a lot of sense
<spiv> Compre e.g. http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/packs/ in case you're wondering if it's something weird in the webserver :)
<spiv> So if for some reason the old branches weren't deleted we're *still* at the point where we haven't ruled out "ancient bzr/udd/builddeb/launchpad bug, fresh import will fix"
<spiv> But I'm not sure how thaey can't be deleted, because I'm preetty sure I was watching it happen :)
<james_w> yeah
<james_w> unless deleting via the webservice doesn't nuke things like we assumed
<james_w> but that seems very unlikely given that branches on disk are based on db ids
<james_w> maybe we need to try delete + reimport again
<mwhudson> 00/00/c9/3e is quite an old id too fwiw
<mwhudson> new branches are up in the 00/01/xx/xx space
<james_w> so old branch seems to be the most likely candidate right now
<spiv> mwhudson: higher, apparently: 00/06/0f/2a is the natty branch of dsdo
<mwhudson> spiv: oh ok
<mwhudson> my point still stands :)
<spiv> (time to start planning for expanding that ID column? :)
<dOxxx> maxb: thanks :)
<mwhudson> spiv: nah, you guys just have to implement colocated branches soon!
 * mwhudson afk for a bit
<maxb> hmm. bzr-gtk build failure in natty
 * maxb creates a cowbuilder chroot
<maxb> "Xvfb failed to start"
<maxb> This is NOT a useful error message :-(
<maxb> (bzr-gtk/jaunty)
<dOxxx> nope :)
<maxb> Just for complete bizarreness, it works fine on hardy and karmic
<achiang> hm, i was just surprised by some debcommit behavior, which i suppose is an issue there, not bzr. but maybe someone can enlighten me anyway...
<achiang> make a bunch of changes to files, but only 'bzr add foo bar'
<achiang> dch -a ; debcommit
<achiang> i would have expected a new commit with just a, b, and debian/changelog
<achiang> instead, i got everything. :-/
<mwhudson> um, you are familiar with git i guess?
<achiang> i suppose this expectation comes from the fact that i'm used to git's index. :(
<mwhudson> bzr ci commits all changes by default
<mwhudson> there is nothing like the index
<achiang> yes, it is my fault
<lifeless> it does what everyone else in the world expects :P
<mwhudson> bzr ci is like git commit -a i think?
<dOxxx> mwhudson: yes
<lifeless> no
<achiang> yeah
<lifeless> it does'nt add new files
<dOxxx> no?
<mwhudson> oh right
<dOxxx> ah
<lifeless> all versioned files are recorded, unknown files remain unknown.
<lifeless> gone files become unversioned and are deleted in the commit
<achiang> lifeless: i mean, sure, i'm not here to start a holy war. but a large portion of "everyone else" uses git. :-/
<achiang> but of course, the fault is mine in this case for having wrong expectations.
<achiang> re-reading the debcommit man page, i see that i should just call it with the files i want to commit next time
<achiang> ok, now this question *is* related to bzr -- i just did a bzr uncommit to recover from the bad debcommit
<achiang> it actually puts my tree back in the state before i did the debcommit, with uncommitted changes in the tree
<lifeless> thats right
<achiang> that is actually quite nice, but i am confused why it behaved that way? my reading of the uncommit man page makes me think that the -r -1 commit should just completely go away
<lifeless> it undoes the commit
<achiang> as if it'd never happened at all
<lifeless> the act of committing doesn't change the files you have on disk.
<lifeless> so neither does the act of uncommitting.
<achiang> interesting
<achiang> it also makes sense, the way you describe what commit/uncommit does
<achiang> lifeless: thanks for the help, i appreciate it
<lifeless> anytime
<achiang> (et al)
<james_w> whoops: http://package-import.ubuntu.com/status/libdbusmenu.html
<spiv> james_w: where "whoops" == "upgrade to bzr 2.3 broke stuff"?
<james_w> I assume so
<spiv> I only asked for an upgrade to 2.1.3, FWIW :)
<james_w> heh :-)
<james_w> I don't see it in the release notes
<poolie> hi all
<poolie> spiv, are you around?
<poolie> is https://code.launchpad.net/~spiv/bzr/fetch-all-tags-309682/+merge/42910 ready for re-review, or still WIP?
<spiv> poolie: I am, sort of
<spiv> poolie: power is still out, but jsut for my flat
<poolie> huh
<spiv> poolie: so currently chasing that up!
<poolie> good luck
<poolie> i was just going to quickly see if there was anything i should review
<poolie> but, perhaps i should instead do the whoami bug
<spiv> poolie: Off the top of my head all my patches are ready for rereview
<spiv> (It's a shame that's not a cleear yes/no at a glance, I wonder if I should do something differently)
<poolie> maybe you should resubmit when you get all the existing stuff done?
<poolie> that's not just you; i think just generally it's not clear when it wants more review
<spiv> *nod*
 * spiv has just run extension cables from the stairwell to the kitchen so the fridge can have power
<vila> . o O (spiv: Safety first: make sure the beers stay cold, errrr the milk ! I meant the milk !)
<vila> hi all !
<vila> fullermd: Oh dear, so sorry, I meant to look at that and... forgot :-/
<vila> fullermd: but note that `bzr config mypush` (backquotes) can ~replace 'bm:mypush' starting with 2.3 and poolie suggested 'config:mypush'
<poolie> hi vila
<vila> poolie: hey !
 * fullermd goes crosseyed trying to parse that...
<vila> fullermd: huh ? And I thought you had some perl background... I didn't even quote single chars there...
<fullermd> Well, I _lexed_ it just fine   :p
<spm> vila: perl has more use of shift-numbers = eg !&^%#@#*(&^)(
<spm> if it doesn't look like line noise, it's not perl :-)
<vila> spm: what's wrong with 'if ($c !~ /^%.*$/)' ? Crystal clear !
<spm> dear lord. I can parse that. AAAAAAAAAAAAA
<spm> :-)
<fullermd> Oh, good.  Now you're talking sense.
<spm> haha
<vila> spm: see ? This perl-is-noise meme is just crap ! :D
<vila> xml now...
 * spm digs up some old line noise captures to compare vs actual perl code, and finds the comparison... similar
<fullermd> XML definitely isn't line noise.
<fullermd> Line noise serves an actual _purpose_...
<spm> fullermd: 1, vila/spm: 0
<vila> LOL
<vila> ha, found back one of my favorite: 'local $/ ;' without comment :)
<fullermd> Yes, I have memories of stabbing people for crap like that...
<fullermd> Not legally actionable memories, of course.  I feel a sudden burst of amnesia...
<vila> for those reading from home, this set the line separator to None so the next read on the *default* file will read until the end of file
<vila> fullermd: very useful trick, you should remember to put it inside a block to limit its side-effect though ;)
<fullermd> It's so much more self-documenting to just $x = join '', <FILE>
<vila> my $text ; { local $/ ; $text = <FILE> ; } isn't that bad
<vila> with a '# Slurp it into memory'  comment just above
<fullermd> I still prefer the join.  It doesn't need a comment, or screwing with magic vars.
<vila> bah, no magic vars ? You spoil the fun !
<fullermd> Oh, no, I enhance it.  I only use my OWN magic vars.  Any fool can look up the _language's_ magic to work from; I like the bar for touching my code to be higher than that   :p
<vila> local ftw !
<fullermd> Any real win has global effect   :p
<vila> spiv: wow, bzr@jubany upgraded to 2.3b5 !!?!
<vila> spiv: this means I should track *that* into bzr-package-importer so we also get that after the migration...
<vila> spiv: I did not dare to do it, but since you did... :)
<maxb> *headdesk*
<maxb> So, properly removing bzr's internal copy of configobj shows us that.... hardy's python-configobj lacks features which causes test failures
<vila> . o O (Quickly throw a pillow on maxb's desk)
<vila> don't do that then ?
<maxb> ah well, I'll just back out the removal in the hardy PPA
<maxb> yay unit tests, I suppose
<vila> indeed, we may miss some about the features we really require from configobj though
<fullermd> I dunno.  I mean, it's hardly a coincidence that unit tests are responsible for a huge percentage of test failures...
<poolie> maxb, how long has hardy got to run?
<poolie> we could probably stop building bzr 2.4 for that
<maxb> desktop EOL at hardy release. server EOL at S-series release
<maxb> erm
<maxb> * hardy: desktop EOL at natty release. server EOL at S-series release
<vila> Z-series ? :D
<maxb> I am tempted to propose we drop all Jaunty packages, though
<fullermd> Taylor series?
<vila> maxb: +1
<maxb> Jaunty is EOL already. Just no-one has turned off PPA for support for it
<maxb> I'll send an email to make it official
<maxb> hmm
<maxb> Except, dropping jaunty doesn't actually result in saved effort, since pretty much any backporting effort you need, is needed to get back so far as hardy too
<poolie> right
<poolie> i wonder if building _new_ bzr series onto hardy is worth while
<poolie> perhaps we should separately backport configobj?
<poolie> but as i recall that gets complicated because of dependencies from other programs
<poolie> and i think it's hard to get new configobj working there
<maxb> bzr includes a copy of configobj - but we removed it in these packages because Debian folks picked up on the unnecessary duplication. So we just need to unremove it on hardy
<vila> poolie: well, we had to decide what kind of support we want to provide for hardy, main includes bzr-1.3.1 only so I'd say we'd better limit ourselves to the stable ppa as I don't think we will ever be allowed to release even 2.0 there
<vila> (there == hardy-updates)
<maxb> It's now possible to get download count info out of the LP API. We should see how many downloads bzr 2.3.0/hardy gets
<poolie> right
<poolie> maxb, i was thinking of removing it from the upstream tree too
<poolie> anyhow, i should go
<poolie> good night to you
<vila> right, but that won't tell us how many hardy sites may want to upgrade
<vila> poolie: g'night
<poolie> vila, i wonder how many people want to upgrade bzr and don't even want to go to lucid
<poolie> probably some
<poolie> removing a copy of configobj would be nice but it's not a big win
<poolie> anyhow, really goodby
<vila> yup, probably not that much and we can tell them to use the ppa
 * fullermd . o O ( bzr said I needed to upgrade my old Ubuntu, so I installed FreeBSD... )
<vila> ENOMATCH: Ubuntu or * better*, don't forget the better :-p
<fullermd> :P
<fullermd> 2.3.0 port update: http://www.freebsd.org/cgi/query-pr.cgi?pr=154496
<fullermd> miwi@ is fairly consistent, so probably committed in the next few days.
<vila> interesting diff...
<fullermd> Howso?
<vila> fullermd: the summary it provides is due to the FreeBSD process right ?
<vila> I mean, it gives an overview of which files were added (none removed apparently which is a bit weird)
<vila> ha, sorry, yes it does
 * fullermd isn't sure what you mean by 'summary'...
<vila> pkg-list
<fullermd> pkg-plist, as in 'packing list'.  Yeah, list of the files, so that deleting a package knows what to delete.
<vila> right
<vila> the whole diff contains almost no noise for a human reader (considering SHA as noise is a bit extreme but you get the idea)
<fullermd> Well, changing the big number in the launchpadlibrarian URL every upgrade is noisy for me  :p
<vila> fullermd: blame your packaging system for not being able to follow redirections ? :-D
<fullermd> But yah, it's not an overly verbose process.  The pkg-descr change I've meant to do the last handful of upgrades, but kept forgetting   :p
<fullermd> Well, it's _able_.  In fact, it goes to significant lengths to _avoid_ it   :p
<vila> why ?
<fullermd> (for a number of reasons, most of which are probably bad...)
<vila> ha
<vila> some good ones worth mentioning maybe ?
<fullermd> The only potentially good one I've ever heard has to do with those "brilliant" sites which respond with redirects instead of 404's to nonexistent files, and that sort of garbage.
<vila> by the way, did I already asked you about some way to get a list of plugins with their releases/revids/revnos from The Ports ?
<fullermd> Leads to user confusion when the downloaded tarball fails the SIZE/SHA256 check because it contains 10k of HTML instead of... y'know.  A tarball...
<vila> hmm
<vila> bad sites, bad, bad, bad
<fullermd> Not sure you did.  I can't offhand thing of a totally automated way...
<vila> no urgency but it would be nice
<fullermd> Only one I manage is bzrtools.  C-S maintains a half dozen of them I think...
<fullermd> freshports probably has a list somewhere you can pull of "all ports that depend on X"; most of those are probably plugins.
<fullermd> Don't see one offhand.  Well, can script it out of INDEX pretty easily, I imagine.
<fullermd> Ideally as a perl one-liner, with over half the characters requiring the shift key.  Naturally   :p
<vila> Shift Copy/Shift Paste :D
<vila> fullermd: If you can propose a mp with a script in tools/packaging, I'll gladly help refine it (long term thingie, may not find its way in 2.3, yada yada)
<fullermd> Hmm...   well, still too readable, but...
<fullermd> http://pastebin.com/Ysa4khCk
<vila> wow
<vila> do you really need the progress bar there ? (/\|/) :D
<fullermd> Hey, INDEX is a big file   :p
<fullermd> Feel free to add a 'local $/;' on to the beginning if it makes you happy   ;)
<vila> lol
<fullermd> Alternately: `grep bazaar-ng /usr/ports/INDEX-8 | cut -f1 -d\|`.  But who wants to waste all that time with a pipeline?
<vila> 8 is for FreeBSD8 right ?
<fullermd> (and that also lists bazaar-ng itself, which obviously doesn't depend on bzr, so you waste a bunch of electrons outputting that...)
<fullermd> Yah.  Though I doubt that particular list changes across versions much...
<vila> copy/pasted into my freebsd8/INSTALL tip&tricks file
<fullermd> Very good.  You'll receive my invoice shortly   8-}
<vila> hehe
<vila> . o O (fullermd.debt.beers++)
<jelmer> hehe
<vila> jelmer: morning !
<jelmer> bonjour!
<vila> fullermd: bug 712935, if you want to subscribe
<ubot5> Launchpad bug 712935 in Bazaar Bookmarks Plugin "_get_filename deprecated in bzr-2.3" [Undecided,In progress] https://launchpad.net/bugs/712935
<jelmer> vila: 2.3.0 uploaded to Debian
<vila> \o/
<vila> fullermd: mind to test https://code.launchpad.net/~vila/bzr-bookmarks/712935-2.3-compat/+merge/48589 ?
<vila> fullermd: no test suite for the plugin :-/ I did a bunch of manual tests but I may have missed some
<luks> vila: if I reassign bzr-bookmarks to you, will it solve the problem? :)
<vila> luks: wow, instant feedback !
<vila> luks: ideally you'll assign it to ~bzr (I think) so any bzr dev can participate
<luks> ok
<vila> luks: And thanks for pioneering this config area !
<vila> luks: you had many good insights showing in the code...
<luks> well, it was always just a hack :)
<luks> anyway, the problem is reassigned
<luks> if you could create a native LP branch and merge your changes, it would be great
<luks> because now I can't :)
<vila> luks: Great !
<luks> er, the project
<luks> (reassigned)
<vila> I'll look into it asap
<vila> fullermd: feedback even more highly welcome ;)
* 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: spiv | 2.2.4 and 2.3.0 are frozen. Release plugins ! Build installers ! (rm vila)
<maxb> vila: Thanks for approving my udd just-cleanup branch. Can I also ask you to land it, as I am not in ~udd ?
<dOxxx> vila: mac installer 2.3 branch is pushed
<vila> maxb: gimme a sec but I won't forget
<vila> dOxxx: great,
<vila> dOxxx: I just froze 2.2.4 but I don't think we want OSX installers for it, 2.3 is the new stable
<dOxxx> yah I saw your email
<vila> dOxxx: if you know someone with an OSX 10.5 host...
<dOxxx> actually, I do... sec
<dOxxx> vila: Craig Sawyer csawyer@yumaed.org, he let me access a OSX 10.5 machine on his network a few times last year until you started building them.
<dOxxx> vila: I don't know if I have time to get it done today though
<vila> dOxxx: if you can forward him the 2.3.0 has gone gold mail so he get the pointers that would be great
<dOxxx> vila: well, he wasn't the one doing the building, he just gave me ssh access to the machine.
<vila> dOxxx: oh, well, then this will need a bit of discussion with him, drop him a note to close the loop then ?
<dOxxx> vila: I'll email you both
<vila> dOxxx: excellent !
<vila> maxb: done
<maxb> thanks
<vila> maxb: but not deployed yet
<vila> maxb: doesn't really matter, just mentioning
<maxb> It has no operational effect, it just makes developer's lives more pleasant
<vila> maxb: indeed ;)
<james_w> ah, thanks vila
<james_w> sorry for not landing it straight away maxb
<vila> james_w: my pleasure
<maxb> no rush. Just didn't want it to sit and be forgotten
<maxb> jelmer: The last revision in lp:bzr-builddeb introduces a new bug. It looks like you missed one call to db.has_pristine_tar_delta(rev) in your refactor
<jelmer> maxb: looking
<trond-> hi room. I've just started with bzr and I'm wondering: I have a website created for one client where code base is going to be used for another client (allowed), how do I do this?
<jelmer> trond-: you should be able to create a clone use "bzr branch"
<trond-> jelmer, ok. so then brz branch (name of directory) (name of new/other existing directory)?
<jelmer> trond-: yep
<jelmer> see also the documentation
<trond-> jelmer, I will. Thanks :) just needed the first direction
<vila> trond-: name of new, yes. other existing directory...  likely to fail
<trond-> vila, yup. it did. :)
<vila> good :)
<jelmer> vila: thanks for the reviews :)
<vila> np ;)
<vila> warming up for next week :)
<mgz> fullermd caught you about the bookmarks plugins I see vila.
<mgz> I'm a bit suprised it broke, your commit looked like it tried to retain compat.
<vila> mgz: hehe, I will feel less gulty when it'll be merged in core (feature wise)
<vila> mgz: err, really ? That's wasn't my intent ;)
<vila> mgz: err, really ? That wasn't my intent ;)
<vila> Without a test suite, I played it safe and tested my patch against 2.3 err 2.4b1 only
 * vila is bad :)
<dOxxx> tsk!
<mgz> ah, I see, you detect the old api but didn't continue to provide it.
<vila> mgz: ha ! right, yeah, that's only by fixing bookmarks that I realized I left a hole in the compatibility
<vila> . o O (Freudian slip to push to the new API ? Well hidden...)
<mgz> python doesn't make this stuff easy.
<dOxxx> dynamic typing is both a blessing and a curse :)
<vila> errr, wth is going on ? 57 branches in the active reviews page ?
<mgz> I see a normal number on <https://code.launchpad.net/bzr/+activereviews>, which page are you looking at?
<vila> https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews
<vila> how did I arrive there ???
<dOxxx> click the back button ;)
<vila> from here: https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev
<vila> dOxxx: hehe, no, previous tab :D
<mgz> ...maybe that's a launchpad change to that link.
<dOxxx> heh
<vila> and from here: https://code.launchpad.net/~jelmer/bzr/extra-branch-formats/+merge/48608 I clicked the Merge Into: lp:bzr link...
<vila> the weird thing is that these two branches are supposed to be the same one...
<dOxxx> hmm that seems wrong
<dOxxx> looks like launchpad is resolving lp:bzr wrong?
<mgz> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/changes/12274 <- that page is slightly annoying to try and read
<mgz> launchpad's multiline commit messages don't really work with the loggerhead output
<vila> got it, the long page shows the wips
<vila> no idea why
<mgz> bug 707808
<ubot5> Launchpad bug 707808 in Launchpad itself "Unmerged revisions list does not exclude merged revisions" [Critical,Fix released] https://launchpad.net/bugs/707808
<mgz> ...nope, not that
<mgz> bah, too much stuff.
<mgz> "some launchpad change".
<jelmer> :)
<vila> jam: -Dxxx Critical ? Isn't it a bit excessive ? We know we'll blame mgz anyway, don't be too hasrsh :D
<jam> vila: it's poolies fault
<jam> and I've tracked it down
<mgz> ...whaddidibreak?
<jam> but yes critical
<jam> vila: We used to track how many bytes a command took. we now *always* get 0
<jam> IMO, that is a regression
<jam> hence critiacl
<jam> critical
<jam> not data loss critical
<jam> but I probably would have blocked the release if I had known
<jam> mgz: you didn't break it, though I suspected you first, too :)
<mgz> :D
<jam> I thought the get_transport() stuff changed us tracking the bytes transferred
<jam> but we still tracked it.
<jam> but it turns out we through away the info right before we went to log it
<jam> threw away
<jam> vila: also, -Dbytes only shows it to the user. we always log it so that we can go back and see if a command is being reasonable
<mgz> will people throw pots at me if -Dthing is important not to break, it should have tests?
<mgz> +I say
<vila> jam: what I don't get is how none of us saw it before, I'm running from trunk and most of my usages are from the command line...
<vila> ...hmmm, wait, is it for all operations or for uploads ?
<vila> Nah, I also push manually...
<vila> mgz: I didn't suspect you for one second :) But between you and jelmer, I thought it would be funniest with you :D
<jam> vila: all operations
<vila> jam: we have switched and tested multiple times around the hack-around-the-hook
<jam> and yes, I run bzr.dev
<jam> what happens is that if the number of bytes is 0, then it doesn't print anything
<jam> so even though I have '-Dbytes' set to always on
<jam> I don't notice that it isn't reporting
<vila> ha, but that doesn't impact the progress, only the end report in log ?
<jam> right
<jam> the final log is not correctly showing
<jam> nor is it being logged to .bzr.log correctly
<jam> I noticed because of the emacs question
<jam> so I went to see how much is transferred, and it was saying "0"
<jam> :)
<vila> . o O (My evil plan to market bzr as the fastest dvcs for internet just died...)
<vila> anyway, I've EOWed, I must really go ;)
<vila> I'll try to check later !
<vila> Have fun all !
<sobersabre> hi guys.
<sobersabre> I see there is a 2.3.0 release.
<sobersabre> when will the windows build be online on https://launchpad.net/bzr/+download ?
<vila> sobersabre: where did you see that ? It hasn't been officially announced *because* we want as many installers available as possible when we do
<vila> sobersabre: anyway, 2.3.0 frozen yesterday, release *planned* Thursday :)
<vila> sobersabre: the rhythm these releases is: freeze on Thursay, releases on Tuesday, but we take a bit more time to start our new stable release, so: Thursday
<vila> jam: well done ! I wonder if we want some king of hook there to make it easier to avoid this kind of failure (but you've probably added a test already)
<jam> vila: working on a test right now
<peitschie> mornin all :)
#bzr 2011-02-05
<alexMocanu> Hi everyone!
<alexMocanu> I am not sure how Bazaar and Launchpad work together
<alexMocanu> so for example if i do bzr branch lp:unity
<alexMocanu> a branch of Unity is created on my computer
<alexMocanu> but if I try to commit the code what actually happens? Because it probably won't modify the code on the website
<alexMocanu> I see it just modifies my files. So basically I am working on a branch on my computer and only when I think it is suitable to merge it with the trunk I proceed to do that?
<alexMocanu> But what if the project trunk gets modified when I'm working on my branch? This means I'll work on an outdated version
<lifeless> alexMocanu: then you can merge or pull in code from the unity trunk
<alexMocanu> lifeless: yes, but isn't my work going to be overwritten? :)
<lifeless> no
<delaman> im runnning Ubuntu with the main language in Spanish.  I installed Bazaar Explorer and I want it to be in english.  I did the following http://pastebin.com/JmVYBv48  however the explorer still shows up in spnaish.  how can i fix this?
<delaman> let me put the whole thing here http://pastebin.com/YyMeYyN5
<delaman> i got it to work with
<delaman> LANGUAGE=en
<scorp007> can bzr reorder commits similar to git rebase -i ?
<lifeless> theres some support for that in the bzr rewrite plugin
#bzr 2011-02-06
<scorp007> lifeless, which command would I need to look at? rebase doesn't seem to have this feature.
<gthorslund> scorp007: I think lifeless was referring to https://launchpad.net/bzr-rewrite
 * gthorslund zZz afk
<scorp007> yes but that plugin essentially provides the rebase command. And as I said earlier, rebase doesn't seem to support reordering.
<AfC> Is there a reason why "bzr-builddeb 2.6" in only in the Bazaar PPA for juanty,karmic,lucid?
<AfC> as far as I can tell, 2.2.0 is what's in Maverick. Should I be [trying to] use something newer?
<taylanub> undocumented features FTL.  on the haunt for the bug that causes bzr to hang in the case the log file is a symlink, i found out that a BZR_LOG env var is supported. no mention of that in the manpage even though there's a section mentioning other BZR_* environment variables
<taylanub> hrmm, really weird; the bug seems fixed, even though i'm still on the same bzr version. same python version too...
<taylanub> anyway, /me exports BZR_LOG=/dev/null in etc/sh/profile
<fullermd> I've got .bzr.log symlinked to /dev/null in one or two places...
<maxb> AfC: bzr-builddeb 2.6 is in maverick itself. there's no need for a newer version in the PPA
<AfC> maxb: uh
<AfC> maxb: $ bzr plugins
<AfC> builddeb 2.2.0
<AfC> ?
<AfC> ah
<AfC> $ dpkg -l | grep builddeb
<AfC> 2.6ubuntu0.1
<AfC> ok
<AfC> I get it now
<AfC> (someone needs a kick)
 * AfC goes away happy in the certain knowledge that he has a properly up to date version
<AfC> maxb: thanks
<sobersabre> hi.
<sobersabre> Is it possible to branch a subdir of branch root ?
<sobersabre> i.e. I have a dir /proj, which has .bzr dir. I Want to branch its subdir, /proj/module1
<inada-n_> https://lists.launchpad.net/bzr-packagers/msg00093.html
<inada-n_> I can't recieve this mail by gmail.
<inada-n_> IWATA-san too.
<inada-n_> Anyone can recieve it?
<mgz> didn't go to <bazaar@lists.canonical.com> so I wouldn't be getting it anyway, sorry.
<mathrick> hiya, is there any way to use the python bundled with standalone Windows installer as python?
<mathrick> that is, I need to install dulwich to be able to use bzr-git, and for that I need python to invoke setup.py
<treaves> Would someone point me to where I can find options for the bazaar.conf file?
<treaves> Specifically, I'm trying to find the setting to keep Bazaar from creating backup copies.
<mathrick> treaves: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/configuring_bazaar.html
<mathrick> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/configuration-help.html tpp
<mathrick> *too
<mathrick> treaves: backup copies of what?
<treaves> Of anything.
<mathrick> you'll have to elaborate with some examples
<treaves> It creates files & directories that are backup copies.  And it tells you it is doing it too.
<treaves> These have tilda's in the name.
<treaves> SomeDeletedFile.~1~
<mgz> mathrick: if you want to do clever things, you're better off installing python seperately and then using the windows installer for bazaar-on-your-python-version not the all-in-one bundle
<mathrick> mgz: yeah, I might need to do that
<moebiuspersona> Hey, I have a quick question.
<moebiuspersona> Can I set a different private key file for Bazaar?
<lifeless> ssh key?
<moebiuspersona> Aye.
<lifeless> it just calls into ssh
<moebiuspersona> So it has to be my default SSH key?
<lifeless> so if you put the public key you want on the server you're connecting to, and add the private key file to your ssh agent, you should be set.
<moebiuspersona> I just use openssh and specify different keys for different servers with -i.
<moebiuspersona> I'll just do the easy thing and make my Bazaar key my default key, then use the other key explicitly.
<lifeless> its generally controlled by the server
<lifeless> all you need to do is add all the keys you want to your agent
<lifeless> I wonder if openssh has an environment variable equivalent to -i
<mathrick> moebiuspersona: that's odd, it should just ask for the proper key
<moebiuspersona> It's probably because I'm not using ssh-agent or anything.
<moebiuspersona> It's not a major thing, anyway. I just renamed my private key files.
<lifeless> you could cat them together
#bzr 2012-01-30
<vila> hi all
<vila> heya poolie
<poolie> hi there
<poolie> time flies
<poolie> how are you?
<vila> fine, was in Paris this past week-end ;)
<poolie> lucky you
<Merwin> Hi ! I pushed a modification on a remote repo, but I want to revert it locally and remotly
<Merwin> Should I use bzr revert and the commit+push?
<Merwin> vila ?
<vila> Merwin: ?
<Merwin> Good morning ;)
<Merwin> <Merwin> Hi ! I pushed a modification on a remote repo, but I want to revert it locally and remotly
<Merwin> <Merwin> Should I use bzr revert and the commit+push?
<vila> the main question is about your remote branch, who is using it and did they already pull the modification ?
<Merwin> Nope, I told them to not pull
<Merwin> What if they did? :
<vila> if not, uncommit/revert&tweak&whatever/commit/push --overwrite
<vila> if yes, they will need to pull --overwrite instead of a simple pull
<Merwin> ok
<Merwin> And if they have not-pushed commits? :D
<vila> they'll need to merge and resolve the conflicts locally
<vila> you can also avoid the whole issue by just committing a reversed merge of your unwanted change
<vila> i.e. your branch history will then contain both the change and the removal of the change instead of not mentioning the change at all :)
<vila> It flows better with distributed workflows but ultimately is a mater of personal taste
<Merwin> vila, you mike like "commit an 'inversed' commit" ?
<Merwin> Here, I commited something I want to cancel, but they worked and modified the repo since my commit
<Merwin> So I have to undo what has been done in the commit, and recommit
<Merwin> Is there a way to do this automatically ?
<vila> with X being your unwanted commit: bzr merge -rX..X-1 .
<Merwin> Hum, I'll try
<Merwin> bzr merge -r371..371-1 .
<vila> 371..370
<Merwin> bzr: ERROR: Requested revision: '371-1' does not exist in branch
<Merwin> Ah
<Merwin> Lol, I look stupid right now :p
<vila> hehe, I don't think so, failing is the best way to learn
<Merwin> Nice, it worked very good
<Merwin> I don't understand why I have to use merge here...
<Merwin> But it worked :p
<vila> it's called a sherry-pick (merge a revision range instead of a branch) and is the easiest and safest way to reverse a change
<vila> heya mgz !
<mgz> morning!
<Merwin> vila, http://friendpaste.com/2TAVKpXwcJV3PdPlrlEOBn
<Merwin> This is because of the cherry-pick ?
<vila> meh, check which branch is used for which command, 'bzr missing :push' should clarify a bit
<vila> but the 'diverged branches' is probably because you uncommit at some point or because someone else pushed there
<vila> Merwin: hmm, have a look at 'bzr config' too, you probably have a 'submit_branch' option defined now that is... confusing stuff, get rid of it
<vila> Merwin: 'bzr config --remove submit_branch'
<Merwin> I think that when I did the cherry pick from '.', it changed the default branch location
<Merwin> Specifying the good location resolved the problem
<Merwin> vila, thanks
<jelmer> 'morning poolie
<poolie> o/ jelmer, mgz
<mgz> hey poolie
<poolie> jelmer, the bug for junk might be a dupe, but i support it either way
<jelmer> poolie: I'll have a look
<jelmer> poolie: I vaguely recall that jam once described it to me as a feature of baz or tla
<jelmer> maybe that wasn't entirely the same thing
<jam> jelmer: baz/tla did have a non-precious ignored file as a separate concept from a precious ignored file
<jam> I think the final decision we had come up with, was actually to have a precious ignored
<jam> and make standard ignored 'junk'
<jam> at least I thought that was what poolie had settled on
<jam> because prob 95% of ignored files today are junk, and just a few cases where they are passwords, etc.
<mgz> yup, that would be neat.
<dholbach> hiya
<dholbach> I was just wondering: can you see the private ubuntu bzr bugs?
<jelmer> dholbach!
<dholbach> hey jelmer
<jelmer> dholbach: only those of us who are also ubuntu members
<jelmer> s/members/developers/
<dholbach> ok, I think I'll have a look at them now and see if there's anything private in there and unprivate
<jelmer> dholbach: in other words, only poolie and me
<jelmer> dholbach: thanks!
<dholbach> ok, they're public now
<dholbach> jelmer, am I the first reporting problems with the new bzr/bzr-builddeb combo when it comes to UDD? :)
<dholbach> for some reason almost every udd merge I do brings me a crash (I collected 3 different ones now)
<dholbach> ah sorry, you're patch piloting - nevermind then :)
<jelmer> oops
<jelmer> actually, mgz is patch piloting this week
<jelmer> dholbach: I haven't seen any other bug reports on it yet - can you send in bugs for the issues?
<dholbach> yep, sent them already (923706, 923691, 923688)
<jelmer> thanks!
<Alan502> Hello, I've been trying to commit some changes to a project but I keep getting this error: bzr: ERROR: Cannot lock LockDir(chroot-64962512:///%2Bbranch/classlink/.bzr/branch/lock): Transport operation not possible: readonly transport can somebody help me?
<jelmer> hi Alan502
* jelmer changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: mgz
<jelmer> Alan502: what are you trying to do exactly?
<Alan502> jelmer, hello :)
<Alan502> i'm trying to commit changes to a project
<Alan502> by using bzr commit -m "comment"
<fullermd> I'd guess a checkout over http.
<Alan502> bzr checkout?
<jelmer> Alan502: as fullermd says, it does indeed sound like you're trying to do a commit but the location you're committing to doesn't allow writing.
<Alan502> I see
<jelmer> Alan502: are you perhaps committing in a local branch that's bound to something else?
<Alan502> hmmm
<Alan502> jelmer, I am trying to commit to a launchpad project that me and my friend created
<jelmer> Alan502: how did you check out the launchpad project?
<Alan502> I need to register on that project first at launchpad.net right?
<Alan502> I just pull to get the files
<jelmer> Alan502: did you create a checkout or an entirely new branch of the project?
<Alan502> it says "not a branch"
<Alan502> nooo
<Alan502> i haven't created a checkout
<jelmer> Alan502: how did you create what you have locally?
<Alan502> how do I do it?
<fullermd> Let's just shortcut to 'bzr info'   8-}
<Alan502> bzr pull lp:name
<Alan502> jelmer, let me check bzr info :)
<Alan502> http://pastebin.com/0KrrcXfg
<fullermd> Right, checkout.
 * fullermd wins!
<Alan502> aha?
<Alan502> xD
<jelmer> Alan502: do you have write access to lp:classlink?
<jelmer> Alan502: are you matthewowebb ?
<Alan502> I guess that is the problem, I have to set that in launchpad right?
<fullermd> I'm guessing you don't _want_ a checkout, considering you're pushing to a different location as well.
<Alan502> nope
<Alan502> Can I get write access as a different user=
<jelmer> dholbach: thanks for the bug reports. I fixed one, will have a look at the other two a bit later.
<Alan502> i'm trying to use the gui on the ubuntu repositories :P
<vila> jelmer: what's the possible values for quilt-tree-policy ?
<vila> ha, found in the tests: applied or unapplied...
<vila> jelmer: meh, it's still unclear to me which one I should use for the importer :) There is no 'leave-me-alone' acceptable value ;)
<jelmer> vila: the default
<jelmer> vila: quilt-tree-policy is disabled by default
<jelmer> vila: you probably mean quilt-smart-merge ?
<jelmer> vila: that's just a boolean option.
<vila> I meant the one that leads to the lxc failure
<jelmer> vila: you want 'quilt-smart-merge=False' for that
<vila> okydoky
<vila> jelmer: ouch, I missed the ssl.ca_reqs=optional case
<vila> jelmer: your second remark is still about the 'optional' case right ?
<jelmer> vila: yes
<vila> jelmer: checking the lazy option: what the use case for 'optional' ?
<vila> sounds like a  feature for python's ssl to allow backwards compatibility by using it as a default value
<jelmer> vila: it's useful if you talk to servers that don't actually have ssl certificates
<vila> err, you mean a certificate signed by an unknown authority ? I don't think you can setup an https server without any certificate, am I wrong ?
<vila> otherwise that'd be an http server ;)
<dholbach> jelmer, you rock!
<SamB> vila: Well, it *could* just make up a certificate on the spot. (Though that *would* consume a lot of CPU/entropy to no purpose ...)
<vila> No, a certificate should be signed, you can't do that on the spot unless you also create the authority on the spot ?
<vila> but searching for certificateless ssl returns some results, there is apparently a rather obscure way to do that
<gypsymauro> hi
<gypsymauro> how can I tell to bzr that my local files are correct and overwrite the modified on the repository?
<jelmer> HI gypsymauro
<jelmer> gypsymauro:  just commit your local changes?
<gypsymauro> jelmer: I've already committed changes form another host.. but I forget to done an update so now I want to take as good just my local changes
<jelmer> gypsymauro: merge?
<gypsymauro> jelmer: of course, but 'cause I'm sure that local is perfect I just wont to overwrite remote :)
<jelmer> gypsymauro: in that case "bzr push --overwrite"?
<gypsymauro> jelmer: can I pm you? just for not showing my paths :)
<gypsymauro> bzr push --overwrite bzr: ERROR: Working tree ..... has uncommitted changes (See bzr status). Use --no-strict to force the push.
<gypsymauro> it's a good idea?
<mgz> okay, have a handle on bzr-explorer changes needed for filesystem watcher, just need to split up the code across the different bugs
<nDuff> Is authentication.conf expected to work for bzr-svn?
<poolie> o/ jam
<poolie> jam, what we did vs tla was:
<poolie> the default is 'precious' because they might be precious (seems safer though a bit more annoying)
<nDuff> ...funny thing is that the logs indicate that it's seeing saved credentials: Obtaining username and password for SVN connection '<https://REDACTED:443> Authorized'(username: 'duffy')
<poolie> allow them to be orphaned as a compromise between not losing them and not being annoying
<poolie> nDuff, i would guess libsvn will read it
<nDuff> ...but below that: PermissionDenied: Permission denied: ".": OPTIONS of 'https://REDACTED/svn/repos/puppet': authorization failed: Could not authenticate to server: rejected Basic challenge
<lifeless> nDuff: perhaps something in .subversion/auth ?
<nDuff> lifeless: poked at it a bit -- the svn command-line tool is having no trouble using the cached credentials, which implies to me that that configuration is in a good state; still no love from bzr-svn.
<jelmer> nDuff: hi
<jelmer> nDuff: what platform are you on?
<nDuff> jelmer: I'm using the bzr-svn-1.1.0-1 package (with bzr-2.4.1-1ubuntu1) from Linux Mint 12 (x86_64).
#bzr 2012-01-31
<m3ga> hi. bzr is not working on me. from ~/.bzr.log : http://paste.pocoo.org/show/543402/
<m3ga> bzr version is from debian testing
<AuroraBorealis> does bzr support "glob' syntax that git/hg do? (as in can i copy/paste their ignore files have)
<Peng> AuroraBorealis: Yes, but not necessarily precisely the same syntax. bzr help ignore
<AuroraBorealis> k
<Peng> I dunno about git, but converting hg should basically be a copy+paste, but you will need tweaks, if only taking out "syntax: glob".
<AuroraBorealis> http://stackoverflow.com/questions/4095696/mercurial-hgignore-for-visual-studio-2010-projects
<AuroraBorealis> so the [Bb]uild[Ll]og.* stuff will work if you just put RE: infront of it?
<Peng> I guess.
<AuroraBorealis> there is 'bzr help patterns' which says yeah that works
<m3ga> damn, that's just really silly. "bzr branch somerepo" used to just work and now it gives what i think is an obscure error message. bzr: ERROR: Target directory "" already exists.
<Peng> I'm 15% sure that's a bug that was fixed.
<m3ga> this is in debian testing
<lifeless> m3ga: branching a branch, or a repo ?
<m3ga> branch
<lifeless> hmm, thats gotta be a regression
 * lifeless handwaves and blames bzr-colo prep work (jelmer :P)
<m3ga> 2.5.0dev6 in debian testing
<Peng> *.log:6659032:2012-01-25 15:02:07: < jelmer> vila: no, that's not actually fixed yet but it's on my radar
<m3ga> thanks Peng. pity it already made its way into debian
<vila> hi all !
<hariom> I want a binary file to untrack. How to do that?
<hariom> I have added that file in .bzrignore but still in bzr status I see that file appearing in modified: list
<poolie> bzr rm --keep THING
<poolie> you may also want to uncommit, if you just committed it, then recommit without it
<hariom> poolie: I hope it won't remove the THING. Does --keep ensure that?
<vila> hariom: yes, that's what --keep does
<poolie> hi vila
<vila> hey poolie !
<poolie> hi, how are you?
<mgz> morning all
<poolie> hi there
<vila> poolie: fine, was able to deploy pristine-tar and pbzip2 late yesterday, I'm looking at the fallouts but we're down to ~400 failures (some new ones have appeared as usual ;-})
<poolie> that's great
<poolie> maybe i should follow up on the list
<jelmer> hey
<wgz> you guys carry on, I'll fiddle here
<mardy> hi all, "bzr pull" from a local git repository suddenly started failing for all my projects: bzr: ERROR: Error reading from 'refs/heads/'.
<vila> hghgnh lp downtime
<vila> jelmer: ping, pm
<mgz> you should just pick a public channel vila :)
<vila> different subjects ;) Here, I'd like to mention I'll propose a merge to introduce 2.5b6 before we do 2.5.0 and that will mean retargeting the existing bugs
<vila> that is, as soon as lp is back
<vila> which seems to be the case already
<mgz> yup, fdt is annoying because it's dt just when we're working, but it is at least f
<elmo> halp, wat
<elmo> Uncommit these revisions? ([y]es, [n]o): yes
<elmo> bzr: ERROR: An inconsistent delta was supplied involving 'modules/geoip/templates/geoip.erb', 'geoip.erb-20110907035659-stu7uecbpgflsa0u-1'
<elmo> reason: Unable to find block for this record. Was the parent added?
<elmo> the uncommit appears to have taken - I'm now on $revno-1, but I'm scared by the ERROR message
<mgz> like bug 910002 maybe?
<ubot5`> Launchpad bug 910002 in Bazaar "uncommitting a dir rename causes InconsistentDelta error" [Undecided,New] https://launchpad.net/bugs/910002
<vila> elmo: bzr version ? plugins ?
<elmo> mgz: hmm, I do have a bunch of renames, but not of directories, but checking
<mgz> that's a good bug report.
<mgz> why's it still new...
<elmo> vila: precise, so 2.5b5 - no funky plugins I know of
<mgz> elmo: so, summary, don't be too scared because it's 'just' a dirstate error, which worst-case you can alwasy regenerate
<mgz> but if you've got a slightly different from that existing bug, it would be good to add info there
<vila> jelmer: filed bug #924220
<ubot5`> Launchpad bug 924220 in Bazaar "ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
<mgz> somewhat telling stat about the last few weeks, 2.5 is on r6465 but dev is only on r6456
<mgz> hm. that's a switch regression
<elmo> mgz: should I be worried about 'inconsistent parents' in bzr check output?
<mgz> `bzr switch -b existing_dir` now gives a LockDir error rather than just saying it already exists
<mgz> elmo: well, to be safe you can do `bzr branch -r($revno-1) . ../new_tree` then copy over the changes
<mgz> but no, probably.
<elmo> mgz: ok
<elmo> mgz: #910002 updated, thanks
<mgz> elmo: thank you very much.
 * mgz optimistically targets it
<jelmer> mgz: that indeed is a very nice bug report
<jelmer> so far the InconsistentDelta bug reports have all been very vague and hard to reproduce
<mgz> I've put it on my queue to look at after the stuff needed for the freeze this week are done.
<jml> Most of my local Bazaar projects are set up in treeless repos where I use a checkout
<jml> I really want to try colo support, so I'm installing the nightly bzr
<jml> how do I start hacking on one of my existing projects (e.g. testtools) with colo?
<jelmer> hey jml
<jelmer> jml: "bzr switch -b colocated-branch-name"
<mgz> I'd create a new testtools repo locally with colo on, then branch any works in progress into it
<jelmer> mgz: there's no need to enable colo anymore
<mgz> as I think we discussed the other day, there's no easy migration tool from shared-treeless to colo currently
<jelmer> you can just do it in an existing branch
<mgz> ah, I missed the nightly part.
<jml> interesting.
<jml> jelmer: and I can blame you if everything goes pear-shaped?
<jelmer> jml: well, there are still quite a few rough edges
<jelmer> but you won't lose any data
<jelmer> it's not a new repo format or anything like that
<jml> jelmer: sweet.
<jml> jelmer: so when I try "bzr switch -b new-branch-name" and then type "bzr branches", I only see '* (default)' listed
<jelmer> jml: are you in a lightweight checkout perhaps?
<jml> jelmer: I am.
<Stavros> hello
<jelmer> jml: That would explain it. "bzr switch" creates branches in your original directory, "bzr branches" lists branches in your current directory
<jelmer> hi Stavros
<Stavros> i'm trying to use bzr-git, i've installed dulwich and did "bzr branch lp:bzr-git .bazaar/config/plugins/git" but it's saying "unknown protocol" for git+ssh
<jelmer> Stavros: it should be in .bazaar/plugins/git, not .bazaar/config/plugins/git
<Stavros> jelmer: sorry, that's where it is
<Stavros> jelmer: it fails properly when i rename it to bzr-git
<jelmer> Stavros: does "bzr plugins" list it?
<jml> jelmer: is that a bug? should I be using a full & proper branch with tree instead?
<Stavros> ah,   ** Unable to load plugin 'git'. It requested API version (2, 5, 0) of module <module 'bzrlib'
<jelmer> jml: if you're using colocated branches, you should beu using a full and proper branch instead; there is no point in mixing shared repositories with treeless branches and colocated branches
<jelmer> Stavros: which version of bzr are you using?
<jml> jelmer: good point.
<Stavros> 2.4.2
<jelmer> Stavros: that explains it, bzr-git trunk only works with bzr 2.5
<Stavros> that's weird, i have the bzr ppa
<jelmer> Stavros: you probably want to use a release
<Stavros> oh
<Stavros> hm
<Stavros> do you have it tagged?
<jml> jelmer: huh, and I guess all that's needed when fetching a project for the first time is 'bzr branch <URL>' and that will automatically work... that's actually a lot nicer than shared repos
<jelmer> Stavros: or the daily build of both bzr and bzr-git
<Stavros> i'll just use the release of bzr-git, thanks
<jelmer> jml: yep, exactly
<Stavros> how do we branch to tags again? it's been long since i used bzr, but it was the best
<Stavros> bzr revert tag:bzr-git-0.6.7?
<Stavros> hmm no
<jelmer> Stavros: bzr up -rtag:bzr-git-0.6.7 I think
<Stavros> that worked, thanks
<jelmer> Stavros: you ctually want 0.6.6 I think
<Stavros> jelmer: yep, that worked, thank you
<jml> hmm.
<Stavros> you might want to make the error messages a bit more descriptive :/
<jml> also makes it a bit less cumbersome to write a command that shows branches with unmerged revisions.
<jml> ugh, I wish fewer projects I worked on used virtualenv...
<Stavros> jml: virtualenv is awesome, why don't you like it?
<jelmer> Stavros: we keep going back and forth on this; the reason the error messages are less intrusive is because people kept complaining about them.
<jml> Stavros: in a nutshell, because it requires too much network access.
<Stavros> jelmer: even something like "unsupported protocol, see 'bzr plugins' for details" would be nice
<Stavros> jml: ah
<Stavros> jml: you can use pip with freezing
<Stavros> bzr-git is amazing, oh how i love it
<Stavros> has bzr gotten significantly faster in the past year? i switched to git from it for the speed, but git is a mess
<jelmer> Stavros: yes, 2.5 will be a lot faster
<Stavros> fantastic
<Stavros> how stable is 2.5?
<jml> jelmer: after branch lp:testtools, 'bzr branches' says '* (default)', then if I switch -b new-branch, only that new-branch appears in the 'branches' listing. How do I get back to trunk?
<jelmer> Stavros: you should have gotten an error message about versioning when attempting to use git+ssh://. You didn't?
<jelmer> jml: "bzr switch -b trunk"
<jelmer> jml: The initial branch is unnamed, it's not named trunk
<Stavros> jelmer: no, the exact message is: bzr: ERROR: Unsupported protocol for url "git+ssh://git@github.com/skorokithakis/django-browserid.git"
<jml> jelmer: but if I'd started hacking on that new branch then I wouldn't be able to do that without first figuring out the revision on which I diverged, right?
<jelmer> Stavros: ah
<jml> jelmer: is https://bugs.launchpad.net/bzr/+bug/588020 righly a colocated bug?
<ubot5`> Launchpad bug 588020 in Bazaar "tab completion should honour switch lookup path" [Wishlist,Confirmed]
<jelmer> Stavros: can you perhaps file a bug report about that? That's definitely a bug.
<Stavros> sure
<Stavros> with bzr or with bzr-git?
<jelmer> Stavros: bzr
<jelmer> jml: somewhat - it's an issue with sibling branches; that includes colocated branches but also "siblings" that happen to live in the same shared repository
<jml> jelmer: so I guess that unless you are some kind of weirdo you almost always want to do 'bzr switch -b trunk' after fetching a branch for the first time
<Stavros> do colocated branches shelve your uncommitted changes when switching yet?
<jml> jelmer: I see. I was about to file a bug for tab completion for colo branches but I think that bug covers it.
<jelmer> Stavros: no
<Stavros> ah :/
<jelmer> Stavros: personally I wouldn't really want that behaviour, but I guess it might make sense for switch to have an option to do that.
<Stavros> jelmer: i would love it, instead of having to use different folders, if i could have a shelve per branch
<Stavros> that way i could switch my uncommitted changes around
<jelmer> I think shelves are per checkout at the moment though.
<jelmer> so it's not just a matter of running shelve before the switch, you would actually have to change the way shelves work.
<mgz> there are arguments both ways on that
<jelmer> mgz: how do you mean?
<Stavros> jelmer: ah :/
<mgz> I find sometimes I'm glad my shelves are all on ./tree but sometimes they should be following ./feature-branch
<jelmer> mgz: for what Stavros is asking about, you would definitely have to have them per-branch though
<jelmer> jml: I think so too
<Stavros> what i want is colocated  branches to contain my uncommitted changes, i don't really mind if this isn't implemented via shelves
<Stavros> it would just be nice if this were possible
<mgz> right, it's different ways of working
<jelmer> Stavros: you don't want them all shelved onto the same shelve though
<jelmer> Stavros: is what I'm saying
<mgz> I quite often just start off on trunk then switch when I know what to name the thing I'm hacking on
<jelmer> Stavros: you could always commit/uncommit before switching?
<Stavros> jelmer: oh, yes, probably not
<Stavros> jelmer: yeah, that's a solution
<Stavros> it'd be nice if it were done automatically
<Stavros> i might write a plugin to do it
<Stavros> commit with some special commit message, uncommit if the last commit matches the message when switching
<jelmer> I wouldn't want to do that automatically in the core, because it would really pollute the repository
<jelmer> but yeah, you could very well do that as a plugin
<Stavros> how hard is that to write, as someone very familiar with python but not at all with bzr plugins?
<jml> Stavros: I found it pretty easy
<Stavros> great, i'll give it a stab later today then
<Stavros> it'll just commit and uncommit, how hard can it be
<Stavros> although i guess it would break things if you push
<Stavros> hmm
<jml> Stavros: I found existing plugins and bzrlib/builtins.py to be the best places to start
<Stavros> jml: ah, i'll try that, thanks
<Stavros> i'll try to find a simple plugin and look at it
<jml> bzr-grep is pretty simple, iirc.
<Stavros> aha, i'll look at that then, thank you
<Merwin> vila, are you there
<vila> tricky question...
<vila> I'm having a late lunch and reading the backlog ;)
<Merwin> vila, one of my coworker just made a huge mistake :D
<Merwin> He removed a lot of files, in different commits, merged with more recent commits, then commited the merge and pushed again...
<Merwin> I need to undo all what he did, without touching other team members commits because they are good
<Merwin> But looking at the qlog, I can see its merges with subcommits -the good ones-
<Merwin> How can I just undo its modifications ?
<Merwin> (For example, the last commit is a good one, but the 4 previous are bad, then 5th back is good, and the 6 back is wrong...
<Merwin> So I would need to unco changes made in commit -2..-4, and -6 for example
<mgz> jelmer: just to distract you further, have you got 30 seconds to check my thinking on <https://code.launchpad.net/~gz/qbzr/trivial__get_entry_nosuchid/+merge/90845>
<mgz> jelmer: feel free to revenge bug me about anything during the week
<vila> Merwin: same as yesterday, merge the reverse range of the revisions you want to undo, check the diff, commit, rinse and repeat for all ranges
<Merwin> vila, I'll try, thanks
<Merwin> vila, but the "good" commits are in merges, so I don't see them in bzr log
<Merwin> I just see my bad-coworker commits
<jelmer> mgz: +1, though you might want to always convert to a list in case iter_entries_by_dir returns a sequence rather than an iterator
<mgz> but that loses the ability to only do the work for the first item
<mgz> I guess for filter like this it's already done everything?
<mgz> there's only one thing matching the given file-id
<jelmer> mgz: there is only one item, so I don't think that's a big deal :)
<vila> Merwin: use 'bzr log -n1 -l32' to view lower level commits (-n)
<Merwin> vila, removing a "parent" commit (a merge commiut) won't remove all its children ?
<mgz> I guess an alternative spelling would be: for i in iter(): return i; raise
<mgz> which is actually a bit neater...
<jelmer> yeah, that works too..
 * mgz uses that
<vila> Merwin: when you cherry-pick, you remove nothing
<vila> Merwin: actually when you merge you remove nothing either, cherry-picking a reversed range doesn't remove the revisions either it only applies the opposite change
<vila> mgz: being able to *move* a shelve would be really nice
<Merwin> hum
<vila> mgz: some revisions may need to be pulled too
<mgz> vila: it would, but only if it was then available when switching back
<vila> mgz: err, not sure we're on the same page, I was thinking about an explicit command to move a shelve from one tree to another
<Merwin> vila, I can't male it work. The commit 350 is a "merge" commit. I want to keep all commits under it, but exclude modifications made by the guy. I try bzr merge -r 350..349 . but it seems that it cancels all subcommits
<mgz> right, but needing to manually move it back again would be a little annoying too
<vila> Merwin: well, yes, 350..349 includes all children, you probably want something I can;t describe without seeing your history though ;)
<vila> Merwin: but you can address lower level commit by revno too, use their dotted representation that log -n1 will display
<vila> mgz: rubber stamp for https://code.launchpad.net/~vila/bzr/beta6/+merge/90869 ?
<vila> jelmer: see above and check your news entries :-p
<vila> jelmer: kidding, don't lose time on that ;)
<vila> jelmer: but I don't know if pqm will be as friendly ;)
<Merwin> ok vila I think I got what I wanted! In fact if I want to cherrypick only the modifications done between a bzr merge and a bzr commit, I have to do bzr merge -r350..XXX.YYY.ZZZ, with XXX.YYY.ZZZ being the last commit before the merge
<Merwin> Thanks for your help... again ;)
<vila> yup exactly
 * vila wishes this can some sort of drap-and-drop operation from qlog or something...
<vila> s/can/can be/
<Merwin> The GUI is too limite IMHO for these use cases :)
<vila> yup... for now ;)
<mgz> vila: done
<vila> thanks
<mgz> some of the pending bugs retargetted may want to be 2.5.0 again, but can see when the freeze happens which got done
<vila> oh, just a sec, I'll make the 2.5.0 milestone active again
<vila> done, feel free to retarget
<vila> and sorry for bug spam
<vila> jelmer, mgz : https://code.launchpad.net/~vila/bzr/920455-ssl-defaults/+merge/90693 should now be ready for final review
<mgz> vila: looks like you still need a relative path for the installer versions
<vila> I need a path yes, why relative ?
<vila> and relative to what ? Oh, you mean relative to sys.executable for windows ?
<vila> but yes, the intent is to do two one-liners fixes when windows and osx installers have a proposal
<mgz> just `os.path.join(os.path.dirname(sys.executable), "ca_bundle.crt")` or something wouldn't hurt
<vila> bzr_ca_bundle.txt ? Or is the executable already in a bzr-private directory ?
<mgz> it's in "Program Files\Bazaar" or whatever on windows for the all in one installer, and Python26 etc otherwise
<vila> ok, done then. People that don't use the all-in-one installer are supposed technical-savvy enough to set it up themselves in bazaar.conf
<mgz> there's no reason to prefix the name at any rate, there's nothing bzr specific about certs.
<vila> and pushed
<mgz> and have you double checked that you do actually get the pretty error rather than random junk if a particular dir doesn't exist?
<vila> yup, it's explained in one of my comments with instructions to reproduce ;)
<vila> double-check welcome as I went to a lot of small changes trying to support 'optional' but I'm pretty sure I didn't break that in the end
<vila> i.e. the logic is: if you defined ssl.ca_certs, it should be valid. When we need it, we query the config, if it doesn't exist, we abort (you ask for verification, we need some valid path)
<mgz> but required is the default, so they didn't ask as such, the initial branch had various nitpicking about the connection-to-https case needing to have a pretty message about disabling checking when it fails
<mgz> I'll try out your branch downstairs in a bit
<trebor_dki> hi. being an plain cvs user, i am forced to import a subversion repo into a (new) bzr repo. is there a 5-minute howto in the man/info/web? thanks for hints
<vila> mgz: yup, indeed the tension is between 'required' being the default and ssl.ca_certs *not* providing a valid default ;)
 * trebor_dki found http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ - but that is (to me) about using bzr as a svn (super-)client.
<jelmer> trebor_dki: the entire repository (all branches) or just a single branch?
<trebor_dki> jelmer: (sorry for delay) - the entire repository
<trebor_dki> it is a move from svn to bzr
<smoser> anyone have thoughts on how i could get libvirt importer fixed: http://package-import.ubuntu.com/status/libvirt.html#2011-05-26%2020:07:23.558315
 * trebor_dki found this: svnadmin dump -q path/to/my_svn_project > my_project_dump;; bzr svn-import my_project_dump new_path/to/my_project;;      is this the way to migration?
<abentley> jelmer: bzr-pqm r83 breaks lp-land, because it calls BranchConfig.get, which doesn't exist.
<jelmer> trebor_dki: you probably just want to call "bzr svnimport /path/to_my_svn_project project.bzr"
<jelmer> ehm, "bzr svn-import ..." (with a dash)
<wgz> vila: so, the current SSL config error handling is borked
<wgz> I may be able to do something sane on the trace side when ssl.SSLError is raised, I then just need a suitable error for the config issue raised as well rather than the useless generic one
<wgz> then the trace.note stuff in connect_to_origin can go, having been absorbed at a higher level
<vila> borked how ? In which case ?
<wgz> see mp.
<wgz> 'Bad value' sucks.
<wgz> given we're breaking something that used to work, the message needs to be totally clear about how to fix the issue
<wgz> `bzr help ssl.ca_certs` could do with being a lot more detailed too.
<vila> then move the trace you like into ca_cert_from_store *before* raising bad value
<wgz> you can do that, just need to copy the block from `if ca_certs is None` below which I presume now never gets hit?
<wgz> raising a custom error would still be nicest
<vila> hmm
<wgz> yeah, `ca_certs = config_stack.get('ssl.ca_certs')` is validating the file rather than just leaving None or a non-existant name
<vila> at one point I wanted to add 'See bzr help %(option_name)s' ib ConfigValueError then the help can be used to provide more details
<vila> well, I wanted.. I did and then removed it because the strings were frozen (which may have been a bad idea)
<wgz> these messages aren't translated anyway atm.
<wgz> (they should be)
<wgz> you see what I'm talking about in HTTPSConnection.connect_to_origin right?
<vila> the trace.note call right ?
<wgz> there are two
<wgz> they should kinda be combined really
<wgz> but we need something for all kinds of validation errors, and the cert file missing is just a particular case of that
<wgz> what's the easiest way of overriding a config default for a blackbox test?
<wgz> having something try and connect to a https server with a default cert file that doesn't exist and asserting the error is useful would be good
<wgz> +missing
<vila> there is one trace.call and two trace.warning calls
<vila> yeah, I tried a bit but resigned, there was no obvious way to test that ;_;
<wgz> monkey patch opt_ssl_ca_certs to have a different default function?
<vila> yeah, I did that at one point to unit test when trying to support 'optional'
<vila> let's backtrack a bit
<vila> we want: 1) the default value to be good for 99% of the cases, having the all-in-one windows installer and the osx installer carry the certs cover that
<vila> 2) for the remaining windows/osx users, we want a clear error message
<vila> mentioning bzr help %(option_name)s and enhancing the help *and* keeping the trace.note and trace.warnings where they are ?
<wgz> plus a bit of editing, wouldn't be too bad
<vila> mgz: by the way, we're not "breaking something that used to work", really, we fixed https for urllib that wasn't verifying ;)
<wgz> though a little backwards compared to the error-then-advice approach trace.report_user_error has
<wgz> the effect is breakage, it's good breakage, but I want to avoid hundreds of bug reports about an intended change
<wgz> mentioning the default path is one thing config is doing right that the previous version didn't
<vila> yeah, me too, that's why I want to fix this asap but the current implementation is already known to not be the final one, we really want support from authentication.conf
<vila> err, why do you backwards ? We display the error mentioning the help, the advice in the help so it will displayed after the error too no ?
<vila> or do you want the help itself to be part of the error ?
<wgz> nope.
<wgz> I like the advice after
<wgz> moving the trace calls around would mean it gets printed first, which is till okay.
<wgz> *still
<vila> wgz: http://paste.ubuntu.com/824008/
<wgz> vila: yeah, that kind of thing is nice. could also special case ConfigOptionValueError in trace, there are benefits both ways.
<wgz> have we got a standard form of marking commands? I use backticks, but that may just be me.
<wgz> I really want the advice about disabling right there in the error
<wgz> and ideally not duplicated in several places.
<vila> no standard, some errors use double-quotes most use nothing
<vila> the problem is that we want a valid path, so config is the right place to check that,
<vila> hmm
<wgz> but config users can't rely on config to actually ensure a path is correct
<vila> wgz: can you redo your test after changing 'error' to 'warning' for ssl.ca_certs ?
<wgz> as they may be using the value later, and files can move etc.
<wgz> ^sure
<vila> right, but at one point the config is queried and at *that* point the file should be in the right place
<wgz> vila: http://paste.ubuntu.com/824030/
<wgz> that's more like what wget does, though still not *completely* perfect :)
<vila> perfect enough ? :-D
<vila> wgz: pushed
<vila> with some more minor tweaks
<wgz> http://paste.ubuntu.com/824042/
<vila> argh, crossed on wire ;)
<vila> None ??
<wgz> apparently.
<vila> err, and the meaning is ?
<wgz> I'm built against a slightly newer openssl than default Python 2.7 config, but I doubt it's changed
<vila> there are two 'raise's there, I just edited to use only one, but we'll raise if we see 'None'
<vila> s/$/ anyway/
<wgz> None is just what I observed the errno is if we don't supply a string for ca_certs
<wgz> the trace functions kinda suck, we need to get away from using them
<vila> but still use ssl.ca_reqs=required ?
<vila> grr, that's the case I was getting rid of by using error instead of warning ;_;
<wgz> config just doesn't have enough context to give good errors
<vila> right, but we should not accept ca_reqs=required and ca_certs == None, no need to even try
<vila> yeah config does not have enough context but if we go too far from config we can't point to config anymore
<wgz> anyway, I've distracted you enough, what you have will do for now and I can tweak later
<wgz> wrapping both ConfigValueError and SSLError in a BzrError with extra stuff would work as well.
<wgz> would then avoid the duplication in those two locations
<pmezard> hello, are Revision.message guaranteed to be unicode objects?
<wgz> yes, with normal python caveats.
<pmezard> what do you mean?
<vila> wgz: as in: I push my latest changes and you'll pilot to safe harbor from there ?
<wgz> python doesn't actually enforce types, so a misbehaving plugin could give you a Revision object where message is a byte string, or a tuple, or a Rabbit
<vila> wgz: this code *will* be revisited in the future anyway
<vila> or a Pony ?
<wgz> a Pony would be too much to hope for.
<pmezard> wgz: oh right, bugs are bugs, I was more interested about the intent
<wgz> vila: yes, land away.
<pmezard> thanks
<fullermd> Ponies aren't bugs.  Unless they have 6 legs.  Which would be awesome.
<wgz> :D
<pmezard> eheh
<LeoNerd> Some sort of centaur?
<fullermd> That would be 5 legs.  Traumatic amputation.  He doesn't like talking about it.
<vila> wgz: err, the None bit is unclear, I'd rather not test e.errno at all so we always display the note (this except clause is fatal anyway and the only workaround is to set ssl.ca_reqs=noe)
<wgz> vila: land what you have, not my changes
<vila> meh, AIUI, what I have will not do what we want on windows without a valid bundle O_o
<vila> wgz: please just do a final test with reno 6464 and I'll land it
<wgz> that now shows both messages though vila
<wgz> the rev before was okay.
<wgz> or delete the `if ca_certs is None:` block above
<vila> wgz: will delete this block and land
<wgz> cool.
 * vila bangs head
<vila> I've landed the 2.5b6 change on bzr.dev
 * wgz pats vila
<wgz> I should have seen that too
<vila> lp-propose should default to the submit_branch location (which itself should default to parent_location if not set)
<vila> each time I look at the pqm page when the test_non_ascii are passing, I have a wtf moment thinking we're back to the time were the test suite was run twice on pqm :)
<cob_olp> hi
<cob_olp> i would like have a bzr repository on a server
<cob_olp> it is a windows machine
<cob_olp> probably smart server will be a good choice?
<cob_olp> but how can I introduce some security, I mean something like ssh
<cob_olp> is it possible to setup ssh on windows, or maybe there is some other way?
<nDuff> cob_olp: yes, cygwin's sshd supports Windows
<nDuff> cob_olp: ...there are certainly other approaches as well, ie. running over https
<cob_olp> hmm
<cob_olp> so maybe instead of cygwin ssh, the better choice will be in fact a virtual machine with linux?
<cob_olp> because for https I will have to introduce some authentication
<cob_olp> should I in such case put some password on my repository folder?
<cob_olp> will bzr support such access?
<jelmer> cob_olp: yes, bzr supports kerberos and basic/digest auth
<cob_olp> ok, thank you
<cob_olp> and what setup would you suggest on windows 2003 machine?
<jelmer> cob_olp: no idea, I haven't set up a https server on Windows
<cob_olp> thank you for help
<cob_olp> probably I will install VM with ubuntu server and use bzr+ssh:/ :)
<JPeterson> i installed bzr-2.5b5-1-setup.exe, selected everything, and get this error bzr: ERROR: No module named xml_errors
<JPeterson> when selecting All in the bazaar explorer toolbar
<JPeterson> it seems like it was fixed here http://bazaar.launchpad.net/~gz/bzr-windows-installers/xmloutput_r160_update_921754/revision/202
<JPeterson> can i use that release? how do I use it?
<wgz> JPeterson: you can either remove xmloutput from the plugins dir or update it if you need it
<JPeterson> wgz, how do i updated it?
<JPeterson> why can't i update it from the plugin list
<wgz> JPeterson: go to the plugins dir, remove the xmloutput dir, then do `bzr branch lp:bzr-xmloutput xmloutput` to recreate it with the latest version of the plugin
<JPeterson> thx
<JPeterson> wgz isn't the xmloutput dir supposed to come back after that?
<wgz> yup, but you need to be in the plugins directory when you run the command
<JPeterson> ok
<JPeterson> wgz why do i get "Permission denied (publickey)"
<JPeterson> i haven't even told it where my private key is
<JPeterson> and i haven't told it my password
<wgz> generally it means you've done `bzr launchpad-login` because it told you to, but not uploaded your public key to launchpad or run your ssh-agent
<wgz> you can either remove 'launchpad_login' from your bazaar.conf (running `bzr version` will tell you what directory that's in), or go through the steps to enable ssh access
<wgz> see <https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair> for that.
<JPeterson> wgz, i dunno what running the ssh agent mean, but i ran it from cygwin isntead which worked
<JPeterson> that didn't work because the Windows command line needs to see the private key too
<JPeterson> how do i do that?
<JPeterson> ok i need to use the annoying pageant.exe
<JPeterson> it can't even add the key generated from ssh-keygen -t rsa lol
<JPeterson> ok i have to run it through puttygen.exe first 0_o
<JPeterson> wgz, now pageant.exe is running but bzr still fails with Permission denied (publickey).
<JPeterson> can i ask tortoisebzr to run bzr through cygwin instead?
<JPeterson> what's the point of tortoisebzr if it can't run bzr?
<wgz> ...I'm missing context on that question thanks to my ISP
<JPeterson> wgz, ok
<JPeterson> https://launchpad.net/subdownloader "Programming Languages: Python / QT4 "
<JPeterson> fantastic, what pythin version is it using
<JPeterson> that's kind of relevant lol
<wgz> that... doesn't seem related to bzr. it's just some project on launchpad,
<JPeterson> ya
<wgz> you could use 'Ask a question' to ask the developers to document which python version, or just try it locally and see if it breaks
<mgedmin> Commit message was not edited, use anyway? [y/n]: n
<mgedmin> this always makes me stop and think
<mgedmin> don't make me think, please
<mgedmin> if I abort the editor without quitting, clearly that's because I noticed something wrong in the diff and decided not to commit
<wgz> or because you liked the auto generate commit message as it was?
<wgz> (not that I'm sure it applies)
<wgz> personally I always just use commit -m
<wgz> mgedmin: deleting the contents of the file if you're unhappy with it avoids the prompt
<mgedmin> there are auto-generated commit messages?
<mgedmin> in what circumstances?
<wgz> using the set_commit_message or commit_message_template hooks, as used by bzr-builddeb for instance
<mgedmin> ooh
<mgedmin> so when I answer "n" to the not edited question, I get
<mgedmin> bzr: ERROR: empty commit message specified
<mgedmin> which scarily-looks as if bzr tried to commit anyway and then aborted when it noticed the message was empty
<mgedmin> there's no reason bzr can't check for empty-ness before it checks for not-edited-ness
<mgedmin> and abort the commit (like git does) without asking unnecessary questions
<wgz> patches welcome!
<wgz> bzr branch lp:bzr then it's in bzrlib\msgeditor.py
<wgz> just moving the block down would work but the logic could probably be tidied up more generally
<wgz> JPeterson: now I've read the log from when I was disconnected, I see you were having issues getting an ssh key set up
<wgz> JPeterson: did you remember to do 'Add key' on Pageant? pasting the section from you .bzr.log where it failed may have more info.
<JPeterson> wgz ok
<wgz> it seems to did all the hard bits.
<wgz> and if it worked via cygwin then you must have the key on launchpad correctly.
<JPeterson> wgz where's .bzr.log?
<wgz> ah, unless you generated a new key rather than importing your existing one?
<wgz> ^`bzr version` will tell you where .bzr.log is
<JPeterson> 0.082  bazaar version: 2.5b5
<JPeterson> ...
<JPeterson> 0.322  ssh implementation is OpenSSH
<JPeterson> [234260] 2012-01-31 21:11:08.059 WARNING: ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<wgz> you did Conversions -> Import key rather than Generate right?
<JPeterson> correct
<wgz> hm. and that looks like it's using openssh rather than paramiko or plink, which is why it doesn't find the key
<wgz> if you do..
<wgz> set BZR_SSH=paramiko
<wgz> and then try to branch something again, do you get a different ssh implementation line in the log?
<JPeterson> wgz thx, that's what was missing
<wgz> ...it should be the default, I wonder what was going wrong
 * wgz checks the code
<wgz> hm. no, having something called ssh on your path takes precedence, that's not great on windows.
<JPeterson> ok
<JPeterson> restarted pageant and get this
<JPeterson> 0.234  failed to load system host keys: [Errno 2] No such file or directory: 'C:\\Users\\User/.ssh/known_hosts'
<JPeterson> thats' not where it is,
<JPeterson> it's in C:\Files\Services\cygwin\home\User\.ssh
<wgz> JPeterson: remember to set that variable in you user variables under system properties so it sticks
<wgz> ^heh, that comes from a function where the docstring begins "Load system host keys (probably doesn't work on windows)..."
<wgz> it's ignorable kipple though, provided you add the key again whenever you restart paramiko (yes, it's annoying, but most ssh-agents are like this) then things will work
<wgz> so, right click little icon, add key, select key file, enter password
<JPeterson> wgz, what? how do I tell it where the known_hosts is?
<wgz> ah, maybe you can actually, and avoid pageant
<wgz> try `bzr config ssh_host_keys=C:\Files\Services\cygwin\...etc`
<wgz> no, wait, misread
<wgz> what *is* this doing...
<wgz> meh, just ignore it, is harmless
<JPeterson> wgz: ok. now it worked again btw. ConnectionReset reading response for 'BzrDir.open_2.1', retrying came from a temporary router downtime
<JPeterson> not bzr
<wgz> it's unfortunate the failure modes look the same...
<poolie> hi all
#bzr 2012-02-01
<JPeterson> the tortoisebzr diff window is really something else
<JPeterson> how do i revert rows in it? lol
<JPeterson> I've never seen anything so stupid. how do i revert parts of a file?
<AuroraBorealis> reverse rows?
<JPeterson> i can't do any edits in the diff window ROFL
<JPeterson> holy mother of god
<AuroraBorealis> i dont use tortoisebzr i just use qbzr
<spiv> JPeterson: if you want to revert parts of a file, you might find 'bzr shelve FILE' to be more helpful.  (Not sure if there's a GUI for that?)
<JPeterson> spiv: ok. thx.
<Wellark> hi! I'm having problem with pipeline plugin. I'm using the latest revision from bzr-pipeline trunk, but now I started to get these messages: "bzr 2.6.0dev1 is too new for pipeline 1.1.0"
<fullermd> Probably hasn't been updated for the new version of bzr.dev.
<Wellark> has there been any discussion on fixing it?
<fullermd> There's probably nothing broken, strictly speaking.  It just doesn't know that it can work with 2.6.
<fullermd> You could just find the version check and bypass it, and see if anything breaks.
<Wellark> :)
<Wellark> the __init__.py does the check and it defines maximum_bzrlib_version = (2, 4)
<Wellark> any API breakage between 2.4 and 2.6?
<fullermd> Probably.  An API that pipeline uses?  I have no idea.
<Wellark> I mean in bzrlib
<fullermd> But if it worked with bzr.dev when it was called 2.5 a couple weeks ago, it probably still works with it calling itself 2.6 now.
<Wellark> I'm not familiar with bzrlib API policies
<fullermd> Well, I'm not really familiar with the API's, and even less with pipeline.
<fullermd> If you smoosh the two of us together in a steam press, we could own this joint   ;)
<fullermd> Things are likely to get broken across major releases.  But whether that has any impact on a particular plugin is a wide open question.
<fullermd> If pipeline actually works with 2.5 (or bzr.dev just before 2.5 branched), it probably works equally well with bzr.dev-called-2.6 now.  I'd _guess_ the major premise is supportable, but I don't know.
<spiv> Wellark: many plugins are very conservative about API versions.  They prefer to break up front if they haven't been tested against that version rather than risk some strange breakage while being used.
<spiv> Wellark: even though most of the time no change to the plugin is needed (other than relaxing the version check)
<Wellark> fullermd, spiv: OK, thanks. I'll upgrade the test and see what happens.
<Wellark> and also file a bug against bzr-pipeline as it seems nobody has done so
<stewart> have lightweight checkouts improved over $years ago? i.e. do they actually suck down less data and are faster than pulling full (big) repo?
<spiv> I think perhaps jelmer and jam have done a bit of work on that lately.
<spiv> I have a partially completed branch (that jelmer is continuing) to make "bzr branch --stacked" a good answer for that case, though.
<spiv> (i.e. to make it reasonably efficient w.r.t. how much data it sucks down, at least when using a smart server.)
<spiv> (it's about the same amount of data as a lightweight checkout -- all the full texts of the current revision's tree, but actually kept in a local stacked repo so you can still have speedy local diff etc. without necessarily hitting the network for almost every subsequent operation)
<poolie> hi vila, and good night
<vila> hey poolie et al.,
<vila> poolie: g;night
<Merwin> hi
<vila> Merwin: hi
<Merwin> Hey vila :-)
<Merwin> What web interface would you recommend for end-users not very familiar with bazaar ? I'm looking for something simple which will help them understand
<vila> hmm, loggerhead is the most advanced one I know of, but qlog used locally is IMHO the best way to understand branch history or even branches histories (you can use 'bzr qlog trunk feature1 feature2' to visualize how branches are related)
<mgz> morning
<vila> morning mgz
<mgz> ha, bug 924727
<ubot5`> Launchpad bug 924727 in Bazaar "bzr pull does not remember urllib links" [Undecided,New] https://launchpad.net/bugs/924727
<mgz> that workaround for self signed cert won't be good much longer
<vila> mgz: one word: rabbit hole
<vila> mgz: are you already replying or should I ?
<mgz> you go ahead
<mgz> the good part is that they'll just be able set a conf value with 2.5
<vila> ok
<vila> yeah, unless he still want his certificates to be verified in which case things will be a bit harder to use until we fix bug #923220
<ubot5`> Launchpad bug 923220 in update-manager (Ubuntu Precise) "update from oneiric to precise blocked on skype:i386 says updater" [High,Triaged] https://launchpad.net/bugs/923220
<vila> grrr
<vila> bug #924220
<ubot5`> Launchpad bug 924220 in Bazaar "ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
<Merwin__> bug #1
<ubot5`> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<mgz> what the b- config? <http://pastebin.ubuntu.com/825188/>
<mgz> ^any ideas vila?
 * mgz downgrades from 2.5b5 to something b4 for now
<vila> O_o I used feed-pqm no later than... this morning ?
<vila> and my copy is in sync with lp:hydrazine
<vila> mgz: try *upgrading* hydrazine ?
<vila> mgz: there is a bzrlib_version < (2, 5) to select the right config (and you run 2.5b5 not trunk ?)
<mgz> ah yes, missing r102 from hydrazine
<abadger1999> I know we've had discussions about supported timeframes for various things like python-2.4 in the past so I'm going to post this for people to know that things have changed for one of the distros I package for.
<abadger1999> Just an FYI, for future discussions
<abadger1999> http://www.redhat.com/about/news/press-archive/2012/1/red-hat-enterprise-linux-stability-drives-demand-for-more-flexibility-in-long-term-operating-system-deployments
<abadger1999> The RHEL5+ lifecycle has been expanded to 10 years.
<mgz> yup, that's been pretty widely linky-ed.
<abadger1999> k
 * abadger1999 now looking at supporting stuff on python-2.4 until March 31, 2017
<mgz> that doesn't feel to bad, unless you're also being bugged to move things to Python 3 at the same time.
<mgz> we've yet to make any significant use of post-2.4 features
<mgz> various sugar like with and str.format are getting scatterred around but it's not code that couldn't be written the old way
<abadger1999> <nod>
<abadger1999> I'm liking the idea of plugins for old versions if new repository formats are made too.... less work for me to package a plugin than to backport fixes/patch out post-py2.4 code in order to get a new format.
 * SamB wonders what Ubuntu is going to do when they pass z
<mgedmin> wrap around to a, probably
<mgedmin> maybe a double a
<mgedmin> aawful aardvark?
<mgedmin> that's what speadsheets use after z, after all
<mgz> only gets you one more animal.
<mgz> debian has a more pressing naming problem.
<mgz> they've already run through all the toy story characters anyone knows about.
<mneptok> dude, Barbie.
<mneptok> i *started* using Debian only in hopes that one day i could say, "I'm a Barbie user," without having to buy those horrid dolls.
<SamB> mgedmin: yes, but ~aawfull doesn't compare after ~zany
<mgedmin> hmm
<SamB> as for Debian, they will presumably have to switch naming schemes at some point, yes, but at least this won't be a *technical* problem
<SamB> (assuming they leave sid as-is)
<mneptok> hmmm ... Mattel should make a "Debian Barbie"
<SamB> they should include a USB stick with a net installer
<SamB> (A copy of Debian testing?)
<vila> abadger1999: have you considered having python-2.7 available in addition to 2.4 ?
<vila> abadger1999: well, 'you' in the collective sense I mean
<abadger1999> vila: In the epel5 world, we do have a python26 package (no python27 atm).
<abadger1999> vila: but -- if we moved bzr to that, we'd need to create a parallel stack of all the python26 modules that bzr requires.
<vila> abadger1999: epel5 ?
<abadger1999> vila: addon packages for RHEL5 and rhel5 clones.
<vila> thanks
<vila> yeah, you need to find the right balance
<abadger1999> <nod> definitely.
<vila> I think the most important ones are cython|pyrex, python-paramiko and python-configobj, akk the others are for testing
<vila> well python-pycurl is still needed probably but not for too long hopefully
<mgz> right, break for an hour, just need to remember to come back and listen in on Barry's chat
<abadger1999> yeah... I'm very hesitant to just build bzr without invoking the test suite, though ;-)
 * SamB thinks it would be a lot better if bzr would branch 0 or 1 revision initially, and actually make a branch, before pulling anything else into the repository
<SamB> (In terms of what happens when a "bzr branch" command gets interrupted.)
 * SamB wonders how stupid it would be to replace bzr's native repository format with a variant of git's
<LeoNerd> IIRC, formats are largely invisible to the user.
<LeoNerd> That's one main philosophy difference between bzr and git.
<SamB> I'm just wondering if it would be good for efficiency
<LeoNerd> bzr holds the tool UI canonical, and re-invents the data format underneath it to better help the user
<LeoNerd> git holds the data format canonical, and re-invents the tool UI to better help the user
<jelmer> SamB: are you still hitting performance issues with 2.5 ?
<jelmer> (FWIW, bzr supports git's repository format through bzr-git but because the latter uses dulwich it's significantly slower than native git)
<LeoNerd> I've never been able to make bzr-git work without running out of "disk" space in /tmp
<LeoNerd> ((I use tmpfs))
<SamB> jelmer: I'm not sure if it's as bad as it was, but it's taking forever to pull lp:launchpad ...
<jelmer> LeoNerd: that's odd, since it shouldn't really be storing anything in /tmp other than the pack file it receives from the remote git server
<jelmer> SamB: Launchpad is large :)
<SamB> jelmer: and I was thinking something along the lines of: use git's 'object store' format(s), and probably the existing 'blob' format
<SamB> but make up new object types to represent the other bzr concepts
<SamB> (how many other concepts are there?)
<SamB> (in a repository, I mean)
<jelmer> SamB: bzr and git pack files aren't too different, I don't think remaining performance issues are related to the formats
<SamB> hmm
<jelmer> it would be interesting to further optimise pack fetching over HPSS, but I doubt that that requires format changes
<SamB> did you say anything between "bzr and git pack files aren't too different" and when I got back on?
<jelmer> SamDB: it would be interesting to further optimise pack fetching over HPSS, but I don't that that requires changes as introdusive as format changes.
<SamB> yeah, I cought that after I returned
 * SamB wonders if putting transient stuff on disk instead of keeping it in memory wouldn't help
<SamB> (Well, sometimes, anyway.)
<abentley> vila: AFACT "diff --summarize" is not a real thing, and was not real at the time this was submitted:  https://code.launchpad.net/~jbowtie/bzr/doc-bzr-st-historical-532600/+merge/35950
<SamB> abentley: maybe "--stat"?
<abentley> SamB: bzr: ERROR: no such option: --stat
<SamB> oh
 * SamB misread a "git" into there somehow
<milki> eh, its a jelmer
<jelmer> hey milki
<milki> you arent in #dulwich o.O
<jelmer> whoops
<michaelh1> I'm using bzrlib on a long-running task.  How can I turn on some type of debug/progress to show that it's ticking along?
<michaelh1> (this is a throw-away script.  My Google-foo fails me)
<jelmer> hi michaelh1
<michaelh1> Hey
<jelmer> michaelh1: the simplest thing to do would be to create a progress bar
<jelmer> michaelh1: are you calling bzrlib.initialize() ?
<michaelh1> jelmer: no
<jelmer> michaelh1: if you do so, it should install the standard termninal UI for you I think
<michaelh1> OK.  Added, it's still silent, how can I turn on the progress bar?
<fullermd> Kl
 * fullermd mutters.
<jelmer> michaelh1: that should do it, when there's stuff to display
<jelmer> michaelh1: if you're using the Launchpad API as well, that doesn't use bzrlib
<jelmer> oops, nevermind
 * SamB wonders what in the world all these huge "Repository.get_parent_map" HPSS calls are for
 * jelmer is confused by talking with Michael Hope and Michael Hall at the same time
<jelmer> SamB: browsing the revision graph
<SamB> jelmer: why does *my* bzr need to browse the *remote* graph?
<jelmer> SamB: it depends on what you're doing
<SamB> shouldn't it leave that to the remote?
<jelmer> SamB: if you're running "bzr log lp:bzr" then it would look at the remote revision graph to find out what to display
<michaelh1> jelmer: hmm.  the backtrace shows that it's in search_missing_revision_ids.  This is GCC so that may take some time and there might be no progress.
<SamB> hmm
<SamB> well, I wasn't
<SamB> I'm just pulling
<michaelh1> CPU usage is zero so it might be round tripping.  I'll update bzr from 2.3.4 and try again.
<jelmer> SamB: in that case it's finding out which revisions it needs to fetch
<SamB> there's got to be a better way to do that
<jelmer> SamB: Git does the same thing (the "want " / "have " bits)
<jelmer> SamB: for some cases, yes, definitely
<michaelh1> Is there a PPA with 2.5b5 in it?
<jelmer> SamB: if you're a couple of revisions behind on what you're pulling from, or creating an initial clone then it's fine
<michaelh1> Ah, found it
<SamB> jelmer: assuming you don't run out of RAM and have to interrupt bzr mid-way
<jelmer> SamB: in that case you wouldn't end up with any data anyway I think
<SamB> why would you think that ?
<michaelh1> Ah, much better with 2.5b5
<jelmer> SamB: it streams to a temporary pack file, which I think gets removed if you abort it.
 * SamB thinks the smart protocol would be easier to understand if it weren't based on RPC ...
<jelmer> SamB: hmm?
<SamB> maybe not
<jelmer> SamB: RPC is a fairly generic term, not a protocol
<SamB> I guess what would really help was if there was some kind of ... spec
<jelmer> SamB: see doc/developers/network-protocol.txt IIRC
<jelmer> not great, but more than nothing :)
<SamB> yes, it is more than nothing
<jelmer> SamB: good places to start in the code are bzrlib/remote.py (all client-side callers are here) and bzrlib/smart/, in particular bzrlib/smart/request.py
<SamB> yeah, I was already looking at bzrlib/remote
<SamB> it's aptly named
<jelmer> :)
<SamB> this thing that you did not actually call a spec does also at least refer to relevant modules
<fullermd> It's a speck of a spec   8-}
<SamB> I guess you'd call it a "stub"
<SamB> well, if you were a wikipedian, anyway
<SamB>   Code not geared to do pipelined requests, and this might require doing
<SamB>   asynchrony within bzrlib.  We might want to either go fully pipelined
<SamB>   and asynchronous, but there might be a profitable middle ground.
<SamB> there seem to be some words missing here ...
<fullermd> It was written during the Great Verb Drought of 2009.  They were strictly rationed, and as a free software project, we can't afford to splurge on non-essentials.
<SamB> ... right ...
<jelmer> SamB: s/Code/The code is /
<SamB> what about the whole idea that's missing in the second sentance?
<SamB> or is that just an "and" that should be "or"?
<fullermd> It's probably more like an extra word than a missing one.
<fullermd> I think it calls for an either-ectomy.
<SamB> ah
<SamB> what does "tw=74" mean, exactly?
<fullermd> vim modeline
<SamB> is that the same as `fill-column' in emacs, do you think?
<jelmer> yep, "textwidth" - it indicates the number of colums in a text document
<SamB> good, good
 * SamB has started editing and wanted to make sure to follow the local conventions
<SamB> git does something fairly simple here: the client sends "have" messages in batches of 32, but sends an "extra" block to start with so there's always one in flight...
<jelmer> SamB: git has a completely different approach here - it only supports receiving a pack and sending a pack
<SamB> well why not?
<jelmer> bzr supports all operations remotely; the initial calls that were added were for low-level operations, and over time more high-level operations have been added (for performance reasons)
<SamB> it's not that hard to make a pack
<jelmer> SamB: git doesn't allow you to inspect a remote repository in any way; "git log git://foo.com/bar" doesn't work
<SamB> well, true
<jelmer> SamB: the streams sent by bzr over HPSS are packs
<SamB> though nowadays the protocol doesn't actually prevent that
<SamB> (I mean, with the "shallow" stuff, it wouldn't really be all that tricky to do git logging remotely.)
<jelmer> SamB: does that allow you to retrieve just commit objects? I thought you would get the commit contents with it as well?
<jelmer> SamB: and it requires you to create a new connection for each request that you do
<SamB> jelmer: oh, maybe
 * jelmer actually has more experience with the Git protocol than with the bzr protocol
<SamB> but that seems unlikely to make things much worse
<SamB> you'd just have to throw them away, right?
<SamB> ... unless there might be deltified commits based on blobs or trees?
<jelmer> SamB: yes, but you'd have to do the negotiation each time you connect, and there could be a lot of data you throw out.
<jelmer> SamB: bzr does that bit really quickly these days (not against launchpad, but against a modern bzr server)
<SamB> oh, right, launchpad is probably running something old, true
<jelmer> but I think we're getting distracted from the discussion about optimizing fetch :)
<SamB> yeah, a bit
<jelmer> SamB: so basically there is a generic call for retrieving objects in the HPSS
<jelmer> SamB: Repository.insert_stream and Repository.get_stream allow you to send and receive streamed packs of objects like texts, chkbytes (inventories), revisions and signatures
<jelmer> SamB: Repository.get_stream receives some sort of search result which indicates the kind of objects that the client wants to receive
<jelmer> s/result//
<jelmer> SamB: (bzrlib/vf_search.py for some of the search types)
<jelmer> the searches do support things like "give me the data for revision X1..Xn but exclude everything that is an ancestor of Y1..Yn"
<SamB> ... it would also be nice if it didn't use so much memory during the streaming phase, hmm ...
<jelmer> SamB: I'm not sure why it would be using so much memory, my guess is that it could just stream directly to the pack file, but I'm not sure what's happening in practice. Perhaps a bug ?
<SamB> bug, missing feature, who knows?
<lifeless> jelmer: SamB: we're running 2.5b3
<lifeless> this isn't really 'old'
<SamB> okay
<lifeless> maybe not 'newest', but not like we're running 1.8 or something :->
<SamB> I was thinking more 2.3 or 2.4
<SamB> well, after jelmer gave me the idea that it might not be the latest
<jelmer> lifeless: it predates the collection of HPSS improvements we landed in 2.5
<jelmer> lifeless: it's not really old, but landing 2.5b5 will have a significant impact for some operations
<lifeless> cool
<SamB> does it somehow return better answers for Repository.get_parent_map ?
<jelmer> SamB: nope, it's doesn't help in that regard
<jelmer> SamB: If I understand things correctly, "bzr pull" shouldn't be calling Repository.get_parent_map too often in your case anyway
<jelmer> SamB: if it's trying to figure out the revno of a revision by browsing branch history then those improvements will help
<SamB> well, it seems to do a lot of those at the beginning of the pull
<jelmer> SamB: can you see why?
<SamB> well, lets see ...
<jelmer> SamB: Ctrl+\ should land you in a python debugger
<SamB> 8.069  hpss call:   'Branch.last_revision_info', '+branch/launchpad/'
<SamB> 8.069               (to bzr+ssh://bazaar.launchpad.net/+branch/launchpad/)
<SamB> 8.169     result:   ('ok', '14742', 'launchpad@pqm.canonical.com-20120201203052-676sbmji00bd2h57')
<SamB> then a bit later
<SamB> 8.300  hpss call w/body: 'Repository.get_parent_map', '+branch/launchpad/', 'include-missing:', 'launchpad@pqm.canonical.com-20120201203052-676sbmji00bd2h57' ('\n\n0'...)
<SamB> 8.300                3 bytes
<SamB> 8.921     result:   ('ok',)
<SamB> 9.162                64719 body bytes read
<jelmer> SamB: it's more interesting to see what high-level request triggers the HPSS call
<jelmer> (and perhaps shouldn't)
<spiv> jelmer: hmm.
<spiv> jelmer: you knowâ¦
<spiv> jelmer: It'd be possible to write a -Dhpsswhy flag I reckon
<SamB> yes, of course it would
<spiv> jelmer: that adds to -Dhpss which method of Branch/Repository/BzrDir triggered it
<spiv> jelmer: by horrible stack introspection :)
<SamB> (but what if there were more than one involved?)
<spiv> List them all.  Shouldn't be more than three most of the time I'd reckon
<spiv> It would be a good middle-ground between context-less -Dhpss now and having to manually get full tracebacks with Ctrl-\
<spiv> E.g. adding "via: BzrDir.sprout, Branch.sprout, Repository.get_parent_map" or whatever
<jelmer> spiv: hmm, that'd indeed be nice :)
<SamB> is there some way to get more ordinarily-formatted traceback in pdb?
<spiv> SamB: I guess you can just use "import traceback; traceback.print_stack()"
<SamB> hehe
<SamB> that shows me a lot of pbd's own stack frames
<spiv> I guess it would :)
<SamB> http://paste.debian.net/154425/
#bzr 2012-02-02
<SamB> it might be a good idea to also list whoever called the first of those guys to get called
<SamB> oh, interesting
<SamB> "bzr info -v" crashes on this branch
<SamB> Branch history:
<SamB>      14741 revisions
<SamB> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/naesten/hacking/launchpad/.bzr/repository/') has no revision launchpad@pqm.canonical.com-20120201152332-0i5ysxdk0ouw6jc2
<jelmer> SamB: it's an interrupted clone?
<SamB> yeah
<jelmer> SamB: that's a bug fixed in 2.5, we shouldn't be setting the branch data unless the revision data is actually present
<jelmer> so, it seems the odd thing wrt your traceback is that it's using vf_search.NotInOtherForRevs
<SamB> bzr branch lp:launchpad; (hit ^C); bzr branch lp:launchpad; (this time it completes right away setting the branch data); cd launchpad; bzr pull
<jelmer> and that doesn't have a get_recipe thing it can send over the wire
<jelmer> SamB: yes, that's fixed in 2.5
<SamB> where is this "2.5" ?
<SamB> I'm on b5
<jelmer> SamB: lp:bzr/2.5
<SamB> so, you mean it was fixed since 2.5b5?
<jelmer> yes
<jelmer> I THINK
<SamB> oh
<jelmer> sorry about the caps
<SamB> no problem
 * SamB runs "sudo apt-get install bzr/unstable"
<SamB> hmm
<SamB> apt-get complains
 * SamB uses aptitude instead
<jelmer> SamB: unstable doesn't have the right version yet I think
<SamB> oh. what should I be installing, then ?
<jelmer> SamDB: either way, the bug is just that it allows creating a branch without fetching the relevant data in an empty repository
<SamB> oh, actually, it's not doing that anymore afaict
<jelmer> SamB: a workaround is just to "bzr init foo && bzr pull lp:launchpad"
<SamB> so I guess "bzr 2.5.0~bzr6458-2" was good enough
<jelmer> ah, ok :)
<SamB> (apt-get is apparantly not smart enough to think of pulling python-bzrlib{,.tests} from unstable too
<SamB> though, in all fairness, aptitude isn't smart enough to figure out that that would be a better plan than just not doing what I wanted, either
<SamB> or better than deleting bzr, python-bzrlib, and everything that depend on them
<SamB> why it thinks "delete the only thing asked for" or "leave the only thing asked for alone" are good plans, nobody seems to know
<jelmer> :)
 * jelmer -> sleep
<Stavros> hello
<Stavros> i have two branches in different directories, A and B. whenever i commit something to B and try to pull it to A, bzr tells me they have diverged and need a merge. i merge, and the next time i need to pull from B, it needs a merge again. why can't it see it's fast-forwardable?
<Stavros> here, i just merged B to A, and trying to pull from B to A needs another merge
<Stavros> i don't think this should be happening
<spiv> If Stavros comes back, someone should suggest "bzr missing" to them to diagnose their situation.
<vila> hi all !
<rcsheets> hello vila
<wgz> morning vila.
<vila> rcsheets: please to meet you (not sure I recognize the nick though ;)
<vila> heya wgz
<vila> wgz: did you land evrything you wanted on 2.5 ?
<rcsheets> vila: i mostly lurk :)
<vila> good, we also welcome lurkers
<wgz> bus time
<wgz> vila: not yet
<vila> wgz: k, ping me when you're done
<vila> wgz: or better, let's chat quickly when you come out of the bus
<mgz> morning all!
<mgz> vila: so, my issue is I still need to change some apis, but am having trouble deciding on how exactly to do it
<mgz> and that's the kind of thing that should really be in the last beta
<mgz> it should all be pretty safe, private functions, some extra args, and otherwise compatible
<rcsheets> good morning
<mgz> I am wondering from your nick rcsheets, why you need to revision control your bedding.
<rcsheets> it's... a complex and embarrassing story
<mgz> :)
<vila> mgz: change APIs around unicode issues ?
<mgz> vila: I need to alter two things particularly
<mgz> how trace exception reporting functions pass error information around
<mgz> and some details of exception instances
<mgz> I have a generic fix for BzrError I've been sitting on that involves wrapping it for _format, but it'll actually be a safer change to modify each class
<vila> you know about bt.test_trace right ?
<mgz> ...specifically?
<vila> I think that's where most of output tests are, checking various functions and combinations of encoding, let me check
<mgz> also bt.test_errors
<mgz> I can certainly do this without breaking existing testcases
<vila> hehe, that's bad :) You should at least add a failing test first ;)
<vila> you're fixing at least a bug right ?
<vila> hmm, not sure that's the one I was thinking about
<mgz> there's also bb.test_non_ascii and things, but that's less useful
<mgz> the combinatronics aren't particularly valid in the same process without having an actually different locale
<vila> there is a test file where all sort of output are kinf of magically tested (I remember reading a test in a review that made no sense until I read the setup in this test file)
<vila> can't find it back :-/ or may be it's not catching my eye as it did
<mgz> do we know what's up from the test failures from the bzr-builddeb ppa due to debian_releases() returning None?
<mgz> I'm guessing it's related to the package upgrades we've been trying to get through on the builders?
<jelmer> mgz: that's already fixed
<mgz> ace.
<mgz> ah, that's the 'Fix tests' r714 commit.
<jelmer> mgz: yeah, that was kindof sloppy of me, only testing without distro_info installed
<mgz> gah, I'm going nuts, I just need to start commiting bits
 * mgz shelves the world
<vila> mgz: yeah and land some :) I'm late for lunch and would like to start freezing 2.5b6 not too long after I come back ;)
<jelmer> oh
 * jelmer should put up his overwrite-tags MP while he still can
<vila> ha :)
 * vila back
<vila> jelmer, mgz: so what ?
<mgz> vila: so, I still need to do some things, but only have the one mp to land atm
<mgz> I think I can do some of this with... minimal-ish risk though, so it's not the end of the world if you freeze first
<vila> ok, jelmer ?
<jelmer> vila: mp on the way
<vila> ha cool
<jelmer> vila: proposed
<vila> jelmer: so the idea is that you can use '--overwrite' or '--overwrite-tags' or both right ?
<mgz> hm. `bzr rm .bzr` does something.
<mgedmin> ooh! does it do something bad?
<jelmer> vila: yeah, though there isn't much point in that
<vila> mgz: yeah, I receive an email saying you're naughty
<vila> jelmer: in what ?
<jelmer> vila: (speciufying both is the same as just specifying --overwrite)
<vila> oh
 * mgedmin now knows vila is santa!
<vila> jelmer: and '--overwrite --no-overwrite-tags' works ?
<mgz> jelmer: seems generally okay, but I'm not convinced by the passing around of 'history' and 'tags' strings
<jelmer> vila: We could also add --overwrite-history if you wanted to be able to just overwrite history
<mgz> do we really want to support lots more kinds of unversioned data?
<vila> jelmer: nope, the change looks fine for now, I'm just kicking the tires
<rly> How do I express 'do not care anything about local changes, just update it'?
<vila> rly: 'bzr revert ; bzr update'
<rly> vila: thanks
<vila> jelmer: meh, wtf with changes in bzrdir.py  on crontroldir.py ?
<vila> urgh, my bad
<jelmer> vila: hmm?
<vila> nothing, did I mention anything ?
<jelmer> :)
 * vila should really fix his bzr-review hack to take the targeted branch into account
<jelmer> mgz: thoughts on alternatives? Would you rather see another argument be passed around and renaming overwrite to overwrite_history ?
<vila> jelmer: Aren't we breaking plugins that redefine push/pull here ?
<jelmer> vila: yes
<mgz> not having a day of api epiphanies unfortunately
<mgz> maybe vila has clever ideas?
<vila> mgz: it happens but I'm not sure I understand API epiphanies ;)
<vila> jelmer: so having overwrite_tags will break them less no ?
<jelmer> vila: no, it will break them more
<jelmer> vila: if we pass a tuple, then most of them will just work - they'll just do full overwrites in some cases even if the user requested tag overwriting only
<jelmer> if we add a separate parameter then it will definitely break them
<vila> hmm
<mgz> ideally that bool would flip, and tags would count as not overwriting at all
<mgz> but I don't think that's a big deal
<rly> Why would anyone want to use bzr over any of the other DVCSs?
<mgz> why would anyone want to use any of the other dvcss over bzr?
<rly> mgz: for git: performance.
<rly> mgz: for Mercurial: better user-interface and I think it is more popular.
<jelmer> rly: unless you have a really big tree, I don't think there's a significant difference in performance left
<rly> I almost never see a bzr repository.
<rly> I think it is at around 2% or so for the repos I care about.
<jelmer> rly: I think the Bazaar UI is much better than Mercurial's. Not sure about popularity
<rly> E.g. if bzr has zero open bugs, then that would be an advantage.
<rly> I think darcs has tons of bugs open, still.
<rly> An open bug is something which affects correct operation.
<rly> Not some silly feature request.
<rly> Speed could affect correctness because of termination problems.
<rly> 'it takes until the heat death of the universe before this completes...'
<rly> So, that said, where does bzr stand?
<rly> https://bugs.launchpad.net/bzr suggests it is unmaintained.
<jelmer> rly: why?
<jelmer> rly: Mercurial and Bazaar both have open bugs
<vila> rly: try https://launchpad.net/bzr/+milestones
<jelmer> rly: I think popularity is mostly perspective; I don't come across many mercurial projects anymore these days, most (and quite a few who used Bazaar in the past) have migrated to Git.
<vila> jelmer: I don't really know what to do with your --overwrite-tags proposal, this looks like something that needs to mature a bit. As such I'd more inclined to land it in trunk :-/
<jelmer> vila: mature in what regard? I think if we're happy with the API change we should just land it - there's another couple of weeks before 2.5.0
<vila> plugin breaks, fallouts discovered while using it...
<jelmer> vila: plugin breaks should be fine now before we have 2.5.0
<jelmer> there were requests from both the emacs people and go users (Gustavo) for this; I'd really like to land this rather than having them wait for another 6 or 7 months
<vila> gustavo use case is already covered by --overwrite IIUC, overwriting only tags may be cleaner but if we deprecate the option in the future he won't be happy either
<jelmer> vila: he was specifically asking for this
<vila> and if we had proper versioning for tags we shouldn't need the option at all
<vila> yes, but why ?
<jelmer> vila: https://bugs.launchpad.net/bzr/+bug/681792/comments/4
<ubot5`> Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [High,In progress]
<vila> to be able to *not* use --overwrite unconditionnally
<vila> I know I re-read it
<jelmer> vila: if we had proper versioning for tags we might still wants this option
<alucardni> hello, is there a way to make bzr work behind a proxy? Exporting http_proxy, https_proxy doesn't work with bzr 2.5b5
<vila> jelmer: why ?
<jelmer> vila: because you might want to discard your local tags in favor of the ones on the remote host
<jelmer> vila: I don't see why that matters though, if you're happy for this change to land on trunk
<vila> I don't think pull and push are the right way to align tags between branches, it *is* today because the interactions are limited
<vila> because we can more easily revert/fix it on trunk
<vila> rushing features never worked in the past :-(
<Mez> Is there a way I can take a subdirectory of a branch, and split it out into it's own branch? (we want to create a new project from a sub-project)
<jelmer> vila: I don't think this is really rushing, and it's a really small feature
<jelmer> Mez: see "bzr split"
<Mez> yeah, just spotted that
<jelmer> also, hi :)
<Mez> hey :D
<vila> jelmer: well, I do :) But if you manage to get approval from mgz instead, I will freeze a bit later (I need to leave for ~1/2 h)
<Mez> jelmer: how're nested trees coming along ?
<jelmer> vila: we have another full month for the final release, and this change is really simple. What is the worry?
<vila> jelmer: that we said roughly the same thing one month ago ? ;)
<vila> jelmer: I really need to go (and just get informed that I have *another* appointment* at 6pm so freeze won't be for today :-/),
<vila> jelmer: the way you transform 'overwrite' is not public, how will the plugins deal with that ? Overall, there are issues I feel needs to be addressed (gut feeling), size doesn't matter
<jelmer> vila: what do you mean with not public?
<jelmer> vila: the plugins will need to be updated, but that seems fine as long as we haven't frozen the API (e.g. before the last beta)
<jelmer> Mez: slowly :)
<jelmer> Mez: but there is some progress, at least
<mgz> heh, another dupe of the bug I'm working on now just filed
<uniquenick> is bundlebuggy still actively maintained?
<alucardni> \wc
<jelmer> uniquenick: it's not
<uniquenick> do the bzr devs still use it anyways, or something else?
<jelmer> uniquenick: we're using Launchpad review system for bzr itself
<uniquenick> does launchpad take over for pqm also, or is it still used?
<jelmer> uniquenick: we're still using PQM
<abentley> jelmer: In fact, I've just submitted a branch for bzr-pqm.  Are you up for a review?
<jelmer> abentley: sure
<abentley> jelmer: thanks.  https://code.launchpad.net/~abentley/bzr-pqm/fix-lp-land/+merge/91318
<mgz> okay, nearly there, cut this down enough to be workable
<SamB> hmm
<SamB> it would be nice if bzr would save what it's downloaded so far to non-temporary packfiles every so often ...
 * SamB expects there's a bug about that
<jelmer> SamB: That's not necessarily useful - that would require it to send data in a specific order
<SamB> jelmer: hmm?
<SamB> oh ...
<jelmer> SamB: if it's sending texts first, then having those texts in the repository wouldn't be really useful if you didn't have the rest of the revisions
<jelmer> SamB: so you would need to change things so that revisions are sent in toplogical order, and grouped data per revision
<SamB> maybe for large clones, multiple packs should be negotiated, then?
<jelmer> SamB: why would you need multiple packs?
<jelmer> SamB: it seems you're trying to solve a symptome of a problem rather than the problem itself
<SamB> could be
<SamB> so, what I should be doing is making lp:launchpad smaller, you say?
<wgz> resumable branching would be ace
<wgz> but nothing has been designed with that in mind unfortunately
<SamB> well, I don't see anything to out-and-out prevent the client doing it anyway
<jelmer> SamB: why do you need resumable clones? Why is your clone being interrupted in the first place?
<SamB> well, okay, so bzr is eating a lot of RAM
<jelmer> SamB: the only thing you could do is to have the client request smaller chunks of data rather than a lot of revisions at once. I don't see what that really solves though.
<jelmer> SamB: so that seems like solving a symptom (interrupted clones) rather than the actual problem (high memory usage)
<SamB> but, there are many ways it *can* happen
<SamB> say, power loss
<wgz> ...the symptom there sounds easier :)
<SamB> and there's that, too
<jelmer> wgz: I don't see why we would need all that much memory during clone?
<jelmer> SamB: is power loss really common enough to warrant decreasing performance and adding extra roundtrips?
<SamB> jelmer: not seeing it is a *lot* easier than making the computer see not it
<wgz> people with unreliable and slow connections are common enough
<SamB> jelmer: well, it could be an option
<wgz> I've never touched the launchpad source because it was basically unbranchable for me when I tried some years back
<jelmer> wgz: we already retry in newer versions, so unreliable connections shouldn't be much of an issue anymore
<SamB> for those who tend to run out of batteries, lose connectivity, run out of RAM, you name it
<SamB> jelmer: doesn't that depend on how long the connection goes out for?
<jelmer> SamB: I'd rather see that engineering time be spent on reducing the memory overhead
<SamB> jelmer: would be a lot more time, I think
<wgz> there's also the fact 2a requires a lot of actual processing client side
<jelmer> SamB: I think they're both far from trivial.
<wgz> anyway, there are various annoyances, that lp:launchpad has more problems with than most projects
<jelmer> wgz: fair enough, but does that have to mean lots of memory use?
<jelmer> wgz: yeah - the other thing I think is that lp:launchpad has lots of ghosts, and the we seem to be querying those repeatedly
<wgz> jelmer: anything big that compresses well can cause memory issues on unpacking
 * SamB wonders if git actually manages to avoid this, or if he has simply not cloned a sufficiently large repository using the smart protocol for him to notice
<SamB> (on this system)
<jelmer> wgz: launchpad doesn't have really big tests so I'd be surprised if that was really an issue
<jelmer> SamB: git doesn't have an abstraction for the formats - there is one and only one format, and that's used directly by the server and client
<wgz> yeah, without actually looking at the memory consumption it would be wrong to blame any particular thing
<jelmer> SamB: so after the negotation, the server just streams a byte-for-byte pack file that the client can write to disk directly
<SamB> jelmer: that's no excuse for us to suck at cloning 2a to 2a over smart server ...
<SamB> jelmer: I thought the server used a thin packfile
<jelmer> SamB: right, that's what I've been saying all along :)
<SamB> which is not a file
<jelmer> SamB: a thin packfile is a valid pack file too, it just can contain deltas that have a base that is in a different pack file (that the client already has)
<SamB> jelmer: well, yes, I know it's the same format
<jelmer> as a client you can negotiate whether you're happy with a thin or a fat pack file
<SamB> oh, I missed that
<jelmer> (originally pack files were never thin IIUC)
<SamB> so ... when bzr reconnects, how does it resume downloading the same pack, anyway?
<jelmer> I'm not sure, I think it just re-does the request
<SamB> so why couldn't the request be saved along with the partial packfile again ?
<LeoNerd> If I rm -rf a branch directory I don't care about any more, it'll still leave the actual revisions in the parent's .bzr directory, yes? (because it's a shared repo)
<jelmer> SamB: because you would have incomplete data in the packfile, the order in which pack entries are sent isn't topological or grouped by revision.
<LeoNerd> Is there some garbage collection I can do to clean those up? Just want the disk space back really
<lifeless> jelmer: original pack files were thin, because they were just vf deltas split temporally rather than fileidly
<jelmer> LeoNerd: yes
<jelmer> LeoNerd: I think bzr-colo has something, but there's nothing in core that can clean those revision up.
<LeoNerd> Ah OK.. Then I won't worry overly for now.. it's not -that- big..
<SamB> jelmer: so ... how does the reconnecting thing help people with unreliable net connections?
<jelmer> SamB: they don't have to run the command again
<SamB> jelmer: that does a lot of good if the transfer keeps getting inturrupted, I suppose?
<jelmer> SamB: it will retry a particular HPSS request only once
<jelmer> SamB: so if it keeps getting interrupted you still have a problem
<jelmer> SamB: but I'm not sure if that's really an issue we should be trying to solve in bzr
<SamB> well, it would beat having to sit there and type "bzr pull -r <something>" over and over
<jelmer> SamB: so, let's fix the reason why you're keep hitting those memory limits
<jelmer> allowing resumes wouldn't be complex *and* would hurt performance even further
<jelmer> SamB: Git doesn't have any kind of resuming either - do you miss it there?
<SamB> well, somehow no
<jelmer> s/wouldn't/would/
<SamB> but I'm not sure why I haven't ...
<Stavros> hello
<jelmer> hi Stavros
<Stavros> i copied an entire working tree directory with cp -R master otherbranch and the repos are somehow shared, what trickery is this?
<Stavros> i want completely different repos i can push and pull from
<jelmer> Stavros: how are they shared?
<Stavros> when i commit in one, the commit shows up in the others
<jelmer> are they checkouts of the same branch, perhaps?
<Stavros> and bzr info on the other repos shows: shared repository: master/.bzr/branches
<jelmer> Stavros: you're using bzr-colo ?
<Stavros> i have it installed, yes
<SamB> lightweight checkouts ?
<jelmer> Stavros: it seems this is some sort of bzr-colo thing, I'm familiar with that - sorry
<Stavros> hmm
<Stavros> can i unshare it?
<SamB> jelmer: +not, right?
<jelmer> Stavros: euhm, yep, thanks
<SamB> Stavros: bzr reconfigure is your friend
<SamB> well, I think it is
<Stavros> bzr reconfigure --checkout .?
<Stavros> ah, standalone
<jelmer> stavros: "bzr reconfigure --standalone" I think
<jelmer> Stavros: are you using bzr explorer? I wouldn't know how you end up with bzr-colo workspaces otherwise
<Stavros> i'm not, but i colo-ified my repo once
<Stavros> but it's weird that it knows to share, since i'm doing cp -R
<Stavros> apparently this is a lightweight checkout
<Stavros> i didn't know you could do that with cp -R
<Stavros> bah, now bzr-reconfigure fails with "repo is already standalone" and bzr info says it's a lightweight checkout
<Stavros> i branched and moved the .bzr dir to this repo and now it's a standalone repo
<Stavros> but i don't understand what's going on otherwise
<Stavros> aha, now one of the branches complains there's no repo
<Stavros> i'll have a read on lightweight checkouts and figure it out, thank you all for your help!
 * SamB seems to recall having ended up editing .conf files in the past
<SamB> hmm, is there a way to use a different file instead of .bzr.log ?
<fullermd> env BZR_LOG
<SamB> is there any good reason for multi-pull to be recursing into .bzr directories?
<fullermd> That sounds like the 'find_branches blows' bug.
<fullermd> (well, related anyway.  It's going to "have to" recurse into .bzr for colo'd branches...)
<ls3> is there a way to extract a directory from a (remote) branch? Ie, I have a repo of surveys but I want to do something like 'bzr export bzrrepo/surveys/foobar1 /save/to/dir' in a release script
<ls3> Essentially extracting a single survey's directory within the repo.
<fullermd> export does that.
<ls3> oh ok. I must have failed previously
<fullermd> Note that it looks like you have the args in reverse order.  bzr export DEST SRC.
<ls3> yikes
<barry> i have a question about what bzr-builddeb -S is supposed to do when upstream releases a .zip file.  anyone around to chat about that?  jelmer?
<jelmer> hey barry
<barry> hi jelmer
<barry> jelmer: i'm helping someone add packaging for this: http://pypi.python.org/pypi/autobahn/0.4.10
<jelmer> barry: .zip isn't a valid extension for debian source files, so you would have to repack it
<jelmer> barry: bzr merge-upstream will accept .zip files, but it will re-export .orig.tar.gz files for this reason
<barry> jelmer: yep, so i added a get-packaged-orig-source target which calls `uscan --force-download --repack`
<barry> jelmer: but it still fails
<jelmer> barry: how does it fail - doesn't uscan create a .orig.tar.gz file?
<barry> jelmer: straight up uscan or even make -f debian/rules get-packaged-orig-source works properly, but bzr bd -S doesn't
<barry> http://pastebin.ubuntu.com/826923/
<barry> so this might just be a bug, but i wanted to understand what's intended before filing one
<barry> after that failure, i see ../autobahn-0.4.10.zip but no orig.tar.gz
<barry> and nothing in ../build-area
<jelmer> does 'make -f ...' actually create a .tar.gz file ?
<barry> yes, uscan --force-download --repack works.  it's bzr bd -S that doesn't
<barry> jelmer: iow, i can do the uscan, then debuild -S and i get the expected source package.
<barry> but bzr bd -S gives me the error
<jelmer> barry: perhaps it's creating it in the wrong directory
<barry> jelmer: could be, but if it's not in .. or ../build-area where would it be? ;)
 * barry plays with --orig-dir
<jelmer> barry: it should be in the cwd when make -f is executed, which is currently the source directory
<barry> yeah --orig-dir doesn't help
<barry> jelmer: yeah, there's no orig.tar.gz anywhere to be found
<barry> jelmer: in case you want to take a look: lp:~barry/+junk/autobahn
 * barry suspects it's just a bug
 * jelmer looks
<SamB> fullermd: what is this "find_branches" of which you speak?
<fullermd> The API that roots around for branches under a dir.  multi-pull would use it to find the branches to pull.
<jelmer> barry: you want --destdir=.
<jelmer> barry: as argument to uscan
<SamB> hmm, it looks like multi-pull is using something that drives find_bzrdirs, instead
<barry> jelmer: thanks, that does seem to work, but i'm disturbed by the fact that `bzr bd -S` and `make -f debian/rules get-packaged-orig-source` leave things in different states
<fullermd> Maybe that's what it's called.
<jelmer> barry: where does 'make -f debian/rules get-packaged-orig-source' create the tarball?
<SamB> no, the next method down is called "find_branches"
<barry> jelmer: in ..
 * SamB wonders where get-packaged-orig-source may be documented
<barry> SamB: if you add get-orig-source and run debuild, you'll see a warning to use get-packaged-orig-source instead ;).  istr it described in some dpkg-* or debuild manpage somewhere, but don't remember the details
<jelmer> barry: right, bzr bd expects the tarball in .
<SamB> hmm, it looks like bzrtools might be avoiding find_branches because it wants an iterator?
<jelmer> SamB: I think it's got it's own wrapper for find_branches which adds support for apache index.html files
<barry> jelmer: hmm.  okay.  it does bother me that it seems difficult/impossible to make this work for either bd -S or debuild -S
<barry> debuild -S afaict, expect it in ..
<SamB> jelmer: oh, that's also true
<SamB> I mean, there is certainly code here for scraping those
<barry> jelmer: but now that i know how this works, i think i will just file a bug on bzr-builddeb and we can discuss further there
<jelmer> barry: debuild -S doesn't run get-packaged-orig-source I think ?
<SamB> multi-pull might not touch that, though
<jelmer> barry: get-orig-source is defined as putting the tarball in the current directory, not ..
<SamB> it seems to iterate over *local* branches
<jelmer> barry: (per debian policy)
<jelmer> barry: I would be very wary of diverging from that.
<SamB> jelmer: presumably that's why this other target has a different name ?
<jelmer> SamB: hmm, which target?
<barry> jelmer: but, here's the problem.  if i do the following:
<SamB> the "get-packaged-orig-source"
<barry> make -f debian/rules get-packaged-orig-source
<barry> followed by
<barry> debuild -S
<barry> the latter will fail to find the orig.tar.gz even though it is in .
<jelmer> SamB: get-packaged-orig-source was added for bzr-builddeb specifically, because get-orig-source is defined retrieving the *current* upstream source tarball, not the upstream source for the current package version.
<SamB> oh
<jelmer> barry: right, but that's an issue for 'debian/rules get-orig-source' as well; we can't require get-orig-source to write to anything but "." because that would violate policy
 * SamB wonders why launchpad doesn't give him a preview of his merge proposal
<jelmer> we could change just get-packaged-orig-source, but that would make the target for get-orig-source and get-packaged-orig-source inconsistent which I think would be a bad idea.
<barry> jelmer: something still isn't sitting right with me. ;)  let me look at one other thing for a moment
<jelmer> barry: another alternative would be for bzr-builddeb to just do the repacking for you, doesn't it already do that?
<barry> jelmer: it doesn't
<jelmer> we could fix that at least, though
<barry> jelmer: yep, i can file on that
<barry> jelmer: here's what bothers me...
<barry> if i branch say ubuntu:python-wadllib and then bzr bd -S i get the orig.tar.gz in ..
<barry> it's also in ../build-area
<barry> and no .orig.tar.gz in .
<jelmer> barry: it's only copied there by bzr-builddeb itself before it builds
<barry> jelmer: copied from where to where?
<jelmer> barry: extracted from the relevant revision in the branch
<barry> jelmer: into both .. and ../build-area ?
<jelmer> barry: $(orig-dir) is the location where a cache of the orig tarballs is kept, $(build-area) is where the builds actually happen
<barry> jelmer: okay that does make some sense then.  in one case we're using a source branch, so the info is in the branch revisions.  in the other, we have to download it from the 'net so it must conform to policy
<jelmer> barry: the other difference is that files in $(orig-dir) can either be .tar.gz, .tar.bz2 or .tar.xz
<jelmer> barry: for the build-area they're converted as necessary (e.g. if you're building a 1.0 version package they're converted to .tar.gz)
<barry> make snse
<barry> sense even
<barry> jelmer: my (hopefully last ;) question is: what happens when the package gets uploaded and a source branch is created?  is get-packaged-orig-source ignored?
<jelmer> barry: yes, get-packaged-orig-source is just one way to get the source
<jelmer> IIRC we first look in ../tarballs, then check the branch for a relevant tag, then check get-packaged-orig-source, then try uscan
 * SamB didn't know 1.0 packages were required to use .tar.gz
<barry> jelmer: okay cool.  that all makes sense then and sounds good.  so i think the one bug to file then is that bd should do the repacking automatically, right?
<jelmer> barry: yep
<barry> jelmer: awesome.  thanks for all the help!
<jelmer> barry: perhaps another about bzr-builddeb making it clearer where it expects the generated tarball?
<barry> jelmer: yep
<jelmer> barry: np, thanks for getting to the bottom of this and providing useful feedback, as always :)
<barry> my pleasure! :)
<SamB> jelmer: does bzr-svn need to be so noisy about not being able to open such-and-such location with subversion?
<jelmer> SamB: it shouldn't be - what version of bzr-svn?
<SamB> jelmer: I mean, it's just log messages, but for multi-pull it's a lot of 'em
<SamB> hmm
<jelmer> oh, you mean about the files in ~/.bzr.log? I guess it could be a bit quieter about that
<jelmer> though I would also argue that the way in which the probing happens there is wrong
<SamB> jelmer: happens where?
<jelmer> SamB: in find_branches/find_bzrdirs
<SamB> ah
<SamB> yes, now that you mention it I did see some mention of probing elsewhere ...
<jelmer> SamB: that's very well possible :)
<jelmer> Probers are things that can detect a control directory somewhere
<jelmer> so we have a BzrProber that looks at .bzr/branch-format and returns the right bzr format based on that
<SamB> yeah, it seemed fairly likely given the name
<jelmer> and svn registers two probers, one that recognizes svn repositories and one that recognizes svn checkouts
<jelmer> etc
<SamB> jelmer: so, how *should* find_bzrdirs be probing?
#bzr 2012-02-03
 * SamB wonders how wide the tabs in subvertpy/_ra.c are supposed to be ...
<jelmer> SamB: 4 spaces
<vila> good morning all !
<mgz> morning
<vila> hey mgz
<mgz> how can I create a checkout with a bogus remote branch location for a test?
<LeoNerd> vim .bzr/branch/branch.conf   ?
<mgz> I'm after an idiom for a unittest, rather than just how to break things :)
<vila> mgz:  the problem is that opening a checkout requires a valid branch so you can't achieve that easily via the API,
<vila> I think you need to create a valid checkout and break it manually
<mgz> am trying to remember where the tests are the jelmer wrote when adjusting the bzr info output for foreign formats
<mgz> bt.test_info doesn't look familar and doesn't seem to test checkouts where the parent has gone missing
<jelmer> mgz: I don't think I adjusted info for foreign formats
<jelmer> mgz: there is a hook for info which can add more info, and which some foreign format plugins use
<mgz> what's the mp I'm trying to remember then...
<vila> hmm, one about info rings a bell
<LarstiQ> lp-open is awesome!
 * LarstiQ will not use lp-propose just yet
<jelmer> hehe
<mgz> jelmer: what time are you leaving today?
<jelmer> mgz: 5ish
<mgz> have a nice time :)
<LarstiQ> jelmer: ooh, fosdem?
<jelmer> mgz: thanks :)
<jelmer> LarstiQ: Jup! Are you going this year, or are you still in .fi?
<jelmer> hmm, "still in .fi" sounds a bit odd considering you've moved there :)
<LarstiQ> jelmer: not going, we need to get our house done before the moving date of the 15th
<LarstiQ> jelmer: uhuh :)
<LarstiQ> jelmer: we're visiting .nl for a week in march though!
<jelmer> LarstiQ: congrats on the new house - are you still near(ish) Helsinki?
<jelmer> LarstiQ: cool, give me a shout if you happen to have some time/zin to grab some coffee/tea/$beverage when you're here
<LarstiQ> jelmer: yup, moved a bit closer to Helsinki.
<LarstiQ> jelmer: will do :)
<abentley> jelmer: when do you think you'll be able to look at https://code.launchpad.net/~abentley/bzr-pqm/fix-lp-land/+merge/91318 ?
<mgz> can someone unprivate bug 925933?
<ubot5`> Error: Launchpad bug 925933 could not be found
<jelmer> mgz: one sec
<jelmer> abentley: sorry, I got distracted.. will look now
<abentley> jelmer: thanks.
<jelmer> mgz: unprivatizatationed
<mgz> jelmer: ta
<abentley> jelmer: thanks for the review.
<abentley> jelmer: I tried using a native colocated branch for Launchpad hacking, but didn't get very far, because it ran Launchpad's bzr (bzr-2.5.0dev2_r6152-py2.6-linux-x86_64.egg) which complained "Unknown bzrdir format: 'Bazaar meta directory, format 1 (with colocated branches)\n'"
<abentley> jelmer: i.e. our make process uses the egg version of bzr that ships with lp to examine the cwd, and the current bzr is too old.
<abentley> jelmer: Not make, test.
<abentley> jelmer: no, make.
<LarstiQ> abentley: jelmer is in a train to Brussels atm I think
<abentley> LarstiQ: Cool.
<jelmer> abentley: yes, it wouldn't work with the bzr in launchpad at the moment
<jelmer> I have an MP open to update the version of bzr used by launchpad
<jelmer> LarstiQ: I wish :)
<jelmer> snow on train tracks -> chaos in .nl
<abentley> jelmer: Oh, cool.
<AuroraBorealis> what is this snow?
<AuroraBorealis> (sits around in shorts in his 70 degree F winter)
<abentley> AuroraBorealis: Something tells me the aurora borealis is not commonly visible where you are.
<AuroraBorealis> no it is not haha. far from it.
<fullermd> 's been the same here.  What a pointless season.
<jelmer> abentley: :)
<mgz> these NoSuchRevision bugs confuse me
<SamB> jelmer: so, *what* do you think is wrong with the way find_bzrdirs probes?
<mgz> SamB: I just posted some fixable looking bugs to the list if you're interested
<wgz> aa, standing up too long today
#bzr 2012-02-04
<alkisg> Hi, commits in git can be annotated with one-line descriptions and with multi-line comments, e.g. https://git.ipxe.org/ipxe.git/commit/fcc35bf48776fff9ebfd8db537679583221a9cd4.
<alkisg> Is there a similar concept in bzr, where I would be able to only see the one-line descriptions e.g. with bzr log, but I would also have the ability to see the analytical comments about each commit with bzr detailed-log or something?
<alkisg> Hmm it seems that git follows a convention similar to .deb package descriptions, i.e. leaving an empty line between the one-line description and the detailed commit message.
<alkisg> Does bzr have something similar?
<SamB> bzr log --line ?
 * alkisg just found "git log --oneline", try ing "bzr log --line" now...
<alkisg> Yup, thank you SamB
<jelmer> SamB: hi
<jml> in a colo, how do I fetch & switch to a remote branch?
 * SamB wants to joke "over SSH""
<jelmer> jml: hi
<jml> jelmer: hello
<jelmer> jml: 'bzr branch --switch lp:foobar file:,branch=bar'
<jelmer> or manually branch and then 'bzr switch bar'
<jml> 'manually branch'?
<jelmer> 'bzr branch lp:foobar file:,branch=bar; bzr switch bar'
<jml> ahh.
<jelmer> the syntax isn't ideal, we're still working on that
<jelmer> it's hard to get to something that's not ambiguous
<jml> jelmer: so there's 'switch -b' _and_ 'branch --switch'
<jelmer> jml: yes, 'switch -b' bases the new branch on the current branch
<jml> jelmer: that's a bit confusing.
<jelmer> jml: in what way?
<jml> jelmer: I guess in my head, 'switch -b' expands to 'switch --branch' (I know it expands to --create-branch)
<jml> jelmer: and looking at 'branch --switch' vs 'switch --branch', I can't figure out which is for which purpose, or why the two would be any different
<jml> I guess it's obvious when you try to implement it
<jelmer> jml: I don't really like the -b alias for --create-branch
<jelmer> jml: I think it's there for consistency with 'git checkout -b'
<jml> jelmer: what would you propose instead
<SamB> jelmer: pretty sure, yeah
<SamB> I'm not sure I didn't suggest that?
<AuroraBorealis> interesting thing i found: http://thread.gmane.org/gmane.comp.version-control.git/189776
<wgz> AuroraBorealis: that was quite interesting
<AuroraBorealis> yeah
<wgz> git not having great annotate performance is pretty well known
<AuroraBorealis> its kinda related to that long standing bug where bzr was trying to import a huge repo
<wgz> but the giant cold cache penalty seems... surprising
<AuroraBorealis> its interesting to see how any vcs would handle freaking
<AuroraBorealis> 1.3 million files
<wgz> I guess it's very filesystem dependant for any operation that peeks at every file in a huge tree
<AuroraBorealis> yeah. one of the suggestions was just
<AuroraBorealis> "get some SSD's "
<wgz> I think ext4 also doesn't have seperate metadata blocks?
<wgz> so probably ends up needing to read from much more areas of the disk
<AuroraBorealis> does it clump all the metadata together?
<AuroraBorealis> so it doesn't have to skip around?
<wgz> I think it doesn't, but some filesystems do, or do to some measure
<AuroraBorealis> i have no idea about filesystems but i was just wondering if any VCS would handle such extreme repo sizes
<wgz> some of the comercial ones are certainly more tuned for it.
<wgz> but there's also a fair bit of cheating with big beefy central servers and partial checkouts I think
<AuroraBorealis> people were suggesting just splitting it into different repos which just seems like a cop out to the real problem
<wgz> which, in the dvcs world, the advice of having more smaller repos is sensible analogue
<wgz> heh, you typed faster
<wgz> but it's really the same kind of cheat
<AuroraBorealis> yeah, i have no idea what facebook is keeping in there
<AuroraBorealis> i hardly think that just the sourcecode to facebook is 1.3 million indepenent files
<wgz> php *is* pretty bad :)
<AuroraBorealis> haha
<AuroraBorealis> i hear you there
<Noldorin_> hey jelmer
#bzr 2012-02-05
<LarstiQ_> wgz: I've got a number of utf8 failures I'm not sure are due to bzr or due to pypy
<LarstiQ_> wgz: should I start out by filing them on bzr anyway?
<LarstiQ_> aah
#bzr 2013-01-29
<foxhouston> Hi all
<foxhouston> I have a problem for which I could not find a solution.
<foxhouston> when I enter a folder with several project versioned, screen starts blinking
<foxhouston>  The version of Bazaar I use is the 2.5.1
<foxhouston> I have experienced this problem either in Windows Xp Service Pack 3 or Windows 7
<jdahlin> jelmer: FYI, I managed to migrate my bzr repositories over to git, but had to work around a couple of bugs that are no longer present in current bzr versions
<jdahlin> # A -> B, B -> A in the same commit should be nulled out
<jdahlin> # A -> B, B -> C, should be A -> C
<jdahlin> none of the existing tools handled that
<jelmer> jdahlin: which of the existing tools did you try?
<jdahlin> jelmer: fast-import, dpush, git-remote-bzr
<jelmer> jdahlin: ah, ok
<jelmer> jdahlin: git-remote-bzr uses either fast-import or bzr-git (just like dpush) under the hood
<jdahlin> jelmer: no, it uses neither
<jdahlin> jelmer: it just reads from bzrlib and generates the fast-import format on the fly
<jelmer> jdahlin: argh, then somebody created another tool with the same name?
<jdahlin> jelmer: https://github.com/git/git/blob/master/contrib/remote-helpers/git-remote-bzr
<jdahlin> it's the one in the git repository
<jelmer> yeah, but it's dated from *after* bzr-git shipped a tool with that name
<jdahlin> oh well.
<jelmer> and judging from the copyright header that guy was aware of the duplication
<jelmer> anyway..
<jelmer> glad you managed to get your repositories converted
<jdahlin> seems to be another few projects called git-remote-bzr as well
<LeoNerd> Can I  bzr merge  the addition of a directory from one branch into another, without also merging adding a file in that directory at the same time?
<mgz> yu.
<LeoNerd> Branch contains a revision that adds a dir and a file within it. I want to merge just the directory addition, so it doesn't keep conflicting every time I switch
<LeoNerd> Hrm.. so how's that then? I presume I need some sort of no-recurse option?
<mgz> no, you need to do the full merge, then revert the bit you don't want
<LeoNerd> Oooh.. duh!
<LeoNerd> Ofcourse :)
<mgz> then, if you *are* going to want it later, merge that branch back to the other one and keep the file you didn't merge
<LeoNerd> Yah
<mgz> alternatively, you want the changes I have proposed against 2.6 which make dir conflicts less painful
<LeoNerd> Well, that's an easy workaround for now
<LeoNerd> In future I'll just have to remember to add the directory itself in its own revision on the trunk
<LeoNerd> (I'm playing dual-VCS games :) )
<LeoNerd> Bah.. bzr revert  adding the file to the dir also reverted adding the dir itself :/
<LeoNerd> Ahhah. bzr rm  the file
<LeoNerd> keeps the dir
<mgz> right, or revert with path.
<LeoNerd> Well, I did that
<LeoNerd> bzr revert path/to/dir/file.java    showed   -D path/to/dir/file.java  -D path/to/dir/
<LeoNerd> but I have it working now.. I just  bzr rm  the file and the directory remains, empty
<mgz> ah, revert being smart I guess
<LeoNerd> Yah.. usually I'd liek that but in juuust this case, too smart
<LeoNerd> Anyway, all is now committed and now I can freely switch branches without that dir getting upset
<mgz> right, remember to do the merge the other way before landing, or you'll lose the file and wonder where it went :)
<LeoNerd> Already merged. I actually did   bzr revert --forget-merges  on the trunk
<LeoNerd> Then merged that (empty no-op) commit back into the branch. so now all is happy
<mgz> ace.
<LeoNerd> For general background: I'm using a dual bzr+p4 working directory, using bzr to work around p4's lack of features..
<LeoNerd> So what was confusing bzr was that I'd added one file to a dir, that already actually existed and had other files in.. so it wasn't empty when it wanted to remove whenever I switched to trunk
<LeoNerd> Someone remind me again: how to  bzr shelve  with a smaller diff horizon? It's managed to merge two unrelated changes in one chunk because there weren't enough unchanged lines inbetween
 * LeoNerd ooooohs, having just read about change_editor
<LeoNerd> vimdiff? :)
<mgz> right :)
<mgz> I have this set in bazaar.conf:
<mgz>   change_editor = vimdiff -of @new_path @old_path
<LeoNerd> Hrm... -of ?
<LeoNerd> Hrm... doesn't appear to help.. :/
<mgz> you then hit 'e' in shelve?
<mgz> LeoNerd: I took the options from an example somewhere, -o is horizontal split apparently
<LeoNerd> Ooooooh I see
<LeoNerd> You have to 'e'
<LeoNerd> Soyeah,  vimdiff  implies -o anyway
<LeoNerd> and -f is only useful to gvim
<LeoNerd> Ahyes, e works fine now
#bzr 2013-01-30
<Logomachist> Hi
<Logomachist> I was trying to install from source on Windows but it wasn't going very well so I gave up and used the standalone installer.
<Logomachist> Was my orginal goal ill-advised?
<spacecowboy29> A question , when trying to fetch a branch I get this error http://paste.ubuntu.com/1589248/
<spacecowboy29> corkscrew is referred to as corksrew, so I guess a typo, but I don't know where I should correct it...
<mgz> spacecowboy29: looks like you've got some borked config
<mgz> try `ssh -vv YOURLPNAME@bazaar.launchpad.net` and get that working first
<spacecowboy29> Ah, same error http://paste.ubuntu.com/1589664/
<spacecowboy29> Would fiddling around with bazaar.conf help ?
<mgz> no, it's ssh that's borked, not bzr
<mgz> you were meant to substitute the bit in CAPS though :)
<spacecowboy29> holy...
<mgz> and you don't need the `` when running
<spacecowboy29> Ah I feel like an idiot...sorry
<mgz> spacecowboy29: basically, you need to fix your ~/.ssh/config
<mgz> you have a proxy command that's using a tool you don't have installed
<mgz> well, it's tyoped at any rate, but you probably don't want it
<spacecowboy29> I corrected the typo from "corksrew" to "corkscrew" an error though, I've installed corkscrew though
<spacecowboy29> Should I nuke the cofig file ?
<spacecowboy29> Here's the config file http://paste.ubuntu.com/1589680/
<mgz> just remove that, if you don't actually need to ssh via that?
<spacecowboy29> I'm under a HTTP proxy, so I probably need it ?
<spacecowboy29> The typo error is removed but it still shows a few errors http://paste.ubuntu.com/1589690/  Are my keys bad ?
<mgz> perhaps, you'll need to `man corkscrew` and figure out the right configuration if you really do need it
<mgz> spacecowboy29: nope, it's not getting as far as key exchange, you can't open a connection of any kind
<mgz> I suggest reading up on tunnelling ssh over http, it's probably non-trivial and may require more than you can actually use
<spacecowboy29> Ah, I see, thanks a ton ! Will have to check out, thanks again !
<mgz> note, you don't need ssh for read-only access to launchpad, just to push branches yourself
<mgz> rmoving your launchpad_username from bazaar.conf and ignoring the message that tells you it's not set makes bzr use http for lp: urls
<spacecowboy29> I see, I think my ip lets only http and https connections, so maybe thats the problem
<mgz> it seems like corkscrew might work, but you probably want to follow a guide on that and see if you can actually ssh to anywhere once you're set up
<spacecowboy29> Removing it seems to work, so I guess I need to configure corkscrew for it, thanks again  !
<mwhudson> what's the api equivalent of 'bzr branch'?  sprout?
<spiv> mwhudson: IIRC, yes, depending on the level you're operating at.
<spiv> I *think* there's a convenience method that's more closely like the 'bzr branch' command somewhere too.
<xnox> most of the time you want branch_or_dir thing (whatever is it's proper name)
<mwhudson> xnox: i'm not sure that counts as a helpful comment :-)
<xnox> mwhudson: =)))) it's midnight here and I'm chatting =) how you doing btw? =)))))
<mwhudson> sigh
<mwhudson> rev
<mwhudson> bzr: ERROR: Revision {andy.doan@linaro.org-20130130184516-m3y3yvonltpjl45i} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(CallableToParentsProviderAdapter(<bound method CHKInventoryRepository._get_parent_map_no_fallbacks of CHKInventoryRepository('file:///home/mwhudson/canonical/repos/lava-manifest/deploy-from-branches/branch-cache/lava-dispatcher/.bzr/repository/')>))], []))))".
<mwhudson> xnox: i'm ok, super busy all of a sudden
<mwhudson> oh, that was me being dumb
<spiv> mwhudson: ERROR: Not enough brackets in errorâ¦
<mwhudson> spiv: i recall a similar joke about colons
<mwhudson> this one only has 3 though, and one of them is a bit of a cheat
#bzr 2013-01-31
<mwhudson> i think create_clone_on_transport might be the more 'bzr branch'y api
<mwhudson> i wonder what the no_tree argument does
<lifeless> mwhudson: hi
<spacecowboy29> A question, I'm not able to connect to lanchpad, I'm using corkscrew since I'm behind a proxy,  I'm not sure what I'm doing wrong... http://paste.ubuntu.com/1592875/
<mgz> from yesterday, can you ssh to anywhere at all like that?
<mgz> if not you really need corkscrew help, not bazaar/launchpad help.
<spacecowboy29> yes, hi :) no I'm not able to ssh anywhere else
<spacecowboy29> I followed the corkscrew help, by adding the config file "Proxy Command 172.16.35.90 8080 %h%p"
<mgz> spacecowboy29: can you http proxy through the given ip and address?
<spacecowboy29> I was able to connect using bzr when I removed my username from bazaar.conf
<spacecowboy29> bzr branch lp:calibre, seems to work fine when I'm not using a username from bazaar.conf, so I should get some corkscrew help ?  Does bzr handle ssh through https on it's own ?
<mgz> did you have HTTP_PROXY set?
<spacecowboy29> yes I set it system wide in the Networks option
<spacecowboy29> But this was working before, I must have borked some config file or something, if this doesn't work I'll have to reinstall the os, then I'll know for sure....
<mgz> google "ssh corkscrew" or something, from their readme it seems it only works against certain http proxies
<mgz> so, you might need to find out what http proxy is and if it's on the supported list
<spacecowboy29> ok will do, thanks :)
<DarylXian> hi.  can bzr checkout a single revision/tag from a remote repo, or do i have to pull the entire repo, then select/switch to a tag locally?
<LeoNerd> bzr co -rFOO URL
<LeoNerd> -r123 or -rtag:NAME or whatever
<DarylXian> LeoNerd: ah, simple enough. noted!  thx.
<LeoNerd> The commandset is usually quite orthogonal like that. Most commands that can care about a specific revision take a -r for example
<DarylXian> LeoNerd: when i bzr co -rtag:FOO, am I still pulling the complete repo, in terms of total MB, but just ending up in the FOO-tag state?  or Am I actually pulling less content?
<LeoNerd> Er... hrmm.. Notsure offhand
<DarylXian> I'm trying to avoid, specifically, pulling the entire MySQL repo just to get at the latest code.  It's *huge* (&/or slow ...)
<LeoNerd> Oh. So you'll still get all the history up until that point
<LeoNerd> So even if you pull -r1000 you'll get -r1 to -r999 as well. I'm just not sure if it will pull any history -past- that; -r1001 and onwards
<DarylXian> ah, so not a solution.  unless 'they' create a tarball from a specific checkout, I get all the prior history. :-/
<LeoNerd> Yah
<DarylXian> well, rats.
<DarylXian> thx
<bsd> Oh DarylXian left â he could use a stacked branch
<LeoNerd> Is there a handy way I can store locally in a workdir, some extra name=value information related to a specific branch?
<LeoNerd> I'm writign some wrapper automation scripts, and I need to keep track of some more details
<mgz> LeoNerd: `bzr config --scope=branch leo-special=1`?
<LeoNerd> Hmmm.... that might work
<mgz> retrieve by not assigning
<LeoNerd> Yah.. I'll try that, thnaks
<LeoNerd> ... now all I need to do is work out how to wrap  p4 change  and obtain the new OCL number
<mgz> I'd use a prefix just so you're double-sure not to clash with other config keys :)
<LeoNerd> Sure
#bzr 2013-02-01
<Meatball_py> I'm new to bazaar, just wondering if it is possible to create such a bzr server:
<Meatball_py> 1. It branches a launchpad project
<Meatball_py> 2. It pulls from launchpad regularly (every midnight)
<Meatball_py> 3. I pull from this bzr server, and I can commit changes to this server
<Meatball_py> 4. If required, I can resolve conflicts on this server manually
<JPeterson> how do i change `bzr revert -r2` to only revert r2 rather than r2..-1
<james_w> JPeterson: bzr merge -r2..1
<james_w> it's a "reverse merge" of the revision that you don't want, so will remove the changes from that revision, but not others
<JPeterson> james_w: it returns many (599 conflicts). can i avoid that?
<JPeterson> james_w: i rectract that stement, i specified the wrong revision range
<JPeterson> how do i change `bzr git-apply -`to read from stdin?
<jelmer> JPeterson: see cmds.py in the bzr-git source
<jelmer> JPeterson: but please note that bzr git-apply is experimental and e.g. doesn't handle new files or renames
<JPeterson> jelmer: there's no such file http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/files
<JPeterson> jelmer: do you mean http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/commands.py ?
<JPeterson> i dont see the answer
<JPeterson> explain the answert
<JPeterson> jelmer, i haven't received a reply to the question if bzr git-apply can read from stdin
<jelmer> JPeterson: Yeah, commands.py
<JPeterson> jelmer: row?
<jelmer> JPeterson: in cmd_git_apply, the run method
<JPeterson> jelmer: row?
<JPeterson> do you mean http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/commands.py#L292 ?
<JPeterson> is it `bzr git-apply sys.stdin`?
<JPeterson> thet return
<JPeterson> bzr: ERROR: [Errno 2] No such file or directory: u'sys.stdin'
<JPeterson> jelmer: message fot you
<JPeterson> open(sys.stdin, 'r') return
<JPeterson> TypeError: coercing to Unicode: need string or buffer, file found
<JPeterson> it seems like the answer to
<JPeterson> [19:12] <JPeterson> how do i change `bzr git-apply -`to read from stdin?
<JPeterson> is no
#bzr 2013-02-02
<shnatsel> Hello!
<shnatsel> Does anybody know if I can force bzr to use HTTP transport for Launchpad branches given in "lp:..." format?
<shnatsel> I'm going to run an unattended script on a machine that's authenticated to Launchpad with SSH, but the key has a password and it's typically locked, so the script tries to use SFTP transport and fails.
<LarstiQ> shnatsel: remove the launchpad login in the config
<LarstiQ> shnatsel: launchpad_username in ~/.bazaar/bazaar.conf
<LarstiQ> shnatsel: remove/comment out
<shnatsel> LarstiQ: the problem is I still want to keep the SSH transport for operations I perform manually
<shnatsel> and scripts with such side effects are not a great idea
 * LarstiQ nods
<shnatsel> maybe there's some environment variable I can export or something like that?
<shnatsel> if all else fails I can replace all "lp:" with "https://code.launchpad.net/" but that's ugly and error-prone
<LarstiQ> shnatsel: I'm not aware of a good solution, but one is terribly welcome
<shnatsel> LarstiQ: okay, where can I get the code for launchpad plugin?
<LarstiQ> shnatsel: looking at the bzrlib/plugins/launchpad/lp_directory.py code, it shouldn't be too hard to make it more flexible
<LarstiQ> shnatsel: it's part of core bzr, so `bzr branch lp:bzr` will do
<shnatsel> I'm more of a shell scripter than a pythoneer, but I'll see what I can do
<LarstiQ> shnatsel: bug 238776 it looks like
<ubot5> bug 238776 in Bazaar "Confusing error message if ssh login fails while using lp url" [High,Confirmed] https://launchpad.net/bugs/238776
<LarstiQ> shnatsel: feel free to ask for help on how to proceed with that
<LarstiQ> shnatsel: my bzr coding is very rusty, but I promise to help review whatever you come up with
<shnatsel> LarstiQ: thanks!
 * LarstiQ heads for lunch and mathematics
<shnatsel> as far as I can tell, _resolve(...) in bzrlib/plugins/launchpad/lp_directory.py is what turns lp: URI into bzr+ssh:// or https:// URI
<LarstiQ> shnatsel: yes
<LarstiQ> shnatsel: #  Only accept launchpad.net bzr+ssh URLs if we know the user's Launchpad login:
<shnatsel> no, that seems to be an unrelated function
<LarstiQ> shnatsel: that's in _resolve
<shnatsel> oh
<shnatsel> I confused it for another function definition, sorry. I see now, thanks!
<LarstiQ> shnatsel: you could try to see if http comes up as an option but gets rejected because of that logic
<LarstiQ> by say putting a trace.mutter at the start of the loop
<shnatsel> oh, by the way, how do I test the changes I make?
<LarstiQ> and then tailing ~/.bzr.log
<LarstiQ> shnatsel: in the end, by writing a test in test_lp_directory.py I think
<LarstiQ> shnatsel: but for starters, change that file, and then run ./bzr from your branch
<LarstiQ> shnatsel: bzr can run directly from the branch, no installation needed
<LarstiQ> quite handy for development
<LarstiQ> shnatsel: doc/developers/HACKING.txt may have some helpful bits for debugging and such
<shnatsel> No, it doesn't consider using HTTP transport
<shnatsel> well, at least when ssh is available
<shnatsel> let me relogin, I can't kill off ssh-agent for some reason
<shnatsel> no, it doesn't even consider using HTTP URLs
<shnatsel> when bzr+ssh is not available
<shnatsel> I'm not sure how to implement proper fallback, it seems to require pretty big changes, as per James Westby's comment on bug 238776
<ubot5> bug 238776 in Bazaar "Confusing error message if ssh login fails while using lp url" [High,Confirmed] https://launchpad.net/bugs/238776
<shnatsel> what I can add is checking for environment variable and forcing HTTP if it's set to "true"
<shnatsel> I'm not sure if that's an acceptable solution
<LarstiQ> shnatsel: I don't think we need to go quite as far as james_w suggested there
<LarstiQ> shnatsel: probably not for bzr proper, but you can take that approach locally of course
 * LarstiQ does some testing
<shnatsel> okay, so I shall add some kind of a URL blacklist parameter to the lookup function, then add error handling to SFTP module that checks if it's a launchpad branch and if it is, try to fall back to other URLs?
<LarstiQ> shnatsel: it should be enough to change 'if _lp_login is not None:' to 'if _lp_login is not None or url in blacklist' or somesuch
<LarstiQ> shnatsel: because when the launchpad username is not set, lp:bzr resolves to http://  , and when it is, to bzr+ssh://
<shnatsel> that is rather trivial, I'm more worried about the error handling in SFTP/bzr+ssh module
<LarstiQ> shnatsel: what error handling are you thinking of?
<shnatsel> as described in the bug, if bzr+ssh transport fails
<LarstiQ> shnatsel: but you don't actually need that, do you?
<shnatsel> no
<shnatsel> I'm not sure how to pass the blacklist either and what exactly it should contain
<LarstiQ> shnatsel: right
<shnatsel> I could pass URL prefixes probably, as that's what the function operates on
<LarstiQ> shnatsel: can you explain some more how your automatic setup would work?
<LarstiQ> shnatsel: ah hmm
<LarstiQ> shnatsel: I suppose if you are sticking to local, you could indeed go with checking an environment variable
<shnatsel> in fact I'm not
<shnatsel> this is not even REQUIRED for my latest project, I can get by with sed I think...
<shnatsel> it's just... there are lots of cases when http is desired over ssh for accessing Launchpad, such as running a script under su or sudo (ssh can't access keys), or when you want a script to work on other users' machines and want it to run unattended even if their SSH keys is locked
<LarstiQ> right
<shnatsel> it's not necessary for me right now, but it's something that's been bugging me and striking back for years
<LarstiQ> shnatsel: so there are two things that come to mind
<LarstiQ> shnatsel: one is decorating the url
<LarstiQ> shnatsel: like http+lp:branch
<LarstiQ> shnatsel: and the other is the fallback to http when ssh doesn't work
<shnatsel> the first is already possible but it's error-prone
<shnatsel> sed 's|lp:|https://code.launchpad.net/|'
<shnatsel> that does the trick #1
<LarstiQ> shnatsel: right, but now with bzr support
<shnatsel> and fallback doesn't work
<LarstiQ> shnatsel: bzr _has_ support for decorating urls
<shnatsel> because the script just sits there waiting for user to input password to SSH key
<LarstiQ> but it needs to be extended to lp:
<LarstiQ> shnatsel: right
<LarstiQ> shnatsel: this could time out, but yeah
<shnatsel> that's why I thought of environment variable
 * LarstiQ nods
<LarstiQ> shnatsel: so the environment variable thing would be something like "try: no_ssh = os.environ('NO_LP_SSH') except (KeyError, ValueError): no_ssh = None"
<LarstiQ> shnatsel: and then `url in blacklist` would be `or no_ssh is not None`
<shnatsel> LarstiQ: makes sense
<shnatsel> yeah that looks good to me
<shnatsel> LarstiQ: shall I create a branch with that and post an RFC/merge request?
<shnatsel> I think it will still need tests and documentation
<LarstiQ> shnatsel: yeah, it might serve as a point for further discussion
<LarstiQ> shnatsel: so a merge request is ok I think
 * LarstiQ now really detaches to do some math
<shnatsel> I can't get to the fallback path for some reason
<shnatsel> I get an error:
<shnatsel> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/elementaryos": no supported schemes
<shnatsel> and it never considers the http URL
<shnatsel> Turns out the HTTP URL is not even passed to that function.
<shnatsel> Okay, I give up. Pushed what I have so far to lp:~shnatsel/bzr/launchpad-no-ssh-switch
<shnatsel> oh wait, looks like I gave up too early
<shnatsel> well, tried a bunch of other things, still nothing. Now I really give up.
<vila> shnatsel: another solution would be to use a different user for your unattended operations. But you may run into access rights issue if these operations need write access. But using the same user, you can override BZR_HOME (which controls how bazaar.conf is reached) to point to a directory with whatever is needed for your unattended operations.
<jelmer> JPeterson: sorry, I'm at a conference and I only have limited access to irc
<jelmer> JPeterson: try /dev/stdin rather than just -
#bzr 2013-02-03
<vedic> I have created a local repository. I want to use this for creating a branch on remote system. How to do that?
<vedic> Note that local system doesn't have static ip.
<LarstiQ> vedic: `bzr push some/remote/location`
<vedic> LarstiQ: yea, that has worked.
<vedic> LarstiQ: How to allow files with certain extensions only (like .gz, .bz2, .tar ) but not any other files or directories to tracked
<LarstiQ> vedic: preventing tracking entirely is perhaps tricky
<LarstiQ> vedic: but you can ignore everything else
<vedic> LarstiQ: How to ignore everything else?
<LarstiQ> vedic: see the "debian" example in `bzr help ignore`
<LarstiQ> so something like RE:(?!.*\.(gz|bz2|tar))
<LarstiQ> vedic: may require some tinkering to get the regex exactly right
<vedic> LarstiQ: so something like: bzr ignore "!.tz"  bzr ignore "!.bz2"  bzr ignore "!.tar"
<vedic> would not that ignore every thing else?
<vedic> and before that bzr ignore "*"
<vedic> LarstiQ:^
<LarstiQ> vedic: !*.tz, otherwise you will match only the exact file ".tz"
<vedic> LarstiQ: oh yea
<vedic> LarstiQ: Would these ignore apply on root directory? How to ignore inside a particular directory?
<vedic> root => repo main direcotry
<tsul> Hi!Don't
<tsul> Don't you know when the next stable version of Bazaar will be released?
#bzr 2014-01-27
<awilkins> Probably a common and stupid question but googling answer is hard
<awilkins> What's the equivalent of git rebase -i in bzr
<awilkins> Want to remove one revision from the history of a branch
<awilkins> Hum, in other words : https://bugs.launchpad.net/bzr-rewrite/+bug/243150
<ubot5> Ubuntu bug 243150 in bzr-rewrite "support -i flag as per git" [Wishlist,Triaged]
<awilkins> May just reverse CP this revision
<jelmer> awilkins: yeah, sounds like it
<awilkins> jelmer, Reverse cherry pick was more appropriate to this case anyway
<jelmer> ah, cool
<achiang> when doing a bzr merge of a branch, is there a shortcut to have the commit message just say what branches i pulled from?
<achiang> i'd settle for any type of shortcut/boilerplate for a merge commit message
<rozzin> achiang: "bzr commit -m"?
<achiang> rozzin: i still have to supply an arg for -m right?
<jelmer> achiang: yep
<jelmer> achiang: there is nothing like what you're asking for AFAIK
<achiang> so that's not a shortcut at all
<jelmer> it would not be hard to do a hook around 'bzr merge' that sets a proposed commit message
<achiang> jelmer: darn, too bad. it's just a little papercut, but i find myself frustrated every time i trip over it
<jelmer> achiang: I'm sure patches are welcome :)
<achiang> jelmer: i think i'd rather just build up scar tissue ;)
<jelmer> heh
#bzr 2014-01-31
<xnox> can I use lp:foo syntax, but force using un-authenticated / http access?
<jelmer> xnox: if I remember correctly, we talked about that but never implemented it
#bzr 2015-01-29
<sumanah> is there a built-in bzr command to update *multiple* directories/branches in a single command?
<sumanah> or should I do something like    bzr update ~/foo ; bzr update ~/bar
<sumanah> The latter works, but if there's something better, it would be nice to know about it
#bzr 2016-02-02
<jubalh> hi
<jubalh> i clone this https://code.launchpad.net/~g-bluehut/ubuntu-terminal-app/whitespacefix/+merge/228807 which has the 'merged' but when i go through the log and search i caant find it. am i using bzr wrong here?
<jubalh> different branch it seems
#bzr 2016-02-03
<calher> How do I download my already-existing repo so I can make changes and push back up?
<Peng> "bzr branch"?
<calher> Peng, thanks!  I didn't know if that was just for new repos or not!
<calher> bzr: ERROR: Cannot lock LockDir(chroot-63781840:///~csh-a/calher-configs/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
<calher> I had problems trying to make a push -- http://hastebin.com/raw/uhapewidul
<calher> oh, and i did also generate an ssh key and give it to launchpad
<fullermd> What's the push location?
<calher> fullermd, I want it to go to <https://launchpad.net/calher-configs>.
<fullermd> Can't push over https.  Also doesn't sound like a branch location anyway.
<fullermd> You probably want to do something like "push --remember lp:what/ever" and let it translate it, since you're logged in.
<calher> fullermd, Run command: bzr push
<calher> Using saved push location: bzr+ssh://bazaar.launchpad.net/~csh-a/calher-configs/trunk/
<calher> That's where it went when I tried it.
<calher> I didn't actually try to push it to the https...
<fullermd> 'k, that's a writable transport (assuming you're logged in)
<calher> I have an SSH key and it knows my username...
<fullermd> If you're getting the chroot message, it's probably logging in OK.
<calher> the pubkey is on launchpad
<fullermd> Is csh-a you?
<calher> csh-a Is
<fullermd> 'k, so you're presumably be OK permissions-wise.
<fullermd> Can you 'bzr ping' that URL?
<calher> the weird lp: one?
<fullermd> I'd go with the bzr+ssh, just to be sure it's the same.
<calher> Response: ('ok', '2')
<calher> Headers: {'Software version': '2.6.0.lp.2'}
<fullermd> Well, that sounds reasonable enough.
<fullermd> Oh, hang on, that's an import branch?  You probably can't push directly to those.
<fullermd> So you'd have to push somewhere else, or delete/move that aside and push up to it fresh making a normal branch.
<fullermd> (LP thing, not strictly a bzr thing)
<calher> I suspected that only Launchpad could mess with that branch.
<calher> Sounds confusing to move it somewhere else
<fullermd> Well, if you're wanting to maintain it in bzr, the import from git only matters long enough to do the conversion.
<fullermd> If you're planning to maintain them in parallel somehow, that's another matter.
<calher> I want to get rid of the git and start using bzr
<fullermd> 'k, then you don't need the LP import branch to sit there and keep running.  So you can just delete it, and then doing a push will create a 'new' plain branch in the location.
<calher> fullermd, go to <https://code.launchpad.net/~csh-a/calher-configs/trunk> and click "Delete branch"?
<fullermd> Think so, yeah.  Been a little while since I did it.
<calher> Branch deleted.  In local bzr dir, pushing to lp:~csh-a/calher-configs/trunk
<calher> Jeez, this takes a while.
<calher> k$ bzr push lp:~csh-a/calher-configs/trunk
<calher> Created new branch.
<calher> But it doesn't show up on the web view.
<calher> its up now
<calher> thanks fullermd!!
#bzr 2016-02-04
<calher> I see milestones on Launchpad but it doesn't have docs on what they are.
<vila> calher: https://help.launchpad.net/Projects/SeriesMilestonesReleases
<calher> I couldn't do launchpad-login -- https://transfer.sh/seKxU/bzr-launchpad-login-fail.txt
#bzr 2016-02-05
<calher> I did `bzr remove foo~' and it said it removed foo~ but kept a copy foo~.1
<calher> removed COPYING~.~1~ (but kept a copy: COPYING~.~1~.~1~)
<calher> Do people here actually prefer Bazaar?
 * fullermd_ would assume   :)
<calher> fullermd: Cool!  I know it's not too popular and people make fun of it, but I like Bazaar for my personal revisioning.
<fullermd> In a world that contains VSS, I can hardly imagine making fun of bzr...
<calher> fullermd: VSS?
<fullermd> Oh, my.  If you don't already know, don't try to find out.
<fullermd> You'll never sleep again.
<calher> => bzr sucks
 * Peng gasps
<fullermd> bzr: ERROR: unknown command "sucks"
<calher> That is, if I must be scared to learn what "VSS" is.
<fullermd> There are many things in the world any sensible person should be scared of   :p
<calher> ohh visual anything is bad
<calher> i think judging bzr by vss is a low standard tho
<fullermd> There're a lot of low standards available in present VCSen, to say nothing of historical   :p
<fullermd> You can be _so_ much more pathetic than anything about bzr, and still be in like the top 10%...
<quicksilver> I have a conflict in code which the author has 'tidied'
<quicksilver> (indentation changes)
<quicksilver> that is, there is a real honest conflict, but the extent of it is considerably confused by purely formatting changes
<quicksilver> are there any clever tricks?
<quicksilver> I tried formatting the two branches identically and committing that before the merge
<quicksilver> whilst that makes the diff look simpler (good) it makes the merge conflict worse :(
<fmccann> Hey bzr folks. Iâve been working on packaging some bzr plugins as Homebrew formulas to make installation on OS X much easier. Iâve got bzrtools, qbzr, and bzr-explorer working pretty well. I'm trying to get bzr-bisect, bzr-difftools, and bzr-extmerge set up, but they have no release tarballs in launchpad. Would it be possible to have an official tarball made for these projects? I can't pull direclty from version control in a Homebrew for
<fmccann> and we'd need to have a release from the authoritative source.
<beuno> vila, ^
<beuno> fmccann, vila's not around, but he might be able to do that
<vila> fmccann: hello there !
<fmccann> Howdy!
<vila> fmccann: Please to meet you ;) What osx version are you using ?
<fmccann> Iâm on OS X 10.11.13
<fmccann> But I can make the Homebrew formula make easy installs for most any recent versions of OS X
<vila> fmccann: I have not the fanciest idea about Homebrew ;-) Have you looked at the lp:bzr-mac-installers project ?
<vila> https://launchpad.net/bzr-mac-installers
<fmccann> I havenât looked at that - I assume thatâs what creates the dmg packaged installer?
<vila> yes, is that obsolete for 10.11 ?
<fmccann> I think the website says the last build was for 10.7 or so
<fmccann> Iâm trying to get packages into OS Xâs most popular package manager - I think this is how people are keeping bzr up to date on OS X these days
<vila> yes, so if you can build one for 10.11 with qbzr only that would already be a huge step forward
<fmccann> Iâm more than happy to throw some time at that as well
<fmccann> either way, would it be possible for bzr-bisect, bzr-difftools, and bzr-extmerge to have a formal release tarball?
<vila> If you have a way to install bzr on osx 10.11, there is a 2.7.0 release in the works
<vila> certainly
<fmccann> Is that on the horizon? Iâm planning on updating http://bzrinit.com when thatâs out
 * vila blinks
 * vila reads
 * vila blinks again
<beuno> fmccann, that is a great site, I hadn't heard of before!
<vila> fmccann: are you subscribed to  the (beuno, stop stealing my words ;-) mailing list ?
<fmccann> I am
<fmccann> I did announce the site back in 2011 I think
<beuno> vila, type faster!
<fmccann> and while I know a bunch of languages, I havenât bit the bullet and learned python yet, but at some point Iâll get past packages and documentation and seriosuly break trunk one day :D
<vila> fmccann: it should be referenced on the bzr site, sorry about that oversight :-/
<vila> fmccann: care to throw a MP at it ?
<fmccann> whatâs the lp url for the site?
<vila> https://launchpad.net/bzr-website
<fmccann> No problem. Iâll get a MP in there
<vila> \o/
<vila> fmccann: back to the ML. Would you mind replying to the freeze announcement message describing your status/progress/needs on 10.11 ?
<fmccann> Sure
<fmccann> Just for future reference, is the mailing list or the IRC channel the preferred way of harrasing people? :D
<vila> Be careful what you wish for :)
<vila> You just summoned the Daemon of The Channel ;)
<vila> fmccann: whatever works for you, IRC is higly dependent of time zones
<fmccann> ok. And let me appologize in advance if I get any of the launchpad ettiquite or process wrong. I mean well ;)
<vila> fmccann: and back to the tarballs. I could create one for bzr-bisect but for bzr-difftools and bzr-extmerge, only the maintainers can
<fmccann> ok
<fmccann> Is the mailing list the best way to reach out to them? Or filing a bug against the project?
<vila> fmccann: but even that is not really needed, if you say: this is version revno X 'bzr export' gives you a 100% reproducible tarball
<fmccann> So the issue here really is the homebrew guys. They donât have a mechanism for pulling from VCS oddly enough. They need a staged tarball from the owner of the project. Iâm asking them if thereâs a way around this, because I donât see a problem with pulling from bzr directly
<vila> fmccann: Ideally well defined bugs (scoped) are the best to track progress and organize people around tasks
<vila> fmccann: I think we can arrange that as part of the bzr release and provide tarballs from https://launchpad.net/bzr/+milestone/2.7.0
<vila> fmccann: i.e. where we provide installers
<fmccann> great
<vila> fmccann: do you have a way to test those installations /before/ we provide the tarballs there though ?
<vila> fmccann: never mind, we can iterate until the release is announced
<fmccann> ok
<fmccann> for now I made my own tarbal and built packages
<fmccann> which works, but itâs not good enough to go into the global package repository
<fmccann> The last issue Iâm working through is getting the python path playing ball on OS X for pyqt and dulwich (working on bzr-git)
<fmccann> but thatâs all OS X and homebrew specific, not the bzr code
<vila> oh, that's good enough to test the tarballs :)
<vila> fmccann: are you using lp:bzr or lp:bzr/2.7 ?
<fmccann> RIght now Iâm sticking with 2.6 until 2.7 is baked
<vila> fmccann: 2.7.0 won't change anymore
<fmccann> so 2.7 is go? I can get the packge for OS X updated and work on the OS X installer once I make sesne of that
<vila> if commits have to be done on lp:bzr/2.7 , you will need them
<fmccann> is 2.7 officially the stable release now?
<vila> fmccann: yes, the freeze announcement is the 'go' for packagers on the formal announcement is planned for 2016-02-12 iirc
<fmccann> :D
<vila> fmccann: it *will* be official with whatever installers are available
<fmccann> Well, Iâm glad I popped in today. Iâll get it working on OS X asap
<vila> fmccann: it would probably sound a bit abusive to call it a rolling release... But the idea is that 2.7.0 is only a new label on the most tested version of bzr since that's what is currently distributed :-}
<vila> so we release what has been tested and we don't touch anything ;)
<fmccann> Hey, thatâs just software these days. At a minimum bumping the version will keep people from telling me no one is working on this.
<vila> fmccann:  you get the idea ;-D
#bzr 2017-01-31
<brkban> hello hello
<brkban> Anyone availible?
#bzr 2017-02-02
<acdha_> Am I correct in assuming that bazaar.launchpad.net does not support HTTPS for checkouts? I was trying to deal with a buggy proxy which breaks HTTP ranged requests and noticed that `bzr branch https://launchpad.netâ¦` still fetches the actual pack files over unencrypted HTTP
#bzr 2017-02-03
<Koterpillar> I have bzr affected by this bug: https://bugs.launchpad.net/bzr/+bug/1644003 how do I clone master bzr without bzr?
<ubot5> Ubuntu bug 1644003 in Bazaar ""first argument must be string or compiled pattern" with python 2.7.12-7" [High,Fix released]
#bzr 2018-02-01
<gioveW31POR> âââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ssysgy: Walex Peng_ vila âââââââââââ
<gioveW31POR> ââââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  djlvp: fifr verterok vila âââââââââââââ
<gioveW31POR> âââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  vrhpw: elmo catern jam ââââââââââââ
<gioveW31POR> ââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  sthzapqvjk: vila jam fifr[m] ââââââââââ
<gioveW31POR> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  nrnkqxdu: fullermd Keltia anthonyf ââââââââââââââââââ
<gioveW31POR> âââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  valfsfdr: alexlist pjdc Peng ââââââââââââââââ
<gioveW31POR> ââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  emzryjqbaj: gour CHYC elmo âââââââââââââââââ
<gioveW31POR> âââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  qfrtvre: m1sc ubuntulog quicksilver âââââââââââ
<gioveW31POR> ââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  gwjjmbc: irsol LeoNerd jam âââââââââââââââââ
<gioveW31POR> âââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  xslmmxm: fifr CHYC Peng ââââââââââââââ
<gioveW31POR> âââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  alvlphyfpz: djinni` LeoNerd nicoulaj âââââââââââââââ
<gioveW31POR> ââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  padbnfrjdx: quicksilver fullermd elmo ââââââââââââ
<gioveW31POR> âââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  aetojofq: vila ubuntulog nicoulaj âââââââââââââ
<gioveW31POR> âââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ldrdem: catern james_w jelmer ââââââââââ
<gioveW31POR> âââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  cafzbjqrl: verterok Walex Peng ââââââââââââââ
<gioveW31POR> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  tafummrr: djinni` catern ubuntulog âââââââââââââââââ
<gioveW31POR> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  fdumrs: jam Peng_ gour ââââââââââââââââââ
<gioveW31POR> ââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  zuiqwarsbg: catern quicksilver jam âââââââââââ
<gioveW31POR> ââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  xvxxgqjlv: quicksilver superfly charles âââââââââââââââââ
<gioveW31POR> ââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ehxatfkw: Walex ggherdov ajmitch âââââââââââ
<gioveW31POR> ââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  mfxggp: pjdc ggherdov charles âââââââââââââââ
<gioveW31POR> ââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  zxkhbtggh: gour ajmitch ggherdov ââââââââââââ
<gioveW31POR> âââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  njeeo: thomi ubot5 LeoNerd âââââââââââââââ
<gioveW31POR> âââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  stkfgfos: fullermd ubot5 nicoulaj ââââââââââââ
#bzr 2018-02-02
<jelmer> Walex: what do you mean with binary files exactly?
<jelmer> large files?
<jelmer> Walex: speed often depends a lot on the exact situation in which you're using a tool, I don't think it's necessarily correct to say that Bazaar is fast and Mercurial is slow :)
<jelmer> Walex: Bazaar also supports HTTP (and technically, SFTP and FTP) as a transport, in addition to native and SSH
<jelmer> (and git also has 'native')
<jelmer> Walex: git only tracks basic file metadata (e.g. normalized mode), not other metadata (e.g. file owner/group, ACLs, extended attributes, etc)
<jelmer> Walex: note that the git format support hasn't been merged into breezy yet, it's currently still in a plugin (brz-git) but may be merged at some point
<Walex> ahhh sorry to miss this
<Walex> jelmer: many thanks for the details.
<Walex> jelmer: as to speed I think that mercurials's "lots of small files" repo is a really bad idea *for system administrators*. Developers tend to have desktops/laptos with SSDs, monstrous amounts of RAM, and only a few repos, so they could not care less.
#bzr 2020-01-30
<LeoNerd> How is breezy (brz) looking these days? Is there any reason I shouldn't just use it as a bzr client where previously I'd run bzr? i.e. just a different spelling...
<LeoNerd> (that muscle memory though..)
<Eighth_Doctor> LeoNerd: since Fedora 31, breezy provides bzr, so if you use Fedora, you don't have to change anything :)
<Eighth_Doctor> err, Fedora 32
<LeoNerd> debian here
<Eighth_Doctor> (which isn't out yet, but of course, since I live on the edge, I forgot :P )
<LeoNerd> My `bzr` is still the original bazaar
<Eighth_Doctor> LeoNerd: you'll likely get this once bzr is ripped out of Debian with py2 removal going on now
<LeoNerd> Righty
<jelmer> LeoNerd: no reason not to use Breezy, though I'm possibly biased :)
<jelmer> "bzr" in Debian unstable and testing is already Breezy
<LeoNerd> Oh.. righty
<LeoNerd> Ah that does clear up a confusion I had earlier, then
<LeoNerd> I had a python2 program that wanted to import bzrlib and it didn't find it, and I was confused why bzr kept working
<LeoNerd> Is `bzr` itself now just a trampoline for brz then?
<jelmer> LeoNerd: yeah
<jelmer> mostly to make the migration as seamless as possible
<jelmer> obviously the API has changed, so not much we can do in that sense :-/
<LeoNerd> Sure; I mostly just interact with commandline which honestly I hadn't noticed any difference on
<fullermd> Last I looked there was a meaningful slowdown (worse with py3).  But I think my 'b' has been brz for a while too...
<LeoNerd> Eh; any of my projects are quite small and usually the network roundtrip is the slowest part of most b{zr,rz} operations for me anyhow,.. I don't really notice the speed of the tooling overall
<fullermd> Yep, it is (though forced to py2)
<fullermd> The startup time is way higher.
<LeoNerd> Ah h,,
<LeoNerd> *hmm
<LeoNerd> I've often wondered why more programs don't do a FastCGI-style persistent runner + lightweight wrapper setup
<LeoNerd> make the wrapper a tiny C program that talks over a UNIX socket in $HOME
<fullermd> I think that was the sorta idea behind 'bzr shell' or the like, once upon a time.
<fullermd> 'd have to build it like that from the start though, or it'd be mighty hard to retrofit.  Apart from all the fiddle details about making it not blow up in fascinating ways in edge cases...
<LeoNerd> I wouldn't like that. For me the whole point of having oneshot commandline tools is they sit right there in my normal shell with everything else
<LeoNerd> OH. yeah.. Well for a start the moment you `cd` to somewhere else you might be in a different place
<fullermd> Pshaw.  It's that sorta thinking that leads you to not use mh   ;p
<LeoNerd> mh ?
<fullermd> (well, use, I meant)
<fullermd> The mail client, which is all individual shell commands.
<LeoNerd> Ooh.. that one
<jelmer> fullermd: there was a slow down because Breezy supported loading plugins from python endpoints for a while
<jelmer> that triggered a lot of extra imports on some systems due to the way endpoints wokr
