#bzr 2008-02-25
<jelmer> yep
<lifeless> jelmer: can you document what you need from the hook? I can likely do the bzr side trivially
<jelmer> https://bugs.launchpad.net/bzr/+bug/186422
<ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged]
<lifeless> is in-python sufficient
<jelmer> the summary should probably be changed to "Add a start-commit hook"
<jelmer> lifeless: yes
<lifeless> k
<lucasvo> hi
<lucasvo> I'm having issues with bzr. It doesn't want to work if locales isn't set correctly...
<lucasvo> see: http://paste.ubuntu-nl.org/57277/
<lifeless> thats correct; you can set LANG=C etc if you have really broken locales on your machine
<lifeless> but to get the correct i18n filename we need locale information
<jelmer> shouldn't it be "locale en_US.UTF-8" rather than "locale enUS.UTF-8" ?
<lucasvo> lifeless: I am using gnome terminal with an ssh session
<lucasvo> if I set  encoding to western in gnome terminal it works
<lucasvo> I usually have it on utf-8
<lifeless> jelmer: yeah, I think so
<lifeless> lucasvo: as long as its set to a valid locale bzr will work fine
<lucasvo> so that is not a bug.
<lifeless> lucasvo: we have to recreate the files you commit, with their names, on different operating systems
<lifeless> lucasvo: some (mac os X) require unicode paths.
<lifeless> lucasvo: so we have to know the actual unicode path of each file we read from disk
<lucasvo> ok
<LaserJock> would it be possible to get bzr-svn in the bzr LP PPA?
<lifeless> lucasvo: and to do that we need to know if you are using 8859-{1,3,...} or utf8 or utf16 or utf7 or whatever
<jelmer> LaserJock: it's already there
<lifeless> lucasvo: so yes, it is a _requirement_ that your locale be set up accurately for bzr to work. if its complaining, you have a bug in your locale setup.
<LaserJock> jelmer: you sure? I don't have it here
<jelmer> a traceback shouldn't be necessary for this error though
<LaserJock> jelmer: ah, I see the problem, there is a version in -backports that overrides the one in the PPA
<jelmer> LaserJock: Yes, it's only in feistry, gutsy and hardy though
<lifeless> jelmer: its being thrown from python's core
<lifeless> jelmer: we could catch and pretty it up I guess
<LaserJock> jelmer: gutsy-packports has 0.4.7-1~gutsy1 and the PPA has 0.4.6-1~bazaar1~gutsy1
<lucasvo> ok, well, I gotta move over to the ubuntu channel and try my luck there. Thanks for the help guys.
<LaserJock> dang, even if you put in 0.4.7 it'd be a lower version than -backports :/
<jelmer> LaserJock: what exactly is so problematic about that? in the end, you have the latest version
<jelmer> lifeless: yeah, that would make sen
<jelmer> se
<LaserJock> umm, because I either can't upgrade bzr or I have to remove bzr-svn
<LaserJock> not sure why bzr-svn has such a tight dependency, but I'm assuming the maintainer knew what they were doing
<jelmer> LaserJock: bzr-svn gets very easily broken by bzr API changes
<LaserJock> fun
<LaserJock> so right now I'm not updating bzr/bzr-tools so I don't remove bzr-svn
<jelmer> LaserJock: ah, that bit is unrelated to the packaging
<jelmer> I simply haven't released bzr-svn 0.4.8 compatible with bzr 1.2 yet
<lifeless> tsk tsk
<lifeless> :)
<LaserJock> ah
 * LaserJock tries to resist a "that's why git is nice" comment ;-)
<LaserJock> but instead I'll wait patiently
<LaserJock> although, I'm using bzr-svn because it seems a lot better than git-svn
<LaserJock> so I should just hold my tongue
<jelmer> Sorry for not being quicker with this
<jelmer> Although I don't see why it would be an immediate problem
<jelmer> LaserJock: git-svn doesn't have the same level of integration that bzr-svn has so it doesn't use the same range of the API
<jelmer> LaserJock: if we would make the dependencies of bzr-svn less tight bzr-svn would probably break every other upgrade of bzr
<LaserJock> jelmer: right, I figured it must be something similar
<LaserJock> I just wondered if it was a known thing as I've been unable to upgrade bzr for something like a week or so
<LaserJock> but it seems that really gutsy-backports is more to blame
<jelmer> LaserJock: why?
<LaserJock> because -backports has 0.4.7
<LaserJock> I was thinking that the bzr PPA didn't have bzr-svn in it
<jelmer> yes, but what's problematic about backports having 0.4.7?
<lifeless> is 0.4.7 released ?
<jelmer> yes
<jelmer> 0.4.7 is compatible with bzr 1.1
<lifeless> LaserJock: actually I think aptitude is to blame; if bzr's ppa has a matching bzr-svn, aptitude should be able to resolve to install that over backports; unless you've got pinning set
<jelmer> lifeless: ppa doesn't have a more recent version than backports
<lifeless> jelmer: I know that
<LaserJock> jelmer: it's just that it means I'm getting bzr from bzr PPA but not bzr-svn
<lifeless> jelmer: I didn't say more recent; I said matching.
<jelmer> lifeless: There is no matching bzr-svn for the latest bzr in PPA
<lifeless> jelmer: there we go :)
<lifeless> LaserJock: so its really just that bzr-svn has not recently this week yet
<jelmer> lifeless: Right, but I fail to see how LaserJock is blaming that on backports rather than on me :-)
<LaserJock> well, I'm just saying it's nice to get the whole set from the same repo
<LaserJock> rather than bits from one and bits from another
<LaserJock> but of course, in this case, I guess I'd be in the same situation even if I didn't have -backports
<jelmer> the version of bzr-svn in backports is newer
<jelmer> ~bzr comes after ~backports
<jelmer> hmm, no that's not right..
 * jelmer gets some sleep before he says more stupid things
<LaserJock> -backports uses ~gutsy
<LaserJock> wasn't stupid
<LaserJock> versioning sucks ;-)
 * lifeless waits for 11K unit tests.
<lifeless> poolie: if you are touching logging again; I would like to remove logging to disk entirely for tests. Its pointless to write a log when we can introspect it in python; less disk io is good.
<ubotu> New bug: #195282 in bzr-loom "new revision spec needed - below:" [High,Triaged] https://launchpad.net/bugs/195282
<lifeless> bob2: ping
<bob2> hi
<lifeless> hows your nicer-error patch coming? I just got forcibly reminded of it :)
<poolie> lifeless: i'm not at present but will try to remember that
<poolie> lifeless: quick call sometime
 * igc food
<lifeless> poolie: sure; now ?
<poolie> sure
<lifeless> please find my house phone for me
<poolie> lol
<lifeless> damn charge
<fullermd> Holy crud.
<fullermd> I just watched that talk Bryan Cantrill did at Google about dtrace.  That's insane how deep it gets its fingers into python.
<keir> so, is loom headed for core? seems like incredibly useful functionality, and is something the other systems don't do as well.
<lifeless> keir: well, I think it will get smoothly integrated; I don't know that it belongs in core
<lifeless> bob2: hows your nicer-error patch coming? I just got forcibly reminded of it :)
<poolie> thumper: hi?
<bob2> lifeless: updating tests.blackbox atm
<lifeless> bob2: cool
<bob2> lifeless: ooi, is the arg ordering of assertEqual('literal', var) deliberate?
<lifeless> bob2: our convention is expected, actual
<lifeless> so 'literal' is what we want.
<bob2> lifeless: right
<thumper> poolie: hi
<lifeless> bbiab, late lunch time
<lifeless> spiv: ping
<lifeless> spiv: is urlutils.escape(user_supplied_url) the right way to get a ascii url ?
<jml> did 1.2 change things about when Branches let go of http connections?
<lifeless> it shouldn't have; why ?
<lifeless> you may be seeing pycurl vs non pycurl ?
<jml> maybe
<jml> there's no pycurl in the stack
<lifeless> what are you seeing happen ?
<jml> lifeless: the test suite is complaining about how there are sockets in the garbage after certain of our tests that do stuff with http
<lifeless> interesting
<lifeless> you may have found a bug I guess?
<jml> specifically, a socket._fileobject
<lifeless> I'd need to look closely in the log; you can do that:O - look for stuff from vila
<jml> it's possible that we're holding on to a reference too long or that the gc is doing something stupid
<lifeless> try a gc collect?
<jml> or both
<jml> my money's on both
<jml> s/the gc/the calls to the gc/
<lifeless> one thing that is likely is that persistent connections are better
<lifeless> that is, that we won't drop them after every call, I'm sure vila was working on that
<lifeless> yay:
<lifeless>  du -sh ../thallow/
<lifeless> 72K     ../thallow/
<lifeless> thats a shallow branch
<lifeless> wow slow though
<lifeless> 1m24 to create over sftp
 * igc dinner
<lifeless> ok, bzr push is whackily slow ; that or too much data.
<lifeless> ah link fuggage
<ubotu> New bug: #195360 in bzr "bzrtools 1.2 in feisty ppa: broken depends on bzr" [Undecided,New] https://launchpad.net/bugs/195360
<lifeless> muhahaha it works: ~/source/baz/shallow-branch/bzr log -r -1 http://people.ubuntu.com/~robertc/test-shallow/3
<lifeless> using http://people.ubuntu.com/~robertc/baz2.0/shallow-branch
 * bob2 branches
<bob2> oh that's what all the stackable thing was about
<jrydberg_> hi guys
<lifeless> bob2: extremely small branches
<lifeless> http://people.ubuntu.com/~robertc/test-shallow/4 has a commit in it
<lifeless> total repo size - 56K
<lifeless>  du -sh public_html/test-shallow/4/.bzr/repository
<lifeless> 56K     public_html/test-shallow/4/.bzr/repository
<lifeless> bob2: ^
<bob2> that's quite cool
<Prodoc> Good mornin'
<Prodoc> I'm trying to install the Bazaar Eclipse plugin using the following instructions: http://bazaar-vcs.org/BzrEclipse/Installation
<Prodoc> After selecting the latest version it will try to download the plugin but I get an error that an exception occurred downloading the .jar file
<bob2> lifeless: is that bluesky or 1.3 material?
<Prodoc> it's only after a couple of retry's that it appears to work
<Prodoc> is this a known issue?
<lifeless> bob2: 1.3 I hope
<mrflip> Hello, I am just moving over to bzr.  Here is my question.  I'm working on a website, and the project is the main dir site/ with subdirectories srcassets/ (original copies of graphics, etc), meta/ (design notes), utils/ (tools), web/ (the actual site).
<mrflip> When I deploy, I want to only push site/web/ to the server, which was easy with svn
<mrflip> how do I do this with bzr?
<bob2> bzr split would let you split that dir into it's own branch
<bob2> or you could just not import the others into bzr
<bob2> but bzr doesn't generally work like svn, where each dir is a nested checkout
<mrflip> (reading about bzr split now)...  I definitely need all of those dirs versioned... and I need to have (somehow or another) site/* on my dev machine and only web/ on the server.
<mrflip> so I think I have to move web/ into its own repos, which I can live with... it's tiny compared to srcassets, which I can't afford to pull each time I deploy.
<mrflip> Thanks for the help bob2
<bob2> doesn't have to be it's own repository, just branch
<bob2> well, depending on how you do it I guess
<ubotu> New bug: #195397 in bzr "Bazaar does not follow the Freedesktop XDG Base Directory Specification" [Undecided,New] https://launchpad.net/bugs/195397
<adwi2> jelmer: Could the ability of bzr to use a SVN repository be used to create a branch that used a SVN repository that one could push back into another SVN repository with bzr-svn?
<jelmer> awilkins: Yes
<jelmer> it wouldn't create a copy of the original svn branch in the other svn repository though
<jelmer> at least, it won't look like a copy to svn
<jelmer> it will look like one to bzr
<awilkins> jelmer: What I essentially want is what SVK does but using bzr, I suppose
<awilkins> I have an Eclipse ticket plugin that syncs to SVN
<awilkins> But I'm rapidly leaning toward BZR for the other version control aspects of this project because the branch / merge requirements are rigourous and I'm probably going to end up re-inventing merge tracking if I stick to SVN
<awilkins> Alas, the ticket plugin is closed-source (what a dumbass I was to recommend that one...)_
<awilkins> And doesn't use the geenric Eclipse team sync, as far as I can tell.
<awilkins> Ah, I shall just have to experiment.
<awilkins> I shall be using BZR for dev and testing just because it's so much faster than SVN :-)
<awilkins> It'll save me more time tha it'll take to re-roll things in SVN if I have to.
<jelmer> re
<jelmer> awilkins: yes, bzr-svn is usable in a svk-like style
<jelmer> that's what it was originally designed for
<xif> is branching and merging with Bazaar less of a headache than it is with Subversion?
<edreamleo> Hello All, this is Edward Ream from the Leo editor
<Peng> xif: Yes.
<Peng> xif: Any modern VCS, including bzr, tracks which revisions have already been merged.
<Peng> xif: Of course, that makes cherrypicking a pain in most of them...
<edreamleo> Is this the place to ask total newbie questions?
<jdong> edreamleo: any bzr related question :)
<Peng> edreamleo: Sure.
<jdong> or any question you'd want a bzr related answer to :D
<edreamleo> ;-)
<edreamleo> First, let me say I'm excited about moving Leo to bzr.
<edreamleo> It will enable much closer cooperation between Leo and IPython.
<edreamleo> I have been able to get bzr working on XP...
<edreamleo> But am having trouble connecting on Linux
<xif> Peng: if I plan to do lots of branching and merging, would you recommend Bazaar or anything else?
<edreamleo> I suspect the problem is easily fixed, but I have no idea how to fix it.
<jdong> xif: I'd definitely recommend some distributed VCS with a 3-way merge algorithm. bzr's defnitely nice for it but it's not the only one
<jdong> edreamleo: can you describe more what kind of trouble you're having when connecting?
<edreamleo> Sure.
<Peng> xif: Sure, I'd recommend bzr or anything else that's not cvs or svn. :P
<edreamleo> I have pull defined as a bzr alias. One moment while I look it up...
<xif> jdong: yeah, I'm still contemplating whether I want hg, darcs, or bzr
<jdong> xif: well I think between those 3, the answer all of us in #bzr will give you is obvious ;-)
<xif> from what I've seen, hg has better performance, bzr has more features
<jdong> xif: I don't think that's entirely true anymore
<xif> ("seen" = "read in online reviews" :-)
<jdong> xif: recent versions of bzr come quite close in performance, storage size, etc
<jdong> xif: it is true that older versions of bzr have horrendous performance compared to hg
<xif> right, before you rewrote some of the Python modules in Pyrex
<xif> yeah, I think I'll check bzr out first
<Peng> And made other improvements.
<xif> Peng: such as?
<jdong> xif: and changed on-disk storage format, etc
<xif> oh, right.
<Peng> xif: General improvement of the code?
<xif> now your storage format is git-like I hear.
<Peng> Sorta, yeah.
<jdong> xif: there's far too many performance tweaks for us to list one by one short of reproducing the changelogs
<Peng> For me, it's really a toss-up between bzr and hg, but I haven't used anything else (other than svn).
<xif> not sure how darcs fits in the comparison, doesn't look like it can compete with hg or bzr on either performance or features.
<jdong> yeah, my unbiased toss-up would be between bzr, hg, and git
<Peng> I haven't looked into git much.
<xif> Peng: aren't there features you miss on hg vs. bzr or vice-versa?
<edreamleo> Ooops.  pull is not an alias
<Peng> xif: Yeah.
<jdong> xif: bzr's vast array of plugins... seems like there's more of them than for hg
<xif> I prefer hg and bzr (or even darcs) because Python and Haskell are nice languages.
<jdong> xif: also, hg is horrible without its smart server IMO
<jdong> xif: which is a problem if you don't have the access to install hg on the remote system
<Peng> Indeed.
<jdong> bzr's non-smart-server performance is quite good with packs
<xif> jdong: so if I want to stay lightweight (e.g. using the VCS to manage my own project) bzr might be a better choice?
<Peng> And even if the performance was poorer, at least it supports dumb servers fully.
<edreamleo> Ok, now I remember, I did a bzr co, not a bzr pull
<Peng> (Well, it is poor*er*, just not that much worse.)
<edreamleo> co *is* an alias
<Peng> If I was smarter, I'd work on SFTP support for hg...
<jdong> xif: I'd believe so.
<jdong> Peng: last time I tried dumb HTTP, it didn't work well either
<xif> OK, thanks.
<jdong> Peng: and the response I got upstream was "well it's outdated, set up a CGI"
<Peng> jdong: Heh.
<Peng> jdong: I didn't know it was outdated.
<Peng> jdong: I don't know how good it is now.
<Peng> jdong: I've always had the impression that it doesn't get quite enough love, but I don't know whether it's still good enough.
<jdong> Peng: well apparently thy are considering oldhttp to be obsolete
<edreamleo> co is defined as co=checkout bzr+ssh://edreamleo@bazaar.launchpad/~edreamleo/leo-editor/main
<edreamleo> now when I do a bzr co I get a Python traceback
<LeoNerd> Who keeps highlighting me? :P
<jdong> Peng: but I was surprised that they do not support SFTP
<Peng> edreamleo: "co" is a builtin alias.
<edreamleo> Oh!
<Peng> edreamleo: (for "checkout")
<Peng> jdong: I asked once, and mpm mentioned that he wouldn't want to add a dependency on Paramiko or whatever.
<edreamleo> Right, that's what I was trying to do :-)
<edreamleo> Trust a newbie to find the ways to crash a program.
<Peng> :)
<edreamleo> Ok, let me pick another name for co and see what happens...
<Peng> edreamleo: Are you using bzr 1.2? If not, upgrade; if so, file a bug.
<Peng> edreamleo: You shouldn't need to co the same branch so often that you need an alias for it...
<jdong> edreamleo: also, why is the alias necessary? Do you really checkout that branch enough times that you don't want to type it out?
<jdong> Peng: we're trampling over each other :D
<edreamleo> I'm using bzr 0.90.0
<jdong> edreamleo: I highly recommend upgrading to the latest
<edreamleo> Iirc I used apt-get (or maybe the synaptic package manage) to get the latest version
<jdong> edreamleo: what distribution?
<edreamleo> Ubuntu, Gutsy Gibbon
<jdong> edreamleo: you can either (1) enable backports, or (2) use the bzr PPA
<jdong> although I'm the maintainer of backports, I recommend #2
<edreamleo> What's the bzr PPA?
<jdong> I've got hundreds of requests for updates and I can't keep backports as up to date as fast as the bzr PPA
<Peng> edreamleo: Bzr's official apt repo thingamabob. https://launchpad.net/~bzr/+archive
<jdong> edreamleo: it's an APT repository maintained by the bzr developers
<Peng> (Though they do have a habit of screwing up bzrtools's dependencies... :P )
<jdong> edreamleo: it contains the latest bzr packages, plus minus a few days ;-)
<jdong> Peng: hehe well I'm guilty of doing the same
<Peng> I'm hungry.
<jdong> backports is currently on bzr 1.1, though I do intend on updating to bzr 1.2 once Hardy's entire stack is ready
<jdong> but backports gives you other cool new packages too ;-)
<edreamleo> Ok, I see bzr-1.2.-1~bazaar2~gutsy1 at the url you gave.
<edreamleo> Are there installation instructions?
<jdong> edreamleo: the page should have such instructions
<jdong> edreamleo: pick Gutsy from the dropdown....
<jdong> edreamleo: add the "deb" line to Software Sources Manager in system->admin
<jdong> the deb-src line is optional
<edreamleo> I did system->admin->software soucrces...
<edreamleo> Now I see a dialog, with 5 tabs...
<edreamleo> What's the "deb" line?
<jdong> elmo: click Third Party Software, then Add
<jdong> grr wrong person
<jdong> he doesn't need to know how to add sources lines... :)
<edreamleo> Heh, heh,
<jdong> in the dialog that pops up, type deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
<edreamleo> djong: ok, that seemed to work.
<edreamleo> Do I do an apt-get now?  If so, what would I do exactly?
<edreamleo> Never mind, the latest version now shows up in the package manager.  Doing an update now.
<jdong> edreamleo: you can pop up update manager or synaptic, check and apply for new updates
<edreamleo> Ok, we have progress...
<edreamleo> Now we have bzr 1.2.0
<edreamleo> And now bzr co (still with the confusing co alias) doesn't crash, it says...
<jdong> edreamleo: run bzr reconcile and bzr upgrade on your existing branches to bring them to the new faster packs format
<edreamleo> ssh: connect to host bazaar.launchpad prt 22: connection refused
<edreamleo> Ok.  bzr reconcile and bzr upgrade made what seem like happy sounds.
<jdong> edreamleo: bazaar.launchpad.net
<jdong> unless you're one of those lucky people on the .net domain :D
<edreamle1> Drat: something weird happened to gaim.
<edreamle1> gdong: I'll check the url and change the co alias to something else...
<jdong> edreamleo: yeah the URL is the only problem I see
<Peng> Also, again, why are you checking out the same thing so often that you need an alias?
<dato> Peng: bzr provides the alias
<edreamle1> Peng: my memory isn't the best, so I like to leave bread crumbs around wherever possible.
<edreamle1> Success: the bad url was the problem
<jdong> edreamleo: you'd probably want to alias your branch location as a branch
<jdong> rather than alias the entire co command to one branch
<edreamle1> Btw, bzr co worked just fine, even with co as an alias
<jdong> edreamleo: after the initial checkout, you never have to type the branch URL again
<jdong> just "bzr up, bzr commit, bzr log" all work inside the branch
<jdong> so I don't see the point of making the co=checkout branch alias.
<edreamle1> jdong: you must be right :-)
<edreamle1> jdong: but what if I wanted to check out another sandbox?  Wouldn't I need to know the url?
<Peng> Is it possbile to checkout or branch a checkout?
<jdong> Peng: yes
<jdong> edreamle1: indeed, but you can branch from your existing checkout
<jdong> edreamle1: or type "bzr info" inside the branch to figure out what URL it was from
<edreamle1> jdong: Thanks for these tips.
<edreamle1> Clearly, I don't understand bzr branches yet...
<edreamle1> Anyway, many thanks for your help.  I'm unstuck.
<Odd_Bloke> Does anyone know anything about http://article.gmane.org/gmane.emacs.devel/89117 ?
<Peng> Odd_Bloke: No. It's been confirmed as true, but there's still no information.
<Peng> Odd_Bloke: Ask Mark Shuttleworth or poolie?
 * Peng shrugs.
<Peng> Ok.
<Odd_Bloke> OK, it's the confirmation that I was looking for.
<Odd_Bloke> Peng: Thanks. :)
<Peng> The confirmation isn't very useful when I have no idea what it *means*.
<Peng> RMS is replacing poolie as lead developer? Mark Shuttleworth paid them $10,000 to get "GNU" stamped on bzr?
<Peng> Of course, I could do research and see what exactly it usually means, but I'm busy reading about Star Trek.
<abentley> Peng: It means nothing in terms of personnel.  It means that GNU will endorse bzr, use it for their own projects, and update Savannah to support it.
<Toksyuryel> awesome!
<Peng> Right. It's just marketing.
<Peng> I forgot.
<abentley> It does mean that there are certain rules we must follow.  I forget the details at the moment.
<Toksyuryel> yay bzr ^_^
<Peng> You said that earlier. :P
<Toksyuryel> What does it mean with regards to launchpad?
<abentley> Well, if you're gonna get snotty, I don't have to say anything...
<johnny> Toksyuryel, nothing afaics
<Odd_Bloke> The list of things that have to be complied with is at http://www.gnu.org/prep/maintain/
<Peng> I'm only being a tiny bit snotty.
<Peng> And that's non-sarcastic.
<Peng> I completely forgot that you explained it earlier.
<Peng> Odd_Bloke: Yikes, 100K of ASCII?
<diocles> Odd_Bloke: There's also the GNU Coding Standards, and maybe a few other documents.
<Toksyuryel> it's not really fair to call it "just marketing", I think that bzr being endorsed by GNU is a pretty damn big deal
 * Toksyuryel thinks that it shows just how good bzr is, that they would choose it over other things out there :) it also grants a lot of additional credibility to the project
<diocles> Peng: http://www.gnu.org/help/evaluation.html#whatmeans would seem to answer your questions, but I realise Star Trek is important.
<Toksyuryel> Stargate is better~ *hides*
<Peng> Toksyuryel: What about Firefly?
<johnny> they're all dumb :)
<abentley> I'm not aware of any direct effects on Launchpad, though it does turn Savannah into a Launchpad competitor.
<johnny> that should solve it..
<johnny> barely..
<johnny> a very very poor one
<Toksyuryel> I never watched firefly, I heard good things about it though
<Toksyuryel> abentley: my concern is more related to the issue of the fact it's not a free/open project (yet)
<Peng> Toksyuryel: Same here. I'm afraid that whenever I do finally watch it, it won't live up to my expectations thanks to the hype. :\
<johnny> Toksyuryel, has no effect on bzr
<Peng> diocles: Thanks. I have 550 tabs open!
<Toksyuryel> mmkay
<johnny> launchpad is the only reason i'm considering using bzr seriously
<johnny> which is upsetting, since it's not free
<Toksyuryel> there's a lot of great things about bzr completely unrelated to launchpad...
<johnny> like?
<diocles> johnny: What are you comparing bzr with?
 * Toksyuryel personally considers it to be the best vcs of them all, period ^_^
<Peng> The GNU documents mentions using an @gnu.org address for bugs, and hosting on gnu.org. What is bzr going to do?
<johnny> i mean above and beyond git,mtn,hg
<johnny> Peng, the docs mention that
<johnny> there's notice you put on there
<Toksyuryel> bzr is way way better than git and hg. not sure what mtn is but bzr is probably better than that too :)
<johnny> how so?
<johnny> how is it better than git or hg?
<johnny> other than being much easier to use than git :)
<Peng> Toksyuryel: Monotone.
<johnny> hg is not really in my consideration tho
<Toksyuryel> there are documents on the website that do a way better job explaining than I ever could
<Peng> Toksyuryel: Kinda inspired git and hg, but not very popular. Slow.
<johnny> i've read them Toksyuryel
<Toksyuryel> eww, ok, bzr is definitely better than that XD
<Peng> Toksyuryel: Gaim/Pidgin used it, last I checked.
<johnny> and i wasn't convinced
<Toksyuryel> well I was
<Peng> johnny: Why not hg?
<johnny> bzr has launchpad, hg doesn't bzr has the potential to be tested across 1000s of projects
 * Toksyuryel is even considering using it to version his entire system, but thinks he may need a bigger hard drive for that
<johnny> hg has a few, and moz..
<johnny> but bzr will always have the edge due to launchpad
<Peng> Toksyuryel: Don't do that.
<johnny> since it mirrors everything in bzr
<Peng> Toksyuryel: I do; it sucks.
<johnny> Toksyuryel, bzr doesn't handle privs
<johnny> at least not last i heard..
<Toksyuryel> ohh
<Toksyuryel> yeah that could be tricky...
<Peng> Oh, that's true.
<johnny> you need seperate sfotware
<diocles> johnny: The other advantage over git might be Windows support. But that never bothered me.
<james_w> johnny: there will hopefully be a plugin to handle that at some point.
<Peng> None of the popular VCSes handle more than the exec bit.
<johnny> yes
<Peng> I don't version my whole system, just my homedir.
<johnny> Pe is correct
<Peng> And I'm reducing that today.
<james_w> for now you can check out etckeeper, which there is a bzr plugin for.
<johnny> err Peng is correct
 * Toksyuryel has never considered windows support to be a feature, rather finds it to distract people from the features that matter
<johnny> i'm concerned about windows support
<johnny> but git is mostly used by the hardc0re
<johnny> and the speedsfreaks
<Peng> Toksyuryel: (Especially since Windows support is a rough spot in both bzr and hg; at least case-insensitive file system stuff. Cough.)
<diocles> I use git.
<Toksyuryel> don't the benchmarks say bzr is faster than git?
<johnny> no
<johnny> try mirring the kernel and proving it
<johnny> with full changes
<Toksyuryel> dependant on the size of the project of course; they are working on that part :)
<johnny> or moz for that matter
 * diocles tries to work out whether he's "hardc0re" or a "speedsfreak".
<johnny> Toksyuryel, i know what they are working on :)
<johnny> i really really like in mtn how revisions are not dependent on a branch
<johnny> a branch is just a cert on a revision
<Toksyuryel> Peng: I find windows support to be a waste of time and resources that could better be spent improving the software =/
<johnny> Toksyuryel, you're wrong
<johnny> more devs come because of windows
<johnny> and even more users come
<Toksyuryel> they should switch to a real OS =/
<johnny> and that is?
<johnny> does it run autocad? or photoshop? :)
<johnny> this is sad for me to have to say this :(
<johnny> but it's true
<Toksyuryel> that's not the fault of the OS
<johnny> sure, but the OS doesn't mean much if it can't run apps
<Toksyuryel> and photoshop is easily replaced besides
<johnny> no it isn't
<jdong> Toksyuryel: no it's not...
<johnny> google is spending alot of money on wine support now tho
<Toksyuryel> GIMP, inkscape, probably some other stuff out there too
<johnny> nope
<johnny> they are all weak
<jdong> Toksyuryel: you've got to be kidding
<Odd_Bloke> Guys, arguing about why people should switch from Windows in #bzr is kinda OT...
 * Toksyuryel stops then
<jdong> Toksyuryel: that's like saying gwbasic roughly replaces C
<jdong> but at any rate, if you don't care about Windows, then windows support is not something to look at in your VCS of choice :)
<johnny> i've used linux only on the desktop for 5 years now Toksyuryel .. and even i can't say those apps have proper replacements :)
<jdong> likewise. I've used Linux for a few years and developed on it for a few less than that
<jdong> I can say FOR ME I've found Linux replacements
<jdong> but I can't say for every application there is a Linux replacement
<diocles> Tut, tut, it's GNU/Linux. Don't you know bzr is a GNU project now?
<jdong> that's completely nonsense
<jdong> diocles: no it's not, I use a BSD userland ;-)
<Peng> Who needs Photoshop; I can write JPEG by hand. With a magnet, up hill in the snow all three ways.
<johnny> lol
<diocles> jdong: I bet you don't. :)
<jdong> diocles: how do you know? :)
<johnny> it is possible tho
<johnny> or the opposite ..
<diocles> jdong: Because Ubuntu doesn't have a BSD port.
<jdong> diocles: and that's where you start assuming :)
<jdong> but ANYWAY, still OT :)
<johnny> unless bzr won't run on that combination.. :)
<jdong> johnny: A few of us here have independently got bzr running on IronPython
<Toksyuryel> bzr ought to run on any POSIX-compliant system... I think
<jdong> Toksyuryel: more than that :)
 * jdong feels sorry for all the bzr devs who will be reading this scrollback
<johnny> jdong, but then the boycottnovell guys will come after you !
<johnny> lol
<abentley> johnny: Bzr handles only the execute bit, not other privs.
<johnny> abentley, i know :)
<abentley> Oh, I thought you didn't because of how you phrased it.
<johnny> supporting windows is difficult for sure :(
<Toksyuryel> hmmm... The requested URL /bzr.1.2/en/release-notes/NEWS.html was not found on this server.
<abentley> johnny: In most DVCses, branches link to revisions, and the revisions themselves are not tied to any particular branch.
<johnny> maybe it's not as exposed in bzr in the docs then
<johnny> i read over the user guide , and that other one
<james_w> Toksyuryel: there is a missing symlink, someone reported it to the list already, but it doesn't seem to have been added yet
<Toksyuryel> ok
<Vadi> I'm trying to 'push' a branch online, but I get an 'Not a branch:' error. Is there some specific setup I need to have on my local folder or something?
<Odd_Bloke> Vadi: What cmmand are you running?
<Vadi> "bzr push bzr+ssh://vperetokin@bazaar.launchpad.net/~vperetokin/vadi-mapper/main"
<Odd_Bloke> Vadi: That suggests that you're not in the branch when running the command.
<Vadi> Ahah. Now what exactly does that mean? I'm in a folder on my laptop, that I want to upload the contents of on the branch (new to this)
<Odd_Bloke> Vadi: OK, you'll need to use 'bzr init' to create an initially empty branch.
<Odd_Bloke> Then you'll want to use 'bzr add' to add all of the files in the directory to the branch.
<Odd_Bloke> s/branch/working tree/
<Odd_Bloke> Then you'll want to commit the changes in your working tree (i.e. everything) to a revision of the branch, using 'bzr commit -m "Initial import."'
<Odd_Bloke> The part in "s is the commit message, which will show up in the log of the branch.
<Vadi> Where do I specify the branch I want to commit to?
<Vadi> I got the bzr init'd and add'd
<Vadi> Ahah, okay. I think I got it.
<Vadi> I got a exceptions.AssertionError :(
<abentley> Vadi: please copy the traceback into a pastebin
<abentley> ubotu: paste
<ubotu> pastebin is a service to post multiple-lines texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
<Vadi> abentley - here you go: http://paste.ubuntu-nl.org/57363/
<Vadi> I might have screwed up my ssh key, I'm not entirely sure.
<abentley> I was just about to suggest doing sftp manually.
<abentley> Just to make sure it's set up properly.
<abentley> Also, you might consider upgrading to 1.2
<Vadi> How? To both suggestions..
<Vadi> I'm on Ubuntu 7.10.
<jdong> # Implementation. Implement your chosen code design in Java. You might find that you want to make changes to your design. You are free to do this, but should record the changes so it is clear what the original design was and what changes you made to it.
<jdong> # --> Test. Run the staff test suite using the test framework provided. If your program fails any of the tests, correct the problem, and rerun the test suite. Create at least three additional test cases of your own, that demonstrate the robustness of your Multipart implementation.
<jdong> oops
<jdong> stupid paste button
<jdong> I meant to paste https://launchpad.net/~bzr/+archive
<lifeless> moin
<abentley> Vadi: for the first: "$ sftp vperetokin@bazaar.launchpad.net"
<abentley> For the second, http://bazaar-vcs.org/DistroDownloads
<awilkins> Random offtopic question : recommend a home office colour laser (scanner optional)
<lifeless> no idea
<ubotu> New bug: #195560 in bzr "version-info {clean} doesn't work" [Undecided,New] https://launchpad.net/bugs/195560
<blueyed> wow... "bzr revert" after "bzr add" deletes files?? 8/
<LaserJock> revert says "go back" so yeah
<blueyed> well.. "only" the symlinks..
<blueyed> LaserJock: nah.. I wanted to undo the add.. not delete files that were already there...
<LaserJock> hmm
<mwhudson> there should be backup files .~1~ or whatever
<blueyed> bug 87548
<ubotu> Launchpad bug 87548 in bzr "bzr add and revert on symlink deletes symlink" [Undecided,Invalid] https://launchpad.net/bugs/87548
<blueyed> mwhudson: nope.. /etc/alternatives is now nearly empty..
<mwhudson> LaserJock: i finally started the openbabel import btw
<mwhudson> blueyed: oops!
<lifeless> blueyed: this is the difference between 'undo' and 'revert' - undo needs to know exactly what sequence of things has occured
<LaserJock> mwhudson: awesome, thanks
<lifeless> blueyed: revert just puts them back the way they were
<lifeless> you undo an action, and revert to a state
<blueyed> lifeless: the way they were? e.g. /etc/rc?.d/ wasn't empty before "add". but it's after "revert".
<blueyed> I just did "bzr init; bzr add;", thought "well, add some ignores first", so "bzr revert" and oooops..
<blueyed> lifeless: there's no "good" undo, is there?
<lifeless> blueyed: no we don't have an undo, I'm not aware of a vcs that has one - its actually quite unwieldy. Anyhow, that said - I think its a bug that we didn't make backup files called .~1~ of each symlink
<lifeless> blueyed: (unless we did ?)
<blueyed> lifeless: no.. also not for empty directories like ".common/vim/.svn/props/"
<blueyed> so, where's my backup of "/etc"? :/
<dato> lifeless: uh, if `bzr add regularfile; bzr revert` does not remove/rename regularfile, why would it not behave the same for symlinks?
<blueyed> dato: exactly my thinking.. (including empty dirs)
<Vad1> abentley: Hiya
<abentley> Vad1: Hi.
 * abentley is inclined to fix revert so that it always deletes files, thus not leading people down the garden path.
<shagbag> lifeless, I'm running the command: bzr co http://bazaar.launchpad.net/~awn-extras/awn-extras/trunk awn-extras-bzr -r 347
<shagbag> and it's taking a LONG time to 'transfer'
<Vad1> abentley: I'm still having that error with bzr. Do you know if there's a .deb of the 1.2 version? I'm running 0.9 right now.
<abentley> Yes, there is.  Did you see the link I posted?
<Vad1> No, but it somehow was opened in firefox already. I was wondering if I was dilusional
<Vad1> Whew.
<Vad1> (how did you do that though?)
<dato> abentley: so how does one undo an add before commit? rm?
<Vad1> A bit better this time, but still not quite there: http://paste.ubuntu-nl.org/57373/
<abentley> dato: Yes.
<lifeless> blueyed: there isn't one, because revert was doing what it is designed to do. That said,  I think we can provide more of a safety net
<abentley> Although, I call it "remove", because it's not the same thing as rm.
<blueyed> abentley: and how would you undo an "add"?
<lifeless> abentley: we can define merge-hashes for links and dirs too
<abentley> blueyed: see above.
<lifeless> shagbag: its in knit format, knit format is slow.
<abentley> lifeless: Not for dirs.
<Vad1> I did paste the public ssh key in my ubuntu profile. Not sure what can be wrong - but then again, I couldn't find clear instructions on how to do all of this either.
<lifeless> blueyed: 'bzr rm --keep --new'
<blueyed> ah.. I see..
<lifeless> abentley: yes, we can - sha1('\x00'.join(sort(child.name for child in dir._children)))
<blueyed> but I expect "rm" to be more bad to my data than "revert"..
<ryanakca> Is it possible to commit in someone's name (other than going sudo -u jsmith bzr commit -m "ponies") ?
<abentley> blueyed: So call it "remove" instead.  both work.
<lifeless> ryanakca: sure, long as they are not expecting gpg signed commits ;)
<lifeless> ryanakca: also see --author IIRC
<blueyed> for me, the previous state is "unknown" for those symlinks, empty dirs (and files) in general.
<ryanakca> lifeless: okies, thanks :)
<lifeless> yes, --author
<lifeless> to commit
<abentley> lifeless: I don't think that's a clear indicator of whether the directory was automatically created.
<lifeless> abentley: merge-hashes records the hash value of a file that we write to disk, IIRC ?
<lifeless> abentley: so if we create a directory with 'foo' 'bar' and 'baz', we can look at disk and see that it actually has 'foo', 'bar', 'baz', 'baz.pyc' and conclude that its been altered since.
<abentley> Technically, yes.  But the connotation is that the content was generated automatically, not subject to user info.  For example, even though shelf rewrites files, it doesn't update merge-hashes.
<blueyed> lifeless: so it's at least a bug that there are no ~1~ files, yes?
<lifeless> blueyed: I think its arguable that that is the case.
<lifeless> abentley: got you
<Vad1> What does a "Permission denied (publickey)." in bazaar mean? It
<Vad1> It's not exactly unique, so google doesn't help
<lifeless> Vad1: thats being reported by ssh, not bzr
<TFKyle> Vad1: if it's while pushing/pulling to sftp it's likely that the other end requires ssh public key authentication and bzr/your ssh client didn't provide any (or you didn't get your passphrase right possibly)
<shagbag> lifeless: thanks.  the command worked tonight (unlike last night).  I'm trying the
<shagbag> lifeless: thanks, it's downloaded (unlike last night) and compiling now.
<Vad1> TFKyle: Okay, how can I do it without the keys?
<Vad1> TFKyle: I can't find clear instructions that work anywhere for uploading. The ones I'm going by right now are here (http://ddaa.net/blog/launchpad/bzr-hosting)
<lifeless> shagbag: contact the branch owner and get them to upgrade with bzr 1.0 or newer
<TFKyle> Vad1: you'd have to configure the server to accept things other than public keys, with openssh have a look at /etc/ssh/ssshd_config
<lifeless> shagbag: it will massively improve performance
<Odd_Bloke> Vad1: If you're trying to upload to Lauchpad, you need to have an SSH key set up.
<TFKyle> but yeah, with lp you need a public key
<Vad1> Okay, I do have one in my profile in launchpad
<Vad1> Do I need one on my laptop too or?
<Odd_Bloke> Vad1: When you create a public key, it generates a private key and a public key.  You should have uploaded the public key.
<Odd_Bloke> Vad1: If you haven't created one on your laptop yet, then yes.
<Vad1> Right, I uploaded the public key
<Vad1> What to do with the private one?
<LaserJock> it should be in ~/.ssh/
<Odd_Bloke> Vad1: It should have been generated in the correct place, IIRC.
<Vad1> Any specific file name?
<Vad1> I did it on my server :/
<LaserJock> I have a id_dsa in ~/.ssh/
<LaserJock> if you have that you can scp that over
<blueyed> Wouldn't it be possible to detect a "revert" before any commit, so that no files would get deleted? (I've read in bug 193980 that the problem only is too less information to have "proper" "undo")
<ubotu> Launchpad bug 193980 in bzr "revert after add destroy my working tree" [Undecided,New] https://launchpad.net/bugs/193980
<ubotu> New bug: #195578 in bzr ""bzr revert" does not backup symlinks and empty directories" [Undecided,New] https://launchpad.net/bugs/195578
<igc> morning
<lifeless> hi
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> whats a good test to crib from that works with public locations?
<lifeless> I want bzr push --shallow to default to looking for the parent branches public location
<abentley> Maybe a merge directive test?
<lifeless> k I'll look thanks
<igc> lifeless: I'm wondering whether we ought to put an upper bound on the auto-repacking
<lifeless> igc: we should fix the bugs marked 'pack'
<igc> in my OOo import, the repack of 10 10,000 packs has been going for 14 hours now
<igc> and in still stage 2/5
<lifeless> igc: you are at 100K revisions?
<igc> yup
<igc> there's 300,000+ just in trunk
<igc> the full rpeo is closer to 500,000
<igc> I wondering whether 10,000 packs is big enough and beyond that we should only manually pack
<lifeless> so, thats very slow. We should fix it being slow
<lifeless> igc: with 10 packs you have 10 times the latency problem of 1 pack.
<lifeless> igc: please get a lsprof of it.
<lifeless> igc: hint: you can cp -a the repository while pack is active
<lifeless> igc: then you can break lock and run 'pack' manually to lsprof it
<igc> ok
<lifeless> igc: so I don't think number of things to rearrange is the issue; because - its exponential backoff
<lifeless> igc: the new pack this 10x10K operation creates will not be altered again at all by bzr during your import
<lifeless> igc: clearly though we have a performance problem in the pack logic and we should fix that
<igc> and memory pressure as well
<igc> I think it's lack of memory (4G) that is causing the issue
<igc> but 4G isn't 'lack of memory'
<lifeless> so
<lifeless> pack streams data
<lifeless> it holds two things: the index, and an individual delta in memory at a time
<lifeless> it uses a readv interface; a bug there would cause very high memory pressure
<lifeless> and it buffers writes crudely; a bug there could lead to high memory pressure if you have many big deltas
<lifeless> (but many small deltas will be fine)
<lifeless> it could be the index builder
<igc> thanks for the info
<lifeless> it could be the memory pressure of the index
<igc> I'll go digging later today
<lifeless> so yeah - backup the repo before it completes so that we can reproduce it
<igc> shall do so now
<lifeless> and get a basic handle on whats wrong and I'll help fix that
<igc> ok
<foom> does bzr write out profile data even if you interrupt an operation, these days?
<lifeless> for instance we may need to start tape-sorting the index we are creating incrementally with very large index sizes
<lifeless> foom: maybe; ctrl-\ + a little prodding will let you finish early though :)
<lifeless> is there a way to do optional strings on an option?
<lifeless>  --reference=bar, with --reference when given defaulting to something e.g. auto:// ?
<lifeless> I'd like to not have two options (--shallow and --reference=url)
<poolie> lifeless: i see your point but i think it's bad style
<spiv> lifeless: hmm, I don't think so.  How would that disambiguate between "--reference unrelated_argument" and "--reference bar"?
<poolie> confusing when people say --option SOMETHING
<lifeless> yeah
<poolie> wot he said
<lifeless> this has already occured to me
<lifeless> but I still thought I'd ask
<Prodoc> I accidentally added some folders I didn't want to track using 'bzr add' (windows xp), now when I try to remove those folders using 'bzr remove <folder name>' I get an error message: 'bzr: ERROR: Can't safely remove modified or unknown files:', can someone explain what's going on here? Is this a bug or should I exclude the folders in a different way?
<lifeless> bzr rm --new --keep
<Prodoc> --new?
<lifeless> bzr help rm
<Prodoc> heh, of course, thank. I'm ashamed to admit that I'm too much used to GUI's :-$
<Prodoc> it worked, cheers lifeless
<lifeless> poolie: np
#bzr 2008-02-26
<blueyed> abentley: why have you silently duplicated bug 195578? - it's not the same
<ubotu> Launchpad bug 195578 in bzr ""bzr revert" does not backup symlinks and empty directories (dup-of: 87548)" [Undecided,New] https://launchpad.net/bugs/195578
<ubotu> Launchpad bug 87548 in bzr "bzr add and revert on symlink deletes symlink" [Undecided,Invalid] https://launchpad.net/bugs/87548
<poolie> lifeless: bad tab completion?
<lifeless> poolie: yes
<lifeless> Prodoc: np
<Prodoc> :-)
<Prodoc> time for a nap again, goodnight all
<bob2> is bzr+http support on launchpad planned anytime soon?
<poolie> yes, thumper would know more
<thumper> bob2: yes, real soon now
<poolie> lol
<poolie> thanks for the more precise answer :)
<bob2> heh, great
<lifeless> argh
<lifeless> run_bzr working_dir=xxx breaks our test HttpServer
<lifeless> _now_ that that is sorted, I just now need to fix it :|
<lifeless> yay test passing. what a waste of time that was
<AfC> Hooray for time wasters!
<blueyed> yay.. I'm finished for today restoring my symlinks, empty directories (including svn checkouts) in /etc.
<lifeless> blueyed: I really regret that you had that experience
<lifeless> is there a command line to set the public_location of a branch ?
<Odd_Bloke> So I notice that there are two formats of name/bug number for fixes, namely "(#123456, Foo Bar)" and "(Foo Bar, #123456)".  Which should I use?
<lifeless> Odd_Bloke: where
<Odd_Bloke> lifeless: In NEWS (to clarify).  Everything under IN DEVELOPMENT uses the former, and BUGFIXES of 1.2 has examples of both.
<Peng> I've always thought the correct one was the former.
 * Odd_Bloke would've opted for the latter.
<fullermd> Sad that your choices are limited to orderings in only one dimension...
<johnny> ?
* pooli1 changed the topic of #bzr to:  http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://edge.launchpad.net/bzr/1.2/1.2
<lifeless> Odd_Bloke: hmm, Look at 1.1's area, that will probably make it more clear :)
<Odd_Bloke> lifeless: It does, thanks. :)
* Odd_Bloke changed the topic of #bzr to:  http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2
<pooli1> thanks
<pooli1> Odd_Bloke: are you all set for london
<Odd_Bloke> pooli1: Yup, should be turning up early afternoon.
<Peng> Err, wait.
<Peng> I like the latter, not the former.
 * Peng checks.
<Peng> Yeah. (The Name, #1234).
<Odd_Bloke> Sanity is restored! :)
<igc> bbiab
<kohwj> ok, branching and merging are good things, but what happens when a user branches and makes changes to the branch, while another user makes changes to main, and then a merge is attempted?
<bob2> depends if they texttually conflict or not
<bob2> if they're different files, merge just works without intervention
<kohwj> bob2: i see. if the same file is changed in the branch and main, manual intervention is needed?
<bob2> depends if the changes overlap or not
<johnny> two seperate changes to two seperate areas of the file shouldn't cause a problem
<kohwj> that's nice!
<kohwj> thank you!
<bob2> (same as every revision control system I've ever heard of)
<kohwj> i'm new to vcs
<johnny> kohwj, it's an interesting area
<AfC> kohwj: you're lucky. Most of us started with RCS, SCCS, or CVS. Those were dark days indeed :)
<johnny> kohwj, if you want your mind blown, read the revctrl mailing list
<johnny> unless you have a degree in graph theory..
<kohwj> johnny: heh
<johnny> luckily we can just let the smarties do it :)
<lifeless> win 20
<bob2> lose all
<lifeless> tie nothing
<lifeless> bob2: thanks for the patch
<bob2> did it work?
<lifeless> haven't applied it yet
<lifeless> will do so on the plane tomorrow
<lifeless> bob2: did you write a test for it ? :)
<bob2> ah, have a nice trip
<bob2> lol
<bob2> what do you take me for ;)
<lifeless> just asking!
<abentley> bob2: You know, some guy's been using your name on a blog about ODF
<bob2> haha
<lifeless> abentley: the guy with the scyth?
<lifeless> bob2: you _so_ have to get a job with ibm
<abentley> lifeless: eh?
<bob2> I'd love an exciting job at ibm working on office file formats!
<lifeless> abentley: http://www.robweir.com/blog/rob.html
<lifeless> abentley: not bob2
<abentley> Ah, I'd forgotten about the scythe bit.
 * igc dinner
<lifeless> spiv: cool thanks
<visit0r> why is bzr outputting basic output to stderr?
<visit0r> any way to change this so it would output only if something's wrong?
<lifeless> output to stdout is the requested output, not status or debug or error info
<lifeless> output to stderr can be reduced/made quiet by -q
<lifeless> though we don't claim to have audited all commands yet
<visit0r> hmm ok, always tought it's primarily for error messages
<visit0r> but thanks anyways
<lifeless> visit0r: we want e.g. 'bzr diff | less' to only ever have the content of the diff
<visit0r> lifeless: ok, sounds reasonable
<liw> how do I make bzr forget the parent branch (set by "bzr pull")?
<quicksilver> I know how to make it remember a new one
<quicksilver> does that help?
<quicksilver> I don't know how to make it forget without that though
<quicksilver> bzr pull --remember new://url
<liw> hmm, I can make it remember the empty string, which it translates to the current working directory -- ugly, but at least a partial solution
<bob2> you can delete the line from .bzr/branch/branch.confg, as a last resort
<liw> bob2, yep, that worked -- slightly ugly to do, but good enough for now
<liw> thanks
<Bronger> Is there another GNU program of the size of Bazaar written in Python?
<bob2> mailman, maybe?
<TFKyle> Bronger: don't think so (can't think of any Version Control Systems created by GNU offhand)
<Bronger> I didn't only think of VC software.  Mailman, yes, this is also large.  Didn't know that it is part of GNU, but you're right.
<bob2> at least rcs and cssc are gnu vcs (and not in python)
<TFKyle> ah, just in general
<Bronger> ... and GNU arch.
<bob2> touche
<lifeless> Bronger: I'm not sure how 'big' bzr is to really answer that ;)
<Prodoc> good afternoon
<Prodoc> how do I commit and push using the bazaar eclipse plugin?
<Prodoc> I've created a bazaar snapshot of an existing eclipse project (local), now I'd like to commit the changes to the branch and push them to the ftp server (php project)
<Bronger> lifeless, I don't undertand what you say, sorry.
<beuno> Verterok, ^
<awilkins> Prodoc: Pushing is not deploying, if that's what you want
<awilkins> Prodoc: Pushing only updates the remote branch, not the working tree of the remote branch
<Prodoc> awilkins: the only thing I've got remote is simply a FTP server to access the hosted website. This is what I want to update after changes have been commited
<jdong> Prodoc: bzr will not update the user-visible contents on a push. It only updates the stuff inside .bzr
<Prodoc> aha, so what is it what I should do to update the site and (how) can this be done in eclipse?
<jdong> Prodoc: the only form of access you have is FTP?
<Prodoc> yes
<jdong> Prodoc: AFAIK bzr won't have a way to do this for you. My suggestion would be to "bzr export" to some directory, then use an uploader like ncftpput to upload that exported directory up to your website
<jdong> you could script those two actions so that it's less of a pain
<Prodoc> But that would be a simple overwrite, wouldn't it? What if someone else made changes to the online content?
<Prodoc> ah, it appears to be possible: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id40 now the only thing that remains is to find out how this is handled in exclipse by the bazaar plugin
<luks> branching?
<Prodoc> sorry, one down: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id41
<Prodoc> he, luks?
<Prodoc> :-D
<luks> :)
<luks> merging works with branches, not files
<luks> the fact that you have some files on the server is completey unrelevant to bzr
<luks> the only data it needs are under the .bzr dir
<Prodoc> aha
<luks> also, it's probably not a good idea to have published .bzr dirs on a public http server
<luks> so what you want if you work with some other people is to have a common location to push/pull/merge from bzr, and a way to update the live site from that location
<Prodoc> true, I wanted to address that issue once I got it working ;-)
<luks> bzr is only a version control tool, not a deployment tool :)
<Prodoc> too bad ;-)
<Prodoc> my only option is to use FTP, live or not. What if I simply upload a branch, could that work?
<luks> you can simply push to FTP
<luks> but it will push only the .bzr dir
<luks> then if somebody else already pushed to the branch, it will complain
<luks> so you know you have to merge the changes
<luks> but after you do all this, you need a way to upload the actual files
<Prodoc> creating an export of the branch
<Prodoc> no?
<luks> that's one way
<Prodoc> hmm, not really handy if I only have FTP access to the server
<TFKyle> <luks> also, it's probably not a good idea to have published .bzr dirs on a public http server <-- why's that? just because he might have private config stuff in the branch or?
<luks> if it's html only site it doesn't matter
<luks> but you usually don't publish the source code of your websites
 * TFKyle tends to :)
 * luks tends to work on commercial ones
<luks> and for the free ones, there are better ways to push the source code :)
<luks> er, publish
<jdong> Prodoc: another way to handle changes in content involves "getting" all of the website, locally doing a 3-way merge, then pushing back the merged results
<jdong> this assumes during that time, nobody writes to the website, of course...
<jdong> Prodoc: ultimately having only FTP access really cripples what you can do
<awilkins> If you're using Windows you can do worse than Beyond Compare 2 for deploying webs over FTP
<awilkins> It even utilises the remote CRC function if your FTP server supports it, cuts down your transfer times
<awilkins> Will also note which files on either side are newer
<Prodoc> I think I'll search for a better solution. In the mean time, how to I commit changes to my local branch using Exclipse?
<shaya> in bazaar, how does one revert a patch in the middle?
<shaya> i.e. revisions 1 2 3 4 5, want to undo revision 3?
<shaya> is there an automated way, or does one have to do it manually (make a patch that is version 3, patch in reverse, commit)
<LeoNerd> bzr merge -r 3..2
<LeoNerd> ((or maybe 4..3   I forget offhand))
<shaya> I'd assume 3..2 probably
<LeoNerd> It's the reverse of the change from rev2 to rev3, so I guess that sounds right
<shaya> thanks
<shaya> here's a bigger issue
<shaya> on my feisty box
<shaya> ImportError: No module named bzrlib
<shaya> this is using the unbuntu package
<shaya> do I really need a PYTHONPATH on ubuntu?
<Stavros> hello
<Stavros> is there a good bzr plugin for eclipse?
<Prodoc> Stavros : are there more then one?
<Prodoc> http://bazaar-vcs.org/BzrEclipse
<Stavros> Prodoc: no idea
<Stavros> is it good?
<Prodoc> can't tell yet, just started playing with it but I it's a bit confusing
<Prodoc> and it's far from complete
<Stavros> ah, hmm
<Prodoc> (see the website)
<Stavros> well, i just installed subclipse and i have no idea how even that works
<Prodoc> haha
<Stavros> eclipse is confusing :/
<Stavros> where IS everything :(
<Prodoc> it's a bit of getting used to yes
<Prodoc> too many options
<Stavros> yeah
<Prodoc> too many shortcutsd
<Stavros> but pydev is great
<Prodoc> -s
<Prodoc> -d
<Prodoc> darn
<Stavros> haha
<Stavros> hortcuts?
<Stavros> i looked into buying pydev but you can only rent it, apparently
<Prodoc> shortcutsd -d
<Prodoc> typo
<Stavros> i know :P
<Prodoc> let me know if you manage to find a BzrEclipse manual ;-)
<Stavros> will do
<Stavros> but first i must find bzreclipse :P
<Prodoc> http://bazaar-vcs.org/BzrEclipse
<Stavros> no, i installed it
<Stavros> i need to find it in eclipse :p
<Prodoc> haha
<Odd_Bloke> Stavros: PyDev is under the Eclipse Public License.
<Stavros> Odd_Bloke: pydev extensions isn't, though
<Odd_Bloke> Stavros: Ah, I see.
<Prodoc> Stavros: finding the settings is the easy bit, as far as I can tell all the rest is in the file context menu
<Stavros> oh hmm
<Prodoc> in the explorer
<Stavros> aha
<Prodoc> but that might only appear if you're viewing an actual branch
<Stavros> oh hmm, let me create a project then
<Stavros> damn its eyes, i can't create a project in an existing folder
<Stavros> anyway this isn't #eclipse, so i'll keep my ranting to myself :p
<Prodoc> Stavros: I assume you'll get less help for bazaar in exclipse in that channel than here
<Stavros> haha, true
<Stavros> it's ok though, i found the file browser so it should be there
<Stavros> i have to go now, thanks for your help
<Prodoc> np
<thatch> I'm using bzr 1.2 with a 1.1 server over bzr+ssh... I got the "Server is too old for fast get_parent_map", is that supposed to break locks itself before reconnecting?
<thatch> I ctrl-c'd the second password prompt, then had to break the lock myself even though the process had exited when the first ssh session was over (I think)
<james_w> thatch: I imagine it might hold the lock so that it knows no-one else nipped in while it was reconnecting.
<james_w> I don't know how it works though, so I'm just speculating.
<lifeless> hi james_w
<lifeless> thatch: it won't break the lock before reconnecting
<lifeless> thatch: the server is stateless
<james_w> hi lifeless
<mib_oa5m0u19> having an issue with merging where I get "nothing to do" even though there are changes - anyone able to help?
<lifeless> mib_oa5m0u19: what do you mean
<mib_oa5m0u19> if I create a feature branch off a main branch and make some changes, then try to merge those changes into the main branch using bzr merge, I just get "nothing to do"
<lifeless> mib_oa5m0u19: are your changes visible in 'bzr missing $feature_branch_url' or 'bzr log $feature_branch_url'
<Odd_Bloke> mib_oa5m0u19: You need to have commited the changes in the feature branch.
<mib_oa5m0u19> ok, so when I am in the feature branch
<mib_oa5m0u19> I type bzr commit?
<mib_oa5m0u19> (this is my first time using bzr, btw....)
<Odd_Bloke> mib_oa5m0u19: 'bzr commit -m "<message>"', where <message> describes the changes you've made.
<mib_oa5m0u19> great thanks
<mib_oa5m0u19> that was the issue - i just didn't realize i had to had the -m option
<mib_oa5m0u19> works now
<Vadi> This is purely a cosmetics question, but when I do bzr branch <link>, it makes a folder with the branch name (ie, if my project name is vadi-mapper and branch is main, it'll make a folder called main). Is it possible to name the folder after the project name instead, not the branch?
<Odd_Bloke> Vadi: 'bzr branch <from> <to>'
<Vadi> So instead of "bzr branch http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main", try "bzr branch http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main vadi-mapper" ?
<Odd_Bloke> Vadi: Yup.  Or you can just 'mv main vadi-mapper'. :p
<Vadi> That would be like... whole 2 commands. Too much!
<Odd_Bloke> This is true, but if you've already branched it once, then branching it again is almost certainly slower. :)
<Vadi> -grin- thanks for the help
<Vadi> Can I make bzr remember what location to push to, instead of asking everytime?
<Odd_Bloke> Vadi: Have you tried pushing without specifying a location?
<Vadi> Yes, and it complained - "No push location known or specified."
<Odd_Bloke> Vadi: Sorry, have you tried pushing once with a location and then again without?
<Vadi> Oh, that worked. Okay, excellent.
<james_w> Vadi: if you are using launchpad then bzr branch lp:vadi-mapper will probably do what you want.
<Vadi> Yes, I was told that wouldn't work on non-ubuntu though and the link is a better way to go
<james_w> it should work on non-ubuntu, unless the launchpad plugin is disabled on whatever platform you are on.
<thatch> lifeless: I put 1.1 back on the server and I'm able to reproduce the lock-left-open situation
<Vadi> Is it enabled by default in mac/windows too?
<lifeless> thatch: if you are hitting control-C rather than putting your password/key in again, then this is expected
<lifeless> thatch: because at the point of reconnect we have a held lock. Then we drop the link. Then you interrupt bzr before it gets a new link.
<lifeless> thatch: there is no way to remove the lock at that point :)
<thatch> lifeless: hmm. so if users go "Oh! Yeah, I forgot to update bzr on the server" they must proceed to completion instead of stopping now to upgrade?
<lifeless> thatch: or break the lock
<lifeless> thatch: Its not beautiful, but really - what can we do about it that is both correct (dropping the lock isn't) and robust (asking for *another* password to break the lock when you hit enter is going to be confusing)
<lifeless> when you hit ctrl-C I mena
<thatch> lifeless: Yeah, you're between a rock and a hard place there.  The "entering the password twice" situation didn't actually get to me until after I'd entered the first of the pair though :)
<Vadi> Odd_Bloke: I got a bit stumped on the push isntructions. The first time I'd do it it would be "bzr push b zr+ssh://vperetokin@bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main" - but that has my username in it. I'd tell the user to use their own launchpad name, yeah?
<Odd_Bloke> Vadi: Probably.
<Odd_Bloke> It does depend on your workflow.
<Vadi> Well, the vadi-mapper-dev is a team I made.
<Vadi> So people join in the team. Theoretically. So far someone has joined who I have no idea they are
<lifeless> Vadi: the bit USER@bazaar...
<lifeless> Vadi: that is who *you* are, so launchpad will allow you access to your teams etc
<Vadi> ahh
<lifeless> for instance, if I was a collaborator that you allowed into the vadi-mapper-dev team
<lifeless> then I would use bzr+ssh://myname@bazaar.launcpad.net/~vadi-mapper-dev/vadi-mapper/main
<Vadi> right, okay
<Vadi> Um, be right back, something is really wrong with my X - it's been hogging the both cpu's at 50% for a while now and even the fans turned on.
<lifeless> beuno: ping
<bialix> hi, I have question about loom plugin
<james_w> hi bialix
<bialix> hi james_w
<lifeless> hi bialix
<lifeless> bialix: ask away
<bialix> why for 'record' command is needed
<bialix> ?
<lifeless> to version the loom
<bialix> I'm using loom for versioning my own package for our custom Slackware Linux. I did commit, but not record. Is it wrong?
<lifeless> bialix: cool
<bialix> record seems strange for me
<lifeless> bialix: its not wrong; but you can't share the loom with other people - merge at the loom layer - without recording
<lifeless> bialix: imagine that you had each thread as a separate directory on disk
<bialix> what do you mean 'merge at the loom layer;'?
<lifeless> bialix: for me to get the same directories, I would need to list-dir, then branch each one
<lifeless> bialix: the loom is a text file that lists branch names & revision ids.
<bialix> but commit did update loom references for heads
<lifeless> bialix: commit updates the revision ids yes.
<bialix> why I need record?
<lifeless> bialix: if you want to give me a copy of the loom
<lifeless> bialix: or if you want to see what the loom looked like some days ago
<lifeless> as bzr help loom says -
<bialix> I thought the loom is just metaphor around several heads in one branch. Is it not?
<lifeless> its more than that
<bialix> when I do bzr log I see ordinal bzr history with merges
<lifeless> it can also _version_ that list
<bialix> how can I see the version from record?
<bialix> I mean log?
<lifeless> I haven't written a command to do that yet ;)
<bialix> there is no loom-log
<lifeless> if you do a record
<lifeless> and then do bzr heads --dead-only
<bialix> so it should be additional command?
<lifeless> yeah, or perhaps an option to 'bzr log'
<lifeless> perhaps bzr log should just annotate the output with thread details; and have an option to only show the history of the loom
<bialix> something odd in my head. loom have 2 different histories?
<lifeless> yes. history of the _loom_, and _history of the source code_
<lifeless> normal branches only have _history of the source code_
<bialix> can you point me to actual code?
<bialix> loom history goes to repository storage?
<bialix> at first I thought that loom islike named branches in hg. but then I understand it's not. but I have no experience with Mercurial Queue though.
<lifeless> branch.py - LoomMetaTree, and record_loom
<beuno> lifeless, pong
<lifeless> and pull sa well
<lifeless> pull *as well*
<lifeless> beuno: hi, re debian packages and bazaar/bzr
<lifeless> beuno: will you be doing the packaging patches and sending to BTS ?
<beuno> lifeless, for Ubuntu?  I'm neither DD nor UD, so I can't really upload to anywhere. I'll be more than glad to help out doing the heavy lifting though
<bialix> lifeless: record is calling regular commit under the hood?
<lifeless> beuno: please do :)
<lifeless> beuno: for me its just time, if we have patches in the BTS its a big help
<lifeless> beuno: (and I'm ubuntu-dev, but not ubuntu-core-dev, so can't upload some of it anyhow)
<lifeless> bialix: yes, for a separate tree
<lifeless> bialix: the separate tree contains one file
<bialix> separate tree?
<lifeless> called 'loom' with fileid 'loom_meta_tree'
<lifeless> bialix: yes, the loom project
<beuno> lifeless, alright, sounds good, we'll find someone to bug. This would basically be making "bazaar" install baz and bzr, right?  The first step
<lifeless> bialix: really, try doing heads --dead-only after a record
<lifeless> beuno: yeah, whatever we said the other day :>
<bialix> lifeless: ok will do
<lifeless> bialix: then branch the revision you file to /tmp/whatever
<lifeless> bialix: and have a look at whats there :)
<beuno> lifeless, hehe, alright. I'm getting on a plane in a few hours towards Madrid, so I'll be offline for a day or so. I'll take a look at it and see if we can have that done during the sprint. Sound good?
<bialix> ok, I think separate tree is a bit of hack. But if I need commit additional file along with dirstate. How I should do it?
<james_w> lifeless: confirmed status still exists doesn't it? Or has it been removed on edge?
<lifeless> james_w: I was whinging because confirmed is useless now
<lifeless> james_w: if its not triaged it will get deleted.
<lifeless> bialix: cool
<lifeless> bialix: sorry, wrong nickname
<lifeless> beuno: cool
<james_w> beuno: I'll be happy to work on it during the sprint if it's not done by then.
<james_w> beuno: with you of course, I forgot those two words :)
<lifeless> bialix: separate tree is for the loom metadata only; I'm trying to make the guts visible to you.
<james_w> lifeless: that does sound wrong to me.
<lifeless> bialix: anything for your normal source code just do what you do with bzr commit
<beuno> james_w, great, thanks. Glad that's getting done in time.
<bialix> lifeless: yes, I understand intend
<mwhudson> lifeless: it's only incomplete bugs that get expired, and only if the project switches that feature on
<lifeless> mwhudson: its incomplete if its < triaged is it not ?
<lifeless> mwhudson: that was my understanding
<mwhudson> incomplete is a separate status
<lifeless> mwhudson: anyhow, write this up to 'user got bitten, user remembers workaround _forever_'
 * beuno goes continue packing
<mwhudson> lifeless: thus, we must never make mistakes
<mwhudson> lifeless: it's even documented! https://help.launchpad.net/BugExpiry
<lifeless> mwhudson: righto, so it has changed :)
<lifeless> mwhudson: never making mistakes is not a corollary to what I said :)
<mwhudson> the fact that so many bugs got expired the first time it run was a bad bad bug
<lifeless> mwhudson: indeed
<lifeless> mwhudson: I simply had remember the workaround for the initial implementation
<lifeless> mwhudson: because that got rather effectively burnt in
<bialix> does launchpad means 'area where rockets launch to outer space'?
<lifeless> yes
<bialix> thanks
<ig1> morning all
<abentley> lifeless: mats is specifically complaining that wget -c doesn't skip files he's already downloaded.
<Verterok> Prodoc: I'm working in bzr-eclipse, there is no Manual (yet)
<Verterok> Prodoc: in the meantime shoot any question you have about it :-)
 * Verterok says Hi to everyone 
<Prodoc> yeah, I noticed :-( It took me some time to figure it out being new to eclipse and bazaar but I finally found out how to use it. I took the liberty to add the very basis to the installation page if you don't mind ;-)
<Prodoc> (http://bazaar-vcs.org/BzrEclipse/Installation Kick-start section) though it might need some more clarification, like I said, I'm new to both so this only counts for a clean setup
<Prodoc> so additional steps might be required and there might be different methods as well
<Prodoc> at least this actually gave me the all the actions like commit, etc.
<Verterok> Prodoc: great, thanks! it's a wiki, y're wellcome to edit it :-)
<Verterok> it's looks good :-D
<Prodoc> This should be sufficient for the new users, other don't really need it, more should go in a separate manual
<Prodoc> others
<james_w> hi Verterok
<james_w> hi igc
<Verterok> sure, it was my mistake to assume that everyone using bzr-eclipse will know eclipse :)
<Verterok> Prodoc: I'm planing to add Help integrated in the Eclipse help system, but first it must be written :P
<Verterok> james_w: hi
<Prodoc> Verterok: what is the opposite of the 'Share Project...' action? First I thought it was Disconnect but I've got the feeling that this applies to the branch, not just the removal of the Bazaar stuff in Eclipse because of the confirmation dialogue
<Prodoc> to get rid of the Bazaar stuff again
<Prodoc> in Eclipse
<Verterok> Prodoc: for the moment Disconnect only remove bzr-eclipse support from the Project, but it'll let you choose to completely wipe bzr control files
<Verterok> I take a conservative approach on this, mainly because I usually kill the branch (and the working tree) when I merge it in trunk
<Prodoc> ok, so it's save to use it? It won't kill the branch?
<Verterok> Prodoc: sure :). For the moment bzr-eclipse maps each command with the corresponding CLI one.
<Verterok> it only removes bzr-eclipse support
<Prodoc> ok, cool :-)
<Prodoc> It might be an idea to change the message from 'Are you sure you want to disconnect Bazaar from '<project name>'' to something like 'Are you sure you want to disconnect Bazaar from the Eclipse project '<project name>'?' With or without including 'Eclipse' (note the question mark as well ;-) ) to make it clear that it doesn't do anything to the files/branch but only to the Eclipse project.
<Prodoc> e.g. the project name and containing folder name are identical, hence the confusion
<Verterok> Prodoc: it's sound ok. could you fill a bug about this?
 * Verterok brb
<Prodoc> Verterok: or maybe Bazaar should be changed to something else as well make indicate that it's the plugin we are dealing with, not an actual bazaar action
<ubotu> New bug: #195927 in bzr "bzr commands not available after suspend-to-disk" [Undecided,New] https://launchpad.net/bugs/195927
<lifeless> hi poolie
<lifeless> do you want a lift to the airport?
<poolie> hello
<poolie> that would be nice
<poolie> i think you said you were aiming to get there at 4 - the flight is at 6 so that's a bit tight...
<mwhudson> this code raises an exception: http://paste.ubuntu-nl.org/57523/
<mwhudson> is it doing something silly?
<mwhudson> (this is what prevents viewing an empty branch with loggerhead right now)
<poolie> hm
<poolie> i kind of think you're meant to create a memoryserver and get a transport from that
<poolie> but presumably that's not what's breaking
<poolie> so presumably the problem is that get_revision_graph doesn't like being given the null revision?
<poolie> that would probably be a bug
<mwhudson> no, it's the merge_sort that fails
<mwhudson> sorry, perhaps i should have been more clear
<poolie> it doesn't like being given an empty graph?
<mwhudson> b = "get me a branch with no revisions in it"
<mwhudson> right
<Prodoc> time for a nap again, goodnight all
<poolie> just a bug, presumably
<poolie> should be trivila
<mwhudson> poolie: ok
<poolie> could you try to write a test for it?
<poolie> it may just need an adjustment to an 'if' in tsort
<mwhudson> hm, maybe this is a fallout from the move to using "null:" for the null revision
<mwhudson> oh grr, i can't import NULL_REVISION in tsort.py :/
<mwhudson> poolie: this seems to suffice http://paste.ubuntu-nl.org/57525/ but it's not clean at all
<poolie> you can't import it because of circular dependencies?
<mwhudson> yeah
<mwhudson> revision imports deprecated_graph imports tsort
<poolie> well, just import the module then and do mod_revision.null_revision
<poolie> thisi s done elsewhere
<poolie> if you could also just add a test you have my +1
<mwhudson> that doesn't work either
<mwhudson> poolie: i did add a test, or a line to a test
<mwhudson> maybe something to do with lazy imports?
<poolie> yes could be
<igc> poolie: call on today?
<poolie> yes
<mwhudson> seems not, found a workaround though
<mwhudson> (sometimes it amazes me that any python program manages to import anything at all)
<mwhudson> boy, there seem be a lot of unused imports in bzrlib
<johnny> you guys using pylint or pychecker ?
<bob2> lazy_import breaks them
<johnny> fun...
<spiv> Yeah, there are a few.
<spiv> johnny: I use pyflakes sometimes, but lazy_import gets in the way.
<spiv> pyflakes works a module at a time though, so it's fairly easy to comment out the lazy_import magic in a single module, run pyflakes on it, and then uncomment the magic.
<mwhudson> spiv: "a few"?
<mwhudson> you must have not looked recently :-)
<spiv> mwhudson: I have a hackish branch at http://people.ubuntu.com/~andrew/bzr/faster-startup that removes some unused imports, among other things.
<spiv> mwhudson: but I haven't tried checking many modules, just those that tend to be imported all the time.
<mwhudson> spiv: well, i started alphabetically and spent 10 minutes on "branch.py" :)
<mwhudson> (after option.py which was where i first noticed some silliness)
<bignose> I'm getting an error <URL:http://pastebin.ca/919766> trying to 'bzr upgrade'
<bignose> the upgrade is prompted by a 'bzr commit' giving "Repository KnitPackRepository('sftp://bzr@fs/%7E/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bignose/Projects/.bzr/repository/')"
<bignose> when I attempt to upgrade, I get the error shown at the pastebin URL above.
<bignose> how can I get the commit to succeed?
<bob2> bzr upgrade --rich-root
<bignose> why, then, is that not the default?
<spiv> bzr upgrade --rich-root-pack
<bignose> or rather, why is something not-default actually necessary for this commit to succeed?
<jamesh> bignose: because you're using bzr-svn?
<bob2> does the repository you're commotting to have svn branches in it?
<spiv> bignose: it's a bug, really.  What's happened is that you have a repo that is in a format that was never the default.
<bignose> jamesh: I'm not.
<jamesh> hmm
<jamesh> then I wonder how your repo got into a richroot format?
<spiv> bignose: and the default "bzr upgrade" doesn't have the smarts to pick a compatible (and again, non-default) format to upgrade to.
<bob2> which non-default repo format?
<bignose> okay. so, again, what do I need to do to fix this?
<ubotu> New bug: #195962 in bzr "send -f (using bzr-svn): 'FakeControlFiles' object has no attribute 'put'" [Undecided,New] https://launchpad.net/bugs/195962
<bignose> bob2: I don't know. either of the ones that has been suggested here, which clearly aren't the default otherwise I wouldn't need to give an option to use them.
<spiv> bob2: IIRC, bzr upgrade tries to upgrade pack-0.92 atm, but this needs rich-root-pack.
<bignose> I vaguely recall performing a non-default 'bzr upgrade --foo-bar' suggested by someone in this channel to fix some earlier bug
<bignose> so that may explain why it's currently in a non-default format
<bignose> I'd be very happy to get the repo to a state where everything will work, including default 'bzr upgrade' in future.
<bignose> but my immediate problem is to get this commit working
<bignose> so, what do I need to do in order for a commit to this branch to succeed?
#bzr 2008-02-27
<abentley> Why is an upgrade necessary for the commit to succeed?
<bignose> abentley: scroll back. the commit is failing with an error about incompatible repository formats.
<bignose> my response to that was to attempt an upgrade on both the branch and the repo
<abentley> It's not in my scrollback.
<abentley> All I see is your paste of the upgrade failure.
<bignose> abentley: the line immediately following that
<bignose> abentley: 10:49 < bignose> the upgrade is prompted by a 'bzr commit' giving "Repository KnitPackRepository('sftp://bzr@fs/%7E/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/bignose/Projects/.bzr/repository/')"
<abentley> So you're committing in a checkout?
<bignose> abentley: yes
<abentley> So as spiv noted, the command is "upgrade --rich-root-pack"
<bignose> $ bzr upgrade --rich-root-pack .
<bignose> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<abentley> It sounds like your remote branch is the one that needs to be upgraded.
<bignose> the checkout branch?
<abentley> sftp://bzr@fs/%7E/.bzr/repository/
<bignose> okay, trying that
<abentley> What does bzr info . say for the format?
<bignose> too late, I'm upgrading it now :-)
<bignose> isn't this just going to compound the problem though? surely I want to *reduce* the number of repos and branches that are in this non-default "rich-root-pack" format?
<abentley> Well, the rich-root formats can't be converted into the default format.
<bignose> ugh.
<bignose> so I'm proceeding down a dead end?
<abentley> Because they can't represent everything that the rich-root formats can.
<abentley> So you can make it so you can commit, which is what you were saying was your immediate priority.
<abentley> And you can continue using this format for branches that are already in it.
<jml> I'm trying to merge from a colleague's branch into my copy of trunk and I get this error:
<bignose> yes. I didn't think, though, that the Bazaar developers would have implemented formats that cannot be converted to each other.
<abentley> That's half the point of making new formats.
<jml> bzr merge ../other-branch
<jml> bzr: ERROR: Tags not supported by BzrBranch5('file:///home/jml/project/trunk/'); you may be able to use bzr upgrade --dirstate-tags
<bignose> abentley: the problem is that this is the *entire repository* of all branches that I work on at this site.
<abentley> You're the one who said "too late".
<spiv> I believe the plan is that rich-root support will eventually be in the default format.
<abentley> There's nothing *wrong* with this format, it's just not the default yet.
<jml> why do I have to upgrade my copy of trunk?
<bignose> again, I didn't think 'bzr upgrade' commands would be leading me down a dead end.
<spiv> It's not a dead-end.  You're just an early adopter.
<bignose> seemed like a reasonable assumption.
<abentley> jml: Because we are tag fascists, and you must be assimilated.
<jml> abentley: let me rephrase
<abentley> bignose: Have you looked at the documentation of upgrade?
<jml> abentley: I'm not upgrading my trunk branch format
<abentley>     --rich-root-pack    New in 1.0: Pack-based format with data compatible
<abentley>                         with rich-root format repositories. Incompatible with
<abentley>                         bzr < 1.0
<bignose> I'll be clear: I never chose this "rich-root-pack" format, except in response to getting a bug fixed so long ago that I can't recall what it was.
<bob2> isn't bzrbranch5 dirstate-tags era?
<bignose> now, there is of course the caveat to be careful of doing things suggested by people on IRC
<abentley> bob2: older.
<abentley> format 5 is knit era
<bignose> but it's rather astounding to me that soemone would implement a format that cannot be converted *from*.
<abentley> bignose: That was the whole point of the format.
<bignose> Yes, I see that it's "incompatible with bzr < 1.0", which is fine because I'm no longer using versions less than that.
<abentley> All it does is allow bazaar to store data that it otherwise couldn't.
<spiv> bignose: the new format was made *because* there was data we want to record that cannot be recorded in earlier formats.
<bignose> my concern is that you're saying it can't be converted *from* in future.
<abentley> bignose: Oh certainly it can be converted from.
<spiv> bignose: aah
<bignose> spiv: earlier formats? you said above "I believe the plan is that rich-root support will eventually be in the default format."
<bignose> so I've now got "rich-root-pack", which can't be converted to "rich-root"
<bignose> which means I won't be able to convert to the future default.
<abentley> It can be converted from rich-root-packs to the formats that support subtrees.
<spiv> bignose: it's just that you can't convert from this to older formats.  You will be able to convert this data to future formats.
<spiv> bignose: as I said before, it's not a dead end.
<bignose> spiv: so, if I read that right, it's *not* true (as someone said earlier) that "rich-root-pack" can't be converted to "rich-root"?
<bignose> why, then, would I not convert to "rich-root" immediately, instead of "rich-root-pack"?
<spiv> bignose: I don't know any reason why you couldn't covert between those.
<lifeless> rich-root and rich-root-pack share the same *model*. Of the two rich-root-pack is faster.
<spiv> bignose: but if you're running >= bzr 1.0, I also don't know of a good reason why you'd want to downgrade from from rich-root-pack to the slower rich-root :)
<abentley> bignose: rich-root-pack is likely to be the future default, not rich-root.
<bignose> abentley: that makes it clearer, and is different to what spiv said.
<spiv> bignose: sorry, I didn't mean to confuse you.
<bignose> thanks everyone.
<abentley> bignose: What spiv said was about rich root support, not a particular format.
<bignose> new problem:
<bignose> in trying to upgrade the checkout branch, I seem to have messed up the .bzr directory.
<bignose> I've reverted to the .bzr.backup (that is, 'rm -r .bzr && mv .bzr.backup .bzr')
<bignose> but still 'bzr info' says "bzr: ERROR: No repository present: "file:///home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/"
<abentley> ls /home/bignose/Projects/websites.devel/www.benfinney.id.au/site.ikiwiki/.bzr
<bignose> ]$ ls .bzr
<bignose> branch  branch-format  branch-lock  checkout  README
<abentley> cat .bzr/branch/format
<bignose> $ cat .bzr/branch/format
<bignose> Bazaar-NG branch format 5
<abentley> This looks like a standalone tree whose repository is missing.
<abentley> You actually deleted the .bzr directory, eh?
<bignose> well, the current '.bzr' directory is one that was backed up by the 'bzr upgrade' process, so unless that has modified it somehow, it was working fine as a checkout.
<abentley> I think that has modified it somehow.
<bignose> yeesh.
<bignose> it's not a simple 'mv .bzr .bzr.backup' ?
<lifeless> its a cp -r
<abentley> Specifically, I think that your repository was moved from the old .bzr into the new one as part of the upgrade.
<lifeless> abentley: err no.
<lifeless> abentley: .bzr.backup is done by t.copy_tree(.bzr, .bzr.backup)
<lifeless> abentley: so the old repository doesn't move at all
<bignose> okay. at this point I'm ready to blow away this directory and check it out again.
<abentley> lifeless: Okay, so why wouldn't there be a repository directory?
<bignose> should I do so?
<lifeless> bignose: hang on a sec please
<bignose> okay
<abentley> bignose: if you have significant local changes, I can show you how to retain them.
<lifeless> bignose: lets get a root cause so we can fix/prevent in future
<lifeless> bignose: can you do ls -l .bzr
<lifeless> bignose: and ls -l .bzr.backup
<abentley> lifeless: he has deleted the .bzr that upgrade produced and moved .bzr.backup to .bzr
<bignose> lifeless: bear in mind that '.bzr' has been restored from '.bzr.backup'
<bignose> so the only thing we'll see in '.bzr' is whatever was put into '.bzr.backup' by the upgrade
<lifeless> abentley: ah
<lifeless> bignose: all the same, lets see whats there :)
<bignose> okay. paste flood cometh
<bignose> $ ls -l .bzr
<bignose> total 20
<bignose> drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 branch
<bignose> -rw-r--r-- 1 bignose bignose   35 2008-02-27 10:40 branch-format
<bignose> drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:40 branch-lock
<bignose> drwxr-xr-x 3 bignose bignose 4096 2008-02-27 10:40 checkout
<bignose> -rw-r--r-- 1 bignose bignose   82 2008-02-27 10:40 README
<abentley> lifeless: tag, you're it.  I need to buy groceries.
<bignose> abentley: thanks for your help
<lifeless> abentley: thanks :)
<lifeless> bignose: ok; now cat .bzr/branch/format
<bignose> Bazaar-NG branch format 5
<lifeless> bignose: is there meant to be a shared repository above this one ?
<bignose> yes.
<lifeless> above this directory I mean
<lifeless> ok
<lifeless> this all looks fine to me
<lifeless> is it working correctly at this point
 * bignose really hopes this doesn't lead to the discovery that the shared repo is gone.
<bignose> lifeless: no. 'bzr info' complains there's no repository.
<lifeless> ok
<lifeless> where is the repository meant to be?
<bignose> argh.
<bignose> 'bzr info ~/Projects/' gives no output :-(
<lifeless> (a relative path is fine if you don't want to paste an abs path)
<bignose> $ ls -l ~/Projects/.bzr
<bignose> total 16
<bignose> -rw-r--r-- 1 bignose bignose   35 2006-09-02 09:54 branch-format
<bignose> drwxr-xr-x 2 bignose bignose 4096 2006-09-02 09:54 branch-lock
<bignose> -rw-r--r-- 1 bignose bignose   82 2006-09-02 09:54 README
<bignose> drwxr-xr-x 5 bignose bignose 4096 2007-11-14 15:42 repository.backup
<lifeless> there is a distinct lack of 'repository' there
<lifeless> repository.backup is from november
<lifeless> now, there are multiple possible reasons
<lifeless> one is a catastrophic bzr bug
<bignose> $ ls -l ~/Projects/.bzr.backup/
<bignose> total 16
<bignose> -rw-r--r-- 1 bignose bignose   35 2008-02-27 10:45 branch-format
<bignose> drwxr-xr-x 2 bignose bignose 4096 2008-02-27 10:45 branch-lock
<bignose> -rw-r--r-- 1 bignose bignose   82 2008-02-27 10:45 README
<bignose> drwxr-xr-x 5 bignose bignose 4096 2008-02-27 10:45 repository
<lifeless> ok yay
<lifeless> bignose: here is what I think has happened.
<lifeless> bignose: I'll get you to cat a format file in a second to confirm
<lifeless> what I think is:
<lifeless> you are running subtree or rich-root
<bignose> if it helps, I previously in this session also ran 'bzr upgrade --rich-root-pack ~/Projects/'
<lifeless> and you tried to upgrade the repository to something with less data
<lifeless> the upgrade failed; leaving the backup intact but the repo borked.
<bignose> which gave "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
<lifeless> bignose: can you cat the repository/format file from the projects repository backup
<bignose> which directory? '~/Projects/.bzr/repository.backup/format' or '~/Projects/.bzr.backup/repository/format' ?
<bignose> or something else?
<lifeless> '~/Projects/.bzr.backup/repository/format'
<bignose> $ cat .bzr.backup/repository/format
<bignose> Bazaar Knit Repository Format 3 (bzr 0.15)
<lifeless> bignose: ok, I'm correct.
<lifeless> bignose: I will file a bug in a minute.
<bignose> good to know :-)
<lifeless> bignose: now, here is the cause:
<lifeless> we have three discreet data models
<lifeless> call them 'plain', 'rich root', 'subtrees'
<lifeless> they are ordered: plain<rich-root<subtrees
<lifeless> commits done to plain can be upgraded to rich-root (which pull will do automatically), but not downgraded.
<lifeless> (the reason for this is long and involved; skip it for now)
<lifeless> likewise rich-root commits can be upgraded to subtrees but not downgraded.
<lifeless> what you asked bzr to do is to convert a subtrees repository to a rich-root repository, which it doesn't know how to do (as it would have to toss away data)
<lifeless> so -
<lifeless> reinstate your repository by discarding ~/Projects/.bzr and mv ~/Projects/.bzr{.backup,}
<bignose> okay
<lifeless> and now upgrade it to pack-0.92-subtree
<lifeless> all the trouble with the checkout was pure confusion due to the shared repository being awol
<bignose> alright. but all this started *before* I attempted the upgrade, with a commit that failed because of format incompatibilities.
<lifeless> ok
<bignose> so I'll have to try that again and make sure there isn't more upgrading to be done.
<lifeless> get this upgrade done
<lifeless> and I'll predict what the problem was
<bignose> so, what upgrade do I need to do now that I've restored the backup shared repository?
<lifeless> bzr upgrade --pack-0.92-subtree ~/Projects/'
<lifeless> I predict you have a heavyweight(the default) checkout of a project in a 'plain' repository
<bignose> doing now
<lifeless> Your local data has been upgraded to subtrees
<lifeless> and the commit is failing because your local commit can't be represented in that other repository.
<bignose> okay. so 'bzr upgrade --rich-root-pack ~/Projects/' was a mistake?
<lifeless> yes
<bignose> argh. please cluebat the appropriate people in this channel then, for suggesting that I do that
<lifeless> next week we're planning how to change our defaults
<lifeless> to remove all this pain as quickly as possible
<bignose> okay, the shared repo is upgraded
<bignose> I will now attempt the commit again on the checkout branch
<lifeless> it will fail
<lifeless> because the problem is not your local data, its the remote data
<lifeless> in that the remote data is in a plain format (or -rich-root) and yours is in subtree
<bignose> Permission denied: ".bzr/repository/upload/crezvop7l0z8hop1rxvb.pack": [Errno 13] Permission denied
<bignose> okay. so what needs to happen next?
<lifeless> uhmf
<lifeless> thats an interesting error
<lifeless> thats after the upgrade finished?
<bignose> okay, probably time for a quick roundup of what format everything is at
<bignose> checkout branch: Bazaar-NG branch format 5
<bignose> local shared repository: Bazaar pack repository format 1 with subtree support (needs bzr 0.92)
<bignose> remote central branch: Bazaar-NG branch format 5
<bignose> remote shared repository: Bazaar pack repository format 1 with rich root (needs bzr 1.0)
<lifeless> bignose: yup, its clear there :)
<lifeless> bignose: the original problem was:
<lifeless> local repo: subtree
<lifeless> remote repo: rich-root
<bignose> all done by 'cat ./bzr/{branch,repository}/format' as appropriate.
<lifeless> the use of knits/packs/etc is orthogonal to the model of data being stored.
<bignose> so what's next? upgrade the remote repository?
<bignose> with 'bzr upgrade --pack-0.92-subtree' ?
<lifeless> if that is an option, then yes that will stop the error occuring. Or, if that is not an option or not trivial to do, then you can create a local repository that is rich-root only and use that
<bignose> well, I have write permission on the remote shared repository. is there a reason I shouldn't upgrade it to that format?
<lifeless> all your other devs will get errors updating when you upgrade the central repository though; because across model boundaries you cannot do bidirectional push-pull
<bignose> also, didn't you just take me through the necessity of *not* having the local shared repository as rich-root?
<lifeless> yes, remember the relationship of the models:
<lifeless> plain<richroot<subtree
<lifeless> for whatever reason your _existing_ repository was at subtree
<bignose> local repository?
 * jdong gives jelmer a big hug
<lifeless> *you* can't go down from here for your existing projects
<lifeless> existing local repository yes.
<jdong> thanks for bzr-svn goodness :)
<bignose> lifeless: okay. so if I upgrade the central (remote) shared repository, everyone else needs to upgrade their own repositories for all checkouts?
<bignose> lifeless: any other downsides? i.e. will I regret doing this in six months?
<lifeless> yes, and if you have multiple projects in each repository, and there are other places you are collaborating with, this will propogate
<lifeless> We will be changing our default format to be rich root, and then subtrees, in the 'near' future.
<bignose> what about just branching from these repositories?
<bignose> will those also need to be at the same format?
<lifeless> yes - think of it as water and ink - once you have the subtree ink in the water, it goes everywhere and can't be taken out.
<bignose> grah.
<lifeless> bignose: the easiest option for you is to use a separate repository for this tree on your local disk
<bignose> can't I just downgrade to "rich-root" and *discard* the extra information that can't be represented in the rich-root format?
<lifeless> bignose: e.g. bzr init-repo --rich-root-pack ~/Projects/Foo && bzr checkout REMOTEURL ~/Projects/Foo/bar
<lifeless> bignose: that will make anything in Foo be rich-root only and commits will work fine
<lifeless> bignose: no, because the information loss would round trip - you could downgrade and upgrade and end up with two revisions claiming to be identical but with different values; bzr will consider that a hostile attack and barf at you.
<lifeless> ^ no you can't just strip the information
<spiv> (I suppose this could almost be a use case for rebase...)
<lifeless> spiv: tag you're it.
<lifeless> spiv: I have a plane to catch.
<spiv> Heh.
<spiv> lifeless: ok.
<lifeless> two bugs files
<lifeless> *filed*
<spiv> lifeless: thanks
<lifeless> bignose: I *hope* its clearer now.
<bignose> I'll have to attack this another day, I'm way late.
<bignose> lifeless: it's more complicated :-)
<bignose> lifeless: but thanks for the help
<lifeless> bignose: mail me if you like, and I'll give you a reply my tomorrow (your friday - I'll be in London)
 * spiv wonders if subtree revisions with no subtrees in them could be represented adequately in a rich-root repo...
<bignose> talk with you all later
<ubotu> New bug: #195970 in bzr "bzr upgrade --rich-root-pack fails badly when upgrading subtree	repositories" [Undecided,New] https://launchpad.net/bugs/195970
<ubotu> New bug: #195971 in bzr "checkout silently upgrades repo data" [Undecided,New] https://launchpad.net/bugs/195971
<spiv> ubotu: nice timing
<ubotu> Sorry, I don't know anything about nice timing - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<spiv> Pfft.
<spiv> lifeless: have a good trip
<jelmer> spiv: yes, they can be represented in a rich-root repo correctly
<jelmer> ideally we should be able to support downgrading from subtree to rich-root if there are no nested tree revisions in the repo
<spiv> jelmer: hmm.  In that case, it seems like a "bzr upgrade" from subtree to rich-root ought to be allowed if all revisions in the repo are representable.
<spiv> jelmer: snap :)
<spiv> Hmm, if this is true for bignose, he ought to be able to do that manually by "bzr init-repo --rich-root-pack" somewhere, and then pulling all the revisions across.
<abentley> spiv: That does work AIUI
<abentley> But there's no code that actually checks the revisions to ensure they have no subtrees, so it will break noisily if they do.
<lifeless> abentley: the model check fails
<lifeless> abentley: bzr won't do it.
<bob2> lifeless: is pack-0.92-subtree an alias for development-subtree?
<lifeless> bob2: no
<lifeless> bob2: the development formats are compatible with but have their own disk signatures.
<bob2> "bzr help formats" needs an updatin'
<abentley> bob2: What needs to change?
<abentley> lifeless: Actually, I'd prefer if development-subtree were hidden.
<bob2> abentley: pack-0.9.2-subtree isn't mentioned in upgrade --help or help formats
<abentley> bob2: That is emphatically deliberate.
<abentley> No one should be using it, except people implementing nested tree support.
<bob2> ah
<mwhudson> did repository.get_revision(NULL_REVISION) ever work?
<lifeless> mwhudson: no
<mwhudson> hm
<mwhudson> i wonder how loggerhead ever worked with empty branches then
<mwhudson> ho ho ho
<lifeless> its xmas?
<mwhudson> this seems surprising: http://paste.ubuntu-nl.org/57545/
<lifeless> mwhudson: well, its not that friendly true, but I don't think we expect people to use the attributes for flow control
<lifeless> rephrase
<lifeless> don't use the attributes for flow control, kthxbye
<mwhudson> so what loggerhead does, which is probably totally dumb
<mwhudson> is it goes
<mwhudson> revs = bzrlib.get_revisions(long list of revids)
<lifeless> which can raise
<mwhudson> catches NoSuchRevision, throws e.revision out of the list and tries again
<lifeless> thats dumb
<lifeless> do this
<lifeless> parents = repository.get_graph().get_parents(revids)
<lifeless> missing = rev_ids - set(parents.keys())
<mwhudson> so given that i don't actually care about what's in the missing set
<lifeless> mwhudson: well, you get the point, kthxcode
<mwhudson> repo.get_revisions(repo.get_graph().get_parents(revids))
 * igc lunch
<mwhudson> lifeless: http://paste.ubuntu-nl.org/57546/
<mwhudson> looks like a typo ...
<lifeless> mwhudson: get_parents_map
<lifeless> my bad
<mwhudson> ok
<mwhudson> that's a pretty aggressive deprecation though :)
<lifeless> mwhudson: its meant to work, I think that is indeed a typo, but anyhow
<ubotu> New bug: #196002 in bzr-svn "lack of bzr 1.2 support" [Undecided,New] https://launchpad.net/bugs/196002
<jml> I'm not really sure what to type for my message when I say "bzr record"
<jamesh> jml: you could say what music you are listening to at the time
<jml> I hate it when people do that.
<jml> in commit messages, that is.
<jamesh> jml: they should really use revision properties, yes.
<jml> heh heh
<jamesh> maybe we need hooks to let plugins add revision properties
<jml> jamesh: they already can
<jamesh> really?
<Peng> One file in Mozilla's CVS has been committed with each message a line from a poem or whatever... :)
<jml> jamesh: it's just that cmd_commit is ugly
<jml> or maybe I'm on crack
<jamesh> jml: I was referring to the actual bzrlib hooks feature
<jml> oh.
<jamesh> not something that requires replacing cmd_commit, and only letting one plugin do stuff
<jml> lifeless: how do I break a thread out into a separate branch?
<jml> bzr branch -r thread:foo loomed-branch foo-branch doesn't seem to do what I expect
<spiv> jml: you could always use the revid
<jml> spiv: how would I calculate the appropriate revid
<spiv> jml: "bzr revision-info" while in the desired thread
<spiv> jml: (or peek in the .bzr/branch/last-loom file)
<spiv> jml: It would be good if "bzr branch -r thread:foo ..." worked, though.
<jml> nope, that didn't work either
<jml> maybe I have been allowed to do something stupid
<jml> this is going to make it difficult to land this branch.
<spiv> jml: You mean "bzr {up,down}-thread" to the desired thread, followed by "bzr branch -r revid:$(bzr revision-info | sed -e 's/^[ 0-9]\+//') . foo-branch" doesn't work for you?
<jml> spiv: yes, I mean that.
<jml> except I also want to imply that your sedding is ridiculous.
<spiv> :)
<jml> tbh, I was a little surprised that having the thread selected wasn't enough
<spiv> jml: that method works for me
<spiv> jml: in what way is it not working for you?  An error, or branching the wrong revision, or...?
<jml> spiv: the whole branch is being branched
<jml> all of the changes in the threads *above* the thread I want are being pulled in.
<spiv> You mean as a loom?
<spiv> ("the whole branch is being branched" sounds like a *good* thing...)
<jml> spiv: my original question was "how do I break a thread out into a separate branch?"
<jamesh> jml: try this: 1. "bzr init" a new branch in non-loom format, 2. pull or push the desired thread into that new branch
<spiv> So "bzr revision-info" in the new branch doesn't match "bzr revision-info" in the thread you are trying to extract?
<spiv> (It would be nice if there were a "explode-loom" command for this...)
<jml> spiv: they aren't equal, no.
<spiv> jml: so, for me, the commands I gave give me the same revision-info (and appropriate log) on both sides.
<jml> ok.
<spiv> jml: (although the new branches are also in loom format, but they don't have any threads, so technically they meet your stated requirements)
<jml> I don't really care about the format.
<spiv> jml: I'd be interested to hear how jamesh's instructions work for you
<jml> spiv: so all I need is for you to come over and explode the branch for me :)
<jamesh> judging by the README in bzr-loom, those instructions should do it
<spiv> jml: but I also don't know why my method isn't working for you.
<jml> jamesh: that works
<Peng> jelmer: bzr-svn's setup.py uses python2.4. Why not 'python'?
<spiv> Peng: that's a good question, but on the other hand it's common to explicitly do "python setup.py ..." rather than just "setup.py ...", so that you're explicit about the python version you're using.
<Peng> spiv: True. (I partially do it because I've run into setup.py files not being executable.)
<Peng> spiv: I ran into it because I ran "make" and that runs "./setup.py".
<Peng> s/not being/that aren't/
<jml> crap.
<jml> does combine-thread lose changes?
<spiv> jml: I wouldn't expect it to... you mean uncommitted changes?
<jml> spiv: I mean committed changes.
<jml> oh well, it's too late now.
<spiv> jml: well, you can always get those back with the heads plugin
<spiv> jml: although it's probably a bug if combine-thread lets you lose changes.
<spiv> s/probably//
<jml> how?
<spiv> jml: (Also, if you had recorded the loom before the combine-thread, you could also recover that way)
<jml> I had
<spiv> jml: the "bzr heads" command will show you all the "heads" of the revision graph your repo
<spiv> jml: i.e. all revisions that aren't referenced as a parent by another revision, thus are the head of a line of development.
<jml> spiv: ah, ok. it's not showing, so maybe I hadn't committed these changes
<spiv> jml: there's probably a smallish number of those in your repo (unless you've been doing something crazy in your repo), so it should be easy for you to find the revision in that list, then do "bzr branch -r revid:..." to get it as a standalone branch.
<spiv> jml: Also, I *think* the "bzr revert-loom" command should take the loom back to the last "bzr record"ed state, but I haven't used that command.
<jml> let's see!
<jml> yep.
<Peng> Hahaha.
<Peng> Of course my ConfigObj change finally gets merged right after I notice an error in it.
<spiv> Peng: d'oh
<ubotu> New bug: #196043 in bzr "Crash in bzr-svn trying to brancy python trunk" [Undecided,New] https://launchpad.net/bugs/196043
<AfC> Well the least I can do is fix the description of that bug.
<Peng> I just got that too on another project.
<Peng> I converted it with hg instead. :P
<Peng> Well, with bzr-svn, it barfed on one of the tags. Hg just didn't import any tags...
<Peng> Totally throwaway conversion anyway.
 * igc dinner
<luks> hm, does somebody know if launchpad uses shared repositories for mirrored branches?
<spiv> luks: no, it doesn't.
<spiv> luks: all the branches on launchpad at the moment are standalone.
<spiv> luks: why do you want to know?
<luks> ok, thanks
<luks> well, it I tell it to mirror N branches of the same product, using a shared repository would save bandwidth on both sides
<luks> *if
<spiv> luks: yeah, that's true.
<spiv> luks: there is work underway to improve this.
<awilkins> Even if the branches at LP aren't inside shared repos, if your local branches are, if they share common ancestry you should still have savings,yes?
<luks> not bandwidth savings, only disk space
<luks> LP will still download them one by one with full history
<awilkins> Should it not just be able to download some indexes and determine which revisions you already have?
 * awilkins speaks in general ignorance of internal format, forgive him
<luks> that's what shared repositories are for :)
<luks> if the revision data are not shared, it doesn't know which revisions it already has
<awilkins> Yes, but if you are branching an LP branch into a shared repo that contains other branches of the same ancestry, your local repo knows which revisions it has ?
<luks> ah, you mean the other way around
<awilkins> So it could get away with getting a revision list from the server and only downloading stuff it's missing?
<luks> yes, in that case it will download only the revision it needs
<awilkins> Ah, aI am reassured
<unenough> how do i create a copy of an old revision of a file?
<awilkins> I thought it could, with all the HTTP range downloading stuff in there
<awilkins> unenough: bzr cat -r <rev> path/to/old/file > myoldfile
<unenough> awilkins, thanks.
<spiv> unenough: or "bzr revert -r REV path/to/file"
<unenough> i didn't want to revert, just view it
<unenough> cat is good
<unenough> but thanks
<quicksilver> bzr cat is awesome :)
<ubotu> New bug: #196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Undecided,New] https://launchpad.net/bugs/196080
<ubotu> New bug: #196082 in bzr-loom "checkout of loom produce regular branch" [Undecided,New] https://launchpad.net/bugs/196082
<awilkins> Is Guillermo Gonzalez here?
<awilkins> Or anyone else who cares about bzr-eclipse?
<Lo-lan-do> Hi all
<Lo-lan-do> Any plans to update bzr-svn in Debian sid?  It prevents upgrading to bzr 1.2...
<jelmer> I hope to release 0.4.8 this weekend
<Lo-lan-do> Yay :-)
<Lo-lan-do> Another question: when I pull from a pure bzr branch to a branch bound to a remote SVN repo, there seem to be many many HTTPS connections, and the entire process is rather slow.  Is that inherent to the way SVN works, or can that theoretically be fixed?
<lamont> given a commit, how do I tell bzr to tell me what files were changed in that commit?
<luks> bzr st -r X
<lamont> thanks
<luks> er, no
<luks> bzr st -c X
<luks> which is an equivalent for bzr st -r (X-1)..X
<jelmer> Lo-lan-do: what version of bzr-svn are you using?
<jelmer> Lo-lan-do: Theoretically a lot of it can be fixed
<Lo-lan-do> 0.4.7-1
<fbond> Hi, I really want to be able to "bzr update -r xxx" in a checkout; what am I really looking for?
<fbond> I want to be able to "rewind" my checkout (not just the working copy).
<fbond> I know I could make a new checkout, but it seems like this should be easier...
<jelmer> fbond: there's no way to do that at the moment
<jelmer> afaik there are several bug reports open a bout supporting -r for bzr upgrade
<jelmer> s/upgrade/update
<fbond> jelmer: second time you've helped me today, thanks!
<jdong> jelmer: why is "bzr missing" so significantly more costly than "bzr pull" for bzr-svn?
<jelmer> it uses a different (not yet optimized) code path
<jdong> ah, ok
<jelmer> pull is a lot more common so I've spent more time optimizing
<jdong> jelmer: are there any better ways of looking for new upstream commits rather than pulling into a branch?
<jelmer> "bzr missing" :-)
<jdong> :)
<jdong> jelmer: do you know if any DVCS svn converters like bzr-svn work well with gigantic history svn repos?
<jdong> I'd like to follow a specific branch of KDE's anonsvn and don't feel like dealing with a few million revision history
<jelmer> git-svn probably although I don't have experience with it
<jelmer> If you're just interested in following upstream you may want to wait until after the bzr sprint
<jelmer> with a bit of luck we'll be have shallow branches support then
<jdong> sweet
<Lo-lan-do> Sweet indeed :-)
<jdong> jelmer: does bzr-svn currently deal well with subtrees of svn repos? Like if I just want to follow ktorrent in kde's SVN, would that be an intensive operation?
<jelmer> jdong: What do you mean with subtrees exactly? svn:externals?
<jdong> jelmer: like a subdirectory of a svn repo
<jelmer> jdong: Yes, it can do that but the size and number of files in the repository still matter at the moment.
<jdong> jelmer: so would it still be prohibitively expensive, in your opinion, to bzr branch a single app's dir from anonsvn.kde.org?
<jdong> the entire repo has a bazillion revs but I doubt more than 1000 pertain to ktorrent itself
<Peng> Should I kill svn-import when it hasn't done anything but slightly fluctuate its RAM usage for 6 hours?
<jelmer> jdong: caching those revs the first time will be pretty expensive
<jelmer> jdong: After that, all KDE-repository-related operations should be pretty quick
<jelmer> jdong: s/Caching the revs/caching the revs' metadata/
<jelmer> Peng: Depends on the size of the repository
<jdong> jelmer: sounds painful...
<jelmer> Peng: It does support resuming
<jdong> jelmer: does the svn-cache take a lot of disk space?
<Peng> jelmer: 60k revisions?
<jelmer> Peng: Could be. I should show a progress bar though.
<abentley> Peng: When you generate new merge directives, please generate them against a fresh copy of trunk.
<jelmer> jdong: yes, although I'm not sure how much that would be for KDE
<abentley> That way the diff shows the changes that aren't already in trunk.
<jelmer> jdong: For samba (26k revs) it's 50 Mb
<luks> I remember mine for the KDE SVN beeing around 2GB :/
<jelmer> luks: it should be smaller now than what it used to be
<jdong> luks: ouch
<luks> oh
<Peng> abentley: Yeah. I only pulled and noticed that it had been merged right after sending that patch.
<abentley> Okay.
<Peng> If I noticed it had been merged, I would've been more apologetic. :
<Peng> P
<Peng> :P
<abentley> Peng: Submitting your latest.
<Peng> Thank you. Sorry.
<mvo> lifeless: do you have a sponsor for bzr-loom yet?
<Qhestion> can a plugin store metadata in branches, or do i have to use normal (versioned) files?
<mwhudson> does someone want to merge http://bundlebuggy.aaronbentley.com/request/%3C47C4A6D2.7080508%40canonical.com%3E ?
<mwhudson> -or- remind my how to use bzr-svn
<mwhudson> oh, it helps if you get the url right
<mwhudson> oh, wow, there's already a lp import of the branch i wanted
<Verterok> awilkins: ping (I'm Guillermo)
<abentley> mwhudson: bialix was the last reviewer, so he should have merged it.
<mwhudson> oh, ok
 * mwhudson is pleased with his 10 minute hack of pyflakes to understand lazy imports...
<mtaylor> GAH
<mtaylor> bzr: ERROR: Repository KnitPackRepository('file:///home/mtaylor/package/python-modules/python-mysqldb/.bzr/repository/') is not compatible with repository SvnRepository('svn+ssh://mtaylor-guest@svn.debian.org/svn/python-modules')
<mtaylor> I know what the problem is... I'm just complaining
<mtaylor> jelmer: looking for bzr svn-import advice...
<mtaylor> jelmer: http://svn.debian.org/viewsvn/python-modules/
<mtaylor> has a packages dir, underwhich are a dir for each project, each have possible a trunk and some branches...
<mtaylor> jelmer: should I just svn-import the whole thing and then ignore the branches I don't care about?
<mtaylor> so that the meta-data is all right?
<Peng> Oh my god.
<fullermd> Yes?
<Peng> There's a new version of ConfigObj out!
<Peng> Bwahahaha!
<fullermd> Timing is everything.
<mtaylor> speaking of versions and timing...
<mtaylor> bzr-svn for gutsy in the ppa is not compatible with bzr for gutsy in the ppa
 * mtaylor votes that bzr-svn be considered part of the release... 
<Peng> The new ConfigObj has no changes to configobj.py, just docs and validate.
<Peng> And the license is now executable.
<bob2> mtaylor: did you get that error doing a co of an originally svn branch?
<mtaylor> bob2: yeah, into an init-repo'd dir that I just let init-repo to the default
<mtaylor> bob2: it worked fine if I did init-repo --rich-root-pack instead
<bob2> mtaylor: ah, right, that's the workaround
 * mtaylor votes that rich-root-pack become the default
 * mtaylor votes again that bzr not be released to the ppa without corresponding bzr-svn packages too
 * mtaylor votes himself a free lunch
 * bignose concurs. mtaylor is now a free lunch.
<fullermd> And me without my skewers today   :(
<jam> lifeless: ping, question about redefining some of the sources of knowledge for content versus indexes
<jam> specifically, I'm thinking about making the ancestry accessible from the Content objects rather than the Index
<jam> does that make sense? or will we always want to have the overall ancestry in the index
<jam> pff, I just remembered that lifeless is traveling for the next few days
<jam> :(
<igc> morning all
<igc> hi jam
<beuno> morning igc
<igc> hi beuno
<beuno> igc, started packing for the sprint yet?
<igc> I'm not sure I want to answer that :-)
<igc> 'just in time' rules :-)
<beuno> heheh, I started packing 2 hours before leaving to the airport, and so far, I don't think I've forgoten anything
<abentley> Last time I went to London I forgot my laptop power brick.
<beuno> aah, laptop and power brick is the only thing I triple-checked. I might of not brought any clothes with me though  :p
<alien> hello, you claim that bzr only needs python at runtime, but it seems it still needs a C compiler if one needs to compile its sources
<abentley> alien: One doesn't need to compile its sources.
<beuno> alien, not really, the c bits are only to push performance a bit more, it runs fine on python-only libraries
<alien> couldn't you provide some kind of backup python code for those modules written in C
<abentley> They are strictly optional optimizations.
<abentley> We do in fact provide backup python code.
<alien> i'm trying to port bzr to minix
<alien> and it lacks a linker, since its binaries are static
<alien> the bzr setup is running fine but bzr init explodes
<spiv> alien: can you pastebin the error?
<alien> sure
<alien> http://rafb.net/p/AA29No74.html
<alien> and here's the compilation error of the C sources: http://rafb.net/p/oRx27w34.html
<alien> it sais it's using the py version instead
<alien> but it seems i'm missing pyexpat
<alien> shouldn't plain python be sufficient?
<dato> alien: pyexpat.so is supposed to be built along with python itself (if expat is available, that is, of course)
<spiv> alien: xml.parsers.pyexpat is part of the Python standard library
<alien> miix lacks an expat port
<alien> minix*
<blueyed> lifeless: the /etc-messed-up system now runs again. bzr is a good regression test (in the sense of corner cases) for Ubuntu in the right hands. Just like "find /etc -type l -type -d | xargs /bin/rm" and then trying to get the system running on the next boot again.. ;)
<blueyed> ...like /dev/null should get right permissions without udev properly setup.
<blueyed> I think the best thing to do about "bzr revert" is to at least warn in the help text about it. Or get saner in the case of "bzr init; bzr add; bzr revert" - I can't see a reason why the previous commit state would be "empty".
<mtaylor> statik: around?
#bzr 2008-02-28
<blueyed> Is there a "maintain /etc using bzr" wiki page somewhere around already?
<Peng> etckeeper?
<Odd_Bloke> mwhudson: Regarding your list email(s), you wrote "It produces rather a for bzrlib currently".  I believe jam was wondering what it produces for bzrlib. :)
<mwhudson> Odd_Bloke: yeah, he replied
<Odd_Bloke> mwhudson: Aw, lag. :)
<mwhudson> Odd_Bloke: thanks for trying though :)
<Odd_Bloke> mwhudson: No worries.
<jelmer> mtaylor: yes, you can svn-import everything and remove what you don't need or run bzr branch on the things you are interested in
<Odd_Bloke> jelmer: o/
<blueyed> Peng: etckeeper for bzr?
<jelmer> 'evening Odd_Bloke :-)
<jelmer> blueyed: yes, there's etckeeper support for bzr
<jelmer> although it's not entirely finished yet because bzr doesn't have a start-commit hook
<blueyed> jelmer: i think I've set it up manually now, except for the metathingy.. found http://kitenet.net/~joey/code/etckeeper/
<blueyed> sounds great though.
<blueyed> does it make sense to lock a branch for 33+ hours? (like bazaar.launchpad.net/%7Eplanet-ubuntu/config/main/)
<spiv> blueyed: probably an accident.
<spiv> blueyed: e.g. someone getting disconnected while trying to do a commit.
<blueyed> spiv: sure, but there should be amore sensible timeout.. e.g. like "no data received in 2 minutes" => revert
<mtaylor> jelmer: thanks
<spiv> blueyed: Perhaps, or for connection-oriented smart server sessions it could unlock after the connection drops.
<awmcclain> I'm looking for a GUI for OS X that will just let me see which files have changed/added/coflicts (bzr st), allow me to merge side-by-side, and allow me to resolve conflicts and mark files as resolved. Some combination of apple's diff or vimdiff? Any thoughts?
<spiv> awmcclain: maybe http://www.sorn.net/projects/wildcat-bzr/?  I haven't tried it myself.
 * spiv -> lunch
<Verterok> awmcclain: did you tried qbzr?
<awmcclain> Nope.
<abentley> jam: You don't mean having the ancestry *only* in the content objects, do you?
 * igc lunch
 * jdong cries
<jdong> git doesn't care bout empty directories
<RAOF> Git doesn't care about sanity, either :P
<mwhudson> directories are a myth!  or something
 * mwhudson leaves
<jamesh> jdong: empty directories are not files, so are not important
<jamesh> in fact, directories aren't files, so it doesn't consider them to be important
<abentley> jdong: I'm kinda surprised, considering git's equivalent to inventory is a stack of nested trees.
<abentley> So their data model explicitly includes directories, and it should be easy for them to support empty ones.
<robotgeek> hi, could anyone help with bzr? i am a bit confused about checkout vs merges vs branches
<bob2> ask away
<robotgeek> I was trying to follow https://wiki.ubuntu.com/DocumentationTeam/Repository (Advanced Methods -> Downloading a tarball of the revision history)
<robotgeek> then, i did a checkout of a working tree of one branch
<robotgeek> using bzr checkout .
<robotgeek> then i did a bzr merge of the documentation tree that I am supposed to be working on from the website.
<robotgeek> now "bzr status" shows pending merges, which I don't follow (i tht after the merge, i am supposed to have a exact copy of what is on the url )
<bob2> no
<bob2> merging A into B pulls all the changes from A into the checkout of B.  you need to commit after merging to make those changes part of the B branch.
<bob2> (but do not make any other changes after merging but before committing - except fixing conflicts or fixing errors from the merge)
<spiv> robotgeek: if you want your checkout to be an exact copy of the URL, use "bzr pull"
<robotgeek> spiv: will it override the merge command?
<spiv> robotgeek: no, you'd need to revert the merge
<spiv> robotgeek: a merge is an edit to the checkout, like editing the files with your text editor
<robotgeek> spiv: am i looking for remerge?
<spiv> robotgeek: no, remerge reapplies the merge you just did in a slightly different way
<spiv> robotgeek: but it doesn't sound like you want a merge at all
<robotgeek> heh, is there a single command i can use to undo the merge? or do i need to repeat my process all over again?
<spiv> robotgeek: Merging is a way to combine the changes in two different branches
<spiv> robotgeek: "bzr revert"
<spiv> robotgeek: sorry, I should have been more explicit about what I meant by reverting :)
<robotgeek> hmm, similiar to svn.
<spiv> Right.
<spiv> "bzr revert" undoes any uncommitted changes.  And merging changes from another branch are changes like anything else, so you can revert them if you don't want them.
<robotgeek> spiv: thanks. it now crashes on ssh key.
<spiv> Can you pastebin the error?
<robotgeek> spiv: http://pastebin.com/m5a342010
<spiv> robotgeek: ah, two problems there
<spiv> robotgeek: one is that you have an old-ish version of bzr that crashes rather than gives a friendly error message when this happens
<spiv> robotgeek: the other is right up the top: "Launchpad user 'venkat' doesn't have a registered SSH key"
<robotgeek> spiv: why would i need a ssh key to "pull" ? its a read only action, correct?
<spiv> robotgeek: you can add SSH keys to your Launchpad account at https://launchpad.net/~venkat/+editsshkeys
<spiv> robotgeek: it is, but you're trying to access a bzr+ssh:// URL, which requires SSH, which requires authentication.
<robotgeek> spiv: i did not know that i was accessing with ssh :) alrite, one more thing to do!
<RAOF> Was the launchpad plugin introduced to bzr after version 0.90?
<spiv> robotgeek: you could use "http://..." instead of "bzr+ssh://..." as the URL.
<bob2> why did bzr/lp redirect the http url give to bzr+ssh?
<bob2> s/give/given/
<spiv> bob2: It didn't, but I'm guessing that the current working directory is a checkout claiming to be bound to bzr+ssh://...
<robotgeek> spiv: but i did use http://
<spiv> robotgeek: what does "bzr info -v" say in that directory?  (pastebin again)
<bob2> spiv: hrm, robotgeek's paste started with "bzr pull http..."
<robotgeek> spiv: http://pastebin.com/m6b5c8a9 you were right :)
<spiv> robotgeek: ok
<spiv> robotgeek: so you probably don't want to be doing that pull into that checkout, anyway.
<spiv> robotgeek: let's step back a moment
<spiv> robotgeek: what do you want to do?
<bob2> duh, missed that it was a co
<robotgeek> i essentially want to work on some kubuntu docs, but the initial branch command was taking so long, i decided to use a tarball of the revision history that was linked to from the documentation site
<robotgeek> spiv: https://wiki.ubuntu.com/DocumentationTeam/Repository , Advanced Methods -> Downloading a tarball of the revision history.
<spiv> robotgeek: if you upgrade your bzr to 1.2, and use bzr+ssh, the initial branch will be *much* faster.
<robotgeek> spiv: okay, will do.
<spiv> robotgeek: I also suggest not using --dirstate-with-subtrees if you do upgrade to 1.2
<spiv> robotgeek: that said, 420MB is a lot of history, so it's going to take some time :)
<spiv> robotgeek: Ah, I see what's going on.
<spiv> robotgeek: ok, the instructions on the wiki are ok, but perhaps not complete.
<spiv> robotgeek: so, you want to unpack the tarball, make a checkout from the history in it, and make sure it's up to date with the live version, right?
<robotgeek> spiv: exactly
<spiv> robotgeek: Ok, so after "bzr checkout .", you should use "bzr update".
<robotgeek> spiv: okay, lemme add ssh key and come back.
<spiv> robotgeek: "bzr merge" on that wiki page is bad advice.  There's one branch involved, so "bzr merge" doesn't make sense, because it's for combining changes from multiple branches.
<robotgeek> spiv: heh, i guess it was written way back, and most of us are still confuzzled with the bzr stuff. plus, i am getting back into this after a long long time!
<spiv> robotgeek: (If you had a separate branch of this project with your own changes, and wanted to merge in new changes from the original branch, that's when you'd use "bzr merge")
<robotgeek> spiv: okay. so if i did something radically new and wanted to merge my changes, i would use that. ok
<spiv> robotgeek: so basically, the tarball hack there is a shortcut that is equivalent to doing "bzr checkout bzr+ssh://..."
<robotgeek> spiv: how do i change what bzr thinks is my launchpad name (lp name is venkatvc
<spiv> robotgeek: which like SVN gives you a checkout of a branch hosted elsewhere.  When you make commits, they are committed back to the central branch.
<robotgeek> it is trying to find my name under venkat, my lpname is venkatvc
<spiv> robotgeek: "bzr launchpad-login"
<spiv> robotgeek: "bzr launchpad-login venkat", to be precise
<robotgeek> spiv: if i am trying to make it venkatvc, it should be bzr launchpad-login venkatvc .
<robotgeek> bzr update still looks under venkat
<robotgeek> spiv: "bzr lp-login" displays venkatvc, but bzr update looks for ssh keys with venkat
<spiv> what does bzr info say?  Does it have a login in the URL?  ("bzr+ssh://venkat@..." ?)
<robotgeek> spiv: it does not, so i am guessing it is using the shell name venkat.
<spiv> "bzr lp-login" only affects "lp:" URLs, not "bzr+ssh:" URLs.
<spiv> Right, that would be what's going on.
<robotgeek> for the ssh part
<spiv> So either include a "venkatvc@" in the URL, or create a .ssh/config
<robotgeek> spiv: thanks, that worked. i will probably save a log of our conversation, and update that page!
<robotgeek> spiv, bob2 : thanks for you help!
<spiv> robotgeek: glad I could help.
<jelmer> awilkins: no, fast-import and bzr-svn aren't compatible (and shouldn't ever be)
<awilkins> jelmer: Bah, never mind.. I'm going to look at fast-import anyway for a nasty MKS repository.
<lifeless> ho jelmer
<jelmer> hola lifeless
<lifeless> jam: hi, in London now, chat at your convenience
<weigon__> jelmer: g'morn
<weigon__> jelmer: who is bulding the bzr-svn ubuntu packages on launchpad ?
<jelmer> I am
<weigon__> can you trigger a build for gutsy ?
<weigon__> of 0.4.7
<weigon__> gutsy is only 0.4.6, hardy has 0.4.7
<jelmer> I'll have a look at releasing 0.4.8 now
<jelmer> weigon__: Or is there a specific reason you need 0.4.7 ?
<weigon> nope, just that the 0.4.6 release requires bzr < 1.2
<weigon> so 0.4.8 is fine too
<jelmer> 0.4.7 does too, there's nothing compatible with 1.2 out yet
<spiv> jelmer: is the strict version checking worthwhile, do you think?
<jelmer> spiv: yes, as we've had a lot of breakages in the past
<spiv> I guess I track the development branch too much to notice :)
<jelmer> In particular because upstream bzr started passing new arguments that bzr-svn didn't support yet
<spiv> It's a shame, because it seems to cause as much hassle as it avoids :/
<jamesh> spiv: maybe bzr should include a list of which versions of bzr-svn it is compatible with :0
<spiv> jamesh: heh
<jamesh> then you wouldn't need a new bzr-svn release for every bzr release
<spiv> Hmm, I wonder if bzr-svn could try to run with a new version, and then only if an internal error occurs, give a "please upgrade bzr-svn" message with the traceback?
<spiv> (and only if the version of bzr isn't a known good version, so real bug reports aren't discouraged)
<jelmer> spiv: heh, that would be a neat hack
<mwhudson> bzr svn-import --im-feeling-lucky
<spiv> jelmer: It extends "easier to ask forgiveness than ask permission" right to the user :)
<jelmer> yup
<jelmer> I guess we can just have a generic variable somewhere with extra text that should be in the traceback
<spiv> jelmer: hmm, you could possibly do it entirely in the plugin
<spiv> jelmer: with a big try/except around your command implementation that inspects the exception, and if it's an internal error *and* bzr-svn is possibly too old, then emit the warning and re-raise the exception.
<spiv> Or re-raise a slightly modified/wrapped exception.
<jelmer> spiv: that means injecting that try/except in a lot of places
<spiv> It'd probably be nice to have proper support in bzrlib.
<jelmer> pretty much every function of the bzr-svn Repository implementation, etc.
<jelmer> yeah
<spiv> jelmer: Possibly just in a single Command subclass?
<jelmer> spiv: bzr-svn provides more than just commands
<spiv> Oh, right, it's not just Commands
<spiv> Yeah, that's tough.
<spiv> You could monkey-patch trace.report_bug ;)
<jelmer> james_w: ping
<jelmer> spiv: Too much trouble :-)
<jamesh> spiv: of course, the only danger is poisoning your repository with incorrectly converted revisions.
<spiv> jamesh: technically true, but I think the sort of errors you'd like have would be unlikely to fail in that sort of way.
<spiv> jamesh: bzrlib tries to be backwards compatible, and even where it fails I think an API change that would cause old code to suddenly start making broken data would be rejected.
<lifeless> well
<lifeless> we advertise an API compatability version
<lifeless> and a current API version
<lifeless> the two should be sufficient to massively reduce surprises
<lifeless> in particular, depending on the minimum API version rather than the current version would be a big improvement
<lifeless> (and slap us if we don't reset it appropriately)
<jelmer> lifeless: in practice, bzr tends to break backwards compatibility sometimes without deprecating first
<jelmer> I'm not sure the extra work for deprecation is worth the effort in all cases though
<lifeless> jelmer: if we break compatibility we are meant to raise api_minimum_version
<spiv> Maybe we should be regularly running the bzr-svn test suite around the time we make release candidates.
<lifeless> jelmer: thats the point of that export, to signal when we have broken api's without deprecating
<jelmer> lifeless: Would there ever be a release without that variable changing though?
<lifeless> jelmer: yes, there have been several
<jelmer> lifeless: 1.1 has been the only one so far I think (ignoring rc's)
<lifeless> jelmer: even so :)
<lifeless> jelmer: existence proof FTW
<jelmer> true, though it would still mean that in pretty much all cases you have to have a matching bzr-svn release for your bzr release
<jelmer> which is not that much of a problem imo
<lifeless> jelmer: it does cause some friction
<lifeless> jelmer:  you might like to play with my hsallow-branch branch
<lifeless> jelmer: it works :)
<jelmer> lifeless: I know, the current situation is not perfect but there are more important issues imho
<jelmer> lifeless: Cool, I'll check it out. What's the branch URL or is there some mailing list post I should look at?
<AfC> lifeless: did you ever get the patch review you were looking for?
<lifeless> jelmer: http://bazaar.launchpad.net/~lifeless/bzr/shallow-branch/
<lifeless> AfC: I have about 10 branches needing revie wnow :) = plane trip -- hacking :>
<AfC> I used to get so much done on flights. Now it is a bit more hit and miss.
<AfC> I've been making progress on a number of things, though, and that's always a nice feeling.
<poolie> AfC: hi, are you up?
<poolie> I'm in Londo
<poolie> n
<AfC> poolie: hey Martin.
<AfC> poolie: I hope you had a good trip up.
<awilkins>  < poolie> I'm in Londo <-   eww, Babylon 5 character action
<awilkins> http://en.wikipedia.org/wiki/Londo_Mollari
<lifeless> awilkins: dude.
<lifeless> AfC: poolie just had 24 hours sitting next to yours truely :>
<awilkins> lifeless: Shallow branching ... that would super-great for bzr-svn :-
<lifeless> awilkins: try it out
<lifeless> awilkins: it probably will break with bzr-svn, but jelmer will want patches :>
<lifeless> in fact, it *will* break with bzr-svn because the current stacking code looks for an exact repository match
<jelmer> lifeless: Speaking of API compatibility, bzr.dev just broke bzr-svn :-)
<lifeless> what we need is more generic stacking, which is  aseparate refactoring that aaron and John and I have been working on/towards
<lifeless> jelmer: ok, we should bump the api version then :)
<lifeless> jelmer: what it did break?
<jelmer> BzrDir.sprout() now takes a hardlink argument
<lifeless> jelmer: ah yes; I wonder if it would be nicer to only pass that when its not the default value
<jelmer> well, even if it would be passed only in some situations it would still be API breakage
<jelmer> there doesn't appear to be anything in NEWS about this, btw
<awilkins> Maybe there should be some kind of API breakage monitoring tool :-)
<awilkins> Are the bzr-eclipse guys in here?
<Verterok> awilkins: hi :-)
<lifeless> jelmer: there is hard-link as a feature, but indeed not as a internals change
<awilkins> Verterok: Hi there ; I'm running with a branch of bzr-eclipse for my purposes, I've been making changes to BzrClient and I have some more ideas for API changes.
<Verterok> awilkins: Oh, great!, I'm working in the client right now :D
<awilkins> Verterok: I've added some of the commands hidden from the help because they are useful for my current project
<Verterok> nice!
<awilkins> Verterok: I'd also really love to see a Jepp version of the client (something that holds the libraries loaded) because the process spawning time is significant.
<Verterok> awilkins: I'm currently working in passing relative paths (to the branch root) instead of full paths, and adding some tests
<awilkins> Verterok: I've just added find-merge-base and revisioninfo because they are useful for automating my current stuff
<awilkins> No tests as yet, I'm too busy just using it :-)
<Verterok> awilkins: I tried to start the Jepp version, but the distribution requiremnts of that client is quite troublesome
<Verterok> awilkins: there is always time to write them ;)
<Verterok> awilkins: I'm hoping the jython guys put a 2.5 aplha out after the PyCon sprint
<Verterok> awilkins: did you tried using bzr service plugin to improve the performance of spawning multiple bzr commands?
<awilkins> Verterok: Not yet.. but thanks for the heads up, I shall look at it if performance becomes very bad
<Verterok> awilkins: are you using the bzrClient outside bzr-eclipse?
<awilkins> Verterok: My principal wish for the API is for all the places that take Revision to take RevisionRange instead. (and make Revision a special case of RevisionRange. And write RevisionRange in the first place)
<awilkins> Verterok: Yes, I'm using it for VCS operations in a publishing system (they want very thorough change reports)
<Verterok> nice :)
<Verterok> awilkins: that sounds ok for me, in regards of bzr-eclipse it's only matter of a simple refactor
<awilkins> Verterok: I was planning on using SVN but their requirements are so heinous I'm abstracting it all and using bzr ; I'll either rewrite the abstractions for SVN, or just use bzr / bzr-svn instead. Or if it's politically OK, just change the underlying repo to bzr anyway.
<jelmer> lifeless: There's only "bzr push --shallow", not "bzr branch --shallow" ?
<awilkins> Verterok: If bzr is ever to run well on IronPython it needs a service plugin because IronPython doesn't cache it's compilation products to disk
<Verterok> awilkins: I think there is no problem of API changes, I'm not aware of any other using the bzrClient
<awilkins> Verterok: That's good.
<Verterok> awilkins: maybe a warning in the wiki-page will suffice.
<lifeless> jelmer: bzr branch --shallow works
<lifeless> jelmer: go to the master copy not the mirror; the mirror is probably out of date
<Verterok> awilkins: are you going to implement the RevisionRange class? (so, we don't duplicate work :))
<awilkins> Verterok: Yeah, I might do at that :-)
<awilkins> Verterok: I'll probably make a branch just for that and merge it to my current stuff
<Verterok> awilkins: Oh, great! thanks! then I'll merge that with trunk :)
<Prodoc> Is anyone else experiencing high Bazaar CPU usage on Windows XP when using the Eclipse plugin?
<Verterok> Prodoc: that should be expected, because bzr-eclipse uses bzr executable under the hood
<Verterok> Prodoc: this is caused by the calculation of the status to decorate the tree
<Prodoc81> Verterok: sorry about that, lost connection
<Prodoc81> can high CPU usage (80%+) for a period of sometimes minutes be expected?
<Prodoc81> this happens after saving a file
<Verterok> it's a know issue, this is cause because after each save bzr-eclipse run status to update the decorators
<Verterok> Prodoc81: sorry, I musst leave for a while
<Prodoc81> np, ok, at least it's a know issue, I'll just disbale the decorators for the time being
<Verterok> ok
 * Verterok bbl
<Prodoc81> disable
<radix> hm. but why would 'bzr st' take minutes?
 * awilkins has a feeling it probably runs it once for each file
<radix> oof
<awilkins> The "Eclipsey" way is probably to have a "FileDecorationListener" that gets called for each file
<awilkins> bzr-eclipse probably needs a status cache server
<awilkins> It might work better with the bzr service plugin that Verterok mentioned earlier
<awilkins> The bulk of the CPU time bzr eats for small operations on win32 is process creation, loading, etc.
<awilkins> It's probably still going to suck though, until there is a way of hosting bzrlib inside the JVM along with the rest of the code.
<jdong> :( why is git using almost 1.5x the space of bzr for the same sized project....
<jdong> and that's after git-gc. I won't flatter git with the number from before.
<edreamleo> Hello all
<edreamleo> I have a question about something that looks like magic...
<Odd_Bloke> edreamleo: Shoot. :)
<edreamleo> Leo has a trunk at: https://code.launchpad.net/leo-editor/
<edreamleo> And the comment with the trunk (I didn't write it, an expert did), says...
<edreamleo> To get a copy of this branch, use the command:  bzr branch lp:leo-editor
<edreamleo> This works, and creates a new folder called leo-editor
<jdong> bzr has support for launchpad URL's
<jdong> it's a bundled plugin with bzr that makes lp: stuff look like URL
<edreamleo> Ah, so lp: means launchpad?
<jdong> yep
<jdong> lp:product-name picks the trunk of that project
<edreamleo> And it's not documented because?
<jdong> edreamleo: see bzr help launchpad
<jdong> it's often documented but not in an obvious spot ;-)
<edreamleo> I see.  Thanks very much.
<jrydberg_> who's maintaining trac-bzr these days?
<abentley> lp: should really be listed in "bzr help urlspec", because failing to list it implies it's not supported.
<awilkins> While we're (vaguely) on the subject, there are commands like find-merge-base and revision-info that are very useful
<awilkins> But not listed in the help
<therve> hello
<awilkins> (ok, they're useful from a low-level perspective)
<therve> I think I've done something stupid with a repos
<therve> http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated
<therve> I don't manage to 'co' it anymore
<therve> if fails with: bzr: ERROR: Repository KnitPackRepository('file:///XXXX/handle-deprecated/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://therve@bazaar.launchpad.net/%7Etherve/pydoctor/handle-deprecated/.bzr/)
<luks> the branch is in dirstate-with-subtree format, which is not compatible with the default format you get after "bzr init-repo"
<therve> ok
<luks> probably converted by older bzr-svn, today you would probably use rich-root-pack or rick-root for that
<therve> hum...
<luks> branching without a shared repository should work fine
<spiv> luks: Weird, I get that error with "bzr co" too, even without a shared repo (i.e. making a standalone checkout)
<luks> or create/update the repository with --dirstate-with-subtree
<spiv> But I don't get it with "bzr branch"
<luks> oh, branch worked fine for me
<luks> bzr co seems to work fine here
<luks> lukas@nemo:/tmp$ bzr co http://bazaar.launchpad.net/~therve/pydoctor/handle-deprecated
<luks> lukas@nemo:/tmp$ cd handle-deprecated/
<luks> lukas@nemo:/tmp/handle-deprecated$ ls
<luks> basic.tac  bin  doc  LICENSE.txt  nevow.cfg  pydoctor  README.txt  server.tac  setup.py  twisted.cfg  www  zibasic.tac
<spiv> luks: try with bzr+ssh:// rather than http://
<luks> are you sure you are not in a shared repo? :)
<spiv> luks: certain :)
<luks> well, I can't use bzr+ssh on that branch obviously
<spiv> luks: why not?
<luks> Permission denied (publickey)
<spiv> luks: you can read any branch on launchpad via bzr+ssh://, you just need to give it a public SSH key.
<spiv> luks: oh, you haven't got a launchpad account with an SSH key?
<luks> I do
<ubotu> New bug: #196607 in bzr "Export command improvements (status, speed)" [Undecided,New] https://launchpad.net/bugs/196607
<luks> but I realized I need to specify username@bazaar....
<spiv> Then you shouldn't be getting "Permission denied (publickey)", that's an authentication error.
<spiv> therve: I fear you might be hitting something like https://bugs.edge.launchpad.net/bzr/+bug/173002
<ubotu> Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,New]
<spiv> therve: although the "bzr co" vs. "bzr branch" part is weird.
<spiv> therve: a workaround would be to use sftp:// vs. bzr+ssh://
<spiv> therve: this is definitely a bug in bzr, rather than user error
<spiv> therve: please file a bug about this, I need to sleep
<therve> spiv: it looks like 'co http:' and then 'switch bzr+ssh' worked
<therve> but good night
<spiv> therve: right, that'd be an equivalent workaround
<edreamleo> Hello all
<edreamleo> This newbie just found another way to crash bzr :-)
<edreamleo> The bug report is at: https://bugs.launchpad.net/bzr/+bug/196618
<ubotu> Launchpad bug 196618 in bzr "bzr push lp: crashes" [Undecided,New]
<edreamleo> This all comes of the bzr branch lp:leo-editor magic
<edreamleo> Previously, that is, when checking out from a url, bzr remembered the url, so...
<edreamleo> bzr push "just worked"
<edreamleo> But somehow bzr didn't remember the url when using lp:leo-editor
<edreamleo> So when I tried bzr push I got...
<edreamleo> bzr: ERROR: No push location known or specified.
<edreamleo> In typical newbie fashion, I just tried something :-)
<edreamleo> bzr push lp:
<edreamleo> And got a traceback
<edreamleo> The output from bzr info is given in the bug report.
<edreamleo> As you can see, there is no push bzr+ssh entry in the info output
<luks> it never sets the push location on 'bzr branch'
<lifeless> edreamleo: bzr push lp: is interesting; its not valid but it would be good if it gave help :)
<edreamleo> So my newbie question is, how do I tell bzr the push location?
<luks> bzr push URL
<luks> URL might be lp:something
<luks> depends where do you want to push it
<edreamleo> So the natural thing would be to create an alias?
<luks> alias?
<luks> why?
<edreamleo> So I can just say bzr push rather than bzr push lp:leo-editor
<luks> it will remember it once you it for the first time
<edreamleo> Ahh...
<luks> *do it
<edreamleo> That's nice.
<luks> or you can use push --remember to change the location
<edreamleo> bzr push lp:leo-editor doesn't work...
<edreamleo> Let me try the real url...
<luks> I think you need bzr launchpad-login or something to make push over lp:XXX work
<ubotu> New bug: #196618 in bzr "bzr push lp: crashes" [Undecided,New] https://launchpad.net/bugs/196618
<edreamleo> I think I'm getting close, but...
<edreamleo> I tried this: bzr push bzr+ssh://bazaar.launchpad.net/~edreamleo/leo-editor/trunk
<edreamleo> A connection was started...
<edreamleo> But it said Auth banner: No such Launchpad account: HP_Administrator
<luks> bzr+ssh://<username>@bazaar.launchpad.net/~edreamleo/leo-editor/trunk
<edreamleo> Ah.  <username>
<luks> but you will need to setup also the putty ssh agent, if you want to use it on windows
<LeoNerd> Lots of false highlights for me here lately :)
<luks> because launchpad only uses SSH key authentification
<edreamleo> But why is the message about HP_adminitrator when bzr whoami give my correct id?
<edreamleo> Yes, I am running pagent
<edreamleo> Let me try the corrected url now...
<radix> edreamleo: it's the ssh transport. ssh defaults to using your current username for remote logins, unless explicitly stated otherwise
<luks> I guess the code that determines the username for ssh is outside of bzr
<radix> edreamleo: and whoami has nothing at all to do with authentication, only what to record as the author of commits
<edreamleo> Thx radix
<edreamleo> The push is cranking away nicely now...
<edreamleo> Clearly, I am the fool that your 'foolproof' code must guard against...
<luks> I'd just blame launchpad :)
<radix> luks: what, because it requires specifying a username?
<abentley> luks: unfortunately, adding AI to launchpad has been delayed to version 3.0 :-)
 * radix looks forward to it :)
<luks> radix: it wasn't really serious
<luks> but I still don't like how bzr works with LP
<radix> ok.
<luks> e.g. that bzr push lp:something works differently based on bzr lp-login
<luks> but it doesn't tell you so
<luks> too many options, just using real URLs would be less consfusing
<edreamleo> Wow, the push is really slow.
<edreamle1> Hmm.  After getting to step 5/5, the ===== line went away but the xp terminal appears hung.
<edreamle1> just opened another console.  bzr status prints nothing, so maybe the bzr push worked...
<radix> edreamle1: "bzr missing <remote_url>" will tell you if the branches are out of sync
<edreamle1> I'm assuming hanging a console isn't the default bzr push 'success' notification :-)
<radix> indeed :
<radix> )
<edreamle1> drat.  Killing the console resulted in the wrong push location being remembered.
<edreamle1> The push location isn't in the main bazaar.conf file in C:\Documents and Settings\HP_Administrator\Application Data\bazaar\2.0
<edreamle1> Where would the remembered push loc be?
<radix> edreamle1: hmm. it would be in locations.conf, unless I'm out date
<lifeless> radix: you are out of date
<lifeless> edreamle1: just run the push again, with --remember
<radix> ok, my bad :)
<edreamle1> That assumes *I* remember what the url was :-)
<edreamle1> Ok, just opened the Secsh channel 1, so all looks good.
<edreamle1> Once again, the console appears to be hung.
<edreamle1> Maybe it's time for a reboot.  I probably should have done so after installing the bzr upgrade...
<edreamle1> Never mind: I got the can not acquire lock message.  I'll kill the console and break the lock
<madduck> so if i just want to track a repo and update it every day
<madduck> bzr merge is apparently the wrong tool
<madduck> Merging from remembered location http://liw.iki.fi/bzr/unperish2/trunk/
<madduck> bzr: ERROR: Working tree "/home/madduck/code/unperish/" has uncommitted changes.
<madduck> i never made any changes to the working tree
<madduck> what's the command to use instead?
<luks> pull
<madduck> okay, and another question: how do i reset the worktree to a given revision?
<luks> (and revert to clear the merge)
<luks> revert -r XX, but that will really reset only the working tree
<madduck> hm.
<luks> what do you want it for?
<madduck> play around/test the bzr integration into the mr tool
<andrea-bs> you can [temporary] commit the current workingtree, use "bzr revert -r old_revision" and finally "bzr revert -r latest_revision"
<madduck> thanks
<lifeless> marianom: mr tool ?
<LarstiQ> lifeless: a tool by joeyh iirc
* lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | bazaar.launchpad.net currently slow, being worked on
<LarstiQ> lifeless: http://kitenet.net/~joey/code/mr/
<lifeless> LarstiQ: hi dude
<jelmer> wow, yet another vcs-related tool by joey
<LarstiQ> jelmer: others being?
<LarstiQ> lifeless: hey
<jelmer> LarstiQ: etckeeper and ikiwiki
<LarstiQ> jelmer: ah, related in that way
<LarstiQ> jelmer: did you catch the stomach flu aswell at fosdem?
<jelmer> LarstiQ: Nope, I'm fine. Were there more people that caught it?
<LarstiQ> jelmer: nattie, Womble2 and murb at least.
<jelmer> LarstiQ: Ah, not anybody I met then. I think all of the other flooders are ok too
<LarstiQ> jelmer: meh, I blame it on nattie then.
<james_w> Hi all.
<james_w> LarstiQ: hi. Did I see that you will be there next week?
<LarstiQ> james_w: that is the planning, yes
<james_w> LarstiQ: fantastic.
<jelmer> LarstiQ: btw, when are you flying?
<jelmer> Apologies if I've already asked this weekend
<james_w> jelmer: pong. Sorry, it dropped off my traceback, so I had to look up who pinged me.
<jelmer> james_w: no worries. Hi!
<james_w> Hi jelmer. How are you?
<LarstiQ> jelmer: sunday
<jelmer> james_w: Basically, I keep hitting an import error when running the bzr selftest
<james_w> jelmer: on builddeb?
<jelmer> james_w: yep - "from errors import DebianError"
<jelmer> LarstiQ: morning or afternoon?
<lifeless> dont use relative imports PLEASE
<lifeless> jelmer: I filed a bug on this already :)
<lifeless> jelmer: you're in a directory with errors.py :>
<jelmer> james_w: I've got a patch for this if you're interested
<james_w> lifeless: yeah, I'm going to fix it soon, I promise.
<jelmer> lifeless: I'm probably the worst violator of this myself..
<james_w> jelmer: I'll happily take a patch for it.
<jelmer> cool
<LarstiQ> jelmer: 16:55 at AMS
<jelmer> LarstIQ: ah, ok. I'm leaving at 10 or something in the morning
* lifeless changed the topic of #bzr to:  http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2
<TeijoIhmiskilpi> yo
<TeijoIhmiskilpi> is there a solution for getting a warning/whatever when checking in cr/lf stuff?
<TeijoIhmiskilpi> short of running a verification script manually on checkin
<mwhudson> there are pre-commit hooks
<TeijoIhmiskilpi> ah, ok. something you can use out of the box or do you have to custom-make such a thing?
<mwhudson> well, you'd have to write some python i think
<mwhudson> but i don't think it's very complicated
<mwhudson> i have no experience of it myself though, let me see if i can find some documentation :)
<mwhudson> TeijoIhmiskilpi: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-hooks
<TeijoIhmiskilpi> well, python is not a problem ;-)
<TeijoIhmiskilpi> just as long as it's easy to config for our project
<TeijoIhmiskilpi> ok, seems easy enough
<TeijoIhmiskilpi> btw, it would be a good idea to have some "ready" hooks for checking sources for crlf
<TeijoIhmiskilpi> (because, typically, you don't want those and bzr does no translation on them)
<mwhudson> perhaps
<mwhudson> my life is blissfully windows-free these days, so i'm not the best person to talk to about this :)
<TeijoIhmiskilpi> yeah, I can understand that. However, when part of the developers in on windows... it can become painfull
<TeijoIhmiskilpi> like with symlinks
<TeijoIhmiskilpi> current approach (repos with symlinks are unaccessible) is unbearable
<TeijoIhmiskilpi> or at least a history-fixing NUKE_ALL_SYMLINKS would be quite swell ;-)
<TeijoIhmiskilpi> case in point - we had IPython imported to launchpad, but had to start a new project from scratch because it had single symlink
<mwhudson> TeijoIhmiskilpi: you should perhaps email the list about this stuff
<luks> I think just removing the symlink would be enough
<mwhudson> mark hammond is going to be working on windows support soon
<luks> it only fails if it has to create it on the disk
<TeijoIhmiskilpi> ah
<TeijoIhmiskilpi> so removing it from svn will suffice?
<luks> and there is a plugin to support fake cygwin-like symlinks
<luks> no, I meant from bzr
<TeijoIhmiskilpi> well, the svn is being imported to bzr in launchpad so it will disappear from bzr as well
<luks> ah, then yes
<TeijoIhmiskilpi> ok, perhaps I'll join bzr mailing list
<TeTeT> how do I copy a shared repository from one place to another? I have a shared repo on a usb stick and want to know copy it to the HD of the system
<TeijoIhmiskilpi> just copy it?
<TeijoIhmiskilpi> drag & drop?
<TeTeT> won't the push/pull references be wrong?
<TeijoIhmiskilpi> they are not absolute, I think
<TeijoIhmiskilpi> did you test it
<TeijoIhmiskilpi> ?
<TeTeT> no, not yet, can do
<james_w> TeTeT: there's no repository copy operation at the UI level, but a normal copy should work.
<TeTeT> james_w: thx
<TeijoIhmiskilpi> regarding shared repos btw
<TeijoIhmiskilpi> anyone know whether launchpad has project repos as shared repos by default?
<TeijoIhmiskilpi> or should those be created by user?
<james_w> TeijoIhmiskilpi: no, it doesn't
<james_w> TeijoIhmiskilpi: and I don't think you can.
<TeijoIhmiskilpi> ok. well, it's their disk space ;-)
<jdong> TeijoIhmiskilpi: not just that, it's your push time too
<mwhudson> well, it's also your bandwidth
<mwhudson> it's being worked on though
<TeijoIhmiskilpi> but as I understand it, I can have the same branches as shared repos locally, even if they are not shared on LP?
<mwhudson> (for various reasons "one shared repo per project" would be a bit simplistic)
<TeijoIhmiskilpi> the bzr reference was not all the explecit on this issue
<jdong> TeijoIhmiskilpi: correct
<jdong> TeijoIhmiskilpi: but the problem will come when you push your branch to launchpad, pushing a new branch always means uploading the entire revision history
<TeijoIhmiskilpi> ok. that kind of sucks
<TeijoIhmiskilpi> why would shared repo / project be too simplistic?
<TeijoIhmiskilpi> are there space/performance for having shared repos?
<TeijoIhmiskilpi> tradeoffs I meant to say
<jdong> TeijoIhmiskilpi: probably beacuse nobody's gotten around to implement it
<jdong> TeijoIhmiskilpi: from what I understand manpower is tight for bzr-launchpad folks
<TeijoIhmiskilpi> but wouldn't it be enough to create one shared repo for the project upload area?
<TeijoIhmiskilpi> i.e. no actual implementation to be done
<TeijoIhmiskilpi> for all its worth, it should be possible to create one shared repo far my c:/prj folder that has all my projects :-)
<mwhudson> TeijoIhmiskilpi: well, there are problems with locking for one thing
<mwhudson> bear in mind that anyone can upload code for your project
<TeijoIhmiskilpi> it bzr backtracks the directory tree to find shared repo, it should work automatically
<TeijoIhmiskilpi> hmm, ok
<TeijoIhmiskilpi> still... why would it need to lock stuff?
<TeijoIhmiskilpi> if they just created a series of "images" on shared repo
<TeijoIhmiskilpi> i.e. if user foo uploads snapshot 123ffdfbbb21212, it should not lock anything else
<TeijoIhmiskilpi> to shared repo I mean
<TeijoIhmiskilpi> though I have to admin I'm a total newcomer to bzr....
<TeijoIhmiskilpi> but assuming it works like hg/git... just create the snapshots in the shared repo, and the rest in own branches
<ubotu> New bug: #196702 in bzr "qlog fails to run with or with parameter" [Undecided,New] https://launchpad.net/bugs/196702
<TeijoIhmiskilpi> ah, bugbot, sexy
<Toksyuryel> with or with?
<emilis_info> what wiki is used for bzr website?
<Toksyuryel> http://bazaar-vcs.org/MoinMoin
<Toksyuryel> I think it's called "Moin
<Toksyuryel> I think it's called "MoinMoin"
<emilis_info> aha
<emilis_info> thanks
<Lo-lan-do> Hello
<jelmer> hey Lo-lan-do
<Lo-lan-do> I tried to "bzr pack" a repository of mine, and that doubled its size...  Is this supposed to happen?
<fullermd> Yes, the old packs are kept aroudn in obsolete-packs
<Lo-lan-do> Hm.  So I can safely remove that dir?
<abentley> No, the directory is required.  The contents will be deleted automatically next commit.  You can delete the contents manually, but there's not real point.
<abentley> s/not/no
<Lo-lan-do> There's the point that it won't use resources for the next backup.
<dato> abentley: not in the next commit, but in the next repack, IME... :-?
<abentley> That might be.
<abentley> Lo-lan-do: Anytime you manually manipulate the contents of .bzr, you risk shooting your foot off.
<Lo-lan-do> I know, but 80 MB of wasted space is... suboptimal.
<Lo-lan-do> And surprising, when you're told that "bzr pack" compresses a repo.
<abentley> Lo-lan-do: destroying your repository is of course your prerogative.
<Lo-lan-do> Thanks :-)
<Lo-lan-do> Hence my need for backups, and my need for them to be as useful as possible (and no bigger than needed).
<Lo-lan-do> Hi again
<Lo-lan-do> I seem to have encountered a bug :-(
<Lo-lan-do> http://paste.debian.net/50128
<Lo-lan-do> Does that ring a bell?
<james_w> Lo-lan-do: I've not seen that one before. Please file a bug.
<james_w> Lo-lan-do: does it depend on --lca?
<Lo-lan-do> I'll try to reproduce in a clean environment first.
<Lo-lan-do> I don't see the bug with --diff3
<Lo-lan-do> And --weave takes forever so I don't know yet :-)
<james_w> Yeah, I suspect --lca is a rarely used codepath, so it wouldn't surprise me.
<Lo-lan-do> I can reproduce with --lca in a clean env (bzr 1.1).  I'll check with bzr 1.2 in a cowbuilder.
<james_w> Lo-lan-do: do you have a launchpad account?
<Lo-lan-do> No
<james_w> that's fine. If you want to file in Debian I'll happily relay it.
<Lo-lan-do> Yay, I can reproduce that even with bzr 1.2.
<Lo-lan-do> (Not sure it really makes me happy though :-)
<Lo-lan-do> bzr get http://bzr.debian.org/~lolando/bzr/f-spot/patches/superpatch/ ; cd superpatch ; bzr merge --lca http://bzr.debian.org/~lolando/bzr/f-spot/patches/bz-329174/
<bob2> reproducible with bzr.dev
<mwhudson> looks like an abentley bug to me!
<abentley> mwhudson: agreed.
<abentley> I'll grab those branches now.
<Lo-lan-do> I copied them to http://bzr.debian.org/~lolando/tmp/bzrbug-20080228/
<Lo-lan-do> Since --weave seems to have worked, I'll probably continue evolving them.
<Lo-lan-do> Shall I submit the bug nevertheless?
 * Lo-lan-do goes ahead
 * Lo-lan-do goes to bed, too
<james_w> night Lo-lan-do.
<ubotu> New bug: #196780 in bzr "Exception during merge --lca" [Undecided,New] https://launchpad.net/bugs/196780
<ja1> spiv: ping
<spiv> jam: pong
<macogw> why does "bzr break-lock" then make bzr commit tell me that 1) it's still locked 2) i'm locking it
<beuno> macogw, are you sure the lock got broke?
<macogw> dont know.  it asked "do you want to break ....? [y/n]" and i hit y
<macogw> is there supposed to be some sort of "lock broken" message afterward?
<beuno> macogw, maybe it couldn't break the lock due to permissions?  can you run it again and check it doesn't spit out anything odd
<beuno> I don't recall if it confirms it, but it sure would tell you if it failed
<macogw> it never said it failed
<macogw> it works now....maybe waiting a few minutes does....something?
<macogw> i tried it like 5 times before, but less than a minute apart
<beuno> macogw, is this on launchpad?
<beuno> still, locks should be broken immediatley
<macogw> yes
<macogw> i was trying to add myself to Planet Ubuntu, since i never got around to it before
<beuno> macogw, LP might be a bit weird about it, yes
<macogw> ok
<spiv> Generally repeated break-lock means there were multiple smart server processes on the server waiting to take the lock.
<spiv> So you need to break-lock repeatedly to get through the backlog.   (Although I also thought bzr 1.2, which is on Launchpad, would be better about leaving those processes hanging around indefinitely.)
<beuno> spiv, ah, good to know. Maybe that should be added as a FAQ somewhere?
<spiv> beuno: it doesn't seem to come up very often.  I'd like to get more information from the next person that reports it, too, because I thought it should be largely fixed by now for servers running 1.2.
<beuno> spiv, I've seen this come up many times before. I'll make sure to grab on to the next one and send a ping your way
<spiv> beuno: thanks
#bzr 2008-02-29
<spiv> I know it used to come up frequently, this is the first report I've seen in a while.
<beuno> oh, could be
<beuno> time is a very slippery thing lately
<seydar> how does bazaar compare to git?
<seydar> seriously, i have only used git, but bazaar has a cooler name
<jdong> lol
<fullermd> It's less salty, with more bite.
<jdong> I find bzr's interface much easier to use, much more friendly
<seydar> i want to name some project 'balthazaar'
<jdong> it feels more high-level than git IMO
<jdong> though the performance in my experience isn't as great
<beuno> seydar, maybe something like this will help: http://bazaar-vcs.org/BzrVsGit
<seydar> is there a sample session online?
<seydar> ooh windows support. i'm not too fond of supporting windows ;-)
<spiv> seydar: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<spiv> seydar: that's a tutorial called "Bazaar in five minutes"
<jdong> I really disliked git's way of committing things before I expected it to commit
<spiv> seydar: there's other documentation at http://doc.bazaar-vcs.org/latest/
<jdong> I've recently started using git for dealing with subversion... I've found its performance to be more acceptable when paired with svn versus bzr-svn
<jdong> but at the same time, I grumble about git's UI every 5 minutes
<seydar> does bazaar have a witty hat, like
<seydar> 'git 'er done' from larry the cable guy?
<jdong> I believe they do sell t-shirts like that :)
<jdong> and what's up with git's refusal to acknowledge empty directories exist? :)
<seydar> i saw linus torvalds in one
 * beuno wonders if igc will take the bzr tshirts to the sprint
<seydar> ok. so bazaar it is
<fullermd> I think it's a side effect of refusing to acknowledge directories exist.
<jdong> lol
<jdong> as I said, I've been looking at git lately for my subversion interactions with large svn repos
<fullermd> Actually, who DOES treat directories directly as entities?  bzr does, mtn does...  I don't think hg does...
<bob2> also file identity
<jdong> but only because I'm kinda forced to
<seydar> balthazar is such a badass name
<seydar> whats mtn?
<igc> beuno: igc has no idea re tshirts sorry
<jdong> monotone I believe
<bob2> seydar: monotone (venge.net)
 * fullermd nods.
<jdong> seydar: btw, you do acknowledge the implications of asking #bzr whether to use bzr or git, right? :D
<seydar> totally
<jdong> but I really do think we're giving an objective opinion, if there is ever such a thing
<fullermd> Which there isn't, on most things (especially UI), because they're inherently subjective.
<fullermd> I mean, Tom Lord probably thinks arch has an easy and intuitive UI   ;)
<jdong> haha
<jdong> though I find that hard to believe!
<fullermd> And he'd be right, for him.
<fullermd> And most people would probably hate my GUI setup...  but it's perfect for me.
<bob2> oh, and arch had directories as entities
<seydar> thanks guys
<beuno> igc, didn't you send an email a few months ago to send bzr tshirts for contributors?
<fullermd> That was poolie I think.
<igc> beuno: probably. If so, I did it on behalf of poolie
<beuno> right, it was poolie.
<beuno> not sure why I was convinced it was you
<jelmer> it was poolie
<Peng> Right, hg doesn't version directories.
 * Peng wanders off.
<awmcclain> What's the name of the other bzr GUI that isn't qbzr? wildfire or something?
<spiv> wildcat, IIRC
<beuno> awmcclain, or bzr-gtk?
<awmcclain> wildcat!
 * igc lunch
<awmcclain> Hrm. I'm guessing wildcat doesn't work with 1.2.0... I get a "file not locked" exception when I try to diff.
<beuno> awmcclain, I think it's a very alpha sort-of-thing at the moment
<awmcclain> And bzr-gtk is x11, right?
<Verterok> awmcclain: yes
<spiv> awmcclain: it should work on any platform where pygtk works
<spiv> Which includes win32 I believe.
<awmcclain> I'm running os x but I'm not a huge fan of the x11 emulation. :)
<spiv> (Although installing it might be a bit of a hassle)
<awmcclain> So... it looks like i'll have to brave pyqt
<RAOF> awmcclain: There's the native OS X gtk now, right?
<awmcclain> RAOF: o really?
<RAOF> If you don't mind less than fully tested code.  http://developer.imendio.com/projects/gtk-macosx/ is one google hit.
<RAOF> I recently saw a blog post with native mac gtk screenshots, which is why I have any idea about this :).
<carnage4ever> is there anyone around?
<spiv> carnage4ever: yes
<carnage4ever> spiv: trying to somehow get bzr to run a precommit shell script BEFORE commiting files...
<carnage4ever> is that possible?
<spiv> carnage4ever: it is, although you need a python plugin to do it.
<spiv> carnage4ever: https://lists.ubuntu.com/archives/bazaar/2008q1/036955.html may help
<ubotu> New bug: #196881 in bzr "Exception redirecting merge output to a file" [Undecided,New] https://launchpad.net/bugs/196881
<spiv> The protocol-v3 branch is ready for dogfooding.
<lifeless> cool
<dholbach> heya
<dholbach> what answer is there to something like  http://pastebin.ca/923001 and http://rafb.net/p/6xkuJL96.html ?
<spiv> dholbach: looks like a possible launchpad bug
<dholbach> spiv: oh? how so?
<spiv> dholbach: or maybe a bug in the launchpad plugin for the client
<dholbach> is there any information I should try to get for it?
<spiv> dholbach: but IIRC "lp--NNNN:..." URLs are a server-side implementation detail.
<spiv> dholbach: "bzr info -v", and the actual bzr commands being run by that script
<dholbach> bzr update; bzr commit -m "something" is what the script runs
<dholbach> let me get the version
<dholbach> spiv: http://rafb.net/p/LKucRO74.html
<spiv> dholbach: yeah, I'm pretty sure it's a launchpad bug.  File it against launchpad-bazaar.
<spiv> dholbach: as a workaround, hobbsee should be able to "bzr switch sftp://hobbsee@bazaar.launchpad.net/%7E5-a-day/5-a-day-data/main/"
<dholbach> spiv: thanks a lot
<dholbach> https://bugs.launchpad.net/launchpad-bazaar/+bug/196913
<ubotu> Launchpad bug 196913 in launchpad-bazaar "Cannot lock LockDir(lp--1218658708:///~5-a-day/5-a-day-data/main/.bzr/branchlock): Transport operation not possible: readonly transport" [Undecided,New]
<spiv> dholbach: thanks for the bug report
<dholbach> de rien
<spiv> dholbach: if you can get the particular bzr command that triggers the error in the bug report, that'd be good.
<spiv> dholbach: or link to the add-5-a-day script
<dholbach> done, thanks
<lifeless> abentley: ping
<lifeless> http://bundlebuggy.aaronbentley.com/request/<1203467195.15574.136.camel@lifeless-64>
<lifeless> abentley: I think you had partially reviewed this
<lifeless> dholbach: 5-a-day stuff should be faster now; we had some supermirror issues
<dholbach> lifeless: rock and roll
<dholbach> you guys kick ass
<dholbach> lifeless (and others): do you think it's worth splitting up the branch into per-people-branches? (less possible locking issues)? we're at 53 committers now
<lifeless> dholbach: are you having locking issues?
<dholbach> lifeless: some people run into this every now and then (not that often yet, but I expect the project to grow)
<lifeless> dholbach: bzr should handle it
<dholbach> OK
<lifeless> if it becomes a problem, then sure
<dholbach> I'll keep you in the loop :)
<lifeless> nag me to do 5 a day :)
<dholbach> 5-a-day keeps the doctor away! :)
<dholbach> https://wiki.ubuntu.com/5-A-Day#Log :)
<dato> jelmer: hi. I've found the -r option for replay a tad confusing. its docs say "see help revisionspec", so I assumed it'd work as in merge, so that `replay -r 372..373` would replay just 373, but it replays both 372 and 373. -r 373 does what I want, but that's not how merge behaves. it does what -c 373 would do, but -c is not available in replay.
<dato> jelmer: do you see what I mean?
<lifeless> sounds cnfusing
<lifeless> dato: send a patch :]
<Peng> Hmm, looks like svn-import is up to something now.
 * Peng wanders off, nervous of swapping to death suddenly.
 * dato wonders if --overwrite will work well when pushing to svn.
 * Peng wonders if converting 60k revisions with about 400 MB of free RAM is a good idea.
<Peng> jelmer: Man, svn-import is way too verbose. It's averaging almost one line of output per day!
<dato> revno: 371
<dato> revision-id:dato@net.com.org.es-20080228115922-wi3npwo1rnfmilbg
<dato> parent: dato@net.com.org.es-20080222115116-62obf3ebstr8l3lh
<dato> a space has been lost after revision-id?
<dato> jelmer: (also, any plans for a new bzr-svn in unstable? bzr can't migrate to testing without it)
<jelmer> dato, this weekend
<dato> ok
<dato> jelmer: do you have a sec to tell me how/if I can solve this bzr-svn problem?
<jelmer> dato: sure
<dato> I had a bzr branch synced with a svn branch. my replay went bad (see above), and I replayed one more revision than desired. sadly, I pushed that to svn.
<dato> so I replayed well in a copy of the bzr branch, and tried to push that (expecting to get the "branches have diverged" message), but it's just taking ages to do anything
<dato> should I try with --overwrite directly, or... maybe svn rm, + svn cp -r $HEAD-2 ?
<jelmer> dato: The argument to replay is a range of revisions and supporting -r272..273 to mean [272,273] makes sense to me
<jelmer> dato: Patches for improvements are welcome though
<jelmer> dato: It should just work
<dato> what should work, sorry?
<jelmer> dato: The push giving "Diverged Branches"
<dato> and with --overwrite?
<lifeless> jelmer: we use [from, to) for nearly everything else in bzrlib though
<lifeless> jelmer: or (from, to] perhaps I should say
<lifeless> jelmer: I think, that 'diff -r x..y' should show the aggreate changes that reply -r x..y will aply.
<jelmer> lifeless: Yeah, consistency is also nice, indeed
<asabil> is it normal that bzr-bookmarks doesn't work with bzr pull ?
<lifeless> I don't know, what is bzr-bookmarks?
<asabil> a bzr plugin
<asabil> to have bookmarks
<asabil> lifeless: also the launchpad plugin doesn't work with bzr pull
<asabil> bzr pull lp:~easy-radio/easy-radio/bargraph
<asabil> bzr: ERROR: Not a branch: "/home/asabil/Devel/INSA/5IF/OT/easy-radio/trunk/lp:~easy-radio/easy-radio/bargraph/"
<lifeless> asabil: you are missing the required dependencies for sftp for bzr
<asabil> lifeless: ??? why ? I use the sftp transport all the time ?
<asabil> python-paramiko is installed
<lifeless> asabil: huh, interesting
<lifeless> asabil: what does 'bzr plugins' list ?
<asabil> svn, multiparent, launchpad, rebase, gtk, record, bzrtools, xmloutput, bookmarks
<lifeless> asabil: this is very interesting. I think something is buggering up pull :)
<asabil> let me disable xmloutput
<asabil> no, that's not the cultpit
<lifeless> bookmarks sounds like something inclined to diddle with pull
<TFKyle> lifeless: there's a bug about it reported on lp iirc, pull doesn't like lp: uris
<TFKyle> https://bugs.launchpad.net/bzr/+bug/181945 if you havn't seen it yet
<ubotu> Launchpad bug 181945 in bzr "bzr pull lp:upstart fails" [High,Confirmed]
<asabil> lifeless: the bug was there before I installed bookmarks
<lifeless> asabil: ah, interesting
<lifeless> TFKyle: thanks
<lifeless> seems to be pull not handling redirects
<asabil> now it seems like lp's server is stalled or something :/
<asabil> am unable to push
<lifeless> asabil: checking
<asabil> thanks
<lifeless> asabil: yes, rogue process, fixing in a couple of minutes
<lifeless> your lilnk may get bounced
<asabil> oki
<asabil> I interrupted already
<lifeless> \asait should be faster now
<Lo-lan-do> Hmmm.  "bzr pack" seems to make "bzr status" *slower*.
<Lo-lan-do> Not much, but a bit.
<poolie> Lo-lan-do: it may be forcing things out of memory?
<Lo-lan-do> I ran it several times in a row :-)
<Lo-lan-do> Both before and after the pack.
<Lo-lan-do> It took about 0.58s before the pack, and it now takes 0.61s.
<lifeless> Lo-lan-do: pack and status use dufferent data; its almost certainly just measurement noise
<lifeless> Lo-lan-do: specifically status won't read data from the repository
<Lo-lan-do> Hm.  Okay :-)
<mvo> bazaar.launchpad.net is refusing connections for me, does anyone else sees this too?
<poolie> yes
<poolie> we're working on it urgently
<mvo> ok, thanks
<poolie> bazaar.launchpad.net is down; it's being addressed urgently
<poolie> sorry, paste error
<lifeless> its back now
<poolie> pqm.bazaar-vcs.org's invalid https cert looks worse under ff3
<lifeless> poolie: yes it does :)
<Verterok> awilkins: just to let you know, I pushed a BazaarClient with some fixes and command syntax updated to bzr-1.2
<jdong> jelmer: have you considered upgrading or at least making available a packs version of bzr-svn's branch? :D
<jdong> I'm in a low-patience branching mood today
<poolie> night all
<james_w> night poolie
<james_w> have a safe journey
<lifeless> night all
<lifeless> james_w: we're in London now
<james_w> ah, welcome.
<thumper> what does: "899.934  not updating child fraction" in the .bzr.log file?
<abentley> It's related to progress bars.  The details escape me.
<jelmer> jdong: heh
<jelmer> yeah, I guess it's about time to upgrade
<jelmer> jdong: please note that it is *not* advised to use the 0.4 branch of bzr-svn atm
<jdong> jelmer: ah, ok. Also, are there any known issues between bzr-svn and subversion 1.5.x/1.6.x?
<jdong> jelmer: I recall trying it earlier and getting something along the lines of a mismatched # of arguments traceback
<jelmer> jdong: I haven't tried 1.6.x, 1.5.x should work fine
<jdong> jelmer: ok, just an FYI the ForeignBranches howto says to branch subversion trunk which is apparently "1.6.x" now
<jelmer> jdong: Can you be more specific ? :-)
<jdong> jelmer: *grumble* let me reproduce it ;-)
<jdong>     return apply(_ra.svn_ra_do_update, args)
<jdong> TypeError: add_nodes() takes exactly 2 arguments (4 given)
<jdong> jelmer: ^^. Lemme know if that's totally wack. I did really mutilate the svn stack to get it to build in this RHEL4 env
<jelmer> jdong: That looks like a python-subversion issue
<jdong> jelmer: this is subversion branches/1.5.x IIRC....
<jdong> jelmer: wait is bzr-svn 0.4.7 supposed to work against bzr 1.2.0?
<jelmer> jdong: Something funky is happening at your side
<jelmer> jdong: There is no symbol add_nodes in either bzr-svn or python-subversion
<jdong> /mit/jdong/.local/lib/python2.5/site-packages/bzrlib/index.py:    def add_nodes(self, nodes):
<jdong> it seems to be in bzrlib?
<jelmer> any chance you can post the full backtrace somewhere?
<jdong> O_O
<jdong> oh
<jdong> wow
<jdong> lol that was confusing
<jdong> so I post this traceback to Ubuntu pastebin...
<jdong> and Ubuntu pastebin HAPPENED to spit back a CGI error in the form of a python traceback
<jelmer> heh
<jdong> and all I could think is "hey that's not the one I put in"
<jdong> lol lemme find another pastebin
<jelmer> (-:
<jdong> http://paste.ubuntu-nl.org/57869/
<piedoggie> the more I work with svn, the more I love bzr.  thanks folks for making bzr real.
<jdong> WELL I guess the selftest segfaulting is a good sign that I did something idiotic compiling svn.
<beuno> lifeless, ping
<mdke> I'd like to merge changes from a branch into another one but only in relation to one file - can I do that?
<mdke> "bzr merge branch filename" doesn't seem to work
<jdong> jelmer: any hints on the backtrace?
<jdong> mdke: the only way I know of is to merge the branch, then revert all but that one file
<beuno> mdke, AFAIK, cherrypicking is not supported yet
<jelmer> jdong: Whoops, sorry
<mdke> jdong, beuno: ok, shame. Thanks
<mdke> cp it is then :)
<jdong> spoken almost like a git developer :)
<beuno> mdke, old n' trusty  :p
<jelmer> jdong: Doesn't make an awful lot of sense
<mdke> yes, cp seems to work
<fullermd> No, you can bzr merge /some/branch/some/file
<jelmer> jdong: I guess the backtrace gets messed up by the python subversion bindings
<mdke> fullermd: doesn't seem to work with a remote branch on launchpad at least
<fullermd> (it doesn't record anything of course, just like cherrypicking revs, but it works)
<beuno> ah I guess that would be bug #81758 then
<ubotu> Launchpad bug 81758 in bzr "'bzr help merge' should describe merging a single file" [Low,Confirmed] https://launchpad.net/bugs/81758
<jdong> jelmer: well, I can tell these RHEL4 servers hate me
<jelmer> it may actually be a core bzr bug
<jelmer> but it's hard to tell without a proper traceback :-/
<jdong> jelmer: confusing why a nearly identical setup on ubuntu doesn't err out
<jelmer> jdong: Does "bzr selftest svn" pass?
<jdong> jelmer: no, it.... segfaults....
<jdong> which is another worrisome sign
<jelmer> uhm, yes :-)
 * jdong nukes his ~/.local and starts over
<jdong> when in doubt..... wipe ito ut.
<jdong> spoken in the true voice of American diplomacy.
<jelmer> (-:
<jdong> ok, let's try just installing bzr and running its selftest first...
<benjaminpeterson> has anyone used bzr-lomb?
<makko> hi, I'm running bzr on Mac (Leopard OS X) and I don't know why, but when I run a commit or branch, it just hangs... I've left it running overnight and it still doesn't finish. Any ideas/pointers?
<beuno> makko, maybe take a look at ~/.bzr.log?
<poolfoo1> Does any one know of a nice (aka TortousCVS) graphical interface to bazarr on OSX?
<makko> beuno: I did. For example, I just wanted to get the latest bzr.dev (as in the user manual), and it just hangs. My bzr.log says: 396.636  creating branch <bzrlib.branch.BzrBranchFormat6 object at 0x1326d10> in file:///Users/normsu/root/bzr/bzr.dev/.bzr/ ...
<beuno> makko, what version of bzr would that be?
<makko> beuno: I got bzr from macports  (1.2.0) and I'm trying to fetch bzr.dev with "bzr branch -v http://bazaar-vcs.org/bzr/bzr.dev"
<benjaminpeterson> poolfool: have you seen QBzr
<beuno> makko, can you report a bug with the contents of your .bzr.log?
<makko> beuno: OK, I just wasn't sure if this was an actual bug or something kooky with my own setup/environment.
<beuno> makko, thanks. I'm sure someone else will help you debug it
<makko> beuno: OK, thanks for your kind assistance I'll try your suggestion.
<beuno> makko, np. good luck  :D
<poolfoo1> benjaminpeterson: No ... sorry ... but I guess I was looking for something a little more tied into finder.
<poolfoo1> I am kind of new to OSX (1 month new), and I mostly use the console ... but at work I use TortoiseCVS and it gets kind of addicting.
<poolfoo1> benjaminpeterson: Quit a nick by the way ... hurts to type ... almost
<benjaminpeterson> poolfool: Hmm, I don't actually know of any applications that interface with the MacOS finder. Is that possible? (Are their APIs?)
<poolfoo1> benjaminpeterson: I would guess not ... Apple kind of sucks that way ... but I figured I would throw the question out any ways.
<poolfoo1> bpeterson: Much easier ... are you a Mac OSX guy?
<bpeterson> poolfool: I switch between KDE and Mac
<bpeterson> poolfool: I agree that Apple should make this possible. Some cool things could be done...
<jdong> maybe I'm crazy, nerdy, and so on... but am I the only one to prefer working with a textmode VCS?
<jdong> I mean, I've used Subclipse, TortoiseSVN, bzr-gtk, etc all before, and find them more cumbersome than their command line counterparts
<jdong> with the sole exception of  bzr visualize and similar tools
<jdong> ancenstry is more clear in a GUI form
<bpeterson> jdong: I love textmode
<bpeterson> jdong: I typically use a simple editor with syntax highlighting and perform all my other operations with bash
<poolfoo1> I like gui for the quick clues that a file may be out of date (icon overlay in Microsoft Windows with Tortoise), but commits, diff, log generation for reports are much easier text based.
<bpeterson> bzr missing
<poolfoo1> That said, I just seem to live via gui. That is kind of why I was looking for something that might tie into finder ... not yet another graphic program to learn.
<jdong> poolfoo1: interesting... I find bzr diff, bzr log, bzr status easier by commandline
<poolfoo1> jdong: sorry, maybe I didn't read/write that just write. I agree that diff, log and status are much easier from command line\text.
<fullermd> A GUI is a way to get LOTS of command lines at once   :)
<poolfoo1> What about web interface (bzrweb?) to revision control? I like the bonsai/ViewVC interface a lot for a while.
<jdong> poolfoo1: seems like loggerhead is the preferred one nowadays
<jdong> launchpad has a demo of it
<jdong> poolfoo1: http://bazaar.launchpad.net/~bzr/bzr/trunk/files
<jdong> I still like bzr-serve or whatever that other older one is called
<jdong> because you can start it on some arbitrary port on a single command
<poolfoo1> loggerhead (the last time I played with it) was a whole suite of power tools just ready to rip an finger/arm/leg off. I like the small light weight ability of bzweb for small projects/groups or single use as a simple gui.
<poolfoo1> loggerhead would be much better for something like launchpad/sorceforge/...
<jdong> poolfoo1: yeah the older one was easier for personal use
<bpeterson> i like to know what my computer is doing, so bash gives the most control and detail
<jdong> I find commandline easiest for stuff I know how to do, and GUI's easier for, frankly, BS-ing my way along when I really don't know what I'm doing.
<jdong> again, personal opinion.
<bpeterson> it is more intuitive
<poolfoo1> What is the craziest/coolest use of bazaar to date? I heard someone ( lifeless ) suggest using bzrlib for a wiki ... sounded pretty cool to me.
<jdong> if you *know* what you want to do, it's much easier to express it in a CLI
<jdong> poolfoo1: benjamin mako hill is doing a bzr wiki for his doctoral thesis
<jdong> poolfoo1: I wrote a ruby+bzr TODO list program a few weeks ago
<jdong> so I can operate disconnectedly
<poolfoo1> jdong: do you have the link? ... but what about a revision controlled filesystem ... something more complex then the Linux COW patch.
<jdong> poolfoo1: I also use bzr heavily while doing Ubuntu package development or packaging. It helps me keep track of my current changes a lot better
<bpeterson> i suppose you can bumble around in GUI with out causing horrible damage
<jdong> poolfoo1: I don't have a link handy, no
<jdong> bpeterson: well a GUI's beter at answering "Hmm, what can I do?"
<jdong> i.e. poking around a new program
<jdong> I found git extremely bewildering on day one
<jdong> IMO it's approaching arch fame :)
<jdong> but once I kinda knew what I was doing, it was pretty easy to use
<poolfoo1> jdong: when you use it for ubuntu you are using it as a RCS? ... how about using it somewhere that is revision control (wiki/apple time machine/... ) but you just don't realise or think of it that way.
<bpeterson> jdong: when you don't want to look through the docs :)
<bpeterson> jdong: is git really as fast as Linus says
<ubotu> New bug: #197125 in bzr "bzr hangs on Mac OS X Leopard (10.5.2)" [Undecided,New] https://launchpad.net/bugs/197125
<mkanat> Is there any way to make bzr ignore permission changes on files, for a checkin?
<jdong> bpeterson: git is fast indeed, impressively so
<jdong> bpeterson: something like "git log > /dev/null" for 500,000 revisions happens nearly instantly
<jdong> i.e. complete in 0.5 seconds
<jdong> bpeterson: but personally I don't think most sized projects benefit from that speed
<jdong> bpeterson: git has been much slower for me because in the time it takes me to answer "What the hell is git pull . refs:master/trunk?", bzr could've done the operation 10 times :)
<poolfoo1> jdong: Have you tried git on Microsoft Windows recently? Is there a not cygwin version?
<poolfoo1> My big selling point for bazaar is Win32 at work, Linux & MacOSX at home ... no problems to date ... <knock on wood>
<jdong> poolfoo1: AFAIK all the git-on-windows implementations are either quirky or very slow
<jdong> poolfoo1: bzr is definitely much much more portable
<poolfoo1> Which would be my big selling point ....
<jdong> poolfoo1: for me, that and (2) simplicity (3) outstanding support for dumb protocols
<jdong> those two are things that most VCSes lack IMO
<poolfoo1> jdong: you mean the fact that bzr can checkout over http/scp/ssh ?
<jdong> poolfoo1: right. The fact that bzr works just fine over standard protocols like SFTP, HTTP, FTP and so on without the need for anything special on the remote end
<jdong> Git can read over HTTP, but that's it
<jdong> if you want to push, you can't do that over FTP. You can only do it over SSH if git were installed on the remote machine
<poolfoo1> jdong: so the purpose of a dedicated bzr protocol and server? speed ... but I am just looking to get info.
<jdong> poolfoo1: right, the smart server tends to be faster
<jdong> poolfoo1: rather, has more potential to be faster
<jdong> poolfoo1: though the recent "packs" storage format evened the playing field a lot
<poolfoo1> jdong: potential ... yea .... about that ...
<jdong> poolfoo1: branching a large packs-format repo over http maxes out my connection at 8MB/s
<jdong> for the most part
<jdong> which is as good performance as one can hope for, right? :)
<poolfoo1> Wow ... 8MB/s ... that's a lot better then any connection I have had in a long while; at work Dual T1 with poor load balance right now and CrapCast (ComCast) at home.
<jdong> poolfoo1: well I'm glad my $40,000 tuition allows MIT to buy me some pretty decent internet :)
<mkanat> I've bursted almost that high on Comcast.
<mkanat> jdong: Hahahaa, ahh, the days of school internet...
<jdong> indeed :)
<jdong> I'll miss my 18.0.0.0/8 subnet too
<poolfoo1> Aaaahh yes ... the last time I had decent net speed I was at Colorado State University (CSU) .... the good old days.
<jdong> where everything from the printer next to me to my iPod Touch has a public IP
<mkanat> jdong: In a sense that's a little frightening, though. :-)
<damageboy> can anyone explain how to write a pre-commit hook script with Bzr 1.2?
<jdong> mkanat: :) access control should be strong enough to withstand that anyway :)
<poolfoo1> damageboy: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
<poolfoo1> Is there some place for good bzr scripts?
<mkanat> jdong: I hope so! :-)
<damageboy> Can I run a bash script that changes the files I'm about to commit (potentially even creates more changes...)?
<damageboy> From the pre_commit hook that is...?
<bpeterson> damageboy: I dont't believe so. Bazaar has already calculated the changes to commit.
<awilkins> damageboy: I'm not sure, but I'd imaging that would work, unlike on SVN
<awilkins> damageboy: I think I might want to try that myself, I have some reasons to do it in my present project :-)
<awilkins> Anyway, time for bed.
#bzr 2008-03-01
<jdong> jelmer: interestingly, the crash did not happen with svn 1.4.6 and the patch.
<jdong> jelmer: it seems 1.5.x specific for some reason.
<jdong> anyway, I'm too tired to investigate more carefully, I'll just leave it at its pseudo working state :D
<james_w> jam: thanks for looking in to the cherrypick issue.
<jdong> silly question, but will bzr reconcile ever be faster?
<jdong> jelmer: is there a straightforward way for determining what bzr rev matches a svn rev?
<jdong> other than grepping both logs
<jelmer> jdong: There is a svn: revision specifier
<jelmer> that allows you to get from svn to bzr revision
<jelmer> that will only work against a native svn branch though
<jelmer> as there is no one-to-one mapping in other cases
<jdong> jelmer: ok, cool I'll take a look at that
<kgoetz> hi all. i asked this in #ubuntu-doc, but i was pointed here. https://wiki.ubuntu.com/DocumentationTeam/Repository#head-7349bc14cd12ae1087537a239427a70a4d73295d talks about setting up a shared repository for checkout histories. i'm wondering if theres a way i can check my 3 docs checkouts (edu/kubuntu/ubuntu) are shared or not
<jdong> kgoetz: cd into your branch, type "bzr info"
<jdong>   shared repository: /home/jdong/src/rockbox
<jdong> ^^ you'll see a line like that if it's shared
<jdong> kgoetz: and you should probably omit the --format argument too; the new default pack format is more efficient and faster over network
<kgoetz> jdong: thanks a lot! "Shared repository with trees (format: dirstate-with-subtree)"
<jdong> cool
<kgoetz> jdong: i setup the repo months ago, but i've only just come back to it.
<jdong> ah
<jdong> consider upgrading to the packs format for space savings
<jdong> and consider telling the same to doc team :)
<kgoetz> ok :)
<jdong> I'm quite sure you remember how painful it was to branch the first time :)
<kgoetz> i'll check on bzr's site to see if i can find instructions
<kgoetz> yes i do *g*
<james_w> kgoetz: if you don't have a "shared repository:" then I think they may not be shared.
<james_w> Although it would be odd to say "Shared repository" if it didn't mean shared.
<james_w> Ah, the code is sensible after all :(
<james_w> I was wrong, you get "Unshared repository" if not, so it should be fine.
<jdong> ah, the forward thinking of bzr is just simply astonishing at times
<james_w> yeah, and yet again it makes me look like a fool.
<clynetic> I need a pointer to any docs that will show a noob how to setup and use PQM.
<abentley> james_w: The "info" code was a rat's nest.  I've cleaned it up somewhat, but there's still plenty left to do, especially in the test cases.
<beuno> kgoetz, http://beuno.com.ar/archives/48  (instructions to upgrade your branches)
<kgoetz> beuno: thanks.
<beuno> I'm off to bed now, it's too close to 6am
<kgoetz> later mate
<beuno> kgoetz, np. Upgrade them in Launchpad too if you host them there (upgrade them with sftp)
<jdong> kgoetz: remember that packs are only compatible with bzr 0.92 or above (though they're a very very good reason why everyone should upgrade to said versions)
<kgoetz> jdong: ok. theres always a catch :|
<jdong> kgoetz: well... it's not much of a catch. IMO anyone using an earlier version of bzr is seriously missing out
<jdong> kgoetz: I mean, in many of my branches you're talking about a 10x to 20x increase in branching speed by switching to packs
<jdong> to ask someone to upgrade to a newer bzr is not at all unreasonable
<kgoetz> sounds like installing 1.1 was a good call *heh*
<jdong> not to mention the bzr team provides great methods for doing so on nearly all platforms
<kgoetz> mmm.
<lifeless> beuno: pong
<beuno> lifeless, was in doubt on how to implement a change you requested, but I figured it out eventually. Sent the patch to the list  :D
<mohbana> hello guys
<mohbana> is it possible to use bazaar with eclipse
<clynetic> I haven't tried this yet, but here's info about the eclipse plugin.
<clynetic> http://bazaar-vcs.org/BzrEclipse?highlight=%28eclipse%29
<elijah> 404: http://doc.bazaar-vcs.org/bzr.1.2/en/release-notes/NEWS.html
<elijah> (That's the top link from http://bazaar-vcs.org/news#1.0released)
<james_w> elijah: yes, there is a symlink missing on the server. Thanks for telling us about it though. Hopefully someone with access will fix it soon.
<Bloguero__Connor> Hello, how do I go back to the version x of my code. Lets suppose I commited 7 times. But then I regret and I say: I want to go back to commit #4. How do I do that?
<beuno> Bloguero__Connor, bzr revert -r 4
<Bloguero__Connor> gracias!
<beuno> Bloguero__Connor, ;)
<lifeless> later
<jdong> lifeless: why doesn't bzr pack remove all obsolete_packs at the end of its run?
<jdong> it seems like a logical time to do it
<jdong> [jdong@jdong:src/rockbox]$ du -sh .bzr/repository/*packs
<jdong> 130M    .bzr/repository/obsolete_packs
<jdong> 112M    .bzr/repository/packs
<jdong> kinda silly after a pack the repository size doubles
<beuno> jdong, fun discussion about it in: https://lists.ubuntu.com/archives/bazaar/2008q1/036719.html
<jdong> beuno: interesting.... thanks for the info, though reading it didn't give me a satisfied happy ending
<beuno> jdong, me neither  :p
<jdong> beuno: all I see is "bzr help pack" tells me it recompresses packs to save me disk space, and du -sh tells me my repository size *doubled* after running it
<jdong> we could change it to say "reorganizes packs to save disk space 5 commits later" but that sounds silly :)
<LarstiQ> log(n) commits later?
<beuno> jdong, yeap yeap, I upgraded ~200 repos and maxed out my servers harddrive
<beuno> was fun
<beuno> than had to script something that would check the repo and delete them
<beuno> LarstiQ, hey  :D
<beuno> there should be a
<beuno> an option to remove them automagically
<ubotu> New bug: #197356 in bzr-svn "Branches created in svn don't seem related in bzr" [Undecided,New] https://launchpad.net/bugs/197356
<Lo-lan-do> Hey, this one is mine!
<gnumarcelo> Hi guys! Anybody here are using any bazaar plugin for Eclipse ide?
<james_w> Lo-lan-do: yeah, sorry it took so long to forward it.
<james_w> gnumarcelo: I think there are a couple of people
<james_w> gnumarcelo: Verterok is the developer.
<gnumarcelo> I'm planning use Bzr in my new project but i saw that plugin for eclipde is alpha version...I d'like to know if it is usable now
<gnumarcelo> im sorry, im not speak english
<Keybuk> what's the easy command to revert to a previous revision in the current branch?
<andrea-bs> bzr revert
<Keybuk> example?
<andrea-bs> bzr revert -r6
<Keybuk> oh, that easy
<beuno> Keybuk, "bzr revert" will revert to the last revision, or you can do "bzr revert -r revno"
<andrea-bs> it reverts the branch to the revision 6
<Keybuk> oh, easy then
<beuno> yeap. or bzr uncommit if you want to remove all metadata for that commit
<scorpioxy> hey guys, if i have a a couple of standalone branches, would an init-repo after they are created have any effect on their storage optimization? Or does it only work before branch creation?
<beuno> scorpioxy, I would say itwon't affect them at all
<beuno> I'm not sure if you can re-convert them to be shared without re-branching
<james_w> scorpioxy: you can make them use the storage by branching them to a temp dir in the shared repo, and then renaming.
<james_w> scorpioxy: or directly in to the shared repo if you don't create it in the directory that contains the branches.
<scorpioxy> james_w: aha, so creating a shared-repo and then branching from into it....and so, is are we still limited by one level of ancestry for branches and shared repos? I remember that there was a discussion about that some time ago.
<james_w> scorpioxy: what do you mean by one level of ancestory?
<scorpioxy> james_w: i mean any branches that want to use the shared-repo have to be first level children...as in just one ".."(single directory up)
<james_w> scorpioxy: no, they will search down directories and stop at the first .bzr (pretty much).
<Keybuk> and second silly question of the day
<scorpioxy> james_w: you mean search up, don't you? shared-repo would be be parent
<Keybuk> how do I push new tags to another branch? :)
<james_w> scorpioxy: up/down, it depends whether you are standing on your head :-)
<james_w> Keybuk: I think you just do it with a push
<Keybuk> james_w: that says "No new revisions to push."
<james_w> Keybuk: however I think there is a bug report about not pushing tags if there are no new revisions, just new tags.
<james_w> Keybuk: ah, yeah, that sounds like the bug.
<scorpioxy> yes, there is a bug report about that
<scorpioxy> james_w: :) i remember earlier that the shared-repo was only supposed to be one directory up from any branches in this repo...i guess that was changed..
<scorpioxy> james_w: well, i'll give it a try, thanks for the help
<scorpioxy> beuno: thanks for the help too
<james_w> scorpioxy: no problem.
<beuno> scorpioxy, :D
<jdong> jelmer: what do you think about ancestry between bzr-svn and launchpad vcs-imports?
<jdong> it'd be nice if they recognized each other
<jelmer> jdong: There has been talk about that a year or so ago
<jelmer> jdong: We may end up discussing it again this sprint
<jelmer> jdong: but it's really all up to the launchpad folks to decide they want to use the same mappings and revision ids as bzr-svn
<jelmer> it would also involve trashing all existing imports...
<kosipov> hi
<beuno> hello kosipov
<kosipov> beuno: is there a gui tool you would recommend for browsing change history with bazaar?
<beuno> kosipov, have you tried bzr-gtk?
<kosipov> beuno: yes, and qt. I am having a very long history here, > 3000 revisions, and both are quire slow
<kosipov> quite
<jelmer> kosipov: Even newer versions of bzr-gtk?
<jelmer> kosipov: It loads up a 26k revision tree in a couple of seconds here
<kosipov> jelmer: hm.. maybe a bug in the way we imported our revision history here
<kosipov> takes about 2 to 5 minutes
<jelmer> the way you imported your history shouldn't matter
<kosipov> jelmer: I believe I have the latest version here
<jelmer> And you're just running "bzr viz" ?
<jelmer> kosipov: the one from bzr-gtk trunk?
<kosipov> is there a way to find out the total number of revisions?
<kosipov> jelmer: yes, I just bzr branched it
<jelmer> "bzr revno" should print it
<jelmer> (the number of revisions on mainline)
<kosipov> this is very strange then
<kosipov> kostja@dipika:~/mysql-5.1-runtime$ bzr revno
<kosipov> 2624
 * kosipov . o O (why does it take so much time?)
<kosipov> jelmer: hm... mainline we actually have very heavy branching
<jelmer> kosipov: bzr info should be able to print the total number of revisions
<beuno> kosipov, there is also a very-alpha WX-based tool: https://code.launchpad.net/wildcat-bzr
<beuno> what OS are you on?
<kosipov> ubunty gutsy
<kosipov> ubuntu
<kosipov> hm...
<kosipov> interesting...
<kosipov> I started bzr info --verboze and it took 20 secs for it to finish
<beuno> kosipov, I'm on gutsy too and I can navegate _much_ bigger projects very quickly
<kosipov> Branch history:
<kosipov>       2624 revisions
<kosipov>        871 committers
<kosipov>       2770 days old
<kosipov>    first revision: Mon 2000-07-31 21:10:05 +0200
<kosipov>   latest revision: Wed 2008-01-16 01:17:05 +0300
<beuno> what version of bzr are you using?
<kosipov> Repository:
<kosipov>      51009 revisions
<kosipov>     596938 KiB
<kosipov> 1.2
<kosipov> so is above big enough?
<beuno> jelmer, looks pretty big to me  :p
<kosipov> ok, then this is expected I think
<kosipov> I was just wondering
<beuno> kosipov, not sure if it's expected, would be nice if we could look into it a bit
<kosipov> good thing is that when it finally started it works with ok performance
<beuno> kosipov, can you run bzr info again
<beuno> and paste out what repository format you have?
<kosipov> it's the latest
<kosipov> second
<beuno> you might be using an old version instead of the new one optimized for speed (packs-0.92)
<kosipov> or is it not:
<kosipov> Format:
<kosipov>        control: Meta directory format 1
<kosipov>         branch: Branch format 6
<kosipov>     repository: Packs containing knits without subtree support
<kosipov> okay, then the question is how do I change the format?
<kosipov> and also, if I create a branch, does it preserve the old format?
<kosipov> it seems it's not
<beuno> kosipov, your repo seems fine
<kosipov> but working with the branch wasn't too fast either.
<beuno> kosipov, yes, it does
<beuno> kosipov, can you file a bug with this information, noting it's too slow?
<j1mc> hi all.  i'm having a problem where when i've changed my local branch of a repo, and someone else has committed changes on the server.  how can i commit both sets of changes without any conflicts?
<j1mc> or without the commited change showing as reverted, and then re-committed.
<beuno> j1mc, you want both changes merged?  or discard one of them?
<kosipov> beuno: I believe I will be able to give you all the data
<j1mc> hi beuno ... i would like both changes merged.
<kosipov> just writing a report here for our group
<j1mc> my problem is that the committed change shows as reverted, and then recommited at the end.
<kosipov> we're trying to migrate, but first need to check that we can actually work ok
<beuno> kosipov, even more interesting if you can file a bug so we can follow up and help you get the performance you need
<beuno> j1mc, the work flow would be "bzr merge", resolve conflicts, than "bzr commit"
<beuno> and, finally push if you want the final version on main
<kosipov> beuno: I will sure file a bug but when I have a tarball with the source tree with which you can play to attach to it.
<ubotu> New bug: #197426 in bzr "bzr diff message when some files are not versioned is unhelpful" [Undecided,New] https://launchpad.net/bugs/197426
<kosipov> beuno: I need to double check that if I attach this tarball my company is not sued...
<beuno> kosipov, maybe just file it with the "bzr info -v" data to get it rolling, and attach it later on
<beuno> might not need the tarball at all
<beuno> j1mc, you also might not get any conflicts, but you have to commit anyway
<j1mc> beuno: ... ok.  i'm just looking up info on resolving conflicts.  any tips?
<beuno> j1mc, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts
<j1mc> beuno, you are the reason irc is awesome.  :)
<j1mc> thanks for your help
<beuno> j1mc, muehehe, no problem
<kosipov> https://bugs.launchpad.net/bzr/+bug/197429
<ubotu> Launchpad bug 197429 in bzr "bzr gui tools are too slow with old/large repositories " [Undecided,New]
<jelmer> beuno: btw, what airport are you guys flying into tomorrow?
<beuno> jelmer, gatwick I belive. You?
<jelmer> beuno: looks like Heathrow
 * beuno double checks
<jelmer> I'm arriving an hour or a half before you guys but I guess waiting doesn't make sense if it's a different airport ;-)
<beuno> jelmer, confirmed, Gatwick
<beuno> it would be a bit odd to wait for us if we're in different airports  :p
<beuno> I was told to stay away from heathrow for some reason
<ubotu> New bug: #197429 in mysql "bzr gui tools are too slow with old/large repositories " [Undecided,New] https://launchpad.net/bugs/197429
<james_w> in mysql?
<beuno> james_w, he seems to work for mysql
<beuno> and is trying to use bzr with mysql devel
<james_w> ah, ok
<beuno> but, of course, it shouldn't be assigned to mysql
<james_w> kosipov: mind if I drop the mysql part of that bug, it doesn't really reflect where the problem is?
<beuno> jelmer, do you think it should be asigned to bzr-gtk too?  It does seem a bzr problem but...
<jelmer> beuno: If it's consistent across all tools I think it's a bzr problem
<jelmer> perhaps it can be reassigned if it turns out there is a specific issue in bzr-gtk
<beuno> jelmer, 50k revisions doesn't look like a bzr-gtk probem, no. Just wondering if it would be useful for other people reporting the same problem  (it does affect bzr-gtk indirectly anyway)
<jelmer> beuno: well, we can always mark it as a duplicate if people report the same bug although marking it as occurring in bzr-gtk is also fine with me
<beuno> jelmer, nah, it's fine, just a though
<beuno> *thought
<kosipov> james_w: sure
<james_w> kosipov: thanks.
<kosipov> james_w: should I attach the total size of the directory, number of files, lines?
<kosipov> would that help?
<james_w> kosipov: I don't think the exact numbers are necessary.
<kosipov> ;-]
#bzr 2008-03-02
<kumi> If I move (w/ filesystem tools, not w/ bzr) paths around, how do I tell bzr about the new arrangement of folders and files?
<kumi> I had to migrate some code to a new server, which has a different directory structure... "/www/htdocs/" has become "/www/a.com/pages/" and "/www/htdocs/common/" has become "/www/c.com/pages"
<Verterok> kumi: bzr mv --after
<kumi> Verterok: thanks :D
<Verterok> np :)
 * Verterok heading to bed
<awmcclain> Hey all.. is there any way to prevent bzr logfiles from littering my directories after each checkin?
<jelmer> moin
<james_w> hi jelmer
<james_w> awmcclain: to which logfiles do you refer?
<awmcclain> bzr_log.OxncjQ~ bzr_log.RNweuu~
<awmcclain> Commit logs
<jelmer> I think those are only left when bzr aborts a commit
<james_w> awmcclain: if that is not the case then I think a bug report is appropriate
<awmcclain> Hrm
<awmcclain> Bug report!
<james_w> awmcclain: what's your OS?
<jelmer> I think this is Windows-related
<awmcclain> 10.5, running bzr 1.2.0, using vim to edit commits.
<awmcclain> (commit mesages)
<james_w> they are not editor backup files are they?
<jelmer> since it's by default impossible to delete a file unless nobody has it open
<jelmer> actually, I think they are
<awmcclain> So. Silly
<james_w> that's not what vim's look like on linux, but I don't know Mac.
<awmcclain> Yeah, you'd think the ~ would have tipped me off.
<awmcclain> Hrm
<awmcclain> weird though
<jelmer> james_w: if you 'set backup' in vim, it'll write ~ files
<awmcclain> Is there a setting to have the commit files written to /tmp?
<james_w> ah, backup as opposed to .swp, I see.
<james_w> perhaps we should be using $TMPDIR anyway.
<jelmer> james_w: The current setup has the nice side-effect that if bzr crashes during commit, the log file is still there
<lifeless> moin
<ubotu> New bug: #197597 in bzr "branches command slow" [High,Confirmed] https://launchpad.net/bugs/197597
<ubotu> New bug: #197618 in bzr "Document BZR_REMOTE_PATH in man page" [Undecided,New] https://launchpad.net/bugs/197618
<abentley> Hi all.  I'm at the hotel.
<lifeless> hi
<lifeless> I'm at the office
<lifeless> abentley: which hotel are you in?
<lifeless> abentley: hi
<abentley> Hey there.  How's things?
<lifeless> good
<lifeless> at the office at the moment
<lifeless> have you eaten lunch?
<abentley> No.
<lifeless> Henrik Nordstrom and I are considering food
<lifeless> which hotel are you in?
<abentley> I'm in favour of food.
<abentley> I'm at the Rochester.
<lifeless> cool
<abentley> I think all the Canonical people are at the Rochester.
<lifeless> many are, but not al I believe
<lifeless> I'd happily swap to the plaza - they serve prridge for breakfast :>
<lifeless> abentley: we'll come to the hotel
<lifeless> abentley: be about 15 minutes
<abentley> Cool.  I'll be in the lobby.
<seba__> hi
<seba__> i am importing from hg to bzr using fastimport
<seba__> i used to have a crash till last rls
<seba__> and now i have some warning msg like that instead:
<seba__> WARNING: ignoring delete of content/xul/document/public/nsIXULContentSink.h as not in inventory (:65)
<seba__> what does it mean exactly ?
<james_w> seba__: I'm guessing that fastimport is being told to delete that file, but it doesn't think that it exists to delete it.
<seba__> that's rather strange
<james_w> seba__: indeed.
<seba__> i guess a delete from hg was actually made on an existing file
<luks> it might have been done in a different order and hg-fast-export might not handle it correctly
<seba__> bah it failed again now later...
<seba__> I wonder if those fastimport plugin are tested on projects bigger than 5 commits and 1 branch...
<james_w> seba__: I believe it is being developed as the developer is working on importing OO.org
<seba__> oo chose bzr ?
<jelmer> hey
<jelmer> any sprint people awake?
<james_w> jelmer: i am, but I'm not there. Are you after someone there, or just someone who is going?
<thumper> james_w, jelmer: hi
<james_w> hi thumper
<thumper> anyone staying in the rochester?
<james_w> I am, but I don't arrive until Wednesday.
<james_w> I think lifeless and abentley are. They were here a little earlier.
<jelmer> james_w: Just wondering who is here
<jelmer> james_w: I just met up with the two eclipsebzr guys
<jelmer> we're going to get some food in a few minutes
<jelmer> thumper: All the canonical folks are in the rochester
<jelmer> All the non-canonical folks are in the park plaza
<thumper> jelmer: ah, is that the way it is
<jelmer> hmm, LarstiQ either forgot to turn his phone on or is still on the plane..
<nexus10> hi -- can anyone tell me what's the advantage of 'bzr ignore foo-pattern' over 'echo foo-pattern >> .bzrignore'?
<Odd_Bloke> jelmer: Where did you meet the EclipseBzr guys?
<jdong> nexus10: the former's more intuitive to find for the newcomer and the latter makes Git users happy? :D
<jdong> nexus10: (ignore me, I'm in a grumpy flame-git mood today)
<nexus10> jdong :-D
<nexus10> jdong: that's what
<nexus10> jdong: ... I was hoping you'd say -- cos I have some probs with bzr ignore
<jdong> nexus10: Yeah, from a user interface perspective, the first place I'd look for my VCS's "ignore" function would be in the commands list
<nexus10> jdong (and anyone else): is there a "why bzr kicks git's posterior' doc you can suggest?
<jdong> nexus10: indeed there is one on the wiki
<jdong> http://bazaar-vcs.org/BzrVsGit
<nexus10> jdong: ta, I'll go hunt -- dunno how git has got such buzz in the Rails world, but I need some ammo against all that buzz
<nexus10> jdong: fantastic, ta
<jdong> nexus10: I think the reasons are quite compelling, and although that article prefaces itself to be bzr-biased, for the most part I think it's a quite unbiased view of reality
<jdong> nexus10: the one thing I do give Git massive credit for is performance. Git's still noticeably faster than bzr on some tasks (bzr log on 5000 revisions), etc
<nexus10> jdong: I don't need persuading -- but I have a git diehard to win over
<jdong> nexus10: though frankly for the average size project I don't care if I wait another 1 second for log to show
<jdong> the time it took me to figure out how to tell git to stop committing things without my permission, bzr could'll logged itslef a billion times
<jdong> lol
<jdong> nexus10: if this Diehard Git user is a part of a bigger project, cross-platformness will instantly knock him down a few pegs. Force him to live the life of a Windows user for a day, and I bet he'll reconsider his choice :)
<nexus10> jdong: Rails projects are usually small - 2000 files or so
<jdong> nexus10: yep, as I've noticed. I worked on a rails project last summer that was entirely versioned via bzr and all went great
<TFKyle> jdong: bzr log doesn't seem that slow on 3184 revisions here, time bzr log > /dev/null == real 0m4.640s (hot cache though)
<nexus10> jdong: this user was on Windows -- now on gentoo and much happier
<jdong> TFKyle: time git log > /dev/null on the entire mirror of Subversion's repository took less than a second
<jdong> TFKyle: git log is unbelievably fast, but faster than most people would need it to be
<nexus10> speed is addictive
<jdong> nexus10: yes, but in reality most projects would have to address Windows contributors, and Git's frankly unusable under Windows
<jdong> nexus10: its speed and functionality are closely knit with the POSIX model of doing things
<TFKyle> jdong: hmm, indeed
<jdong> nexus10: and something else that might be a concern.... Git has little support for "dumb protocols"
<nexus10> jdong: don't understand why the git buzz is so incessant for Rails
<jdong> nexus10: in particular, to push a git repo somewhere, you almost HAVE to have a git server on the remote end. Which isn't something one can always negotiate
<nexus10> can git even do symlinks properly?
<jdong> nexus10: not sure. I'm not sure if we do that correctly too. At least we can *version empty directories*
<jdong> (which might be something useful in dir-structure-sensitive things like Rails)
<nexus10> indeed
<nexus10> eg -- a Rails plugin has foo.rb and foo/*
<nexus10> rename it and you need to rename both
<TFKyle> jdong: having a bit of a hard time measuring git log's performance btw as it seems to run PAGER. there a quick way to disable that?
<jdong> TFKyle: AFAIK if it's redirected somewhere it would not use a pager
<TFKyle> doesn't here (git 1.5.4.3)
<jdong>        -p|--paginate
<jdong>            Pipe all output into less (or if set, $PAGER).
<jdong> I guess you can set PAGER to (1) nothing (2) cat
<TFKyle> still, I assume setting it to cat hurts it a bit, but meh
<jdong> lol if setting a pager to cat hurts performance, change operating systems :)
 * jdong looks on his HDD for any git repos he has lying around
<TFKyle> (doing that on the wine source tree from maybe a month ago takes ~1.5secs btw
<jdong> how many revisions are in the wine tree?
<jdong> ok I've got a git mirror of Rockbox and a bzr-svn mirror of it
<jdong> the git mirror is 1k revs behind, lemme bring that up and we can compare
<TFKyle> (though, gitk and qgit4 do seem quite slow compared to bzr visualize, dunno why)
<jdong> I wish gitk was a gtk based frontend
<jdong> there's apparently something called gitview somewhere out there
<lifeless> jdong: gitview is based on bzr viz :)
<dudemeister> hi, i have a beginner question here. how do i actually start a project using a centralized style - the user guide seems to cover only the developer's site, but are there tutorials on how to setup the server?
 * TFKyle wishes hg view was gtk-based as well
<jdong> git log > /dev/null  0.60s user 0.00s system 98% cpu 0.615 total
 * jdong waits for bzr
<jdong> bzr log > /dev/null  10.86s user 0.33s system 98% cpu 11.305 total
<jdong> order of magnitude
<jdong> of course, logging 16378 revs is not exactly a "real world usecase"
 * TFKyle still isn't sure how to tell the amount of revs in a git tree, hardly ever uses it :)
<jdong> git rev-list --all | wc -l
<jdong> lol that might be a hack
<jdong> but everything in git seems that way.
<TFKyle> and that's why I love bzr :)
<jdong> and it's ALSO kinda annoying that git's on-disk size explodes when you commit to it
<jdong> kinda forcing you to pack at least once every busy coding day if you don't want the thing taking up 5x the space it should.
<TFKyle> 43449
<nexus10> jdong, TFKyle: thanks, this was v useful
<TFKyle> nexus10: oh, sorry - didn't mean to go off topic
<jdong> TFKyle: yeah, git's fast at operations like this :)
<jdong> but the UI is so.... urg....
<nexus10> TFKyle: no worries, not OT for me
<jdong> I tried to explain Git to someone who uses svn the other day, and he thought I was mocking him
<nexus10> jdong: so the consensus is -- git wins on speed, bzr on evetrything else?
<jdong> i.e. I invented a parody of svn that was hard to use
<jdong> nexus10: roughly put, yeah
<jdong> nexus10: rather, git has a lot of gotchas that should make one think twice before adopting it across some project where not everyone is familiar with the tool
<jdong> nexus10: on my coding project last summer, one guy had no experience with version control, and in an afternoon he was comfortable branching, pushing, pulling, merging..... bzr's that intuitive.
<jdong> I can't say the same about git
<james_w> There was a bunch of patches to the git list the other day to make it halfway windows compatible.
<james_w> so, the git on windows effort seems to be progressing ok.
 * jdong bzr branches his todo list ponders the real-life meaning of what he just did.
<abentley> jelmer: no
<abentley> :-)
* lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org//SprintLondonMarch08
<weigon> lifeless: the link needs a /Sprint .. instead of //Sprint
* lifeless changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.2 is out! | https://launchpad.net/bzr/1.2/1.2 | Sprint wiki page: http://bazaar-vcs.org/SprintLondonMarch08
<h4writer_> Hi
<h4writer_> hope I can ask a question related to launchpad and bzr here?
<h4writer_> I have locked my own branch :-(. How can I unlock it
<elmo> bzr lazy imports are self-created and not a standard python thing, right?
<elmo> h4writer_: bzr break-lock, I think?
<lifeless> elmo: impoty bzrlib.lazy_import
<h4writer_> doesn't do the job, but I had this before and had to use sft
<h4writer_> *sftp
<lifeless> h4writer_: bzr break-lock URL
<elmo> lifeless: ok - not sure I wanna make dak depend on bzrlib :)  thanks
<h4writer_> Still having the issue
<h4writer_> :-(
<h4writer_>  bzr break-lock bzr+ssh://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons
<h4writer_> doesn't do anything
<lifeless> elmo: go on
<awmcclain> Is there a way to set a configuration value across all users and branches?
<awmcclain> h4writer_: Total shot in the dark, but have you tried bzr break-lock sftp://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons ?
<h4writer_> awmcclain, Indeed I thought it was that, but it isn't helping either :-(
<awmcclain> :(
<h4writer_> awmcclain, still locked, already for 30 min. :-(
<awmcclain> ...or is the only way to specify a branch.conf in each one of my branches?
<poolfool> h4writer_: you tried both 'sftp://' and 'bzr+ssh://' ?
<h4writer_> poolfool, indeed
<h4writer_> but I see there are some processes busy with bzr if I do "ps -ax | grep bzr"
<poolfool> h4writer_: What is with the '+' plus sign in your path? ... what exactly is displayed on your screen about the lock OR when you try and break the lock?
<h4writer_> poolfool, when I try to break it, nothing happens (so I get nothing returned)
<poolfool> h4writer_: Wait ... 'ps -ef' on your local machine or on the lauchpad server?
<h4writer_> poolfool, local
<h4writer_> poolfool, can't kill those :-S, how come that
<poolfool> h4writer_: do you own the process ? '#ps -ef |grep bzr' and check the User ID (uid).
<h4writer_> poolfool, don't know, but I now killed them with system monitor :-D
<h4writer_> poolfool, still locked :-(
<h4writer_> poolfool, ?
<h4writer_> poolfool, I did the committing with sftp
<h4writer_> poolfool, and now it works
<poolfool> h4writer_: Yea ... kind of new to bazaar my self. but you did fix the 'lock' problem? But you can commit with sftp?
<h4writer_> poolfool, I didn't fix the lock problem. I still have it when I try with bzr bzr+ssh:// LOL
<Polarity> If I want to track /etc with bzr, what is the proper way to ignore all the rcX.d directories?  rc.d/rc*.d/ in .bzrignore doesn't seem to work
<h4writer_> poolfool, only a workaround :-(
<h4writer_> poolfool, lifeless, awmcclain and elmo thank you for helping. I can do again further :-D
<poolfool> Polarity: I saw something on the channel the other day, someone is doing the same thing but with Ubunto(sp) ... maybe a google search might help.
<poolfool> Polarity: But sounds like something I have wanted to try for a while. Good luck.
<TFKyle> lifeless: playing around with loom a bit, this has probably been suggested before or is total crack but would something like a goto-thread command to go to a specific thread instead of manually up/downing multiple times be a good idea?
<lifeless> TFKyle: 'bzr switch threadname'
<ubotu> New bug: #197748 in bzr "getattr on WorkingTree should not raise ObjectNotLocked" [Undecided,New] https://launchpad.net/bugs/197748
<lifeless> going out to dinner now, back tomorrow UK morning time
<TFKyle> ah, cool
<CarlFK> I was tole to:  bzr co http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk
<CarlFK> but that errors.
<CarlFK> while I wait, is there any poking around that might help?
<dato> CarlFK: "co" with "http" doesn't make much sense. but what error do you get?
<CarlFK> http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk/ is permanently redirected to https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/
<CarlFK> bzr: ERROR: Not a branch: "https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/".
<dato> CarlFK: they gave you a wrong URL
<CarlFK> yep
<CarlFK> "Never mind, I've attached the full checkout tarball."
<stefanv> a colleague of mine requested similar functionality to "hg cleanup" -- which removes all unknown files in the current working tree.  i wrote a small script to do just that... would it be of any interest?  how hard would it be to convert it to a plugin, or to add it as a command?
<dato> stefanv: hm. "clean-tree" from the bzrtools package can do that
<stefanv> great, thanks for the pointer
<radix> I often just use rm `bzr unknowns`. (adding -r when necessary)
<stefanv> that's probably fine for posix
<stefanv> i'm not sure what he is running
<stefanv> unknowns must be fairly recent
<awmcclain> Anyone know... can I use pyqt4 with qbzr?
<Peng> Soo.
<Peng> Remind me not to get swapped to death (presumably by svn-import) in the future.
<awmcclain> Ug. What a nightmare it is to compile PyQt on a mac.
<poolfool> awmcclain: don't tell me that ... I am still looking for something nice to run on Mac OS X (leopard) with an OK gui.
<poolfool> awmcclain: Do you have a good link for a Mac OS X tool chain? Have you tried fink?
<awmcclain> poolfool: Ug. I'm not a huge fan of fink. Plus i think they only have pyqt3, not pyqt4. One of htese weekends when things die down I'm going to start a cocoa app for bzr.
<awmcclain> poolfool: Wildcat works pretty well, except for the fact that it doesn't work. ;)
<luks> ... and qbzr is no an 'app' :)
<luks> *not
<awmcclain> luks: Well, an "app" that has extensive, non-trivial dependencies. :)
<luks> no, I mean it's more like tortoise* except that instead of using a graphical shell you use the command line
<luks> there is no actual application that would run on it's own
<awmcclain> I'm confused... did you mean bzr or qbzr is not an 'app'?
<luks> qbzr
 * awmcclain scratches his head.
<luks> the dev version has a partially-working standalone application, but I guess I'll never finish that
<poolfool> luks: did you write qbzr ?
<luks> mostly because I know that I won't use it, so I'm not very motivated :)
<luks> yes
<awmcclain> :)
<awmcclain> Oh, I see.. you mean you have to invoke qbzr from the command line
<luks> more that you invoke qdiff, qci, etc. from the command line
<awmcclain> ahhh...
<awmcclain> luks: Can qbzr give me a graphical display of bzr status?
<luks> yes and no :)
<awmcclain> meaning it shows me the console output in a window?
<luks> qcommit shows you the equivalent of bzr status
<luks> but there is no standalone command for that
<awmcclain> No, that's fine
<awmcclain> Can you step through each file and get a graphical diff?
<luks> sure
<awmcclain> And finally....can you resolve conflicts through it?
<luks> and add files, revers, etc.
<luks> *revert
<luks> no
<awmcclain> ok.
<luks> but this one is on my todo list pretty high
<awmcclain> mmm
<awmcclain> any sense of timeline?
<luks> depends on when will I have to deal with first conflicting merge :)
<awmcclain> Bascially I'm just looking for a way to 1. see the specific changes going out and 2. be able to resolve conflicts using a side-by-side diff.
<luks> I definitelly don't plan writing a merge tool
<luks> so resolving conflicts would involve just involving an existing tool
<awmcclain> Ah yes, sorry, I wasn't more clear... can you pipe those diffs to diffmerge or something? I'm just looking for the workflow, really.
<luks> at the moment, no
<awmcclain> ah.
<luks> it just uses internal side-by-side diff viewer
<awmcclain> Basically I'm just looking for the eclipse-style team synchronization view. (But we've abandoned eclipse, thankfully)
<luks> hm, I've never used eclipse with a VCS
<luks> http://publib.boulder.ibm.com/infocenter/wsphelp/topic/org.eclipse.platform.doc.user/images/Image245_sync_view.jpg ?
<awmcclain> Pretty much, yeah. You see files incoming, files outgoing, ignored and conflicts.
<awmcclain> I suppose I could just run extmerge with a file merger for file conflicts.
<luks> I'm afraid qbzr isn't going to help you much in it's current state
<awmcclain> S'ok. :)
<luks> I seem to need a GUI for quite different actions
<awmcclain> branching and such?
<luks> no, mostly history browsing
<awmcclain> ahhh
<awmcclain> we have bzr-trac for that. :)
<awmcclain> (which also doesn't really work. ;) )
<luks> :)
<awmcclain> Is there any way to see, when you update, what the exact merges will be?
<stefanv> something a bit more detailed than bzr missing?
<awmcclain> now that I know about bzr missing, i think, no. :)
<luks> ditch the checkout, use a real branch, merge --preview? :)
<mc__> I've accidentically remove am file with rm. Can I restore it with bzr? (It was version controlled of course)
<ferringb> mc__: bzr revert file # should do it.
<mc__> thanks
<ferringb> any security issues w/ bzr server for ro access?
<ubotu> New bug: #183565 in trac-bzr "KeyError: 'root_directory'" [Low,Incomplete] https://launchpad.net/bugs/183565
<james_w> ferringb: none known, but I don't think it's been audited
<ferringb> mmm
<ubotu> New bug: #57447 in trac-bzr "Viewing changeset diffs is slow" [Low,Triaged] https://launchpad.net/bugs/57447
<ubotu> New bug: #126835 in trac-bzr "COPYING file not being included in tarball" [Low,Fix committed] https://launchpad.net/bugs/126835
<ferringb> james_w: do you know what sort of perms it requires?  specifically, I'm thinking about locking on the repo
<ferringb> I'd rather run the server as a user that has no write access on disk personally
<james_w> ferringb: that should help.
<james_w> ferringb: there are read and write locks taken out by bazaar, and working tree, branch and repo locks.
<ferringb> yeah, that's specifically what I was concerned about
<james_w> some of the read locks are just nops, but I can't remember if all are.
<ferringb> mmm
<ferringb> well, I'll experiment
<ferringb> server is fast enough I'm going to bring it up- 3.2k revs, http pull has been pretty painful for our users
<james_w> read only on everything except .bzr/whatever/lock/ should be ok I guess.
<james_w> Obviously not ideal, but better than nothing.
 * ferringb nods
<james_w> ferringb: does bzr+http:// not suit you?
<ferringb> james_w: wasn't even aware of it- specifics?
<james_w> ferringb: well you can serve over http://
<james_w> however for better performance you can use the "smart server", which requires bzr to be installed on the server.
<ferringb> yeah, bzr server; thought that was 'bzr branch bzr://...' ?
<james_w> That means you can use bzr+ssh:// for people you trust and need to grant write acess to.
<ferringb> ah, right
<james_w> And you also get bzr+http:// which is fast readonly (though I've never used it, so don't believe everything I say)
<ferringb> mmm
<ferringb> how do you setup bzr+http:// ?  only familiar with bzr+ssh
<james_w> and bzr:// which is a native tcp protocol, which by default is read only, but you can grant write access with.
<james_w> and allows read access to every file beneath the directory you serve.
<james_w> ferringb: http_smart_server in the docs. Do you have the source of bzr? Otherwise what OS are you on?
<ferringb> linux, likely have docs, but didn't see it in the --help
<james_w> It's not a help topic, but a doc
<ferringb> this up on the site at all?  I went looking for perf. stats on bzr --server (and a quick intro to it), but didn't find anything
<james_w> /usr/share/doc/bzr/txt/en/user-guide/http_smart_server.txt.gz
<james_w> for me on Debian/Ubuntu
<james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<james_w> it's got a big fat warning on that section, so maybe it is not trustworthy.
<james_w> Serving over plain http should be pretty secure for read only access.
<james_w> It is slower though, so if you have a large project it would be far from ideal.
<ferringb> well hell
<ferringb> been forcing people to use http://; speed up is a speed up, even if I just use bzr+http:// ;)
<ferringb> james_w: does bzr+http play nice with shared repositories?
<ferringb> it's giving me a 404 error indicating it doesn't ;)
<james_w> ferringb: you trying to branch a shared repository, or a branch in a shared repo?
<ferringb> branch a shared repo
<ferringb> bzr.pkgcore.org/ferringb/pkgcore-dev; trying to pull that down, /bzr/ferringb/pkgcore-dev, shared repository at /bzr/
<ferringb> mmm.  screw it, bzr:// it is (it's fast enough I'll shove through the permissions issues)
<ferringb> james_w: thanks for the info
<james_w> ferringb: no problem. Feel free to ask again if you need any more info.
<fullermd> bzr, bzr+ssh, and bzr+http use mostly the same code, so they should be equally speedy and secure (or slow and insecure)
<ferringb> heh
<ferringb> hell, I'm just happy to see smart server is around- been waiting for it a while, *very* happy to see a 71s checkout for users rather then the usual ~15m affair
<LaserJock> jelmer: friendly ping on getting newer bzr-svn in PPA for gutsy :-)
#bzr 2009-02-23
<lifeless> it will make subunit-ls clearer, so if you get the time to review, assume its gone :)
<mwhudson> ronny: have you read "xUnit test patterns"?
<lifeless> spiv: stacked [merge] sent
<ronny> mwhudson: no
<mwhudson> ronny: the first 100 pages or so is well worth reading for provoking thoughts about testing
<ronny> hmm, added to my should read list
<mwhudson> it's unfortunate that you have to buy the other 700 pages too :)
<ronny> ew
<edcrypt_> igc: ping
<igc> edcrypt_: pong
<edcrypt_> igc: hi, I the one who made that bug report about views
<edcrypt_> igc: what is the view-aware API to iterate on the WT?
<igc> edcrypt_: there probably isn't one ...
<igc> I tend to trap most things at the UI layer inside builtins.py ...
<igc> so that the list of files is automagically passed to commands without needing to change their internals
<igc> edcrypt_: there are exceptions though ...
<lifeless> igc: shouldn't it filter at the tree?
<igc> diff comes to mind
<lifeless> igc: so that plugins work
<igc> lifeless:it depends
<igc> whether to use a filtered view needs to be considered on a case by case basis
<edcrypt_> igc: WorkingTree..inventory.iter_entries_by_dir() gives all files, but probaly I shouldn't be using it
<igc> edcrypt_: so if you look at the code for cmd_diff in builtins.py, you'll see it passed apply_view flag down to the next layer
<igc> edcrypt_: you certainly can use that API, you'll just need to post filter the results by seeing if the path falls inside the view or not
<igc> thst's not hard - see the examples at the top of builtins.py (like internal_files_for_add say)
<igc> s/thst/that/
<edcrypt_> igc: ok, taking a look, thanks!
<igc> np
<igc> edcrypt_: any you looking at fixing ls for me? :-)
<lifeless> igc: in what cases is the answer 'no' so far?
<igc> lifeless: merge, log, info at least
<edcrypt_> igc: hehe, maybe, I have just learned hwo to create a plugin!
<edcrypt_> igc: _check_path_in_view()
<edcrypt_> ops, diff._check_path_in_view()
<spiv> lifeless: reviewed, bb:approve
<lifeless> woo
<igc> edcrypt_: might be good to make that a public function in views.py instead of a private one in diff.py.
<edcrypt_> igc: indeed
<lifeless> spiv: ok, thats sent.
<jelmer> luke-jr, hi
<igc> poolie: fyi, here's my plan for today
<jelmer> luke-jr, any chance you can comment on bug 326278?
<ubottu> Launchpad bug 326278 in bzr-svn "'bzr log' KeyError" [Undecided,Incomplete] https://launchpad.net/bugs/326278
<igc> 1. get usertest tweaked with some of the changes on the roadmap
<lifeless> jelmer: ping
<jelmer> lifeless, pongz0rz
<igc> 2. ping you and we'll update orchadas
<igc> 3. land content filtering after chatting with you
 * igc bbiab - food calling
<lifeless> jelmer: could you do a pass over your subunit branches, and submit for merge where relevant
<jelmer> lifeless, k
<lifeless> thanks
<poolie> igc, sounds good
<poolie> my laptop won't boot, i'm guessing because of bug 333073 in jaunty :/
<ubottu> Launchpad bug 333073 in linux "very slow boot with lvm-on-dmcrypt" [Undecided,New] https://launchpad.net/bugs/333073
<poolie> that gave me a bit of a setback
<poolie> but let's talk anyhow when you're done
<garyvdm> Hi - when I run bzr shelve - I get the following prompt:
<garyvdm> Shelve? [yNfq]
<garyvdm> yes No f???? q????
<garyvdm> Where can I find more info. bzr help shelve does not say anything.
<poolie> q is quit
<poolie> does ? do anything?
<garyvdm> no
<garyvdm> no - ? seams to cause no which is the default action - lol
<poolie> srsl? :(
<mwhudson> f flips the defaults
<lifeless> Odd_Bloke: is workng on this I thought
<garyvdm> mwhudson - I jest tested that - f seems to do a "full" diff?
<mwhudson> oh
<mwhudson> i'm wrong then
<garyvdm> ok - it easy to figure out - but irritating.
<poolie> it should definitely be able to give you help
<poolie> igc, back in 5
<lifeless> spiv: ok with that sent off I'm looking at the next round trip
<lifeless> spiv: another regression - we're not using find_repository to do the iteration for us
<lifeless> we're walking up dirs manually
<spiv> lifeless: actually, I'm not sure if that ever worked...
<spiv> But yes, it'd be good to fix that.
<spiv> Also, coffee is good...
 * spiv does something about that
<lifeless> I'm fairly sure it did at one time ;)
<lifeless> but I could be wrong
<spiv> Me too :)
<jml> new small lp-open patch just sent to mailing list.
 * jml doubles as an IRC notification bot.
<mwhudson> :)
<lifeless> spiv: I want to delete InterPackToRemotePack
<poolie> igc, i'm free now if you are
<poolie> lifeless: +1 (minus a bit for not being right there in the code atm)
<spiv> lifeless: so that was only doing two things
<spiv> lifeless: (IIRC).  calling the autopack RPC, and making sure _walk_to_common_revisions walks 50 revs at a time
<spiv> lifeless: the streaming push takes care of the former, I think the latter might be taken care of by the InterOtherToRemote?
<spiv> lifeless: if so, I don't see any reason to keep it either
<lifeless> spiv: yeah
<lifeless> spiv: thats why I want to delete it; and am doing so ;)
<spiv> Ok.  +1 :)
<spiv> I'm glad to see the set of InterRepos shrinking for once :)
<lifeless> http://paste.ubuntu.com/121655/
<lifeless> I'd like to just toss that at pqm - pass land fail I'll look into it
<lifeless> spiv: ^
<spiv> lifeless: sure, if it passes, then +1
<spiv> lifeless: or rather, bb:approve :)
<mwhudson> jml: your blug reports footnote doesn't seem to exist
<jml> mwhudson: mea culpa
<mwhudson> i think i just made the annotate view in loggerhead twice as fast
<lifeless> mwhudson: good
<lifeless> :)
<mwhudson> by not calling annotate_iter twice!
 * mwhudson sighs
<lifeless> mwhudson: its amazing how little things can make a difference :)
<lifeless> mwhudson: I have a suggestion for you
 * mwhudson listens
<lifeless> this is for testing
<lifeless> create a little delegate branch
<lifeless> which logs all the calls made to it
<lifeless> and has a repository object it can return which likewise does the same for the branches repository
<lifeless> you can do two things with this
<lifeless> when asking 'why is X slow' you can see the api calls being made
<lifeless> and secondly you can write a test that no more than a certain number of calls/exact calls etc are made
<mwhudson> hmm
<lifeless> the former is useful for exploring
<lifeless> the latter is useful for locking down a behaviour ratchet
<mwhudson> certainly, something i've been doing lately is removing the layers between loggerhead and bzrlib
<mwhudson> and it was in the process of doing this that i found this problem
<lifeless> spiv: I'd like to make RemoteRepository.*write_group* no-ops like knit/weave repositories
<spiv> lifeless: the _real_repo would still need to have a write group, though?
<lifeless> well
<spiv> lifeless: or are we avoiding enough vfs ops now?
<lifeless> as a start point we may find points that break
<lifeless> at the moment though it and repo.lock_write are triggering _ensure_real
<lifeless> actually
<lifeless> lock_write doesn't trigger _ensure real
<lifeless> but its a noop for pack repos
 * spiv nods
<lifeless> light weight commits will still need vfs
<lifeless> but bound commit shouldn't
<lifeless> calls 13 through 18 are RemoteRepository.start_write_group(), in the acceptance test
<lifeless> spiv: ok, BranchFormat.network_name next I think
<lifeless> spiv: ping
<lifeless> bah
<lifeless> spm: ping
<spm> lifeless: pong
<lifeless> spm: I think pqm is hung, can you check please?
<spm> sure
<jml> did jelmer's clean-tree patch get reviewed?
<spm> lifeless: it was wedged pretty good. should be rockin again
<lifeless> spm: did you note the cause?
<spm> looked like the old email thing; but that didn't fix it. the sendmail was then hanging around as a defunct process. ie still wedged.
<lifeless> ok, I'll try the merge again
<spm> damn. it's rewedged itself. looks like on the original one too.
<igc> poolie: I'm back
<lifeless> spm: ok, patch is bad anyhow, so I suggest just removing the request from me and killing the bzr child
<lifeless> spm: you shouldn't ever kill the pqm parent when a test is wedged
<igc> is it just me or does bazaar-vcs.org seem really slow these last few days?
<spm> lifeless: yeah - that was a pebkac. :-( did the chroot kill without a dir specified. clobbered everything :-( x 3
<lifeless> spiv: we need a 'refresh your data' api for all repositories
<lifeless> spiv: because this streaming push can work for knits, but we can't let it try :>
<poolie> igc, hi?
<igc> hi polie
<igc> poolie:^
<igc> poolie: you ready to do this orchadas stuff?
<poolie> hey
<poolie> i am
<poolie> i hit an ubuntu bug 332270 that stopped my laptop booting and messed up my day a bit
<ubottu> Ubuntu bug 332270 in udev "udev repeatedly generates "change" events for the same block device(s)" [High,Triaged] https://launchpad.net/bugs/332270
<igc> poolie: yum
<igc> poolie: let's start by having a quick call maybe?
<poolie> that's why it's called an alpha
<poolie> good idea
<poolie> i'll call your home?
<igc> sure
<jam> lifeless: I have some theoretical reasons why multiparent with xdelta is smaller than gc, care to have a call about it tomorrow?
<poolie> hello jam
<jam> hi poolie
<jam> just heading off to bed after perusing the ~200 emails that came in over the weekend...
<lifeless> jam: I'd be delighted
<jam> lifeless: k, ping me when you wake up
<jam> I'm going to sleep now
<lifeless> jam: ciao
<lifeless> jam: I'd expect the theoretical reason is deltas composition rather than recipes
<lifeless> but see recipes for why gc is fast at extraction
<maco> um, bzr just said "bzr: ERROR: exceptions.AttributeError: children" and aborted the commit i told it to do. how do i make it successfully commit?
<lifeless> maco: what bzr version?
<maco> 1.12
<lifeless> maco: uhm
<lifeless> maco: is there more in ~/.bzr.log ?
<maco> lifeless: it spit out a backtrace
<maco> i'll pastebin it
<maco_> kernel panicked
<maco> http://paste.ubuntu.com/121690/
<maco> lifeless: ^
<lifeless> maco: can you pastebin the output from 'bzr st' please
<lifeless> (parent appears not to be a directory)
<maco> just "added: .kde@"
<lifeless> so .kde is a symlink
<maco> i just made ~/config-backup, cd'd there, and did "bzr init" then tried to do "bzr add ~/.kde/share" and some other directories, but it didn't like that, so i made the symlink
<maco> yes
<lifeless> ok
<lifeless> so we'll make a bug for the error, because it shouldn't be happening; but if you're trying to backup your .kde directory, a symlink to it won't do that - bzr will version the symlink
<maco> i didnt give it ~/.kde to version though
<edcrypt_> igc: merge request sent (make ls aware of views)
<maco> i gave it ~/.kde/share and ~/.kde/Autostart and ~/.kde/env
<lifeless> you need to either make ~/.kde a symlink to your bzr tree, or actually bzr init in ~/.kde
<lifeless> maco: you did 'ln -s ~/.kde' inside config-backup didn't you?
<maco> yes
<igc> edcrypt_: thanks!
<maco> but then i did bzr add on .kde/share, not on all of .kde
<edcrypt_> igc: np
<lifeless> maco: right, so I think I know what the bug is
<lifeless> maco: however fixing it won't do what you want, so give me a second to record the issue
<maco> was trying to get around it giving "NotBranchError: Not a branch: "/home/maco/.kde/share/"." when i did "bzr add ~/.kde/share"
<maco> ok
<poolie> igc, ok, i got a report with just one tool running
<maco> is it not possible to give an absolute path to bzr add?
<poolie> now i'll try it with some more though that will be slower
<lifeless> maco: no, its not possible
<lifeless> maco: bzr requires that all the files it versions are underneath a .bzr directory containing the 'tree' to be versioned
<lifeless> maco: roughly, thats where you do 'bzr init'
<lifeless> maco: so if you want to version ~/.kde/share, you must have done 'bzr init' in one of: ~/.kde/share, or ~/.kde, or ~
<lifeless> maco: I've filed a bug for the specific error you're getting, but the actual fault is in 'bzr add' :(
<maco> lifeless: ok thanks. a friend suggested avoiding putting it in ~/.kde in case of the next time i blow away ~.kde but i'll just have to remember to keep a backup of the .bzr that's in there
<lifeless> maco: put it in ~/.kde like so:
<lifeless> rm -rf ~/config-backup; cd ~/.kde; bzr init; bzr add [things]; bzr commit -m "start versioning ~/.kde"; bzr push ~/config-backup
<igc> poolie: cool
<lifeless> maco: now config-backup is a backup
<maco> ah ok good idea. thanks!
<lifeless> my pleasure
<poolie> http://benchmark.bazaar-vcs.org/usertest/summary.html
<maco> if i do "bzr remove" it doesnt remove the file, right? just stops doing version control on it?
<poolie> if you do rm --keep it will do that
<maco> or well...how do i tell it to not track anything in share/apps/kmail/*/*? bzr ignore? and will that get rid of its past control of those files or not?
<poolie> if you have already added them, and you want to just ignore them in future you need to both remove --keep and also ignore them
<poolie> igc, still here?
<maco> ok
<maco> thanks
<igc> poolie: yep
<poolie> i'd like to make something that will feed usertest output into rrd
<poolie> so we have an over-time plot of results
<maco> er, was i supposed to ignore or remove first? bzr diff still shows stuff from those files
<lifeless> maco: bzr ignore ./share/apps/kmail/
<poolie> i'd probably start with getting the total scenario time for each tool
<poolie> and recording that each time we execute
<lifeless> maco: ignore and remove
<poolie> so firstly ,is this redundant with something you've done
<maco> ok thanks
<igc> poolie: no, I'm yet to produce rrd friendly output
<poolie> bearing in mind it has to run on a dapper machine with no added software
<poolie> and secondly, what should i start from?
<poolie> oh
<poolie> actually for the overall time, now that we're running each test separately, it's obviously easy
<poolie> to do it from the driver script
<poolie> i'll do that first then see how we go
<igc> poolie: ok
<igc> poolie: btw, new usertest just pushed with Description column added to the html report
<igc> poolie: that will reduce the # of times I need to explain what each task/action does :-)
<poolie> scalability :)
<igc> rev 151 also fixes the colouring when multiple projects are given in the one html report
<igc> i.e. colouring is per project, not just against the first column :-(
 * igc dinner
<Odd_Bloke> lifeless: I have a branch to fix the prompt up.  I'll send it in now (as the branch it depends on has been merged now).
<ronny> yo
<Peng_> lifeless: FWIW, I always run latest bzr.dev, and the streaming push work hasn't broken anything for me. I don't use stacking though.
<spiv> Peng_: that's good to know.  Does that include using bzr.dev on the server?
<Peng_> spiv: Yes.
<Peng_> Except for once half an hour ago, where the revisions on the client and server were incompatible, so I had to do one push over sftp.
<lifeless> Peng_: thanks
<lifeless> Peng_: is it faster?
<Peng_> lifeless: Sorry, but I don't really pay attention. It takes more than 1 second, so I always do something else while it runs.
<lifeless> Peng_: fair enough
<Peng_> I always run it through "time", and yet I never read the results. :P
<lifeless> LOL
<jelmer> moin lifeless, Peng
<ronny> lifeless: are there any plans to support custom objects in the history store at one point?
<Peng_> jelmer: Good morning.
<lifeless> ronny: no; as we discussed before I think we'd need to see more examples of custom things before being able to design a good reliable & sufficient interface
<lifeless> ronny: so its not 'no, never' its 'no, no _plans_ at the moment, open to things as we see people doing it in plugins'
<ronny> k
<jelmer> lifeless, what happened to the annotated code stuff you were discussing with James in London during the summer?
<jelmer> can't remember the exact name you were using
<ronny> the main use-cases *i* see is signed tags, code-review, testresults
<james_w> jelmer: "marks"?
<jelmer> james_w, yeah, that's it
<james_w> I don't know if lifeless has done any work on it, I certainly haven't
<james_w> I would love to have it though
<james_w> the thing that I'm not sure about is how to store the marks
<james_w> "file-id hunk-start hunk-end sha-of-hunk" might work I guess
<lifeless> jelmer: views
<lifeless> jelmer: erm
<lifeless> views/filters/tags something like that
<lifeless> marks maybe?
<lifeless> james_w: yeh I started sketching htat
<ronny> hmm
<lifeless> haven't gone far; performance is a major issue first
<lifeless> ronny: so for all of those, I'd definitely help you get support in the core as hooks, so that plugins can do them
<lifeless> and once we see what plugins *do* with those hooks look at the design for core inclusion of extensible things
<ronny> lifeless: atm im puting together a nosetest plugin for subunit
<james_w> lifeless: if you've committed anything I'd love to take a look
<james_w> lifeless: I understand that it's not your first priority
<ronny> lifeless: subunit could use a setup.py
<lifeless> ronny: yeh, though it builds native C and shell and stuff; setup.py isn't really a good fit there
<jelmer> scons isn't either though >-)
<ronny> lifeless: at least for the python part
<lifeless> jelmer: scons was an awful nightmare that I regret
<lifeless> ronny: certainly thats doable yes
<lifeless> I think there is a branch
<lifeless> ronny: http://www.somethingaboutorange.com/mrl/projects/nose/doc/plugin_interface.html#prepareTestResult
<lifeless> prepareTestResult(self, result)
<lifeless> seems to be the bit
<lifeless> lp:~lifeless/subunit/filter has the latest subunit branch I was tweaking
<ronny> would you mind if i would put nosetest support directly into subunit ? its basically just replacing the reporter
<lifeless> ronny: I'm not sure what you're asking
<lifeless> ronny: but note bug 332770
<ubottu> Launchpad bug 332770 in subunit "provide a nose extension to output subunit" [Undecided,New] https://launchpad.net/bugs/332770
<ronny> lifeless: thats what i do atm
<lifeless> which is to say, I'd like it if installing subunit added an option to nose [if nose is installed]
<lifeless> I don't want subunit to depend on nose though
<lifeless> I consider it a lower level helper
<ronny> ok, so separate repo it is
<lifeless> ronny: hm? Not sure I follow, however I'm tired :)
<lifeless> so - chat with you in ~ 7-8 hours
<ronny> k
<ronny> cu later
<jam> morning vila, I hope you had a good weekend
<vila> jam: hehe, hi ! Yes, pretty good, didn't touch a mouse nor a keyboard (didn't happen for a while :)
<vila> jam: how was yours ?
<jam> jelmer: I'm getting timeouts while trying to access a signature file on your dulwich branch
<jam> vila: pretty good
<jam> sat was a kids birthday party
<jam> so it was fun to see Kareem playing with the neighbor kids
<jam> I didn't get back to a comp until late Sunday night as well
<jam> jelmer: lp also seems to be having problems with that branch
<jelmer> jam: us2 seems to be under heavy load at the moment, one of the admins is looking into it
<jam> jelmer: k. It seems funny since everything works until the .six
<jam> vila: still looking into the mysql stuff?
<vila> jam: on my right screen, yes
<vila> jam: trying to find a better ftp test server on the left one
<vila> jam: I was so close :-/ And had problems *again* with FtpStatResult and the test suite being too demanding for ftp :-/
<Peng_> Hmm, it took 438.396 seconds to pull one revision from subvertpy. bzr-svn is still going. Did my connection hiccup?
<vila> jam: the idea was to spend a couple of hours only on it and then address the fact that we can't test under 2.6 anymore until we avoid using medusa there which requires another one
<vila> jam: I hate ftp
<vila> <cough> that was rude, ftp doen't like me that much
<jelmer> Peng_, server is having issues
<jam> vila: Would it be easier to just get medusa working with 2.6 ?
<Peng_> Oh. Oh! I did read backlog, just not enough to understand it. Alright. :)
<vila> jam: no, far harder as the bug is deep down inside asyncore/asynchat or something (I suspect the problem is roughly that somewhere in an iterator str() objects are special-cased and unicode isn't, ugly business), so the idea was to just stop using medusa for >= 2.6 and find another ftp test server
<vila> jam: I found one that doesn't require running as root, only to find that it returns an empty list when asked to list a non-existing directory and has no problem giving the *size* of a directory
<jam> vila: why would we be using Unicode anywhere...
<jam> at the FTP level, everything should be 8-bit strings, (I think)
<vila> utf-8 (sorry)
<jam> vila: we wouldn't be special casing a utf-8 string
<jam> as it is just another 8-bit string
<vila> but at some point giving utf-8 means handling unicode (from memory)
<vila> jam: I don't remember exactly the problem, certainly it was on server side, and ... well there is little we can do there :(
<jam> vila: I don't know the failures, but everything *under* FTPTransport should be 8-bit strings. I suppose if we have a unicode file on disk there may be other issues
<jam> vila: does everything fail?
<jam> Or is it just a couple tests that we could say "py2.6 + unicode files + medusa is KnownFailure"
<jam> vila: I certainly would rather you spending your time on other things :)
<vila> under 2.6 with medusa, failures are about utf-8 encoded file names IIRC
<jam> vila: exactly, so wrap tests that do exactly that with KnownFailure and get on with your life :)
<vila> jam: I know :-/ I hoped to be done with it far quicker and then... well each bug looks like the solution was close :)
<eferraiuolo> Can I expect the Mac OS X 10.5 Installer for bzr 1.12 soon?
<vila> hmm, not sure we can peak under the cover to realize we are under 2.6 + medusa + whatever, the idea was to shorcut at get_transport_permutations
<vila> get_test_permutations I meant
<Peng_> eferraiuolo: "tonight (European time)" according to a post on the mailing list :)
<eferraiuolo> Peng_: thanks for the info :-)
<vila> jam: to be precise, I have a test server that pass the test suite, with a relaxing constraints patch against bzr.dev, so that's not *that* bad :-)
<jam> jelmer: I have a trivial patch to 'dulwich' which should help the performance of 'apply_delta'. Care to test it out?
<jam> http://paste.ubuntu.com/121930/
<vila> jam: on the bbc front all the remaining failures will require a bit of work and I wanted to start with a bzr.dev merge which raise to many conflicts to be solved quickly, so *that* was pushed out of the parrallel activities which are now back to the two mentioned above :)
<jam> vila: sure. I'm also submitting the "trailing whitespace" fix
<jelmer> jam, Is that against the current trunk? James also submitted a performance improvement yesterday
<jam> which is going to be bad for merging into bbc
<jam> jelmer: versus 154
<jam> it just changes to use a list and append
<jam> and then ''.join() at the end
<jelmer> jam, ah, cool
<jelmer> jam, can you "bzr send" or is it easier if I just pick up from pastebin?
<jam> that should avoid O(N^2) performance
<jam> I haven't committed, but I can and I'll send it
<vila> jam: by the way, if *you* are able to merge bzr.dev cleanly in bbc, just tell me :-)
<james_w> nice
<james_w> there are probably a couple more places in that file where that approach could be used
<jelmer> jam: Please do :-)
<jelmer> jam, vila: Also, if you can have a look at my InterBranch patch that would be really helpful for bzr-git..
 * jelmer is still wondering what the magic trick is to get a patch reviewed
<jam> jelmer: sent
<jelmer> jam: Thanks :-)
<jam> vila: I'm sure I'm not
<jam> I changed some code in fetch
<jam> which Robert changed with the network streaming stuff
<arshad> hi channel
<jam> I added a progress bar
<arshad> whats bazaar all about  ??
<vila> jam: yeah, so at least you know *one* side of the conflict as opposed to None :-)
<jam> jelmer: I think it is beer. And submitting patches that directly effect other people. The problem with InterBranch is that I haven't worked out whether the added complexity is worth the benefit for non-core code. I'll try to give it a look
<jam> arshad: freedom :)
<arshad> <jam>ok . . . . . .   but freedom for what ??
<james_w> jelmer: I assume that is the cause of "AttributeError: 'module' object has no attribute 'InterBranch'" with a newer bzr-git?
<jam> arshad: That was a trivial response. To give you a better one, how much do you *know* so I don't repeat myself
<jam> bzr is a version control system
<jam> do you need to know the diff from others
<jam> what a vcs *is*?
<jam> etc
<arshad> hope u wont fire me for that
<jam> arshad: no firing, just trying to understand what info you really want
<jam> vila: yeah, robert refactored a lot of stuff that bbc had hacked to get working :(
<jam> So I need to actually understand the new stream code
<jam> before we can really adapt it
<jam> vila: like understanding how to get chk records as part of the new stream
<vila> jam: The good thing is that that should address at least *one* failure :-)
<vila> jam: ouch, not an easy bird then :-/
 * vila throws some stones at jam to help him :)
<arshad> can VCS b made as a career
<arshad> ??
<jelmer> james_w: yep
<jelmer> .
<Peng_> Doesn't CPython optimize += on strings with only one reference, making it faster than ''.join()ing a list?
<james_w> jelmer: am I better merging that, or going back in time a little bit on bzr-git?
<vila> arshad: vcs == version control system, try reading http://bazaar-vcs.org a bit
<vila> arshad: you should get many answers there
<arshad> where??
<jam> vila: so one problem I have with your "knownFailure" change to "autopack_rpc_is_used" test. Is that you don't test anything, in case we accidentaly *fix* that.
<jelmer> jam: It's the only way to make "bzr pull" work on remote git repositories since we can't walk the graph of remote git repositories to determine the revno
<jelmer> james_w, Better off merging InterBranch, without it you can't pull from remote git branches
<vila> jam: that was quite the only possible route at that time as we were testing that the hpss autopack call was in hpss_calls
<vila> jam: and that required some InterRepo accepting chks which wasn't the right way
<jam> vila: not really
<jam> you could have put the knownFailure later
<jam> around the actual "x in y" test
<jam> anyway, it is fine.
<jam> For right now, I'm pulling out your change, because it conflicts with the new streaming RPCs
<jam> and I don't know how BBC will interact with that yet
<james_w> jelmer: will InterBranch allow things like "missing" against the remote branch? I guess they may have to become a fetch to local then missing operation?
<vila> jam: pull out ! pull out ! sounds perfectly right now that the test has changed
<jam> vila: dammit.... we have a serious problem
<jam> the generic fetching code doesn't really seem to support converting on-the fly
<jam> at least not easily
<jam> since it expects to be getting a stream
<jam> that it can just insert on the other side
<jam> and with chk
<jam> it has to convert the repos
<jam> well, convert the inventories.
<jelmer> james_w: It mainly allows for custom implementations of branch-to-branch operations, such as pull
<jelmer> james_w: right now bzr-git only overriden update_revisions(), which is the main worker used by pull
<jelmer> james_w, but in the end, we would indeed end up with a search_missing_revisions() and that would most likely indeed to a fetch :-/
<jelmer> james_w, s/to a/do a/
<james_w> yeah, that's a pain
<vila> jam: ouch :-/
<james_w> jelmer: would it be at all possible to extend git's server to help with this?
<james_w> not in terms of would they do it, but in terms of whether git could provide the sort of information that is needed?
<jelmer> james_w, it would, though I'm not sure how likely such changes would be accepted upstream
<james_w> I guess having it speak the bzr remote protocol would work :-)
<jelmer> james_w: :-)
<jelmer> james_w, Actually, that has crossed my mind.. the git server John has been working on can provide a "bzr" capability, just like "bzr svn-serve" does
<james_w> heh
<james_w> jelmer: also, would "bzr format-git-patch" make sense?
<james_w> and something to then pull then back in? maybe "bzr patch" is enough
<jelmer> james_w, you mean "bzr send --format=git" ? >-) Yes, I think so
<james_w> yeah, that too
<james_w> :-)
<Jc2k> jelmer: i thought about custom extensions to git-serve too :)
<james_w> making "format-patch" and alias of "send" might be a good idea
<jam> vila: so StreamSink *is* meant to handle some of that, but it only really is defined as handling the case where 1 fulltext == 1 inventory
<jam> which is no longer true for bbc
<jam> so I have to figure out how to work around it
<jam> the stream code seems to think that just "get_bytes_as('fulltext')" would be enough
<jam> and, of course, lifeless and spiv are both sleeping right now
<jam> I may have to punt... :(
<jam> until I can talk to them and see what they were thinking of as a solution for this
<Ng> is bzr 1.12's "st" supposed to explode on me?
<jelmer> Ng, you may want to update your copy of bzr-loom
<vila> Ng: let me guess: it doesn't like 'verbose' and you have installed bzr-loom ? Grr, jelmer is too fast :)
<Ng> correct :)
<vila> jam: punting sounds the most reasonable thing to do, is StreamSink._extract_and_insert_inventories where the problematic assumption is being made ?
<jam> vila: that an inventory is contained within a string
<jelmer> james_w, yeah, I agree
<jam> the idea is that you can do "read_inventory_from_string()" using the source serializer
<jam> the problem is that for chk repos
<jam> you can't just have the little bits you need
<jam> you have to have all the chk pages
<jam> for that inventory
<jam> in order to cast up to an Inventory object
<jam> that can then be serialized back down into whatever format the target requires
<jam> vila: does that make sense?
<vila> jam: can't we just transmit the delta and build from that ? Argh, yes, not all formats can build from a delta :-/
<jam> vila: so the issue is that "CHKRepo.get_stream()" would want to at best just send the individual pages that changde
<jam> changed
<jam> but the target repo doesn't have *any* pages
<jam> so it wouldn't know how to interpret them
<jam> so CHKRepo.get_stream() sort of needs to do the conversion on *its* end
<vila> jam: so either the target is chk and we send changed pages (>-/) or better the delta or the target is not and... pfff
<jam> The BBC logic just did "for inv in self.source_repo.iter_inventories(revs)"
<jam> vila: right, so I can easily figure out what to do when source_format == target_format
<jam> However, when source_supports_chks != target.supports_chks
<jam> I'm a bit stymied
<vila> I can understand that :-/
<jam> The code is written such that the *target* does the conversions
<jam> But a Pack-0.92 repository isn't going to know what to do with a chk page
<jam> So I think we need a get_stream() that can tell the target what format it needs
<jam> sorry, tell the *source*
<jam> hmm.. maybe I can cheat and try to do that
<jam> I just worry that I'm breaking the *spirit* of lifeless & spiv's work
<vila> jam: better talk with them then
<jam> though I know they wanted to make sure that the streaming code worked with bbc
<jam> as part of the "if it doesn't, then we haven't done the right thing"
<vila> there is already some XXX in remote.py
<vila> so may be we should just don't try to merge yet (and will regret it later :-)
<jam> vila: well, the other 3 conflicts were easy to resolve... :)
<jam> and if we don't merge revno 4032, when we merge 4033 we're going to have a real pain (it is the whitespace cleanup patch)
<vila> jam: hmmm, can you resolve the last one with a hammer maybe ?
<jam> it is easy enough to do if you merge just before
<jam> because then you know you can revert everything
<jam> and do your own whitespace cleanup
<jam> vila: yeah, I can always put big XXX and say that robert and andrew need to fix this
<jam> :)
<vila> jam: if we end up with test_autopack_or_streaming_rpc_is_used_when_using_hpss failing, well that will make 5 failures instead of 4, not a big deal
<jam> vila :)
<vila> jam: sounds like a good idea, at least they get an almost working bbc
<vila> jam: and they may already know that can't work right now
<vila> jam: and they may already know that bbc can't work right now
<jam> vila: I'll also note that "supports_chk" isn't a sufficient test. As if you have different CHK repos with a different paging structure (different hash, etc)
<jam> then the target repo still doesn't understand the source repository
<jam> pages
<jam> (layered on *top* of the pages is a possible delta format, which could differ but still be understood by both formats)
<jam> like gc+chk255 should be able to understand the wire-stream of a chk255 repo
<jam> but chk16 != chk255
<jam> me == :(
<vila> jam: yup, and a delta format may be easier to serialize/deserialize for *future* formats too
<jam> vila: I think we are talking different things
<jam> logical inventory diff
<jam> versus byte-wise diff of chk page
<jam> I think defining a "get_stream()" that can return serialized bytes of a logical inventory diff may be the way to go
<jam> though possibly slower than a pure chk => chk could be
<vila> jam: sorry, I went too fast, but you were already saying the byte-wise diff of chk pages was having problems, so going with a logical inv dif... yes, what you said :)
<vila> jam: I'm not sure you can assume that two repos have the needed pages without checking first (and it's true today, I'll be more comfortable if that wasn't required)
<vila> jam: I'm not sure you can assume that two repos have the needed pages without checking first (and *if* it's true today, I'll be more comfortable if that wasn't required)
<jam> of course, I don't want to have to write a logical diff format + serialized form just to get bbc working
<jam> vila: chk pages are the same problem we have today, so I'm not specifically worried
<jam> we assume that if you have the inventory at revision X, then you don't need to transmit it
<jam> in the same way, you don't need to transmit the chk pages for X
<jam> the issue is that if both sides have different chk serializers
<jam> the pages for Y don't mean anything to the other side
<vila> I think that defining new serialized formats shouldn't be harder than defining a % format
<vila> It *is* today but it shouldn't
<jam> vila: anytime you work on bytes-on-the-wire or bytes-on-disk it is hard
<jam> because you need a whole lot of direct tests
<vila> jam: exactly
<jam> to make sure that bzr-X.Y can talk to bzr-X.Z
<jam> I don't see that going away
<vila> I worked in that direction in the transportstats plugin (not the interoperability part, but the easy defined formats)
<jam> argh....
<vila> jam: but the gap to go there is still rather large :-/
<jam> I thought I had a decent workaround
<jam> by changing the source to do the reserialization and hand it back
<jam> but it seems the Sink always uses the source-serializer to decode the fulltext bytes
<jam> (which sort of makes sense, but means I don't have a way to do this yet)
 * vila dinner
<jam> hmm... it seems that chk_serializer's inherit from the XML serializers (perhaps wrongly, but they do)
<jam> which means an ugly-ugly hack is to actually write out a xml5 format inventory to the record stream
<vila> jam: will that make it less ugly to use composition instead of inheritance (ignoring it doing that) so that you can provide the right xml serializer ?
<jam> vila: so the ugly hack is that we will read in the CHK inventory, bring it up all the way to a full Inventory object in memory
<jam> and then convert it to some-semi-random not really used XML representation
<jam> and write those bytes out on the wire
<jam> I think I can make it work
<jam> but it certainly isn't what I would consider the "correct" method
<jam> One other possibility, is that get_stream() from a CHK repo
<vila> jam: At least you'll have some meat to talk with lifeless and spiv :)
<jam> could return *all* the pages
<jam> which would mean the target would have enough to work with to do it on its end
<jam> but it would have to transmit and buffer all of those pages somewhere
<jam> until it got to the inv records
<jam> and new what to do with them.
<vila> jam: returning all the pages sounds wrong especially considering that you'll certainly ends up transmitting some of them multiple times
<jam> vila: you can just transmit the set()
<jam> for revisions 10..30 send all referenced chk pages
<jelmer> hmm
<vila> jam: sounds better
<jam> jelmer: ?
<jelmer> jam, Trying to figure out what I'm doing wrong benchmarking OOo with bbc and bzr.dev
<jam> vila: yeah, I'm still going to let robert and andrew worry about how to semi-optimize transfering between formats
<jelmer> I'm seeing a 28x performance gain with bbc
<jelmer> which seems a little excessive ;-)
<jam> jelmer: not really
<jam> it is an O(N^2) versus O(N) sort of change
<jam> I don't know *what* you are benchmarking
<jelmer> jam, import from OOo-svn into bzr
<jam> jelmer: oh sorry, it is a log(N) versus N change
<jam> jelmer: so still possible
<jam> with bzr.dev
<jelmer> bzr.dev gives one revision every 6 or 7 seconds, bbc close to 4 per second
<jam> we have to generate an inventory which contains a line for *every* file
<jam> with bbc
<jam> we only have to update the few pages based on the actual change
<jam> O(tree) operation versus O(changes)
<jam> jelmer: also the bbc pages aren't delta compressed (yet), which means they are also faster to read, etc.
<jam> so *faster* but not *smaller* to store
<jam> jelmer: so my initial feeling is that you aren't doing anything wrong
<jam> as that is really what bbc is *about(*
<jam> I would actually expect the difference to get *more* pronounced as time goes on
<jam> as the larger OOo gets, the size(changes) stays relatively constant for most projects
<jelmer> right
<jam> jelmer: well, at least if you have an optimized Inventory._make_delta() for bzr-svn
<jelmer> jam, I do
<jelmer> jam: Still surprised it matters this much though
<jelmer> jam, Anyhow, I'm not complaining ;-)
<jelmer> jam, bbc rocks \o/
<jam> jelmer: if you see igc around, I'm sure he'd be interested to hear it
<jam> It seems that OOo is looking again at possibly switching to a DVCS
<jelmer> jam, This was actually why I was looking into it
<jelmer> jam: They were seeing slow imports with bzr.dev
<jam> jelmer: yeah, when we imported in the past, it was... 2 weeks to a month? something like that
<jam> Also, I wouldn't be surprised if the generic converter is actually *slower* in bzr.dev than it used to be
<jam> as it was updated in preparation for bb
<jam> bbc
<jam> And I believe Ian was looking at fast-import code in the last couple of days
<jam> as it had also done some internal hackery for performance that may not be as relevant now
<jelmer> based on what I'm seeing now with bzr-svn (4 revs / second) I should be able to import OOo in 20 hours
<jam> jelmer: that's a good number
<jam> jelmer: is that streaming from their repository? Or do you have an svn dump locally?
<jelmer> I have a local dump
<jelmer> That's mainly to avoid hammering their server too much though
<jelmer> as the process is mainly CPU-bound
<jelmer> jam: bzr-svn basically does one "svn log -v" followed by "svn up -rX-1:X" for each revision
<jelmer> so while the extra roundtrip-time should have some impact, it shouldn't be significant
<jam> jelmer: well, bandwidth and latency
<jam> and as you say
<jam> if you try multiple times
<jam> you only have to have dumped once :)
<jam> at 4 revs/sec
<jam> latency becomes an issue
<jam> 250ms
<jam> a latency of 100ms and 2 round trips would cut your conversion speed in half
<jam> certainly didn't matter for bzr.dev at 7s/rev
<jelmer> jam: Latency to launchpad is 10ms here, not sure how much it is to the ooo svn server
<jam> vila: ok, I've hacked it enough that it seems to be working
<jam> the RPC tests still fail
<jam> though I think we could fix that by allowing chks to be included in the InterPackToRemotePack tests
 * ToyKeeper finds it a little odd that two opposite-sounding options are required to produce the desired output...  bzr log --verbose --short
<ronny> anyone knows when lifeless will appear?
<mthaddon> anyone know what's up with http://benchmark.bazaar-vcs.org/usertest/usertest.log ?
<jam> ronny: he usually shows up in about 2 hours
<jam> though he almost never actually completely logs off irc
<jam> so I'm not sure if something changed
<jam> mthaddon: what is the problem?
<mthaddon> jam: it seems to be debug output rather than the expected output
<ronny> i hacked up a inital nosetest plugin for subunit
<mthaddon> jam: either that or the format has changed radically (it's used to generating performance graphs, so I'd need to alter my parser if the format's changed)
<jam> mthaddon: poolie or igc would be the ones to ask
<jam> If you want, I'll try to mention it when I talk to them later
<jam> mthaddon: best guess is that someone forgot a flag when the updated the benchmarks being run
<mthaddon> cool, thx - I'll send them an email as well
 * jelmer makes a note to buy John beer at the next bzr sprint
<jelmer> jam: Thanks for the reviews, it's much appreciated!
<glade88> hello. is there a way to make bzr use a network proxy setting?
<mwhudson> does nicolas allen irc?
<mwhudson> nicholas, sorry
<lifeless_> mwhudson: I think so
<poolie> jam, hi
<Peng_> Do http connections time out...ever?
<jam> morning poolie
<poolie> Peng_: probably, but i would say not as fast as they should
<poolie> they should timeout and retry
<poolie> since they're all idempotent
<poolie> jam, want to talk?
<jam> hey poolie, chatting with robert right now
<poolie> ok
<poolie> i'll be here all day, ping me if you want a 1:1
<james_w> hi poolie
<poolie> hello
<mwhudson> Peng_: we occasionally had http connections hang for ridiculous amounts of time in the branch puller
<poolie> jam, btw not sure if you saw but it looks like rockstar will go to the mysql conf
<Peng_> mwhudson: How long?
<mwhudson> Peng_: days, iirc
<Peng_> Eh. I'm at 12.5 hours so far. That sounds bad.
<Peng_> Oh well, I have nothing better to do. :)
<mwhudson> well
<mwhudson> killing and starting again will probably work...
<Peng_> Sure, but how would that be fun?
<mwhudson> i'm not going to try to guess what you find fun :)
 * mwhudson watches pydoctor trunk process bzrlib
<mwhudson> gawd docutils is SO SLOW
<lifeless> jam: let me know if you want to continue the compression chat [just skype me]
<ronny> lifeless: got an initial nose plugin for subunit wired up, currently it imports the reporter
<ronny> lifeless: how about a convention for giving stream output/log lines after the trace?
<mwhudson> beuno: hi
<lifeless> ronny: How would that map into pyunit [let alone junit etc]
<beuno> mwhudson, hiya
<mwhudson> beuno: so the masses are complaining about https://bugs.edge.launchpad.net/loggerhead/+bug/253950
<ubottu> Ubuntu bug 253950 in loggerhead "Changes view slow to render with large initial import" [High,Triaged]
<ronny> lifeless: ignore unless known otherwhise
<lifeless> ronny: no, I mean *where* would that be exposed
<ronny> nosetest tracks things like stdin/stderr (and its nice for additional output)
<lifeless> ronny: you have a RemoteTestCase which calls result.addFailure(self, RemoteError(self.blah))
<mwhudson> beuno: a simple fix is to truncate the list of added/modified/... files when the list gets more than a certain length
<lifeless> ronny: ah
<lifeless> so; divide and conquer
<beuno> mwhudson, sure. Although, to be fair, doing it with ajax should be pretty quick as well.
<mwhudson> beuno: yeah, i guess
<ronny> currently my initial wire up doesnt handle that tho
<mwhudson> maybe i should just try that quickly
<lifeless> there are two use cases here - there is 'get nose discovered tests run with output to subunit', and there is 'accept a subunit stream for display with the nose infrastructure'
<beuno> mwhudson, and we could potentially avoid getting that information at all unless needed, gaining some performance?
<mwhudson> doing it nicely will require some infrastructure hacking i guess
<ronny> lifeless: i see 2 possible solutions - mangle it into the trace output, or have a new event
<lifeless> In terms of the former, just putting it in the comment area in the result is fine [though if people should be seeing it real time (e.g. a debugger prompt), put it in the stream in realtime.
<mwhudson> and some nice gifs
<beuno> mwhudson, we have most of that in lazr-js  ;)
<mwhudson> i should look at lazr-js i guess!
<lifeless> for the latter, I don't think you need to accept any random stream into nose so much as nose generated ones, so as long as you use the same approach for in as for out it should work nicely
<lifeless> ronny: yes, I see the same two things; I'm cautious about new events though
<mwhudson> argh
<mwhudson> when will bzr info lp:lazr-js not say "format: unnamed" ?
<lifeless> ronny: particularly things that are tricky to map into python space - like jml's testtools, I want to see what multiple projects are doing before committing to a design
<lifeless> mwhudson:
<lifeless> Repository branch (format: pack-0.92)
<lifeless> I bet its info not doing the right thing with hpss branches; perhaps filing a bug would help.
<ronny> lifeless: got a link to jml's testtools?
<lifeless> https://edge.launchpad.net/testtools
<mwhudson> lifeless: would seem to be https://bugs.edge.launchpad.net/bzr/+bug/196080
<ubottu> Ubuntu bug 196080 in bzr "`bzr info -v bzr://host/branch` hides actual branch/repo format" [Medium,Confirmed]
<lifeless> mwhudson: k
<lifeless> thanks
 * beuno -> home
<beuno> bbiab
<mwhudson> beuno: so how do i actually use lazr-js, is there documentation or a quickstart somewhere?
<phinze> is there any way to get bzr log to show me only the commits made on this task branch?
<ronny> afair bzr log -rsubmit:..
<ronny> see bzr help revisionspec
<igc> jam: I've been struggling getting a good conversion of mysql and emacs to --development5
<igc> emacs fell out with a serializer bug after 10 hours
<igc> s/out/over/
<igc> mysql completed but then didn't work ...
<igc> and I'm yet to track down why cos ...
<igc> bzr check isn't fast
<igc> jam: I'm wondering if you've had more luck converting these
<jam> igc: I have, but I haven't done a full conversion in a while
<igc> if so, could I ask for you to tar.gz the converted branches and put them on orcadas?
<igc> that's the missing piece for getting meaningful benchmark results
<jml> abentley: thanks for the review
<abentley> jml: np
<thrope> hi - numpy/scipy developers are discussing dvcs ... I pointed out bzr-svn (they were talking about the shortcomings of git-svn)
<thrope> http://projects.scipy.org/pipermail/scipy-dev/2009-February/011205.html
<thrope> someone asked "can you point us to a public svn repo where non-trivial branching is happening with bzr?" was wondering if anyone (perhaps jelmer ) could point me to this
<jelmer> thrope, hi
<jelmer> thrope, non-trivial branching?
<fullermd> I thought the point of a DVCS was that ALL branching is trivial   ;>
<thrope> not sure - thats what the person asked...
<thrope> I dont have a lot of experience - but bzrsvn worked well for me and they were complaining about git-svn
<thrope> I guess can anyone point to an open source project using bzr-svn 'officially' with a couple of different bzr branches in svn
<jelmer> thrope, well, there are some projects that contain roundtripped revisions using bzr-svn
<jelmer> thrope: it seems kindof pointless to have official bzr-svn branches though, since the official repo would always be svn, even if some developers are accessing svn using bzr
<thrope> right
<thrope> just not sure how to respond to the guys question then
<jelmer> thrope, if you're looking for example branches in bzr created from svn branches using bzr-svn, see http://bzr-mirror.gnome.org/
<thrope> ok thanks
<jelmer> thrope: alternatively, I'm interested to hear about svn repositories that don't work in bzr-svn
 * igc out for several hours
<igc> back later hopefully
<lifeless> spiv: so, what shall we do today?
<fullermd> The same thing we do every night; try and take over the world.
<spiv> lifeless: so I'm currently wikifying my measurements from yesterday
<spiv> lifeless: after that I'm happy to head over to Epping
<spiv> lifeless: if that suits you?
<lifeless> hornsby would be better for us today; if epping is better for you though, that is fine too
<spiv> lifeless: that's ok
<lifeless> ok, well I'll pick up food and grab a train
<lifeless> late morning is ok for you ?
<spiv> Sure.
#bzr 2009-02-24
<wgrant> If I have a remote branch with some ghosts, how do I fix them? If I fetch-ghosts on a local copy and then push, it does nothing.
<lifeless> jml: what bug number is your stacked performance # ?
<lifeless> wgrant: you need to fetch-ghosts directly on the remote branch
<lifeless> I;m not sure if the cli supports that or if you'll need to [trivially] patch the command first
<jml> lifeless: bug 331823.
<ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,New] https://launchpad.net/bugs/331823
<garyvdm> wgrant: Hmmm - fetch-ghosts does not have a -d option. It should have...
<wgrant> lifeless: Thanks.
<lifeless> jml: its almost certainly the interface fixes for hooks
<wgrant> garyvdm: What would -d do?
<jml> lifeless: ok.
<garyvdm> wgrant: normaly a -d option lets you specify the branch/directory to perform the action on
<wgrant> garyvdm: Ah, right.
<garyvdm> a> bzr push b == bzr pull -b a
<garyvdm> Err
<garyvdm> a> bzr push b == bzr pull -d b a
<lifeless> my next patch drops push-trivial-branch to 44 hpss calls
<bob2> spiffy
<garyvdm> What does hpss stand for?
<mwhudson> high performance smart server
<jml> is loom included in the OS X dmg file?
<thumper> lifeless: 44 seems high, what was it? and what is a trivial branch for this example?
<lifeless> thumper: 107
<lifeless> thumper: a trivial branch is a trivial branch
<lifeless> current bzr.dev is 64
<thumper> lifeless: like a single revision?
<lifeless> yah
<thumper> lifeless: to a stacked branch?
<lifeless> no
<lifeless> current bzr.dev stacked is 88
<lifeless> for the equivalent test case
<lifeless> my branch drops that to 68
<rockstar> beuno, http://www.ericsink.com/entries/git_immutability.html
<Peng_> The streaming push stuff should help "push a couple new revisions to an existing branch", right?
<lifeless> Peng_: modulo bug 331823
<ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,New] https://launchpad.net/bugs/331823
<lifeless> rockstar: nice
<Peng_> Well, I don't use stacking. For my usual "bzr push-and-update" case, I think it's helped nicely.
<rockstar> lifeless, I thought so.  This is something that's always bothered me about a DVCS in general.
<Peng_> Seems to be about 7-10 seconds now, when it used to be maybe twice that.
<rockstar> I still don't really like `bzr uncommit` either.
<lifeless> Peng_: cool
<spiv> Peng_: sweet
<fullermd> "Some folks say that Git's killer feature is its index.  That's like saying that C's killer feature is the ability to cast an int to a pointer."
<spiv> Peng_: http://bazaar-vcs.org/SmartPushAnalysis1.13 has some early numbers, FWIW.  1.13 final is likely to be significantly better than those numbers.
<spiv> Peng_: glad to hear the improvements exist for real users :)
<Peng_> spiv: Oh, thanks for the link.
<Peng_> Thank you for your work! :)
<RAOF> Faster push?  Sweeeeet!
<mlh> fullermd: ... but that's true :-)
<spm> spiv: any truth to the rumour that v1.13 will be release on the 2009-04-01? ;-)
<spiv> spm: you'd have to ask the release manager ;)
<rockstar> Hm.  `bzr help commands` seems to see the new plugin I'm writing, but actually invoking tho command throws a NotImplementedError
<rockstar> Any idea why that might be happening?
<spiv> rockstar: what's the traceback?
<spiv> rockstar: I bet something in your command is triggering a raise of NotImplementedError ;)
<rockstar> spiv, the only thing in the command is a docstring and a pass
<rockstar> spiv, http://pastebin.ubuntu.com/122179/
<spiv> rockstar: so you don't implement a run method on your command object?
 * rockstar facepalms
<rockstar> Was doing that in the __init__  Thanks for the extra set of eyes there.
<jml> abentley: ping
<abentley> jml: pong
<jml> abentley: I'm looking at the lp-open patch...
<jml> abentley: I would like to be very careful that Branch.open doesn't do network operations in the tests.
<jml> abentley: sorry, I'm trying to think about how to formulate an actual _question_
<abentley> jml: Seems ironic, considering what you're testing...
<jml> abentley: yeah, I know. but I'd like the tests to not suck :)
<abentley> jml: The approach of using Branch.base was a suggestion, not a requirement.  If you want to land the current patch first, that's fine with me.
<jml> abentley: ok. I'll leave that bit as-is.
<jml>         self.assertEqual(
<jml>             ['Opening https://code.edge.launchpad.net/~foo/bar/baz in web '
<jml>              'browser'],
<jml>             self.run_open('bzr+ssh://bazaar.launchpad.dev/~foo/bar/baz'))
<jml> abentley: ^^ that's the thing I'm not sure how to test.
<abentley> jml: I guess you could register your own https handler.  Seems a bit overkill
<jml> abentley: yeah.
<abentley> Sorry, I meant bzr+ssh handler
<abentley> jml: So this looks like a blackbox test.  Is it?
<jml> yeah.
<abentley> Does it need to be?
<jml> umm.
<jml> no. It was the easiest way to do it when the command was smaller.
<jml> there are also unit tests for the feature.
<abentley> It sounds like this test is redundant.  Is that right?
<jml> not quite
<jml> I tell you what the Right Thing is
<jml> _possible_locations and _get_web_url ought to be unit tested
<jml> and then that test would reduce to 'attempt to look up whatever is passed on the command line'
<abentley> Sounds good.
<jml> anyway, I've filed https://bugs.edge.launchpad.net/bzr/+bug/333681 and replied to your review
<ubottu> Ubuntu bug 333681 in bzr "Make lp-open also check Branch.base" [Low,Triaged]
<jml> abentley: do I need to send another bundle or a progress diff or something?
<abentley> jml: Yes, you should submit a new merge directive, not an incremental diff.
<jml> thanks.
<jml> why would 'info' not print anything.
<lifeless> if it crashed?
<jml> lifeless: return code 0, say the logs.
<jml> yeah, looks like non-existent branch.
<mwhudson> bzr info in a bzrdir with no branch or repo says nothing silently
<mwhudson> i meant to file a bug about that...
<mwhudson> for example:
<mwhudson> mwh@grond:trunk$ bzr info sftp://bazaar.launchpad.net/~mwhudson/bzr
<mwhudson> mwh@grond:trunk$
<lifeless> mwhudson: please do
<jml> mwhudson: yeah, that's what I'm seeing.
<jml> I'll do it
<mwhudson> jml: thanks
<jml> mwhudson, lifeless: https://bugs.edge.launchpad.net/bzr/+bug/333684
<ubottu> Ubuntu bug 333684 in bzr "bzr info fails silently when pointed at a bzrdir with no branch, repo or checkout" [Undecided,New]
<jml> incidentally, info -v does *way* too much.
<jml> spiv: in this comment -- https://bugs.edge.launchpad.net/bzr/+bug/255292/comments/22 -- you say "capture the SFTP conversation"
<ubottu> Ubuntu bug 255292 in launchpad-bazaar "MemoryError/OverflowError in _read_info_file during branch unlock when pushing over SFTP" [Undecided,Incomplete]
<jml> spiv: presumably you want some sort of unencrypted version?, rather than the data sent on the wire?
<lifeless> gotta say the whole green flash when changing a bug title is ... odd
<jml> lifeless: file bugs about it on Launchpad if you want to.
<mwhudson> jml: fwiw, the copying of .bzr to backup.bzr on upgrading a launchpad branch seems to trigger that bug a pretty large fraction of the time
<lifeless> jml: oh, I do
<mwhudson> jml: if you want a test case
<jml> mwhudson: that's good to know.
<jml> mwhudson: right now, I just want to make some movement on it.
<spiv> jml: yes please
<spiv> jml: unless you want to provide me with tools to decrypt your SSH conversations ;)
<jml> spiv: do you want to provide me with tools to record a decrypted SFTP session?
<mwhudson> i imagine hacking paramiko is going to be required :/
<jml> mwhudson: gosh, I haven't hacked paramiko to get debugging information in _months_
<spiv> jml: I *want* to
<spiv> jml: that unfortunately doesn't mean that I *will*...
<spiv> Basically, what mwhudson said sounds like the most likely route.
<spiv> Someone should write a pipedump util, like tcpdump for interprocess pipes ;)
<spiv> jml: btw, I've just sent a probable fix for your bug to PQM
<jml> spiv: the hour-long push bug?
<jml> spiv: thanks.
<spiv> jml: yeah
<igc> igc
<igc> is back
<jml> welcome back!
<vila> hi all
<igc> hi vila
<vila> hey Ian !
<igc> vila: can we mark http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2prhqzm09.fsf%40free.fr%3E as merged now?
<vila> igc: man, why are you *all* looking above my shoulder ? :-)
<vila> I think it's merged, I'm trying to understand why it isn't :-)
<fullermd> Would it help if I looked at your knee instead?
<vila> igc: I think what happened is that poolie merged it more or less manually, I'm checking that
<vila> fullermd: leave my knees alone too, please !
<vila> fullermd: I mean, I'm an honest person, how dare you young man looking at my knees
<poolie> hello vila
<igc> vila: I assume you mean "over my shoulder" ..
<fullermd> YOU claim you're honest.  I think you have shifty knees.
<igc> vila: I'm just cleaning out the merge Q - you're patch just happened to (still) be in it
<vila> igc: damn, over my shoulder, yes. Remember to tell you the favorite expression of my gf grand-mother  one day :)
<vila> igc: damn, over my shoulder, yes. Remember me to tell you the favorite expression of my gf grand-mother  one day :)
<poolie> vila, i'm pretty sure i did merge that, maybe
<poolie> probably manually because all bb has is a patch not a bundle
<vila> poolie: we are all pretty sure :)
 * fullermd ponders.
<fullermd> As more people are pretty sure, does that make the total likelihood higher or lower?
<fullermd> I mean, a bunch of numbers [certainty] less than 1, multiplied together, get smaller and smaller...
<vila> poolie, igc: right, the only missing bit is a depreceation test, I'll send it to PQM and BB should catch up
<vila> poolie, igc: err, not even that much in fact, only some review feedback is missing regarding adding some try/finally around some f.write() calls
<poolie> yes i was merging it for 1.12 so i didn't actually do the tweaks
<vila> and the deprecation mention in NEWS
<poolie> would be good to add them if you want to tidy up though
<vila> poolie: doidn it right now
<vila> poolie: doing it right now
<igc> thanks vila
 * vila slaps his knee: *Don't* run selftest in a bound branch, you know that damn it
<poolie> vila, what happens?
<vila> poolie: I get prompted for my id_dsa password since the test suite is isolated from my ssh agent
<vila> this is due to 'bzr info' being used by some tests as a 'do something but not that much' command
<vila> it's a known problem related to the branch nick
<lifeless> vila: sounds like they are not properly isolated; which tests
<poolie> it may be that we're trying to open the branch to print the revision of the source tere
<poolie> tree*
<vila> err wait, not bzr info, bzr version, sorry for the confusion
<vila> lifeless: they *are* isolated ans SSH_AUTH_SOCK is cleared, that's the problem :)
<lifeless> vila: if htey are isolated the fact that your branch is bound should be irrelevant
<vila> well, not really *the* problem, that's only one way to look at it, it's just that bzr version get some information from the branch for the bzr it is running, which IMHO, makes it an unfortunate choice for that kind of tests
 * vila searching for those tests again
<lifeless> vila: the gathering of data of the bzr running the tests should be outside the test isolation
<vila> lifeless: have a look at bzrlib.tests.blackbox.test_selftest.TestRunBzrSubprocess.test_run_bzr_subprocess and tell me if you will try your approach or choose another command :)
<lifeless> vila: it looks like an isolation issue to me
<lifeless> vila: I *bet* the cwd in one of tise is wrong
<lifeless> vila: and in fact it is, its running the bzr under test rather than [e.g.] an exported copy or some such
<vila> lifeless: I *agree*, but do you you really want to export bzr to run these tests ?
<vila> I meant, I agree that's an isolation issue, but the cure sounds a bit excessive
<lifeless> vila: perhaps --version shouldn't connect to bound branches in this way
<vila> lifeless: I think I remember tracking the problem until an access is made to the branch *nick*, so not really a --version directly related issue
<lifeless> yes, nick ill be the trigger
<vila> and still from memory there is a default value which says get the remote one when we access the nick, but changing that wasn't an option, so I back-tracked and finally thought that the right fix was to not *use* --version when possible because that was not worth the effort, and since this was introduced by yet another totally unrelated patch, I just went unbinding my branches when needed :-)
<vila> I mean, I mentioned the problem just after the patch was merged but... there was more important issues around that patch
<vila> In other news, I can confirm that our ftp support hasn't regress under python-2.6 and that all the failing ftp tests were indeed caused by medusa not being compatible
<poolie> http://benchmark.bazaar-vcs.org/rrd/runtime-common-suite-all.png
<mtaylor> lifeless: what was that thing ( I think it was you that showed me ) that lets me manage multiple deb packaging branches from a single thing?
<poolie> bzr-loom?
<poolie> nightall
<lifeless> mtaylor: autoppa
<mtaylor> lifeless: hell yes! thanks
<lifeless> spiv: it landed!
<lifeless> spiv: if you have a script to record the timings, it could run overnight :P
<lifeless> spiv: also, train ride home == VF decorator fully tested.
<willwill> hello, I got bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Enotify-osd-developers/notify-osd/main/.bzr/repository/packs/535754cb35e490c69b794a3cc65ffee4.pack: Expected a boundary ()yo,4lJD726(aEMWnFZV) line, got ''
<willwill> bzr 1.11 on Fedora 10 , bzr branch lp:notify-osd , I does not supply my lp login yet
<awilkins> Sounds like the "defective squid" error
<willwill> I directly connected to the internet, no proxy is used except for DNS proxy
<igc> night all
<beuno> good night igc
<beuno> it's great to have you back
<beuno> have I said that already?  :)
<james_w> night igc, the document looks great, I'll review fully later
<james_w> hey beuno
<beuno> hi james_w
<beuno> how's it going?
<james_w> good thanks, you?
<igc> thanks beuno
<igc> thanks james_w
<beuno> pretty good, trying to catch up on work, as always  :)
<bialix> hi, I'm looking for some (wise) advice about some almost standard options like --include(-i) and --exclude(-x)
<bialix> does --include implies that its argument (list of an items) should be used instead of default one?
<bialix> or it can be used as "add this items to default list"?
<bialix> fast-import-filter command e.g. used first variant: --include list used as default processing list
<bialix> any suggestions?
<vila> bialix: I don't remember having ever encountered the second variant, so go with your first variant
<bialix> my question related to my scmproj plugin. I have several ways to select components for processing. Yep, the first variant is most logical, and I hope "standard" way to doing this
<bialix> vila: thanks
<vila> I'm not sure you need a --include option as opposed as accepting arguments to define your list
<vila> then, --exclude applies to your arguments *or* the default value for your arguments
<bialix> I need --include because I'm using arguments for other purposes
<vila> s/as opposed as/as opposed to/
<bialix> -i/-x pair should work just fine
<bialix> but... I wonder, why bzr uses -i/-x form as short names for include/exclude, while hg uses -I/-X
<bialix> IIRC
<vila> tar defines: --files-from (files listed into a file) and --exclude-from (files listed into a file too), zip defines -x files and includes files specified as arguments
<rexbron> bialix: dumb luck :P
<vila> bialix: tar defines -X as an alias for --exclude-from, zip defines -x files...
<bialix> rexbron: I don't understand your joke
<vila> bialix: And this comes from a case sensitive OS :-)
<bialix> vila: I like zip. -x ftw
<bialix> no need to hold shift in the end
<bialix> ok, bzr is simpler
<awilkins> reduced wear on the little-finger tendons
<bialix> :-)
<vila> bialix: diff defines -x pattern and -X file (containing file names) :-)
<bialix> OMG
<awilkins> How people use Emacs without getting swingeing tendonitis I'll never know
<vila> bialix: on unix, man(1) is your friend :-)
<bialix> but in my case it's `diif -x`
<awilkins> ctrl-alt-meta-ow-shit-my-hand-is-now-a-claw
<vila> awilkins: because they started young and are trained :)
<vila> Escape-Meta-Alternate-Control-Shift ftw :)
<awilkins> Ah, so you're saying Emacs is the editor for chinese acrobat children?
<bialix> and del?
<vila> awilkins: You didn't know *that* ?
<vila> bialix: real programmers don't need del :-)
<bialix> oh
<bialix> vila: Putty screwed up Backspace when I'm editing files in nfte on Linux, and have to use Del. This always make my crying
 * awilkins gets around this by using Windows via rdesktop on Linux
 * bialix has no such luxury
<awilkins> Especially since they installed some kind of security product that stops the Windows Vista RDP client working properly
<vila> bialix: besides del is achived with Ctrl-d under emacs :)
<awilkins> It's really good when you try to open a \\tsclient\ drive and the server BSODs
<bialix> ctrl-d deletes selected region for me in fte
<bialix> ok, I have answer I've looked for. thanks
<vila> bialix: nah, delete-region is C-w :)
<bialix> :-D
<bialix> I'd better to do not continue this finger battle
<vila> hehe, I think being comfortable with emacs *requires* to know at least ~50 key bindings, efficient ~100, hacker mode ~150, after that you'd better learn the commands themselves in case you forget the key bindings :)
<cody-somerville> How do I disable a plugin?
<vila> cd ~/.bazaar/plugins ; mkdir DISABLED; mv bogus-plugin DISABLED
<vila> cody-somerville: why do you need to disable it and what plugin is it ?
<cody-somerville> vila, gtk
<cody-somerville> vila, it prevents me from using bzr when X isn't available
<vila> urgh, is it dbus related *again* ?
<cody-somerville> yup
<vila> bialix: by the way, qbzr still blows out when I try to run selftest with python-2.6 (for which I don't have pyqt4)
<bialix> file a bug please
<vila> cody-somerville: I think this has been fixed at least a dozen of times already :-/
<bialix> vila: IIRC I dont try to fix selftest w/o PyQt4 yet
<vila> bialix: I did and I thought you fixed pretty quickly, only to discover later that the problem was still there
<bialix> vila: this is different problem
<bialix> I've fixed bug-url command, but you now talks about selftest
<bialix> why you run selftest for qbzr if you don;t have qt?
<vila> I run selftest and that includes qbzr because it's installed
<vila> the problem is that qbzr *aborts* at load time instead of raising some import error or something that disables it without aborting the current command
<bialix> please, file a bug about selftest
<bialix> I'll fix it shortly
<bialix> qbzr has a lot places where we import pyqt4 lazily, but some internal modules are not so lazy
<cody-somerville> hmm... I guess it wasn't bzr-gtk that was causing the dbus issue
 * cody-somerville tries removing bzr-dbus
<bialix> vila: btw my fix is not released yet
<vila> bialix: and you think I'm not running qbzr trunk ? :-)
<vila> bialix: no time to file bug, here is the fix: http://paste.ubuntu.com/122430/
<vila> bialix: :)
<bialix> vial: you said about "installed" version
<bialix> sorry, vila ^
<vila> bialix: tested against 2.5 with pyqt4 and 2.5 without :)
<vila> bialix: sorry about what ? Providing qbzr ? You should be proud instead :)
<bialix> sorry about typo in your nickname (I wrote vial)
<bialix> the main author is luks
<vila> bialix: I'm running lp:~qbzr-dev/qbzr/trunk@revno 623
<bialix> I'm just hacking it and maintain it
<bialix> vila: your fix is quick hack, I'll try to investigate the problem a bit deeper
<vila> bialix: sure
<vila> bialix: and thanks
<bialix> for what?
<bialix> if you don't have qt you can't use qbzr
<bialix> vila: bug #33389
<ubottu> Launchpad bug 33389 in samba "Winbind does not start on boot" [Medium,Fix released] https://launchpad.net/bugs/33389
<bialix> no Bug #333892
<ubottu> Launchpad bug 333892 in qbzr "selftest crashed if qbzr installed without pyqt4" [Undecided,New] https://launchpad.net/bugs/333892
<vila> bialix: thanks ! And blame launchpad for eating the spaces in the patch :-)
<bialix> bad lp, bad lp. go to the corner and think about it
<beuno> vila, it's the world crisis, we had to cut down on food for servers, so now they're after characters. Just wait until they find out how yummy a's are
 * bialix waves
<jelmer> whoa
 * jelmer is running bzr log on a 190k ooo bzr branch
<jelmer> bzr sure doesn't like that
<vila> jelmer: 190k revisions I presume ? Having fun ? :-)
<jelmer> vila: yeah
<jelmer> vila: brisbane-core rocks btw
<jelmer> vila, without it it would've taken me days to get this import
<jelmer> now it took me around 14 hours
<vila> jelmer: good to know, did you talk with igc about it ?
<jelmer> vila, no, not yet
<jelmer> it takes about 100 seconds before "bzr log" even gives any output..
<vila> jelmer: a bare 'bzr log' ? Without any options ? No hidden alias or something ?
<jelmer> vila: yep
<jelmer> running with lsprof now
<vila> jelmer: how many packs ?
<jelmer> vila, 30
<jelmer> the largest is 640 Mb
<NfNitLoop> ... whoah.
<jelmer> vila, the problem seems to be that it has to walk the graph all the way down to the bottom
<NfNitLoop> Do they have lots of binary files?  (Clip art, logos, etc?)
<jelmer> NfNitLoop, they mainly have a big history (270k revisions)
<jelmer> vila, and most revisions are on the mainline
<vila> jelmer: it shouldn't need to walk the whole graph for a bare 'bzr log'... at the least in common cases...
<jelmer> vila: it has to determine the revno's
<vila> jelmer: yeah, nevermind, I certainly know that and I mixing potential optimizations with actual code ;)
<jelmer> vila: :-)
<jelmer> vila: I'll certainly talk to Ian about it
<vila> Ian's revno cache plugin could certainly help there, until we implement some lazy revno tricks
<jelmer> vila: after the initial wait, it's pretty decent
<jelmer> I haven't tried his revno cache plugin yet, I'll give it a try
<vila> jelmer: yeah, once we get the graph loaded, log is really streamed
<vila> jelmer: me neither but I saw the code passing around :-)
<jelmer> vila: same story for "bzr viz" btw, it Just Works except that the initial ancestry browsing is a bit slooow
<vila> jam: http://paste.ubuntu.com/122440/ can fix two more failing tests but I'm affraid the approach can be rude for performances, thoughts ?
<vila> jelmer: bzr viz lacks the nifty +/- of qlog :-)
<jelmer> vila: To quote lifeless: Patches welcome (-:
<vila> jelmer: not that it will solve the problem you're referring to :-)
<vila> jelmer: hehe, I looked at it once,... and had to work on other things...
<vila> jam: come back  ! :)
<jelmer> vila: do you know why a push from development5-subtree into 1.9-rich-root would use a lot (1Gb) of memory?
<vila> jelmer: in bbc ?
<jelmer> vila: yeah
<vila> revno 3834 may be ?
<jelmer> vila: is that the cause or the solution ?:-)
<vila> jelmer: I think it's the cause, but if you don't use it already, let see if it's a solution :-)
<vila> jelmer: and it's the cause, we really like to know as it's part of a streamed push whose purpose is to avoid consuming too much memory :-)
<vila> jelmer: and *if*it's the cause, we really like to know as it's part of a streamed push whose purpose is to avoid consuming too much memory :-)
<jelmer> vila, is it right that that no longer gives any progress indication?
<vila> jelmer: right ? no. Known ? I think so. IIUC part of it was lost during the last big merge made by jam
<jelmer> thrope, fwiw this is wrong: http://projects.scipy.org/pipermail/scipy-dev/2009-February/011210.html
<jelmer> thrope, clones *are* the same, and the bzr metadata is not visible as long as you're running svn >= 1.5
<latexer> morning all.
<latexer> if bzr blame shows a revision number like "297.2.3" how do I find the "main" revision that introduced the change?
<awilkins> jelmer: You don't even need to run svn > 1.5  repository
<awilkins> jelmer: Works fine with a 1.4 format repo and 1.5 libraries
<awilkins> latexer: You'd need to know which branch that revision came from to find the "main" revision.... or you could just branch it at that revision, and hey presto, you have theat revision
<latexer> awilkins: can I at least find the "merge point" that introduced the change?
<awilkins> latexer: You have qbzr or bzr-gtk?
<latexer> awilkins: I think i've got bzr-gtk installed on this box.
<latexer> hrm... nope, I removed it cause it kept spitting warning about not working with my bzr version.
 * latexer re-installs.
<jelmer> hi enigma42
<jelmer> awilkins: Ah, I thought that was specific to the collabnet server
<awilkins> jelmer: I've been using file:/// to push branches into a 1.4 repo locally
<awilkins> The repo has to be compatible with our server and since I'm the server admin I can't be bothered to upgrade it to 1.5.x
<jelmer> awilkins, but does that use file proeprties or revision properties?
<awilkins> jelmer: I'll take a look at the repo
<awilkins> If you want a copy it's only a couple f meg
<latexer> awilkins: ok.... now what? I have a *lot* of revisions in this branch...
<latexer> awilkins: the log view doesn't show the revision numbers...
<awilkins> jelmer: bzr:file-ids? Seems to be using revprops
<jelmer> awilkins: So nothing shows up in "svn diff" wrt properties?
<awilkins> On a file across two revisions?
 * awilkins looks
<enigma42> jelmer: Hello
<enigma42> jelmer: Not ignoring you...I had just stepped away from my desk.
<jelmer> awilkins, any kind at all (but bzr-specific, of course)
<awilkins> Ok, I'm having trouble with the CLI (used to tortoise), and I have to cath my train now, I'll check later
<jam> vila: just seeing how things are going for you
<enigma42> jelmer: Oh...one thing comes to mind about 0.5...
<vila> jam: hi !
<enigma42> jelmer: Sometimes, a push or a pull takes *forever*
<LarstiQ> latexer: I was hoping to get close with 'bzr log -r 297.2.3 -n1 ', but it doesn't do exactly what I'm looking for
<enigma42> When I turn on transport logging, it looks like it is fetching revision information on rev at a time.
<enigma42> And for my project, that's several hundred revisions.
<enigma42> jelmer: Maybe this is due to having a mix of file properties and revision properties?
<jelmer> enigma42, 0.5.2 should be a lot faster
<enigma42> (The total push time is about 9 minutes for no changes.)
<enigma42> jelmer: OK. Let me grab it and try it out. I didn't realize there was a new release.
<enigma42> jelmer: I guess I haven't been checking it daily recently. ;-)
<vila> jam: I'm back on bbc fixing tests
<jam> vila: sounds good.
<jam> How is the current state for bbc?
<jam> (Just curious if merging bzr.dev made it a lot better or worse)
<vila> jam: Currently working on 'CHKInventory' object has no attribute 'apply_delta'
<vila> jam: merging made it a bit worse, but I've already fixed some, we are not *that* far the previous point
<jam> vila: k. Just to mention I don't think you want to implement 'apply_delta'
<jam> CHKInventory has "create_by_apply_delta" which is what we should be switching to
<jam> CHKInventory is meant to be immutable
<jam> and you have to create a new one to modify it
<vila> jam: I know: http://paste.ubuntu.com/122440/
<vila> now it's failing with   p_offset, p_length = self._container_writer.add_bytes_record(
<vila> AttributeError: 'NoneType' object has no attribute 'add_bytes_record'
<jam> vila: you need to be in "start_write_group()"
<jam> aka, repository.lock_write(), repository.start_write_group(), *create_by_apply_delta*, repository.commit_write_group(), repository.unlock()
<jam> CHKInventory.create_by_apply_delta() writes bytes down to disk
<jam> We don't have a memory-only implementation
<jam> In theory we could
<jam> but we pun the "finalized form" with "written to disk"
<jam> so that we know what pages need to be written, and what not
<vila> hmm, the test use branch_builder, does that imply a memory only impl. ?
<jam> vila: A plain Inventory can exist nowhere but in memory objects (InventoryFile, etc)
<jam> CHKInventory only exists when backed by a repository
<jam> whether that repo's bytes are stoored in a MemoryTransport or on actual disk
<jam> vila: does that make more sense?
<vila> yes
<jam> lifeless: when you get online... it looks like git uses 'libxdiff' not 'libxdelta', minor difference, but xdiff seems to be about "Rabin's Polynomial", so I would guess they cribbed the implementations from there.
<jam> ah, the thread seems to be here: http://kerneltrap.org/index.php?q=mailarchive/git/2006/4/21/203883/thread
<thrope> jelmer: ping
<jelmer> thrope, pong
<thrope> hello - I saw your point earlier - I am replying to that guy and jsut wanted to check something
<thrope> for me bzr branching etc. works fine without any bzr metadata in the svn repo
<chx> I read http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt and I like it. "Thus, if a partial commit is performed, I first shelve any remaining changes before going up-thread: " -- what does it mean by partial commit?
<jelmer> thrope, yes, that's correct - and will always create the same bzr repository
<thrope> so when is that needed? bzr stuff in the svn repo is only needed when you are pushing branches back?
<thrope> or you want to keep track of bzr side histroy of commits you are pushing to svn
<jelmer> thrope, yes, and that's necessary for the 1-to-1 mapping he mentions as not existing
<jelmer> thrope, the metadata is *optional* when pushing back into svn, but mandatory if you would like to push the exact same revision, including all bzr metadata
<thrope> right
<thrope> is this correct: for example, one can checkout from subversion using bzr-svn, branch using bazaar, modify, and push back to a different location in svn and it will be a svn branch
<jelmer> yes, that's correct
<thrope> ie svn copies
<thrope> with history preserve
<rawler> hey people..
<Peng_> Hi
<rawler> we're a bunch of people using bzr for various projects, with mostly very good experiences..
<Peng_> That sounds kind of secretive.
<rawler> now, however we've seen our first challenge.. we're starting up a new project, with a bunch of new people, who have never used version control, or even linux command-line before..
<Peng_> Sorry, Peng_ watches too much TV. Anyway..
<jelmer> thrope, yes
<rawler> Peng_: heh.. not really a secret at all.. just trying to not having to list the 10-15 project dirs controlled by BZR.. ;)
<rawler> so, my question is: is there any really good book or booklet (preferably in printed form), that goes through the very basics of bzr source control, without requiring too much previous knowledge on POSIX shells and such?
<rawler> I.E. if someone expects them to know in advance what a unified diff is, they will probably run for the hills.. ;)
<jelmer> vila, not much better :-(
<vila> jelmer: context ?
<jelmer> vila: push from bbc to 1.9-rr
<jelmer> vila, still uses about 1g of RAM and takes around 5 minutes to push 150 revisions
<vila> jelmer: both repos are local or ?
<jelmer> vila: yes, both local
<thrope> jelmer: would  you say this is accurate ? http://pastebin.com/m7e84dfb7
<jam> jelmer: what is the repository?
<jam> Also, last I checked bbc isn't always rich-root
<jam> (--dev5 is *not* IIRC)
<jam> and neither are the current hash forms
<jam> but regardless, pushing from bbc => 1.9* is going to have to do a conversion
<jelmer> jam, dev5-subtree
<jam> k
<jelmer> jam, the repository is here: http://people.samba.org/bzr/jelmer/ooo/trunk
<jelmer> http://people.samba.org/bzr/jelmer/ooo/ooo/trunk/
<jam> jelmer: so did it convert in ~20hrs ?
<jelmer> jam: it got up to 190k in 12 hours, after that I stopped it since I wanted to do actual work :-)
<jam> out of?
<jelmer> jam: out of a little less than 270k
<jelmer> thekorn, I'm not sure what you mean exactly by "it will be a svn branch"
<jelmer> s/thekorn/thrope/
<jelmer> thrope, also, it's possible to push without those bzr properties, it just means you don't get the 1-to-1 mapping
<thrope> jelmer: i mean the files will be svn copies - ie preserve history from the originals
<thrope> thanks for your help
<jelmer> thrope, other than that, seems right to me
<enigma42> jelmer: About push and pull slowness....
<enigma42> jelmer: 0.5.0 took about 9 minutes, 0.5.2 took about 2m15s.
<enigma42> jelmer: So, it's much faster.
<jelmer> enigma42: great :-) 0.5.3 should be significantly faster again, once it's released
<enigma42> Cool!
<NfNitLoop> yay!
<ronny> jelmer: is dulwich already able to generate commits (preferable without the need of a workdir)
<jelmer> ronny, yes
<jelmer> ronny, and without the need for a workdir; in fact, we can't generate a commit for a workdir yet
<ronny> oh, thats good
<ronny> i need some kind of backup app, and a git repo will do fine
<jelmer> vila: whoa, bzr-revnocache reduces the "bzr log" startup time on OOo from >100s to 0s
<beuno> yeah, igc's a genius
<vila> jelmer: told you ! :-) Seriously, I had no idea, that's great !
<beuno> it does magic with loggerhead
<beuno> haven't been able to work in the changes needed to use it
<beuno> but experiments show amazing improvements
<jelmer> would also be nice if bzr-gtk could use it..
<Peng_> bzr-revnocache stores data in .bzr, doesn't it?
<beuno> yes
<Peng_> Does it use a significant amount of disk space?
<Peng_> (Although I have lots of bzr-search indexes anyway, so who am I to care about that? :P )
<jelmer> Peng_, 12Mb for 190000 OOo revisions
<beuno> jelmer, it needs to be updated to use the new API. I guess if I manage to get to it for LH, I can do the same for bzr-gtk
<jelmer> beuno, that would be awesome
<Peng_> I guess I might as well install it, then?
<beuno> jelmer, I peaked at the code briefly, and it's roughly the same changes for both. Maybe bzr-gtk is easier
<beuno> Peng_, go for it, although LH will probably not use it
<beuno> it calls the old APIs, etc
<Peng_> I don't think my Loggerhead install has permission to write to .bzr anyway.
<beuno> right, that's one of the changes I need to make
<beuno> configurable caching dir
<jelmer> bzr-search could use that as well
<beuno> yeah, also on my ToDo list
<beuno> once I get that, and auto-scan-new-branches
<beuno> I want to make bzr-search a dependency for LH  :)
<beuno> well, that and allowing you to turn it off, of course
<ronny> hmm
<Peng_> FWIW, I don't want LH to do automatic indexing, but I do want it to use bzr-search indexes when they're available.
<ronny> i'll have to steal some ideas from lh later
<beuno> Peng_, the current behavior
<beuno> ronny, that's what open source is about  ;)
<ronny> im still not at the point where anyvc is ready to power a web interface
<Peng_> beuno: Right. If you add automatic indexing, please don't remove the current behavior. :)
<beuno> Peng_, of course not, I will make it a non-default optional setting
<Peng_> beuno: Thank you.
<ronny> hmm
<ronny> it kinda sucks that git lacks a smart server one could mimic over wsgi
<jam> jelmer: I'm repackaging 1.12 so that I can remove the ugly dll that is causing problems
<jam> Should I include svn 0.5.2 ?
<jam> also, jelmer, why are your branches no longer mirrored on Launchpad?
<Peng_> jam: So that people can't do "bzr branch lp:bzr-svn" and get an out-of-date copy.
<Peng_> jam: Last I checked, the mirrors still exist, under names like lp:~jelmer/bzr-svn/0.5-mirrored.
<jam> Peng_: of course it breaks all my build scripts...
<jam> which don't really care about getting the *latest*, just want to get an older tag
<jam> not to mention that people.samba.org was broken a couple times recently...
<kfogel> are revprops a new feature?  the string "revprop" does not appear in the Users Guide.
<jam> kfogel: possibly under "revision properties". Not new, but not really exposed to users, either.
<jam> I wouldn't expect to see them in a "Users Guide"
<jam> (--author happens to be implemented using it, though)
<kfogel> jam: not under "revision properties" either, but okay, I didn't realize they weren't exposed.
<jelmer> jam, yes, 0.5.2 would be nice
<jelmer> jam, sorry about the branches, I'm surprised the remote branches stuff doesn't allow -r..
<jam> jelmer: well, it would probably have worked, but by checkouts were from "bazaar.launchpad.net" and those branches disappeared
<jam> plus that machine has bad DNS, so I have to manually enter each ip address
<jelmer> jam, Yeah, it seems to work with just "lp:bzr-svn"
<jam> for now I just rebound to 0.5-mirrored
<kfogel> LarstiQ: hey, did you see that mail about bzr-email-notifier on the list?  The project that appears to want to be a superset of bzr_hookless_email?  Probably good if you respond and advise the developer whether to try to merge or to do an independent project.
<LarstiQ> kfogel: I've not been reading my email for the last ~2 weeks (been away from home), thanks for the heads up
<kfogel> LarstiQ: want me to follow up in the thread saying your attention has been drawn and you will be replying?
<LarstiQ> kfogel: that'd be swell :)
<kfogel> LarstiQ: doing now, np
<lifeless> spiv: when you see this; sometimes sleeping on the problem helps :)
<lifeless> http://paste.ubuntu.com/122552/
<jam> hi lifeless
<lifeless> hi jam
<lifeless> jam: I have a full test running; if you want to chat we could do so no
<lifeless> w
<jam> lifeless: I didn't get much done on compression today.
<jam> Today was packaging win32 installers, looking into python.org questions
<jam> etc
<jam> Like changing "time bzr branch --stacked" from 67m down to 4m30s...
<Peng_> 67m?
<jam> Peng_: we currently build the working tree by requesting each file's content separately
<lifeless> Peng_: get_record_stream was being overly conservative on memory
<Peng_> Ah.
<jam> so 4k files == 4k ish round trips at 100ms each
<lifeless> jam: thank you! :)
<jam> lifeless: Well, I did it by cheating, and I don't have great answer as to how to stream the content off correctly.
<jam> I do have 1 patch which is obvious for bzr.dev
<lifeless> jam: cheating - back to one big request?
<jam> lifeless: yeah
<jam> I just wanted to see where we would get to
<lifeless> jam: components_positions has the sizes
<lifeless> I suggest summing stuff from in there, or something
<jam> lifeless: 'bzr branch --stacked bzr+ssh://" is 3m39s' which is nice
<jam> I'm not sure if it is the max 200-range request issue
<jam> or if it is because of the new streaming
<lifeless> new streaming ?
<jam> lifeless: One is a smart server, rather than a dumb request
<jam> lifeless: so I don't know if the 4m40s => 3m40s is because of the smart server
<jam> or because of better readv() handling
<lifeless> oh
<jam> Our HTTP code has a hard-cap of 200 Range requests
<lifeless> readv() I would suspect
<jam> because Apache gives errors at 400 Range requests
<jam> our bzr+ssh code just has a hard-cap at ~5MB
<jam> but 5MB >> .5MB I was seeing for HTTP
<jam> lifeless: I'm seeing the "get_parent_map()" calls of death on a 'bzr push' for a bzr branch
<jam> (to a stacked branch on Launchpad)
<jam> so it isn't specific to lp trees
<jam> this is with bzr.dev tip
<jam> well 4039, close enough
<lifeless> jam: spivs fix hasn't landed
<lifeless> jam: I imagine it failed in some way
<jam> lifeless: k. I thought I saw him mention he sent in a fix
<jam> lifeless: can you point me to the patch?
<lifeless> yeah, its not in the log though
<jam> I haven't seen a specific patch for it on the bzr mailing list
<jam> though maybe I just haven't found it
<lifeless> yah I reviewed in person
<lifeless> http://people.ubuntu.com/~andrew/bzr/bug-331823/
<jam> so is the actual fix just getting rid of "update_revisions" ?
<lifeless> yes
<jam> anyway, it works here :)
<jam> stopped a process after 11min, new one finished in 17s
<lifeless> yeah
<mwhudson> gaaaaar, depending on other people's software is terrible
<jam> jml: so it looks like spiv's fix will probably work for your launchpad pushing woes, as long as we can actually get it merged :)
<lifeless> it was intended to land yesterday
<jam> lifeless: I did manage to spend a little bit of time looking through the git 'repack' code
<jam> some interesting bits
<jam> like the max allowed delta size changes based on how long the delta chain is
<jam> it is a bit hard to understand how it is defined, but they will stop generating a delta early
<jam> if it exceeds the expected length
<jelmer> hi davidstrauss
<davidstrauss> jelmer: hi
<jml> jam: sweet
<Tak> mwhudson: s/depending on // :-P
<mwhudson> Tak: if i don't depend on it, i can blissfully ignore it :)
<tdomhan> can I somehow delete all revisions before a specified revision in bzr?
<jam> lifeless: are we doing the conference call via phone again today?
<lifeless> jam: I hope not
<jam> lifeless: I thought other people said they preferred it
<lifeless> jam: opinions vary; I find it less convenient and worse audio
<mwhudson> skype has better audio when you can hear anything at all
<Peng_> Bazaar is supposed to work right when a local branch is read-only, right?
<Odd_Bloke> Peng_: Locking might be a problem.
<lifeless> Peng_: yes, it should
<lifeless> Odd_Bloke: if it is is a bug
<Odd_Bloke> Yeah, I was about to say I don't know about the 'supposed to'. :)
<Peng_> Just checking. Thanks.
<Peng_> (I'm not having any problems with bzr itself, just bzr-revnocache.)
<james_w> poolie: confirmed today
<poolie> yay
<jelmer> igc, 'morning
<poolie> james_w, put up your details when you get a chance please in https://wiki.canonical.com/Bazaar/Sprints/Brisbane09?action=diff&rev1=13&rev2=14
<garyvdm> Hi - I'm trying to use rebase for the first time. I'm trying rebase the revisions 631..624 on to the tip of trunk
<james_w> poolie: done
<james_w> hey jelmer
<garyvdm> I did bzr rebase -r 624 ../../trunk/
<jelmer> hey James
<garyvdm> It did nothing.
<garyvdm> What am I doing wrong
<igc> hi jelmer
<igc> nice to hear revnocache is helping OOo log speed
<jelmer> igc: Yeah, I was about to mention that :-)
<jelmer> igc, revnocache rocks, and so does the development5-subtree format :-)
<igc> I still feel making --short the default is the right thing from both a usability and performance perspective but I'll leave that battle till later :-)
<jelmer> igc: I hope to have a full import of OOo tomorrow, but that will be in development5-subtree
<igc> jelmer, so tell me more about why development5-subtree was so much faster at importing
<igc> I'm not seeing big gains in fastimport yet
<jelmer> igc: Well, the original comparison was against rich-root-pack, not 1.9-rich-root
<jelmer> igc: I'm also using create_by_inventory_delta
<igc> jelmer:that's good but you must be doing other stuff too
<igc> create_by_inventory_delta is typically wrapped by higher levels repository APIs isn't it?
 * igc looks
<jelmer> igc: previously I was using apply_delta()
<jelmer> which means a lot of time is spent copying and serializing inventories
<jelmer> igc: In fact, pushing development5-subtree back into 1.9-rich-root is probably about as slow as importing into 1.9-rich-root directly
<igc> jelmer: I'll get back to fastimport in a day or two and take another look at this
<lifeless> igc: create_inventory_by_delta is a huge win
<igc> jelmer: add_inventory_by_delta *looks* like its building a full new inventory but I suspect it's being smarter than that down in the ChkInventory, in which case the serialisation time should be much better
<jelmer> igc: yeah, it's a lot smarter than that
<igc> jelmer: thanks so much for working on the OOo import and keeping the conversation going with Jens
<igc> jelmer: back to revnocache, it's worth mentioning that's its still pretty raw
<igc> there's a TODO file in the plugin that I'm hoping mwhudson, beuno and others can use to get inspired and hack on it further :-)
<jelmer> igc: ah
<jelmer> igc: but are there plans to eventually have some of this in the cocore?
<jelmer> s/cocore/core/
<mwhudson> i want to work on incremental update,
<igc> jelmer: the trick to using revnocache is to update code to use Branch.iter_merge_sorted_revisions()
<igc> jelmer: I do want put of revnocache in the core but it's a part I haven't written yet ...
<igc> namely fast mapping of dotted-revno to revision-id by using a mergeline-cache
<jelmer> igc: looking forward to it :-)
<igc> unlike the full sorted merge graph, that cache can be small and (hopefully) cheap to update
<igc> jelmer: the biggest problem with revnocache is that it's a space pig - it stores the sorted merge cache *per* branch
<igc> if and when we can start chaining caches so that most the data is only cached in the local mirror/trunk branch with
<igc> incremental changes stored per branch, that issue will largely go away
<mwhudson> also, btrees will be a lot smaller i guess
<igc> mwhudson: right
<jelmer> igc: ah, hmm
<jelmer> igc: for OOo it's managable but that's because they have a huuuuge mainline and not a lot of branches
<dirkD> i just installed bzr-gtk from EPEL (on Centos 5), but how do i enable the Bazaar integration in Nautilus?
<garyvdm> igc: what is the difference between mergeline-cache and  full sorted merge graph?
<lifeless> jml: spiv: the fix for the bug is on its way now
<jml> lifeless: cool.
<garyvdm> igc: I assume that full sorted merge graph is what you get from merge_sorted_revisions()?
<jelmer> dirkD, install python-nautilus
<jelmer> dirkD, if it's doesn't work after restarting nautilus, then it probably is a bug in the RPM
<garyvdm> jelmer: Do you think a similar architecture to tbzr help the Nautilus integration perf problems?
<dirkD> jelmer: what's the name of python-nautilus in EPEL or Centos?
<jelmer> dirkD, no idea, sorry - the bzr-gtk package should already depend on it, or suggest it
<dirkD> gnome-python2 maybe?
<jelmer> garyvdm, perhaps
<jelmer> dirkD, if the bzr-gtk package doesn't depend on it, it probably doesn't install nautilus-bzr
<dirkD> jelmer: i think it's installed: i have "/usr/lib64/python2.4/site-packages/bzrlib/plugins/gtk/nautilus-bzr.py"
<jelmer> dirkD, it needs to be installed in the nautilus extensions directory
<jelmer> something like /usr/lib/nautilus/python
<dirkD> now the monkey comes out of the sleeve, i only have  /usr/lib64/nautilus/extensions-1.0
<jelmer> ah
<lifeless> argh
<lifeless> this test_source is killing me
<lifeless> honestly, who the hell cares
<lifeless> we've wanted to get to fast deltas between trees for a couple years now
<lifeless> and the branch to do that is only now closing in on completeness
<lifeless> bah, ECHANNEL
<dirkD> jelmer: should i put the *contents* of the gtk folder (/usr/lib64/python2.4/site-packages/bzrlib/plugins/gtk/nautilus-bzr.py etc.) or the whole gtk folder in ' /usr/lib64/nautilus-python/'?
<jelmer> dirkD, just nautilus-bzr.py
<jelmer> dirkD, but the package should be doing that for you..
<dirkD> ok
<dirkD> well, it doesn't (i even removed, and re-installed bzr-gtk after installing nautilus-python)
<jelmer> dirkD, sounds like a bug in the packaging
<dirkD> yes
<dirkD> jelmer: how would i know if the extension works?
<jelmer> dirkD, it'll show extra icons on bzr-managed files
<jelmer> hmm, autopack now seems to be taking 20% of the time of a svn-import now :-/
<lifeless> jelmer: cool
<ronny> is it possible to disable autopack?
<jelmer> ronny, afaik, yes
<jelmer> lifeless, so I'm wondering what the best approach is; I write a pack (commit_write_group) every 500 revisions at the moment
<jelmer> lifeless, however, that doesn't seem optimal anymore once the pack files are close to a Gb in size
<lifeless> ronny: its not a good idea, but for some specific applications [imports] it makes sense, so there is no UI, but there is a facility
<ronny> lifeless: thats why i asked
<jelmer> lifeless, would writing a pack file every 500 revisions and then later on triggering a single autopack have any negative influence on performance?
<lifeless> jelmer: its unlikely too as our delta chains are hard capped at 200 anyway
<dirkD> jelmer: the extension still doesn't work :( is there a way to debug it?
<lifeless> jelmer: btw, write 999 revisions
<lifeless> the pack count is log10 based
<jelmer> lifeless, what's unlikely /too/ ?
<lifeless> packs of 1 for 1-9
<jelmer> dirkD, it should print something to stdout when you load it in nautilus
<lifeless> its unlikely to have a negative performance impact doing a single autopack with that many revisions in a pack
<igc> jelmer: right, but the moment they start feature branching (which is a core part of their "cws" workflow), revnocache will grab the disk space for that branch (once a revno off the mainline is needed)
<lifeless> packs of 10 for 10, 20, ... 90
<lifeless> jelmer: so 999 revisions are permitted 27 pack files; you'll trigger less autopacks simply by doing that
<jelmer> lifeless, ok, will change that
<lifeless> jelmer: 500 revisions will be autopacking every 2 packs
<lifeless> (5, 10 -> 1 pack)
<igc> garyvdm: yep, the mergegraph-cache is the serialised output from merge_sorted_revisions()
<lifeless> 15, 20 -> 2 packs
<lifeless> 25, 30 -> 3 packs
<dirkD> jelmer: wait.... *i* should load it?
<lifeless> jelmer: changing to 499 would work too
<jelmer> dirkD, no, nautilus should load it
<bob2> lifeless: why 200? robustness?
<dirkD> jelmer: ok, it doesn't (just 'Initializing nautilus-open-terminal extension')
<jelmer> dirkD, my guess would be that it's not in the right directory
<dirkD> /usr/lib64/nautilus-python/nautilus-bzr.py
<jelmer> lifeless, ok, I've changed it to 999
<garyvdm> dirkD: run nautilus from the command line and see if it prints anything.
<lifeless> bob2: arbitrary figure
<dirkD> garyvdm: yes, i did, "[root@server1 ~]# nautilus -q"       "Initializing nautilus-open-terminal extension"
<jelmer> dirkD, In my case it's in /usr/lib/nautilus/extensions-2.0/python
<igc> garyvdm: the proposed mergeline cache is basically (base-revno, length, tip-revision) ...
<jelmer> lifeless, so, just to double-check:
<igc> e.g. 1.23, 12, xxxx
<jelmer> lifeless, there's no significant performance influence in turning off autopack during imports and autopacking only once at the end of the import ?
<igc> so finding the revision for 1.12.11 (say) will have much the same speed as finding revno:-2
<lifeless> jelmer: as long as you don't end up with massive scatter-gather IO on getting basis texts, it is fine
<garyvdm> igc: ic
<lifeless> jelmer: if you have delta chains spread across very many packs, its a problem.
<igc> i.e. we can match the base revno (1.12), find it's tip and search backwards from there
<jelmer> lifeless, hmm
<garyvdm> igc: I'm interested in this cause I can maybe use it to speed up qlog
<igc> that will be much faster that building/loading the whole revision graph and doing a map lookup
<jelmer> lifeless, thanks
<ronny> jelmer: are there any higher level apis for building trees/commits for dulwich?
<jelmer> ronny, other than bzr-git, not yet
<igc> garyvdm: well, I think qlog ought to call a new log api I'm working on called iter_log_revisions()
<igc> See my patch on logging multiple directories for the details
<dirkD> jelmer: a strace gave some nice info: "open("/usr/lib64/nautilus/extensions-1.0/python", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOENT (No such file or directory)"
<igc> Until that lands - I need to resubmit it following vila's review - the trick is to call Branch.iter_merge_sorted_revisions()
<ronny> jelmer: so i would have to use bzr-git to build things like commits for dulwich?
<igc> garyvdm: ^^^
<jelmer> ronny, well, what do you mean by a higher-level API exactly?
<james_w> dirkD: what version of nautilus are you using?
<jelmer> dirkD, looks like you want that dir then
<garyvdm> igc: Unfortunately qlog relies it's copy of graph_parents to work out what lines it needs
<igc> garyvdm: the mergeline cache will only speed up "log -rx.y.z"; otherwise you'll want what revnocache does now
<dirkD> james_w: 2.16.2
<lifeless> fooding
<lifeless> spiv: eta?
<james_w> dirkD: and how did you install the nautilus-python extension?
<garyvdm> igc: I'll have to make that lazy before I'll be able to take advantage of revnocache
<ronny> jelmer: 2 things i need to do- 2. iterate the paths a tree builds to blobs, so i can infer a sha1 sums file, 2. updating the current tree from a tarball that only has the changed blobs
<dirkD> james_w: from source
<spiv> lifeless: not sure, have been fighting the suddenly flaky wireless for a chunk of the morning.  Will SMS.
<lifeless> spiv: ok
<dirkD> ah, got it: http://pastebin.com/m78634a99
<lifeless> spiv: fwiw my wireless still works :)
<ronny> hmm
<ronny> i really love that content-addressing stuff
<james_w> dirkD: it seems to have picked up the wrong nautilus extension dir, is it hardcoded in the build system?
<dirkD> james_w: of bzr-gtk?
<james_w> dirkD: no, python
<jelmer> ronny, There's no functions for that at the moment, but the functions required to implement them are there
<dirkD> james_w: it's in the makefile
<james_w> dirkD: is there any mention of the -1.0 path?
<james_w> if not then you will need an older nautilus python
<dirkD> yes, it is :)
<igc> poolie: the benchdata directory on orcadas now has pack & btree archives for mysql & bzr
<dirkD> james_w: could this be relevant? http://pastebin.com/m30f48386
<igc> I've added bzr.ini and mysql.ini files as well showing how the indirection works
<igc> poolie:^^
<lifeless> igc: indirection ?
<igc> lifeless: picking the best pre-upgraded (branch) archive based on the tool name usertest is benchmarking
<james_w> dirkD: maybe
<james_w> dirkD: your strace shows that you haven't got nautilus-python installed for the right nautilus ABI, you need to fix that to have any chance of this working
<dirkD> PYTHON_LIBS = -L/usr/lib -lpython2.4
<dirkD> PYTHON_LIB_LOC = /usr/lib
<igc> lifeless: that way, usertest benchmarks the operations without taking 10-20 hours to upgrade to the right format first
<igc> (well, for development5 formats on big projects at least)
#bzr 2009-02-25
<jelmer> jam, where does subvertpy live on Windows?
<jelmer> igc: btw, it would still be nice to see your RevisionImporter class land
<ronny> jelmer: basically i'd have to store blobs, then generate the tress - and finish with the commit
<jelmer> ronny, yeah, that's very well possible
<dirkD> james_w: i don't understand why it still keeps looking for "/usr/lib/libpython2.4.so", even if i set 'PYTHON_LIBS = -L/usr/lib64 -lpython2.4' and 'PYTHON_LIB_LOC = /usr/lib'
<ronny> jelmer: bascially i want to write up a client/server that can start a content-addressed repo for backups, and then send added/removed files
<james_w> dirkD: no idea
<ronny> i think git is an almost ideal store for incremental backup
<lifeless> igc: cool
<jelmer> ronny, yeah, I agree it seems quite well suited for something like that
<lifeless> ronny: seen duplicity?
<ronny> lifeless: yes, dont like it
<lifeless> k
<dirkD> jelmer, james_w: i had to change PYTHON_LIB_LOC and PYTHON_LIBS not only in ./Makefile, but also in ./src/Makefile . But it doesn't work yet: http://pastebin.com/m9691f84
<igc> jelmer: I haven't forgotten about that, though its now a bit more than just revision loading because I needed a thin veneer over a repository and that become it
<jelmer> igc: I might also have a look at preparing it for bzr.dev after finishing InterBranch, if that's ok with you?
<james_w> dirkD: maybe because you are using nautilus-python that is meant for the new API
<dirkD> ok, but isn't it related to libnautilus-extension?
<dirkD> http://library.gnome.org/devel/libnautilus-extension/stable/libnautilus-extension-nautilus-file-info.html#NautilusFileInfo
<poolie> igc, thanks <https://wiki.canonical.com/Bazaar/Sprints/Brisbane09?action=diff&amp;rev1=13&amp;rev2=14>
<dirkD> james_w: i think i have the right version
<dirkD> james_w: http://pastebin.com/m16eae94d
<spiv> jml: btw, the probable fix for https://bugs.edge.launchpad.net/bzr/+bug/331823 has landed, please let us know how it works out for you
<ubottu> Ubuntu bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,New]
<james_w> dirkD: I'm not really sure what's going on, and it's far too late for me
<dirkD> for me too :P (1:27)
<dirkD> for jelmer too
<jml> spiv: thanks. I'm running the nightly build, so it'll be easiest to tell when that updates.
<igc> jelmer: sure. Make sure you grab the latest fastimport - revision_store.py is the latest code
<jml> Or I guess I can just pull dev and push up an LP branch
<lifeless> jml: bug 331823 fix hath landed
<ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,In progress] https://launchpad.net/bugs/331823
<spiv> lifeless: you're four minutes behind the times!
<lifeless> spiv: heh
<jml> what revno?
<lifeless> 4043
<spiv> jml: 4043 pqm@pqm.ubuntu.com-20090225000405-09p33ue22l4h19yk
<jml> thanks.
<lifeless> igc: great work vis-a-vis emacs
<jml> http://paste.ubuntu.com/122611/ that's r4041 on initial push -- that hasn't happened before
<lifeless> spiv: my sink fix is merging now
<jml> as in, this bit hasn't happened: "Source format does not support stacking, using format: '1.6'
<jml>   Packs 5 (adds stacking support, requires bzr 1.6)"
<igc> thanks lifeless
<jam> jelmer: subvertpy the python files lives inside 'library.zip' with all the other python files. The '.dlls' are in lib/*, IIRC
<lifeless> jml: what is your source branch format?
<jml> lifeless: source branch == the branch I'm pushing?
<lifeless> jml: I hope
<jml>         branch: Branch format 7
<lifeless> jml: please file a bug
<jml> lifeless, spiv: the critical bug is fixed. pushing up a single revision change took only "HPSS calls: 274" and "136.763  return code 0"
<lifeless> jml: 'ugh'
<lifeless> jml: you might like to try a copy of bzr.dev on the server too
<jml> lifeless: haha
<jml> lifeless: the server in this case is Launchpad.
<lifeless> jml: I know
<jelmer> jam: Thanks
<jelmer> igc: thanks, will do
<jml> lifeless: anyway, two minutes for a single revision sucks, but it was what 1.12 was doing, so the regression is gone.
<lifeless> jml: Im serious though, I posted details on using a bzr.dev on e.g. people yourself
<lifeless> jml: be great to know if you get the sort of improvements we're seeing in our testing
<jml> lifeless: yeah, well I'm not going to install bzr.dev onto Launchpad this week
<jml> lifeless: I can try setting up a toy server to experiment with later.
<lifeless> jml: some checkout bzr into your homedir on people :P, if you havetime
<ronny> can someone point me to docs for conviently using the apis to do things like pull/push/branch
<lifeless> ronny: I don't think we've got great docs for that. To reproduce exactly the UI I'd go to builtins.py cmd_pull|push|branch
<lifeless> ronny: but generally you can just do branch.push(other_branch), branch.pull(other_branch), and branch.sprout(new_url)
<ronny> lifeless: the ui thing seems to do a toon of things more (like handling stacking)
<lifeless> ronny: yeah; so big picture I want to put a layer of ui-but-not-cli into bzr, but its not there yet; things like push.py are heading in that direction
<dirkD> james_w, jelmer: thanks a lot, it works!
<dirkD> and goodnight
<ronny> hmk
<lifeless> ronny: the push UI specifically handles 'need a new branch' 'target dir is missing' 'explicitly stack' and a couple more
<ronny> i think i want to avoid replicating that in anyvc
<lifeless> you could use show_push_branch
<ronny> yeah, less to replicate
<lifeless> yay, sink refactoring landed
<poolie> lifeless: dude, put your stuff on the wiki so that maria can book our hotel plesae
<lifeless> poolie: sure think
<lifeless> poolie: didn't realise it was blocked, I've put the core details on
<lifeless> poolie: I'll dig up the itinery thing and get exact flights soon
<poolie> ok
<poolie> flights wbn, but dates are of course necessary to make the booking
<lifeless> I had no idea it was blocked, I've known dates for ages (since I told you I'd booked)
<poolie> thanks
<jelmer> When I add tests for InterBranch.update_revisions(), should I remove the old tests (except for a trivial one) for Branch.update_revisions(source, ...)
<jelmer> ?
<poolie> jelmer: probably yes
<poolie> maybe just a test that it's finding the interoject that you expect
<jelmer> ok
 * igc lunch
<igc> (probably a long one - back later)
<grettke> Hi folks. Question for you. I've got a bzr repo and I would like to keep a svn repo in sync with the bzr repo. How would you go about doing that? Is there a standard approach?
<lifeless> install bzr-svn
<grettke> lifeless: done
<lifeless> if you want to go svn->bzr use bzr svn-import or even just bzr branch svn://path/to/branch (and then bzr pull to incrementally update)
<lifeless> for the other way, its bzr push
<grettke> lifeless: When I push, it complains that: bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<grettke> I do just want to branch as I am primarily sharing out to svn in this case, bzr is the master.
<lifeless> grettke: try push --overwrite
<lifeless> jelmer: ^
<grettke> lifeless: Entered. It is working.
<grettke> lifeless: I mean "running".
<Peng_> Um, I'd do "bzr missing" to help figure out why it thinks they're diverged.
<jelmer> grettke, are you pushing a new branch?
<grettke> jelmer, It is "new" in that I just created it and there is nothing in it. I created it via svn mkdir before pushing.
<Peng_> With a new enough bzr-svn, you don't need to do that.
<grettke> I've got 1.12.1
<grettke> Peng_: Understood. I shouldn't have had to.
<lifeless> grettke: the svn mkdir is what made the branch history different
<mwhudson> does anyone here have access to IE?
<grettke> lifeless: I see. From here forward, I can just push right to it?
<lifeless> grettke: yes
<grettke> mwhudson: Internet Explorer?
<mwhudson> yes
<grettke> mwhudson: yes
<mwhudson> grettke: have you used loggerhead before?
<grettke> jelmer: I can't find a subvertpy directory in the Windows installation
<grettke> mwhudson: no
<jelmer> grettke, I've just replied to the bugreport after asking jam
<mwhudson> in any case, if you could look at http://bazaar.staging.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/changes and see if it looks ok and the js behaves that would be awesome :)
<jelmer> grettke, it's in a zip file in the lib directory
<grettke> jelmer, oh I see you posted, agreed!
<grettke> mwhudson: is a change in the UI supposed to occur after clicking on the downward facing arrow icons?
<mwhudson> grettke: yes
<mwhudson> grettke: i take it from your question that it doesn't?
<grettke> grettke: The arrows facedownards, but nothing else.
<mwhudson> grettke: it works ok in safari and ff if you can try those to compare
<grettke> mwhudson: I Can screenshoot if you like.
 * mwhudson swears
<grettke> mwhudson: How about opera?
<mwhudson> grettke: haven't tried that either
<grettke> mwhudson: It does the same thing in Opera.
<mwhudson> :(
<poolie> igc, we're now getting a decent graph in http://benchmark.bazaar-vcs.org/rrd/runtime-common-suite-all.png
<poolie> i haven't reenabled all the branches yet
<poolie> however we're getting an error in generating the summary.html so i'm going to look at that
<Stanlin> how to use bazaar with eclipse?
<lifeless> Stanlin: http://bazaar-vcs.org/BzrEclipse
<Stanlin> it doesnt work in windows
<lifeless> verterok: ^ you have a fan
<Stanlin> it simple cant pull
<Stanlin> commits, but doesnt pull
<lifeless> what happens
<Stanlin> no traffic, just fails
<Stanlin> in debian works fine
<lifeless> Stanlin: well for starters please report a bug
<lifeless> on bzr-eclipse
<Stanlin> is bazar cvs or vsc?
<lifeless> Bazaar is Bazaar.
<Stanlin> i mean
<Stanlin> is this a control system?
<Stanlin> or versioning system?
<spiv> Stanlin: I don't know what you mean by those terms
<thumper> Stanlin: some people refer to it as one of the "distributed version control systems" (DVCS)
<poolie> spiv/lifeless: in http://bazaar-vcs.org/SmartPushAnalysis1.13 in case 2/3 (push one revision), there are lots of get_parent_map calls after we've inserted the stream
<poolie> apparently caused by bug 331823
<ubottu> Launchpad bug 331823 in bzr "Pushing an update of a stacked branch to Launchpad sometimes takes nearly an hour" [Critical,Fix released] https://launchpad.net/bugs/331823
<spiv> poolie: not since this morning
<spiv> poolie: :)
<poolie> way to go robot you found kitten
<thumper> spm: on bzr.dev?
<spiv> poolie: new numbers are 28.7s, 19 HPSS calls
<poolie> thanks
<spiv> poolie: I'm just digging into why case 4 is still apparently suffering from that bug, though.
<spiv> poolie: also, the only VFS calls in that 19 are read-only ones
<spiv> (gets and stats)
<spiv> (Actually, it looks like case 4 is suffering from a different bug that happens to be superficially similar, but it's still worth figuring out exactly what it is)
<spiv> It looks like the fix to 331823 also fixed a previously unnoticed bug with update_revisions of a stacked remote branch, which has in turn revealed this issue.
<poolie> http://bazaar-vcs.org/SmartPushAnalysis1.4?action=AttachFile&do=get&target=HPSS-push-bzr-logs.tar.gz
<poolie> thumper: ^^
<poolie> spiv, we should add some tests about stacked branches...
<thumper> spiv: a smart push analysis I think poolie means
<thumper> spiv: case 8 (or 9), push a new stacked branch
<lifeless> poolie: already planned
<spiv> Yes, definitely.
<thumper> thanks guys
<poolie> cool
<poolie> those tables are good
<poolie> i changed one of them to have three row headings: version, wall time, rpcs
<spiv> thumper: push a new stacked branch, also push onto an existing stacked.
<thumper> spiv: right
<spiv> poolie: thanks, I was intending to do that :)
<poolie> thanks
<jkakar> How can I create an empty Bazaar branch in a temporary directory, for use in a unit test?  It seems to be missing from http://bazaar-vcs.org/Integrating_with_Bazaar.
<spiv> thumper: possibly also with different combinations of modifying new files vs. modifying files whose bases are already present in the stacked branch.
<thumper> spiv: I defer to your knowledge on the tests needed
<lifeless> jkakar: self.make_branch('foo')
<lifeless> jkakar: in TestCaseWithMemoryTransport or any subclass thereof
<spiv> jkakar: use TestCaseWithMemoryTransport (or a subclass) -- what lifeless said
<jkakar> lifeless: Cool, thanks.
<lifeless> jkakar: you _want_ to use that to get full isolation of bzr
<spiv> jkakar: http://doc.bazaar-vcs.org/latest/developers/testing.html#test-support
<Stanlin> how to make Zend work with bazaar?
<Stanlin> zend studio
<jkakar> spiv: Awesome, thanks.
<lifeless> Stanlin: no idea sorry
<Stanlin> i meant
<Stanlin> is bazaar a CVS or a SVN?
<igc> polie: that graph looks good; let me know if I can help with the summary.html issue
<thumper> Stanlin: what?
<igc> poolie: ^^^
<thumper> Stanlin: its a VCS
<poolie> :?
<thumper> Stanlin: a DVCS even
<poolie> igc i'll get back to it when thumper lets go of my ear :)
<poolie> Stanlin: it's like both but much better
<spm> thumper: ? i gather you were after andrew not me?
<Stanlin> well im asking that, because Zend has the option for CVS and SVN, dunno what to use
<thumper> spm: yes
<thumper> spm: tab completion sometimes gets you fist
<thumper> s/fist/first
<spm> and here was me thinking 'fist' was you being excessively NZerish for 'first'... ;-)
<thumper> Stanlin: what is Zend?
<spiv> Stanlin: Bazaar is not a drop-in replacement for CVS or SVN
<spiv> Stanlin: it works in a different (and better) way, but tools that expect to invoke CVS or SVN won't automatically work with Bazaar.
<lifeless> thumper: zend is a proprietary php ide
<Stanlin> oh i see, thats why bazaar doesnt work in windows
<spiv> Stanlin: Bazaar works in windows.
<lifeless> Stanlin: bazaar works fine in windows; did you file the bug on bzr-eclipse I asked you to? (The primary developer of bzr-eclipse is in argentina and won't be awake at the moment, so if you want the problem fixed he needs a bug report)
<Stanlin> ok ill prepare it
<poolie> thumper: End getting all value/timestamp matches to Function End took 0.0423979759216 seconds
<Stanlin> what connection type uses bazaar?
<poolie> http, ssh, sftp, https, etc
<Stanlin> pserver? ext? extssh? pserverss?
<poolie> it has equivalents to those but it's not the same protocol as cvs or svn
<poolie> thumper: http://bazaar-vcs.org/Roadmap, http://bazaar-vcs.org/Roadmap/BrisbaneCore, http://bazaar-vcs.org/Roadmap/SmartServer
<poolie> ... https://wiki.canonical.com/Bazaar/Migration, Bazaar/Projects <https://wiki.canonical.com/Bazaar/Projects>
<poolie> Draft Specs/Easy Workspace Setup <http://bazaar-vcs.org/DraftSpecs/EasyWorkspaceSetup>
<Stanlin> how to specify the protocol for bazaar? aint working with https
<Stanlin> do i need to point to the trunk?
<thumper> Stanlin: what are you trying to do?
<spiv> Stanlin: you may find http://doc.bazaar-vcs.org/latest/ helpful, in case you haven't already seen it.
<Stanlin> im trying to connect from zend
<Stanlin> usin svn
<lifeless> Stanlin: bzr is not svn, if you're using svn you should seek help in a svn channel - e.g. #svn
<Stanlin> but i want to use bzr
<lifeless> Stanlin: if the code you want to get access to is in a bzr branch you need to use bzr.
<Stanlin> yeah i want to force bzr to become svn
<spiv> bzr isn't svn.
<spiv> It's a bit like asking for WordPerfect to be MS Word ;)
<spiv> Perhaps try asking the Zend community if anyone has integrated bzr?
<Stanlin> whats the channel for zend?
<Stanlin> i mean, i like eclipse but we use zend framework which zend studio is perfect
<Stanlin> ok brb
<Stanlin> i need to sleep
<berto-> hi, if i want to submit a merge directive is the email address: bazaar@lists.canonical.com ?
<bialix> vila: ping
<bialix> hmmm. I don't think he's sleeping. fullermd said real hackers never sleep
<bialix> vila: please look at my comment for https://bugs.launchpad.net/qbzr/+bug/333892
<ubottu> Ubuntu bug 333892 in qbzr "selftest crashed if qbzr installed without pyqt4" [High,Confirmed]
<bialix> ubottu say vila about my fix
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bialix> pff
<bialix> ubottu: next time try harder and say this to vila
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bialix> ubottu -- you're empty can
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bialix> yeah, yeah. train yourself
<lifeless> poolie: I'm done for the day, but perhaps you'd like a small chat ?
<poolie> lifeless: sure, call me?
<lifeless> sure
<vila> hi all
<creek23> hi, how do i output a diff on a patch file? it only displays it on command prompt -- im on windows.
<ignas> hi
 * igc dinner
<lifeless> creek23: I'm not sure
<lifeless> creek23: is this in the gui or the console?
<creek23> console
<vila> lifeless: Are you still there long enough to talk about some _commit_write_group problem I encounter in bbc ?
<lifeless> creek23: I thought windows supported '> filename ' syntax
<creek23> ...? how do i do that?
<ignas> why logger head has revisions "inverted", i mean - when looking at a revision through the web - let's say 2534 "next" button points to 2533, while previous to 2535... shouldn't it be the other way
<lifeless> bzr diff > foo.patch
<creek23> thanks lifeless... its working now.
<lifeless> vila: always, but there will be latency
<lifeless> I'm in the middle of other things
<vila> lifeless: high latency is better than infinite latency :-)
<vila> So, the problem I encounter is that during a commit on a MemoryTree the _write_group is None when  self.work_tree.update_basis_by_delta(self.rev_id,  self.builder.get_basis_delta()) is called in Commit.commit()
<lifeless> vila: seems appropriate to me
<lifeless> vila: it should be None
<vila> ok
<vila> The problem is we can't build an CHKInventory then. This is where I want some input: should we even try to build one and if not why do we end up trying ?
<lifeless> vila: you shouldn't be building on in the working tree object :)
<lifeless> vila: you can _construct_ a CHKInventory, for an existing CHKInventory in the repository, outside of a write group
<lifeless> but update_basis applies a delta to a inventory
<lifeless> ...
<lifeless> so this is MemoryTree
<lifeless> which has no persistent basis
<lifeless> probably it just needs an overridden update_basis_by_delta - see the one in MutableTree and think about what MemoryTree needs :P
<vila> but how comes commit can work for chk without that ?
<vila> First test ever trying to run with a MemoryTree ?
<ronny> when is on-disk stability for brisbane-core planned?
<lifeless> ronny: soon, a few weeks
<lifeless> vila: WorkingTree4/5 have a real apply_delta thing in there
<lifeless> vila: MutableTree is for WorkingTree3 and MemoryTree
<vila> lifeless: right, so that's because it's the first test using a memory tree for chk repo, right ?
<lifeless> I imagine so
<lifeless> at least the first doing a commit
<vila> lifeless: ok, thanks, that gives me the right context :)
<lifeless> np
<mwhudson> ignas: i guess the idea is that you start at the tip
<mwhudson> ignas: i agree it's a bit ass-backwards
<ignas> mwhudson: i think being backwards is a binary choice - it either is or is not ;)
<Coke> Hi guys. I'm confused about the distinction of repository and branch. I have my repository under DIR A, I check it out under DIR B. The strange thing is, DIR A is completely empty aside from .bzr. Is that correct?
<mwhudson> ignas: not really, it's backwards or not depending on your state of mind :)
<ignas> mwhudson: there is no spoon?
<ignas> Coke: did you commit anything to DIR A?
<lifeless> Coke: a repository is a database, a branch is what you push and pull and checkout
<lifeless> you *cannot* 'check out' a repository :)
<Coke> ignas: yes
<ignas> ahh, you tried checking out a shared repository?
<Coke> Right, still though, just did init on a new repos, did a co, added files and then ci. The repos still only has .bzr files
<ignas> i did not even know you could do that
<lifeless> Coke: so you did something like "bzr init-repo A" "bzr init A" "bzr checkout A B" ?
<Coke> lifeless: not init-repo, just init
<lifeless> Coke: ok
<lifeless> Coke: so A is a *branch*
<lifeless> pure and simple
<Coke> uh.
<Coke> ok.
<Coke> I have to make them into repositories then?
<lifeless> 'bzr init' makes branches
<lifeless> no you don't need to do anything else
<lifeless> what does 'bzr log' report in A
<ignas> Coke: you should bzr update the A branch
<ignas> Coke: then the files you have commited in B will appear
<Coke> ignas: yes
<Coke> so, how can I make it a real repos from this branch?
<ignas> Coke: it's a "real" repo
<lifeless> Coke: its already real.
<ignas> Coke: but the working tree is only updated explicitly i think
<lifeless> Coke: I'm gonig to guess, that A is on a remote server
<lifeless> Coke: would that be right ?
<Coke> lifeless: yeh, but it's mounted locally
<lifeless> Coke: as far as bzr is concerned, is it seeing the local mount for A, or are you using a network protocol
<Coke> local mount
<Coke> told you
<ignas> lifeless: i just tried it locally, bzr ci in a checkout of a branch, does not update the working tree of the original branch
<lifeless> I'm not doubting you, I'm just making sure we're communicating clearly
<lifeless> ignas: right, its not == push
<lifeless> Coke: ok so here is whats going on; the checkout command is designed for folk wanting to emulate svn/cvs where there is a centralised spot that all commits go to
<Coke> I don't need to emulate it .
<ignas> lifeless: oh, so bzr ci is not just "commit locally + push", it's just something simmilar to it
<Coke> I've done init-repo on my source repos now
<Coke> So, what do I do to make my working copy in my home dir? not co?
<lifeless> ignas: bzr ci with a bound branch is a two-phase commit direct to the branch object thats checked out
<Coke> I think they should have ditched the SVN terminology, if you're switching from svn it's confusing
<lifeless> Coke: well, given that svn repositories are also just a .svn directory on the server, I don't agree. But lets get you up and running ?
<lifeless> Coke: you can use checkout if you want.
<Coke> what is the bzr way
<lifeless> Coke: alternatively you can use branch and then use push to push commits back to the other branch
<lifeless> Coke: bzr supports a few different ways, for different use cases
<Coke> it says I cannot check out, my repos is not a branch
<Coke> what the hell?
<Coke> the repository has to be a branch?
<lifeless> right, repos are not branches. As I said above you *do not need to do anything*
<Coke> lifeless: I want to see the files in the actual repos
<lifeless> Coke: repositories are not branches, you don't need to care about repositories at all.
<lifeless> Coke: Ok. We can do that. Can I ask, why you have both A and B?
<Coke> What I did before 1) bzr init /sourcedir  2) bzr co /sourcedir /projectdir
<Coke> lifeless: because I want versioning
<Coke> all the files on the server are backed up
<lifeless> ok
<Coke> if you're going to question/make me change our entire network setup to accomodate bzr I'll just switch source tools
<lifeless> I'll be slightly delayed for a bit here, real life things happening
<lifeless> Coke: I am not trying to do that, I'm trying to make sure I actually give you what you want.
<Coke> I don't know what I want.
<Coke> How is it done with BZR?
<Coke> Right now I'm not even sure my commits are working properly
<Coke> no files in the "repository"????
<ignas> Coke: why do you want to see the source code in /sourcedir?
<ignas> Coke: you don't expect that from svn do you?
<Coke> ignas: comfort?
<Coke> ignas: yes
<ignas> Coke: nope, svn repository is an opaque object, that you can't see inside of
<ignas> Coke: so if you want to use bzr co and bzr ci - just trust it ;)
<Coke> What should I use?
<ignas> and when you don't trust it - go over to /sourcedir and bzr up
<Coke> Like I said, I don't WANT to use anything
<Coke> ignas: bzr up does not work on one of the ... I don't even know what to call it
<Coke> It's NOT a repository, because I used init, not init-repo
<Coke> What the hell is it?
<ignas> branches, you don't need repositories
<lifeless> Coke: if you used 'bzr init' it is a branch
<ignas> don't think about repositories
<lifeless> Coke: what does 'bzr info' report in that directory
<Coke> We are iterating the same thing over and over.
<Coke> I still don't know, do I want a repository or a branch as the one true source for my files?
<lifeless> you want a branch
<Coke> Ok. So branch has left it's original english and programming meaning to become what used to be "repository"?
<lifeless> we're reiterating because you're not answering the questions I'm asking which are designed to let ignas and I know what you have configured so we can tell you what it will do
<Coke> lifeless: like I've said, nevermind what I want or what I have, I want to know how to do it bzr style
<lifeless> Coke: no, a branch is a branch - its a line of development, the tip of a DAG
<Coke> lifeless: but the main source repository isn't a branch
<Coke> it may contain branches
<ignas> Coke: no
<Coke> (in the SVN sense)
<Coke> ignas: ok
<ignas> Coke: no, the main source is not a branch container
<Coke> if not, let me ask you this: what did my branch actually branch off from?
<ignas> Coke: the main source is a branch, branches are all over the place
<Coke> a branch needs something branch off from, this is the one and only source I have
<lifeless> Coke: your branch B branched off the branch A that you inited.
<Coke> no wonder I didn't get it, branch is misused
<lifeless> Coke: in fact, because you made B using 'bzr checkout' you have one branch - A, and a checkout of A called B
<Coke> it's a bzr branch even though by english and svn meaning it's not
<lifeless> its a branch in svn meaning
<Coke> lifeless: branches are grown from the main repos in svn
<lifeless> though svn is vague on that; its a branch in CVS and git and hg meaning
<Coke> well, svn is shite, that's why I'm switching
<ignas> Coke: you are confusing branches, repositories, branch containers and working trees
<Coke> tried both hg and git, didn't like the way they handled stuff
<Coke> "branch CONTAINERS"?
<Coke> working tree?
<Coke> Is there a bzr primer?
<lifeless> ignas: I think you're adding confusion :)
<Coke> I just want 1, 2, 3, 4
<Coke> done
<lifeless> ignas: cause I don't know what a branch container is
<lifeless> Coke: there sure are docs
<lifeless> http://doc.bazaar-vcs.org/latest/
<Coke> 1) bzr command of some sort -> your main source is setup correctly, 2) bzr command of some sort -> your main source is copied to my local project dir ready for commits
<Coke> that's just two steps
<lifeless> you've done that
<Coke> Indeed.
<lifeless> and if you would run 'bzr log A' you'd see that your commits are there safe and sound
<Coke> so no worries that the files are missing?
<lifeless> no worries at all
<lifeless> I really regret that you've had some confusion here
<Coke> cvs -> svn -> bzr   I basically got through that by using svn and bzr as I would cvs
<lifeless> Coke: 'bzr log A' will show the commits A has
<lifeless> 'bzr log -v A' will show you more details
<Coke> I think compatibility with the older, lesser versioning systems is the mistake
<ignas> lifeless: http://info.wsisiz.edu.pl/~blizinsk/git-bzr.html "Differences between Git and Bazaar" (the document I got the branch container term from)
<Coke> one just just empty the cup completely and start anew
<lifeless> the big difference betwen bzr and cvs is that branches in CVS are just labels, but in bzr they are separate directories (which is close to svn, but not as free-form)
<ignas> Coke: yeah, i think so too, which is why I use Darcs for my small hobby projects ;) (wouldn't suggest it to you though)
<Coke> lifeless: yeh
<Coke> here's waht my impression is though, bzr has no main repository
<lifeless> the big difference between bzr and svn is that bzr doesn't need a server or main repo at all
<lifeless> it can start in a single location and scale up from there
<ignas> the Distributed part ;)
<Coke> it's just a collection of branches, you just decide on a per-branch basis where you wan to put your changes?
<lifeless> yup
<Coke> ok
<Coke> that's quite different from svn
<Coke> well, glad that's cleared, was worrying that all my commits had gone missing
<Coke> it does make sense now
<Coke> I could init my project direcotry and check the files in from the same dir
<lifeless> we _do_ have a hidden repository object, but its *solely* for disk-space optimisation, so in common use you don't need it. And as its just a database its not very useful on its own, so we try to avoid talking about it.
<ignas> lifeless: sometimes I think that you should have named it "shared something" instead of "shared repository" to reduce the confusion
<bialix> monsieur vila?
<vila> bialix: yup
<bialix> vila: my fix is just better version of your yesterday patch
<bialix> I've tried to use Unavailable Feature but failed
<bialix> because it seems I can;t use lazy import in test modules
<bialix> it failed with traceback then
<Coke> Ok, so here's the deal.
<vila> bialix: May be I can help ? Where is your fix ?
<vila> bialix: lazt_import is not for tests, that's for sure
<Coke> bzr init /myreposmount/someproject; bzr co /myreposmount/someproject mylocaldir
<Coke> then I just use ci -m, update, log and status inside mylocaldir as I please
<Coke> am I still within the comfort zone of bzr there?
<lifeless> Coke: totally
<bialix> vila: I'm not sure this problem require too much efforts
<Coke> Sweet. Thanks boys!
<lifeless> my pleasure
<bialix> vila: my branch https://code.launchpad.net/~qbzr-dev/qbzr/bug-333892
<vila> bialix: sure, but easing selftest use is worth it IMHO :)
<bialix> vila: actually I'm just wrap addTestFromModuleName into tre-except ImportError
<bialix> vila: this way I'm skipping not all qbzr tests, but only those that required PyQt4 libs
<vila> bialix: that's indeed better than my fix
<bialix> vila: with qt libs we have 30 tests to run; without - 13 test
<bialix> vila: I'm just want to ask you about my warnings
<Coke> I switched to launchpad just for their bzr support
<bialix> vila: here is my diff: http://bazaar.launchpad.net/~qbzr-dev/qbzr/bug-333892/revision/630
<vila> bialix: pulling your branch, just a sec
<Coke> Then it turns out that it doens't provide any way to upload files or screenshots.
<Coke> Which is complete suckage.
<lifeless> Coke: it can upload files
<lifeless> Coke: you just need to have a release
<lifeless> Coke: not sure about screenshots, have you asked on #launchpad ?
<bialix> vila: I hope you excuse moi for my harmless game with ubottu :-)
<vila> bialix: hehe, bots are our friends, we should take care of friends, always ;)
<bialix> you think I offend it?
<bialix> poor ubottu :'-)
<Coke> lifeless: yeh, screenshots on their website faq is "not yet"
<Coke> lifeless: I'll try that release thingie
<mwhudson> ignas: https://bugs.edge.launchpad.net/loggerhead/+bug/297930 fwiw
<ubottu> Ubuntu bug 297930 in loggerhead "When browsing revisions, next should go up, previous should go down, numerically" [Undecided,New]
<Coke> I'm currently making a barcode library, so far all EAN encodings work nicely. Going for code-128 today.
<Coke> I was planning on making it available on launchpad just because it's easy for me to switch the, uhmm... "branch root" (?) to launchpad.net
<ignas> mwhudson: that makes me sad...
<mwhudson> maybe i should change the links to "older" and "newer"
<Coke> What do I call the "original" branch? the one you want people working against
<bialix> vila: so you qbb:approve my fix? ;-)
<vila> bialix: ok, I think what you've done is best than what existed, the way you did it doesn't allow using UnavailableFeature, which is a bit unfortunate, but certainly the best you can do
<bialix> vila: UnavailableFeature cannot be used because to load modules we need to import PyQt4
<lifeless> Coke: 'trunk'
<bialix> vila: I've tried and failed
<lifeless> Coke: or 'mainline' sometimes, but most folk call it 'trunk'. Oh, another possible term is 'project.dev'
<Coke> Oki doki
<vila> bialix: the idea is that you should wrap the import pyqt4 or define some TestFeature that tests can then use, but that would certainly be far more invasive than your actual fix
<bialix> wrapping import pyqt4 does not help, because the tests will try to import qbzr modules, and these modules in turn also will try to import pyqt4
<vila> bialix: in the end, that's your code, for me, as a user or even occasional contributor, the most important point is being to run selftest without the need to enable/disable the plugin 40 times a day :-)
<vila> bialix: yes, you should wrap everywhere... that's why I say invasive :-)
<bialix> vila: I've asked you about those warnings
<bialix> is it ok?
<vila> bialix: warnings are fine, I can visual-grep-v them :-)
<bialix> I've used trace.note, so IIRC they could be suppressed with bzr selftest -q
<bialix> ok.
<bialix> thanks
<bialix> will push to trunk shortly
<awilkins> Coke: What's your barcode library written in?
<bialix> vila: why you say all the time "qbzr is my code"? it's not fair and actually incorrect.
<bialix> qbzr is written by luks, me, garyvdm and markh
<bialix> 4 men, most of them much better hackers than me alone
<vila> bialix: saying that it's not your code isn't true either, I don't forget the orthers, but it's not like I was talking to someone who didn't *en *know* the code
<vila> s/*en/even/
<vila> bialix: yet, it's more your code than mine because you know it far better than me
<bialix> ok, I forgot that in English you and you written by the same word.
<bialix> in Francais is not IIRC
<vila> bialix: you (singular) and you (plural) are indeed different in French tu (singular), vous (plural)
<Coke> awilkins: Pythohn
<bialix> yep, I'm sorry. OK
<vila> bialix: I had a fight with my gf long ago because one day I said *my* house instead of *our* house :-)
<bialix> :-D
<vila> bialix: in the end qbzr is GPL right ? So it's really *our* code, whoever we are :)
<bialix> yep
<Coke> lifeless: where's the release stuff in launchpad?
<Coke> I see no way to upload files to launchpad. "Downloads" is empty and no way of adding any files there.
<bialix> branch format 7 != 1.9?
<bialix> Coke: you have to create release first
<Coke> There's no option to create a release
<Coke> I can register a series
<Coke> I can make announcements.
<Coke> ctrl+f doesn't find "release" anywhere on the page
<bialix> go to your series
<bialix> you'll see "make release" link
<Coke> i have a series named "1.0"
<Coke> Holy crap.
<Coke> I'm 100% sure that programmers have built the interface for launchpad
<Coke> When you have to use the search function to find menu options in an UI you know programmers have designed it
<lifeless> lol
<Coke> The option to make a release is via "series" (doesn't even mention "release" on the details)
<lifeless> yes
<Coke> There are FOUR option menus that switch around depending on where you are.
<Coke> Either you use top tabs, and then there's the middle tabs, you have links in the middle of the page and now it seems releases are handled via a special menu to the right.
<Coke> I might consider buying the Appple bible of UI design and send it to the launchpad crew.
<Coke> How can BZR know about launchpad-login??
<bialix> you told it
<Coke> so bzr can run any arbitrary command name?
<bialix> almost. but I won't do the sandwitch for you
<bialix> even if you say "sudo"
<Coke> Oh, it supports plugins
<Coke> neet
<bialix> heh. s/I won't/bzr won't/
<Coke> Here's what I don't understand, it took the svn guys years to complete svn and it was a total failure. When did Bazaar start as a project?
<bialix> between 2004 and 2005
<Coke> How does bzr obtain my email address when I commit to trunk?
<bialix> run `bzr whoami`
<Coke> how do I change it?
<gnomefreak> is it known that bzr is saying you dont have permission to push branch (its a brand new branch
<bialix> `bzr whoami "My Name <foo@example.com>"
<bialix> bzr whoami -h ftw
<gnomefreak> to be exact http://pastebin.mozilla.org/628162
<bialix> gnomefreak: perhaps you're trying to push with http:// URL
<Coke> what would be the "bzr way" to do tags
<gnomefreak> nope im using the lp:~gnomefreak/....
<gnomefreak> bialix: ^^
<bialix> gnomefreak: try again with -Derror option
<bialix> you should have your SSH key registered at LP
<bialix> Coke: bzr way?
<bialix> `bzr tag` is not good enough for you?
<gnomefreak> bialix: i do
<bialix> -Derror will print more info about problem
<bialix> ah
<bialix> yep
<bialix> gnomefreak: you can't use this URL
<bialix> lp URLs has 3 parts: username/projectname/branchname
<bialix> you have 4
<gnomefreak> i think i see that. i changed it and ill let you know
<gnomefreak> yep i used extra it has created it. thanks
<bialix> you need to choose another branchname instead of "greasemonkey/greasemonkey.upstream"
<Coke> oooufffffff.
<Coke> It's just tooooo complicated to make proper releases in launchpad.
<Coke> I don't get it, I made a series, it's a competely new branch now
<Coke> How do I tag 1.0 ?
<bialix> first time everything is hard, is not?
<Coke> no
<Coke> sourceforge was quite pleasant
<Coke> albeit slow
<Coke> ok, so each version is it's own branch
<bialix> Coke, look at http://bialix.com/qbzr/docs/make_release.html
<bialix> this is my instruction how to do QBzr release
<bialix> I wrote it for myself and other QBzr guys
<bialix> Coke: you can tag the trunk with "1.0" label or use separate branch and tag it. does not matter
<Coke> I tagged it now
<Coke> and I have a separate branch
<Coke> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<Coke> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x138fa90>
<Coke> permission denied, public-key
<Coke> ah.
<Coke> ofcourse.
<Coke> bialix: is it possible to add a release on a trunk tag?
<Coke> I'm quite possitive this could not have been made any more complex.
<Coke> It appears that you have to link a branch in launchpad to get it into a release
<Coke> That means tags can't be used.
<Coke> Bleh, sorry for pestering you with these bullshit noob questions...
<Coke> http://launchpad.net/crosswordpuzzle
<Coke> I think I've managed to make my first release.
<Coke> I did tag the revision, so 1.0rc1 should be "frozen" in time, but I'm using the same branch (trunk) for the 1.0 series. Don't see the point of forking unless there are simultaneous changes in trunk and 1.0, but im the only developer so...
<Coke> Time for lunch.
 * bialix back
<bialix> this will work
<igc> night
<jam> night igc, morning vila
<jam> jelmer: why did you mark bug #334326 as invalid after reporting it?
<ubottu> Launchpad bug 334326 in bzr "Creating working tree for OOo takes ages" [Undecided,Invalid] https://launchpad.net/bugs/334326
<jelmer> jam: It was a cold cache issue
<jelmer> jam: running bzr st on the wrong disk
<jelmer> jam: it takes less than 2 seconds on a disk with a warm cache
<vila> jam: hi !
<jelmer> jam: Which I think is reasonable for 2Gb and 75k files :-)
<jam> jelmer: can you just mention that on the bug?
<jam> I think we could be doing better in cold-cache situations, though that isn't the current focuse
<jelmer> jam: I did, but it looks like it hasn't come through yet on lp
<jam> hi vila
<jam> jelmer: ah, ok, np then
<jam> I just saw the "invalid" change
<jelmer> jam: The checkout one is valid though, and quite annoying
<jam> jelmer: what version are you running?
<jam> I just submitted a couple patches for review which might address this specifically
<jelmer> jam: my own strange mix of brisbane-core and my own patches that haven't been merged yet
<jelmer> jam: Ah, cool
<jam> jelmer: so phase one of the patch was this: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49A45A9D.5040303%40arbash-meinel.com%3E
<jam> You might want to try *just* that fix, and see what it does for you
<jam> (When extracting fulltexts, we weren't reading in forward-sorted order, which is a bit naughty)
<jelmer> jam: checkout is a pity, since most other things seem to work well (status, commit, log)
<jelmer> jam: Thanks, I'll give that a try
<jam> I have another patch on top of that, which may help more
<jam> though the fact you are hitting such high memory consumption is a bit strange
<jam> certainly if you are swapping
<jam> things get uber-slow
<jelmer> I'm not swapping
<nicolaide> i have some problems try download from launchpad using bzr... the error is that
<nicolaide> bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/%7Enotify-osd-developers/notify-osd/main/.bzr/repository/packs/f8097ae6b0b6a1353502801617edd7cf.pack: Expected a boundary (Wb_/GvfIMKppD)jWz:C-) line, got ''
<nicolaide> someone can help me?
<jam> nicolaide: sounds like you have a broken squid proxy
<jam> (known issue that has been fixed in squid for a year or 2)
<jam> I think we have a workaround
<nicolaide> mmm....and how can i fix that problem?
<jam> nicolaide: so the bug is #198646
<jam> bug #198646
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646
<jam> nicolaide: I assume you can't do anything about your squid proxy, right?
<nicolaide> i dont have any idea of that
<jam> nicolaide: the easy fix is to use "bzr launchpad-login" with your launchpad username
<jam> after which we'll connect via ssh rather than http
<nicolaide> mmm... i try...
<nicolaide> stay tunned
<nicolaide> jeje
<nicolaide> No Launchpad user ID configured.
<jelmer> abentley: hi
<abentley> jelmer: Hi
<jelmer> abentley: I put up a patch a couple of days ago that merges clean-tree into bzr core
<jelmer> abentley: Are you still ok with moving it?
<abentley> jelmer: I have mixed feelings.
<jelmer> abentley: What about in particular?
<abentley> I don't like the core command set getting bigger, and I don't like everything good getting ripped out of bzrtools.
<jam> jelmer: do we still get the performance benefits in 0.5+ if you use the old mapping?
<jelmer> abentley: I agree we shouldn't end up merging all of bzrtools into bzr core, but clean-tree is common enough to be in core imo
<awilkins> jelmer: Yes, when you push revisions to a 1.4 repository using 1.5 libraries, the bzr: properties are revprops and not fileprops.
<awilkins> jelmer: Sorry, latency on that was a bit long
<jelmer> awilkins, ah, cool
<jelmer> awilkins, :-)
<jelmer> jam, some of the benefits, yes
<jam> jelmer: so specificaly, I'm thinking of the python.org conversion. What would they gain by switching mappings?
<jam> As blowing away an existing conversion has a lot of knock-on effects
<jelmer> jam: pushing back into subversion wouldn't need svn file properties
<jam> jelmer: isn't that only with svn >= 1.5 ?
<jam> I guess they are using 1.5.1 according to: http://svn.python.org/projects/python/trunk/
<jelmer> jam: Also with newer 1.4's, as awilkins just reported
<jam> jelmer: so the big win there is just that they aren't *visible* ? Or does it scale better, or ?
<jelmer> jam, it also scales better
<jelmer> jam, file properties require one roundtrip per revision
<jelmer> jam, revision properties come in with the log data
<jam> jelmer: though if someone else is doing the conversions for you... it doesn't change much, does it?
<jelmer> jam: Well, you also need to fetch that data when you push
<awilkins> jelmer: Not with 1.4 ; with a 1.4 repository as long as you are using 1.5 libraries (the specific scenario I was using was the 1.5 file:/// provider)
<jelmer> jam: "bzr co" on OOo trunk is now down to 43 minutes
<jelmer> with your sort knit fetch patch
<jam> jelmer: down from?
<jam> jelmer: the next step is to check out: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49A47EDF.2050001%40arbash-meinel.com%3E
<jam> Which may or may not improve things
<jelmer> jam: Down from somewhere between 45 to 55 minutes.
<jam> aka, a little, but not very significant
<jam> we should really teach pack about grouping texts together...
<jelmer> jam: Yeah, a significant amount of time is spent in seek()
<jelmer> during the actual import itself it was close to 20%
<jam> jelmer: that is converting from bzr-svn, right?
<jam> Do you know if you cache parent texts?
<jelmer> jam: yes, I cache parent texts (in bzr-svn)
<jelmer> actually, that code wasn't there yet when I was doing the import
<jelmer> so it may actually be better now
<jam> jelmer: when converting texts from subversion, you just use "get_record_stream()" which passes FulltextContetFactory, is that right?
<jam> (btw, it would probably be better to use ChunkedContentFactory, so you don't have to ''.join(lines))
<jam> which causes the target repo to switch over to "foo.add_lines()"
<jam> but that doesn't use any caching.
<jelmer> jam: well, svn deltas are on the fulltext
<jelmer> not on lines
<jam> jelmer: I'm talking about "versionedfiles.py line 78"
<jam> line 70: lines = stream.readlines()
<jam> line 78
<jam> FulltextContentFactory(..., bytes=''.join(lines))
<jelmer> jam: ah
<jelmer> jam, That's only used during stacking, but worth optimizing anyway - thanks
<jam> jelmer: ah, so what is the code path for "bzr branch $SVN" ?
<jelmer> jam, all in fetch.py
<jelmer> RevisionBuildEditor is the object that Subversion reports changes to
<jam> jelmer: line 561
<jam> self.editor.texts.insert_record_stream([
<jam>     FulltextContentFactory((self.file_id, text_revision),
<jam>         [(self.file_id, revid) for revid in text_parents],
<jam>         text_sha1,
<jam>         fulltext)])
<jam> So my earlier comment is still correct
<jam> you insert the texts 1 at a time
<jam> as a Fulltext
<jam> which then is translated in '.insert_record_stream()' into an add_lines() call
<jam> which doesn't cache the parent_texts
<jelmer> jam, That's a corner case situation though
<jam> jelmer: I haven't been able to track down the bulk-insert yet, then
<jelmer> jam: FileRevisionBuildEditor._close()
<jam> That is line ~561 isn't it?
<jelmer> yeah
<jam> self.editor.texts.insert_record_stream([]), and inserting a stream which is 1 entry long, and uses a FulltextContentFactory
<jelmer> jam: It used to be add_lines() but IIRC lifeless recommended using insert_record_stream() here to avoid splitlines()
<jam> jelmer: I'll write up a patch.
<jam> the big win is being able to cache recently inserted texts
<jam> I'll ping you with a patch in a second
<jelmer> jam: thanks
<Peng_> You mind if I mark someone's bug as a duplicate?
<jam> unfortunately, there is some munging you have to do to get between fulltexts and a Content object
<jam> :(
<jam> but I'll still see what I can do
<jam> it could be pretty big
<jam> jelmer: is _text_cache used for anything else? Or could I put 'lines' in there, instead of 'fulltext' ?
<jelmer> jam: you could put lines there
<jam> k
<jam> and self.file_stream
<jam> I can do "readlines()" instead of '.read()' ?
<jelmer> jam, It's a LRUSizeCache though, so the max size of it would have to be reduced
<Peng_> (Bug 328148 and bug 321750.)
<jelmer> jam, yeah
<ubottu> Launchpad bug 328148 in bzr "Less spaff from unshelve, please" [Undecided,Confirmed] https://launchpad.net/bugs/328148
<ubottu> Launchpad bug 321750 in bzr "unshelve emits "UserWarning: ProgressTask(0/3, msg='Merge phase') is not the top progress task ProgressTask(None/None, msg='')"" [Undecided,New] https://launchpad.net/bugs/321750
<jam> jelmer: I can change the "measure length" function
<jam> so as to remain accurate
<jam> sum(map(len, lines)) :)
<jam> (I've done this before :)
<jelmer> jam, :-)
<jelmer> peng_: go for it
<barry> jam: so, i want to get the c.p.o mirrors updated, packed, and mirroring the svn masters again.  do you have some time to help me set that up the right way?
<jam> barry: first, you need to install bzr-svn on the appropriate machine
<jam> Then we will need to look at this: http://paste.ubuntu.com/122880/
<barry> jam: @dinsdale[~/python:1006]% bzr plugins
<barry> bzrtools 1.12
<barry>     Various useful commands for working with bzr.
<barry> launchpad
<barry>     Launchpad.net integration plugin for Bazaar.
<barry> netrc_credential_store
<barry>     Use ~/.netrc as a credential store for authentication.conf.
<barry> svn 0.5
<barry>     Support for Subversion branches
<jam> barry: any chance to get svn 0.5.2 ?
<jam> jelmer just mentioned he has done perf improvements and bugfixes
<jam> 0.5 is good enough if it is hard to do others
<barry> jam: is that in a ppa?
<barry> jam: this is a debian lenny box but i've hacked in the ppa for bzr from hardy
<barry> jam: and it seems to work okay :)
<jam> barry: it isn't yet. jelmer?
<barry> jam: we have svn 1.5.1 on the machine
<jam> barry: so for now, we'll go with what you have
<barry> jam: cool
<jelmer> barry: 0.5.2 is in experimental
<sevenseeker> I have code that is neither in svn or bzr, if I init the bzr environment, and I need to eventually import this into svn, can I then update the svn repos?  If so, where do I supply the svn info?
<barry> jelmer: i don't want to do too much admin tweaking on this box, but adding a ppa would be okay
<Peng_> jelmer: :)
<jam> barry: we just need to get jelmer to update the ppa :)
<jam> but for now 0.5.0 is probably good enough
<barry> jam: cool
<jam> barry: so it seems the next step is to log in as the user that will be doing the conversions
<jam> (whoever runs the cron script)
<jam> and set "default-mapping =v3" in ~/.bazaar/bazaar.conf
<barry> jam: can we trigger the update from an svn hook?
<jam> barry: I know there are ways to do something like that. *I* don't know them
<sevenseeker> should I first import to svn, then checkout a fresh copy via bzr and go from there?
<jam> I think the ones I've seen trigger on the email generated by the svn hook
<jelmer> sevenseeker, either would work
<jam> I don't know svn well enough
<barry> jam: okay, no worries.  for now i'll do the updates as a cron
<jam> I would guess it would be something simple
<jelmer> barry, doing it inside of the post commit hook means svn commit won't finish until the bzr mirror has updated
<sevenseeker> jelmer: thank you, just looking for best practices is all :)
<jelmer> sevenseeker, committing to svn first would probably be easiest
<jam> jelmer: would you expect that to take long for simple updates?
<barry> jelmer: i hadn't thought about that
<jelmer> jam: In 0.5.0, it could be noticable
<jelmer> jam, barry: is there any particular reason for going with the v3 mappings? Lots of existing branches that depend on it?
<barry> jelmer: ok, for now i think i'll just run it from a cron every minute...?
<jam> jelmer: "lots"? not sure, but we had trouble getting them to upgrade to 1.9
<jelmer> barry: yeah, that should work
<barry> jelmer: yeah.  i really don't want to ask the py-devs to have to update their branches after i've just asked them to update their clients ;/
<barry> jelmer: these are experimental mirrors so when the experiment is over, we can make real ones using the better format
<jam> jelmer: when is "apply_textdelta" used?
<barry> jelmer: iow, i hate to require that people blow away their branches right now
<jelmer> jam: apply_textdelta is called to report delta's for a particular file
<jelmer> jam: it's called for any text change
<jam> jelmer: k, but is/isn't it used during conversion?
<jelmer> jam: it's used heavily during conversion
<jam> don't worry, I think I have it sorted out
<jam> you hide its actually calls behind the VF api
<barry> jam, jelmer we have a bzrdev user that owns the branches currently, and holds the ssh authentication tokens.  should we make that user also do the mirroring?
<jam> texts.get_record_stream()
<jam> barry: makes the most sense to me
<barry> jam: no security issues that you can think of?  (i can't)
<jam> barry: it seems like it is a trusted user already
<jam> and it only needs *read* access to the svn repo
<barry> cool
<barry> jam: so, add a ~/.bazaar/subversion.conf for that user?
<jam> It looks like you can put it in ~/.bazaar/bazaar.conf, but having subversion.conf is probably still a good thing
<barry> jam:  we have no bazaar.conf right now
<jam> jelmer: so when converting, you insert a text of "link XXX" for symlinks?
<jelmer> jam: yes, and set a magic file property
<jam> jelmer: but why do that for bzr?
<jam> since bzr never pays attention to the texts of symlinks
<jelmer> jam: where do I set that?
<jam> I just see you doing "if fulltext.startswith('link' )"
<jam> and I'm trying to figure out how to handle it
<jam> You insert the fulltext *before* you check for whether it is a symlink or a file
<jam> and I was trying to understand why
<jam> (I would insert empty lines for a symlink, though I don't think it specifically hurts anything)
<jelmer> jam: A symlink can be magically changed into a regular file
<jelmer> jam: and in that case we need to know the base against which we'll receive delta's
<jam> barry: sorry we didn't tell you about the "don't disconnect my internet" flag
<barry> jam: not sure if this made it through:
<jam> :)
<barry> % cat subversion.conf
<barry> default-mapping = v3
<barry> jam: man, my router is so royally f'd ;)
<jam> barry: looks right to me. what about you jelmer?
<jelmer> barry, it should be in the relevant [UUID] section
<jam> jelmer: can it just be the default?
<jam> for what they are doing at least
<jelmer> in that case it should be in bazaar.conf
<barry> jelmer: yeah, i don't know what that means ;)
<jam> barry: put it in ~/.bazaar/bazaar.conf :)
<barry> % cat bazaar.conf
<barry> [DEFAULT]
<barry> # Use the old bzr-svn mappings for now so that users don't have to re-get
<barry> # any of their existing branches.  This should be removed and the new
<barry> # mappings used when the experiment is over.
<barry> # barry 25-Feb-2009
<barry> default-mapping = v3
<barry> jam, jelmer ^^
<jam> +1 (AFAIK)
<barry> jam: cool, thanks.  now we have to set up the cronjob, right?  what's the command for updating the existing branches?
<barry> jam: is it a (cd wherever; bzr pull http://svn.python.org/blah) ?
<jam> jelmer: does "svn-import" update? Or is it just "for branch in branches: bzr pull" ?
<jam> barry: that should be fine, I'm just not sure if there is a svn-import command that would bring in all branches at once
<jelmer> jam: It will craete new branches when they appear in svn
<jelmer> barry, you probably want to use "bzr svn-import --incremental"
<jelmer> that will only fetch new svn revisions
<barry> oh, i should note that we don't want to import all svn branches, becuase we have a bazillion of them
<jam> barry: branches are cheap in bzr, are you sure?
<jam> I suppose the total history may get bigger
<barry> jam: right now we have just 2.5, 2.6, 3.0, py3k and trunk
<barry> jam: hmm.  we have 77 branches in svn.python.org/python/branches
<barry> i guess it wouldn't be too bad.  let's do what's easiest
<barry> we've got 188GB free, so that shouldn't be a problem
<jam> I would think "svn-import --incremental" would be easiest
<jam> since it runs across the whole repo in one pass
<barry> jam: okay cool.  since this is running on the svn machine, should i use the svn repo file path as the FROM_LOCATION?
<jam> presumably
<jam> you probably want to run it manually once
<jam> to make sure
<barry> and TO_LOCATION would be the shared repo dir containing the .bzr directory, right?
<jam> right
<barry> jam, jelmer okay cool, thanks.  so --incremental is the only svn-import switch i'll need?
<jelmer> barry, yep
<barry> jelmer: great, thanks.
<barry> jam, jelmer now i know you wanted me to do a pack. can i just do that after the svn-import runs?  note that we haven't been updating the mirrors in many days
<jelmer> barry, bzr should be autopacking
<jam> jelmer: I want an explicit pack, because it changes the indexes
<jam> barry: should be fine
<barry> jam: so just to make sure: bzr svn-import --incremental followed by bzr pack, right?
<jam> barry: right. You don't need to "bzr pack" during cron
<jam> just this one time
<barry> jam: gotcha
<barry> jam: thanks
<barry> let me run these commands and see how they go!
<sevenseeker> running 'svn checkout http://foo.com/bar/trunk bar-trunk' works for me, but with bzr 1.12 switching 'svn' with 'bzr' like 'bzr checkout http://foo.com/bar/trunk bar-trunk' does not work and says...
<sevenseeker> bzr: ERROR: Not a branch: "http://foo.com/bar/trunk"
<jelmer> sevenseeker, do you have bzr-svn installed?
<sevenseeker> got this from http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn
<sevenseeker> jelmer: I did... its possible it is messed up I guess, so let me reinstall
<jelmer> sevenseeker, you can check by running "bzr plugins"
<sevenseeker> argh! not there
<jam> jelmer: I'm seeing test failures with svn "trunk"
<jam> replay_snapshot() takes at least 5 arguments (4 given)
<sevenseeker> its been awhile since I installed it... maybe I didn't reinstall when I upgraded bzr to 1.12
<jelmer> jam, your bzr-rebase is outdated
<jam> k
<sevenseeker> ok, I reinstalled 0.5.2 via easy_install from source, but it is not showing up in the plugins
<jam> jelmer: now I'm getting a failure in: test_fetch_signature
<jam> has no revision svn-v4:137f067b-b28 ...
<jam> (this is with trunk, to make sure the test suite is clean before I apply my changes)
<jelmer> sevenseeker, I don't think easy_install works for bzr plugins
<sevenseeker> jelmer: oic
<jelmer> jam: trying here
<jelmer> jam: all tests pass here
<jelmer> jam: lp:bzr-svn ?
<jam> jelmer: yep, and bzr.dev
<jam> $ bzr revision-info
<jam> 2675 jelmer@charis.vernstok.nl-20090225162227-tr0271cjv6ta6gli
<jam> jelmer: does it matter that I'm using subvertpy 0.6.1?
<jam> I'm also getting failing "dpush" tests
<jelmer> jam: What's the error message for the dpush failures?
<jam> AssertionError: not equal:
<jam> a = 'unknown:\n  foofile.BASE\n  foofile.THIS\nconflicts:\n  Contents conflict in foofile\n'
<jam> b = 'modified:\n  foofile\n'
<jam> and another with "Unexpected return code"
<jelmer> jam: Perhaps you have bzr-git installed as well?
<jam> probably
<jam> I also see: ValueError: Only svn:log can be set with Subversion 1.4
<jam> So maybe my local SVN is old?
<jelmer> jam: Ah, yeah, that would explain the failures
<jam> jelmer: nope, no bzr-git
<jelmer> svn 1.4 would explain it though
<jelmer> the dpush thing is a bug though; it seems to accidently be setting revprops there while it shouldn't
<jam> k
<jam> I just need a baseline so I know my code isn't breaking *more* stuff :)
<jam> I think I have a reasonable patch, which I can let you test in a second
<jam> finishing the test suite run now
<rodolfo> hi all
<rodolfo> yesterday i installed bzr-gtk and still didnt figure out how to use: 1) nautilus integration, 2) what's that notification icon on my tray all about?!
<jam> jelmer: do you create a new RevisionBuildEditor for each revision?
<jelmer> jam: Yes
<jelmer> uhm
<jelmer> no
<jam> jelmer: so the text_cache is regenerated each rev
<jam> I'm inserting something into self.editor._XXX
<jam> but then I never find it again
<jelmer> jam: yeah, you're right
<jelmer> pointless cache :-)
<jam> jelmer: so we might want to rethink  the text_cache
<jelmer> jam: Pushed a fix
<Peng_> jelmer: Did you mean to make a change to commit.py in your "Fix import." commit?
<Goundy> Hi.
<Goundy> How to commit and push a branch by keeping the commits messages got from a merge ?
<jelmer> peng_: Yes
<jelmer> peng_: The commit message is incomplete :-)
<Peng_> jelmer: Ok, just making sure. :)
<Peng_> Goundy: If you run "bzr merge" and "bzr commit", the merged revisions will be listed in the log. (Unless you did a cherrypick.)
<Goundy> Peng aborting commit write group: BzrCommandError(empty commit message specified)
<Goundy> Peng and if I specify a message I'm screwed cuz I loose my messages got from merge
<Goundy> what's a cherrypick ? Ã´O
<jam> jelmer:  care to try out: http://bzr.arbash-meinel.com/plugins/svn/add_lines_cache/
<jam> With my trivial testing, it makes a modest improvement
<jelmer> jam: checking
<jelmer> jam: Are chunks random blocks of data?
<jelmer> jam: or is there more to it?
<Goundy> Peng any hint ? :-)
<jam> "chunked" means that it is a list of strings
<jam> so "lines" is a chunked
<jam> as is [fulltext]
<Goundy> well guys are you sure nobody have a little idea about my issue ?
<Goundy> It's making me stuck...
<Goundy> And I already screwed my history tree I don't want to put more rubbish inside it :/
<jam> Goundy: I doubt you are "screwed"
<jam> try committing with a message
<jam> and then doing "bzr log"
<jam> it should show the commit messages for the merged revs
<jam> (just indented)
<pickscrape> Is anyone aware of any integration between bzr and cruisecontrol?
<Goundy> jam well I know that it works but I'm just trying to keep my meaningful messages for each file that comes from the merge destination....
<jam> I'm pretty sure "bzr log file" will also give you what you want
<jam> as would "bzr gannotate file"
<KhaZ> pickscrape: No, I'm not sure.  That said, check out TeamCity - it rocks Cruise Control.
<KhaZ> pickscrape: (Not sure if it works with bzr either, however.  We use it at work tho, and prefer it over CC).
<pickscrape> KhaZ: does it handle PHP projects well?
<jelmer> jam: so ideally, bzr-svn should be working with chunks?
<jam> jelmer: for some values of "ideally".
<jam> I think they are generally better
<jam> as they are more trivial to convert to lines or fulltexts
<jam> and you can have *part* of your content shared
<pickscrape> KhaZ: ah, it's not free is it...
<jam> (so 2 texts for the same file can share 90% of the content, just the lines that have changed are diff)
<jelmer> jam: Any reason you call chunks_to_lines() ? Is that really necessary?
<jam> jelmer: chunks aren't guaranteed to be lines
<jam> so if you want to work in *lines* (like for .add_lines()) you have to call it
<jam> that said, chunks_to_lines() was written with that in mind
<jam> chunks_to_lines(lines) is very fast
<jam> and returns the original object
<Goundy> jam ah indeed bzr log gives all what I want but not loggerhead so it's a launchpad problem and not a bzr one
<Goundy> Thank you
<jam> barry: how's it going?
<jam> (I don't see any updates to code.python.org yet)
<barry> jam: nope, i got nervous so i'm doing a fresh import into a test directory, which is still running.  i wanted to see what branches it ends up with because i forgot that that svn repo has the sandbox an dlots of other crud
<jelmer> jam, We don't seem to actually require chunks to be lines anywhere
<jam> jelmer: does 'bzr svn-import' use a 1.9-r-r format by default?
<jelmer> jam: Except when self.file_data wasn't changed
<jelmer> jam: No, it uses rich-root-pack
<jam> jelmer: we do during the "add_lines()" call
<jam> but yes, that is the only time
<jelmer> jam: But we call read_lines() to obtain the data we feed to add_lines()
<jam> It was more to leave "file_data" as always lines
<jam> but we can make it always chunks
<jelmer> jam: http://pastebin.ubuntu.com/122932/
<jam> jelmer: fine with me
<barry> jam, jelmer opps, i'll need to import to a 1.9-r-r format i guess.  when i do the real incremental import will that work automatically if the target branches are 1.9-r-r?
<jelmer> barry, it won't change the format of existing items
<barry> jelmer: but all the new branches?
<jelmer> barry, so if you create a 1.9-r-r repo before you start, it should work fine
<barry> gotcha
<Peng_> When will bzr stack without me explicitly requesting it? When branching from LP? When pushing to LP? What?
<beuno> Peng_, pushing
<Peng_> beuno: Do I ever have to worry about it on "bzr branch"?
<beuno> Peng_, why would you worry?
<beuno> if you want it stacked, you add --stacked to the branch command
<beuno> but it doesn't stack at all by default
<beuno> Launchpad can't force you to  ;)
<Peng_> beuno: Alright. That's what I wanted to make sure of. Thanks.
<jelmer> jam: Merged, thanks!
<thumper> beuno: actually stacking by default on LP does work
<thumper> beuno: the branch will be stacked on the development focus branch
<thumper> beuno: if and only if your local repository format supports it
<thumper> beuno: unless there were more bug fixes I haven't checked
<thumper> beuno: and you're running with a bzr later than 1.7
<thumper> Peng_: if you have a local branch in format 1.6 and push to LP for a project that has a dev focus branch set, LP will try to stack it for you
<thumper> Peng_: actually LP tells the bzr client to stack it
<LarstiQ> thumper: I suppose lp doens't have shared repositories for multiple branches in the same (owner, project) combo yet?
<LarstiQ> (if ever)
<jam> jelmer: so did you see a performance difference?
<KhaZ> pickscrape: There's a free version of it, but it is limited somewhat.
<jam> LarstiQ: I think with stacked, they are working around the issue
<LarstiQ> jam: that is indeed why I asked :)
<bialix> yo LarstiQ, how your vacations?
<LarstiQ> bialix: too short, but good! Thanks for asking :)
<LarstiQ> had good weather (snow out, -8, clear sky and sun)
 * bialix wanna get vacation too, but can't
<bialix> that's nice
<bialix> I'm reworking UI of the scmproj
<fullermd> Vacations are so exhausting.  You always have to deal with people saying things like "Oh, where are you going?"
<bialix> now it's much more usable
<fullermd> ...   what do you mean, going?  I'm locking the door, taking the phone off the hook, and sleeping for 2 weeks straight...
<LarstiQ> :)
<LarstiQ> fullermd: in my case it's usually "Finland, visiting my girlfriend"
<bialix> fullermd: ya, I know what you talking about
<fullermd> Going somewhere is something you then have to lock the door, take the phone off the hook, and sleep for 2 weeks straight to _recover_ from.  Defeats the purpose.
<LarstiQ> bialix: so how is scmproj coming along?
<bialix> I've starting actively uising it at work.
<bialix> I think nested trees should rocks
<bialix> but even with my emulation I've got measurable boost
<bialix> I can finally implement very complex build configuartion for my project
<bialix> and this is fantastic.
<bialix> Too bad nested trees was in coma so long
<bialix> I'm working on tutorial now.
<LarstiQ> bialix: that's good to hear
<bialix> I've forced to rework model a bit, but in the end it's just improve usability (based on my dogfooding experience)
<bialix> I hope it's no more so clunky as before
<bialix> it was really is
<bialix> I found many interesting ideas in git submodules
<bialix> but in the same time their submodules are so "spartan"! you have to do many boring operations manually
<bialix> it seems just like a half-hour hack
<bialix> but bzr still don't have anything, so git won by scores 1:0
<bialix> ok. thanks for listening. have to go. bye.
<barry> jam: bzr: ERROR: parent_id {18549@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease20-maint:Lib%2Fidlelib} not in inventory
<jam> barry: can't say I've seen that specific issue. But it is claiming that "Release20-maint:Lib" isn't present, when  its child "idlelib" is being addedd
<jrydberg__> anyone here installed bzr using fink?
<jam> this certainly wasn't one of the branches you used to be converting
<jam> I don't know if jelmer knows what would cause that sort of traceback (but he may be sleeping by now)
<barry> jam: right.  i think it's a byproduct of running 'bzr svn-import' over the whole svn repo
<jam> barry: sort of. I don't see how bzr-svn wouldn't be able to convert something that could be represented in svn, without giving a different error.
<barry> jam: might be interesting to check out that branch over svn and see i end up with?
<jam> barry: probably a good starting point
<jam> (I could understand if it was a path that svn supports that bzr doesn't, like with a '\', but I don't see that happening here)
<barry> jam: that's probably a pre-svn branch iirc.  i don't remember when we upgraded from cvs to svn
<jam> If it helps, it looks like revno 18549 is when this file was originally introduced
<jam> barry: considering you are at 44k or so, I would guess it is also a cvs time
<jam> but still, if it is valid in svn, I don't see why we couldn't represent it at this poin
<jam> point
<jam> oh, and it idlelib is the directory which is missing
<jam> I misread the original error
<jam> the *parent_id == ...idlelib* is missing
<barry> jam: yep.  i just checked out the branch, which went fine, but there is no Lib/idlelib
<jam> barry: can you try an older rev?
<jam> to see if there used to be one
<barry> jam: let's see if i can remember how to do that :)
<jam> svn co -r 20000 should work, IIRC
<jam> either that or
<jam> svn co $URL@20000
<barry> jam: thanks
<barry> jam: cvs2svn was run at r18549 and nothing before that appears to be 'svn up'able
<barry> svn: Target path does not exist
<jam> does that mean you already had a svn repo, and then you pulled in things from cvs?
<jam> or that the existing svn was pure conversion up to r18549?
<barry> jam: svn log says...
<barry> r18549 | (no author) | 2001-01-02 12:07:49 -0500 (Tue, 02 Jan 2001) | 2 lines
<barry> This commit was manufactured by cvs2svn to create branch
<barry> 'release20-maint'.
<jam> barry: so can you do "svn co -r 18549 $SVN/python/branches/release20-maint"
<jam> ?
<barry> yep
<lifeless> moin
<jam> barry: and is there a Lib/idlelib in there?
<jam> morning lifeless
<jelmer> barry, hi
<barry> jam: nope
<jelmer> barry, that's caused by a bug in 0.4 that's now fixed :-/
<jam> jelmer: so is it the old mappings causing the problem?
<jam> he's using 0.5.0
<barry> jam: yeah
<jelmer> jam: Well, sortof
<jelmer> jam: An import using the new mappings would of course never cause problems since there's no older interpretation you could conflict with
<barry> jam: otp w/thumper
<jelmer> barry, This is importing into an empty bzr repository ?
<jam> jelmer: that is what he said earlier
<jam> on a machine that didn't do the earlier import
<jam> so it wouldn't have anything cached
<jelmer> oh, hmm
<jelmer> couldn't be the different interpretation then
<jelmer> barry, and this is the python repo?
<jam> jelmer: yes
<jam> svn.python.org/python/ IIRC
<lifeless> bug 334326
<ubottu> Launchpad bug 334326 in bzr "Creating working tree for OOo takes ages" [Undecided,Invalid] https://launchpad.net/bugs/334326
<lifeless> jelmer: ^ why invalid?
<jelmer> jam: I'll give that a try
<jelmer> lifeless, crap I closed the wrong one
<jelmer> lifeless, the "bzr st" one is invalid
<jelmer> lifeless, fixed
<jelmer> jam: btw, do the tests for InterBranch look ok ?
<barry> jelmer: it is importing into an empty bzr repository
<jelmer> barry, I'm trying to reproduce it
<jam> jelmer: http://svn.python.org/projects/python/trunk is the trunk branch
<jam> I had the wrong url
<jelmer> barry, whereabouts does it fail?
<barry> jelmer: time bzr svn-import --incremental /data/repos/projects/ experiment
<barry> jelmer: bzr: ERROR: parent_id {18549@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease20-maint:Lib%2Fidlelib} not in inventory
<calc> is there any way to have a partial repo checkout like what is normal with cvs and svn?
<calc> eg i want to have dirs a/b a/c a/d and be able to just checkout a/b
<jam> calc: in general, checkout granularity is at the *branch* level, so you can checkout less than a whole repository, but not less than a whole branch
<lifeless> calc: its intended but not implemented
<barry> jelmer, jam would it make sense to switch to updating only the handful of branches i really care about (for now)?
<jam> barry: it may save *you* some time :)
<jam> jelmer: I just sent in a review
<jam> I'll also comment that some of this may conflict with stuff like RemoteBranch and streaming code.
<jam> otherwise it seems ok
<calc> lifeless: ok
<calc> hmm well this will create a bit of a mess in my lp repo
<calc> i'll have something like 15 branches per release now :-\
<barry> jam: ;)  what's the best way to do that. not svn-import i'm guessing.
 * calc wonders if he can add more to the lp bzr path eg sub repo's
<jam> barry: for the *first* time 'bzr branch svn...' for later times 'cd XXX; bzr pull'
<jam> afaik
<jam> another alternative is to use a 'custom' layout
<jam> which defines just the branches you want to convert
<jam> let me see if I can come up with that quickly
<barry> jam: ah yes!  duh.  i can just bzr pull in the directories we already have
<jelmer> jam: Thanks
<jelmer> barry: Hopefully I'll have a fix more the main issue in a few minutes
<barry> jelmer: ok, cool.  any chance of a ppa? :)
<jam> barry: something like: http://paste.ubuntu.com/123015/
<jelmer> barry: For which Ubuntu release?
<barry> jelmer: debian lenny :)  but so far hardy has been working for bzr/bzrtools
<jam> Hardy, I believe
<barry> jam: is that hex string an example, or specifically what i should use?  i have no idea what that means
<jelmer> I'm trying hard to stay away from being the maintainer of various things in PPA, as there's plenty packages I have to worry about as is
<barry> jam: and that goes in subversion.conf, right?
<jam> barry: the hex string is specifically what you should use
<jam> barry: it is the UUID for your svn repository
<jam> (I took it from the error message you gave)
<barry> jam: gotcha
<barry> jam: thanks
 * barry tries
<jam> I don't know if "projects" is in there or not, as I don't know where your svn root is
<jam> but it *looks* like that may be correct
<barry> jam: projects is the root of the filesystem repo, but i don't believe it's in the urls
<jam> jelmer: do you have debian lenny packages then? I know you do the "debian/experimental" stuff
<jelmer> jam: I've been looking at providing backports for lenny
<jelmer> jam, Also so they can be used on alioth
<jelmer> since the bzr 1.5 smart server (which is in lenny) is kinda slow
<lifeless> jelmer: have you tried push with .dev to .dev this week ?
<jelmer> lifeless: "No revisions to pull." :-P
<lifeless> 'push'
<jelmer> oh, right (-:
<jelmer> lifeless, what do you mean exactly?
<barry> jam: the paths in branches: are those svn paths or bzr paths?
<jam> barry: svn paths
<barry> jam: cool, thanks
<jam> jelmer: he wants you to test the latest streaming code in bzr.dev
<jelmer> jam: ah
<jam> which has a couple new smart verbs, etc
<jelmer> lifeless, no, I haven't tried that yet
<lifeless> jelmer: I sent a mail to the list
<jelmer> problem is I don't control most of the bzr smart servers I connect to
<igc> jam: fyi, lifeless had tweaked his groupcompress branch: http://bazaar.launchpad.net/~lifeless/+junk/bzr-groupcompress/revision/29
<lifeless> jelmer: andrew and I have landed streaming push etc
<jelmer> lifeless, Yeah, I saw some interesting things fly by
<igc> jam: the second part of that is missing from your branch - don't know how much it matters
<lifeless> jelmer: and you can use a homedir checkout on the server
<igc> morning all
<lifeless> jelmer: its all in my mail :)
<lifeless> h igc
<igc> morning jelmer, lifeless
<jelmer> lifeless: ah, neat
<jelmer> lifeless, is there a plugin yet for installing a new bzr on a remote server ? :-P
<lifeless> bzr-copy-server?
<jam> lifeless: I don't know if you noticed, but I created a bzr-groupcompress project, so there should be a shared location we can work on it.
<lifeless> jam: cool, I hadn't
<jam> igc: I think my 'experimental' branch did
<jam> lp:///~jameinel/bzr-groupcompress/experimental
<jam> I need to put that back in 'trunk'
<jam> since we have --development5 now
<Peng_> Is there any reason to use "lp:///foo" instead of "lp:foo"?
<domas> more slashes
<jam> Peng_: technically you can use lp://dev/foo
<domas> looks like URI, too
<jam> and some other lp special names
<Peng_> Cool, "lp://///foo" works. :P
<jam> lp:/foo doesn't :)
<Peng_> Aww.
<igc> jam: ah, ok. I guess I should stick with testing/using the main branch though, shouldn't I?
<jam> lp:foo == lp:///foo == lp://edge/
<jam> igc: I would stick to using "lp:bzr-groupcompress"
<jam> I'll probably land my stuff there now
<jam> since you need it for d5 anyway
<Peng_> Why does it still use edge? Just because of the redirect for testers?
<jam> Peng_: not sure, something to do with how the xmlrpc code is set up
<Peng_> Yeah, I think it's that xmlrpc doesn't like the redirect.
<jam> I know that *used* to be the case
<jam> not sure if it is still true
<jam> igc: I just pushed up my latest
<igc> jam: thanks
<jam> igc: I'll mention that the only "hack" I need to make conversions fast is the xml8.py change
<jam> And I can convert mysql 525 in 1m45s
<jam> (bzr branch mysql-5.1 -r 525, which is 1063 revs)
<igc> jam: so which gc format should I be testing? gc-plain-chk?
<jam> If I was picking one, 'gc-plain-chk255'
<jam> not sure if that is the pure winner
<jam> but it is my best choice right now
<igc> jam: sure. I guess my goal is to tell you the answer :-)
<igc> but I want one to work firstly :-)
<jam> igc: oh, and I should mention that I think GC+CHK repositories don't autopack right now
<jam> They may not even "bzr pack"
<jam> I need to work on that
<igc> jam: please
<igc> lack of autopack will certainly distort benchmarks
<jelmer> dev5-subtree is not GC, right?
<jam> igc,lifeless: so I'm thinking that for a first-cut, to go ahead and have 'autopack' fully rebuild the groups
<jam> jelmer: correct
<lifeless> jam: sure
<jam> basically, just stream the expected revs in "gc-optimal" order
<jam> and shove them into the target
<lifeless> jam: well, calculate pack count, and for the ones to redo, do tht
<jam> lifeless: right
<jam> not the whole repo
<thumper> why is bzr lying to me?
<thumper> Source format does not support stacking, using format: '1.6'
<thumper> bzr info -v tells me it is branch format 7 and packs 5
<thumper> which AFAIK --1.6
<jam> thumper: I bet you upgraded the repo and not the branch. Also, are you checking the *target* or the *source* ?
<thumper> the branch is branch format 7
<thumper> and it is the source
<thumper> the target is lp
<thumper> a new branch
<thumper> the command appeared to work
<thumper> but it is telling me it is in the wrong format when it isn't
 * thumper wishes there was a `bzr info --format` that just showed the formats
<lifeless> bug 334114
<ubottu> Launchpad bug 334114 in bzr "Bazaar tells me my source branch format doesn't support stacking, even though it does." [Undecided,New] https://launchpad.net/bugs/334114
<thumper> lifeless: thanks
 * thumper me tooed
<Peng_> bzr info -v is reasonably fast now, so it can work.
<jelmer> thumper: is there an easy way in lp to sort by how many people have me tooed?
<jelmer> maybe an "AOL" button ? :-P
<thumper> jelmer: no idea
<jelmer> thumper, found it: https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-users_affected_count&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<barry> jam: i'm catching up on the bzr thread now.  that "12 minute" branch time; was that using bzr 1.5, 1.6 or something else, and was that from c.p.o, lp.net or someplace else?
<jam> barry: so testing from people.ubuntu.org/~jameinel/python/trunk
<barry> jam: also, when do you think the --stacked fix will hit bzr.dev?
<jam> a full "bzr branch" took 16m40s
<barry> jam: bzr version?
<jam> a 'best case' 'bzr branch --stacked' took 3m30s
<jam> barry: bzr.dev
<jam> (with patches)
<jam> barry: pqm is finishing up running the tests now
<jam> so... 5 min ?
<barry> jam: wow!  that's impressive.  do i get all my wishes fulfilled so easily? :)
<jam> I think 3m40s with the patch over bzr+ssh. versus 6m50s over http
<jam> plain http
<jam> I think you could get 3m40s there if you had a smart server running
<jam> because it seems to be the http Range request issues
<lifeless> does anyone know why we intercept failing hooks?
<lifeless> it make it really hard to see whats going on
<barry> jam: can you sanity check: https://pastebin.canonical.com/14265
<jam> barry: the patch has landed.
<barry> jam: excellent!
<jam> any chance you could try' bzr branch --stacked' and see how it compares with your 8min ?
<barry> jam: yep.  'course my router sucks :)
<jam> barry: well do whatever you did to get around the router earlier
<barry> jam: basically, it's yank my internet connection.  my wife's about to go out for a bit, so i'll do it then.  i like being married :)
<poolie> hello barry
<barry> poolie: hi!
<barry> jam: that pastebin is my response to brett.  i wanna make sure i'm not telling fibs
<jam> barry: yeah, I haven't seen any fibs yet, but having your timing would be a real asset there
<barry> jam: cool.  i'll do that in a bit
<jam> barry: you may want to do timings against http://people.ubuntu.com/~jameinel/python/trunk and bzr+ssh://rookery.canonical.com/home/jameinel/public_html/python/trunk
<jam> just to see what adding a smart server would get you
<barry> jam: anything special i need to do on the client?
<barry> jam: other than --stacked
<jam> barry: I don't think so
<barry> jam: cool.
<lifeless> jam: if you wanted to finish tuesdays chat, I can do that
<jam> igc, lifeless: I just landed a few patches that make 'groupcompress' compatible with the new network streaming changes
<jam> igc: in the meantime, to get around autopack, you can branch to a new standalone branch
<jam> lifeless: I think for tonight, I'm just going to try to get gc autopack working
<jam> I think I'm close
<lifeless> ok cool
<igc> jam: I'm out of here for several hours real soon (so I'll wait till the autopack stuff is going)
<lifeless> spiv: that hook race condition fix is up for review
<lifeless> spiv: it also leads into setting the stacked branch during init so that will be a less round trip or so
<spiv> lifeless: just reviewed
<poolie> kfogel: thanks for the thoughtful comments on our release docs
<kfogel> poolie: you're welcome
<lifeless> spiv: so, I'm going to work on _real_repository in push
<maxb> Is there any documentation which explains "ghosts" ?
<kfogel> maxb: "ghosts"?
<fullermd> Well, usually they're just pockets of swamp gas...
<kfogel> "Rodents of Unusual Size?  I don't believe they exist."
<garyvdm> maxb has asked a good question.
<garyvdm> qbzr has code in it to deal with "ghosts: - which I don't understand, and don't know how to test.
<garyvdm> How do you end up with a ghost?
<fullermd> Ghosts are revisions that are referenced but not available.
<lifeless> jam: ping
<fullermd> The usual way AIUI is conversions, especially from arch.
<jam> lifeless: pong, though I'm going out the door now
<jam> autopack is now working
<lifeless> you added a bug, I need to ask you about it
<jam> and does a pretty good job
<fullermd> Stacked branches are sorta a special case of ghosts, but I'm not sure if they actually "look like" ghosts...
<lifeless> :!bzr diff -c 3871.4.4
<lifeless> jam: cool
<lifeless> bug 304841
<ubottu> Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix released] https://launchpad.net/bugs/304841
<garyvdm> fullermd: how can you create a branch that has a ghost to test that your code is ghost friendly?
<jam> sorry I can't talk more now
<lifeless> jam: ok, I'll just delete the offending line :)
<lifeless> jam: I think its bogus
<fullermd> garyvdm: No idea.  I think there's something in the bzr test suite that does it...
 * fullermd refers all questions that require actual knowledge to lifeless   :p
<lifeless> garyvdm: do a commit with a parent that is a ghost
<lifeless> garyvdm: one easy way is tree.set_parent_ids([tree.last_revision, 'blah blah blah']); tree.commit()
<lifeless> garyvdm: testing a ghost on mainline is a little more compelx
<garyvdm> lifeless - thanks
<garyvdm> fullermd, lifeless: I really need to work on qbzr testsuit.
 * igc out for a few hours - back later
<lifeless> pop quiz, moving _fetch_order and _fetch_uses_delta to RepositoryFormat ?
<james_w> erm, the ides of March?
<james_w> oh, wrong sort of quiz
#bzr 2009-02-26
<CaMason> hi guys. I'm trying to revert to a previous revision, but  I'm getting ERROR: [Error 2] The system cannot find the file specified
<CaMason> This is on Windows
<CaMason> which I figure is a problem with the case of the file
<lifeless> there should be a full backtrace in your bzr.log
<CaMason> I have a feeling my earlier experiment with cygwin was causing some conflicts
<thumper> abentley: ping
<thumper> abentley: I have a question about preview trees
<abentley> thumper: pong
<thumper> abentley: and getting dependent branches working with lp:mad
<lifeless> CaMason: well maybe; happy to help - pastebin the full exception as a starting point though
 * thumper drew a face for lp:mad last night
<thumper> abentley: I know you were working on that area of preview trees, but I don't know if it landed in trunk
<abentley> thumper: I'm pretty sure it did.  You can generate a preview tree from a preview tree, which is what you need to do.
<thumper> abentley: all the code is on lp now :)
<thumper> yay
<fallenpegasus> is tailor the current best practice for converting a hg project to bzr?  it seems pretty heavyweight
<lifeless> jelmer: I'm a little confused why you needed InterBranch to make update_revisions work right for you
<lifeless> jelmer: not that InterBranch is bad; it just seems like it doesn't add anything for bzr svn
<jelmer> lifeless: bzr-git can't return revno's for remote branches
<jelmer> lifeless, since git doesn't expose the revision graph
<jelmer> (not without fetching the actual revisions, anyway)
<jelmer> lifeless, for bzr-svn it's just a performance improvement, since calculating the revno for a remote svn revision is more expensive than calculating it for the revision once it's been fetched into the local bzr branch
<thumper> jelmer: has bzr-git been frozen for rev-ids?
<thumper> jelmer: we are looking to use it soon
<jelmer> thumper: yes
<jelmer> thumper: This was actually one of the requirements for actually making bzr-git work with a vanilla bzr
<jelmer> s/This/This patch/
<thumper> jelmer: cool
<thumper> jelmer: have you done a "release" of bzr-git?
<lifeless> jelmer: ah
<lifeless> thanks
<jelmer> thumper, no, was waiting for this patch to land :-)
<jelmer> thumper, I'll do one at around the same time as bzr 1.13
<thumper> jelmer: what patch does it need?
<thumper> jelmer: and will it be ready for next week?
<jelmer> thumper, the patch it needs landed 5 minutes ago :-)
<thumper> jelmer: cool, so bzr-git needs bzr 1.13?
<jelmer> thumper, yep
<thumper> what's the date for 1.13 rc?
<jelmer> thumper, Martin's original announcement said march 6, but I'm not sure if that's still true
<lifeless> thumper: got some sort of rush?
<thumper> lifeless: we are sprinting next week on integrating this into lp
<jelmer> thumper, I should point out that bzr-git isn't ready for imports of e.g. the linux kernel yet
<thumper> jelmer: what is it ready for?
<jml> bzr init-repo --1.9 --no-trees ~/repos/<proj>; bzr branch lp:<proj> ~/repos/<proj>/trunk; mkdir ~/src/<proj>; bzr co --lightweight ~/repos/<proj>/trunk ~/src/<proj>/trunk
<thumper> jelmer: and what are the limitations?
<jml> someone please write a computer program to do that for me.
<lifeless> jml: jamesh already did
<jelmer> thumper, it hasn't been optimized for performance
<jelmer> thumper, I've used it for moderately sized projects, e.g. couple of hundred revisions, couple of hundred files
<lifeless> does it round trip yet?
<lifeless> are there conversion logic bumps in the pipeline?
<jml> lifeless: what's it called?
<jelmer> lifeless: no, it doesn't roundtrip yet
<jml> lifeless: how can I use it?
<lifeless> jml: gnome-somethjing-or-other
<jelmer> lifeless, roundtripping is nontrivial
<lifeless> jelmer: I'm sure :P
<thumper> lifeless: that is something else I think
<jelmer> lifeless, in other words - yes, there are mapping bumps ahead
<thumper> jml: don't forget the additions to the locations config for cbranch :)
<lifeless> jelmer: I'm just alarmed that thumper might throw  it onto LP suddenly :P
<jml> thumper: I don't need to worry about that.
<thumper> jml: my thoughts would be a bzrtools command
<jml> thumper: I have some magic in my locations.conf that takes care of it.
<thumper> jml: I'd like your magic
<jml> thumper: http://paste.ubuntu.com/123098/
<thumper> lifeless: my push to LP to an existing stacked branch is borked
<thumper> lifeless: is this expected?
<thumper> lifeless: I'm using the bzr from the nightly ppa
<jml> thumper: the only thing I have to specify per-project is the submit branch
<lifeless> thumper: details
<thumper> lifeless: by borked I mean nothing output for over 8 minutes
<jml> thumper: one day, I'll figure out a way of getting bzr to default to ~/repos/<proj>/trunk
<lifeless> yes, its working fine
<lifeless> thumper: ^
<lifeless> thumper: just no progress bar
<thumper> lifeless: why is it taking so long?
<thumper> lifeless: it is one or two new revisions
<thumper> lifeless: to an existing stacked branch
<lifeless> thumper: well, depending on which nightly build you have
<lifeless> you may be running into one of a couple of bugs we found
<lifeless> where fixing X broke/regressed Y
<thumper> lifeless: should I kill it or just wait?
<lifeless> what revno is your bzr
<thumper> I have 1.13~bzr8.10-40041-1 installed
<lifeless> man, how to turn that into a revno
<thumper> sorry, 4041
<thumper> I think that is the revno isn't it?
<thumper> too many zeros
<lifeless> ok
<lifeless> in which case you're missing 4043
<lifeless> and it will take an hour
<thumper> that I am
<thumper> an hour?
<thumper> geez
<lifeless> una hora per favour
<thumper> should I care what it is doint?
<thumper> it isn't sending heaps of revisions is it?
<lifeless> no
<lifeless> or yes
<lifeless> depending on your point of view
<thumper> lifeless: man, you are so helpful
<lifeless> it was a bug, its fixed :)
<lifeless> how much more helpful do you want?
<thumper> lifeless: can you give me unlimited cosmic power?
<lifeless> thumper: sorry, no
 * fullermd can only dispense terrestrial power.
<lifeless> thumper: its not inserting unnecessary revisions into the brnach
<lifeless> thumper: its just calculating a bunch of stuf it doesn't need
<lifeless> so that it can avoid calculating something it does need :P
<garyvdm> Who can I ask questions relating to expected performance of graph methods?
<garyvdm> I'm looking at the profile data for a particular use case in qbzr
<garyvdm> In qlog
<garyvdm> The data is not what I expected.
<garyvdm> I've looking at a branch that has a pending merge.
<lifeless> me, john, the list are all good candidates
<lifeless> aaron too
<garyvdm> qlog uses graph.find_unique_ancestors to figure out which revisions are part of the pending merge, and which are part of the rest of the branch.
<garyvdm> The cost of graph.find_unique_ancestors is higher than the cost of graph.iter_ancestry
<garyvdm> Lifeless: is that normal
<lifeless> doesn't sound normal, but it could be a bug :P
<lifeless> bzr st got changed to not show a similar thing, I don't recall if someone looked into the cost of the calculation, or not
<garyvdm> Ok - I'll investigate.
<mtaylor> lifeless: bzr-hg?
<mtaylor> lifeless: AttributeError: 'HgBzrDirFormat' object has no attribute '_workingtree_format'
<lifeless> mtaylor: doing a selftest?
<mtaylor> lifeless: a friend is trying to migrate some stuff from hg to bzr
<mtaylor> lifeless: is there a better way than cd ~/.bazaar/plugins ; bzr branch lp:bzr-hg bzr_hg ?
<lifeless> fast-export is probably the best route at the moment
<lifeless> jelmer is doing bzr-hg dev at the moemnt
<mtaylor> is fast-export written up somewhere sensible?
<lifeless> jelmer: btw, I asked before, but why isn't your stuff in the trunk of bzr-hg and bzr-git ?
<lifeless> mtaylor: http://bazaar-vcs.org/BzrFastImport
<mtaylor> lifeless: rock. thakns!
<lifeless> spiv: you've been very quiet today
<jam> lifeless: for the bug you brought up earlier. I think your new fetch cycle wil have fixed it, but there definitely was a bug there in the past
<spiv> lifeless: yeah.  I spent more time looking at/writing up my xfce thoughts than I expected.
<spiv> lifeless: it just occurred to me, btw, that I do in a sense have two unfinished branches lying around
<spiv> lifeless: smart protocol traffic reporting, and /~/ support for bzr+ssh
<lifeless> jam: I don't deny the bug :) in fact I checked carefully that it wouldn't regress
<lifeless> jam: which was easy as you wrote a test for it :>
<lifeless> jam: there is a merge request up for a patch rolling back just part of the changes you ade
<lifeless> *made*
<jelmer> lifeless, I'm not sure why it's not in the trunk :-)
<lifeless> jelmer: push man, push
<jelmer> lifeless, I guess it's mainly that I'm not used to pushing to launchpad and the trunks are in launchpad
<fullermd> Oh, jeez.  I'd given up hoping for bzr+ssh:/~/
<jelmer> time to fix the bzr-jelmer plugin :-P
<lifeless> jelmer: please do push them; lp isn't evil. Honestly.
<jam> lifeless: your patch had no revisions, BB:resubmit
<lifeless> jam: grah
<jam> there *was* a bundle there, but it was empty
<jam> I assume you forgot a submit branch/ used the local branch
<lifeless> jam: I did branch dev new; merge -r y..x .; commit; send
<lifeless> the merge changed the submit branch :(
<spiv> lifeless: also, I think we should add some more remember_remote_is_before((1, 13)) in remote.py, and corresponding if _is_remote_before guards to skip straight to fallbacks, for the sake of minimising impact when talking to older servers.
<lifeless> jam: -> list
<lifeless> spiv: I think that makes sense, I'd like to put that on the 'after protocol freeze' list
<lifeless> spiv: ack on the two branches
<spiv> lifeless: agreed about 'after freeze'
<lifeless> the smart protocol traffic reporting - why didn't that land again ?
<spiv> I think it should probably borrow vila's work for http traffic reporting, but I didn't make time to look closely enough in time for the release.
<spiv> IIRC, he decorates the underlying socket object with a traffic reporter, which sounds like it would work well for smart media too.
<lifeless> indeed
<spiv> Oh, and I suspect that if my patch landed as is with vila's patch already integrated, then smart http traffic would probably have been reported twice...
<spiv> We didn't need to make hpss look even worse than reality! ;)
<lifeless> very true
<jam> spiv: far from it, it would look like you were getting amazing download speeds
<lifeless> I've nearly finished find repository v3
<lifeless> which will ensure that we always have a network name
<spiv> jam: yeah, but then the release that fixes the bug would look like it was half the speed ;)
<lifeless> allowing PackToRemote to check compatibility without _ensure_real
<spiv> Hooray
<lifeless> that + moving fetch_order and uses_deletas to format
<lifeless> will avoid real repo at all for push I *think*
<lifeless> the patch jam is looking at is a prereq for that stack of changes
<jam> lifeless: so I don't think you fix is 'complete' just from the bugs I noticed in the code
<jam> lifeless: the issue is when 'buffered=True'
<jam> the code has
<jam> if not buffered: self.index.add_records()
<jam> however later on it unilaterally does
<jam> added_keys = [record.key]
<jam> while added_keys:
<jam>   ...
<jam> which assumes that it successfully added the key
<jam> and anything that depends on it can be added
<jam> Look at the last example: https://bugs.edge.launchpad.net/bzr/+bug/304841/comments/5
<ubottu> Ubuntu bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix released]
<jam> In case that helps
<jam> If we get 'E' before 'D', then E gets buffered, when D comes in, we still haven't seen 'C', but since D shows up, we think we can insert E
<lifeless> jam: thats deliberate
<jam> lifeless: It is deliberate to record the entry "E" even though you would fail to extract it?
<lifeless> jam: yes
<jam> I don't understand
<lifeless> jam: there are comments about this, but let me try explaining
<jam> Given that you intentionally don't record *D*
<lifeless> there are two index implementations
<lifeless> Kndx and Pack
<jam>             # Add any records whose basis parent is now available.
<jam> I see that, but that isn't really enough info
<lifeless> so there are two loops
<lifeless> there is a loop over the stream
<lifeless> and the logic in there is 'if the compression parent is available just add it'
<lifeless> if its not, buffer it
<lifeless> if its buffered its not in the index and its children (and their children etc) will also be buffered
<jam> lifeless: except the children that *were* buffered
<jam> get inserted *at that time*
<jam> *when* the entry is buffered
<lifeless> jam: huh
<jam> The 'added_keys = [record.key]" is *outside* the 'if not buffered" check
<lifeless> oh, you are suggesting we need a
<lifeless> if buffered:
<lifeless> at that point? That makes sense to me
<jam> lifeless: well, 'if not buffered', but yes
<jam> lifeless: and you need to move the 'buffered' variable higher in scope
<lifeless> yeah
<jam> so that all paths have ti
<lifeless> let me do that
<jam> it
<jam> I think with that
<jam> the fix is complete
<jam> I just did 'topological' because it was easier to 'get stuff working'
<lifeless> http://paste.ubuntu.com/123109/
<jam> and would hide any other bugs that were latent to get the release out
<jam> lifeless: seems fine, you could reduce the indenting slightly by just setting 'added_keys = []', but I would approve that patch
<lifeless> so this wouldn't affect pack repositories at all
<lifeless> only .knit
<jam> no, it effects packs
<jam> when stacked
<lifeless> but its good not to break them :)
<jam> and getting 'unordered' streams
<jam> well, assuming you don't actually get the complete stream
<lifeless> how does it affect packs?
<lifeless> if you don't get the complete stream, thats an issue :)
<jam> ... I guess you mean the index won't become visible?
<jam> if all the gaps weren't filled in?
<lifeless> yes, it will fail atomically
<jam> lifeless: It *did* trigger bugs with stacking
<jam> because of trying to extract a fulltext
<jam> but the delta-chain wasn't complete
<jam> I *think* that code is fixed
<lifeless> ah, with an adapter
<jam> by properly looking at 'compression_parent'
<jam> rather than missing(parents)
<lifeless> ok, if you're happy I'll commit this and push to pqm
<jam> lifeless: go ahead
<lifeless> thanks
<jam> lifeless: so i'm still a little concerned that stacking + 'unordered' fetching will cause problems with trying to expand texts, but perhaps with your new two-pass logic it will be ok
<lifeless> we do topological for conversion push
<lifeless> so the reason we do expansion of texts with stacking was to get the delta closure in
<lifeless> jam: the two-pass logic should avoid that though with a newer server
<lifeless> it passes the acceptance test you wrote
<jam> lifeless: with the other fix, I can't think of a way to break it, but let me think about it for a bit
<jam> lifeless: it should be fine
<lifeless> jam: cool; if its not I'll fix it :)
<ia> hello. could you tell me, please, If i use latest version of bzr, which contains "push" bug (https://bugs.launchpad.net/bzr/+bug/295350), then does exist some way to push branches in such version of bzr?
<ubottu> Ubuntu bug 295350 in bzr "Push fails with Revision {set([('null:',)])} not present in "KnitVersionedFiles" [Critical,Confirmed]
<lifeless> ia: are you encountering that bug ?
<lifeless> ia: because it was fixed in 1.10, just the report wasn't updated
<lifeless> (the log shows that it was fixed)
<lifeless> And I've updated the bug to record that
<jam> lifeless: it is occurring now with bzr.dev and rich-root repos
<jam> lifeless: I sent a bug report to the ML and spiv said he was going to look at it today
<ia> lifeless: hmmm, very intresting - i use bzr from "nightly builds" repo (latest version - 1.13dev) and I've just would like to push(from desktop) in my branch(to LP), but I've got error message. I've googled it and found the same bug at LP. So, now i'm here ) In those bug report you can find my comment - it's the last one.
<lifeless> ia: you definitely don't have that bug
<lifeless> ia: what package version do you have?
<ia> lifeless: 1.13dev
<lifeless> ia: 'dpkg -l bzr'
<lifeless> ia: will give the *package* version
<lifeless> jam: pushing to stacked rich root repos from plain repos?
<jam> lifeless:  "bzr init-repo --1.9-rich-root bzr+ssh://new-repo; cd ~/.bazaar/plugins/svn; bzr push bzr+ssh://new-repo/svn"
<ia> lifeless: 1.13~bzr8.10-4
<jam> lifeless: no stacking
<lifeless> ia: thats not the full version string
<lifeless> ia: please show the full version string
<ia> lifeless: 1.13~bzr8.10-4041-1
<lifeless> thank you :)
<chx> oh 1.13 already??
<chx> i thought 1.12 just got out
<lifeless> chx: we're working on 1.13 at the moment
<chx> ah ok
<ia> lifeless: sorry - i just didn't get it instantly :-)
<jam> chx: there is a ppa with nightly builds
<lifeless> ia: I think you're suffering bug 334187
<ubottu> Launchpad bug 334187 in bzr "RemoteBranch.revision_history broken when stacking" [Undecided,Fix committed] https://launchpad.net/bugs/334187
<lifeless> ia: a fix is landing at th emoment
<lifeless> ia: the symptoms look similar, but they are quite different bugs; in future I suggest that you file a new bug rather than commenting on an existing one, unless you've dug into the code and checked the entire backtrace is identical
<lifeless> ia: alternatively, you may be suffering a new bug we haven't seen yet, or possibly the issue jam is reporting with rich root branches
<lifeless> ia: can you please do 'bzr info -v' in your branch that you're having trouble pushing
<lifeless> jam: is there a bug for this?
<jam> lifeless: not yet, I started on the mailing list to bring up discusion
<lifeless> ia: can you please do 'bzr info -v' in your branch that you're having trouble pushing
<ia> lifeless: oh, thanks for advice about bugreporting. And you're right - problem not in bzr, but in branch; i've just tested "push" with another branch - it works fine. And here bzr info -v : http://paste.ubuntu.com/123114/ - it's a branch of bzr-gtk, which I would like to upload (with tiny changes) to my branch at LP.
<lifeless> ia: is it a new branch?
<lifeless> ia: ok, when you push a new branch to launchpad it tries to stack;
<lifeless> ia: thats what this bug is about; you'll need a new build to fix the bug
<ia> lifeless: well, i've registred branch at LP, made "bzr branch lp:bzr-gtk", made changes, commited it, and now when I run "bzr push lp:~iaz/bzr-gtk/cosmetic" i get error - http://paste.ubuntu.com/123119/
<lifeless> ia: or, if you have a copy of bzr.dev yourself, you can just update from it
<lifeless> and then use that copy to push
<lifeless> ia: can you look in ~/.bzr.log
<lifeless> ia: there should be a full backtrace; if you could pastebin that that would be good
<ia> lifeless: I guess, that this - http://paste.ubuntu.com/123120/ - log for last try of "push"
<lifeless> jam: does http://paste.ubuntu.com/123120/ match what you're seeing
<lifeless> ia: thats intersting, and new
<lifeless> ia: please install a 1.12 full release
<lifeless> ia: I'll file a new bug for this problem you're seeing
<jam> lifeless: yes
<jam> iter_lines_added_or_present_in_keys triggering a problem with ('null:',)
<lifeless> jam: that looks like a bug in the what-to-copy logic to me
<lifeless> spiv: are you looking at this?
<ia> lifeless: eeem, what, i've clashed with some new unknown problem? )
<jam> lifeless: judging by the backtrace, I would guess somehow NULL_REVISION snuck into the 'revisions' field of the 'data_to_fetch'
<lifeless> ia: yes, you've found a new bug
<lifeless> jam: yes, thats what I'm thinking
<spiv> lifeless: not right at the moment; I'm currently thinking it's time for lunch...
<lifeless> spiv: I'm guesing we're not pairing today :P
<spiv> lifeless: No :P
<spiv> lifeless: what can I say, I'm a (busy) slacker ;)
<spiv> We definitely should tomorrow though.
<ia> lifeless: ok. well, however, I will be very appreciate, that if you'll file new bug about this, you'll highlight me and send link to this bug. And thanks for response and help.
<lifeless> ia: already filed
<lifeless> ia: bug 334666
<ubottu> Launchpad bug 334666 in bzr "error pushing new bzr-gtk branch to launchpad" [High,Confirmed] https://launchpad.net/bugs/334666
<jam> lifeless: how fixed are you about inserting the 'label:' and 'sha1:' lines into the group compressed text
<jam> I just did a quick test removing them
<lifeless> jam: sha1: I'm not attached to at all
<jam> and the text sizes dropped from 621 kB compressed down to 482kB
<jam> or ~30% overhead from those 2 lines
<lifeless> label: we have to store somewhere
<jam> lifeless: sure, atm we store it in the index
<lifeless> I'll mull on this
<jam> I can understand wanting it in the text
<jam> I haven't finished a conversion with a bigger repo
<pasc> i/wi1
<pasc> gah
<jam> lifeless: so texts for bzrtools in 1.9 == 1.2MB, in GC .6MB, with label & sha1 stripped .48MB
<lifeless> jam: hmm _find_modes is a round trip on just opening a RemoteRepository
<jam> lifeless: arguably it should be returned as part of BzrDir.open()...
<lifeless> jam: or deferred until a write is desired
<jam> either way
<jam> the former means you don't have an extra round trip when you *do* want to write
<lifeless> the latter means you don't have an extra round trip at all for pull
<lifeless> and its the same as the former when you do write
<lifeless> (because, mode probing is a stat that bzrdir.open doesn't do)
<abpend> Anyone here?
<lifeless> abpend: generally, just ask your question
<abpend> Alright, then.  Does anyone know if any work is being done on getting nested tree support into bzr?
<abpend> Googling around, it looks like there are periodic discussions every year or two, but I'm not sure if that's just talk or indicative of something actually happening.
<lifeless> spiv: new merge request up
<lifeless> abpend: I believe abentley will be focusing on it soon
<abpend> lifeless: good to know.  We've just started using bzr at work, and that'd be a much-appreciated feature.
<spiv> lifeless: I'll take a look
<thumper> abpend: can you say which work?
<abpend> thumper: I work for a small web development firm in Washington, DC called Community IT Innovators... so far, it's just one development group, and we're just giving it a go, but so far, we've been pretty impressed.  Everybody else is still using CVS.
<thumper> abpend: I think you'll like it
<thumper> abpend: I came primarly from svn (and other biggies like perforce and clear case)
<lifeless> jam: interesting commit there
<lifeless> spiv: just shout if you want to chat about causes there
<jam> lifeless: too sleepy to continue, but yeah, I'm curious where it will get to
<spiv> lifeless: I don't actually see where in the patch the server will send the network_name?
<lifeless> spiv: very interesting... neither do I :P
<lifeless> spiv: let me, uhm, fix
<spiv> lifeless: :)
<spiv> lifeless: the change to transport/remote.py looks reasonable, but I'm curious about what prompted it
<lifeless> the client wasn't preserved
<lifeless> so the stub test ended up trying to do a real op
<spiv> Interesting that nothing else had bumped into that issue before this...
<lifeless> I think this is the first deliberately recording a real_repo invocation
<spiv> Oh, right, I just noticed that.
<spiv> Makes sense.
<lifeless> spiv: yeah tests breaking all over.
<lifeless> update coming
<spiv> lifeless: :)
<lifeless> ERROR: bzrdir_implementations.test_bzrdir.TestBzrDir.test_sprout_bzrdir_repository(RemoteBzrDirFormat-v2)
<lifeless>     Received bad protocol version marker: '\n'
<lifeless> spiv: *hate* that
<spiv> Hmm.
<lifeless> spiv: we can make a findV3 request on the old protocol, but can't answer it
<spiv> Perhaps the v2 (and v1) encoder should check for \n in args, and raise a better exception?
<lifeless> spiv: I'd like it to be unknown method on a v2 or before stream :(
<lifeless>   File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/medium.py", line 202, in serve
<lifeless>     server_protocol = self._build_protocol()
<lifeless> spiv: where would be a good place to put this chceck
<spiv> Ah, in the response.  Tricksy.
<spiv> Yeah, it would be good to have it unknown in earlier protocol versions.  At the moment the client is responsible for not trying new verbs on old protocols via _is_remote_before
<lifeless> spiv: so I can do it two ways
<lifeless> a min_version=3 on the register side
<lifeless> or in the dispatch or something like that
<lifeless> or a heuristic in the response encoder
<lifeless> I prefer the former (avoids having work done then error late; which would suck for mutating methods)
<spiv> I'm not sure what you have in mind for a heuristic in the response encoder, but it doesn't sound like a good idea to either.
<spiv> So, there's a commands registry in request.py
<spiv> Currently that registry is always passed into the SmartServerRequestHandler
<lifeless> the heuristic would be \n in the args :P
<spiv> Which is kicked off via _get_protocol_factory_for_bytes
<spiv> Ugh, yeah, let's not do that :P
<lifeless> hey, you proposed it ;)
<spiv> I thought we were talking client-side :P
<spiv> _get_protocol_factory_for_bytes already dispatches to different factories depending on protocol version (that's what it's for)
<lifeless> spiv: ok
<lifeless> so we could make it active on the request
<spiv> e.g. b/s/protocol's build_server_protocol_three passes in commands=request.request_handlers
<lifeless> or passive
<lifeless> or in the registry
<spiv> So we could make those not all pass the same request_handlers
<lifeless> I think a passive attribute on the request is enough
<lifeless> None = any
<lifeless> 1/2/3 is a minimum
<spiv> (Also, it would be good if there were a way to vary the request_handlers by server instance, rather than having those factories hard-coded to use the global request_handlers)
<spiv> That seems reasonable.  Just an extra arg on the registration API.
<spiv> You don't need to do all this to solve your immediate problem, though...
<spiv> You could just do the _is_remote_before check in open_repo_v3, and if it fails raise UnknownSmartMethod without even touching the network.
<spiv> I don't mind if you want to fix this now, though.
<lifeless> it will fail to work
<lifeless> if the remote version isn't established
<lifeless> and that needs a known-higher not a known-lower
<spiv> No, it will work.
<spiv> Because if the protocol is v2 then _remember_remote_is_before((1,6)) has already been called on the medium for you.
<lifeless> ah
<spiv> So _is_remote_before((1,13)) will be False
<spiv> Other things already rely on this :)
<lifeless> ok, I'll do that
<lifeless> spiv: any insight on the push null: issue?
<lifeless> spiv: ok the next giltch
<lifeless> spiv: RemoteBranch(...real_branch) is triggering the assert real_repository is already set
<lifeless> ok, seems good
<lifeless> spiv: I'll wrap this real_repository elimination up tomorrow
<lifeless> night all
<spiv> lifeless: g'night
<spiv> lifeless: regarding the push null: issue, for some reason the searcher from _walk_to_common_revisions is including null: in its result
<spiv> And nothing after that point filters it out.
<spiv> I don't quite get why it only happens on some pushes to new branches, rather than all.
<lifeless> spiv: stacked branches shouldn't reach null: though
<lifeless> spiv: perhaps, its *non* stacked new branches with old servers?
<spiv> lifeless: I've got a reproduction with a non-stacked branch, current server
<spiv> Possibly due to a non-lefthand null: parent in the history.
<spiv> pushing bzr-svn -r100 reproduces it.
<lifeless> that would make sense
<spiv> If I add parents_of_found.discard(revision.NULL_REVISION) to _do_query in the searcher, it works.
<spiv> I also bumped into a trivial bug in the insert_stream server code; if the stream is empty, the thread is never started, so self.insert_ok is never set.  That causes some mess in the .bzr.log.
<spiv> (and of course we try empty streams fairly often atm ;)
<lifeless> spiv: ah! I saw that once but had no reproduction
<lifeless> spiv: null: is legitimate in the core graph code
<lifeless> I suggest post-filtering
 * spiv nods
<poolie> spiv, lifeless, i've just hit that too
<poolie> i think this is bug 3217654
<ubottu> Error: Launchpad bug 3217654 could not be found
<poolie> bug 317654
<ubottu> Launchpad bug 317654 in bzr "error about null revision not present pushing to server" [High,Confirmed] https://launchpad.net/bugs/317654
<lifeless> poolie: bug 334666 is definitely it :)
<ubottu> Launchpad bug 334666 in bzr "error pushing new bzr-gtk branch to launchpad" [High,Confirmed] https://launchpad.net/bugs/334666
<lifeless> poolie: because its the bug I filed to track it
<poolie> well, are they perhaps dupes?
<lifeless> possibly
<lifeless> I've said so in 317654
<lifeless> we know the cause for 334666
<vila> hi all
<poolie> hi vila
<jml> what's the bzr nightly ppa team?
<poolie> ~bzr-nightly-ppa :)
<jml> thanks.
<jml> (why isn't the fingerprint on the page any more)
<jml>   File "/home/jml/.bazaar/plugins/svn/branch.py", line 31, in <module>
<jml>     from bzrlib.branch import (
<jml> ImportError: cannot import name InterBranch
<jml> which bzr-svn should I be using with bzr nightly?
<lifeless> jml: an older one
<lifeless> jml: that landed today
<lifeless> jml: generally I'd say either use all packaged, or none-packaged, for bzr&plugins
<jml> lifeless: it's kind of scary that a day's lag can make such a difference
<lifeless> jml: jelmer added a dependency on a new feature in bzr
<lifeless> jml: I think its great that he did so so promptly
 * jml should have just made a checkout of bzr
<lifeless> jml: if you're running from a checkout of bzr-svn, definitely.
<jml> lifeless: well, the progress bar said it downloaded 900MB+ of data
<lifeless> poolie: are you sure its the same bug ?
<jml> lifeless: and it's not like I'll be doing dev on this machine, so a checkout would have been fine
<poolie> fairly sure
 * jml runs bzr svn-import --incremental svn+ssh://svn.twistedmatrix.com/svn/Twisted Twisted
<poolie> is there anything that indicates they're different?
<lifeless> poolie: well, its odd that its suddenly happening to everyone
<lifeless> poolie: its the same symptoms as a bug reported in 1.10 for isntance
<lifeless> which is what ia brought up
 * lifeless tends to be very cautious about dups
<lifeless> anyhow
<lifeless> I finished a hour back :P
<poolie> an inactive bug that might or might not be a dupe is not helping anyone
<lifeless> poolie: true, but I didn't suggest leaving it in active
<poolie> if we dupe it, and then later that guy comes back and says its not fixed at least we'll have more information
<jml> actually, you know what,
<jml> let's run that in a screen session
<lifeless> screen is a great invention
<poolie> i wish it allowed multiuser in ubuntu by defautl
<lifeless> spiv: btw if you're not finished, doing a review of my updated patch we were discussing earlier would be a great help to me as I start earlier than thee :)
<spiv> lifeless: yeah, I can do that.
<lifeless> spiv: cool. thanks
<lifeless> poolie: possibly bzr.dev has changed to tickle that bug
<poolie> maybe
<lifeless> or possibly none of us were pushing unstacked branches of bzr to lp
<lifeless> (which raises the question of why we're getting unstacked branches of bzr on lp)
<lifeless> [or if it does happen with stacked, then the data is definitely quite recent]
<vila> lifeless: bzrlib.tests.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss, when run in bbc, alwats reports 0 autopack calls (and fails for dev5, but that's another point)
<lifeless> vila: its failing?
<lifeless> vila: oh, I know why
<vila> lifeless: I thought you may be interested as it may mean PackRepository.autopack is not covered anymore
<lifeless> vila: its PackToRemote
<lifeless> which is on the cards to delete
<lifeless> ignore that for now, though if you want to fix it you _might_ find that extending PackToRemote to match bbc formats works
<vila> lifeless: I'm tracking progress in bzr.dev, so if it's going to be fixed, I'll go fix another failing test :)
<lifeless> vila: its on the slate to be fixed, yes
<lifeless> need to delete that class which requires a generic 'sync your state with the remote server' method
<vila> lifeless: ok, then the first remark still stands, is it expected that PackRepository.autopack is not called anymore ?
<lifeless> vila: expected? no
<lifeless> I doubt its a recent reression though, due to where it was gooked in
<lifeless> *hooked* in
<vila> lifeless: Well, under its previous incarnation (with a slightly different name, PackRepository.autopack *was* called, even if not for dev5
<lifeless> vila: oh sorry misread your question
<lifeless> yes, autopack is never called on current servers
<lifeless> they don't need it
<vila> by 'current' you mean they only used it after 1.12 but not in bzr.dev anymore ?
<lifeless> bzr.dev->bzr.dev uses insert_record_stream
<lifeless> bzr.dev->0.>whateveraddedautopack< uses autopack
<vila> lifeless: ok
<lifeless>  because insert_record_stream does the write group in the servers context a round trip for autopacking isn't needed - the remote instance iwll have locally autopacked if needed
<vila> mthaddon, spm, herb: PQM struck again by the rare-enough-to-let-you-think-it-s-finally-fixed-that-time bug :-/ Help ? Please ?
<LarstiQ> vila: ai
<vila> LarstiQ: Hey !
<LarstiQ> vila: heya :)
<LarstiQ> vila: are you the only one triggering that pqm bug?
<vila> LarstiQ: It seems so :-) Evidence points to me using lp: URLs
<vila> But it happens once in ~20 submissions, sometimes several times a week, sometimes not during a month...
<LarstiQ> irritating
<lifeless> vila: there is a patch
<lifeless> vila: I think it needs review
<vila> lifeless: ??? Against bzr ? pqm ?
<lifeless> pqm I think, possibly bzr-email
<LarstiQ> jelmer: is there a better way to check if rebasing didn't do any weird things (the conflicts surprised me) other than "for i in $(seq a b); do bzr diff -c $i > left.$i.diff; done" for left and right and comparing the diffs?
<vila> lifeless: ok, thanks, I'll research that
<igc> night all
<vila> igc: night Ian
<lampliter> I think I see what I need to do but I could use confirmation.  What I think I need to do is found in section 6.2 .5 of the user documentation.  What I'm doing is I have branch A committed to launch pad and I want to merge those changes into branch B.
<lampliter>  I suspect I need to pull the changes from launch pad and merge if there are any differences then commit the conflicts that are fixed
<lampliter> I'll also think I might need to push branch a before I do anything
<lampliter> interesting.  It looks like the documentation is off because the pull seemed to merge
<LarstiQ> lampliter: excuse me?
<Stanlin> help
<Stanlin> what is the zend channel in freenode ?
<Stanlin1> whos bazaar for windows developer?
<barry> jelmer: ping
<jsled> howdy.  We have a centralized/distributed repo; there's the shared central repo, but individual devs also have local (pristine and dirty) branches.  Our build just moved (bzr tag --force â¦) a release tag, and now devs are seeing "Conflicting tags: Â«moved tag nameÂ»" on pulls, and neither a pull nor a merge is "correcting" things.
<jsled> Is our only recourse `bzr pull --overwrite`?
<LarstiQ> no.
 * LarstiQ looks at tags
<ronny> yo LarstiQ
<ronny> sup?
<LarstiQ> hey ronny
<LarstiQ> ronny: doing some rebase dancing on stuff that needs to go back into svn, sigh.
<LarstiQ> ronny: but otherwise good :)
<LarstiQ> ronny: you?
<ronny> LarstiQ: lacking time and sanity
<ronny> hacking on gtk things recently
<LarstiQ> ronny: what kind of gtk things?
<ronny> trying to put together a lib that supplies pygtk with developer oriented debugging things
<ronny> like ui tracebacks, debugging consoles in widgets
<LarstiQ> nice
<ronny> LarstiQ: http://picasaweb.google.com/ronny.pfannschmidt/Pida#5305371513427638034
<ronny> oh, i just noticed i shouldnt leave the captions in ;P
<LarstiQ> jsled: hmmm, I can't find anything else
<LarstiQ> jsled: (well, handling .bzr/branch/tags manually, but eh)
<LarstiQ> jsled: there is bzrlib.tag.BasicTags._reconcile_tags(), but it is only used in the overwrite case
<LarstiQ> ronny: that seems to suggest clicking on the backtrace will do stack walking?
<jsled> LarstiQ: okay, thanks.
<ronny> LarstiQ: next step is opening a console window within the stack frame on double click
<ronny> i want to reuse soething else, but i have to wait for an ok to go lgpl instead of gpl
<vila> mthaddon, spm, herb: PQM struck again by the rare-enough-to-let-you-think-it-s-finally-fixed-that-time bug :-/ Help ? Please ?
<herb> vila: checking on it.
<vila> herb: thanks
<herb> vila: should be good to go.
<vila> herb: yup, great, thanks
<jam> morning barry
<barry> jam: hi.  will you be around in about 1h15 ?  i have some additional questions for you, but i have some meetings coming up
<jam> barry: sure
<jam> morning vila
<vila> morning jam :)
<jam> vila: so am I right that brisbane-core now passes all tests except the autopack/streaming one?
<jam> I think we can just change the "is_compatible" check
<jam> to remove the "supports
<jam> if not 'supports_chk'
<vila> jam: not quite, I have still some failures due to known bugs (at least one specific to 64 bits)
<jam> vila: I'm pretty sure my last run had exactly 5 failures
<jam> though that is --no-plugins, etc
<vila> jam: regarding bzrlib.tests.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss, I talked with lifeless this morning and he said he will fix some related problem, so we can wait for bzr.dev
<vila> jam: re-running (I should somehow archive my last runs somewhere :)
<jam> vila: yeah, I read through that. I still think we can just get rid of the 'not fmt.supports_chks' and have it 'just work'.
<jam> Mostly because I did the work to get streaming working
<jam> which is really all it should have needed
<vila> I'll check that then (lifeless proposed it too)
<Tak> if I had uncommitted changes in part of a checkout, and I unthinkingly did `bzr revert -rblah` from the checkout root, is there a way to back that out?
<garyvdm> Tak: there may be .~n~ files in your directory
<Tak> heh
<garyvdm> Tak: In some cases when bzr overwrites a file in your working directory - it creates a backup. The name of this back up file will be <the name of your file>.~1~ or .~2~ ect..
<Tak> yeah, I know
<Tak> probably easier to remerge from the original source than to manually recopy the backups
<Tak> I guess I was looking for `bzr undo` ;-)
<vila> jam: commenting out the 'and not fmt.supports_chks' make the tests error out in an ugly way, even after fixing obvious typos (http://paste.ubuntu.com/123379/ wth ? untested ?)
<vila> jam: rats, get rid of the import pdb before trying ./bzr selftest -s bt.test_pack_repository.TestSmartServerAutopack.test_autopack_or_streaming_rpc_is_used_when_using_hpss
<jam> vila: well to start with, 'fulltext_network_to_record' looks like a bug in bzr.dev that we should fix anyway
<cody-somerville> How do I make it so that bzr will never mangle the revision number - only add?
<cody-somerville> I understand this is a branch setting.
<vila> jam: yeah or at least report to spiv and lifeless
<beuno> cody-somerville, IIRC, append_only = true in ~/.bazaar/locations.conf
<jam> beuno: "append_revision_only"
<jam> sorry
<jam> "append_revisions_only"
<jam> cody-somerville: you should also be able to set it in .bzr/branch/branch.conf inside the branch itself
<vila> jam: with http://paste.ubuntu.com/123385/, tests are passing (not the [] pair in fulltext_network_to_record
<vila> jam: so, obviously untested code, which raises the question: is it expected to convert to fulltext ?
<jam> vila: so there is a new issue with a "network stream" record versus the "text you put on disk" bytes
<jam> Obviously nothing was using the 'fulltext' record yet
<jam> for the network stream
<vila> jam: yeah we agree
<vila> jam: fix sent to ML
<jam> vila: I think the patch should be against bzr.dev, probably with a direct test of that function
<vila> jam: patch *is* against bzr.dev. I have not hte slightest idea about what this function is doing :-) I call that 'blind debugging' :)
<jam> vila: I know what it is doing, just not why it wasn't tested before
<vila> jam: but I'm sure lifeless will add the proper tests :)
<jam> I saw that it came in a bit late
<jam> I just saw you claim it as a "bbc:MERGE" which didn't make as much sense to me
<jam> my guess is this code is meant to be used
<jam> when the source repo sends a 'fulltext' stream
<jam> over the RPC
<vila> ha sorry, I forgot to remove that, I wanted to leave only the [Attn lifeless]
<jam> as pack repos don't do that
<jam> but chk does because it was easiest to write things that way
<jam> GC repos do as well
<vila> jam: so forget that [bbc:MERGE], that wasn't a request, I'll merge it as is and wait for conflicts with further modifications by lifeless. Or do you want me to add a FIXME-bbc above the # no fmt.support_chks ?
<jam> vila: I was suggesting that we fix the code in bzr.dev, and then bring that back into bbc
<vila> jam: but lifeless said InterPackToRemotePack will be removed, so I don't think if it's worth it
<jam> I think it is worth having a clean test suite for now
<jam> as we can then send things through pqm, etc
<vila> jam: right, I did the fix against bzr.dev and I'm merging it into bbc right now
<garyvdm> Is there a equivalent to commit's --local option for pull?
<garyvdm> Ah - bug 194716
<ubottu> Launchpad bug 194716 in bzr "bzr pull should support --local" [Medium,Triaged] https://launchpad.net/bugs/194716
<jelmer> barry, pong
<barry> jelmer: hi.  i was looking at the bzr branches on python.org and i think we have a problem, but i'm not sure
<barry> jelmer: bzr info on the 2.5 branch is http://people.ubuntu.com/~andrew/python/branches/release25-maint
<barry> jelmer: but i want to change that to http://svn.python.org/projects/python/branches/release25-maint
<barry> jelmer: can i just do a 'bzr pull --remember' or will that mess things up (either for the branch or for clients of the branch)
<jelmer> barry, no, that should work ok
<barry> jelmer: as long as i use the old v3 mapping, right?
<jelmer> barry, yeah
<jelmer> barry, if you use the v4 mapping it'll just give you a "Branches Diverged" error
<barry> jelmer: cool, thanks.  i'm planning on setting up a cron that just does the `bzr pull` in each of the 4 or 5 directories we care about
<barry> jelmer: cool
<evarlast> how can I do the opposite of push?
<jelmer> evarlast, pull?
<evarlast> oops.
<Tak> unpush?
<evarlast> that was a think-o. its like a typo, only my brain was the problem.
<evarlast> how can I do the opposite of split?
<evarlast> I have two entirely unrelated branches. I would like to move branch B into branch A/B while keeping history.
<Tak> incidentally, is there any reason a `bzr undo` couldn't be implemented?
<jelmer> evarlast, the opposite of split would be join
<radix> Tak: you mean like "revert"? or, say, "uncommit"?
<evarlast> jelmer: thank you.
<evarlast> jelmer: I'll file a bug for docs. there should be a see also: join on the bzr help split output ;)
<james_w> Tak: I believe it is something that Aaron wants, and is slowly adding things that would allow it to happen
<james_w> Tak: it's a way from being ubiquitous though
<evarlast> can anyone help me with join?  I successfully upgraded to a rich-root format. I try bzr join ../B, and it says Not A Branch /home/me/placewithAandB.  I copy B into A thinking it will join in place. I run bzr join B and it says bzr: ERROR: Cannot join O2SensorDiagCalSyn.  Trees have the same root
<evarlast> oh wow, no join documentation in the user-reference :(
<jelmer> evarlast, the tree you'd like to join already ahs to be in place
<evarlast> ok, so it is in place and I get "Cannot join B. Trees have the same root"
<evarlast> but B isn't a dir known to the branch at .
<evarlast> oh, interesting. I did it on all new branches and it worked fine.
<Tak> radix: I mean something like uncommit that doesn't care what the last command was
<evarlast> I need to upgrade the format of B too, not just A, I'll bet.
<evarlast> damn, nope, still the same error.
<evarlast> it works on all fresh branches, but not these two branches.
<evarlast> bzr: ERROR: Cannot join ... Trees have the same root
<evarlast> but they don't!!!
<rocky> hm, does the smart server have any type of user access control?
<evarlast> rocky: the bzr serve does not.
<evarlast> rocky: when running one through apache, use apache Access control.  Same is true of SSH
<rocky> gotcha
<rocky> i'm looking for something a little more flexible like mod_svn
<rocky> with it's authz files
<evarlast> rocky: yes, see the manual.
<evarlast> there is a fastcgi option that is well documented.
<evarlast> google around and find a small modification to that will make it work very well with mod_wsgi
<evarlast> and you can use apache auth.
<evarlast> it is very nice.
<evarlast> Active Directory auth integration and all :)
<fbond> Does anyone know if trac-bzr supports using multiple bzr branches with a single trac installation?
<evarlast> I'm so confused as to why my trees have the same root.
<evarlast> looks similar to this unanswered question: https://answers.edge.launchpad.net/bzr/+question/46922
<evarlast> answer was answered here 8 months ago: http://bzr.arbash-meinel.com/irc_log/bzr/2008/06/bzr-2008-06-07
<evarlast> I'll blog post my solution, which will hopefully make it more googlable.
<evarlast> new question, how can i change my root id from 'TREE_ROOT'
<rockstar> jelmer, ping
<jelmer> rockstar, pong
<jam> barry: ping
<barry> jam: otp...
<jam> k
<jam> just wanted to see about possibly setting up the http + smart server
<rocky> hrm, i'm currently building a wsgi app that wraps the http smart server wsgi app ... is there anyway i can peek at the request info to see what sort of operation is being done (read or write) and to what branch and/or path?
<barry> jam: ping
<jam> hey barry
<barry> jam: hi.  smart server!
<rocky> ok another question, does the "bzr serve" server for bzr 1.12 use smart server protocol one or some other protocol?
<jam> rocky:  smart server protocol
<jam> but certainly not wrapped in http calls
<rocky> jam: no, i'm asking which version of the smart server protocol is it using?
<rocky> or is there only "one" version at this point?
<jam> in general we don't have a separate versioning of the protocol, just more/less functions available
<rocky> jam: also i'm not sure what your last comment meant about not being wrapped
<jam> I don't think 1.12 has anything different from 1.11
<jam> rocky: the smart server protocol is a series of requests and responses
<jam> you can 'tunnel' that through an HTTP POST session
<jam> 'bzr serve' doesn't handle an HTTP POST
<rocky> oh yeah i forgot
<rocky> basically i'm working on ClueBzrServer with is a simple http server that serves up bzr smart protocol over http via the bzr smart wsgi app
<rocky> and i'm trying to add basic read/write security
<rocky> but i really need to peek at what command is being requested to determine security
<rocky> and i'm having difficulty doing that
<rocky> i'm seeing references to ProtocolOne classes and ProtocolThree ... hence my question about protocol versions
<vila> jam: down to 1 failure, 1 error on bbc, one is the symlink/dirstate/64bits and I think you can't see it the other is about AssertionError: these files contain an assert statement and should not:
<vila> /home/vila/src/bzr/experimental/brisbane-core/bzrlib/chk_map.py
<jam> ProtocolX is about how the bytes are encoded on the wire. ProtocolThree has been used for a while
<jam> vila: yeah, there are a lot of asserts there
<vila> jam: Can you have a look ? There are less than 10 asserts, are you confident enough to remove at least some and I'll handle the others
<jam> it is a heck of a lot more convenient for prototyping/debugging
<jam> vila: I'm not sure if I can guarantee not to introduce more...
<vila> lol
<jam> if ...: raise AssertionError is ok for production code
<jam> but sucks when trying to get stuff done
<rocky> jam: so any hints on how i might peek to see what command is being issued if i'm inside SmartWSGIApp ?
<vila> well, long ago, when I was C++ing, I used assertions a lot, but now in bzr, I think there are 3 kinds of assertions:
<vila> 1) The ones you can write tests for
<vila> 2) The one you left in production with if ..: AssertionError
<vila> 3) the ones you put during prototyping because... because
<vila> jam: Can you delete the 3) kind ? :-)
<jam> vila: I'm not sure I'm done prototyping
<jam> i can probably take a look at it
<vila> jam: well, like me, you want a *passing* test suite, and using assert forbids that :-)
<jam> rocky: My recommendation would be to look at how 'bzrlib/transport/http/wsgi.py' is doing it
<jam> and then change things based on whether the user is authenticated or not
<rocky> jam: that's where my rabbit hold began :)
<jam> rocky: why does it matter what request is made?
<rocky> jam: i can easily restrict user access, but i need to restrict based on what commands are being used... like anonymous should be able to read but not write
<jam> rocky: right, so anonymous gets the readonly+ server
<jam> and authenticated gets the other
<jam> rocky: See 'make_app()'
<rocky> but i need to make user1 be able to write and user2 only read
<rocky> and i want user3 to be able to write to some branches/paths but not others
<rocky> so using separate apps doesn't really help with all those use cases
<rocky> and i'm quite familiar with make_app() atm ;)
<jam> rocky: what you probably want is something along the lines of: https://blueprints.edge.launchpad.net/bzr/+spec/acl-transport
<jam> which isn't written yet
<rocky> lol
<jam> though I'm happy to work with someone who wants to implement it
<rocky> sounds like what i'm writing actually :)
<rocky> well, i'm much higher level
<rocky> but maybe that's my problem, i need to be hooking in a the transport level to make these decisions, not on the wsgi level (too high)
<jam> rocky:  so at the intermediate level, you can look around line 160
<jam> where it does
<jam>         smart_protocol_request = self.make_request(
<jam>             transport, out_buffer.write, request_data_bytes, adjusted_rcp)
<rocky> yep... that's where i have my pdb stuck atm :)
<jam> so... (a) you could only support ProtocolThree
<jam> rather than trying to support all possible bzr clients
<jam> we've been at 3 since bzr 1.6
<rocky> yeah i don't care about old clients atm
<rocky> it's looking like i'd have to stuff my own transport in there that is aware of my security/acl rules and raises errors when security authorization isn't met
<rocky> hm
<fullermd> I tend to think ACLage pretty much requires shutting off VFS methods wholesale.  Certainly can't do much while they're being actively used by clients.
<fullermd> I mean, once you have write at all, you can use them to scribble over any existing data in the repository to your heart's content.
<rocky> but if i'm inside the transport what difference does it make about the vfs methods? i can restrict as necessary
 * rocky realizes he doesn't have a lot of experience with bzr transports atm
<thumper> morning, morning
<fullermd> Well, but restricting "as necessary" to prevent bad stuff would be enough to prevent it from doing its actual job as well.
<rocky> jam: do tranports have to be registered? or can they simply be used by instantiating them and passing them to the appropriate places?
<jam> rocky: you should be able to create them and then pass them around
<jam> as long as nothing needs to call 'get_transport()'
<rocky> because i'm considering writing my own transport that wraps ChrootTransport and doing what make_app does but make sure my transport gets used instead
<jam> rocky: sounds right
<jam> make_app() just uses get_transport() to be easy, so constructing it yourself should be fine
<rocky> yeah, basically i won't be able to use make_app() verbatim anymore but i can make my equiv factory function that does the same but uses my transport
<rocky> i wish make_app() had a transport=None arg that fell back to get_transport when transport wasn't specified :)
<barry> jam: brettcannon 's here to talk about cpo in a few minutes
<jam> rocky: you could always register it, and then set your "local_url" to whatever you want
<jam> or 'root'
<jam> sorry
<jam> make_app(root='myacl:///')
<rocky> interesting
<brettcannon> barry: OK, I'm ready; running a checkout now to see what kind of timing I am getting right now.
<barry> brettcannon: i'm still running my update puller.  you're using trunk right?
<brettcannon> Yep.
<barry> k
<jam> brettcannon: are you still around?
<brettcannon> jam: Yep, I'm still here.
<jam> I was wondering if you had ssh access to code.python.org, so we could see what impact using a smart server would have
<brettcannon> I have the same ssh access any core developer does under the pythondev account.
<jam> brettcannon: good enough.
<jam> The performance of bzr+http should at least be comparable to bzr+ssh
<jam> and should be faster than plain http
<brettcannon> OK.
<brettcannon> Is the server up?
<jam> brettcannon: well, I can go to the web server: http://code.python.org/python/trunk/
<brettcannon> jam: I meant the smart server.
<jam> brettcannon: as long as bzr is installed and in the path on the remote machine
<jam> it should 'just work'
<brettcannon> bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://code.python.org/python/trunk/.bzr/smart: Unable to handle http code 404: Not Found
<brettcannon> And that was with ``bzr branch bzr+http://code.python.org/python/trunk bzr``.
<jam> brettcannon: we don't have 'bzr+http' installed. I was asking you to use 'bzr+ssh'
<jam> to let us know ~ what you would see if we set up bzr+http
<brettcannon> Ah, OK.
<brettcannon> jam: Didn't work either.
<brettcannon> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<brettcannon> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<brettcannon> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x14220b0>
<brettcannon> jam: But I am more worried about non-committers getting a decent checkout time than core committers.
<jam> brettcannon: right. I just haven't taken the time to set up bzr+http, and performance should be on par with bzr+ssh
<jam> barry-afk: let us know when you get back
<jam> brettcannon: you can set up bzr+http to be 'anonymous' read-only access
<brettcannon> jam: OK.
<jam> brettcannon: it looks like it didn't find bzr on the server
<brettcannon> jam: Figures. =)
<jam> can you do "ssh host; bzr --version" ?
<jam> barry said that he had 1.12 installed
<jam> I would have assumed it installed in /usr/bin, which is why it doesn't make sense that it wasn't found
<brettcannon> I don't have that kind of ssh access to code.python.org.
<jam> so what access *do* you have?
<brettcannon> I can do checkouts over SSH through the pythondev account, but that's basically it; Barry is the one with shell access.
<brettcannon> I am just the guinea pig who keeps getting slow checkout times compared to everyone else.
<jam> brettcannon: yeah, I'm hoping we can sort out why
<jam> I think we need to hear from barry how things are set up
<jam> are you doing "bzr branch bzr+ssh://pythondev@.../" ?
<brettcannon> jam: OK
<brettcannon> jam: bzr branch -Dhpss bzr+ssh://pythondev@code.python.org/python/trunk bzr
<jam> brettcannon: Did that work?
<jam> -Dhpss isn't strictly necessary, but it might be interesting to see what it logs
<brettcannon> jam:  No.
<brettcannon> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<brettcannon> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<brettcannon> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x14220b0>
<brettcannon> jam: I'll be back a few minutes; need to grab lunch and bring it back to my desk.
 * mwhudson suspects a python gc bug!?
<barry> jam: did brett leave?
<jam> barry: for a bit. he said he had to go grab lunch
<barry> jam: k.  what did we decided about smart server?
<jam> barry: he wasn't able to branch using bzr+ssh
<jam> do you know why that would be?
<barry> jam: nope.  i do it all the time
<barry> jam: was he doing bzr+ssh://pythonbzr@ ?
<barry> jam: pythondev@ is for svn
<mwhudson> arararargh
<mwhudson> LockableFiles has a reference to the transport and has a __del__
<jam> barry: he was using "pythondev" it would seem
<jam> so does he just need a different user?
<lifeless> mwhudson: cycles  ><
<barry> jam: yes, i think so
<mwhudson> lifeless: yes
<jam> barry: just as a point of reference, can you "time bzr branch http://code.python.org/python/trunk" versus "bzr+ssh://.../trunk" ?
<jam> and then time it again with '--stacked' ?
<barry> jam: sure
<jam> that is what I'd like to see from brett, but perhaps you'll have an easier time getting it to work
<jam> (of course, *his* connection is the one we care about)
<jam> barry: what is weird is that he seemed to be getting *some* sort of error for 'pythondev', but not a very clear one.
<barry> jam: pythondev should be harded coded to speak svn.  weird
<jam> barry: probably is, and that is the problem
<jam> it spoke 'svn' back to the bzr client
<jam> which then said "server doesn't understand bzr protocol 3"
<jam> and then closed the connection
<barry> that makes sense
<jam> (that *was* the problem)
<barry> pythonbzr is hard coded to speak bzr, but uses the same keys (and is generated at the same time as pythondev)
<poolie> hello world
<brettcannon> barry: jam: I'm back
<jam> hi brettcannon
<barry> brettcannon: hi.  you want pythonbzr@ :)
<brettcannon> barry: No. =)
<jam> hi poolie
<barry> brettcannon: well, if you want to speak bzr to code.py.org
<brettcannon> barry: Ah, as in you set that account up. Thought you were trying to give me some SSH account and thus more responsibility.
<barry> brettcannon: right!  bzr+ssh will only work against pythonbzr.  svn+ssh will only work against pythondev
<brettcannon> barry: That did it.
<barry> cool
<brettcannon> barry: OK, so bzr+ssh took 14 minutes.
<barry> brettcannon, jam http took 12m12 and bzr+ssh took 14m9
<barry> that was without stacking
<brettcannon> ditto
<barry> brettcannon, jam i'm running it again w/ --stacked
<jam> barry: running sequentially, not concurrently, right?
<barry> jam: right!  i still don't trust my router
<barry> jam: e.g. i /know/ i'm taking probably a 30% hit on throughput since i "upgraded" the firmware
<barry> not to mention the instability
<brettcannon> barry, jam http checkout took 9:34; shaves five minutes off compared to home.
<brettcannon> Still wonder if there is something special about my machine or just the way bzr does things as my hg checkout is more than halved from school compared to home instead of by a third as for bzr.
<barry> brettcannon: well, one thing is for sure.  when i bypass my router and talk directly to my modem, i get much better performance.  i'm planning on downgrading the firmware back to the previous version this weekend to see if i can recapture the better performance
<barry> brettcannon, jam http + --stacked was 15m32!
<barry> brettcannon, jam where it was something like 3m55s bypassing my router
<barry> so i don't know what to make of that
 * barry is trying bzr+ssh --stacked now
<jam> barry: this is with bzr.dev, right?
<barry> jam: ah shit, not
 * barry slams C-c
<jml> jelmer: at some point, the progress bar for bzr svn-import gets stuck, it seems: e.g. [#|                  ] copying revision 777/7694
<jml> oh no, it's turning
<jml> jelmer: never mind me.
<mwhudson> can someone triage https://bugs.edge.launchpad.net/bzr/+bug/335180 ?
<ubottu> Ubuntu bug 335180 in bzr "LockableFiles.__del__ creates uncollectable garbage including connected sockets" [Undecided,New]
<jelmer> jml: :-)
<jml> this bug is also easy enough to triage: https://bugs.edge.launchpad.net/bzr/+bug/335182
<ubottu> Ubuntu bug 335182 in bzr "break-lock does not accept upper-case 'Y' as 'yes'" [Undecided,New]
<jml> jelmer: my svn-import of Twisted has been running all night and is still not finished
<jelmer> jml, which bzr-svn version/
<jelmer> ?
<brettcannon> barry, jam: 6:48 on http stacked.
<jml> jelmer: whatever lp:bzr-svn was yesterday :)
<jelmer> jml: Hmm
<jml> jelmer: Twisted is a big repo with a lot of branches and a long history, so I'm not *too* worried, just as long as the updates don't take as long.
<jelmer> jml: Hmm, still
<jml> jelmer: yeah :)
<jelmer> jml: OOo took less than a day in total..
<spiv> jelmer: from Australia? :)
<jelmer> spiv, ah
<jml> spiv: this isn't from Australia
<jml> it's from my linode box
<spiv> jml: hmm.  Keep an eye on the memory consumption...
<spiv> jml: also, you may find svnadmin dump on wolfwood and then importing from that to be faster...
<spiv> jml: or, just be patient :)
<jml> spiv: huh, interesting.
<jml> spiv: it has graphs for CPU, Disk IO and Network, but not memory
<spiv> jml: I find "vmstat 1" is practically the same thing ;)
<jml> spiv: if I type that into firefox I just get a google search page :P
 * mwhudson hits jml
<mwhudson> the bzr-gtk tests are spamming dialog boxes at me :(
<jml> tsk tsk
<jml> there are ways of writing tests to avoid that.
<mwhudson> yes, "using bzrlib.tests.TestCase" being the main one
<jml> well.
<jml> mwhudson: also the tests for tribunal create GTK+ windows and avoid spamming the screen with them.
<barry> brettcannon, jam 4m17 http --stacked
<barry> jelmer: did you ever ppa the bzr-svn that had the fix for the svn-import problem i was seeing yesterday?
<barry> jelmer: bzr pull on an svn hosted branch is not an option.  it takes hours just to do a pull
<lifeless> spiv: so I need to leave here late avo to get to the city, so if you'recoming over I highly commend earlier to you
<barry> jam: bzr+ssh --stacked in 3m52s
<jelmer> barry: No, I haven't reproduced the problem yet
<barry> jam: i need to leave now for a while.  can you please related those numbers to brett if/when he gets back
<jelmer> barry: Whoa, hours?
<barry> jelmer: yeah
<jelmer> barry, it's less than a minute here..
<barry> jelmer: is there maybe a cache i'm not utilizing?
<spiv> lifeless: ok
<lifeless> spiv: right now, I have a little quirk your input would be great on
<jelmer> barry, no, it's just a performance regression in 0.5.0 that's fixed in 0.5.2
<barry> jelmer: i'm sorry, but i need to go out for a few hours now.  i'll try to ping you tomorrow for details.
<lifeless>   File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/request.py", line 279, in _call_converting_errors
<lifeless>     return callable(*args, **kwargs)
<lifeless>   File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/repository.py", line 444, in do_chunk
<lifeless>     for record in stream.read():
<lifeless>   File "/home/robertc/source/baz/RemoteRepository._format/bzrlib/versionedfile.py", line 1529, in read
<barry> jelmer: ah!  okay cool.  i'll try to figure out a way to get 0.5.2 on that box tomorrow
<lifeless>     for record in self._kind_factory[storage_kind](
<barry> jelmer: thanks!
<lifeless> KeyError: ''
<barry> jam: thanks!
<barry> see y'all tomorrow
<lifeless> spiv: (its getting a zero-length byte string out of the pack sent on the wire)
<jelmer> barry-away, np
<spiv> lifeless: so the record_bytes starts with a \n?
<lifeless> spiv: I guess
<spiv> lifeless: the decoder logic looks sane (although the error reporting could be better I suppose), so I'd suspect an encoding issue.
<spiv> lifeless: sticking a print(body_stream_chunk) in do_chunk would probably help
<spiv> Er,
<spiv> print repr(body_stream_chunk) :)
<lifeless> (Pdb) print repr(bytes)
<lifeless> ''
<lifeless> spiv: we get some nested packs here, a little odd
<spiv> That does sound odd.
<spiv> Also, I have no idea which 'bytes' variable you show in that pdb snippet...
<lifeless> the one that should contain the record stream record
<lifeless> which is the body of the pack record from the stream
<lifeless> (Pdb) print repr(body_stream_chunk)
<lifeless> 'B0\ntexts\n\n'
<lifeless> (Pdb) c
<lifeless> > /home/robertc/source/baz/RemoteRepository._format/bzrlib/smart/repository.py(432)do_chunk()
<lifeless> -> self.stream_decoder.accept_bytes(body_stream_chunk)
<lifeless> ERROR: branch_implementations.test_branch.TestBranch.test_clone_partial(RemoteBranchFormat-default)
<lifeless>     Error received from smart server: ('error', "''")
<lifeless> ok, understood and fixed
<lifeless> (though its a bug that we're hitting the broken case)
<spiv> The sender was encoding some sort of dud text record?
<lifeless> we're sending a delta-closure
<lifeless> which means transcoding
<lifeless> that code path is just broken atm
<spiv> Oh, hmm.
<lifeless> @@ -1500,7 +1477,11 @@
<lifeless>                      serialised = record_to_fulltext_bytes(record)
<lifeless>                  else:
<lifeless>                      serialised = record.get_bytes_as(record.storage_kind)
<lifeless> -                pack_writer.add_bytes_record(serialised, [(substream_type,)])
<lifeless> +                if serialised:
<lifeless> +                    # Some streams embed the whole stream into the wire
<lifeless> +                    # representation of the first record, which means that
<lifeless> +                    # later records have no wire representation: we skip them.
<lifeless> +                    pack_writer.add_bytes_record(serialised, [(substream_type,)])
<lifeless> fixes the symptoms
<lifeless> but I need to find why its flagging that as True
<spiv> Well, LazyKnitContentFactory explicitly can return '' from record.get_bytes_as(record.storage_kind)
<lifeless> yes
<spiv> And this is a RemoteBranchFormat test, so it makes sense that the source stream would have a LazyKnitContentFactory record...
<lifeless> thats the point
<lifeless> not if we're not transcoding
<lifeless> LazyKCF only turns up when include_delta_closure=True
<lifeless> ok, should all be good now
<lifeless> spiv: down to 23 hpss calls
<spiv> lifeless: sweet
<garyvdm> hi bialix: Check out http://garyvdm.googlepages.com/revision-selector.png
 * spiv prepares to wander off
<bialix> garyvdm: WOW
<garyvdm> Work in progress...
<bialix> you're wizard of log
<garyvdm> lol
<bialix> gary, did you see progress bar in qbzr with bzr 1.12?
<poolie> sweet
<garyvdm> bialix: Let me test - I normally use the command line for pull/push etc.
<garyvdm> Hi poolie
<bialix> I don't see pb neither in command line nor qbzr @win32
<lifeless> full tests running, then this branch is up for landing too
<garyvdm> bialix: pb working fine for me in command line and qbzr on ubuntu. I'll test on win32 tomorrow for you.
<bialix> well, I guess it's the bug
<bialix> at least one more windows user confirm it
<garyvdm> bialix: Your mail brought out some usefull information. It's just gone off topic though.
<bialix> you mean bzr-gtk vs qbzr?
<garyvdm> yes
<garyvdm> bialix: You we asking about adding things like push, pull, revert, tag to qlog
<bialix> yep
<garyvdm> I've been thinking about it.
<bialix> generally it's easy
<bialix> unless we playing with multiple branches at once
<bialix> there things becomes tricky for me
<garyvdm> For push, pull - if you've got more than one branch - it's not important which branch you push/pull from, just get a branch that has the revision.
<bialix> tag
<garyvdm> To get such a branch - just get the revision, and then rev.branch
<bialix> if there is more than 1 branch?
<garyvdm> For revert, and tag - what I think we should do is show a sub-menu with the branches that have the revision
<garyvdm> and for revert  - only those that have a working tree.
<bialix> oh, I finally understand your desire to have revert
<bialix> revert to revision?
<garyvdm> Ah-ha
<bialix> ok
<bialix> maybe we should make such submenu all the time?
<garyvdm> all though - these days I use "bzr pull . --overwrite -r ..." more
<bialix> it's just like uncommit
<bialix> uncommit to revision in qlog?
<NfNitLoop> sshing from my g1.   geek heaven.  :)
<garyvdm> Rr submenu all the time - Na - the most common use case is log from tbzr - and that will only ever have one branch
<garyvdm> uncommit to revision in qlog? why not?
<bialix> I mean uncommit instead of revert
<garyvdm> Why not both?
<bialix> revert is really rare
<bialix> I have no objections to both
<garyvdm> If the user has open more than one branch - but choses a revision that is only one branch - we should show the sub menu.
<bialix> gary, today I've thought about qbzr future. I'm planning to start writing some user docs soon
<garyvdm> Ok
<bialix> also, I think we should switch to usual version number scheme: 0.10.0, 0.11.0 and so on
<garyvdm> Ok
<bialix> in the June 2008 I want to release 1.0 as is
<bialix> but your magic on qlog changed everything
<garyvdm> ha ha
<bialix> I don;t think we have to release 1.0 after 0.9.9
<bialix> no, it's really magic, I'm just too busy to dive so deep into qt tricks.
<bialix> I don;t wrote nothing really serious yet
<garyvdm> A big issue is selftest. I'm a unit test noob. I see the value in writing unit tests - but it's a very daunting task.
<bialix> I found unit-testing very nice thing
<bialix> and I like it
<bialix> I'll try to figure out how to write it for some trivial cases
<bialix> I want to say big THANKS to poolie and lifeless
<bialix> and jam of course
<poolie> (:
<bialix> I've learned everything I know about unit-tests from bzr
<garyvdm> I keep on saying to myself - ok - you've got to write unit tests for qlog - and then I end up implementing new features...
<garyvdm> bialix: you need to put pressure on me to get it done :-)
<garyvdm> Unit tests for LogGraphProvider should be easy.
<bialix> I'm fine with new features unless we don;t have too much regressions
<garyvdm> I want to be able to add new features and not worry about regressions. Test should help in that area.
<bialix> but  I can return to latest working release if things going wrong
<bialix> yes, they should
<bialix> we have toooooooo many features to test all of 'em every time manually
#bzr 2009-02-27
<garyvdm> How do we write a test for say qdiff?
<garyvdm> side - by - side qdiff
<garyvdm> and check that the systax highlighting is working?
<bialix> puzzling
<fullermd> Obviously, you write two tests and run them side by side!
<bialix> if our internal data is correct then colors should be correct
<bialix> fullermd :-P
<garyvdm> Ok - thats a very extreame case.
<garyvdm> qlog should not be too hard - just lots of work.
<bialix> garyvdm: I've installed winmerge today. it's more powerful than qdiff s-b-s, albeit lacks syntax highlighting
<bialix> there is too much 3rd party diff gui tools
<bialix> may be we just need ad them
<garyvdm> On windows - I prefer Araxis Merge - unfortunately it is proprietary.
<garyvdm> But I'm doing most of my dev on ubuntu these days - so I use meld
<bialix> some people can buy proprietary soft
<garyvdm> or crack pro^H^H^H^H^H^H^H^H^H^H^H^H^H^
<bialix> I dunno, luks rewrote qdiff s-b-s several times and we still is not perfect
<bialix> garyvdm, I understand
<bialix> there is one area we can do better: qann
<garyvdm> Yes - we need to be able to select the revision you are annotating.
<garyvdm> Go back
<bialix> yes, something like this
<garyvdm> I personally don't gannotate's ui for that though.
<bialix> don't? don't like?
<garyvdm> err - yes - don't like
<garyvdm> I would rather have this: you right click on a revision in the revision list - and click "Annotate this revision"
<bialix> I don't ran bzr-gtk for ages, I don;t remember how it
<bialix> this is fine way
<garyvdm> The revision that is annotated is highlighted in the list.
 * fullermd just wishes viz would stop polluting his clipboard...
<bialix> one thing that turn me mad in qt is clipboard
<bialix> I'm selecting some text in qdiff, close it -- and then find that clipboad is empty
<garyvdm> You need to go back to an older qt
<bialix> err, I mean I'm copy text to clipboard but qt clear it on exit
<bialix> older?
<bialix> I'm using 4.3.1
<bialix> fullermd: switch to qbzr and your clipboard will be empty all the time
<garyvdm> Are you sure - We had a discussion on the ml about it - you told me that it worked in 4.3.1
<garyvdm> Subject: Copy, Close Window, Paste does not work
<fullermd> qbzr requires qp 4 though, don't it?
<garyvdm> Yes
<bialix> yes, I'm observing this issue only in qdiff, but not in qlog
<fullermd> I don't have 4 around.  And QT is freakin' HUGE.
<fullermd> (only reason I have bzr-gtk around is that I already have GTK anyway)
<bialix> fullermd: windows installer is about 12MB
<bialix> it's not very huge for me :-P
 * fullermd doesn't own a machine that runs Windows   :p
<igc> morning
<bialix> good day igc
<fullermd> Heck, even QT 3 takes longer to build than Firefox, IIRC.  Nutbar.
<garyvdm> fullermd: so you have never tried qbzr?
<bialix> that's why I prefer python tools: I don;t need to compile tem (usually)
<fullermd> No.  I wouldn't have tried bzr-gtk if I didn't already have all the pieces but the python gtk bindings either.
<fullermd> I don't have any real use for it.
<fullermd> I don't think I've ever even fired up anything but viz, and I've only used viz recreationally.
<bialix> garyvdm: I've re-read that discussion about clipboard
<bialix> I have no problem with most of the q-windows, only with qdiff
<bialix> only with s-b-s qdiff, because it's default
<garyvdm> bialix: ok
<bialix> I suspect it's because there is different widget used
<bialix> maybe something related to painting
 * bialix checks
<garyvdm> bialix: linux desktops generally have clipboard managers. I wounder if you can find one for windows.
<fullermd> (I note that viz resets its clipboard damage when it exits too, which makes it either better or worse; I'm not actually sure which)
<bialix> wow
<bialix> it looks interesting
<igc> hi bialix
<bialix> it works now on win xp for black text
<bialix> ian, I have question about fast-import
<lifeless> garyvdm: http://msdn.microsoft.com/en-us/library/ms649014(VS.85).aspx
<igc> bialix: sure, and I have a Q for you!
<lifeless> garyvdm: which is, its built in. You can supply the content or you can be called back.
<igc> bialix: bug 328007 - any thoughts?
<ubottu> Launchpad bug 328007 in bzr "UnicodeDecodeError on 'log -p'" [Undecided,Confirmed] https://launchpad.net/bugs/328007
<bialix> garyvdm: but it does not work as expected with win2k I'm using at work
 * bialix looks
<igc> bialix: my simply fix breaks a fair few tests that I think you wrote so I wanted to hear how you thought we should proceed there
 * bialix cough
<bialix> it's tricky
<bialix> honestly, I think we should have versioned properties to store encoding of files
<bialix> or at least rules
<garyvdm> lifeless: thanks
<bialix> it's ideal situation I know
<bialix> igc: you can't use exact on log
<bialix> otherwise you have to manually encode log messages
<igc> bialix: I'm not sure I understand how encoding files/rules will help here?
<bialix> igc: because then you can decode them to unicode
<jelmer> lifeless, do you remember the subject of your email with instructions on running bzr serve from homedir on a remote side?
<jelmer> *site
<bialix> igc: I think to fix this issue one have to provide exact stream for log formatter but create another wrapped stream internally to log everything but diff
<lifeless> streaming-push alpha testing
<bialix> igc: is it correct?
<igc> bialix: something like that but I have next to no idea on how to do that :-(
<bialix> ok, I can try to figure it out, but I have a question about fast-import first
<igc> bialix: my knowledge in the whole encode/decode space is "just the basics"
<igc> bialix: fire away
<poolie> hey igc
<igc> hi poolie
<bialix> igc: I'm pleased to hear you think I'm expert in unicode, of course, I hope I can help
<igc> lifeless, jam, poolie: got a bzr-1.12 branch converted to gcchk255 yesterday
<poolie> oh ok
<igc> it took 4.5 hours
<poolie> igc, i'd like to set them up on orcadas
<bialix> igc: I have a real need to replay some my branches and filter them in very smart way. But I need to preserve file-ids
<igc> but it's 1/2 the size!!!
<igc> jam: I've been trying to benchmark it this morning but I've been running into gremlins here and there - mostly in my setup
<poolie> i had many gremlins on orcadas
<igc> jam: however, "./bzr log -r-1 NEWS" doesn't work for me on brisbane-core
<poolie> the patch i sent you was really pathetically small for how long it took me to work out :-}
<bialix> igc: where the code for generating diff in log lives?
<bialix> poolie: what is orcadas
<poolie> bialix: the machine that's http://benchmark.bazaar-vcs.org/
<igc> bialix: the diff gets generated by calling into diff.py - the result is stored in a StringIO
<poolie> you can really see in that first graph how the noise makes it hard to say straight away whether there was a meaningful change or not
<bialix> poolie: your genius to choose right names for things is imressive
<igc> bialix: later on, the LOgFormatter calls a method called show_diff that tries to dump it to self.outf
<poolie> bialix: is that sarcasm or not? :)
<bialix> poolie: but Kergelen is a bit offensive :-P
<bialix> a bit
<poolie> ah ok
<bialix> the naming of cat is a difficult matter
<poolie> well, that one i did not choose
<bialix> :-)
<poolie> Orcadas Base <http://en.wikipedia.org/wiki/Orcadas_Base>
<poolie> the worst canonical machine name (for me) is in russian actually
<poolie> um
<bialix> soyuz
<igc> poolie: sorry that the usertest code is pretty rough - it gets minimal love because it doesn't necessarily deserve/need more
<bialix> yes?
<poolie> Novolazarevskaya
<igc> poolie: well until some other por sucker tries to tweak it :-(
<bialix> LOL LOL LOL LOL
<igc> s/por/poor/
<poolie> igc, i know, it's ok
<bialix> ROTFL!!!!!!!!!!!!!!!!!!!!
<bialix> poolie: you know the English is hard language too
<poolie> i'm not sure if this is true but i've heard it means something like "New Miami Beach"
<poolie> which is a joke because it's a place in Antarctica
<bialix> they have a bath there
<bialix> bath == warm
<bialix> warm == beach
<bialix> Novolazarevskaya is just a name
<bialix> Novo == new
<poolie> maybe it's the nickname for the place or something
<poolie> soyuz is about the last part of landscape to have an obscure code name
<bialix> lazarevskaya it's the beach near the Sochi
<bialix> Black Sea
<bialix> so yes, it's ~= New Maiami Beach
<bialix> igc: so what about fast import and file ids?
<igc> bialix: its a good question!
<igc> bialix: fast-import has some support for incremental changes ...
<igc> but I feel it needs some deeper thought
<igc> at a minimuym, some better ui polish and doc on how to do it and the limitations would be nice
<bialix> igc: until I saw fast-import in action I'm thinking about writing my tool for this
<bialix> also, I have many failures with renames
<igc> bialix: I really need to bug Jelmer about this topic when we both have some time
<bialix> some of my branches even have cyclic renames???
<igc> bialix: please raise bugs for the rename issues
<igc> bialix: I've recently added a heap of tests for fast import, though fast-export doesn't have any yet
<bialix> igc: it's occured on private branches
<igc> bialix: I know I'm still missing fast-import tests for renaming and copying directories though
<bialix> I dunno how to properly write bug report
<lifeless> igc: 1/2 size, thats a bit disappointing
<igc> bialix: all I need is a minimal fast-import stream showing the scenario and expected outcome
<bialix> igc: ok I see LogFormatter.show_diff, but who call it?
<igc> lifeless: you were expecting more?
<bialix> rats
<bialix> I'm back
<lifeless> igc: yes, various sample data goes to 1/7th
<lifeless> jam: probably need the byte-length encoding for gc 'i' instructions
<igc> lifeless: the other curious thing about running brisbane-core/bzr upgrade --gcchk255 was that the dirstate size went up
<igc> not by much but a bit (328 blocks to 36) - something like that)
<lifeless> igc: ? *blink*
<igc> s/36)/360/
<bialix> igc: how about this fix for log -p
<bialix> igc: store original exact stream as self.exact_stream and use it for show_diff
<igc> bialix: show_diff is called by the ShortLOgFormatter and LOngLF
<lifeless> igc: did you do a full branch of the result?
<bialix> igc: and wrap it as in command.py Commad._setup_outf and store as self.to_file
<lifeless> igc: that will get rid of some redundancy (outside a shared repo, obviously)
<igc> bialix: line 1311 of log.py is one called to show_diff()
<bialix> igc: I'll write it for you. Here is just 02:56 and I'm don;t sleep anyway
<igc> bialix: legend
<igc> lifeless: I was upgrading from a pack branch - no shared repo before or after
<bialix> legend?
 * bialix hates chatzilla but have no better irc client
<igc> bialix: I was trying to say thnk-you very, very much
<igc> s/thnk/thank/
<igc> lifeless: I'll upload the branch (as an archive) to orcadas - I just wanted to make sure it mostly worked first
<bialix> lifeless: I've used to pb. don't see it with bzr 1.12 is hurt
<bialix> igc: one downside with using exact encoding for log: output will be LF-only on Windows
<lifeless> bialix: yeah, I'm not sure whats going on; if it was 1.13 I'd know (because spiv and I broke it temporarily)
<bialix> but I think for Windows qlog is rocks
<bialix> lifeless: and I don;t see pb in qbzr too, it seems it's just disappear
<igc> bialix: does diff have the same issue?
<bialix> igc: what issue?
<bialix> igc: for plain diff exact is right thing
<bialix> igc: but for plain log -- i'm not sure
<bialix> but I can live with this
<bialix> I just want to inform you abut this side effect
<bialix> igc: ping
<shtylman> is there a way to delete a bazaar branch remotely? without logging into launchpad per se?
<poolie> shtylman: there probably is an API for it in launchpadlib but i don't think there is a UI at present
<shtylman> poolie: thanks
<bialix> igc: I have the patch for you
<igc> bialix: thanks! I'll test it later today
<bialix> send it to list or to you personally?
<poolie> shtylman: you could add one to bzr's launchpad plugin if you're keen
<bialix> I've tested it manually only, have no desire to write unittest
<shtylman> poolie: well, I don't just want to be able to do it in launchpad, but for other projects as well
<bialix> igc: sent to ML
<bialix> perhaps I need to manage me to sleep. bye
<Stanlin> whos bazaar for windows developer?
<khemicals> how does one duplicate a bzr repository to another bzr repository -- do you have to do it one branch at a time?
<Peng_> khemicals: I'd probably use rsync.
<khemicals> rsync doesn't talk http
<Peng_> There might be a plugin that helps, but if so, I don't remember it.
<khemicals> so -- there's no command I am m issing
<khemicals> but bzr doesn't natively support it
<Peng_> If it's plain HTTP, there's no way to walk the file system, so unless bzr kept a list of branches somewhere, which it doesn't, it isn't possible...
<Peng_> Mmm, commas.
<khemicals> k
<mlh> it doesn't keep a list of branches?
<Peng_> mlh: Correct.
<mlh> nowhere?
<Peng_> mlh: Correct.
<mlh> so you can't discover branches remotely, you have to know what you want.
<khemicals> So, I pulled a branch from an existing public repo (just playing with bzr here to see how it goes) and tossed it into a local repo (was created using repo-init) using something akin to bzr push bzr+ssh://host/PATH_TO_REPO but now I cannot check it out since I don't know what the branch name is
<Peng_> There are find_bzrdirs and find_branches methods, but they just go recursing through the file system.
<khemicals> is there a default branch name
<Peng_> khemicals: ...What?
<Peng_> khemicals: Branch names shouldn't matter, just the specific location.
<khemicals> it errors
<khemicals> let me get the error for you
 * Peng_ avoids knowing much about checkouts
<khemicals> bzr: ERROR: Not a branch:
<khemicals> and then the path thereafter
<khemicals> with git, for instance, I can clone the ENTIRE repository
<khemicals> just trying to figure out how to do the same without filesystem access to the repo I am trying to duplicate
<khemicals> Peng_: Why do you avoid knowing much about checkouts?
<khemicals> trying to figure out where I am going wrong here
<Peng_> khemicals: Checkouts are something extra to learn. Regular branches are usually enough for me.
<khemicals> what's the difference between pull/checkout/branch commands?
 * khemicals reads the man I guess
<Peng_> Ehh, I'm not good at explaining things.
<Peng_> khemicals: Were you trying to "bzr branch" from a repository or checkout instead of a branch?
<khemicals> it was a branch since none of it worked against the repo root I don't think
<lifeless> khemicals: pull maintains a mirror; checkout creates a checkout - a place to edit an existing branch, branch creates a new branch (and if the target is local it can be edited in-place)
<khemicals> so, pull still only works against a branch though, right?
<Peng_> khemicals: Right. Use "update" against a checkout.
<khemicals> so, can I pull a branch from one repository and use push to push it to another?
<lifeless> khemicals: yes
<khemicals> do I need to create a destination branch in the repo I am pushing to first? -- or is that was export is for?
<lifeless> khemicals: no, push will make a branch if one doesn't exist alrady
<khemicals> what's the name of the branch -- the same as what I pulled?
<lifeless> khemicals: branches have urls, not names
<lifeless> khemicals: in git branches are 'refs in a repo', in bzr 'branches are directories at a url'
<lifeless> s/refs in a repo/'named refs in a repo'
<khemicals> well, the name is essentially just a subdir of the repo
<khemicals> so, how is that name determined
<lifeless> khemicals: you don't need a repo
<lifeless> khemicals: try it - bzr branch [some branch] /tmp/demo
<khemicals> bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr
<khemicals> so, how do I populate a new repo, that I want to share, with that content (including full history)?
<AfC> khemicals: bzr branch
<khemicals> bzr branch bzr SOME_NEW_URL ?
<Peng_> khemicals: Sure.
<lifeless> khemicals: if you have a lot of branches, or a lot of history, you can run 'bzr init-repo URL' to create a history-sharing repository with no content, then whenever you bzr branch URL/suffix, or bzr push URL/suffix, bzr will use that repository to share branch content
<lifeless> khemicals: but generally most folk don't need this
<lifeless> the folk that do tend to be server admins and developers on projects with hundreds of MB's of history
<khemicals> I found my issue
<khemicals> in checking out the various protocols server side, I set the --directory option on the bzr daemon
<khemicals> it stripped too much of the path out
<khemicals> so it didn't match the path used by the other mechanism
<khemicals> thus confusing the heck out of me
<khemicals> but I do understand it enough to limp along now -- will keep reading, thx for the assist
<lifeless> khemicals: no problem
<lifeless> khemicals: most folk just use 'bzr+ssh://' as the protocol, which sets --directory automatically
<khemicals> I am just toying with all its server side functions
<khemicals> bzr+ssh is fine
<lifeless> cool
<khemicals> but wanted to try native bzr
<khemicals> protocol
<khemicals> as well
<lifeless> feel free to shout if you want any more input
<khemicals> you can checkout from loggerhead to? or no?
<lifeless> I think you can branch from loggerhead in the very latest versions
<lifeless> mwhudson: ^ please confirm or deny
<mwhudson> yes you can
<khemicals> s/checkout/branch
<khemicals> wrapping head around new nomenclature that overlaps others
<mwhudson> but it doesn't support Range:s so don't use it on anything big...
<lifeless> yeah, I can appreciate that
<lifeless> strictly speaking you could checkout from loggerhead, but it doesn't support writing back to it, so you wouldn't be able to commit -> checkout isn't that useful in that case :)
<mwhudson> loggerhead will do bzr+http sooner or later i guess
<igc> lifeless: can you help me with a CHKInventory issue please?
<igc> lifeless: what's the way forward wrt referencing "children" of an InventoryDirectory?
<igc> it looks like iter_entries() on a  chk-inventory can break because the attribute is now _children, not children, and there's a children() method on the ...
<igc> ChkInventryDirectory class but not one I can see on InventoryDirectory?
<igc> jam: ^^^
<jam> igc: I would say we need to add one to InventoryDirectory()
<jam> we really want to be able to lazily bring stuff in
<igc> jam: ok, I'll do that and change the references to .children to .children()
<igc> jam: sound right?
<jam> sounds right to me
<igc> jam: thanks
<igc> jam: fyi, to see the bug in action, try bzr ls -r-1 on a chk branch and you'll see nothing listed
<jam> interesting
<jam> igc: btw, I just finished another improvement to chk+gc
<jam> which improves inventory compression by 50-100%
<igc> jam: sweet
<jam> I'm pushing it up now
<igc> jam: is gcchk255 still the preferred format for me to be benchmarking?
<jam> igc: I need to do another round of testing myself
<igc> jam: it souded like you were leaning towards a 127?
<jam> I might also be cheating more than I realized
<jam> igc: I have to test *after* compression
<jam> it can make smaller things become bigger
 * fullermd blinks.
<fullermd> Something went screwy with pushing multi-initial-rev branches?
 * fullermd really needs to watch bugs more closely...
<spiv> fullermd: apparently!
<spiv> fullermd: I was surprised too.
 * fullermd is extremely surprised.
<fullermd> A very large number (quite possibly a majority) of my branches have >1 initial rev.
<fullermd> I've never seen issues pushing with say a up to 1.5 version spread between my bzr.dev client and the latest-release-mod-upgrade-slack-time server.
<fullermd> It's only a blowup, right?  Not a "gee, it worked fine, but it's gonna screw you later"?
<spiv> Right.
<spiv> And it's purely a client-side issue.
<jam> spiv, lifeless: question on the new stream tests
<jam> if an entry is in "Chunked" encoding
<fullermd> Oh, good.  That leaves me with only 38,849 entries on my worry stack for today.
<jam> the "capture_stream()" fails
<jam> because "self.assertIsInstance(factory.get_bytes_as(factory_kind), str)"
<jam> groupcompress hits this
<jam> because it only talks in fulltexts/chunked (so far)
<lifeless> igc: so as jam says, it needs to stay lazy
<lifeless> igc: there is a property for children; if the property isn't working correctly there is a bug
<jam> I would guess that ultimately we want to have gc go the same route as your "knit-delta-closure" patch
<lifeless> igc: it sounds like something changed in bzr.dev
<lifeless> jam: yes, knit-delta-closure is roughly the same problem case as gc for streaming network
<lifeless> jam: I just haven't gotten around to it
<lifeless> jam: that might be a bug in the test; but generally we don't want any stream returning direct Chunked or Fulltext objects, because they don't have a small network representation
<jam> igc: for example, I expect 255-way to compress better, because you have a big top level page, and fewer intermediate pages
<jam> so even though its raw size is slightly larger
<jam> it may end up smaller post compression
 * igc lunch
<jam> igc: So if you pull the latest groupcompress, you should be able to 'bzr pack'
<jam> and have it spend far too long with no progress bars
<jam> but end up with a smaller inventories
<igc> jam: so just running pack is enough? I don't need to upgrade to another format then upgrade back for example?
<jam> igc: for this, that should be enough
<jam> so in my quick test
<igc> lifeless,jam: so I missed the @property bit - make me wonder whether the bug is in the inventory building rather than the inventory lookup?
<igc> lifeless,jam: but lots of stuff *is* working
<igc> so it's not obvious to me yet where the bug is
<jam> pre-compression, gc+chk16 is 20MB versus gc+chk255 is 31MB, after compression it is 9.5MB versus 7MB
<jam> so 20MB raw => 9.5MB comp, 31MB raw => 7MB comp
<jam> which makes gc255 better
<jam> There are other factors to test, though, so I'll get there
<igc> jam: any do you expect lookup speed to be much the same? or 255 faster?
<igc> s/any/and/
<fullermd> How relevant are those compression numbers, though?  Aren't you still to-do delta compression or other schemata on them?
<jam> igc: smaller == less bytes to read, larger fan-out means you filter more keys per pass. So overall, I expect 255 to be better on both counts
<jam> but expect != measured
<jam> fullermd: this is one form of delta compressino
<jam> still one of the factors to be evaluated
<fullermd> Well.  But does it have the same properties as $FINAL, though.
<jam> it should at least have *similar* properties
<igc> jam: pulled groupcompress rev 50 and kicked off that pack now
<lifeless> igc: So yeah, there is a property; it should work; there are tests - perhaps the input is flawed in some way. Cross checking by using iter_entries_by_dir or something might be enlightening
<jam> igc: wait
<jam> I just found a quick bug when there are signatures
<jam> I'll have a fix in just a sec
<igc> jam: ok, I'll stop it
<jam> I'll also get a quick progress on the texts done
<igc> lifeless: sure. I tried a quikc corss check using entries but it's not defined on CommonInventory, just Inventory, so I might move that up a level too
<lifeless> igc: when moving up just take the time to check it uses public interfaces not private attributes
<igc> lifeless: sure
<jam> igc: revno 52 is available
<jam> should give you some idea of progress now
<jam> I also noted that converting is slower than 'bzr pack', which is good
<jam> well, good that 'pack' is faster :)
<igc> jam, lifeless: so I'm closer t finding that children() bug - the "slow path" in CHKInventoryDirectory.children() gives a good result while the code after that if statement finds no children
<jam> lifeless: so here are some hard numbers for including/removing 'label' and 'sha1' sum fields.
<jam> for gc+chk255, the inventories go from 8.3MB compressed down to 7.0MB compressed
<jam> the texts go from 11.0MB => 9.6MB
<jam> or approx 107 bytes per object for inventories
<jam> and 202 bytes/object for texts
<jam> [compressed]
<jam> though interestingly enough, after a 'bzr pack', the final inventories shrunk dramatilaly
<jam> as it is now 6.5MB rather than 8.3 (so w/ labels is smaller than w/o labels)
<jam> though after 'bzr pack' the *text* size went up, 11.0MB => 11.3MB.
<mwhudson> hm
<mwhudson> in a test, i want to create a (local) branch, then open it over the smart protocol
<mwhudson> what's the easiest way to do this?
<mwhudson> nm, got something working
<jml> lifeless: I deleted your subunit/filter merge proposal and created it again so that I could blog about something more easily
<jml> lifeless: please ignore the mail :)
<jam> igc: a quick update. revno 53 drops it by another 2MB, so now 4.4MB down from 6.5
<Stanlin> how to undo last changes in my directory
<jam> Stanlin: "bzr revert"
<jam> lifeless: woot!. Surprisingly, changing the grouping had a much bigger impact than I expected.
<Stanlin> thanks
<jam> By creating more groups, I'm down to 1.5MB, which is actually finally *smaller* than the knit source
<jam> (1.8MB)
<jam> I'm going to do a conversion from scratch to confirm, but it looks good so far
<jam> (raw size is identical, etc)
<jam> igc: You may want to stop it and use revno 55
<jml> jelmer: so, it's still running
<jml> jelmer: "copying revision 1405/6696" (I killed it and restarted it at one point, in a bout of nervous fear)
<eferraiuolo> I was wondering if there was an appropriate way to delete a branch that's in a shared repo?
<eferraiuolo> if I have /repo and /repo/b1 and b1 branch is using the shared repo for storage, I've just been deleting the b1 directory... Does that leave un-wanted cruft around in my shared repo?
<eferraiuolo> Is this where the pack command comes in? I guess I'm just unsure since there isn't a remove-branch from repo command...
<poolie> eferraiuolo: there's a bzr gc plugin that will remove it
<poolie> normally people just leave it there unless it's unreasonably big
<eferraiuolo> poolie: so there is some cruft left around in my repo if I just delete the branch dir?
<poolie> yes
<eferraiuolo> poolie: thanks. I'll look into the gc (garbage collection??) plugin
<poolie> yes
<poolie> igc, are if you're still here, is http://pastebin.ubuntu.com/123652/ correct/reasonable?
<poolie> igc, also, i was wondering about encoding eg the project name, scenario name, script name into the csv file
<igc> poolie: back from reviewing some chk code
<igc> poolie: that pastebin looks fine bar lines 54/55 which is a partial sentence
<igc> poolie: I'm open to any encoding suggestions, though the current output of 'just a table' has value in it's simplicity
<poolie> i was basically thinking about putting just a couple of other heading rows
<poolie> like tool, version, project, scenario
<poolie> suite
<igc> poolie: sure
<poolie> it shouldn't break anyone using them in eg  a spreadsheet
<poolie> as long as they can cope with there being nonnumeric data
<poolie> and it'll make it more selfcontained
<vila> hi all
<igc> hi vila
<vila> hi Ian :)
<berto-> abentley: hi.
<thrope> help - tried to upgrade bzr and now get: bzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.4/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 9, 0)". It supports versions "(1, 11, 0)" to "(1, 12, 0)".
<thrope> but bazaar is 1.12 - I don't know where 1.9 is coming from
<luks> from a plugin, probably
<thrope> deleting bzr-lib seemed to work
<thrope> now when I try to update bzr-svn directory I get bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/"./      0kB
<igc> night all
<vila> thrope: what do you mean by 'deleting bzr-lib' ? bzrlib ? Where did you delete that ?
<thrope> vila: site-packages
<thrope> anyway thats ok now - but it seems bzr-svn and bzr-rebase that I had a branch of have moved or something so I just gave up and downloaded a tar ball
<vila> thrope: So you deleted the bzrlib fron you site-installed packages (but you may still have the bzr script somewhere). What OS are you using ?
<thrope> vila: centos - its really fine now - I had installed a new version without manually deleting the old one
<thrope> so i deleted the old one (script and site-packages) and reinstalled the new one
<vila> thrope: ok
<Spaz> is it possible to allow checkins to bzr via http?
<finiteset> I want to delete Bazaar from one of my projects completely. How do I do that?
<ollie_> hey what is the parameter for adding a dir but not recursively
<luks> bzr help add is hard to read?
<Ollie_R> luks: nope :)
<Ollie_R> luks: thanks
<Spaz> finiteset, what do you mean?
<finiteset> Spaz: I have this folder for one of my projects which is a Bazaar branch. It has all the .bzr stuff in it. Now I want to get rid of Bazaar from the folder. I was wondering if I can use a Bazaar command to remove Bazaar from the folder.
<Spaz> just rm -rf .bzr
<Spaz> no special commands needed
<finiteset> So all Bazaar files are in .bzr folder?
<finiteset> its done thanks
<vila> Spaz: commit needs write access, you need to either install a smart server or configure DAV and use the webdav plugin
<Spaz> hm ok
<vila> The former is preferred for performance reasons, the later exists for people who just can't administer their http server
<vila> Spaz: what is your server ?
<Spaz> it's internal
<Spaz> :p
<Spaz> (not publically accessible)
<vila> Spaz: or more to the point, what is available on this server ? bzr+ssh it easy to setup, or even bzr: if it's really internal on you don't need to implement access rules
<vila> s/internal on/internal and/
<Spaz> well access rules will still be necessary
<Spaz> bzr+ssh is a possibility
<Peng_> If you don't mind configuring ssh, bzr+ssh is probably best.
<vila> Spaz: Just as Peng_ said :-)
<wysek> Hi, I have a user-question. Is this the proper place to ask?
<luks> I'd say it's *a* proper place
<LarstiQ> assuming it's about bzr :)
<wysek> Ok. I have a bzr repo with some revs. I need to commit these into svn repo.
<wysek> It started as a normal bzr repo; there is no module/branch in the svn repo yet, I have to create it
<wysek> how should I do it?
<LarstiQ> wysek: I'd use the bzr-svn plugin
<wysek> (well, I want to test it before I commit to svn, so I did: svnadmin create ~/repo)
<LarstiQ> wysek: how did you install bzr?
<wysek> LarstiQ: I had bzr from ubuntu, but 10min ago I upgraded to latest stable
<LarstiQ> wysek: via the ppa?
<wysek> yes
<wysek> assuming a clean svn repo is at ~/svn and my bzr repo is at ~/bzr/$dir.
<wysek> I need to commit $dir to ~/svn/$dir
<LarstiQ> wysek: (with bzr-svn installed), afaics that should be `cd ~/bzr/$dir; bzr push ~/svn/$dir`
 * LarstiQ goes to work, later
<wysek> great, I've just encountered an "internal error"
<awilkins> wysek: You want the dpush command
<awilkins> Pushing new branches just off "push" doesn't work yeyt
<awilkins> *yet
<wysek> ok, I'll try
<wysek> hmm
<rcmorano> btw, does anybody knows if it is technically possible to push a complete branch to a svn repo served via http and preserve the commiters in the log??
<wysek> wysek@scout:~/bzr/radardaemon$ bzr dpush /home/wysek/svn/radardaemon
<wysek> bzr: ERROR: Not a branch: "/home/wysek/svn/radardaemon".
<rcmorano> i have been trying hard with bzr-svn
<rcmorano> even hacking it a bit
<rcmorano> but i always got something like i wasnt allowed to change the revprop on that scenario
<rcmorano> scenario = context = using post-revprop-change hook in server side
<wysek> wysek@scout:~/bzr/radardaemon$ bzr dpush /home/wysek/svn/radardaemon
<wysek> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<wysek> wysek@scout:~/bzr/radardaemon$ bzr merge /home/wysek/svn/radardaemon
<wysek> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<wysek> awilkins: what now? :)
<wysek> (I did svn mkdir file:///home/wysek/svn/radardaemon before that)
<awilkins> Are you pushing the trunk branch?
<awilkins> Or a branch branch?
<awilkins> wysek: You are creating a new folder, so push to the URI that makes sense for that new folder ; i'd go for
<awilkins> bzr dpush /home/wysek/svn/radardaemon/trunk
<wysek> (I don't know much about svn, trunk...)
<awilkins> The usual convention is   /project/trunk|tags|branches
<wysek> bzr: ERROR: Not a branch: "/home/wysek/svn/radardaemon/trunk".
<wysek> awilkins: and trunk|tags|branches are just dirs?
<awilkins> Oops, make that into a file:/// URI
<wysek> ok
<awilkins> wysek: Yes, everything in SVN is a "cheap copy"
<wysek> the same
<awilkins> wysek: There's no technical distinction between tags and branches, it's just convention
 * awilkins looks at the scripts he has doing thing
<awilkins> Try svn-push
<wysek> actually I need to commit to some svn repo: svn://repo/trunk/<project>/radardaemon/
<wysek> and I'm just testing it locally
<awilkins> Yuck, they have the _other_ convention
<awilkins> I thikn it's svn-push, not dpush
<awilkins> At least, that's what I've got here - I've been converting old archives into bzr repos and then SVN repos
<wysek> so first I need to svn_mkdir $SVN/trunk/
<wysek> and svn_mkdir $SVN/trunk/radardaemon/ ? or just the trunk?
<awilkins> I'm not so sure about that layout
<awilkins> But hey, it's a test
<wysek> wysek@scout:~/bzr/radardaemon$ bzr svn-push file:///home/wysek/svn/trunk/
<wysek> Initialising Subversion metadata cache in /home/wysek/.bazaar/svn-cache/921462df-d7b4-450a-9d4b-2ef3c14a844f
<wysek> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<wysek> *diverged* :D
<awilkins> Are you pushing to a folder that exists?
<awilkins> rm -rf /home/wysek/snv
<awilkins> svnadmin create ~/svn
<awilkins> mkdir ~/svn_template
<awilkins> mkdir ~/svn_template/trunk
<awilkins> mkdir ~/svn_template/trunk/project
<awilkins> svn import svn_template file:///home/wysek/svn -m "Initial folder structure"
<awilkins> bzr svn-push -d ${bzr_branch} file:///home/wysek/svn/trunk/project/radardaemon
 * awilkins crosses fingers
<wysek> Initialising Subversion metadata cache in /home/wysek/.bazaar/svn-cache/52c0211b-6b7a-4d98-8a1d-2bbbabca63ca
<wysek> bzr: ERROR: Prefix missing for trunk/project/radardaemon; please create it before pushing.
<wysek> svn import does not need commit?
<jelmer> wysek, what version of bzr-svn are you using?
<awilkins> Not afaik
 * awilkins cheers jelmer
<jelmer> wysek, iirc older versions of dpush don't support creating new branches
<wysek> 0.5.0-1
<wysek> ok
<wysek> it almost worked
<wysek> *** Bazaar has encountered an internal error.
<wysek> it pushed 24/33 revisions
<wysek> the error was:
<wysek> bzr: ERROR: subvertpy.SubversionException: ('Attempted to get textual contents of a *non*-file node', 160017)
<wysek> hmm, there is a link in my repo, maybe that's the problem
<jelmer> wysek, does the problem occur if you push repeatedly?
<wysek> jelmer: yes
<wysek> it seems it "sees" that it has pushed some revs and goes just to the error
<jelmer> wysek: Can you pastebin the traceback?
<wysek> (no progress bar)
<wysek> sure
<jelmer> back in 10m
<wysek> http://pastebin.com/m72316e4c
<wysek> ok it has nothing to do with the link as it stopped 6 revisions before the link appeared
<wysek> in the revision it stopped I have added a binary file
<wysek> and the error is: SubversionException: ('Attempted to get textual contents of a *non*-file node', 160017)
<wysek> note _textual_
<wysek> seems like a bug:)
<jelmer> wysek, please run with BZR_PDB=1 set
<jelmer> that should land you in a debugger
<wysek> yep
<jelmer> wysek, after that, please run "up" followed by "print new_inv.id2path(child_ie.file_id)"
<wysek> (Pdb) up
<wysek> > /usr/lib/python2.5/site-packages/bzrlib/plugins/svn/commit.py(319)dir_editor_send_changes()
<wysek> -> modified_files[child_ie.file_id](child_ie), child_editor)
<wysek> (Pdb) print new_inv.id2path(child_ie.file_id)
<wysek> tests/src/radardaemonTest/radardaemonTest.csproj
<wysek> (hmm, this is not thah binary file I was talking about)
<jelmer> what about "print new_inv.revision_id" ?
<wysek> None
<jelmer> wysek, what about "print base_revnum" ?
<wysek> 24
<jelmer> wysek, does that file exist in svn, and is it actually a file ?
<wysek> jelmer: it does not exist as the push process threw an exception
<wysek> btw, in bzr_last_rev it does not exist too, as I removed it from the bzr repo
<jelmer> wysek, so "print child_ie.file.id in base_inv" returns False?
<wysek> after up?
<wysek> *** AttributeError: 'InventoryFile' object has no attribute 'file'
<wysek> ok
<jelmer> sorry
<wysek> should be file_id
<wysek> returns True
<jelmer> yeah
<jelmer> wysek, that suggests the file should already be there in the svn repository
<wysek> well, the repo was empty before the svn-push
<jelmer> wysek: but it should exist now, since the push has partially succeeded
<wysek> which file? radardaemonTest.csproj?
<jelmer> wysek, yep
<wysek> well, it sort of exists. but it's in a different dir and it's name is different too.
<wysek> that is, radardaemonTest.csproj is the name in the last_bzr_rev (and the desired name)
<wysek> but in rev24 it is named differently and is in a differrent dir
<jelmer> wysek, 24 would be the name of the revision in svn
<wysek> (I've heard svn does not support filename changes or mv in a "normal" way)
<jelmer> wysek, not the bzr revno
<wysek> yeah, they differ by 1
<wysek> I mean the revno the svn-push process stopped
<wysek> so what now?
<wysek> any ideas?:)
<jelmer> wysek, is this bzr repo public?
<wysek> jelmer: no
<jelmer> wysek, so the "svn log -v" output doesn't match the "bzr log -v" output for the revisions already pushed?
<wysek> for the revs pushed it matcheds
<wysek> *matches
<jelmer> wysek, do the contents of that particular file match?
<wysek> the rev it stopps is full of binary_files add and files moves
<wysek> jelmer: yes
<wysek> ok I've found sth
<wysek> in bzr_rev 24 there is :
<wysek> renamed: radardTest => tests/src/radardaemonTest/radardaemonTest.csproj
<wysek> removed: radardTest/radardTest.csproj
<wysek> as I remember I did some renames automatically and I did a mistake
<jelmer> wysek, ah, that may be it
<wysek> I renamed a dir into a filename
<wysek> somehow I got the file back
<jelmer> wysek, so
<jelmer> wysek, radardTest is a directory
<jelmer> wysek, and tests/src/radardaemonTest/radardaemonTest.csproj is a file ?
<wysek> right
<jelmer> wysek, please file a bug about this
<jelmer> wysek, I'll see if I can commit a test + fix for this this afternoon
<wysek> is it a bug with bzr or bzr-svn??
<wysek> I think its bzr bug as it shouldn't allow me such a change, I think
<wysek> (or at least, without a warning)
<jelmer> wysek, it's a bzr-svn bug
<jelmer> I think such a change is allowed
<jelmer> it's not a really common kind of change though..
<wysek> I don't know what bzr actually did as the order of file/dir name changes is important in this case
<wysek> if bzr did well then it's a bzr-svn bug :)
<wysek> I'll try to recreate the bug first, and then file it
<wysek> ok I recreated the bug
<wysek> but
<wysek> I still think it's a bzr bug
<wysek> what I did is:
<wysek> I had: dir1/ dir2/ dir2/file1
<wysek> then I did: bzr rm dir2/file1 ; bzr mv dir1 dir2/file ; rm -r dir2/file ; echo "new file contents" > dir2/file
<wysek> then bzr commit
<wysek> log says:
<wysek> removed: dir2/file1
<wysek> renamed: dir1 => dir2/file1
<wysek> modified: dir2/file1
<wysek> it does not say that a dir changed into a file :)
<abentley> wysek: When you did "bzr rm", you told bzr that you deleted the file.  If you wanted to change the file type, you should have just used "rm".
<wysek> abentley: I did that by a mistake. I didn't want to revert the changes as there were too many changes.
<vila> mthaddon, spm, herb: PQM stucked again, should be the moon...
<vila> herb: I don't know if you changed the way you kill whatever process but the yesterday occurrence was slightly different than usual
<herb> vila: how so?
<vila> the merge succeeded, yet the public branch didn't contain it... is pqm using some sort of local branch and push regularly ? (The next sumbision went well and made the first merge apparent)
<wysek> jelmer: I've just submitted a bugreport
<herb> vila: that's strange. I don't know what would have caused that.  pqm should build a fresh tree every time from the public branch.
<jelmer> wysek, thanks
<vila> Also, I think poolie has a fix for it in the bzr-email plugin but 1) I'm not sure, 2) I don't really know what should be done to get that fix taken into account on pqm (but don't spend time investigatin until we at least try that fix)
<jelmer> abentley, a kind change while keeping the file id is allowed inside bzr though, right?
<jelmer> abentley, even if not recommended
<abentley> jelmer: Sure thing.
<wysek> ok thanks a lot, cu guys
<herb> vila: should be fixed now.
<vila> herb: sounds like some thing happened, http://bazaar-vcs.org/bzr/bzr.dev/ doesn't mention revno 4064 (revision-id:v.ladeuil+lp@free.fr-20090227084553-ritia8ukxh8i25po)
<vila> s/some/same/
<vila> grrr
<vila> herb: yet, I'm pretty sure the merge succeeded, is there some mirroring between pqm and bazaar-vcs.org ?
<jimmy_dean> anyone know if it's possible to push a local bzr branch up to a central repository with tortoisebzr?
<barry> jelmer: hi!  it's morning here in dc, so i want to try to find some time today to get bzr-svn 0.5.2 up on code.py.org
<herb> vila: no.  pqm commits to the public branch at the end of the run if the test suite completes successfully. It *may* do that after the email is sent though. I don't know pqm internals well enough to comment on that.
<vila> herb: ok, thanks for the help anyway. I'll have to resubmit with crossed fingers :-/
<jimmy_dean> it doesn't seem like the functionality is in there yet and I just want to make sure I didn't miss it somewhere
<RaceCondition> is it possible to have bzr generate patches to reverse existing patches?
<RaceCondition> I wan't to revert the effect of a certain patch
<luks> bzr merge (X-1)..X
<luks> er
<luks> bzr merge -r (X-1)..X
<luks> actually, still wrong
<luks> bzr merge -r X..(X-1)
<RaceCondition> and I can also do bzr merge -r (X-n)...(X-m)?
<luks> you can use any revision range
<RaceCondition> and the range is inclusive on both ends, right?
<RaceCondition> so when I do -r 19..9, all revisions from 9 to 19 including 9 and 19 are reverted?
<luks> if you are talking about revisions, then yes
<RaceCondition> yeah
<luks> it will take revision 19 and revision 9
<luks> and compare them
<RaceCondition> $ bzr merge -r 19..9
<RaceCondition> bzr: ERROR: No location specified or remembered
<luks> use . as the location
<RaceCondition> ok
<RaceCondition> and is it also possible to delete existing patches?
<luks> bzr doesn't have patches, you mean revisions?
<RaceCondition> looks like the 19..9 range was a bit wrong because some changes were not reverted
<RaceCondition> revisions, yeah, same thing..
<luks> no, it's all immutable
<luks> the point is that revisions are states, not changes
<luks> maybe the range was incorrect
<RaceCondition> it's all immutable? like SVN?
<RaceCondition> that's bad
<luks> "more" immutable than SVN :)
<RaceCondition> is there just some way I can simply return to a specific revision?
<vila> herb: right, this is getting more obscure by the minute :-) pqm now refuses to merge saying there is nothing to merge, yet the branch it is asking to merge contain my revisions :-) Oh well, I think we need to escalate that :) lifeless ?
<luks> do you want a new branch completely ignoring the old revisions or the existing branch changed to have files like in the old revisions?
<RaceCondition> luks: looks like the range is non-inclusive
<RaceCondition> 19..9 means 19-10 really
<luks> RaceCondition: because you are thinking in changesets, not revisions
<luks> the -r option specificies revisions
<RaceCondition> whatever
<RaceCondition> I mean, even revision wise, this could still have been inclusive
<luks> they are
<luks> 19..9 does exaclty this: take revision 19, take revision 9, compare them and apply the reversed patch
<herb> vila: what was your change?
<vila> revno 4064 (revision-id:v.ladeuil+lp@free.fr-20090227084553-ritia8ukxh8i25po)
<herb> vila: was that a change to the NEWS file?
<vila> herb: revno 4063 v.ladeuil+lp@free.fr-20090227082909-6i864fof6qyksm87 includes a change to NEWS, 4064 fixed a 2.4 compatibility bug in bzrlib/transport/ftp/__init__.py
<vila> the submission includes both
<herb> vila: ok.  I'm going to get the tree in a state where you can submit 4063 and 4064 again.  give me a couple of minutes.
<vila> herb: ok, so the tree is refreshed instead of created from scratch then ?
<herb> vila: it seems that way.
<jam> morning all
<beuno> hiya jam
<barry> jam: morning!
<barry> jelmer: any possibility of getting bzr-svn 0.5.2 into the ppa?  i'd really love to update code.py.org today
<jam> hi beuno, barry
<herb> vila: try to submit now. it should work.
<vila> herb: thanks, done
<jelmer> barry, I've just uploaded to the PPA (hardy only)
<barry> jelmer: perfect!  let me see if i can grab it.  thanks
<jelmer> barry, it'll take some time to build
<barry> jelmer: right!  okay, i'll wait a bit, thanks
<jelmer> Is there any chance brisbane-core is going to make it into 1.13?
<jam> jelmer: I think we are targetting late March, after the next get-together
<jelmer> ah, hmm
<jam> I *just* got it to the point where inventory compression is reasonable
<jelmer> so the OOo folks won't be able to take that into account
<jam> we've had excuses to push things earlier based on real-world needs
<jam> but I think we'd like to make this one a bit more polished
<jam> We might have it as a '--development' in 1.13, but I don't think OOo would count that, right?
<jelmer> I have no idea
<jelmer> they said "released versions", so I guess not
<jelmer> converting to 1.9-rich-root is a real PITA, took me a whole night to do 30k revisions
<barry> jelmer: ROCK!  time bzr pull on the 2.5 branch: 1m8s :)
<jelmer> barry: :-)
<barry> jelmer: thanks so much.  i'm wondering if i should try svn-import again?
<barry> jelmer: i have branches = ... in my subversion.conf file, which should limit to just the branches i care about, right?
<barry> jelmer: that does not include the 2.0 branch which we were having problems with
<jelmer> barry, yep
<jelmer> barry, in that case, I think it should work
<barry> jelmer: let's give it a shot!
<jam> jelmer: do you know if the caching changes I gave you had a perf impact for importing something like OOo?
<jelmer> jam, I haven't tried yet
<vila> herb: submitted and... stucked again, not my day :-)
<herb> vila: boo
<herb> vila: ok. I'll see if I can clear it up.
 * LarstiQ gets confused trying to preserve merged revisions with bzr-svn pushing back to svn
<rbriggsatuiowa> is there a quick way I could find what revision I deleted a file in?
<LarstiQ> rbriggsatuiowa: other than looking at `bzr log -v`?
<vila> herb: I submitted once again but with a different public branch, let's see if it works better
<herb> vila: I was going to suggest breaking it up into two commits to see if one part or the other is causing a problem.
<herb> vila: but we'll go ahead with this.
<rbriggsatuiowa> yeah - my bzr log -v is dragging down my machine
<vila> herb: I usually submit a single revision and still encounter the problem, so I'm pretty sure this isn't related
<herb> ok
<barry> jelmer: ping
<jelmer> barry, pong
<barry> jelmer: hi.  bzr svn-import pulled in too much it seems
<jelmer> too much?
<barry> jelmer: well, i wanted to limit it to updating only the 5 or so branches that we're publishing through bzr, but it pulled in everything under http://svn.python.org/projects
<barry> jelmer: i guess what i'm trying to mimic is say 'bzr pull in each of the 5 branches i care about' and ignore everything else in that svn repo
<jelmer> barry, what was the output from svn-import exactly?
<barry> jelmer: it didn't really output much except for the progress bar, which i didn't watch too closely
<jelmer> barry, there should be a line saying what repository layout it was going to use
<barry> jelmer: if it did, it didn't survive my control-C :/
<barry> jelmer: but the subversion.conf now has branching-scheme = trunk1 branching-scheme-guess = trunk1
<jam> barry: sounds like it didn't see your specific listing request
<jam> or I had you format it wrong, etc
<barry> jam, jelmer let me pastebin what i've got
<jelmer> ah, of course..
<barry> jam, jelmer http://pastebin.ca/1348884
<jelmer> barry: branches = * won't work with v3 mappings
<barry> ah
<barry> sounds like i really want to update to v4 ;)
<barry> well, for now i think i'll just cron a 'bzr pull' in each directory separately
<barry> and when/if the experiment ends, i'll do things the right way at that time
<barry> with bzr-svn 0.5.2, those are very quick now! :)
<barry> jam: we talked about doing the bzr pack.  should i do that in the shared repo directory or in the individual branch directories?
<barry> <barry> ah
<barry> <barry> sounds like i really want to update to v4 ;)
<barry> <barry> well, for now i think i'll just cron a 'bzr pull' in each directory separately
<barry> <barry> and when/if the experiment ends, i'll do things the right way at that time
<barry> <barry> with bzr-svn 0.5.2, those are very quick now! :)
<barry> * thekorn_ (n=markus@a89-183-70-151.net-htp.de) has joined #bzr
<barry> <barry> jam: we talked about doing the bzr pack.  should i do that in the shared repo directory or in the individual branch directories?
<jam> barry: so first off, I see your repo got quite a bit bigger, is this because of the extra branches? or is there just a lot of stuff going on?
<jam> and you run 'bzr pack' at the root of the repo
<barry> jam: i think it's because of all the extra branches i got with svn-import
<barry> jam: i guess there's no way to clear that out?
<jam> barry: well, branch out to another repo, and then bring it back, but not easily
<jam> for now, we'll just live with it
<barry> jam: dang.  yeah
<jam> it shouldn't impact things *too* much
<jam> barry: though I seem to see about 200MB *more* data that was just brought in
<jam> perhaps there is a mapping issue causing the data to be copied 2x ?
<jam> ugh
<jam> barry, jelmer: I see a mix of "svn-v3-trunk1" and "svn-v3-single1" in the index files
<jam> which certainly sounds like a mismatched conversion
<barry> jam: it's certainly possible that i f'd up somewhere ;)
<barry> jam, jelmer the pack is finished
<jam> barry: well, it just sounds like you effectively have 2 different conversions
<jam> stored in the same repo
<jam> which is a bit less than ideal
<barry> jam: that doesn't sound good ;)
<jam> since instead of being a 200MB repo, it is a 400MB now
<barry> jam: that could affect branch times for clients, right?
<jam> barry: so we should only be copying half the data, but it means seeking through the other data as we do it
<jam> jelmer: do you know how you would get "svn-v3-single1" mapping?
<jam> Is that what you get when you do "bzr branch" instead of "bzr svn-import" ?
<jelmer> jam: Yes, that's what bzr-svn will use if the branching scheme it's determined doesn't match
<jam> barry: so looking closer, it seems the only extras might be:
<jam> sandbox%2Ftrunk%2F2to3
<jelmer> jam: (also specific to v3, v4 will always create the same svn-v4 mappings)
<jam> is that one of the important branches?
<barry> jam: no, that's one of the ones i don't care about and deleted after killing the svn-import
<jam> barry: so what are the *specific* branches you are interested in?
<jam> (I'm a bit confused between '2.6/' and 'experimental/2.6' and some other such differences)
<barry> jam: 2.5, 2.6, 3.0, py3k, trunk
<jam> barry: and probably the 'users/'?
<barry> jam: the experimental stuff is not the svn mirrors
<jam> (though I assume those are native bzr branches)
<barry> jam: right, users too
<barry> i guess we care about experimental but i don't think anyone's using it afaik
<barry> i don't even know what shared is for
<barry> jam: perhaps we should get rid of experimental and shared
<vila> herb: sorry for the delay, my last submission (using an http: public branch instead of a lp: one) went through
<herb> vila: good news
<vila> herb: I'll stick to that until I'm in a better position to diagnose the problem, I'm not sure using http is the right solution (I seem to remember having problems with that too, but my memory is blurry (it's hard to keep straight facts which such transient bugs))
<luke-jr> How can I clear the related branches (pull, push, submit) info?
<james_w> luke-jr: there's currently no way through the UI
<james_w> luke-jr: you can delete the entries from the config files
<james_w> .bzr/branch/branch.conf or ~/.bazaar/locations.conf
<Spaz> hm
<tyhicks> I'm trying to figure out how to get a unified diff with commit message out of bzr.  Google suggests that it it isn't possible, is that still the case?
<LarstiQ> tyhicks: you'll have to be a bit more specific. diff and log produce that output, so what about that isn't good enough?
<LarstiQ> tyhicks: or do you mean log -p?
<tyhicks> LarstiQ: Well those are 2 different commands - maybe I'm being selfish in wanting it done in a single command?
<LarstiQ> tyhicks: you're not being selfish
<tyhicks> LarstiQ: I need to post a patch to a bugzilla ticket
<LarstiQ> tyhicks: oh, in that case, use `bzr send`
<LarstiQ> tyhicks: assuming the project uses bzr, maybe I shouldn't have assumed so?
<tyhicks> LarstiQ: Yes, my project uses bzr
<LarstiQ> tyhicks: this would be easier if I had enough context information :)
<LarstiQ> tyhicks: ok, then `bzr send` sounds like the way to go
<Spaz> i'm having issues with bzr svn-import
<Spaz> [root@ind-prod003 /home/awos-bzr/repo]# bzr svn-import https://awos.svn.sourceforge.net/svnroot/awos .
<Spaz> bzr: ERROR: Not a branch: "https://awos.svn.sourceforge.net/svnroot/awos/".
 * tyhicks runs off to play with bzr send
<LarstiQ> Spaz: is bzr-svn listed in `bzr plugins` ?
<Spaz> just svn
<LarstiQ> right
<LarstiQ> Spaz: bzr: ERROR: [Errno 0] Path 'https://awos.svn.sourceforge.net/svnroot/awos/' is not canonicalized; there is a problem with the client.
<LarstiQ> Spaz: is what I get
<Spaz> hm
<tyhicks> LarstiQ: I'm still missing something with bzr send. I've already written up a nice commit message - but bzr send doesn't seem to include it in the unified diff.
<LarstiQ> tyhicks: the produced bundle actually includes all metadata
<LarstiQ> tyhicks: so you can bzr pull/merge that file
<tyhicks> LarstiQ: But that bundle means nothing to the package maintainer who is viewing the bugzilla ticket
<tyhicks> LarstiQ: No worries, I piped bzr diff to a file and copied the commit message from bzr log to the top of the diff. That doesn't take too long to do by hand
<LarstiQ> tyhicks: I thought you said the project was in bzr?
<tyhicks> LarstiQ: It is in bzr, but this is an external bug tracker and people viewing the bug need to see the commit message, not the bzr bundle
<LarstiQ> maybe I'm too tird to make sense of this
<LarstiQ> tyhicks: so what I think the maintainer would do, is bzr pull url/to/bug/tracker/attachement
<LarstiQ> tyhicks: and get your changes
<LarstiQ> tyhicks: no monkeying with diff and patch
<Spaz> grr
<LarstiQ> tyhicks: but if you want to do things manually, look at `bzr log -p` from 1.12+
<Spaz> what's the best (most reliable) way to migrate a bzr repository to svn
<Spaz> i can't make a dump unfortunately
<Spaz> as the repo is hosted on sourceforge
<LarstiQ> Spaz: svn->bzr or bzr->svn?
<Spaz> LarstiQ, svn->bzr
<LarstiQ> Spaz: I would use bzr-svn
<tyhicks> LarstiQ: They could do a pull, but it would be nice if they could simply view the patch and commit message in a vcs agnostic way in the bug ticket
<Spaz> that requires a dump
<Spaz> i can't get a dump as aforementioned
<tyhicks> LarstiQ: Thanks for the help, I will take a look at bzr log -p as well
<LarstiQ> Spaz: it doesn't, are you thinking of svn2bzr?
<LarstiQ> tyhicks: hmkay, I don't understand your use case then
<LarstiQ> Spaz: it does seem like the svn repo is acting up
<Spaz> ooh, apparently i can get an svn dump via rsync
<Spaz> hm
<radix> yeah, bzr-svn doesn't need an SVN dump
<Spaz> LarstiQ, i tried bzr-svn but it gave me errors
<Spaz> and an inconsistent repo which made bzr reconcile crash
<LarstiQ> jelmer: ^^
<tyhicks> LarstiQ: The use case is that not everyone uses bzr and lp. Sometimes individual patches have to be carried by maintainers, patches need to be shared through email, etc.
<tyhicks> LarstiQ: I was just looking for a vcs agnostic way to share a diff and the commit message I already wrote for it
<LarstiQ> tyhicks: That I get, but doesn't match my understanding of what you described.
<LarstiQ> tyhicks: well, log -p for the simple case then
<tyhicks> LarstiQ: cool, thanks again!
<LarstiQ> tyhicks: little bit more involved if you need to roll up more than one revision
<jelmer> Spaz: If you can make bzr-svn 0.5.x do that, I'd be very interested in a bug report..
<LarstiQ> jelmer: I can make 0.5.x do that
<LarstiQ> jelmer: oh, depends on what you mean with 'that'
<LarstiQ> jelmer: bzr ls 'https://awos.svn.sourceforge.net/svnroot/awos/'
<LarstiQ> jelmer: for the canonicalized path
<LarstiQ> and now I'm going to bed, ciao
<jelmer> LarstiQ, the making reconcile crash
<LarstiQ> jelmer: that, I don't know how to do
<Spaz> jelmer, i'm using 0.5.2
<Spaz> jelmer, atm it doesn't work on my fbsd box, it works fine on my linux box but it results in a corrupted repo
<jelmer> Spaz, public repo ?
<Spaz> the repo isn't public
<Spaz> but i can give you a tarball
<Spaz> (well, not public yet, getting it ready)
<jelmer> I'd be interested in a copy of the svn repo
<jelmer> Not aware there are any corruption bugs left
<Spaz> jelmer, https://awos.svn.sourceforge.net/svnroot/awos/, or get the raw repo by rsync -az awos.svn.sourceforge.net::svn/awos/ /foo/bar/
<jelmer> LarstiQ, fixed that one
<jelmer> Spaz, imports fine here, at least trunk
<jelmer> Spaz, what exactly goes wrong on your end?
<Spaz> hm
<Spaz> jelmer, http://pastebin.ca/1349026
<Spaz> on checkout
<jimmy_dean> ok, so my co-worker had bzr delete a file (unintentionally) today when trying to do a commit to a bound branch
<jimmy_dean> is there any kind of condition where this would happen because it's obviously not desirable
<Spaz> jelmer, as for reconcile
<Spaz> jelmer, http://pastebin.ca/1349028
<jimmy_dean> he did: bzr add myfile.doc
<jimmy_dean> bzr commit
<jimmy_dean> said his bound branch was out of date so he did "bzr commit --local"
<jimmy_dean> bzr update (at this point his file was gone)
<Spaz> jelmer, that's the result of doing bzr svn-import https://awos.svn.sourceforge.net/svnroot/awos/ .
<Spaz> on the box it actually works
<Spaz> on
<Spaz> jelmer, should i just try doing trunk/branches separate?
<jelmer> Spaz, ah, I think I can reproduce it as well now
<jimmy_dean> anybody have any ideas? I can't seem to reproduce this myself
<jelmer> jimmy_dean: Did he perhaps do a bzr revert after the update?
<jimmy_dean> yes he did
<jelmer> jimmy_dean, that would explain it
<jelmer> jimmy_dean, "bzr up" will turn local commits into pending merges
<jelmer> and "bzr revert" removes pending changes, including pending merges
<jimmy_dean> jelmer, but the bzr revert was done after he had already lost the file
<jelmer> Spaz, looks like a bzr-svn bug
<Spaz> whee.
<jelmer> Spaz, it's not picking up the fact there are old bzr-svn revisions in that svn repo for some reason
<Spaz> jelmer, any workaround?
<jelmer> Spaz, no idea what's causing it yet
<Spaz> ah ok
<jimmy_dean> jelmer, I have the .bzrlog file from his Windows machine, mind taking a look at it on pastebin?
<jelmer> jimmy_dean, sorry, already kindof busy looking into this bug spaz is running into
<jimmy_dean> oh ok, thanks anyway!
<jam> jimmy_dean: I'll take a peek
<jimmy_dean> jam: thanks, one sec
<jelmer> Spaz, found it
<Spaz> hm?
<Spaz> jelmer, where is it? :o
<jimmy_dean> jam: ok
<radix> aw dang, bzr-svn isn't built for dapper?
<jimmy_dean> jam: the file to look for in the log is: Battery Controller CoProcessor Specifications.doc
<jimmy_dean> jam: http://pastebin.ca/1349047
<Spaz> jelmer, the reconcile problem was discovered a while ago: https://bugs.launchpad.net/bzr/+bug/297024
<ubottu> Ubuntu bug 297024 in bzr "bzr reconcile crashes" [Undecided,New]
<jam> jimmy_dean: there is no 'update' or 'commit' in this log
<jam> perhaps in ".bzr.log.old" ?
<jam> (we keep 1 level of backlog)
<jelmer> Spaz, that's just a similar traceback, it's a different bug
<jimmy_dean> jam: I truncated it, perhaps I was too aggressive, let me paste the whole thing
<jimmy_dean> jam: http://pastebin.ca/1349052
<jelmer> Spaz, I've pushed a fix
<jelmer> Spaz, You'll have to remove ~/.bazaar/svn-cache and your existing repo
<Spaz> ok
<jam> jimmy_dean: so.. it looks like it was an 'update' triggers a merge, which failed half-way through because of an open file, and then the following update finished, but the file was gone
<jam> the good news, is that you should be able to do "bzr heads --dead"
<jam> and find the revision that the branch used to be at
<jam> so you can do "bzr merge . -r revid:XXX"
<jimmy_dean> excellent, thanks...we'll give that a shot
<jml> jelmer: hi
<jam> I would have thought that a merger failing half-way through would have rolled-back the action, but I guess not
<jml> jelmer: so, I'm importing Twisted with bzr-svn using "bzr svn-import --incremental svn+ssh://svn.twistedmatrix.com/svn/Twisted Twisted"
<jelmer> jml: Hey!
<jml> jelmer: it's copied 20000+ revisions, but it's going really, really, really slowly on the last few thousand.
 * jelmer gives it a try as well
<jelmer> jml: how large is the tree?
<jml> jelmer: an svn checkout is 42M
<jml> < 2000 files and directories.
<Spaz> jelmer, http://pastebin.ca/1349063
<Spaz> :S
<jimmy_dean> jam: success! my co-worker said I'm his hero, how you're my hero
<jelmer> Spaz, you need bzr.dev for bzr-svn trunk
<Spaz> ah ok
<jelmer> Spaz, sorry about that
<Spaz> eh it's fine.
<jam> jimmy_dean: always happy to help
<jimmy_dean> jam: so do you think that's a bug for bzr on Windows?
<jimmy_dean> because Windows is super aggressive in its file locking
<eix> jimmy_dean did you ever tried linux ?
<jam> jimmy_dean: sort of, yeah. we certainly should have an alternate way of resolving a locked file than aborting in the middle of an update
<jam> we'd still have to do some sort of conflict resolution
<jimmy_dean> eix: yes, I use Linux but this machine has to be Windows
<jimmy_dean> and he uses Linux for certain things
<eix> jimmy_dean no machine has to be Windows :-)
<jimmy_dean> eix: it does if only certain software runs on it
<eix> jimmy_dean use alternatives
<jimmy_dean> there aren't any
<menesis> same wiht my girlfriends computer - she has to use a certain licensed application for her job. but I admit I have not tried to run it under WINE...
<jelmer> jml: And you're using bzr-svn trunk?
<jelmer> jml: whoa, that's a lot of branches
<jml> jelmer: yes and YES
<jml> jelmer: Twisted's been using the same dev process as bzr and Launchpad except in Subversion :)
<jelmer> jml: nice :-) I think that's the first project I see that actually uses cheap branching in subversion
<radix> we could probably clean up a lot of the dead branches. I'm not sure when we did that last.
<jelmer> jam: What's this mutter message for:
<jelmer> 324.402  Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [336]
<radix> we're into swap on that svn server.
<radix> although I don't think it's actively swap*ping*
<radix> (how can I tell that?)
<jimmy_dean> eix: like SolidWorks for 3D modeling
<eix> jimmy_dean try blender ;)
<jimmy_dean> eix: I love Linux don't get me wrong, I'm sold out on it...but I also like to use the best tool per each job
<eix> jimmy_dean I'm really thirsty I want linux to be adopted in business world...
<menesis> is there a way to exclude branches by pattern using `bzr svn-import`?
<jimmy_dean> eix: Blender is not optimized for 3D modeling for creating industrial product that you'll send and have a factory make
<eix> not only for their damn servers
<eix> ah
<jam> jelmer: just tracking how we split up a request for XX files into YY bytes
<jimmy_dean> jam: I think I'll add my co-worker's experience as a bug and let the developers decide if it actually is one or not
<jelmer> jam: so that's mainly useful for remote transports, I guess?
<jimmy_dean> jam: thanks again for the help...you saved a month's worth of work redo
<jam> jelmer: generally, though it isn't really necessary overall
<jam> hence mutter()
<jam> we can remove it if it is causing you problems
<jelmer> it's ok, but a little bit verbose compared to everything else
<jml> jelmer: have you fixed anything performance related in bzr-svn over the last day or so?
<jelmer> jml: not really
<jml> jelmer: hmm. ok.
<jml> so, I'm wondering if this is a memory thing.
<jelmer> jml: If memory is a problem for you, do you have the latest subvertpy?
<jml> jelmer: yes.
<jelmer> I'm about to reach r1000
<jml> jelmer: of ~27k?
<jelmer> 1084/34680
<jml> jelmer: ok.
<vila>     while _tasks and now >= _tasks[0].timeout:
<vila> IndexError: list index out of range
<jelmer> jml: Is that similar to what you were seeing?
<jml> jelmer: I've hit Ctrl-C and restarted the process a couple of times now.
<vila> doh
<jml> so it's "copying revision 779/5703"
<jelmer> ah
<jml> "2439.492  Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1390946]
<jml> " is the last thing in the log.
<jelmer> jml: Strange, there shouldn't be a particular reason for it to get slower over time
<radix> could be the server?
<radix> but it doesn't seem to be under particular load. dunno
<jelmer> jml: That last bit is pretty large
<jml> jelmer: yeah. actually I'll pastebin a chunk of the log.
<jelmer> hmm, I need "bzr svn-import -j"
<radix> heh
<jml> actually I won't pastebin the log.
<jml> since it just interrupted itself, I think
<lifeless> moin
<jml> lifeless: good morning.
<lifeless> jml: nose uses 'inspect the exception in addError', and have a deprecated addSkip
<radix> interrupted? as in, blew up?
<lifeless> bzr uses inspect the exception in addError
<jml> lifeless: sweet.
<jml> lifeless: I like that way of doing it as well.
<lifeless> why
<jml> lifeless: because it makes the interface narrower and easier to use with other pyunit things
<jml> lifeless: what do you think?
<lifeless> jml: bzr does it that way to meet the pyunit protocol; I don't think narrow is particularly strong as a reason
<jml> lifeless: neither do I.
<lifeless> I want to change the protocol
<jml> lifeless: you want addSkip?
<lifeless> I think a stronger question is 'does the source of the skip event matter
<jml> lifeless: by "source", do you mean the test?
<lifeless> line of code
<jml> 85% mem usage :(
<lifeless> addError and similar interfaces give you a stack trace
<lifeless> so they pinpoint where it happened
<lifeless> addSuccess and similar don't
<jml> lifeless: so, I can't think of a use-case where I'd want that information beyond having the name of the test. But I can't think of a good reason to *not* have that information either.
<jml> lifeless: so I'm wondering why you think it's an important question?
<lifeless> if we start with the premise of designing for python inclusion; then the base classes for both test and result will be in sync, so 'pyunit compatibility' isn't hard any which way; so I then started thinking about how the different approaches vary
<jml> jelmer: is it possible that there's a particularly troublesome revision?
<jelmer> jml, could be; a particularly big file, for example
<jelmer> jml: Did you re-build subvertpy ?
<jml> jelmer: I got the trunk for it and ran python setup.py install
<Ollie_R> is there anyway to get a readout of transfer speeds when doing a bzr co over sftp. There is a progress bar but it is very vague, and seems to jump in large chunks which is not especially useful. The verbose argument also doesn't give any more info
<jml> jelmer: but that was 1-2 days ago. haven't done anything to it since.
<jml> Ollie_R: what version of bzr are you using?
<jelmer> jml: That should do it
<Ollie_R> jml: i believe 1.5 let me check
<jelmer> jml: another copy of subvertpy installed by PPA perhaps?
<jelmer> I'm at 3500 now
<Ollie_R> Bazaar (bzr) 1.3.1 on both client and server/repo
<jml> Ollie_R: upgrade. the progress bar is substantially improved.
<jml> (as indeed is the rate of progress :))
<Ollie_R> ah ok great
<Ollie_R> do both client and server need to be running the same versions?
<lifeless> jml: what i have so far is 'addSkip is clearer for implementors of Results; it can have a exc_info if desired; its not innately compatible with existing TestResult objects that didn't subclass TestResult'
<jml> jelmer: I can't find a python-subvertpy or a python2.5-subvertpy package
<lifeless> jml: 'addError is unclear for implementors as they don't have a full list of exceptions-that-are-skips, that-are-expected-fail, etc; using addError will mean that tests that skip show up as errors rather than as test-framework issues, and using addError defines that there will be a stacktrace'
<fullermd> Ollie_R: Not in theory at least.  I run with a 1-2 version skew pretty regularly without problems.
<fullermd> I've never tried a ~9 version skew, but I would guess it works OK (though it may not show much improvement on some things, since both sides wouldn't support $SOMETHING_NEW)
 * jml afk
<Ollie_R> the version labelling is kind of strange bzr 1.1rc1 2008-01-05 bzr 1.9 2008-11-07 bzr 1.10rc1 2008-11-28 bzr 1.11rc1 "Eyes up!" 2009-01-09. Expected it to go to 2.0 - kind of strange
<fullermd> It can't go to 2.0 until it can read email.  Law of nature.
<Ollie_R> fullermd: being serious?
<fullermd> I'm always serious.
<fullermd> Or is it never?  One of the two.
<Ollie_R> hah
<Ollie_R> so which version is considered stable atm
<radix> Ollie_R: that's not really strange at all
<Ollie_R> just noticed i am running 1.5 on my macbook
<lifeless> Ollie_R: 1.12
<fullermd> The latest release, generally.
<radix> Ollie_R: versions are not decimal
<radix> this is pretty common in lots of software
<Ollie_R> radix: hmm some apps go from 1.9 to 2.0 though. So if something is 1.9 you have no reference if it is going to go to 2.0 or 1.10,,,
<fullermd> Well, lots of apps go from 1.4 to 2.0 too..
<fullermd> Heck, bzr went from 0.18 to 0.90, which is still WAY weirder in my book.
<jml> lifeless: let me think out loud for a bit
<Ollie_R> well my box here is 1.3.1 which at a glance looks like a newer version than 1.12 so that seems odd to me
<Ollie_R> neways all a little irrelevent
<radix> once you internalize the fact that versions aren't decimal, you'll get over it :)
<Ollie_R> radix: yep
<jml> lifeless: the way I see it, there are two ways to add more types of events to unittest: add more methods to the listener interface or enrich the object that represents the event
<fullermd> It would probably confuse more people if we called it "1.C"   :p
<jml> lifeless: I guess if I wrote unittest in the first place, I would probably have defined a TestResultEvent class and sent those to TestResult, rather than the multiple-method approach they have now
<jml> lifeless: incidentally, you used to consider "using addError will mean that tests that skip show up as errors rather than as test-framework issues" to be a good thing
<jml> lifeless: have you changed your mind?
<lifeless> jml: that was designed around pyunit
<lifeless> jml: I'm designing for pyunit now
<jml> lifeless: :D
<jml> lifeless: part of our "ply mwhudson with whisky until he commits testtools to trunk" plan?
 * mwhudson blinks
<jml> mwhudson: sssh. it's a secret plan.
 * mwhudson goes away again
<mwhudson> oh, cpython trunk?
<jml> yeah.
<jml> lifeless: what do you want addSkip's parameters to be?
<jml> lifeless: and how do you see this interacting with Feature support.
<lifeless> jml: I thought it was offer mwhudson whiskey but withhold until he commits it
<jml> lifeless: it's a delicate balance.
<mwhudson> alka seltzer would be a better inducement this morning, i think
<jml> mwhudson: :)
<lifeless> jml: so that was why the question about exc_info relevance
<lifeless> jml: I think TestResultEvents are messages, and xUnit has a smalltalk heritage where messages are messages
<lifeless> jml: which is to say TestResultEvent isn't any better than explicit method calls for this, IMO
<Ollie_R> am i right in thinking that if i do a light checkout from a to b then i can't do a checkout from b to c ?
<lifeless> Ollie_R: if you do a checkout from b to c, it will be a checkout from a to c
<lifeless> Ollie_R: if you want multiple branches, the branch command makes new branches
<Ollie_R> i want to start using bzr to deploy websites. so i have a repo and my develoeprs checkout locally. Then my website is a checkout of the repo which I update as and when i need to
<lifeless> I suggest you use the bzr-upload plugin
<lifeless> developed by a guy at a website hosting company :)
<Ollie_R> but obviously as the dir is going to be web enabled I don't want people to be able to checkout from my actual website
<Ollie_R> lifeless: yeah i know of it
<jml> lifeless: that's why I'm interested in addSkip's parameters :)
<brutimus> the authentication ring (authentication.conf) stuff made it into mainline, right? (this stuff http://bazaar-vcs.org/DraftSpecs/AuthenticationRing)
<lifeless> brutimus: yup
<brutimus> ok thank you lifeless.. i must be doing it wrong then :-)
<billiejoex> I'm sorry, I'm trying to get a copy of bazaar source branch but I get this error: http://rafb.net/p/b4T8mc45.html
<lifeless> jml: I think that addSkip(test, str()_able_reason) is minimal and meets the needs of all tests I've seen
<lifeless> billiejoex: you have an older version of bzr
<jml> lifeless: are you planning on using skip for features?
<jml> lifeless: and how do tests signal a skip
<Ollie_R> yeah bzr-upload plugin isn't quite right as oddly I want to be able to commit from the live checkout to send back the users files added to the live site via a cms.
<Ollie_R> basicially normal bzr will work i just need to prevent people checking out from http://www.example.com/ when the site is live
<jelmer> lifeless: it's a bit unfortunate that lenny has 1.5, making it impossible to checkout bzr.dev :-/
<Ollie_R> bzr-upload basicially just looks like bzr revision history linked in with a rsync
<lifeless> Ollie_R: checkout --lightweight will have that property; but just blocking the .bzr dir in apache will have it too
<Ollie_R> lifeless: ok brilliant thanks for that bit of info, cleared things up nicely. Hadn't considered doing this via apache actually
<billiejoex> lifeless: 'm using the latest 1.12 version
<lifeless> billiejoex: 1.12 can read 1.9
<lifeless> billiejoex: what does 'bzr --version' show ?
<billiejoex> lifeless: 1.6.1
<lifeless> billiejoex: then thats the version you're actually using
<billiejoex> I thought I did get the 1.12 version :\
<lifeless> :>
<lifeless> jml: not sure re: features
<lifeless> jml: TestCase.skip(), like TestCase.fail()
<lifeless> jml: I'd kind of like TestCase.succeed() too ::
<jml> lifeless: so it would raise an exception?
<lifeless> yes, to allow dropping out of an arbitrary call depth
<lifeless> which lets people write helpers to decide when to skip
<jml> lifeless: what use cases are there for skip besides missing features?
<lifeless> jml: expensive test, and expensive test mode not on
<lifeless> jml: test enumeration [in a sick sort of way :P]
<lifeless> jml: users may find others; probably will in fact :)
<rasker> hi, how does one use the --stacked option in bzr branch?
<jml> lifeless: those are good use cases.
<jml> lifeless: so, I am thinking that missing features is a special kind of skip
<jml> lifeless: is that the way it's done in bzr right now?
<rasker> anyone?
<jml> rasker: what are you trying to do?
<lifeless> jml: self.requireFeature raises UnavailableFeature, which is not a subclass of SkippedTest, and there is an addNotSupported on bzr's TestResult
<lifeless> jml: I'd be comfortable mapping that to skipped, at least for now
<jml> lifeless: ok.
<jml> lifeless: so I'm happy enough with adding addSkip.
<jml> and not imposing any extra burden on addError.
<rasker> jml I'm looking at a project that contains one feature/bugfix per branch. I'm writing a script that automatically merges a few branches against the release branch to see if anything breaks (sort of like 'continuous integration'). I'm thinking I can use the --stacked option to pull in the branches, stacked against the release branch
<rasker> jml does that make sense?
<jml> rasker: sure.
<jml> rasker: probably easier than using stacked is to use shared repos
<lifeless> jml: revno12 is tip ?
<jml> rasker: so, bzr init-repo <project>; cd <project>; bzr branch <trunk url> trunk; bzr branch <branch url> <branch name>
<jml> rasker: that second "branch" command will only fetch revisions that are in the branch but not in the trunk branch.
<jml> lifeless: yes
<jml> lifeless: man, it runs the full test suite in 0.006s -- why can't all my projects be like that.
<rasker> jml right, I see. so the amount of data downloaded from launchpad for a trunk plus a bunch of it's development branches for example would be less?
<rasker> for each branch
<jml> rasker: yes. (if I understand you correctly)
<jml> rasker: the trick is running init-repo in a directory above the branches.
<rasker> jml great! Just what I was looking for. Just for interests sack then, how does stacked work (the docs are a bit hazy)?
<lifeless> jml: because most of your projects do a bunch of things
<jml> rasker: so, roughly speaking, a repository is a bucket for revisions
<jml> rasker: a stacked branch is a branch whose bucket is missing most of its revisions, but has a pointer to another branch where those revisions can be found.
<rockstar> jml, I branched difftodo.  I have a patch that I'll want you to look at on Sunday.
<jml> rockstar: awesome
<jml> rockstar: why don't you submit a merge proposal?
<rockstar> rockstar, I will when I'm not on a semi-hostile network.
 * jml wants to use the sexy new diff generation stuff on Launchpad
<jml> rockstar: ahh ok.
<jml> rockstar: where are you right now?
<rockstar> jml, you've seen thumper's MAD, right?
<rockstar> jml, in the Denver airport.  They're boarding now.
<jml> rockstar: I've seen its effects, not the actual code.
<rasker> jml, ok, that makes sense. the repository then contains 'full' or complete branches? or is it something like, a repository uses stacked branches internally?
<rockstar> jml, can you submit merge proposals for junk branches?
<jml> rockstar: no you can't
<rockstar> I didn't think so.
<jml> rockstar: I guess I should register a project.
<rockstar> Make a project please.
<rockstar> :)
<jml> rasker: not quite
<jml> rasker: repositories don't contain branches
<jml> rasker: they just contain revisions.
<jml> rasker: quite often a branch contains its own repository
<jml> rasker: this is what happens in the default case when you do 'bzr branch <foo>'
<lifeless> difftodo is your python pending thing?
<jml> lifeless: yeah.
<lifeless> cool
<lifeless> well, I'm -> lunch event
<lifeless> I have testtools
<lifeless> will make a skipped thing I think is beautiful
<jml> lifeless: sweet.
<jml> rasker: so, when you run init-repo in dir1/ and then branch to dir1/dir2/, Bazaar finds the repository in dir1/ and sticks all the revisions in there.
<jml> rockstar: https://edge.launchpad.net/difftodo
<jml> oh wait. the branch.
<rasker> jml ok so repositories are more flexible and --stacked is basically used to save space?
<jml> rasker: again, not quite :)
<rasker> :)
<jml> rasker: all branches have repositories whether you like it or not -- most of the time you don't have to care about this fact though
<jml> rasker: both stacking and *shared* repositories are used to save space and prevent unnecessary network transfer.
<rasker> jml perhaps if you could give me an example of where --stacked would be used I could differentiate them better?
<jml> rockstar: https://code.edge.launchpad.net/difftodo
<jml> rasker: perhaps, but no example is leaping to mind and it's past time for my morning shower :)
<lifeless> rasker: --stacked is used to get a branch which *can only be used while online* but downloads less data [it skips all the history]
<jml> rockstar: have a good flight
<lifeless> rasker: a shared repository is used to allow many branches with common history to share the storage of their history
<lifeless> rasker: imagine you have 1GB of history, and a working tree of 50MB
<lifeless> rasker: a shared repository will need to download that GB.
<lifeless> rasker: a stacked branch will download ~50MB
<lifeless> rasker: but you can't use the stacked branch without being connected to the server that has the rest of that 1GB
<lifeless> rasker: for many small but related branches a shared repo will work better - more setup time but you get offline support
<rasker> jml lifeless !!!! Ok I finally understand !!!! Thank you both for taking the time to explain.
<jelmer> jml: at 13k
<jelmer> jml: When did it slow down for you exactly?
<jml> jelmer: ~5000 before the end.
<rasker> jml lifeless so basically --stacked effectively gets you the working tree and would do something like refer back to the original branch for the history if needed
<lifeless> rasker: exactly
<lifeless> I'm heading out now
<lifeless> ciao
<rasker> thanks
#bzr 2009-02-28
<rasker> jml Just so I have a fuller mental picture, using stacked would be useful in scenarios like a bzr server on a LAN serving repositories for a large project or a pull for an automated build system  build system
<jml> 8262.921  Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1526124]
<jml> 9055.759  Collapsed 1 keys into 1 requests w/ 1 file_ids w/ sizes: [1592792]
<jml> those are big numbers :(
<rasker> jml If you have a bunch of branches in a local repository and you want to remove a branch is it sufficient to just delete that branches' directory or does something more have to be done?
<beuno> rasker, you have remove it, but the revisions will still stay in the shared repo
<jml> beuno: hello
<beuno> jml, hi there
<rasker> so I would have to do a bzr remove?
<beuno> how's it going?
<beuno> rasker, no, it's not really something easy to do to remove revisions from a shared repo
<jml> beuno: happy and slow :)
<jml> beuno: you?
<beuno> jml, I have unaswered emails from you, and I'm ashamed of it
<beuno> I'm good actually!  my brain is almost non-functional, but it's also de weekend, so it's good timing
<jml> beuno: that's ok.
<rasker> beuno actually I just want to remove a branch that is within a repository
<jml> rasker: deleting the directory is fine then
<rasker> this doesn't mess with the repository itself (i.e unreferenced stuff left behind)?
<beuno> jml, I just realized that I've been thinking your lp-open stuff hadn't landed because bzr doesn't autocomplete it. Do you know why that is?
<jml> rasker: nope
<jml> beuno: not a clue, I'm afraid.
<rasker> jml beuno : thanks. This bzr stuff is wickedness
<jml> rasker: np.
<rasker> jml this repository I created with all these branches is pretty big (meaning that shovelling everything in a repository has not reduced the disk storage) . Is that because each branch has a working directory?
<rasker> jml sry I mean working tree not working directory
<jml> rasker: sorry, but without concrete numbers I couldn't possibly guess.
<jml> rasker: du -sh branch/.bzr
<jml> rasker: du -sh repo/.bzr
<jml> rasker: that should give you an idea of where the data is, aside from the working tree.
<fullermd> Oh look, sourceforge adding git support.
<lifeless> jml: lp merge request ok?
<mwhudson> if i wanted to play with bzr-git, which branches of the various things should i get?
<jml> lifeless: sure
<lifeless> bah, push failure
<lifeless> can I just send a bundle yet?
<mwhudson> mwh@grond:git-play$ git st
<mwhudson> git: 'st' is not a git-command. See 'git --help'.
<mwhudson> BAD START
<lifeless> no, thats about normal
<lifeless> I've seen folk who use git all the time get such messages
<lifeless> apparently they expect them
<mwhudson> no ci either
<jml> lifeless: I think bundle sending didn't quite make it into the release, due to rollout issues
<jml> lifeless: you can send a merge directive without a bundle
<jml> lifeless: but I'd rather a branch.
<lifeless> jml: yeah, I've deleted and initted and pushing again
<lifeless> will look at the cause on monday
<lifeless> https://code.edge.launchpad.net/~lifeless/testtools/addSkipped/+merge/4031
<lifeless> ja1: you don't need len
<lifeless> jml: so, whaddya think
<jml> lifeless: mostly looks good. some spelling tweaks
<jml> lifeless: will reply when I have more energons.
<lifeless> jml: if its just tweaks, merge and do?
<jml> lifeless: sure, if you want.
<lifeless> jml: long as self.skip, and result.addSkip aren't the things being tweaked, I don't care about the rest :)
<jml> lifeless: yeah, it's comments and test method names and the like
<jml> nothing of substance :)
<lifeless> then I'll start using it
<lifeless> and put a patch for bzr to meet the same contract
<lifeless> hmm
<lifeless> actually subunit first
<bignose> I have a branch with a loom
<bignose> I want to export a single thread as a separate, *non*-loom branch
<bignose> so that I can push it to a public location for others (who may not necessarily have loom support) to work with.
<bignose> how can I do that?
<lifeless> bignose: bzr init target; bzr switch thread; bzr push target
<lifeless> bignose: and after that the last two commands only
<bignose> doesn't âbzr switchâ need to be done *inside* a branch?
<lifeless> whats 'a' ?
<bignose> you gave me three commands; presumably I type them all in sequence (with appropriate arguments).
<lifeless> sure, starting in your loom
<bignose> okay, so âtargetâ would need to be a branch location *outside* the loom then?
<lifeless> yes
<bignose> I was confused because I've been trying to do this with âbzr branch --revision thread:foo orig/ target/â
<bignose> done *outside* any branch, of course
<lifeless> though not required, you could create the target standalone in a subdir of the loom
<lifeless> I'm seeing some unicode glyph my terminal can't render
<bignose> UTF-8 FTW, baby
<lifeless> I'm not at all sure of what Ã¢ means
<bignose> probably your terminal isn't set to UTF-8
<lifeless> yes, and when I track down the xlib fuckage that means I don't get utf8 when my locale *does* support it, I'll be able to read it
<bignose> and sadly IRC has no way of communicating what character encoding is in use
<bignose> the only non-ASCII characters I've used, AFAICT, are typographical quotes
<lifeless> anyhow, I'm seeing 'okay, so XXXXXsomethinghereXXXXXX would need to be ...'
<lifeless> where XXXXsomethinghereXXXXXis my terminal fail
<lifeless> its not a big deal, but it does mean I don't know quite what you are referring to
<lifeless> so, I'll explain more fully and hopefully that will make it clearer
<lifeless> bzr push URL, when you are in a loom, and URL is the URL of an existing regular branch, pushes the current thread to that branch's tip
<bignose> I'm trying it out with the explanation so far
<bignose> let me report back when I see how far that gets me
<lifeless> so the three commands were just saying 'create a branch somewhere', 'push to it from the thread you want to export'
<bignose> thanks, that appears to have worked
<bignose> for the record, the issue only became apparent when I tried to *bind* to a pushed branch
<bignose> and it complained because it was a loom
<lifeless> oh
<lifeless> I don't think that would work well, no :P
<bignose> also, I was expecting the revision spec to be able to pull oput a specific thread when branching
<bignose> would that make sense, as something to add to the UI?
<lifeless> -r thread:name is possible, but bzr branch LOOM URL creates a LOOM at URL
<lifeless> I'm not quite sure of the best way to represent the use case, but its definitely something that would be nice to have
<bignose> okay, but in that example, if a thread is specified as the revision, does it make any sense to create a loom at the target instead of a single thread?
<lifeless> bignose: possibly, possibly its in the too-much-magic category
<bignose> still getting my head around looms, but I'm just giving feedback on how I expect it to work given my current mental model
<lifeless> bignose: yeah; what they need is a month or two of dedicated love
<lifeless> bignose: how are you liking them ?
<bignose> they're good; they don't do what I originally expected them to do (have arbitrary interconnections between the threads)
<bignose> and I still have no idea when I'm supposed to use the ârecordâ command
<bignose> but for managing a *stack* (which isn't what I would expect a *loom* to do), they are quite handy.
<lifeless> did you say "record" command ?
<bignose> I fully appreciate that the namespace of real-world concepts is already stretched thin :-)
<bignose> lifeless: yes
<lifeless> ok, so I saw one character ><
<bignose> AFK now, thanks for the help
<lifeless> my pleasure
<lifeless> mwhudson: b.l.n is still 1.12 yes?
<lifeless> jml: areound ?
<mwhudson> lifeless: yes
<mwhudson> code.lp.net is reliable :)
<lifeless> mwhudson: all this talk of beta and edge servers :)
<lifeless> I think spiv and I will have some qa to do on stacking on monday
<mwhudson> launchpad fails tests with bzr.dev currently, we'll be trying to fix soon i guess
<lifeless> cause?
<mwhudson> not completely clear
<mwhudson> transport_server = SmartServer_for_testing
<mwhudson> self.make_branch('.')
<mwhudson> makes a remote branch now
<mwhudson> that was one
<lifeless> always should have
<lifeless> its flip flopped, now its fixed with a test to test the test helper that it stays working
<mwhudson> and two, in fact, though that one is really our fault, code and tests not agreeing and passing by fluke
<mwhudson> some other stacking stuff, having debugged yet
<mwhudson> (failing acceptance tests are _so_ fun)
<mwhudson> oh no, some loom stuff
<lifeless> its possible you're seeing stuff I'm triggering here
<lifeless> we should talk
<lifeless> in the meantime
<lifeless> What will it take to commit some sensible things to unittest.py
<mwhudson> yes
<mwhudson> but not at 23:30 on a saturday :)
<mwhudson> um, i'm not at all connected to cpython development at the moment
<lifeless> good :P
<mwhudson> it would probably take much arguing on python-dev
<lifeless> there's no 'its clearly sane jfdi' clause?
<mwhudson> i guess i might see gvr at pycon, i can try to get some preemptive points in
<mwhudson> i'm not even subscribed to python-dev
<lifeless> I'm talking simple stuff like
<lifeless> TestResult.done() [the entire set of tests are finished with]
<lifeless> better still things like the addSkip patch I've put forward to testtools
<lifeless> I'm not fussed whether gvr agrees or not :)
<mwhudson> well
<mwhudson> i'm not going to commit stuff without getting involved in the community again
<lifeless> probably wise
<lifeless> I'm getting quite tired of carrying deltas to unittest.py
<mwhudson> have you submitted patches?
<mwhudson> though i wouldn't be super optimistic about getting them apploed
<lifeless> jml has had assertRaises-returns-exception rejected
<mwhudson> the cpython developers, on the whole, don't maintain large systems :/
<lifeless> I like included batteries to be capable of carrying a charge;
<lifeless> shipping flat batteries, not so good
<mwhudson> um, the stdlib is good marketing, not much more
<mwhudson> see above :)
<lifeless> well
<lifeless> much of it works well enough
<mwhudson> lifeless: http://pastebin.ubuntu.com/124208/ <- that's the loomish failure
<mwhudson> (haven't debugged at all)
 * mwhudson zzzzzzzzzzz
<lifeless> mwhudson: ah yes loom needs a [trivial] fix to match bzr.dev api changes
<lifeless> done
<bignose> lifeless: did you observe the discussion mid-2008 regarding improvements to Python's unittest?
<bignose> on the python-dev forum
<bignose> fuzzyman and I worked together for a little while putting forward some PEPs for improvement, in 3.x
<lifeless> bignose: I'm on TIP, but not python-dev
<lifeless> bignose: so no, I don't think I saw it
<jelmer> jml: ping
<shled> Hello there, can anybody tell me how to disable these bzr-gtk notifications popping up after I push to a repository? I am using bzr and bzr-gtk under Ubuntu Intrepid.
<shled> solved it myself, many thanks for your help :-/
<bignose> lifeless: <URL: http://mail.python.org/pipermail/python-dev/2008-July/081052.html>
<bignose> lifeless: and subsequent unittest threads in that forum
<lifeless> jml: are you subscribed to python-dev?
#bzr 2009-03-01
<rocky> when i'm inside a Transport and want to raise like a security error, what's the proper type of exception to raise?
 * rocky finds bzrlib.errors
<jelmer> rocky, :-)
<rocky> jelmer: i'm building a very simple ACLTransport for my ClueBzrServer ;)
<jelmer> rocky: Ah, cool
<jelmer> rocky: Is there no branch open hook you could use?
<rocky> i thought i went down that path originally and found the branch hooks rather limited ;)
<lifeless> rocky: we can always add more
<rocky> lifeless: this is my first experiment so i'm not entirely sure what i need or what would make my life easier ... i'm gonna try building this up the best i can and look back and see if i can make some suggestions :)
<johnf> lifeless: just testing my bzr package building setup. I notice the beta PPA only has 12 rc1. It would make sense for it to have 12 right?
<lifeless> definitely
<johnf> ok I'll use that as my test that everything works.
<mwhudson> grrnk
<mwhudson> you know you're doing something wrong when you're reading dirstate code on a sunday
<lifeless> mwhudson: loom should be fixed btw, in trunk
<mwhudson> lifeless: it is, i landed trunk into rocketfuel earlier
<mwhudson> thanks
<lifeless> does every change to stdlib need a pep ?
<fynn> hey, the C extensions that Bazaar uses:
<fynn> are they plain C-API extensions, or Cython?
<fbond> Hi.  If I have a directory containing several unrelated branches and I want to turn that directory into a shared repo, how can I move the repository data in each branch into the shared repo?
<lifeless> fynn: some are plain C-API, most are pyrex
<lifeless> fynn: Cython is a version of pyrex, more or less
<lifeless> fbond: if they are unrelated you won't get much benefit; anyhow - bzr init-repo <dir>; bzr branch dir/branch1 dir/branch1-using-repo; rinse and repeat
<fynn> lifeless: yeah, I should have s/Cython/Pyrex
<fbond> lifeless: Thanks.  The reason I'm doing it is because trac-bzr doesn't seem to like to deal with multiple repositories...
<abentley> lifeless, fbond: Alternatively: bzr init-repo <repo>; cd <repo/branch1>; bzr reconfigure --use-shared
<lifeless> abentley: ah sweet
<sohail> hey, is bzr checkout what I want to do if I am doing connected work/
<sohail> ?
<mwhudson> yes
<sohail> mwhudson, ok thanks
<sohail> it just seemed to take for-freaking-ever but I guess that's because the repo is kinda big
<mwhudson> sohail: maybe you mean co --lightweight?
<sohail> mwhudson, ah I thought that was it
<sohail> so what is the difference between that and straight bzr co?
<mwhudson> sohail: co gets the entire history of the branch
<mwhudson> sohail: co --lightweight just fetches the most recent revision (a bit like 'svn co')
<sohail> mwhudson, ah I see
<sohail> ok I'm getting the hang of it... thanks :-)
<fbond> lifeless: bzr: ERROR: Revision {('forest.bond@logicsupply.com-20081210015641-515ojqps68c9fdyk',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x864fd4c>".
<fbond> I get that when branching in the new shared repository, but only for some branches.
<fbond> Others seem to work fine.
<fbond> bzr Bazaar (bzr) 1.3.1
<Toksyuryel> that's rather old
<Toksyuryel> current is 1.12
<fbond> Toksyuryel: 1.3.1 is less than a year old.  I'm hoping to avoid upgrading, so a work-around would be helpful.
<Toksyuryel> not sure how much help you'll be able to find; good luck
<lifeless> fbond: I'm not sure; it may be a bug in 1.3.1 of the branching into the repo
<lifeless> fbond: if so, using 1.12 and starting over will work well; its possible to use a little python to manually fetch everything, but thats more complex
<cammoblammo> Does anyone have any idea when a bzr newer than 1.5 will go into Debian unstable?
<Toksyuryel> two years from the date 1.5 went in, 1.6 will go in
<lifeless> cammoblammo: well, should be soon now that debian has released
<cammoblammo> lifeless: Let's hope so! Is it that hard to install it from source? And is there any reason why I'd want to?
<lifeless> well, 1.12 is a lot better than 1.5 :)
<lifeless> its trivial to run from source - grab the tarball
<lifeless> run 'make'
<lifeless> and symlink something to 'bzr'
<cammoblammo> Yeah, I'm looking at it now. I just have to make sure it doesn't stuff anything else up on my box. I don't think it will.
<cammoblammo> Ah, I see. It installs into /usr/loca/ so it should live quite hapily with my Debian install. I just have to make sure it comes first in my $PATH, which I'm pretty sure is the case anyway.
<lifeless> cammoblammo: you don't even have to install it
<lifeless> just unpack the tarball, run 'make' in the source dir
<lifeless> and ln -s $(pwd)/bzr /usr/local/bin/bzr
<cammoblammo> Yeah, I see that. Too easy.
<lifeless> cammoblammo: easiest though is probably to use the bzr ppa, which should be compatible with debian; unstable is roughly jaunty
<cammoblammo> I thought of that, but I've had bad experiences with that in the past.
<lifeless> fair enough
<lifeless> it would be nice to have a unstable specific ppa
<Toksyuryel> ppa? what happened to deb?
<cammoblammo> If it's just a matter of a symlink, it's probably easiest to pull the bzr repo. Does it break that often?
 * cammoblammo likes playing with stuff he doesn't understand!
<lifeless> Toksyuryel: ppa - personal package archive - a mini debiana archive
<Toksyuryel> I... see.
<cammoblammo> Ah, bother. The bzr code requires bzr 1.6 to pull. Grr.
<Toksyuryel> you could install bzr 1.12 via the method described above and then use that to pull :)
<cammoblammo> Yeah, that'll have to do!
<lifeless> thanks vila
<cammoblammo> Hmm. No biggy, but the python script installed bzr to /usr/bin instead of /usr/local/bin as http://bazaar-vcs.org/InstallationFaq seems to think.
<vila> lifeless: :-) Me ? Why ? I'm not even there :) By the way, does the following makes sense to you:
<vila>     while _tasks and now >= _tasks[0].timeout:
<vila> IndexError: list index out of range
<lifeless> vila: erggg
<lifeless> vila: oh damn, my patch isn't python 2.4 compatible
<lifeless> vila: can I get a rubberstamp for fixing it to be so?
<vila> lifeless: sure enough
<lifeless> vila: _tasks is a list, but _tasks[0] is out of range - hmm, threads involved?
<vila> lifeless: hehe, good, I wanted confirmation for that, yes, threads are involved, and sockets too
<lifeless> vila: make sure that anything removing from tasks is excluded from anything reading it
<vila> lifeless: yeah, that's the hard part :-/ I know I do some dirty thing, and I know which, I didn't suspect it could lead to that though...
<lifeless> vila: I would guess that a concurrent block of code is executing between _tasks, and 'and now >= _tasks[0].timeout
<vila> lifeless: yeah, my thought too. The problem is that the bug is transient, weird interaction between the python scheduler and the kernel socket handling obviously, bug go isolate that junk :-/ The good thing is that it's more or less related to that other discussion about branches leaking sockets (in a rather convoluted way, but yet)
<vila> lifeless: anyway, I should leave, I'm on the right track I think to better understand how we should handle servers in their own thread  running into that mess... (and some of that knowledge should apply to the http servers too (this one is with ftp servers))
<lifeless> vila: so if this is in the progress updating code?
<lifeless> vila: you should probably do something in the ftp code to do thread sync there
<lifeless> so that non-threaded transports don't pay the cost of thread primitives
<lifeless> so python 2.5 changed self._methodName from self.__methodName
<lifeless> jml: ^
<lifeless> vila: ok that looks like its going through
<andersfeder> can someone help me get started with bazaar on launchpad?
<andersfeder> everything i do results in: bzr: ERROR: Not a branch: ...
<james_w> andersfeder: what command triggers that error?
<andersfeder> james_w:  bzr push lp:~anders-feder/+junk/test
<james_w> and what is the rest of the error?
<andersfeder> bzr: ERROR: Not a branch: "/home/feder/branch/+junk/test/".
<james_w> what does "bzr info" say?
<andersfeder> bzr: ERROR: Not a branch: "/home/feder/branch/+junk/test/".
<james_w> ok, so you're not inside a branch
<james_w> did you create a branch with "bzr init"?
<LarstiQ> notes /home/feder/branch
<LarstiQ> instead of lp:~..
<andersfeder> james_w:  no, i am a noob .. can you explain how?
<james_w> andersfeder: ok, before you can push a branch you have to create one to push
<james_w> that is done with the "bzr init" command
<andersfeder> okay
<james_w> if you run that with no arguments it will create a branch rooted in your current directory
<andersfeder> i see
<andersfeder> i try it
<james_w> you can then create some files, and run "bzr add"
<james_w> then "bzr commit" will commit the first revision in to that branch
<andersfeder> okay
<james_w> you can then run "bzr log" to see that revision
<james_w> once that is all ok you can push your new branch to launchpad
<andersfeder> ah
<james_w> running the command you were trying before should then work
<andersfeder> up until 'bzr push', everything is something being configured locally?
<james_w> yeah
<andersfeder> when  i do 'bzr commit', i get thrown into a text editor showing a log reading "This line the following will be ignored..."
<andersfeder> how come?
<andersfeder> or is that just a log of the commit operation?
<mneptok> andersfeder: you are thrown into your default text editor in order to create a commit message
<andersfeder> aha
<andersfeder> mneptok: so i just type something into the editor, save and exit?
<mneptok> andersfeder: one would hope you'd type a meaningful message instead of mashing the keyboard with your palm, but yes. ;)
<andersfeder> right :)
<mneptok> one man's meat is another man's poison. "verbose commit messages" threads on developer lists prove this axiom.
<andersfeder> well, everything seemed to work .. thanks everyone, bye
<CBro2007> guys how do I revert to the last committed copy of my project, removing all changes made in my local dir?
<CBro2007> I did a "bzr revert" and it gave me the latest one from the repository but my new changes since last commit where still in there
<CBro2007> is this possible?
<edcrypt> CBro2007: use either uncommit or branch/checkout again
<CBro2007> uncommit?
<CBro2007> wouldn't that remove the last committed copy from my repo?
<CBro2007> I want to keep the last GOOD copy in the repository... but just change my working directory to the good copy
<CBro2007> edcrypt: whats the command to do that?
<edcrypt> CBro2007 'bzr uncommit -r X' , where X is the revision you want it to go back
<edcrypt> CBro2007 or maybe I'm not undestanding it right...
<CBro2007> says no revisions to uncommit
<CBro2007> but bzr log shows 3 revisions
<CBro2007> well basically I have 3 commited copies in my repository and my working copy is not working well
<CBro2007> so I want to get to my last good commited copy
<CBro2007> this should be common stuff with bzr
<edcrypt> have you pushed this revisions?
<CBro2007> pushed how?
<CBro2007> I just did "bzr commit -m "Initial comments... blah"
<CBro2007> when I committed copies of my project
<edcrypt> you know the revision number of this 'good' commit, right?
<CBro2007> yeah its 3
<edcrypt> have you tried 'bzr uncommit -r 3' ?
<CBro2007> Macintosh-2:xxx$ bzr uncommit -r 3
<CBro2007> No revisions to uncommit.
<edcrypt> it must be at the revision 3 already, then
<edcrypt> 'bzr revno'
<CBro2007> Macintosh-2:xxx$ bzr log
<CBro2007> ------------------------------------------------------------
<CBro2007> revno: 3
<CBro2007> committer: xxx <xxx@gmail.com>
<CBro2007> branch nick: XXX.dev
<CBro2007> timestamp: Tue 2009-02-24 07:42:17 +0000
<CBro2007> message:
<CBro2007>   Added new table
<CBro2007> ------------------------------------------------------------
<CBro2007> revno: 2
<CBro2007> committer: xxx <xxx@gmail.com>
<CBro2007> branch nick: xxx.dev
<CBro2007> timestamp: Thu 2009-02-19 15:07:55 +0000
<CBro2007> message:
<CBro2007>   XXX: Added
<CBro2007> ------------------------------------------------------------
<CBro2007> revno: 1
<CBro2007> committer: xxx <xxxl@gmail.com>
<CBro2007> branch nick: trunk
<CBro2007> timestamp: Tue 2009-02-17 12:03:25 +0000
<CBro2007> message:
<CBro2007>   Initial Import
<CBro2007> shit sorry....
<CBro2007> accidental paste
<CBro2007> trying to show you what its at
<CBro2007> just >bzr revno?
<CBro2007> or
<CBro2007> >bzr 3?
<CBro2007> its at 3
<CBro2007> bzr revno = 3
<CBro2007> I had done a "bzr revert" earlier on
<CBro2007> but it kept ALL the changes that I made in the file
<edcrypt> ok, you can't go back to r3 because it is already in this revision.
<edcrypt> CBro2007: bzr diff shows something?
<CBro2007> yeah quite a lot
<edcrypt> have you tried 'bzr revert FILENAME' ?
<edcrypt> it would be very, very strange if it would't nuke all your changes :)
<madduck> bzr is supposed to be user-friendly, right? ;)
<madduck> piper:~|master|.tmp/cdt.UPlIXyzw% bzr launchpad-login madduck                                  #3,10003
<madduck> piper:~|master|.tmp/cdt.UPlIXyzw% bzr clone lp:pytagsfs                                          #10004
<madduck> Permission denied (publickey).
<madduck> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<madduck> -Dhpss does not give any other info
<LarstiQ> madduck: heya
<madduck> hi
<madduck> i figured out the problem
<madduck> launchpad still had my old keys...
<LarstiQ> printing out the key info after the Permission denied from openssh might help
<madduck> the messages I get during the clone are very disconcering
<madduck> piper:~|master|.tmp/cdt.UPlIXyzw% bzr clone lp:pytagsfs                                          #10006
<madduck> Format <RepositoryFormatKnit1> for lp-45955728:///~forest-bond/pytagsfs/dev/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<madduck> Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<madduck> Format <RepositoryFormatKnit1> for lp-45955728:///~forest-bond/pytagsfs/dev/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<madduck> Branched 518 revision(s).
<james_w> yeah, it's unfortunate
<jkakar> I've been enjoying digging through bzrlib and figuring out Command and friends work.  The code and facilities here are very nice.
<fm> i think i just found a bug, have a look at http://pastebin.ca/1350390
<fm> i am using 1.11 as this is shipped with fedora 10
<fm> could anybody look at it and say wether it is expected? why was the user.png not commited is my question ...
<fbond> Hi, which branch of bzr-loom is appropriate for use with bzr 1.12?
<thekorn> fm, because bzr commit -m requires an argument, and user.png is interpreted as an argument for -m
<fm> thekorn: thnaks, i should sleep ...
<RaceCondition> what's the best way to publicly expose a bzr repository besides SFTP?
<RaceCondition> authentication would be nice as wel
<RaceCondition> smth like svnserve
<LarstiQ> RaceCondition: reading or writing? http/bzr+ssh/bzr://
<RaceCondition> I'd like to be able to both read and write
<RaceCondition> but I'd like to be able to give either just read permissions or rw permissions to users
 * LarstiQ is happy with posix acl and bzr+ssh
<LarstiQ> RaceCondition: if all your users already have system accounts
<RaceCondition> well I don't want all of them to have system accounts
<RaceCondition> I want to pull updates to client deployments and I don't want clients to be able to access my server over SSH
<LarstiQ> RaceCondition: right
<thumper> RaceCondition: surely if you are wanting to pull from client deployments, isn't that your answer?
<thumper> RaceCondition: for you to pull, not them to push
<RaceCondition> no
<RaceCondition> I want them to be able to pull from my central repository to get updates
<RaceCondition> without being able to write nor access any system accounts
<thumper> RaceCondition: then serve over http for them to pull should be fine
<RaceCondition> hmm, OK
<RaceCondition> would I have to use HTTP auth then?
<thumper> umm...
<thumper> I guess so
<thumper> not done it myself
<RaceCondition> ok
<RaceCondition> I'll try
<lifeless> RaceCondition: put the directory somewhere on a http server, use http auth, then the clients pull from that url
<RaceCondition> lifeless: thanks, I'll try that
<jkakar> I wonder how hard it would be to completely the separate the bzrlib.commands and surrounding infrastrucure from the code in bzr that uses it.
<jkakar> It doesn't look like it would be terribly hard.
<lifeless> jkakar: its pretty easy; import bzrlib.commands :)
<lifeless> RaceCondition: for writing over http, you need the webdav plugin, or to follow the smart server http guide, in the documentation
<lifeless> RaceCondition: (I missed that you wanted writing above, or I'd have said this initially)
<RaceCondition> I'd rather write over SFTP
<RaceCondition> so that the same Åepo would be exposed through both SFTP and HTTP
<jkakar> lifeless: I want to use it without making Bazaar's builtin commands (and plugins).  Which is requiring a bit of wrangling (read: monkey patching).
<jkakar> s/without making/without including/
<jkakar> lifeless: I want to use it to build an application with a bzr-like '$program $command' type interface.
<lifeless> jkakar: I'd be happy to review patches that make using it (by importing) not automatically expose bzr's builtins
<lifeless> jkakar: plugins seems easier (don't call bzrlib.plugin.load_plugins())
<lifeless> jkakar: but I'd consider an answer to 'how to stop a plugin registering a command, even though its needed for $my-program'
<jkakar> lifeless: Great, thanks.  I'm not sure what the right answer is yet, so I'll continue with brute force.  If/when I come up with something better I'll let you know.
<lifeless> RaceCondition: that will work fine too
<lifeless> RaceCondition: though I recommend using 'bzr+ssh://' as the protocol, not sftp - it also uses openssh for authentication and encryption, but its faster.
<RaceCondition> OK, that's good to know
<RaceCondition> I've been using SFTP though and the upload plugin with success because my repositories are small
<lifeless> RaceCondition: if you're happy with it - stick with it by all means :)
<RaceCondition> yeah
<RaceCondition> but I'll remember the bzr ssh combo for future :)
<lifeless> RaceCondition: if/when you start feeling 'if only this was faster' - well, you have an answer ;)
<RaceCondition> yeah
<jml> lifeless: I knew that about py 2.5 -- trial.TestCase works around that.
<jml> lifeless: I unsubscribed from py-dev
<jml> lifeless: I'm not around :)
<jml> jelmer: pong
<lifeless> jml: py-ideas?
<lifeless> jml: I've been trying to find the rejection for assertRaises -> theException
<lifeless> jml: getUniqueString and run would appear to break on 2.4
<jml> lifeless: no, I'm not on py-ideas. The rejection was py-dev
<jml> lifeless: testtools only supports 2.5+ atm.
<lifeless> jml: ah, that explains it :P
<jml> (for no good reason, other than being sick to death of 2.4)
<jml> lifeless: now, I'm at a sprint.
<jml> bye
<lifeless> jml: ciao :P
<lifeless> jml: if/when you surface, I'd love a review or two :)
<igc> morning
<fbond> Agh, I'm having a hard time getting an svn repository converted.  I'm getting http://bazaar.launchpad.net/%7Easabil/bzr-interactive/trunk/.
<fbond> Oops wrong paste.
<fbond> AssertionError: base checksum mismatch: '2d5c2c8ce179bd24a696676890af367b' != '5d43b775c320bea1a509debdc5431eef'
<fbond> Anyone seen anything like this before?
<lifeless> fbond: no, is there a backtrace?
<lifeless> igc: http://en.wikipedia.org/wiki/Rabin-Karp_string_search_algorithm
<igc> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/336373
<ubottu> Ubuntu bug 336373 in bzr "error upgrading emacs to gc-plain-chk255" [Undecided,New]
<lifeless> igc: which gc are you using?
<igc> lifeless: rev 56
<lifeless> igc: of what brbanch
<igc> lifeless: https://code.edge.launchpad.net/~bzr/bzr-groupcompress/trunk
<lifeless> igc: so, be interesting to know what is None
<lifeless> the locations, or the key
<lifeless> igc: either way, have you tried rolling back to the last version that worked?
<igc> lifeless: not yet. jam was keen for me to use rev 55 and rev 56 has a pretty obvious bug fix
<lifeless> igc: I'd either start debugging the gc code, or rollback
<lifeless> igc: myself, I'd rollback because the rabin stuff hassn't landed in trunk yet
<igc> lifeless: shall do
<fbond> lifeless: Yes, I can post a backtrace.
<fbond> lifeless: Prefered paste site?
<fbond> lifeless: http://pastebin.ca/1350545
<fbond> jelmer: This is a bzr-svn traceback, FYI.
<fbond> The repository I'm importing from has been around for a few years, and I've used early-ish versions of bzr-svn with it.  I've dealt with some svn property conflicts related to bzr-svn metadata.  It's possible some of them were not resolved perfectly.  Not sure if any of this is relevant.
<lifeless> fbond: I'd file a bzr-svn bug
<lifeless> fbond: it looks to me like it got the wrong text out of svn somehow
<fbond> lifeless: Hm, what a bummer.  I'd really like to get this thing converted.  Thanks.
<bignose> once I have a loom with a stacked series of patches, how do I then generate a âquiltâ series?
<fbond> bignose: Are you looking to generate a series of patches?
<bignose> fbond: specifically, a series of patches that I can use with âquiltâ.
<bignose> so, the closer I get to what quilt calls a âpatch seriesâ, the better.
<bignose> naming the patches after the thread names would be good
<bignose> as would generating the âpatch headerâ that âquiltâ can use
<fbond> bignose: Hm, I didn't know that quilt could import patches.
<fbond> bzr-loom is, as I understand things, a replacement for quilt.
<bignose> fbond: um? I'm talking about what the quilt system handles natively.
<fbond> But generating a series of patches from a loom is easy enough.
<fbond> bignose: I may not know quilt well enough.
<bignose> nor I :-)
<fbond> However, to generate a patch for thread foo:
<fbond> bzr switch foo; bzr diff -r thread: >foo.patch
<bignose> I'm using a loom to generate the patches, but a Debian package can't have a loom
<bignose> but it *can* have a quilt series of patches, so that's what I'm trying to generate
<fbond> I see.
<bignose> that's the extent of my knowledge of quilt :-)
<fbond> bignose: There are a few other patch systems that can be easily used in debian packaging.
<fbond> Others might be simpler, given your use-case.
<bignose> well, simplest for me would be to simply generate a new tree, and generate a diff against the original files
<fbond> I would generate patches, toss them in debian/patches, and use cdbs with simple-patchsys.
<bignose> but I'm trying to find a way to be nicer to others than that
<fbond> bignose: You can explode a loom into separate branches for each thread...
<bignose> and from what I understand, quilt is the most accepted system
<bignose> fbond: but then generating the patch for each one would require knowledge of which branch precedes it in the series.
<bignose> so I think generating the patches from the loom is the approach with most promise
<fbond> bignose: quilt has the concept of patch order, too.
<bignose> yes, and that's what I'm trying to feed it.
<bignose> my point was that exploding the patches to separate branches looses that order.
<bignose> s/loose/lose/
<fbond> bignose: Right.  I would generate patches from the loom directly.
<bignose> okay.
<bignose> currently only possible manually then?
<fbond> bignose: As far as I am aware.
<bignose> fbond: thanks for your help.
<fbond> bignose: No problem.
#bzr 2010-03-01
<jelmer> slangasek: hi
<jelmer> slangasek: James was about to release another version of bzr-builddeb so I was waiting on that before uploading to sid
<jelmer> james_w: ^
<igc> hi lifeless, jelmer
<jelmer> hey Ian
<jelmer> igc: Congrats on bzr-explorer 1.0!
<slangasek> jelmer: ok :)
<igc> thanks jelmer
<lifeless> hi igc
<lifeless> jelmer: did you get the commitfromnews tests working ok?
<jelmer> I haven't tried yet
<lifeless> ok
<lifeless> bzr.dev change is landed
<lifeless> is it doc or docs we use for doc bugs?
<poolie> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers!
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers!
<igc> hi poolie
<poolie> hello igc
<poolie> how are you?
<igc> ok today
<igc> time for a call sometime today maybe?
<igc> poolie: ^
<poolie> now's good if that suits
<igc> poolie: it does
<mwhudson> lifeless: yes
<lifeless> mwhudson: its doc, I looked
<mwhudson> although it redirects and that should work for a good while
<lifeless> mwhudson: oh, the out of date question.
<lifeless> ok, I won't stress about the link
<mkanat> mwhudson: So, no crashes all this time?
<mwhudson> mkanat: one, but i think a sysadmin was woken up for it, so no debugging :/
<mkanat> mwhudson: :-(
<mwhudson> yeah
<dsuch> Hmm is there any notion of a session when working with WorkingTrees? My application accepts HTTP requests and upon receiving one I'd like to create some sort of a 'bzrlib session' which would go down through a couple of layers of the code,
<dsuch> possibly ending in its committing if no exception have been raised. However, if an exception is raised, I'd like to rollback any possible changes.
<dsuch> revert rather :)
<dsuch> Something along starting a new SQL transaction I guess.
<dsuch> Actually, not sure if it matters, but there would be only one commit made deeper in the code and I think I'd like to commit the commit right before finishing with the HTTP request.
<dsuch> Or commit the session, if there is such a thing.
<mwhudson> dsuch: there are write locks and write groups, which i think are at least a bit like that
<dsuch> okay, I'll take a look at that, thanks
<jmcantrell> how do i get the repo url that i branched?
<dsuch> jmcantrell: bzr info ?
<jmcantrell> dsuch: if i need to get it in a script, is the best way to just parse that output or is there a better way?
<dsuch> in Python?
<jmcantrell> dsuch: bash
<dsuch> doesn't seem bad
<jmcantrell> dsuch: yeah, i just didn't know if there were a way to get just the path
<dsuch> I'm not sure, there are lots of commands but I tend to stick to a few mostly used, take a look at 'bzr help commands', maybe there is some shorter one
<jmcantrell> dsuch: ok. thanks
<poolie> thanks for all the reviews jelmer
<parthm> hello. I have lp:bzr-grep working to grep a specified revision for a pattern. http://pastebin.com/AkccBvx8
<parthm> I am working on extending it to take a range. I found builtins._get_revision_range(revision, wt.branch, 'grep') returns two RevisionInfo objects.
<parthm> Whats a good way to get a list of inclusive revision for this range.
<poolie> hello parthm
<poolie> that'd be a nice featuer
<parthm> hi poolie
<poolie> *feature
<poolie> there should be a repository method for that
<poolie> i'd look in log
 * parthm goes digging into log code
<poolie> i'd probably call something like _graph_view_revisions from log.py actually
<poolie> igc, hi?
<igc> hi poolie
<poolie> igc i think bug 524177 is now fixed, if you want to try again
<ubottu> Launchpad bug 524177 in bzr "Doc rebuilds are deleting chm files" [Critical,Fix released] https://launchpad.net/bugs/524177
<igc> poolie: thanks
<parthm> poolie: thanks. i will look at that.
<poolie> igc, do you want me to try this thing of removing the ga urchin from the html templates? or are you ok with that?
<parthm> hello. For lp:bzr-grep I have a simple loop to iterate through the rev range given by the user http://pastebin.com/qaQyVsjX This works fine and I am able to grep the rev range.
<parthm> However, I am seeing a weird failure in a test http://pastebin.com/Nqtr2kCu which tries to grep on an unversioned file. it seems to be failing in at the 'for' clause http://pastebin.com/BfM0Hvhu
<parthm> interestingly, running the exact same step from command line works fine (and issues a skip warning as expected). any ideas?
<parthm> the run from the command line: http://pastebin.com/NLQhsihG
<parthm> never mind. this seems to be the edge case of the repo having only 1 revision. http://pastebin.com/dYJHRxSE Any suggestion on what may be a good fix? Do I just catch the error and ignore?
<poolie1> hi parthm
<poolie1> sorry did anyone answer before?
<lifeless> poolie1: check out lp:bzr-plugin-info
 * lifeless goes offline
<parthm> poolie1: np. i located and fixed the error. it was a special case for revno:0
<parthm> i am done with the rev range support also (just adding tests). you can try it at lp:bzr-grep. i can try to make it a builtin and propose a merge if you think its upto it.
<vila> hi all !
<poolie1> hi vila
 * poolie1 is writing stuff to plot the review queue length
<vila> hey poolie
<vila> interesting
<lifeless> :!bzr git-import
<lifeless> Command git-import is supplied by the following plugins:
<lifeless>   git
<lifeless> poolie1: ^
<poolie1> good
<poolie1> lifeless: makes it sound like it's actually supplied by them
<poolie1> but for you, not so much :)
<lifeless> hmm ?
<poolie1> "Command '%s' is not available at the moment but might be provided by the following plugins: %r.  See <http://doc......>"
<poolie1> oh also make sure it exits nonzero
<lifeless> I think might is a little waffly
<poolie1> delete it then
<poolie1> use something like what ubuntu's thing does
<lifeless> thats what I have done;)
<poolie1> The program 'darcs' is currently not installed.  You can install it by typing:
<poolie1> sudo apt-get install darcs
<lifeless> yes
<lifeless> we don't have that slick a system yet
<poolie1> you don't understand the difference?
<lifeless> I was going to add the URL
<poolie1> please make it more clear that the command is not actually available yet
<lifeless> ok
<lifeless> I'm glad you like it enough to offer feedback.
<poolie1> i do :)
<poolie1> this is just polish :)
<lifeless> yes; you're coming across a bit aggro. Sorry if its me being slow or whathaveyou.
<poolie1> sorry
<lifeless> I just spent an hour twisted sideways on the train; only pasted it here to show that I had actually got <something> done
<lifeless> take #2
<lifeless> :!bzr git-import
<lifeless> Command 'git-import' is not available at the moment.
<lifeless> The following plugins include this command:
<lifeless>  * git (branch available ../../git/trunk)
<poolie1> sweet
<lifeless> its pushed
<lifeless> vila: beuno: ^ you might enjoy that. (install lp:bzr-plugin-info)
<lifeless> poolie1: gnight
<vila> lifeless: nice
<vila> lifeless: Do^H^H When you plan to put it into core ?
<lifeless> it needs discussion
<poolie1> vila i think we should ship it somehow
<poolie1> whether it's in core or a shipped plugin is not a big deal
<poolie> lifeless: you might be interested to know in the last week 38 bugs were filed, 11 were fixed, and 54 left state New
<vila> poolie1, lifeless : sure, keeping it as a plugin is fine with me, one more example
<poolie> 23 were closed
<poolie> 17 became inprogress
<vila> poolie: wow, excellent, hydrazine ?
<poolie> psql :)
<poolie> could be done more slowly through hydrazine
<poolie> however i want to plug it into tuolumne aka lpstats
<poolie> and that is easier done here
<lifeless> vila: grats on hudsonification
 * vila returns the compliment ;-)
<parthm> poolie: lp:bzr-grep plugin is tested and has the most common features http://pastebin.com/ijCs02kr . Feel free to try it out. I am thinking this can be proposed as a builtin. If you agree I could do the porting.
<parthm> I plan to add --external-grep, --include/exclude but if a merge is to be proposed I would like to add these after to keep the proposal size small.
<vila> parthm: thanks for resurrecting this plugin !
<parthm> vila: welcome :-) this one uses a builtin grep and i have tested it out on windows also.
<poolie> wow that's great
<poolie> i'll install it now
<bialix> hi all
<parthm> bialix: hi
<vila> hey bialix
<bialix> bonjour vila
<lifeless> vila: you did all the wrk:)
<bialix> jelmer: ping
<lifeless> vila: https://code.launchpad.net/~lifeless/bzr-gtk/setup/+merge/20341
<poolie> vila, lifeless: https://code.edge.launchpad.net/~mbp/tuolumne-lp-configs/bzr-graphs/+merge/20357 - plot mps in progress etc
<vila> poolie: Not allowed here
<vila> Sorry, you don't have permission to access this page.
<poolie> blah
<poolie> oh well you'll have to trust
<poolie> me
<vila> lifeless: a bit of explanation for that bzr-gtk mp ? (to save me the time to install your plugin and encounter the failure)
<vila> poolie: hehe
<lifeless> vila: http://doc.bazaar.canonical.com/bzr.dev/developers/plugin-api.html#plugin-metadata-before-installation
 * igc dinner
<vila> lifeless: excellent
<slangasek> james_w: when you're about, I'd appreciate having your eyeballs on bug #529900; I have an opportunity to nudge the Debian Samba packaging in the direction of bzr from svn, and that bug's a blocker for it
<ubottu> Launchpad bug 529900 in bzr-builddeb "merge-upstream --v3 tries to unpack .tar.bz2 with tar xzf" [Undecided,New] https://launchpad.net/bugs/529900
<poolie> night all
<vila> poolie: g'night
<jml> lifeless, no
<james_w> slangasek: haha
<james_w> thanks for the fix, I'll get this uploaded soon
<slangasek> ok, cheers :)
<soren> Is there a simple way to get bzr-svn to allow me to check out some stuff over https if the certificate on the server is expired and/or signed by an unknown CA?
<lifeless> if you tell svn itself that its ok
<lifeless> I think it will work
<lifeless> YMMV
<soren> Oh.
 * soren tries again
<soren> Ah, I was just doing "bzr branch https://blahblah/"... switching to "bzr branch svn+https://blahblah/" helped. It didn't even ask me to confirm the cert, which I suppose is a bit worrying.
<lifeless> vila: 120K tests is kinda scart
<lifeless> *scary*
<lifeless> gnight
<vila> lifeless: yeah, matrix job fallout, I know
<vila> lifeless: just divide by the number of slaves :-D
<lifeless> :P
<igc> night all
<mthaddon> can anyone enlighten me on whether there's a way to specify which identity file to use for a given bzr operation (the use case is when the home dir for the user is on a tmp filesystem)?
<bialix> what?
<vila> mthaddon: identify file as in ssh ?
<vila> grr identity
<mthaddon> yeah
<vila> we obey ~/.ssh/config ... you want a way to force it without having a ~/.ssh directory ?
<mthaddon> vila: yeah, similar to -e for rsync
<vila> mthaddon: nothing comes to mind... I'm not sure ssh itself obey an appropriate env var...
<vila> hmm, there has been talk about specifying
<vila> grr delete not enter
<mthaddon> vila: in rsync you can just do rsync -e="ssh -i file" and it does what we're hoping for in this case, but that sounds like bzr doesn't support that, right?
<vila> mthaddon: I don't think so, I'm checking
<mthaddon> thx
<vila> There is BZR_SSH but it's supposed to be the executable name only, no options
<vila> mthaddon: the command is built in bzrlib/transport/ssh.py
<vila> mthaddon: I see to env var used there
<vila> mthaddon: two possible tricks: 1) patch b.t.ssh.py to add your -i param, 2) define your own ssh wrapper
<vila> both are a bit ugly, the later is just a bit less ugly :-/
<vila> mthaddon: feel free to file a bug with your use case
<mthaddon> thx, will do :)
<vila> errq, s/I see to env var used there/I see *no* relevant env var used here/
<vila> mthaddon: out of curiosity what *is* your use case (i.e. why can't you build a usable ~/.ssh dir ?) ?
<mthaddon> vila: running a nagios check - user has tmp home dir as it's a role account
<vila> tmp as in empty ?
<GaryvdM> Hi all
<GaryvdM> Hi bialix
<bialix> Hi GaryvdM !!!
<bialix> GaryvdM: I'm a bit busy with current work, so I was unable to release qbzr 0.18.3 this weekend
<bialix> maybe next weekend
<GaryvdM> Maybe I can do it this week.
<bialix> will be nice
<vila> hey GaryvdM !
<LeoNerd> I think my dist-upgrade just broke bzr-svn... I now get: bzr: ERROR: exceptions.AttributeError: 'BranchConfig' object has no attribute '_get_change_editor'
<GaryvdM> Hi vila
<jelmer> LeoNerd, please file a bug against bzr-svn
<LeoNerd> OK willdo
<LeoNerd> jelmer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572109
<ubottu> Debian bug 572109 in bzr-svn "AttributeError during 'bzr shelve'" [Normal,Open]
<RainCT> Hi
<RainCT> About that websites thing in Explorer, I'm not sure how it works but wouldn't it make sense to let projects include a dot-file directly in the branch with that info (instead of having to get it merged)?
<jelmer> LeoNerd, thanks
<shortlord> Is it possible to create a daily build with bzr-builder for software that is not hosted on Launchpad and does not use bzr? (SVN for example?)
<james_w> yes
<james_w> if you have bzr-svn installed
<shortlord> james_w, oh wow, that sounds great. thx :)
<ubuntujenkins> can you push branches to launchpad with out an ssh key?
<maxb> no
<rubbs> ubuntujenkins: not that I know of
<ubuntujenkins> fair enough that just means a little more work thats all , thanks rubbs
<rubbs> np
<anddam> hello
<rubbs> hello
<anddam> woa 2.1.0
<anddam> I guess 1.4 is considered old
<anddam> was binary called baz back then?
<nDuff> I don't believe so
<GaryvdM> anddam: baz and bzr have unrelated version numbers. bzr started at 0.1
<anddam> what's the difference? I installed bazaar with macports and I see just a single binary "baz"
<anddam> 1.4.2
<anddam> well there's annotate-baz too, but no bzr
<anddam> oh lol
<anddam> it's a different app,  "NOTE: this is baz, aka Bazaar 1. If you want Bazaar 2, use the bzr port" I should have read the long description
<GaryvdM> anddam: I just checked, there was never a bzr 1.42
<GaryvdM> *1.4,2
<GaryvdM> *1.4.2
<GaryvdM> anddam: I would recommend this: http://wiki.bazaar.canonical.com/MacOSXDownloads
<anddam> no, I'm using mp
<anddam> I mean I don't need further instructions, I just wrongly assumed bazaar was the right port
<GaryvdM> anddam: ok
<anddam> thanks anyway
<anddam> is baz distributed?
<GaryvdM> Yes, but really really old
<GaryvdM> and unsupported
<GaryvdM> anddam: The reason I'm recomending our download in that our download has everything for the gui. Installing the gui via mp will be difficult. (not sure whether this is important to you)
<anddam> no really
<GaryvdM> ok
<anddam> I'd not be using mp in that case
<GaryvdM> anddam: it is also very easy to run bzr from source.
<anddam> run==build?
<luks> no, run :)
<anddam> scripted?
<GaryvdM> python
<luks> bzr is written in python
<anddam> I mean it's interpreted rather than compiled?
<nDuff> anddam, Python with C modules for speed
<anddam> I see
<anddam> I'll let mp do the magic tho', that's the whole poing in a package manager
<anddam> s/poing/point/
<GaryvdM> I see
 * anddam builds dependencies, that's the whole point in using a package managerâ¦ 
 * anddam sighs
<anddam> I can't recall if I already asked, is bzr suited to work with mercurial repository?
<luks> hg is probably better at that :)
<anddam> I read the migration doc and I saw it has hg module but can I "pull" (is that the right action?) into an hg repo?
<nDuff> anddam, there's a plugin: http://wiki.bazaar.canonical.com/BzrForeignBranches/Mercurial
<luks> I'm not sure if bzr-hg supports at least dpush now
<anddam> luks: yes but the "Why is Bazaar better" page got me with the disk usage comparison
<GaryvdM> anddam: Yes, with bzr-hg you would just do branch/pull
<anddam> svn's commit being "push"?
<GaryvdM> anddam: svn commit â bzr commit + push
<GaryvdM> anddam: or bzr push in a bond branch (aka checkout)
<GaryvdM> * bzr commit in a bond branch (aka checkout)
<nDuff> s/bond/bound/
<anddam> so my question was meant with "push" rather than "pull", namely I'm thinking about a Google hosted project
<Raim> anddam: use bzr instead of bazaar port with macports
<anddam> Raim: lol, hi man
<Raim> hi anddam :)
<anddam> I just wrote that myself a few lines up
<luks> anddam: bzr-hg doesn't support that
<luks> if it's your project, then you can use Google's svn with bzr-svn
<anddam> Raim: I'm looking at the portfile now, namely the tcl split you made
<luks> that will work jut fine
<anddam> luks: this way loosing the distribution in DVCS, isn't it?
<luks> anddam: depends on how you look at it
<luks> of course if you want the best DVCS experience, then I'd suggest you to use bzr natively
<anddam> the point is I'm DVCS agnostic atm and I'd like with one tool rather than several, from what I can read I like bazaar more but I'd like to work easily with G Project Hosting
<luks> is hosting the code launchpad a problem?
<GaryvdM> anddam: bzr-svn support is excellent
<anddam> luks: I don't think it'd be
<GaryvdM> anddam: bzr-hg is in development...
<anddam> Raim: it's installing the whole py26 depsâ¦
<anddam> Raim: from what I heard on chan the main issue in adopting a DVCS rather than svn for trunk is GPL, right?
<anddam> Raim: did you follow (one of) the last discussion?
<Raim> anddam: kind of, MacPorts is using svn as that is what is being shipped with OS X
<anddam> to build a mp system out of the box?
<Raim> yep
<anddam> Raim: I mean one could provide a bootstrap pkg
<anddam> Raim:  I kinda ends messing up repo with svn, like the infamous email address commit
<anddam> fetching bzr now :-)
<Raim> anddam: unfortunately bzr-svn lacks keyword expansion for svn:keywords, so if you plan to use that it will not work correctly
<anddam> Raim: well, no, I'm trying to switch to distributed, otherwise I can stay with plain svn client
<jelmer> Raim: keywords work but you have to do some additional local configuration
<KhaZ> Hello: I'm wondering if this is a crazy idea, and how one would go about implementing it.  We use Perforce at work (sadly; particularly at times like today when it's down), and I'd like to work around it's outages.  I was thinking it would be neat to 'double-version' our source code - once in Perforce, and once in bzr.  Ideally I'd work in bzr, have my commits to bzr 'queued' to be put into perfroce at some
<KhaZ> time, and then be able to commit them all to Perforce some time in the future.
<KhaZ> Does this sound like something automatable, or does this sound purely crazy? :)
<jelmer> KhaZ, it sounds reasonable
<jelmer> I think somebody (Matt?) once started on a plugin for this sort of thing named bzr-p4
<jelmer> I'm not sure what its status is though
<rubbs> I"m not entirely sure, and I'm definately not an expert (I'm better at helping complete newbies), but you could automatically pump out your changes as patches and then commit them with preforce
<rubbs> perforce*
<KhaZ> Hrmm, interesting.  I'll give that some thought.
<rubbs> I'd checkout jelmer's suggestion of bzr-p4 first.
<nDuff> bzr-p4 looked subject to severe bitrot last I checked
<nDuff> which was within the last week
<rubbs> ah
<KhaZ> Still, might be a good launching point - I've never written a plugin for bzr before.
<KhaZ> Would be nice to add a true 'disconnected mode' for Perforce.
<poolie> hi jam?
<poolie> hello lifeless
<lifeless> hi poolie
<poolie> hey
<lifeless> rsync is having trouble with my BackupPC llink farm
<poolie> too many hardlinks?
<lifeless> yeah
<lifeless> that and an assertion in the rsync code base
<lifeless> I hope the too many links issue is ext3 vs btrfs
<lifeless> poolie: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/4614
<poolie> istr rsync has some kind of hardcoded limit on the number of links
<poolie> or did ten years ago
<lifeless> thats likely too
<lifeless> this is rsync3
<lifeless> which is pretty nice
<bob2> are you using btrfs on your desktop or backup server?
<lifeless> backup USB2 connected drive on my home server
<lifeless> main drive is ext3
<lifeless> actually, main drive is raid 5 on 4x320GB disks w/ext3.
<lifeless> poolie: I've discussed this with dbarth; I'm going to be timeshifted to evenings this week to help dx with a sprint
<poolie> k
<jelmer> hey lifeles, poolie
<jelmer> does either of you know if the config editing code changed recently?
<poolie> hi
<jelmer> I'm suddenly finding my mock Config object needs to implement _get_config_editor()
<poolie> not as far as i know
<lifeless> I don't remember anything
<poolie> check the log i guess
<poolie> log -p|less may help
<poolie> or bzr search
<jelmer> lifeless, that's worrying :-)
<jelmer> poolie: I'll have a look
<poolie> jelmer, iirc you're going to uds with the soyuz team?
<jelmer> poolie, yes
<spiv> Good morning.
#bzr 2010-03-02
<igc> morning
<poolie> hi spiv! igc!
<igc> hi poolie, spiv, jelmer, lifeless
<igc> lifeless, poolie: has anything changed in the PQM setup recently?
<igc> I'm getting "ender not authorised to commit to branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ "
<lifeless> igc: I haven't asked for any config changes
<igc> lifeless, poolie: is that the right branch for 2.1 submits?
<lifeless> igc: that is a release branch, which may have a different commit group; have you submitted to 2.1 before?
<igc> *s*ender
<igc> lifeless: maybe not
<lifeless> spm: ^ please check igc is inthe release manager group in the pqm config
<spm> igc: yup; you're in the RM group
 * spm checks logs...
<igc> spm: hmm
<spm> igc: how long ago did you submit?
<igc> spm: around 11.30pm last night
<spm> igc: we need to chat about your working hours... ;-)
<igc> spm: http://pastebin.com/EGv3bFy8
<igc> spm: :-)
<spm> igc: should that be to 'bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1' vs http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/ ?
<lifeless> spm: I don't think so, isn't there a mapping section
<lifeless> ?
 * lifeless really needs to make this totally painless
<lifeless> well
<lifeless> anyone can do that. lp:pqm. kthanks
<poolie> igc that branch looks right to me
<spm> [/home/pqm/archives/thelove/bzr/2.1]
<spm> publish_to=bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1
<spm> published_at=http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1
<spm> lifeless: yeah...
<poolie> it may need no trailing slash?
<poolie> it's incredibly finicky
<lifeless> I suspect that that is it
<igc> ok, I'll try with no trailing slash
<igc> spm, lifeless: that's looking better thanks. Failing now due to a text conflict in NEWS which is much better
<spm> heh, for values of "better" :-)
<poolie> spm, can you review tuolumne changes at all?
<spm> poolie: sure can, I gather that's a review request of your recent one.
<bjp> is nested branches the best way to handle multiple branches taht depend on the same branch?
<bjp> like multiple programs using a shared library
<spm> poolie: *comments*!!!! I'm inclined to auto-approve +1 on that basis alone! ;-)
<poolie> spm, yes, :)
<igc> poolie: any chance of some 2 minute reviews soon on the 2 trivial patches I submitted yesterday?
<poolie> some chance :)
<igc> poolie: I want to build a fresh set of CHM files for 2.1 and those patches would be nice
<poolie> sure
<igc> poolie: one is desktop-link, the other is drop-analytics
<igc> poolie: thanks
<poolie> igc, sphinx's setup is a bit of a rats' nest
<poolie> i love the results
<igc> poolie: the desktop link one adds "Desktop Guide" into "Related Links" and moves Developer Docs to the top of the 2nd column fwiw
<poolie> yep, i can read it
<poolie> i just don't like changing it
<igc> poolie: just saving you from running sphinxx to see the results :-)
<poolie> +1 on both
<poolie> thanks
<poolie> spiv, you may have noticed our cup brimmeth over
<spiv> :)
<spiv> I'll see what I can do.
<thumper> what was the name of the plugin that gives general author stats for a branch?
<Peng> bzr-stats, IIRC?
<thumper> Peng: ta
<spiv> poolie: would you like to give a second review to https://code.edge.launchpad.net/~parthm/bzr/138600/+merge/19471 (and its backport to 2.1, https://code.edge.launchpad.net/~parthm/bzr/138600-2.1-mkdir-should-fail-on-invalid-parent/+merge/20199)?  It's short.
<marv> so I did a "bzr branch http://svn.digium.com/svn/asterisk/branches/1.4 asterisk-1.4", and it seemed to mostly work, but most of the tags (if i do bzr tags) show their revision as "???", even ones i know are on the 1.4 branch, like 1.4.29
 * igc lunch
<marv> which is somewhat disappointing because for the most part i'd like to branch off of a certain tag, and then when upstream makes a new release merge in up to the next tag
<spiv> marv: that means that your branch doesn't include the revision referred to by the tag
<spiv> marv: if you use 'bzr svn-import' to import all the branches and tags, then those revisions should be present in the resulting bzr repo.
<spiv> marv: you can always "bzr branch" directly from the relevant svn tag, of course.
<spiv> marv: (and if you do it in a shared repository, whether made by 'bzr init-repo' or 'bzr svn-import', it will be much faster to do so than the first fetch from SVN)
<marv> but i can still pull new changes from svn after I do an svn-import?
<spiv> marv: yep
<spiv> marv: just "bzr pull" in an individual branch, or you can re-run 'bzr svn-import' to update the whole set.
<marv> I don't really want to run commands like 'bzr branch svn-url' too often, they probably don't appreciate that load on their svn server
<spiv> marv: if you do in in a shared repo, most of the data will already have been converted when you make the first branch, so the load should be fairly low.
<spiv> Not as cheap as the equivalent SVN command, but not ridiculously larger either.
<marv> ah i see now. looks like the tag was modified after it was tagged
<marv> guess that makes their tags not really tags
<marv> subversion might be a little too free form some times
<poolie> spiv, ok
<poolie> spiv, parthm, i think we're still finding our way as far as risk/reward for stable updates
<poolie> to me this is not a very severe bug
<poolie> so worth fixing but perhaps not worth taking the risk of breaking the stable branch
<poolie> even if that risk is not very high in absolute terms
<poolie> what do you think?
<spiv> poolie: I don't feel strongly either way about this change
<spiv> poolie: which is probably an argument against the backport :)
<poolie> probably
<poolie> we should work out how to articulate the line
<poolie> for me it should be closer to "prevents you getting stuff done" than "a bit annoying"
<poolie> after all we don't backport performance things, generally
<poolie> and many of them may have a larger user impact than this bug
<spiv> "user impact" is a difficult to quantify concept.
<spiv> For instance, I don't think I've ever used 'bzr mkdir', so for me the benefit of this patch would be zero.
<spiv> But if there are users that use it daily, then that's a different story.
<spiv> In this instance, I don't really have a good idea of where this feature lies in the spectrum of "literally no-one cares" to "some users use it every day".
<spiv> With many features it's easier to judge; I think we have a reasonably good idea that e.g. ftp support is used a lot by a small minority (and against a wide variety of servers).
<spiv> Anyway, for the mkdir patch, it certainly isn't in the "prevents you getting stuff done" category.
<spiv> Or even close to it.
<spiv> I'm not sure that performance improvements make a good comparison though, because they are often more wide-ranging patches.  Although they are interesting in that one person's annoying performance may be another's unusable performance.
<poolie> that's true
<poolie> both parts are true but particluarly that they tend to be more intrusive
<spiv> On a completely different topic: http://exogen.github.com/nose-achievements/
<spm> poolie: have done a couple of minor fixes (really. minor.) and result set is here: https://pastebin.canonical.com/28557/ if you would like to sanity check the numbers?
<poolie> that's cute
<poolie> spm it's a bit gross (but not at all your fault) that this is mixing things about bzr on launchpad with things about the bzr project
<poolie> is it too gross?
<poolie> should we s/bzr/bzrproject/ in my methods, or something like that
<spm> poolie: not to my mind. (being gross as in). I think it's fine as is; I'd only advise doing the separation if that'll make stuff easier for you?
<poolie> i think it will avoid confusion and it's probably better done now than later
<poolie> the numbers look plausible
<poolie> thanks for reviewing/fixing it
<spm> sounds like a plan; just doing the review write up now which mentions the fixes needed.
<poolie> spm so do you want to do these tweaks or should i?
<poolie> to be clear, with the renaming, i'm just talking about renaming it in the self.store calls
<spm> poolie: probably best if you do it; then it stays in the same branch/merge proposal (I think....)??
<poolie> mm
<poolie> no, you can just merge your branch with the changes
<poolie> lp will see the common ancestry
<spm> ha. I just *run* LP, I don't know how to use it. :-D
<poolie> so...
<poolie> maybe you should do it, for practice? :)
<spm> sssh. :-) is pushing atm...
<spiv> poolie: I see you are filling in commit messages on your merge proposals... does that mean you have a tool to turn a mp into a pqm request?
<spiv> Oh,
<poolie> i do :)
<spiv> I just saw the mail :)
<poolie> it's a bit crude but better than doing it by hand
<lifeless> poolie: what are you doing for \n ?
<poolie> in pqm?
<lifeless> yeha
<lifeless> I mean, commit -> mp is fairly lossless
<poolie> replacing it with spaces and ennui
<poolie> spiv, i agree about 'almost ready' etc
<igc> bbl
<vila> hi all !
<GaryvdM> Hi vila
<GaryvdM> Hi all
<GaryvdM> Is there a way to make pqm use ssl for the smtp server?
<GaryvdM> *bzr-pqm
<GaryvdM> So that I can use the gmail smtp server
<lifeless> yes
<lifeless> bzr help configuration / bzr help email
<lifeless> one of those docs the options I think
<GaryvdM> Thank lifeless
<GaryvdM> Ah - Using the smtp.gmail.com:465 (ssl) does not work, but smtp.gmail.com:587 (TLS) does
<fullermd> Port 465 is totally on my "die-already" list   :p
<spm> fullermd: it's a long shot; but could you add ports 135-139 inclusive for me on that list? no reason....
<fullermd> Oh, those are long since dead to me.
<GaryvdM> Hi bialix
<bialix> Hi GaryvdM !!!
 * spiv calls it a day
<vila> spiv: have a nice evening and say hello to Vincent and his mother from me :)
<vila> s/from/for/ ?
<thumper> what is the easiest way to get the local user from the bzr config?
<thumper> using bzrlib
<lifeless> look at builtins.py
<lifeless> cmd_whoami
<thumper> ack
<GaryvdM> thumper:
<GaryvdM>         config = self.tree.branch.get_config()
<GaryvdM>         self.default_author = config.username()
<spiv> vila: both "from" and "for" are ok I think, but "for" is the more common choice for that phrase.
<vila> spiv: ack ;)
<thumper> is there an easy way to extract out the "Eric the Viking" and "eric@vikings.net" from "Eric the Viking <eric@vikings.net>" easily with the config or do I need regex?
<lifeless> thumper: use the email parsing module if you need to do that
<spiv> There's bzrlib.config.parse_username
<vila> thumper: look into config.py
<spiv> But... *shudder*.  I'd be inclined to use a proper email parser, like lifeless suggests.
 * thumper looks at what launchpad uses
<mwhudson> there's something in the email package for it
<thumper> email.Utils.parseaddr
<thumper> awesome
<lifeless> I thik we have our own one because we get weird shit
 * bialix waves hi all
<igc> hi bialix
 * igc dinner
<bialix> hi igc, bon appetit
<GaryvdM> bialix: for rev 1207 in qbzr trunk. I'm not sure how it looks on windows.
<bialix> I can check
 * bialix pulling
<GaryvdM> bialix: Please let me know if it is not good.
<GaryvdM> To see the change, do bzr update -r -2 ; bzr qcommit
<bialix> not so fast
<bialix> GaryvdM: I don't see anyhing new in qcommit dialog
<bialix> GaryvdM: I don't see anything new in qcommit dialog
<bialix> I've did: bzr update -r-2; bzr qcommit
<bialix> and have usual qcommit dialog
<GaryvdM> bialix: press ok
<bialix> ok, I see now
<bialix> it's a bit too big
<bialix> IMO
 * bialix preparing screenshot
<bialix> I would prefer smaller icon
<GaryvdM> Yes - need to resize the icon.
<bialix> GaryvdM: http://imagebin.ca/view/2kq8NvOq.html
<GaryvdM> bialix: Thanks
<GaryvdM> I was hoping that the background would be tool tip yellow
<bialix> also I have suggestion about text: IMO better: "...To commit, update the working tree first."
<bialix> GaryvdM: there is no tooltip
<GaryvdM> I wanted the background of the frame to be yellow.
<bialix> ah
<bialix> understand
<GaryvdM> I also need to make the frame and the textbox the same width.
<GaryvdM> Ah - just need to make the textboxes colspan = 2
<ahorden> hi, I am setting up a shared resporatory and so far everything works, we can do a push pull checkout commit and worked out of the box with no effort, problem is if I ssh into the centeral server and check the location of the shared resporatory bzr log works fine but there are no files in any of our branches? any ideas? I did a bzr init-repo --no-trees sftp:// and then a bzr init on the indevidual projects. Any ideas why the cent
<ahorden> eral server does not keep the files inside the rsporatory?
<bob2> that's waht --no-trees does
<bob2> and is fine
<ahorden> ah thanks bob2, I over looked that, the problem is the server is for development so on a push I wanted the changes to go live, any way I can revert away from --no-trees no I have a running setup?
<ahorden> *now
<bob2> that doesn't help
<bob2> push doesn't update the working tree on the remote end
<bob2> (unless you're pushing to a file://) url
<bob2> you could switch it to have trees + install the update-after-push plugin on all the clients
<ahorden> so we would be better using it the way we have it now, and have a shell script do the checkout somewhere else away from the working resporatory?
<ahorden> so to do a backup from bazaar all we need to do is run a checkout and stick this on our backup rotation?
<bob2> you can just back up the repository
<ahorden> bob2 this is where the confusion hit me, I was going to do that but then noticed no files other than directories with a .bzr in it so I was suspecting that would not work, but now I get how a --no-trees works
<bob2> all the revision data is in the .bzr dirs
<bob2> it's just nto checked out
<ahorden> ah thanks bob2 I will keep playing, we use git in work so just trying to move over to bazaar on my own systems
<bob2> in git you're discouraged from pushing to non-bare repositories for the same reason
<tasslehoff> What GUI would you recommend for working with bzr in Windows? "none" is not a valid answer ;)
<tasslehoff> I tried bzr explorer, but it is far from stable on my system when I work with a tree checked out from an svn server
<ahorden> whats the best way to import from git?
<thrashold> Hello. I want to include someone else's source code inside mine. Both of us are using bzr. What is the best thing I can do, since bzr doesn't support external references? Fork it?
<GaryvdM> tasslehoff: what errors do you get?
<GaryvdM> tasslehoff: bzr explorer is the best we have. Hopefully we can solve your problems.
<tasslehoff> GaryvdM: I choose "log history", right click a commit and select "show tree". It crashes with bzrlib.errors.NoSuchRevision
 * GaryvdM checks bug db
<tasslehoff> GaryvdM: lunch now. back to debug more later
<GaryvdM> tasslehoff: Seems like bug 383359. If you subscribe to that, you will get notified when it is fixed.
<ubottu> Launchpad bug 383359 in qbzr "qlog remotebranch/file crashes if there are revisions missing in the current directory." [Medium,Fix released] https://launchpad.net/bugs/383359
<tasslehoff> GaryvdM: back. thanks. released doesn't mean released to the general public?
<GaryvdM> Oh, sorry I made a mistake. That was fixed in 0.11.0 which is released. I thought that it was not fixed.
<GaryvdM> tasslehoff^
<GaryvdM> tasslehoff: I'll log a new bug
<GaryvdM> tasslehoff: what happens if yeu run bzr qbrowse -r XXX ?
<GaryvdM> *you
<tasslehoff> GaryvdM: the same for a rather new version. for version 15 in the tree (now at ~1500) it works
<GaryvdM> tasslehoff: so you got the some error?
<GaryvdM> *same
<tasslehoff> GaryvdM: yes
<GaryvdM> jelmer: ^
<jelmer> hey GaryvdM
<jelmer> I think I missed some context
<GaryvdM> Hi jelmer
<GaryvdM> jelmer: If he does bzr qbrowse -r XXX he gets bzrlib.errors.NoSuchRevision
<GaryvdM> jelmer: bzr-svn branch
<jelmer> does the revision actually exist ? :-)
<jelmer> does bzr log -rXXX work ?
<GaryvdM> jelmer: How do you get the revision to be fetched
<GaryvdM> jelmer: He can see it in qlog
<jelmer> how do you mean?
<jelmer> in that case, what about "bzr ls -rXXX" ?
<tasslehoff> http://pastebin.ca/1819014
<jelmer> that doesn't look like a bzr-svn branch
<jelmer> (CHKInventoryRepository)
<tasslehoff> jelmer: I followed "A simple example" on http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/svn_plugin.html to get started
<GaryvdM> tasslehoff: Ok - I don't know what is causing that, but I can get browse to ignore it.
<jelmer> is that revision a ghost perhaps?
<GaryvdM> Perhapse
<GaryvdM> jelmer: qbrowse tries to load all revisions for inventoryentry.revision
<jelmer> GaryvdM: that'd explain it
<tasslehoff> it actually works on every revision up to 1500, and fails from there
<GaryvdM> jelmer: Is there a way to get bzr to fetch the ghosts?
<jelmer> GaryvdM: bzr fetch-ghosts
<GaryvdM> tasslehoff:logged as bug 530606
<ubottu> Launchpad bug 530606 in qbzr "qbrowse chashes on branch with ghost revision." [High,Confirmed] https://launchpad.net/bugs/530606
<jelmer> GaryvdM: but they might not be fetchable
<tasslehoff> GaryvdM: ok
<jelmer> GaryvdM: in other words, not present anywhere
<tasslehoff> how can I check if it's a ghost commit?
<GaryvdM> jelmer: Ok. Thanks for the help.
<GaryvdM> tasslehoff: try bzr fetch-ghosts
<jelmer> GaryvdM, If it's a bzr-svn repo the revisions probably just won't be there
<tasslehoff> GaryvdM: it did something, and said "Still missing" about four revisions
<GaryvdM> tasslehoff: I'm not sure what would cause that. But I should be able to fix bug 530606 by the next qbzr release.
<ubottu> Launchpad bug 530606 in qbzr "qbrowse chashes on branch with ghost revision." [High,Confirmed] https://launchpad.net/bugs/530606
<tasslehoff> GaryvdM: great
<maxb> jelmer: dulwich got push --overwritten? Dropping "Fix memory leaks in error paths." ?
<jelmer> maxb: oops, yeah
<jelmer> maxb: I must've thought I forgot to dpush earlier
<jelmer> maxb: Thanks for pointing that out, should be fixed now.
<maxb> that was fast!
<GaryvdM> Hi vila, Are you arround ?
<vila> GaryvdM: no ?
<vila> :)
<GaryvdM> Hi
<GaryvdM> vila: I'm looking test code that creates a tree with all the different types of conflicts.
<GaryvdM> I'm batteling to grok test
<GaryvdM> *test_conflicts
<vila> GaryvdM: Yeah, tell me when you find it :)
<vila> ha, yeah, it's a work in progress
<GaryvdM> Oh
<GaryvdM> So I need to write my own. Any tips?
<vila> The best ones so far are in bt.test_conflicts
<GaryvdM> Ok - thats what I was looking at
<vila> I've started writing them as shell-like tests, but 1) that means blackbox tests 2) less precise
<vila> I started converting them to whitebox tests instead and already found a bug
<vila> So TestResolveContentConflicts is the last I wrote and the most recent
 * GaryvdM looks
<vila> GaryvdM: bug qblame would tell you that :)
<vila> GaryvdM: What is your intent ?
<GaryvdM> vila: Tests for bp.qbzr.lib.treewidget
<GaryvdM> Before I start fixing some of its bugs
<GaryvdM> One such bug is bug 528548
<ubottu> Launchpad bug 528548 in qbzr "qbrowse: can't open tree with conflicts if conflict file has been deleted" [Undecided,New] https://launchpad.net/bugs/528548
<vila> hmm, then you can start with the scenarios already described in the tests
<GaryvdM> Yes - that is what I'm hoping to do.
<vila> the bug description is scarce...
<vila> As far as you're concerned, you should have to worry about whether a file is involved in a conflict, it's either versioned or unknown (or ignored) no ?
<vila> s/should/shouldn't/
<GaryvdM> vila: I give options from qbrowse to open extmerge and resolve
<vila> GaryvdM: haa. But only for text conflicts right ?
<GaryvdM> The extmerge is only availible for text conflicts, But I show a status for  All conflicts, and the option to resolve
<vila> interesting
<vila> you know you can start displaying *several* options to resolve ?
<GaryvdM> Yes. I have been ramping up on your improvement to resolve.
<GaryvdM> vila: see http://bazaarvcs.wordpress.com/2009/11/08/new-working-tree-features-in-qbzr/ for screenshot.
<vila> nice
<vila> GaryvdM: Some info on the coming features here : http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
<vila> GaryvdM: Explicitly marking the file as resolved should be the exception, there are ways to mark them automatically (today for text conflicts, soon for more)
<vila> GaryvdM: Keep that in mind for the ui
<GaryvdM> ok
<vila> but as far as bzr-2.1 is concerned, you're fine with this design
<GaryvdM> It's the first time I've seen TestCaseWithTransportAndScript. That's cool
<GaryvdM> Thanks vila.
<vila> hehe
<vila> Don't abuse them though, they are good for bug reports but a bit imprecise (since they are essentially blackbox tests)
<GaryvdM> But fine for creating trees with conflicts?
<vila> GaryvdM: if you explore the history around bug #529968 you'll see why
<ubottu> Launchpad bug 529968 in bzr "bzr resolve --take-this fails to rename file.THIS to file on ContentConflict " [High,Fix released] https://launchpad.net/bugs/529968
<vila> GaryvdM: they are fine to create any configuration you may think of
<vila> GaryvdM: but they are not the right tool for whitebox tests
<GaryvdM> ok
<GaryvdM> vila: Could you please point me to some example code again. I have a set of trees, and a set of widget tests. I want to run each test on each tree
<vila> see bzrliv.tests.test_conflicts.load_tests
<vila> your widget tests should be in classes that define attributes that are set by load_tests via a scenario
<vila> a scenario is a tuple (name, dict)
<GaryvdM> vila: there is no  bzrliv.tests.test_conflicts.load_tests, but I'm looking at another load_tests :-)
<vila> name is displayed while running the tests as test_this(name) and dict contains the test class attribute names as keys and values as... values
<vila> s/bzrliv/bzrlib/ and update you bzr.dev :)
<GaryvdM> ah - the code never sleeps...
<vila> hehe
<GaryvdM> Hmm - I think I should do it the other way around. The widget configuration should be the senerio, the with a tests for different trees.
<mtaylor> anybody around with pipeline zen?
<mtaylor> I've got a pipeline that I want to push all of the pipes to launchpad so that I can do lp-submit
<bjp> is nested branches the best way to handle multiple branches taht depend on the same branch?
<bjp> like multiple programs using a shared library
<jelmer> bjp: nested branches don't exist yet
<bjp> it doesn't? i thought it did...
<bjp> i could have sworn i tried it out a couple months ago :/
<jelmer> perhaps you're using a different name?
<jelmer> what did you do ?
<bjp> branch within a branch
<jelmer> oh, that works indeed - but cloning one branch won't clone the containing branches
<bjp> with --bind (i think)? and their versions are tracked?
<jelmer> bjp: bind is for bound branches
<bjp> i was looking for a way to track a couple projects with shared dependencies, nested branches (trees?) was the only thing i found about it
<jelmer> nested trees don't work yet; perhaps you tried one of the plugins?
<bjp> i'm trying to find the web site i was reading
<bjp> http://doc.bazaar.canonical.com/devnotes/nested-trees.html
<bjp> is there a plugin that does something similar?
<mgedmin> say, I bzr get lp:ubuntu/karmic/mc
<mgedmin> is there a way of now doing bzr get lp:ubuntu/lucid/mc and share part of the history I already downloaded?
<mgedmin> create a stacked branch e.g.?
<lifeless> stacked branches don't do that
<lifeless> repositories do
<lifeless> so - bzr init-repo mc
<lifeless> cd mc
<lifeless> bzr branch lp:ubuntu/lucid/mc
<lifeless> bzr branch lp:ubuntu/karmic/mc
<lifeless> mgedmin: we strongly prefer 'branch' to 'get'.
<mwhudson> mm
<mwhudson> jelmer: http://launchpadlibrarian.net/39998980/albatross-trunk-log.txt <- new one on me!
<mgedmin> 'get' is shorter to type, just be happy I wasn't doing 'bzr co' ;)
<mwhudson> (bzr-hg failure)
<mgedmin> back to the question: I already did bzr branch for the karmic
<mgedmin> can I bzr branch mc new-repo/mc-karmic to get it to not download the whole history again?
<mgedmin> can I have the repository not in ../ but rather next to the branches?  bzr init-repo .bzrrepo; bzr branch lp:... --using-repo=.bzrrepo ?
<jelmer> moin mwhudson
<jelmer> bjp, bzr-externals I think
<jelmer> bjp: I have no experience with it though
<jelmer> mwhudson, how's the kernel import?
<mwhudson> jelmer: i think it got like 6k revs in or something
<mwhudson> (staging is down for an update)
<mwhudson> and then it failed, but in a way that didn't leave logs, so that probably means it being down for an update killed it or something
<bjp> jelmer: interesting, is that the best way to handle the dependency problem until nested-trees is available?
<bjp> i'm just looking for a good solution
<mwhudson> jelmer: better than before, definitely
<jelmer> bjp: I'm not sure, I'm probably not the best person to ask..
<jelmer> mwhudson: but hopefully it'll continue after the update?
<mwhudson> jelmer: yeah
<bjp> k
<poolie> hello all
<james_w> morning poolie
<poolie> hello james_w
<poolie> james_w, any special requests at the moment?
<james_w> nothing special
<poolie> ok
<poolie> we're pretty busy this week with community reviews
<poolie> i expect we will get into rebase or conflicts after they're more in hand
<poolie> i liked your mail  'what is bazaar about?'
<poolie> i might try to answer it more fully in a separate thread
<poolie> i think essentially i want something that's very easy and straightfoward for new contributors, but that has enough power and extensibility not to hold advanced developers back
<poolie> perhaps that sounds too close to 'all things to all people'
<james_w> yeah, I wondered if it should be a new thread, as it could be a long discussion :-)
<james_w> do you know about Personas?
<poolie> also this is a place where my two different hats as project leader and as canonical staffer are a bit different
<poolie> not in disagreement but different emphases
<poolie> yes, i know the idea
<james_w> yeah, I can see how that could be tricky here
<poolie> do you think they would be a good way to define this?
<james_w> good, it could be a useful tool to help talking about this
<poolie> so to define the few archetypal personas we care about?
<poolie> that could be good
<james_w> then you don't have to talk about "enough power and extensibility", you can say "Amy, an experienced Python coder can write plugins based on good documentation of how to start one and good API docs that allow her to customise Bazaar to her team's needs"
<james_w> which gives you something to aim for
<poolie> right
<poolie> to me that's one step down from the real values of the project, but definitely easier to put into non-waffly words
<james_w> yeah, I guess the values are embodied in the few personas you pick to play this role
<poolie> and in the general culture/feeling of the list
<james_w> yes
<igc> morning
<jasonlife> I can ssh into my bzr server without passwd, but I keep getting passwd prompt when I run bzr command, like "bzr up"
<bob2> windows?
<jasonlife> no
<jasonlife> do I have to do something to prevent passwd with bzr commands?
<bob2> not really anything to do with bzr
<bob2> it just uses ssh
<jasonlife> hmm
<bob2> maybe ~/.bzr.log says something interesting?
<jasonlife> that I expect.. but it doesn't work.. weird
<jasonlife> I see
<jasonlife> Nothing special I guess.   I have line about ssh... 0.295  ssh implementation is OpenSSH
<james_w> morning igc
<jasonlife> bob2: sorry for the noise.. After I checkout with bzr+ssh instead of sftp, no passwd anymore.. :)
#bzr 2010-03-03
<jasonlife> Do I create one repo per project? or one repo for all projects ?
<jasonlife> Do I have to
<bob2> either
<bob2> there's no storage-space benefit to the latter
<jasonlife> Is there no right way to maintain repo and project?
<jasonlife> If I have just one repo, then it ends up with a lot of projects and their different branches in one place.. so it may be bad..
<bob2> who cares?
<jasonlife> :P
<jasonlife> bzr maintains different directories for different branches of same project.. right?  I'm new to bzr..
<bob2> a branch is a directory
<jasonlife> in cvs, it maintains only one directory even if I created multiple branches..
<jasonlife> that's why I'm wondering..
<Peng> The benefit of repo-per-project is if projects use incompatible repo formats, or if you want to delete a really large one or something.
<jasonlife> and I can use shared repo feature with different branches of same project I guess.
<Peng> Yes. THat is what it is for.
 * igc lunch
<AfC> lifeless: I'm very intrigued by your commitfromnews plugin
<lifeless> AfC: cool
<MTecknology> With subversion you can proxy the traffic through apache so you can have pretty fine grained control over who can access what. Is there any easy way to do this with bzr? I was looking at the launchpad code to get an idea but that's pretty hard for me to understand and follow
<AfC> lifeless: Since most people can't be bothered (or taught, it seems) to write "good" commit messages, and since commit messages aren't editable in Bazaar, I've been increasingly down on them as a change log for a code base.
<AfC> lifeless: but the prospect of people editing ChangeLog files explicitly doesn't appeal much either (since merging branches with {NEWS, ChangeLog} type files is a nightmare)
<AfC> lifeless: your plugin makes me think that maybe the two together might be ok (as people could see the ChangeLog and be more likely to follow its patterns; and meanwhile the log|visualize view of history isn't completely useless
<AfC> lifeless: I realize full well that your plugin was for a file called NEWS, but it got me thinking.
<AfC> [I know, I know, thinking without a licence. Scary, this free market economy]
<lifeless> AfC: the plugin could be easily extended to support other file names.
<AfC> lifeless: no doubt
<lifeless> MTecknology: there is a thing in contrib
<lifeless> MTecknology: or unix file permissions
<AfC> lifeless: (it's the wisdom of it all that I'm mulling over)
<lifeless> MTecknology: or you can hook into it
<lifeless> AfC: so I wrote it because I've never liked 'bzr log' as a way toget a human meaninful summary of what has happened in a code base.
<lifeless> even if the commit messages are perfect, some changes union
<lifeless> e.g.
<lifeless> rev N, add feature
<lifeless> rev N+M, change feature to be better
<lifeless> rev N+M+Z do a release: but we should only mention feature /once/.
<AfC> lifeless: yeah
<AfC> lifeless: I'm not sure if this is what you're doing, but I'm guessing that in such a NEWS file Ã your plugin, the diff would show up at each merge up the chain of gatekeepers
<lifeless> indeed
<lifeless> and when doing a commit myself, I write the one for N
<AfC> lifeless: that would be good; one of my beefs is that I spend a lot of time writing the damn mainline merge commit messages; all the other bastards get away with one liners.
<lifeless> for N+M, I edit the NEWS entry
<lifeless> and the plugin gives me the edit, which I then tweak to say 'improved thing from N'
<lifeless> give it a spin
<AfC> [not the terms of warmth and affection for the wonderful contributors to the open source project I am the maintainer of]
<AfC> s/not/note
<AfC> lifeless: in my case, NEWS is hand-crafted public release note, ChangeLog doesn't exist (based on our drooling enthusiasm of the early days of DVCS that we wouldn't need one anymore).
<lifeless> sure.
<AfC> lifeless: I don't think I need *revision* resolution in a ChangeLog file, but a features, API changes, etc aggregation would be useful indeed
<lifeless> would you like a config option to set the filename
<lifeless> or just have it grab stuff from both ChangeLog and NEWS ?
<AfC> lifeless: anyway, thought I'd give you some surface level first impression feedback
<AfC> lifeless: probably both?
<lifeless> AfC: I just ordered a new laptop :)
<lifeless> i7, 2 cores w/hyperthreading.
<lifeless> the bit that I possibly went overboard on, is memory and disk.
<AfC> lifeless: (NEWS file only gets tweaked in the final weeks before a release; on the other hand, what's really missing is a Â«changesÂ» record of "what a branch actually introduces (feature, bugfix, whatever))
<lifeless> 8G, and a 128GB SSD
<AfC> nice!
<lifeless> yeah
<lifeless> lenovo have about 35% off at the moment
 * AfC is undecided on whether or not an SSD would be a good idea for him or not
<AfC> what I'd *really* love is an SSD for the /, /usr type stuff, and a fast spinnning HD for the dynamic and temporary stuff (ie, compiling fallout, web browser cache crap, etc). If I'd bought a 17" monster with 14,000 cores and two drive bays I coulda done it
<AfC> but with an itty bitty 12" with one drive bay and a ULV chip, no room for me. Not even a PCMCIA slot :)
<lifeless> mine is 12", ulv
<RAOF> They do ulv i7s now?
<lifeless> yup
<lifeless> and i5's (can be better than i7 at the same clock rate), and i3's
<lifeless> http://www.notebookreview.com/default.asp?newsID=5546&review=lenovo+thinkpad+x201+x201s+tablet
<lifeless> the x201s is what I ordered
 * RAOF is a big fan of his x200s
<lifeless> RAOF: now they do touchpads, I'm happy ;)
<lifeless> AfC: i7-620LM - the L is the low component, m is mobile
<RAOF> Oh, it's got a touchpad now?  Hm.
<lifeless> AfC: i7-xxxM is mobile - all the voltages have shifted around:P
<lifeless> RAOF: optional
<lifeless> RAOF: depending on model, the x200t always has it, I believe.
<lifeless> sory, 201t
<MTecknology> there's a bzr-email package in the repos. how does a person use that?
<lifeless> if you install it and type 'bzr help email' it has online docs
<MTecknology> lifeless: awesome, thanks :)
<poolie> hi all
<lifeless> hi
<parthm>  /leave
<poolie> igc, hi?
<igc> hi poolie
<poolie> just wondered if you were around
<poolie> i'm in the middle of something atm but wanted to chat
<poolie> missed you before
<igc> np
<lifeless> I wish the bash completion knew about the switch sarch path
<poolie> igc, how about now?
<igc> poolie: sure
<poolie> i was thinking about bzr-grep vs your 'product as platform' thing
<poolie> i'm a bit ambivalent about whether to merge it into bzr core or make it a platform
<igc> poolie: hmm
<poolie> the easy answer is to just let the author decide
<poolie> there are pros and cons
<igc> I haven't been following the discussion to be honest
<poolie> so, the details don't particularly matter
<lifeless> poolie: btw, if you want bzr-plugin-info in core; please just merge it
<lifeless> I don't object, but don't have cycles atm
<poolie> but we have some new code that could be either a plugin or builtin
<poolie> lifeless: yes it applies to that too, though it's arguably a special case cause it helps with bootstrapping
<poolie> maybe i should just post to the lisnt
<lifeless> poolie: yes; I'm not proposing that you treat all things the same way ;)
<lifeless> poolie: I'm specifically saying not to wait for me.
<spiv> poolie: drive by opinion: I think grep would be good to have in core.  I haven't carefully considered, it's just my initial reaction to the idea.  (Although maybe users will have a similar initial reaction?)
<igc> poolie: my initial reaction to "grep" is that it probably ought to be in core
<spiv> igc: snap!
<poolie> :)
 * spiv wanders off
<igc> hi spiv! :-)
<lifeless> w.r.t. grep, as a special request - consider making sure its hookable-enough for bzr-search to kick in when possible.
<lifeless> may be a YAGNI.
<spiv> igc: hi :)
<spiv> lifeless: interesting idea, probably a case of "land it first, refactor as necessary later", though?
<igc> poolie: is a 5 min phone call possible?
<poolie> eminently posssible
<igc> poolie: I'd like a quick chat re the windows installers, ec2, etc.
<poolie> call me?
<igc> poolie: sure
<lifeless> heh - cheap but humorous http://www.makeuseof.com/tech-fun/quick-glance-into-apples-future-pic/
<mwhudson> wow, bzr-svn is quite complicated
<lifeless> ...
<mwhudson> just randomly griping
<mwhudson> it wasn't totally obvious to me what a CachingRevisionMetadata was
<mwhudson> also the tests take ages and fail with the bzr i have installed
 * mwhudson tries bzr.dev
<GaryvdM> Hi igc
<igc> hi garyvdm!
<igc> garyvdm: thanks for the numerous bug fixes to treewidget
<GaryvdM> :-)
<GaryvdM> igc: I made some big improvements to the treewidget tests last night
<igc> GaryvdM: that's great news
<igc> GaryvdM: I'm wondering whether the additioal filtering I'm doing in epxlorer is triggering some issues
<GaryvdM> igc: Maybe that will make it possible to easily write a test for Bug 529985
<ubottu> Launchpad bug 529985 in qbzr "treewidget: list index out of range error" [Undecided,New] https://launchpad.net/bugs/529985
<igc> hopefully
<GaryvdM> igc: Let me have a look at the be code
<igc> GaryvdM: lib/wt_browser.py
<poolie> lifeless: i have a draft message here about patch pilots vs just helping people
<poolie> to emphasize that there's "help people" and then "staff committing to do this as a timeslice"
<lifeless> cool
<poolie> do you want me to finish/send it
<lifeless> I think its worth teasing the issues apart
<lifeless> if you think the mail will help with that, then you should send it
<poolie> ok
<GaryvdM> igc: ha ha
<GaryvdM> >                # This locks and unlocks the tree each time.
<GaryvdM> >                # I wonder how that impacts performance?
<GaryvdM> igc: Badly!
<poolie> lol
<GaryvdM> igc: The code in _QBrowseFilterProxyModel could be better a taking advantage of TreeFilterProxyModel.
<GaryvdM> igc: ie, if you overwrite filter_id rather than filterAcceptsRow, then you don't have to worry recursive loading, caching, and showing parents for children that are shown.
<GaryvdM> igc: I'll fix that for you.
<igc> GaryvdM: I'm just in the middle of something right now so I can't take a look. Is there any chance you could submit a MP or fire me an email with an explanation of what I need to do?
<GaryvdM> Sure
<igc> thanks
<lifeless> poolie: around?
<lifeless> poolie: if so, up for a quick call?
<poolie> let me finish this first pls
<poolie> 5m
<vila> hi all
<igc> hi vila
<poolie> hello vila
<poolie> how are things
<vila> fine
<vila> slowly making my way in the review queue
<vila> I was wondering about https://code.edge.launchpad.net/~parthm/bzr/138600-2.1-mkdir-should-fail-on-invalid-parent/+merge/20199
<vila> Should we land it in 2.0 and 2.1 ?
<vila> What's your opinioin ?
<vila> onion even
<vila> bah typos
<poolie> my opinion: thanks but no
<poolie> not severe enough for 2.1
<vila> ha good, just the nudge I was waiting for :) I was 60% / 40% myself (for the same reasons)
<vila> my main reason was to minimize the SRU related overall patch size, so the autopack bug from jam was ok but the mkdir should clean wasn't
<poolie> k
<poolie> explain nicely and i'm sure parthm won't be offended
<vila> k
<vila> Regarding the grep plugin though, I'm for landing into core (but still as a plugin)
<vila> likewise for plugin-info
<vila> I don't want to merge *any* plugins, but these two are exceptions :)
<parthm> poole: i won't be offended :-)
<lifeless> vila: I'm not really fussed on either; I think plugin-info has good reason to be outside [the case for updating preferred-lists without doing new releases of bzr itself]
<vila> parthm: Ha great ! :)
<poolie> lifeless: actually in that case possibly it's the list itself that should be separately updated
<vila> lifeless: hmm, I'm tempted to say you can still install locally to override but...
<vila> lifeless: Are you sure it will be updated *that* often (after some initial period) /
<vila> ?
<vila> lifeless: I think plugin-info is targeted at users who don't know the ecosystem well and as such are unlikely to install it
<poolie> that's the thing
<vila> may be the preferred-lists can be updated on demand without updating the plugin itself ?
<vila> 12GB and thrashing.... wth ?? I can't believe that with 10.5GB active and 1.4G swap used there are enough processes swiping their entire memory space.... :-/
<poolie> running what?
<poolie> i'd like to help with reviews but it's been an awfully interrupted week and looks set to continue
<vila> poolie: my desktop (including babune), no clear culprit to point my finger at, I'mm also running a bunch of emacses and firefox and whatnot
<vila> That's fine, I nudge people when needed
<vila> it also seems that runinng the test consume more memory that it used too, just a feeling across the various OSes, may just be yet another consequence of the leaking tests
<lifeless> vila: poolie: I'm not arguing for or against particulary.
<vila> lifeless: ok, I see your point anyway
<vila> GaryvdM: ping
<GaryvdM> vila:pong
<vila> poolie: did you process GaryvdM's key for pqm
<vila> GaryvdM: https://code.edge.launchpad.net/~garyvdm/bzr/commit-BoundBranchOutOfDate/+merge/20393 any problem to send that to pqm ?
<poolie> vila, GaryvdM, sorry, no
<poolie> it's flagged but i haven't done it yet :-(
<poolie> vila can you see if there's a typo or something, otherwise ping a sysadmin or send a signed rt
<GaryvdM> vila: I would like to do it myself :-) poolie: I'm not in a rush
<vila> GaryvdM: to you want me to merge it or do you still want to use it to test pqm ?
<vila> poolie: typo where ?
<vila> poolie: is there an url to look at pending RT requests ?
<poolie> GaryvdM, vila, there is already an rt for this, 35953
<poolie> claims to have been done
<poolie>  DCA3 ACB2 0CC7 D6D4 6100 18E6 77FD C477 018A 3A1D
<GaryvdM> I'll retry then :-)
<poolie> is that you?
<vila> GaryvdM: give a try and let us know
<vila> good
<GaryvdM> poolie: how do I check that?
<poolie> GaryvdM: remove the trailing slash from the destination url
<poolie> nm, it is you
<poolie> pqm is bizarrely pedantic
<vila> GaryvdM: and use submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<poolie> i think that's the problem
<GaryvdM> vila, poolie: Cool that worked.
<GaryvdM> But I got a NEWS conflict
<poolie> welcome :)
<GaryvdM> :-)
<poolie> not sure what's up with that
<poolie> better ask spiv tomorrow
<poolie> for now, merge trunk and resubmit
<vila> GaryvdM: be sure to insert your netry sorted
<GaryvdM> ack
<GaryvdM> vila: http://pqm.bazaar-vcs.org/ says the test for my patch is stuck on 0%. Is this normal?
<vila> GaryvdM: yes. :-/
<GaryvdM> ok
<vila> It's not stuck, the progress report is bogus
<GaryvdM> I see
<vila> lifeless: I thought you fixed that ^ recently ?
<vila> GaryvdM: the important bit is that it accepted your request, now you'll get a feedback mail titled either 'success' or 'failure'
<vila> the later came with a full output
<GaryvdM> vila: yes - that is cool. :-)
<GaryvdM> Now that I can submit to pqm, I'm going to have to do *mini*-patch-pilot duties. :-)
<vila> GaryvdM: Welcome !
<lifeless> vila: no, poolie added it.
<lifeless> vila: its doing a progress bar
<lifeless> vila: once spm: / lamont
<lifeless> vila: once spm: / lamont: get the python-subunit package in the bzr chroot on balleny sorted out, we can move forward.
<vila> ha, ok
<vila> losa: ping, thanks in advance ^ :)
<lifeless> vila: there is an rt, its non trivial
<vila> yeah,kidding
 * vila rejoices that it installed subunit once for all babune slaves :)
 * lifeless goes blind
<lifeless> python code written in 2007, that doesn't use optparse
<lifeless> or getopt
 * vila sends some perl to lifeless 
<poolie> GaryvdM: your branch merged, yay
<vila> GaryvdM: Congrats ! :D
<GaryvdM> Yay. Thanks for the help.
<GaryvdM> Bye. Need to focus on work
<Peng> Eh, optparse is a pain. Every time I use it, I have to find the last script I wrote that uses it and still read the docs. For a quick hack with only one or two options, it's not worth the effort.
<Peng> Once it gets more complicated than that, it's definitely worth switching to optparse, but before that? Eh.
<Peng> s/find/copy and paste from/
<distatica> I'm trying to follow http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/centralized_workflow.html But I have a problem, when I use checkout and then commit it uploads as expected but clobbers the existing dir with my new group + permissions, making it unaccessible to other members of the group.
<distatica> is there a way to stop the permissions from being written? Prefer something that doens't need to be included every commit if possible.
<fullermd> On a SysV filesystem, you need g+s on the dir to preserve the group ownership.
<distatica> oh, thank you
<fullermd> bzr doesn't touch the group, so that's all in the filesystem.
<fullermd> The perms (e.g., g+w) bzr does, based on...  uh...  some dir.
<fullermd> I just g+w everything under .bzr/
<lifeless> Peng: optparse is less code @ 2 options
<Peng> lifeless: Yes, but it's code I have to look up first.
<lifeless> Peng: even if it wasn't, getopt would be better than a manual parser
<lifeless> Peng: you've been spoilt by bzrlib :)
<Peng> I've forgotten how to use getopt after spending time with optparse! :(
<Peng> So I have to look it up too!
<lifeless> check out gtester-report
<fullermd> You could just compromise and use Getopt::Std   8-}
<lifeless> fullermd: acgggrle
 * fullermd sneaks back under his bridge.
<Peng> In my most recent manual option parsing abomination, I _was_ using optparse. I was just doing it in a really stupid way and optparse could handle it much more simply.
<distatica> thanks again fullermd, g+s fixed it perfectly.
<parthm> vila: hi.
<vila> parthm: hey
<parthm> so i was looking at bzrlib/plugins. whats needed to put a plugin there. seems like just a copy. right?
<lifeless> Peng: do you mean to merge to core?
<lifeless> bah
<lifeless> parthm: ^
<lifeless> parthm: or do you mean to install it ?
<parthm> yes. i was talking in context of vilas comment on https://code.launchpad.net/~parthm/bzr/503670-grep-builtin/+merge/20420
<vila> parthm: well, as a plugin, you need to register (lazily) the command and put your files under bzrlib/plugins yes
<parthm> iiuc i need to put the relevant files in trunk/bzrlib/plugins/grep/*
<vila> yes
<lifeless> oabzr branch lp:bzr-plugin-info
<lifeless> parthm: ^
<lifeless> copy the setup.py from there
<lifeless> change appropriately.
<parthm> lifeless: sounds fine.
<lifeless> or grab the sample from the developer docs
<parthm> one thing which came up was that the advantage of a plugin is that it can be used by 2.0/2.1 users.
<lifeless> I like plugins
<lifeless> my default is 'plugin' ;)
<parthm> does bzr provide a way for someone to checkout just bzrlib/plugins/foo?
<parthm> :)
<vila> parthm: your call, there is no urgency into merging into core
<lifeless> parthm: not really; there is views
<lifeless> but plugins in core are generally not maintained with backwards compat in mind.
<vila> parthm: I think maturing as a plugin for a couple of months is a good plan (and 2.0 users will love you too :)
<parthm> yes
<lifeless> there is my branch somewhere to include arbitrary plugins in the tarballs we make
<lifeless> but that had a bug and noone fixed it
<parthm> vila: :-) ... yes that sounds fine to me too.
<vila> parthm: in that case mark your mp as rejected and create a new one when you feel ready
<parthm> vila: ok.
<parthm> so as suggested i will continue to bzr-grep as a plugin for sometime and improve it based on feedback.
<parthm> maybe the bzr packaging (tar or installer) step should have a step to pick specified plugins to package them.
<parthm> i think linux users are ok but i suspect windows users may not bother installing plugins manually.
<parthm> thats the adv of prepackaged plugin vs external plugins
<vila> parthm: file a bug against bzr-windows-installer and osx asking for inclusion
<parthm> vila: will do.
<parthm> is there a way for including it in the source tarball thats released? or maybe getting it listed in synaptic?
<parthm> i typically pick up my plugins from synaptic and don't bother manually installing.
<lifeless> parthm: to include it in the source tarball, see the branch I wrote to do just that; its around somewhere.
<lifeless> problemis that it doesn't call into setup.py in each plugin.
<lifeless> parthm: to list it in synaptic, package the plugin and get someone on the debian plugins team to upload it to debian
<lifeless> we can sync it from there to Ubuntu a day layer
<lifeless> *later*
<parthm> lifeless: ok. i can try to do it after a few weeks when the plugin has had some time to mature.
<parthm> in the mean time i will add setup.py. how does bzr-plugin-info work, where does it get the plugin list?
<lifeless> parthm: from cached.py' bzr plugin-info --python URL URL URL .... > cached.py is how that is updated.
<parthm> lifeless: and URL is lp:bzr-xxx?
<lifeless> yes
<parthm> vila: maybe good to keep https://code.launchpad.net/~parthm/bzr/503670-grep-builtin/+merge/20420 open for some time. basically i am looking for review inputs. it can be rejected after review.
<parthm> lifeless: thats sounds good.
<lifeless> parthm: if you want review on the plugin; I suggest:
<lifeless> bzr init an empty branch
<lifeless> bzr push that to lp:bzr-grep (if vila will accomodate you :))
<lifeless> then submimt your branch to lp:bzr-grep as a merge proposal
<parthm> lifeless: ah. ok. thats sounds like a better way. i will try that.
<vila> lifeless: parthm vreated lp:bzr-grep :)
<parthm> vila: :-) in that case we can probably reject the mp. i will raise a review request against lp:bzr-grep.
<vila> but adding more devs to it would be good... what the right team ? ~bzr ?
<vila> parthm: great
<parthm> vila: will do.
<parthm> so for lp:bzr-grep, should i just change 'maintainer' to bzr-core and add myself as 'driver'. so apart from bzr-core will i also have commit permissions.
<lifeless> not bzr-core
<lifeless> bzr
<lifeless> and you should be in bzr anyhow
<lifeless> bzr-core is actually 'just bzr not plugins'
<lifeless> its confusing
<parthm> lifeless: ok.
<parthm> lifeless, vila: done. 'bazaar developers' are not listed as maintainers for lp:bzr-grep.
<lifeless> don't set a driver either
<parthm> lifeless: but won't i lose commit rights to lp:bzr-grep that way?
<lifeless> join ~bzr
<lifeless> driver doesn't do what you might think it does
<lifeless> it has no influence on commits
<lifeless> the url - lp:~TEAM/bzr-grep/branchmae
<lifeless> the TEAM there is what controls commits
<parthm> lifeless: ok. looks like i lost the rights to change the driver of lp:bzr-grep maybe you could remove my name from there https://launchpad.net/bzr-grep
<parthm> lifeless: so to join team bzr, do i send a message via "contact team's owner"?
<lifeless> parthm: I've added it to the 'bazaar' project group
<lifeless> parthm: no, you click the join this team link
<lifeless> I've also added 'bzr plugin' to the description
<lifeless> I hope thats ok
<parthm> lifeless: sorry this is taking so long. i can't seem to find the 'join this team' link on https://launchpad.net/~bzr
<lifeless> bah
<lifeless> its set to restricted
<lifeless> I'll talk to poolie about this friday
<lifeless> for now
<lifeless> whats your lp username
<parthm> its parthm.
<parthm> lifeless: looks like it worked. thanks for your help.
<parthm> vila: the grep mp can probably be rejected, i will raise an empty one against lp:bzr-grep.
<vila> parthm: I think you can reject yourself (or something is broken otherwise), let me know if you can't (I'm curious)
<parthm> vila: i can't seem to find a way to reject it. should it be listed in the "Review:" dropdown?
<vila> parthm: in the status at the top of the page
<vila> parthm: found it ? Click the little yellow pencil otherwise
<parthm> vila: ok. that worked. thanks.
<vila> parthm: great !
<vila> haaaa, https://code.edge.launchpad.net/bzr/+activereviews done to 10 mps with 4 ready to land, go bzr devs :D
<parthm> vila: cool :-)
<parthm> vila, lifeless: thanks for your help. got to go. have a nice day.
<davidstrauss> How can I convert from svn to bzr and filter out some files?
<igc> night all
<jelmer> davidstrauss: convert from svn to bzr first, then use fast-export/fast-import's filter-branch to remove those files
<parthm> hello. i am trying to add binary support (ignore binary) to bzr-grep. https://bugs.launchpad.net/bzr-grep/+bug/531336
<ubottu> Launchpad bug 531336 in bzr-grep "bzr grep does not handle binary files cleanly" [High,In progress]
<parthm> my initial thought is to catch UnicodeDecodeError and print a message that its a binary file and move on to the next one.
<parthm> i am not too familiar with unicode. does that seem like a reasonable fix?
<parthm> it will certainly be faster than looking for \x00 in the first few lines.
<davidstrauss> jelmer: thanks :-)
<parthm> nevermind. i did the fix using textfile.text_file which is very convenient.
<parthm> vila: ping
<vila> parthm: pong
<parthm> vila: hi. I am going through your comment 'I think we put new features into bzrlib.test.features instead.'  on https://code.launchpad.net/~parthm/bzr/262450/+merge/19483
<parthm> does this mean i take the _PosixPermissionsFeature and the following assignment and move it to tests.features?
<parthm> there aren't any other classes there so i was a little confused.
<vila> parthm: yes. Sorry for that, as often when we change some coding rule we haven't apply that one in the whole code base
<parthm> vila: ok. thanks for the clarification. i am closing the review comments now.
<parthm> vila: i see lines like 'subunit = tests.ModuleAvailableFeature('subunit')'. does my code just to be moved (and Feature) class imported or do i need to do something more?
<vila> just move the code and update the imports so that the tests use 'features.PosixPermissionFeature'
<parthm> vila: ok.
<davidstrauss> jelmer: How can I specify multiple exclude_paths? It's not anywhere in the documentation>
<jelmer> davidstrauss, I'm not myself familiar with bzr-fastimport/bzr-fastexport unfortunately :-?
<davidstrauss> How can I get Paramiko to use a custom SSH private key location? (Not the default of .ssh/id_rsa or .ssh/id_dsa)
<luks> davidstrauss: does Paramiko even use .ssh/id_rsa/dsa?
<luks> I thought it only supports the Putty key agent
<davidstrauss> luks: This is on Mac OS X
<luks> oh
<luks> why not use openssh then?
<davidstrauss> luks: I can.
<luks> you can set the key in ~/.ssh/config then
<luks> (Host example.com\n    IdentityFile /path/to/private/key)
<MTecknology> There's bzr-email. I read the help for it 'bzr help email' but I still don't understand how to set the configs it's referring to.
<MTecknology> hrm... Can I set those values in $HOME/.bazaar/bazaar.conf on the remote server?
<MTecknology> * that I'm pushing the code to
<Raim> if you can open a ssh session, yes...
<Raim> I mean, a shell :)
<MTecknology> Raim: I mean for the bzr-email plugin. I don't know if I need that set local or remote; now that I know what file I need to set those in
<MTecknology> I suppose now that I have a clue I can just try it to :P
<stani> When i merge branch B into branch A and commit the changes to branch A, all the commits of branch B become one commit in branch A. Is there an easy way to transfer the commits of branch B as individual commits to branch A while merging?
<vila> stani: the commits are still there as inidividual commits, try 'bzr log -n0'
<vila> or bzr qlog
<stani> thanks, can i diff them?
<stani> vila: thanks, I think i know how
<vila> stani: bzr diff -caaa.b.c should do the trick once you get the revnos from the log (or clicking at the right place in qlog)
<bialix> hi all
<bialix> I have a question about hooks
<bialix> there is open hook
<bialix> can I setup new hooks from open hook?
<bialix> say, I have config in a branch which tells me about other hooks
<bialix> then I would like to setup in runtime required hooks based on this config
<bialix> is it possible
<bialix> ?
<vila> bialix: I don't think that's the expected usage
<bialix> hi vila
<vila> bialix: you install hooks and then you can tests whether they apply or not instead
<bialix> I want to make universal hooks launcher
<vila> s/can tests/can test/
<bialix> but I don't want to install every possible hook
<vila> define universal hooks launcher ?
<bialix> I'm put the script into the tree under version control
<bialix> and I need the way to laucnh this script on hook
<bialix> say I have python module in my tree with hook implementation
<bialix> so I need only one plugin to install to launch this hooks
<bialix> vila: is it make sense? or sound crazy?
<vila> a little bit of both so far :)
<bialix> yep :-)
<thorike> thorike> hey guys
<thorike> * jelmer has quit (Ping timeout: 265 seconds)
<thorike> <thorike> i get bzr launchpad-login thorsten-prante
<thorike> <thorike> bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for https://launchpad.net/~thorsten-prante/%2Bsshkeys
<thorike> <thorike> what can i do
<vila> each hook has a different signature at least so I don't see how you will address that to start with
<bialix> vila: okay, say I have python module with hook function which conforms signature
<bialix> script won't fly, I see
<bialix> thorike: lp is upgrading now, no?
<vila> thorike: you may get better feedback from #launchpad where you already asked :)
<bialix> hmm, it's planned to upgrade today but not yet, according to announce
<bialix> vila: how can one define project-specific hooks?
<vila> thorike: from the bzr side, I don't remember a 403 for launchpad-login, so I'd suspect a server -side thing
<bialix> or better: branch-specific?
<vila> bialix: by testing that they are invoked for a given branch
<thorike> what abou bzr: ERROR: Invalid http response for http://bazaar.launchpad.net/~docky-core/docky/trunk/.bzr/repository/packs/2ff01fc6c27e6c04d7c95356fe08a608.pack: Missing the Content-Range header in a 206 range response
<bialix> vila: e.g.?
<thorike> vila, ^
<bialix> thorike: are you using proxy?
<vila> thorike: urgh, sounds like an intercepting proxy playing tricks at first glance
<thorike> yeah
<vila> thorike: bzr branch  http://bazaar.launchpad.net/~docky-core/docky/trunk docky WFM
<vila> Branched 1165 revision(s).
<vila> that adds value to the proxy cause
<j^> hi, is there a way to run loggerhead with loggerhead.conf and just auto_publish_folder
<j^> the example just sets that for a subfolder
<thorike> thanks guys
<thorike> had to reboot
<thorike> was proxy
<bialix> what it means: repacking chk?
<bialix> it seems pul from lp:bzr/2.1 triggers full repack of my repo, :/
<vila> bialix: rejoice ! You now have a fully repacked repo :)
<vila> bialix: how many packs in repository/packs ?
<bialix> now there is 2: one 90 big
<bialix> 90MB big
<bialix> it was it
<bialix> so, vila: how can I check in the hook that I'm in the right branch/tree? any examples?
<vila> bialix: sounds like a regular autopack to me
<vila> bialix: not readily available but depending on the hook you should have some tree/branch/repo handy and from there you can get your hands on the config or xxx.base
<bialix> right now I'm interested in MutableTreeHooks.start_commit
<vila> AAARGH ! Forgot dentist appointment  !
<bialix> wow
<vila> grr, next available slot in 2 weeks :-/
<bialix> oops
<bialix> you have not enough good dentist around it seems
<vila> bialix: so MutableTreeHooks.start_commit has the tree as parameter, so you from it you check whether your hook should apply or not
<vila> well, once I *go* to the first appointment I'm in the loop and get new ones quicker, that's first time I have to wait so long though
<MTecknology> is smtplib build into python?
<bialix> MTecknology: yes
<bialix> MTecknology: err, no
<MTecknology> bialix: I'm still trying to figure out bzr-email; I got side tracked
 * mrjazzcat is away: Auto-away after 30 mins idle (gone at 3rd Mar, 09:22:12)
<MTecknology> I put this configuration on ~/.bazaar/bazaar.conf on the server that I'm pushing code to http://dpaste.com/167394/. I just pushed a new revision to is but no email was generated.
<MTecknology> I just looked in /var/log/mail.* and there's nothing that seems to be trying to get through.
<bialix> vila: still here?
<bialix> vila: it works
<vila> great !
<MTecknology> I'm not even finding the docs I need to figure out how to make this work...
<cody-somerville> If I have a checkout, what is the location alias for the remote branch? ie. I'm trying to find out the revno so want to do something like: bzr revno :checkout
<james_w> does :bound work?
<cody-somerville> yes :)
<cody-somerville> ty
<MTecknology> Any ideas about that email question above?
<jasonlife> i'm using NFSv4 and keep getting "bzr: ERROR: [Errno 5] Input/output error" after some bzr command..  Actually the command seems to work tough..
<jasonlife> I noticed bzr problem with NFS, but couldn't find fix..
<jasonlife> anybody have idea on NFS and bzr issue?
<jam> jasonlife: the only 2 problems I've seen are
<jam> 1) stuff with bzr-svn/git/hg because of using TDB which doesn't like NFS
<jam> 2) We use a OS level file-locking, and sometimes that isn't enabled on NFS
<jam> one solution to (2) is to use local working trees with NFS branches and repos
<jasonlife> I'm using NFS for my home directory and my local copy is in my home directory
<jam> k, so you'll probably need to make sure that NFS locks are properly set up.
<jam> But I don't really know how to do that
<jasonlife> Are there any side effects of the error?  I have used bzr for one days so far, everything seems working fine even if I got the error
<jam> I'd have to see the actual failure to tell you any more
<jam> that specific error doesn't quite match what I would think the locking would be
<jasonlife> You mean NFS locks in my NFS server for my home directory?
<jam> jasonlife: right
<vila> morning jam !
<vila> jam: quick question before I quit
<vila> jam: branchbuilder doesn't support symlinks right ?
<jam> hey vila
<jam> IIRC, no
<jam> we could add it
<vila> jam: or rather, it *looks* like it supports adding them but not modi... ok, yeah, I'll do that
<jam> though I don't think MemoryTree supports them either
<vila> :-(
<jam> well, not well
<jam> at lesat
<jam> least
<vila> well, time to add them there too :)
<vila> ok, I'll look into it tomorrow...
<jasonlife> jam: http://pastebin.com/bUMuuehZ
<jasonlife> this is the error I got in .bzr.log
<jam> so, that does look like it is a locking issue.
<jam> Given the location
<jam> I would guess it is normally harmless
<jam> We keep track of the current sha value for a file, and track it against the mtime. That looks like it is a failure to update that
<jam> which means we will re-read the file later
<jam> which isn't a problem.
<jam> It is *possible* that you could get a failure during 'bzr add'
<jam> which would then forget that a new file was added
<jam> but most failures are a 'repeat the command' away. I wouldn't expect corruption from it.
<jasonlife> I see
<gavenkoa> Hi! I have issue on bzr pull. When pull done on emacs source it gets 4 MiB inet traffic! When I search diff and compress it I got only 10 KiB! Why so mach inet traffic used by bzr client?
<gavenkoa> http://pastebin.com/i6nXw15n
<Kinnison> Presumably because you're not using the smart protocol; so it has to fetch indexes etc to work out what diffs it needs to fetch
<gavenkoa> Kinnison: OK, that protocol use?
<Kinnison> It would rely on the emacs people having set up the smart server
<Kinnison> If they've not published how to use it; then they haven't
<gavenkoa> sftp is ok?
<Kinnison> sftp is just as bad
<Kinnison> bzr+ssh:// is better
<gavenkoa> ((
<gavenkoa> I post bug https://bugs.launchpad.net/bzr/+bug/252945
<ubottu> Launchpad bug 252945 in bzr ""bzr push" uploads 1-2 MB just to send a one-line change revision" [Undecided,Fix released]
<Kinnison> Your comment really didn't belong on that bug
<Kinnison> Your bug is "When pulling from HTTP, a 10KiB diff transferred 4MiB of data"
<Kinnison> Not "When pushing...."
<MTecknology> I'm still not getting it... for bzr-mail to work, does it have to be client side instead of server side?
<gavenkoa> Kinnison: sorry ((
<jasonlife> Is there bzr command to list the files that are not part of bzr project?
<gavenkoa> bzr st | grep "^\?"
<lifeless> bzr ls --ignored --unknown -R
<jasonlife> lifeless: thanks.. it works..
<jasonlife> is "*.o" file the "ignored file" ?
<lifeless> yes
<mtaylor> bzr tags is showing me crap
<mtaylor> lifeless: http://pastebin.com/qBxVcwfz
<mtaylor> lifeless: the tags with ? listed are from other projects...
<lifeless> yes.
<lifeless> you merged them into your tree. Don't do that.
<jasonlife> I'm wondering how mtaylor merged tags from other projects..
 * mtaylor also wonders that
<lifeless> mtaylor: the bzr merge command probably ;P
 * mtaylor pokes lifeless in the eye
<lifeless> its possible that it merges under mistake circumstances; in which case please file a bug
<lifeless> mtaylor: I need these eyes... to use my awesome new lappy
<mtaylor> lifeless: cool
<luke-jr> just found a large history of a project that I imported into Bzr... is it possible to prepend that history to my repository?
<ahorden> hey all, what is the max size of file I can store in bazaar?
<mtaylor> abentley: pipelines question... is there any way that I'm not finding to do bzr lp-submit on the whole pipeline at once? Also - is there any way do bzr push on each pipe in the pipeline at once ... or do I need to move through the pipeline and do each pipe in turn?
<lifeless> ahorden: pragmatically, about 1/3 your physical memory
<ahorden> I have a 3.8G database dump I want to keep in revision control, and I keep getting bzr: ERROR: exceptions.OverflowError: signed integer is greater than maximum
<ahorden> lifeless, box has 8 gig of memory at the moment
<lifeless> code wise we should be 64-bit safe; if not please file a bug
<abentley> mtaylor, there isn't currently a way to submit all pipes at once.
<lifeless> ahorden: are you running a 64-bit kernel and userspace ?
<bialix> ahorden: most likely you have 32-bit version of python?
<mtaylor> abentley: cool. at least i'm not just stoopid
<lifeless> mtaylor: he didn't say that :P
 * mtaylor pokes lifeless in the eye
<ahorden> Platform: Linux-2.6.31-19-server-x86_64-with-Ubuntu-9.10-karmic
<lifeless> ahorden: please run 'ubuntu-bug bzr' then, and give us a bug report. Let us know the number and I'll promote it to upstream right away
<bialix> ahorden: run `python` and check the first line
<ahorden> lifeless, I was about to upload this http://dev.biological-hazard.net/~adhorden/bzr-20100303195926-10714.crash its the crash report might help you debug better
<MTecknology> lifeless: any chance you could help me with bzr-email? I've been looking. I feel like I'm retarded for not finding information about it beyond 'bzr help email' and where to set the config.
<lifeless> MTecknology: what version of bzr-email do you have?
<lifeless> MTecknology: and what do you want to do with it?
<MTecknology> lifeless: On the server I have a user account with this config [http://dpaste.com/167394/] on that user account. I'd like it to be that if anyone pushes new code to any branch there an email gets sent to the devs.
<ahorden> lifeless, I would do a bug report if Launchpad would let me log in!
<lifeless> ahorden: #launchpad should be able to help you with that
<MTecknology> lifeless: 0.0.1~bzr4
<lifeless> MTecknology: that doesn't look like a version I've ever seen packaged
<lifeless> rmadison bzr-email
<lifeless>  bzr-email | 0.0.1~bzr40-1 | lucid/universe | source, all
<lifeless> do you mean that ^ ?
<MTecknology> sorry, ya
<MTecknology> running on karmic; same version - just had part of it chopped off
<lifeless> MTecknology: so, you've read bzr help email ?
<ahorden> lifeless, is the crash report any good?
<lifeless> ahorden: I don't know, please file it as a bug
 * lifeless is already in the middle of prepping breakfast, helping MTecknology, writing an email
<MTecknology> lifeless: ya, the config seems easy enough; it took looking aroundto figure out I need to put that in $HOME/.bazaar/bazaar.conf
<lifeless> MTecknology: you'll want it in .bzr/branch/branch.conf
<lifeless> MTecknology: as different user accounts might not have the config otherwise.
<MTecknology> lifeless: OH!
<MTecknology> lifeless: can I put that in on the server side or how should I put that in the branch?
<ahorden> lifeless, thanks bug will have to wait maintainance tonight on launchpad
<lifeless> this is covered (although it could be clearer) in 'bzr help configuration'
<lifeless> ahorden: ok
<lifeless> MTecknology: the servers copy of the branch, the server can't see the client side branches ;)
<MTecknology> lifeless: parent_location is kind of odd to have considering it's where I pushed to it from. What happens when somebody else pushes code to it from a different location?
<lifeless> nothing
<MTecknology> that just deals with where the branch was created from?
<lifeless> its just the default for 'pull' or 'merge' in that branch
<lifeless> see bzr help configuration
<MTecknology> ok
<MTecknology> lifeless: what would you suggest using for sending email? Could I just use sendmail?
<lifeless> MTecknology: use whatever you like
<MTecknology> time to see if this works now...
<jelmer> jam: fwiw we don't require TDB for bzr-hg/svn/git, we can also use sqlite (which might has the disadvantage of only allowing one concurrent writer)
<MTecknology> lifeless: I tried that in the file you mentioned; just added it to the end of the file using email = Kalliki Private Devs <dev-private@kalliki.com>
<MTecknology> editor = /usr/bin/vim
<MTecknology> post_commit_to = dev-private@kalliki.com
<MTecknology> post_commit_difflimit = 40000
<MTecknology> oopss... sorry
<lifeless> did you see the bit 'By default bzr-email only emails when a commit occurs,...'
<MTecknology> ya, I made a commit and pushed it to the server
<MTecknology> oh... that's for local commit; it only knows I push- doesn't it?
<lifeless> right
<lifeless> the server can't tell 'commit' from 'push' or 'uncommitt
<MTecknology> lifeless: I'm guessing this is working mostly.. It doesn't want to let the user use sendmail - I guess I'll try to allow the user to do that
<lifeless> what do you mean
<lifeless> I hesitate to ascribe an intentional stance to your server.
<MTecknology> I have sendmail installed; I guess by default normal users can't use it
<lifeless> uhm
<lifeless> most folk use 'mail' not sendmail to queue mail for delivery.
<lifeless> queuing and internet transferral are very different things.
<MTecknology> what package is that?
<lifeless> you may have it already
<lifeless> try typing 'mail'
<MTecknology> nope
<MTecknology> not found
<lifeless> well, there are lots of packages
<lifeless> most MTAs include a mail program
<lifeless> I can't really comment  on sendmail per se
<lifeless> you don't need an MTA on the machine though, bzr can use an SMTP server
<MTecknology> what would you choose to queue the message?
<lifeless> I use the default, which is to run the mail program
<MTecknology> mailx; alrighty
<mwhudson> jelmer: hey, did you see my bzr-svn merge proposal?
<mwhudson> no hurry, just wanted to make sure it didn't fall through the cracks
<MTecknology> well - I like this error more - bzr: ERROR: mail is not installed
<lifeless> MTecknology: well, whatever you want again. 'mail' is largely a standard, there are options to tweak how bzr-email uses it. My /usr/bin/mail comes from bsd-mailx
<MTecknology> lifeless: I just installed bsd-mailx assuming that was the right one; which mail gives me /usr/bin/mail; when I push I get that error
<MTecknology> lifeless: but if I'm that user and I run 'mail' I get 'No mail for kalliki'
<lifeless> MTecknology: 'mail -s test your-email@gmail.com'
<lifeless> type type type
<lifeless> ctrl-D
<lifeless> or you could use smtp
<lifeless> or whatever :P
<MTecknology> ok odd, I get "bzr: ERROR: mail is not installed !?" after a push; but the message still winds up in my inbox
<lifeless> MTecknology: run with -Derror
<MTecknology> lifeless: http://paste.ubuntu.com/387847/
<lifeless> we're getting ENOENT
<lifeless> on your workstation
<lifeless> did you install the plugin locally?
<MTecknology> It's both local and remote
<lifeless> well, then you'll probably want to install mailx on the workstation
<lifeless> or don't install it there.
<MTecknology> ok
<lifeless> bzr is running the plugin locally and its erroring
<MTecknology> oh
<MTecknology> lifeless: awesome :D now... is it possible to change the subject of the email?
<lifeless> not currently
<lifeless> there might be patches unmerged, I'm not sure
<MTecknology> awesome
<MTecknology> lifeless: thanks for the help :D
<MTecknology> awesome plugin :D
<lifeless> de nada
<drewww> I'm having trouble checking out just part of a tree from a bzr repository on launchpad - can I not do "bzr branch lp:projectname/path/to/file"?
<bob2> correct
<bob2> the only common vcs to support that is svn, afaik
<lifeless> and cvs
<drewww> huh
<drewww> So how should I work around this? It's making deployment for this web service tricky.
<lifeless> you can use views
<lifeless> but that doesn't quite do the same thing
<drewww> hmm
<lifeless> why do you need to deploy?
<drewww> It's a web app thing
<drewww> I'm using a framework that I Can't distribute
<drewww> so I just have the "app" folder in my repository
<drewww> and to deploy, need the app folder to be at the same level in the web server's webroot as the framework's files.
<lifeless> why not have your repository root /be/ the app folder
<drewww> yeahhhhhhh starting to think that would have been the right choice, but I had an installation instructions file at the same level as app
<drewww> which was how I used to set stuff up with svn
<drewww> old habits die hard
<ahorden> lifeless, one bug https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/531612
<ubottu> Launchpad bug 531612 in bzr "ERROR: exceptions.OverflowError: signed integer is greater than maximum" [Undecided,New]
<jelmer> mwhudson: hi
<jelmer> mwhudson: yep, I saw it
<mwhudson> cool
<jelmer> mwhudson: I have some concerns, will reply today
<mwhudson> jelmer: ok
* Chex changed the topic of #bzr to: Bazaar version control | Launchpad will be down/in read-only from 23:00 UTC until 00:30 UTC for a code update | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers!
<mwhudson> jelmer: i see what you meant by bzr-svn's tests being better than bzr-git's being better than bzr-hg's :-)
<jelmer> mwhudson: :-)
<mwhudson> jelmer: HgWorkingTree.commit() doesn't seem to create a revision that has the current tree tip as a parent
<mwhudson> jelmer: is that "yeah, we know", "oh, that's surprising" or "meh" ?
<jelmer> mwhudson: yeah, we know :-)
<jelmer> mwhudson: the working tree support in bzr-hg is, uhm, experimental
<jelmer> if it works, I'm surprised too
<mwhudson> jelmer: it's kind of a shame that the pull tests use it to set up the test cases then?
<jelmer> mwhudson: it uses commit as well?
<jelmer> are you sure it doesn't just use the hg API directly?
<mwhudson> jelmer: yeah
<mwhudson> jelmer: look at tests/test_pull.py:34 ish
<mwhudson> (i was a bit surprised to see this!)
<thumper> how do you use bzrlib to add a file, or update a file if there is no working tree?
<thumper> actually if a file exists, I want to merge it in if it is text and replace if it is binary
<mwhudson> thumper: you can
<mwhudson> 't merge or commit or anything without a tree
<mwhudson> you can do this stuff in a preview tree though, i guess?
<thumper> interesting
<distatica> I'm having a problem commiting to lp after a checkout, I get a Invalid url supplied to transporter error: http://paste.pocoo.org/show/185320/ am I missing something obvious?
<distatica> wait, that doesn't have me with the issue on commit, just checkout, I had another checked out branch and I tried commiting wtih the same error.
<mwhudson> distatica: launchpad code hosting is down for a rollout right now
<distatica> oh I see
<jelmer> mwhudson: I've merged your patch but changed the way in which limit is used
<jelmer> mwhudson: The reason for this is that a pull from an out of date branch should be a no-op unless --overwrite is specified
<jelmer> mwhudson: unfortunately I can't push atm, launchpad being down temporarily and all :-)
<mwhudson> jelmer: awesome
#bzr 2010-03-04
* Chex changed the topic of #bzr to: Bazaar version control | Launchpad will be down/in read-only from 23:00 UTC up to 02:00 UTC for a code update | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers!
<lamalex> Hi, I just installed bzr-builddeb and got a debconf dialog about postfix
<lamalex> I know I can basically ignore it, but is there some way to set it up to work with gmail?
<lifeless> bzr's email stuff can
<lifeless> but I don't think thats what installed postfix
<lifeless> it will be debuild's dependencies bringing it in
<lamalex> right
<lamalex> is it a known bug that bzr branch lp:<project> isn't working in lucid?
<lamalex> oh, maybe this is because lp is read-only right now
<lifeless> lamalex: lp is down right now, for code hosting.
<lamalex> lifeless, thanks
* Chex changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0final has gone gold, time to build installers!
<igc> hi all
<parthm> hello. I was wonder if "Bazaar Developers" received a review request for bzr-grep for https://code.launchpad.net/~parthm/bzr-grep/bzr-grep-first-review/+merge/20613
<lifeless> I get an oops looking at that page
<lifeless> thumper: ^
<thumper> lifeless: yep
<thumper> lifeless: we kknow
<thumper> works on prod
<thumper> edge has a misconfiguration
<spiv> parthm: I haven't received an email about it, so I guess not
<parthm> spiv: weird. the maintainer is bzr devs so i assume it should have worked.
<parthm> for bzr-grep
<parthm> spiv: i did 'request another review' with reviewer as 'bazaar developers'. i though the maintainer would be the default reviewer.
<spiv> parthm: FWIW, it's listed at https://code.edge.launchpad.net/~bzr/+activereviews
<spiv> Although bzr's reviews actually go to ~bzr-core, not ~bzr
<lifeless> spiv: they do ?
<spiv> Oh, I might be wrong?
<lifeless> they go to subscribed teams
<lifeless> anyhow, ~bzr is in ~bzr-core
<lifeless> so there is issue if ~bzr-core is the one subscribed to lp:bzr
<lifeless> s/is/is no/
<spiv> My mail archives suggest that review requests for bzr go to bzr-core
<parthm> spiv, lifeless: ok. as long as its in activereviews :-) next time on i can add bzr-core.
<lifeless> parthm: please don't
<lifeless> the folk in bzr-core *explicitly do not want* to know about bugs or code in plugins.
<lifeless> ~bzr is the right team, always, for working with stuff in plugins.
<spiv> parthm: what lifeless said
<parthm> lifeless: sounds fine.
<spiv> parthm: but unfortunately I haven't actually received a mail about your review request, so I wouldn't have known it was there without you saying on IRC :(
<parthm> spiv: thats what i was confused about. its probably listed only because i added ~bzr explicitly. shouldn't maintainer (~bzr) be the default reviewer? lp bug?
<spiv> parthm: I'm as confused as you are.
<lifeless> parthm: who owns the branch
<parthm> lifeless: ~parthm owns the branch, ~bzr is the maintainer for bzr-grep.
<lifeless> maintainer doesn't mean anything
<lifeless> branch owner does
<lifeless> if you want - and its up to you - bzr-grep to be team maintained (which your desire for code review suggests), then change the owner of lp:bzr-grep (the target branch), to be ~bzr
<parthm> lifeless: that was it. fixed. https://code.launchpad.net/~bzr/bzr-grep/trunk
<parthm> lifeless: thanks.
 * igc lunch
<spiv> lifeless: btw, regarding bug 531667, see http://jcalderone.livejournal.com/54911.html
<ubottu> Launchpad bug 531667 in subunit "There is no version attribute anywhere in subunit" [Undecided,New] https://launchpad.net/bugs/531667
<lifeless> spiv: patches appreciate
<spiv> lifeless: Good to hear they appreciate rather than depreciate in value :)
<marv> I was reading through the man page and I don't see any way to do the equivalent of "svn up -rxxx [file]", i.e. switch a file or the tree to some previous revision
<lifeless> so, seriously. I'd love a patch
<SamB_XP> spiv: what happened to the "p"?
<spiv> marv: in bzr 2.1 both update and switch take a -r option
<marv> ah. i seem to have 2.0.2, which is apparently what ubuntu 9.10 makes available to me
<spiv> marv: for individual files, perhaps you just want "bzr revert -r NNN some/file", though?
<marv> spiv: that was my next question, i read about the "revert" command, but the man page didn't make it clear if it just changed the working copy, or actually uncommitted the files. all the stuff about it making backups makes me think the latter
<spiv> marv: note that bzr commits entire trees, not just individual files, so there isn't really any concept of "fileA at rev 99, but rest of tree at rev 101"
<spiv> marv: revert just changes your working tree
<marv> ok, thanks
<spiv> marv: if you want to try 2.1 for ubuntu 9.10, you can try the bzr PPA: https://launchpad.net/~bzr/+archive
<Peng> marv: revert doesn't actually change the meta data from "r101" to "r99", though. It's "r101 + the files have been modified and coincidentally happen to look like r99". That's often perfectly fine, though.
<marv> Peng: yeah, i could just revert them again to be back at head. and that behavior actually matching what svn users want half the time when using -r with update, at least in my experience
<Peng> :)
<jtv> Anyone got a moment to enlighten me on bzrlib's export function?
<jtv> I thought this would be the most lightweight way of getting the contents of the current revision of a branch.
<jtv> But when I use it from within my Launchpad branch, it seems to ignore the URL I pass it and always retrieve a Launchpad branch instead.
<jtv> Is this the wrong function to use when I just want to get the current contents of a branch given by URL?
<lifeless> jtv: there isn't a really lightweight way to get a remote branches tip revision content.
<lifeless> jtv: export is 'ok', as is using the tree functions. But tell me what you want to do - gimme a full lifecycle use case.
<jtv> lifeless: I want to get the current contents of a given branch, do stuff with them, take the results of the stuff away, and forget all about whatever I did with bzr
<jtv> (in other words, delete the directory where I got the branch contents)
<lifeless> jtv: more detail
<lifeless> will you be querying the revision graph
<lifeless> will you be diffing files
<lifeless> will you be doing other things
<jtv> I'll be running intltool.
<jtv> Which afaik doesn't care one hoot about bzr and even if it wanted any of its features, doesn't know how to.
<lifeless> thaats it ?
<jtv> That's it.
<lifeless> will it be over the internet
<lifeless> or a LAN ?
<jtv> Read the branch contents as a bit of filesystem.
<jtv> This is LP build slaves talking to the codehosting server, so pretty much LAN.
<jtv> No private branches now, and for this way of obtaining the branch, probably ever.
<lifeless> ok
<jtv> The preferred protocol is http.
<lifeless> export should be alright for your use case
<lifeless> so whats happening
<jtv> My code:
<jtv> branch, subdir = Branch.open_containing(branch_url)
<jtv> rev_tree = branch.basis_tree()
<jtv> export(rev_tree, branch_dir)
<jtv> .
<jtv> This creates branch_dir as it should, but in there, gives me the contents of a Launchpad branch.
<jtv> Regardless of what URL I pass.
<mwhudson> what is branch_url?
<lifeless> what do you mean 'Launchpad branch.'?
<jtv> mwhudson: http URL where the branch can be found.
<spiv> jtv: do you mean it gives you the entire contents of the branch, not just a subdir that you are identifying in the url?
<jtv> lifeless: a branch of the Launchpad source.
<SamB_XP> !
<jtv> spiv: no, I'm asking for a completely different, non-LP-related branch and am still getting the LP source tree instead.
<spiv> jtv: you are running this command while your cwd is a launchpad checkout?
<mwhudson> that sounds a little strange
<jtv> spiv: exactly
<lifeless> jtv: provide a failing url
<lifeless> jtv: please
<jtv> Now, it may just be an unintended consequence of the way I'm running this.
<jtv> lifeless: lp:unpaste
<mwhudson> jtv: oooh
<lifeless> ok, /not/ an http url.
<lifeless> jtv: in future, please don't be vague :)
<mwhudson> jtv: make sure bzr plugins are loaded
<lifeless> jtv: you need to load bzr plugins - the launchpad one specifically
<lifeless> import bzrlib.plugin
<lifeless> bzrlib.plugin.load_plugins
<lifeless>  - or -
<mwhudson> jtv: but yeah, best to use http:// urls
<SamB_XP> shouldn't that just FAIL if the plugins are missing ?
<lifeless> import bzrlib.plugins.launchpad
<jtv> I did try with an http URL at one point, but don't remember how it failed
<lifeless> SamB_XP: no, because open_containing is a heuristic - it walks up
<mwhudson> jtv: because lp: name resolution is done by talking to the appservers, which buildds won't be able to do
<lifeless> SamB_XP: and finds '.', 'lp:unpaaste'
<SamB_XP> lifeless: ah
<lifeless> jtv: I suggest that you don't want open_containing either
<lifeless> jtv: for what you're doing, 'open'.
 * jtv experiments
<lifeless> open_containing is for dealing with user input
<lifeless> 'there is abranch around here somewhere'
<lifeless> and 'I want the relative path to something in that branch'
<SamB_XP> like "bzr diff", yeah?
<lifeless> neither of which apply to your case AFAICT
<lifeless> SamB_XP: right
<lifeless> and bzr merge
<lifeless> bzr log
<lifeless> bzr cat
<SamB_XP> bzr dog
<SamB_XP> bzr moo
<jtv> Okay, it works when I try it with open_containing on an http URL.  Obviously I'm still doing something wrong with the URL though, because I get "BzrBranch7 object is not iterable" when I use open.
<lifeless> jtv: open returns the branch
<lifeless> jtv: no subdir
<lifeless> jtv: see pydoc bzrlib.branch.Branch.open
<lifeless> SamB_XP: $ bzr dog
<lifeless> Command 'dog' not found, perhaps you meant 'log'? [y/n]:
<lifeless> $ bzr moo
<lifeless> Command 'moo' not found, perhaps you meant 'move'? [y/n]:
<SamB_XP> oh. "this bzr does *not* have super-cow powers."
<spiv> open_containing returns (branch, left_over_url_portion) because it has to perform guesswork.  open either finds the branch or fails, no ambiguity, so no need for left_over_url_portion.
<SamB_XP> oops
<lifeless> SamB_XP: install bzr-guess :P
<jtv> ...and that works!
<jtv> Thanks for your patience with my screwups.
<spm> lifeless: tsk tsk: $ bzr love ==> bzr: ERROR: unknown command "love" ;; leaving me to ask, where's the love!!!
<lifeless> ~$ bzr love
<lifeless> Command 'love' not found, perhaps you meant 'move'? [y/n]:
<lifeless> spm: install bzr-guess, you can find the love :>
<spm> I find that a bit creepy that bzr love === bzr move.
<lifeless> I've been meaning to ask. We can delete thelove@canonical.com now, surely.
<lifeless> spm: there ain't no love without movement.
<spm> probably; RT requests accepted.
<spm> that's the creepy part....
<spm> lifeless: somewhat less seriously; managed to briefly grab lamont; he is reaching new levels of bafflement and bewilderment on the subunit stuff. the build for intrepid; drop in hardy question remains open.
<lifeless> spm: I'm happy with a manual install: I just want it done </user>
<spm> yeah... trouble is we've been down that path before and pain awaits in the fairy garden at the end. But he is aware of it, so I remain hopeful of a solution soon.
<lifeless> thanks!
<bob2> goodbye, thelove!
<spm> alas poor love, I knew him/her/it well....
<jtv> spm: we're being very Shakespearian this week, aren't we?
<jtv> Or Hamletic really, since it's all from the same monologue
<spm> one (badly mis)quote and I'm labelled?!!?!? :-)
<lifeless> to commit or not to commit, that is the question
<jtv> (Hmm... "monologue"âthat's a good word for a dialogue-that-just-holds-everything-up-until-you-click-OK)
<jtv> spm: I did most of the bad quoting as I recall
<jtv> "whether 'tis nobler in the channel"
<jtv> "to suffer the guns and roses of outrageous fortune"
<spm> jtv: ahh my bad, you said "we're". apologies for the excess of self-ego issues
 * jtv is going dyslexic and read that as self-lego issues
<jtv> Must be also why I typed "bzr sty" just now, but in my defense, that _should_ be a valid command
<SamB_XP> jtv: I didn't know Self came with Legos!
<SamB_XP> or is that the issue ?
<spm> jtv: so what I'm getting there is that a monologue is a language exclusive lock? or perhaps I've spent too much time earlier today staring at postgres logs....
<jtv> SamB_XP: I'll completely ignore the reference and answer, "it depends on who self is"
<jtv> spm: hey, it beats sniffing glue.  What's a _language_ exclusive lock though?
<spm> jtv: and technically, it could be argued, I do have self-lego issues. seeing as I started stock piling lego for a boy when he was ~ 2-3 months old. which now he's 6 works *really* well :-D
<SamB_XP> you know, that language-whose-implementation-does-not-wish-to-build-on-x86/with-modern-G++?
<spm> s/a boy/our boy/
<jtv> spm: that pretty much meets my definition of being one of the very few people _without_ lego issues
<spm> hahahah
<jtv> Two, if you count the boy
<jtv> SamB_XP: I _said_ I'll completely ignore the reference.  :-P
 * SamB_XP gives jtv a morphic drip to correct the problem
<jtv> a whu'!?
<SamB_XP> Morphic is the name of Self's UI framework
<jtv> ah
<jtv> and the drip?
<jtv> (damn this trait of curiosity!)
<SamB_XP> you know, an IV
<SamB_XP> like a morphine drip, only morphic ;-P
<jtv> YKYBPTLW you miss a reference to morphine because morphic seems such a normal word
<SamB_XP> normal word? what the?
<spiv> Well, if YBPTL, it might seem to be ;)
<SamB_XP> have you been on Squeak or something ?
<spiv> (I'm guessing P == Pratchetting)
<SamB_XP> also, YRU using all these crazy things starting with Y?
<marv> the what's new in 2.1 page linked me to http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html which seems to 404
<fullermd> Y?  Y!
<poolie> hi all
<poolie> thanks for pointing that out, marv
<spiv> Hi poolie
<poolie> hi spiv, how are you?
<marv> i wish http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion would have linked to http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html the latter seems much more useful but I had a harder time finding it
<poolie> marv, it's a wiki so please feel free to add a link
<spiv> poolie: pretty good, although I just got a surprising and hopefully unreproducible test failure...
<bialix> igc: ping
<igc> hi bialix
<bialix> hi igc
<bialix> qbzr 0.18.3 is ready for you
<igc> bialix: thank-you
<bialix> :-)
<igc> marv: that 404 is a bug in the plugin guide. I need to generate a new one
<bialix> igc: anything else needed?
<igc> bialix: not that I know of. hopefully .3 fixes most of the treewidget issues in explorer
<bialix> okay, I'll be online again later
 * bialix disappears
<poolie> igc, marv, i'll just run an update on escudero
<poolie> it may just be out of date?
<poolie> no, that's not it, so i'll leave it with you igc
<sttng359> Hello
<poolie> hello
<poolie> biab, rebooting
<sttng359> I have a bazaar repository made with 1.13.1 that I'd like to clone to be able to use with Bazaar 1.6.1.
<sttng359> Can I use the newer Bazaar to clone it in a way compatible with the older Bazaar?
<RAOF> sttng359: This depends on what format the repository is in.  If I remember correctly, the default format of 1.13.1 should be compatible with 1.6.1, so you should be good to go.
<RAOF> If you used a non-default format, then you may have problems.
<sttng359> It was created using the bzr-svn plugin.
<sttng359> I get Unknown repository format: 'Bazaar RepositoryFormatKnitPack6RichRoot (bzr 1.9)\
<lifeless> sttng359: you are _much_ better off installing a new bzr.
<sttng359> with the older Bazaar.
<lifeless> sttng359: is that not possible?
<RAOF> sttng359: I think you could get around that by serving the repository over the smart-server, but newer bzrs are cooler. :)
<sttng359> My work is using an Ubuntu 8.10 server with has 1.6.1.
<Peng> RAOF: Probably not -- bzr still does a lot of VFS access.
<Peng> sttng359: So use the PPA to install a newer one. https://launchpad.net/~bzr/+archive
<Peng> Then you can upgrade to a newer, smaller, faster repo format too. :D
<sttng359> The options like 1.6.1-rich-root don't seem to affect branch.
<Peng> sttng359: Downgrading is certainly possible, but...why would you want to use an older, suckier format in an older, suckiet bzr?
<sttng359> I don't have root on my work server.
<Peng> sttng359: Ooh. Well, do you have the sysadmin's phone number? :D
<spiv> sttng359: you can do 'bzr upgrade --1.6.1-rich-root'
<Peng> You _could_ still run bzr from source.
<sttng359> They are planning on upgrading to Ubuntu 10.04, I think, but it's currently 8.10.
<spiv> sttng359: (i.e. the upgrade command can also downgrade)
<sttng359> ok
<Peng> spiv: It can?
<spiv> Yes.
<Peng> Hey, it can.
<sttng359> I'd have to get fellow devs to share work with me, so I prefer the server installed version of tools
<sttng359> but I could probably get them to use my custom installed version.
<lifeless> 1.6 is not going to be reliable on rich root
<lifeless> _really_ don't use it with the bzr-svn import
<sttng359> does --1.9-rich-root represent the format used by newer Bazaar?  That option doesn't exist in 1.6.1.
<lifeless> no
<Peng> "bzr init --2a foo && cd foo && bzr upgrade --1.6.1-rich-root" seems to go into an infinite loop. :D
<vila> hi all !
<lifeless> the 1.9 formats are about a 15 months old, maybe more.
<lifeless> Peng: the branch objects don't have a downgrader written for them.
<lifeless> Peng: there is a bug open.
<Peng> lifeless: Ah, fun.
<lifeless> sttng359: you can use sftp:// rather than bzr+ssh://, then the version of bzr on the server won't matter.
<sttng359> do I need rich-root support on clones if they won't be directly commiting to subversion?
<lifeless> yes
<lifeless> 2.0 has rich root by default
<lifeless> is much faster and uses less memory ;)
<sttng359> maybe I can convince my sysadmin to install a newer package, but even my home computer with 9.04 only has 1.13.1.
<Peng> You can use the PPA on your home computer too. :>
<sttng359> Are http transports for Bazaar repository agnostic?
<lifeless> I don't know what you mean by that question.
<sttng359> I'm just curious how much trouble open source developers have since it seems like the Bazaar repository format keeps changing.
<Peng> It hasn't changed so far this year!
 * Peng ducks
<Peng> People use older formats, or upgrade bzr.
<poolie> vila, thanks for all the reviews
<spiv> sttng359: as Peng says, people stick with the older formats if they can't upgrade bzr
<sttng359> If I can't clone an open source projects repository because it's the new 2.0 format for example.
<poolie> and for replying to the meta patch pilot thing, that saved me feeling i was totally wasting my time
<spiv> sttng359: the main problem we had was that bzr-svn required a non-default format until 2.0
<poolie> sttng359: are you having trouble yourself or is it just a general comment?
<vila> poolie: hehe, you're welcome, there are still some left but the queue size is already more reasonable
<poolie> fwiw i probably would have finished henninge's branch rather than pushing it back
<poolie> bu, obviously, i can still actually do that myself
<sttng359> no, I am just an assumption that Bazaar 2.0 would create a 2.0 rep by defaultd on my difficulkty using repositories created with bzr-svn (yes, using pre-2.0 bazaar.
<sttng359> I have had enough issues with subversion automatically updating the format of working copies the moment a newer client even does a status on an older format.  I was very glad to at least find out that Bazaar does not automatically upgrade.
<sttng359> But I assumed Bazaar would use the newest format available for new repos.
<sttng359> so standard 1.x Bazaar does not use rich-root for standard (non svn-based) repos?
<Peng> Usually they wait a couple releases before making a new format the default. The 2.0 format has been supported since 1.18 or so.
<Peng> sttng359: Bazaar only started defaulting to a rich-root format in 2.0.
<vila> poolie: well, for henninge's branch, I left the door open, had he say: "Sorry I won't", I would have finished it, but I'd like to make some progress on the conflict stuff too...
<_habnabit> Can you have a subdirectory in a branch be linked to some other branch, like you can in svn?
<Peng> sttng359: There's nothing bzr-svn-specific about rich-root formats, it's just that bzr-svn is pretty much the only thing that requires rich-roots.
<sttng359> On a seperate note, I am having issues with Bazaar 1.13.1 and bzr-svn checking out a secured HTTPS subversion repository with unexpect 401 response (expect 200 or 404).
<Peng> Oh god, _that_ bug.
<sttng359> so I *really* need to upgrade?
<Peng> Wait. Maybe not _that_ bug.
<Peng> Still auth makes my head hurt, and I meant to go AFK like an hour ago. Bye!
<Peng> s/auth/HTTP auth/
<sttng359> k
<sttng359> thkx for your help
<nil1> Hi
<nil1> Is there a known memory leak in "bzr svn-import"?
<nil1> If not, how can I obtain additional information for the bug report?
 * igc dinner
<parthm> vila: i am going through your review comments https://code.launchpad.net/~parthm/bzr/376388-dot-bazaar-ownership/+merge/19691
<parthm> vila: for the comment on "def parent_dir(path):" are your suggesting i move the code into copy_ownership?
<vila> parthm: copy_ownership says: "If own_src is None, the containing directory is used as source" but this refers to the *usage* of the function instead of implementing it,
<vila> and even there ISTM that you *don't* call chown() if ownership_src is None in higer levels
<vila> So I would rather special case None and '' in copy_ownership and get rid of parent_dir
<vila> but I as said in the end, I'm not sure the whole approach is really sound...
<parthm> vila: sounds fine. i think the change might have got lost in one of my edits.
<parthm> vila: the approach is discussed a bit on bug #376388
<ubottu> Launchpad bug 376388 in bzr "~/.bazaar created owned by root (when run under sudo)" [Medium,In progress] https://launchpad.net/bugs/376388
<vila> parent_dir is weird in itself and doesn't realy match the way we work in bzrlib
<vila> parthm: yeah, I've read that, I don't agree with everything said there :)
<parthm> vila: ok.
<parthm> so should we just keep the behavior as is for now?
<vila> but if you address my other concerns, I'll nudge poolie for a review and we'll discuss on a clean patch
<parthm> vila: sounds fine.
<parthm> regarding the test.
<vila> parthm: that's what I'm unsure about, ISTM that etckeeper already addressed the bug and that we may leave that as is. On the other hand, if we can address the sudo problem for the root user case, maybe we should
<parthm> i use _dummy_chown to set instance variables and see if these are changed. does that seem inadequate to you.
<vila> parthm: partly yes, because you then execute code that doesn't do what it's supposed to do and that's... weird
<parthm> vila: the assumption is that os.chown works correctly.
<parthm> i couldn't think of another way.
<vila> i.e. this is cheating a bit too much and will be brittle in the long run (say if someone make a change, you may still have tests passing without detecting a potential bug)
<parthm> vila: thats the lowest level. so unless the os.chown behavior changes it should catch things. the only other way istm is to actually copy ownership from/to another user.
<vila> What I'd do there is making sure chown *change* uid gid
<vila> yes, that would be better
<parthm> but i am not sure how portable/reliable that is.
<vila> as long as chown is available and the user running the test owns the containing directory, I'm pretty sure you're allowed to change uid/gid and still be able to delete the file
<vila> or dir
<parthm> vila: but do we have access to another user for a test system? we could assign root, but how does that play out with the test infra.
<vila> I'll avoid root but using anything else should be fine
<parthm> vila: ok. i was concerned about the delete part. i can try that out.
<vila> making the test explicitly delete the chowned file is a good way to ensure that it fails if something goes wrong
<parthm> vila: what other user do you suggest?
<vila> uid+1, gid+1
<vila> anything that isn't the current user nor root
<parthm> vila: +1 may not always work. for e.g. on my laptop i am the only user.
<vila> ro
<vila> I'm pretty sure you may use uids and gids that don't exist
<vila> s/may/can/
<parthm> vila: oh. ok. so just change the uid/gid. sounds reasonable as long as we can delete it. i will give that a try.
<vila> parthm: also recording the calls to chown allows to use a single assertEquals(('path', 12, 12), call_args)
<vila> instead of 3
<parthm> vila: or maybe we can go with some user like 'backup' but i am not sure if that exists on osx.
<parthm> vila: i am not sure i understand the part about recording the calls.
<vila> you need to use uids anyway so no need to translate that from usernames, and I don't know of any username guaranteed to exist anyway
<vila> let me find an example in the code base
<parthm> vila: sounds ok. i can pick some reasonably large uid/gid
<vila> parthm: arbitrary large is not guaranteed to be different of the current one, that's the key
<parthm> vila: yes. +1 should be ok i suppose. if +1 has too many rights we are in trouble anyway :-)
<fullermd> Probabilistic tests are more fun anyway   :p
<parthm> fillermd: :)
<vila> fullermd: yeah and funny hostnames too :)
 * fullermd slinks back into his corner [case]   :p
<vila> parthm: bzrlib/tests/test_selftest.py search for SkippedTest
<vila> parthm: the methods record the calls *and* call the real methods
<vila> overrideAttr returns the original value (the real chown) that you'll need to use
<parthm> vila: sounds good.
<parthm> a somewhat related question. is there a shortcut to see work-in-progress mps. right now i go through my branch list for this but its difficult to remember.
<Peng> https://code.edge.launchpad.net/$project/+activereviews
<parthm> vila: so assertEquals actually makes the call?
<parthm> Peng: it seems work-in-progress doesn't show up there.
<Peng> Oh.
<parthm> Peng: i was just wondering if there was something like +wip
<vila> parthm: wow, no, assertEqual just checks that things are equal :)
<Peng> parthm: The branch's +activereviews page shows work-in-progress ones, e.g. https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/+activereviews
<parthm> vila: :-) so i make the call myself.
<vila> parthm: there is https://code.edge.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1
<vila> parthm: you want a recording_chown that append to self._calls and *then* you can check :
<parthm> vila, Peng: thanks. loggerhead definitely has a nicer url :-)
<dcoles> Good afternoon. I was wondering if anyone knew if bzr+svn can use authentication.conf (trying to work on a Google Code svn+https repository that asks for passwords every operation)
<parthm> vila: yes. thanks for the help on the review. i think i am good to take another stab at it.
<Peng> vila: What pages link to +merges?
<vila> assertLength(1, self._calls)  and assertEquals(('path', 12, 12), self._calls[0])
<parthm> vila: good idea.
<vila> Peng: I don't know, I just have this one in my history so I type 'workinp' in firefox and select it :-P
<Peng> vila: Heh, okay.
<vila> Peng: sorry, I lied, I just type ''wor' :D
<vila> oh my, I should go through that list as Patch Pilot...
<parthm> vila: thats a long list :-)
<vila> Peng: I lied again, see: http://wiki.bazaar.canonical.com/PatchPilot
<vila> Peng: it's mentioned there from 'You can also keep an eye on work in progress merges ...'
<Peng> Ah.
 * parthm goes back to actually closing review comments and not talking about them.
<Kohlrabi> hello, I got a question regarding checkout of subfolders: I have a project where I have a main "root" folder and subfolders e.g. "A" and "B". Currently I have "root" setup as a branch. Is it possible to just checkout/branch one of the subfolders and at the same time get the full history of that subfolder (i.e. no exporting), and also push only this subfolder back?
<Kohlrabi> Or would I have to setup each subdir as a branch?
<Kohlrabi> Also, if I did that, is it possible to have changes to the subfolders propagated to the root?
<Kohlrabi> So if some user just needs folder "A" he can checkout/checkin that, but if someone wants the whole project he can checkout "root", and both are synchronized?
<Kohlrabi> I'm not afraid to do a bit of python hacking to make the sync work ;)
<bialix> vila: lol (re-patch crew mail)
<bialix> Kohlrabi: A and B should be 2 branches
<bialix> then you can use bzr-externals plugin or scmproj plugin to work on root+A+B as the whole
<vila> bialix: Always Happy to make you laugh (TM) :D
<bialix> vila: many thanks!
<bialix> vila: I'm writing plugin as universal hooks launcher
<bialix> it's maybe interested for others
<vila> bialix: mail the list !
<bialix> I think I've figured how to run either external script or python function
<bialix> err, I need your mini-review
<Kohlrabi> bialix: thank you
<Kohlrabi> Will look into that
<vila> bialix: hehe, don't be shy :)
<fullermd> Do you get mini-reviews from mini-pilots?   :p
<bialix> vila: so I'm trying to build such scheme: universal hook look into .bzrmeta/hooks/config for the details
 * vila is reminded that Gary is already waiting for some test review :-//
<vila> -o-  <-- mini plane
<bialix> say start_commit hook (of MutableTree)
<bialix> fullermd: yeah
<bialix> so my hook launcher will looking for the line in the config like:
<fullermd> . . .      <-- mini anti-aircraft artillery
<bialix> MutableTreeHooks.start_commit = XXX
 * vila 's goes boom
 * vila 's *plane* goes boom
<vila> argh typo/joke/runied
<bialix> ^ parachute for vila
<bialix> \^/
<fullermd> That's OK.  We expect typos while you're being shot at   8-}
<vila> LOL
<fullermd> ...  'course, we expect typos from you when you're NOT being shot at too...
<vila> what a pyto
<vila> bialix: remind me: is .bzrmeta versioned ?
<bialix> vila: if you wish
<bialix> but in general -- yes
<bialix> it was igc's idea
<lifeless> bialix: so, jelmer has a plugin that runs external hooks
<bialix> to put there meta info
<lifeless> its totally insecure
<lifeless> and it sounds like what you are proposing is as well
<bialix> lifeless: where it is?
<vila> bialix: with an additional twist about running the hook or not depending on some config setting right ?
<lifeless> http://wiki.bazaar.canonical.com/BzrPlugins
<lifeless> look for shell-hooks
<bialix> rats, I'm reinventing the jelmer's wheel
<lifeless> bialix: running code specified *by the branch* is a very dangerous thing to do
<lifeless> bialix: running code *selected by* the branch, is much safer, and thats what we already do.
<bialix> I don't understand
<lifeless> ok, say you have something in .bzrmeta to run a shell script
<lifeless> I can tell you to branch my code to do something
<lifeless> and the shell script can email me your credit cards, and then rewrite itself as being innocent
<bialix> yeah, that's cool
<lifeless> the same applies if the thing specified is python code
<bialix> lifeless: I'm ok with that
 * vila notes to never ever branch any lifeless stuff anymore
<bialix> and I need exactly thing thing
<bialix> this thing
<lifeless> bialix: Are you sure you need it?
<bialix> yes
<lifeless> its come up many times here and there has always been another way.
<bialix> lifeless: there is no another way to run hooks, one always need to write a plugin to implement the hook
<lifeless> I'll note that neither git nor hg run untrusted code, for the same reason - stuff that you clone can't be allowed to just run code of its own
<lifeless> bialix: thats orthogonal to whether the branch supplies the code
<bialix> okay, I understand
<lifeless> you can have shell scripts in ~/.bazaar/shell-hooks or something, and I won't object
<fullermd> Well.  Just because it's nutso in one context doesn't make it so in another.
<lifeless> you could have them in .bzr/branch/xxx too, as long as they can never be propogated by the branch [or effectively never :P]
<bialix> lifeless: approach with branch.conf does not scale with colo plugin
<fullermd> Having it in-branch has significant advantages over that schema.  And there are situations where its drawbacks aren't relevant.
<lifeless> fullermd: troll or serious? if serious please enlarge
<fullermd> In ~/.bazaar/ is totally unscalable because it means you have to do it for (every user * every change).
<bialix> unless we will have exactly the same model as git and hg by default: one working tree for many branches and only one branch.conf for all of them
<fullermd> Under .bzr/ somewhere that doesn't propogate solves one set of problems.  Somewhere that does (be it under .bzr/ or in the WT) solves another set.
<fullermd> And in the case *I* work with all day, of internal-ish code, trust is fundamental anyway.
<vila> fullermd: sure, but here I think the question is *who* controls. And via the already existing configs you can already depends on the branch to decide what code is executed. The point is to have *that* code under control and not arbitrary coming from anyone.
<fullermd> Obviously trusting code from $RANDOM_SOURCE_ON_THE_NET is a totally different question.
 * vila nods
<fullermd> But the only way code could end up in these branches is if I put it there, or one of a very few people I work with puts it there.
<fullermd> And I know where they all live.
<fullermd> (besides, we all run the versioned code in the branches anyway; if an attack vector were wanted, it's right there waiting already)
<vila> reflections on trusting trust...
 * fullermd nods.
<vila> ..arbitrary code can hide itself from bzr diff...
<vila> nightmare
<fullermd> And also the same thing as that article...  Eric's?  about differences in mindset in the OS vs corp VCS worlds.  Things can make good sense in one and be lunacy in the other easily.
<lifeless> so
<lifeless> there are two problems
<lifeless> a) distributing the code
<lifeless> b) making it run
<lifeless> for a) plugins are great. So are shell scripts in ~/.bazaar if you lik that sort of thing.
<lifeless> both of these can be totally automated for users * changes: make a branch with all your plugins, put 'bzr pull' in a cronscript.
<lifeless> b) then, for both cases, is 'run the code always, in every branch, and have the code quit early if it doesn't want to do anything'
<lifeless> bialix: I don't understand why the ^ won't work for you. (using shell scripts if needed, thats a different conversation).
<lifeless> jelmers shell-hooks plugin may need some love, and I don't think anyone else from core has audited it; it may be insecure - I don't know.
<bialix> lefeless: jelmer's code is pretty simple
<bialix> but it does not work what I need: it has no support for start_commit
<bialix> and in fact there is need some sort of templates instead of dumping all possible arguments to command line
<lifeless> should be easy enough to extend
<bialix> lifeless: I don't understand your question about "why the ^ won't work for you"
<bialix> I need special hook in the specific branch
<bialix> not in al branches
<bialix> all
<lifeless> bialix: so there is a conceptual 'if block' for that one branch, right ?
<bialix> to be precise: I need to run scons befor starting commit so some auto-generated files will be refreshed
<lifeless> so, in psuedo code: - in the hook, you say
<bialix> lifeless: if specific_tree: yes
<lifeless> 'if branch.config.run_scons: run_scons()'
<lifeless> and that then will only run scons on the branch you want it to run scons
<bialix> lifeless: in another branch I need to run something else
<bialix> I don't want to write zillion plugins
<lifeless> I'm not talking plugins
<lifeless> if you're doing shell scripts you're writing shell scripts
<bialix> if I want branch-specific python code?
<lifeless> [note to self, running scons *is* running arbitrary code...]
<vila> bialix: then you run the python code is the branch matches some config setting
<bialix> I want to distribute my hooks as the part of my branch
<vila> bialix: I don't want to give you my credit card number
<bialix> I understand your security concerns, but I think for colo-case using branch.conf is the wrong idea
<vila> bialix: how do you address that ?
<bialix> put them into .bzrmeta/hooks
<bialix> I understand lifeless idea to enable them explicitly
<bialix> so it should be enabled via unversioned .bzrmeta/hooks/local config
<vila> For the news_merge plugin we have a setting that should be set explicitly, what makes colo usage so specific that you can't add the relevant code there ?
<bialix> colo usage means you have several branches
<vila> and ?
<bialix> you need to remember that every time you create new short-lived branch you have to go into .bzr/branches/foo/.bzr/branch/branch.conf and copy-paste your settings
<bialix> it's not my way
<vila> you can do that in locations.conf then
<vila> [/home/vila/src/bzr]
<bialix> I don't use it because of some reasons
<vila> post_commit_to = bazaar-commits@lists.canonical.com
<vila> news_merge_files = NEWS
<vila> auto_update_copyright = True
<bialix> I have many working trees around and I'm working with scmproj-based projects
<bialix> it complicates things a lot
<lifeless> so
<lifeless> I think some settings should propogate in branch.conf
<bialix> locations.conf is good only if you're working on mono-project and never move it around your filesystem
<lifeless> and .bzrmeta/pluginname is equally good to do that
<lifeless> the *key* thing for me is not to run arbitrary code
<bialix> define "arbitrary code"
<lifeless> I'm happy to advise on how to achieve that; we've managed so far, but we can be more userfriendly without losing that safety net.
<lifeless> bialix: if I can make it mail me your credit card numbers, its arbitrary
<bialix> it's too wide
<bialix> I can write a plugin to do so
<bialix> and advise my friends to install it
<bialix> without putting anything in their branches
<bialix> you get the loop
<lifeless> the act of branching is the key thing
<bialix> who will watch the twatchers?
<lifeless> I realise you can have someone install a plugin - but they know that that means 'install new code'
<lifeless> branching something should never equate to 'install new code'
<bialix> lifeless: I have evidence when one man refused to run the code: python -c "import this"
<lifeless> heh
<vila> bialix: perl -t runs perl in a mode where it "taints" (marks) any unsecure code and all code depending on it, if you open a hole, you compromise the whole. We'd better enhance the whole than opening a hole
<bialix> okay, I undertsand your points. Let's stop here. I know what I need, and I need it for my work. So it will be my private thing
<bialix> thanks all for discussion
<bialix> I think something similar to shell-hooks plugin should be in the core
<sttng359> I am using bzr 2.1.0 with bzr-svn 1.0.2 from PPA to checkout a SVN repo, but I keep getting a checksum mismatch about 10 revisions in.
<sttng359> I ran svnadmin verify across the whole repo which found no errors.
<jelmer> sttng359: can you pastebin the error somewhere?
<sttng359> http://pastebin.com/k4jJuMFc
<sttng359> I had previously used bzr 1.13.1 with bzr-svn 0.5.3 successfully.
<jelmer> sttng359: I have no idea what might be wrong there. Can you please file a bug against bzr-svn including the relevant backtrace from ~/.bzr.log ?
<sttng359> OK
<sttng359> as a workaround for now, is there any issues with using bzr 1.13.1 to do a checkout using the 1.9-rich-root repo from subversion, and perhaps later upgrading to 2a?
<dcoles> Hi. Does anyone know how to make bazaar's svn+https scheme remember username and passwords?
<bob2> doesn't it use whatever svn uses?
<dcoles> I've had no luck getting it to use authentication.conf.
<dcoles> I'm... not really sure.
<dcoles> bob2: There is a ~/.bazaar/subversion.conf, but I've not yet found it's config reference
<jelmer> dcoles: Newer versions of bzr-svn can use ~/.bazaar/authentication.conf
<jelmer> dcoles: bzr-svn will also use any passwords cached by svn
<dcoles> jelmer: Thanks for the help. How new is "new"? I'm currently running the version in Lucid and haven't had any luck with authentication.conf (it doesn't even seem to note the configuration in the bazaar log)
<jelmer> dcoles: 1.0.2 should be new enough (I think that's what's in lucid)
<dcoles> jelmer: Yup. 1.0.2-2
<dcoles> I guess my question would then be should authentication.conf be set up the same as what you would for a normal bazaar remote repository?
<jelmer> yeah
<dcoles> I have a host, user and password set (and a commented out scheme of https)
<jelmer> I think you need to have the scheme set to get it to work
<dcoles> Ok, Ok, I've just tried a scheme of https, svn+https and https - still no luck
<Kamping_Kaiser> can bzr-svn be told not to look in the root of an svn repo when branching over http? http://paste.debian.net/62396/ seems to be a result of trying to access svn/fsfla/ directly, which isn't viewable without a login
<jelmer> Kamping_Kaiser: not at the moment, there's an open bug about that
<Kamping_Kaiser> jelmer: ok, thanks for the info
<jelmer> dcoles: so you get a password prompt ?
<dcoles> jelmer: Yes - And a username prompt too
<dcoles> "HTTPS  username:"
<dcoles> Ok, it looks like it's calling AuthenticationConfig.get_user(...) but that is just giving me my local username
<jelmer> dcoles: are you including the username in the URL?
<dcoles> No, I'm not
<dcoles> Even with a username in the URL, it still asks for one
<dcoles> auth.py calls get_user with what looks like an empty host...
<jelmer> oh, hmm?
<dcoles> I managed to find get_svn_simple which is also getting my local username passed to it before even calling get_user
<dcoles> Though I'm not quite sure where get_svn_simple is called from - I couldn't find it by greping /usr/lib/pyshared
<jelmer> dcoles: the svn libs call it
<jelmer> when they need credentials
<dcoles> Ah, so similar to pysvn's auth callbacks
<ahorden> hey all, we have been converting over to Bazzar from git, its allot nicer, but we need to move servers can we just do a mv -vf on the root reporatory to the new system over nfs with no issues? the server will have the same host name, but the system path will be diffrent so I am guessing the only diffrence is the sftp path we use will have to reflect the change, but is there anything else I need to look out for?
<jelmer> ahorden: nothing I can think of
<dcoles> jelmer: OK. The prompts are coming from AuthenticationConfig.get_user, so I hacked get_svn_lookup so that it sets self.host to "clir.googlecode.com" and then I get no prompts and get_user and get_password return the correct values
<jelmer> dcoles: could you perhaps file a bug against bzr-svn with this info ?
<ahorden> thanks jelmer, I will give it a go
<dcoles> jelmer: Sure thing. I'm about to head off to bed, so I'll make sure I report it in the morning.
<jelmer> dcoles: thanks!
<dcoles> Thanks for your help :)
<rgrig> bzr almost kills my computer when I branch emacs. It uses >500MB of memory (I have 1GB in total) and the computer is almost unusable for >20 minutes. Should I file this as a bug?
<persia> Good day.  I have a branch and a need to have made a stable release branch from it about 10 months ago.  I'd rather not record the results of "bzr revert -r327; bzr commit -m "Revert to r327" in the log.  Is there an easy way to accomplish my goal?
<james_w> bzr branch -r 327 stable-release-branch?
<persia> My other option is reconstructing from a 16 month old branch, replaying each commit, but that's unappealing for other reasons.
 * persia tries
<maxb> bzr branch -r 327 . ../stable-release-branch ?
<james_w> yeah, that spelling :-)
<persia> That works wonders.  Thanks heaps for having already supported this, probably for ages :)
<james_w> rather a fundamental operation :-)
<james_w> available since long before my time :-)
 * persia actually ran `bzr branch -r327 lucid jaunty` but it's the -r to branch that mattered
<rubbs> james_w: but not always obvious in this context
<james_w> no
<persia> It's very much not obvious, but incredibly useful and impossible to forget.
<ramvi> I'm running bzr client on my server to get the newest code. When trying to branch I get Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later), but bzr --version returns Bazaar (bzr) 1.5
<ramvi> how do I fix this/
<ramvi> ?
<beuno> ramvi, 1.16 is newer than 1.5
<james_w> hey beuno
<beuno> so, upgrade bzr
<beuno> hey hey james_w!
<james_w> how's the new job treating you?
<ramvi> I have to learn to count. You know if there's debian etch packages available?
<ramvi> 1.5 seems to be the newest
<james_w> ramvi: backports.org probably have something
<ramvi> james_w: that's the one I'm using. 1.5
<james_w> ah
<james_w> then I don't know, sorry
<ramvi> thanks for point out that 1.16 is newer :)
<beuno> james_w, I love it. Back to hacking on a daily basis, which I missed a lot. Also, busy busy busy  :)   how are you?
<james_w> good thanks, pretty much the same :-)
<james_w> it's been a while since I ran in to you
<james_w> I guess you'll be at UDS this time?
<beuno> james_w, not sure yet. Probably not, I'm trying to cut down on travel for a while, get back to a more normal day to day
<james_w> yeah, I can imagine :-)
<beuno> james_w, but I'm sure we'll bump into each other soon  :)
<james_w> yeah
<james_w> let me know if you are over here
<jam> morning all
<james_w> morning jam
<rubbs> morning
<fullermd> Morning?  Ah, no wonder it's gotten so bright...
<bialix> anybody knows how missing -r should work? and is it work actually?
<RobOakes> Is this a good place to ask for help with bzr and launchpad errors?
<pwolanin> in bzr when I merge and have conflicts
<pwolanin> is ther a way to specify that I want the version in the branch i'm merging into?
<pwolanin> in svn I can use 'tf'
<pwolanin> sorry I want the remote branch's version to replace local in case of conflict
<rubbs> pwolanin: I don't know of any way with a bzr command, but *.THIS is from the branch being merged into. *.OTHER is from remote branch. *.BASE is what they both came from. Just rename *.OTHER to the file and delete all the others. Then mark the conflict as resolved
<rubbs> that's how I do it at least
<pwolanin> rubbs:  ya, that's what I did before - but was hopiong bzr coudl do it in one swoop
<rubbs> pwolanin: It might, but I don't know it. :( sorry
<pwolanin> rubbs:  np, thanks
<vila> pwolanin: this is currently working on
<vila> pwolanin: it will be be available as 'bzr resolve --take-this file' or '--take-other'
<pwolanin> vila:  hmm, ok - thanks for the update
<pwolanin> find . -name "*.OTHER" | sed -E "s/(.+)\.OTHER/\1/" | xargs -n1 -I %j cp %j.OTHER %j
<vila> pwolanin: you still need to call 'bzr resolve' before committing
<pwolanin> might do the trick
<pwolanin> vila:  right
<vila> 'bzr conflicts' may be a better start for scripts
<vila> pwolanin: how many conflicts are you dealing with on average and of what kind ?
<pwolanin> vila:  these are trivial - I'm merging two builds of Drupal - some meta data files have different build info appended by build scripts
<vila> pwolanin: so they are 'Text Conflicts', I won't adress them later too but probably with additional options available see http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution
<pwolanin> vila: yes, text conflicts
<chx> hey. i am getting a bzr: ERROR: [Errno 13] Permission denied and i cant understand why i pastebinned http://privatepaste.com/4dec19bef1 relevant information.
<chx> i really have no idea what's going on, every file is owned by me :/
<vila> chx: check ~/.bzr.log and ~/.bazaar
<vila> chx: did you run 'sudo bzr' sometimes ?
<vila> chx: otherwise try running with -Derror and paste the traceback
<chx> i doubt...
<chx> vila: http://privatepaste.com/71c8ffd814
<chx> vila: find .bzr   \! -uid `id -u` also comes back empty.
<vila> I saw
<vila> ha no, '.bzr' not '.'
<chx> both . and .bzr
<chx> i tried both
<vila> BZR_PDB=1 bzr -Derror then
<vila> and 'pp from_, to' when you got the pdb prompt
<chx> (u'/ebs/home/kbridges/public_html/examiner-d7/.bzr/checkout/limbo/new-83',  u'/ebs/home/kbridges/public_html/examiner-d7/sites/parc.dev.examiner.com/modules'
<chx> oh shit
<chx> thanks
<vila> chx: Hey ! Tell me ! :)
<chx>  dr-xr-xr-x 4 kbridges kbridges 51 Feb 25 14:33 /ebs/home/kbridges/public_html/examiner-d7/sites/parc.dev.examiner.com
<chx> so what would be the find command to find such ?
<vila> chx: The error message is not nice, it would be good to make it clearer, care to file a bug ?
<chx> vila: certainly, where?
<vila> https://bugs.launchpad.net/bzr/+filebug
<vila> chx: try explaining why you ended up with a read-only dir here, I smell a valid use case...
<chx> well
<chx> yeah
<chx> i think that's a bzr error indeed
<chx> no
<chx> that's a pebkac
<vila> I don't think bzr itself ever create a directory with dr-x but... I can imagine that he accepted to version it but failed to handle changes inside
<chx> still we need a friendlier error message
<vila> chx: certainly, mentioning the paths at least will help understand the problem (at least it worked for you :)
<vila> did I just used at least twice ? Well, I realized it a t le^H^H^H^H^
<chx> vila: https://bugs.launchpad.net/bzr/+bug/531989 so far i filed this
<ubottu> Launchpad bug 531989 in bzr "Permission denied error is not friendly" [Undecided,New]
<bialix> hi, what is the correct way in bzr tests to say: I know this bug is broken, so just skip it
<bialix> I have hit /msg NickServ identify
<bialix> I have hit Bug #526221
<ubottu> Launchpad bug 526221 in bzr "tests involving stub_sftp are broken on win32" [Medium,Fix released] https://launchpad.net/bugs/526221
<SamB_XP> bialix: hehehe
 * bialix shys
<SamB_XP> pasted the wrong thing or something?
<bialix> pasted the wrong thing
<SamB_XP> at least you didn't paste in your password!
<bialix> yeah
<bialix> that's chatzilla thing: it don't want to store my password
<bialix> dumb chatzilla
<SamB_XP> though usually my client manages to login without help from me ...
<bialix> what is your client?
<SamB_XP> an XChat that calls itself YChat for some reason ...
<SamB_XP> (but, strangely, it does not have a Y icon!)
<mathrick> hiya
<mathrick> jelmer: what URL should I use to push to a github branch?
<mathrick> the location git uses is git@github.com:mathrick/unix-options.git
<mathrick> but bzr dislikes that
<jelmer> mathrick: in fact, that's not a URL :-)
<NfNitLoop> Are there any plans to add a 'bzr cp' command?
<jelmer> mathrick: git+ssh://git@github.com/mathrick/unix-options.git
<mathrick> ah
<mathrick> I think I tried that
<jelmer> NfNitLoop: vague plans, nothing concrete at this point
 * mathrick checks
<jelmer> mathrick: what error did you get?
<mathrick> nope, didn't try with +ssh
<mathrick> ooh, but now it got wedged alright
<NfNitLoop> jelmer: Yeah, I seem to recall that being the state of things a long while ago.   I'm using bzr atop SVN so it feels dirty to do a fresh add in BZR when I could've done an svn cp. :p
<mathrick> bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/mathrick/Dev/Lisp/lib/unix-options/.bzr/branches/.bzr/repository/') has no revision ('git-v1:ed0fdab09830e372d470089d77867a3ce7a79233',)
<mathrick> jelmer: look like the same error again, did you look into it in any way?
<jelmer> mathrick: what same error again?
<mathrick> the one I reported some time ago, a week or so
<mathrick> which everyone says should've been fixed in core
 * mathrick checks for 2.2 betas
<jelmer> mathrick: sorry, can you refresh my memory
<jelmer> ?
<mathrick> NfNitLoop: but that's still how it works. Might be not ideal compared to svn cp, but at least we have sane branching and merges don't render our branches unusable :)
<mathrick> jelmer: sure, I think I even filed a bug
<jelmer> mathrick My memory is failing me and a quick check of the bzr-git bugs list also doesn't reveal anything
<mathrick> jelmer: indeed, lemme check the history of the bugs I filed
<mathrick> jelmer: https://bugs.launchpad.net/bzr/+bug/526792
<ubottu> Launchpad bug 526792 in bzr "Revision not present error in annotate" [Undecided,New]
<mathrick> it got reassigned
<mathrick> you did it even :)
<jelmer> mathrick: that's a completely different bug
<mathrick> oh
<mathrick> jelmer: okay then, the above is what I got when trying git+ssh
<jelmer> mathrick: what does bzr check output?
<mathrick> jelmer: I might've messed something up, I've been cloning and rebasing things to work around git failing to fetch revisions in a way I seriously didn't feel like resolving
<jelmer> what versions of bzr/bzr-git ?
<mathrick> hang on
<mathrick>     47 revisions
<mathrick>      5 file-ids
<mathrick>      8 inconsistent parents
<mathrick> so again, like with that other repo cloned from git
<jelmer> mathrick: what version of bzr-git are you running?
<jelmer> cloning that repo I don't get any inconsistent parents
<mathrick> I think it might be my shared repo
<mathrick> jelmer: r721
<mathrick> jelmer: I just checked, cloning and reconciling a branch outside my shared repo works just fine
<mathrick> but inside it, no cigar
<mathrick> it was the same last time
<jelmer> mathrick: but this repo was probably created with a much older version of bzr-git ?
<mathrick> no, it's a shared bzr repo I've been using for two years or so
<jelmer> mathrick: so some of the revisions in it were created with older versions of bzr-git at least?
<mathrick> yes
<jelmer> mathrick: Can you do a fresh clone of that git branch outside of the shared repo, then "bzr pull" in the other revisions from the shared repo branch and then dpush ?
<mathrick> but none in this particular branch, I've created it 1h ago
<mathrick> jelmer: I managed to dpush after just reconciling the branch cloned outside the shared repo
<mathrick> I'm not quite sure what the best course of action is, this repo seems completely resistant to my attempts at reconciling it
<jelmer> mathrick: I would create a new shared repo, clone all foreign branches into that and then pull whatever revisions you created yourself into that from the original shared repo
<mathrick> urgh, that'd take forever, I keep all my branches in it
<mathrick> jelmer: what if I just cloned that repo and attempted to reconcile the clone?
<mathrick> would that change anything?
<mathrick> I'm not sure it'd be safe to switch that out from under my branches
<jelmer> mathrick: no, I doubt that would make a difference
<mathrick> bummer
<mwhudson> will i learn anything from reading the "Re: Fixing rebase rather than avoiding it" thread?
<mwhudson> it's got a bit large...
<james_w> mwhudson: not if you've read the other 5 threads on the subject
<mwhudson> good
 * mwhudson dumps it
<mathrick> humm
<mathrick> mathrick@hatsumi:~/Dev/pettanko$ bzr info
<mathrick> bzr: ERROR: Unknown repository format: 'Bazaar development format 0 with subtree support (needs bzr.dev from before 1.3)\n'
<mathrick> what's the easiest way to fix that?
<luks> you probably need an old bzr
<luks> then upgrade to some non-developmenr format
<mathrick> yeah, but what'd be the easiest way to do that in ubuntu?
<luks> download the tarball
<luks> you can run bzr directly from the unpacked directory
<mathrick> aha, lemme try that
<mathrick> is there a commandline option to disable plugins temporarily?
<bialix> --no-plugins
<mathrick>     from gzip import U32, LOWU32, FEXTRA, FCOMMENT, FNAME, FHCRC
<mathrick> ImportError: cannot import name U32
<mathrick> *grumble*
<luks> hm, I think I've seen an error like this before
<luks> python2.6?
<mathrick> yes
<luks> not as easy as I expected then :)
<mathrick> will 2.5 help?
<luks> yes
<luks> otherwise you would have to patch bzr
<mathrick> oh damn it
<mathrick> now it won't upgrade because the old version doesn't understand 2a
<mathrick> which is the format of the containing repo
<luks> you can probably upgrade to some immediate format
<luks> not sure which one
<mathrick> yes, but it errors out when I try to do that
<luks> oh
<mathrick> I tried rich-root-pack, and it makes a backup, then goes "Dunno how to handle 2a"
<luks> I don't understand the situatoin there
<mathrick> I don't either
<mathrick> somehow it managed to upgrade the repo without upgrading the branch
<luks> ~/Dev/pettanko is in the old format, right?
<mathrick> yes
<mathrick> but it's under ~/Dev/, which is a shared repo
<luks> hmm
<luks> and ~/Dev/pettanko is using the repo?
 * mathrick checks
<luks> it wouldn't complain about the old repo format if ~/Dev is 2a
<mathrick> Standalone tree (format: development0-subtree)
<mathrick> I guess not
<mathrick> so I probably need to move it outside ~/Dev/ to upgrade
<luks> yeah
<luks> (just guessing)
<mathrick> argh, it seems impossible to do
<luks> not that I've ever done it, but I'd probably try to use bzr-fastexport/fastimport if everything failed
<mathrick> yeah, if I can find them in versions compatible with 1.3
<luks> hm
<bialix> mathrick: use pull or push
<luks> oh right
<luks> there is a bug in old bzr which allows that
<mathrick> bialix: no can do, it errors out with bzr: ERROR: Repository KnitPackRepository('file:///tmp/clean-pettanko/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///tmp/pettanko/.bzr/repository/')
<bialix> start bzr 1.3 as server
<mathrick> hmm
<lifeless> jam: 'sack' ? !
<lifeless> jam: btw did you read the bzr-search code for same?
<jam> Self-contained Pack
<bialix> and point it to your old branch
<jam> You call it "Index" as near as I can tel
<bialix> then try to branch from it
<jam> but it has a lot of extra 'stuff'
<bialix> heya jam
<jam> hi bialix
<jam> lifeless: I don't have a better name, but I'm certainly willing to change it
<jam> I needed something to get started
<lifeless> jam: its not perfectly isolated no; I was just meaning to make sure you had studied theprior art
<jam> yeah
<mathrick> bialix: interesting, it seems to hang when I try to connect
<jam> also, I find your code a bit confusing to read, since you have "Index" meaning several things
<jam> well, at least several different levels of meaning
<lifeless> jam: ah
<lifeless> jam: so "Index" == "Repository"
<jam> storing indexes in a pack doesn't help
<lifeless> ComponentIndex == Pack
<lifeless> ComponentIndexBuilder == NewPack
<lifeless> jam: what do you mean
<jam> pack files have indexes to find the content in the pack file, which in your case the content is a btree index
<jam> so you have the top-level 'collection of files' index, pointing to indexes which point to indexes
<lifeless> tis a file system basically
<jam> so 'doesn't help' *understanding* what level I'm looking at
<lifeless> oh right, I see
<lifeless> jam: well, it looks ok to me, though I'm not sure why you need a custom index for the directory
<lifeless> I find Sack and Tie confusing
<lifeless> it leaves me thinking of male strippers for some reason!
<jam> lifeless: I'm a bit concerned about your associations :)
<lifeless> so am I, so am I
<jam> so the 'tie' is meant to make the file completely self-contained, at minimal expense
<jam> you do it with just the meta-index, AFAICT
<jam> 'index_value = '%d...'
<jam> tells you how to  find the various intermediate indexes
<lifeless> right, I just put the directory listing for the indices as a directory listing
<lifeless> 'these are the files in the pack'
<lifeless> with their name
<lifeless> it has the nice effect that I can add other things and not confuse older versions of bzr-search
<lifeless> a new index added is just ignored
<jam> so I plan on having a directory listing at the 'pack collection' level, but making it redundant with the tail of the actual '.pack' file
<lifeless> jam: sure, I see that. I'm mainly asking 'why is the in-pack directory listing a special class'
<lifeless> jam: rather than a regular btree index.
<jam> readability
<jam> atm
<jam> I certainly could do just another btree
<mathrick> man, finally
<mathrick> the trick was to specify --pack-0.92-subtree, which wasn't listed in --help
<jam> mathrick: well, it is generally considered a dev/experimental format, hence why it wasn't listed
<mathrick> yeah, but --pack-0.92 was
<jam> mathrick: sure, the '-subtree' is quite special
<mathrick> and --development-subtree said "can convert to pack-0.92"
<mathrick> which confused me
<jam> I would assume just a bad doc for --development-subtree
<lifeless> jam: so in terms of names; rather than tie, it looks like a Trailer to me, or a RootIndex
<jam> reasonable
<jam> oh, I also wanted to expose some of the values in the index to be combined into the overall directory listing
<lifeless> or even, if we want to let our inner java dev out to plain, a TrailingRootIndex
<jam> I'm not sure how you handle that
<lifeless> jam: thats orthogonal
<lifeless> by overall directory listing, you mean pack-names ?
<jam> lifeless: somewhat, except it is easier to grab a named attribute than to parse a 'value' string back into its contents
<jam> lifeless: right pack-names
<lifeless> jam: mmm, mumble. Could easily subclass BTreeIndex to parse the values for you
 * mathrick gets a lesson not to touch development formats without very good reasons
<lifeless> jam: bzr-search isn't wholly self contained; it's upload process returns the specific entry points.
<lifeless> jam: I think its good to do what you're doing.
<jam> I think you have a point to re-using the key-value of BTree versus Stanza
<jam> so I'll poke at that a bit
<jam> it does make testing a bit harder
<en1gm4> hi all
<jam> since you can't just test the bytes on disk
<jam> since they are compressed, etc
<lifeless> jam: you might find you can offset that with a good Matcher
<jam> en1gm4: hi
<jam> lifeless: that decodes the Btree ?
<lifeless> right; pass it a dict that you want the BTree to match
<lifeless> it can unzip parse, check all the elements.
<en1gm4> simple question: bzr revert  <file> restore <file> to the last commit, how can I restore a file from a particular revno?
<jam> although BTreeIndex also assumes it has a Transport. Which we will ultimately do, but is a bit extra complex for this specific stuff
<lifeless> BTreeMatches({}). ..
<jam> en1gm4: bzr revert -r <revno> <file>
<lifeless> jam: there is a transport adapter in bzr-search for this, rip it out wholesale
<en1gm4> thanks jam
<lifeless> search.transport.FileView
<lifeless> it even has tests
<jam> lifeless: thx for the heads up
<lifeless> it just maps a region of a file to be a transport
<lifeless> actually its more general - you give it a dict of name:(start,length)
<lifeless> and it acts a transport containing those names
<lifeless> each of which can be readv'd.
<lifeless> gotten
<lifeless> and recommended_page_size queried.
<lifeless> jam: I'd seriously consider calling this thing a pack still :- none of the higher level code needs to change at this point, except for index writing & setup-for-reading
<jam> lifeless: well "SelfContainedPack" would be possible...
<jam> ultimately I plan on bringing in the PackCollection code, etc. so that you have a self-managed thing you can just use
<jam> or at least I'd like to
<lifeless> jam: yay; I've wanted to do that for ages
<jam> I didn't want to put it in 'pack_repo' though
<lifeless> jam: indeed, at that point it should be pulled sideways
<jam> so I needed somewhere to put it and 'pack.py' is really more about the Container streaming format
<lifeless> pack_collection.py
<lifeless> anyhow, I'm really glad you're doing this; I'm really just talking about the icing :)
<jono_> hey all
<jono_> getting a weird error
<jono_> bzr: ERROR: Could not acquire lock "/home/jono/source/bzr/python-snippets/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable
<jono_> what does that mean?
<lifeless> you have it mounted on fuse
<jono_> lifeless, eh?
<lifeless> or nfs/smb with file locks disabled
<lifeless> thats generally the cause
<jono_> it is on my local disk
<lifeless> we're trying to take an OS lock
<jono_> I don't understand what you mean lifeless
<lifeless> we lock that file
<lifeless> using OS locks
<lifeless> (flock on unix I think)
<jono_> lifeless, what can I do to resolve this?
<lifeless> the most common cause for the locking to fail is when its not on a local file system (which may not be obvious: early U1 stuff would fail, for instance)
<lifeless> do you have a stale python/bzr process that might be messing with it ?
<jono_> hmm works now
<jono_> just pushed
<lifeless> you can use fuser /home/jono/source/bzr/python-snippets/.bzr/checkout/dirstate
<lifeless> to see if its inuse, in future
<jono_> cheers
<jono_> :)
<servilio> jelmer!
<servilio> hi all! I am on my way to import a subversion repository with bzr-svn, any advise for things to watch-out?
<jelmer> servilio: hi!
<NfNitLoop> servilio: It's pretty simple these days.   Just bzr branch <URL to your SVN branch>
<NfNitLoop> if you have multiple related branches, I'd recommend branching into a shared repo.
<jelmer> servilio: not really, it should "just work" :-)
<NfNitLoop> jelmer: famous last words!
<NfNitLoop> ;)
<jelmer> :-)
<jelmer> servilio: if you are going to import a set of branches in a svn repository, you might want to use the "bzr svn-import" command rather than "bzr branch"
<NfNitLoop> eh.  I just branch the branches I care about.  No need to download and cache data from dead branches.
<jelmer> NfNitLoop: it won't import any branches that have already been removed from svn unless you specify --all
<servilio> jelmer: forgot that was the command I was looking at, from the homepage recommendation
<servilio> jelmer: thanks!
<servilio> NfNitLoop: thanks!
<servilio> NfNitLoop, jelmer: I am migrating a subversion repository to bzr in this case, so I am using --all so far
<servilio> already created a shared repo for them
<servilio> jelmer: if my svn repo consists of different projects with independent {tags,branches,trunk} directories in each of them, should I import them separately into the bzr repo? or is there a way to import them all at once while keeping the branches, etc.?
<mathrick> jelmer: btw, I managed to fix these repositories, more or less, by cloning again from the reconciled branches back into the repository
<jelmer> re
<jelmer> mathrick: More or less in what regard?
<jelmer> re
<jelmer> servilio: svn-import should be able to import them all at once
<mathrick> more or less in the sense I can dpush from them, and they themselves don't have any inconsistent parents. I don't expect it has fixed the repo itself though
<jelmer> mathrick: ah, right
<igc> morning
#bzr 2010-03-05
<AfC> asac: ping
<sttng359>  how do I remove a branch from a shared repository?
<bob2> rm
<sttng359> but won't that leave copies of the data in the repo?
<sttng359> I know I can safely rm a standalone tree, but this branch has nothing worth saving.
<bob2> yes
<bob2> don't think there's a 'bzr gc' command yet
<bob2> so if you really care, afaik, you'd have to make a new repo and branch everything to it
<sttng359> ok
<sttng359> hmm, bzr pack wouldn't do garbage collection would it?
<Peng> It does not do garbage collection.
<Peng> That is, it doesn't remove anything. It just organizes and compresses it more efficiently.
<sttng359> Is a gc command on the roadmap?
<spiv> It would be nice to have, there's a bug report for it somewhere, but it's not a priority.
<sttng359> yea, I suppose I didn't have gc with svn after all.  Deleting branches in svn only add to diskspace requirements.
<sttng359> hmm, what about bzr reconfigure --standalone and rm?
<sttng359> will that remove extra copies from the repo or do copies always stay in the repo?
<bob2> I'd be very surprised if that removed all the now-unneeded revision data from the repository
<sttng359> I suppose the repo just doesn't track which branches are using it so the above would be very difficult.
<Peng> Right.
<Peng> When you get into stacked branches, remote clients and stuff, it becomes impossible.
<dcoles> jelmer: Here's the bug report for that bzr-svn authentication.conf bug I was having https://bugs.launchpad.net/bugs/532292
<ubottu> Launchpad bug 532292 in bzr-svn "Doesn't get user/password details from authentication.conf" [Undecided,In progress]
<dcoles> urlparse.urlsplit doesn't like 'svn+https' urls :S
<jelmer> dcoles: I've just fixed it :-)
<dcoles> jelmer: Cheers :)
<jelmer> dcoles: thanks for the detailed bugreport, that made it really easy to fix.
<maxb> Has anyone encountered bzr-svn corrupting its cache.tdb if Ctrl-C'ed whilst caching new revisions?
<dcoles> jelmer: I do a lot of python programming for work... and bazaar being python based makes it really easy to hack on ;)
<maxb> It seems to manifest as some paths/<revno> keys going missing from the tdb
<jelmer> maxb: I've seen it, I'm 99% sure it's because of the "svn log" fetch reversal patch that went in for 1.0.2
<maxb> ooh, that would entirely explain it - log-last is ending up pointing to a higher number than completely cached
<jelmer> maxb: I haven't had time to look into it yet, but if you can provide a bug report/patch that would be most welcome :-)
 * maxb will have a think. Unfortunately I guess you reversed the fetching for a reason, and fixing it without just backing it out doesn't seem obvious
<jelmer> the reversing is done because svn servers are quicker if asked for the revision data from newest to oldest
<maxb> The "obvious" way to fix this would be to bin log-min and log-last and store a list of ranges which are cached
<maxb> but that's a compatibility can of worms, I suppose
<mwhudson> jelmer: this one failed in discovering tags, i think: http://launchpadlibrarian.net/40213543/vcs-imports-sit-trunk-log.txt
<jelmer> mwhudson: there's an open bug about that issue
<jelmer> mwhudson: would be nice if we could associate bugs with import failures (-:
<mwhudson> jelmer: oh cool
<mwhudson> jelmer: well yeah, i'll do the unsophisticated whiteboard/comment thing i guess
<MTecknology> What's your opinions about keeping documents stored in a bzr branch?
<mwhudson> jelmer: hm, it seems none of the 5 vaguely similar bugs is in tag discovery
<jelmer> mwhudson: it's not really the tag discovery that's relevant but rather the code that infers the revision graph from a svn repo
<mwhudson> jelmer: oh ok
<Traveler2> Hi, I want to use bzr in the following scenario.  I have some html files on a server.  I want several people to edit them using bzr.  How should I set this up?  I setup the server, did init-repo, copied the html in here, did 'bzr init' in the html folder.  Then my devs can branch fine.  But if they push, the worknig tree isn't updated.  How should I set up the repository?
<jelmer> mwhudson: I think bug 384192
<ubottu> Launchpad bug 384192 in bzr-svn "Assertion in _set_direct_lhs_parent_revmeta when pulling from remote branch" [Medium,Triaged] https://launchpad.net/bugs/384192
<mwhudson> jelmer: then probalby all these bugs are duplicates: https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.searchtext=Tried+registering
<jelmer> mwhudson: yep, thanks!
<mwhudson> np :)
<jelmer> MTecknology: it's up to you :-) Should work well, although diff probably isn't much use if they're binary documents. And if the documents are *very* large (gigabytes) it's probably also a bad idea.
<jelmer> Traveler2: check out the bzr-upload plugin
<MTecknology> jelmer: It won't be a lot of massive files, the only thing I'm not sure about is, when they delete a file or alter it and the diff is just the replaced file; then that .bzr they always have to pull down will get massive pretty quick
<jelmer> MTecknology: how big the deltas are going to be depends on the document format really
<Traveler2> jelmer: thanks, but with this plug-in does it mean no repository is kept on the server?  Will revision history be shared with other developers this way?
<jelmer> Traveler2: the plugin is used independently
<jelmer> Traveler2: I assume you don't want to push your history to the same location as your web site, as that would mean visitors of your web site could access the source code and the history.
<MTecknology> jelmer: ya lost me with the word delta
<MTecknology> jelmer: probably mostly pdf and mso 2007 docs
<jelmer> MTecknology: the binary diff between the old and new version of a file
<MTecknology> jelmer: oh
<MTecknology> hrm... I think I just figured out exactly what I want to do :D
<Traveler2> jelmer: I do want to push it there, it's just html and I take care of people accessing it with apache
<MTecknology> jelmer: thanks, I'll try out diffs from changing some things
<jelmer> Traveler2: in that case you might be interested in the push-and-update plugin
<jelmer> MTecknology: I should say, "bzr diff" isn't a good indication of the size of the data that's going to be stored
<MTecknology> jelmer: I suppose if I just make a new branch for every year I won't need to worry about the size that much
<Traveler2> jelmer: cool, thanks again!
<MTecknology> jelmer: thanks for the info, I'll do a little trial, mess around with docs, check the diff size, see how big things grow
<dcoles> jelmer: Looks like another small issue - passwords from authentication.conf can come back as unicode strings
<dcoles> jelmer: Ah. Never mind. That's fixed in lp:452121
<poolie> hello all
<Peng> Hi. :)
<MTecknology> hi
<MTecknology> I'm trying to use the bazaar explorer for windows. Is there any way to use this to setup a shared key? I don't want to give this user account a password if I can help it - I prefer accepting connections with keys only
<MTecknology> I don't even see how you can open it using a shared key if you do have one..
<bob2> yes
<bob2> the launchpad docs explain how
<bob2> (assuming you mean "I'd like bzr explorer to use a ssh key to connect to my remote bzr repository via bzr+ssh/sftp")
<MTecknology> will it let me generate the key in the bzr explorer too?
<Kamping_Kaiser> does the lp plugin provide a shorthand way of saying 'push to a branch which isn't asociated with any project'? 'help lauchpad' only talks of projects
<spiv> 'bzr push lp:~username/+junk/branchname'
<MTecknology> Kamping_Kaiser: bzr push lp:~user/+junk/branch_name
<Kamping_Kaiser> so i need to enter the whole ~username/+junk bit? ah well. thanks both :)
<spiv> put 'export J=lp:~username/+junk' in your bashrc, then you could do 'bzr push $j/branchname' :P
<spiv> Er, $J
<poolie> hello all
<poolie> hi spiv
<MTecknology> bob2: I'm not finding the docs for that
<Kamping_Kaiser> spiv: trying to decide if i want shorthand way enough to file a bug ;)
<bob2> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Next step
<MTecknology> bob2: thanks
<spiv> Kamping_Kaiser: you can always write a plugin to provie a junk: namespace as a shortcut to lp:~you/+junk
<Kamping_Kaiser> spiv: much as i like the idea, i won't know enough python (any) to do that for a while
<spiv> Kamping_Kaiser: bzrlib/plugins/launchpad/lp_directory.py would be a starting point if you felt like trying anyway ;)
<MTecknology> ok, so I have the key generated but the bazaar explorer is still confusing me, I thought it would let you pick a key in the branch operation
<Kamping_Kaiser> spiv: tempt me not! or i might not be able to resist :p
<MTecknology> or do I need to put it in C:\Users\Username\.ssh or something like that?
 * MTecknology is remembering how much it sucks to deal with windows
<MTecknology> bob2: any chance I could just get a little more help with that?
<spiv> MTecknology: I don't think bzr or explorer have a concept of a key per branch, if that's what you're asking?
<MTecknology> spiv: I can't use a shared key with the bazaar explorer?
<bob2> what do you mean when you say "shared key"
<MTecknology> ssh key
<bob2> ok
<bob2> in what way do you think bzr explorer should be involved in this?
<MTecknology> use the private key to authenticate the same way when I pull the branches in linux
<MTecknology> bzr branch bzr+ssh://user@server/path/to/branch
<bob2> sure, follow the launchpad page and bzr will use pageant
<bob2> afaik
<bob2> pretty sure it has nothing to do with bzr explorer specifically
<Kilroo> hm...looks like my pet bug got pushed back farther.
<MTecknology> ok... so use puttygen to create the ssh key; add public key to server; start pageant; add key to it; leave running; try to pull branch; still asks for password
<MTecknology> hrm.. authentication (publickey) failed is showing up in the output, must be at least trying to use it??
<MTecknology> AWESOME!
<MTecknology> bob2: thanks - sorry if I was annoying
<bob2> yay
<MTecknology> I REALLY hate how windows works....
<MTecknology> Linux, ssh-keygen; put id_*.pub on server; done
<MTecknology> so simple :D
<MTecknology> bob2: thanks again, time to relax :)
<poolie> spiv, can you answer https://answers.edge.launchpad.net/bzr/+question/98083 ?
 * spiv looks
<spiv> Done; I've essentially just repeated jam's answer.
<poolie> lifeless: can you have a look at https://bugs.edge.launchpad.net/bzr/+bug/528793 for me?
<ubottu> Launchpad bug 528793 in bzr "MemoryError in _ensure_content during commit in small repository" [Medium,Confirmed]
<poolie> spiv, and also https://answers.edge.launchpad.net/bzr/+question/103163
<spiv> I wonder why I don't receive question notifications.  I guess I need to subscribe somehow...
<poolie> mm
<poolie> i just made ~bzr-qa be subscribed
<poolie> are the per-file merge hooks in the user guide?
<spiv> They'll be in the hooks documentation at least, but they probably need better docs than that.
<lifeless> poolie: http://software.intel.com/en-us/articles/itaniumr-processor-family-performance-advantages-register-stack-architecture/
<poolie> so, spiv, could you answer that guy?
<poolie> https://answers.edge.launchpad.net/bzr/+question/103163
<poolie> and i'll file a bug for documenting it
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/532435
<ubottu> Launchpad bug 532435 in bzr "need user-guide documentation of per-file merge hooks" [Undecided,New]
<spiv> poolie: yes, I just did, was composing and testing the code for the answer
<poolie> thanks
<spiv> The code for that is still a little more complex than is ideal :/
<poolie> urk
<poolie> i think he was hoping for a single configuration item :)
<spiv> Well, I suppose that plugin could be tweaked to read patterns from a .bzrmeta/fauxbinaries file ;)
<poolie> i'd like to put it in the rules file
<lifeless> we have too many places
<AfC> I so wish you could have put the meta data in .bzr
<AfC> I gather you had reasons, but it seems such a shame to have more .bzr* files than 1
<poolie> mm
<poolie> did any of you see a failure in https://bugs.edge.launchpad.net/bzr/+bug/532435
<poolie> blah
<ubottu> Launchpad bug 532435 in bzr "need user-guide documentation of per-file merge hooks" [Medium,Confirmed]
<poolie> ERROR: bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
<spiv> poolie: what sort of failure?
<poolie> SocketConnectionError: Unable to connect to SSH host localhost:35949; [Errno 111] Connection refused
<spiv> I haven't seen that test fail, or that type of failure in general, no.
<vila> hi all !
<jam> uh-oh. If I see vila wake up, I *must* need to go to bed!
<jam> night all
<Peng> Note to self: Impersonate vila in the middle of the afternoon to screw with jam.
<vila> jam: eeerk
<vila> jam: have a good night
<SamB_XP> !localtime Peng
<SamB_XP> aww
 * igc dinner
<vila> bialix, bialix, where are you ?
<bialix> vila: hi! thanks!
 * bialix waves hi all
<vila> bialix: hehe, just so your Approve vote, thanks for that
<vila> s/so/saw/
 * bialix starting to understand vila even with typo like that
<vila> I'm wondering if 'so' and 'saw' are pronounced differently in English in which case I'll blame my awful accent (or so cute accent depending who you ask :)
<Peng> They are pronounced differently in my accent.
<vila> Peng: ha good...
<vila> Peng: ... what is your accent ? :-)
<Peng> I don't know. Isn't it said that people don't hear their own accent?
<bialix> say us who you are and we say what is your accent ;-)
<Peng> vila: I'm from Florida, US.
<vila> Peng: Well, my girlfriend recorded me lately (without notice) and I could clearly hear my accent :)
<vila> Peng: So you're a native speaker and for bialix and me I think that counts as no accent :)
<Peng> Heh.
<neaj> hello all ..
<Peng> sup!
<neaj> i want to merge svnA into svnB using bazaar .. what's the Right Way?
<bialix> STing has a song in French: La belle damme sans regret, it's funny to listen his accent
<neaj> i managed to do it, but now svnB doens't have the history
<bialix> ghost around us?
<Peng> Hmm, what's a stereotypical southern greeting? I couldn't come up with one...
<neaj> hi y'all
<Peng> Ah! Good one!
<vila> bialix: weirdo :) Listening to foreign accents in foreign foreign languages :)
<bialix> neaj: hi, what it means "does not have the history"?
<Peng> I can't say "y'all" with a straight face. :(
<neaj> 'bzr log' shows only 7 revisions, but svnA has 283 revisions
<bialix> vila: yep
<bialix> neaj: try bzr log -n0
<neaj> !!
 * neaj gives bialix a noisy kiss
<bialix> oh no
<bialix> neaj: bonus: install QBzr and try qlog
<neaj> OK :-)
<neaj> wow that was a nice discovery :-)
<vila> neaj: There should have been a message at the end of 'bzr log' (use -n0 blah blah)
<vila> neaj: did you just miss it ?
<vila> neaj: I'm asking to know what could have helped you discover it alone (since that's why we put the message there in the first place)
<neaj> vila: yes, i completely missed it, sorry ..
<vila> neaj: no no, you don't have to be sorry, instead, tell us what could have helped you notice it
<vila> rats, I will lose *power* in ~30mins for 2 hours, I'll have to shut down properly *now*
<vila> neaj: feel free to file a bug with your ideas
 * vila goes back to shutting down every work in progress and migrate some stuff to the battery-powered laptop :)
<neaj> something like this? http://pastie.org/855302
<vila> hmm, embedding or at the top, yeah, makes sense, will not fly well with our current implementation but I think it's worth addressing for people using '| more or less
 * vila runs
<neaj> hmm, now is this history in svnB? when i 'svn co svnB', svn log shows only 7 revs also.
<Peng> neaj: No. It's just in bzr.
<Peng> I think.
<neaj> i did: 'bzr branch svnA; bzr branch svnB; cd svnA; bzr merge -b 0..283 ../svnB; bzr commit -m "Merged"; bzr push'
<bialix> vila: may I ask your wisdom advice? re scmproj
<Peng> bialix: vila is gonna be AFK for the next 2 hours because of a power outage.
<bialix> oops
 * bialix sends vila some spare batteries
<joey> any bzr guru's on line?
<joey> need help to work around https://bugs.edge.launchpad.net/bzr/+bug/532550
<ubottu> Launchpad bug 532550 in bzr "bzr error: Bad message kind byte: '\\x1d'" [Undecided,New]
<bialix> joey: does this error reproducible?
<bialix> does you have any proxy between you and lp?
<joey> bialix: I'm trying. It happens 47 mins into my push
<joey> bialix: probably, I'm in a hotel in London
<joey> bialix: I'm pushing up about a 4 gig diff
<joey> :-)
<bialix> try to run bzr missing first to understand how many revisions you're about to push, and try then push in chunks
<bialix> 4 gig? could be 32bit issue, maybe?
<joey> good idea
<bialix> sorry, I'm not really guru in 4 gig question
<joey> oh right, I'm on a 32bit netbook not more normal 64bit system
 * bialix summons spiv, lifeless
<joey> 2 revs down, 1 I just did after the crash on the 1st
<bialix> may be push in chunks would help
<spiv> joey: ouch, big diff!
<spiv> I doubt it's a 32-bit vs. 64-bit issue.
<bialix> and here is: our smart server guru: spiv!
<bialix> applause
<spiv> joey: please add -Dhpss -Dhpssdetail to the command line, try again, and then attach the .bzr.log to the bug
<spiv> joey: it's certainly a bug in bzr, although it's one I haven't seen before
<spiv> joey: bialix's advice about pushing less revisions at a time is probably the best workaround I can think of.
<spiv> joey: hmm, although sftp might be a workaround too?  'bzr push sftp://joey@bazaar.launchpad.net/~oem-solutions-group/oem-process/oem-presentations/'
<spiv> joey: I need to go to bed; please put any further info you get into the bug, I'd really like to understand what's gone wrong here.
<joey> hmm
<joey> I think I might have found the issue....
<joey> there was a file name that included a funny space and two periods.
<joey> I changed that and am attempting to push again
<lifeless> where was the file
<lifeless> jml: does the lp server capture server side errors to oops yet?
<jml> lifeless, no.
<lifeless> or to some log we can see - i want the server side backtrace
<spiv> joey: filenames really should not have that effect on the network protocol
<spiv> (will be in bed soon, really!)
<joey> spiv: I'll give it a shot.
<spiv> joey: so I very much doubt that is the issue, it just doesn't fit with symptoms so far at all
<joey> oh you know, maybe I should have done a -Dhpss
<jml> lifeless, whatever logs we have are synced to devpad -- I doubt the server-side backtrace is synced though. a losa will be able to point you at the right directories, and might be able to sync the appropriate ~/.bzr.log on request.
<lifeless> jml: well, its 2317; I'm beat
<jml> lifeless, ok. thanks for trying.
<lifeless> this needs to be gathered to move this further I suspect
<lifeless> joey: if you want to track down the log for the error, so we can look at it when .au rolls around (or so vila can look at it), that would be great.
<lifeless> joey: the error you see is local bzr saying 'the server spat at me. waaah.'
<lifeless> joey: there is a real backtrace on the server somewhere.
<spiv> joey: yes, -Dhpss -Dhpssdetail, please
<joey> lifeless: I was hoping that was the case :-)  Just wondering if I can translate the "waahh" into something that might help me diag the problem
<spiv> joey: the server-side traceback is what we really need, but -Dhpss -Dhpssdetail on the client might provide some useful clues
<lifeless> joey: talk to a losa; they can flail about more effectively.
<lifeless> :)
<joey> thanks spiv... and lifeless ... I'll wait to this one finishes or crashes to prove my theory and if it abends I'll try the debug items
<joey> heh. Maybe herb or mthaddon can find something for me
<joey> spiv: lifeless - the filename rename did the trick
 * joey updates the bug
<Peng> It did? But...why?
<Peng> o_O
<spiv> joey: I *really* doubt that is more than a co-incidence
<jam> morning all
<jam> evening igc
<rubbs> morning
<igc> hi jam
<jam> igc: other than needing to go to bed, how are things going?
<igc> I'm fighting windows installers tonight
<igc> debugging me new scripts
<igc> jam: any chance you can upload one of the installers I built to people.canonical.com say?
<igc> jam: I'm heading to bed now but I'd like to test it on the weekend
<jam> k
<igc> it's the one tagged igc
<igc> jam: ^
<igc> jam:thanks
<jam> on d?
<NfNitLoop> hrmm.
<NfNitLoop> what would cause a commit back to svn to have the property bzr:pointless?
<NfNitLoop> It seems to be doing those commits to store some sort of metadata in the commit properties, but I only have 2 revisions in my local repo to push.
<jelmer> NfNitLoop: a commit that is pure administrative
<jelmer> NfNitLoop: i.e. shouldn't appear in "bzr log" but is required because of the way svn works
<Tak> does bzr have any special provision to handle the situation where a branch contains large, binary files that often change?
<NfNitLoop> required for what reason?
<NfNitLoop> Tak:  It'll diff binary files just like text files.... no special provisions, AFAIK.
<NfNitLoop> jelmer: I mean, I see why you might need that.  I'm just wondering what the common case for it would be.
<NfNitLoop> (My 2 revisions seem pretty straightforward, not sure why I'm seeing this behavior for the first time today.)
<NfNitLoop> I did do a rebase before pushing back to SVN.
<NfNitLoop> but I don't know why that should matter.
<Tak> hm - I ask because I went to branch from an svn repo (where that happens), and I was around a gig downloaded at ~200/~18000 revisions in, and the tip wc size is substantially less than a gig
<jelmer> NfNitLoop: IIRC if you push a branch that adds a tag while there is no 'tags' directory and bzr-svn creates the tags directory for you it'll set that revprop
<NfNitLoop> hrmm, nope.   it doesn't appear to have changed anything other than that property.
<NfNitLoop> Tak: Well, it does keep all of your history.
<NfNitLoop> Tak: you might consider a stacked branch next time you do a checkout.
<NfNitLoop> that'll download just enough history to recontruct a working copy.
<NfNitLoop> jelmer: aah.  It looks like my coworker updated a branch in the /tags directory.
<NfNitLoop> and for some reason those commit messages got copied into the branch from which that tag was created.
<NfNitLoop> which is wrong, because those changes weren't committed there.
<NfNitLoop> (Yes.  It's a complete misuse of the "tags" directory.  But in my experience, it is not uncommon in SVN usage.)
<vila> jam: ping
<bialix> is it possible to mark command-line option as deprecated?
<bialix> there is hidden flag
<bialix> I want to make some options hidden and deprecated
<bialix> does bzr has some support for this?
<jam> hi vila
<vila> bialix: no idea :-/
<vila> jam: I'm searching how to find back a file-id for a file that has been deleted in a working tree
<jelmer> bialix: yeah, I think you can add hidden=True to Option()'s constructor
<bialix> I'm not very good in optparse, what method is called when option processed?
<jam> vila: you have to walk history until you find a revision where it existed
<bialix> jelmer: yes, hidden=True works fine
<bialix> I want to make some deprecation check now is some universal manner
<jelmer> bialix: I don't think we have a deprecated=True flag, but I guess you could warn the user if you see they use that flag
<vila> jam: what is the purpose of has_or_had_id (slightly related) ?
<bialix> hmm, Option constructor has custom_callback
<jam> vila: I think that only checks the WT before commt
<bialix> I think I need to provide my callback with deprecation warning
 * bialix trying
<jam> so if you delete a file, you 'had' the file, referenced by the existing file_id
<jam> once you commit, that will return nothing
<jam> I think
<vila> :-/ Yeah, my wt is just in that state, the file *is* deleted by the merge but was present in a least one of the parents
<jam> vila: well, it is easy enough to just probe all parents with path2id
<jam> if it was deleted in the merge
<jam> then doesn't it have to be present in the basis (left-hand parent)?
<jam> otherwise it would have been deleted already
<vila> yes, but I don't have that info anymore when starting from the conflict object
<vila> but " probe all parents with path2id" should be enough
<jam> it isn't great, but I think it will work for what you need
<jam> though...
<jam> could you have a conflict if the file was deleted in all parents but had been locally versioned (not yet committed)?
<vila> jam: no worries, I plan to need that only for conflicts created *before* I fix bug #531967
<ubottu> Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967
<jam> bzr add new-file; bzr merge ../other # conflict with 2 files wanting to be 'new-file'
<vila> bzr add-new file should create a new file-id so I think it's a different case, let me think
<bialix> custom callback working fine
<jam> vila: sure, it just is a potential to cause a conflict
<jam> another way is just
<jam> touch new-file
<jam> bzr merge ../adds-new-file
<vila> jam: I think that will be a DuplicateEntry conflict which can have two file-id involved
<jam> well, --force
<jam> vila: I trust that you know better than me, I'm just trying to bring up edge cases
<vila> jam: thanks for that
 * vila notes to add tests for just to be safe ;)
<vila> jam: (Pdb) pp tree.revision_tree('other').path2id('new-dir')
<vila> 'dir-id'
<vila> \o/
<vila> jam: (teddy bear) Can you think of a *simple* way to restore an inventory entry as it was in an available revtree ? This has to cope with the entry being of any kind of course
<jam> vila: you mean like 'bzr revert' sort of thing?
<jam> I'm not really sure what you mean by 'restore'
<jam> are you trying to do something on disk? only in the inventory, etc?
<jam> and I assume this is in a WT?
<vila> then entry doesn't exist in my current wt, I want to add one from a revtree
<jam> vila: the only stable way I can think of is to use 'revert(specific_files)'
<jam> I don't think it is particularly simple
<vila> jam: yeah, I thought so :-/
<jam>         _mod_merge.transform_tree(tree, tree.basis_tree(), interesting_ids)
<jam> is what "bzr remerge" uses
<jam> before it re-applies the merge
<vila> I'll punt then and abort in that case, it should be rare enough to not be really that important
<jam> so transform 'tree' into 'other_tree' for objects mentioned in 'interesting_ids'
<jam> vila: it is a single line of code :)
<vila> haaa, *that* sounds what I'm after
<bigjools> hi - I just had bzr traceback when I was merging a bundle: http://pastebin.ubuntu.com/389096/
<vila> jam: bah, that doesn't work, long story short, I need my fix first which sucks because it means my tests won't be failing anymore which in turn means I won't be able to test my backup plan 8-{
<vila> jam: using tree.revert([revtree,id2path(file_id)], etc) seem to work better ! \o_
<jam> vila: the only concern there is that I *think* 'tree.revert(dir-id)' will revert all files underneath it?
<vila> jam: At that point, the directory *should* be empty (at least I hope so :)
<vila> It doesn't exist anymore so I just need to recreate it, I'm pretty it's empty,
<vila> for dirs that is, for files and symlinks... well, that doesn't apply ;-)
<jam> vila: but wouldn't it end up restoring the files that used to be in the directory in that parent?
<jam> (not sure, but def something to test)
<vila> jam: I sure will, but AIUI, the conflict can't be created if the dir is not empty (that's what I need to check)
<awilkins> Is an "inconsistent delta" error as critical as it sounds in #256409
 * vila EODing
<vila> bye all !
<vila> jam: thanks for help and the teddy bearing ;-)
<jam> awilkins: there is a known form where 'bzr commit' and a deleted nested directory (deleting a/ and a/b/ and a/b/c), which commits fine, but fails at one point, and you need to run 'bzr update' afterwards
<jam> there it isn't serious
<jam> just a bug in handling recursive removal
<jam> otherwise, prob serious
<awilkins> jam: The scenario is as follows... this branch was pulled from an SVN repo. The lead developer has had a moment of confusion (doesn't seem to understand version control) and copied a folder from an old revision forwards in time as an attempt at renaming it.
<jam> awilkins: well, that sounds like a bzr-svn issue, as it could be supplying an invalid delta to the rest of the code
<jelmer> awilkins: bzr-svn should be able to handle that
<awilkins> jam: It's happening during a bzr mv --auto
<jelmer> awilkins: this is a change that's already been committed?
<awilkins> jelmer, They must be because I'm working in a fresh checkout of a past revision
<jelmer> awilkins: how do you know it happened during a bzr mv --auto ?
<awilkins> jelmer, The error was raised during bzr mv --auto ; I don't know when the root cause of the error arose
<awilkins> I'm trying to create a revision that's this persons changes done right... then I can merge the changes from everyone else which he's ignored because he's not committed for a few weeks
<jam> awilkins: hmm.. I've seen that with stuff trying to be renamed into a dir that wasn't versioned
<jam> again, a bug, but shouldn't long-term break anything
<jam> the error is to prevent getting corruption
<jam> so getting it during 'bzr mv' is probably ~ok, getting it during 'bzr commit' is more worrisom
<awilkins> jam: Yes, eventually it stops throwing the error if you manually add a bunch of parent folders
<awilkins> Alas, mv --auto is guessing too promiscuously
<awilkins> I guess it's not so hot at Java code with enormously similar and long import lists
<jam> awilkins: IIRC if a line is very common, it gets less weight for matching
<jam> however, if you are saying they shouldn't match at all, there is probably a 50% threshold or so
<cr3> how can I use bzr to patch a branch from revision x..y in a different branch, which happens to not have the same root
<cr3> hm, seems to be as simple as bzr merge -rx..y /path/to/other/branch
<cr3> awesome! 167 conflicts encountered.
<jam> cr3: bzr diff -r x..y /path/to/other/branch | bzr patch ?
 * cody-somerville is very happy bzr now handles merging local commits on a binded branch correctly. :)
<mrjazzcat> hey.  newbie bzr dev question.  I'd like to setup a simple bzr server that I build to test remote calls.  Is ssh the best model to pick?  If so, how to I tell the client which bzr program to invoke.
<lifeless> what do you mean?
<lifeless> I don't know what 'build to test calls'
<mrjazzcat> well, I've built bzr 2.2 and I want to run it as the server when I run the client.  But, what gets run via sftp (for instance) isn't up to me.
<lifeless> when pushing over sftp, the server is just sftp - no bzr code runs at all
<lifeless> bzr only runs in client-server mode when you push to a bzr://, bzr+ssh://, or http:// [when the WSGI interface is enabled on the server]
<mrjazzcat> ah, I see (sort of).  I thought that sftp could be used as the simplest server.  You're saying that all the commands to run come from the client, in that case.
<lifeless> with SFTP, bzr works just like it does on local disk - sftp only offers a virtual file system
<lifeless> no RPCs
<mrjazzcat> ok, thanks.  That makes sense.
<lifeless> with bzr+ssh you can export BZR_REMOTE_PATH to control the program invoked on the remote host
<lifeless> bzr help env-variables
<mrjazzcat> thanks.  That's better.  That's what I'll do.  I'm trying to pick off an easy bug to get started, and I thought figuring out the client-server model was also a good place to start
<lifeless> many easy bugs are tagged 'easy' in the bugtracker
<lifeless> that may help you find a good bug
<mrjazzcat> thanks, it will
<neaj> hi all .. what is submit_branch in .bzr/branch/branch.conf ?
<lifeless> its the branch that 'bzr submit' will submit to by default
<NfNitLoop> is that an addon?   'bzr help submit' is an error for me.
<NfNitLoop> and yet I've got a submit branch.
<NfNitLoop> (error: unknown command "submit")
<lifeless> sorry, 'send'
<lifeless> bzr send
<NfNitLoop> I think it's the default branch for merge too?
<neaj> i'm not really clear on the differences between parent_location submit_branch push_location
<neaj> i don't know why my submit branch is different from my push location
<lifeless> zr help configuration
<neaj> and why isn't it a push branch?
<jpds> neaj: I think submit branch is the tweak branch which your branch will be merged into.
<neaj> i've never used 'send'. i merged from another repo. that repo ended up as submit branch. don't understand the reasoning behind that yet
<neaj> jpds: in this particular case, the submit branch is pointing at a throwaway branch that i just used to migrate an svn repo into my bzr repo
<neaj> now i've moved the throwaway branch out of the way, but it bothers me that i now have an invalid submit_branch in .bzr/branch/branch.conf
<lifeless> so delete it
<neaj> lifeless: my point is that i don't want to end up with funny invalid things that i have to fiddle by hand just by working normally
<NfNitLoop> all it's doing is remembering the last place you did an operation from so that it becomes an optional parameter.
<NfNitLoop> just specify your destination every time and it won't affect you.
<NfNitLoop> I never quite grokked submit_branch either.
<NfNitLoop> but I always specify where to merge from so it doesn't mater much.
<NfNitLoop> I sortof want to write a plugin to just create a named pool of all branches that a branch has seen and prompt on every operation.
<NfNitLoop> but... yeah, that hasn't happened yet. :p
<lifeless> NfNitLoop: bookmarks can do something in that direction
<lifeless> NfNitLoop: could extend it
<lifeless> neaj: so, bzr remembers things you work with, the first time; you deleted the branch it had remembered - I don't see that there is an easy way to avoid that.
<lifeless> neaj: you don't need to manually fiddle by hand - the next time you do a send, just do '--remember', and bzr will update the setting.
<neaj> that name (submit branch) feels super confusing to me. it sounds very familiar, but turns out it doesn't have to do with commit or push, but with send. send turns out to be an async version of push, but it follows different rules as to where the changes will go.
<lifeless> neaj: send is not an async version of push
<neaj> no?
<lifeless> neaj: send is for sending your changes to someone else to integrate. They might merge. They might pull.
<neaj> i appreciate everyone's teachings, by the way :-]
<lifeless> push updates a remote branch to be a mirror of your local branch.
<lifeless> very different
<neaj> OK, so push puts your changes into a branch, and send sends your changes to someone who may or may not put them into a branch
<neaj> and send assumes you'd want to send to wherever you last merged from.
<neaj> if i understand correctly ..
<lifeless> by default, yes
<lifeless> because, common case, you are merging from the maintainer
<lifeless> and sending back to the maintainer
<lifeless> and pushing to your own repository
<neaj> OK, i see.
<neaj> hmm, i notice that 'bzr info' talks about push/parent/submit *branch*, but 'bzr help configuration' talks about submit_branch, push_location and parent_location
<neaj> i wonder if 'send branch' would be a better name for 'submit branch'. send bransh for sending, push branch for pushing.
<mkanat> neaj: It's also the bundle branch.
<neaj> you send bundles also, right?
<mkanat> I never do, personally. :-)
<neaj> i mean that's how they reach that branch
<mkanat> They can be merged in.
<neaj> in that case i wonder if 'send' should be called 'submit'
<lifeless> it was originally
<lifeless> it got renamed for few reasons; the setting stayed the same for compatability
<jelmer> lifeless: btw, I started on adding support for adding 'bugs' revprops in the commitfromnews plugins
<neaj> hehe .. names are tricky ..
<lifeless> awesome
<jelmer> unfortunately the commit message template hook doesn't seem to allow modification of the commit message
<jelmer> so I'll have to use a different hook I guess
<jelmer> (lp:~jelmer/bzr-commitfromnews/extractbugnumbers)
<lifeless> jelmer: do you mean 'of the commit object' ?
<jelmer> lifeless: yes, sorry
<lifeless> jelmer: I think we'll want a new hook anyway, because we want to process the /saved/ commit message, not the generated template for bug numbers.
<jelmer> lifeless: do we? I don't want the bug numbers to show up in the commmit message itself, but stripping them out afterwards is hard.
<lifeless> jelmer: oh, I want them to stay in the message.
<lifeless> I hadn't really thought about hiding them.
<jelmer> Generally I would have something like "(Jelmer Vernooij, #34243242)" after each line in the NEWS file. That seems like redundant information to have in the commit message.
#bzr 2010-03-06
<lifeless> hmm
<lifeless> so it is
<lifeless> and ist isn't
<jelmer> ?
<lifeless> not all log viewers show bugs
<lifeless> but yeah, I can see the case
<lifeless> so we want a
<lifeless> #bug:lp:3423423432
<lifeless> or something
<lifeless> and a hook that can edit the message and rev props late
<jelmer> yeah
<aspidites> is there some setting that needs to be present before I can receive karma on launchpad for committing code?
<lifeless> no
<lifeless> but you ahve to push the code to lp
<jelmer> also, karma isn't updated instantaneously
<lifeless> bbiaw
<dOxxx1> good evening
<dOxxx> when should bzrlib.trace.show_error etc be used instead of the ui_factory.show_error etc?
<sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/files  how is my 'whyteboard' folder shown at version 170 when I've commited several times to files inside it since?
<bob2> the dir was amde in 170
<Peng> sproaty: Bazaar tracks directories as their own objects. Presumably it's showing when the directory itself was modified, rather than its contents.
 * Peng shrugs
<sproaty> figured
<sproaty> kinda a shame#
<Peng> https://bugs.launchpad.net/loggerhead :D
<sproaty> heh, cheers
<sproaty> night
<Peng> I wasn't joking.
<dOxxx> if I'm writing a bzr plugin which works with launchpad branches via the lp api, should I be using the lp_api module from the launchpad plugin or just using launchpadlib direcrly?
<dOxxx> directly*
<dash> hi. I started 'bzr upgrade' on a launchpad branch to upgrade it to 2a, but I haven't upgraded the repo yet. will it be a problem to kill the upgrade and do the repo first?
<dash> oh, heh, it finished. Never mind!
<enli> i checked out a branch from launchpad to fix some bug and pushed changes to my own branch on lp. I would like to remove that revision from launchpad, is it possible?
<Peng> enli: Completely remove all traces of it? Is this just, like, you misspelled something, or did you accidentally commit the nuclear launch codes?
<enli> Peng: the code is working, its just that i want to change the commit message
<Peng> enli: Ah. How bad is it? Mostly it's not worth doing. You can see all sorts of fun errors in lp:bzr's history.
<enli> not too bad, i am just playing with it.. wondering if it is possible :D
<Peng> enli: It's not hard, but it's not clean either.
<Peng> enli: You'd have to "bzr uncommit", "bzr commit again" and then "bzr push --overwrite". This creates a completely different revision, so people who have already pulled the old one will get confused.
<Peng> enli: Like I said, it's usually not worth it.
<enli> ok, so if my latest revision was before uncomit, 198 and i do uncommit, commit, push what will be the revesion number?
<Peng> enli: 198
<Peng> enli: But the ID and everything else will be different.
<enli> Peng: i dont know yet what ID and everything else is, but i will take your word and not uncommit it, thanks a lot
<Peng> enli: bzr log --show-ids will display it, FWIW.
<Peng> enli: It's not very interesting. It's just a more complicated, unique ID for the revision.
<enli> hmm, so if nobody has yet pulled my branch, it will be pretty safe to push --overwrite.. yes?
<enli> Peng: i am out, thanks again
<NyRy> having a problem when committing on my server that bzr hangs
<NyRy> Any help much appreciated
<meoblast001> hi
<meoblast001> is it possible, with the understanding that i will break trees, to remove a commit, and all subcommits, from a branch?
<dash> sure, uncommit
<meoblast001> i'm not uncommitting that far back
<Peng> meoblast001: uncommit takes a -r argument.
<meoblast001> Peng: so i can remove 1 specific commit, while keeping everything else in tact?
<bob2> if it's the most recent one
<Peng> bob2: <3
<meoblast001> it's not
<meoblast001> that's the problem
<bob2> do you care this much |<------>|?
<Peng> If this is really the nuclear launch codes, you can use rebase or fastimport or somesuch to rebuild the branch.
<meoblast001> care about what?
<bob2> about removing this commit
<meoblast001> yes, i suppose
<Peng> meoblast001: Just curious, why?
<meoblast001> well, currently, until i get legal stuff worked out, i need to make sure i own copyright on every ounce of code in my project
<meoblast001> there is a small amount of unnecessary code made by others
<meoblast001> so i wanted to remove it completely
<Peng> Do projects usually complete expunge the old code in such situations?
<Peng> completely*
<meoblast001> don't think so
<meoblast001> but i'm very paranoid
<meoblast001> already freaking out with stress
<bob2> well, how will you separate it out?
<bob2> e.g. if you branch from before the first potentially-dodgy commit, what do you want to do?  just exclude the entire commits by other people?
<meoblast001> well, it's only really one
<meoblast001> i've been lucky enough to not get many contributors
<meoblast001> which is good, considering i have copyright issues to work out
<bob2> is this free software?
<meoblast001> yes
<meoblast001> i think i'll work this out tomorrow
<meoblast001> i'm going to bed
<meoblast001> good night
<NyRy> anyone know the syntax for drush generate-content
<mathrick> hey guys, is there something wrong with website?
<mathrick> I can't connect to it
<ralph> Hi, I've done 'bzr add foo' but haven't committed yet.  I want to remove foo from the list of outstanding things to commit.  How?
<ralph> mathrick: I concur.
<mathrick> ralph: bzr rm --keep --new foo
<ralph> mathrick: Thanks.  I understand.  Bye.
<parthm> vila: ping
<parthm> vila: ping: unknown host vila ... hmm maybe i will try later :-)
<Sheepherd> hey all
<Sheepherd> trying to install bazaar for the first time on win xp sp3 with this tutorial
<Sheepherd> http://wiki.bazaar.canonical.com/WindowsInstall
<Sheepherd> now unfortunately i got python 2.6 running and i cant seem to find the pycurl package for 2.6 only for 2.5
<Sheepherd> what should i do?
<Sheepherd> or is there even a crucial reason to use the python based installation instead of the stand alone one??
<starenka> hi, i'm desperate. how can i get branch base path in precommit hook?
<Sheepherd> just solved it. http://curl.haxx.se/mail/curlpython-2009-11/0001.html for a python 2.6 pycurl msi file
<Sheepherd> its me again... i ran into following error while compiling bzr-gtk. http://paste.pocoo.org/show/186339/
<Sheepherd> what shall i do now?
<Wellark> hi! does the rebase plugin have any active maintainer?
<Wellark> I tried to use it but could not get it working
<Wellark> using google does not bring up any tutorials or anything
<Wellark> ah, OK, it's maintained alright..
<Wellark> http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/ has had it's last update on Sat 2010-02-27 15:28:05 +0100
<Wellark> oh, well.. maybe I some day have time to look in to the inner workings of the plugin to be able to use it
<jelmer> Wellark: yeah, it's maintained but there isn't much documentation other than the command-line help
<jelmer> it's quite similar to rebase in git and hg though
<Wellark> ok, well it's probably just a user error on my side
<marv> I saw that inkscape recommended keeping a checkout the remote branch, and doing development in a separate branch, and then merging that into the otherwise pristine branch and then pushing, instead of pushing from the branch you actually wrote the feature in.
<marv> and then i did some googling and saw this thread:  http://www.mail-archive.com/maria-developers@lists.launchpad.net/msg00220.html
<marv> so i was wondering if the reverse merge thing they were talking about was on the roadmap
<mathrick> is there something like git's commit --amend?
<luks> bzr uncommit && bzr commit?
<mathrick> well, yeah, but it makes me write the commit message again
<luks> bzr uncommit && bzr qcommit :)
<mathrick> at least some links in 2.1 user guide are broken, they specify the old-style URLs: http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/bzr_man.html#revision-identifiers
<mathrick> which doesn't resolve, because this chapter is available at http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/revisionspec-help.html
<mathrick> the faulty link is here: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/specifying_revisions.html
<goundy> #chromespot
<goundy> oupse
<goundy> sorry guys
<goundy> I missed the /join
<goundy> this is not advertisment -_-
<marv> https://blueprints.launchpad.net/bzr/+spec/nested-tree-support links to http://bazaar.canonical.com/NestedTreeSupport, which 404s
<MTecknology> For my own bzr server; how hard is it to convert something like this   bzr+ssh://user@code.domain.com/home/user/connect/foo   to something like this   kalliki:~user/connect/foo ?
<MTecknology> I remember there being some nifty way to do something like that but I forgot how
<mathrick> MTecknology: what do you mean by "convert"?
<MTecknology> and never got it to work before
<MTecknology> mathrick: so I can do bzr branch kalliki:~user/connect/foo and it will change it to the really long one
<MTecknology> mathrick: sorry for the poor question - long day already
<mathrick> MTecknology: "converting" it as such is simple, as long as you have the access to a shell or smart server and install your own hooks
<mathrick> but no idea how hard it'd be to make bzr actually do that
<mathrick> you'd need plugins both on the client side and on the server side
<mathrick> because client needs to grok foo:bar as a remote ssh reference, and the server needs to do the actual translation
<mathrick> MTecknology: perhaps it'd be easier to make a plugin which just works on the client side and translates ~foo to /home/foo by default, unless you provide a map to override that for a particular host
<MTecknology> I'm just trying to make things simple for my users
<mathrick> then you definitely want to avoid relying on a particular server + client combination
<MTecknology> client side plugins sounds doable
<mathrick> make it a client-only plugin, it'll be a bit more manual for machines where ~foo isn't /home/foo, but at least it'll work with any host as long as you use the proper client
<mathrick> MTecknology: if you need to override the branch reference syntax, take a look at lp:bzr-colo
<MTecknology> I should be able to make something that can just be unpacked into ~/.bazaar/pulgins/, right?
<mathrick> it installs a colo: prefix
<mathrick> yes
<mathrick> oh, right, and beware of clashes with the built-in colon prefixes
<mathrick> date:, branch:, tag:, submit:, before: and last: at least
<mathrick> though of these I think only branch: and submit: are valid branch syntaxes
<MTecknology> I was thinking probably just k: or kalliki:
<mathrick> well, and lp: of course
<mathrick> MTecknology: but you want to provide that for any host
<mathrick> otherwise it'll be just confusing for users
<mathrick> well, maybe not more than lp:
<mathrick> but still, if you attempt to support widely-used syntax (SSH), you'd better make it work like everything else that supports it
<MTecknology> so, where should I get started building this plugin?
<MTecknology> I'll obviously need to start understanding python a little bit :P
<MTecknology> mathrick: do you know where the plugin is that handles lp:? or is that probably much more in depth than what I need?
<mathrick> MTecknology: lp: and colo: are the same deal
<mathrick> MTecknology: I think bzr plugins -v should tell you
<mathrick> the plugin you want is called launchpad
<MTecknology> I'm seeing .pyc files, do I need to compile the python before it can be run?
<mathrick> eh, no
<mathrick> that's done automatically by python whenever you invoke a .py file
<MTecknology> oh
<mathrick> running ubuntu/debian?
<MTecknology> ya
<mathrick> if so, you have them precompiled
<mathrick> sec
<MTecknology> looks like test_lp_directory.py is the file that I should look into
<mathrick> quite possibly
<MTecknology> mathrick: wow; this doesn't look friendly :P
<mathrick> lp is kinda huge
<MTecknology> yup
<MTecknology> I don't think my mind thinks in python
<mathrick> but you shouldn't be looking at test_*
<mathrick> that's, as the name suggests, tests
<mathrick> hmm, the netloc thing might not really be suitable for the kind of thing ssh foo:bar syntax needs
<mathrick> MTecknology: I'd wait until somebody more familiar with bzr's guts comes
<MTecknology> test_lp_directory.py has 'lp:' in it; which makes me want to look at lp_directory.py
<MTecknology> mathrick: ok, thanks for pointing me in the right direction
<mathrick> MTecknology: lp_directory is where it's at, but it might not be suitable a method for registering a catch-all prefix
<mathrick> which is why I suggested waiting
<mathrick> and you're welcome
<MTecknology> It's not really that bad because it remembers the branch push/pull locations; just be easier when we get more going on
<mathrick> yeah, though I could see it useful in an environment with many branches going on
<mathrick> if that's the case, a generic branch-reference-shortener could be useful
<mathrick> so you could say b:mtecknology:foo for example
<asabil> MTecknology, I can probably help
<mathrick> or b:main
<MTecknology> asabil: I can probably eagerly listen :D
<MTecknology> mathrick: how would I do that?
<asabil> http://pastebin.com/HHgSxp5M
<mathrick> MTecknology: by registering a b: URL scheme, like lp:, and then having a map from shorthands to full locations somewhere in the config file
<mathrick> but that only makes much sense if you really operate in a forest and need to refer to many branches often
<mathrick> asabil: but that's only for a fixed prefix:, no?
<mathrick> can you make it catch any not otherwise recognised prefix?
<asabil> mathrick, well you wanted something like lp: no ?
<MTecknology> ya
<mathrick> well, I wanted something like scp host:dir
<MTecknology> This is long: bzr+ssh://user@code.domain.com/home/user/connect/foo
<MTecknology> that's what I'm trying to change
<MTecknology> to k:~user/connect/foo
<praseodym> just upgraded to 2.1, but now I get the following error when pushing to a remote repository: "AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously.
<asabil> MTecknology, what I pasted answers your question
<MTecknology> asabil: what about the username@ part?
<asabil> MTecknology, you can do whatever you want with the url
<asabil> you parse it the way you want
<MTecknology> So I need to format this? -> return "bzr://code.kalliki.com/repo" + name
<asabil> yep
<asabil> for example
<MTecknology> asabil: Is there any way to decopmose the whole path into little pieces?
<MTecknology> So I could grab the first part of the path
<asabil> split ?
<MTecknology> ya
<asabil> "hello:world".split(":")
<asabil> for example
<MTecknology> oh
<MTecknology> that first part of the path will be the user name as well as the home directory
<MTecknology> so k:foo/bar -> bzr+ssh://foo@blah.com/home/foo/bar
<asabil> you remove the prefix
<asabil> and then split on th "/"
<MTecknology> then toss the first part into a variable
<asabil> user, directory = uri[2:].split("/", 1)
<asabil> (it is not the most beautiful python code :P)
<MTecknology> if url.startswith('prefix:'):
<MTecknology> I change that to my prefix?
<asabil> yes
<asabil> the uri[2:] it to remove the 1st 2 characters
<MTecknology> oh
<MTecknology> what's the else: for? if I matched that it start's with k:
<asabil> the else shouldn't happen
<MTecknology> if url.startswith('k:'):  if url starts with k:    name = url[2:]    then remove the first two letters and store in name     else:    but if it doesn't start with k:
<MTecknology> OH!
<MTecknology> does indentation matter in python?
<MTecknology> I had it wrong when you copied things and I read it as the return happens in the else :P
<MTecknology> asabil: that's what goes in __init__.py ?
<asabil> yes
<MTecknology> cool - an error
<asabil> ?
<MTecknology> I tried  return 'bzr+ssh://' + name.split("/", 1) + '@code.kalliki.com/home/' + name
<asabil> name.split("/", 1) returns an array
<asabil> whose size is maximum 2
<MTecknology> oh
<asabil> you need to extract the element
<MTecknology> asabil: ok, I thought it was returning the 1th item from it :P
<asabil> I guessed so
<elpargo> hi, I'm not a bzr user but I want to check out some code from trunk/tip whatever you guys call it :)
<elpargo> will someone be kind enough to point me the URL to check out the 0.10 branch for https://launchpad.net/ipython
<asabil> elpargo, bzr branch lp:ipython
<asabil> or  lp:ipython/0.10
<asabil> if you want the 0.10 series
<elpargo> yea I believe that is what I want as it has the bugfix but there is no 0.10.1
<elpargo> asabil: what's this lp? is that with an existing checkout?
<asabil> elpargo, lp is a shorthand for launchpad
<MTecknology> asabil: so if I want to force an error to happen, now do I do that?
<asabil> do the same as what is in the else:
<elpargo> asabil: interesting. That seems handy.
<asabil> elpargo, you are welcome
<humitos> hello
<humitos> I'm tryig to serve a branch downloaded from launchpad with "bzr serve" and I get this error:
<humitos> bzr: ERROR: Invalid http response for http://localhost:4155/.bzr/branch-format: Bad status line received
<MTecknology> asabil: :D absolutely perfect :D
<asabil> cool
<MTecknology> asabil: wanna see?
<asabil> yeah sure
<MTecknology> http://dpaste.com/168836/
<MTecknology> asabil: team|user/project/branch :D
<asabil> looks good
<MTecknology> asabil: namesplit = name.split("/", 3)
<MTecknology> sorry
<MTecknology> asabil: thanks :D
<MTecknology> mathrick: ^ In case you're curious what the solution was
#bzr 2010-03-07
<ubuntujenkins> how do i merge lp:~quickshotdevs/quickshot/luke-quickshot  into lp:quickshot?
<MTecknology> ubuntujenkins: pull the lp:quickshot branch, go into that directory, then br merge lp:~quickshotdevs/quickshot/luke-quickshot
<ubuntujenkins> cool thanks
<scibotic> Hi, I want to have a subdirectory of a repository to have seperate defaults to the rest, is it safe to just initialise another in there or is there another way I should approach it?
<scibotic> Oh hmmm, I probably should just avoid adding that directory ey?
<en1gm4> Hi all
<en1gm4> can anyoune tell me what's the command to view a screen like this: http://samba.org/~jelmer/bzr/bzrk.png
<jelmer> en1gm4: bzr viz
<jelmer> it's part of the bzr-gtk plugin
<en1gm4> jelmer: thanks a lot!
<en1gm4> yes I installed it but thought its command start with g***
<en1gm4> ok it works thanks!
<jelmer> maxb: hi
<meoblast001> ok, i've probably asked this before, but i tend to forget things a lot
<meoblast001> but when you move files, doesn't Bzr only log a move?
<meoblast001> actually, i'm sure i've asked that before, but don't remember the answer
<ronny_> meoblast001: kind of, it just reflects the changed locations of things in the inventory
<meoblast001> ok, so it doesn't log as file deleted, new file created?
<ronny_> just a move
<meoblast001> ah, ok, goo
<meoblast001> d
<ronny_> i dont think there is a vcs that records a delete+new (all that im aware of is recording copy+delete)
<luks> ronny_: CVS? :)
<ronny_> luks: is cvs really a vcs?
<lifeless> certainly
<luks> well, it has it even in it's name
<lifeless> ronny_: git
<lifeless> ronny_: (doesn't record copies, so it does delete + new)
<ronny_> lifeless: git doesnt record deletes either, it just records tree state
<lifeless> ronny_: well, from that angle so does bzr
<ronny_> lifeless: bzr cares about item histories and where a item is uniequely placed
<ronny_> git is just a state of trees of blob
<lifeless> ronny_: its tooearly for this. I assure you though, bzr does not record deltas.
<lifeless> any more than git does; bzr is snapshot focused.
<ronny_> lifeless: i didnt mention deltas, afair all of the major 'good' vcs's see them as internal optimazion
<ajeans> jelmer: I'm coming from LP #533407, do you have instructions on how to use the trunk versions of dulwich and git ?
<ubottu> Launchpad bug 533407 in bzr-git "bzr-git craches on pull in shamap.py , add_entry()" [Undecided,New] https://launchpad.net/bugs/533407
<lifeless> well you claim 'git doesn't record deletes' - a delete is part of a delta
<lifeless> you can't have a debate about 'storing deletes' - or not - without the concept of a delta being present.
<ajeans> jelmer: I grabbed the trunks of both, but how do I set them up ?
<luks> darcs doesn't count as good anymore?
<ronny_> luks: darcs isnt major
<lifeless> I wants: http://web.media.mit.edu/~marcelo/cornucopia/
<luks> heh
<ronny_> lifeless: everyone that saw star-trek does
<lifeless> :)
<ronny_> hmm, i think git is the most snapshot oriented, bzr carries way too much metadata about inventories
<luks> only the file ID
<luks> the rest is the same
<luks> but the file ID makes a big difference
<ronny_> where?
<luks> the difference? in how you can view the system
<ronny_> the only thing it really can help is annotate on a single file history
<luks> oh, I didn't mean functional differences
<ronny_> my usual view is tree of files' how do file-id's add a new perspective?
<luks> they don't (most filesystems represent files as ids anyway), git's no-file-ids add a new perspective
<ronny_> so where do they make the difference in viewing the system
<luks> in the definition of a snapshot
<luks> you said that git is the most snapshot oriented system
<luks> but the only difference is that bzr keeps file ids
<luks> so there is a difference in what people consider to be snapshots
<ronny_> bzr has a lot of metadata that relates items within one snapshot to the previous snapshot
<lifeless> no
<luks> what kind of metadata?
<lifeless> relates items in one snapshot to any other snapshot <- I'll accept that statement
<lifeless> luks: file id, content-revision-id
<ronny_> lifeless: my sloppy wording again :(
<luks> oh right, I forgot about per-file revisions
<lifeless> ronny_: :P de nada
<ronny_> lifeless: i decided to degrade bzr from fully wanted to 'pass the tests' in anyvc
<lifeless> ronny_: oh, thats a shame
<ronny_> lifeless: since having bzr in my mind actively complicated some of my mindmodels more than ever should be necessary i lost all reasons not to
<itistoday> anyone from japan here? Or know japanese immigrants who've lived in the USA whom I can ask a few questions?
<mwhudson> jelmer: "merge dave" isn't much of a commit message :-)
<mneptok> mwhudson: but makes a great potential title for a romantic comedy (or porn film)
 * jelmer tries to be smart and keeps quiet
<RenatoSilva> is there any command for undoing a given diff?
<bob2> kinda out of scope
<bob2> patch -R
<RenatoSilva> bzr: ERROR: no such option: -R
<bob2> nothing to do with bzr
<bob2> the gnu patch tool can apply diffs backwards
<RenatoSilva> can you get what I want?
<RenatoSilva> e.g. you are in rev 100
<RenatoSilva> then you realize that rev 80 was a mistake, then you want to undo it
<idnar> bzr merge -r 80..79
<RenatoSilva> it would be nice to have something like bzr revert -r 80
<idnar> or...
<RenatoSilva> idnar: nice, will try it
<idnar> hmm
<idnar> doesn't look like there's an easier way to specify it
<idnar> -c 80 will get you 79..80
<bob2> -c -80?
<RenatoSilva> bzr merge -r 80..79 doesn't work, it generates a conflict in a file, non-sense, the file wasn't edited in that revision
<bob2> bet you it was
<idnar> bob2: -80 will get you the revision 80 revisions before HEAD, I think
<bob2> ah
<idnar> RenatoSilva: are you sure r80 is the one you want to revert?
<RenatoSilva> of course
<RenatoSilva> it's actually 146, but that doesn't matter
<idnar> so you're using -r 146..145?
<RenatoSilva> 146 should not exist, so bzr merge -r 146..145
<RenatoSilva> yes
<fullermd> You need the dot.  "bzr merge -r80..79 ."
<RenatoSilva> oh
<idnar> oh, that's my bad
<fullermd> That won't make it not exist.  It just reverses the change and sets you up to commit that.
<RenatoSilva> of course
<fullermd> There's no way to make it not exist without rewriting all the revs after.
<RenatoSilva> no one said it would
<fullermd> Well, re "<RenatoSilva> 146 should not exist [...]"
<RenatoSilva> fullermd: and?
<fullermd> Just sayin'.
<RenatoSilva> no, I didn't say
<bob2> oh, I think RenatoSilva meant "146 is the rev I'd like to undo the effect of"?
<RenatoSilva> should != will
<fullermd> I know.  I'm just clarifying.
<RenatoSilva> bob2: should not exist == if I could go back in time, I would not commit it
<RenatoSilva> which may be possible if I find The Island
<RenatoSilva> fullermd: ok
<RenatoSilva>  bzr merge -r 146..145 . is sort of workaround right? it generates a conflict for the change, it doesn't actually patch the file
<RenatoSilva> hmm, it doesn't work either
<bob2> it's not a workaround, it is asking bzr to undo that change
<RenatoSilva> if I simply accept the merge source, I could be reverting valid changes in further commits (my case here)
<RenatoSilva> <<<<<<< TREE
<RenatoSilva> div.header, div.footer, div.sidebar, ul#timings, div#interwiki, table.navigation, a.action {
<RenatoSilva> =======
<RenatoSilva> div.header, div.footer, div.sidebar, div#interwiki {
<RenatoSilva> >>>>>>> MERGE-SOURCE
<RenatoSilva> it should be:
<RenatoSilva> div.header, div.footer, div.sidebar, div#interwiki, ul#timings, {
<RenatoSilva> >>>>>>> MERGE-SOURCE
<bob2> is this repo available?
<RenatoSilva> hmm that's right
<RenatoSilva> if a further rev did not chnage that line, the conflict would not happen I think
<idnar> if there have been other changes since r146 that conflict with undoing r146, then I would expect to see conflicts
<idnar> which you'll then have to manually resolve
<RenatoSilva> it's really a conflict I must solve
<RenatoSilva> so ok, my bad, but I don't get bzr merge -r 146..145 ., although I know the pratical result. I would get better bzr revert -r 146..145
<RenatoSilva> anyway, this is not so useful, it's more easy to just see the changes and undo them manually
<RenatoSilva> but thanks all anyway
<RenatoSilva> is there how to bzr diff -r 146..<current_uncommitted_changeset>?
<lifeless> bzr diff -r 146
<RenatoSilva> ok thanks!
#bzr 2011-02-28
<jelmer_> lifeless: sortof
<jelmer_> lifeless: ideally there wouldn't be any retrieval of tags beforehand as finding out what tags are present remotely requires a new TCP connection
<lifeless> right
<lifeless> I mean
<lifeless> 'I will want the heads for the tags for this branch'
<lifeless> so specifying a double dereference server side
<jelmer_> lifeless: I'm not sure I follow - server side in Bazaar you mean?
<lifeless> svn.git/hg
<jelmer_> I think I understand what you mean, except I don't really see where the double dereference is
<jelmer_> either way, I'll have a closer look tomorrow when my head doesn't hurt :)
<lifeless> jelmer_: denied
<lifeless> (ftpmaster)
<jelmer_> whoops
<jelmer_> lifeless: thanks
<arose> Hi, I was wondering if there is any easy way to create a copy of a pipeline to use with sync-pipeline
<jelmer_> moin spiv
<bialix> hi
<bialix> jelmer: please, don't set qbzr bugs status to Triaged. we're using only Confirmed. thank you
<jelmer> bialix: ah, sorry
<Manikandan> hi all when i am entering this cmd "bzr branch lp:nova", i got  ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<Manikandan> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist
<Manikandan> any one help me
<bialix> Manikandan: what
<bialix> Manikandan: what's your OS?
<Manikandan> debian
<bialix> what if you just launch command: ssh bazaar.launchpad.net
<Manikandan> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<bialix> that's your ssh client
<Manikandan> yes
<bialix> try to branch with command: BZR_SSH=paramiko bzr branch lp:nova
<Manikandan> wt is paramiko
<bialix> python ssh client library, bzr knows how to use it
<Manikandan> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; [Errno 111] Connection refused
<jelmer> Manikandan: does "sftp bazaar.launchpad.net" work?
<bialix> something prevents you to connect to launchpad. maybe some sort of firewall or proxy?
<JaredWigmore> hey, is bzr replay documented in more detail somewhere? / what do you do if you get a conflict during the replay command?
<bialix> JaredWigmore: only cry
<Manikandan> after remopvinf proxy also it show the same error 111
<jelmer> JaredWigmore: replay isn't really polished yet, it's intentionally hidden at the moment
<jelmer> JaredWigmore: I'd recommend using "bzr merge -c" + "bzr commit" for the moment instead
<JaredWigmore> jelmer: thanks
<Manikandan> after removing  proxy also it show the same error 111
<mgz> jelmer, I'm curious, what was the bzr-git fix for bug 393038?
<ubot5> Launchpad bug 393038 in Bazaar "UnicodeDecodeError in _inaccessible_normalized_filename" [Medium,Confirmed] https://launchpad.net/bugs/393038
<mgz> did you basically do decode('utf8') somewhere before passing a string to the bzrlib.inventory code?
<jelmer> mgz: yes
<mgz> okay, so I think the bzrlib side needs to define what sort of strings inventory stores and check they're the right ones.
<mgz> even the docstrings in that file use both bytestrings and unicode.
<mgz> having some unrelated function blow up later isn't a great way to tell callers they passed the wrong thing.
<Manikandan> i have stop the firewall
<Manikandan> also
<bialix> jelmer>	Manikandan: does "sftp bazaar.launchpad.net" work?
<Manikandan> no, it shows
<Manikandan> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<Manikandan> Couldn't read packet: Connection reset by peer
<bialix> jelmer: ^
<Manikandan> wt
<Manikandan> when i remove the proxy i got this error : bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 111] Connection refused
<jelmer> Manikandan: for some reason your machine can't make outbound ssh connections to bazaar.launchpad.net, but it seems to happen independent of bzr as well
<Manikandan> so , wt can i do
<jelmer> Manikandan: you can force the use of http by specifying http://bazaar.launchpad.net/nova (IIRC) or alternatively fix the connection issue on your side
<sbs> i
<sbs> hi
<sbs> I am new to bzr, and have started working on my repo but I have now a message in bzr explorer which I don't understand
<sbs> "branch has changes not present in its submit branch
<sbs> what would that mean?
<jelmer> sbs: that message doesn't make sense to me either
<sbs> :(
<jelmer> sbs: WHen do you see that message?
<sbs> when I look at my repo in bzr explorer
<jelmer> maxb: do you have bzr-builddeb commit access?
<maxb> I do not
<hunger> How long does bzr take to checkout bzr? It downloaded 16MiB in .bzr and now nothing happens. Is that normal?
<jelmer> hunger: building the tree after the history has been pulled in should be 5 seconds or so
<jelmer> maxb: landed your 4 branches
<hunger> Its more like 10min so far... No output apart from some complaining about a missing launchpad id.
<hunger> How big is .bzr of bzr? Is my network *SLOW* again?
<jelmer> hunger: 53Mb
<hunger> jelmer: Thanks. So it does not have all the data yet.
<hunger> Hmmm... size is only increasing every minute or so:-( Most likely a network issue then.
<maxb> hunger: Worth bearing in mind that the dumb http transport may be less efficient than the smart bzr+ssh transport
<hunger> maxb: I am only testing a Qt Creator plugin... Just asked it to clone lp:bzr because that was the first bzr project I thought of. No idea what it is doing.
<maxb> A fresh branch of lp:bzr done just now claims to have transferred 117948kB and taken 2m43s
<maxb> Which.... is a bit excessive considering it only ended up with a 53M .bzr :-(
 * maxb lunches
<hunger> maxb: No output from bzr at all (apart from bitching about missing launchpad ID), du -sh bzr says 22M so far.
<jelmer> maxb: that's including HTTP overhead, indexes, etc I think
<jelmer> hunger: it should show a progress bar if you're running it in a terminal
<maxb> That's a lot of overhead
<hunger> I am running it in the Qt Creator plugin. No progress bar there.
<lool> james_w: SUre
<james_w> unfortunately we are short on canonical bzr developers to ping
<lool> james_w: is this a new type of failure?
<james_w> lool, I suspect it is new with the move to bzr 2.3
<james_w> it may be an LP change though
<lool> Ok; thanks
<lool> james_w: Should I file a bug on this?
<lool> It's kind of unfortunate as we've moved the UDD branch for flash-kernel development
<lool> +to
<lool> https://bugs.launchpad.net/udd/+bug/726584
<lamont> bzr unshelve
<lamont> Using changes with id "1".
<lamont> bzr: ERROR: exceptions.NotImplementedError: <property object at 0x232daa0>
<lamont> sigh.  is known issue?
<lamont> shelved item was bzr moved between shelve and unshelve
<jelmer> lamont: I vaguely recall a bug like that
<lamont> that's 2.2.1-0ubuntu1
<lamont> cool enough
<zyga> hi, is there any documentation for bzr's "change-editor" configuration option
<zyga> it apparently can edit shelve'd changes to split a change in two
* spiv 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 officially out ! (RM: vila)
<mtaylor> how do I get a branch to push without stacking?
<spiv> mtaylor: I don't think we have an option for that yet, but you could init the remote branch and then 'bzr reconfigure --unstacked' that remote branch, then push.
<spiv> There's a bug about adding a --no-stacking option IIRC
<spiv> https://bugs.launchpad.net/bzr/+bug/391405
<mgz> spiv: I need some help with smart server code. if I put some not-complete branches up for review, would that be your preferred way of telling me where I need to be going?
<spiv> mgz: yeah, that's probably the best
<mtaylor> spiv: thanks
<jelmer> moin mgz, spiv, mtaylor
#bzr 2011-03-01
<mgz> spiv: thanks. posted some mps for you to look over at your leisure.
<lifeless> spiv: hi
<lifeless> spiv: did you check for a branch.conf with %7E, or was it clearly stacking?
<spiv> lifeless: there was a %7E in one branch.conf
<lifeless> spiv: the 11 second thing sounds suspiciously like sftp + branch locking + the url changing issue that broke checkouts
<spiv> lifeless: but the stacked-on locations were definitely pointing to each other (modulo how the URL was escaped)
<lifeless> spiv: is that even possible, even with branch renames?
<spiv> So maybe the %7E is a problem, but there also appears to be a stacking loop.
<spiv> Which is surely a problem too :)
<spiv> lifeless: I think so
<spiv> lifeless: with changing the dev focus around and enough rename steps
<spiv> See also <https://bugs.launchpad.net/launchpad/+bug/692085>, which features someone doing a complicated dance with dev focuses and renames (not sure why!) and ends up with a self-stacked branch.
<spiv> lifeless: I agree it sounds simliar to that checkout issue too, although I haven't managed to dig up the relevant bug yet
<lifeless> kk
<spiv> lifeless: I perhaps don't remember enough details, and I stopped looking for it when I saw the apparent mutual stacking.
<lifeless> the 'same branch' check looks for url string equality
<lifeless> a normalise call was either added/removed- I don't remember - on the lookup of something checkout related
<lifeless> it made 'bzr update' blow up
<lifeless> fullermd remembers the bug
<fullermd> Hmmwhut?
<fullermd> I don't recall ever being involved with any bugs on stacking...  I have it on my mental "do not touch" list.
<lifeless> not stacking
<lifeless> bzr update and the %7E vs ~ thing
<fullermd> Hm.  I vaguely remember hearing of such a thing, not sure I got anywhere near it.
 * fullermd checks what LP has to say...
<lifeless> fullermd: last time this was discussed here, Ithought you piped up witht he bug #
<lifeless> perhaps it was peng
<fullermd> Hmmm...   here's an ugliness about co's of co's with local vs remote paths: https://bugs.launchpad.net/bzr/+bug/325296
<fullermd> Nothing about recursive livelocking though.
<fullermd> Unrelated, but on a bug gardening note: https://bugs.launchpad.net/bzr/+bug/582656
<fullermd> Still showing a 'New' status on one of its product/effects/whatever's.  Should it?
<fullermd> Annoying how LP shows the same bug multiple times (and widely separated) in its listout   :|
<lifeless> thats the per context thing
<lifeless> there is a bug on it
<lifeless> it has a reasonable reason behind it, solvable with some good ui work
<Manikandan> when i use this cmd
<Manikandan> i got the following error
<Manikandan> root@cdac[openstack]#bzr branch lp:nova
<Manikandan> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<Manikandan> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<spiv> Manikandan: the service is up for me
<spiv> Manikandan: you may have a firewall between you and bazaar.launchpad.net:22?
<techbreak_> bzr branch lp:ubuntu/maverick/computer-janitor
<techbreak_> Permission denied (publickey).
<techbreak_> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<techbreak_> help me with this please
<spiv> techbreak_: the SSH authentication is failing
<techbreak_> spiv, what am I supposed to do ?
<spiv> techbreak_: have you added your SSH public key to your Launchpad account?
<techbreak_> spiv, yes
<spiv> techbreak_: try 'ssh -v -l YOUR_LP_USERNAME bazaar.launchpad.net' and take a look at which keys it tries
<techbreak_> spiv, http://paste.ubuntu.com/573882/
<spiv> Also, what's your launchpad username?  I can take a look at your equivalent of https://launchpad.net/~spiv/+sshkeys and see if there's any really obvious problem.
<spiv> Well, it's trying a key (/home/techbreak/.ssh/id_rsa), but it apparently doesn't match your publickey(s) on Launchpad.
<ChrisCauser> Hi guys
<ChrisCauser> Just wanted to say that I've just downloaded the PPA of the bazaar 2.4 and it is fantastic. It's so much zippier than the 2.2 I was using before. Keep up the good work. You have a fantastic codebase
<spiv> ChrisCauser: thanks! :)
<ChrisCauser> Spiv: No problem. I use bazaar everyday to integrate with a subversion repo and it does it much better than any other solution out there. I like how it made subversion faster even before I upgraded to 2.4!
<techbreak_> spiv, so what am I supposed to do ?
<spiv> techbreak_: <spiv> Also, what's your launchpad username?  I can take a look at your equivalent of https://launchpad.net/~spiv/+sshkeys and see if there's any really obvious problem.
<techbreak_> spiv, gupta-chandan1
<spiv> techbreak_: but basically, as I said above, the SSH public key(s) you have imported into Launchpad don't match your local SSH key.
<techbreak_> spiv, how am i suppose to import matching one then  ?
<techbreak_> :O
<spiv> techbreak_: um
<spiv> techbreak_: you should remove that publickey
<spiv> techbreak_: and read https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<techbreak_> spiv, how do I remove that publickey ?
<techbreak_> spiv, same link I followed earlier and created key
<spiv> techbreak_: no, you didn't create that key
<spiv> techbreak_: that's a key from paramiko's demo's directory
<techbreak_> spiv, huh? whats that now ?
<spiv> techbreak_: it's important for your security that generate your own key
<techbreak_> spiv, hmmm
<techbreak_> spiv, ok now tell me what shall I do now and how  ? bare my Noobity, I am just a beginner
<spiv> techbreak_: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<spiv> techbreak_: it explains things more clearly than I can :)
<techbreak_> spiv, ok I will do that :)
<spiv> techbreak_: I'd like to know how you found that publickey to upload, though
<spiv> techbreak_: it seems like an unusual thing to do!
<techbreak_> spiv, wait i will tell you :)
<techbreak_> spiv, gpg --fingerprint gupta.chandan1@gmail.com
<techbreak_> spiv, and then gpg --send-keys <mykey>
<spiv> techbreak_: that's GPG, that's a different set of keys entirely
<techbreak_> spiv, huh ? am I suppose to send some other key too ?
<spiv> At a technical level the public key cryptography GPG does has a lot in common with SSH, but it's different software with different keys.
<spiv> At some point you presumably went to https://launchpad.net/~gupta-chandan1/+editsshkeys and pasted in the contents of 'user_rsa_key.pub' from the demos/ directory of a library called paramiko.
<spiv> You almost certainly *meant* to paste in the contents of ~/.ssh/id_rsa.pub
<spiv> techbreak_: I'm off to bed.  Good luck!
<techbreak_> spiv, thaks a lot :) good night.. have sweetest dream :)
<jelmer> g'night spiv!
<spiv> techbreak_: (and if you figure out where you went wrong, feel free to tell me in this channel, I'll see it in the morning)
<techbreak_> spiv, can i have your email id ? or anything to contact if i get further problem ?
<techbreak_> spiv, okie fine if you are regular in this channel :) i will surely tell .. whether i succeed or not ;)
<spiv> (perhaps it's something we can improve)
<zyga> hi
<zyga> I'm trying to push a branch to lp:~zkrynicki/ubuntu/lucid/launch-control/packaging
<zyga> I'm doing this for a number of my packages (I push the debian packaging to a branch under ubuntu lucid)
<zyga> yet for some reason it fails on this branch, the error message is: "bzr: ERROR: Invalid url supplied to transport: "lp:~zkrynicki/ubuntu/lucid/launch-control/packaging": No such source package launch-control."
<zyga> am I doing something wrong? The patter is ~username/distro/series/package/branch-name
<maxb> zyga: Why not push the Debian packaging under debian?
<maxb> Also, apparently there is no such source package as launch-control
<zyga> maxb, that's not my problem - let's solve one problem first
<maxb> You know you can push to lp:~zyga/debian/sid/sourcepackage/branch right?
<zyga> maxb, there are no source packages for any of my things (I'm writing packaging for the first time) but previously it also accepted launchpad project names
<maxb> zyga: I'm fairly sure it never did that
<zyga> maxb, it did this for about half dozen other packages I made today and yesterday
<zyga> maxb, please have a look at https://code.launchpad.net/~zkrynicki
<jelmer> zyga: are you sure those were packaging branches, not "regular" branches?
<zyga> at the ubuntu/lucid brnahces
<zyga> jelmer, please explain the difference
<maxb> I infer that source packages already existed for the ones you've pushed already
<zyga> nope
<maxb> zyga: An "interesting" "feature" of launchpad is that source packages in PPAs count for this
<zyga> I've started packaging the stuff I'm writing for linaro
<zyga> ah
<zyga> so if I push a package to a ppa first
<zyga> then it's enough :D
<zyga> that's something I might have done earlier
<zyga> (build with pbuilder, push to ppa, push to lp)
<jelmer> yeah, that's a bug :-/
<maxb> see https://launchpad.net/ubuntu/+source/launch-control-tool for example
<maxb> jelmer: But it's such a *useful* bug :-)
<zyga> I like this bug :>
<zyga> but in fact there are two bugs :/
<zyga> there is no sane way to push packaging in a way that would link it from the project
<zyga> and project -> packages is a messy path with possibly different names
<zyga> (it just happens that some projects have same source package name as lp project name)
<zyga> right?
<zyga> maxb, now what is the advantage to pushing to debian/sid?
<zyga> maxb, my situation is rather strange as I need to target lucid explicitly and I cannot use more recent features without backporting things like dh_python2 that I'd rather not do (packaging is not my expertise)
<maxb> You said "debian packaging". I inferred you meant "Packaging for Debian"
<zyga> maxb, well I meant the packaging as in the debian directory for bzr-builddeb in merge mode (should have mentioned that)
<maxb> ah :-)
<zyga> while I'd love to push those packages to debian too
<zyga> I do not know the way
<zyga> (that would also solve future problem for the next LTS as I'll need to target that and it would come from debian for free
<zurgutt> Question: is there a size limit for bzr controlled project? i have one that is around 9 Gb, 18Gb with repository, 50 revisions, biggest file around 1Gb of sql.  bzr commit has started to segfault.  Ideas?
<jelmer> zurgutt: there shouldn't be a size limit
<jelmer> zurgutt: there are some issues with memory usage, but you should just get a MemoryError in that case
<jelmer> zurgutt: Can you file a bug about this, with a gdb backtrace?
<mgz> could be the dirstate pyx bug.
<zurgutt> if you tell me how to do it
<mgz> generally sizes > 4GB aren't well tested.
<zurgutt> it has actually created a big problem for me so need to find solution, either fix problem, drop some history or convert to other system if thats only option, im used to bzr tho
<mgz> is there a general guide about how to file bugs on actual crashes anywhere? does apport do the right thing?
 * mgz doesn't know gdb
<mgz> zurgutt: if nothing else, file a bug with the details on your repo and however much of .bzr.log gets output during the commit before it dies, and ask for more instructions
<viciousprimate> joing #ubuntu-devel
<viciousprimate> bah
<jelmer> viciousprimate: boing :)
<jelmer> zurgutt: something like "gdb --args /usr/bin/bzr commit" should land you in a gdb prompt
<viciousprimate> :)
<jelmer> zurgutt: after that, "run" to start bzr and then "bt" to print the backtrace when it's crashed
<zurgutt> jelmer: roger, thanks, ill try
<zurgutt> gdb --args /usr/bin/bzr commit
<zurgutt> (gdb) run
<zurgutt> Starting program:  commit
<jelmer> zurgutt: sorry
<jelmer> zurgutt: gdb --args /usr/bin/python /usr/bin/bzr commit
<maxb> jam: Thanks for the bzr-cvsps-import review (though that MP was already Merged). In that instance I considered the commit message itself to convey sufficient information, hence not supplying an explicit cover letter.
<quotemstr> Why does bzr complain about a " valid .bzr control directory, but not a branch or repository." when trying to upload to launchpad?
<quotemstr> The local branch is fine.
<jam> maxb: when reviewing via email, you don't see the commit message
<jam> I actually reviewed it about a week ago
<maxb> hmm. that seems like a bit of a flaw in the process
<jam> but launchpad rejected it for various reasons, so I was resending my "Submit Request Failure" queue
<maxb> quotemstr: Can you show the whole error message please?
<quotemstr> bzr: ERROR: At lp:~dan-colascione/emacs/misc-23/ you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
<jam> maxb: given that almost 100% of my submissions involve many commits, I think it is intentional
<jam> the point of the review is to summarize what happened
<jam> etc
<jam> it *does* tell me if you set an explicit recommended commit message for the proposal
<maxb> quotemstr: I would imagine a previous attempt to upload the branch failed, leaving only the basics of a .bzr control directory.
<quotemstr> Worked fine after I deleted the branch and recreated it.
<quotemstr> Thanks.
<achiang> hello, having some issues branching based on an rspec
<achiang> bzr tags gives me this partial output:
<achiang> 1:0.133.10           ?
<achiang> 1:0.133.11           ?
<achiang> i want the .10 version
<achiang> so, i say: bzr branch update-manager test -r "1:0.133.10"
<achiang> where update-manager is FROM and test is TO
<achiang> and i get: bzr: ERROR: Not a branch: "/home/achiang/Projects/update-manager/0.133.10/".
<achiang> any clues?
<maxb> achiang: "number:path" is a revspec format, so that's what it's parsing it as
<maxb> For tags containing colons, you'll need -r tag:blah
<achiang> maxb: what value do i use for "blah" ?
<maxb> e.g. -r tag:1:0.133.11
<achiang> oh, i see
<achiang> am i just being dense?
<achiang> achiang@oak:~/Projects/charlotte-x86/update-manager$ bzr branch update-manager charlotte -r tag:1:0.133.10
<achiang> bzr: ERROR: The branch update-manager has no revision <RevisionSpec_tag tag:1:0.133.10>.
<maxb> oh... I have a hunch
<maxb> Could you try "cd update-manager && bzr branch . ../test -r tag:1:0.133.10" ?
<achiang> bzr: ERROR: The branch . has no revision <RevisionSpec_tag tag:1:0.133.10>
<maxb> hrm
<achiang> does it have something to do with that ? in the output of bzr tags?
<maxb> oh!
<maxb> yes
<maxb> So, there's a tag there in the branch pointing at a revision-id, but that revision-id is not present in the branch
<achiang> hm
<achiang> that is disturbing. i just did a straight bzr branch from lp...
<maxb> of what?
<achiang> https://code.launchpad.net/~ubuntu-core-dev/update-manager/main
<maxb> achiang: thats .... interesting
<achiang> maxb: so, any clues on how to resolve this? i do kinda need to fork the branch at that revspec
<maxb> based on looking at the earlier 0.133.* tags, I would suggest that that revision exists on some lucid-updates branch
<putrycy> Hi! I think that it's is not possible to make "partial push". I.e. let's assume that I have two files - both modified. And I would like to push changes just from one of them. I think that it is impossible (=hard and not straightforward) if main branch and the main have diverged.
<achiang> hrm, ok. i guess i'll ping mvo tomorrow about this
<putrycy> Please, correct me if I am wrong
<putrycy> if my branch
<putrycy> and the main branch
<maxb> achiang: Have you tried lp:~ubuntu-core-dev/update-manager/lucid
<maxb> putrycy: You seem to be mixing two separate issues. If you have local modifications to two files, you can certainly commit one but not the other.
<maxb> Meanwhile, your branch diverging from main is a separate issue
<maxb> achiang: Yes, 0.133.11 is in that branch
<achiang> maxb: ok, i'll take a look. need to eat before my stomach digests itself.
<achiang> maxb: thanks for the help!
<putrycy> maxb: I know I can commit. But I'm talking about situation where one change is needed to push to the main branch. Is it possible?
<maxb> I'm sorry, you're not explaining your problem well enough for me to be able to help.
<putrycy> maxb: It seems that I know how to explain it: As I said before I have two branches - a main one that is shared with other users and a local one. I use the local one to commit to it my small changes and from time to time I push my work to the main branch
<putrycy> And now I have a part that I could push to the main brach
<putrycy> and a part that is not ready yet
<putrycy> Question: how to push to the main branch only changes that are ready to show them to other users
<putrycy> ?
<putrycy> In version control systems like SVN I can commit for example only one directory. What would be equivlent with pushing changes from that directory in the case of usage of bazaar
<putrycy> right?
<maxb> If you're using bzr in a svn-ish way, then you'd just commit the single directory in exactly the same way
<putrycy> and If I don't use it in a svn-ish way?
<putrycy> what then?
<maxb> If you've already committed a mix of changes, then you have created a problem for yourself and will need to recommit changes in sensible logical groupings
<putrycy> OK
<putrycy> thanks for reply
 * jelmer_ waves
<poolie> hi all
<spiv> Hi poolie, welcome back
<poolie> hi, thanks
<poolie> how are you?
<spiv> Pretty good, finally.  After the gastro last week I think my appetite has returned to normal today.
<poolie> and you're pilot this week?
#bzr 2011-03-02
<spiv> Yeah
<maxb> spiv: If you land your loom bzr-2.4 branch, then I think we can celebrate the daily builds PPA being all green for the first time ever :-)
<spiv> maxb: ooh, that's quite an incentive :)
<spiv> maxb: I need people to review https://code.launchpad.net/~spiv/bzr/branch-revs-to-fetch/+merge/51710 before I can though!
<maxb> ah...
 * jelmer waves to poolie, spiv, maxb
<jelmer> spiv: I had a look earlier today and was wondering if revs_to_fetch() wouldn't be more appropriate on InterBranch
<spiv> jelmer: hmm!
<jelmer> it seems like it should belong on InterBzrDir, but we have no such thing
<spiv> I don't think it would belong on InterBzrDir
<jelmer> spiv: I'm thinking of a case when there are e.g. multiple heads
<jelmer> like colocated branches
<spiv> Well, for the logic we have today that this is a refactoring of, it wouldn't belong on InterBzrDir
<jelmer> spiv: fair enough
<spiv> Colocated branches are an interesting case.
<jelmer> spiv: still, I think InterBranch might be a better location than Branch as that e.g. allows custom InterBranch implementations to override the behaviour
<spiv> jelmer: yeah, I didn't remember about InterBranch at all
<spiv> It may even make the 'use default local logic' hack in remote.py slightly neater.
<spiv> (or maybe not, but worth trying)
<spiv> Can you maybe elaborate a little in a review comment about the sort of thing that custom InterBranch would want to do here?
<jelmer> spiv: sure
<spiv> I think I can guess pretty well, but not guessing is even better :)
<spiv> Also,
<spiv> Do you think this is heading in a direction that'll be overall a bit nicer for foreign formats?
<spiv> I'm pretty happy that it's made it pretty easy to improve the way bzr-loom fetches, but that's also a pretty similar format to the builtin ones in that it has a regular bzr repo underneath it.
<jelmer> spiv: yeah, I think it is
<spiv> That's good to hear.  :)
<lifeless> :(
<amriedle> jelmer: in subvertpy, is there support for svn mergeinfo --show-revs = merged/eligible ?
<yjmbo> I'd like to use bzr+ssh:// to get to a branch, in a cron scripted task. I need to specify a keyfile for authentication. I don't see any way to pass options to the ssh command (i.e. like rsync does), and this task doesn't really have an associated user account, so no ~/.bazaar directory to leave a config file. BZR_SSH doesn't allow arbitrary commands to be used. How can I achieve this?
<spiv> yjmbo: hmm, I thought we did allow arbitrary commands somehow
<spiv> yjmbo: ah, so I think BZR_SSH doesn't take arbitrary commands, but it does take arbitrary paths
<spiv> yjmbo: i.e. you could make a shell script that does "ssh -OIdentityFile=...", and set BZR_SSH to that script.
<yjmbo> spiv, I tried point to a script with BZR_SSH, but it had to have a pre-approved name. So I called it 'ssh', put it first in PATH, and accidentally fork-bombed my server.
<yjmbo> When my server recovers I'll try again :-) But it looks like the only way to pass ssh options is to fake the environment, rather than explicitly pass them in.
<spiv> yjmbo: you should be able to pass any path, which version of bzr do you have?
<spiv> yjmbo: using a path has been supported since 2.1.0
<yjmbo> spiv, it should be 2.1.1 but I cannot tell you what happened when I tried because I've lost that server session. Need an intervention from the VM host to get back in, too. I'll try again tomorrow and see what happens then!
<jam> morning all
 * fullermd waves at jam.
<jam> fullermd: good to know I'll see you around in any TZ I switch to
 * fullermd is a constant   :)
<Manikandan2> when i use the cmd bzr branch lp: nova i got the folooeing errorbzr branch lp:nova
<Manikandan2> Write failed: Broken pipehing revisions:Inserting stream:Estimate 26772/42003
<Manikandan2> Write failed: Broken pipe
<Manikandan2> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.          à¤
<maxb> Manikandan2: my initial thought would be a local connectivity problem
<maxb> Manikandan2: works fine for me
<Manikandan2> à¤¦à¤
<Manikandan2> ok i will check it thank u
<Manikandan2> it is downloading for some, after that only it gives broken pipe error
<stefanlsd> is http://wiki.bazaar.canonical.com/BzrHooks still the best info re hooks?
<spiv> stefanlsd: probably not
<spiv> stefanlsd: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html and http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/hooks.html are better I think
<stefanlsd> aah. thanks. yeah
<spiv> (which is where that wiki page tries to link to, but its links are a bit stale)
<maxb> I'm contemplating some plugin to automatically sync branches from one server to a backup when they change. I'm thinking LockHooks.lock_released is the best way for me to do this. Anyone have some thoughts on that?
<spiv> maxb: Branch's post_change_branch_tip perhaps matches better.
<spiv> Although I guess lock_released will catch updates to tags too.
<maxb> spiv: Unforunately that will fail to tell me about tags changing
<maxb> yup
<spiv> We should at a hook point for that!
<maxb> tags in general need some love
<spiv> Well, at least tagged revisions are (mostly) fetched now.
<maxb> I would like to see info on new/changed tags reported by push/pull
<spiv> *nod*
<maxb> Also, merging tags probably should omit revisions not in the ancestry of the destination branch
<spiv> Hmm, I'm not sure about that.
<maxb> oh?
<spiv> I'm just not sure enough of the use cases to have a strong opinion, but my suspicion is that at least some users expect tags to never be omitted by default.
<spiv> Partly because tags are merged in several different contexts.
<maxb> Hmm. I'm trying to think of a way in which a tag referring to a non-present revision id would be useful
<spiv> not-in-ancestry != not-present
<spiv> But I think there are probably cases where even tags of ghost revisions may be useful.
<spiv> Anyway, zzzz time.
<jam> hi spiv
<jam> bye spiv :)
<empity> hallo everyone
<empity> I had some conflicts, but I didn't care about the changes
<empity> so I removed simply them and pull again
<empity> but they don't get pulled
<empity> can I force this somehow?
<empity> with git I think they are written if you remove them
<maxb> If you pulled, got conflicts, and reverted them, then you already have the changes, so there is nothing new to pull.
<exarkun> is there a windows installer that includes bzr and bzr-svn?
<jelmer> exarkun: the default installer includes bzr-svn I believe
<exarkun> hm, I guess that is what http://wiki.bazaar.canonical.com/WindowsDownloads suggests
<exarkun> I wonder why it's not working
<jelmer> I think you have to click a checkbox in the setup to enable it
<maxb> jelmer: Hi. You've not pushed bzr-rewrite 0.6.2 into lp:bzr-rewrite
<jelmer> maxb: it's a mirror
<jelmer> maxb: might take a while to update
<maxb> ah
<maxb> grr, LP should make that more prominent
<jelmer> maxb: btw, you're aware you have two approved reviews for landing into bzr-cvsps-import?
<jelmer> uhm, s/reviews/mps/
<maxb> *blink*
<maxb> Oh, they've been re-opened by jam's delayed merge proposal emails
<jam> jelmer: so what hours do you usually work?
<jelmer> jam: 10-6 CET
<jam> jelmer: so for another ~2 hrs?
<jam> I think I'm shooting for 8:30 - 5 CET myself.
<jelmer> yep, although I'll probably head out a bit earlier today and then do some more work around the UDD meeting in the evening
<jelmer> jam: I think that (8:30-5) is roughly the hours vila works, too
<jam> jelmer: I'm pretty sure vila works until past 6 or 7. At least, that's what I recall from the US :)
<jelmer> jam: I guess it's probably more like 8:30-7:00 :)
<jelmer> I'm often around in the evenings too
<jelmer> I just hate mornings.
<jam> I think vila nominally stops at 5, but he almost never actually stopped then. At least, I remember him saying around 10 that he should go, and 10+7 = 5pm.
<mgz> jam is in europe?
 * jelmer heads out to vote and errands
<jam> mgz: I just moved. My wife got a promotion for 2 years in the Netherlands.
<mgz> great! more timezone overlap means I get to bug you even more? :)
<jam> mgz: /ignore, /ignore /ignore, dangit, it just doesn't work
<jam> :)
<achiang> this is a silly question, but... how can i push a branch to just a filesystem?
<achiang> say i have a local branch, and i have an account on a remote machine
<achiang> i just want to push my branch to a directory on the remote machine somewhere
<james_w> achiang, if bzr is on the remote machine then "bzr push bzr+ssh:///remote/some/path" should work
<james_w> if it's not installed then use "sftp://"
<achiang> james_w: great, thank you. i had my syntax wrong, was missing an extrah '/'
<james_w> achiang, err, I think I added an extra one actually :-)
<achiang> oh
<james_w> achiang, what error did you get?
<achiang> james_w: it was a conceptual misunderstanding on my part
<achiang> james_w: i was attempting to use scp/rsync semantics, like such:
<james_w> ah
<achiang> bzr push bzr+ssh://remote:./local/path/in/home/dir
<achiang> but bzr push bzr+ssh://remote/home/achiang/local/path/in/home/dir works
<james_w> if you have modern bzr on the server then ~ will work
<james_w>  bzr+ssh://remote/~/local/path/in/home/dir
<achiang> Bazaar (bzr) 2.1.1
<james_w> I can't remember the version that was added, sorry
<achiang> james_w: no worries, i got it to work
<achiang> i think this is actually nicer than git; iirc, you must git init first before you can push somewhere
<achiang> git init on the remote machine, that is; rather simply pushing and creating a new repo
<achiang> so kudos to bzr for Doing The Right Thing (tm)
<achiang> james_w: another dumb question -- what's the best way for a local repo to sync back up with upstream? i've been using bzr merge ; bzr commit, which isn't so nice because it introduces a merge commit. is there an equivalent to git's fast-forward?
<james_w> achiang, "bzr pull"
<achiang> james_w: ah, thank you
<achiang> james_w: much nicer, thanks!
<james_w> achiang, oh yeah, there's "bzr merge --pull", which is more like "git merge", and does the fast-forward if it can
<james_w> it doesn't auto-commit like git
<achiang> git merge definitely introduces a merge commit there
<achiang> in git, i usually say, "git fetch ; git rebase <refspec>" where <refspec> is usually 'origin'
<achiang> that does a fast-forward thingy, but it's only good for leaf-node developers
<achiang> 'bzr pull' does what i want in the simple case quite nicely
<james_w> sorry, I meant "git pull"
<LeoNerd> If your branch is a strict ancestor of upstream, then  bzr pull  is what you want
<LeoNerd> (You can tell this by  bzr missing  only listing revisions you don't have, not extra ones you have that upstream does not)
<achiang> that terminology is confusing. shouldn't it be "descendent" ?
<LeoNerd> No... your branch being an ancestor, meaning it's older than... Upstream will be newer, having more commits..
<LeoNerd> So  pull  just introduces those revisions into your branch, from upstream
<achiang> LeoNerd: got it, that makes sense... kinda. :)
<briandealwis> achiang: I think the confusion comes from provenance (where did the branches originate) vs contents (revisions)
<briandealwis> I too was initially confused reading LeoNerd's description
<achiang> yes, i think most people think of provenance when it comes to terminology (ancestors, children) rather than contents
<achiang> but i appreciate all the explanations, very helpful, thanks
<yshavit> Hi all, I've got a criss-cross warning on a bzr merge... there's only a couple conflicts and they're pretty easy to resolve. If I manually resolve them, is the criss-cross taken care of, or does it still linger (ie, will it cause problems down the line) ?
<poolie> yshavit, it's now taken care of as far as merging those particular revisions
<poolie> of course another one way occur in future
<yshavit> poolie: but it's not like every branch/merge from that branch is now going to have that, right?
<poolie> no
<yshavit> poolie: awesome, thanks :)
<poolie> it's not really a problem if this occurs
<poolie> basically it means A is merging from B and B is merging from A, without them ever pulling
<poolie> which is fine
<poolie> but the conflicts will sometimes get more complicated than if they both merge to and pull from a trunk
<yshavit> poolie: okay, thanks. I was pretty sure that was the case, I just wanted to make sure since I hadn't seen that before.
<spiv> Morning folks.
#bzr 2011-03-03
<lifeless> is this a regression:
<lifeless> :!bzr pull :push
<lifeless> bzr: ERROR: Unsupported protocol for url "lp:~lifeless/launchpad/bug-722956"
<spiv> lifeless: I'm not sure, but it's certainly not ideal.
<spiv> lifeless: not a regression based on quick experimentation
<lifeless> spiv: k. do you want a bug files?
<poolie> there may be one, but if there isn't please do
<lifeless> poolie: I no longer know the bzr bugs like the back of my hand :)
<lifeless> poolie: I've filed bug 728162, I wasn't sure how imprtant to make it, and have left it untriaged as a result
<ubot5> Launchpad bug 728162 in Bazaar "bzr pull :push with a push url of lp:~me/project/$appendpath crashes" [Undecided,New] https://launchpad.net/bugs/728162
<stewart> hi! I'm having issues using fast-export to do a fast-import into git. I'm getting an error from the git fast-import about a path not being in branch.
<stewart> http://paste.drizzle.org/show/418/ and http://paste.drizzle.org/show/419/ are relevant
<stewart> (i'm only trying the import to run gitdm on it... instead of extending bzr stats, at least initially)
<poolie> hi
<stewart> poolie, hi!
<poolie> sorry that doesn't ring any bells
<poolie> i would probably dig into the fastexport stream to work out whether the name was in fact written already
<stewart> poolie, hrm. darn.
<stewart> poolie, i'll try doing a bzr fast-import :)
<spiv> Hmm, is it just me, or is per_branch.test_bound_sftp always skipping every test?
<jam> spiv: yes, I saw that a while ago, and I think I opened a bug
<stewart> poolie, the first mention of that path is a "M 644 inline storage/innobase/handler/handler0alter.cc" line... which IIRC means the same as create new file, right?
<poolie> i think so
<poolie> hi spiv, jam
<stewart> trying new git version, seeing if it's fixed there :)
<maxb> spiv: I'm sorry to report that the bzr-loom testsuite run in the daily PPA is still having five tests failing with NoSuchRevision exceptions after your branch has landed
<maxb> although...perhaps thats because the version of bzr itself wasn't new enough
 * maxb hits some rebuild buttons
<spiv> maxb: yeah, that's probably what's up
<maxb> Hurrah! The daily PPA is now *all green*
<lifeless> \o/
<catphish> does bazaar support a 'receive' hook?
<maxb> catphish: What is a 'receive' hook?
<catphish> when a client pushes to a server, a 'receive' hook would be executed on the server side
<catphish> similar to pull i suppose, but initiated by an external host
<maxb> That's a git-ish way to describe it :-)
<catphish> i'm a git user :)
<maxb> There's a post_change_branch_tip hook
<catphish> that is what i need :)
<maxb> What do you want to do with the hook?
<catphish> when someone pushes to my branch i want to know what commits were pushed
<maxb> right
<maxb> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html#post-change-branch-tip
<catphish> that seems ideal, thanks
<catphish> is there any documentation about what params it passes?
<maxb> yes.... at that link
<maxb> post_change_branch_tip is called with a bzrlib.branch.ChangeBranchTipParams
<catphish> oh yeah
<catphish> sorry i'm not actually a python developer but hopefully i can push that out to a shell script easily enough
<catphish> it has all the parameters i need in that object
<lool> james_w: Hey; how do bzr fixes propagate to UDD?  I see bzr was fixed in tip to fix the flash-kernel bug; do we then need a bzr package upload in natty and some action on package-import.ubuntu.com before this gets picked up?  do I need to ask for flash-kernel to be tried again?
<spiv> lool: the bzr on package-import.ubuntu.com needs to be updated
<lool> spiv: is this a manually installed one, or a .deb from Ubuntu?
<spiv> It's a deb, packaged by the admins I think
<spiv> Probably an RT asking for it to be updated to tip of lp:bzr/2.3 would be the next step, although perhaps having a tarball release would help, I'm not sure.
<spiv> I think it's based on a deb for hardy in one of our PPAs.
<jam> jelmer: just a poke that your converter script should be ready to land
<jam> spiv: isn't it ~midnight in sydney?
<jam> but hi, nonetheless
<jelmer> hi John
<jelmer> jam: Which converter script?
<jam> https://code.launchpad.net/~jelmer/bzr/converter/+merge/51993
<jam> Ah, I see it says sent-to-pqm
<jelmer> jam: It's already merged :)
<jam> did you have some problems recently with that? I thought I saw a patch from you that got about 4 submissions
<jam> jelmer: guess it is just lag on LP's part, then.
<jam> or, lag on *my* part refreshing the page :)
<jelmer> heh :)
<jam> would be nice to have Queued to take things out of Approve Ready to Land
<jelmer> jam: Are you seeing this in hydrazine?
<jelmer> there's a bug in launchpadlib that makes it connect to staging rather than production
<jam> jelmer: no, on +activereviews
<jelmer> and staging's data is behind on production
<jelmer> oh
<jelmer> jam: I had some problems with my mail server a week or so ago, so some of my PQM submissions were being blackholed
<jam> I haven't had any particular problems with feed-pqm and this
<jam> ah
<jam> fun
<catphish> i seem to be having an odd problem with locks
<catphish> when i push i get "Could not acquire lock"
<catphish> it seems to be able to get a log but can never release it
<catphish> "bzr break-lock" returns bzr: ERROR: No such file: '/data/repos2/19/04af0f-525c-c55a-ec7e-0b7b801b8819/master/.bzr/branch/lock/held'
<catphish> which is simply not true
<catphish> ah - it only happens on bzr+https
<catphish> not plain http
<catphish> how odd
<catphish> probably another client bug in 2.1.1
<sidnei> is there a command in bzr that updates either a bound or unbound branch without bothering about which kind it is?
<maxb> um, define update?
<maxb> update on an unbound branch means make the working tree version match the branch version
<maxb> update on a bound branch involves making the working tree version match the (master) branch version, possibly synchronizing the local mirror of the branch data
<maxb> What about 'bzr pull' ? Does that do what you need?
<maxb> jam: Hi. Question about loggerhead - what are your plans for the evicted "experimental" branch? Are you going to bring all that lot in in a big merge at some point, or would it be useful to selectively propose merging of some of the feature branches that landed on experimental whilst it was trunk, to the new trunk?
<jam> maxb: if you have bits you can selectively propose, that would be great.
<jam> I don't really know how to split it apart at this point
<maxb> In that case, I think I will fire up qlog, and try to extract some merged feature branches for re-merging
<poolie> hello all
<jelmer> g'morning poolie
<poolie> hi there jelmer, how are you?
<jelmer> Doing all right, had a productive day :)
<jelmer> sorry I wasn't more awake during the meeting yesterday
<jelmer> How's your morning?
<poolie> np
<poolie> pretty good
<poolie> stephane is learning to scuba dive during her holiday, so i dropped her off at a little cove on sydney harbour this morning
<poolie> that's a nice way to start the day
<poolie> i'd like to actually write some code today after just doing mail and admin and sysadmin stuff yesterday
#bzr 2011-03-04
<Manikandan> hi all when i use this cmd bzr branch lp:nova
<Manikandan> i got bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 110] Connection timed out
<poolie> hi Manikandan
<poolie> that probably means a networking problem between you and launchpad
<poolie> maybe a firewall is blocking it?
<poolie> try using 'bzr lp-login YOUR_USERNAME'
<Manikandan> i entered the cmd but bzr: ERROR: Connection error: curl connection error (couldn't connect to host)
<Manikandan> on https://launchpad.net/~mahendrancse/%2Bsshkeys
<poolie> Manikandan, are you meant to use a proxy on your network?
<poolie> hi jam
<jam> hi poolie
<poolie> i think jelmer may be up at 0700 if he stays up late :)
<poolie> maybe not
<jam> Right, and I'm pretty sure there's no way you'd be up at 1800 CET
<jam> (~when he finishes his day)
<jam> 0400 Sydney if I'm doing the math correctly
<jam> He mentioned wanting to be around at 22:00 CET for the Ubuntu meeting. Maybe something like that would work better
<jam> poolie: I'll have to go in a couple mins. Would you rather see the EINTR codepath removed
<poolie> ah, as you said
<poolie> i often see him in his evening
<poolie> when he's not officially working, but we say hi
<poolie> if the eintr path is useful for testing, keep it and just mark it as such
<poolie> otherwise, i think it's just a distraction
<poolie> do things still work if you delete it?
<poolie> i'm a bit concerned it will vary between python versions
<poolie> iirc the built in eintr handling has done so
<jam> poolie: possibly, though this is LP code, so we don't care a lot about working across lots of versions
<poolie> well, eventually they will go to 2.7 or whatever
<poolie> better not to have to revisit it then if something changes
<poolie> but you're right there's not nearly as many variations as in bzr
<robblesz> Hi folks, can someone explain to me what these revision numbers are, with the .x.y suffixes? http://www.szakmeister.net/pictures/qbzr-log.png
<robblesz> All revnos in my repo are whole numbers, I'm just wondering what kind of work flow would produce what's in the screenshot
<soren> robblesz: When you merge stuff, the commits on the merged branch don't get integer revnos.
<robblesz> soren: oh, I see. I've been using feature branches but instead of merging I've been pushing. Maybe I should try merging
<soren> It's entirely up to you.
<JimmyTheKid> how do I check the last 5 logs
<JimmyTheKid> bzr log -r-5 only shows me the 5th last items
<JimmyTheKid> I want to check all last five
<bob2> -5.. probably
<hallyn_> I've done a 'debcommit -r -R --changelog=changelog'.  It didn't use my $DEBEMAIL for 'committer:'.  Is there a way to edit that after the fact?
<hallyn_> i.e. 'bzr commit --amend'
<hallyn_> all right i guess i'll just have to redo the merge
<maxb> no
<maxb> bzr uncommit; bzr commit
<hallyn_> maxb: thanks, will try that next time
<Lo-lan-do> Hi all
<Lo-lan-do> I see there's going to be a bzr sprint in London on 16-20 May.
<Lo-lan-do> Coincidentally, there's going to be an Alioth sprint in Cambridge on 20-22 May.
<Lo-lan-do> Maybe some of the former would care to join us for the latter?
<jelmer> ooh
<Lo-lan-do> Someone more familiar than I am with loggerhead would be particularly welcome :-)
<jseabold> Hi, I just nuked the whitespace in a project and it affects almost every line. Is there a way to keep these changes but remove the commit from the history, so bzr annotate is still useful?
<beuno> jseabold, not really, no
<rubbs> jseabold: is it the most recent commit?
<rubbs> cause you could always bzr uncommit, but as far as keeping the changes I have no idea.
<jseabold> Yeah, there was one more, but I can uncommit it.
<jseabold> Oh yeah, I want the changes I just don't care to see them in the history. Seems like it could be a common need. Guess not.
<vanguard> is there some command that returns me in a simple way whether the working dir is clean (everything commited) (I want to make a decision upon that in a bash script)
<james_w> bzr status should do that
<james_w> I'm not sure what it does w.r.t. unknowns, and what you want to happen there
<vanguard> Something that returns with 0 if it is clean and 1 if it was not clean would be awesome
<vanguard> got it: if the tree is clean, it does not output anything -> test "`bzr status`" ; echo $?
<maxb> james_w: Hi. The launchpad milestone/release metadata for bzr-builddeb is pretty out of date. What's your criteria for ~bzr-builddeb-hackers membership, would it be reasonable for me to request to join, to be able to fix that?
<maxb> (Or to put it another way, where is the boundary between ~bzr and ~bzr-builddeb-hackers?)
<james_w> maxb, I'd be happy to have you join the team
 * maxb requests
<maxb> On a wholly different topic, it's nice to see that someone other than me really really wants bzr-svn to interpret svn mergeinfo :-)
<james_w> maxb, accepted
<maxb> thanks
<maxb> I've just clicked in a join request for ~loggerhead-team, with the desire to be able to re-open merge proposals for branches de-merged by the shuffling off of recent trunk to the experimental branch
<maxb> Actually given the team's administrator membership I should say that on #launchpad-dev instead
#bzr 2011-03-05
<maxb> woo, sub 7 minute testsuite run.  bzr so *very* beats launchpad :-)
<wgrant> maxb: REAL projects have test suites that take 3.5 hours and fail 50% of the time.
<AdamDV> How can I get the file contents of file foo.bar from commit 45?
<jelmer> "bzr cat -r45 foo.bar"
#bzr 2011-03-06
<quotemstr> How do I use bzr merge to *revert* a revision given a commit number without having to type it twice?
<quotemstr> What on earth?
<quotemstr> bzr diff -r 102621..102620 shows a diff for an unrelated revision.
<lifeless> when is the release due that has jam's patch to commit to lightweight checkouts ?
<jelmer> lifeless: you mean to stacked branches?
<jelmer> let me check if it's in 2.3, if so it's already out
<lifeless> yeah
<jelmer> otherwise, 2.4 will be out around August I think
<jelmer> lifeless: it's in 2.3.0, so a fixed version has been out for roughly a month
<jelmer> (and is present in unstable/testing)
<jelmer> lifeless: thanks again for the encouragement to get the normal bzr testsuite going against the foreign formats.. finding *heaps* of small bugs
<lifeless> jelmer: :)
<lifeless> jelmer: I'm really glad you're doing that
#bzr 2012-02-27
<vindolin> is someone here using loggerhead?
<poolie> vindolin, yes, but right now i have to go
<poolie> might be best if you ask on the list
<Kamping_Kaiser> i'm using bzr builddeb and just tracking debian/. should i keep debian versioned, or a directory above debian? (eg, bar/debian , where bar has the .bzr in it)
<mgz> morning all
<jelmer> hi mgz
<jelmer> Kamping_Kaiser: hi
<jelmer> Kamping_Kaiser: you should keep debian/ versioned
<poolie> jelmer, mgz, hi?
<mgz> hey poolie
<jelmer> hi poolie
<poolie> oops
<poolie> will help if i talk in a channel that has you in it
<poolie> mgz, jelmer, how about a mumble?
<poolie> or hangout or whatever
<mgz> mumble works for me
<jelmer> sure, one sec
* mgz 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: gz
<mgz> jelmer: what's the status of your two approved-but-yet-to-land branches?
<mgz> ...I can never remember which two of shelve/unshelve --destroy/--delete match up
<mgz> they should just use the same switch
<jelmer> yeah
<jelmer> mgz: there was a test failure or two, I should bump them back to in progress I think
<jelmer> the downstairs neighbours have been noisly redecorating for the past couple of hours, I'm going to find a better place to work
<mgz> I've got room here!
<mgz> it's just a short swim away...
<mgz> okay, upgrading cythong fixed the importing of static_tuple, but broke the version parsing thing in setup.py again...
<jelmer> heh
<jelmer> not sure if that's worth the effort, considering the ferry already takes 5 hours or so :)
<jelmer> mgz: urgh :(
<mgz> they now like the form '0.16.beta0'
<sladen> I'm puzzled:  https://code.launchpad.net/~sladen/unity-2d/unity-2d-no-glow-lp933578 (Diff) shows "=== renamed file 'shell/launcher/artwork/launcher_pip_ltr.png' => 'shell/launcher/artwork/launcher_pip_ltr.png.OTHER'"
<sladen> but  find -name \*.OTHER  doesn't find such a file
<czajkowski> aloha
<ahasenack> hi guys, where can I find a 2.5b6 build for ubuntu? The beta ppa only has beta2
<ahasenack> I'm being hit by this bug in beta5, which is in precise: #917733
<jelmer> ahasenack: 2.5 should be in precise now
<ahasenack> jelmer: 2.5 final?
<ahasenack> jelmer: cool, let me try that, didn't see it
<ahasenack> jelmer: nice, it's working now, thanks
<jelmer> great
<mgz> darn it, would notice problem just after merging everything up
<mgz> ah well, should have tested again with the cython problem fixed before merging, could see it was causing failures
<DBO> where can I get bzrlib api docs?
<DBO> doh, nevermind
<DBO> related comment:
<DBO> http://doc.bazaar.canonical.com/bzr.2.4/developers/
<DBO> the bzrlib api docs link there is busted
<jelmer> DBO: hi
<jelmer> DBO: thanks for the hint
<jelmer> mwhudson: hi
<jelmer> mwhudson: http://starship.python.net/crew/mwh/bzrlibapi/ seems b0rked
<DBO> jelmer, if Im writing a plugin to a text editor to make it support bzr
<DBO> is it best to use bzrlib
<DBO> or to just call out to the bzr binaries?
<jelmer> DBO: if the plugin is in python then the best thing is indeed to use bzrlib directly
<jelmer> if not then there are perhaps other things that may work better
<jelmer> there is a fair bit of overhead in invoking the bzr binary directly (because of starting python, importing all modules, etc) so you probably don't want to do that, at least in a naive manner
<DBO> jelmer, are there good examples of doing simple things with bzr lib?
<DBO> (and yeah, the plugin is in python, so bzrlib should be easy enough to use)
<jelmer> DBO: hmm, that's a good question
<jelmer> DBO: http://doc.bazaar.canonical.com/bzr.dev/developers/ that you linked to is a good place to start
<jelmer> most of the existing trivial plugins are also good for inspiration
<jelmer> "from bzrlib.branch import Branch; b = Branch.open('/some/url'); print b.last_revision_info()"
<DBO> jelmer, yeah I am getting along now, is there really a need to do the initialize call?
<DBO> it seems to work without
<DBO> meh no big deal actually, just will do it anyhow
<jelmer> DBO: it's not strictly necessary at the moment but might become necessary i nthe future
<DBO> jelmer, okay will just do it
<DBO> jelmer, let me know if you mind the stupid questions, Im not a python guru :)
<jelmer> DBO: no problem at all :)
<DBO> jelmer, is there any way I can tell python where to look for some other packages, it seems this application ships a complete version of python with it...
<DBO> (so the plugin cant find bzrlib)
<thumper> DBO: really?
<jelmer> DBO: you can modify sys.path (which is a list) to include other locations it should look in
<DBO> jelmer, like this: sys.path = sys.path + ["/usr/lib/python2.7"]?
<DBO> thumper, yeah
<jelmer> DBO: yep, something like that (or sys.path.append(...))
<DBO> oooo append duh
<DBO> hmmm
<DBO> doesn't seem to work
<DBO> jelmer, sorry...
<DBO> sys.path = sys.path.append("/usr/lib/python2.7")
<DBO> AttributeError: 'NoneType' object has no attribute 'append'
<DBO> Im guessing that the sys hes shipping doesn't work right?
<LarstiQ> DBO: append works inplace
<LarstiQ> DBO: and returns None
<DBO> LarstiQ, ah
<LarstiQ> DBO: so just do sys.path.append("/usr/lib/python2.7")
<DBO> gobject has forever broken me
<DBO> LarstiQ, actually its still complaining with the same error
<LarstiQ> DBO: is this some longer running process?
<LarstiQ> DBO: what application is it?
<DBO> sublime text
<LarstiQ> DBO: http://sublimetext.info/docs/en/basic_concepts.html says "This embedded interpreter is intended only to interact with the plugin API, not for general development."
<LarstiQ> I wonder how far they took that
<LarstiQ> DBO: in a normal python sys.path should never be None
<LarstiQ> I think
<LarstiQ> DBO: what you could try then is assigning to it, sys.path = ["/usr/lib/python2.7"]
<DBO> that got me further
<DBO> crazy
<DBO> jelmer, do you know how I can turn an lp: link into something bzrlib understands?
<mwhudson> jelmer: you should be using the people.c.c version now
<mwhudson> jelmer: how did you get that link?
<poolie> hi mgz, jelmer, all
<poolie> dbo, if you have the launchpad plugin loaded bzrlib ought to just understand it directly
<DBO> poolie, do I need to do something special to make it load
<DBO> because I am just getting an error
<DBO> poolie, I am getting an unsupported protocol error
<jelmer> hi DBO, mwhudson, poolie
<jelmer> DBO: where are you passing the URL to ?
<jelmer> mwhudson: it's in one of the bzr docs
<jelmer> mwhudson: what is the proper URL?
<DBO> jelmer, branch.push(Branch.open("lp:myurl"))
<mwhudson> jelmer: http://people.canonical.com/~mwh/bzrlibapi/
<mwhudson> jelmer: i had a redirect, but it seems to have stopped working at some point
<jelmer> mwhudson: thanks, I'll fix thew link
<jelmer> DBO: did you call initialize() ?
<jelmer> DBO: and are you calling load_plugins()?
<mwhudson> jelmer: thanks
<DBO> jelmer, ahhhh that makes it crash but I'll figure it out :)
<DBO> is it possible to get bzrlib on python 2.6
<jelmer> DBO: yeah, it works with 2.6
<DBO> jelmer, how do I make it do that on ubuntu?
<DBO> :)
 * DBO knows nothing of python
<jelmer> DBO: it would just be available for the default python in that case I think (which is 2.7 in your case, I think)
<DBO> jelmer, yeah but im stuck on 2.6 :D
<jelmer> DBO: you can manually compile bzr into a specific location I guess, or get your editor to use the system python
<DBO> jelmer, it breaks with python 2.7 :)
<DBO> awesome
<DBO> screw it, abandoning S.S. bzrlib
<jelmer> DBO: you should be able to build bzr for python2.6 into a specific location (e.g. "python2.6 setup.py install --prefix=bar")
<DBO> jelmer, where do I get the sources?
<jelmer> DBO: https://launchpad.net/bzr/+download
<DBO> okay, trying that
<DBO> this guy needs to update his editor to python 2.7...
<DBO> jelmer, it gives a bunch of errors, Im thinking this might be more hassle than its worth
<DBO> i can probably just call the bzr command directly and get decent enough results to not care
<jelmer> DBO: I guess it depends a bit on what you're trying to do exactly
<DBO> I want to do a full out integration
<DBO> but its really not nice to have to deal with this python incompatibility
<jelmer> DBO: the issue with not using bzrlib but the bzr command-line executable is that you have to parse the output it generates
<jelmer> or use bzr-xmloutput and parse the output that generates
<DBO> why is bzrlib looking to build C files
<DBO> I dont get that...
<DBO> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.6 -c bzrlib/_static_tuple_c.c -o build/temp.linux-x86_64-2.6/bzrlib/_static_tuple_c.o
<DBO> bzrlib/_static_tuple_c.c:35:33: fatal error: _simple_set_pyx_api.h: No such file or directory
<DBO> its puking on that
<jelmer> DBO: there are (optional) implementations in C of some functionality, faster than the python implementation
<jelmer> hmm, I think that header should be included
<DBO> ah
<DBO> okay, just using the python fallbacks then
<jelmer> DBO: that header file should be included in the tarball I think
<DBO> I just grabbed trunk
<DBO> bad juju
<DBO> ?
<jelmer> DBO: if you want to run trunk with the C extensions, you need to have cython installed
<DBO> jelmer I do
<DBO> that was one of the first thigns i did
<DBO> its still complaining about not having it
<DBO> but it is installed
<DBO> jelmer, so this is the same error I was getting before when I moved teh bzr 2.7 stuff to be used with 2.6 (just to test)
<DBO> http://pastebin.com/duBb96yu
<DBO> thats what I get with my locally installed bzr now
<jelmer> DBO: your python installation doesn't support ssl, it seems
<DBO> jelmer, a man could be driven to insanity this way...
<DBO> Im sorry I have dragged you along :)
<jelmer> DBO: this is really unusual; I think you might not get very far in communicating with launchpad if there is no ssl support
<DBO> I wish I could talk with the app author
<DBO> and get maybe a better version of python on this
<DBO> either way I have switched his program to using system python 2.6
<DBO> which works mostly
<DBO> except now bzr is complaining about not being able to import future, which I can do from an interpreter
<DBO> ah I see
<wgz> the easiest option would be if the editor supported building against the system python
<wgz> rather than bundling another copy
<DBO> this is the program unsetting the sys.path
<DBO> wgz, its not open source
<wgz> then all the stuf you've just had break would work
<DBO> yeah, not my program though
<DBO> alright going to ask the program author to try to give me a better python env to work in...
<DBO> will see what happens
#bzr 2012-02-28
<mgrandi> it seems bzr explorer does not like huge trees
<mgrandi> http://bpaste.net/show/24322/
<poolie> hi
<poolie> yes it's a known bug
<poolie> i thought bialix was going to turn file watchers off by default
<poolie> it is too risky to be on til it's more stable
<mgrandi> it was going to be turned off on windows by default
<mgrandi> cause of its wonderful practice of one thing locking a file and then nothing else can use it
<mgrandi> i'm on a mac atm
<poolie> ah, maybe it should be off everywhere
<mgrandi> well
<mgrandi> this is a pretty extreme case, i'm just running a script (thats in a bzr directory) and by default it outputs stuff to the same dir the script is in
<mgrandi> and it has 6,721 items totaling 800 mb sooo =P
<mgrandi> be back on later~
<AfC> bzr 2.5 is released, right? Does that mean in will be in ppa:bzr/ppa soon?
<poolie> afc, right, quite soon
<AfC> poolie: cheers (just hit a github repo that I'm trying to branch that gave me an error to do with nested trees; I'm hoping that 2.5 will parse it)
<mgrandi> so, does bzr-git support pushing to github?
<mgrandi> dont want to push to test it cause i dont wnat to mess up the branch >.>
<LarstiQ> mgrandi: afaik it does
<mgrandi> well
<mgrandi> one way to find out
<mgrandi> haha
<mgrandi> and aww yeah thats sexy.
<mgrandi> requires a dpush but it works perfectly.
<mgrandi> anyway, bedtime~
<Milky> Hello all
<Milky> I am going to host a private bazaar for an internal team development
<Milky> but can't come across a descent doc/manual that goes through this...
<Milky> especially users administration
<Milky> I still have no idea how this works, assigning branches to specific users, setting read-only one a mainstream branch for all users but one for example... etc
<Milky> could anyone point me to the right direction?
<Milky> Thanjs in advance
<Milky> ...
<mgz> morning
<jelmer> hi mgz
<mgz> hi!
<poolie> o/ jelmer, mgz
<mgz> hey poolie
<jelmer> hey poolie
<poolie> hi there, sorry i missed you before
<stefanct> i am trying to setup a daily build recipe for a svn import, but i obviously have problems with the the deb-version string (or to be more precise with fulfillment of its prerequisites).
<stefanct> i have included a nest-part statement for the debian part of the ubuntu package
<stefanct> the first line of the recipe is bzr-builder format 0.4 deb-version {debupstream-base}-0~r{svn-revno}
<stefanct> http://paste.ubuntu.com/860449/ is the complete recipe + bzr dailydeb output
<jelmer> stefanct: hi
<stefanct> hi jelmer
<jelmer> stefanct: I think the 0.4 recipe format still has issues on launchpad
<jelmer> stefanct: you might want to try 0.3 (though that unfortunately doesn't support some of the variables you're using
<stefanct> agreed@0.4 but i am testing locally. shouldnt it work there?
<jelmer> stefanct: it should work locally indeed
<jelmer> stefanct: there isn't any packaging in lp:flashrom I guess?
<jelmer> in that case you want {debupstream-base:packaging}
<stefanct> a "packaging" directory?
<jelmer> stefanct: packaging refers to the branch you're nesting
<jelmer> stefanct: your deb-version has {debupstream-base} which would take the version string from the 'debian/changelog' file in the root branch (lp:flasrom)
<jelmer> except there is no such file in the root branch
<jelmer> {debupstream-base:packaging} makes it look at the branch nested under the 'packaging' name
<stefanct> ah!
<stefanct> are there any good docs about that? this is all missing from the help.launchpad.net pages :/
<stefanct> well.. i should recheck that first before blaming.. :)
<stefanct> "Here fix-build is a unique short name that we'll use to refer to this branch throughout the recipe." my bad.
<jelmer> stefanct: see also 'bzr help builder'
<stefanct> ah. i was looking at the man page...
<stefanct> jelmer: thanks a lot! --no-build completes now successfully locally and i think i know enough to solve the ppa build on my own
<jelmer> cool
<stefanct> but it explodes ofc on launchpad due to https://bugs.launchpad.net/launchpad-buildd/+bug/915505 :)
<ubot5> Ubuntu bug 915505 in Launchpad Auto Build System "bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split'" [Critical,Triaged]
<jelmer> stefanct: yep, that's the bug I had in mind earlier
<stefanct> last question hopefully: is it possible to have comments in recipes? # obviously is not ignored :) i would like to add a 0.4 template for later when that bug is solved
<jelmer> stefanct: yes, you can have comments but they have to start at the beginning of a line
<jelmer> I'm not sure if launchpad preserves them
<stefanct> it does not
<jelmer> stefanct: I guess you can put it in the recipe description
<stefanct> good idea, but i dont trust launchpad... ill save it locally too :)
<wilx> Hi.
<wilx> Is it possible to sync-pipeline and then work with the pipeline in the other location?
<wilx> I have done this: 1) created a pipeline and done some changes. 2) bzr sync-pipepile /my/usb/flash/memory. 3) bzr sync-pipeline /home/wilx/mysharedrepo.
<wilx> Now, it has created two branches in the shared repor with the names of the pipes in the pipeline.
<wilx> But the branches are not the pipeline it seems.
<wilx> I cannot bzr swp in them.
<wilx> While bzr pipes still shows the pipeline pipes in each of the branches.
<wilx> Ideas?
<stefanct> jelmer: first binary package just built successfully by the recipe, thanks again and bye :)
<jelmer> wilx: hi
<jelmer> wilx: no idea, you might want to talk to abentley
<abentley> wilx: you ought to be able to, but I haven't tested it recently.
<wilx> http://codepad.org/AUt0awX5
<wilx> Here is a log of what I have done. The bottom shows the problem.
<abentley> wilx: Right, you need to create a lightweight checkout of branch1 or pipe2.
<wilx> Would that be bzr co --lightweight in the branch1 dir?
<abentley> wilx: co --lightweight $PATH_TO_BRANCH1 anywhere except the branch1 dir.
<wilx> Ah.
<wilx> I see. It works that way.
<wilx> However it makes layout different from the inital pipeline which is surprising.
<abentley> wilx: I mostly use sync-pipeline for pushing to Launchpad, and producing that sort of layout wouldn't work.  Launchpad needs the branches to be separate.
<wilx> I see.
<wilx> Maybe there should be a switch to allow the original repo layout for other destinations/transports.
<abentley> wilx: probably the easiest way to reproduce that layout manually is to colo-init, and then sync-pipeline into colo/.bzr/branches
<abentley> wilx: btw, until recently, the layout produced by reconfigure-pipeline is one I never used.  I would do "bzr init-repo --no-trees branches; bzr init branches/branch1; bzr checkout --lightweight branches/branch1/"
<wilx> I see.
<abentley> wilx: if you're using reconfigure-pipeline, init-repo isn't strictly necessary.  reconfigure-pipeline creates a shared repository.
<jono> hey all
<jelmer> hey jono
<jono> hey jelmer!
<jono> if I have a branch that I want to merge into another one, and the branch I want to merge in has much of the same code structure, but re-factored, is bzr smart enough to find the right code fragment and merge the branch?
<jelmer> jono: the branches aren't related in any other way?
<jono> jelmer, so this is what is happening:
<jono> I have a branch and someone is re-factoring the code
<jono> but moving the code around, changing some of the method names etc
<jono> much of the original code logic is the same
<jono> but I want to write some changes and I am not sure if I should hold off
<wilx> Are your changes conflicting his changes?
<wilx> Then hold off. Otherwise proceed.
<jono> wilx, this is the thing, I don't know - I suspect they won't because he is just moving some code around - the code itself doesnt change
<jono> but as an example if I patch my_func() and the file my_func() is in changes, would the patch still apply?
<jelmer> jono: if you're going to be changing the same code that he is moving around then I would wait
<jono> thanks jelmer
<lifeless> jono: best way to tell: just try merging :)
<lifeless> jono: you can always do your changes on top of his branch, rather than in trunk
<lifeless> jono: or you can do yours in trunk and let him(or her) merge from you before they submit
<thomi> jelmer: I just saw your bug on indicator-jenkins - I didn't think anyone knew about that yet
<thomi> jelmer: the bug's been fixed in trunk, and there's a package building - should be done in 1 hour
 * jelmer hugs thomi 
<jelmer> I don't remember where I learned about indicator-jenkins, but it seemed like a nice thing to try
<thomi> let me know if you have any more problems with it. I'll get it working well then send an email out to the canonical QA lists...
<wilx> jelmer: Hey, thanks for the quick patch for the bzr:// URI mirroring.
<jono> thanks lifeless
<poolie> hi all
<wgz> hey poolie
<jelmer> hi poolie, wgz
#bzr 2012-02-29
<justdave> how does one go about creating a new repo that contains multiple branches on a remove server via bzr+ssh ?
<justdave> bzr branch . bzr+ssh://repo/projectname/branchname <- doesn't seem to work if repo/projectname doesn't already exist
<justdave> s/remove/remote/
<justdave> someone told me there's a command line option for bzr branch that makes it create the directory path if it doesn't exist, but I can't find mention of it in bzr help branch
<lifeless> bzr push is the usual thing to push content
<mgrandi> do you mean creating a shared repo on a server?
<lifeless> push --create-prefix ...
<justdave> mgrandi: yeah, that's what I'm trying to do
<mgrandi> bzr init-repo <linkhere>
<justdave> --create-prefix says no such option, init-repo again complains that the parent directory doesn't exist
<justdave> --create-prefix maybe was added in a newer bzr than I have
 * justdave looks to see what version he's running
<justdave> looks like 2.4.2 on my laptop and 2.3.1 on the server
<lifeless> justdave: bzr push has a --create-prefix
<mgrandi> init does too
<mgrandi> init-repo doesn't look like it does
<lifeless> init-repo wouldn't need it in the example structure
<mgrandi> but you can just create the directory on the server
<lifeless> init-repo  bzr+ssh://repo/projectname
<lifeless> push bzr+ssh://repo/projectname/branchname
<justdave> woot, push worked, thanks
<justdave> I have root access on the server end, but was trying to find a way to let people do that self-serve instead of having to have a sysadmin go create directories for them. :)
<lifeless> naturally :)
<goddard> im trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up
<poolie> hi
<poolie> there are some tutes on http://doc.bazaar.canonical.com/
<poolie> how do you mean 2 branches for a web server?
<mgz> morning all
<jelmer> hey mgz
<mgz> what are you on today jelmer?
<jelmer> mgz: just coffee, mgz, just coffee
<mgz> neat:D
<Pikkachu> tagging logic problem: I have one branch where I pull upstream updates and tag released changesets appropriately, and I have another working base branch which merges these updates from the former branch, but I tag there too as the merges themselves don't inherit the tags
<Pikkachu> I want advice on this because it may be a lot of tagged merges with single commits which are also tagged with the same tag, it's odd. I'm thinking of just dropping the source tags, how about it?
<jelmer> Pikkachu: I'm not sure I follow - merges should bring in tags too
<Pikkachu> jelmer: it does... let me show you
<Pikkachu> jelmer: http://i.imgur.com/s08YA.png
<Pikkachu> I forgot of no repeated tags, so the wonder is if the merge has many commits and I wanted to keep track of the source release...
<Pikkachu> actually the tags aren't the same thing... I like how problems solve themselves in bazaar when you just think logically, I don't care that much whatever embarrassing codebase it may have... thanks all
<jelmer> Pikkachu: sorry, I'm having trouble understanding what you mean.
<jelmer> Pikkachu: emberassing codebase?
<Pikkachu> jelmer: people blame bazaar like it's slow and/or it's a fork of that ugly ancient gnu tool...
<Pikkachu> jelmer: can you get what I mean in the screenshot? the tags referred to upstream releases in the source branch...
<jelmer> Pikkachu: The current bzr codebase shares no code whatsoever with tla, and hasn't for the last 7 years. bzr is also reasonably quick these days, at least with 2.5..
<Pikkachu> ...but the tags in that branch must refer to the upstream release for which it is targeted
<jelmer> Pikkachu: anyway, I don't really understand what you're asking about tags..
<jelmer> Pikkachu: you're merging from an upstream branch that has tags set?
<Pikkachu> jelmer: tla wasnt' the name... I'm telling about others say not me, they love to tell people using git because it's cool, and when it comes to eliminating other options, bazaar is usually that one based on <forgot>, slow and worth a joke (then I'm like @@)
<Pikkachu> jelmer: let's say you have a branch responsible for fetching upstream updates, or it's really an upstream branch and they tag like '2.6.3', '2.7.0' etc for their releases
<Pikkachu> jelmer: then let's say I forked it at 2.6.3 to add a feature and since then there has been a few commits in upstream, then they release a new version tagging with xyz
<jelmer> Pikkachu: ok
<Pikkachu> jelmer: now I want to update my fork and tag it appropriately to point to the respective upstream commits for which they apply (i.e. they'd be immediately subsequent if just applied upstream without forks)...
<Pikkachu> jelmer: then when merging I can't duplicate xyz, I need to remove it from potentially many sub commits and apply on top of merge
<Pikkachu> jelmer: but this way I loose information on the original release (I know a given merge matches some release, but within that merge I don't know which commit is the upstream changeset which was released)
<jelmer> Pikkachu: why do you want to tag the upstream again?
<Pikkachu> jelmer: solution is using different naming schemes...
<Pikkachu> jelmer: in the upstream branch? not again... what I want to tag again is my fork
<jelmer> Pikkachu: Do you want to both have tags for what upstream called a certain release and a tag for the point at which you merged upstream?
<jelmer> Pikkachu: in that case you indeed want two different tags
<Pikkachu> jelmer: mostly, except that the latter is 'at the point a merge is ready to match a release'
<Pikkachu> yeah I'm just thinking of ideas like, say, 'Upstream_1.23' and 'Fork_1.2.3' but these are horrible...
<Pikkachu> I'm thinking of 'P1.2.3' (Patched 1.2.3)
<Pikkachu> I have a commit that was released upstream and I want to tag it with the release. It was the last commit, is it ok to uncommit it just for tagging or should I use an empty commit like "Stick on new release xyz"?
<Pikkachu> hmm nevermind
<wilx> How often is the Launchpad production code updated?
<mgz> wilx: there's a #launchpad as well for such questions
<mgz> but basically they have the machinary to update every day at 10:00GMT, generally it's only some weekdays that they actually need to though
<wilx> Thanks.
<lifeless> mgz: erratta - the time scheduled thing is only for downtime requiring deploys; simple code pushes happen all over the map, and often more than one/day
<mgz> lifeless: thanks
<goddard> im trying to use bzr to maintain 2 branchs for a web server are there any tutorials on how to go about setting this up
<lifeless> goddard: poolie answered you last night; did the answer not help? What sort of additional info would you like ?
<goddard> lifeless: well he gave me a link to the documentation
<goddard> but didn't really understand what i was talking about
<lifeless> yeah
<lifeless> so I don't understand any more than he did; perhaps you can help me do so?
<LarstiQ> goddard: what do the two branches contain?
<goddard> dev site and a live site
<goddard> here is a git example http://joemaller.com/990/a-web-focused-git-workflow/
<goddard> are there bzr type tutorials?
<goddard> i'd like to be able to read about it
<LarstiQ> goddard: I will have to read that article
<LarstiQ> goddard: normally I'd just say: keep your website in a branch and use bzr-upload to deploy
<goddard> LarstiQ: ok
<LarstiQ> but maybe you are trying to do something more involved
<goddard> i dont want to work on this locally
 * LarstiQ reads
<goddard> the enviornment that i would setup would be different from the server
<goddard> so i guess the dev site would push to the live site
<goddard> and i would push to the dev site
<goddard> i think
<goddard> dont know
<LarstiQ> goddard: the workflow from the article seems a bit weird to me
<goddard> if you have a better idea id like to hear it
<LarstiQ> goddard: I guess it may depend on what you want
<LarstiQ> goddard: for my purpose I would hack locally, `bzr upload` to the dev site (can be done automatically on commit) till you're happy
<LarstiQ> then `bzr upload` to the live site with the same revision
<goddard> alright
<LarstiQ> but maybe I don't understand the requirements well enough
<jcsackett> is there a way to change the colorscheme used in "bzr cdiff"?
<LarstiQ> jcsackett: looking at colordiff.py, not at the moment
<jcsackett> LarstiQ: ah, thanks.
<LarstiQ> jcsackett: but it shouldn't be too hard to make it more flexible
<LarstiQ> jcsackett: basically some configuration that sets self.colors
<LarstiQ> jcsackett: the DiffWriter class that is
<poolie> hi all
<jelmer> 'morning poolie
<poolie> hi there, how are things?
<jelmer> alright, how are you?
<rockstar> Where did bzrlib.tests go?
<james_w> python-bzrlib.tests package?
#bzr 2012-03-01
<james_w> what would be the old way of spelling Graph.iter_lefthand_history()?
<lifeless> branch.get_history(0
<AfC> I lament Git.
<poolie> mm
<twb> bzr-fastimport repo used to include darcs-fast-export script.  Now I can't find it.  What happened to it?
<twb> Hmm, seems latest version simply delete all exporters, without telling me where to get replacements
 * twb randomly googles and finds http://hackage.haskell.org/package/darcs-fastconvert
<mgz> morning
<johan> Hi, I'm having an issue uncommiting a set of changes in a branch, using bzr 2.5.0
<johan> bzr: ERROR: An inconsistent delta was supplied involving 'pixmaps/validation-error-16.png', 'pixmapsvalidationerr-20070828004315-ef6og11rrm2qvq9v-234'
<johan> reason: Unable to find block for this record. Was the parent added?
<johan> happens when I try to uncommit
<mgz> johan: similar to bug 910002 maybe?
<ubot5> Launchpad bug 910002 in Bazaar "uncommitting a dir rename causes InconsistentDelta error" [High,Confirmed] https://launchpad.net/bugs/910002
<johan> mgz: yes, seems to be the same issue
<johan> running bzr uncommit again says nothing to commit, but it also complains that the working tree needs to be updated
<johan> I'd really like to be able to check out an earlier version of a branch before that bug is fixed
<mgz> you can just do that
<mgz> `bzr co --lightweight -r -5 ../olderversion` for instance
<johan> ah, let me try that
<mgz> plus the . to indicate from the cwd
<johan> not needed, it worked fine thanks
<hypnocat> bzr is often criticised for being slow compared to git.. is bzr slow because it's written in python?  or because of the algorithms it uses?  or some design decisions?
<mgz> it's mostly historical
<mgz> git was born fast and dumb, bzr evolved differently
<quicksilver> git was designed pretty much first and foremost "how do I maintain linux kernel source trees and fast"
<mgz> so, many core things these days don't have very different performance characteristics
<quicksilver> and since the linux kernel tree is (a) big and (b) had loads of history
<quicksilver> actually having a design that made sense was quite secondary to it being very fast.
<quicksilver> bzr was designed "how do we do DVCS right?"
<johan> no history was imported into the kernel when git was created
<quicksilver> really? I stand corrected.
<mgz> there are still some obvious differences
<johan> they left the old bitkeeper data behind and did a clean break
<mgz> cold startup is worse with python
<hypnocat> would it help if bzr used one of the python compilers instead of the python interpreter?
<mgz> so, your first vcs command after a memory pressure situation will be faster with a small binary rather than lots of pyc files
<mgz> hypnocat: no, in short.
<mgz> long version, bzr already uses cython (and C) for some parts where more C-like performance is needed
<mgz> and the pypy answer to bad performance is "let it run for several seconds so the JIT warms up"
<mgz> which obviously doesn't help much with a multiply invoked commandline tool like bzr
<hypnocat> so, what are the main things that bzr does right compared to git that slow it down so much?
<mgz> I think you missed my first line :)
<hypnocat> that it's historical?
<hypnocat> i got that.. they evolved differently
<hypnocat> and the core stuff has similar performance
<mgz> these days, there aren't big differences in performance on basic opterations
<hypnocat> so where are the big performance differences?
<mgz> I think their network protocol is more reliably performant
<mgz> because there's only one way of doing it, whereas bzr doesn't discourage you from using lots of different protocols, some of which then do silly things
<mgz> feel free to benchmark things though, or look in the list archives for older benchmarks, a few have been done
<hypnocat> alright, thank you
<bsd> Hi jelmer.  Is there any support in bzr-svn (or a bug) to allow stacking against a Subversion repo?  I'm having to work against a very large and old repo, and it will take days (weeks!) to download it allâ¦
<jelmer> hi bsd
<jelmer> bsd: unfortunately stacking across different repository formats is not supported at the moment, and the svn format does not support stacking itself
<bsd> jelmer: so there's little that can be done other than maintaining a parallel branch.  Oh well.
<jelmer> bsd: how big is the branch?
<bsd> jelmer: 142k entries.  But they've pushed in zip files and all sorts of monstrous binaries.
<jelmer> ah
<Omni|Work> How do I find out which branch a tag is on?
<Omni|Work> I do 'bzr tags' and there are a whole ton of tags with a '?' on them.
<wilx> The information is part of the log output.
 * Omni|Work nods.
<poolie> hi all
#bzr 2012-03-02
<Omni|Work> I want to create a 'full clone' of an upstream repository that has a number of branches.
<Omni|Work> I want copies of all of those branches on my local system.
<Omni|Work> Is this possible?
<spiv> Currently, not in a single command.
<spiv> You can of course make a local repository and then branch each upstream branch into it (and there might be plugins that can help you automate that?)
<Omni|Work> How do I do that and ensure that the branches are 'branched into the local repository' rather than each turning into their own standalone repositories?
<wilx> Omni|Work: You branch them into a shared repo.
<Omni|Work> wilx: bzr init-repo something ; cd something ; bzr branch bzr://repo/a-branch
<spiv> Omni|Work: right
<Omni|Work> Interesting.
<mgrandi> what does this error mean? bzr: ERROR: _ssl.c:319: No root certificates specified for verification of other-side certificates.
<spiv> You're trying to connect to an HTTPS server?
<mgrandi> i think, tried to just put a github url as the thing to merge with
<spiv> It means that for some reason the pycurl library (which bzr uses for https) hasn't got any root certificates configured, thus it can't actually verify the authenticity of any server certificates.
<mgrandi> well i'm on a mac, where are these certificates ?
<spiv> I don't know, sorry :(
<goddard> whats a good bzr tutorial for some one with a short attention span?
<mgrandi> the bzr docs? oo
<mgrandi> http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher
<mgrandi> needs the keychain, hmm >.>
<goddard> mgrandi: thats funny
<mgrandi> i mean, if you don't want to read some documentation wehn its pretty simple as that, i dunno what to tell you...
<goddard> mgrandi: i didn't say it was me.
<goddard> :D
<poolie> mgrandi, there's an 'in ten minutes' doc on doc.bazaar.canonical.com
<mgrandi> ah, tell that to goddard =)
<poolie> i mean, goddard
<poolie> :)
<poolie> mgrandi, for you, there's an open bug that bzr doesn't know how to talk to the os x keychain, i think
<poolie> there's a way to disable it
<poolie> which bzr version are you using?
<mgrandi> 2.5b6
<mgrandi> it says to use -Oca.certs=none or something
<mgrandi> which worked
<poolie> mgrandi, ok good
<poolie> i think that's fixed to be off by default in 2.5.0
<mgrandi> using ssl certs?
<poolie> yes on mac os
<poolie> until it's hooked up
<mgrandi> is there an api for the keychain?
<mgrandi> how does any other program look up ssl certs then...
<goddard> does bzr upload let you have a dev and a live upload?
<goddard> or how do you do that?
<poolie> goddard, i think you can just give it different urls to upload to
<poolie> that's probably what i'd do
<poolie> maybe two branches, depending on how much you expect them to vary
<poolie> i would aim for not having too much variation
<goddard> what is the point of branches?
<goddard> i know it is the line of development for a project
<goddard> but what should i use it for?
<mgz> morning all!
<poolie> hi all, and goodbye
<wgz> hm, the bzr beta ppa is dead? maxb was maintaining and hasn't been updated since November
<wgz> what should be suggested in bug 944557 as an alternative?
<ubot5> Launchpad bug 812749 in bzr-builddeb "duplicate for #944557 Misuses bzr 2.4's new set_commit_message hook to disable editor prompting for a commit message entirely" [High,Fix released] https://launchpad.net/bugs/812749
<wgz> ...you're being too clever ubot5, I wanted a link to the dupe
<soren> I'm having trouble with bzr behind a proxy.
<soren> bzr branch lp:reincarnate
<soren> bzr: ERROR: Certificate error: hostname 'proxy-sjc-1.cisco.com' doesn't match either of '*.launchpad.net', 'launchpad.net'
<Daviey> soren: Do they have ssl bump proxy?
<soren> Both $http_proxy and $https_proxy read "http://proxy-sjc-1.cisc.com/"
<soren> Daviey: It works well enough to talk to launchpad in w3m.
<soren> Sorry, that was a lie. Both $http_proxy and $https_proxy read "http://proxy-sjc-1.cisc.com:80/"
<Daviey> soren: right, but are they MITM'ling you?
<soren> Daviey: Not enough to make w3m upset at all.
<soren> wget is also perfectly content fetching things over https.
<soren> So no. They're not.
<Daviey> soren: right, but if *.cisc.com is a valid cert, it won't complain, right?
<soren> Daviey: Then why would bzr?
<Daviey> It seems to me that bzr has stricter checking.
<soren> It really looks like the checknig is backwards.
<soren> It gets bzr branch lp:reincarnate
<soren> bzr: ERROR: Certificate error: hostname 'proxy-sjc-1.cisco.com' doesn't match either of '*.launchpad.net', 'launchpad.net'
<soren> Gah, whoops. Sorry.
<soren> It gets the '*.launchpad.net', 'launchpad.net' from the cert, but compares it to the hostname of the proxy.
<soren> Which seems wrong.
<wgz> soren: file a bug, the urllib2 checking is new and python doesn't help out much, so there are probably issues.
<soren> *sob*
<soren> I guess maybe corkscrew will work for now.
<wgz> soren: it would probably be useful to try with pycurl as well and confirm that that works
<Daviey> soren: try, -Ossl.cert_reqs=none
<soren> Daviey: But I *do* want cert checking :)
<soren> Daviey: But it works.
<Daviey> soren: and you DO want to be MITM'd? :)
<soren> Er.. no.
<soren> I thought we agreed I wasn't being MITM'd?
<Daviey> soren: but yes, it would seem it doesn't take proxy into account.
<Daviey> soren: i didn't agree that..
<Daviey> soren: it's likely you are correct, but they could be doing. http://wiki.squid-cache.org/Features/SslBump
<wgz> soren: try this as a cute workaround:
<wgz> BZR_LP_XMLRPC_URL=http://xmlrpc.launchpad.net/bazaar/
<wgz> nope, wrong value...
<wgz> annoying that there's no way to override the connection method of that
<soren> uite.
<soren> Quite, even.
<wgz> soren: I take it `bzr info https://bazaar.launchpad.net/` also complains about the cert?
<wgz> (just to confirm this isn't xmlrpc specific)
<soren> wgz: Hm.  No.
<soren> $ bzr info https://bazaar.launchpad.net/
<soren> bzr: ERROR: Not a branch: "https://bazaar.launchpad.net/".
<wgz> okay, then it's launchpad plugin specific
<wgz> certainly a bug in our code or a dependancy then
<wgz> please file :)
<soren> wgz: Already did.
<wgz> soren: thanks!
<soren> https://bugs.launchpad.net/bzr/+bug/944696
<ubot5> Ubuntu bug 944696 in Bazaar "When using a proxy to talk https, cert checking validates against proxy host name" [Undecided,New]
<wgz> confirming that your browsers are happy talking to https://xmlrpc.launchpad.net/bazaar/ is probably also a good idea
<soren> wgz: It just says "Your request didn't fit the protocol expected by this server."
<soren> wgz: Which is also does from somewhere else, so that's fine.
<wgz> yup, that's expected.
<wgz> soren: the easy work around for now, provided you can ssh out, is to set your launchpad login so the lookup over http step isn't required
<wgz> otherwise you can use the http url that lp:reincarnate resovles to to avoid the lookup for that particular branch
<soren> wgz: I just added some more info to the bug (with a better stack trace)
<soren> wgz: I can't ssh out, unfortunately.
<wgz> well, `bzr branch http://bazaar.launchpad.net/~soren/reincarnate/trunk/` should work at least
<soren> wgz: Indeed it does.
<wgz> loses much of the convience of lp: urls but generally they get remembered after the first time
<Pikkachu> I want to fork a branch but it's overkill, I just want one file...what should I do?
<Pikkachu> is it possible to create a separate branch which has nothing to do with it for then merging on a per file basis?
<jelmer> Pikkachu: branching is cheap, even for a small change it shouldn't have much overhead
<jelmer> Pikkachu: can you perhaps try to explain what you're trying to do exactly?
<Pikkachu> jelmer: patching purple plugin pack, it' a whole pack but I just need one single file from it
<jelmer> Pikkachu: what is the problem with simply merging that file?
<Pikkachu> jelmer: the problem is a common ancestral to begin with
<Pikkachu> jelmer: I wanted to move irchelper/irchleper.c to the top but it seems to confuse bzr completely, to the point of saying non-sense. I'm gonna try keeping file structure...
<jelmer> Pikkachu: you can force common ancestry by using "bzr merge -r0..-1"
<Pikkachu> (bzr 2.3) bzr: ERROR: No final name for trans_id 'new-4', file-id: None, root trans-id: 'new-0'
<jelmer> Pikkachu: what are you trying to merge into what exactly? I can give it a try with 2.5.
<Pikkachu> the problem is how to being
<Pikkachu> begin
<Pikkachu> I have a branch with lots of stuff
<Pikkachu> I jus want a new branch with only of those files, what to do?
<Pikkachu> I want to merge updates to that secific file later
<jelmer> Pikkachu: I would suggest just writing a script that pulls in the files you need
<nisu> how is nested tree support comming for bzr? It's hard to find comprehensive up-to-date imformation about that
<jelmer> nisu: there are small incremental steps towards nested tree support
<jelmer> with a bit of luck, 2.6 will have nested tree support
<jelmer> I don't think we've published much about it
<jelmer> I should finish off the update to the developer docs document about nested trees...
<nisu> jelmer: sounds good
<nisu> does that include tracking remote repositories of lets say subversion code as nested trees?
<Pikkachu> hm ok jelmer thanks anyway
<fayaz> hi, is there any way i can convert a shared repository into one with no-trees?
<jelmer> nisu: that's a separate topic, although in the case of bzr-svn and bzr-git most of the code to support svn-externals and git submodules is already present (just waiting for the support from bzr core)
<nisu> jelmer: that is not exactly what I meant, I am more interested to know if it will be possible to import a plain svn or git branch using bzr-* into a nested tree of a pure bzr project
<jelmer> nisu: ah, I see
<jelmer> nisu: yes, that would be possible
<nisu> jelmer: nice, can't wait to try it out :)
<Pikkachu> bzr branch pack fork; mv fork/sub/file .; rm -r fork/*; mkdir fork/sub; cp file fork/sub; cd fork; bzr add; bzr commit -m "Pack purge except for file"; bzr tag PURGE; <patches here>; bzr commit -m "my fork"; bzr merge ../pack/sub/file
<Pikkachu> is this workflow ok?
<jelmer> Pikkachu: sure
<Pikkachu> how about making 'fork' --stacked for having it even more lightweight?
<jelmer> Pikkachu: there is a --stacked option to 'bzr branch', if that's what you mean
<Pikkachu> that's what I mean, I would like to stick the branch on exactly where I diverge
<Pikkachu> so when I branch it from LP it's lightweight
<Pikkachu> (I likely won't be any interested in changes prior to the divergence and purge)
<Pikkachu> but I'm a bit afraid after reading the docs...:(
<jelmer> Pikkachu: how do you mean?
<Pikkachu> I'm just afraid of using it, nothing much...
<james_w> if running some code using bzr is exiting and just printing "Killed" to the terminal, what would that indicate?
<mgz> james_w: SIGTERM I'd guess
<james_w> hrm
<mgz> james_w: SIGKILL rather
<james_w> I wonder if celery is getting involved even though I'm not actually going through it in this case
<mgz> I was going to suggest you installed a signal handler, but doesn't help with that case
<james_w> it's pretty hard to branch large branches if you can barely get the revision history from the server prior to whatever timeout is kicking in :-)
<james_w> aha
<james_w> oom killer
<mgz> ehehe
<mgz> an old friend
<abentley> jelmer: the daily builds of pqm for oneiric-lucid are failing.  I can't reproduce the errors locally-- even with no email set, I get a default.
<jelmer> abentley: I think it might be related to the version of bzr
<jelmer> let me see if I can reproduce it here
<goddard> bzr just chokced on me over a file name
<goddard> InvalidEntryName
<jelmer> goddard: what's the file name?
<abentley> jelmer: Yeah, I reverted to the version of bzr specified by the bzr package name, but still couldn't get it.
<jelmer> abentley: it seems to've built fine here
<jelmer> and there is a new build pending
<jelmer> http://people.canonical.com/~jelmer/recipe-status/bzr.html
<abentley> jelmer: unless you've changed those tests, I'd expect the pending builds (except precise) to fail.
<jelmer> abentley: unfortunately I can't see any of the old builds on the daily build page (https://code.launchpad.net/~bzr/+recipe/bzr-pqm-daily)
<abentley> jelmer: No, you can get to them via the PPA package listings, though.
<abentley> jelmer: https://code.launchpad.net/~bzr/+archive/daily/+packages?batch=75&memo=75&start=75
<goddard> this is what it is giving me
<goddard> %\^5C5^5C597A95%?min_videos_edit.tpl.php
<goddard> looks like a cached file to me
<jelmer> goddard: that file seems to contain a backslash, which is a prohibited character
<goddard> that is why i got the error
<lamalex> Does anyone know when the -c flag was added to bzr merge?
<jelmer> lamalex: it's really old - it's been there for as long as I can remember
<lamalex> far out
<lamalex> i wish i knew this ages ago. i thought you had to do bzr merge -r Y..X barnch
<jelmer> there are a few other commands that support -c too
<jelmer> 'bzr diff' and 'bzr log' in particular
<wilx> Hi.
<wilx> Is there any explanation anywhere about the three different merge algorithms?
<wilx> Merge3, LCA, Weave?
<wilx> Never mind, I have found this: http://doc.bazaar.canonical.com/developers/lca-merge.html
<wilx> Hmm, still not enough information about the --weave algorithm.
<wilx> Also, what is the --reprocess switch about? The help text is rather uninformative.
<fullermd> Just try using it.  Then you'll be doubly uninformed.
<wilx> Heh.
<wilx> I want to know what to expect.
<fullermd> There are some fair explications of weave merges out there.  I think --weave is not actually precisely a weave merge anymore, but it's comparable.
<fullermd> If you can dig up some of the talk about "Precise Codeville Merge" from years back, I believe that's essentially a reinvention of weave merges.
<wilx> I see.
<wilx> Isn't LCA what monotone uses?
<fullermd> I think mark-merge is a bit different.  But I was a little hand-wavy on the details when I had it all loaded into my brain, and that was years ago.
<wilx> http://revctrl.org/FrontPage
<wilx> I hate wiki spammers :(
<wilx> They destroy so much useful stuff.
<fullermd> Sadly, that's been abandoned to the spammers for many years now   :|
<smoser> hey all.
<wgz> hey smoser
<smoser> trying to get a dailyb build going
<smoser> and its not being nice
<smoser> http://paste.ubuntu.com/865797/
<smoser> any ideas ?
<wgz> hm.
<wgz> the error message seems pretty clear, but I'm not sure what you want.
<wgz> throw a quick mail to the udd list
<smoser> why would there be a tag for that thing ?
<smoser> that string 'upstream-0.9.4+r4177' is only a creation of this daily build recipe
<wgz> I don't know, I haven't done any of the fancy recipe things
<wgz> jelmer will be able to point you in the right direction, and I'm sure he'll look at email over the weekend :)
<smoser> ewll, i sent email just now, but i think i must have unsubscribed from that list at some point
<smoser> and i just tried re-subscribe but still haven't gotten the conf mail
<smoser> so dont know if my mail will go through
<wgz> it arrived.
<smoser> well, thanks for confirming that.
<wgz> thanks, that's a clear problem report
 * smoser steps away for weekend.
<wgz> part of my issue with builder problems is they tend to get asked on irc, quickly answered by jelmer, then my only recall of them is searching through irc logs :)
<wgz> have a nice weekend!
<Amoz> jelmer, I'm trying to fix the bzr-gtk FTBFS in precise, and xvfb-run -a ./debian/testsuite.sh works well if I run it manually in precise, but fails in pbuilder due to an assertionerror
<Amoz> any pointers of what could be happening here?
#bzr 2012-03-03
<AfC> Hi
<jelmer> Amoz: that issue should be fixed in unstable
<vivekimsit1> Hii, Everyone :)
<vivekimsit1> I am new to bazaar and looking forward to use it for and my projects, But first of all I want that there are some existing projects which I would like to convert into the bazaar repository but when I do bzr init-repo it creates a new repository!
<lifeless> vivekimsit1: hi, that is what init-repo is meant to do. What were you expecting ?
<vivekimsit1> lifeless: init-repo is creating a new dir!
<vivekimsit1> lifeless: but I want that the I have one project folder already and I would like to convert it into the bzr repo
<lifeless> 'bzr init' on its own will bzr-ise an existing directory
<vivekimsit1> lifeless: ok! let me conform, Go to the existing directory run the command bzr init inside it and this will make the parent directory a bazaar repo..! am i right?
<lifeless> yes; you might like to read the manual, it give a guided introduction
<lifeless> vivekimsit1: e.g. http://doc.bazaar.canonical.com/latest/en/user-guide/starting_a_project.html
<vivekimsit1> lifeless:Thanks :)
<vivekimsit1> How can I know how many repositories I have
<vivekimsit1> or how to see the list of all the repos
<wilx> repositories are just directories
<wilx> If you want to bzr'ize a single directory, that means you will want to create a stand alone branch.
<wilx> Just cd ~/mycode and then bzr init .
<wilx> bzr add .
<wilx> bzr commit .
<wilx> Done.
<wilx> I am pretty sure the basics are well enough described in the docs.
<vivekimsit1> Is there any doc related to launchpad?
<wilx> help.launchpad.net
<wilx> ?
<vivekimsit1> ok'
<goddard> can some one explain something to me
<goddard> if I am creating a new branch and then I use bzr-upload
<goddard> it will upload that branch
<goddard> what happens if i create a new branch?
<wilx> goddard: Then you will have two? :)
<wilx> I have never tried bzr-upload.
<wilx> I see, it is pure copy upload.
<wilx> Why don't you use bzr branch/push instead?
<Amoz> jelmer: so that issue is already taken care of? will it be automatically synced to build in LP?
<M-Boy> Hello all
<M-Boy> is there somewhere I can chat with ?
<M-Boy> someone*
<M-Boy> sorry
<jelmer> hi
<M-Boy> for instance; I know the "don't ask to ask" rule but every time I come over and just ask I see all people are dead so am checking first ^^
<M-Boy> Hi jelmer what up ?
<M-Boy> I mean how are you...
<jelmer> alright, how are you?
<jelmer> Amoz: hi
<jelmer> Amoz: let mec heck
<M-Boy> jelmer, I got a straight forward question. I am looking for a "tool" that would replace the linux shell in order to administrate and manage bazaar branches :/
<jelmer> M-Boy: what do you mean with replace the shell, what would you like to do?
<M-Boy> launchpad is a hell therefore I cannot really manage to clone it on my private server, hence I am looking for something else
<M-Boy> jelmer, let's see I have set up a quick dev environement for a team of 3 developers
<M-Boy> we have agreed on a straight forward version control workflow: Local branches map on remote branches + 1 remote branch (so called mainline) for global merges
<M-Boy> the issue is that we keep struggling with permissions...
<M-Boy> I litteraly spent the whole afternoon trying to figure out how to achieve the best organization but each time I keep fighting with folders' permissions
<M-Boy> jelmer, any advice?
<jelmer> M-Boy: what have you set up exactly?
<jelmer> M-Boy: how are you sharing the branches?
 * jelmer back in ~15 min
<M-Boy> jelmer, I am using bzr+ssh
<M-Boy> I simply created /bazaar/project_repositoru/branches...
 * jelmer is back
<jelmer> M-Boy: you might want to adjust the permission mask that's used for those users
<jelmer> so that the group automatically gets write access to new files
<M-Boy> jelmer, so there is nothing that does this for me through a simple user interface for example?
<M-Boy> i only found bazaar explorer and it doesn't
<wilx> Can I remove an entire branch on bzr+ssh:// repo?
<wilx> Remotely.
<M-Boy> nvm
<M-Boy> see ya
<jelmer> wilx: yes, "bzr rmbranch" can do that
<kbulgrien> say I want to have --no-recurse whenever I add a directory.  Is there an easy way to set stuff like that up?
<Kamping_Kaiser> kbulgrien: you can add aliases to ~/.bazaarbazaar.conf
 * kbulgrien reading up on alias
<kbulgrien> bleah. As with other VCS, don't much care for personal alias because it makes you not know how to do things native.
<kbulgrien> If I go somewhere my aliases aren't set up, that is a pain.  I'd rather know how to do it without an alias.
<kbulgrien> (It's also a pain that --no-recurse has no shortcut)
<kbulgrien> Tho I guess its the same if I have to do something else to set up a different default.
<jelmer> kbulgrien: I guess we could add a short option for it, but I think it's generally not used very often
<AfC> jelmer: I'd vote for a short option; --no-recurse is something I use a great deal and yeah, it's a pain to type.
<kbulgrien> Use it heavily ... coming to bzr from other vcs, this is a great pain.
<kbulgrien> It at least needs a short option, IMO.
<jelmer> is this --no-recuse for 'bzr ls', 'bzr add', 'bzr status' or all?
<AfC> jelmer: I personally am describing my use of add
<kbulgrien> Mostly add is where it bugs me the most.
<kbulgrien> but if added, I'd probably vote for consistency.
<jelmer> yeah, I agree if we add it we should add it consistently
<AfC> jelmer: my complaint is that in the case of add (one of your first experiences with bzr,) would be more along the lines that most Unix commands require you to specify ls -R or grep -r to make it recursive.
<AfC> jelmer: but it is what it is
<kbulgrien> AfC: I agree
<jelmer> AfC: I think one of the issues there is also that all other VCS tools seem to be recursive by default
<jelmer> and other bzr commands are recursive by default
<kbulgrien> jelmer: also agree, but short option then.
<AfC> jelmer: {shrug} then bzr has to be. Put another way, bzr was recursive before any of the others :)
<jelmer> bug 945904
<ubot5> Launchpad bug 945904 in Bazaar "-N as alias for --no-recurse" [Medium,Confirmed] https://launchpad.net/bugs/945904
<jelmer> AfC: not before svn (or CVS?)
<AfC> modern 3rd generation DVCSen
<kbulgrien> CVS was recursive, but not for add
<kbulgrien> of directory
<kbulgrien> recursive add of all directory contents is bad imo
<kbulgrien> very bad
<kbulgrien> recursive for anything I'm largely okay with.
<kbulgrien> (else)
<kbulgrien> but to add new stuff recursively to the vcs is a big giant pain more often than not.
<jelmer> why would you have non-versioned and non-ignored files under a VCS directory?
<kbulgrien> many reasons
<AfC> jelmer: it's incremental;
<AfC> jelmer: as you're building a new project
<AfC> jelmer: you add a little bit at a time; and I am constantly surprised that "oops!" it went deep.
<kbulgrien> exactly
<AfC> jelmer: especially when you're being careful trying to add the bits you know you should have under version control
<kbulgrien> now try to vcs your OS
<kbulgrien> bzr add etc
<kbulgrien> oh crap
<AfC> jelmer: the END RESULT is yes, you might have added everything, but that's not a conclusion you immediately come to
<AfC> jelmer: also things like "yes, I should add the log/ directory as an empty stub... ooops, oh crap"
<AfC> anyway
<kbulgrien> AfC: you and I think alike.  yes. stubs is another reason.
<AfC> I doubt you will be able to change the default behaviour, but a short alias would indeed be lovely.
<jelmer> AfC: bug 945904
<ubot5> Launchpad bug 945904 in Bazaar "-N as alias for --no-recurse" [Medium,Confirmed] https://launchpad.net/bugs/945904
<AfC> jelmer: already subscribed :)
<kbulgrien> svn is -N for the same thing
<kbulgrien> not that I think we should copy svn
<kbulgrien> btw, lest it be seen I popped in to complain, I have been looking for new vcs for a long time. bzr is it.
<AfC> kbulgrien: it's a good choice.
<jelmer> ... and branch attached
<jelmer> we just need to wait for a bzr reviewer to approve it now, and it will be in 2.6
<kbulgrien> :-)
<kbulgrien> Am slated to convert my work over sometime in not too distant future.
<kbulgrien> of all the newfangled vcs, bzr is the most natural progression imo. All others have made me work to adopt. bzr just fits like a glove.  A bit uncomfortable, but just what it seems a vcs should be.
<kbulgrien> uncomfortable primarily just like anything new with a lot of stuff in it is uncomfortable, not bad kind of discomfort.
<AfC> kbulgrien: our contribution to getting people going on using bzr with our project was http://java-gnome.sourceforge.net/HACKING.html You might find some useful tidbits there.
<kbulgrien> bookmarked
<kbulgrien> I tried git for a few weeks and borked things up several times while learning and it was hard all the way.  one night I tried to do something I was used to doing in another vcs.  After a long time I found git will not do it.
<kbulgrien> I started reading and found probably hg wouldn't either.
<kbulgrien> I d/l bzr and it was done in 15 minutes.
<kbulgrien> None of the pain of git at all.
<kbulgrien> I had never used distributed vcs before.
<wilx> Hg and Bzr seem largly equal though.
<kbulgrien> treating dirs as explicit versioned resources.
<wilx> I have picked Bazaar over Mercurial mainly because the ecosystem seems stronger.
<kbulgrien> hg didn't used to.  maybe they changed.
<kbulgrien> i didn't even have to look in the manual... what I wanted to do "just worked" when I figured out what to type from built in help.
#bzr 2012-03-04
<kbulgrien> interesting... bzr status sometimes fails to report status if the file happens to not have read perms for the user.
<kbulgrien> ie `bzr add this; bzr status` shows added.
<kbulgrien> `bzr add this; chmod a-r this; bzr status` shows nothing
<kbulgrien> `bzr add this; chmod a-r this; bzr status this` shows status
<kbulgrien> really, there's a good reason I'd like status in this case...
<kbulgrien> but I guess that's kind of wierd.  oh well.
<kbulgrien> hmm. I wonder if that is true for both heavy and light checkouts.  I'm in a light checkout.
<kbulgrien> hmm. something happened.  maybe I was crosseyed.  It's now showing status.
<kbulgrien> I was crosseyed.
<kbulgrien> hum. somehow I have made things so bzr status hangs.
<kbulgrien> strace is unhelpful
<kbulgrien> I guess I am hosed.  I don't know how to fix.
<kbulgrien> bzr check shows nothing bad.
<kbulgrien> afaict, only bzr status is messed.
<kbulgrien> And as long as I put in explicit file names, bzr status is ok, just not `bzr status` or it hangs solid.
<kbulgrien> appears that 2.5.0 has the problem fixed.\
<kbulgrien> for that matter 2.4.2 is fixed.
<kbulgrien> head is hurting.  having hard time figuring out what I did wrong.  set up repo, init an area under it, checked out somewhere else. added, committed, but can't see anything going into the repo.
<kbulgrien> Anyone want to help.  Shared repo tutorial isnt very tutorial
<stlsaint> i changed my default python now bzr has stopped working
<bob2> what did you change it to
<bob2> kbulgrien, it's unclear what you did
<bob2> pastebin shell history?
<kbulgrien> well, shell history is so scattered, not sure pastebin will help here.
<kbulgrien> I guess I could pastebin a reconstruction
<kbulgrien> I don't know how to set up a new "lockstep" project.
<kbulgrien> I've obviously done it wrong because there is nothing going into the shared repo
<kbulgrien> I can't push or pull
<kbulgrien> It says there's nothing.
<kbulgrien> the shared repo data shows the revision that is in my checkout, but all the goods are in the checkout and won't go up into the repo
<bob2> I think you're just confused about trees vs branches
<kbulgrien> I come from cvs background
<bob2> condolences
<kbulgrien> it works
<kbulgrien> no need to feel sorry
<bob2> anyway, it's still not clear what you're saying, to me
<bob2> do you mean "I made a repo, with init-repo --no-trees, then did 'bzr init' in some dir, then added and commited some files, then pushed to the repo, but the 'branch' dir, in the repo, is empty?"?
<kbulgrien> bzr init-repo --no-trees top; bzr init-repo --no-trees top/mid; bzr init top/mid/bot;
<kbulgrien> somewhere else I did bzr checkout --lightweight top/mid/bot .
<kbulgrien> I probably should not have done --lightweight
<kbulgrien> I did adds and commits in the checkout.
<bob2> why did you make two nested repositories?
<bob2> and is the problem you're asking about that 'top/mid/bot' doesn't have all your files in it?
<kbulgrien> I thought I was making a repository for multiple projects
<bob2> not sure what you mean
<bob2> but you don't need (or want) to nest repos
<bob2> just init a branch somewhere inside the repository
<kbulgrien> yes, there are no files in top/mid/bot
<bob2> that's what no-trees means
<bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
<kbulgrien> then why do docs say to use no-trees for centralized server repos
<bob2> because it's a good idea
<bob2> since 'bzr push' doesn't update checked out files
<kbulgrien> what is a centralized server if it has no data
<bob2> and newbies get immensely confused by that
<bob2> :-/
<bob2> it has /all the revision data/
<bob2> 15:36:28 < bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
<kbulgrien> The commit comments don't do me any good without the data
<bob2> you're confused
<bob2> all the data is there
<bob2> there is just no checked out copies of the working tree
<bob2> that's what --no-trees does - not check out the files
<kbulgrien> I am looking at the file system.
<kbulgrien> there is no data
<kbulgrien> only meta data
<bob2> false, fortunately
<bob2> one last time: all the revision data is in the .bzr dir of the /repository/ (ie in the root), the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself
<kbulgrien>  du
<kbulgrien> 1.0K	./.bzr/branch-lock
<kbulgrien> 1.0K	./.bzr/branch/lock
<kbulgrien> 5.0K	./.bzr/branch
<kbulgrien> 9.0K	./.bzr
<kbulgrien> 10K	.
<bob2> this is all unrelated to whether there is a workign tree or not
<kbulgrien> I committed more than 10k
<bob2> please read what I said
<bob2> that's the contents of top/mid/bot/.bzr
<bob2> "the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself"
<bob2> "all the revision data is in the .bzr dir of the /repository/ (ie in the root)" -> du -sh top/mid/.bzr
<kbulgrien> ok
<kbulgrien> I see that
<kbulgrien> I think
<kbulgrien> yes. I see a repository folder that has packs and stuff.
<bob2> bzr has branches (mutable pointers to a revision), repositories (big piles of revision data) and working trees (your checked out files, with enough info to be able to get pristine copies)
<bob2> ^ important model information
<kbulgrien> well, I can see what youre saying, but setting up a repository to me isn't nearly so clear as for cvs.
<kbulgrien> I don't know that I've done what I wanted to do.
<bob2> I'd start over
<bob2> cd /srv/bzr ; bzr init-repo --no-trees something
<bob2> mkdir something/projectname/branchname
<bob2> cd !$
<bob2> bzr init
<kbulgrien> you do nothing at the projectname level?
<bob2> cd ~/something
<bob2> bzr checkout /srv/bzr/something/projectname/branchname projectname
<bob2> cd projectname
<bob2> bzr add .... ; bzr commit -m'first commit111'
<bob2> correct
<kbulgrien> ok
<bob2> ^ so it's just a matter of: make a repo (one time thing), make a branch in it (per-branch thing), check it out somewhere and then use it
<kbulgrien> ok, thanks for your patience.
<bob2> progress?
<kbulgrien> well, I'm doing something a bit unconventional, so the setup is a little more complex than that.
<bob2> unconventional how?
<kbulgrien> perms and stuff
<kbulgrien> I'm trying to version control changes I make to an OS.
<bob2> do you mean /etc
<kbulgrien> yeah, but sparsely
<kbulgrien> I only track what I mess with.
<bob2> I'd not bother and instead use etckeeper
<kbulgrien> I'll look it up.  Part of the thing is that I need/want to learn bzr so I can transition workk over.
<kbulgrien> I'm not really using it to preserve etc, but to preserve the knowledge of what I have to tweak to do what I want to do.
<kbulgrien> I'm not really backing up etc per se.
<kbulgrien> ah, its a frontend to bzr...
<kbulgrien> to do this in cvs I wrote my own front end
<bob2> (and git and hg)
<kbulgrien> ok
<kbulgrien> well, then it bears looking at for sure.
<kbulgrien> I already had to make a wrapper script for files I had to sudo to get access to.
<kbulgrien> but it was way simpler than what I had to do for cvs
<kbulgrien> cool
<kbulgrien> okay, managed to even keep the history in the checkout
<kbulgrien> and then I checked out somewhere else and got the goods.
<kbulgrien> I was able to push the original checkout into the remade repository.
<kbulgrien> now the data is under "top/.bzr""
<kbulgrien> well even if I should have used etckeeper for this, it gave me a real world problem to solve that forced some learning.
<kbulgrien> in the process, I found that 2.3.1 (mageia) had a bug with respect to no read perms in the checkout.
<sbarcteam> hi.
<sbarcteam> Let's assume I have a repository at rev. N
<sbarcteam> I have a checkout branch (with bound=True)
<sbarcteam> at location B at the same revision.
<sbarcteam> (the 1st repo is at location A)
<sbarcteam> now, I am doing changes in B, and do a normal commit (not the one with --local)
<sbarcteam> and before that commmit I do some changes in A
<sbarcteam> and do not commit them.
<sbarcteam> so, I have 1) dirty working dir, 2) updates on the way already in the repo history
<sbarcteam> I want to merge both the update and the dirty working dir.
<sbarcteam> what is the right (bzr) way to do this ?
<sbarcteam> I thought I could commit the dirty work dir, but bzr doesn't allow.
<lifeless> you can commit --local, or you can just update.
<lifeless> I would just update.
<sbarcteam> #lifeless: so, If I commit --local and then
<sbarcteam> there's importance to not
<lifeless> or you could shelve the work, and then update and then unshelve
<sbarcteam> shelving is not a good idea.
<sbarcteam> It is a running django code.
<sbarcteam> So I want to commit the work running, and merge it off-line, test it and only then to deploy the merged code.
<sbarcteam> What would happen if I uncommit on the location B.
<sbarcteam> then commit on A,
<lifeless> you can use merge --uncommitted to grab the uncommitted work.
<sbarcteam> then update on B
<sbarcteam> and remerge.
<lifeless> that work work too
<sbarcteam> OK.
<sbarcteam> So: on B (the checkout branch) uncommit the last merge, then on A: commit changes, then on B: update, and merge.
<sbarcteam> right ?
<sbarcteam> (and then I'd have to update A of course)
<lifeless> yes
<wilx> Can bzr sign-my-commits not use keychain/gpg-agent?
<hno> Is it possible to "unmerge" a merge in such way that it do not get expunged from the originating branch if it later pulls/merges changes?
<wilx> I do not understand the question entirely. However, it is possible to uncommit the last commit.
<maxb> hno: Only if you can uncommit the merge commit, or arrange for the originating branch to (merge; revert .) the unmerging commit
<hno> maxb, ok, not quite what I am looking for.
<hno> It's very unlikely it's the last commit. May be many versions back, and development in the branch may have continued after merge.
<hno> I guess what I am really looking for is kind of a large distributed bzr-loom with loose threading.
#bzr 2013-02-25
<idnar> anyone know what would cause the error seen at https://buildbot.twistedmatrix.com/builders/debian-easy-no-zope-py2.6-epoll/builds/186/steps/bzr-svn/logs/stdio ?
<idnar> the branch in question is an SVN branch via bzr-svn
<jelmer> hi idnar
<jelmer> idnar: so, it looks like for some reason the revspec is trying to get a write lock while the branch is read-only locked
<idnar> hi jelmer
<jelmer> idnar: actually, it seems like this is being triggered by ghosts
<jelmer> so the revspec (before:) is trying to use some revision data that is not present in the svn branch
<jelmer> it tries to fetch that data into the branch, but that is not possible because the branch is read-only locked
<idnar> okay, I was thinking something along those lines but wasn't familiar with the internals
<idnar> should I file a bug report against...bzr-svn, I guess?
<jelmer> idnar: I think this is a bug in bzr itself, in the before: revspec
<jelmer> idnar: it just happens to be triggered by bzr-svn, or this particular situation
<idnar> okay, I filed https://bugs.launchpad.net/bzr/+bug/1132932
<ubot5> Launchpad bug 1132932 in Bazaar "before: revspec trying to write to branch with read-only lock" [Undecided,New]
<jelmer> thanks idnar
<jelmer> idnar: it should be possible to work around the issue by simply forcing a write lock in bzr log
<idnar> apparently it's been worked around by using a different revspec that accomplishes the same thing
<bamvac> I'm getting error "No module named xml.parsers.expat" when trying to `bzr init-repo ProjectX`
<bamvac> `zypper in expat` was successful, but problem persists
<jelmer> bamvac: sounds like you are missing an xml library
<jelmer> bamvac: how did you install bzr?
<bamvac> I built the OS with suseStudio using a JeOS base image. I'm rebuilding another using the Server base now.
<bamvac> jelmer: do you suggest I include bzr with the selected software, or install it after configuring the OS?
<spiv> bamvac: that module is part of the standard python installation IIRC
<spiv> bamvac: so I guess make sure that your OS build includes that part of Python (for simplicity, I'd just make sure it has the whole Python standard library; it's not very large)
<bamvac> spiv: Including python-xml package solved my issue.
#bzr 2013-02-27
<jelmer> hi bzrers
<fullermd> Sounds like you've got a mouth full of marbles.
<mariusko> Hi
<mariusko> Why do I need to resolve a conflict multiple times when doing multiple merges?
<mariusko> In git, I just do it once
<mariusko> http://bazaar.launchpad.net/~mariusko/charms/precise/node-app/trunk
<mariusko> Revision #34 was also resolved
<mariusko> I mean lost
<spiv> mariusko: because rev 36 removed that file and added a new file with the same name
<spiv> mariusko: even though it's the same name bzr considers it to be a completely different file.  This property (files having an identity separate to their name) works great for merging changes involving file renames
<spiv> mariusko: but it's not so good in this sort of case
<spiv> It might be nice if bzr merge had a --ignore-file-id option or something to do merging git-style, but I can imagine all sorts of nasty edge cases that would need careful thought.
#bzr 2013-02-28
<LeoNerd> Huh.. I didn't know Martin Pool now works at Google.
<LeoNerd> I should say hi :)
<jelmer> LeoNerd: you're at Google too?
<mgz> it's a black hole...
<mgz> endlessly sucking
<jelmer> mgz!
<mgz> jemler!
<mgz> ...tyop!
<LeoNerd> Yah
<fullermd> It's not the sucking that gets you, it's the tides.
<jelmer> fullermd: perhaps tis teh typsos ? :P
<jelmer> LeoNerd: same here, based in the UK
<LeoNerd> Oh.. huh... I should come say hi then. Me too
<jelmer> I'm jelmer@
<mgz> this is where you both turn around and go, "there you are"?
<fullermd> That's why google keeps 'em chained to their desks; not enough slack to turn around.
<vila> Oh, there you are ? :)
<jelmer> LeoNerd: we're in shouting distance of each other :)
<mariusko> spiv: thx for looking. What really happened was not even a rename, but a simple conflict resolution (that happened bad (maybe similar to add/add in git))
<mariusko> spiv: I still haven't got it to understand that it is the same file in revision 38: http://bazaar.launchpad.net/~mariusko/charms/precise/node-app/trunk/changes
<mariusko> Probably would worked better then if one of the feature branch was based on the other
<vila> mariusko: Having both branches share history will certainly avoid the file-id conflicts
<vila> mariusko: you won't be able to make bzr understand that two file-ids are really the same file, but you can teach it to chose which one you want to track
<vila> hmpf, X server crash.., lovely
<fullermd> ex-server crash?   :p
<mgz> the X server is now an ex-X server?
<fullermd> It's not crashed, it's resting.
<fullermd> Of course, if he shut it down now, it would be an ex ex X server, and he could make a few bucks off it.
<vila> let's see
<jelmer> haha
<vila> Sorry, the program "Xorg" closed unexpectedly
<vila> Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers.
<fullermd> See what happens when you run emacs?
<vila> hehehe
<CcxCZ_> hello, I've done git-import on a repo and now I have empty directory with just .bzr. bzr branches report some branches but I don't know how to get to them
<xnox> bzr checkout .
<xnox> CcxCZ_: ^
<xnox> note the '.'
<CcxCZ_> I don't want the default branch though
<LarstiQ> CcxCZ_: does git-import give you colocated branches, i.e., bzr checkout co:branch ?
<LarstiQ> where branch is the branchname
<CcxCZ_> possibly, it used to use directory per branch
<CcxCZ_> how do I address colocated branches?
<jelmer> CcxCZ_: git-import shouldn't create colocated branches by default. did you use --colocated?
<jelmer> (or are you perhaps using an older version that does?)
<ccxCZ> not sure about version tbh
<jelmer> ccxCZ: does 'bzr branches' list a number of branches?
<jelmer> if so, then you are probably using a set of colocated branches
<jelmer> it's probably better to avoid that, since the UI support for colocated branches is still fairly limited
<ccxCZ> ok. I guess it would be best to upgrade and re-import then
 * ccxCZ resolved it in raw git in the meantime
<vila> jelmer: bzr branch https://code.google.com/p/selenium trunk
<vila> bzr: ERROR: exceptions.KeyError: '2fabdeb9fad1cf7e41c129b65dc98f94cd711ba3'
<jelmer> vila: that's a known issue, though there isn't an obvious fix IIRC
<vila> jelmer: is there some hope to get that working or is that a known and... hehe, great answer as expected ;)
<vila> jelmer: the repo seems to have been svn -> git migrated IIUC
<jelmer> vila: that shouldn't matter, there are issues with bzr-git branching from google code IIRC
<jelmer> https://bugs.launchpad.net/bzr-git/+bug/878085 looks possibly relevant
<ubot5> Launchpad bug 878085 in Launchpad itself "NoSuchRevision error during git import" [High,Triaged]
<vila> jelmer: oh, you mean that if I start with a local 'git clone' I will then be able to 'bzr branch' ?
<jelmer> vila: actually, that might indeed work
 * vila tries
<vila> err
 * vila try ?
<jelmer> "vila tries" is correct, I think
<vila> jelmer: thanks ;)
<mgz> vila is very trying
<spiv> mgz: don't be trite ;)
<mgz> :D
<vila> spiv: hey !
<vila> mgz, spiv : Can I have subtitles ? (not http://www.youtube.com/watch?v=R3Yi-t2w_gI) ;)
<vila> jelmer: it worked
<vila> jelmer: so that's a bug between remote and local access right ?
<jelmer> vila: yeah
<mgz> vila: it's an old joke of the sort teachers might make, on the meaning of "trying" as difficult or annoying :)
<mgz> teacher - Why aren't you getting on with your work? pupil - I'm trying! teacher - Yes, you're very trying.
<vila> mgz: Oh, I think I get it ;) And "trite" is because it sort of rhymes ?
<mgz> it's also 'try-' sounding yes
<fullermd> It's enough to make you cry.
<jelmer> fullermd is missing on out a wonderful career as a poet..
<fullermd> I like to think of it as the rest of the world missing out on my wonderful career as a poet.
<fullermd> I'm not entirely sure I'll get universal agreement on that point though.
<jelmer> I think you would in particular do well as a "Sinterklaasgedichten"-poet, but I'm not sure how to explain that concept to somebody who is not Dutch.
<fullermd> Well, I know what "sinter" means when you apply it to metal.  Sounds fitting to me   ;p
<fullermd> I prefer to work in more dignified forms.  Like, the other year as part of some mailing list thread, I wound up having to write a sonnet.  About bologna.
<fullermd> The reception wasn't entirely what one might hope for, sadly.  Obviously my compatriots had NO taste.
<jelmer> basically, if Santa (Sinterklaas) gives you a gift in the Netherlands he tends to accompany the gift with some sub-par poetry
<jelmer> ... in some way relating to you or your naughty activities over the last 12 months
<jelmer> fullermd: ah, tough crowd?
<fullermd> My genius is constantly underappreciated, sadly.  I'm pretty sure it's a global conspiracy.
<mgz> we appreciate it, just not too much, or you'd get big-headed
<SunilJoshi> Hi, i am using bzr to get the source code for bugzilla under windows, now i have installed ubuntu and want that i can use the same checked out code while using bzr from ubuntu, can i do this?
<fullermd> OK, so, yeah, qlog gets cranky pulling up a 300-some meg diff.
#bzr 2013-03-01
<lifeless> fullermd: not surprising
<fullermd> Well, it was over 5 gig when I killed it.  That seems a LITTLE excessive.
<fullermd> Rebase seems awful difficult to figure out...
<fullermd> Ah, apparently that's 'cuz I want replay instead, which which 'help rewrite' doesn't even mention.
<jelmer> fullermd: yeah, replay is experimental (and hidden for that reason). don't use it.
<fullermd> Well, it's what I _need_.
<fullermd> And it seems to have worked.
<KombuchaKip> Would anyone perchance be able to help me with a d-bus issue? I know it's off topic, but since there are Bzr developers in hear familiar with d-bus, I thought I would give it a shot having nearly given up on the XDG mailing list.
<thumper> sorry, I know nothing about dbus... very little anyway
 * KombuchaKip nods at thumper
<DarkLinkXXXX> Anyone active here at this ungodly hour?
<mgz> you mean around noon? yeah. :)
<lifeless> An atheist might observe that every hour is ungodly, since there is no god...
<LeoNerd> But no moreso than any other hour
<pindonga> hi, does anyone know why this is happening when importing a branch from github? http://launchpadlibrarian.net/132585831/django-core-django-master.log
<jelmer> hi pindonga
<mgz> pindonga: bug 1084403
<ubot5> bug 1084403 in bzr-git (Ubuntu) "no support for gpgsig tags" [High,Triaged] https://launchpad.net/bugs/1084403
<jelmer> mgz beat me to it :)
<mgz> fastest bug search in the west :)
<pindonga> jelmer: mgz thx!
<pindonga> any way to work around this until the bug is fixed?
<jelmer> pindonga: remove that tag from the repository, or create a clone of the repository with that tag removed and import that
<jelmer> pindonga: alternatively, use git-fastexport/bzr-fastimport
<pindonga> jelmer, ack, thx... will see what I do
<DarkLinkXXXX> Hello.
<mgz> hey
<DarkLinkXXXX> With launchpad, what is the process for "forking" a project?
<mgz> there isn't anything you need to do on the website, you get a branch you're interested in, then push your changes back up under a new location
<DarkLinkXXXX> Okay.
<mgz> see https://help.launchpad.net/Code
<DarkLinkXXXX> Okay. I think I'm having trouble with launchpad ssh verification with the gui on windows.
<DarkLinkXXXX> I'm doing just fine with the cli though.
<DarkLinkXXXX> Nevermind. I believe I fixed it.
<mgz> DarkLinkXXXX: are you using p... good good :)
<DarkLinkXXXX> Yeah. Just had to set a global variable.
<DarkLinkXXXX> What does it mean exactly that a branch has no working tree?
<mgz> DarkLinkXXXX: read <http://doc.bazaar.canonical.com/beta/en/user-guide/core_concepts.html>
<DarkLinkXXXX> Thanks.
<DarkLinkXXXX> I suppose I should skim the manual before asking simple questions. ^_^
<mgz> genenerally it means you're trying to do something that requires the files to work (like a merge), on a remote branch that won't have them (push doesn't create files on disk, just the vcs bits)
<DarkLinkXXXX> Not sure if this bug or not, but pasting lp branch with a space causes problems without manual correction
<mgz> don't do that then :)
<DarkLinkXXXX> True.
<DarkLinkXXXX> But the problem was confusing at first.
<mgz> explorer (which I guess you're using?) could be nice and strip whitespace for you
<DarkLinkXXXX> Yeah.
<DarkLinkXXXX> I'm just saying that'd be nice.
 * DarkLinkXXXX may try to see if he can implement that himself, if he knows the language
<mgz> yeah, it would be reasonably easy for you to submit a fix for if you know some python
 * DarkLinkXXXX knows some, fortunately.
<DarkLinkXXXX> So I guess first I'll see the branch for the version I'm using, then check out the latest branch to see if this was alerady implemented.
<DarkLinkXXXX> Of course, the hard part is always finding the code where such functionality is deermined.
<mgz> DarkLinkXXXX: possibly lp:qbzr lib/branch.py though that only tackles the one dialogue
<DarkLinkXXXX> Hmm.
<mgz> you'd probably want a fancy get_location helper that would take a text widget and pull out a sane path or url from it
<mgz> then other places could use it too
<DarkLinkXXXX> I was looking in lp:bzr-explorer/1.1. Wrong place?
<mgz> nope, it just uses qbzr quite heavily
<DarkLinkXXXX> Ah. Okay.
<mgz> so, some dialogues are from there
<mgz> you may also want some changes in lp:bzr-explorer
<DarkLinkXXXX> I already have my version of that.
<DarkLinkXXXX> I thought I'd compare my version and the latest versioin to see if anything has happned along the lines of what I wanted.
<mgz> yeah, that's sensible
 * DarkLinkXXXX prepares to read throught oodles of documentation, as he's never used pyqt.
<mgz> it's mostly sensible and ignorable
<mgz> and you shouldn't need to do anything complex with it
<DarkLinkXXXX> Yeah.
<DarkLinkXXXX> Is there a standard function to get text from textboxes? Someting I could search for?
<mgz> the one gotcha I'll mention now is you get a unicode-like object back as the string from qt widgets, but cast to unicode() works fine
<mgz> currentText() seems to be it, going by qbzr lib/branch.py l142
<DarkLinkXXXX> Thanks.
<DarkLinkXXXX> strlen is a function right?
<SunilJoshi> Hi, i was using bzr with windows 7 and checkout some code, now i hv installed ubuntu (i.e. Dual boot) and i use the same checkout code from ubuntu using bzr
<DarkLinkXXXX> Nevermind. I wanna try to figure this.
<SunilJoshi> can i use the same checkout code from ubuntu using bzr?
<mgz> SunilJoshi: generally you don't want to do that with a dvcs
<mgz> having lots of branches is cheap, as is syncronising them
<mgz> just have a location that both your windows and nix boxes have access to (eg, your launchpad account),
<mgz> and get in the habit of committing and pushing when you've finished doing a change, and pulling before starting a new one (and using feature branches)
<SunilJoshi> mgz: ok
<mgz> (you can access your ntfs partition from under ubuntu, but you probably don't want to be writing to it with bzr from nix)
<DarkLinkXXXX> mgz, Does this change seem sensible to you?
<DarkLinkXXXX> if from_location.endswith(" "):
<DarkLinkXXXX> 		from_location = from_location[:-1]
<mgz> DarkLinkXXXX: I'd look at unicode.strip instead, remember you can just run python and do help() on things
<DarkLinkXXXX> True.
<DarkLinkXXXX> mgz, Seems to work in my experiments. Now how do I suggest the change? I'm used to a git workflow.
<mgz> DarkLinkXXXX: I suggest you look at writing a test first
<DarkLinkXXXX> ?
<mgz> probably the easiest way of doing that is putting the helper in qbzr lib/util.py then writing unit tests for thaat function in lib/tests/test_util.py
<DarkLinkXXXX> I don't understand. Doesn't that function already have a test?
<spiv> DarkLinkXXXX: you're adding new functionality, though, so that implies a new test
<mgz> particularly, what does your function do for inputs like "repo/branch name" as well as the case you care about
<DarkLinkXXXX> Oh. Okay.
<mgz> don't worry, it's quite easy and I'll help :)
<DarkLinkXXXX> Okay.
<DarkLinkXXXX> But first, how do I create my own branch?
<DarkLinkXXXX> Do I need to create a new project for that?
<mgz> what version of bzr are you using?
<DarkLinkXXXX> 2.5.1
<DarkLinkXXXX> These are simple questions, I know. ^_^
<mgz> okay, just go up one level, then do `bzr branch trunk strip_location` where trunk is whatever you've got the existing branch named and strip_location is whatever you want to call this feature branch
<DarkLinkXXXX> That's simple enough.
<mgz> there are ways and means of using git-style branches all in one place and switching between, but using seperate directories always works
<DarkLinkXXXX> Okay.
<DarkLinkXXXX> Here's the new branch with all it's glory. https://code.launchpad.net/~darklinkxxxx/qbzr/edit
<DarkLinkXXXX> So should I just suggest a merge via standard email?
<DarkLinkXXXX> Nevermind. I see a propose for merging option.
#bzr 2013-03-02
<DarkLinkXXXX> Is there a guide for using an ssh server as a bzr repository?
<lifeless> DarkLinkXXXX: just the server setup docs
<DarkLinkXXXX> This may be an unrelated problem, but I'm getting this error
<DarkLinkXXXX> C:\Users\[CENSORED]\C>bzr push bzr+ssh://[CENSORED]@everettlug.info/home/[CENSORED]/C
<DarkLinkXXXX> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<DarkLinkXXXX> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectiv
<DarkLinkXXXX> ity and permissions, and report a bug if problems persist.
<lifeless> DarkLinkXXXX: suggests you don't have an ssh server there, or bzr isn't installed there, or your credentials don't work.
<DarkLinkXXXX> If I have no public key there, shouldn't it ask for password?
#bzr 2014-02-24
<mbruzek> Hello #bzr, how does one merge diverged-branches?
<mbruzek> bzr help diverged-branches has been run.
<LeoNerd> bzr merge OTHER_URL   surely?
<mbruzek> I ran "bzr merge", and it told me there was nothing to do.  How do I get the other URL?
<LeoNerd> Mmm>
<LeoNerd> It's.. the URL of the other side; wherever it has diverged from
<mbruzek> OK thank you LeoNerd I was missing the OTHER_URL
<mbruzek> I had to follow it with a bzr commit -m "Resolving divergent-branches"
<mbruzek> And that seemed to have worked.
<LeoNerd> :)
#bzr 2014-02-25
<zamN> hey can someone help me out? I'm getting a ImportError: No module named operator when I try to run 'bzr'
<zamN> google isnt helping today
<fullermd_> google says it's part of the standard library, so that suggests something squirreled up in your python install.
<fullermd_> Try a "python -c 'import operator'", frex.
<zamN> yeah my python install is messed up :\
<zamN> just realizing that now heh
<zamN> i mean the python command works fine
<zamN> just not sure where these modules are located
<zamN> since theres /usr/lib /usr/local/lib etc
<fullermd_> Well, you shouldn't have to.  That's python's job   :)
<zamN> it failed :x
<zamN> ./configure && make && make install
<zamN> is all i did
<fullermd_> Your system didn't already have a package python installed?
<zamN> it did
<zamN> and then i needed another python version for other beautiful things
<zamN> because, why would anyone ever use the latest
<zamN> and of course theres always 10 versions of python in production at once
<fullermd_> You sure they didn't step on each other?
<zamN> they probably did
<zamN> i just dont know how to fix this
<zamN> as if you couldn't tell, i dont use python
<fullermd_> I couldn't, 'cuz I don't either  :p
<zamN> lol
#bzr 2014-02-26
<tnzk> hi, I'm learning how bzr merges branches now. I undestand bzr uses the algorithm called LCA Merge today.
<tnzk> but what does it differ from Recursive Three-way Merge? It seems very similar to me.
<tnzk> I mean the recursive three-way merge of Git.
<fullermd_> Actually, I think the default is still plain 3-way merge, with LCA and weave as alternate options.
<fullermd_> Vague memory says that the 'lca' variant uses per-file LCA's rather than full-tree?  But I wouldn't put much stock in my memory.
<fullermd_> I don't think bzr does git-ish recursive-3-way.  At least not without a plugin I've never heard of.
<tnzk> Oh I just read literally bzr wiki says that it *could* be the default...
<tnzk> Am I right to think bzr uses plain 3-way merge by default, and with options it can merge by 'lca' which is more accurate than 'recursive' strategy of git.
<fullermd_> "more accurate" is a bottomless pit of discussion   ;p
<tnzk> indeed :p okay, I'll keep on learning. thank you.
<fullermd_> Once upon a time, there were decent descriptions/discussions/etc on the revctrl wiki.
<fullermd_> It was drowned in spam and them tossed away some years back, but there might be an archive somewhere.
<quicksilver> I think bzr missing displays the wrong message.
<quicksilver> bzr missing --theirs-only -r1234 bzr+ssh:/path/to/remove
<quicksilver> displays
<quicksilver> Other branch is up to date.
<quicksilver> actually surely it means *this* branch is up to date. "My branch" as the command line options call it.
<quicksilver> oh there we go
<quicksilver> https://bugs.launchpad.net/bzr/+bug/250296
<ubot5> Ubuntu bug 250296 in Bazaar "bzr missing gives confusing 'up to date' message" [Low,Confirmed]
<quicksilver> reported 2008 :(
<tnzk> @fullermd: I've never heard about revctl wiki but it looks very valuable in the internet archive
<tnzk> @fullermd: I wish I was then interested in this topic...
#bzr 2014-02-27
<CcxCZ> when bzr mv --auto screws up, how do I undo it's guesses?
<mgz> CcxCZ: you can just bzr mv things back
<CcxCZ> $ bzr mv --after doc/index.rst.old doc/spec.rst
<mgz> or, if you can recreate the same tree state, revert and try again
<CcxCZ> bzr: ERROR: Could not rename index.rst.old => spec.rst: doc/doc/index.rst.old is not versioned.
<CcxCZ> bleh
<mgz> the .old bits aren't versioned, if you want that copy, just mv it back over the copy you don't want
<CcxCZ> the files are all right. only bzr metadata is messed up
<CcxCZ> I do want to keep the files exactly as I have them. they have been moved around in a fashion bzr can't guess. I want it to forget about all moves and let me bzr mv --after the files to tell it how it really is
<CcxCZ> ie. allow me to modify the id=>filename internal map
<CcxCZ> have I made myself clear enough? do you understand my issue?
<mgz> sure, but I don't see why you were mving a .old file then
<mgz> you just move all the moved versioned files
<mgz> `bzr st` tells you what's been moved where, you can `bzr mv --after` everything so no moved have occured (or to how you want it)
<CcxCZ> what happened with files was: index.rst -> index.rst.old; spec.rst -> index.rst  what bzr mv --auto guessed was: doc/spec.rst => doc/index.rst.old
<mgz> and what does `bzr st` report for those currently?
<CcxCZ> note that it's ancient bzr version on this box, might be a bug. but I seem not to be able to move it back
<CcxCZ> renamed:
<CcxCZ>   doc/spec.rst => doc/index.rst.old
<mgz> okay, well the easiest thing if that's not playing ball
<mgz> is copy the changed files, `bzr revert`, copy them back, and do your `bzr mv --after` changes
<CcxCZ> well I guess I can rsync --exclude=/.bzr it elsewhere, just thought there has to be a better way
<mgz> the mv is the better way, if it's failing you need the less handy way
<CcxCZ> backed up, reverted, restored, manually mv --after'd
<CcxCZ> I guess I'll blame not being able to bzr mv stuff on old bzr version
<Derailed> hey everyone -- I know next to nothing about bzr. but I'm tasked with fixing a shell script that's doing some bzr stuff and is misbehaving. I wonder if someone can help me debug it?
<CcxCZ> we can try :)
<Derailed> sorry -- had to run away for a minute. just a sec, lemme find a pastebin
<Derailed> here's the snippet: http://pastebin.com/UHJVrJJH
<Derailed> the logic is trying to be dumb simple: "I want a certain branch of my project in the directory 'launchpad', if it's not there, get it, if it is there, update it.
<Derailed> the '$1' is a version number like 1.4, 1.5 etc
<Derailed> the first part -- the 'checkout' doesn't actually seem to populate the 'working directory' (I only know git jargon sorry) and I have no idea why
<Derailed> it's ubuntu 12.04, so bzr 2.5
<Derailed> this is obviously very much a newbie question, but any help would be deeply appreciated
<thumper> o/ Derailed
<Derailed> hi thumper :-)
<thumper> Derailed: I missed the start of the problem, whazzup?
<Derailed> I will repost:
<Derailed> <Derailed> sorry -- had to run away for a minute. just a sec, lemme find a pastebin
<Derailed> <Derailed> here's the snippet: http://pastebin.com/UHJVrJJH
<Derailed> <Derailed> the logic is trying to be dumb simple: "I want a certain branch of my project in the directory 'launchpad', if it's not there, get it, if it is there, update it.
<Derailed> <Derailed> the '$1' is a version number like 1.4, 1.5 etc
<Derailed> very sorry -- I have to run away for 10 minutes, I will be back!
<thumper> kk
<thumper> Derailed: I'd change the logic slightly...
<thumper> Derailed: initially use "branch" instead of "checkout", as this will get you the current copy from LP
<thumper> Derailed: second bit should be "bzr pull", not switch
<thumper> this will just bring the latest from launchpad into your local repo
<CcxCZ> Derailed: is this posix sh? if not [[ might be more appropriate than [ and also quote properly any parameter expansion (such as $1) unless you target only zsh with parameter wordsplitting turned off
<Derailed> hiya, sorryh about running away -- I'm back now
<Derailed> thumper, so 'branch' will create the directory and populate it with the branch I ask for -- will 'pull' switch branches for me? the script is run in a for-loop, it does 1.4 then 1.5 then 1.6 etc, switching branches every time
<thumper> no, pull doesn't switch
<thumper> what does bzr info -v show in your repo?
<Derailed> thumper, http://pastebin.com/8StJRYkg
<thumper> Derailed: ok, what you have there is a checkout of a remote branch
<thumper> something that is very inefficient to deal with
<Derailed> that's the "checkout of branch" thing?
<thumper> yes
<thumper> the benefit is that when you commit locally, you are also committing remotely
<thumper> the slow part is that when you commit locally, you are committing remotely
<Derailed> this is an automated script that pulls the translation files for the branch, and builds docs with them. it never commits.
<thumper> ok
<thumper> in which case that should be ok
<thumper> switch will not pull in new changes
<thumper> you need to switch, then 'bzr update'
<Derailed> okay so the first one should be 'branch', and the second one should be 'switch' and then 'update'?
<thumper> Derailed: hang on
<thumper> you have multiple sources, but just one target
<thumper> multiple lp branches, but just one local launchpad directory
<thumper> is that what you want?
<Derailed> yes
 * thumper thinks
<Derailed> thumper, the whole script for context: http://pastebin.com/1bx1abtt
<Derailed> I've no doubt it was written by someone who expected git-like behaviour
<Derailed> and never tested the first part of that if statement, because the repository was already there
<thumper> I have a cunning plan
<thumper> to make it simpler :)
<thumper> although it messes things up a bit
<Derailed> sure. this is all a distraction from what I was SUPPOSED to be doing -- which was just making sure the mahara manual built correctly with the new version of sphinx. I just noticed this part was broken
<thumper> actually
<thumper> all you need to do to make it work is add "&& bzr update" just after the bzr switch ... --force
<thumper> prior to the cd ..
<thumper> ...
<thumper> actually, I think that perhaps it should work as is
<thumper> what isn't it doing?
<Derailed> the first version that is supposed to be built is 1.4, when the script runs for the first time (when launchpad isn't there) a bzr operation happens and launchpad/ is created, but it's empty
<Derailed> and I don't know why
<Derailed> root@precise64:/var/lib/sitedata/mahara-manual-sphinx# bash generate-mo-files.sh 1.4
<Derailed> Starting import of translations...
<Derailed> Checking out the launchpad .po files
<Derailed> You have not informed bzr of your Launchpad ID, and you must do this to
<Derailed> write to Launchpad or access private data.  See "bzr help launchpad-login".
<Derailed> Branched 0 revisions.
<Derailed> ls: cannot access launchpad/potfiles/: No such file or directory
<thumper> echo out the actual bzr command
<thumper> I think you'll find that it isn't substituting the $1
<Derailed> Checking out the launchpad .po files
<Derailed> + bzr checkout 'lp:~mahara-lang/mahara-manual/1.4_STABLE-export' launchpad
<thumper> huh
 * Derailed starts to wonder if there's even anything IN that branch
<thumper> Derailed: the reason there are no revisions
<thumper> is because the branch on LP is empty
<thumper> it has no revisions to give you
<Derailed> ha!
<Derailed> ffs
<Derailed> you know what that means?
<thumper> yes, it means the branch was initialized
<thumper> but never had any revisions pushed to it
<Derailed> unless I'm wrong, then that means that the mahara 1.4 manual has been being translated with whatever was left over in that directory from the last time the script was run, every time
<Derailed> whoopsies
<thumper> also marked as abandoned
<Derailed> that'
 * Derailed is bemused
<mgrandi> since people are here
<mgrandi> anyone know where the bzr windows release guide is? like how to compile it?
<mgrandi> maybe Jelmer knows?
<Derailed> thumper, in that case. do you believe the script is still doing the right thing for branches 1.5+?
<thumper> Derailed: yes
<Derailed> okay thanks.
<thumper> mgrandi: no, but jam may well, he is UTC+4 I believe
<Derailed> I gotta run away now. doing too many things at once, but thanks a lot for helping clear up this little mystery. now all I have to do is work out where http://manual.mahara.org/de/1.4/ is getting its german from if it isn't from the 1.4 branch :-)
<Derailed> but that can be a 'later' problem
<mgrandi> bah, keep missing people cause im not in europe =P
<fullermd_> I prefer to think of it as "people keep missing me"   :p
<mgrandi> =P
<mgrandi> maybe ill just stop being lazy and search my email for it, i remember it being talked about
<mgrandi> doesn't help that bazaar seems to have like..2.5 websites
#bzr 2014-02-28
<jelmer> Derailed, mgrandi: I have no idea about the Windows builds. vila and mgz have both done them in the past, I think?
<mgz> there are instructions in doc/developers
<mgz> it still something of a pain, even if you've got access to a pre-set up ec2 machine and have done it beforethough
#bzr 2014-03-01
<thewrath> just wondering because right now i am the only person working on this if other people would join and don  ot have a LP account is there a way ic an have a central bzr server that everyone puts into and then i  push it to lp myself? kind of having like having two repositories?
<thewrath> like having a local and remote copy of everything
#bzr 2014-03-02
<Naveen> while getting the code using 'bzr branch lp:gtg trunk' command, I'm getting an error
<Naveen> bzr: ERROR: Connection error: while sending CONNECT xmlrpc.launchpad.net:443: [Errno 110] Connection timed out
<Naveen> Does anyone has any solution?
#bzr 2015-02-27
<CcxCZ> how do I revert one specific commit from history?
<CcxCZ> diff and patch (bzrtools) seems to do it, though I'd expect convenience command
<mgz> CcxCZ: see the bzr-rewrite plugin
<CcxCZ> kthnx, will look into it next time
<Peng> You can do something clever with bzr merge.
<Peng> bzr merge -r 4..3
#bzr 2015-02-28
<thrope> hi - I saw loggerhead trunk last commit was 2 years ago, and only 1 commit since september 2012: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/changes/
<thrope> is the project dead or am I looking in the wrong place? (I know the repo moved around before on launchpad)
<thrope> if dead - is there any supported alternative for simple web hosting of bazaar branches?
<fullermd> I have no actual knowledge one way or another on any of it.  But I wouldn't be shocked to discover nobody was doing much of anything on such outside of LP itself.
<thrope> fullermd: ok thanks
#bzr 2016-03-01
<josharenson> I merged a branch and committed (revision #3). The merge was bad, so I reverted to revision 2 and committed. Now I'm at revision #4 and I can't attempt the merge again as bzr says "Nothing to do." How can I fix this?
<fullermd_> You didn't want to revert to 2, you wanted to rewind to 2.
<fullermd_> If that's actually all you've done (there are no other changes in the middle you care about), you can just go ahead and rewind now.
<josharenson> fullermd_: I tried what is listed here https://answers.launchpad.net/bzr/+question/45980 but now I have 51 conflicts
<fullermd_> I'd normally use pull.
<fullermd_> (assuming again you really are talking about 2/3/4, and there's nothing between 3 and 4 you need to keep), `bzr pull -r2 --overwrite .` and then do the merge.
 * josharenson tries that
<fullermd_> Uncommit I always have to look up details and do scratch experiments with, for anything but the simple "pop last" usecase.
<fullermd_> You want to make it like 3 never happened.  Revert just changes the file contents.
<josharenson> fullermd: I think that did exactly what I wanted, thanks
<josharenson> There are only 20 conflicts now :-)  (which is what there was before, and why the merge went badly)
<fullermd> If things go poorly resolving them, you can always just 'revert' (with no args) before you commit it to try again clean.
#bzr 2017-03-03
<LeoNerd> Not directly a bzr topic, but I'm not sure where else is good to ask: On Launchpad, on the "blueprints" list - is it possible to adjust the fields displayed? I want to show the target milestone for each, so I can see what is and isn't assigned.
