#bzr 2008-08-18
<lifeless> back online in a bit
<jml> lifeless: so, the work I've done on testresources is broken up into three branches, but I think it'll be easier for both of us if you just review the final branch.
<jml> lifeless: https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup/+merge/767
<nteon> does anyone know where the 'branch stacking' feature of 1.6 is documented?  I'm trying to figure out what it is
<bob2> nteon: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches
<nteon> bob2: ah, thanks!  google was not helpful for me in this situation
<markh> heh - so I entered a bug report with my ISP for the proxy yesterday, and they just rang me to arrange to put my account on a proxy bypass :)
<rextilleon> anyone here
<jml> yes.
<rextilleon> whats up
<rextilleon> quiet around here
<rextilleon> jml, is there a directory site that gives you a master list of irc locations
<jml> beuno: is there a nice URL for viewing the latest revision of a file in loggerhead?
<xshelf> Is there anyway to handle symbolic links on windows in bzr? Like, creating a hardlink if NTFS or creating a copy of the pointed file as fall back and prevent any operations to be committed into bzr on such files
<xshelf> I have read this article: http://bazaar-vcs.org/WindowsSymlinkSupport?highlight=(symlinks)
<markh> xshelf: not that I'm aware of - but bzr shouldn't break IIUC - only things that try to follow the links will :)
<xshelf> I have a perforce folder tracked by bzr on gnu/linux, I wanted to clone it on wxp. It had a few symlink files and it failed
<xshelf> I did the following: I did a 'p4 sync' on gnu/linux, 'bzr init' followed by 'bzr add' and 'bzr commit'. I copied the .bzr folder to wxp and did a 'bzr revert'
<xshelf> i just read, mercurial handles symlinks on system with no support to symlink!
<lifeless> xshelf: there is a plugin for bzr to do this
<beuno> jml, you can use :head for the last revision
<beuno> not sure about the path
<beuno> (ue, not use the fileid)
<xshelf> lifeless: which plugin is that, I need it please
<lifeless> its called win32symlinks or something; its on the plugins page
<xshelf> will look into it
<arjenAU> lifeless: around?
<lifeless> vaguely
<arjenAU> lifeless: wa just trying to install the bzr-hg plugin and failing miserably
<arjenAU> using the prescribed info
<arjenAU> fastimport installs fine
<xshelf> arjenAU: are you trying to import hg to bzr?
<arjenAU> yea. for a gsoc project of a student of mine that needs to be public tonight
<arjenAU> the hg repo is not public
<xshelf> one dirty way: hg to svn
<xshelf> svn to bzr
<xshelf> or use tailor
<lifeless> arjenAU: for one-shot conversions just use fastimport
<arjenAU> lifeless: just did. works. the point was, I couldn't get your gizmo to even install.
<arjenAU> which is probably my python incompetence, however fastimport did work
<lifeless> arjenAU: bzr-hg is not complete at all
<lifeless> arjenAU: but I do appreciate the feedback
<arjenAU> hmm so fastimport makes me a master subdir... hmm
<arjenAU> all is well, not just trying to understand launchpad for the rest
<arjenAU> lifeless: ok. no worries!
<arjenAU> lifeless: https://code.launchpad.net/sql-obfuscator whatever it says there, how to fix?
<lifeless> FF is restarting for me
<lifeless> I dunno what it says :)
<arjenAU> I think I found it, needed to re-edit the project info. just checking now if that did it.
<arjenAU> the branch (trunck) was not yetnoted as the dev focus for the project
<arjenAU> A branch has not yet been specified as the primary development focus for SQL Obfuscator (set).
<arjenAU> still says.... hmm
<lifeless> click on set
<arjenAU> hmm had to work out how the format worked in the set .... does it look ok now?
<lifeless> dunno ;)
<lifeless> let mepeek
<lifeless> arjenAU: looks fine to me
<robsta> hi
<robsta> does `merge --pull' recognise whether the branches are in sync, except for the pulled changes?
<arjenAU> lifeless: ye. once done once it's perfectly sensible. and it's oh so functional. was just trying to do this in a hurry while actually needing to do other stuff. tnx for your elp
<arjenAU> +h
<lifeless> robsta: it looks at the graph, not the content
<robsta> graph == "chain of revision numbers", for noobs?
<lifeless> directed acyclic graph of UUID
<lifeless> which we show as a chain of numbers :)
<robsta> the thing is, i'd only managed to "merge --pull" the other branch once, so i didn't have to commit myself
<lifeless> merge --pull is a 'fast forward' in git terms
<lifeless> if that helps
<robsta> definitely not :P
<lifeless> :)
<robsta> does a pulling merge fall back to normal merge automatically when the branches are not in sync?
<lifeless> its for when two people are 'sharing' a branch but they each have separate copies and no shared writable space
<lifeless> yes
<robsta> and there is no way to force pulling merge?
<lifeless> pull --force?
<lifeless> merge --pull is 'merge if you can't pull'
<lifeless> got to go
<robsta> thx, looks like that's what i want
<robsta> to have the other author show up in the commit log
<robsta> oh, there's commit --author too
<xshelf> the win32symlinks plugin works, great!
<EarthLion> hey, i have a directory under control. I then copied these files manually and started working on the files in their new directory. I want to place this under control but keep all the history of the revisions. I realise i should of started a new branch and then done a checkout. Is there anyway I can do this now?
<bob2> what do you mean by "these files"?
<awilkins> EarthLion_: Did you copy the folder recursively?
<EarthLion_> yep
<awilkins> Then it's already a bzr branch :-)
<awilkins> Do a bzr info in it and see if you got the .bzr control dir
<EarthLion_> ok (scratches head)
<awilkins> Well, only if you copied the whole tree from the root
<thumper> if I have shared repo with no trees, and I want to check out a branch from within the shared repo, how can I specify the hardlink location?
<thumper> so I have a working tree called trunk
<thumper> and a branch called foo
<thumper> in branch foo I do a `bzr co --hardlink ???`
<thumper> how do I specify trunk as the hardlink source?
<lifeless> thumper: you can't today
<lifeless> thumper: unless you have a checkout of trunk
<lifeless> thumper: in which case just cp -al it and then switch :P
<EarthLion_> awilkins: so dispite doing a recursive copy (it must of been because the directories are many levels deep, and the website still functions perfectly) but the .bazaar directory isn't there. a bzr info tells me that it isn't a branch
<EarthLion_> so is there a way to just commit a directory to an existing branch?
<lifeless> EarthLion_: make a new branch, copy the directory into the branch
<EarthLion_> fair enough
<EarthLion_> lifeless: and just replace/overwrite existing files?
<siretart> beuno: FYI, I've uploaded a bzrtools 1.6.0 package for hardy to my PPA. it is based on jelmer's package for debian/experimental.
<ignas> hi, where do I find out what was added to 1.6rc3 compared to 1.6rc2?
<dato> the NEWS file does not say?
<ignas> found it, thanks
<ignas> do you know if anyone is going to fix the memory consumption problems in 1.6 series?
<mwhudson_> which particular problems?
<ignas> bzr upgrade
<mwhudson> in any case, i don't think anything more is going to be fixed in 1.6
<ignas> ouch :/
<mwhudson> 1.7 is only about 3 weeks away tho
<ignas> i guess I should start warning all of my colleagues to ignore the "your repository is too old, bzr upgrade it" warning
<beuno> siretart, great! I'll copy over to the bzr PPA.  Thanks  :)
<ignas> because that eats 1.5 Gb of ram quite reliably
<mwhudson> ignas: :(
<mwhudson> ignas: can you branch into a new repository instead?
<mwhudson> at least you can probably do that in stages if you have to...
<ignas> emm, that would be very painful
<ignas> I would have to redo the central repository setup again
<ignas> on a remote machine
<ignas> and then hope that launchpad mirrors keep working, and no one commits to anything while i am switching
<ignas> not even talking about the 20 branches in the shared repository on my machine :/
<ignas> mwhudson: what kinds of manipulations are you performing with the code to explode from 70mb repository on disk into more than 1.5 Gb in memory
<ignas> ?
<ignas> well, 140mb repository
<mwhudson> ignas: i don't know, and am not a bzr developer either :)
<ignas> hmm, I wonder if python gives memory allocation information when profiling
<ignas> bzr branch from my shared repository to the outside is taking 7 minutes already
<ignas> mwhudson: ouch, I can't branch using 1.6rc3 too
<ignas> at least not without running out of ram
<fullermd> Well, to be sure, I wouldn't so much expect (branch into new format) to have memory usage or performance much different from (upgrade to new format)...
 * ignas is thinking that migrating to git might be faster than waiting for 3 weeks to be able to create new branches :/
<ignas> I wonder how will launchpad migrate my branches to the new format... maybe branching from a remote repository will work out better ...
<mwhudson> ignas: you can probably bzr pull -r 100
<mwhudson> then bzr pull -r 200
<mwhudson> etc
<ignas> up to 6000?
<mwhudson> ignas: is there a bug on lp?
<ignas> ok 4000
<ignas> for upgrade - yes
<mwhudson> ignas: maybe you can do 1000 at a time, or write a script ...
<ignas> and make everyone who has a schooltool checkout do that... :/
<ignas> that will be as painful as migrating from svn to bzr was...
<fullermd> You'll understand the reasoning next week, when Canonical starts selling RAM   ;)
<mwhudson> ignas: or rebranch, i guess
<luks> haha
<ignas> mwhudson: we have a distributed team, most of the developers are part time, and will be working only in a week, or in two weeks, and I don't even know what are update schedules of deployed instances, making everyone do "something" or *not* do "something" is a bit tricky ...
<mwhudson> ignas: well, you _can_ pull from packs to knits and so on
<mwhudson> ignas: anyway, i hope a fix is found soon, i am off to bed
<ignas> good night
<lifeless> ignas: disk compression is very good
<lifeless> ignas: the memory usage is a bug, its the sum of the plain texts, I suspect
<lifeless> ignas: but it shouldn't do that unless its cross-format
<ignas> lifeless: cross-format?
<lifeless> ignas: please file a bug about this, get someone here to mark it critical
<lifeless> I need to go sleep right now
<lifeless> ignas: 1.6 is nearly released, to please file the bug asap
<ignas> lifeless: ok
<dato> poor jam
<ignas> https://bugs.launchpad.net/bzr/+bug/256757 is there already
<ubottu> Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Undecided,New]
<ignas> I can update it with new information
<ignas> as soon as I'll be done bzr branching from a remote repository
<ignas> I know that local branching is not working, so I want to see whether I can at least create new branches from my server
<fullermd> Yeah, do stick repo size and revision coutn and all that yada yada on it.
 * fullermd critical-bumps it.
<ignas> ok, will do that
<ignas> fullermd: how do I get revision count?
<dato> bzr info should say afaik
<fullermd> info -v lists it, under the 'Repository' heading.
<fullermd> (total revisions in the repo, rather than the number of revs in a branch)
<ignas> fullermd: posted full bzr info -v of one of the "main" branches in that shared repository
<xshelf> quit
<balor> Is there a way to recursively inventory a directory and see if I've forgotten to add some files a-la-tla's [U] flag for unknown files?
<vila> hi all
<vila> Can someone remind me why diffs from bzr viz are colored under Linux but not under windows ?
<vila> I'm pretty sure it's some python package but can't remember which nor find one...
<Toranin> whee, left bzr-svn svn-import running all weekend...looks like only another day or two for it to actually finish :p
<Toranin> copying revision 58473/81533
<luks> hm, lots of revisions
<Toranin> yeah
<Toranin> it's (a) large project with (I think) 5 or 6 years' history, and (b) contains a bunch of 'content translation' commits in the last year or two from our i18n infrastructure.  Ideally I'd like to see the translations moved to a separate repository, but right now I'm just doing basic feasability testing
<fullermd> vila: gtksourceview?
<vila> fullermd: the name rings a bell ! thanks
<vila> fullermd: yup, that's the one
<aantn> I'm trying to upgrade a repository to format 6
<aantn> do I need to do anything other than run bzr upgrade --development && bzr push?
<aantn> err, sorry; there should also be a bzr commit --unchanged in there
<aantn> is that correct?
<fullermd> push won't update the format at the far side.
<fullermd> You have to do an upgrade there (or give upgrade the URL, though remote upgrade'ing is likely to be really slow unless you're really close)
<Necoro> aantn: and make sure the remote update won't fail (esp. if you are using LP) ^^
<Necoro> I haven't found a way of restoring the repository (except deleting and repushing the branch)
<luks> why do you want to use a development format, though?
<aantn> luks: I'm actually not certain that I do
<luks> so what do you want to do? :)
<aantn> luks: is format r the development version or is that default?
<aantn> *format 6
<luks> I don't know, there is no "repository format 6" as far as I know
<aantn> luks: sorry, branch format 6
<luks> that's the default
<aantn> thanks
<aantn> I misunderstood that
<luks> and if you want to upgrade a remote branch, you need to run either bzr upgrade sftp://... or run it remotely on the server
<aantn> luks: is there any way to run an upgrade on launchpad without doing it remotely?
<luks> no :(
<luks> sftp is the only way
<Necoro> bzr upgrade bzr+ssh://... works too
<luks> bzr+ssh doesn't work, it was implemented only in 1.6 and it still not more efficient than sftp
<Necoro> ;)
<aantn> luks: do you mind giving an example upgrade command for launchpad
<Necoro> ok - I used 1.6
<aantn> I'd like to make sure that I don't mangle this up
<luks> Necoro: the server needs 1.6
<luks> aantn: what's the branch you want to upgrade?
<aantn> https://code.launchpad.net/~universal-applets-core/universal-applets/trunk
<Necoro> aantn: make sure you have a local branch ready in case it fails ;)
<aantn> Necoro: will do
<luks> bzr upgrade sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/
<luks> or insert your username before the hostname, if you don't have it configures in .ssh/config
<luks> *configured
<aantn> luks: thanks; I'll try that in a few minutes
<Necoro> luks: but ... I used bzr+ssh ... and at least it started ... it later failed - but with a message that does not read like "we don't support upgrading via bzr+ssh"
<Necoro> "bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data." was the error message to be specific
<luks> Necoro: you did not specify the format
<luks> and you can't convert rich-root formats into the default formats
<Necoro> the old format there was dirstate-tags
<luks> I think it was 'rich-root' :)
<Necoro> luks: http://rafb.net/p/rRkVlp50.html
<Necoro> thats the output of "bzr info" from before upgrading
<luks> dirstate-with-subtree then, even worst
<luks> *worse
<Necoro> oh ... I should improve my reading skills ;)
<Necoro> but - this format hell is not really easy to understand ;)
<luks> yeah
<Necoro> for example - I don't know where there is the difference between pack-0.92, rich-root and rich-root-pack
<Necoro> and which one to use for my repositories
<luks> with that specific branch you can upgrade only to --pack-0.92-subtree
<luks> --dirstate-tags, --rich-root and --dirstate-with-subtree are basically the same format, but with different handling of "tree root"
<luks> same for --pack-0.92, --rich-root-pack and --pack-0.92-subtree
<luks> the subtree variants were never 'officially supported'
<Necoro> hmm - I guess I used this on LP, because it is a converted svn repo
<luks> yeah, bzr-svn used to need the subtree formats
<luks> the rich-root formats were added basically only for bzr-svn
<luks> to avoid the subtree ones
<Necoro> hmm - ok ... so it is not necessarily a good idea to have nearly all my repositories (even these ones which are created directly in bzr and never saw any subversion) in rich-root-pack
<luks> AFAIK, the plan was to make a rich-root variant the default
<fullermd> AFAIK, it still is.  That should land in 1.2 or so...
<luks> but I guess they are still not the default, because it's much slower to upgrade the default formats to them
<luks> it needs to rewrite a lot of data
<luks> can't see any other reason do to not do it
<fullermd> Last I heard, it was still blocked on the upgrade not actually doing everything right.
<luks> oh, and that, yes
<luks> but that was fixed in 1.5, no?
<fullermd> BTFOOM.
<Necoro> hmm - and by "rich-root", it is meant to have a repos A - and inside it another repos B? - or something different?
<fullermd> abentley was working on it, and I thought he still had another bump when he got busy with other stuff.
<robsta> hi
<robsta> i'm trying to interoperate between gnome's svn and bzr-playground
<robsta> rumor has it that the newest bzr has lots of svn fixes, but i can't install from the ppa
<robsta> this is on hardy, looks like deps are missing
<LarstiQ> can't install bzr, or can't install bzr-svn?
<robsta> added deb http://ppa.launchpad.net/bzr/ubuntu hardy main to sources.list, but it won't let me update
<robsta> when i try with hardy's 1.3 it says SvnRepository and KnitRepository are incompatible
<robsta> or "not implemented" when i try to "push --overwrite" to gnome-svn
<luks> robsta: the latest version will tell you the same thing, because it's not compatible
<luks> well, that's different
<luks> but push --overwrite is almost a good idea
<luks> what are you trying to do?
<robsta> push my bzr-playground branch to gnome svn
<luks> damn, "almost NEVER a good idea"
<robsta> ooooh
<luks> the svn branch has probably diverged since then
<robsta> it said it had, but actually trunk/ was empty
<robsta> not i "svn import" ed the source tree and try to "push --overwrite"
<robsta> no2 i "svn import" ed the source tree and try to "push --overwrite"
<robsta> *now
<robsta> so the state of svn is irrelevant, the project was born on bzr-playground
<luks> oh, it never existed in svn before?
<robsta> no
<luks> and the trunk/ in svn is already created, right?
<robsta> yes
<luks> so it thinks it's a different branch
<luks> I'm not sure what's the best fix
<Jc2k> robsta: hi again
<robsta> well, now it has the latest source, because it tried to import it with svn, and the overwrite with bzr
<Jc2k> robsta: i'm afraid we need bkor or jelmer to do this
<luks> push --overwrite to svn can't work
<Jc2k> robsta: i have a link for you
<luks> I'd personally use "bzr replay" to copy the branch
<luks> but there is probably a better way
<robsta> Jc2k: are you the guy that gave us bzr-playground?
<Jc2k> robsta: not quite, i spawned bzr-mirror and then canonical people spawned the playground
<luks> )but of course that would screw up revision numbers in the original bzr branch)
<Jc2k> robsta: http://uwstopia.nl/blog/2008/06/importing-bazaar-branches-into-gnome-svn
<luks> oh, a trick with moving the trunk
<Jc2k> thats what jelmer came up with
<robsta> Jc2k: thx, and anyway, bzr-playground rocks :)
<Jc2k> yes, they did a sweet job
<robsta> svn rm'ing trunk doesn't work because of the maintainer hook
<Jc2k> robsta: thats why we need bkor
<Jc2k> (or jelmer, who threatened to write a python script that was immune to that hook)
<robsta> ah, hah
<robsta> Jc2k: ok, no hurry
<robsta> it's just i don't know if people are happy when i'm starting to release tarballs of a playground-only module
<Jc2k> robsta: you are just being to nice
<Jc2k> *too
<Jc2k> afaik, telepathy isnt on svn.gnome.org for example
<robsta> hmm
<robsta> by the way, is there any chance that bzr will interoperate with git repose some day?
<Jc2k> jelmer is working on it
<robsta> oh rock
<Jc2k> indeed
<Necoro> hmm ... there is the need for one common format of storing repository information ;) ... and then just having git, bzr, hg, svn etc. as frontends -- so everyone can use what they prefer ;P
<LeoNerd> Er.. no, becasue that misses the entire point
<robsta> Jc2k: so there /is/ a light at the end of the tunnel for DVCS :P
<Necoro> LeoNerd: ok
<LeoNerd> The different systems store diffrent data, in different models, with different capabilities. No one system would cover them all
<fullermd> Good idea.  But it doesn't go far enough.  We also need one common format of command interface too, for easy interoperability.
<fullermd> Then git and bzr and hg and svn can just be different...  uh...
<Jc2k> oh dear, meta-dvcs talk is never good
<Jc2k> robsta: i dont see light, really. if bzr talks git, then git wins anyway
<Jc2k> robsta: which i dont call light at the end of the tunnel
<robsta> Jc2k: honestly, i don't care who wins
<Jc2k> robsta: i have phases, but the bzr team consistently impresses me and think its a better long term choice
<robsta> yeah, but git has such an incredible head start
<fullermd> You think that's bad, look at the head start CVS has.
<pickscrape> Not in terms of usability it doesn't...
<LeoNerd> No, git just has better marketing.. I.e. kernel uses it
<LarstiQ> robsta: head start on what? Market share?
<robsta> market share in number of projects
<robsta> (and that is guesse)
<LarstiQ> robsta: right
<pickscrape> What worries me about git is that it is very much focused on "What the kernel devs need"
<LeoNerd> Ya.. it's highly tuned to one specific use case.. It doesn't work too well outside of that
<luks> but but... it's so fast!
<pickscrape> Diminishing returns though.
<LeoNerd> luks: "The wrong answer quickly is still wrong"
<pickscrape> Plus, I found that the speed advantage of git was more than eaten up by the time taken to refer to the man pages and googling for help every 2 minutes :)
<LarstiQ> lots of people are happy with it though.
<Necoro> hmm - btw: the GHC folks - they wanted to leave darcs behind ... does anyone know where they ended (or whether they already found an end at all)
<luks> no program is ever going to fit all use cases
<luks> Necoro: I think they decided to go with git, and now they argue if it was such a good idea
<LeoNerd> luks: Exactly my point above, on the "no we don't want one VCS"
<Necoro> luks: hmm ... if they at least had chosen hg ^^
 * luks is not going into hg vs git debate :)
<Necoro> luks: the only point, why I would have preferred it is: "at least hg is not git" ;P
<luks> there is nothing wrong with git, er... wait
 * LarstiQ doesn't think this is particulary constructive.
<Necoro> LarstiQ: who wanted to be constructive?
<Necoro> ;P
<Necoro> perhaps it needs another bzr-hosting-service ... LP is a lil' bit too ubuntu-centric imho
<luks> almost any webhosting can host bzr
<LeoNerd> I've never quite seen the point...
<luks> I don't see a problem there
<LeoNerd> Any ol' webserver will do
<Necoro> luks: webhosting with SSH access ... because pushing via FTP is annoying
<Necoro> and this isn't the cheapest thing to get ;) (if you don't own one already)
<LeoNerd> Why is FTP pushing worse than sftp/bzr+ssh ?
<Necoro> always typing a password is annoying
<Necoro> and no: I'm not saving the pwd as part of the push-branch-address
<LeoNerd> Ahright....
<cody-somerville> LeoNerd, bzr+shh makes use of the smart server
<gour> Necoro: still git (for GHC) without any other alternative really concerned. i sent some msg to ml and two days ago started some discussion on #ghc 'cause someone noticed that git's workflow is not all in all. unfortunately, #bzr was quite sleepy and there was nobody to explain how looms can replace need for git's rebase :-(
<Necoro> gour: oh =|
<hsn_> i have checkout and want to checkout different revision from same tree into same directory bzr checkout -r give error 183: .bzr file exists
<LarstiQ> lifeless, jelmer: do you have cycles to help gour with explaining things to #ghc people?
<gour> LarstiQ: someone should go there and talk...i'm too young with bzr and didn't go into such stuff as looms
<LarstiQ> gour: aye, and I have been away too long.
<LarstiQ> gour: you mentioned rebase earlier, jelmer would be the guy for that. And in general, lifeless is good at explaining things.
<Necoro> hsn_: I would say: bzr revert -r 183
<gour> LarstiQ: yeah, i called for 'em. btw, see (huge) thread http://www.haskell.org/pipermail/glasgow-haskell-users/2008-August/015134.html
<gour> LarstiQ: thumper jumped in and helped a bit, but then he had to go quickly
<Necoro> hsn_: but if you want to create a new branch that starts at rev 183, I would say, it would be saner, to delete the current branch and start fresh at rev 183 ...
<LarstiQ> gour: I'll try to read that thread today.
<LarstiQ> Necoro: bzr branch -r 183 . ../newstart ?
<Necoro> LarstiQ: please read what hsn_ wants ;P
<Necoro> " and want to checkout different revision from same tree into same directory"
<LarstiQ> Necoro: I have difficulty parsing that sentence.
<hsn_> yes bzr revert -r works
<LarstiQ> hsn_: could you describe some more what your desired end result is?
<Necoro> LarstiQ: he wants to have rev 183 in the current directory (for whatever reason)
<LarstiQ> Necoro: is that it? That's fine for testing a historicals behaviour for instance, sure. And you are right that revert -r 183 is the way to do that.
<gour> LarstiQ: the most unfortunate thing is that bzr was ruled out due to speed only although on wiki page it is quite feature-rich - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation howver, maybe there is still chance 'cause they did not switch. someone knowledgeable should contact them, ask for common workflows and explain how to do it in bzr. i'll continue using bzr (came from darcs), but i'm sure that ghc's move will heavily
<gour> influenced the rest of haskell community (the whole hackage - haskell' cpan - uses darcs)
<Necoro> true ... but one should not modify and commit now ;P - except this is what is really intended ;)
<LarstiQ> Necoro: there are reasons to do that, but yes, it is slightly peculiar. Ref my request for clarification of intent from hsn.
<LarstiQ> hsn_: so. :)
<Necoro> ah btw ... just because this is such a great tool: Thanks to all you Bzr-Devs for your efforts ;)
<Necoro> (needed to be said today :D)
<hsn_> can i start bazaar without loading plugins?
<LarstiQ> hsn_: yes, bzr --no-plugins
<luks> --no-plugins
<awilkins> markh: Are you building Python-flavoured builds?
<aantn> luks: how would I attach my username to the url sftp://bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/
<luks> sftp://USERNAME@bazaar.launchpad.net/~universal-applets-core/universal-applets/trunk/
<aantn> luks: thanks
 * aantn crosses his fingers and hopes nothing goes wrong with the remote upgrade
<luks> it will probably take some time
<aantn> luks: yeah, bzr is still backing up the tree history
<aantn> do I need to repull a local copy of my branch after I finish upgrading the remote branch?
<LarstiQ> aantn: that depends. Was it previously up to date?
<LarstiQ> aantn: If yes, the no pulling is needed. You might still want to make sure it uses the same format as remote (though not required).
<LarstiQ> aantn: so bzr info local; bzr info remote; and bzr upgrade to remote's format if different
<aantn> LarstiQ: thanks
<TemplePrime> can I have multiple projects in a repository?
<Tak> I must be doing something wrong here, correct? http://rafb.net/p/I0Yaxz51.html
<LarstiQ> Tak: what do `bzr st` and `bzr missing` say?
<Tak> `bzr st` returns empty
<LarstiQ> Tak: there might be a bug there. Frankly, being bound to a branch but having zero revisions is a strange situation.
<LarstiQ> How did you end up in that state?
<Tak> ah, ok
<Tak> I'm following the manual, setting up a new repo
<LarstiQ> really? Which manual?
<Tak> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<Tak> except I guess I mingled the working-offline section with the starting-a-central-branch section in a way that's not supported
<LarstiQ> Tak: it mentions unbind a couple of times, but they don't seem to match. What section are you following?
<LarstiQ> Tak: ah.
<Tak> if I just can't do that with the initial revision, then that's cool
<LarstiQ> Tak: I'm still trying to understand what you were trying to do.
<LarstiQ> Tak: it is certainly a bug that bzr tells you to do something, you do it, and then it doesn't help you.
<Tak> I was trying to do the initial file import on a checkout of a newly-created repo
<LarstiQ> Tak: I have a hunch as to why things go awry in this case, but if you can give me a complete recipe for reproducing this, I can thwack the bug on it's head.
<Tak> sure
<LarstiQ> Tak: does the master have any revisions at all?
<Tak> no
<LarstiQ> Tak: thanks, that gave me enough info I think. 'bzr init sftp://localhost/tmp/master; bzr checkout sftp://localhost/tmp/master/ slave; cd slave; bzr unbind; touch foo; bzr add; bzr ci -m 1; bzr bind; bzr ci; bzr up; bzr ci;' gets me the same error.
<Tak> yes, that's exactly what I did
<Tak> I was just pastebinning an entire session for you ;-)
<LarstiQ> Tak: I'll still look at it for your effort :)
<LarstiQ> Tak: so, you'll find that if master actually has a revision, the update will do something.
<Tak> ok, cool
<LarstiQ> Tak: say, bzr checkout master slave2; cd slave2; touch bar; bzr add; bzr ci; cd ../slave; bzr update
<LarstiQ> Tak: and status should show your initial local commit as a pending merge
<Tak> `bzr push master` seems to rectify it for me
<Tak> (for the zeroth => first revision)
<LarstiQ> That is also an option.
<LarstiQ> You're basically operating in standalone branch mode there, and not checkouts.
<LarstiQ> Tak: what I'd personally would have done is probably: bzr init trunk; cd trunk; cp -a ../prebzr/* .; rm -rf CVS; bzr add; bzr ci; bzr push master (this will create the branch); bzr bind master;
<Tak> I see
 * Tak obviously new to bzr
<LarstiQ> Since you're setting up the branch from scratch. With a preexisting master it would just be 'bzr co master trunk; cd trunk; *hack*; bzr ci'
<LarstiQ> Tak: that's ok, you help find bugs in cases more experienced users won't think of :)
<jam> I just found a major regression in knit => pack performance :(
<LarstiQ> namely?
<jam> LarstiQ: "bzr branch knit pack" results in a 170MB repo when it should be 34MB
<jam> https://bugs.edge.launchpad.net/bzr/+bug/256757
<ubottu> Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Triaged]
<jam> It might actually only be in bzr.dev, though.
<LarstiQ> Aha.
<jam> the problem is that it does an "unsorted" fetch with all fulltexts
<LarstiQ> I recently upgraded my bzr repo, it took all evening and was constantly thrashing. 2.3G committed memory.
<jam> which means that the target repository
<LarstiQ> so yeah.
<jam> will insert fulltexts in random order
<jam> and "random" doesn't delta very well
<LarstiQ> oh boy.
<Peng_> Wow.
<luks> doesn't it _always_ diff against the left-most parent?
<LarstiQ> james_w: do you remember what happened to your test for bug 120968 ?
<ubottu> Launchpad bug 120968 in bzr ""bzr update" in checkout of empty branch fails and breaks dirstate" [High,In progress] https://launchpad.net/bugs/120968
<Tak> hooray!
 * LarstiQ has trouble finding a test for that in bzr.dev
<james_w> hey LarstiQ
<jam> luks: When you insert in random order, the left-hand parent may not be *present* yet, and thus you get a fulltext
<LarstiQ> Tak: that's a different bug though :)
<jam> So about 50% of your deltas get expanded to fulltexts
<LarstiQ> Tak: yours is #259146
<jam> Changing it to "topological" causes it to re-delta everything, which is costly CPU (and memory) wise, but at least the target repo isn't bloated.
<luks> oh, I thought it would reject revisions with missing parents
<luks> but thinking about it again, it wouldn't make sense for ghosts
<jam> fullermd: ping about bug 256757
<ubottu> Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Triaged] https://launchpad.net/bugs/256757
<jam> I just want to check what version of bzr is involved
<jam> as to whether this is a 1.6 regression, or just bzr.dev
 * Tak subscribe
<james_w> LarstiQ: ah, that was never merged I think
<james_w> I just never got round to writing the fix part of the patch
<jam> damn, it *is* in bzr-1.6
<jam> beuno: I'm going to need a 1.6rc4... :(
<LarstiQ> james_w: 1.5 doesn't break on this, but it isn't testing it afaics, so I don't want to close the bug yet.
<jam> LarstiQ: have you tried 1.6rc?
<LarstiQ> jam: nafaict
<LarstiQ> jam: I _think_ it was 1.5, but I can do it again (I kept the old repo around, it didn't seem right to me)
<LarstiQ> jam: du -mcs backup.bzr .bzr: 100 and 610 meg
<pickscrape> jam: if you have a repository affected by this bug, will a "bzr pack" using a fixed bzr bring the repo down to normal size (obsolete_packs notwithstanding)?
 * LarstiQ looks at the bug
<jam> pickscrape: no :(
<jam> pickscrape: that is why it is an extreme blocker for 1.6
<pickscrape> Heck, yes indeed.
<jam> we could *teach* pack to do so
<jam> but it doesn't yet
<jam> pickscrape: we probably should anyway, to get people who have already upgrade to get back into reality again
<TemplePrime> hey guys, are there any bazaar hosting services around? free and non free?
<Tak> launchpad?
<TemplePrime> does it provide though security features, like only memebers of groups can see source?
<LarstiQ> TemplePrime: any file hoster would do for bare requirements.
<jam> TemplePrime: there *are* private branches, which is non-free
<jam> And IIRC, not widely disseminated. I think it is still in a beta program.
<TemplePrime> launchpad seems a decent service, I'll get an account
<LarstiQ> jam: started an upgrade with 1.5 to --pack-0.92
<jam> fullermd: thanks for marking the bug critical, btw. It caused me to investigate it.
<jam> and it really is a critical regression
<aantn> luks: by the way, thanks for the help earlier; I got my branch switched over successfully
<beuno> jam, :(
<jam> beuno: yeah, but when we start warning users that they need to upgrade, I don't think we want to bloat their repos by about 5:1
<LarstiQ> jam: hmm, that seemed to have gone wonderfully well
<jam> LarstiQ: with 1.5?
<LarstiQ> jam: yes
<LarstiQ> jam: so perhaps I did the upgrade previously with bzr.dev, let me try that
<beuno> jam, right. Makes sense  :)   When?
<LarstiQ> jam: at 300 megs and rising, so far so good.
<jam> beuno: Well, I would really like lifeless to wake up and review the patch
<jam> Otherwise I'll be submitting a patch for review in about 10 minutes
<LarstiQ> jam: ~1G and system becoming unresponsive.
<jam> LarstiQ: yeah it was rev 3854 that introduced the bug
<LarstiQ> so yeah, seems to be the same behaviour as last time.
<jam> which is in 1.6 and bzr.edv
<luks> aantn: what version did you use to upgrade? maybe it was not such a good idea after all :(
<jam> luks: 1.5 is safe
<jam> 1.6-final *will* be safe
<luks> I think aantn was seing the upgrade warning
<luks> which is only in 1.6-something
<jam> luks: yep, and bzr.dev
<clemente> Hey, âbzr logâ is slower in current bzr.dev than in 1.5 :-( 1' 30" vs 1' 15" for showing the log of lp:bzr.dev
<aantn> luks: I upgraded to the repository format 6
<beuno> jam, alright, ping me and I'll try and upload tonight
<beuno> I'm supposed to be on holiday today :)
<jam> beuno: well, we *can* wait until tomorrow if you are busy. This is just a serious regression :(
<pickscrape> On holiday already? :p
<jam> On the plus side, with my fix the branch time drops from 5m => 30s, which actually makes knit => pack faster than it would be in 1.5
<jam> Of course, all of this is discovered while *3* core devs are on vacation
<jam> (abentley, spiv, poolie are all away this week)
<jam> beuno: LarstiQ, can you try to review the patch?
<LarstiQ> jam: I'll look at it, but I don't promise to be worth anything.
<jam> LarstiQ: well, the patch is pretty much 'trivial" as it was just a "not" logic inversion
<jam> if you want to just download it and try it on your upgrade
<jam> that would probably be enough for me.
<LarstiQ> right
<LarstiQ> that does look simple
<jam> I think the problem is that the naming of the parameter is poor
<LarstiQ> agreed.
<jam> "fetch_uses_deltas" versus "include_delta_closure"
<jam> the latter sure *sounds* like it sends deltas
<LarstiQ> (on it being pure, don't know if that is _the_ problem)
<jam> it actually means trace back through all deltas and make sure to include all the referenced info
<LarstiQ> is it me, or is bundlebuggy slow/not resolving?
<jam> abentley has been complaining about his hosting
<LarstiQ> jam: well, _closure does sort of evoke that in my mind
<jam> I'm not getting to the site
<LarstiQ> sort of, because I didn't know exactly what a closure would involve
<jam> LarstiQ: sure, though I will say lifeless wrote both apis and got it wrong :)
<LarstiQ> jam: oh yes, I support you
<jam> LarstiQ: BB is probably down right now, and abentley isn't around to ping to bring it back up.
<jam> You'll have to just do a reply
<jam> and assume BB will wake up later
<LarstiQ> jam: I wanted BB to pull from, but I've saved the patch and scped it. Running the upgrade with a patched bzr.dev
<jam> I don't think BB has even detected my patch yet
<LarstiQ> jam: bzr: ERROR: Revision {('testrevisionnamespaces.py-20050711050225-8b4af89e6b1efe84', 'robertc@robertcollins.net-20051002215128-5686c7d24bf9bdb9')} not present in "<bzrlib.knit.KnitVersionedFiles object at 0x895d90c>".
<jam> LarstiQ: I just got a timeout with a "Proxy Error"
<jam> LarstiQ: you need bzr.1.6
<jam> Though I would have thought that was merged into bzr.dev tip
<LarstiQ> jam: this is my historical bzr repo
<jam> LarstiQ: or is that what you get when upgrading?
<jam> LarstiQ: it wouldn't be something that you need to 'bzr reconcile' would it?
<jam> IIIRC the 1.5 fetch code could handle "broken" repos that need reconcile
<jam> 1.6 doesn't
<jam> And I would guess Robert's "bug" would let you fetch because it would cause everything to be sent as fulltexts...
<jam> So it basically does reconcile on-the-fly
<jam> but the fetch into-packs won't trigger the "auto-reconcile" code, which means you run into your problem....
<jam> hmmm
<jam> LarstiQ: can you try a line for me, just a sec
<jam> LarstiQ: http://rafb.net/p/Ux6YDH80.html
 * LarstiQ is currently afk on the phone
<LarstiQ> jam: it was indeed what I got when upgrading *looks at rafb*
<LarstiQ> jam: applied and trying again
<jam> thx
<LarstiQ> jam: same problem
<jam> LarstiQ: can you post the traceback, so I can see where it happens?
<LarstiQ> jam: http://rafb.net/p/bV38GS44.html
<jam> LarstiQ: ok, it is getting to the failure before it gets a chance to reconcile.
<jam> LarstiQ: unfortunately, I think the correct fix is to upgrade using bzr.1.5 and then run reconcile.
<jam> or run reconcile first
<jam> but that is generally very slow with knits.
<LarstiQ> yeah
<LarstiQ> I'll do some reconciling
<jam> LarstiQ: keep an old copy of it, if it isn't too much overhead
<jam> just so we remember stuff like that.
<LarstiQ> jam: I'm working on copies of my original backup.bzr, it's too valuable to touch directly.
<LarstiQ> great
<LarstiQ> bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit inventory corrupt:
<jam> LarstiQ: so... I would try upgrading with bzr-1.5, and then doing "bzr reconcile" and see where you get.
<LarstiQ> will do. That was an 1.5 reconcile on the knit repo btw.
<LarstiQ> jam: 1.5 upgrade, 1.5 reconcile -> oh hey, your repository is corrupt kthxbye!
<LarstiQ> jam: trying a 1.5 upgrade, bzr.dev reconcile now
<LarstiQ> just out of sheer desperation
<jam> LarstiQ: I wouldn't expect much, if this is the bug I'm thinking of
 * jam guesses LarstiQ pulled directly from one of abentley's repos at some time in the past when they had diverged when we didn't realize
<LarstiQ> maybe
<LarstiQ> sha-1 548f019618118527ae97bb092643be0d187c0cf1  of reconstructed text does not match expected 89853621e92f00ae1bb075139284c4df9a0434d0 for version john@arbash-meinel.com-20051117204806-013b3027c63d642b
<jam> LarstiQ: specifically, there were ghosts in aaron's repo, which caused "last-modified" entries to be different
<jam> there were *deltas* generated against those texts
<LarstiQ> jam: considering I have decendant code of nested-trees, it's not unlikely
<jam> and those deltas were pulled directly on top of the other form
<jam> without realizing that the base sha1 differed
<wolever> I'm getting a message 'bzr: ERROR: Revision {...revision ID...} not present in "filename.py-...revision ID..."' -- how would I go about figuring out what's happening?
<LarstiQ> jam: ehm, that 1.5 upgrade, 1.6 reconcile seemed to work.
<LarstiQ> wolever: I don't have a good answer to that.
<Peng_> wolever: Not that this helsp, but the "filename.py-..." thing is a file ID, not a revision ID.
<LarstiQ> jam: trying to comment on the patch, slow going because it means reading other parts of the codebase
<zeth> Hi
<pickscrape> Is it possible to create a branch of a branch with working tree that carries over the state of the working tree also?
<lifeless> moining
<zeth> So at the moment I am just going open('.bzr/branch/last-revision').readline().split()[0] to get the rev number, can I do this with bzrlib?
<Peng_> pickscrape: Well, you can use "bzr merge --uncommitted" after you branch.
<awilkins> pickscrape: If you are using checkouts, you can push to a new branch and switch to it
<lifeless> zeth: bzrlib.branch.Branch.open('.').last_revision()
<Peng_> zeth: You can also do something like "bzr revno".
<pickscrape> Peng: I'll try that
<lifeless> jam: hi
<Peng_> (well, that's if you're not doing it from Python)
<pickscrape> awilkins: I don't want to commit what's in my WC yet, though I suppose I could do that and uncommit etc.
<awilkins> pickscrape: I think if you push a new branch and switch what's left in your WC remains?
<awilkins> I could be wrong
<awilkins> hmm. Or you could shelve and switch
<zeth> lifeless: cheers
<zeth> Peng_: sorry should have said that from python
<pickscrape> awilkins: yes, you're right. My current tree is in a checkout of a checkout (which actually works). I'm wanting to experiment with a loom, so I want to try it in a new branch
<pickscrape> merge --uncommitted has basically done exactly what I wanted though. Thanks for the help :)
<wolever> Peng_: Ah, excuse me.  LarstiQ: Darn.  Oh well, it's just a frustration, no lost work.
<LarstiQ> wolever: other people should know though, but I wanted to say something and not let your question go without any reply.
<LarstiQ> lifeless: heya
<LarstiQ> lifeless: I think jam would like your feedback on [REGRESSION][1.6] fetching knits => packs
<wolever> LarstiQ: Alright, I'll keep a copy of the offending repositories around then come back tomorrow
<LarstiQ> wolever: if you can provide some more context on when it happens, that would help I think.
<lifeless> LarstiQ: yes, I need to talk to him about it
<LarstiQ> lifeless: good, then I'll stop looking at code and call it a day.
<wolever> LarstiQ: I'd love to, but so far it's only happened once, and I'm not sure how to repeat it.  My suspicion is that it's got something to do with either mismatched versions of bzr-svn and bzr or canceling an operation at the wrong time.
<LarstiQ> jam: do you want me to do anything with the upgraded/reconciled repository?
<lifeless> LarstiQ: lol :)
<LarstiQ> wolever: hmm, I'd say it still shouldn't in those cases. Your ~/.bzr.log should contain a traceback for it btw.
<awilkins> Is it me or is Bundle Buggy Busted?
<LarstiQ> awilkins: it is not you.
<jam> LarstiQ: you can keep it on the side if you want. Thanks for your help. You did miss a 'get_record_stream()' I didn't see.
<jam> lifeless: I'd like your help to put together a quick test case for all the fetches
<jam> I believe there are 4 or so
<jam> revs, sigs, invs, texts
<lifeless> jam: yah, I think there are two tests needed
<lifeless> one with _fetch_uses_delta True, and one False
<jam> I really want to get an rc4 out today if at all possible
<lifeless> we can use the existing VersionedFilesDecorator to catch the get_record_stream_calls
<lifeless> so its roughly
<lifeless> make_repo_a
<lifeless> make_repo_b
<lifeless> repo_a.texts = VersionedFilesDecorator(repo_a.texts)
<lifeless> .signatures
<lifeless> .revisions
<lifeless> .inventories
<lifeless> repo_b.fetch(repo_a)
<lifeless> inspect repo_a.texts.calls
<lifeless> this is a bzrlib.tests.test_fetch test-case, because it doesn't need to be parameterised by formats
<lifeless> and we should do it with repo_b as a pack, and again with repo_b as a weave, to get both values for _fetch_uses_deltas
<lifeless> jam: I can actually write it if you want, I figure that handoff time doing that would be greater
<jam> lifeless: I think you've given me enough
<jam> I've already got the code here
<LarstiQ> jam: those are all icw _fetch_uses_deltas afaics, the rest is in (True, False, include_delta_closure)
<rick_h_> lifeless: ping, I sent off the article I told you about. If you get a chance to peek at it. Pretty simple examples
<rick_h_> no big deal though
<jam> LarstiQ: 'icw' ?
<LarstiQ> jam: in combination with, sorry, that is a Dutchism.
<awilkins> "I cuckold walruses?"
<jam> awilkins: sorry to hear that awilkins
<awilkins> :-P
<awilkins> The standalone exe for win32 has all the source compiled inside it, yes?
<awilkins> What does it do about things like GTK libraries?
<LarstiQ> jam: the endresult now is 173 knitpack and 100 knit repos btw
<jam> LarstiQ: with my patch... and does that include removing files from .bzr/repository/obsolete_packs ?
<jam> reconcile, IIRC, creates an obsolete pack
<LarstiQ> awilkins: last I looked at it, fall over. But maybe markh has done something smart to instrument import.
<lifeless> awilkins: not sure, bundles I thought
<LarstiQ> jam: reconciled with your patch, yes. *looks at oldpacks*
<jam> LarstiQ: We don't have the gtk libraries bundled into the all-in-one so you can't use the bzr-gtk plugin
<jam> awilkins: I thought there was a discussion about adding places to the search path
<jam> but I don't think it got very far
<jam> so, ATM, the win32 will bundle the QT libraries to go with qbzr and tortoise
<LarstiQ> jam: and now it is 87 megs big, cheers.
<jam> LarstiQ: that sounds better
<awilkins> It must bundle some of the QT stuff because it uses qbzr now
<LarstiQ> jam: iirc 14 meg bigger than just the 1.5 upgraded version. But reconciled, so I can live with that.
<awilkins> markh has not posted the Python flavoured builds of the installer
<awilkins> (for win32)
<jam> LarstiQ: probably for the bits that had bad deltas, it inserted new fulltexts
<jam> we should really teach 'bzr pack' to combine a bit better
<jam> but that will probably wait for something like 'group-compress'
<LarstiQ> jam: yes.
<jam> where I see 100MB => ~20MB when done correctly
<lifeless> rick_h_: cool
<jam> lifeless: how do you want to handle the 'extra' calls, like get_parent_map() and iter_lines_added...
<jam> should I just check the *last* entry, which is 'get_record_stream' ?
<jam> or should I be asserting the whole thing
<zeth> so back to bzrlib, bzr has some magic way of finding the branch always, even if you are symlinked off or whatever, any idea how to use that from bzrlib?
<jam> zeth: bzrlib.branch.Branch.open? or open_containing
<rockstar> lifeless, hi
<zeth> jam!, sweet cheers!
<lifeless> jam: I would check there is only one get_record_stream call, and that it has the right value for that parameter
<lifeless> jam: thats all
<jam> lifeless: yeah, I didn't think we wanted to check all of it is constant
<lifeless> zeth: if you look at bzrlib.builtins, you can see the code we use
<lifeless> rockstar: hi
<lifeless> jam: doing wakeup-stuff, back in a little bit
<jam> lifeless: of course, for signatures, we seem to be doing 2 calls . :(
<rockstar> lifeless, I,ve been hacking on cscvs today. Have some questions when you get back.
<jam> lifeless: also, it seems that the proper value is 'unordered' not 'unsorted'...
<jam> 'unsorted' worked because anything other than 'topological' works
<chadmiller> rockstar: Heya.  Did you get mail from me (chad at sun com) about revno reset.
<chadmiller> ?
<lifeless> jam: meep
<lifeless> rockstar: hi, just shoot
<rockstar> chadmiller, I certainly did.  Thank you!
<rockstar> lifeless, aggregating now
<chadmiller> rockstar: I have another case for you.  :)  :\  :(
<rockstar> lifeless, testInitProtocolBadHost seems to hang
<rockstar> chadmiller, yes?
<chadmiller> rockstar: Same problem.  Same three developers.
<lzhang> is there a way to make bzr missing remember the branch that you want to want to run the command on?
<jam> lifeless: ugh, it seems that for the 'iter_items_introduced_by' we do a direct get_record_stream() check for every revision to see if there is a signature
<rockstar> chadmiller, and bzr resolve doesn't help?
<rockstar> chadmiller, I mean bzr reconcile
<lifeless> jam: thats in Model1To2
<jam> lifeless: no, it is in "item_keys_introduced_by"
<lifeless> jam: so you are doing a plain->rich-root conversion in your test case
<jam> lifeless: nope, it does a "get_signature_text() try/except" to decide if it is part of the stream
<lifeless> jam: oh fugkly
<jam> and get_signature_text is implemented as get_record_stream
<jam> which we then discard when we actually stream
<lifeless> still, its been like that for a while
<jam> lifeless: sure, I'm trying to do the minimum possible
<jam> so I'll cheat for that one with a big TODO/XXX
<chadmiller> rockstar: "oh [reconcile] does fix it... we just lose about 3 hours daily running it to fix the corruption"
<lifeless> ok, breakfast
<lifeless> then I will be here uninterrupted
<jam> chadmiller: do you happen to be using knits in one place, and packs in another?
<chadmiller> rockstar: "then someone pushes and it goes to hell again."
<rockstar> chadmiller, oh yikes.
<chadmiller> jam, doubtful.
 * chadmiller verifies.
<jam> chadmiller: well, a) you only need to reconcile the branch, which is a very small and fast portion of 'reconcile' and I think someone wanted to introduce a flag for only runing parts
<jam> chadmiller: well, if it is a mysql tree, they never went public with a knit tree
<jam> s/tree/repo/
<chadmiller> jam: it's an internal project, unpublished.
<jam> b) the only time I've specifically seen this, is when someone is accessing a repo that is missing a mainline revision
<chadmiller> Hrm.
<jam> there was a way that an old client pushing pack => knit could cause this if they ^C at the right time
<jam> it at least feels like someone has a branch with a bad pointer, and they keep pushing over your official location
<rockstar> chadmiller, did the branch come from a conversion of another vcs?
<chadmiller> rockstar: Yes.  svn, iirc.
<chadmiller> jam: all the branches I see pushed to are rich-root-pack.
<jam> chadmiller: the problem is the 'from' (I'm guessing)
<rockstar> That would make sense.
<LarstiQ> hah.
<jam> lifeless: if you get a chance, there is a patch up for review, and i'd like to get it submitted
<jam> No standup today, unless igc comes around
<chadmiller> jam, rockstar:  One other weirdness out of this team is that they're using sftp as transport.
<jam> chadmiller: I'm not particularly worried about that part
<chadmiller> Alright.  They're watching to see when it happens.  I have them running "bzr revno" on the destination before and after each push, branch, and merge.
<lifeless> jam:
<jam> ?
<lifeless> jam: sorry
<lifeless> reading, I'm not sure about the assertion
<jam> chadmiller: what would be nice is to have a post_branch_tip_changed hook, but you aren't using bzr+ssh to install it on the server, and it is probably a pain to install it on all the clients
<lifeless> you didn't alter weaves for instance :)
<jam> lifeless: I think we should have *something* to make sure recognized values are passed. I don't care a lot about that part
<jam> and I just want to get a 1.6rc out that can actually become final
<lifeless> bb:approve
<jam> lifeless: with the assert left in?
<lifeless> jam: yes
<jam> thanks, submitted
#bzr 2008-08-19
<markh> jam: good evening!  Bug 45719 refers to a branch https://code.launchpad.net/~jameinel/bzr/update-r, which is failing to mirror.  Do you still have that branch available?  Helping 'bzr up' grow a '-r' option sounds like something I could do in idle time...
<ubottu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719
<markh> it looks like it must be close to done already too
<markh> htm
<jam> markh: Yeah, LP just didn't like it when I upgraded my repo, and it had to re-fetch everything
<jam> It tends to timeout while downloading a full branch from my server
<jam> markh: you can get it from the source
<markh> A status of " [Medium,Fix committed]" doesn't look correct
<markh> oh - cool
<jam> just make sure you are going into a repo
<jam> http://bzr.arbash-meinel.com/branches/bzr/0.11-working/update-r
<markh> excellent - thanks
<markh> I'm not sure what you mean by "make sure you are going into a repo"
<markh> I can't just branch it?
<jam> markh: branch it into a shared repository, so you don't use up all my upload bandwidth
<jam> you *can* get it without that, but it is *nicer* to me if you do
 * markh feels clueless :)
<markh> I'm not quite sure what you are asking :)
<jam> markh: I'm guessing at some point you did 'bzr init-repo', just make sure you 'bzr branch' underneath that point
<jam> then again, maybe you didnt'
<markh> nope, I didn't
<markh> I think its time I educated myself a little more on a few of these things...
<jam> markh: if you do: "bzr init-repo repo; bzr branch bzr.dev repo/bzr.dev" it will copy revisions into the repo/.bzr/repository, future branches underneath 'repo' will share them
<jam> rather than copying them again
<LarstiQ> markh: you can create one later and seed it with data from the original branch, what jam just said
<jam> anyway, family time now, I'll try to get back later to get 1.6rc4 put out tonight
<markh> oh, right - that makes sense.
<kiko> hey there
<kiko> quick question
<LarstiQ> markh: and the relevant point for jam, if you branch update-r it will only download the revisions that you didn't have before, not hammering his upstream :)
<LarstiQ> kiko: shoot
<kiko> is there a way of saying 'give me the code as it looked in january 1st 2004'?
<markh> my current workflow is, eg, branch bzr.dev into its own folder, then make other branches from that directory.  If I followed that workflow, wouldn't I still only download from John's server once?
<kiko> using bzr checkout ideally
<Peng_> kiko: There's a "date:" revspec.
<kiko> hey LarstiQ
<kiko> aha. date:.
<markh> ie, wound;t a shared repo only save copies between my own local dis directoroes?
<kiko> Peng_, thanks!
<Peng_> :)
 * markh slaps his fingers...
<markh> hi LarstiQ!
<markh> hrm
<LarstiQ> markh: if you just branch inside a directory the branches will be all standalone and not sharing any revisions
<markh> or are you saying that I need to have *both* bzr.dev and john's patch in the same shared repo?
<LarstiQ> markh: you can confirm that by checking for branch/.bzr/repository/
<markh> LarstiQ: yeah, but doing that wouldn't hammer upstream any more would it?  ie, once I have the upstream copy in my local dir, other branches don't hit upstream at all
<markh> but - is the point to not pull revisions that are also in bzr.dev?
<LarstiQ> markh: now, if you are branching something (remote or local), bzr will check which revisions it should get, and if some of those are already present in the target repository, it will not fetch them again.
<LarstiQ> markh: true.
<LarstiQ> markh: exactly.
<LarstiQ> markh: since update-r is largely the same as bzr.dev, you would avoid downloading all those common revisions.
<markh> ok cool - that makes more sense.  I thought the advice was to put that branch in its *own* shared repo :)
<markh> which doesn't make much sense ;)
<LarstiQ> markh: ah no, that wouldn't help any :_)
<LarstiQ> markh: to continue my train of explanation, when your are not branching to a shared repository, there will be no pre-existing target repository, hence no revisions you already have, and you need to get everything again
<LarstiQ> markh: if you are however branching into a shared repository, there _might_ be revisions in there that you would otherwise have to fetch.
<markh> LarstiQ: that makes alot of sense - thanks
<LarstiQ> markh: since we know update-r and bzr.dev are similar, we can make sure we are branching into a repo that includes bzr.dev's revisions
<LarstiQ> and hence, avoid doing more work than we really need to.
<LarstiQ> markh: cool
<LarstiQ> markh: I personally have a ~/src/bzr/ repository where I have all my bzr branches under.
<markh> now we have stacked branches, would that be the preferred way to make such patches now?
<markh> LarstiQ: yes, I think I need one of them :)
 * LarstiQ is clueless about stacked branches, alas
<markh> from 10,000 feet, I understood a usecase was all about avoiding fetching stuff that is common.
<LarstiQ> markh: two effects you should notice after doing that, the size on disk of repo/ with multiple related branches is much smaller than just a directory of related branches
<LarstiQ> markh: and, branching within it is much much faster, since you need to do zero moving of revisions
<Peng_> Stacked branches are sort of like lightweight checkouts, where bzr doesn't download and sae the revisions at all.
<markh> Peng_: ahh, thanks
<LarstiQ> markh: oh right. I guess that might work.
 * LarstiQ 's mind is still molded to think of how bzr used to work
<Peng_> But with stacked branches, it still works like a branch, with local commits and all.
<LarstiQ> markh: I have some catching up to do.
<lifeless> LarstiQ: it hasn't really changed
<markh> LarstiQ: and you make your branches in subdirs under ~/src/bzr?
<LarstiQ> markh: yup
<lifeless> LarstiQ: how are you btw, long time no see
<LarstiQ> markh: ~/src/bzr/{bzr.dev,1.5,1.4,bug1234,etc}
<markh> and you still branch "normally" - bzr just magically works things out?
<Peng_> If you "bzr init-repo", "bzr branch --stacked http://bazaar-vcs.org/bzr/bzr.dev/" and then commit something, the only revision in your local repo will eb the one you committed (or maybe a couple revisions from bzr.dev, I don't remember)
<Peng_> markh: Was that question directed at me?
<LarstiQ> lifeless: long past my bedtime atm :) But otherwise good, had my last exam for a while today, starting september I won't be studying this academic year.
<LarstiQ> markh: yup
<markh> Peng_: I think you answered it in the next line anyway :)
<markh> ok great - thanks guys!
<Peng_> markh: Other than passing "--stacked" to "branch" commands, it'll all magically work.
<markh> I just read the "quick into to bzr.dev" or whatever that doc was called and have stuck with that ever since :)
<LarstiQ> lifeless: and I just spent 5 weeks in Finland with my girlfriend, so things are looking good now
<markh> good, but exhausted :)
<lifeless> nice:)
<LarstiQ> lifeless: and as you may have noticed, jam has dragged me back to reading mail again.
<LarstiQ> but now I think I'll try to get some sleep.
<LarstiQ> markh: you good to go?
<markh> LarstiQ: yeah, thanks for your hel
<markh> p-
<markh> :)
<LarstiQ> glad to be of help, bug me anytime (I don't promise to know everything though :)
<markh> thanks!
<kiko> thmmm
<kiko> Peng_, date: is kinda weird. if the branch checking out hasn't been modified since the date specified, it fails.
<kiko> the branch you're checking out
<kiko> bzr: ERROR: Requested revision: u'date:2007-01-01' does not exist in branch: BzrBranch5('file:///home/kiko/devel/archives/sourcecode/pygpgme/')
<kiko> that fails because pygpgme hasn't been touched in god knows how long
<lifeless> you might try before:date:2007-01-01
<lifeless> if that fails, i think its arguably a bug
<kiko> okay, I will try that
<kiko> but I think it's weird, and nothing in bzr is weird, usually
<lifeless> its not entirely satisfactory
 * markh should have known about shared repos long ago :)
<jam> kiko: date is one of those black sheep. we sort of have it, but it has a lot of points where the answer is unclear, so we sort of guess
<jam> beuno: If you get a chance: https://edge.launchpad.net/bzr/1.6/1.6rc4
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc4! /  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<jam> man, I really don't feel like sending *another* email to bazaar-announce ....
<beuno> jam, how about tomorrow morning?  I'm exhausted now, and will probably mess it up   :/
<jam> beuno: np, you never did write up those better docs :)
<beuno> jam, no, but I have notes!
<beuno> I will send the patch for that tomorrow
<beuno> and, it seems I may have time to try and put a script together during the week
<beuno> so hopefuly I'll at least get started
<VSpike> It must be because it's 3.20am here, but how can a file be in the removed, added and conflicts sections of bzr st?
<Peng_> When should rc4 make the PPA?
 * VSpike thinks kiko probably has the right idea
<mwhudson> VSpike: if you have files with different file id trying to occupy the same path, i can imagine that happening
<VSpike> mwhudson: I'm not aware of having done anything unusual
<kiko-zzz> VSpike, sleeping beats trying to understand pretty much any software artifact. good night! :)
<VSpike> kiko-zzz: night :)
<VSpike> meteoroid: how can I resolve the issue?
<VSpike> mwhudson: ^ sorry
<mwhudson> VSpike: hard to say without knowing more
<mwhudson> VSpike: i suspect it may make more sense after some sleep :)
<VSpike> Yeah, you're probably right
<VSpike> Ah well - g'night
<jam> Peng_: it sounds like beuno will try to make rc4 => .deb early tomorrow
<mkanat> Hey loggerhead question--is the front page supposed to have "Exception: name 'url' is not defined" at the top?
<bob2> it's a feature!
<Peng_> mkanat: That was fixed quickly.
<lifeless> Peng_: its in the 1.6 release tarball
<Peng_> lifeless: Ah.
<Peng_> Whoops.
<lifeless> Peng_: I think
<lifeless> http://www.squid-cache.org/bzrview/
<lifeless> beuno: ^ is da fugly
<Peng_> mkanat: Where do you see this? What version of LH is it running?
<mkanat> Peng_: http://bzr.everythingsolved.com/ It's running 1.6.
<Peng_> Maybe that's a different issue.
<Peng_> mkanat: If you have a few minutes, could you try running the trunk? (bzr branch lp:loggerhead)
<lifeless> Peng_: looks the same as the squid copy
<lifeless> both are 1.6
<lifeless> squid is using a loggerhead.conf, which I think is a mistake, but I've mailed beuno already as to why
<Peng_> 1.6 should have the same 'url' fix as the trunk does.
<lifeless> mkanat: are you using a loggerhead.conf, or serve-branches?
<mkanat> conf
<fullermd> jam: I dunno that much about that bug; the devil told me to mark it crit.  Or maybe it was lifeless.  One of the two...
<lifeless> Peng_: do you use a loggerhead.conf?
<Peng_> Yeah, 1.6 has that fix, so I guess this is a different issue.
<Peng_> lifeless: Nope, I use serve-branches.
<Peng_> I'm using hte trunk too
<lifeless> Peng_: try with a loggerhead.conf file, bet it will cause the problem
<Peng_> Sorry, but I've never used loggerhead,conf, and I'm lazy.
<Peng_> You try serve-branches. :P
<lifeless> :P
<mwhudson> ew, the browse view is sure super hideous
<lifeless> mwhudson: so loggerhead 1.6.1 soon ?
<mwhudson> i guess
<lifeless> the listing page is quite a regression
<thumper> lifeless: gee, what happened?
<lifeless> http://www.squid-cache.org/bzrview/
<lifeless> thumper: ^
<thumper> :)
<lifeless> thumper: see the horrible output?
<thumper> yes I did
<Peng_> Has somebody filed a bug? Should they?
<lifeless> thats loggerhead 1.6 using loggerhead.conf
<lifeless> mwhudson: have you?
<mwhudson> lifeless: no
<lifeless> I shall
<lifeless> bug 259273
<ubottu> Launchpad bug 259273 in loggerhead "loggerhead.conf usage borked" [Undecided,New] https://launchpad.net/bugs/259273
<gour> hi, attempt to merge branch produced with vs import on lp (from cvs) with the branch produced by running tailor on cvs repo gives: "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.". by looking at LP, i've found the latest common revision, but the problem is that revision number differ on both branches. how am i supposed to update my local branch (tailor-generated) with the more-up-to-date branch
<gour> from LP (vsc-import-generated) ?
<bob2> revision numbers don't matter
<lifeless> gour: well bzr thinks of them as totally separate
<gour> hmm
<lifeless> gour: they have different file identity
<gour> lifeless: how is it so?
<lifeless> gour: because they were separate imports
<gour> but those are same stuff, only one is more up to date
<lifeless> gour: if you run bzr inventory --show-ids
<lifeless> gour: you will see that they may have the same paths but are different file ids
<lifeless> gour: you can force it to merge, but it will conflict across the whole tree
<lifeless> gour: the question is, have you been committing to your local tailor generated branch ?
<gour> lifeless: ahh, it means that import us useful only as one-time affair?
<gour> lifeless: no, i just imported earlier
<lifeless> then just replace it with the launchpad one
<lifeless> ongoing imports are useful, but separate imports generate separate histories
<gour> that i know...i wanted to see how to merge them in case i'd have some local changes
<lifeless> in particular with CVS, where 'history' is arbitrary anyhow :)
<gour> the branches are at https://code.launchpad.net/gnumed
<gour> heh, that's why i'm pushing GNUmed to adopt bzr :-)
<gour> lifeless: how to force merge? supplying --force does not help
<lifeless> gour: merge -r 0..-1
<lifeless> gour: and then cry
<jamesh> gour: you could potentially use tailor to transfer the commits from one branch to the other
<gour> :-)
<lifeless> gour: normally, to deal with a local edit in this situation, you'd generate 'bzr diff -r LAST_FROM_CVS..-1' > some_file
<jamesh> but it is probably best to pick one CVS -> bzr import as the canonical one
<lifeless> then bzr patch some_file in the import you're keeping
<gour> jamesh: yeah.
<gour> if my local branch would be older revision of LP's gnumed with local changes, then merge won't be a problem, right?
<gour> the branches would have same ids
<gour> or different vcs import still produces different ids?
<jamesh> gour: neither tailor or cscvs (what the Launchpad imports use) produce repeatable imports
<jamesh> they'll have different revision IDs and different file IDs
<jamesh> both of which are important to "bzr merge"
<gour> jamesh: so, all the imports listed at https://code.launchpad.net/~vcs-imports/gnumed/trunk are not suitable for merge then?
<jamesh> gour: if you branch from that import and do work, you'll be able to merge newer changes from that same location
<jamesh> and merge between branches that derive from that import
<jamesh> the same goes if you used a tailor generated branch as the canonical import
<gour> jamesh: ahh, that's what i wanted to hear
<jamesh> you'll only see problems when you take branches derived from different imports and try to merge between them
<gour> i can use LP's import, work on the branch and then update from the newer imports which are regularly done
<jamesh> yes.
<gour> LP does new import every day...
<gour> good
<jamesh> the Launchpad imports are done incrementally
<gour> ahh, that's the catch ;)
<jamesh> it doesn't redo the import every day -- it updates the existing import
<jamesh> similarly, you can maintain a tailor import incrementally
<gour> however, i do not propose this as normal workflow...the idea is to contribute something via bzr to LP's import and prepare devs to migrate to bzr :-)
<gour> right...just not mixed the two :-)
<jamesh> the Launchpad imports don't really help too much for two-way communication
<jamesh> you can't move changes back to CVS in a way that will be recognised by the CVS -> bzr importer
<jamesh> if you're lucky, it'll come up as a null merge
<jamesh> if you're unlucky it'll be merge conflicts
<gour> well, i'll contribute to bzr branch on LP and let them patch upstream if they don't want to use bzr, but i won't use CVS
<jamesh> if you're using short term feature branches, this isn't too bad: you can throw away the branch once it gets merged
<gour> btw, does it make sense to sign for Ubuntero for someone not using Ubuntu, but using LP
<jamesh> it is up to you
<jamesh> the only things that require it at the moment are becoming an Ubuntu member and getting access to Launchpad's personal package archive feature
<jamesh> if those don't interest you, then you aren't missing out on anything
<gour> hmm, ppa
<gour> that might be handy
<gour> but that's, again, only ubuntu pkgs, not source releases, right?
<jamesh> right.
<gour> heh, then i do not need it...which does not prevent me to follow the good codes uven without signing :-)
<gour> *even
<robsta> ping bkor
<VSpike> I'm confused how files can be in the removed, added and conflicts sections of bzr status?
<VSpike> command output at http://www.pastebin.com/m422b0b96
<VSpike> Sorry that should be http://pastebin.com/m422b0b96
<leopold> Hi All. I have a problem with a bzr repository returning a "Revision .. not present in .." error, does anyone have the time to help me out with the problem?
<lifeless> VSpike: what is confusing?
<VSpike> lifeless: I don't understand what it is telling me.  From my point of view, I have done nothing different other than change the contents of the binary files Bin/Geonix.dll and Bin/Geonix.pdb, which normally results in them showing as changed
<VSpike> I don't understand how to resolve the conflict and commit the changes
<enquest> when I want to install bzr 'aptitude install bzr' it wants to install x-server and so on... ???
<enquest> I only need command line with bzr
<enquest> any tips?
<lifeless> VSpike: so, being in conflict means bzr couldn't decide for you how to do a merge for you
<lifeless> VSpike: if you see the one file both deleted and added, it means someone had added them in parallel elsewhere, so you have the same file /name/ with two different histories, and you need to choose one
<lifeless> VSpike: use bzr mv and del to arrange the tree how you want, then bzr resolve NAME
<lifeless> enquest: uhm, its bzrtools I think
<lifeless> enquest: it uses graphviz or something, and that pulls in X
<lifeless> enquest: if you are using aptitude, try going in via the gui
<lifeless> sudo aptitude
<lifeless> then /, bzr, i
<lifeless> and then edit the actions list and change stuff
<VSpike> enquest: I've solved that problem on a debian server - just trying to remember how
<enquest> this is a securtiy problem using bzr on your server... If you not good at managing servers you don't know these things
<lifeless> enquest: huh?
<luks> aptitude installs recommended packages by default?
<VSpike> luks: it's configurable
<VSpike> enquest: try "sudo aptitude install bzr --without-recommends"
<enquest> ok I did not know that with apt-get you don't have that problem
<enquest> VSpike, thanxs
<VSpike> enquest: or use the ncurses interface as lifeless suggested
<VSpike> lifeless: sorry if i'm being obtuse, but I can't see how it got to this state...
<VSpike> lifeless: I'm working in a single branch, doing modify/commit, modify/commit.. and occasionally modify/commit/push
<VSpike> lifeless: so there should have been no merges into this branch
<Peng_> Some sort of file name case wackiness, maybe?
<VSpike> Peng_: I wondered that, but they show the same in bzr stat at least
<Peng_> Yeah.. it's still possible though
<VSpike> The irony is, this is a binary generated by the build of a sub-project
<VSpike> I only check it in so that I can recreate a past situation exactly, because bzr doesn't allow me to connect the two projects yet
<VSpike> So if I delete it, it will just get regenerated
<lifeless> VSpike: could you pastebin the output
<VSpike> lifeless: of?
<VSpike> I just did "bzr mv Bin
<VSpike> I just did "bzr mv Bin\Geonix.dll Bin\Geonix.dll.old" and the same the .pdb file
<VSpike> But not sure I'm any better off
<VSpike> lifeless: you want bzr stat --show-ids again?
<lifeless> VSpike: again?
<lifeless> VSpike: anyhow, I'm heading off sorry
<VSpike> lifeless: I posted it back aways...
<lifeless> VSpike: perhaps Peng_ or someone else still awake can comment on a pastebin output for you
<VSpike> http://pastebin.com/m422b0b96
<lifeless> so
<lifeless> to get conflicts, you _must_ have done a pull, or merge, or update
<VSpike> now http://pastebin.com/d49a67117
<VSpike> lifeless: anyway I can check that in a log?
<lifeless> as for the delete + add pairs; simplest thing would be to save the copy you want to keep, bzr rm the new file, bzr revert PATH to restore the old fileid, then copy the one you want back in
<lifeless> bzr --version will list your log file
<lifeless> bzr commands are listed in the log
<lifeless> I must go though - good luck
<VSpike> thanks!
<awilkins> Arrgh, rc4 happened while I wasn't looking
<awilkins> :-) Is BB back up?
<awilkins> Guess not.
<LarstiQ> moin.
<ignas> mwhudson: it seems that bzr developers have fixed my bug yesterday, and the fix is going to make it to 1.6rc4 :)
<mwhudson> ignas: i/we found another bug that might mean a 1.6c5 :(
<ignas> oh. What's the number?
<mwhudson> ignas: https://bugs.edge.launchpad.net/bzr/+bug/259275
<ubottu> Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [High,Triaged]
<ignas> mwhudson: hmm, not sure I understand what operations I should be avoiding if I don't want to break things...
<mwhudson> ignas: this bug is only likely to affect launchpad, realistically
<ignas> should I not try pushing to my remote knit repository from my stacked repository for example?
<mwhudson> no
<LarstiQ> no, don't do that, or no, no problem?
<mwhudson> as in, you should be fine
<LarstiQ> pfew :)
<mwhudson> english sucks
<kiko_> hmmm
<kiko_> bzr st segvs for me in my /etc!
<kiko_> that is very fun
<mwhudson> kiko_: exciting
<kiko_> mwhudson, SPEAKING of segvs..
<kiko_> #0  0xb7e54cbf in memcpy () from /lib/libc.so.6
<kiko_> #1  0x08092895 in PyString_FromStringAndSize ()
<kiko_> #2  0xb7778d4e in ?? ()
<kiko_>    from /usr/lib/python2.5/site-packages/bzrlib/_dirstate_helpers_c.so
<kiko_> mwhudson, I guess this is known..?
<kiko_> Bazaar (bzr) 1.5
<mwhudson> kiko_: not by me
<kiko_> okay, will try and file a bug then
<mwhudson> i can imagine a corrupt dirstate tripping up the c parser or something
<beuno> lifeless, ew, template for start-loggerhead seems broken  :/
 * beuno waves
<scgatai_> hi
<pickscrape> beuno: the breadcrumbs branch is ready for a further review
<beuno> pickscrape, cool. I'll take a look at it after my coffee  :)
<pickscrape> beuno: no rush, just letting you know :)
<pickscrape> Could anyone point me at an explaination of when I need to use the record command when using a loom?
<Tak> ok, if my bzr-svn checkout failed (ERROR: revision "blah" already present in "revisions"), is there anything I can do to work around it?
<beuno> jam, building rc4 debs now   :)
<jam> beuno: before you spend too much time, mwhudson wants an rc5
<jam> I'd like to at least look at the bug first
<beuno> jam, ah, heh, ok. I'll start looking intro scripting then
<jam> mwhudson: ping
<jam> You have a bug, but do you have a possible fix?
<jam> Even just an outline of the fix
<cr3> how can I determine to which host bzr launchpad-login is trying to connect exactly? the --verbose flag doesn't show anything and the error says: ERROR: Connection error: while sending GET /%7Ecr3/%2Bsshkeys: (111, 'Connection refused')
<cr3> seeing the url, I guess https://launchpad.net. I thought at first it might be the openid url, nevermind
<jam> cr3: default URL
<jam> BZR_LP_XMLRPC_URL=http://xmlrpc.launchpad.net/bazaar/
<jam> you can set that in your environment, I believe, to override it
<jam> Oops, I'm wrong, it is https://xmlrpc.launchpad.net/bazaar/
<jam> the 's' is there
<cr3> jam: telnet xmlrpc.launchpad.net 443 works, but I'm still getting the same error message
<cr3> jam: I then tried setting the environment variable, just in case, same thing
<awilkins> Is bzr push really really slow over a network share if you have virus checking of network drives on?
<LarstiQ> possibly, I know I've had antivirus software cause locking problems for bzr before
<jam> cr3: are you behind a proxy? It is a known problem with python's xmlrpc implementation that it doesn't respect http_proxy
<jam> awilkins: packs or knits? Knits would probably be extra bad because we would touch lots of files
<awilkins> jam: Packs
<jam> though I could also see a repack of a .pack file causing issues if the software had to virus check the whole pack file
<awilkins> jam: It's rich-root-pack, 210MB total, largest pack 160MB
<jam> though it is all compressed data
<jam> awilkins: well, we might read *parts* of some files
<jam> which may cause the virus checker to read the whole thing?
<jam> So we might read 100k from your 160MB file
<awilkins> jam: I wonder if reading multiple regions of that large pack makes it check the whole file each time
<jam> and then your virus checker decides
<jam> it needs to read all 160 MB
<awilkins> I'll run it with filemon active next time
<jam> also, we may go back multiple times to portions of the file
<jam> which might trigger similar issues
<jam> (one read from 10-100, another at a later time 1000-1100 etc
<awilkins> I'm note sure it's the vchecker
<awilkins> I believe I tried it with the service stopped once
<awilkins> Anyhow, it's nearing 1700, and I need to catch my train
<awilkins> back-in-a-bit
<jam> kiko_: I just submitted a patch for the dirstate parser which should at least give a proper traceback rather than a segfault.
<cr3> jam: I am behind a proxy but I don't have the http_proxy environment variable set and I have an iptables rule explicitly allowing connections to xmlrpc.l.n, bazaar.l.n and l.n
<jam> cr3: can you try it with "bzr launchpad-login -Derror" ?
<jam> that should give you a traceback that you can pastebin for me
<cr3> jam: http://pastebin.com/d36c2c2ae
<cr3> jam: just to make sure, env | grep -i proxy returns nothing
<cr3> jam: also, I'm tailing the logs on the proxy and nothing is appearing when running launchpad-login
<jam> cr3: so, after the xml call, we then do an HTTP fetch, which *does* respect the http_proxy setting
<jam> And that is the point that is failing
<jam> The http fetch is going to https://launchpad.net/~user/+sshkeys
<jam> Try setting http_proxy and see if it works
<mxpxpod> I made a branch from a branch located on my local file system... I moved the branch I created and now I can't pull from the original branch... it's saying the parent is not accessible given a base and a relative path... is there a way to fix that?
<cr3> jam: worked!
<jam> cr3: so it seems you got the xmlrpc stuff to go through without the proxy, but not https://launchpad.net requests
<jam> mxpxpod: 'bzr pull --remember /new/location'
<mxpxpod> jam: ah, thanks... I figured out I can also modify .bzr/branch/branch.conf
<mxpxpod> jam: but I figured there was a better way to do it
<alexreg> hi
<alexreg> i've just upgraded to bzr 1.5 and i'm getting an error when using the --use-existing-dir option now
<alexreg> bzr: ERROR: extra argument to command push: use-existing-dir
<alexreg> couldn't find any notes on the changes to this argument
<alexreg> this is for the push command of course
<alexreg> any ideas please?
<Tak> is there a way to "force" bzr to invoke bzr-svn for a checkout over http?
<Tak> I keep getting "bzr: ERROR: Transport error: Server refuses to fullfil the request"
<jam> alexreg: try it with '--no-plugins'
<jam> I would guess that a plugin is decorating "bzr push" and causing problems
<jam> Tak: "svn+http://" I believe
<alexreg> jam: now i get "bzr: ERROR: extra argument to command push: no-plugins"
<jam> alexreg: "are you using --no-plugins" ?
<Tak> jam: perfect, thanks!
<jam> not "-- no-plugins"
<alexreg> i upgraded from v1.2 but it was occurring even then. so i'm not sure in which version it last worked correctly
<alexreg> jam: yeah
<jam> because '--no-plugins' is a global arg that is always parsed before commands are handled, so something weird is going on
<jam> alexreg: can you pastebin the last part of your ~/.bzr.log ?
<alexreg> sure. one min
<alexreg> jam: http://pastebin.com/m3f3f5e10
<alexreg> the first is with no command line args, the second with use-existing-dir and the third with both use-existing-dir and no-plugins
<jam> alexreg: well when you did 'use-existing-dir' you didn't supply the '--' it is '--use-existing-dir'
<jam> similarly for '--no-plugins'
<jam> For example: [u'push', u'bzr+ssh://...', u'no-plugins', u'--', u'use-existing-dir']
<alexreg> sorry. i *did* include the "--" when executing bzr
<alexreg> just not on IRC
<jam> That means you wrote "bzr push bzr+ssh://... no-plugins -- use-existing-dir
<jam> rather than
<jam> bzr push bzr+ssh:// --no-plugins --use-existing-dir
<alexreg> yeah that's what i did....
<jam> alexreg: notice that you need '--' before the option, and no spaces
<jam> alexreg: not according to the bzr log file
<jam> What are you using as a shell?
<alexreg> hrmm could it be because i'm executing in powershell?
<alexreg> ^^
<jam> alexreg: sounds like
<jam> Sounds like powershell is doing weird things to your command line
<jam> I don't know powershell myself
<alexreg> yeah probably
<alexreg> ok
<alexreg> putting the option in quotes seems to fix it
<alexreg> thanks :)
<jam> alexreg: bad PoS, :)
<jam> of course, PoS is a great acronym for it anyway :)
<LarstiQ> alfonsodg: is that the old and venerable *nix powershell, or the windows one?
<jam> LarstiQ: Windows
<jam> and alexreg left
<jam> I don't think alfonsodg knows :)
<jam> sorry for the double ping a l f o
<LarstiQ> bweh
<Tak> has anybody encountered 'ERROR: revision "blah" already present ...' when checking out from a svn repo?
<pickscrape> pygi! How goes cheezburger?
<pygi> pickscrape, sorry, will poke later
<jbalint> Hi LarstiQ
<LarstiQ> hey jbalint
<jbalint> LarstiQ: i came here a few days ago, with a problem with putty link on windows and aliases
<LarstiQ> jbalint: right, I remember that
<jbalint> LarstiQ: the problem is i am using non-22 port and the command executed is "plink.exe -ssh ...." and -ssh forces this to use port 22 :|
<LarstiQ> jbalint: is there no way around that?
<jbalint> LarstiQ: i havent looked in bzr code to see how it determines the command, but i do not have any solution thus far, except using paramiko with the port given
<LarstiQ> jbalint: is the -ssh needed on plink? And if so, can plink -ssh uses something else than port 22?
<LarstiQ> jbalint: if not then we would need to document that plink can only be used with port 22 I think :(
<jbalint> LarstiQ: it will work if i add -P on the command line, but this is saved in the alias. i'm not sure why -ssh overrides it. maybe i should file a bug with putty
<jbalint> LarstiQ: ok, i just checked, it seems to work if i put the port in the bzr+ssh url too
<LarstiQ> jbalint: is there a way we can query plink for what the alias expands to?
<jbalint> LarstiQ: not that i know of besides exporting it from the registry
<jbalint> LarstiQ: but part of the benefit is that you shouldnt need to do that because you can use the alias in place of 'host' for the plink/ssh command and they both work the same way
<jbalint> LarstiQ: do you know why the -ssh flag is needed?
<LarstiQ> jbalint: I do not, I hoped you would :)
<jbalint>   -ssh -telnet -rlogin -raw
<jbalint>             force use of a particular protocol
<jbalint> thats what plink.exe help says.
<LarstiQ> jam: do you know why we supply -ssh to plink? It seems to override non-22 ports in aliases
<jam> LarstiQ: well, my guess is to keep it from trying to telnet to the other location, at least what from jbalint says
<jam> jbalint: so if you just 'plink host.com' rather than an alias, does it do something other than ssh?
<jam> If so, then it sounds like removing -ssh, would mean that people would need to configure an alias for every machine they want to connect to
<jam> rather than "just working"
<jam> Personally, I don't like plink much, and just use paramiko
<jam> plink has a lot of weird bits
<jam> like not remembering the username in a saved session
<jam> etc.
<jbalint> well i just ran plink host.com and it does ssh
<LarstiQ> does paramiko provide any of the alias/session functionality of plink?
<LarstiQ> jbalint: and if you do plink host -P 23 ?
<jbalint> seems to support pageant
<jbalint> well i get connection refused :) dont have telnet running
<LarstiQ> jbalint: I'm thinking the -ssh/-telnet is to force a protocol when the autodetection for a port comes up with something else
<jam> LarstiQ: paramiko supports pageant, but no, doesn't provide aliases (that I know of). But bzr+ssh://user@host:port/ provides most of what you need.
<jam> jbalint: which is why we pass -ssh :)
<jam> LarstiQ: for most of my time, I used cygwin's ssh.exe
<LarstiQ> jam: afaics -ssh only helps if it's port 23
<jam> LarstiQ: ah, I missed that part
<jbalint> i dont know if detection is based on port. with both of those protocols, the server sends some header info upon connect, right? so it could be based on that
<jam> jbalint: so, if you want to work out more details of how to use plink properly, I think we're happy to take patches, etc. I think plink just doesn't get a lot of support because the other solutions work, and in some cases work better.
<jam> (Like being able to prompt for a password when pageant doesn't have your key)
<jbalint> but you're passing -batch, thats why it doesnt prompt
<jam> jbalint: because if we don't pass -batch it hangs waiting for input because it can't connect to the terminal
<jam> so we would rather it *fail* and get on with it
<jam> rather than hang indefinitely
<jbalint> ol
<jbalint> *ok
<jam> interestingly enough cygwin's ssh.exe can connect to the terminal, so I don't really understand *why* plink cannot
<jbalint> i'll try to get some ideas on plink and ssh. thanks alot for the info so far
<kiko> jam: cool. unfortunately it looks like I've got a corrupted tree.. somehow.
<jam> kiko: well, I can say that we truncate + write (I *think* in that order) so if you somehow managed to do one without the other (power fail, kill -9, etc) it would be possible to have an inconsistent dirstate
<jam> kiko: I posted to the bug a workaround using 'bzr co --lightweight'
<jam> which is also in the bug that yours is a dup of
<kiko> jam: oh, my bug is a dupe? I searched quite a bit for it
<jam> kiko: the problem is that some platforms segfault others give MemoryError
<jam> kiko: bug #186014 is the same bug
<ubottu> Launchpad bug 186014 in bzr "MemoryError on diff/commit due to corrupted dirstate" [High,Fix committed] https://launchpad.net/bugs/186014
<kiko> ah!
<kiko> how interesting
<jam> kiko: yeah, the problem is effectively passing a negative number to malloc
<jam> I assume some platforms cast it to unsigned
<jam> and get a malloc failure
<jam> others just segfault
<jam> as you saw :)
<fullermd> Erk.  segfault?  That sounds bogus.  malloc is defined to take size_t, which is unsigned...
<Toranin> aargh, had to reboot, now I have to start the svn-import over again...and it was almost done, too.  Looks like another week until I can play with bzr...
<jam> fullermd: well, it is PyString_FromStringAndSize, I don't know if it strictly uses malloc under the covers. It might be a PyMalloc which could have more issues, etc.
<jam> Toranin: I believe it starts from where it left off
<Toranin> jam: I'll try it, but I don't think it got killed cleanly so we'll see how well it goes
<mwhudson> jam: i think this might be maybe sort of a fix: http://pastebin.ubuntu.com/38892/
<mwhudson> it makes test_sprout_stacking_policy_handling fail, but i'm not sure that's a bad thing
<jam> mwhudson: does that ignore the value or always create a new one?
<jam> mwhudson: specifically, what fix are you looking for
<jam> should 'bzr push lp:' create a new branch format
<jam> so it can stack
<mwhudson> no
<jam> or just ignore the fact that it was auto-requested to stack
<mwhudson> right
<mwhudson> _my_ idea, not talked this through with anyone else
<mwhudson> would be for the default stacking to only apply when the formats allow stacking
<jam> mwhudson: sure, I'm a bit hesitant about the whole auto-stacking anyway, but if we at least required the user to be using a stackable source, then there is *some* good. And it sure would be shiny
<mwhudson> otherwise people are going to be Surprised(tm)
<jam> mwhudson: well, they might be surprised to have auto-stacking anyway...
<mwhudson> jam: well, if there are no format surprises they hopefully won't really notice
<jam> mwhudson: well, what about when --1.6 is the default format?
<mwhudson> other than the fact that initial pushes take less time
<jam> I suppose as long as it is only stacking within the LP universe
<jam> there isn't a chance for data loss
<mwhudson> another possible fix for 1.6 would be to disable the auto-stacking stuff somehow
<jam> mwhudson: well, auto-stacking was approved for 1.6, I'm not trying to break it
<jam> I think we probably want a fix that means lp doesn't have to do something like check the bzr client version
<jam> mwhudson: Though, what if the branch format is 1.6 and _stack_on is set, will it still stack (with your patch)?
<mwhudson> jam: not sure
<mwhudson> i guess i should check
<jam> mwhudson: so I would probably say the best fix is to have the check for the stack_on policy know if the source supports it
<mwhudson> jam: it seems it does still respect the stacking policy with my fix
<mwhudson> jam: and it fixes my testcase too, although it still prints
<mwhudson> Using default stacking branch b1 at bzr+ssh://localhost//home/mwh/canonical/checkouts/trunk/sourcecode/t/
<mwhudson> even though it in fact doesn't use it, which is a bit bogus
<jam> mwhudson: isn't telling them that a good thing? Or it says that and then ignores it
<mwhudson> it says it, then ignores it
<jam> ok, that is a bit bogus :)
<jam> and considering all pushes creating new branches will say that ...
<jam> Makes me wish I had reviewed the repository policy patch myself
<jam> It certainly seems to have made following the code logic a bit more complex
<jam> mwhudson: what about passing in "default_format_supports_stacking" to the "determine_repository_policy" function?
<jam> or ... "source_format_supports_stacking"
<mwhudson> jam: i think that would probably be more clear than hacking around trying to work with the data that's there already
<jam> I'm a bit confused as to where things are happening ATM
<jam> It seems that both the branch format and the repository format need to support stacking
<jam> and they both figure that out at different times :(
<mwhudson> oh that's the other fun thing
<jam> mwhudson: so it sounds like the specific bug is that the repository figures out it needs to be stacked
<jam> but the branch does not
<mwhudson> in my test case, the broken branch has a stacking compatible repo but not branch
<mwhudson> jam: yes
<jam> so you end up creating a target where the repo thinks it is stacked
<jam> and doesn't copy revisions
<jam> but the branch doesn't
<jam> so it doesn't include the reference
<jam> ugh.
<mwhudson> yeah, you even end up with a 'stacked_on_url' in branch.conf
<mwhudson> but the branch doesn't look at it, of course
<jam> I'm very hesitant to add a kludge on top of the existing kludge
<mwhudson> right
<jam> especially when all the people who *did* the work are on vacation
<jam> I'm tempted to disable the whole lot just to get a clean 1.6 out the door
<mwhudson> +1 from me
<jam> which would (in a way) show the colossal blunder of delaying 1.6 to get Stacked working
<mwhudson> i guess i'd like to hear what jml and thumper say
<jam> the whole reason it was delayed was stacking
<jam> round and round we go :(
<mwhudson> i think everyone realizes what a terrible idea that was now :(
<fullermd> Well, if we disable it, and release 1.7, we can pretend...
<jam> mwhudson: so why in your example
<jam> doesn't it find that the branch format needs to be upgraded
<jam> consider line 1093 of bzrdir.py
<jam> isn't it deciding the Branch policy based on the repo policy?
<jam> mwhudson: in other words, pushing to lp would always create 1.6 branches and repos
<jam> which you don't really want
<jam> but at least they wouldn't be *broken*
<mwhudson> yes, that would be almost as bad
<mwhudson> um, i did look into this but i forget
<vreixo> hi guys!
<vreixo> can I ask a little doubt I have?
<jam> ?
<vreixo> I was working with two branches, then I merged one into the other
<mwhudson> anyway, i've only just got up, so i need to breakfast and stuff before i can really think clearly...
<vreixo> and together with the merge I did a change in a file
<vreixo> after that I did several commits
<vreixo> now I want to revert the change done in the merge commit
<vreixo> but not the merge itself
<vreixo> is that possible?
<vreixo> I use bzr 1.5
<jam> mwhudson: well 'bzr branch' creates a new format branch under those conditions
<jam> mwhudson: I think the problem is "bzr branch" versus "bzr push" where "branch" uses .sprout() and "push" uses ".clone()".
<jam> mwhudson: I think martin fixed up 'sprout()' but didn't fix 'push()'
<jam> sorry, .clone()
<mwhudson> jam: hmm, so the bug isn't so bad in bzr.dev it seems, we don't create a branch with mainline ghosts
<mwhudson> jam: that sounds right (about clone vs sprout)
<jam> vreixo: well, you can 'bzr revert' just the file
<mwhudson> jam: but there's still the default branch/stacked repo thing
<jam> vreixo: but generally tweezing apart what was done by the merge and what was done by *you* is difficult
<jam> which is why we don't let you merge with uncommitted changes
<jam> and recommend that you only do enough to get the conflicts resolved before merging
<vreixo> jam: yeah, that's the problem
<jam> vreixo: so doing "bzr revert -r XX file" isn't fine-grained enough?
<vreixo> jam: no it isn't
<jam> mwhudson: sure, it automatically upgrades when you have a target that says you should stack
<vreixo> as it reverts the changes in the merged branch
<jam> which doesn't sound like what we want.
<mwhudson> jam: right
<jam> vreixo: so the same file included both
<jam> mwhudson: and is a problem because we *do* want to auto-upgrade if the user says "--stack"
<jam> and all the other crazy things that have gone into the policy idea
<jam> mwhudson: I really feel like some of this wasn't well thought through
<vreixo> jam: what is strange is that I can see the diff with only the changes I want to revert, but I have no way to revert it
<vreixo> it would be great to have such feature
<jam> vreixo: how do you get that diff?
<jam> I would guess you can do "bzr merge . -r XXXX" with the same parameters as the diff
<mwhudson> jam: indeed, and i don't think there's any way to not do the suggested stacking at the moment :/
<mwhudson> jam: gee, you think?
<jam> vreixo: well, reverse them
<jam> vreixo: so if you do "bzr diff -r 10.1.1..11" to get the diff, do "bzr merge . -r 11..10.1.1" to revert it
<jam> mwhudson: And I'm extra sad because everyone left this week. Why did they all pick the *same* week, and why did we pick it to be the release week....
<jam> mwhudson: I might just punt... but I *really* wanted to force 1.6 out the door
<mwhudson> jam: i would support dropping/disabling looking at the default_stacked_on url
<vreixo> jam: with ï»¿ï»¿bzr diff -r366..364.1.29
<mwhudson> jam: and releasing everything else
<vreixo> jam: oh, let me try!
<jam> vreixo: so "bzr merge . -r 364.1.29..366"
<jam> mwhudson: good enough
<mwhudson> jam: i so very don't want to have to implement client version blacklisting in launchpad
<jam> mwhudson: yeah, that would be extra crummy
<vreixo> jam: bad thing!
<vreixo> after bzr st I get an error:
<vreixo> jam: bzr: ERROR: exceptions.KeyError: 'pop(): dictionary is empty'
 * mwhudson afk for a few minutes
<jam> vreixo: you're using bzr 1.5, right?
<vreixo> yes
<jam> 1.6 won't give you that, and you can "bzr revert" to get back to where you want to be
<jam> vreixo: actually just "bzr revert --forget-merges"
<vreixo> jam: it was my problem
<vreixo> what I want was to do  bzr merge . -r 366..364.1.29
<vreixo> but I did bzr merge . -r364.1.29..366
<vreixo> anyway, the error is ugly,,,
<jam> vreixo: sure, the error has been fixed in future versions
<vreixo> good!
<jam> and 'bzr revert --forget-merges' will get rid of it, though you want "bzr revert' right now to get back to clean state
<vreixo> bzr revert worked properly
<vreixo> then I did the merge with the correct revision order and all is ok now
<vreixo> thanks!
<vreixo> one more question, can I do that with only one file
<vreixo> or I need to revert later the files I don't want to revert originally?
<hendrixski> If I have an ubuntu server I want to publish a bzr branch to, which sftp program should I use?  Or is there some package I should install that makes the server a great repo for bzr projects?
<jam> vreixo: I believe "bzr merge filename -r 364...." should do what yo uwant
<jam> hendrixski: I would probably just install openssh server
<jam> hendrixski: and possibly 'bzr' itself
<jam> if you want to be able to "bzr push bzr+ssh://server/"
<jam> There are other packages you might consider (trac+bzr, loggerhead, etc) but they all require a bit of setup.
<vreixo> jam: anyway it is fixed now. Thanks!
<jam> vreixo: Did the 'bzr merge filename' work for you?
<vreixo> jam: did not test, I had already reverted the other files...
<hendrixski> jam: yeah, I'm not looking for setup trouble.  just openssh does it eh? and I can push fun new branches to it whenever I want?
<jam> hendrixski: 'openssh' server and not client (of course), but yeah, it will provide sftp support
<jam> I would recommend installing bzr as well
<jam> but that isn't required
<hendrixski> k, actually, who knows, I might occasionally need to tweek something while on the server itself, bzr might be good there
<hendrixski> I would be able to access whatever bzr project is uploaded to the server, right?
<jam> hendrixski: generally
<jam> There is a lot of possibilities here
 * hendrixski tries uploading the project
<jam> mwhudson: what do you think about: http://pastebin.com/m49e6e411
<mwhudson> jam: looks good to me
<mwhudson> jam: it will make a small pile of tests fail
<jam> mwhudson: yeah, but I'll take care of those :)
<mwhudson> jam: my vote doesn't fully count though :)
<jam> mwhudson: well, when 4/6 core devs are AFK, there are only 2 of us to approve
<jam> so non-core's get a lot bigger say
 * LarstiQ plays innocent bystander
<jam> I guess there are a few that still have an official BB vote
<jam> like LarstiQ and jelmer
<hendrixski> jam: yay! it worked!  I needed python-paramiko first, but I got it.  Thanks for spotting me... it's the end of a work day
<jam> And I abuse them as much as I can right now
<LarstiQ> jam: I have not followed 1.6 development, considering its delay I gather some people were invested in getting stacking out.
<LarstiQ> it's a shitty situation you/we are in, that's for sure.
<jam> LarstiQ: well it is mostly just some of the auto-detection stuff that is acting badly
<jam> so I think if I just remove it, we can still have stacking
<jam> the user just has to request it
<jam> mwhudson: there is another possible fix
<jam> only set the "default_stacked_on" value when the development focus is in a format that supports it
<jam> mwhudson: what do you think about that?
<jam> (with the other fix being to have .clone() upgrade the branch the way .sprout() does.)
<jam> I'm not 100% happy with it, but I do feel some of this is LP's fault, and not bzr's.
<jam> LP is getting a bit pro-active, when it may not really be best for the users.
<jam> mwhudson: or it could be a project/user setting
<mwhudson> jam: certainly with hindsight we shouldn't have tried to get stacking-by-default working at the same time as just getting stacking working
<mwhudson> jam: but in general, in the long term, i think it's a really good idea for bzr push <lp:url> to dtrt
<mwhudson> jam: it's not like you want to be typing bzr push server:/path/repo/branch --use-repo server:/path/repo is it?
<fullermd> Now, if only it were entirely clear what the rt is   ;)
<jam> mwhudson: well you could have it a project setting, etc
<mwhudson> jam: yeah, i guess so
<jam> mwhudson: or as I mentioned, just notice that the dev target is in a valid format
<jam> thus it is valid for users' to get upgraded if they aren't yet
<jam> as the *project* is using an upgraded format
<mwhudson> wel...
<mwhudson> that still sounds pretty icky to me
<jam> mwhudson: no more icky than doing it to *all* projects
<jam> mwhudson: Also, I'm not planning on propagating this to bzr.dev
<jam> so you're still going to have a bunch of clients dying
<jam> but I guess you can hold off on rolling out the feature in LP
<jam> and you won't have to worry about a broken old client
<jam> old *released* client
<mwhudson> makes sense
<mwhudson> i think we can be a bit less forgiving for people using out-of-date versions of bzr.dev
<mwhudson> jam: btw, not sure if this is generally known, but the stacking policy will only be presented for a very few projects in the initial rollout
<mwhudson> (launchpad and storm, basically)
<jam> mwhudson: sounds like a whitelist to me :)
<jam> Just not one that you expose to the user yet
<jam> mwhudson: what is the bug # again?
<jam> bug #259275
<ubottu> Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [High,Triaged] https://launchpad.net/bugs/259275
<jam> found it
<lifeless> moin
<jam> mwhudson, LarstiQ, beuno: Any chance you could look over the patch I just sent to the mailing list?
<jam> lifeless: morning. I have a patch to review for 1.6
<jam> rc5 .. :(
<lifeless> jam: ok
<beuno> jam, sure. I'll look at it, however useful that may be
<jam> the Subject is: Disable automatic stacking via Bzrdir	control.conf
<jam> beuno: well, since lifeless is awake now, it can wait
<jam> lifeless: I'll be back in about 15 min, need to pick up my son
<jam> basically, something needs to be fixed, and I went the conservative "disable the feature" route
 * beuno lets leaves it to the experts
<lifeless> jam: I'm looking for it
<lifeless> jam: have you chatted with abentley ?
<jam> lifeless: he is on vacation along with martin and spiv
<lifeless> jam: oh wow
<lifeless> ENOTEAM
<jam> yeah
<lifeless> quick
<jam> not the best time to be working on a big release :)
<lifeless> lets do stuff
<jam> :)
<mlh> party!
<jam> get btree in core, right?
<lifeless> gc-as-default, nownownow
<lifeless> actually, I'm just reviewing your changes
<lifeless> You are aware I don't want to join the trees right? I just want to do a code drop
<jam> lifeless: really?
<jam> Why not join them?
<lifeless> I plan to keep on changing and tweaking blooms etc
<lifeless> and the format hook in stuff and so on is just ugly, it should not merge in , it should be refactored in core so its not needed
<jam> beuno, mwhudson, jml: Anything else for 1.6rc5 I'd really like to not need a rc6
<lifeless> 0730 for jml
<jam> well, nobody has said anything on the ML, but it seems that every day someone drops yet another thing
<beuno> jam, I've been using it without any problems. Of course, I haven't done any weird contortions with it
<jam> well, I'll put together 1.6rc5, and just not make it a final announced thing until more people have woken up
<jam> this bugfix isn't quite as critical as the rc4 one
<lifeless> jam: if you feel strongly we should do a merge, we can, but I wasn't thinking of this as something we'd incrementally merge from, I was thinking we'd instead be dropping in a new different format if we add blooms later
<lifeless> (index format that is)
<jam> lifeless: well, it is really only a couple of test cases, and then one or two files, I guess it doesn't really matter either way.
<jam> I can always use 'add --file-ids-from' rather than doing a merge
<lifeless> I can't find your mail
<lifeless> ah yes, totally disconnected thread name :P
<lifeless> rockstar: you wanted to chat, I don't think the text got past your fingers though
<rockstar> lifeless, I was trying to get the cscvs tests to run.
<lifeless> make check? :)
<rockstar> lifeless, ah, was using test_all, and one of the tests was hanging.
<lifeless> got an onboard rng?
<lifeless> reprhasing - where was it hanging :)
<rockstar> testInitProtocolBadHost
<lifeless> rockstar: check your dns etc
<rockstar> What would I check for?  It works.
<rockstar> Maybe I'm missing something specific?
<LarstiQ> mwhudson: thumper seems to be awake
<mwhudson> LarstiQ: eh?
<lifeless> rockstar: look at what the test does
<LarstiQ> mwhudson: hmm, I thought you wanted to consult with him or jml.
<mwhudson> LarstiQ: i wanted them to see the conversation in here
<LarstiQ> ah.
<mwhudson> LarstiQ: but thumper told me (somewhere else) that he was reading backlog
<LarstiQ> mwhudson: I should not try to meddle with other's afairs.
<LarstiQ> and go to bed, really.
<mwhudson> LarstiQ: no worries :)
<thumper> night LarstiQ
<mwhudson> g'night
<LarstiQ> night thumper :)
<LarstiQ> and mwhudson (and the rest)
<lifeless> vila: ping
<lifeless> beuno: indeed it is
<lifeless> beuno: I was muttering about 1.6.1 :)
<beuno> lifeless, what is?  I've been jumping from screen to local irssi, so I'm missing a lot of context  :)
<lifeless> beuno: 1.6 w/ loggerhead.conf
<beuno> lifeless, ah, so you're proposing a 1.6.1 release with the start-loggerhead fixes in it?  That seems like a good idea
<lifeless> beuno: I'd like http://squid-cache.org/bzrview/ not to look like vomit :O)
<lifeless> beuno: and yeah, the admins there, like admins everywhere, tend to prefer running releases
<beuno> lifeless, agreed.  I'll bump it up to the top of my list and fix that tomorrow.
<lifeless> beuno: if you wanted to add the options for prefix and port to serve-branches, we'd be happy to switch to that too :)
<beuno> lifeless, yeah, I'll actually do that too. I'll file a bug, and add a milestone so I don't forget stuff
<lifeless> sweet
 * beuno goes walk the dog before it explodes
<beuno> mwhudson, btw, I'd like to talk about our next release at some point. Is it going to be 1.7?  (short cycle)  1.8?   I haven't created it yet, and I keep forgetting to ask at time you're actually around
<mwhudson> beuno: so my (vague) idea about this was that a bit before each bzr release (say around the beta) we decide if it's worth doing a loggerhead release
<mwhudson> beuno: for 1.7, i'd be a bit surprised if we get enough done to be worth it
<lifeless> mwhudson: release often
<jam> beuno: how did the 'scripting' attempt go today?
<jam> I don't see a doc patch yet :)
<pickscrape> Poor beuno :)
<jam> I just bring it up because I have an rc5 tarball, which may make it to an upload if jml and thumper don't have anything else to say to me
<thumper> jam: I'd rather see 1.6 get out
<jam> anyone know when jml might wake up?
<beuno> mwhudson, ah, ok. So we just fix bugs until we decide on a release?
<beuno> jam, no scripting today. Didn't get to 3/4 of the things I was planning to  :(
<mwhudson> beuno: yeah, i reckon so
<beuno> mwhudson, fair enough
<mwhudson> beuno: though as lifeless says, our threshold for 'worth it' should be pretty low
<beuno> I'm off to a long and painful dinner then. bbl!
<beuno> mwhudson, agreed. Let's try and not delay it for more than 2 months or so
<lifeless> I'd do it monthly with bzr
<lifeless> just because
<lifeless> releases -> visibility, improvements etc
<vila> lifeless: pong
<jam> vila!!!!
<vila> :D
<lifeless> vila: when do you start?
<vila> in 56 hours ? :-D
<lifeless> LOL
<vila> lifeless: august 22th at dawn, until then I'm still full, but what was your ping for ?
<lifeless> curiousity :)
<vila> ok :)
<lifeless> man too much homepage wiki spam
<vila> I'll go to bed then, see you soon...
<lifeless> gnight!
#bzr 2008-08-20
<james_w> hey vila
<james_w> welcome back, good to see you
<jam> lifeless: the problem is that once you sign up for a bazaar-vcs account, the first link it gives you is your personal page, and then you follow it and it wants to create it for you.
<jam> So the *sign-up* procedure encourages it
<lifeless> yes
<lifeless> I wonder which page to edit to fix that
<jam> lifeless: I'll try to ping newz tomorrow to ask
<jam> lifeless: do you think there might be an obvious way to make the 'three_level' test go faster?
<jam> 60s for a test is a bit ugly
<jam> I guess it is 68s, and iter_all is 81s
<lifeless> well
<lifeless> make the code faster :)
<jam> I'm at least tempted to profile it and see if there is anything obvious
<lifeless> on the dirstate corruption
<lifeless> the change I'm proposing for locks should help that too :P
<jam> there are lots of ways around it
<jam> just getting rid of the write-in-place will help
<jam> however we go about it
<jam> assuming it is the truncate() causing the problem
<lifeless> yah
<lifeless> thats true
<technomancy> does bzr support inline branches?
<lifeless> I don't know what that means
<technomancy> it means creating a new branch in the same directory and being able to switch between them without changing directories
<bob2> no to git-style branches, yes to switching one working copy between branches in a repository
<technomancy> gotcha
<lifeless> technomancy: we have a bzr switch command that can switch branches in a single working dir
<lifeless> technomancy: and we have cheap branches (they are 'bare' - no source files)
<technomancy> so if I've got my own branch checked out in one directory and a friend's checked out in another, I can't exactly just "bzr diff" them, can I... how does that work?
<lifeless> bzr diff -r branch:otherdir
<technomancy> aha; thanks!
<technomancy> I heard Emacs was planning on migrating to bzr, does anyone know how that's going?
<technomancy> nobody in #emacs seems to know; heh.
<mwhudson> there's a bzr mirror of the emacs trunk
<technomancy> yeah, but afaik that's still all unofficial
<mwhudson> and i think there are some performance concerns, at least some of which are fixed
<mwhudson> but i guess right now a whole lot of nothing is happening :)
<technomancy> right; it sounded like they were waiting for some more perf fixes... Emacs is one of the oldest extant projects in any version control system, so it makes sense that it would be a good deal more taxing than your average launchpad project. =)
<mwhudson> it's not actually that big
<mwhudson> it's only 80k mainline revisions or something
<mwhudson> which, yeah, is on the large end, but it's nothing compared to OOo :)
<technomancy> interesting. Yeah I was thinking more in terms of years than any actual measurements I had read.
<mwhudson> oh probably yes
<technomancy> can you diff with a branch straight from launchpad that you haven't checked out locally yet?
<technomancy> oh wait, I  think I can figure that out.
<technomancy> yup, that worked
<technomancy> is there any way to automate file downloads when you cut a new release in launchpad, or do you have to create your tar/zip files manually and upload them through the web interface?
<james_w> technomancy: that last question may be better asked in #launchpad
<technomancy> oh, of course
<james_w> I don't know the answer myself, sorry
<lifeless> jam: don't suppose you are still around ?
<jml> lifeless: got an eta for reviewing https://code.edge.launchpad.net/~jml/testresources/tests-meaning-cleanup?
<lifeless> 'soon'
<lifeless> whee
<lifeless> 10 second saving on cold-cache stat
<jml> lifeless: fair enough
<jml> lifeless: also, 10s on cold-cache is pretty good.
<jml> lifeless: if you have a look at the TODO file I've added, then that'll unblock me for further work.
<lifeless> jml: 1m5 to 53 seconds
<lifeless> jml: k
<jml> lifeless: does the saving translate to hot-cache?
<lifeless> maybe
<lifeless> call for testers coming this afternoon
<jml> heh
<jml> lifeless: well, I'm offline until this evening. maybe I'll talk to you then.
<lifeless> okies
<xshelf> can you have the bazaar mailing list available on www.opensubscriber.com
<xshelf> it really has a cool (soothing) interface to reading mailing lists
<xshelf> anyone here personally interested in brz-perforce-bzr interface?
 * jamesh hasn't had to use p4 since 2001 and is happy to keep it that way
<lifeless> xshelf: you can probably get bazaar on opensubscriber yourself
<xshelf> lifeless: The mail I send to bazaar for subscription requires auth confirmation which opensubscriber does not support
<xshelf> lifeless: So, the list maint needs to bypass confirmation for this mail address
<lifeless> oh
<jamesh> I guess that is a way of only archiving lists with admin approval
<xshelf> you can also reply to author or group with that interface
<xshelf> with Yahoo supporting only 15 filters, I run out of filter space if I subscribe to multiple lists!
<xshelf> Hence, I prefer a one stop shop of reading lists
<mwhudson> man we're going to get a lot of mail when aaron gets back and restarts bb
<bob2> gmane!
<chmac> I'm not clear from http://bazaar-vcs.org/NestedTreeSupport on the status of nested tree support. I'm reading posts from early 2007 which say it's "soon"...
<chmac> Can anyone give me a more up to date view?
<chmac> Ok, this seems like what I'm after http://bazaar-vcs.org/NestedTreeProgress
<chmac> Last update was May 07 though, anyone know if any progress has been made since then?
<beuno> chmac, yeah, that hasn't happened yet
<beuno> you can ping LarstiQ
<beuno> and make him feel guilty about it
<beuno> that's what I do
<chmac> :)
<chmac> LarstiQ: Nested Tree support? When's it gonna happen? :)
<beuno> maybe even email the list to get the subject re-started
<chmac> beuno: I'm considering bzr vs svn for a new project.
<chmac> It's managing WordPress installations, and keeping the up to date
<chmac> So I was thinking to use nested trees to keep the plugins up to date
<beuno> chmac, well, we have something really cool, which is the "bzr-upload" plugin
<chmac> I only need very basic support, to add a nested tree, to update it to the latest version, and then to roll it back to a previous version if necessary
<chmac> beuno: Cool, let me check that out...
<beuno> which will let you upload *just* the working tree, and *just* what has changed since the last upload
<beuno> right, nested trees don't currently work, so I wouldn't go down that path just yet
<chmac> beuno: Ok, bzr-upload looks very interesting
<chmac> It would allow me to keep the code in one central location, and push updates selectively to remote hosts
<beuno> chmac, and not just because I'm onw of the authors. It actually works  :)
<chmac> That might bypass my need for nested trees, as I could simply push plugins separately
<chmac> :)
<beuno> chmac, yeap, that's the idea. Mainly aimed at web-dev
<chmac> https://launchpad.net/bzr-upload/+download:
<chmac> No download files exist for this project.
<beuno> chmac, yeah, we haven't made an official release (will soon)
<beuno> so, to install it:   mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload
<beuno> if you're on linux
<chmac> Ubuntu :)
<beuno> cool, the above should work then
<beuno> and you're set
<chmac> beuno: Will it allow me to push a previous revision without rolling back my "working copy" ?
<beuno> chmac, yeap, just specify -r X
<chmac> :)
<beuno> and, if you find you need features that aren't there, file bugs, we'll get it done  :)
<chmac> beuno: Now that's what I want to hear! :)
<chmac> It's checking out now...
<chmac> beuno: Will it support ssh host definitions? So sftp://blah/some/path/ ? Automatically picking up my ssh key and so on?
<chmac> beuno: When I run `bzr help upload` the first line is "Unable to load plugin 'upload' from '/home/me/.bazaar/plugins'"
<chmac> Yet it outputs the help just fine...
<beuno> chmac, how odd...
<beuno> can you take a peak in ~/.bzr.log?
<beuno> you should have a traceback
<chmac> beuno: http://pastebin.com/d4cc40f5f
<beuno> chmac, what version fo bzr are you using?
<beuno> smells old
<chmac> Bazaar (bzr) 1.3.1, latest in Ubuntu 8.04
<beuno> chmac, hrmm...  mind filing a bug that it doesn't work with 1.3.1, and upgrading to 1.6rc3?  https://launchpad.net/~bzr/+archive
<chmac> beuno: Happy to file a bug. It does actually produce the output ok though.
<chmac> Shall I try a test upload to see if it works?
<beuno> chmac, yeah, it will work. It's the "auto" feature that won't.
<chmac> Ok
<beuno> chmac, I'll file the bug, don't worry
<beuno> upgrade, and the message will be gone
<chmac> beuno: Ok, great, if you need anything else from me, just let me know
<beuno> chmac, you've already found a bug, plenty help already  :)
<chmac> :)
<beuno> chmac, bug #259647 if you want to subscribe
<ubottu> Launchpad bug 259647 in bzr-upload "auto feature doesn't work with older bzr versions and tracebacks" [Undecided,New] https://launchpad.net/bugs/259647
<chmac> beuno: nice, just subscribed, and running `apt-get update` to install the latest bazaar, thanks for all this
<beuno> chmac, happy to help, and, especially, welcome new users   :)
<chmac> Looks like the Thai ubuntu mirror is out of date, time to find an alternative...
<beuno> it should download from PPA, not ubuntu mirrors
<chmac> beuno: Yeah, but the `apt-get update` was failing because of a mirror issue
<chmac> Seems to be running ok now against Taiwan :)
<jpds> chmac: A list of Ubuntu archive mirrors may be found here: https://launchpad.net/ubuntu/+archivemirrors
<chmac> jpds: System > Software Sources has a neat tool which checks the mirrors and determines which one is fastest, turns out Taiwan is faster than Thailand in Bangkok :)
<beuno> yeah, I use brazil
<jpds> chmac: Oh, that's neat. Didn't know that.
<beuno> chmac, I'm off for the night. Good luck with that, and feel free to hang around here and ask questions. Everyone is very friendly here  :)
<chmac> beuno: Thanks again :)
<gour> morning
<gour> is there release date scheduled for 1.6?
<thumper> gour: btw, doing a branch of ghc inside a shared repo (generating a tree) takes about 6s without hardlinks
 * thumper is away
<gour> thumper: heh
<markh> kinda off-topic, but can anyone lend me a clue about how I can filter launchpad bugmail using gmail?  It doesn't recognize the mail as coming from a list
<markh> (its bzr bugmail I most need to filter, which is why the question isn't completely off-topic ;)
<chmac> Anyone familiar with the bzr upload plugin around?
<chmac> beuno said it leaves a file on the server to track what version was last uploaded. I'd like to see a demo of that file, where it's placed, the filename, and so on...
<mwhudson> chmac: i guess you can go bzr upload bzr+ssh://localhost/tmp/test and look in /tmp/test :)
<mwhudson> (or however it works)
<chmac> mwhudson: Hadn't thought of doing it to localhost, that's an idea... :)
<chmac> Turns out it's crashing on my machine, I'm not running a late enough version of bzr
<chmac> Upgrading caused hassle earlier, I'll try it again...
<chmac> If I grab bazaar from ppa.launchpad to get the latest version, I can't also get bzr-svn there can I?
<chmac> When I try to install the latest bzr it's failing because bzr-svn depends on it, but there's no newer version of bzr-svn
<mwhudson> i uninstalled the bzr-svn package and stuck trunk in ~/.bazaar/plugins/svn
<chmac> mwhudson: Is it that easy?
<chmac> I love me some bazaar... :)
<MvG> Hi! I'm looking for some features in bzr, and would be interested to learn if they are available already, or if not, if they have been discussed before, and what you know about the status of them.
<MvG> One would be a way to merge distinct branches. Say you have two projects that started as independent branches, but they grow together with interdependence in both directions, so they should be merged into a single source tree. Is there a way to do so which would maintain the revision history of both parts from before the merger?
<uws> MvG: i thought there was a (kludgy) trick for that
<MvG> The second would be an analogous to the "svn cp" command. When you refactor a file, it makes sense to have two files descend from a common previous file, so that again lines in both files can be attributed to revisions before the split. Is there any way to achieve this in bzr?
<uws> MvG: Something with "use the null revision as the merge parent" methinks
<MvG> uws: Would that work with rich root repos, where even the root dir has a file id? Do you know how I would formulate that on the command line?
<MvG> cd tmp
<MvG> Sorry, wrong window...
<chmac> I'm getting this error when trying to check out bzr-svn:  ERROR: Invalid http response for http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/.bzr/repository/packs/bffc0ecb67b4c56b089ca948c85597dc.pack: Expected a boundary (nDMiLeDyiK0rv.WGnkX:) line, got ''
<chmac> Any suggestions?
<uws> MvG: Something like  bzr merge /path/to/other/branch -r 0..12345   where 12345 is the tip of the other branch
<uws> MvG: backup/try first, it might do strange things
<MvG> uws: At least on a test repo that looks very promising. -r 0..-1 would be the generic way. Thanks a lot, that will be helpful!
<uws> MvG: yw.
<uws> MvG: let me know if you know about the "cp" thing :)
<MvG> uws: Sure.
<MvG> chmac: "bzr branch http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4" works for me, with current bzr.dev. Was that the command you tried? You might try branching http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead.
<chmac> MvG: That wasn't the command I tried, I was trying `bzr co lp:bzr-svn ~/.bazaar/plugins/bzr-svn/`
<chmac> But I'm trying your command now
<chmac> I'm also reading https://bugs.launchpad.net/bzr/+bug/198646
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released]
<chmac> It looks like bazaar can cause issues with firewalls, I'm in Thailand, so everything runs through a transparent proxy
<chmac> I'm trying to run the command via tsocks, but that doesn't seem to be working either...
<MvG> chmac: You can register an ssh pubkey with launchpad, then the lp: branches will convert to bzr+svn, which might work better.
<chmac> MvG: That sounds like a plan...
<chmac> I'll be in Australia on Sunday and will probably not have this issue, but the ssh option is probably sensible anyway...
<gnomefreak> what does bzr: ERROR: Path(s) are not versioned: debian/changelog  mean? see: http://pastebin.mozilla.org/520727 for changelog
<gnomefreak> it looks perfect to me. i get it when trying to commit changelog
<MvG> If this transp. proxy is repeatedly causing you trouble, I would probably start looking for ways to avoid it when the need arises. Most of the ideas I can think of right now do require a host on the outside through which you can relay things, though.
<MvG> gnomefreak: It means that the file is not under control of bzr. If you just created it (like it seems), you should call "bzr add debian/changelog" first.
<MvG> gnomefreak: "bzr status" is useful to tell you about files not yet added.
<gnomefreak> i found issue
<gnomefreak> i forgot to add debian/
<chmac> Woohoo, it worked via tsocks after all :)
<chmac> Gotta love ssh! :)
<gnomefreak> will commit take several files at a time if i list them "bzr commit rules control"?
<MvG> gnomefreak: Sure. Why not simply say "bzr commit" to commit all your changes in one bunch?
<gnomefreak> MvG: what changelog on a separate commit
<gnomefreak> i want
<gnomefreak> not what
<MvG> Does anybody know whether bundlebuggy is ill? Haven't been able to reach it lately, connections always time out.
<MvG> uws: Found http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/45083 by Martin Pool which says the feature is wanted, but not yet implemented. Still hunting for the references.
<MvG> jelmer: How does bzr-svn handle copied files from svn? Do you have an elegant way of representing the copy, whcih would be suitable for non-svn use cases as well?
<MvG> Oh, I guess not, as you are the author of http://bazaar-vcs.org/BzrFileCopies and the corresponding https://launchpad.net/bzr/+spec/filecopies is marked "not started". uws, I think that sums it up so far.
<uws> MvG: I'm not the author of that page :)
<MvG> uws: No, sorry, that was addressed to jelmer.
<MvG> Should have been more clear.
<uws> MvG: it's ok.
<uws> thanks for the pointer
<MvG> http://bazaar-vcs.org/DraftSpecs/PathTokens seems worth reading as well.
<MvG> lifeless: Your path tokens approach, are they intended to replace file ids? Or be an additional tool along file ids for cases where file ids don't get the job done by themselves?
<lifeless> MvG: replace
<lifeless> MvG: or more accurately, implement copy in the file id model
<MvG> I believe I can see the issue in both your use cases, but I have doubt that a single approach would be fit to address them both.
<MvG> As I understand it, the file tokens for copy would depend only of the history of the files involved, whereas the working with different trees in the parallel import scenario would be based on some user configuration, ore some perhaps costly automatic search for a common ancestor.
<MvG> For copy/merge, a DAG of file ids might serve as a token. I have some ideas how to implement this, although I don't know how they would agree with the current infrastructure. But I can see no way to generalize this for parallel imports.
<MvG> lifeless: If I want to put some ideas into words, should I do so in the wiki, or add comments on launchpad, or discuss them here?
<lifeless> MvG: well for parallelimports tokens would work by allowing a join to take place at the first time both trees are examined
<lifeless> the mailing list is probably the best place to describe thoughts on this
<MvG> lifeless: Ah, so you don't want to seamlessly handle distinct imports in all commands, but instead want a single command to join the trees, which does specialized work, and continue from there handling things as two related branches, right?
<MvG> I'm starting a mail to the list. Thanks.
<lifeless> MvG: actually, I mean that 'merge OTHERIMPORT"
<lifeless> will see separate tokens for conflicting file paths
<lifeless> and depending on what we decide works best UI wise, with either have an option to enable, or disable, joining the tokens where the file path conflicts exist
<lifeless> when you commit that merge, you will have created a join in the per-file dags, and subsequent merges in either direction will not conflict
<MvG> Makes sense.
<lifeless> this should be fast - the number of token changes in two parallel imports will be 1 each, and user friendly
<MvG> How about this case: I have a private parallel import, and for some reason I want to merge that branch into an official branch, not the other way round, and continue working on these two in that fashion. So I myself would want to join the DAGs, but it wouldn't make much sense to push these joins anywhere, as noone else can make any use of the IDs from my private branch in any case. I would want a "private, unpushable join". Do you consider this scenar
<lifeless> it cut off at 'do you consider this scenar'
<MvG> ... this scenario to be of any relevance at all?
<lifeless> well
<lifeless> I don't really understand the scenario
<lifeless> you want to merge a private branch into the official branch
<lifeless> but you don't want to merge your history?
<lifeless> ignore implementation details for now
<lifeless> (file ids & file tokens are implementation details)
<lifeless> MvG: still there?
<MvG> lifeless: been AFK ... catching up now.
<MvG> I want to merge the history, but I want to filter which part of the history I publish, I think.
<lifeless> can you be more specific?
<lifeless> (I'm still not understanding the use case)
<MvG> Let's try a set of examples.
<MvG> I create a branch "checkout" from an upstream repo and a branch "tarball" from a tarball.
<MvG> I do "cd checkout; bzr merge ../tarball" or some such.
<MvG> Now when I do "bzr log", I want to see a forked hiostory for the files, as they come from the tarball and the checkout.
<lifeless> sure
<MvG> But when I push the branch, I might wish the option of hiding all the joins, so people think that files changed in the tarball were modified by me, and files just present in the tarball were newly added by me.
<lifeless> well the forked history would show that anyway
<MvG> The forked history would register a different branch from which files have been merged, up to the initial import of the tarball.
<MvG> On my system at least.
<MvG> Gotta go now, I'll write the mail later today, and include this scenario for discussion once I have thought more about it.
<lifeless> showing a fork and showing you as having made changes/added files are not mutually exclusive options
<lifeless> anyhow, I think you could do revert --forget-merges after doing a merge to mainline; not sure why you would want to
<cyberco> Hi! One of my branches (actually the trunk) has a parent branch ('bzr info' says so) that it doesn't need (since it is itself the trunk). Can I remove the parent branch?
<james_w> cyberco: only by editing .bzr/branch/branch.conf currently
<LarstiQ> not that it's particulary important to do so.
<cyberco> james: ok, sounds a little dangerous (being new to bzr). I guess it won't do any harm there is still a parent (that doesn't exist anymore), will it?
<LarstiQ> cyberco: no, it is only used as a default for things like `bzr pull` when you don't supply any arguments.
<cyberco> ok, that's no problem then
<LarstiQ> indeed :)
<LarstiQ> cyberco: in case you want to change it, bzr pull --remeber some/other/branch would do it.
<LarstiQ> cyberco: maybe not for trunk, but will come in handy for others.
<cyberco> another question. On the server I've branched my trunk to 'workbranch'. Then I branched it to my local machine using sftp. But when I try to push my changes back to the 'workbranch' on the server I get the message: "This transport does not update the working tree"
<LarstiQ> cyberco: right
<LarstiQ> cyberco: if you don't need the working tree there (and I suspect you don't), then I'd blow it away on the server with `bzr remove-tree`
<cyberco> larstiq: which means that the files will be removed but not the bzr info?
<LarstiQ> cyberco: exactly.
<cyberco> cool
<LarstiQ> cyberco: in the case you did want to have a working tree there, the message is harmless, .bzr is still updated. You can `bzr up` on the server to update the working tree, or use a plugin like push-and-update to do that everytime you push. (Or bzr-upload if you don't want .bzr, say, website deployment)
<cyberco> Yes, that was what I figured, but I don't need a 'working tree' on the server, so I thought that was a lot of hassle. But, alas, things work wonderful now! Thanks for your help
<cyberco> I'm really impressed with bazaar
<LarstiQ> thanks :)
<gour> LarstiQ: lifeless anyone free to share some point with main ghc dev (JaffaCake in #ghc) ?
<LarstiQ> gour: I'll join, but I can't guarantee anything
<gour> LarstiQ: ok.
<grutte_pier> has anyone experience in setting up a http bzr repository protected by an .htaccess file?
<LarstiQ> gour: in general, there are more eyes in here, so I would recommend asking questions here. But I recognize the value of hopping over to their community for help.
<LarstiQ> gour: I just wish I was better at giving it.
<gour> yes, but let's take whatever opportunity which arises
<LarstiQ> ok
<cyberco> how are commit rights normally arranged? By standard OS file access control?
<LarstiQ> cyberco: yes.
<LarstiQ> grutte_pier: not me.
<grutte_pier> cyberco: from the hasseling I'm having now with .htaccess I would say yes
<fbond> Heya, svn has --stop-on-copy to show log from branch point forward.  Does bzr have anything like that?
<grutte_pier> my problem is that even with a authentication.conf file, I keep getting a 401: Authentication requested error,that bzr doesn't deal with...
<moya> I need to publish branches over http, I can not find documentation about it in the user guide, any hints ?
<fbond> I guess I can use `bzr log -r ancestor:foo..`.
<grutte_pier> moya: same here! I think you'll need the WebDAV plugin to do that
<grutte_pier> moya: you are not coincidentally trying to protect you're branches by a .htaccess + .htpasswrd file are you?
<grutte_pier> moya: https://launchpad.net/bzr.webdav
<moya> grutte_pier:  yes I am
<moya> grutte_pier: using LDAP instead of .htpasswd file
<james_w> you want people to be able to push over http as well?
<moya> james_w: yes, I'd like everything possible available over http
<LarstiQ> grutte_pier: access the branch by http://user@host/...
<james_w> yeah, you need either webdav, or the smart server
<grutte_pier> LarstiQ: that gives an error as well: PathNotChild: Path 'http://host' is not a child of path 'http://user@host': user name mismatch
 * LarstiQ blinks
<grutte_pier> maybe host is not allowed to be a www. adres?
<cyberco> grote_pier:) Do you have links where these "commit rights" access-issues are described?
<LarstiQ> grutte_pier: what version of bzr are you using, and can you pastebin the traceback for that?
<grutte_pier> cyberco: no links yet
<grutte_pier> LarstiQ: version 1.5... but I've been having the problems with all previous versions
<grutte_pier> LarstiQ: I'm not sure what a 'pastebin' means..... :(
<LarstiQ> grutte_pier: http://rafb.net/paste/
<grutte_pier> LarstiQ: great facility ;) http://rafb.net/p/7cPcjb41.html
<LarstiQ> grutte_pier: there are tons of these pastebins around, rafb is just the one I can remember
<Leonidas> hi, am am trying to use the api of bazaar and wanted to ask you guys how to get the permissions of a file in bzr.
<LarstiQ> Leonidas: I'm not sure what you mean.
<LarstiQ> Leonidas: do you mean, what are the unix permissions of a file in a historical revision?
<Leonidas> LarstiQ: Now, when I have a revtree I can get a files contents via a StriongIO object. But I'd also like to get the special attributes like link, executable etc.
<LarstiQ> Leonidas: ah ok, right, those we do track. But everything other than executable we do not.
<robsta> ping Jc2k
<Leonidas> I think exacutable and link is the only thing I need to know anyway.
<Leonidas> There is revtree.is_executable, but what about links?
<Jc2k> robsta pong
<LarstiQ> Leonidas: is there one specific file you are interested in, or do you need to handle all files?
<robsta> hi Jc2k, i'm trying to reach bkor for 2 days now, to help out with the bzr/svn maintainter script workaround, but to no avail
<robsta> Jc2k: any alternative?
<Leonidas> LarstiQ: I just need it for one file at the moment (I the future I might better use a cache for this, but first I wanted to get it working).
<grutte_pier> LarstiQ: same story for test release 1.6
<LarstiQ> Leonidas: well, there are iter_entries type apis for the latter.
<LarstiQ> Leonidas: revtree.kind(fileid)
<LarstiQ> grutte_pier: ok, back to your problem
<Leonidas> LarstiQ: thanks, I'm trying but I am struggling a bit with IPython, it somehow chokes on exceptions.
<LarstiQ> Leonidas: you can %pdb in ipython for dropping you into a debugger when that happens, but can you provide some more info?
<LarstiQ> grutte_pier: https://bugs.edge.launchpad.net/bzr/+bug/245964 looks ort of similar
<ubottu> Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released]
<Leonidas> LarstiQ: well, it seems to be rather IPython related: http://paste.pocoo.org/show/82797/
<LarstiQ> Leonidas: wuh
<LarstiQ> Leonidas: it barfs on getcwd()?
<Leonidas> LarstiQ: oh, indeed.
<LarstiQ> grutte_pier: is there a redirect going on perhaps?
<grutte_pier> LarstiQ: yep, there is... this looks indeed very familiar
<Leonidas> LarstiQ: I have deleted the directory it was in. Just fixed it by chdiring somewhere else.
<LarstiQ> Leonidas: ok :)
<Leonidas> Mhh, that might explain my earlier troubles with it. Sometimes I delete branch folders from one of my numerous screen sessions.
<grutte_pier> LarstiQ: when taking another close look at my traceback, the remarks in bug 245964 make sense as well
<ubottu> Launchpad bug 245964 in launchpad-bazaar "nosmart+http interacts badly with http redirects" [Critical,Fix released] https://launchpad.net/bugs/245964
<grutte_pier> LarstiQ: in the bug they speak of some comparison and indeed the error in my traceback, is that http://host/.bzr/smart is compared with http://user@host/ .... without the additional .bzr-path
<grutte_pier> LarstiQ: it makes sense that something is going wrong there, because they are simply different paths
<grutte_pier> LarstiQ:with nosmart+http the same problems happens with .bzr/smart replaced with .bzr/branch-format
<LarstiQ> grutte_pier: well, foo/.bzr/etc is a a child of foo/, our problem is that foo isn't foo.
<LarstiQ> grutte_pier: I'm not exactly sure why that arises.
<LarstiQ> grutte_pier: and I really need to go out and buy breakfast
 * LarstiQ heads to the AH, oh no, aldi.
<LarstiQ> grutte_pier: I'll get back to you on this.
<Necoro> hey :)
<Necoro> every time I push via FTP - all .bzr files which are altered get the permissions 0600 ...
<Necoro> but this blocks access from the HTTP-server
<Necoro> so I can't pull via http any more
<Necoro> is it possible to make bzr change the default permissions to 0644 ?
<beuno> james_w, hi
<james_w> hey beuno
<beuno> how's it going?
<james_w> good thanks, you?
<beuno> pretty good too
<beuno> I'll be in London again next week, if you want to/can drop by  :)
<james_w> ah cool
<james_w> next week isn't great for me though, sorry
<beuno> no worries, next time (which, for now, seems to be october)
<james_w> cool
<james_w> you're travelling a lot?
<beuno> heh, yeah, seems like it's going to be like this for quite a while
<LarstiQ> beuno: how so?
<beuno> LarstiQ, hi. Well, I have 3 trips already planned from here to december, and a few "maybes"
<LarstiQ> I see.
<beuno> everytime I start to complain about 14 hour plane trips, I remember australian folks do 24+  :)
<jam> Necoro: I don't think we chmod over ftp, but I could be wrong
<jam> if we *do* then setting the permissions on the '.bzr/' directory itself should cause us to set permissions on files correctly.
<jam> But my guess is that it is an ftp server thing, and something outside of bzr's control
<jam> beuno: I'm a bit surprised their bringing you to London so often, I suppose it depends if you enjoy it or not whether I should be congratulating you or expressing sympathy :)
<Necoro> jam: on my local branch the permissions are correct
<Necoro> so - perhaps it is really a server thing
<jam> Necoro: TODO: jam 20051215 ftp as a protocol seems to support chmod, but
<jam>         ftplib does not
<jam> Necoro: but I also see a "SITE CHMOD" command
<jam> So it seems that the server *might* support chmod
<beuno> jam, heheh, well, I *do* enjoy the sprints. Actual plane flights, not as much, but I'm getting used to them. I guess my work needs more high bandwidth interaction
<jam> Necoro: we generally set permissions based on the .bzr/ directory
<jam> beuno: just hack on the plane, right?
<jam> lifeless does that
<jam> you can get some interesting work out of him before/after sprints
<jam> Necoro: so if the .bzr/ directory is set 700 we will create files as 600
<jam> if it is 777 we should create files as 666
<beuno> yeah, I really have to start upgrading to business class, where they have plugs for laptops
<jam> Necoro: that, of course, requires the ftp server to support both stat and chmod
<jam> Necoro: hm... I see a possible problem. It seems that our code doesn't detect ftp permissions correctly, but it does try to *set* them. :(
<jam> vila: ping, just curious if you know about the SITE CHMOD work
<beuno> jam, all debs uploaded, moving on to docs tweaks
<jam>  /cheer
<jam> I guess I should announce then
<beuno> jam, yeah, and possibly blog about it?  warn people this is the last RC, so, speak now or forever hold your complaints
<Odd_Bloke> jelmer: I just got http://paste.ubuntu.com/39158/ when attempting to commit to the Python Applications Packaging Team's SVN repo.
<Odd_Bloke> I get much the same when I commit locally and attempt a push (same SVN exception).
<jam> Odd_Bloke: it looks like a directory isn't there any more, are you sure the URLs are all correct still
<jam> beuno: I suppose
<jam> I just feel a bit like I'm hammering people with 5 release candidates
<jam> when it is typically only 1
<jam> the fact that I've released 4 of them in < 1 week
<fullermd> Well, you could have hammered then with 4 releases in a week instead.  That would have gotten plenty of attention...
<jam> beuno: also there is a trivial bit incorrect with 1.6rc5, the date in NEWS is wrong. I don't know if it is worth doing anything about it.
<luks> rc6 with a changelog bugfix! :)
<Odd_Bloke> jam: This was on a fresh checkout of a freshly created folder.
<fullermd> Then rc7 for the changelog bug of forgetting to put rc6 in the changelog.
<beuno> jam, I'm sure people will forgive an incorrect date in NEWS  :)
<jam> luks, fullermd: Well, Peng teased me that there will be a 1.6rc7, so I need to avoid that one :)
<jam> I'll just skip to 1.6rc8
<moya> I have created a repo with bzr init-repo --no-trees in /srv/bzr and published that dir via web using dav, when I try to access it bzr complains with: ERROR: Target directory http+webdav://localhost/bzr/ already exists, but does not have a valid .bzr directory
<fullermd> That would make perfect sense, actually.
<fullermd> If you skipped rc6 too, that would make the 5th rc in the week, and 1.6 is 8/5.
<jam> fullermd: exactly :)
<beuno> jam, patch sent. I'm moving to the office, will put together a draft on what the script should do and send it to the list. Then I move on to stuff I need to do in these channels  -->
<fullermd> Mmmm.  1.6 stopped using some of the smart server verbs we were using, right?
<jam> fullermd: right
<beuno> (moving to the office == 15 minutes AFK)
<jam> beuno: I thought you just ignored the .bzr dir rather than deleting it
<Odd_Bloke> There is a /www/policy.txt in the SVN repo, but I don't know why it's looking at it (as I'm in a completely different place).
<Odd_Bloke> jelmer: jam: ^
<fullermd> Would that be why a remote missing is taking over a minute to a 1.5 server now, instead of the merely absurd 25 seconds 1.5 takes?
<fullermd> It seems to churn for a very long time before the "You are missing xyz revisions" line.
<beuno> jam, it created problems last time. lamont implied it didn't get added, but it did last time I tried, so I'm adding it just in case
<jam> beuno: you sure you did both -I.bzr and -i.bzr ?
<beuno> jam, I did what the PPA docs say:  debuild -S -sa -i -D
<jam> beuno: I thought lamont's recommendation was to do
<jam> debuild -S -sa -i -D -I.bzr -i.bzr
<jam> Or at least, he configured it to do that in his ~/.something
<luks> why not use bzr-builddeb for the packages?
<jam> luks: a few reasons
<beuno> jam, I didn't quite understand that part, so I went down a different path. I'll be happy to go over the docs with him if he has time
<jam> 1) We add the intermediate compiled .pyx => .c files so people don't need pyrex to build the bzr source
<jam> And AFAIK bzr-builddeb doesn't allow adding intermediate files
<dato> jam: "-i" alone should be enough
<luks> the packages are built against the release tarball, aren't they?
<jam> dato: well, lamont came and complained that it wasn't
<dato> jam: ok, but odd :-)
<luks> and the tarball already contains the compiled .c files
<jam> luks: 2) There was something about bzr-builddeb interacting poorly with orig.tar.gz
<jam> luks: I though bzr-builddeb worked against the *bzr* tree, not a tarball
<luks> bzr-builddeb has many workflows
<jam> dato: and according to beuno just now, it also failed
<luks> but as most software isn't in bzr, it would be weird requirement to use a bzr tree
<jam> luks: I think we would *like* to use bzr-builddeb, and if someone can put something together that actually works, we probably *would* use it.
<beuno> jam, dato, I may have done something else wrong, which made -i do something else, but I'd rather stick with an extra step that works 100% of the time for now. We can always improve
<luks> jam: well, I use bzr-builddeb for some PPA packages and it works all fine
<luks> jam: maybe I'll take a look at it
<jam> luks: *I* would appreciate that a lot
<Odd_Bloke> Bwahaha, I win.
<Odd_Bloke> I had branching scheme issues.
 * LarstiQ hands Odd_Bloke the washing machine!
<Leonidas> What is the number that is stored in Revision.timezone? It seems to be seconds, right?
<Leonidas> (seconds from UTC)
 * fullermd would presume so.
<fullermd> At least, until some random place gets a bug up their behind and decides to make their TZ offset sub-second...
<vila> jam: not sure what you're referring to, I fixed some bugs in the ftp transport but Christophe Troestler  (IRC nick anyone ?) also made some modifications I didn't review
<beuno> vila, hi!
<vila> beuno: hi ! I will be back far more often starting in 37 hours :-D
<vila> beuno: I need to reply to  a couple of mails regarding bzr-upload (as in: I read them but didn't find the time to reply)
<beuno> vila, yay!  Welcome back, you've been missed
<vila> thanks
<vila> I think I'm so excited I prefer to hide :-) (kidding, I need to finish a project in record times but I came back from vacations with fully charged batteries :)
<Verterok> mornin' all
<beuno> hey Verterok
<Verterok> beuno: hey there
<beuno> Verterok, home yet?
<Verterok> beuno: still @ work...but leaving in ~ 2hs
<Verterok> beuno: (mini)sprint at you office? :D
<beuno> Verterok, absolutely!  I'll be here
<Leonidas> When I have a file id, how do I get the revision in which it was last modified?
<Leonidas> for example I have pointtec-20061130215532-730mabsm1q6n7007-1
<Leonidas> Now I'd like to get a revision that contains the file.
<beuno> Leonidas, I can't dig into it right now, but you should peak into how loggerhead does it
<jam> vila: well the "SITE CHMOD" lines are attributed to a commit from you
<jam> namely 3508.1.1, "Fix ftp transport so that it handles the 'mode' parameter when provided"
<jam> Leonidas: Do you already have a tree?
<jam> revtree.inventory[file_id].revision
<Leonidas> jam: yeah, I do. thanks. I was peeking into bzrlib.builtins.cmd_file_id_path which is using WorkingTree.
<jam> Leonidas: unfortunately, for a working tree you have to grab the "basis_tree"
<jam> bt = wt.basis_tree()
<jam> bt.lock_read()
<jam> bt.inventory[file_id].revision
<jam> bt.unlock()
<Leonidas> jam: it is not a problem, I don't want to use the workingtree anyway :)
<beuno> what do I need to fiddle with in locations.conf to commit with different email addys in different locations?
<jam> beuno: 'bzr whoami --branch'
<jam> You just set "email = ..." I believe
<vila> jam: ok, so you're referring to my fix. What's up ?
<jam> vila: I'm just trying to figure out what is going on, since it appears that we don't *stat* over ftp, so we get a bogus mode, and then try to chmod incorrectly.
<jam> Someone earlier was saying that over ftp he was getting 700 for everything
<jam> which meant when he uploaded, it broke modes for http access
<vila> jam: hmm, weird, two things:
<vila> 1- I thought bzrlib always provides 755 or 644 by default (without stat'ing)
<vila> 2- ftp servers can restrict chmod usage
<vila> or set an umask
<beuno> jam, thanks
<vila> but that's from memory, if there is a bug report I could look into fixing it anyway (very sooon 8-)
<jam> vila: *I* thought we provided None by default
<jam> No bug report that I know
<Necoro> vila, jam: Files uploaded via a normal ftp-program results in 644
<beuno> lifeless, ping me when you're up, I'm preparing 1.6.1
<Necoro> ok - using zsh's ftp client also results in 644
<Necoro> so I assume it is a bzr issue
<vila> jam: if we provide mode=None, then we don't call SITE CHMOD...
<jam> vila: I thought we provide None unless we successfully *stat*
<vila> Necoro: can you file a bug report please, I'll look into it
<jam> but our ftp.stat() returns st_mode = S_REG
<jam> or
<jam> st_mode = S_DIR
<Necoro> vila: ok
<jam> and nothing about the actual permissions
<jam> Necoro, vila: My guess is that we should see "mode == 000" and then fall back to None
<vila> jam: I know, it's a faked stat, but where do you see 'we provide None unless we successfully *stat*'
<jam> vila: "BzrDir._find_creation_modes"
<jam> st = self.transport.stat('.')
<jam> try/except TransportNotPossible
<jam> if not posisble "_dir_mode = None"
<jam> else
<jam> _dir_mode = (st.st_mode & 07777) | 00700
<jam> vila, Necoro: So explicitly this is the problem.
<jam> The stat succeeds
<jam> but doesn't return a valid mode
<jam> so we fall back to 0700
<jam> We could simply do
<jam> if st.st_mode & 07777 == 0: self._dir_mode = None
<vila> that's nasty because I thought transport.stat() was used to know wether or not a path is a dir, I was not aware it was used to get permissions
<jam> vila, Necoro: This should be a reasonable fix: http://pastebin.com/d66e4426c
<jam> vila: In other places it is used for size
<jam> Not sure when that is used any more
<Necoro> jam: I'll give it a try
<vila> webdav will suffer from the same problem as will the smart server then (that's where I stole the idea to implement it in webdav)
<Necoro> jam: what version of bzr is this diffed against?
<jam> Necoro: bzr.dev
<Necoro> because the patch fails with 1.6rc3
<jam> Necoro: odd, I see exactly the same code
<jam> slightly different offset
<jam> Necoro: starts at 648 in bzr-1.6rc3
<jam> line 648
 * Necoro will just patch by hand ;)
<jam> vila: smart server issues a real stat request
<jam> and returns stat.st_mode directly
<jam> so it includes file modes.
<jam> well, it uses "self._backing_transport.stat()"
<jam> but 99% of the time backing_transport is Local
<jam> well Chroot(Local())
 * vila scratches his head
<Necoro> jam: works now
<Necoro> should I still file the bug?
<jam> Necoro: so please file a bug
<jam> and include that as a patch
<jam> so we don't forget about it
<jam> and then poke vila in 37 hours so that he fixes ftp's stat :)
<jam> In the mean time, let him get his "private" work done, so he doesn't start working for us late
<jam> :)
<vila> make that 34.5 hours :-D
<Necoro> bug #259855
<ubottu> Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Undecided,New] https://launchpad.net/bugs/259855
<jam> Thanks Necoro
<Necoro> thank you jam for the patch
<teratorn> is there any easy way to append some more changes to the last commit?
<teratorn> (before its pushed or pulled, of course)
<luks> bzr uncommit / bzr commit
<teratorn> yeah, I already knew about that :/
<LarstiQ> teratorn: so what did you want different?
<teratorn> just a simple command "append-commit" or the like... so I don't have to fumble with copying commit messages, etc
<teratorn> one other thing.. bzr shelve/unshleve is great and all, but is there a way to do hunk cherry-picking at commit time, instead of having to do a separate shelve operation first?
 * LarstiQ wonders why people suddenly keep asking for that
<jam> teratorn: there is the "bzr-interactive" plugin, which allows "bzr commit -i"
<teratorn> often times I have a mass of changes, but I will make little "side changes" (docs, comments, etc), that should just be committed immediately and forgotten about
<teratorn> jam: interesting, thanks
<LarstiQ> now, if my browser didn't freeze out on me, I could try to look up if there is an ammend style plugin to do the uncommit/commit dance.
<Necoro> where is the problem with doing two commits?
<Necoro> and stating in the commit message that it counts as an ammendment to the previous one?
<Peng_> Uh-ohs. SimpleTAL exceptions in Loggerhead.
<teratorn> it's dumb... other developers shouldn't be burdened processing two commit messages/diffs when one is best
<teratorn> see e.g. "darcs amend-record"
<Peng_> Coinciding with a spike in resource usage too.
<LarstiQ> teratorn: I thought there was something like that, but I can't find it atm.
<teratorn> LarstiQ: well I'll keep my eye out.. thanks
<teratorn> I imagine writing a plugin to do it wouldn't be hard
<LarstiQ> teratorn: right, fairly trivial even.
<fullermd> I think there might be something in bzr-gtk or one of the GUIs that does it.
<fullermd> There was a hunk of discussion/work on saving uncommit'd logs at least, which is part of the process.
 * LarstiQ watches http://gigo-ice.org/scm/bazaar/plugins/docdiffdemo.htm in the interim
<mwhudson> Peng_: hmm
<Peng_> Oh hi
<Peng_> This page does it: http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/changes?start_revid=1185.33.49
<Peng_> Augh, I can't copy and paste from my log files when you people make 20 requests! :(
<Peng_> Anyway, it just says it can't concatenate str and None.
<mwhudson> what
<mwhudson> Exception: cannot concatenate 'str' and 'NoneType' objects
<mwhudson> hm
<mwhudson> it's in the source too, which makes it easier to find :)
<Peng_> Oh.
<Peng_> OK then. That should make it easier to track down. The log file didn't give any context.
<Peng_> (FWIW, the error was repeated 3 times.)
<Peng_> That revision has no branch nick.
<Peng_> Yeah, none of them do.
<mwhudson> yeah, it's a branch_nick problem indeed
<bkor> Jc2k: when robsta is around, tell him I have an email address
<mwhudson> Peng_: fixed
<Peng_> mwhudson: Cool. Thanks. :)
<mwhudson> np, thanks for mentioning it
<Peng_> Could any other places have that issue?
<Jc2k> bkor: will do
<bkor> Jc2k: I have no idea what the hell he's pinging me for (I prefer people just either asking outright, or staying online 24/7)
<beuno> mwhudson, are you up to doing a review today, so we can release a 1.6.1 with fixes to the template browse.pt and adding --port and --host flags to serve-branches?
<mwhudson> beuno: sure
<mwhudson> Peng_: maybe :)
<mwhudson> Peng_: nowhere totally obvious suggested by grep
<Jc2k> bkor: he's wanting to move his css gtk engine into svn.gnome.org sing the same method as uws did for gnome-specimen
<Lani78> Hi, I'm trying to learn bzr and I've now created a central and shared repository on my server. First I created a local repo:
<Jc2k> bkor: so he needs you do to the honour with killing trunk and copying his branch to trunk
<Lani78> bzr init-repo --trees .
<Lani78> then the remote on my server: bzr init-repo --no-trees sftp://centralhost/srv/bzr/
<bkor> Jc2k: I forgot what I did for uws
<Lani78> I can add files, and commit them just fine, and get them from another computer later, so it all works :)
<Jc2k> bkor: delete drunk and then move the bzr-playground branch in its place
<Jc2k> *trunk
<Lani78> BUT, where does it physically store my data?
<Jc2k> bkor: for http://svn.gnome.org/svn/gtk-css-engine/
<Jc2k> bkor: i can get the blog post uws made with notes if it is helpful
<Lani78> the folders that I create in /srv/bzr are completely  emtpy... ;)
<Peng_> Lani78: Do they have a .bzr directory?
<Lani78> nope
<Lani78> but the data must be somewhere on the server as I could get the files from another computer ;)
<Peng_> Yeah, it's in ".bzr".
<Lani78> but not on the server... I just told you. not in /srv/bzr anyway... If not "ls -l" has changed...
<Jc2k> ls -a
<Lani78> ah!
<Lani78> hehe
<Lani78> da*n
<Lani78> Thanks :)
<Lani78> Now I feel safe again ;) I think that I should go to bed and get some sleep ;)
<Lani78> Ok, my next question now that we have that out of the way ;)
<Lani78> I created the central shared repository with: bzr init-repo --no-trees sftp://centraluser@centralhost/srv/bzr/
<Lani78> if I changed my mind now, and I want a separate shared repository for every project. can I just move all of the contents in /srv/bzr/.bzr into a subfolder, like /srv/bzr/project1
<Lani78> I only have one project at this time
<Necoro> Lani78: using "bzr branch" should make more sense, I think
<Necoro> though using it in a subdirectory of a repository will not do what you think it'll do ...
<Lani78> No, that is why I changed my mind and want a repository for every project
<Lani78> Atleast that is what I think that I want and what was recommended on another wiki page when I found it ;)
<Necoro> Lani78: but I doubt copying .bzr directories is the way to go
<Lani78> Ok. But to make it easy for me know, if I just want to start over, then all I have to do is to remove all the .bzr directories, locally and on my server, right?
<Necoro> then you'll lose all bzr-related information
<Lani78> yes, but that's fine, I can start over now, I only just begun.
<Lani78> It's a lot of new terminology and techniques to grasp for a former Microsoft Visual SourceSafe guy... ;)
<Necoro> Laney: given that /A is a shared repos with projects /A/b and /A/c - and you want to split ... I would do: bzr branch /A/b /tmp/b && bzr branch /A/c /tmp/c && rm -rf /A && mkdir /A && mv /tmp/[bc] /A/
<Necoro> though perhaps there is an easier approach ...
<pickscrape> How may people does Canonical employ to work on bzr full time?
<Lani78> Necoro: ah ok, I think that made sense
<Necoro> Lani78: because for the shared repository, there is a .bzr in /A and in /A/b and /A/c ...
<Necoro> so just copying the one in /A won't work, I assume
<Lani78> Yes, and now I don't wont any in /A, just in /A/b and /A/c
<Necoro> yeah - my branch and move approach above should handle this ...
<Lani78> Yup :)
<Necoro> perhaps "bzr split" might work too ... but this only a guess
<Lani78> I will try that, but I have not fully grasped this working tree stuff yet but hopefully it will come to me eventually, I will start with just doing it as the tutorial says and see what the result becomes :)
<Peng_> "split" is for when you want to break off one directory in a branch into its own branch. It has nothing to do with shared repos.
<Peng_> Lani78: You don't need to throw out your history if you just want to reorganize your shared repos.
<Lani78> Peng_: ok? Necoro gave me an example of creating temporary branches?
<Lani78> ï»¿(11:19:19 PM) Necoro: Laney: given that /A is a shared repos with projects /A/b and /A/c - and you want to split ... I would do: bzr branch /A/b /tmp/b && bzr branch /A/c /tmp/c && rm -rf /A && mkdir /A && mv /tmp/[bc] /A/
<lifeless> beuno: pong
<beuno> lifeless, good morning
<beuno> I promised 3 things for LH 1.6.1
<beuno> 1) fix template
<beuno> 2) --port flag for serve-branches
<beuno> and 3) --host  ?
<beuno> 2) and 3) are done, and 1) is 3/4 there
<lifeless> --prefix
<beuno> lifeless, --prefix for what, sorry?
<lifeless> beuno: see michael's mail to me
<lifeless> beuno: did you find it?
<beuno> mwhudson, can you clarify that a bit for me?  --prefix should be appended before path?  (serve-branches, line 79)
<beuno> lifeless, I don't quite get what needs to be plugged
<lifeless> I have loggerhead on localhost, apache in front mapping host/bzrview -> loggerhead
<lifeless> loggerhead can figure out host magically, but not that /bzrview == '.'
<beuno> lifeless, so you would add  --prefix /bzrview?
<lifeless> beuno: something like that
<beuno> not sure what paste does with the PrefixMiddleware, so I'm kinda in the dark
<lifeless> mwhudson_: welcome to the internets
<mwhudson> lifeless: :/
<mwhudson> lifeless: it's my laptop acting up this time
<lifeless> heh
<lifeless> mwhudson: beuno needs guidance
<lifeless> 07:53 < beuno> mwhudson, can you clarify that a bit for me?  --prefix should be appended before path?  (serve-branches, line 79)
<beuno> mwhudson, this is refered to:
<beuno> >> We use port 8000, and map http://www.squid-cache.org/bzrview/ not /
<beuno> >
<beuno> > serve-branches is meant to autodetect this from apaches forwarded
<beuno> > requests.
<mwhudson> lifeless, beuno: no, it's for the prefix middleware constructor
<beuno> It only detects the hostname automatically (by X-Http-Forwarded-Server),
<beuno> you have to specify the hostname in the construction of the
<beuno> PrefixMiddleware object (or via a --prefix command line option we should
<beuno> add...).
<beuno> mwhudson, so it takes more parameters?
<mwhudson> beuno: yes
 * beuno looks for paste docs
<mwhudson> beuno: read it's source/docstrings, perhaps,
<beuno> mwhudson, thanks. I see it has a prefix value, simple enough
<beuno> lifeless, mwhudson, does this look good enough?  http://beuno.com.ar/random/lh.png
<lifeless> FINE
<lifeless> fine :)
<mwhudson> beuno: +1
<beuno> \o/
 * beuno commits and pushes for review
<beuno> lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/1.6.1/revision/220?compare_revid=215  (see changes to serve-branches)
<beuno> will that make you happy?
<mwhudson> beuno: "Port Loggerhead should listen on. 8080 is the default one."
<mwhudson> is a bit clunky
<mwhudson> maybe just
<mwhudson> "Port Loggerhead should listen on (default 8080 is the default."
<rocky> hm, any reason NEWS.html hasn't been updated to reflect the latest bzr rc releaes?
<mwhudson> "Port Loggerhead should listen on (defaults to 8080)."
<beuno> mwhudson, fair enough. it did feel odd. Any other changes to the other strings?
<mwhudson> i think it's ok
<mwhudson> lets see what lifeless says
#bzr 2008-08-21
<jelmer> hi *!
<beuno> OMG, jelmer is back
<jelmer> hey beuno :-)
<BrianRice> hi. is there a way to run, say, the update command and have it only indicate what it *would* do rather than take action?
<jelmer> beuno, Do I have you to blame for the bzr-search upload? If so, thanks !
<beuno> jelmer, yeah, I took advantage of debcamp  :)  welcome'
<beuno> now, I'm about to release loggerhead 1.6.1, which would be nice to have in debian/ubuntu too  :)
<beuno> even PPA meanwhile
<beuno> BrianRice, I don't think there's a --dry-run option. Feel free to file a bug requesting it
<BrianRice> ok
<lifeless> 08:46 < mwhudson> "Port Loggerhead should listen on (default 8080 is the default."
<jelmer> beuno, ah, cool
<BrianRice> "bzr log" comparison seems to do well enough in the mean-time
<jelmer> beuno, will see what I can do to get into debian once I'm rested
<lifeless> mwhudson: perhaps
<lifeless> "Port Loggerhead should listen on (8080 is the default)."
<beuno> jelmer, where were you, btw?  vacation?
<mwhudson> lifeless: that was a typo, yes
<jelmer> beuno, yep, went cycling in the alpes for ~10 days
<lifeless> jelmer: wow back already
<pickscrape> Bet you're knackered now :)
<beuno> jelmer, cool. Welcome back then.
<beuno> pickscrape, I still owe you your review. I'm sucking at getting to stuff quickly lately
<jelmer> lifeless, yeah, bad weather so came back one day early
<jelmer> lifeless, thanks for the bzr-gtk pqm update
<pickscrape> beuno: no rush at all
<jam> lifeless: Some interesting results when tweaking the knobs on ChunkWriter for the btree index
<jam> http://rafb.net/p/owGbxj90.html
<jam> This is with the artificial nodes from the test suite.
<jam> But still interesting.
<jam> I'm planning on putting something together with real data tomorrow.
<jam> The only problem with using copy() is that it will change the page sizes if it is/isn't available
<jam> which means the test suite will become very brittle.
<jam> The "current" algorithm creates 490 pages, the "best" creates 390
<jam> So there may be some room to either be a bit faster, or compress a bit better in the same time
<jam> Anyway, I'm done for the evening.
<lifeless> jam: gnight
<lifeless> jam: perhaps we should do the zlib interface ourselves
<jelmer> hmm, rc5!?
<beuno> jelmer, don't ask
<AfC> It's ok. It's called "quality". That's a good thing.
<LarstiQ> AfC: what is this "quality" thing you speak of?
<AfC> It's what happens when you take the time to polish a release after you've decided to make one in the first place. There is a point of diminishing returns, but I've long felt that being shackled to particular dates and thereby shipping arbitrary bugs does not result in a better user experience.
<beuno> thumper, working on the gnome theme, progress so far: lp:~beuno/loggerhead/gnome_theme   (still have to fix quite a few things)
<lifeless> beuno: cool
<LarstiQ> AfC: a hard shackling to a specific date, no. But I feel it's better to not ship it if it needs too much polish.
<beuno> lifeless, you have access to gnome to push this once it's finished, don't you?
<lifeless> beuno: maybe:)
<beuno> :)
 * beuno -> dinner
<lifeless> LarstiQ: so if something needs too much polish, what - you give up on the project?
<LarstiQ> lifeless: include it in the next release
<lifeless> LarstiQ: well, thats what we're doing :)
<LarstiQ> lifeless: I was disagreeing with AfC's general statement, I think :)
<lifeless> oh suck
<lifeless> some plugin is making TestOutsideWT.test_url_log fail hard
<jelmer> lifeless, have you updated bzr-svn recently?
<lifeless> jelmer: FSVO recent
<lifeless> jelmer: remember it segfaults for me
<jelmer> lifeless, ahh
<jelmer> lifeless, it should no longer segfault
<jelmer> lifeless, if it does, please let me know
<lifeless> 0.4 still ?
<jelmer> it also contained a bug that made test_url_log hang
<jelmer> yep
<jelmer> I worked on a fix for this with Mark Hammond, which made it into the 0.4.11 rc
<lifeless> pullink
<lifeless> eek
<lifeless> I'm in install-revisions, in fetch :(
<lifeless> EFREAKINGSLOW
<lifeless> jelmer: editor.c: In function 'py_dir_editor_change_prop':
<lifeless> editor.c:358: warning: unused variable 'p_c_value'
<jelmer> lifeless, thanks, fixed
<lifeless> also,
<lifeless> ra.c:1141: warning: 'py_revstart_cb' defined but not used
<lifeless> ra.c:1161: warning: 'py_revfinish_cb' defined but not used
<lifeless> meh,
 * lifeless disables Werror
<jelmer> ah, looks like that happens when you build against svn 1.4
<jelmer> fixed as well
<lifeless> hmm, build_ext -i is broken
<lifeless> actually, no, its fine
<lifeless> ok, that test isn't hanging now, thanks
 * lifeless returns to log hacking
<lamont>  'No handlers cound be found for logger "bzr"'
<lamont> ^^ wassat?
<lamont> 1.6~rc3-1~ bzr and 1.6.0-1~ bzrtools
<lifeless> lamont: a race?
<lifeless> lamont: from pqm or something?
<lifeless> lamont: also, bzr-playground?
<mneptok> that'll teach him to unidle.
<jml> lifeless: testresources?
<lifeless> jml: yes, high on my queue
<lifeless> jml: or are you wanting to chat about it right now?
<jml> lifeless: no, just thought I'd take the opportunity to pester :)
<lifeless> can I review-by-mail?
<lifeless> jml: I see why you wanted the review; you went rather critical.
<lifeless> unfortunately, some of what you did isn't suitable
<jml> lifeless: that's ok. I figured that would be the case.
<lifeless> in particular the licence changes are incorrect
<jml> lifeless: review by mail is fine by me.
<lifeless> we'll see if lp forwards it to you
<chmac> beuno: I'm loving bzr upload, it works like a charm. :)
<lifeless> later all
<sadleder> hi, i've a question regarding launchpad-cscvs, is this the right place to ask?
<siretart> beuno: jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14)
<siretart> beuno: jelmer: is this something to worry about or shall I continue uploading it?
<thumper> sadleder: probably #launchpad is better
<sadleder> thumper: thanks
<luks> is it intentional that http://bazaar-vcs.org/releases/src/ doesn't have the latest 1.6 RCs?
<luks> oh
 * luks is blind
<awilkins> Since MarkH is producing .exe installers, would you like my builds of the Python-flavoured ones?
 * awilkins finds the python ones to be easier to hack/dogfood on
<luks> jam: (when you are here, and if you are interested) http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
 * luks wonder why https://launchpad.net/~bzr/+archive has 1.6rc5 for hardy
<luks> +s
<awilkins> Is everyone dead at their desk?
<bob2> yes!
<awilkins> Arrgh, 'tis zombie bob2
<bazaar> hi. is it possible to change commit metadata (message, commiter etc)?
<bob2> no
<bob2> unless you count "bzr uncommit"
<bob2> or merging them and giving better information in the merge revision
<jelmer> siretart, hi
<siretart> hey jelmer
<siretart> jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14). is this something to worry about or shall I continue uploading it?
<jelmer> what are the errors exactly?
<AfC> jam: did you cut bzr-1.6-rc5 yet?
<jelmer> AfC, yep, according to the website :-)
<siretart> jelmer: I can mail you the full log if you want to know
<siretart> jelmer: where should I mail it to?
<jelmer> siretart: jelmer@samba.org
<jelmer> siretart, It's probably nothing, but let's check just in case
<siretart> jelmer: should be in your inbox now
<AfC> jelmer: ah. Nice. Someone should change channel topic then.
* siretart changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc5! /  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<siretart> AfC: this channel is -t
<lifeless> bazaar: please choose a different nickname; you will confuse people with the nickname you have :)
<lamont> lifeless: in my case, it was a root owned ~/.bzr.log
<lamont> the other person seeing it doesn't have such a simple explanation
<jelmer> siretart, thanks
<siretart> jelmer: is that expected breakage, local breakage or is there something really wrong?
<jelmer> siretart, I haven't received your email yet
<jelmer> ah, got it
<siretart> the file has been created with this command: env -i bzr --no-plugins selftest -v | tee selftest.log
<jelmer> ah, it's all poll errors from pycurl
<jelmer> lifeless/jam: ping
<AfC> Oh dear. I got the error at https://bugs.launchpad.net/bzr-svn/+bug/229419 / https://bugs.launchpad.net/bzr-svn/+bug/234010 and, upon upgrading to bzr-1.6-rc5 and bzr-svn trunk, trying to bzr pull in a (from Subversion) checkout seg faults
<ubottu> Launchpad bug 229419 in bzr-svn "WorkingSubversionBranch.test_create_checkout fails" [High,Fix released]
 * AfC is not even sure where to turn next
<fullermd> Is bzr-svn trunk something runnable?
<fullermd> I thought jelmer was doing all his stuff in the 0.4 branch or something...
<AfC> Oh?
 * AfC tries that...
 * fullermd doesn't really know, just vaguely remembers conversations here.
<AfC> fullermd: sure. Thanks
<fullermd> He must be dead, though.  It's been two minutes since I said 'jelmer' out loud, and he hasn't shown up.
<AfC> I'm not entirely sure he is required to come running just because someone says his name.
<jelmer> AfC, did you rebuild bzr-svn after updating it?
<jelmer> fullermd, coffee brake :-)
<jelmer> *break
<Peng_> Is it safe to have another web server serve Loggerhead's static files, instead of passing them back to Paste?
<fullermd> Oh, good.  I was getting worried about you   ;)
<jelmer> (-:
<AfC> jelmer: so I just did a fresh branch of 0.4 (ok, branch + pull --overwrite --remember, whatever)
<AfC> jelmer: and then ran `make` there.
<AfC> jelmer: and it too segfaults
<AfC> jelmer: .bzr.log shows it getting as far as "opening SVN RA connection to 'svn+ssh://afcowie@svn.gnome.org/svn/gtk+/trunk/"
<AfC> jelmer: and then that's it
<jelmer> AfC, any chance you can run it inside gdb and paste the backtrace?
<AfC> Sure, I can try
<AfC> gdb bzr pull ?
 * AfC doubts
<luks> `gdb python` and inside gdb `run /path/to/bzr pull`
<AfC> k
<AfC> jelmer: http://rafb.net/p/2Gm5ck59.html I hope
 * AfC has never tried Python inside gdb before, but has plenty of scars from trying to debug segfaults in Java code reaching to a native library. Pain.
<jelmer> AfC, thanks
<jelmer> AfC, It's not too bad with Python
<jelmer> AfC, there's even gdb macros that allow you to inspect the python stack
<AfC> jelmer: single threaded :)
<AfC> jelmer: oh yeah? Nice.
<AfC> jelmer: [now that Java is finally free, we're starting to see some progress along those lines]
<jelmer> AfC, Ah, of course. Multiple threads would make things more complex in java
<rocky> hrm, if i bzr merge something but don't commit it, what's the standard way to revert the merge?
<fullermd> revert?
<rocky> i bzr revert'ed each of the individual file changes but when i run bzr stat it still says i have a pending merge
<jelmer> rocky, just revert without any arguments
<fullermd> revert <file> doesn't touch the merges, just the full version.
<jelmer> rocky, (which will revert all changes in the working tree)
<rocky> ah thanks ;)
<jelmer> rocky, or revert --forget-merges
<fullermd> (there's an arg to touch ONLY the pending merges too, but if you're blowing away the merge, you don't care about that)
<rocky> jelmer: btw... i've troubleshooted the speed issue with bzr-svn 0.4.10 a bit again... and i'm seeing that everytime i commit, it basically checks properties on every folder in the remote svn repo (100's of svn requests)
<jelmer> siretart, seems fine to me to upload
<jelmer> siretart, there's an issue with pycurl, but I think that's known
<jelmer> rocky, even with 0.4.11~rc1?
<rocky> jelmer: 0.4.11-rc1 only works with bzr 1.6rcX right?
<jelmer> rocky, yep
<rocky> jelmer: i tried playing with that in a sandbox the other day and got tracebacks all the time
<rocky> jelmer: does that mean you won't be trying to fix this in the 0.4.10 branch?
<jelmer> rocky, what backtraces exactly?
<jelmer> rocky, yes, 0.4.10 won't see any further development
<rocky> jelmer: i'll have to try again (i didn't at the time because you weren't around) to see the tracebacks
<AfC> jelmer: (am I in error to be working from your 0.4 branch? Should I grab the 0.4.11-rc1 tarball instead?)
<AfC> (or trying to bludgeon Subversion, or...?)
<fullermd> Wouldn't you be doing that anyway, just on GP?   :p
<AfC> fullermd: I was thinking more a rapier missile battery on fully-automatic, but yes
<jelmer> AfC, no, the 0.4 branch should work just fine (atm it's the same code as 0.4.11~rc1)
<jelmer> AfC, I'm not sure what's causing your backtrace, still looking into it
<AfC> jelmer: (that's what I figured)
<rocky> jelmer: what version of svn does bzr-svn 0.4.11 require?
<AfC> jelmer: Most kind. I hope it's not something stupid I'm doing (or with my environment).
<jelmer> rocky, 1.4
<rocky> jelmer: will it work with svn 1.5.x ?
<jelmer> AfC, even then it shouldn't be segfaulting
<jelmer> rocky, yes
<rocky> jelmer: atm i'm testing with http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/  ... should i keep testing with that or switch to your tarball or?
<jelmer> rocky, that seems fine, though you may want to use the original location (http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead since the lp mirror may be out of date)
<AfC> (I would automatically blame Subversion, except that I was able to do an `svn checkout` of a different project whereas that URL segfaulted for bzr-svn trying to do a checkout)
<rocky> jelmer: gotcha
<rocky> jelmer: here's a traceback just trying to check out a svn branch...  http://cluebin.appspot.com/pasted/601
<jelmer> rocky, was this in a clean sandbox?
<rocky> jelmer: that toplevel "repo" dir was a fresh repo i just created with "bzr init --rich-root-pack repo" if that's what you mean
<rocky> jelmer: but... the remote svn repo it's connecting to has lots of bzr props set from other versions of bzr-svn
<rocky> jelmer: and, the remote svn repo i'm connecting to is publically available so you can play with it if you'd like
<jelmer> rocky, thanks, will give it a try
<ktenney> for a while my prompt (Ubuntu) included the version of the current tree, now it doesn't
<ktenney> where is that set?
<james_w> ktenney: I think there may be something in /usr/share/doc/bzr/examples , but I'm not sure
<jelmer> beuno, ping
<beuno> jelmer, pong
<jelmer> beuno, any chance you can set a tag for the loggerhead release?
<beuno> jelmer, I've never used tags. Do I have to change the repo format?
<jelmer> beuno, if the branch is in a packs format, you should already be able to use tags
<jelmer> beuno, e.g. "bzr tag -r213 loggerhead-1.6"
<beuno> jelmer, sure then. Tag && push?  IIRC, they don't propagate automatically?
<beuno> although I have a checkout, that may do it
<jelmer> beuno, yep, a checkout should do it
<jelmer> beuno, they should propagate automatically
<beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead/trunk$ bzr tag -r213 loggerhead-1.6
<beuno> Created tag loggerhead-1.6.
<beuno> AKA, done  :)
<beuno> we should have 1.6.1 out tomorrow, the code is up for review
<LarstiQ> don't you need to commit it though?
<jelmer> beuno, I see it here, thanks!
<ktenney> james_w .. no examples, I'll poke around. Odd how it appeared and disappeared ...
<beuno> LarstiQ, it seems not. I never quite got my head around how tags propagate
<jelmer> rocky, thanks, I can reproduce that
<rocky> jelmer: excellent :)
<rocky> jelmer: if you can get this issue fixed i'll try again and if everything's ok i'll start using bzr-svn 0.4.11 for all my stuff ;)
<rocky> since i'm using a bzr branch of your bzr-svn 0.4 i should be able to test quickly
<jelmer> rocky, cool
<rocky> jelmer: if it wasn't for the fact that i love bzr so much i would have given up by now due to the speed issues with 0.4.10 :(
<jelmer> siretart, while you're at it, any chance you can sponsor an upload of loggerhead to debian and ubuntu?
<jelmer> rocky, 0.4.11 should really be a lot better in that regard
<rocky> excellent :)
<awilkins> Does anyone want my rc5 Python/Win32 installer builds?
<jelmer> awilkins, somebody asked me about them
<jelmer> awilkins, perhaps just add them to the releases wiki page?
<awilkins> jelmer: As attachments?
<jelmer> awilkins, Just pointing at the URLs if you have uploaded them somewhere
<jelmer> awilkins, alternatively, maybe you can upload them to the bzr launchpad project?
<jelmer> awilkins, It may be useful to talk with John or Mark about that
<awilkins> jelmer: The "exe" version is convenient but I prefer the Python version which is more hackable
<awilkins> jelmer: I have no inkling of how to upload a file to the launchpad project (I feel certain that I have no rights to do so)
<jelmer> awilkins, I think it makes sense to have both available for users to download
<jelmer> awilkins, John, Mark or Martin should be able to help there
<awilkins> markh: Ping? jam: ping?
<awilkins> jam: Ping?
<jam> jelmer: pong
<jam> awilkins: pong
<jelmer> jam, siretart is seeing select/poll errors in the testsuite from pycurl
<jelmer> jam, is that a known issue?
<awilkins> jam: Hello, I have a build of the python-installer packages for windows if you want them
<jam> jelmer: there is a known issue with newer versions of pycurl giving select/poll errors, yes
<jam> I don't know that anyone has really dug into it
<jelmer> jam, ah, ok
<jelmer> jam, So this occurs with older versions of bzr as well?
<jam> I thought vila poked at it a bit, but has been gone the last 3 weeks, and doesn't really start up again for about 24hrs
<jam> jelmer: it has to do with the new pycurl, not so much bzr
<jam> As I understand
<jam> so <hardy works
<jelmer> jam: Ah, cool - thanks
<jelmer> siretart, ^^
<jelmer> jam, well, not *cool* but good it's not a new issue introduced by bzr :-)
<siretart> jelmer: sec
<siretart> jelmer: okay, I'll upload then rc5 in a minute then
<siretart> jelmer: where to find the loggerhead packaging branch?
<jelmer> siretart, http://bzr.debian.org/pkg-bazaar/loggerhead/unstable
<jam> awilkins: thanks, I would guess it is easier to just have me reboot and build them, or have markh do it when he does the full installer. Mostly because someone needs to upload them, and sending 5MB email attachments isn't great :)
<timnik> when doing a "bzr pull" is it possible to tell bzr to not overwrite a particular file? (ever?)
<timnik> i.e. one of the files under version control
<timnik> I'm guessing it's not, but if I'm wrong would be cool :-)
<Peng_> beuno: ping
<beuno> Peng_, pong
<Peng_> beuno: Just to make sure, is it safe to have Loggerhead's /static/ directory served by another web server instead of LH itself?
<jam> timnik: generally not
<beuno> Peng_, sure, I don't see why that would blow up at all
<awilkins> jam: Fair enough
<Peng_> Yeah, it seems to be working fine.
<beuno> it accesses everything through the URL, so you should be fine
<Peng_> Thanks. :)
<awilkins> timnik: A pull will never overwrite a file. It may move it, but not destroy it
<beuno> Peng_, anything for our star tester  :)
<timnik> jam, thanks
<Peng_> :)
<timnik> awilkins, would it not attempt to update it, if it's contents had changed?
<awilkins> timnik: Unless that's part of the revisions pulled of course....
<timnik> awilkins, well, yes
<timnik> awilkins, not to worry. It's more a matter of me being lazy than any real problem.
<timnik> thanks!
<awilkins> timnik: You could write a post-pull hook that restored your file I suppose
<timnik> awilkins, Thanks for the hints. What I should really do is fix my program to use a custom settings file not under version control. :-D
<timnik> awilkins, admittedly I was looking for the lazy way out
<awilkins> timnik: I like a versioned template that you copy, but it's on the ignore list in it's "active" position
<timnik> awilkins, hmm, that's an idea
<luks> the problem with this is that you have to manually copy any change to the real config
 * timnik runs to try it
<luks> I'd really like to see a proper solution to that problem
<luks> but I can't think of anything
<awilkins> Primary file is versioned but secondary ignored file overrides it?
<timnik> luks, it should really ever be a problem. If it's needed, the developer is doing something wrong, imho.
<timnik> In this case it's me, and I'm too lazy to fix it.
<luks> timnik: well, software evolves and you need to add some configuration options
<timnik> *never
<timnik> luks, well, have a default file, and use it, unless a custom file exists. The settings in the custom file override that of the default.
<timnik> default is under version control, custom is not, and is only ever used if it exists.
<luks> hmm, yeah, that works for some cases
<luks> but it's still not as flexible as I'd like
<timnik> heh, now you sound like me :-P
<timnik> is in possible to undo a "bzr ignore" other than edit the ignore file?
<luks> I don't think so
<timnik> oh, ok. Almost had it. :-D
<awilkins> Is it just me or are the google IMAP servers being a right pain in the bum today...
<pickscrape> They go through spells. Unfortunately Thunderbird doesn't deal with it particularly well :(
<Peng_> The only issue I ever have is having to log in frequently.
<Peng_> Is that what you meant?
<awilkins> Peng_: Yes, that's what I mean
<Peng_> That is a pain, but I've gotten used to it. :\
<Peng_> That shows how much it happens.
<beuno> awilkins, FWIW, I'm having problems with gmail through the web interface
<beuno> it's doing odd things
<Leonidas> What does hgext.convert.common.getchanges mean by "where id is the source revision id of the file."
<siretart> jelmer: oh, loggerhead is a completely NEW package, isn't it?
<Leonidas> I thought it was the revision id where the file was last modified.
<jelmer> siretart, yes
<Leonidas> oops, sorry, wrong channel ;)
<Leonidas> (although the question is bzr-related, too)
<awilkins>  Leonidas Filthy mercurial user! Begone!
<siretart> jelmer: oh, that meas I have to do a more thourough license check and such, I won't get to it today, will try tomorrow. If I fail to manage it until saturday, please ping me again
<jelmer> siretart,
<siretart> jelmer: btw, did you run 'licensecheck -r .' on the source?
<Leonidas> awilkins: hey, when i implement the bzr_sink, you'll be able to convert hg repositories to bzr ;)
<jelmer> siretart, thanks!
<jelmer> siretart, no, wasn't aware of that tool yet
<jelmer> siretart, I will, now :-)
<siretart> jelmer: it is a rather simple tool using regex to determine the license of each file. of course not bulletproof, but a great asset for ftpmasters ;)
<siretart> it is in the 'devscripts' package
<jelmer> siretart, yep, found it
<jelmer> siretart, I did a recursive grep for Copyright, that seemed to've covered everything
<jelmer> siretart, I'll keep this in mind for next time though, very useful
<jam> Leonidas: my understanding was that with hg fast-export | bzr fast-import you already *can*
<jam> Or with the bzr-hg plugin, though I don't know if it has received any polish in a while.
<jam> Leonidas: I don't really understand that sentence, in the context of hg or bzr
<jam> "source revision id of the file" sounds like the revision id that initially added the file?
<Laney> Is this bug known and/or fixed? http://paste.ubuntu.com/39425/
<Leonidas> jam: Yeah, but as far as I have seen it should be the "current" revision.
<Leonidas> jam: I haven't tried fast-(im/ex)port, need to give it a try. I am currently hacking up hg convert so there is support for continous integration of new changesets into repositories.
<jam> Laney: sounds like you have the bzr-dbus plugin installed
<jam> I don't know why it would need X11
<jam> you could do "bzr pull  --no-plugins" and have it work
<jelmer> siretart, any chance you can commit your changes for rc5 in the bzr branch on alioth?
<Laney> I have no idea what that is jam
<Laney> I'll file the bug
<jelmer> Laney, that's a known issue in bzr-dbus
<Laney> Oh!
<jam> Laney: I don't know who did your setup then :) But you seem to have the bzr-dbus package installed. If you don't use it, you could "apt-get remove" it
<Laney> jam: Maybe it was pulled in as a dep of something?
<Laney> "Automatically installed: yes"
<Laney> Well if it's known then I will wait
<jelmer> Laney, https://bugs.edge.launchpad.net/bzr-dbus/+bug/107169
<ubottu> Launchpad bug 107169 in bzr-dbus "Failed to execute dbus-launch to autolaunch D-Bus session" [Low,Confirmed]
<jelmer> bzr-gtk suggests or recommends bzr-dbus these days, I think apt may automatically install it when you install bzr-gtk by default
<Laney> Probably. But I don't know why bzr-gtk would be involved at all - I'm invoking this over SSH
<Leonidas> To read a file from a repo I just need to lock_write it, right? Because lock_read 8which is unfortunately undocumented) would lock it also for reading, as far as I can guess. Am I right?
<jelmer> Laney, If you install bzr-gtk, apt may also install bzr-dbus for you
<jelmer> Laney, bzr-gtk isn't involved here, but bzr-dbus probably came along with it if you installed it
<siretart> jelmer: err, I already did?
<Laney> jelmer: Right, I get that. But shouldn't bzr-dbus be disabled if calling over SSH too, or?
<siretart> >> bzr missing sftp://bzr.debian.org/bzr/pkg-bazaar/bzr/unstable/                                                          :0.0
<siretart> Branches are up to date.
<Laney> jelmer: Anyway, removing bzr-dbus has fixed it. Many thanks
<jelmer> siretart, sorry, my bad
<jelmer> siretart, my mail is just very slow today
<jelmer> pulling manually does indeed work
<siretart> jelmer: I work with checkouts, my local branch is bound to alioth
<jelmer> siretart, I was checking for a commit email from alioth, but for some reason are not seeing any
<siretart> ok, heading home now, cu later!
<jelmer> see you!
<jam> beuno: did you see luks: http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
<jam> vila: I submitted my patch (with test) for bug #259855 so I closed that bug, but opened a new one about FTP transport and assigned it to you. It is priority low, so you are welcome to ignore it, unassign it
<ubottu> Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed] https://launchpad.net/bugs/259855
<beuno> jam, oh, open source rocks!  :)
<jam> beuno: I haven't tried it
 * beuno branches
<jam> but it looks like he set up a few packaging branches
<jam> and has the whole thing fairly scripted
<jam> I noticed he left out "intrepid"
<jam> and he hosted the packaging branches as "bzr" project branches, which isn't quite correct.
<jam> but in general, it could make things a lot easier.
<luks> jam: they already were under bzr
<jam> I would probably create a "bzr-packaging" project, and migrate things over to ~bzr/bzr-packaging etc.
<jam> luks: ah, well, that doesn't make it *right* :)
<jam> Probably martin did that
<luks> I think it's common on launchpad to have debian/ubuntu packages under the product
<beuno> luks, very cool. I'll poke at it in a bit
<luks> beuno: the main advantage is that it uses bzr-builddeb
<luks> so you don't have to mess with tarballs
<luks> the scripting is just extra bonus (yes, I was bored :))
<beuno> luks, so you worked around the .c/pyrex problem?
<luks> there is no .c/pyrex problem
 * LarstiQ waves a spoon about.
 * pickscrape watches the spoon bend
 * timnik thinks there is no spoon
<beuno> luks, didn't jam mention something yesterday?
<luks> yes, and he was wrong
<luks> sorry :)
<beuno> that's great news!
<jam> luks: so how do you get the .c files into the output?
<jam> if you aren't using tarballs?
<luks> jam: *you* put them there
<luks> it does use tarballs
<luks> but bzr-builddeb takes care of it, not the packager
<jam> luks: ok, you just said: (11:36:52 AM) luks: so you don't have to mess with tarballs
<jam> Just a bit confused
<jam> but as long as it works :)
<luks> sorry
<beuno> jam, can you release a rc6, so I can test this?
 * beuno ducks
<jam> beuno: You'll get a 1.6-final in a few days
<jam> is that sufficient :)?
<jam> You could do everything but upload
<beuno> sure, let's alpha-test with 1.6 final  :p
<beuno> I'm kidding, yes
<beuno> I can upload to my own PPA n' stuff
<fullermd> 1.6-final is a RC for 1.7   :p
<luks> heh
 * beuno slowly moves away from jam 
<jam> beuno: isn't that what 1.6.1 is for? :)
<jam> actually 1.6~bazaar2
<jam> since the tarball doesn't change
<jam> just the packaging
<teratorn> beuno: back away, slow. don't take your eyes off of it
<jam> or maybe 1.6~bazaar1~hardy2 ?
<beuno> yeah, as of today, I can upload all bzr packages with "control + r" and changing 4 or 5 characters
<jam> I don't strictly understand all the numbering ideas
<fullermd> Yeah.  Like "1.6i+5".  It gets so complex.
<Odd_Bloke> I checked out part of a Subversion repo using bzr-svn.  I did some local commits and then tried to do a non-local commit (which I was expecting to sync up all the commits).  I was told that the local branch was out of date with the SVN branch.  Nothing has changed in that part of the repo (though I don't know about the repo as a whole).
<jelmer> Odd_Bloke, you need to "bzr up" first
<jelmer> Odd_Bloke, and you may have to push the changes to svn first
<Odd_Bloke> I'm now trying to push my changes into there and bzr-svn seems to be browsing the ~245 branches (as per the branching scheme) on the server, without any actual pushing seeming to happen.
<vila> fullermd: ROFL
<jelmer> Odd_Bloke, it is checking whether the revisions are already there somewhere in one of the other branches
<Odd_Bloke> OK, I'm now pulling from my branch into a pristine checkout of the SVN.  Which seems to be working...
<vila> jam: ok, I'll look into it in 12.5 hours 8-)
 * fullermd clicks off a stopwatch.
 * vila tweaks fullermd's watch to adjust it: 12h40m
<kek2> hi
<kek2> hi everybody. i'am using bzr first time. I Committed revision 1. How can i push the commit to a server over ssh?
<Odd_Bloke> kek2: 'bzr push sftp://<user>@<server>/<path>'.
<jelmer> Odd_Bloke, "bzr push <svn-url>" would've also worked
<kek2> ok, i will test
<Odd_Bloke> jelmer: Yeah, I realised this just now (when it did work :D).
<Odd_Bloke> But the pulling option is actually quicker, because it doesn't feel the need to scan for the revision in every branch.
<kek2> kekz@firefly:~$ bzr push sftp://kekz@kekzkbook/home/kekz/test
<kek2> bzr: ERROR: Not a branch: "/home/kekz/".
<kek2> whats the mistake?
<Odd_Bloke> kek2: Well, '/home/kekz/' is not a branch.
<kek2> the same error when i use bzr push bzr+ssh: ... usw.
<Odd_Bloke> kek2: So you can't use bzr to push it anywhere.
<Odd_Bloke> Which directory were you in when you committed revision 1?
<kek2> oh ... so i must initalize an empty commit on server?
<Odd_Bloke> kek2: No, locally.
<Odd_Bloke> kek2: What directory were you in when you committed revision 1?
<kek2> /media/daten/devcenter
<kek2> no .. the last time i try from /home/kekz
<kek2> aah :)
<kek2> ssh: kekzkbook: Name or service not known
<kek2> bzr: ERROR: Unable to connect to SSH host kekzkbook; EOF during negotiation
<kek2> ok, i think i have an dns problem
<kek2> wrong hostname
<kek2> ok, it works
<kek2> Odd_Bloke: Thank you
<kek2> its pushing =)
<Odd_Bloke> kek2: No worries, glad I could help. :)
<kek2> i have a pc and a notebook and a server (in vmware on the notebook). Sometimes i work on my pc, sometimes i work on my notebook. What is the best practice .... to push and pull from server      OR    to push and pull between pc and notebook directly?
<Odd_Bloke> Argh, I'm having to commit for the third time because I forget that bzr-svn will prompt for passwords multiple times.
<uws> Odd_Bloke: ssh keys to the rescue?
<jelmer> Odd_Bloke, bzr-svn doesn't prompt multiple times, bzr does :-)
<jelmer> kek2, either will work fine I think
<jelmer> hmm, bb down again?
<jelmer> james_w, hi
<beuno> jelmer, it's been down for a while, and abently is on vacation
<jelmer> beuno: ah, ok
<Odd_Bloke> jelmer: Hmm, I've only noticed it when using bzr-svn.
<jelmer> Odd_Bloke, the checkout logic is all inside of bzr
<jelmer> Odd_Bloke, have you used local commits with checkouts and native bzr branches?
<Odd_Bloke> No, I suppose not.
<kek2> bye
<kek2> and thanks for help
<vila> jam: I agree 60% with your analysis and 100% with your patch for #259855, I'll address the remaining 40% while fixing #260131, so BB:approve
<mwhudson> jelmer: i was trying to help a guy the other week who (it turned out) was doing 'bzr ci' in a svn working tree when the svn server was inaccessible
<mwhudson> jelmer: the error was not very clear :)
<vila> ubottu: grrr, bug #259855
<ubottu> Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed] https://launchpad.net/bugs/259855
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jelmer> mwhudson, did you file a bug ? :-)
<jelmer> mwhudson, or, do you perhaps remember what the error message was?
<jam> vila: shame on you for harassing the ubottu :)
<vila> ubottu: grrr, bug #260131, yeah, mister bot, but come on #226131 is *obvious* !!!
<ubottu> Launchpad bug 260131 in bzr "FTP stat() does not return valid permission bits" [Wishlist,Triaged] https://launchpad.net/bugs/260131
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<mwhudson> jelmer: oh, it was https://bugs.edge.launchpad.net/bzr-svn/+bug/211683, you commented already
<ubottu> Launchpad bug 211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,Fix released]
<vila> jam:  :-P 23.5 hours to go :)
<mwhudson> jelmer: that's what the comment from chris perkins was about
<fullermd> What?  It was 12.5 an hour and a quarter ago!
<beuno> mwhudson, hi. Want to see something weird?  bug #260190
<ubottu> Launchpad bug 260190 in launchpad-bazaar "One cannot access to the "Help" section while working on "Changes"" [Low,Triaged] https://launchpad.net/bugs/260190
<mwhudson> beuno: !?
<beuno> mwhudson, I have *no* idea how different tabs can be show on different places
<jam> vila: wouldn't that mean you start late in the evening on Friday? I should get your TZ sometime so I can keep track of your offset.
<jam> Though I guess knowing your working hours is just as important :)
<beuno> vila should be UTC +2
<jam> beuno: so basically your template is der-broken?
<jam> That is kind of odd
<jam> But I certainly see the same thing
<jam> the help tab disappears when you are under changes
<beuno> jam, well, the tabs are generated from one place only, so this kinda throws me off  :)
<james_w> hey jelmer
<jelmer> james_w, Have you had any time to look into my debian directory service patch for bzr-builddeb yet?
<james_w> jelmer: I put it on hold, sorry.
<jelmer> james_w, No hurry, just making sure it's not forgotten
<james_w> ah, ok.
<jelmer> james_w, How's the bzrification of the archive going?
<james_w> I may try and fold it in this week, but I'm wondering how it interacts with my other work
<james_w> I haven't started another conversion run since the sprint as I have been focusing on other things, but it's hopefully on track
<jelmer> james_w, ah, cool
<jelmer> james_w, you've probably already seen it, but just in case: https://wiki.ubuntu.com/BzrMaintainedPackages
<james_w> ah, great, thanks
<james_w> that's probably going to be useful
 * mwhudson hmms
<mwhudson> lifeless: awake yet?
<rocky> anyone here using TracBzr ?
<rocky> curious what it's "status" is
<pickscrape> I am
<pickscrape> Though I'm not sure of its status
<rocky> pickscrape: is there a released version to use or is using a snapshot from bzr the best bet or?
<pickscrape> It seems to have some problems with bzr 1.6.
<pickscrape> We're using a snapshot from bzr
<rocky> this branch seems to be working on bzr 1.6 compat
<rocky> https://code.launchpad.net/~scott-idealist/trac-bzr/bzr-1.6
<pickscrape> ooh, I hadn't seen that...
<pickscrape> Thanks for pointing me at that :)
<rocky> np :)
<rocky> i'm not so interested in 1.6 support yet ... what i'm more curious about is just how fast it is compared to trac's native svn support and being sure it won't blow up my server ;)
<pickscrape> Our experience is that it seems to be slower, though that could be because we have it pointing at a directory containing multiple shared repositories that contain multiple branches
<rocky> hm
<rocky> does it have any kind of support for cross-referencing revision links in wiki formatting? (ie with svn support, if in a ticket you reference r23 it automatically links to svn/browser r23 changeset url)
<pickscrape> Yes
<pickscrape> It looks like [branch_name,revno]
<pickscrape> e.g. [trunk,34]
<rocky> oh cool
<rocky> i'ven ever hosted an actual bzr repo before so that's something i'll have to play with anyhow
<pickscrape> Though there is an annoyance in that if the branch name contains a slash, it gets escaped and looks awful. Not sure if that's a problem with trac core or trac-bzr though.
<brl4n> just installed and started playing with bzr an hour ago. Trying to do a push via sftp but I'm getting an "Connection abandoned.
<brl4n> bzr: ERROR: Unable to connect to SSH host localhost; EOF during negotiation
<brl4n> not exactly sure if it is an ssh problem or bzr problem
<mwhudson> brl4n: sounds like an sftp problem
<brl4n> well I am able to connect through a sftp client.
<mwhudson> hmm
<mwhudson> what platform?
<brl4n> winXP using openshh
<brl4n> bzr returns the rsa2 key finger print
<brl4n> "Connection abandoned" then the Error: Unable ... etc
<brl4n> i've googled around but wasn't able to come up with anything
<mwhudson> oh windows
<mwhudson> i know things can be a bit hard to set up there, don't know the details though :/
<mwhudson> markh probably does, but i guess he's asleep
<brl4n> yah that is what I'm thinking
<brl4n> okie
<brl4n> i'll idle around then.
<brl4n> thanks
<mwhudson> jam, vila: maybe you can advise brl4n ^ ?
<lifeless> jam: ping
<jam> lifeless: pong
<lifeless> that log patch was against bzr.dev
<lifeless> no missing revisions
<lifeless> if you'll note it was started on rev 3642 of trunk -   (jam) Merge in 1.6rc5 and revert disabling default stack on policy
<lifeless> also, good morning
<jam> lifeless: well, the patch I see includes the NEWS entry for 1.6rc4 and 1.6rc5
<jam> Are you sure it was against bzr.dev proper?
<jam> (are you sure your bzr.dev copy is up-to-date)
<lifeless> oh wrong parent,
<lifeless> its got integration as my parent for some retarded reason
<jam> aha
<jam> good morning to you, too :)
<lifeless> resent
<rockstar> Is there a way you can put a plugin in the plugins directory, and blacklist it so it doesn't load in bzr?
<lifeless> yes, don't put it in there
<lifeless> rockstar: why do you want to do that?
<rockstar> lifeless, because we need the functionality of the plugin, but don't want bzr actually trying to use it
<lifeless> rockstar: 'we' ?
<rockstar> All the imports are 'from bzrlib.plugins.foo'
<rockstar> lifeless, lp-code
<lifeless> rockstar: a little more detail and I can probably be really clear and helpful :)
<rockstar> lifeless, sorry
<lifeless> if you have python code you want to use froma python program that also uses bzrlib
<lifeless> you can just import it
 * rockstar winds up
<lifeless> if its not a bzrlib plugin, don't put it in plugins
<lifeless> if it is a plugin, put it in plugins
<rockstar> So, I'm trying to implement a new layer into cscvs which will use the work jelmer did for svn.
<rockstar> So, we need the bzr-svn code, but we don't actually want it used by bzr
<lifeless> well
<lifeless> you'll need to restructure bzr-svn then
<lifeless> or
<lifeless> only have it in the bzrlib plugins path when cscvs is running
<lifeless> BZR_PLUGINS_PATH
<rockstar> Yea, that's what I had figured, and that's what mwhudson and I decided would be a good idea
<lifeless> though I'd just install it normally and use it
<lifeless> (where normal is probably in the lp rollout system)
<lifeless> unless you have a specific reason /not/ to have it available
<lifeless> bzr.dev is looking at shipping bzr-svn by default
<mwhudson> lifeless: it seems like it would be a bad idea to have bzr-svn active when running the supermirror-pull.py mirror script
<mwhudson> unless we want to start supporting imports via bzr-svn essentially by accident
<lifeless> mwhudson: doesn't the pull check the branch type already?
<lifeless> mwhudson: seems like the 'manually create an identical format in the target' step will fail epicly with bzr-svn branches and repositories :)
<mwhudson> lifeless: that's true i guess, but a bit of a detail
<mwhudson> lifeless: also, we use clone() for the initial branch creation now
<mwhudson> lifeless: which relates to something else really i want to talk to you about...
<mwhudson> ('manually create an identical format in the target' is also broken for bzr+http of course)
<lifeless> mwhudson: indeed
<lifeless> so, what I'd do is to integrate and test bzr-svn carefully
<lifeless> rather than doing something complex and hoping noone says 'this is too complex' and 'fixes' it later
<lifeless> without thinking of the things you have thought of
<mwhudson> though oh god, we'll probably completely re-mirror a bzr+http branch each time the puller runs now :(
 * mwhudson biles a fug
<lifeless> better than buggering a file
<mwhudson> bug 45277
<ubottu> Launchpad bug 45277 in bzr "[bzrlib] No easy way to compare format objects" [Medium,Confirmed] https://launchpad.net/bugs/45277
<AfC> So revision specs can be used with -r arguments, all good; is there a way to use them with commands that just take a branch URL (ie, I'd like to do `bzr missing push:` but that doesn't fly)
<mwhudson> well
<mwhudson> i think you mean bzr missing :push
<mwhudson> that works and isn't a revisionspec
<AfC> ooooh
<AfC> nifty
 * AfC wonders where he could have learned that himself
<AfC> mwhudson: (but I was referring to forms like `bzr diff -r parent:` )
<mwhudson> AfC: it's not documented yet
<james_w> AfC: I think parent is also :parent
<AfC> Interesting
<jonnyde1> hi, I've got a question regarding bundles: is it possible to backup a bazaar branch and all its revisions using a bundle? if so, how would it look like?
<james_w> AfC: but if you mean e.g. "branch:" then I think "branch:29:wherever" is the way
<AfC> I'm going to observe that it seems a bit strange that the thing: pattern was inverted to :thing
<james_w> the :thing things are not revision specs, they are location specifiers
<AfC> (if it's meant as a suffix, then fine, it makes sense, but it is rather glaring as using the same names in an inconsistent way. That tends to be a UI foible)
<james_w> I'm not sure that they are the same names
<AfC> james_w: parent, branch?
<mwhudson> it's not really the same class of thing, even
<AfC> same
<mwhudson> though i agree it's a bit confusing
<james_w> I'm not that keen on :parent et. al., but I don't think they conflict
<james_w> AfC: it's branch: and :parent, they are two different words
<AfC> james_w: bzr command -r branch:path
<AfC> james_w: bzr command  path:branch
<james_w> you can say using very similar things is a problem, but I don;t think they are the same
<james_w> AfC: the second doesn't make any sense as far as I am aware
<jonnyde1> (I would like to have a backup which is independent of the repository format)
<james_w> or is that one I'm not familiar with?
<AfC> ok
<AfC> james_w: bzr command -r parent:
<AfC> james_w: bzr command :parent
<james_w> I could imagine it as "the branch of this tree wherever it is"
<AfC> you're trying to tell me that people aren't going to go out of their minds trying to remember when to use which?
<james_w> I don't think parent: is recognised
<james_w> oh, I don't dispute that, but you said "same words", and I don't think there are any actually replicated
<AfC> james_w: as may be.
<AfC> james_w: were I a betting man, I'd be wagering heavily on this one.
<james_w> AfC: is the very nature of these things a problem, or is it just the presentation?
<james_w> would e.g. branch: and @parent be easier?
<jonnyde1> I think somehow creating a diff (bundle) between an empty branch and the branch to be backed up should do it, shoudn't it?
<james_w> jonnyde1: I think so
<jonnyde1> so this should also be a way to convert a format into another format where no direct upgrade/downgrade is available...?
<james_w> direct upgrade is available from every format since 0.4 or something as I understand
<james_w> (so long as you don't try and go rich-root->non-rich-root or similar)
<jonnyde1> well, but as I figured out this is not true for downgrading
<james_w> and as a bundle contains the revision data you won't be gaining anything
<bob2> going via bundles won't let you downgrade repository formats
<jonnyde1> why not? is the bundle format specific to a repository format?
<james_w> I think it just serialises the source repository format
<jonnyde1> ok, I see. So a cannot apply a bundle to a repository where the formats are incompatible...
<bob2> well, pretty sure it works upwardly
<bob2> but you can't go back (from rich-root to plain)
<jonnyde1> I wonder why there is no way to just export a series of commits. This way, I could just replay the commits, no matter what format the repository has...
<james_w> you can fast-export, but it's lossy
<jonnyde1> bob2: btw, thanks for your feedback
<bob2> you can, as diffs or fast-export, but that doesn't help you
#bzr 2008-08-22
<jonnyde1> james_w: I know of fast-export -- but as you already stated -- it's lossy
<jonnyde1> is it now ossible by design to implement something like replaying a series of commits without loosing anything?
<jonnyde1> sorry, I've meant: is it not posible...
<AfC> james_w: the overload of : (the fact that some names work only in one context, and others only in the other seems to be the sort of thing that will drive people batty)
<jonnyde1> with other words: could anyone imagine a way to write a plugin for bazaar which would just output all revisions and associated change sets as a series of commits which could be replayed again in order to create a clone which looks like the original?
<radix> jonnyde1: isn't that what "bzr branch" does?
<bob2> that sounds like it would be its' own repository format
<bob2> why not just trust bzr?  bzr itself has been upgraded from the 2005 preprealpha format with no data loss (unless you count ghosts).
<jonnyde1> radix: yes, indeed it does. but bzr branch creates a branch with a specific repository format.
<radix> oh, I see, you want a format-independent backup. I missed that part
<jonnyde1> radix: yes, exactly :)
<james_w> jonnyde1: you could come up with a non-lossy format similar to fast-export
<jonnyde1> maybe there should be a a format-independent repository format, too. One that does not consider any optimisations regarding storage efficiency....
<jonnyde1> james_w: that's something I would imagine... This way there would always exist a format to which you can get from every other format, and the other way round
<james_w> not really possible
<james_w> well, yes, you could write such a thing, but there's no way to future-proof it, and once you go to a format that stores less information you are stuck
<jonnyde1> ok, that's a good point
<jonnyde1> but I think one should maybe not see it as another repository format, but just as a series of commits that could be replayed by hand, too
<jonnyde1> the only difference is
<jonnyde1> that I would have to be able to commit change sets created by someone else
<jonnyde1> I mean using his signature/checksum
<jonnyde1> (and original content of course)
<lifeless> jonnydee: I think you misunderstand what repository formats do
<jonnyde1> lifeless: probably you are right...
<lifeless> jonnyde1: there are two different dimensions in formats
<lifeless> jonnyde1: one is _model_, one is just how things are indexed etc
<lifeless> the latter is things like knits -> packs -> btree etc
<lifeless> the former is things like 'plain', 'subtree', 'richroot'
<lifeless> its not possible to predict the future
<lifeless> so its not possible to define a model which is accurate in the future
<jonnyde1> ï»¿It is just that for me it looks like so: when I commit something to a repository with format A I do provide the same information as when I commit the same content to a repository with format B
<lifeless> well, when they have the same _model_ that is true
<lifeless> but its not true when you commit to a format with different models
<jonnyde1> but the information I provide during commit is always the same, isn't it?
<lifeless> no
<jonnyde1> I provide my content and a message
<jonnyde1> what else?
<lifeless> the data on disk :)
<lifeless> the entire working tree is information
<lifeless> the unique id for files
<lifeless> whether there are nested trees
<lifeless> the UUID the commit is to be assigned
<jonnyde1> but imagine a batch script in which I create a repository
<lifeless> as james_w says, you can export to e.g. fastimport, or even to a series of patches, and in terms of your user data what you get back after importing again will look the same
<lifeless> but bzr will consider them to be different projects
<jonnyde1> then I do create some files, create dirs, add them, rename them, etc.
<lifeless> jonnyde1: sure, we do this thousands of times in the test suite for bzr
<jonnyde1> now when I execute the same script on a repository with a different format, it just works
<lifeless> jonnyde1: and every single time they are unique
<jonnyde1> ok, now I see
<lifeless> jonnyde1: the script works, the identity of the content is different
<jonnyde1> so you would also get different revision ids?
<lifeless> yes
<lifeless> and different file ids
<jonnyde1> and how do you implement upgrade/downgrade without stumbleing over the same issues?
<lifeless> we're working with the structured data
<lifeless> actually, there is a logical argument here:
<lifeless> if you define something that stores the very minimal data needed to exactly reproduce a bzr repo
<lifeless> you have defined a bzr repository format
<lifeless> its no more neutral than the formats we ship in bzr itself
<jonnyde1> makes sense...
<lifeless> you might not call it a format, and you might not use bzr's format machinery to manage it, but it would be performing the same job
<lifeless> if it looks like a duck, smells like a duck, and quacks like a duck, might as well call it a duck
<jonnyde1> and why doesn't svn have to deal with this issues? is it because there are no cryptographic ids?
<lifeless> svn has the same issue
<lifeless> if you run svn 1.5 on a svn 1.4 tree, it upgrades it and svn 1.4 will no longer work
<lifeless> you have to dump and restore svn repositories to upgrade them on the back end as well
<lifeless> I don't know why svn is not _percieved_ to have the same issues, but it has them :)
<jonnyde1> but I can dump the contents of 1.4 and import them into 1.5 -- and vice versa
<jonnyde1> without loss of information ... AFAIK
<lifeless> you can downgrade a bzr repository from packs-0.92 to knits without loss of information
<lifeless> because thats simple layout, not data model
<lifeless> you can't do a merge in svn 1.4 and have it be tracked, you need svn 1.5 - thats data model
<jonnyde1> ok, I think I am starting to understand....
<jonnyde1> well, the reason why I wish there was some kind of independent format is that I pushed a branch to launchpad using bzr.dev and its newest repository format. And after that there was no way back for downgrading....
<lifeless> jonnyde1: sure there is
<lifeless> jonnyde1: bzr upgrade sftp://.... --format=FORMATNAME
<lifeless> some format choices are one-way, because there is data loss going backwards
<jonnyde1> it told me something like downgrading from that format is not implemented yet...
<lifeless> but the default is not like that, you would have to have explicitly chosen a format that is past that one-way barrier
<lifeless> jonnyde1: whats the branch url?
<jonnyde1> yes, now I understand why. It's indeed a by design issue
<jonnyde1> well I removed the branch completely and created a new branch with an older format
<lifeless> jonnyde1: what was the format you had used?
<jonnyde1> and locally I threw away my history and created a new branch with new revisions from scratch
<jonnyde1> I used --rich-root-pack, I think. But just a moment...
<lifeless> jonnyde1: ok, *why* did you do that?
<lifeless> jonnyde1: its not the default for a reason :)
<jonnyde1> well, I thought it sounds like it stores more information so my guess was that I should be more stable for future format changes...
<lifeless> jonnyde1: you should only use defaults unless you have a specific reason to use something different
<lifeless> it does store more information, and most things should work with it, but you do need a slightly newer bzr than you do for the default format, which only needs bzr 0.92
<jonnyde1> well, that sounds reasonable. But on the other hand there isn't any suggestion to do so in the documentation or bzr help
<lifeless> bzr help formats:
<lifeless> ...
<lifeless> rich-root-pack:
<lifeless>     (native) New in 1.0: Pack-based format with data compatible with
<lifeless>     rich-root format repositories. Incompatible with bzr < 1.0
<jonnyde1> well, but I am always using the newest bzr version
<lifeless> jonnyde1: then why did you dislike the behaviour of rich-root-pack? did something go wrong?
<jonnyde1> the problem was I upgraded my local repository to the newest rich-root-pack format
<jonnyde1> then I had to do the same with the one hosted on launchpad
<lifeless> yes
<jonnyde1> because bazaar told me the formats were incompatible
<lifeless> thats normal for rich-root changes, what went wrong though?
<jonnyde1> launchpad was not comfortable with a repository format named 1.7dev and rich-root-pack
<lifeless> lp handles rich-root-pack fine
<jonnyde1> so actually nothing went wrong except that launchpad had a problem with it
<lifeless> lp won't handle development formats, because it runs bzr releases
<jonnyde1> but it told me that 1.7 is not supported
<lifeless> bzr has not released 1.7 yet
<lifeless> lp only supports released bzr versions
<jonnyde1> yes, exactly. so I tried to downgrade it again
<jonnyde1> and this is where I got stucked
<lifeless> if you downgrade to rich-root-packs it would have worked
<lifeless> ok, for future reference - launchpad supports bzr released versions only
<lifeless> you can upgrade between any format version that has the same data model
<jonnyde1> yes, maybe. but a first downgrade with wrong parameters exited with a downgrade not implemented yet. so there was left a backup.bzr at launchpad
<lifeless> so *-rich-root are all compatible with each others
<lifeless> you can delete backup.bzr there using hitchhiker
<jonnyde1> and the second try exited with the message that there is already a backup.bzr
<lifeless> its a bug in lp that thats not easily removable
<lifeless> I'm sorry you had trouble
<jonnyde1> lifeless: no problem -- really!!! :)
<lifeless> and more sorry you didn't get good support :(
<jonnyde1> I mean I lost some revisions from history but there were only a few until now, anyway
<jonnyde1> it was a fresh project
<jonnyde1> And it was my fault to use a development version of bazaar
<jonnyde1> So please don't mind ;)
<lifeless> ok :)
<lifeless> anyhow - take away message is that you can use development formats locally, but you need to do a little special thing when pushing from them to launchpad
<jonnyde1> and regarding support: I couldn't get better support :)
<lifeless> what you need to do is do 'bzr init --MODEL lp:..' rather than just a 'push'
<lifeless> e.g. if you chose --development-rich-root locally, you would do 'bzr init --rich-root-pack lp:foo' to make a branch that LP understands that you can push to.
<jonnyde1> ok, thanks -- I will do that, instead
<jonnyde1> lifeless: thank you very much for taking the time to answer my questions. It is really really nice of you :) :) :)
<lifeless> my pleasure
<jonnyde1> So have fun and a nice day/night . best regards
<lifeless> thanks, I shall!
<lifeless> jml: lol @ forcing you to use a dictionary :)
<sohail> hey guys
<sohail> I've been working on a project and I want to put up a repo of it (don't really care about history). Is there some document that tells me how to set up my development so I can push to that repo securely?
<lifeless> bzr push URL ? :)
<sohail> over http?
<sohail> sorry my brain is fried today but I fear this is as good as it is going to get!
<lifeless> sure, if you have bzr configured in your apache config and use https rather than http
<lifeless> or you can use sftp or bzr+ssh
<sohail> ah
<sohail> so I hate mucking around with apache... Can I do it without telling Apache this is bzr?
<lifeless> is you isntall the webdav plugin and enable webdav on your server (and use https :))
<lifeless> most people use bzr+ssh or sftp though
<sohail> so how do I let people clone it then?
<sohail> like I don't care about pushing over ssh, that's what I do now
<sohail> but I don't know how to let people clone it
<sohail> again, please refer to brain fried state above if this sounds totally stupid
<lifeless> just have the place you pushed to be served by apache
<sohail> over plain http?
<sohail> sweet
<sohail> no futzing around with apache?
<sohail> double sweet
<sohail> so do you guys have one bzr repository for all your projects or multiple repos
<mwhudson> multiple repos, on the whole
<sohail> I see
<sohail> what are the benefits?
<sohail> mwhudson, I'm not a bzr expert but what do you do when one of your projects depends on another?
<mwhudson> sohail: symlinks, basically
<mwhudson> but i'm not really responsible for the setup or deployment side of things
<sohail> you non-windows user you
<mwhudson> :)
<mwhudson> there's no real disadvantage to one-big-repo, i think
<sohail> symlinks are a perfect solution until you hit the dreaded C:\> prompt
<lifeless> sohail: when there are dependencies between projects, I think best practice is to install the inner one and build on the installed copy
<lifeless> and/or provide variables to build on an uninstalled copy
<sohail> mebbe
<sohail> not a huge deal anyway
<sohail> now next question :-D
<sohail> how can I track a svn repository in bzr?
<mwhudson> various ways
<mwhudson> request an import on launchpad
<mwhudson> or bzr-svn
<mwhudson> being the two main ways
<sohail> bzr-svn sounds promising
<kiko> let's say
<kiko> I have a file in one branch that has its own history
<kiko> how do I bring that file into another branch with full history?
<lifeless> file histories don't have log messages, you need the full branche for that
<lifeless> so you'd do bzr join to join the branches
<kiko> gotcha.
<kiko> so
<kiko> is having some big files in .bzr/repository/upload normal?
<kiko> can I kill them? :-(
<lifeless> they are temporary files during commit/push/pull/merge
<lifeless> if you have no bzr processess doing that, then yes.
<kiko> thanks
<kiko> should they not be cleaned up the next push or so?
<lifeless> they only get left if bzr gets disconnected/physically interrupted
<kiko> well
<lifeless> kiko: we can't tell if they belong to an active process, so no.
<kiko> the funny thing is that this file is 300MB, but the actual .bzr folder itself is about 1MB
<lifeless> probably you interrupted a bzr push of launchpad to that repo :)
<kiko> could it have been a bzr merge?
<lifeless> sure
<kiko> ah, then that's what it was
<kiko> how could you guess?!
<lifeless> I know how big launchpad is :P
<rocky> jelmer: don't suppose you had any luck tracking down that issue today ?
<jelmer> rocky, I did
<rocky> oh? something i can test?
<jelmer> It should work now, haven't tried with your URL though
<jelmer> rocky, 0.4 branch
 * rocky tries
<rocky> jelmer: while i'm waiting for this to checkout ... do you use tracbzr much?
<Peng_> Why have bzr-svn default to 1.6-rich-root?
<jelmer> rocky, yeah, we use it for bitlbee and ctrlproxy
<jelmer> Peng_, Seemed like a sane choice since it'll only work with bzr 1.6 anyway
<rocky> jelmer: oh, should i be creating my repo with --rich-root-pack or 1.6-rich-root ?
<jelmer> rocky, either will work
<rocky> jelmer: another error --> http://cluebin.appspot.com/pasted/801
<Peng_> rocky: 1.6-rich-root supports stacking, but isn't compatible with older versions of bzr.
<jelmer> rocky, sorry, uncommitted change
<rocky> jelmer: let me know when your'e ready
<jelmer> rocky, please try again
<rocky> jelmer: k, recreated repo and checking out the svn source again
<rocky> jelmer: well, the checkout is taking a lot longer this time ;)
<rocky> the amount of http requests this is doing for a checkout is astounding
 * rocky is watching his remote server logs
<rocky> jelmer: when i'm doing a checkout of a particular folder/trunk ... why is it querying all kinds of other folders that aren't in the hiearchy ?
<jelmer> rocky: it needs to search for revisions not on the mainline
<rocky> jelmer: ok it worked ... and i just added a dummy test file and it's considerably faster, but still slower than i'd expect ... that commit (of one file) did about 50 http requests to my server
<jelmer> rocky, incremental commits should be faster
<rocky> define: incremental commit
<jelmer> rocky, if you do another commit, it should be faster
<jelmer> if not, how fast is it?
<rocky> even when i do a commit it's checking all kinds of branches of other projects that aren't in my project's hierarchy
<rocky> this 2nd commit is taking longer than the first one did
<jelmer> rocky, It has to check whether the revision is already present elsewhere
<jelmer> rocky, since bzr does a push under the hood
<rocky> jelmer: added a 2nd file...
<rocky>  time bzr commit -m "Another checkin test"
<rocky> Committing to: https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk
<rocky> added test.txt
<rocky> Committed revision 113.
<rocky> real	1m4.238s
<rocky> user	0m2.168s
<rocky> sys	0m0.148s
<rocky> (bzr-1.6)rocky@zebrax:/usr/misc/apps/bzr-1.6/sandbox/repo/ClueMapper-trunk$
<rocky> whoops, sorry
<rocky> didn't realize it was so much
<jelmer> rocky: This is bug 158657
<ubottu> Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657
<rocky> jelmer: that commit that i just pasted ... did 347 svn requests according to my remote apache log
<rocky> so that's my 3rd commit ... so far it seems like things are slowing down more
 * rocky wonders if he's the only one having these major slowdown issues
<Peng_> You're not
<jelmer> rocky, do you have a lot of directories on the same level as your branch?
<rocky> jelmer: https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk/ is the "branch" i'm "bzr checking out" ... you can look at it your self... at the same "level" as trunk the only other folders are branches and tags in true svn style
<jelmer> rocky, there's a lot of things at the same level it looks like
<jelmer> it'll check https://dev.serverzen.com/svn/*/*
<rocky> jelmer: lol how's that the same level?
<jelmer> same level of nesting in the repository
<mwhudson> jelmer: shouldn't you be asleep? :)
<rocky> jelmer: hmm.... so where does this leave us? :)
<jelmer> mwhudson, yes, I *should* :-) messed up biorhythm again
<jelmer> rocky, it'll be slow for a while, until bug 158657 is fixed
<ubottu> Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657
<rocky> jelmer: i honestly don't think i'll be able to stick it out much longer... these slow commits have been killing me now for the past several weeks :/
<jelmer> rocky, alternatively, you can just work in bzr and push to svn in batches
<rocky> jelmer: the only reason i haven't switched a lot of my stuff to bzr is the fact that i want to reduce the barrier for people to help in my community projects
<mwhudson> i took that line for a while
<mwhudson> then i just gave up and switched 100% to bzr
<jelmer> rocky, what I mean is, you don't have to use a checkout
<jelmer> rocky, you can just use bzr and maintain a mirror in svn using bzr-svn
<lifeless> abentley: welcome back :)
<abentley> lifeless: thanks.
<mwhudson> heh, wb bb
 * vila warms up, reset clock, 22min to go to start at 08/08/22 08:00
<lifeless> vila: :)
 * vila 's internal security check failed, caffeine too low. launching delayed by ~8mins
<lifeless> rotfl
<lifeless> jam: isn't it your bedtime ? :)
<vila> 08/08/22 08:08:22 IGNITION
<vila> Hello World !
<lifeless> welcome :)
<vila> lifeless: thanks :)
<mwhudson> vila: hi :)
<vila> mwhudson: hi !
<uws> Is there a way to "svn checkout" using bzr without downloading full history?
<uws> Just a "get me started RIGHT NOW" basically?
<uws> only downloading history when needed, e.g. for diffing
<uws> or just the last few revisions
<RAOF> uws: I belive the answer is 'yes'; bzr checkout --lightweight will get you a 'this revision only' checkout, I believe.
<uws> hmmm. will that work for foreign svn  branches as well?
<luks> probably, but it will still need to cache all the revision metadata
<luks> but I probably shouldn't be saying this if I'm not sure :)
<uws> it would be a killer feature for many ppl forced to use svn today
<uws> importing like ~10000 revisions into bzr is NOT fun
<uws> can take > 2 days
<mwhudson> stacked branches may give you that
<mwhudson> at some point
<vigneswari> hello all
<vigneswari> how to set permission to access particular folder alone for a particular user
<bob2> bzr doesn't support that, sorry
<bob2> except by making it its own branch
<vigneswari> bob2, who will make that? users they themselves
<vigneswari> but svn has this feature know?
<bob2> sorry, I don't understand the first part of your question
<bob2> but I believe svn lets you set permissions on particular paths in a repository
<vigneswari> bob2, yes..
<vigneswari> making it its own branch?
<lifeless> uws: 'bzr branch --stacked' I believe, should work now
<vigneswari> means...user will create the branch as own branch?
<bob2> you can restrict access to branches, just not to particular dirs within them
<vigneswari> bob2, ok how to do that
<bob2> just create the branch and set the unix permissions on it so only they can access it
<bob2> assuming you're on unix
<uws> lifeless: this stacked branch will cache locally?
<uws> lifeless: and can I convert it to a real branch, e.g. overnight when I'm not using it?
<lifeless> uws: you can just branch from it again to make it full
<lifeless> uws: work you do locally will be stored locally, if you pull from somewhere etc it will store it locally if its not in the parent already
<uws> lifeless: so it's basically a "smart" branch that only pulls when really needed.
<uws> so that I can start hackign right away
<uws> use case: work on $project which is hosted in svn, it has like 1000 revisions
<lifeless> yes, and one that needs to be connected to the real server - because it doesn't have everything locally
<uws> and I don't want to touch svn ;)
<uws> and I do want to get started right away
<lifeless> uws: yes, thats the use case for it - avoid downloading deep history
<uws> lifeless: will "bzr log" require all history?
<lifeless> uws: naturally
<lifeless> uws: unless you do --line or whatever, it will do it incrementally as normal
<uws> lifeless: (I thought perhaps commit log messages are stored separately from the actual diffs)
<uws> anyway, this is 1.6 only right?
<lifeless> right
<lifeless> uws: it will access just the commit messages from the remote server
<uws> Can I define my own prefixes, just like lp: ?
<luks> only using a plugin
<luks> but you might want https://launchpad.net/bzr-bookmarks instead?
<luks> it allows you to define aliase and then bm:<alias>
<luks> or bm:<alias>/some/other/subpath
<luks> this plugin was originally written only as a joke, and turned to be probably the most useful plugin I wrote :)
<bob2> haha
<siretart> any recommendations how to install bzr on a sles9 system?
<luks> download the tarball and python setup.py install?
<luks> (I expect the packaged version to be ancient)
<siretart> sles features python 2.3
<siretart> so I'd first have to deploy python2.5 first.. that's why I ask if someone had already done that
<luks> oh
<bob2> bzr py2exe installer + wine
<uws> luks: trying your bm plugin now. can I use for prefixes as well?
<luks> uws: not for lp: like prefixes
<luks> uws: but you can use bm:<alias>/some/other/path instead of yourprefix:some/other/path
<uws> luks: Thanks, got it to work!
<uws> bzr log bm:ilps/PROJECT/BRANCH  works ;)
<uws> (ilps is my university department/group)
<lifeless> siretart: 2.4 is all we need
<lifeless> siretart: can you get python 2.4 for sles9?
<siretart> lifeless: sles9 only ships python2.3. I have now installed python2.5 in a private, user writable path
<siretart> now I have a working bzr 1.6rc5 :-) - now let's get this cvsps thing working
<siretart> I assume that version 1.99-152.1 is stone age, right?
<lifeless> no idea :)
<lifeless> <- Ubuntu/Debian only :P
<siretart> isn't there a cvsps branch on launchpad somewhere?
<siretart> does cvsps upstream still exist at all?
<lifeless> gnight
<lifeless> siretart: I don't know, I would tend to apt-get source :P
<siretart> yeah
<siretart> okay, cvsps_import seems to be running now on this sles9 system. converting a 10 yrs old cvs managed perl project to bzr for good
 * kiko reminds siretart of his debts to society :-P
<fullermd> Surely 10 years of using CVS is enough to work off any debt   :-P
<gour> 10 years of CVS? it sounds as eternity...i'm (was) not ready for it :-)
<fullermd> Well, *I* had 10 years of CVS.  "Eternity" is what goes by waiting for 'bzr branch' across a network.  10 years of CVS is much, much worse...
<mwhudson> well, i got a job working for this company who use this cutting edge version control system and ended up learning far more about cvs that i did (or wanted) to know!
<siretart> kiko: hey, I also have a real job :-)
<fullermd> You "win".   :p
<kiko> siretart, no you don't!!
 * awilkins knows more about MKS that he wants to know
<awilkins> MKS is based on CVS.
<awilkins> With added evil
<\3TATUK> Which port does the bzr smart server use default?
<hsn_> is bzr native faster then bzr+ssh?
<AfC> 4155
<Leonidas> how to do an iter_changes from revision 0 to the first one?
<Leonidas> iter_changes can, as far as I know just compare between trees and I have no idea how to get the empty tree for revision zero (empty repo)
<fullermd> hsn_: It's the same protocol.  It's presumably marginally faster since it doesn't have to do all the ssh-layer negotiation and encryption and all, but that's probably either constant of negligable.
<LeoNerd> fullermd: I use the ssh controlmaster stuff for most of my connections anyway... so setup/auth/teardown time doesn't happen
<fullermd> I keep wnating to play with that, but last time I looked at it it had some giant gaping flaw that made it unworkable without going way out of my way.  Don't remember what it was...
<LeoNerd> It can get a bit annoying on occasions, in those rare few times you -want- a new connectin
<LeoNerd> E.g. when upgrading an ssh server
<hsn_> bazaar works on python2.3?
<james_w> hsn_: no, you need at least 2.4
<hsn_> sadly we have centos 4.6 on all our servers
<uws> Yay
<uws> project at $work (univ) has officially switched from SVN to Bazaar!
<em1> hi
<em1> it always complain "You have not informed bzr of your launchpad login.."
<em1> what should i do?
<em1> im a newbie
<luks> bzr launchpad-login USERNAME
<luks> is that a problem? :)
<em1> yes
<em1> luks
<em1> yes, what i should input?
<luks> didn't I say it already?
<em1> what did you say
<em1> should i input 'bzr launchpad-login em1'?
<gour> em1: <luks> bzr launchpad-login USERNAME
<gour> em1: have you registered at LP?
<em1> no
<luks> bzr launchpad-login USERNAME
<gour> then do that 1st
<em1> ok
<awilkins> Someone with username em1 has been a launchpad member since 2006 though
<em1> luks, i have type 'bzr launchpad-login USERNAME' and that does not help, lol, apparenly Username should be replace with something
<luks> well, with your launchpad username :)
<em1> after i registed a name, but bzr still does not satisify, how to do?, it say:
<em1> bzr: ERROR: The user jvava has not registered any SSH keys with Launchpad.
<gour> em1: paste some of your ssh keys to LP
<em1> gour, i dont know where and what my ssh keys
<gour> em1: do you use ssh? on LP login and then change details --> SSH keys
<gour> em1: read https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<em1> gour, im using bzr in cmd console in window xp
<gour> em1: i'm on linux, but read the above url and configure following putty setup
<em1> ok, im checking it
<jelmer> beuno, any chance another upload of bzr-search can be sponsored
<jelmer> the license was incorrect so the previous one was rejected
<em1> i dont know how to treat the private key while public key is pasted into the textbox
<jelmer> beuno, and please say thanks to mlt for sponsoring from me
<gour> em1: is your public key accepted on LP?
<beuno> jelmer, I can sure try!  Did you re-upload?  (I will thank her)
<em1> gour, i have not download putty , can i use java produing public/private key instead?
<gour> em1: cannot say for sure. no idea about windows & ssh
<gour> ...applications
<em1> windows have the concept of ssh
<em1> can i use a a password to pass the identify ?
<em1> i have a password when i registerd
<gour> you must have your public ssh key on LP
<jelmer> beuno, yep, to mentors.debian.net
<gour> em1: have you read Why you need an SSH key
<LarstiQ> em1: alternatively, you can just ignore the message.
<beuno> jelmer, will pass it on
<em1> i estimated that the ssh key is identical to one java produced though they all be rsa key pair
<em1> gour, i have read, but not know very much of it convey
<em1> Larstiq, i just want to checkout a branch
<em1> must i have a ssh key?
<gour> "To push code branches to Launchpad you first need to generate your SSH key."
<em1> i see
<LarstiQ> em1: do you want to push changes, or only get changes?
<em1> i have not need to push changes , lol
<em1> but why can not i download all? when i input 'bzr branch lp:openerp'
<LarstiQ> em1: so in that case, you don't need to have a launchpad login set, and can ignore that it says you don't.
<em1> in fact, i got only two files
 * LarstiQ goes fetch his bike from the repairshop
<em1> how to check out source? is it 'bzr co lp:xx'?
<gour> em1: see http://bazaar.launchpad.net/~openerp/openerp/package-script/files
<pickscrape> I'm struggling to find docs on how to configure branch.conf to make bzr send more 'automatic'
<pickscrape> i.e. pre-populating the destination email address etc
<gour> em1: those 2 files are 'sll'
<gour> *all
<em1> then where is all sources, in the office site i read that download all source by that command
<gour> em1: have you executed that python script?
<gour> pickscrape: bzr help configuration ?
<em1> no, i have not python engine installed until now
<gour> well, install it then ;)
<em1> by running the python script can i got all sources?
<gour> most probably
<em1> look, still error: 'ImportError: No module named bzrlib.builtins'
<awilkins> pickscrape: It can read it from the child_submit_to parameter on the submit branches branch.conf file, I think
<pickscrape> awilkins: Ah, thanks!
<pickscrape> I'm seeing that in the 1.3 release notes, but google isn't finding it in any actual documentation
<awilkins> pickscrape: I confess, I read the code to find out
<pickscrape> :)
<pickscrape> It looks like there is a hole in the documentation there. Does such a thing warrant a bug raising?
<awilkins> I would say so. Or a patch to the cmd help
<pickscrape> Does the cmd help also get reflected in the online documentation?
<awilkins> Looks like it just scrapes them to make the user reference, but it should also go in the "branch type specific options" section of the config lists
<awilkins> Gah, really need a "supress repacking" options
<pickscrape> When people on the bzr mailing list review [MERGE] emails, what mail client do they generally use? (general question)
<pickscrape> I'm using Thunderbird and I find that replying to such a mail doesn't give the patch part
<pickscrape> I suppose I could just copy and paste it from the email, just wondering if that's what everyone else has to do too, or if I'm missing something.
<LarstiQ> pickscrape: personally, mutt
<LarstiQ> pickscrape: but others use Thunderbird/Evolution/mutt, etc
<fullermd> Others have all sorts of weird personality quirks  ;p
<awilkins_> I use Thunderbird ; it shows the attachments inline if they are text, which is why it seems weird when replying and they don't show up.
<jelmer> don't forget gnus ;-)
<pickscrape> awilkins_: do you just copy and paste if you reply to review code then?
<awilkins_> pickscrape: As yet, my review comments have been limited to "Looks ok to me"
<pickscrape> I'm just plotting our next evolution in workflow following our migration to bzr and I want to have all bases covered :)
<awilkins_> pickscrape: But I'd probably cut-n-paste from the original mail view if I had to
<pickscrape> Right. Makes sense: I think I was just surprised that it wasn't just there when hitting reply because as you say it is there in the reader display
<fullermd> I'd just read in the patch, write in my comments, and delete the bits I wasn't touching on.
<pickscrape> I really like the idea of being able to annotate beneath specific lines in the code.
<awilkins> fullermd: You're using some kind of vim-based mailer?
<LarstiQ> mutt \o/
<LarstiQ> pickscrape, awilkins: you might want to ask abentley, I believe he used Thunderbird as well
<pickscrape> I keep meaning to try mutt, but Thunderbird's colorediffs extension is *really* nice.
<abentley> LarstiQ, pickscrape, awilkins: Thunderbird used to include text attachments in replies.  I am upset that it no longer does.  I just select all, and Ctrl+Shift+v
<LarstiQ> abentley: ouch, that seems like a bad decision.
<awilkins> It doesn't even have an option for it, as far as I can see
<luks> same for evolution, it used to include them and now it doesn't
<pickscrape> Yeah, I dug around for an option but found nothing (even in the advanced config editor).
<fullermd> awilkins: Well, I sure wouldn't use a mailer that didn't let me choose my own decent editor for the mail writing bit...
<cody-somerville> Is there a good bzr gui client for Windows?
<LarstiQ> cody-somerville: have you looked at TortoiseBZR?
<cody-somerville> LarstiQ, Yes. It only does commit and diff and branch
<LarstiQ> hmm, that doesn't sound like what I think it should do.
<Tak> there's bzr-gtk/olive for win32...
<LarstiQ> cody-somerville: other than that, I think it's Olive or bzr-eclipse (possibly bzr-visualstudio)
<Verterok> cody-somerville: thre's also qbzr
<LarstiQ> cody-somerville: do you spend time on win32 often?
<cody-somerville> LarstiQ, Not at all
<LarstiQ> Verterok: do you highlight on bzr-eclipse? :)
<Verterok> LarstiQ: hi
<LarstiQ> cody-somerville: Alas. We could use some more people there.
<Verterok> LarstiQ: sure :)
<cody-somerville> LarstiQ, Two of my coworkers from my previous employer use bzr on Windows.
<Verterok> LarstiQ: and a few more hilights bzr-eclipse related ones (xmloputput, eclipse and so on) :)
<Tak> I use bzr on windows, when I have to
<LarstiQ> cody-somerville: would they perchance be willing to assist in development?
<cody-somerville> LarstiQ, I doubt it :-]
<LarstiQ> cody-somerville: darn :)
<LarstiQ> Verterok: :)
<cody-somerville> I'll be happy to pass along any bug reports though
<LarstiQ> cody-somerville: cool
 * LarstiQ proceeds to take his desk apart
<hsn_> there is difference between bzr check output on windows and unix. On unix it prints summary while on windows not
<awilkins> hsn_: It prints a summary here, what version of bzr are you using?
<bob2> check bzr alias output to make sure you don't have an alias with -q or something
<hsn_> awilkins: bzr 1.5 python install
<hsn_> it shows progressbar but no summary
<hsn_> bzr check -v gives same result
<jam> vila: are you still around?
<jam> Just wanted to say congrats on your first day
<beuno> right!  vila, welcome  :)
<beuno> jam, btw, I'm going to be sprinting next week in London, so I don't know how/when I'll be able to get to the packaging  :/
<hsn_> oh, its not printed because of installed plugin xmloutput
<hsn_> uninstalling plugin makes it work
<jam> beuno: Well, if you just test out luks stuff and give the green light, it seems easy enough for me to make it work.
<jam> I'd like to move the appropriate branches to ~bzr locations
<jam> etc
<jam> rather than have the official packaging branches be in his namespace.
<jam> nothing against him, but nobody else can commit there :)
<beuno> jam, I'll try and get to it, but I'm very behind on what I want to have finished, and I fly tomorrow
<beuno> what you may be able to do
<beuno> is trick someone into uploading them into their PPA
<beuno> and you just copy each one to ~bzr
<beuno> (possibly test first)
<jam> beuno: bah, testing :)
<fullermd> All testing ever does is cause bugs.
<jam> beuno: do you have the link?
<jam> I sort of remember it
<jam> https://edge.launchpad.net/~luks/bzr/packaging-tools
<jam> right?
<beuno> jam, yeap
<jam> james_w: By the way "bzr co lp:bzr-builddeb" doesn't work because you have the wrong branch nominated as your 'development focus'.
<hendrixski_work> :-( is there a way to branch from what you're locally working on... kind of like in git  using   git checkout -b "newBranchName"  where it creates a branch in place?
<hendrixski_work> or, would I have to go to a separate directory and branch from the original directories location using bzr?
<cody-somerville> hendrixski_work, sure
<cody-somerville> hendrixski_work, do you want it to branch the working tree (ie. stuff that might not be committed)?
<hendrixski_work> cody-somerville: I don't know the names for doing these operations (which makes googling difficult)  but from your description... yes,  I've got some changes I made that I'm not sure I want to comit to my main effort, so I want to branch them, and then be able to revert to a different branch, take that in a direction ...etc.
<cody-somerville> just copy the directory
<hendrixski_work> basically trying to do what this guy is doing in this video using git   http://www.g2one.com/quickcasts/movies/gitGrailsScreencast_web_final_compressed.mov
<hendrixski_work> cody-somerville: ah, so I need to copy it elsewhere and branch against it?
<cody-somerville> copying it makes a branch
<cody-somerville> although if you want the second branch to see your first branch as the parent branch, you'll want to use bzr branch
<cody-somerville> In which case, I think you'll have to commit your changes
<cody-somerville> Or...
<cody-somerville> I suppose you could just branch your current instance w/o committing
<hendrixski_work> hhmm, 'cause in the git video the guy creates a branch of the current directory without switching or copying or anything... then does some changes, then reverts to a different branch, and merges ... all without switching.  And.. I don't want to learn git, I'm just barely learning bzr, and i like it.
<pickscrape> You can bzr branch old_branch new_branch and then in new_branch bzr merge --uncommitted ../oldbranch
<pickscrape> Another alternative is to use shelve to put changes you want to deal with later away in a safe place
<hendrixski_work> shelve?
<pickscrape> Lets you put changes aside and pull them out again later
<hendrixski_work> cool
<pickscrape> If you have bzrtools installed, bzr help shelve or bzr help shelf
<hendrixski_work> hhmm, well, I'll look at those options :-)
<hendrixski_work> Thanks cody-somerville and pickscrape
<cody-somerville> \o_
<pickscrape> np
<awilkins> hendrixski_work: Watching this video, he is switching, it's just that git is doing it implicitly
<awilkins> hendrixski_work: The same workflow is a little more involved with bzr because you need a repo, and to switch as quickly (with simple branch names not paths) you need to be running lightweight checkouts or have a certain patch that's pending in the PQM
<hendrixski_work> oh
<awilkins> Actually, you don't need a repo, it just works a lot better if you do
<awilkins> And he's using rebase in at least one place
<awilkins> It's a nice video, makes Grails and git look really good :)
<awilkins> And it clarified what "rebase" does in my head (although not yet, why it is desirable)
<awilkins> Which so far I hadn't understood
<awilkins> jelmer: Since you wrote rebase for bzr, perhaps you can tell me what it's useful for :-)
<jam> awilkins: responding to people who say they want to rebase because they use git and think they need it
<jam> awilkins: mostly it is used to make your version history "better looking" than it really is
<awilkins> Ah, political features
<awilkins> In both senses :-)
<jam> There are a couple use cases that I've seen
<awilkins> Is that the rebase -i for super-tidying
<jam> 1) You submit your changes to upstream as a series of patches
<jam> and for whatever reason you need that to be identical
<jam> to your series of commits
<jam> (looms do this in a different way, by representing your series of patches by a series of *branches*)
<jam> 2) People feel that extra "merge trunk" commits are "useless and ugly and wasteful"
<jam> so they want to keep popping their changes to make them seem based on whatever the latest tip is
<awilkins> Ah, so 2) is so you can just "pull"
<jam> awilkins: something like that
<pickscrape> I think they call it 'fast forward' don't they?
<awilkins> I would find that less informative...
<jam> 3) reordering history because you accidentally did things out of order
<jam> like you committed
<awilkins> I mean, the London Underground Diagrams are useful
<jam> feature-a, feature-b, update-to-a, update-to-b
<jam> and you want "feature-a, update-to-a, feature-b, update-to-b"
<awilkins> Hmm. Well, now the knowledge is implanted, maybe my sunconscious will find a use for it
<jam> awilkins: my personal feeling is that merge commits can be more than just "necessary" but actually quite informative and useful
<jam> look at bzr.dev
<jam> every commit is a merge commit
<jam> and 'bzr log --short' gives you a great feature-by-feature of what has changed
<jam> fast-forward doesn't have any way to give you that
<pickscrape> No, it stops you from seeing the wood for the trees
<jam> which is one reason why you rebase
<awilkins> I agree ; a frustration with my current development habit is that it's highly subversion-informed and all my commits are in one boring straight line
<jam> because you see all patches all the time
<jam> so they should all be "pristine"
<jam> I've moved on to a model where my feature branches can be as broken as I need them to be to make forward progress
<pickscrape> qlog does a great job of allowing you to 'expand' them at will too.
<jam> as long as at merge time, they are polished
<jam> pickscrape: I <3 qlog
<jam> it is what I wanted from "bzr viz" for a long time
<pickscrape> I didn't until a few days ago. And then the next day it broke for me and won't work any more :(
<luks> I think the most common use case is that you have committed a revision, now you want push and you realize the branch it out of date
<jam> I tend to make incremental commits that are more "logical" based, rather than having to have the whole test suite polished at each step
<awilkins> jam: I started using sibling-switch which is why I submitted that patch that makes it work with heavy checkouts
<pickscrape> jam: do you have any problems with column resizing in qlog?
<awilkins> jam: It could also do with sibling-switch-and-push-a-new-branch-if-it-isn't-there-and-switch-nicks-too
<jam> awilkins: sure, I just do it with lightweight ones in a local shared repo
<jam> and I can see the utility of "bzr switch --create-it"
<awilkins> jam: I used heavies because the repo is on a thumbdrive and I might leave it somewhere
<jam> pickscrape: I haven't used it in a "recent" version
<jam> maybe 1-2 weeks ago
<luks> in that case you can either merge the push branch into your branch, and create one extra commit or rebase
<luks> using rebase instead of regular merge is just insane, IMO
<brl4n> hola
<awilkins> luks: The project I've been using bzr for is doing just that workflow - they need diff reports as if "rebase" had been done ; so I'm doing a merge from trunk into branch before diffs, and then a merge to trunk after ; conflicts get resolved in the branch, not hte trunk
<awilkins> This was before I understood rebase
<awilkins> But I still think it's valid and useful
<jam> brl4n: You had problems with sftp and winxp, right?
<jam> Are you using plink?
<awilkins> I think paramiko is a better bet pageant / paramiko seems to work best for me
<brl4n> jam:yeah I am still having problems. I am not using plink (to the best of my knowledge).
<jam> brl4n: what 'ssh' are you using then?
<jam> cygwin ssh?
<jam> I think you mentioned 'openssh' earlier
<brl4n> yes I actually installed the copssh package
<awilkins> copssh is a server package, isn't it?
<brl4n> awilkins:client and server yes
<brl4n> i was able to remotely ssh and sftp using various clients without any problems so I'm not sure what to do
<awilkins> brl4n: Try paramiko
<awilkins> http://www.lag.net/paramiko/
<awilkins> Unpack it and run Python setup.py install
<brl4n> okie
<awilkins> Then set your BZR_SSH environment variable to "paramiko" (or delete it, I thikn it's paramiko by default)
<luks> awilkins: using rebase does make sense only if you have a few local revisions
<awilkins> luks: My users are well chuffed with how much faster than their old merge process it is
<awilkins> luks: Previously they had to painstakingly re-do any work that conflicted
<luks> awilkins: I probably wouldn't use rebase in a state where I need to resolve conflicts
<awilkins> luks: Well, since I've proved that trunk > branch > trunk works, I'm not about to kick the wasps nest
<brl4n> why doesn't windows just come w/ ssh
<brl4n> so bizarre
<awilkins> Because they prefer RDP ; it just fits their worldview better
<brl4n> cause everyone uses RDP!?
<awilkins> Besides, you ever try to admin an NT 4 box with just a command prompt?
<brl4n> no sir.
<awilkins> Neither have I, I'm too afraid :-)
<brl4n> didn't know NT4 was still running
<awilkins> I'm prepared to bet there are still some out there, in hide-bound places
<awilkins> It was running the email service in my last place far beyond it's sell-by date
<brl4n> ugg, terrible
<awilkins> Truly. I think it had a 2GB limit on TOTAL email.
<awilkins> There was one mailbox in marketing that had nearly half od it crammed with PPT files
<brl4n> that doesn't sound impossible
<brl4n> always odd limits everywhere with windows
<brl4n> not even sure why I bother with it anymoe
<awilkins> For me 1) Games 2) Because it's what they have at work and a lot of their old crap is tied to it
<brl4n> does python 2.5 come with the crypto built in
<awilkins> brl4n: I think you need to install pycrypto too
<brl4n> or do I still need http://www.amk.ca/python/code/crypto.html
<jam> or if you have easy_install it is just "easy_install paramiko"
 * brl4n likes "easy " anything
<jam> easy_install should bring in dependencies
 * awilkins has clearly been doing this the hard way
<awilkins> Do you just run the script at http://peak.telecommunity.com/dist/ez_setup.py
<jam> alternatively, you can do setuptools directly:
<jam> http://pypi.python.org/pypi/setuptools#windows
<jam> I just found the peak site to be *very* slot
<jam> slow
<jam> awilkins: generally
<jam> And that gives you an "easy_install" program
<jam> and then you can use that to install anything in the python cheese shop
<jam> I believe bzr is even in there
<jam> though we don't always play nicely wrt plugins
<jam> because cheeseshop doesn't like installing into bzrlib/plugins
<awilkins> I just roll my own python-installer
<awilkins> But I accept that this is beyond the typical call of duty
<jam> awilkins: well, easy_install does the download and then runs 'setup.py install' (effectively)
<jam> But it does manage dependencies
<jam> and some other bits
<fullermd> jam: What's the current hand-wavy 1.6 time?
<jam> It *does* mean that you need a compiler
<awilkins> jam: Yes, that's the nasty bit
<jam> fullermd: I was considering today, but I'm thinking Monday
<awilkins> jam: As you've probably discovered
<awilkins> jam: You're using MinGW, yes?
<jam> awilkins: well, mingw32 works pretty wel
<jam> I have a VS7 install disks somewhere from when I was at Uni
<jam> It is a shame you can't find the free download anymore
 * awilkins is using MSVC because mingw just doesn't work well when you're linking to stuff that was also built with it
<awilkins> I have a link for the free download somewhere
<jam> awilkins: "wasn't" ?
<awilkins> Was also built with MSVC
<awilkins> Sorry, unclear
<brl4n> well, i dunno what to do
<brl4n> don't feel like learning python
<jam> brl4n: My recommendation would be to get plink + pageant, and to use the standalone win32 install
<jam> which should include paramiko
<jam> which can talk to pageant
<jam> and pageant can manage your ssh keys
<brl4n> yah I already tried that and kept gett'n that EOF error
<awilkins> Wait until you need a bzr feature... then you feel like learning python :)
<brl4n> too many dependencies
<luks> if you were getting errors with the standalone installer then it's probably a bug and should be reported/fixed
<brl4n> well it is just re: ssh/sftp
<brl4n> everything else is working great
<awilkins> jam: http://xona.com/2004/06/29.html
<jam> awilkins: sure, as long as you trust 'xona' :)
<jam> I mean, they have "spyware free" in their title
<jam> no reason not to :)
<awilkins> jam: Heh, yes. I have a download of it from another source, I could compare the two
<jam> more seriously, thanks
<awilkins> Can't find the "other source" though
<brl4n> thanks for your help guys. I'll try back in a few months.
<brl4n> cheers
<hendrixski_work> awilkins: so you're saying git switches directories under the hood to do that?  and.. now I gotta google what rebase is :-p
<awilkins> hendrixski_work: You don't need to know what rebase is ; git has a "every dir is a repo and can hold branches" philospohy
<awilkins> What he's doing is switching between those branches
<awilkins> Then he rebases (gogole git-rebase or bazaar rebase)
<awilkins> Bazaar can do the same, but it's a couple more steps to set up.
<hendrixski_work> awilkins: ah, yeah there's a plugin for it
<awilkins> Bazaar can switch branches. One thing that struck me about that video is how _quiet_ git is
<awilkins> It doesn't tell you very much ; bazaar tells you what's going on when you switch, 'tis a lot more comforting IMHO
<hendrixski_work> awilkins: yeah, I've never used git myself, so seeing that video was like "wow, that's pretty quick and clean"
<hendrixski_work> kind of like the old UNIX philosophy of "silence is golden"
<hendrixski_work> ya know, not giving output unless there's something wrong
<awilkins> Yes, that's nice too
<pickscrape> That's funny. I seem to remember git being criticised for being overly verbose.
<hendrixski_work> lol, I just never tried it because I heard it was too hard for mere mortals to use, just those hard-core kernel developers
<hendrixski_work> but that video didn't seem that way at all
<hendrixski_work> I'll have to watch it again and look for rebase related stuff, maybe try it in bzr over the weekend
<pickscrape> I found that it got pretty complex as soon as you wanted to dig even slightly deeper than the most basic of operations.
<pickscrape> I certainly didn't want to inflict it on my team...
<awilkins> The guy in the video uses rebase, but it's not really necessary
<awilkins> He could have just merged
<pickscrape> I'd have been lynched.
<awilkins> The core of his point was "switch is great" ; rebase is more like him picking his nose while he does it
<awilkins> jam: Comparing those MSVC installers they look mostly the same (alas, my other one is the 1.00 version the new one is 1.01)
<luks> pickscrape: btw, I've just fixed the qlog problem you were having
<pickscrape> luks: I just got the email notification, well spotted :)
<pickscrape> I tried digging into it but I've never used QT before so I was a little lost :)
<hendrixski_work> sooo... what is the technical term for doing that, where it appears to be like several branches in just one directory... "switch"? "rebase"?
<pickscrape> I didn't see anything obvious in the BT changelog to explain it.
<pickscrape> QT *
<luks> I'm really surpsised they broke the API on a minor release
<luks> but at least it's in the changelog
<pickscrape> Can qbzr work around it, so is that version of pyqt basically broken for qlog?
<pickscrape> One of my problems with git was, ok so you have a directory that contains branches. But that directory is itself a branch of the upstream repository. So you have a branch of branches.
<awilkins> Grr, people need to mark their setup packages as needing UAC on Vista
<pickscrape> And that contains tracking branches for upstream and local branches too.
<luks> pickscrape: it's already fixed
<pickscrape> So you have some sort of multi-dimensional branch thing going on and it just made my head hurt.
<pickscrape> luks: oh cool!
 * pickscrape updates
<hendrixski_work> pickscrape: right, it sounds terribly confusing
<pickscrape> luks: I misread your first message and didn't read the 'fixed' part :)
<awilkins> Holy hell, QT is large
<luks> awilkins: it does lots of things! :)
<awilkins> All this talk of QBzr
<awilkins> Yeah, but GTK is small
<luks> GTK is only a GUI library
<awilkins> I only want a GUI :-P
<awilkins> I'm a philistine, I'm still on QT 3 on my MythTV box
<pickscrape> qbzr has leapfrogged bzr-gtk for me just recently because of the folding in qlog.
<awilkins> I'm going to try it out
<awilkins> I just hav eot wait 9 more minutes to do so because QT is 149 MB
<luks> how are you installing it?
<awilkins> Windows installer
<luks> install PyQt, not Qt
<pickscrape> luks: your fix works perfectly for me :)
<luks> the PyQt installer contains everything
<awilkins> luks: Oh.
<luks> and it's much smaller
<luks> at least used to b e :)
<luks> or just get the qbzr installer
<awilkins> luks: The error message says "PyQT 4.1 and QT 4.2"
<luks> if you don't want to hack on qbzr, it should work fine
<awilkins> So I got the impression I needed QT
<luks> do you _have_ PyQt installed?
<luks> oh
<awilkins> Not yet
<luks> yeah, there was a version mismatch between PyQt and Qt, so we needed different versions
 * awilkins downloads pyqt 4.4
<luks> but I agree it's a bit confusing
<pickscrape> I can close all of those pyqt tabs I had open in firefox now :)
<awilkins> Whee, huge numbers of errors
<awilkins> Is this the bug?
<luks> IndexErrors in qlog? :)
<awilkins> Yup
 * awilkins pulls qbzr
<luks> that is what started this conversation :)
<luks> it's an API break in PyQt
<awilkins> Aha, shint
<awilkins> Shiny
<pickscrape> luks: on my other machine I have a different problem with qlog :)
<pickscrape> luks: It's impossible to get the columns to size nicely
<luks> pickscrape: resize them from the other side
<luks> pickscrape: the message column is not resizable, and always expands, so you need to resize the other columns from the right side
<pickscrape> Yeah, I try that and it goes on a crazy dance, never settling on anything suitable
<pickscrape> e.g. right now date is about as wide as half of the screen
<luks> weird, if you just drag the separator between Date and Author it doesn't work?
<pickscrape> If I try to shrink it (from the right side), the columns just start jumping around frantically, and letting go just leaves things pretty much as they were
<luks> hmm
<awilkins> Is there a place where it stores it?
<awilkins> (the column sizing)
<luks> qbzr.conf in bzr config directory
<awilkins> Trash it and try again?
<luks> pickscrape: what Qt style are you using?
<pickscrape> Hmm, I'm running gnome, so I don't think I ever picked one
<luks> should be cleanlooks then
<luks> so that's not the problem
<pickscrape> Is there a simple way for me to check that?
<luks> well, does it look almost like the standard gnome theme?
<pickscrape> Yeah, pretty much
<luks> no idea what's the problem
<luks> but if you delete the qbzr config file, at least it will reset to default sizes
<pickscrape> After deleting qbzr.conf, message is now allowed to be larger, but it still seems to insist on making Date huge :)
<awilkins> DAng, qlog _is_ nice
<sohail> hey guys, I'm trying to branch a svn repo into my bazaar project
<sohail> I tried bzr svn-import https://..../
<sohail> but that died with: "No repository found. Try bzr branch"
<sohail> so I tried bzr branch, and it's not doing anything (just hanging)
<sohail> oh, there it goes!
<sohail> wow that took a while
<pickscrape> sohail: as I understand it the first time to a repository takes a while as it builds up an index or something like that
<pickscrape> (svn repository that is)
<sohail> pickscrape, maybe!
<sohail> so the repository I'm trying to mirror has like 10000 revisions... I tried to do branch -r 9000 and it claims that this revision does not exist..
<Peng_> sohail: There may not be 9000 revisions in that individual branch.
<sohail> oh, so I need to do it based on revisions to that branch but not on the whole repo?
<sohail> i.e., I can't use the svn revision number?
<Peng_> sohail: Right.
<pickscrape> Use a revision number that exists in that branch
<pickscrape> Hmm, no. I'm cornfused :) Isn't there an svn revspec?
<pickscrape> (or whatever it's called)
<Peng_> pickscrape: I dunno. Maybe.
<Peng_> FWIW, "bzr log" will show the svn revnos too, but I don't know if you can use them anywhere.
<pickscrape> You might be able to do something like -r svn:<revno>
<Peng_> Oh, there is an svn: revspec!
<sohail> ah!
<Peng_> pickscrape: Yep
<sohail> sounds like what I need
<Peng_> I totally didn't know that. I'll remember it for the future.
 * sohail crosses fingers
<sohail> so just to clarify, I have an existing bzr repo that depends on this external svn project. I can do cd /my/repo && bzr branch -r svn:FOO <svn-url> project
<Peng_> Sure, why not?
<Peng_> But bzr doesn't support anything like svn:external (yet).
<Peng_> I mean, you can put a branch inside of another one if you want to, but they won't be linked in any way.
<Peng_> And other people who branch from the outer branch won't get a copy of the inner one.
<sohail> oh, damn
<sohail> that's what I want to happen
<sohail> so I guess I have to bzr add that new guy then
<sohail> kind of lame
<Peng_> Sorry
<sohail> np, thanks for your help!
<Peng_> There is work on adding that feature (and there has been for years), but it's not done yet. I dunno how far along it is.
<sohail> I might as well do svn co and add that then
 * Peng_ leaves
#bzr 2008-08-23
<j0hn5> I'm having trouble using bazaar, I used the command bzr branch foo ... to get the source code... I made the changes... and hit bzr push foo... and it tells me that there are no revisions to push :\ can anyone help me?
<lifeless> j0hn5: well, you haven't committed ;)
<j0hn5> can I freely create files on the source I downloaded? just have to make commit?
<j0hn5> and then push?
<lifeless> j0hn5: yes; you probably should read the tutorial
<j0hn5> I have the tutorial here... but still don't get it
<j0hn5> I just made the bzr commit
<j0hn5> and it tells me that  there are no changes to commit
<j0hn5> yet, I created a new folder with a file in it
<Necoro> j0hn5: have you "bzr add"ed the file/folder?
<j0hn5> do I have to do that to both the folder and file? or just the folder? (since the file is in it
<Necoro> j0hn5: bzr add is recursive by default
<lifeless> when you run 'bzr add' it will scan for new files and folders
<j0hn5> ah finally... that was it... I was missing the add
<j0hn5> thanks lifeless and Necoro
<markh> jelmer: ?
<jelmer> markh, hi
<markh> hi jelmer: just to be clear - we are talking about proposing a new function to bzrlib's win32utils?
<markh> or is there one in bzr-svn?
<jelmer> markh: yeah, the one in bzr
<jelmer> markh, I'm trying to keep bzr-svn as platform-independent as possible, relying on the portability layers in both bzr and svn
<markh> ok cool, thanks.  Just a little confused whenyou said "you would apply it"
<jelmer> bzr-svn would probably have to call that new function though
<markh> s/you/i/ in those quotes :)
<markh> yes, that is what I meant in the first place
<jelmer> I'm happy to apply a patch that changes the current bzr-svn code to use that new win32utils function
<markh> but it means bzr-svn will not see it until 0.7
<markh> 1.7 either ;)
<jelmer> :-)
<jelmer> yeah, I don't think it's a problem to delay this until the next release of bzr-svn
<markh> me either - just making sure.  I'll see how I go and submit a MERGE to bzr I guess...
<markh> then you can deal with it once it looks like landing
<markh> "deal with it" == "modify bzr-svn to use it"
<jelmer> k
<markh> can bzr's laxy-import mechanism handle ImportErrors?
<lifeless> markh: it exposes ImportError if thats what you mean
<markh> lifeless: at what point is it raised?
 * markh probably could just experiment...
<Peng_> markh: From experimentation I did a while ago, when it actually loads the module (meaning, when you first access it.)
<markh> Peng_: that would make it hard to catch reliably I guess...
<Peng_> Yeah. I guess you can't lazy_import things you plan to catch ImportErrors for.
<markh> that's the conclusion I came to too :)
<olejorgenb> hm.. can I revert a revert ?
<olejorgenb> I missunderstood the documentation and thought that only the bzr add would be removed, not the actual files
<olejorgenb> hehe, ups, the files are there, sorry
<ToyKeeper> Hmm,,  can never remember how different systems handle this...
<ToyKeeper> Any idea how to insert bzr metadata into a versioned file?
<ToyKeeper> Like...  putting revno into a program's version variable.
<LarstiQ> ToyKeeper: bzr version-info
<ToyKeeper> Thanks.  I just found...  http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#exporting-version-information
<ToyKeeper> (trying to help a svn user learn bzr, and that's a feature I hadn't needed before)
<ToyKeeper> It's really not the same thing, but I guess in some cases it works.
<LarstiQ> ToyKeeper: what is not the same thing?
<luks> because it doesn't update on update
<ToyKeeper> IIRC, svn substituted certain strings at checkout/update time, without actually recording changes to the file.
<LarstiQ> ah, that.
<ToyKeeper> It could be done with hooks, but I don't see any hooks which look like they'd run at the right time.
<ToyKeeper> Maybe post_change_branch_tip
<LarstiQ> ToyKeeper: http://bazaar-vcs.org/KeywordExpansion
<LarstiQ> I'm really not a fan of it, but there you go.
<ToyKeeper> Not a big deal for me, but that should satisfy some svn users.  :)
<LarstiQ> ToyKeeper: but do ask them to test that KeywordExpansion plugin, it is basically intended for people who want that, so they need to be happy with it, not me :)
<ToyKeeper> Hmm, seems to require bzr.dev.  That might be hard to sell.  :)
<ToyKeeper> At least it's really, really easy to run bzr.dev.  I don't bother with .deb versions of bzr+plugins any more.  :)
<Peng_> It'd probably work in the 1.6 RCs.
<Peng_> Or not. I dunno.
<fullermd> Well, I think it was for bzr.dev before 1.6 was branched, so I'd guess it'll work with 1.6.
<LarstiQ> ToyKeeper: right, so this is not from a standpoint of what I'd suggest they do right now in production, but as an investment in ensuring the proposed solution satisfies their needs.
<LarstiQ> ToyKeeper: me, I'll stick with version-info anyway since I dislike the keyword approach, but hey :)
 * fullermd wuvs keywords.
<em1> hi, when i execute a python script, it complains 'ImportError: No module named bzrlib.builtins'
<em1> im a newbie, please help
<ToyKeeper> em1: Some context might help.  Which script are you running?
<RAOF> Man, that's some high quality error message: "bzr: ERROR: Generic bzr smart protocol error: <Fault 8002: 'error'>"
<ToyKeeper> RAOF: Nice.  :)
<RAOF> I wonder if it's reproducible, with -Dhpss.
<RAOF> Hm.  Apparently it actually worked, too.  Except it left a stale lock.
<em1> hi, ToyKeeper,
<em1> i am running lp:/openerp bzr_set.py
<em1> does it means that i need install a module for python i installed it the first time
<em1> i install bazaar then install python, when i try to run bzr_st.py and engine complain 'no module...', i uninstall bazaar and restall bazaar, but dont help
<em1> bazaar, hello
<em1> when i run you, i have trouble
<bazaar> hi. should i run "bzr serve" in inetd or via init script? are there any resources on bzr serve init scripts?
<bazaar> believe me -- a lot of people say that if they run me they have trouble ;)
<bazaar> no serious .. we all here at freenode#bzr love bazaar - do we?
<em1> yes, i love you, but you often puzzled me
<ToyKeeper> em1: What OS/distro are you running?
<bazaar> ``should i run "bzr serve" in inetd or via init script? are there any resources on bzr serve init scripts?'' -- any ideas?
<ToyKeeper> It sounds like bzr isn't installed correctly.
<em1> ToyKeeper, i am on windows xp
<em1> http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/2007-May/000031.html
<em1> above link is similar to my case
<em1> but no windowxp solution there
<ToyKeeper> I have no idea how to correctly set up python or bzr on XP, but it sounds like bzr isn't completely installed.
<em1> how about reinstalling bzr
<em1> i use bzr1.6rc3
<ToyKeeper> Apparently bzr isn't in your python path.
<em1> maybe i should use bzr1.6rc5?
<ToyKeeper> It should work if you run: python -c "import bzrlib"
<em1> running it have the same error
<ToyKeeper> As a kludge, you could probably add a "sys.path.insert(0, 'c:/path/to/bzr')" in a script to work around the issue, but it'll be better to get bzr installed correctly.
<em1> i have cygwin installed, is that cause?
<ToyKeeper> Using bzr 1.5 might help.  Or not, but it's worth a try.
<em1> ok, i will try it
<ToyKeeper> And if you haven't read this, it could help: http://bazaar-vcs.org/WindowsDownloads
<em1> C:\Program Files\Bazaar;
<em1> if is the blank in path result in
<em1> i will intall bzr to other place next time
<em1>  which is easier between stand-alone and python-based installer on window?
<em1> got to go, bye all
<hsn_> God, bzr reconcile is s.l.o.w. it runs 4 hours now at 0.5GB repo and still not done
<jelmer> hsn_, yeah :-(
<hsn_> its knit, not pack repo but still
<beuno> it runs billion of times faster on packs  :)
<hsn_> how can i upgrade shared repo from knit to pack? bzr upgrade doesnt seems to do anything
<hsn_> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at t
<beuno> hsn_, you upgrade the the repo
<beuno> and the branches
<beuno> so,  /code/shared_repo  <--  bzr upgrade
<beuno> and, /code/shared_repo/branch  <-- bzr upgrade
<jelmer> Odd_Bloke, hi
<php6th> hi
<jelmer> hi
 * beuno -> airport
<eikke> has bzr got in-repository branches like, git-style, nowadays?
<pygi> well, you can initialize branches inside a repository :)
<pygi> but it's not really ala-git style
<eikke> i dont really care about the internals :)
<eikke> I'd need something pretty much like git branching, but this is a pure python project so a native environment mihgt be cool
<jelmer> eikke: the code is there in bzr-loom I think, there's just not much UI for it yet
<eikke> ok, I'll check that out
<eikke> still in research phase luckily
<jelmer> eikke, you may want to ask on the list - the people with the most knowledge about that don't appear to be around atm
<eikke> all right
<asabil> eikke: you may also want to check this: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reusing-a-checkout
<asabil> actually it all depends on what you need "internal" branches for
<epsy> hi, i'm trying to install the bzr-svn plugin, i've put it in ~/.bazaar/plugins/svn/ and ran make, thus it doesnt show up in bzr plugins, but instead shows this warning:
<epsy> Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins'
<jelmer> epsy: any information in ~/.bzr.log ?
#bzr 2008-08-24
<mwhudson> epsy: try bzr -Derror rocks
<epsy> same thing
<epsy> $ bzr -Derror rocks
<epsy> Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins'
<epsy> It sure does!
<mwhudson> hm
<epsy> jelmer, i'm at it, second
<mwhudson> epsy: which version of bzr?
<epsy> 1.5
<mwhudson> ... and which version of bzr-svn, i guess?
<epsy> 0.140  looking for plugins in /home/epsy/.bazaar/plugins
<epsy> 0.162  bzr-svn: using Subversion 1.4.6 ()
<epsy> [ 9154] 2008-08-24 01:00:02.301 WARNING: Unable to load plugin 'svn' from '/home/epsy/.bazaar/plugins'
<epsy> 0.165  Traceback (most recent call last):
<epsy>   File "/usr/lib/python2.5/site-packages/bzrlib/plugin.py", line 208, in load_from_dir
<epsy>     exec "import bzrlib.plugins.%s" % name in {}
<epsy>   File "<string>", line 1, in <module>
<epsy>   File "/home/epsy/.bazaar/plugins/bzr_svn/__init__.py", line 158, in <module>
<epsy> AttributeError: 'module' object has no attribute 'properties_handler_registry'
<epsy> er
<epsy> sorry that was a bit much
<jelmer> epsy: your version of bzr is too old for your version of bzr-svn
<epsy> mwhudson, just checked it out
<epsy> ah, right
<epsy> i'll upgrade
<epsy> for that i would need bzr 1.6 right?
<mwhudson> yep
<epsy> alright
 * meteoroid is excited to be the rhel5 x86_64 buildbot host for drizzle (the new mysql) using bzr :)
<markh> when a test fails we see its trace output - how can I see the same output when the test passes?
<james_w> hi markh, I don't know of a way to do it for tests
<markh> hrmph - oh well, hackery must be done then!
<james_w> markh: actually, there is support for it
<james_w> markh: I just don't think it's in the UI
<markh> yeah - I think we just need to arrange for trace.set_verbosity_level() to be called
<markh> or possibly be_quiet()
<markh> it would be handy, eg, when you are working on a feature branch where a test fails - it would be very handy to see that same output on a branch where it works
<james_w> so, there's soem way of stopping it from deleting the log file
<james_w> but I don't know if that's useful, or how to enable it
<markh> I guess it might be...
<james_w> test._log_contents = ''
<james_w> that makes it look like some hackery will be required
<james_w> (in addSuccess)
 * AfC is sad that bzr-svn is still segfaulting for him.
<Odd_Bloke> AfC: Does jelmer know about it?
<lifeless> AfC: 64-bit ?
<jelmer> wtf, are all the Europeans living in .au tz these days?
<AfC> lifeless: no
 * Odd_Bloke starts a job on Tuesday, has to make the most of his last days of freedom. :p
<AfC> Odd_Bloke: yes. I got him a gdb backtrace the other day
<AfC> (although now that I see a fellow named jelmer in this channel, the least I can do is offer to run some other tests or diagnostics if it would help him)
<jelmer> AfC, I didn't see anything obviously wrong and can't reproduce it here
<jelmer> AfC, what platform/architecture are you on?
<AfC> Linux, x86
<lifeless> gentoo :)
<AfC> Subversion 1.5.1
<AfC> Bazaar 1.6-rc5
<AfC> bzr-svn from current 0.4 branch tip
<jelmer> Hmm, that's pretty similar to what I have here except that I'm on sid rather than gentoo
<jelmer> Odd_Bloke, ah, all freedom and no sleep ? :-)
<Odd_Bloke> Something very much like that. :D
<Verterok> AfC: I can try to reproduce it (I have a x86 box with Gentoo)
<Verterok> AfC: steps to reproduce?
<AfC> Verterok: Unfortunately it seems like a fairly fundamental flaw (which is why I doubt bzr-svn is to blame)
<AfC> Verterok: I upgraded from bzr 1.5 & bzr-svn 0.4.10
<AfC> Verterok: to bzr 1.6-rc5 and bzr-svn from the 0.4 branch
<AfC> Verterok: meanwhile, Subversion upgraded to 1.5.1
<AfC> (care of Portage)
<AfC> anyway, somewhere in there bzr-svn stopped working. Both `bzr pull` on an existing bzr-svn branch and `bzr branch` attempting to create a new one crash
<AfC> with a segmentation fault.
<AfC> (joy)
<jelmer> AfC, does the testsuite for bzr-svn pass?
<AfC> jelmer: not sure. I've never tried to run the Bazaar test suite before.
<jelmer> AfC, should be a matter of running "make check" in the bzr-svn dir
<Verterok> AfC: ok. I'll emerge subversion 1.5.1, try to branch a svn repo and come back with the results (in a while, I'm in the middle of a emerge -u world :P)
<AfC> jelmer: ah, indeed? Well then, I shall do that presently.
<AfC> jelmer: `make check` segfaults right quickly
 * AfC curses again
<AfC> (as I am certain that I have done something wrong, though of course haven't the faintest idea what)
<jelmer> AfC, can you perhaps paste the output of "make valgrind-check" ?
<AfC> jelmer: gonna have to grab Valgrind first. Wait, out.
<Odd_Bloke> Has anyone looked at packaging PQM?
<Odd_Bloke> jelmer: ^
<jelmer> Odd_Bloke, yep
<jelmer> Odd_Bloke, let me find the URL
<AfC> jelmer: FATAL: can't open suppressions file '/usr/lib/valgrind/python.supp'
<AfC> Is that something I can do something about?
<jelmer> AfC, you may have to tweak the Makefile to point at the right suppressions file
<Odd_Bloke> jelmer: https://code.edge.launchpad.net/~jelmer/pqm/debian ?
<jelmer> Odd_Bloke, http://bzr.debian.org/pkg-bazaar/pqm/unstable
<jelmer> Odd_Bloke, yeah, that's the lp mirror
<jelmer> weird coincidence, I actually put that up today
<AfC> jelmer: any idea where I can get one?
<jelmer> AfC, without the python suppressions, there'll be a lot of noise from valgrind
<jelmer> AfC, http://samba.org/~jelmer/tmp/python.supp
<AfC> jelmer: (understood). Thanks.
<jelmer> AfC, It's shipped with Debian, not sure where they get it from though
<AfC> k
<AfC> jelmer: http://rafb.net/p/NmyJzz74.html
<jelmer> AfC, please try again with r1627
<jelmer> AfC, I've added some extra error checks that may help determine what's going wrong
<AfC> Um
<jelmer> Odd_Bloke, it uses my distutils code though, and that's not upstream et
<AfC> jelmer: sorry to be slow, but what Branch URL should I be using? http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ says its at 1613
<jelmer> AfC, yeah, that's the one
<jelmer> I'm pushing, it's just slow..
<AfC> Huh
<AfC> ah
<AfC> nevermind
<jelmer> pushing over bzr+ssh is slower than over svn+ssh these days...
<AfC> That's exciting
<Odd_Bloke> jelmer: CDBS. D:
<Odd_Bloke> jelmer: The distutils install-html target seems to be broken.
<Odd_Bloke> It's trying to install into /usr rather than the build-area.
<AfC> jelmer: take 2: http://rafb.net/p/zK9p2492.html
<jelmer> AfC, can't think of anything that may be going wrong
<AfC> Still, "Address 0x0 is not stack'd, malloc'd or (recently) free'd" is pretty funny
 * AfC heads out.
<AfC> jelmer: thanks for looking
<AfC> Without wanting to be negative, /me hopes Verterok reproduces what I am hitting.
<AfC> See ya
<jelmer> Odd_Bloke, yeah, cdbs is kinda nice when you have a package that's trivial to package
<jelmer> Odd_Bloke, when you need to customize things a bit, it gets nasty
<Odd_Bloke> jelmer: I've found debhelper 7 to be pretty good for trivial packages.
<jelmer> does that deal with setup.py ok?
<Odd_Bloke> jelmer: I think you still have to issue the setup.py line yourself.
<Odd_Bloke> But, looking at my packages, most of my Python packages either predate (my knowledge of) debhelper 7 or are inherited and haven't needed enough changing to move away from CDBS.
<Verterok> jelmer: I wasn't able to reproduce AfC's problem with bzr-svn, only 1 test failure
<Odd_Bloke> jelmer: http://svn.debian.org/viewsvn/python-modules/packages/configobj/trunk/debian/rules?rev=6338&view=markup is an example of a debhelper 7 rules file for a Python package.
<clemente> How can I see the changes that would be made if I did a pull?
<mwhudson> 'bzr missing' is a bit like that
<luks> bzr diff --new :parent maybe, not sure
<clemente> In git there's BASE (latest here) and HEAD (latest there), and you can get the log between the two
<luks> bzr missing if you want a log
<clemente> But in âbzr help revisionspecâ I don't find anything like that
<luks> and I think you have BASE and HEAD in git backwards
<luks> er, backwards is not the right word
<luks> but BASE is probably 'latest there', and HEAD 'latest here'
<clemente> Ah, ok, I actually wanted to put the example of Subversion, not git. This works in Subversion: svn log -r BASE:HEAD
<luks> well, in that case you want bzr missing
<clemente> Is it necessary to specify the branch URL in âbzr missingâ? Can't it use the URL which was used for checkout, or for pulling?
<clemente> (I mean automatically)
<luks> it does, doesn't it?
<clemente> Well, I am inside a branch inside a repository, and it tries to use the repository as branch; then it fails
<luks> what does `bzr info` says?
<luks> the parent branch: line
<clemente> It refers to the repository. That's bad
<luks> perhaps you ran 'bzr pull --remember' with the wrong URL?
<luks> it defaults to the location you branched from
<clemente> No, but I converted the branch to a âbranch inside a repositoryâ, and the repository happens to have the same URI as the former branch
<luks> ah, that would be the problem
<clemente> What should I set as parent? It's the branch for lp:bzr
<luks> http://bazaar-vcs.org/bzr/bzr.dev/ probably
<clemente> So the same as the attribute âcheckout of branchâ which âbzr infoâ shows
<clemente> parent_location == bound_location
<clemente> Ok, now it works; a bit slow, but works
<clemente> Luckily âbzr missingâ is a lot easier than in Subversion or git
<clemente> I have seen the log. What if I want to see a particular diff?
<clemente>  bzr diff -r 3647:lp:bzr  ?
<luks> I'd use `bzr diff --new :parent`
<clemente> That shows nothing
<clemente> I want just from âthe revision before 3647â to revision 3647, both in the remote branch
<clemente> -r 3647:lp:bzr seems to select more than 1 revision: not only 3647 but also the ones before
<clemente> I don't understand the grammar for specifying revision ranges. If a range is REV..REV, and REV can be something like branch:/a (according to âbzr help revisionspecâ), then a range could be for instance branch:/a..branch:/a
<clemente> Obviously there's something wrong
<lifeless> clemente: thats a valid range, yes
<clemente> But it's ambiguous
<lifeless> how so ?
<clemente> You don't always know if .. will be a separator or not
<lifeless> thats true, but its possible to look and see :)
<lifeless> branch:FOO - FOO is eaten by the parser and returns the unused portion
<clemente> Then at âbzr help revisionspecâ it's missing a section about revision ranges. Nowhere it says that .. is the range operator
<lifeless> ok, we should fix that
<lifeless> anyhow, are you having some problem ?
<clemente> I also don't find at that page the way to refer to âthe head of the current branchâ
<lifeless> sorry, I see some unicode glyph there
<lifeless> terminal issue
<lifeless> "the way to refer to XXXX" - I don't know what XXX is
<clemente> ok; without Unicode :-( :   to refer to: the head of the current branch
<mwhudson> '-1' usually does that job, if i understand what you're saying
<clemente> And then you don't have to specify that you are talking about the local branch?
<lifeless> right
<lifeless> bzr diff -r -1
<lifeless> ==
<lifeless> show me changes in the working tree against the branches tip
<clemente> That could be also explained in the example in   bzr help revisionspec
<lifeless> I agree
<clemente> I'd like to fix bugs or improve documentation, but I still don't know how to do it in Bazaar
<lifeless> do you ahve a branch of bzr ?
<clemente> yes
<clemente> I don't have much expertise with English; I don't know if I should write much documentation
<lifeless> revision spec help is in bzrlib/revisionspec.py
<lifeless> our review pocess will catch english issues
<clemente> So I'm allowed to check in the changes even if they're not perfect? To which branch?
<lifeless> your own
<clemente> Yes. And how can then other developers access my branch? (ssh, http, ...)
<clemente> Probably I have to push the branches to Launchpad
<lifeless> you can push it to launchpad, or just send in a bundle via email
<lifeless> the HACKING document explains the contribution process
<clemente> Ok, that's good (and long!), I read it
<twb> I'm tracking a project's trunk, but never actually working on the codebase myself.  Is this (still) the best way to get a minimal (fast / small) copy of trunk?
<twb> bzr checkout --lightweight lp:nxhtml nxhtml
<lifeless> twb: fast != small :) - less data locally means more remote access
<lifeless> twb: bzr branch --stacked is likely more efficient than checkout --lightweight
<twb> lifeless: all I will ever do to this copy is get the initial copy, then pull in updates
<twb> Really all I care about is the working tree, and the ability to update it.
<lifeless> twb: I appreciate that, nevertheless
<AnMaster> $ bzr pull --remember http://rage.kuonet.org/~anmaster/bzr/cfunge
<AnMaster> http://rage.kuonet.org/%7Eanmaster/bzr/cfunge is permanently redirected to http://rage.kuonet.org/~anmaster/bzr/cfunge/
<AnMaster> that seems odd
<AnMaster> anyone can explain it?
<twb> %7E is an escaped version of ~
<twb> If you use curl -sLI, you get
<twb> HTTP/1.1 301 Moved Permanently
<twb> Location: http://rage.kuonet.org/~anmaster/bzr/cfunge/
<AnMaster> true
<AnMaster> but I gave ~ on command line
<twb> So what's happening is that the HTTP server is redirecting to include a /
<AnMaster> ah
<AnMaster> right
<twb> And something (bzr) is escaping the ~ just because it can
<twb> Probably it's passing through some sort of normal form-izing printer
<twb> (I'm just speculating; I don't normally even use bzr.)
<twb> So in summary, if you use the trailing slash in your original pull, the notice should disappear
<AnMaster> wait this is #bzr right?
<lifeless> [
<lifeless> AnMaster: yes it is
<lifeless> AnMaster: the ~ is because bzr only emits accurate urls, to aid debugging in the event of unusal servers (there are many such :()
<AnMaster> hm
<AnMaster> ok
<lifeless> AnMaster: but we accept things like ~ and normalise them for ease of use
<twb> I dunno that using ~ isn't "accurate".
<twb> Merely not non-normalized
<AnMaster> heh
<lifeless> twb: read std66, urls are not defined to be in any encoding
<lifeless> twb: it could be in EBCIDIC
<lifeless> the recommended encoding is utf8, but servers don't have to follow that
<epsy> hi
<epsy> right, i've finally upgraded to 1.6rc5, but i'm still getting problems merging from an svn checkout into a bzr branch:
<epsy> bzr: ERROR: KnitPackRepository('file:///home/epsy/CODE/armagetron/http-auth-server-bzr/.bzr/repository/')
<epsy> is not compatible with
<epsy> SvnRepository('https://armagetronad.svn.sourceforge.net/svnroot/armagetronad')
<epsy> different rich-root support
<clemente> lifeless: by the way, thanks; I just posted my first patch to the mailing list.
<clemente> epsy: I don't know much about it, but maybe it's because of the format used. I think "bzr upgrade" can solve this
<clemente> But first make a backup of your .bzr/ ...
<epsy> clemente, in the svn checkout? Oo
<epsy> well, the bzr branch is completely new
<epsy> as in, in just typed bzr init
<clemente> I don't know... I only knew that because I read it here: https://bugs.launchpad.net/bzr/+bug/206258
<ubottu> Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Medium,Fix committed]
<epsy> heh
<LarstiQ> epsy: the bzr branch needs to have rich root support
<LarstiQ> epsy: what does `bzr info` say on the bzr branch?
<clemente> So this can work: bzr upgrade --rich-root-pack
<epsy> how do i turn that on?
<epsy> ok
<clemente> However, apparently bug 206250 was fixed and therefore you should have seen the message with the solution. If you didn't see it, maybe you complain on that bug report :-)
<ubottu> Launchpad bug 206250 in ubuntu "fonts visible in open office editer, but printed as square blocks" [Undecided,New] https://launchpad.net/bugs/206250
<clemente> Oops, I meant 206258
<epsy> is it fixed in rc5 ?
<epsy> it says fix committed and not fix released
<clemente> Ah, ok.
<clemente> I think this is important and undangerous for the release...
<epsy> how do i show "sub-revisions" with bzr log ?
<LarstiQ> epsy: just bzr log. Or --long to be sure it isn't overriden.
<epsy> it only shows with bzr log --line
<epsy> wait
<epsy> negative revision numbers ew..
<LarstiQ> hmm?
<epsy> $ bzr log --line
<epsy> 1: epsy46 2008-08-24 Imported from svn
<epsy> 0: epsy 2008-08-15 redirects back
<epsy> -1: epsy 2008-08-15 moar typos
<epsy> -2: epsy 2008-08-15 fixed bugs typos and turtles
<epsy> -3: epsy 2008-08-15 typo
<epsy> -4: epsy 2008-08-15 some old stuff i forgot to commit
<epsy> [and it goes on]
<epsy> (yes, with even more typos :P)
<LarstiQ> epsy: why do you supply --line? And displaying negative revnos certainly isn't default behaviour. Do you have any plugins installed that modify log behaviour, or an alias?
<epsy> LarstiQ, i was merging from a bzr checkout
<epsy> er
<epsy> an svn checkout*
<epsy> using the svn plugin
<LarstiQ> epsy: so where are you running log on?
<epsy> the bzr branch
<epsy> after merging stuff from the svn one
<LarstiQ> did you commit after the merge?
<epsy> yes, as i thought it didn't commit anything, as nothing showed up on bzr log without arguments
<epsy> 1: epsy46 2008-08-24 Imported from svn
<LarstiQ> ok, you certainly aren't using just default bzr )
<epsy> ill file a bug to the bzr-svn guys :)
<LarstiQ> epsy: bzr-svn also doesn't do that
<LarstiQ> epsy: try 'bzr log --long'?
<epsy> too late, i started over
<epsy> second
<LarstiQ> epsy: and check `bzr plugins` for any obvious culprits. If that fails, peek at ~/.bazaar/bazaar.conf for aliases
<jelmer> epsy, what's going wrong with bzr-svn?
<epsy> jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr log --line
<jelmer> epsy, what's it not doing right?
<epsy> assigning revision numbers, i guess, they show up as negatives
<epsy> the last revision being 0
<epsy> wait, you need to commit something before it show up
<epsy> yeah
<epsy> jelmer, bzr init --rich-root-pack && bzr merge [some svn checkout] && bzr ci -m "test123" && bzr log --line
<jelmer> epsy, does "bzr log" (without --line) print antyhing sensible?
<epsy> nope, it seems that it stops at 1 anyway
<epsy> while --line continues as long as there are available revisions
<jelmer> epsy, but shows the bzr-svn revisions below revision 1?
<epsy> it only shows revision 1
<epsy> er
<jelmer> epsy, can you put the bzr repo with this bug up somewhere?
<epsy> now it calls it revision 34
<epsy> well, i could reproduce it over and over
<jelmer> I can't, that's why it would be useful to be able to analyse this branch :-)
<epsy> in bzr log --line revision with commit message shows up as #1, with the older revisions from svn as 0 and negatives, while in normal bzr log, it shows up alone as rev #34
<epsy> revisions*
<jelmer> epsy, It's very hard to say anything about this without a look at the branch. Any chance you can upload a tarball or something somewhere?
<epsy> second
<epsy> jelmer, also, what is the expected behaviour? i don't have much experience with merging
<jelmer> epsy: "bzr log --line" should just show the revisions on mainline
<epsy> [i'm still at packing an example tarball]
<jelmer> epsy: so not the merged revisions
<epsy> jelmer, is there a way we can somehow track these?
<jelmer> epsy: The merged revisions are shown indented when you run "bzr log" (no --line)
<epsy> right
<epsy> how do i manually choose a merge base revision ?
<epsy> oh, right, that's what's before the .. in -r 1..2 :)
<jelmer> epsy, any chance of that tarball?
<epsy> jelmer, it's taking ages :(
<epsy> i would need a not-so-big bzr branch for testing
<epsy> gnah
<epsy> i mean an svn branch
<LarstiQ> epsy: is the svn branch public? Then maybe jelmer could reproduce it locally.
<LarstiQ> jelmer: or did you already try that?
<jelmer> LarstiQ, he's busy tarring up the bzr branch
<jelmer> I doubt this is related to bzr-svn, rather a bug in bzr log --line
<LarstiQ> jelmer: right.
<LarstiQ> epsy: with the bzr branch you merged the svn checkout into, did it have any revisions before you committed the merge?
<LarstiQ> epsy, jelmer: if that is so, I have a hunch it's a corner cases with the first revision assuming it doesn't have any merged revisions.
<epsy> LarstiQ, no, this seems to be characteristic
<epsy> LarstiQ, i could work around it making an empty commit first
<LarstiQ> epsy: ok, let me try to reproduce that with bare bzr.
<epsy> i think at some point i could reproduce it with plain bzr stuff, without svn stuff, but i'm not sure anymore
<LarstiQ> epsy: yup, thanks, that does it.
<epsy> right
<epsy> :)
<LarstiQ> epsy: so, that explains the negative revnos were we don't expect them. Was there anything else fishy?
<LarstiQ> epsy: do you want to file the bug, or shall I do it?
<epsy> go for it, i dont think i have much more detail than you
<epsy> LarstiQ, the different listing behavoir of normal bzr log and bzr log --line
<epsy> the commit that you do, which shows as #1 in bzr log --line, shows as a higher revision number in normal bzr log
<epsy> brb, dinner
<LarstiQ> epsy: yeah, the root cause is the same, --line is correct for your committed revision, but it shouldn't show the others (and hence not count down through zero).
<LarstiQ> epsy: the --long formatting is slightly more involved, but same cause.
<jelmer> siretart, ping
<siretart> jelmer: pong
<jelmer> siretart: Did you have a chance to look at the loggerhead package?
<jelmer> siretart, You asked me to ping you about it a couple of days back :-)
<siretart> jelmer: yes :) - sorry, no, I had a family party today and was busy the whole weekend with preparations.
<siretart> jelmer: I'll look at it tomorrow. btw, have you done some commits since my last comments?
<jelmer> siretart, Yeah, I clarified the copyright file slightly
<siretart> jelmer: okay, thanks. I'll get to it tomorrow morning
<jelmer> siretart, thanks !
<Lani78> Hello, I'm trying to get the Nautilus extension for Bazaar to work. I've downloaded the source for bzr-gtk 0.95 (as I could not find it in any repository?) I have Bazaar 1.6rc5 installed and I've tried to follow the installation instructions in the README. So I've put the nautilus-bzr.py file in the ~/.nautilus/python-extensions dir.
<Lani78> Is there anything else that I need to do? I've restarted X as well.
<Lani78> I then try to browse a folder in Nautilus to see if there are any new buttons, menu options or icons, but I cannot see anything, am I looking for the right thing?
<Lani78> Anyone awake?
<cody-somerville> I am
<Lani78> ok :) Hi there, do you know anything about the nautilus extension for bazaar?
<jelmer> Lani78, do you have python-nautilus installed?
<Lani78> jelmer: I'm not sure if I've done it correctly, I've downloaded bzr-gtk 0.95
<Lani78> ï»¿I've put the nautilus-bzr.py file in the ~/.nautilus/python-extensions
<jelmer> Lani78, you need to install the nautilus support for python bindings as well
<Lani78> Ah, ok, I will try that right away!
<Lani78> Do I have to restart X then?
<jelmer> you'll have to restart nautilus
<jelmer> though restarting X will take care of that
<Lani78> ok
<Lani78> I've got some new menu entries now :)
<Lani78> Is it possible to do a checkout from within Nautilus, instead of the command line: "bzr checkout sftp://server/bzr/proj1 dev
<Lani78> "
<jelmer> I'm not sure if we added an option for that yet
<jelmer> if not, please file a wishlist bug
<epsy> is there a way i can prevent myself from committing a file, while it still being versionned?
<jelmer> epsy, bzr commit has a -x option now
<jelmer> (bzr 1.6)
<epsy> i mean, permanently
<epsy> a bit like .bzrignore
<jelmer> why would you want to version it then?
<epsy> it's a config file
<Lani78> jelmer: ok, I'm poking around a little. You should probably update the README for bzr-gtk to include the need for "python-nautilus". As it might not be obvious to everyone :)
<epsy> and i don't want my passwords and other crap being committed, do i? :)
<jelmer> epsy, I would not keep it versioned then
<jelmer> instead, just commit foo.conf.example and ignore foo.conf in .bzrignore
<epsy> good idea
<Lani78> I cannot find any menu entry for checkout
<Lani78> So if I'm looking in the right place it might not be there, but I'm just learning bzr so it might be that I just have the wrong status of my project?
<Lani78> I just did a commit now, that went ok.
<jelmer> Lani78, if you can't find it where you expect it to be, it's also a flaw :-)
<jelmer> lamont, I think it's very possible we don't have a checkout menu entry yet
<Lani78> jelmer: I agree ;)
<jelmer> Lani78, Any chance you can file a wishlist bug about it?
<Lani78> jelmer: sure, I'll do that
<Lani78> at launchpad, bzr-gtk, right?
<jelmer> Lani78, yep
<Lani78> How do I mark it as a "Wishlist"-thing?
<Lani78> I can only find "Report a bug"
<jelmer> Lani78, Once you've reported it, you can change the importance
<Lani78> Ah ok, thanks
<Lani78> jelmer: I've filed it now: https://bugs.launchpad.net/bzr-gtk/+bug/260960 but I cannot change the Importance, I guess that only a member of the bzr-gtk crew can do that? I tried to explain it as well as I can, with my very limited knowledge of Bazaar.
<ubottu> Launchpad bug 260960 in bzr-gtk "The Nautilus extension should have a "checkout" command." [Undecided,New]
<jelmer> Lani78, thanks!
<jelmer> Lani78, Ah, yeah, that may be. We'll look at fixing that
<Lani78> Np, thank you for helping me to get it to work at all :)
<Lani78> I'm a bit paranoid when it comes to storing my projects source codes. This might be a very basic question, but how can I be sure that the project has been commited to the server successfully. Can I assume that all went fine if the Nautilus extension doesn't give me an error when I commit?
<jelmer> Lani78: yeah
<jelmer> Lani78, You can look at the logs of the branch to make sure
<Lani78> jelmer: Ah ok, investigating right away ;)
<jelmer> Lani78, If there are other things you're missing, please do not hesitate to let us know
<Lani78> jelmer: There is, an menu option to see the logs? ;)
<jelmer> Yeah, I'm pretty sure there is
<Lani78> Or is the "history" the same as the logs?
<jelmer> yeah, History sounds about right
<Lani78> ok, but how can I be sure that it hasn't just been committed to my local .bzr and that it has gone all the way to my server?
<Lani78> jelmer: also, in the "commit" dialog. I would like to see there where my commit is going, so that I can see to what server and what path. Or am I missing something obvious that removes that need?
<pygi> Laney, when you commit, you commit locally
<pygi> you need to "push" to the repository
<jelmer> Lani78, No, that sounds sensible
 * Laney eyes pygi 
 * Laney points to Lani78 
<jelmer> Lani78, any chance you can file a bug about that as well ? :-)
<pygi> Lani78, what? xD
<jelmer> pygi, Not necessarily; if the branch is bound it goes to the server as well?
<pygi> Laney, ah yes, sorry :p
<pygi> jelmer, ah, right
 * pygi wasn't thinking of that now :p
<Lani78> jelmer: sure I can do that ;)
<Lani78> Another thing that I would like is to have some sort of "status screen", where you could see if it is a local repository or if it is connected to a remote repository. What other branches that exists on that repository and other useful stuff. But I only have one branch now so maybe this is obvious when you have several branches (I will soon try ;))
 * cody-somerville pokes pygi 
<pygi> cody-somerville, poke back?
<Lani78> https://bugs.launchpad.net/bzr-gtk/+bug/260967
<ubottu> Launchpad bug 260967 in bzr-gtk "Add repositrory information to the  commit dialog in the Nautilus extension" [Undecided,New]
<Lani78> I misspelled repository and I cannot find an edit button :P
<Lani78> Now I found it :)
<Lani78> I'm really curious about the release of the Launchpad source code. I saw an article about that it should be released within 12 month!
<Lani78> Another wish/question,  why don't you have ppa repository packages for Hardy Heron for bzr-gtk?
<jelmer> re
<jelmer> Lani78, Not sure, the ppa is maintained by other people
 * jelmer runs Debian :-)
<Lani78> ok
<Lani78> Do you do all this work in bzr-gtk in your spare time?
<Verterok> ls
<Verterok> AfC: ping
<mwhudson> is Transport.ensure_base fairly new?
<lifeless> Lani78: yes, bzr-gtk is a community project
<Lani78> lifeless: Ok, That's impressive
<Lani78> ï»¿How can I make sure that I'm running the correct version of Olive from bzr-gtk? The About dialog doesn't show now. I want to make sure as I'm getting an error when I try to add a new file.
<AfC> Verterok: pong
<lifeless> Lani78: I would check ~/.bzr.log
<Verterok> AfC: Hi, I can't reproduce the segfault (with bzr-svn) in my gentoo box
<AfC> Verterok: well, that's good (for you and for bzr-svn) and bad (for me)
<AfC> Verterok: thanks very much for trying
<Verterok> AfC: installed packages: apr/apr-util 1.3.2, neon  0.28.2 and subversion 1.5.1
<AfC> Verterok: same
<lifeless> could it be the server?
<Verterok> AfC: did you tried a 'revdep-rebuild -p'?
<AfC> lifeless: I don't think so - the unit tests fail
<AfC> Verterok: can't hurt, checking, but I mean, the stack is pretty tight
<Lani78> I had an old version of bzr-gtk installed from the ubuntu repositories at the same time as I manually installed the latest version in another place, I've now removed the old version and everything worked fine :)
<Verterok> AfC: also, a USEFLAGS double-check can't hurt :)
<AfC> Verterok: yeah, it all seems sane though. We'll see what revdep-rebuild has to say.
#bzr 2009-08-17
<sandsmark> I get a fun error when trying to run âbzr updateâ: UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 358465: ordinal not in range(128)
<sandsmark> backtrace and some info: http://pastebin.com/m2d85582c
<johnjosephbachir> anyone have a favorite rhel/centos rpm that's newer than the one provided by EPEL?
<sandsmark> hah, I love bzr:   Conflict adding file .bzrignore.THIS.moved.  Moved existing file to .bzrignore.THIS.moved.moved.
<sandsmark> (how on earth I get conflicts when I only have one local branch is beyond me :-P)
<lifeless> sandsmark: you can conflict with someone else without needing two local branches
<sandsmark> lifeless: there is noone else, there is only one branch, my local one
<lifeless> sandsmark: can you do 'bzr inventory | grep .bzrgnore.THIS'
<RenatoSilva> Is there a way to change commit comments?
<sandsmark> lifeless: yeah, bzr inventory returns such a file
<lifeless> RenatoSilva: uncommit the commit, and recommit it with new comments.
<lifeless> sandsmark: ok, you need to 'bzr remove' that file. bzr uses '$filename.THIS' for storing its conflicts
<sandsmark> ah
<sandsmark> ok
<lifeless> so by versioning it you've got it in a loop
<RenatoSilva> lifeless: I'm better off not doing this, it's an old revision
<lifeless> RenatoSilva: then no.
<RenatoSilva> ok thanks anyway
 * sandsmark blames etckeeper
<lifeless> sandsmark: could you file a bug? we should be more graceful/informative about that particular case.
<sandsmark> lifeless: well, 1.5 is pretty old
<lifeless> even so
<sandsmark> ok
<lifeless> if its fixed already it will be easy to close ;)
<sandsmark> heh, ok :-)
<lifeless> but while I suspect we have a bug thats similar to this already, I'm fairly sure we haven't actioned it.
<lifeless> so at worst this will be a dup and add data to the frequency people hit it.
<sandsmark> lifeless: uhm, is this really a bug, though? I would rather say the problem is with etckeeper, adding all files indiscriminately
<sandsmark> (the real question is where the conflict comes from, though)
<lifeless> bzr could help - it could say 'this is a dangerous file to add', it could, on conflicts, not conflict on that file but instead know it can overwrite it;it could adjust the conflict path it uses
<sandsmark> yeah, true
<sandsmark> well, it might give some false positives, but a simple warning might be nice
<sandsmark> https://bugs.launchpad.net/bzr/+bug/414589
<ubottu> Ubuntu bug 414589 in bzr "Bazaar doesn't notice/care if you try to version-control *.THIS, *.BASE, *.OTHER or *.moved" [Undecided,New]
<sandsmark> lifeless: something like that ok?
<lifeless> sandsmark: great
<sandsmark> k
<lifeless> I'll add a little editorial when it gets to my inbox
<sandsmark> ok, thanks :-)
<sandsmark> hmm, I'll try to backport a more recent bazaar to see if it helps with the utf8-failings
<sandsmark> ah, it is in lenny-backports
<sandsmark> ah, awesome, that worked like a charm
<sandsmark> hmm, another odd error
<sandsmark> http://pastebin.com/m32268cf3
<james_w> igc: some people find documentation more exciting than writing code ;-)
<igc> james_w: really?? Name one. :-)
<james_w> crazy people I know :-)
<james_w> but exactly the ones you want to be writing your documentation
<igc> james_w: true. Too much knowledge of the code can be a disadvantage when it comes to writing clear docs :-)
<igc> james_w: well docs for beginners at least
<mzz> see the git documentation!
 * mzz ducks
<james_w> not wanting to spend your time writing code means that you can instead focus on writing great documentation
<igc> mzz: it makes my head spin
<mzz> (it's not entirely fair towards the git folks, but the thing I remember most clearly about git is that it documentation suddenly went on and on about some kind of squid when I was trying to do some basic version control thing)
<igc> mzz: 'git log' is 30 pages! (and I wish I understood half of it)
<james_w> I'd prefer code written by people passionate about it than code written by those who were just writing it because they felt they had to
<mzz> "I don't *want* to hunt deep sea creatures right now! stop talking to me about an octopus!"
<james_w> same goes for documentation
<Colonel-Rosa> Is there a good guide to using the bzr smart server?
<Colonel-Rosa> Would I have to setup a chroot jail for users?
<spm> am getting these errors: bzrlib.errors.LockContention: Could not acquire lock "<directory>/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable <== which I infer is a roundabout way of saying directory doesn't exist? or?
<spm> This is seen via a cron task; but only 1 in 4 runs.
<lifeless> spm: is it on nfs?
<spm> lifeless: no, local. based on the full traceback tho - i suspect it may be a bzrlib issue of sorts. it's pulling in a local 1.16 copy to run with - which was a hack to get around 2a format updates back in July. Take that out and I get a full on boom. progress of sorts...
<spm> lifeless: old vs new https://pastebin.canonical.com/21210/ - i suspect the cm bzrlib needs updating; and/or rejig the path to use the system one.
<lifeless> spm: this shouldn't have suddenly gone odd
<lifeless> however, the latter error means that you've broken it by whatever gives the boom:)
<spm> truly :-)
<spm> I've just put in a fix which works in manual testing; but in the leadup to, was seeing some really weird errors. My first suspicion was pebkac and inclined to hold that; but I wonder if something else is going on
<lifeless> something changed ;)
<spm> which is where it gets very weird; because a similar script isn't erroring at all. Anyway. see if the fix in place works.
<spm> lifeless: nope. same error. something else is happening here....
<lifeless> spm: yes, I rather thought so :P
<spm> aye. ah well. At least that cleans up one possible area of problem. <== searching for any silver lining
<johnjosephbachir> let's say i have an existing bzr branch, and i want to bring in some code from another completely unrelated tree (think: main project, and plugin) -- is there any slick way to somehow preserve history, or even to keep that part of the tree "pointing" at the other branch to bring in updates later? Is this exactly what is going to be supported in the future with "subtrees"?
<lifeless> bzr add --ids-from /path/to/main files_copied_from_main
<lifeless> or something like that
<lifeless> then if you do a cherry pick merge bzr will know the files are the same
<johnjosephbachir> intriguing-- i'll check that out
<lifeless> keeping the history the same is rather harder, unless you're happy to have all of the other tree copied around forever more.
<bialix> hi igc
<johnjosephbachir> lifeless: this is a really cool feature, i'm amazed that i never encountered it in my hours of googling on the topic
<lifeless> its not a panacea
<lifeless> but it should help
<johnjosephbachir> lifeless: so i put file-ids-from to the top of the branch, even if i'm only integrating a part of it?
<jseabold> Hello, I accidentally moved a file under version control manually and then commited.  Is there a way to tell bzr I have moved the file to update its version history?
<jseabold> I moved the file and then used "bzr add" and then commited instead of bzr move
<lifeless> johnjosephbachir: yes, and you'll want the files being added at the same paths; then you can bzr mv then into their final place in the new tree
<lifeless> jseabold: bzr uncommit
<lifeless> jseabold: bzr remove --keep <file>
<bialix> jseabold: uncommit, revert add, then use bzr mv --after
<lifeless> jseabold: bzr mv --auto
<lifeless> jseabold: bzr commit
<jseabold> Ok, I actually commited more than once before I realized it, can I uncommit to a certain revision?
<lifeless> you can commit several times
<lifeless> you may want to shelve each step
<lifeless> unless you're happy to combine them
<jseabold> lifeless: Hmm, ok thanks.  I will try to follow your instructions.  So I'd just uncommit a few times until I'm at the right revision before the move?
<jseabold> lifeless: I think I need to read up some more on shelving.
<lifeless> uncommit; shelve --all; uncommit; shelve --all; uncommit; do stuff
<lifeless> commit; unshelve; commit; unshelve; commit
<igc> hi bialix
<bialix> igc: I've read http://doc.bazaar-vcs.org/plugins/en/qbzr-plugin.html
<bialix> I see there is holes in or doc
<bialix> and based on your mail today I think I need to release 0.13.2 with some patches cherrypicked from trunk
<jseabold> lifeless: ha, awesome.  I think I see what shelving is about.  I am mighty relieved to learn this.  Thanks.
<igc> bialix: why not a qbzr 0.14 at the end of thw week instead?
<lifeless> the docs say more
<lifeless> you don't want to uncommit past a merge, or stuff other folk will have merged, unless you really need to do.
<lifeless> but uncommit + shelve - very powerful
<bialix> igc: can you explain this deadline?
<bialix> 1 week
<bialix> igc: btw, if you will be able to regenerate the doc with fresh qbzr trunk so I can see my latest doc improvements, it will be great.
<igc> bialix: iiuic, around aug 24? is the close off day for packages to make it into karmic. Beyond that, things can go in but the paperwork and approval process becomes larger
<bialix> aha
<bialix> understand
<jseabold> lifeless: ok, I don't need to uncommit past a merge so I should be good.  Thanks again.
<bialix> igc: so yes, it's better to release 0.14 then
<igc> bialix: I'm not a deb/Ubuntu packaging guy though so take my comments with a grain of salt until someone closer to the process confirms that
<bialix> igc: I'm not either
<bialix> igc: but 0.14 cycle is kinda too short (2 weeks) I guess
<wgrant> New upstream versions do need paperwork in a week, but it's not impossible paperwork.
<wgrant> It gets progressively harder as time goes on, so you should endeavour to get it in ASAP.
<wgrant> (August 27 is the date, I believe)
<igc> bialix, wgrant: sounds right: https://wiki.ubuntu.com/KarmicReleaseSchedule
<igc> bialix: so if it's aug 27, I think next Monday is ok for 0.14
<igc> bialix: there's a lot there in a sense: qexport, qbind, qunbind and hopefully more if I pull my finger out this weekend and write quncommit say
<igc> bialix: and, no pressure, but qrun would be nice :-) :-)
<lifeless> igc: it might be prettier for people to have qbzr uncommit
<bialix> igc: we have also new commit_data patch I'm about to merge
<bialix> igc: so I think I'd better release 0.14 in the middle of this week and have 1 week for user testing.
<bialix> so we can do 0.14.1
<bialix> if necessary
<bialix> wgrant: what is the process to ensure our release from PPA will go into karmic?
<igc> bialix: to regen the plugin docs yourself, just download the branch I mentioned in the email and run the built-topics.py script. I think you can give qbzr as an argument iirc
<igc> bialix: I need some lunch - bbl
 * igc food
<bialix> ok
<jseabold> lifeless: do I need to move the file back by hand?  I uncommitted to a revision that should have the file unmoved but when I "bzr status" it shows the file as removed.  Am I missing something?
<lifeless> jseabold: uncommit doesn't change the tree
<lifeless> jseabold: which is why you need to shelve between uncommits:)
<wgrant> bialix: You have to ask for it to happen, or it will not happen at all. https://wiki.ubuntu.com/SponsorshipProcess is what you want.
<lifeless> jseabold: hwen you're back tot he point you want to be recommitting on, just do
<lifeless> bzr remove --keep FILE
<lifeless> bzr mv --auto
<lifeless> and bzr will detect it
<jseabold> sorry to be slow, but is FILE the path to the file that I have moved or the original location?  Trying the original location gave an unversioned error.
<lifeless> the new location
<jseabold> ah ok
<jseabold> lifeless: "bzr mv --after" rather than "bzr mv --auto"?
<lifeless> the latter is easier
<lifeless> :)
<jseabold> It gave me a no auto option error.  Do I need to upgrade bzr?
<lifeless> oh
<lifeless> if you have an old bzr then mv --after OLD NEW
<lifeless> --auto is reasonably old itself though. strange.
<jseabold> ugh, said OLD is not versioned
<lifeless> hmm
<lifeless> do 'bzr st'
<lifeless> does OLD show as 'missing'?
<jseabold> nope they show as 'removed'
<lifeless> ok
<lifeless> run 'bzr revert OLD'
<lifeless> then, 'rm OLD' (!not bzr rm OLD)
<lifeless> and then the mv --after should work
<jseabold> you are a lifesaver!  I think that did the trick.  Thanks
<lifeless> my pleasure
<thumper> are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ?
<vila> hi all
<lifeless> vila: hi vila
<lifeless> vila: 15:11 < thumper> are there any windows savvey bzr people that use Launchpad that could comment on https://answers.edge.launchpad.net/launchpad/+question/79261 ?
<vila> lifeless: I saw that, but *I* am not windows savvey 8-)
<vila> The best I can guess is that ssh or its agent is not configured as it should... but indeed someone can explain the steps needed to check that better than me...
<vila> lifeless: and hi :)
<lifeless> :)
<lifeless> have a good weekend?
<vila> could have been better, but life can't always be pink :)
<spm> lifeless: that locking error we were chasing earlier. hypothetically :-) if we had two almost identical tasks (bzr update/config-manager) running simultaneously, would you expect that to generate that style of error?
<lifeless> no
<lifeless> but - a) bugs
<lifeless> and b) bugs
<spm> heh
<lifeless> so
<lifeless> we guard the dirstate _write_ lock with a lockdir lock on the tree
<lifeless> and we take write locks out to write stuff (duh)
<lifeless> we don't guard dirstate read locks like that, we expect the os to tell us it can/can't read lock it.
<spm> makes sense
<spm> as a "can't hurt" trial, I've offset the problematic of the two jobs to run 5 mins after the 1st. If we get a repeat, then life gets interesting again; if we don't...
<lifeless> spm: kk
<lifeless> if it 'fixes it', file a bug
<lifeless> it may be a misconfigured sys/proc thing, or a code bug
<lifeless> there may be a legitimate error we don't catch.
<lifeless> \o/ 12 errors
<lifeless> _closing in_
<spm> right
<spm> heh
<lifeless> 11.
<spm> just as well the number counts down. I'd be worried else...
<lifeless> 5
<spiv> lifeless: hurrah!
<lifeless> I love this:
<lifeless> :!bzr commmit -m "Merge fix for test_knit in 2a."
<lifeless> Command 'commmit' not found, perhaps you meant 'commit'? [y/n]: y
<bialix> thumper: your question still open?
<bialix> thumper: answered
<bialix> vila: bonjour
<vila> bialix: hi, argh, already gone
<lifeless> Done!
<lifeless> spiv: ^
<vila> lifeless: tests passing with 2a as default ?
<lifeless> yes
<vila> YES !
<vila> :)
<lifeless> ;)
<lifeless> just in time too
<lifeless> spamming the review queue++
<vila> lifeless: since you seem to be in the right mood, care to fix the loom failures too ? :-}
<lifeless> heh
<lifeless> 6pm
<lifeless> I started at 6:30 this morning.
<lifeless> But you could put up a patch for loom !
<vila> hehe, I tried :)
<lifeless> [please do]
 * lifeless halts
<spiv> lifeless: sweet!
<spiv> lifeless: I churned through a bunch of your review proposals, btw :)
<lifeless> vila: seriously - if you wanted to identify any remaining tests (i've been running a reduced set from what failed the first time I tried) that would be great
<lifeless> vila: and secondly, loom is something we support, feel free to put time into keeping it working :)
<lifeless> spiv: i saw - thanks
<lifeless> spiv: I'm not going to shepard them today.
<lifeless> I'll probably make pqm-submit a bit friendlier tomorrow and batch-submit them from lp directly.
<vila> lifeless: (regarding loom), my last submission stalled, mostly because I had misconceptions about looms (when pushed mainly), I should look at it again...
<lifeless> vila: bzr branch lp:bzr-loom; fix the failing tests; push and submit ;)
<lifeless> the big question for me is 'should -b make a new branch or thread, in a loom' and I think the answer is 'thread'.
<vila> lifeless: hehe, I know, that was bug #309730 I was referring to, marked for expiration tomorrow :-/
<ubottu> Launchpad bug 309730 in bzr-loom "loom semantics around about push/stacking/clone unclear or buggy ?" [Undecided,Incomplete] https://launchpad.net/bugs/309730
<lifeless> oh
<lifeless> well, push in a loom to a new location is meant to make a loom
<lifeless> otherwise it pushes to whatevers there - loom or branch
<vila> yup, I thought it should always push to a branch (misconception)
 * igc dinner
<thumper> bialix: thanks
<bialix> thumper: I think there is bug report in bzr about using paramiko as default SSH client
<bialix> plink (PuTTY SSH tool) has too much caveats
<bialix> and that guy using plink
<thumper> ah
<thumper> what is the default setup with bzr on windows?
<thumper> I have some people locally that want me to give them a tutorial on bzr
<thumper> but they all use windows
<thumper> they are interested in using LP though
<thumper> so they need SSH keys
<thumper> are there docs on the wiki about the easiest way to set this up?
<thumper> I don't have a windows machine myself any more
<bialix> thumper: I guess you need to ask for this in Bzr-Windows mailing list
<bialix> I don't think there is good wiki about setup ssh for windows
<bialix> I'm working with lp and sftp and ssh since 2006 and during this years I've minted the gold rule: always use paramiko
<bialix> thumper: btw, launchpad wiki resource about setting up ssh keys is very good
<bialix> the problem not in lp itself or ssh keys
<thumper> ok...
<bialix> problem in initial connection when user should say: yes, I'm trust this ssh server
<bialix> paramiko do it implicitly
<bialix> plink just fails
<thumper> hah
<thumper> how does one add a trusted server for plink then?
<bialix> manually
<bialix> bzr can;t help here
<thumper> ick
<bialix> one need run plink to connect the server
<bialix> first time
<bialix> thumper: http://pastebin.com/m2d48ac6e
<bialix> maybe launchpad plugin for bzr can help here? with some sort of special command. I dunno
<thumper> hmm, not right now for sure :)
<bialix> yep, I mean somebody need to write this special command
<bialix> but I'm just suggest people to avoid using plink
<bialix> paramiko using the same ssh keys from pageant
<bialix> and I don't find any significant difference in speed between both
<bialix> and paramiko bundled into bzr.exe by default
<bialix> so paramiko -- it's almost the right way
<bialix> and perhaps one can file a bug against lp:paramiko and asking for y/n when unknown ssh server signature encountered
<fax8> hi there, I'm moving my first steps with bzr.. seems pretty cool so far.. I've been able to create a centralized development infrastructure ..
<fax8> now I'm not sure how the workflow for creating different versions of my software will be..
<fax8> should I have to tag the trunk? or creating subdirectories? .. I'm confused
<spiv> thumper: btw, for casual launchpad code users password auth would probably be more convenient... I wonder if we should enable that in code hosting's ssh server?
<thumper> spiv: I'm not sure I could sell that
<spiv> Yeah.  And I kinda like that we're currently only asking users to type their password directly into the website, so maybe it's not worth it.
<thumper> spiv: keep thinking though :)
<spiv> But it would probably ease the pain for SSH newbies.
<thumper> I'm sure there's something for our windows users
<thumper> perhaps we should do something with the launchpad plugin like bialix suggests
<spiv> Make the bzr installer automatically add launchpad's fingerprint to plink's registry of known hosts?
<spiv> The difficulty is partly that windows doesn't have a de facto standard SSH install like /usr/bin/ssh that we can rely on, and partly that the one of the common options (plink) is pretty crummy.
<spiv> So insulating ourselves from that via bundling paramiko is perhaps the best we can do?  Dunno.
<bialix> spiv: just for note: in the past (~2006-2007) plink was disabled for long time, at all
<bialix> because the same problem with initial y/n
<bialix> thumper, spiv: Bug #296110
<ubottu> Launchpad bug 296110 in bzr "bzr should install launchpad ssh host keys" [Low,Confirmed] https://launchpad.net/bugs/296110
<bialix> luks: hi
<luks> hi bialix
<ZuLuuuuuu> hello is there a list of project hosting sites with bazaar support?
<bialix> luks: today I've stumbled with problem in qconflicts
<bialix> luks: mark_item_as_resolved try to convert file_id to filename. do you remember why in needed?
<luks> bialix: not really, sorry
<bialix> heh
<bialix> currently I'm just using filename we shows in the widget
<bialix> I'll dogfood it more, maybe can found use case for this
<vila> bialix: Are you sure you didn't mean bug #237297 instead of #296110 ?
<ubottu> Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297
 * vila trying to better understand for the next time the question is raised
<bialix> vila: no
<bialix> they are different ways to solve th eproblem
<bialix> 296100 is about lp
<bialix> spiv and thumper talking about ssh server fingerprint, and this bug about certificates
<vila> bialix: ???
<bialix> [14:53]	<vila>	bialix: Are you sure you didn't mean bug #237297 instead of #296110 ?
<ubottu> Launchpad bug 237297 in bzr "Putty refuses to connect to unknown host with "The server's host key is not cached in the registry"" [Medium,Won't fix] https://launchpad.net/bugs/237297
<vila> both #237297 and #296110 are about host keys
<bialix> yep
<bialix> vila, I teach you right answer for this problem on WIndows: set BZR_SSH=paramiko
<vila> bialix: ok, good :)
<bialix> https://bugs.launchpad.net/bzr/+bug/414743
<ubottu> Ubuntu bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New]
<bialix> hmmm
<vila> and which ssh agent ?
<bialix> why ubottu said it's a "Ubuntu bug"?
<bialix> if paramiko then pageant
<vila> ok
<denys> bzrlib.tests.blackbox.test_serve.TestBzrServeSSH.test_bzr_connect_to_bzr_ssh is leaking threads among 1 leaking tests.
<denys> should I worry?
<bialix> vila: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<vila> denys: no
<bialix> vila: this guide is OK, but it miss the problem with plink/paramiko
<vila> bialix: may be mention that in bug #414743 ?
<ubottu> Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [Undecided,New] https://launchpad.net/bugs/414743
<bialix> it's really hard
<bialix> bbiab
<bialix> vila: it seems either nobody care too much about plink or don't want to prohibit it.
<bialix> vila: and there is only jam who can do something about windows
<bialix> cila: and jam too busy with other things
<bialix> it's a stalemate I'd say
<vila> These are good reasons to collect the information in the bug reports
<bialix> which sort of information
<vila> <bialix> vila: this guide is OK, but it miss the problem with plink/paramiko
<vila> the sooner people get good directions... the less problems they will encounter down the road...
<bialix> vila: IIUC there is possible that people could use not plink but openssh port for win32 that may not affected by plink problem
<bialix> I'm afraid there is no "right" answer
<bialix> perhaps just prohibit plink from auto-detection will be enough
<bialix> somebody should say: "yes, this is the right way"
<bialix> as of today nobody dare enough
<Colonel-Rosa> Does anyone have experience with bzr server?
<vila> bialix: JFDI :)
<bialix> JFDI?
 * bialix never was good in acronyms
<Colonel-Rosa> Jeff Fondles Dweebs, Init?
<Colonel-Rosa> I don't know, google it
<bialix> jump for dumb iphone?
<Colonel-Rosa> oh, just focus and do it
<vila> Just Do it :)
<vila> Colonel-Rosa: very polite way 'focus', thanks ;)
<bialix> oooh, quoting fullermd: where I can download extra 8 hours to do everythong I want?
<bialix> Colonel-Rosa: you can ask about bzr server
<bialix> the answer will depends on question
<Colonel-Rosa> I was going to ask, if I set one up, do I need to specfiy users if I allow writing?
<bialix> plain bzr serve has no support for ACL
<bialix> so you need to use bzr+ssh
<Colonel-Rosa> Why does it allow writes then?
<bialix> and specify users via ssh stuff
<bialix> good question
<igc> night all
<bialix> igc: night
<bialix> Colonel-Rosa: maybe because when you run bzr+ssh it invokes bzr serve via ssh in write-enabled mode?
<spiv> Colonel-Rosa: in some situations (e.g. a small, isolated network with only trusted users) a simple unauthenticated write-enabled server is all you need.
<bialix> I'm using it in such conditions at work
<bialix> small network
<igc> bialix: before I forget, that bug where qbzr and bzr-pipeline are incompatible needs fixing in qbzr 0.14.*. Can you chat to garyvdm about it? If we have to, I'd like to drop support for us override the merge command - I don't think the feature we're offering is important enough to break compatibility with other plugins overriding merge. You guys may feel otherwise though
<Colonel-Rosa> Ok, I might go with that route. I'll restrict the port to my port
<Colonel-Rosa> to my ip* rather
<spiv> Or you could run "bzr serve" on a localhost only port, and then and use another tool to provide simple authentication based on SSL client certs on a public port.
<Colonel-Rosa> I had a look at setting up a chroot jail for users, but didn't really get it
<lfaraone> Hi, is there any way to make bzr remember the password I use for my googlecode SVN? (HTTPS checkout). Currently it asks me every time.
<bialix> igc: Id like to remove merge --qpreview
<bialix> igc: but garyvdm has another opinion. but I can remove it just for 0.14 and later fix it in trunk
<bialix> igc: good point though. if you can write some comment tomorrow in that bug report
<vila> spiv: regarding ssl client certs, did you review denys merge proposal about bzrs:, you nay have to chase the right one a bit as he made several resubmit
<vila> bialix: good mail on bzr-windows :)
<bialix> why?
<bialix> I hope it will start discussion
<vila> bialix: exactly !
<spiv> vila: I did, yes.
<vila> spiv: great
<vila> spiv: I should check that to stay in touch then :)
<fjalvingh> james_w: good morning, do you have some time to look at bug 405251 again? Our new repo's are killing themselves in the same way...
<ubottu> Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251
<fjalvingh> I don't know why Kopete always replaces jam with James_W: I mean jam...
<jam> fjalvingh: I can probably look at it some today, I need to check for any other pressing matters, though
<jam> morning vila
<bialix> jam: hello
<jam> hi bialix
<bialix> jam: did you saw my message about installing Pyreadline on kerguelen?
<Enisseo> hi everyone!
<Enisseo> i'm in big trouble! :(
<Enisseo> i think maybe i lost 2 weeks of work
<bialix> bzr heads --dead
<Enisseo> bialix > yes!
<Enisseo> bialix > i see my last (true) revision in the list
<bialix> bzr pull -r revid:your-revisioin-id --overwrite .
<Enisseo> trying...
<bialix> or branch with this revid
<fjalvingh> james_w: thanks, I will wait.
<fjalvingh> james_w: thankx
<fjalvingh> Thanks, jam... Very irritating.
<fjalvingh> I will check why Kopete always replaces jam.
<Enisseo> omfg bialix! :)
<jam> fjalvingh: you might be typing jam<tab> which wouldn't autocomplete the exact name, I guess
<fjalvingh> I'm just typing jam:
<bialix> Enisseo: what? I'm in telepatic mode?
<fjalvingh> I'll check the settings.
<jam> bialix, Enisseo: or 'bzr merge . -r revid:'
 * bialix : telepatic mode off
<Enisseo> bialix: kind of ;)
<Enisseo> i did not know this command but i was pretty sure bzr could not lose my files
<Enisseo> but "bzr log" made me nervous :P
<Enisseo> maybe i'll explain how i did to lose my files
<Enisseo> 1. commit changes locally
<Enisseo> 2. commit to the repo
<Enisseo> 3. uncommit the repo
<Enisseo> 4. do a lot of changes to the --locla
<Enisseo> 5. update from the repo
<Enisseo> 6. panicking while reading the list of actions done by the update command
<Enisseo> 7. revert to the last:1 rev
<Enisseo> 8. panicking even more
<jam> Enisseo: so update changes your local work into the upstream work and 'merges' the local stuff in
<jam> when you reverted you through away your local work
<jam> 'bzr heads --dead' shows you the local work again
<jam> and you can merge that back into your upstream
<Enisseo> jam > okay
<Enisseo> bialix > thanks, really :) and to the bzr team for anticipating my mistakes (and for building a *real* VCS, unlike that sh** of VSS i have to use at my office :P)
<bialix> Enisseo: np
<Enisseo> bye!
<bialix> jam: I've got very strange error: ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex(GraphIndex('bzr://host/repo/.bzr/repository/indices/1be11e45e6965720333219afc18eac5b.rix'))) is not locked
<jam> bialix: happens when you use "-r XXX" + log + bzr+ssh
<jam> I assume we aren't locking the branch before evaluating -r
<bialix> jam: no, I'm using merge
<bialix> and plain bzr://
<jam> bialix: you are using a remote access, and -r, right?
<bialix> jam: I did not found such bug, and pehaps just filed duplicate
<jam> bzr+ssh == bzr for pretty much all purposes
<bialix> yes
<bialix> Bug #414869
<ubottu> Launchpad bug 414869 in bzr "backout merge from default location (bzr server) fails with ObjectNotLockedError" [Undecided,New] https://launchpad.net/bugs/414869
<jam> there is one for log
<jam> presumably log and merge both aren't locking the branch
<jam> which works ok locally for some reason
<bialix> error message misleading then
<bialix> it tells about locking index file. not the repo itself
<jam> it is a bug, people shouldn't get that sort of error
<vila> morning jam !
<jam> The error could probably be clearer, not sure if it is worth tracking it all down
<jam> hi vila
<goneri> Hi, who should I contact to get a review of the patch done to fix 'Bug #347729: git-bzr doesn't work'
<ubottu> Launchpad bug 347729 in bzr-fastimport "git-bzr doesn't work" [Undecided,New] https://launchpad.net/bugs/347729
<jam> goneri: jelmer is the maintainer of bzr-git, last I checked
<james_w> git-bzr, not bzr-git :-)
<bialix> if this bug about fastimport you need Ian Clatworthy, igc
<bialix> he's sleeping right now
<goneri> james_w: I know but It's broken by bzr-fastimport
<bialix> AU timezone
<goneri> bialix: ok good to know. thanks
<vila> jam: you haven't submitted 1.19-kg-merge-sort yet right ?
<jam> vila: afaik it is 1.19-known-graph-sorted and no, it hasn't been submitted yet
<vila> jam: yeah, typed it from memory, I knew you recognize it :-)
<vila> It seems to come along nicely...
<jam> vila: I'm at ~3x faster for merge_sort
<jam> it doesn't change the algorithm at all, though
<jam> I at least feel that I have a better understanding of the algorithm now
<vila> Well, I wanted to work on it too, but you fired first :-D I'm ready to review though
<jam> vila: well, review this one first, then :)
<jam> https://code.edge.launchpad.net/~jameinel/bzr/2.0b1-merge-sort/+merge/10253
<jam> vila: so the current open questions for me are
<jam> 1) Am I exposing it in a reasonable manner (VF.get_known_graph_ancestry())
<jam> 2) Should merge_sort handle ghosts internally or not
<jam> (i think it should, since it removes a lot of the _strip_NULL_parents calls)
<vila> 2) yes
<jam> 3) Should bzrlib.tsort.merge_sort be a thunk over to KnownGraph(parent_map).merge_sort()
<vila> 1) sounds ok to me (that was your last commit right ?)
<jam> 4) Should KnownGraph.__init__() check for graph cycles
<jam> vila: 1) last-ish
<jam> (rather than merge_sort and topo_sort doing it now)
<vila> 3) for backward compatibility, but my feeling is that we should deprecate bzrlib.tsort
<jam> for (3) it would basically mean moving the current tsort implementations into KnownGraph.py and then changing the tsort.py functions to import graph, etc.
<jam> 5) KnownGraph.topo_sort() == 10ms, KnownGraph.merge_sort() == 50-60ms, can I get that down any further?
<glyph> exarkun: hi
<exarkun> glyph: Hi
<exarkun> I am having trouble getting revisions that glyph is committing.
<jam> (like not allocating extra info per record, but instead hanging it off of the original KnownGraphNode object.)
<vila> 4) hmm, if they can appear, there should be a cheap way to check, so yes
<glyph> exarkun: so, the revisions are there.  the file in question does exist in my homedir on charm.
<jam> vila: right now, if gdfo = None after processing, we know we have a cycle
<jam> it just means another pass across the data
<jam> or something along those lines
<glyph> (why did this have to happen only with the *one* highly proprietary and sensitive bzr repository I've worked with this year rather than one of the dozens of totally harmless open source ones)
<exarkun> glyph: How did the revisions get there?  Did you 'bzr push ...' to charm?
<glyph> exarkun: yes.
<glyph> from illidan, as it happens
<glyph> are you pulling from alastor?
<vila> jam: hmm, I'm surprised there is not a simpler way... but that can come later if really needed (i.e. start with the check in one pass, and we found a better place, we'll get rid of the pass)
<glyph> wait no
<glyph> crap, this is my fault
<exarkun> Oh too many hosts
<glyph> for some reason 'charm' is an ssh alias for alastor on this machine
<jam> vila: well, we can check as we pass over the data already
<exarkun> glyph: Wow awesome
<jam> the current code pops things out of a dictionary
<jam> and notices when what it wants to pop isn't there
<jam> but
<jam> 1) doesn't handle ghosts
<jam> 2) takes time to build that dict, and pop everything out of it
<exarkun> okay got it
<jam> I'm down to around 4microseconds per node
<jam> which sounds great
<glyph> sorry everybody, bzr's great, no bugs
<jam> but still means it is 1.0s to merge_sort the OOo graph
<jam> though at 10s to load it, I'm probably in the right ballpark
<vila> jam: my feeling is that a two passes algo should be possible,
<vila> if loading still dominate, don't bother optimize the algo :-D
<vila> jam: two passes, not counting building the graph !
<jam> vila: 2 passes for merge_sort?
<jam> it is 1 two depth-first traverse
<jam> 1 to pop that back out and number
<jam> 1 to reverse it for display
<jam> (as it stands now)
<jam> (1 *to* depth-first trav)
<jam> oh, and convert _MergeSortNodes into merge_sort tuples
<vila> jam: ok, I haven't look at how it works in detail right now, if it's already 2 passes, then good. I'm not sure the reversing counts as a pass though, if it is, it may be worth avoiding it
<jam> vila: it costs 10-15 ms out of 55 ms of processing
<jam> though there is some more actual processing going on there
<jam> which I'm trying to factor out
<jam> well, move to a different place at least
<vila> jam: by the way, about revno 4627, don't worry too much about the layering yet, my feeling is that at one point we'll have a node_index and from there we'll be able to have dedicated arrays for specific processing
<OllieR> Hey I am having a problem adding a directory. It doesn't look to be ignored so I don't see why it won't add... http://stikked.com/view/88043329 - my bash session
<OllieR> ah so interesting the files/ dir was ignored in .bzrignore in a previous revision http://stikked.com/view/60255181
<OllieR> since then I have removed that rule but it is as if that has cached somewhere
<OllieR> abyone seen something like this before?
<luks> well, if you want to know more information use bzr add -v
<luks> but if you just want to add the directory, add it manually
<OllieR> luks - http://stikked.com/view/20119491 so I added it and it doesn't give me any errors but still shows as unknown with a status
<luks> what does "bzr add -v" say?
<luks> but I don't know what could be the issue
<OllieR> ignored config/site.php matching "config/site.php"
<OllieR> which is fine as that corresponds with my .bzrignore rule
<OllieR> this is truly weird. Not seen anything like this before
<luks> my guess would be that there is something wrong with the checkout, so I'd make a new checkout to see if it works there
<OllieR> doh the files/ dir was a different checkout!
<lifeless> moinmoin
<vila> Good morning lifeless:)
<lifeless> 4 new failures since I last ran full test run
<beuno> wooo
<beuno> go 2.0, go!
<vila> lifeless: merge trunk and use --parallel=fork again :-)
<gsuveg> re
<awmcclain> What's the command I should run to update my repository (which I created around 1.08 or somesuch)?
<jderose> awmcclain: bzr upgrade --<format>
<jderose> awmcclain: e.g., bzr upgrade --1.9
<lifeless> awmcclain: is bzr telling you to ?
<awmcclain> lifeless: No, it's not, but it's been quite slow branching and doing everything.
<lifeless> awmcclain: we have a bug open at the moment about an apparent performance regression
<lifeless> I suggest you file one yourself
<awmcclain> lifeless: Oh... this isn't a regression. This is more like I haven't seen any speed increases since I've started using bzr.
<lifeless> ah
<awmcclain> What's the newest repository format?
<awmcclain> --19?
<lifeless> what does bzr info -v report for the repository you have?
<awmcclain> 1.9
<awmcclain> Format:
<awmcclain>        control: Meta directory format 1
<awmcclain>     repository: Packs containing knits with rich root support
<awmcclain> so....should I upgrade?
<beuno> awmcclain, upgrade --2a should give you give significant performance improvments
<lifeless> what bzr version do you have?
<lifeless> awmcclain: ^
<awmcclain> 1.18a
<awmcclain> 1.18rc1, sorry
<lifeless> awmcclain: yes, switching to --2a would be sensible. There are docs on doing this on the web
<lifeless> awmcclain: please do follow the upgrade guide ;)
<awmcclain> lifeless: Great! Will do.
<awmcclain> Hrm... my bzr status is borked. (Haven't run the upgrade yet). here's the traceback: http://dpaste.com/81857/
<lifeless> try --no-plugins
<awmcclain> a ha...
<LarstiQ> weird traceback though
<lifeless> awmcclain: if that works, try upgrading your plugins, or something
<awmcclain> lifeless: It was the xmloutput plugin, which was nearly 18 months old
<awmcclain> I don't even need it anymore
<awmcclain> Thank you!
<Noldorin> hi lifeless
<lifeless> hi Noldorin
<Noldorin> thought i might try to prgoress a bit more with my FTP issue now
<Noldorin> while i have some time
<lifeless> cool
<Noldorin> i got your last message...but wasn't quite clear on a few things
<lifeless> spiv: :( you broke my testsuite
<Noldorin> <lifeless>	there is a function in that file that the lock object uses to check that its in the right place on disk and has the right nonce
<Noldorin> i'll be glad to test that now, if you could just clarify things slightly
<awmcclain> One thing I'm not sure of after reading http://people.canonical.com/~ianc/doc/en/upgrade-guide/#data-migration, I have a local shared repository containing a bound "trunk" branch to a remote server (which also has a shared repo) as well as my local branches. Do I need to update the repo on the remote server before I update my local repo?
<lifeless> Noldorin: self.confirm()
<lifeless> put that after the self.transport.rename()
<Noldorin> right
<lifeless> in normal operation that will raise
<lifeless> with your symptoms it may not raised
<Noldorin> i see
<lifeless> awmcclain: no, you can upgrade them independently
<lifeless> the server will need bzr 1.16 (1.18 preferred) though
<lifeless> Noldorin: so you probably need a try:except:else: around the confirm
<lifeless> with the else clause being the 'ftp breakage is occuring code path'
<Noldorin> hrmm...we're not still talking about __init__.py here?
<lifeless> never were
<lifeless> lockdir.py
<Noldorin> oh sorry
<Noldorin> i missed that bit
<Noldorin> we were messing with __init__.py at first
<Noldorin> a while ago
<Noldorin> lifeless: in the _attempt_lock function i presume?
<lifeless> Noldorin: unlock()
<lifeless> Noldorin: locking works fine, its unlocking that is failing
<lifeless> lock appears to fail because the unlock isn't working
<Noldorin> ok, got it
<Noldorin> lifeless: http://pastebin.ca/1533028
<Noldorin> does that look right to you?
<lesshaste> hi glyph, are you about?
<glyph> lesshaste: what's up?
<lesshaste> glyph, something boring I am afraid..it's about python
<lesshaste> I understand you are the founder.. can I pm you?
<lesshaste> I mean #python
<lifeless> Noldorin: you have some tabs
<lifeless> just use spaces (python limitation)
<lifeless> the except needs to be
<lifeless> except LockBroken:
<lifeless>     pass
<lifeless> else:
<lifeless>    print "ftp breakage"
<Noldorin> ok
<Noldorin> got it
<Noldorin> thanks. i can read python, but no more really :)
<Noldorin> lifeless: http://pastebin.ca/1533033
<Noldorin> ftp breakage indeed
<lifeless> right, we're detecting it
<lifeless> I'd add that patch to the bug
<Noldorin> :)
<lifeless> its also now at the point you might be able to show your FTP server admins
<lifeless> we can continue hunting for a work around
<lifeless> perhaps a while loop
<Noldorin> ok sure
<Noldorin> hmm, so what exactly is the FTP server doing wrong?
<lifeless> its not renaming the directory.
<lifeless> but its not erroring either
<Noldorin> (this is IIS6 btw, so i'm not sure how much they could do, short of changing the server software)
<Noldorin> hmm
<Noldorin> due to the fact the OS is locking it, you think?
<lifeless> something :P
<Noldorin> heh
<Noldorin> shall we test this manually perhaps?
<Noldorin> (is there any way to do so?)
<lifeless> with an ftp client perhaps
<Noldorin> yep, i have filezilla or windows explorer at hand
<lifeless> doing the same operations by hand
<Noldorin> lifeless: so just renaming the /branch/lock/held dir to something arbitrary?
<lifeless> yes, with a file in that dir called info, and with the sort of text we put in our info files
<Noldorin> ok
<Noldorin> Status:	Renaming '/httpdocs/repos/texdotnet/.bzr/repository/lock/held' to '/httpdocs/repos/texdotnet/.bzr/repository/lock/held-temp'
<Noldorin> Command:	RNFR held
<Noldorin> Response:	350 File exists, ready for destination name
<Noldorin> Command:	RNTO held-temp
<Noldorin> Response:	250 RNTO command successful
<Noldorin> lifeless: no problems there :S
<lifeless> Noldorin: you don't know that
<lifeless> does held still exit
<lifeless> *exist*
<lifeless> I suspect you need the whole set of operations to trigger it
<Noldorin> hrmm i see
<lifeless> if simply renaming was broken all the time, it would never be able to work
<Noldorin> but if i'll really need to tell my ftp server admin the entier set of steps...
<Noldorin> if they're to reproduce it
<lifeless> 'bzr init' :)
<lifeless> with your build
<Noldorin> lifeless: i tested this on the repo i just pushed btw
<Noldorin> lol
<lifeless> if you run with -Dtransport
<lifeless> then you can see the FTP commands
<Noldorin> i'm not sure i'm paying them enough for that :)
<Noldorin> ok
<lifeless> and make a script to match
<lifeless> we could also automate that using bzrlib
<Noldorin> ok, sounds like a plan
<Noldorin> lifeless: http://pastebin.ca/1533056
<Noldorin> lifeless: anything interesting in there?
<lifeless> Noldorin: if thats the commands bzr is doing, not for me
<lifeless> we know whats going on - bzr is doing a rename, server is saying it has but not doing it
<Noldorin> yeah
<lifeless> there are two main things to do:
<lifeless>  - get the server environment fixed, now that we have bzr able to report on it being broken
<lifeless>  - get an optional flag to make bzr retry the rename some number of times, which you can use to workaround the problem
<Noldorin> right, so if i wrap the rename command in a loop with a 1 second delay, then test that...?
<lifeless> for instance, yes
<Noldorin> lifeless: say i loop 10 times, and exit the loop when self.confirm succeeds, will that be the right thing to try?
<lifeless> sure
<lifeless> for pos in range(10):
<lifeless>     rename
<lifeless>     try:
<lifeless>         self.confirm
<lifeless>     except LockBroken:
<lifeless>         break
<lifeless>     else:
<lifeless>     print "ftp breakage"
<Noldorin> heh, cheers :)
<lifeless> hmm, indent the print more
<Noldorin> yep, noticed
<Noldorin> ho hum
 * Noldorin crosses fingers..
<Noldorin> hrmm
<Noldorin> ftp breakage
<Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
<Noldorin> s not exist.
<Noldorin> lifeless: strangeness..
<lifeless> heh
<jam> lifeless: do you know if poolie is back around?
<Noldorin> now i'm baffled...
<lifeless> jam: I don't, sorry.
<lifeless> jam: hugh got in last night, so if poolie left on the same day he should be around today
<Noldorin> lifeless: http://pastebin.ca/1533085 - sorry for more code review, but can you spot any issue there?
<Noldorin> or perhaps explain the error otherwise?
<lifeless> that looks accurate
<lifeless> I have to assueme that other error is either a) unrelated or b) part of the same server environment issue ;)
<Noldorin> yeah, that was my conclusion
<Noldorin> (well, there really isn't any other)
<jam> lifeless: k. poolie and I usually have a weekly call ~ now, and I was just wondering if he was going to show up this week
<Noldorin> lifeless: brb 20 mins. let me know if the reason strikes you :)
<lifeless> jam: You can ring me if you need to talk to someone ;)
<jam> lifeless: thanks.
<jam> No specific need
<jam> just trying to keep in a weekly habit
<lifeless> I have 2a default w/no test failures
<jam>  \o/
<Noldorin> lifeless: otherwise, i'm just going to have to send my build over to my web host admin and hope they bother checking into it :P
<lifeless> Noldorin: try pushing again
<lifeless> does this new error repeat?
<Noldorin> yes
<lifeless> if so, pastebin a -Dtranspot trace of it
<Noldorin> lifeless: http://pastebin.ca/1533089
<Noldorin> interesting. it seems like the unlock is succeeding now (?)
<Noldorin> brb
<lifeless> looks like
<lifeless> rename
<lifeless> check
<lifeless> rename again
<lifeless> then a traceback
<lifeless> can you run with BZR_PDB=1
<jam> lifeless: I'm probably going offline now. If you see poolie he can call my house or cell
<lifeless> jam: ok. gnight
<thumper> ImportError: cannot import name weave
<thumper> ?!?
<thumper> nm
<thumper> it was probably my update updating bzr while I was pulling :)
<lifeless> thumper: yes
<thumper> is there a bzrtools that works with bzr.dev?
<Noldorin> back
<Noldorin> lifeless: no luck still
<Noldorin> :S
<lifeless> try http://pastebin.ca/1533125
<Noldorin> will do
<igc> morning
<Noldorin> bzr: ERROR: At ftp://alexreg-repos@213.175.198.12/texdotnet you have a valid .bz
<Noldorin> r control directory, but not a branch or repository. This is an unsupported conf
<Noldorin> iguration. Please move the target directory out of the way and try again.
<Noldorin> lifeless: isn't that lovely?
<lifeless> Noldorin: did you delete the texdotnet dir first?
<lifeless> and check it was actually gone ?
<Noldorin> yeah
<lifeless> !
<Noldorin> hrmm
<Noldorin> works now
<Noldorin> well i say works but...
<Noldorin> back to thsi again:
<Noldorin> ftp breakage
<Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
<Noldorin> s not exist.
<Noldorin> no "past unlock step"
<lifeless> ok, some exception is being raised
<Noldorin> mm
<lifeless> http://pastebin.ca/1533138
<Noldorin> heh, i like this way of resolving bugs :)
<Noldorin> it's tedious, though methodical at least
<lifeless> james_w: hi
<Noldorin> ftp breakage
<Noldorin> fail:  No such file: '/texdotnet/.bzr/branch-lock/held': : unable to rename to '
<Noldorin> /texdotnet/.bzr/branch-lock/releasing.1db1o9w8i4g6wxax077u.tmp': 550 /texdotnet/
<Noldorin> .bzr/branch-lock/held: The system cannot find the file specified.
<Noldorin> bzr: ERROR: Parent directory of ftp://alexreg-repos@213.175.198.12/texdotnet doe
<Noldorin> s not exist.
<lifeless> Noldorin: fun!
<lifeless> so we rename
<Noldorin> yep
<lifeless> but the rename hasn't taken effect (because we read back)
<lifeless> then, when we try to rename again, its been moved
<james_w> hey lifeless
<Noldorin> yep
<lifeless> james_w: the .so
<Noldorin> makes sense
<lifeless> james_w: the .so's in the wrong place, what corrects that for the debs - or did you manually work around?
<james_w> sorry, I think I'm lacking context
<james_w> the bzr pyrex speedups?
<Noldorin> lifeless: anything further to test?
<lifeless> james_w: yeah, on karmic setup.py puts them in bzrlib/bzrlib/*.so
<lifeless> there was a bug filed on the nightly debs
<james_w> I missed the bug
<lifeless> And I thought you closed that; we still have a bug in the core about it too (the deb bug being that the dailies should fail to build if the .so's are not there)
#bzr 2009-08-18
<james_w> the bug on the nightlies was that they didn't build them at all
<james_w> pyrex wasn't installed because the usual debs don't need it as the tarballs contain the c files
<lifeless> oh!
<lifeless> righto
<james_w> I fixed that, but neglected to check the paths
<lifeless> so, can you check then, that the so's are going to the right place
<lifeless> and if they aren't make the build fail
<james_w> just looking now
<lifeless>  / workaround
<lifeless> I'd rather the dailies fail if the .so's won't be available to the user.
<james_w> todays uploads have python*/*-packages/bzrlib/*.so
<lifeless> thats great
<james_w> I can add a check that that glob matches something at build time
<lifeless> please
<lifeless> look for one of the pyrex based ones
<lifeless> Noldorin: http://pastebin.ca/1533156
<ronny> sup
<ronny> lifeless: what are the current plans for python3 support?
<Noldorin> lifeless: same result
<lifeless> ronny: there aren't any
<lifeless> Noldorin: can you paste the output please?
<Noldorin> sure
<lifeless> ronny: by which I mean, that we'll accept patches making it easier to use a porting tool etc
<Noldorin> lifeless: http://pastebin.ca/1533161
<lifeless> ronny: but we need to keep supporting python 2 for 5 more years or so
<lifeless> ronny: and python 3 is basically a different language/platform
<lifeless> Noldorin: _wow_
<lifeless> Noldorin: can you do that again, with -Dtransport please
<Noldorin> sure
<Noldorin> indeed, it is behaving rather unusually :P
<Noldorin> lifeless: http://pastebin.ca/1533166
<Noldorin> lifeless: making any sense to you?
<lifeless> Noldorin: yes, look at lines 33, 34, 35
<lifeless> we read a file twice
<lifeless> then get an error renaming the directory above it
<lifeless> I suspect this is just too much damage to reliably work around it
<lifeless> showing that trace to your sysadmins should convince them something is wrong pretty quickly :)
<lifeless> I'll update the bug with more info
<Noldorin> heh, fair enough
<Noldorin> thanks :)
<lifeless> and do whatever I can to help them get to a cause
<Noldorin> lifeless: do you recommend i just point the admins to the bug report, or specifically this trace?
<lifeless> Noldorin: both I suspect
<Noldorin> right
<Noldorin> not sure what i can expect them to do however :(
<Noldorin> if the problem is due to IIS6
<lifeless> IIS has many options
<lifeless> it could be a backing server
<lifeless> they can file a bug with microsoft
<lifeless> etc
<lifeless> I wouldn't want to assume they can't do anything ;)
<Noldorin> yeah, i know
<Noldorin> it certainly doesn't heart to try
<Noldorin> it's just i'm not optimistic!
<Noldorin> but yeah
<Noldorin> if you could update the bug report with the new info, that would be great :)
<lifeless> I will be doing so shortly
<Noldorin> great
<Noldorin> the latest -Dtransport trace should really be attached there, of course
<spm> *** FYI. restarting codehosting for a Cherry Pick ***
<JoaoJoao> Hello
<lifeless> hai
<JoaoJoao> So, when I cancelled a bzr merge, when I tried the same bzr merge, bzr complained about already existing upload packs
<Noldorin> lifeless: i have to go now, but i plan on emailing my host tomorrow.
<Noldorin> if the bug report will be updated by then, that would be helpful
<Noldorin> anyway, i'll let you know the result.
<JoaoJoao> it looks like it's related to the bug https://bugs.launchpad.net/bzr/+bug/165293
<ubottu> Ubuntu bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed]
<Noldorin> lifeless: is that alright...? if you're busy, i could always update it myself. but i feel you understand the issue significantly better than me
<lifeless> Noldorin: Its in my queue to update
<Noldorin> :)
<Noldorin> right ho
<Noldorin> bye
<lifeless> JoaoJoao: you hit ctrl-C while bzr was doing the merge?
<JoaoJoao> yep
<lifeless> ok, I suspect you've found/provoked a bug in the final insertion stage
<lifeless> what repo do you have - info -v will tell you
<lifeless> it prints a repository line
<lifeless> Noldorin: bye ;)
<JoaoJoao> you mean the format?
<JoaoJoao> it's 2a
<lifeless> ok
<lifeless> bzr dump-btree .bzr/repository/pack-names
<lifeless> pastebin the output (its not personal)
<lifeless> JoaoJoao: ^
<lifeless> igc: could I beg three reviews off you?
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-398668/+merge/10288
<lifeless> has two reviews listed in the last comment
<lifeless> and after that, the main branch itself
 * lifeless foods
<JoaoJoao> lifeless: I'm not at the computer with the repo, I'll post that tomorrow, ok?
<lifeless> ok
<lifeless> bbiab
 * igc lunch
<[1]reggie> anyone got a second to answer a question about bundles?
<bob2> best to just ask
<[1]reggie> sorry
<[1]reggie> our commit messages have a bundle file attached.  I uncommitted some revs and then reverted them (mistake).  now I want to reapply from the bundles
<[1]reggie> but when I save a bundle file to my desktop and then do bzr merge <bundle file>  it just says nothing to do
<[1]reggie> this is bzr 1.1
<[1]reggie> 1.17
<[1]reggie> I thought the bundle file contained the "diff" of the revision and it could be applied right from the bundle
<jam> [1]reggie: if you are getting 'nothing to do' that probably means the changes are already merged (by ancestry, if not by diff)
<jam> I'm not user about "uncommitted some revs and then reverted them"
<jam> if you reverted some changes and then committed
<jam> then I would see how you would get the behavior you are seeing
<jam> *uncommit* should remove them from the ancestry, such that 'bzr merge' will re-apply it.
<[1]reggie> jam, could the problem be the encoding of the bundle?  it's not a readable diff.  it's encoded for email
<[1]reggie> does merge handle the unencoding or do I have to do that?
<jam> [1]reggie: possible. If we can't detect that it is a real bundle, then we would probably try to merge the containing dir
<jam> though last I looked at the code, it would read through as much as it could to find the # Bazaar bundle ... header
<jam> even if it was in the middle of an email
<jam> (inline vs attachment)
<lifeless> I suspect a commit-of-the-revert rather than an uncommit
<jam> [1]reggie: so my initial thought is that you didn't uncommit as much as you thought you did
<lifeless> so the bundle is already merged, as jam says above
<[1]reggie> i basically did several bzr uncommit --local
<jam> [1]reggie: there is also the possibility that you could pull the revision-id directly from the bundle
<[1]reggie> and then a bzr revert
<jam> [1]reggie: uncommit --local will be negated by you next 'bzr update'
<jam> *your* next
<jam> since you didn't uncommit the remote revs
<[1]reggie> jam, ok,  sorted some things out but I hit a new snag
<[1]reggie> the uncommit command told me that I coudl restore to this tip by running a certain bzr pull command
<[1]reggie> but I neve rpushed the commits that I uncommitted
<[1]reggie> and when I run the pull command it says the branches have diverged and I need to run bzr merge
<[1]reggie> but bzr missing says I'm up to date and bzr merge says nothing to do
<[1]reggie> I thin it is confused
<jam> [1]reggie: are you doing "bzr merge . -r revid:..." ?
<jam> not just plain "bzr merge"
<[1]reggie> the command it gave me to run was bzr pull . -r revid:reggie.burnett@sun.com-20090817220415-3vg2w7n0a46u09jj
<[1]reggie> but that says 'these branches have diverged'
<jam> [1]reggie: because you've done commits since the uncommit, the histories have diverged
<jam> you can do "bzr merge . -r revid:reggie.burnett@sun.com-20090817220415-3vg2w7n0a46u09jj"
<RenatoSilva> Instead of keeping a changelog file for changes in software releases, I want to keep a changes_from_previous file, that is, a changelog for the current release only, so that each changeset would be a revision of that file matching the related release. What do you think, is it a good idea?
<doctormo> I wanted to ask if it's possible to warn someone if they are about to commit a forbiden (or highly questionable) file type, such as pdf, doc, jpeg. We want to make sure our learning courses for ubuntu have only the sources.
<lifeless> yes, a precommit hook can do policy checks and abort commits that fail $whatever-your-policy is
<doctormo> useful
<spm> doctormo: fwiw, if you go down that path - don't just rely on "*.(pdf|jpg)" for example; Suggest you use file(1) against the suspect. Assuming I'm not telling you stuff you didnt already know. :-)
<doctormo> spm: This is an offical Ubuntu project to teach people how stuff works, the course writers will need help understanding bzr to get into development. I was thinking gtk-bzr
<johnjosephbachir> if both branches and checkouts can be branches, what is the value of having a mirror branch vs a mirror checkout?
<johnjosephbachir> s/can be branches/can be branched
<ronny> johnjosephbachir: branches carry the history along
<ronny> checkouts just point to it
<johnjosephbachir> so do non-lightweight checkouts
<johnjosephbachir> they carry all the history
<fullermd> If you're never committing to it, there's no significant difference.
<bob2> if you are, the default merging behaviour differs
<fullermd> Though of course, you can't really branch a checkout.  When you think you are, you're branching a branch, which you find by pointing at a checkout of it.
<bob2> 'bzr up' can do unpleasant things
<johnjosephbachir> okay
<vila> hi all
<vila> hmpf, massive upgrade all around, massive reboots will follow :) bbar
<spm> hey vila-massive-reboots!
<gsuveg> re
<gsuveg> i srtongly thinkig about write netbeans bzr plugin
<lifeless> that would be great
<gsuveg> i use netbeans
<gsuveg> and doesnt exist bzr only git
<vila> lifeless: inserting CountingDecorator has no effect (unsurprisingly but I checked anyway), do you still want it ?
<lifeless> vila: it totally should for parallel=fork
<vila> lifeless: yeah, we both wish, but it doesn't work
<lifeless> do you get a progress bar?
<lifeless> parallel=subprocess will add its own decorator.
<vila> oh yes, I always have a pb, the # tests is missing though
<lifeless> I mean a counter ;)
<vila> yes, I got the counter but without indication of how many tests *will* be run, I can live with that for a while though
<vila> it's better than not having it (man, 2 weeks without it... such a joy to get it back ;-)
<lifeless> ok
<lifeless> I did the better API
<lifeless> it needs a review I think, in subunit. You could do that if you wanted ;)
<vila> Already ? Great, I'll have a look
<vila> lp:~lifeless/subunit/push-pop-progress ?
<lifeless> something like that
<lifeless> a week and a bit back actually ;)
<vila> yeah. 20090808 sounds like that
 * fullermd begins to lose hope that bundlebuggy will display the page...
<vila> lifeless: I still can't imagine when you can have a negative delta with PROGRESS_CUR, care to enlight me ?
<vila> fullermd: wait for abentley to be bacl from vacations and restart his BB host ?
<fullermd> Well, I don't so much have any _need_ to see it...
<vila> stop hoping then :)
<vila> but he's supposed to come back today...
<fullermd> That's sorta my mantra.  Everything's easier when you give up hoping   :)
<gsuveg> nono. hope is important
<vila> I think the trick is not to give up but to accept that not all hopes can be fulfilled :)
<vila> ... and keep smiling anyway (yeah, right...) :-D
<fullermd> It takes more muscles to frown than to smile, but it doesn't take any to just sit there with a stupid expression on your face.
<lifeless> vila: test filtering
<vila> lifeless: ooooh, excellent, thanks
<OllieR> will be a bzr up stop if a shell session is terminated/
<OllieR> ?
<lifeless> OllieR: if it gets SIGHUP'd
<lifeless> its up to your shell
<OllieR> ok so yeah the update would fail?
<OllieR> can you do a disown on that command then
<bob2> screen's easiest
<OllieR> i tried but then it asks for a password and doesn't allow my input
<OllieR> can't think how I would do it
<fullermd> That's what nohup is for...
<OllieR> ok but can i issue a password with nohup?
<lifeless> I'd use screen
<lifeless> :)
<fullermd> nohup doesn't disconnect it from the terminal.  It just blocks SIGHUP.
<fullermd> Of course, it also may screw with std{out,err} and do other such manipulation, so something like screen can be a better choice (and for other reasons as well), but it's a simple choice.
<OllieR> lifeless: thanks screen is ideal :)
 * igc dinner
<thumper-afk> can we move cbranch into bzr.dev?
<thumper> it is the only reason I still have bzrtools
<vila> thumper: You just don't like bzrtools, are you ? I knew it...
<thumper> vila: I love it
<thumper> I use cbranch and shelve
<thumper> now shelve is in trunk
<thumper> I want cbranch there too
<thumper> because right now, bzrtools won't run with bzr.dev or the nightly ppa
<thumper> which for me is a serious PITA
<vila> Yeah, you want to empty bzrtools, you don't like it, stop pretending :-D
 * vila is afraid the initial joke went unnoticed :-D
<pygi> vila, :P
<vila> thumper: hmm, bzrtools still hasn't relaxed it's compatibility policy and refuse to load ?
<thumper> no...
<thumper> vila: I did notice
<thumper> vila: I just ignored it :)
<vila> thumper: abentley is coming back from vacations today right ? The patch is easy enough (jam used such a patched version to build the windows installers)
<thumper> vila: oh, I'm sure it is simple
<thumper> vila: but this isn't the first time things have gotten out of sync
<thumper> vila: and since it is pretty trivial to make this right
<thumper> vila: lets DTRT
<vila> thumper: as for your initial question, past 2.0 the overall worflow UI will be reworked so certainly cbranch feature will be taken into account
<lifeless> I wouldn't want to bring cbranch in before 2.0
<lifeless> and after 2.0, well as vila says theres a big overhaul to do
<vila> thumper: ha ! You're preaching the chore (sp?) !! But try again with abentley :-D
<thumper> well, we're almost there now anyway
<thumper> I know, I know, I'm just frustrated
<lifeless> thumper: talk to your wife about that :)\
<thumper> I'm running the 1.18 branch build locally instead of my system installed package
<fullermd> vila: "choir".  Though, for some of us, choir WOULD be a chore...
 * vila giggles
<vila> fullermd: by the way, using merge proposals on LP is now the preferred way for submissions,
<vila> fullermd: regarding your DWIM revisions, 1) using mp will ensure a better tracking, 2) it will certainly get more attention once 2.0 is out 3) Can't you try it as a plugin ? Such features are really hard to judge without using them for a while....
<fullermd> Well, that requires uploading a branch, rather than just sending a bundle.  And that means either waiting forever, or stacking, and from all the fun stacking seems to be giving everyone for 2a upgrades...
<vila> fullermd: bzr.dev is not in 2a (yet) and push is stacked by default on lp and works flawlessly, just give a try, really
<fullermd> I don't see how it could work as a plugin, since it requires changing functions.
<vila> *All* merge proposals (i.e. the vast majority of landed patches) for the last releases came from stacked branches on lp
<vila> monkey patching ?
<fullermd> Well, yeah.  If it were in 2a already, issues stacking causes upgrading to 2a would be moot   :)
<fullermd> (and for changes like those trivial cleanups in revspec.py in my other [MERGE], it seems insane to create and upload branches for 3 lines of change)
<fullermd> I'm vaguely aware of what monkey patching it, but I haven't the slightest idea how to go about it, nor would I want to if it were at all avoidable.
<thumper> fullermd: pushing a stacked branch to lp is pretty quick
<vila> you should talk to lifeless one of these days, he add some n lines patches (with n quite small) landed in no time with that
<thumper> fullermd: also, when the merge directive stuff for 2a is sorted out
<thumper> fullermd: you can use bzr send
<thumper> fullermd: and LP will create the branch for you
<OllieR> does anyone else get this. I commit a single character change in one file and I need to upload 3mb for the commit to finish. doesn't make any sense...
<vila> thumper: hey ! Right I think the md stuff *is* sorted out (in trunk if not in 1.18), what email should be used ?
<fullermd> It's still conceptual overhead of having a branch around, for a change I could write on my hand in ballpoint.
<thumper> vila: well, LP needs to be updated for it to work
<vila> fullermd: ho, come on, the point is how that branch/bundle is handled *once* you have created it
<vila> thumper: ha, right,
<fullermd> I'm also still ill at ease with the fact that the LP merge requests go off to the team, not the list.
<thumper> vila: merge@code.launchpad.net
<vila> thumper: thnks for the reminder, sry for being lazy :)
<fullermd> Maybe with internal stuff that's no difference, but with something like the DWIM revspecs, which is a user-visible change, I'd sure like the opportunity for users on the list to be able to see and comment on it before it lands or is rejected.
<vila> fullermd: right, I keep forgetting that, because, in my case, all the mp related mails are filtered in the same mailbox than the list :-/
<fullermd> I feel like the move to LP reviews really cuts off a lot of the chance for community desirability discussion.  Maybe that's intentional.
<vila> fullermd: not intentional !!!!
<fullermd> Well, it is for me too ('cuz otherwise it ends up in the -bugs mailbox.  Have I mentioned how much I hate LP's mail sending stuff lately?)
<vila> eeerk, how can you imagine that :-(
<fullermd> I don't, quite, but nobody seems at all concerned that essentially all the code reviews are no longer seen by anybody other than the devs and a few non-dev masochists like me who joined the team...
<vila> I had some troubles to define my filters correctly but it's all godd now and *I* am quite happy with lp mails...
<vila> fullermd: that's a good point, I really think every dev has more or less handle the filtering and don't realize that ...
<vila> fullermd: there were talks at one point about tagging the mails and let people tweak some preferences in their subscription, I think it's worth raising the point again
<OllieR> modified system/application/models/select_model.php (I added one word to this file)
<OllieR> [###############-    ]   9211kB @   26kB/s | Uploading data to master branch - Stage:Copying content texts:Copied record 178/196
<OllieR> It just seems crazy
<vila> fullermd: Anyway, overall, I'm convinced there is value in your DWIM rev spec and that surely is worth discussing and get more exposure, I was trying to give my understanding on the apparent lack on feedback so far
<fullermd> OllieR: What protocol are you talking across?
<OllieR> sftp://
<fullermd> So it's presumably repacking something, which requires downloading N% of the repo, then re-uploading it.
<OllieR> fullermd: ok so is there any way to speed this up?
<fullermd> If you can use a smart protocol, that should all happen server-side, and not have to shuffle the data across the network twice.
<vila> OllieR: keep in mind that if it's indeed a repack that is occuring, it shouldn't occur frequently (1 every 10 then 100 then 1000 commits)
<vila> OllieR: another option is to issue 'bzr pack' on the server side, but that also requires bzr on the server
<lifeless> OllieR: its bzr doing autocompaction
<lifeless> OllieR: it will happen very rarely, and it keeps the repository performance good
<OllieR> fullermd: how do you mean a smart protocol?
<fullermd> OllieR: bzr[+something]://
<domas> I just wanted to share how I am pleased with 'bzr co'  grabbing 600M of RAM  on my virtual machine :-))
<lifeless> domas: do you have the C extensions? they can help a _lot_
<domas> I hope I do, um. :) I guess I'd use PPA builds
<OllieR> This is think is the problem
<OllieR> checkout of branch: /home/bazaar/mycompany/example.com/screenings/trunk
<OllieR>    shared repository: /home/bazaar
<OllieR> so every tree uses a single shared repository dispite the fact that they are usually not related
<OllieR> i.e. /home/bazaar/mycompany/example2.com/web/trunk is completely different code to /home/bazaar/mycompany/example.com/screenings/trunk
<OllieR> http://bash.pastebin.com/m646edb67 - 7gb repo
<OllieR> Could anyone advise on this setup?
<fullermd> Well, it sounds like a situation where you (not necessarily you personally, but you somebody-associated) control the server.  So using bzr+ssh instead of sftp probably wouldn't be all that hard.
<fullermd> And it would certainly mitigate issues like this by not getting the network involved in stuff it doesn't have to be.
<OllieR> i just ran a bzr pack on the server and then committed again from my local system and it was a lot faster
<OllieR> I will look into bzr+ssh
<lifeless> OllieR: the pack didn't make a difference :)
<OllieR> fullermd: do you know if having one shared repo for all projects is a bad idea? I would assume I should have a shared repo for each project...
<lifeless> OllieR: the previous commit had already done the tuning :)
<OllieR> lifeless: I cancelled the commit, as it was taking forever
<OllieR> then can a pack on the server
<lifeless> ah
<lifeless> ok
<OllieR> then committed from local
<fullermd> OllieR: Well...   it doesn't _gain_ you much, in cases where there's no shared history.
<OllieR> fullermd: but it could potential slow things down?
<fullermd> And at some level, it will slow things down, since there's a lot of data there you can't possible care about at any given moment, you've got more to troll through to find the stuff you do.
<fullermd> Now, whether that's significant, is an empirical question...
<fullermd> I'd say that putting repos at project boundaries makes more sense, since that's where most of your sharing is.
<OllieR> yeah everything on this dev box seems to all of a sudden slowed right down
<fullermd> I think it's axiomatic that one-repo-for-everything is going to be slower.  But how much slower?  If it's 2% slower, who cares?  If it's 20% slower, that may be another matter.
<fullermd> It seems unlikely for it to have caused a sudden dropoff, unless you just put something new and huge into it.
<fullermd> A 300 meg project in a 7 gig repo is going to be slower than a 300 meg project in its own 300 meg repo.
<fullermd> But it'll still be way faster than a 7 gig project in its own 7 gig repo.
<OllieR> ok thanks for the info
<lifeless> generally we have log tree depth
<lifeless> so it shouldn't matter much
<lifeless> 200+ way fan out on a typically B+Tree index in recent repo foramts
<lifeless> which is to say, you need 200 times as much data to add a single additional level to the index.
<andrea-bs> Hello! How can I upgrade the working tree of a branch?
<NEBAP|work> hi
<NEBAP|work> IÂ´m using bzr push to push the history to a location that is backed up daily
<NEBAP|work> now using push with (X:\Folder\Folder) also uploads the working tree what I donÂ´t need
<NEBAP|work> what can I do to prevent doing this?
<hmeland> See "bzr init-repo --no-trees".
<NEBAP|work> so I should initialize the repo on the server at first?
<hmeland> Yes, as a parent directory of wherever you're pushing your branch to.
<hmeland> You can use e.g. a sftp:// URL to "bzr init-repo".
<NEBAP|work> so sometimes push just pushes the history and sometimes it pushes the working tree, too, depending on the protocol?
<hmeland> Depends on both the protocol you're pushing over (sftp, local file access, etc.) and how the destination has been set up prior to the push.
<garyvdm> hmeland: you can also just do bzr remove-tree REMOTE_BRANCH
<NEBAP|work> k
<garyvdm> I meant NEBAP|work ^^
<garyvdm> NEBAP|work: I would do what hmeland suggested if you are pushing multiple branches.
<NEBAP|work> so if I want to push to a non-existing local location without pushing the working tree, I should do:
<NEBAP|work> bzr init-repo --no-trees
<NEBAP|work> bzr push
<NEBAP|work> ?
<hmeland> You can use "bzr reconfigure --use-shared --with-no-trees X:\Folder\Folder" to convert your existing stand-alone branch to a shared repository without any working tree.
<NEBAP|work> hmm
<hmeland> NEBAP|work: Yes, with the appropriate target arguments.
<NEBAP|work> using push with the ftp protocol automatically pushes only the history
<NEBAP|work> does it create a shared repo automatically?
<NEBAP|work> or is it still a standalone tree without the working tree?
<hmeland> No, but updating the working tree over ftp isn't done, due to it being hard to detect whether there would be any conflicts.
<NEBAP|work> k
<NEBAP|work> so using ftp the push destination is still a standalone tree?
<hmeland> Yes.  You could then later do "bzr update" in a shell on the target host to update the working tree.
<NEBAP|work> k
<NEBAP|work> no that was just for info :)
<NEBAP|work> just thinking which is the better solution, creating a shared repo and pushing to it
<hmeland> Whereas that wouldn't do anything in a branch in a tree-less repo.
<NEBAP|work> or deleting the working tree of the standalone puhs ..
<NEBAP|work> s/puhs/push
<NEBAP|work> would be good to offer an option to push without the working tree like "bzr push --no-trees"
<jam> morning all
<jam> fjalvingh: are you around?
<jam> vila: how's it going?
<vila> morning jam !
<fjalvingh> jam: morning, Jam
<NEBAP|work> jam: morning
<vila> going fine, but I reailzed time is running and I tsill haven't reviewed 1.19-merge_sort :-/
<jam> vila: I was wondering about that. as I made sure to submit it before you woke up, and yesterday you said "I'm ready to review" :)
<vila> jam: yeah, went into balancing --parallel=fork and ran into bumps... mutli-thread debug is so fun ;)
<vila> jam: and besides, when i said "ready to review", I had actually reviewed most of your commits, but you added ~15 more :-)
<vila> jam: overall you added new implementations in tsort, leaving the old ones without deprecating them, right ?
<vila> hmm, not really :-/
<jam> vila: I moved tsort.topo_sort, but not merge_sort
<jam> I don't want to implement 'mainline_revs'
<jam> and some other stuff
<jam> because it is cruft
<jam> And there is at least 1 place that needs to add a node to the graph
<jam> before calling merge_sort
<jam> so I need that functionality before I can completely deprecate the existing implementation.
<vila> yeah, re-reading your cover letter, sorry for the noise
<Stavros> hello
<Stavros> i have a bunch of commits in my repo which I did, but different computers show different names. can i change them?
<vila> abentley: welcome back !
<abentley> vila: Thanks!
<Stavros> any idea how i can change my email address retroactively in commits?
<vila> Stavros: short answer: you can't
<Stavros> aw
<Stavros> long answer?
<vila> there were talks about 3 distinct solutions (none fully available  yet AFAIK):
<vila> 1) use some variation of bzr-rebase
<vila> 2) handle some aliases in bzr so that the same user can be "credited" for all his emails
<vila> 3) fast-export, hack hack, fast-import (this is rude :)
<quicksilver> write a script which rebuilds your repo one commit at  atime
<quicksilver> saving commit messages but altering email addresses
<quicksilver> and also changing your boss's name to BADGER BADGER BADGER BADGER BADGER, just because you can.
<Stavros> hmm, can i export the repo in a format i can easily parse and substitute the emails?
<luks> which is what the fast-import/export method does
<Stavros> quicksilver: i am the boss :(
<Stavros> so i'll go with MUSHROOM
<vila> Stavros: LOL
<Stavros> what's fast-export/import, btw?
<Stavros> also, is bzr-rebase useful/mature/stable?
<luks> http://bazaar-vcs.org/BzrFastImport
<luks> and yes, it is
<vila> https://edge.launchpad.net/bzr-fastimport
<Stavros> oh aha, interesting
<Stavros> let me get that
<Stavros> hmm, i need to run something other than setup.py install?
<fjalvingh> Stavros: you might just do bzr branch lp:bzr-fastimport fastimport into your bzr plugins dir
<Stavros> ah right, thanks
<Stavros> how can i get the branch without the repo?
<fjalvingh> Stavros: lp: means get repo from Launchpad?
<Stavros> yes, i mean get just the "clean" copy, without the .bzr dir
<Stavros> i guess i can just delete it afterwards
<fjalvingh> Stavros: just remove the .bzr afterwards.
<Stavros> thanks
<fjalvingh> Stavros: It won't hurt though and you can easily update later on
<Stavros> that is true, i should redownload it
<vila> Stavros: or you can use 'bzr export' to get a clean tree
<fjalvingh> Stavros: just "bzr pull" inside the branch
<vila> Stavros: but why do you want that ?
<Stavros> vila: OCD :P
<vila> Stavros: ha, good, fine, no problem, JDI :)
<Stavros> what's jdi?
<Stavros> also, i figure i can do bzr co lp:bzr-fastimport and then bzr up whenever i want to update
<jam> Stavros: "just do it"
<Stavros> ah
<Stavros> hmm, this fast-export file is binary
<Stavros> i was hoping for base64 encoding or something
<Stavros> i can't edit this without breaking it..
<fjalvingh> Stavros: It is not really binary; it is text intermixed with blobs which can be binary
<Stavros> fjalvingh: yes, but editing will break the blobs
<fjalvingh> Stavros:  Only if you edit inside them
<Stavros> really? text editors can handle that sort of thing?
<Stavros> should i use vim?
<fjalvingh> Stavros: some can; you could also try something like sed or so
<Stavros> ah, that should work very well
<fjalvingh> Stavros: but before trying all this: be aware that this will make a new, idependent repo
<fjalvingh> Stavros: so if you have other branches lying around merges will no longer work
<Stavros> so i won't be able to push it to the parent repo any more?
<jam> Stavros: well, you could push --overwrite, but otherwise no
<fjalvingh> Stavros: only by overwriting.
<Stavros> hmm
<Stavros> that might be acceptable
<Stavros> i will try
<jam> Stavros: you basically say "this is the new ancestry, forget about the old"
<Stavros> ah
<Stavros> hmm
<fjalvingh> Stavros: and one other thing: if you have renames followed by edits in the same commit (something common in Java) import will probably fail..
<Stavros> hmm, that shouldn't be the case, thanks for the heads up though
<Stavros> it crashes with "cannot import name serializer", that's odd
<Tak> hrm, is it normal for a pull to show all pulled changes as conflicts?
<Stavros> Tak: not normal, but it can happen
<Stavros> if you changed things, that is
<igc> night
<fjalvingh> igc: Good night
<[1]reggie> bzr tag keeps giving me bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~mysql-clr-team/connectornet/6.1/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<Tak> well, yeah, they're valid changes from upstream, but all the conflicts are empty for tree, with stuff in merge-source
<Tak> so I'm not sure why they weren't just merged in
<[1]reggie> I've done bzr lp-login <my login name> and then done bzr push --remember lp:<lp home of project>
<[1]reggie> but bzr tag still is trying to use http instead of bzr+ssh
<[1]reggie> what am I doing wrong?
<Stavros> jesus, 1.17 is out? what am i doing with 1.13?
<[1]reggie> nm, got it working
<gus1> So I just upgraded to jaunty ppa bzr (from normal jaunty bzr) and my stacked bzr-svn repo is complaining with "ERROR: SvnRepository(...) is not compatible with KnitPackRepository(...) different serializers".   Is that some known problem?
<Etenil> Hello there
<Etenil> I'm having a small problem with my repository
<Etenil> I have a base code in the root directory
<Etenil> and several independant applications that rely on the base code in sub-folders
<Etenil> basically, I'd like to version the root directory and each sub-directory independently
<Etenil> do you know how I could proceed?
<fjalvingh> Etenil: You cannot, really.
<Etenil> fjalvingh, really??
<Etenil> what should I do then?
<Etenil> move my applications out of the common codebase?
<fjalvingh> Etenil: In time there will be the nested trees extension. But it's progress is slow.
<fjalvingh> What I did is just not to manage the root itself.
<Etenil> yeah, that's what I did so far, but I need to have at least `index.php' in the root folder
<fjalvingh> I created separate repositories/branches for the shared projects
<fjalvingh> Etenil: Hmm.. It might be that you can just branch /inside/ the root.
<fjalvingh> So there are separate branches (not related) and the one is /inside/ the other
<fjalvingh> The outer one has the directory for the inner one as .bzrignored
<fjalvingh> Limitation would be that the inner branch always is a single directory which in turn contains the other dirs
<Etenil> oh, so I could ignore each sub-folder that contains an app
<fjalvingh> There is also something called the "config" extension/plugin but I don't use that one.
<jenred> hello! Is it possible to revert a merge that hasn't been committed?
<jenred> and if so how thx
<beuno> jenred, yes, but theres no way to distinguish it from the changed you had that weren't committed yet (if you had any)
<jenred> so I merged 2 branches and now I want to drop the branch that I just merged b/c their are too many conflicts
<jenred> is there anything like a "unmerge"
<beuno> jenred, jsut "bzr revert" should do it
<jenred> ok I think that worked thanks!
<garyvdm> jam: What does the "known" in KnownGraph refer to?
<jam> garyvdm: we know the full ancestry
<jam> versus Graph which tries to know as little as possible
<garyvdm> jam: I see - So in that case It will work nicely for qlog :-)
<jam> yep
<vila> garyvdm: but keep in mind that it's a step (a significant one, but a step anyway), the final target is to make it lazy in the end :)
<garyvdm> vila: Yes
<garyvdm> jam, vila: Would a KnowGraph be mutable? I think for qlog to be lazy, It's going to run merge_sort every time it loads more of the graph.
<jam> KnownGraph is not currently mutable
<garyvdm> But it will have all of the graph that it wants merge_sort to look at loaded
<vila> garyvdm: no, it's not intended to be mutable
<jam> I plan to allow it to add new nodes on the end, probably not in the middle
<garyvdm> jam: which end?
<jam> also, the time for "KG.merge_sort()" is around 40ms for a bzr.dev tree
<vila> garyvdm: I call it FullyKnownGraph in my head myself
<jam> garyvdm: new revs, not old ones
<garyvdm> jam: so if I load bits of the graph, just create a new KG every time some more is loaded?
<garyvdm> Or us the old merge sort?
<garyvdm> *ues
<garyvdm> *use
<jam> merge_sort won't give you the right answers without the whole graph
<jam> new or old
<jam> it needs all ancestors to know if a revision was merged earlier than now
<garyvdm> jam: I plan to only do this if bzr-historycache is available. I will use merge_sort to just give me the info I need to lay out the graph, and get the revno from bzr-historycache.
<jam> garyvdm: it gives wrong answers for the graph as well
<jam> I can give specifics though it takes some drawing
<garyvdm> If historycache is not available, I will only load the graph in 2 stages: mainline, and the whole graph
<garyvdm> jam: in the order?
<garyvdm> Loading the graph lazy is very complex!
<jam> so, if you have a long lived branch, that gets merged at rev 10 and rev 20
<jam> the revs merged into 10 will show up underneath 20
<jam> if you haven't loaded the ancestry from 10
<jam> to know that they were first merged there
<garyvdm> jam: I see. And there is know way to ensure that for rev a, you have loaded all the revisions that have rev a as a parent (other than loading everything :-()
<jam> well there are ways, but nothing we store currently
 * vila EODing by shaving 30% of selftest --parallel=fork execution time, YES :-)
<jam> gdfo is something that might work well here
 * garyvdm goes to read up on what gdfo is
<jam> Greatest Distance From Origin
<jam> it is part of the KnownGraph code
<LarstiQ> not to be confused with Get The F Offline
<jam> basically rev.gdfo = max(parents.gdfo) + 1
<jam> or Get The F Out
<jam> but that is G*t*Fo
<LarstiQ> jam: which is phonetically rather close when slurred in Dutch ;)
<jam> it is pretty close in american english, too :)
<jam> garyvdm: the idea is that if rev1.gdfo >= rev2.gdfo you know that rev1 cannot be an ancestor of rev2
<jam> we use it for the KnownGraph.heads() work
 * garyvdm is digesting..
<jam> anyway, it allows you to load some of the graph
<jam> until you reach tips that have gdfo <= the one you have now
<jam> since you know that the current one cannot be an ancestor of the others
<jam> the main problem
<jam> is that you need the whole graph to *compute* gdfo in the first place
<jam> vila is trying to figure out how to record it properly
<jam> as it interacts with ghosts ... poorly
<garyvdm> And would need to be recomputed on merge?
<jam> no
<jam> the new revs change
<jam> but gdfo is stable as long as *ancestors* don't change
<garyvdm> I see
<garyvdm> So I should hold of trying to make qlog graph lazy until that is done?
<jam> i think you could lazily load a lot of things like revision info (I think you already do)
<jam> but I wouldn't try to lazy load the graph itself
<jam> I'll also note
<jam> that in current circumstances, computing a node accurately seemed to take about 50% of the graph of bzr.dev anyway except in trivial cases
<jam> stuff like 'brisbane-core' requires a lot of history to be searched
<jam> though potentially that is easier with gdfo... not sure
<jam> oh, and we have several cases where we merge in a plugin
<jam> and a plugin's first rev is gdfo == 1
<jam> so we have to load the wholegraph again
<jam> that said...
<jam> I made loading the whole graph significantly cheaper
<jam> OOo went from 33s => 10s
<jam> bzr.dev from 1.5s => 300ms
<garyvdm> Wow!
<garyvdm> This was with KnownGraph?
<garyvdm> Will that make it into 2.0?
<garyvdm> jam: Yes - revisions are only loaded if they appear on screen. (Or if you do a search, all revisions are load.)
<jam> just landed in bzr.dev
<garyvdm> jam: :-)
<jam> and merge sort is about 3x faster as well
<jam> well, 8x if you don't count the time to build the KnownGraph
<lifeless> moin
<lifeless> jam: I'm quite worried that this will regress shared repo cases
<jam> lifeless: it does the same work we do now, just in a tighter loop
<lifeless> jam: oh cool, so it doesn't load unreferenced nodes?
<jam> lifeless: no
<jam> it walks the ancestry, and just loops on ancestors present on the current btree page
<lifeless> argh double negatives ;)
<lifeless> jam: read your reply on the bug; thats really good
<lifeless> jam: around?
<jam> yeah, for now
<lifeless> I need a quick incremental review, in about 3 minutes
<lifeless> for landing 2a default
<jam> k
<lifeless> its stacking [again]
<RenatoCaelum> verterok: hi
<james_w> Is there a value I could cache to know if the contents of the working tree have changed at all?
<james_w> does the wt have a testament?
<lifeless> james_w: tree.has_changes()
<james_w> but I don't have the old tree
<james_w> I was just watching my commit hook run the tests after I had just done a full test suite run
<lifeless> I'll need more context here
<james_w> it would be nice if my test runner could write something about the state out
<james_w> then the hook could not bother running if the tree it was committing matched that state
<james_w> would also solve an issue I have with package maintenance
<lifeless> you can make a testament of any inventory; however the working tree inventory may not match disk at all
<james_w> caching?
<lifeless> reality
<james_w> or wouldn't match the inventory of the revision tree it became?
<lifeless> neither
<james_w> ok
<james_w> I'll ponder some more
<lifeless> fields like size
<lifeless> sha1 etc
<lifeless> in a working inventory aren't synced with disk, and even if they were they could become dated asynchronously
<james_w> well, it could force a disk scan couldn't it?
<james_w> it's racy, but...
<lifeless> even if it did, it can skew
<lifeless> jam: ugh, I'm having to fix a totally unrelated bug to make this work :(
<lifeless> jam: how would you feel about me landing this with the test_repository_clone_preserves.. test made KnownFailure
<jam> james_w: not to mention partial commits, etc
<jam> lifeless: "landing this" ?
<lifeless> default 2a
<jam> I don't see a 'test_repository_clone_preserves", do you mean "per_workingtree...test_clone_preserves" ?
<lifeless> line 944 in per_repo/test_repo
<james_w> jam: yeah, I would compare to the testament of the revision tree being committed, which should account for that sort of thing
<lifeless> james_w: myself, I'd made the test suite faster to run
<jam> :)
<jam> james_w: I think you could generate a testament from the WT, but the internal code wouldn't do that.
<james_w> I'm just seeing a version tracking system on one hand, and repeated work from not knowing whether something has changed on the other
<jam> easier to stage a commit, and then validate off of that revision
<lifeless> james_w: for an off the wall approach
<lifeless> james_w: make all your test runs do a commit
<lifeless> and uncommit if they fail
<james_w> could work :-)
<james_w> doesn't really help the packaging case, but neat idea anyway
<james_w> as for faster to run, that solves it for one project, but not other cases
<jam> lifeless: so I've at least tracked down the test. How is it failing?
<jam> as it is actually a fairly common case we've run into because "bzr upgrade repo" doesn't upgrade the branches
<lifeless> jam: firstly the whole thing is testing off stuff
<james_w> thanks for your time
<lifeless>         """Cloning an unstackable branch format to a somewhere with a default
<lifeless>         stack-on stack-on branch upgrades branch and repo to match the target
<lifeless>         and honour the policy.
<lifeless> """
<lifeless> my updated docstring
<jam> lifeless: what would happen is your local repo was stackable, but the branch format was too old
<jam> then pushing that to lp would fail
<jam> because it tried to auto-upgrade the repo to abad format
<lifeless> yes
<lifeless> but
<lifeless> that is still broken in trunk
<lifeless> its just that the test happens to fail closed
<lifeless> what we want is that when there is a policy pointing at a stackable branch, and the source repo-or-branch isn't stackable, that its upgraded to match
<lifeless> further, when the source repo is incompatible (e.g. 2a) and the stacked-on is (say)  1.9, we want to not stack
<lifeless> but there is a separate bug that it currently aborts
<jam> so how is it failing at this point? versus the test passing today
<lifeless> the test is changed slightly in my branch, but not enough
<lifeless> the thing is that its broken today
<lifeless> we actually use the default format /somewhere/ and so the target is often unstackable
<lifeless> and the test doesn't notice
<lifeless> when the default is changed, we end up with stackable much more often
<lifeless> and the test against whether repo is stackable suddenly blows up
<jam> lifeless: so last I checked, BzrDir.initialize_on_transport_ex() would create the repo format you requested, but always uses the default branch format.
<lifeless> well, init_ex doesn't make a branch
<jam> lifeless: it *does* use the default branch for the format and stacking checks
<jam> which was a source of bogus "this format doesn't support stacking" messages in the past
<lifeless> yes
<lifeless> so, there is a broken code path
<lifeless> we can either fix it, then land this default branch. or vice verca :)
<lifeless> so
<lifeless> specifically, there are 7 formats that don't update
<lifeless> don't upgrade
<lifeless> and the test was simply not noticing that they don't
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit3)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit4)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack1)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack4)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnitPack3)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormatKnit1)
<lifeless> FAIL: per_repository.test_repository.TestRepository.test_clone_stacking_policy_upgrades(RepositoryFormat7)
<jam> lifeless: so I'm not going to make you block forever on it. But I'll note things tend not to get fixed once they are marked KnownFailure
<jam> I suppose for my balance point.... I'd probably go ahead
<lifeless> I think I have a hacked up version
<lifeless> its a bit heinous
<lifeless> jam: re: KF - I know, but we can file bugs that are critical :)
<lifeless> jam:
<lifeless> http://paste.ubuntu.com/255402/
<lifeless> thats the change vs the branch you reviewed last night.
<lifeless> I think it captures what we want more accurately.
<jam> lifeless: you've got some serious typos in the docstring, one not introduced by you
<jam> "to a somewhere"
<jam> and then "stack-on stack-on branch"
<lifeless> fixed
<jam> the "if stack_on_format in... elif..." seems like it could really use a final "else" clause causing an exception
<lifeless> mm
<lifeless> you need a long list of formats that just work if you do that
<jam> I don't quite understand why you don't just grab the BzrDir format and pass that in
<jam> I suppose you are intentionally using a diff format?
<lifeless> yes
<lifeless> a stackable one matching the serializer
<lifeless> the unlisted formats are already stackable
<lifeless> and thus its a no-op really.
<jam> lifeless: k, probably a comment then
<lifeless> done
<jam> lifeless: good enough then
<lifeless> DoIt?
<jam> yep
<lifeless> thanks!
<goneri> igc: Hi! Can I have you opinion on the branch I did against bzr-fastexport to fix #347729 ?
<lifeless> igc s likely still asleep
<lifeless> give him a couple of hours
<goneri> lifeless: oh ok :)
<lifeless> \o/ onto ascii
#bzr 2009-08-19
<igc> hi all
<igc> hi goneri, lifeless
<igc> goneri: I'll take a look today (hopefully)
<goneri> igc: thanks, this bug is a blocker for git-bzr inclusion in Debian
<igc> goneri: ah - ok. Thanks for the patch and for hassling me
<goneri> igc: my pleasure :)
<gus1> So I just upgraded to jaunty ppa bzr (from normal jaunty bzr) and my stacked bzr-svn repo is complaining with "ERROR: SvnRepository(...) is not compatible with KnitPackRepository(...) different serializers".   Is that some known problem?
<lifeless> gus1: I don't think stacking bzr on svn has ever really worked
<gus1> :(  it ~worked on the previous version.  Now I have to downgrade before I can retrieve a simple diff.
<gus1> upstream has a large svn repo so a non-stacked branch is unfeasible.
<lifeless> uhm
<lifeless> file a bug in bzr-svn then
<lifeless> if you could
<gus1> somewhere in launchpad?
<lifeless> yes :)
<gus1> will do.
<AfC> lifeless: you said "2a now default" but is bzr.dev itself in 2a?
<AfC> lifeless: I just did a `bzr pull` on that branch and was surprised it worked.
<james_w> no, 2a is default
<AfC> (I was expecting it to: 1. fail, then I'd 2. upgrade, then 3. pull would pass)
<james_w> bzr.dev doesn't use its own default yet
<AfC> hm
<lifeless> we haven't migrated yet is all.
<lifeless> we want to be dogfooding
<lifeless> but its orthogonal to getting bugs related to doing a 2.0 release done.
<AfC> hm
<AfC> sorry, not sure I buy that.
<AfC> but that's your call, of course.
<lifeless> there is a bug; its assigned to LarstiQ; you're welcome to comment on it
<AfC> There are certainly many many other things in your lovely work besides repository format iteration.
<AfC> Mind, I feel the same way about you guys not using bzr://
<lifeless> we use the smart server every day
<lifeless> but there is the same gap between dev and deployment
<AfC> lifeless: you mean bzr+ssh://
<AfC> lifeless: I'm talking about bzr in daemon mode.
<lifeless> using bzr:// specifically - well, it doesn't meet our use cases :)
<lifeless> bbiab
<AfC> see ya
<lifeless> back
 * igc lunch
<vila> hi all
 * vila pesters about kernel updates (at least against the daily ones :-)
<vila> lifeless: if you're still around, I'd like a little chat about .progress(), I found *one* way to make it work with --parallel, but I'm not sure it's correct
<lifeless> SET -> CUR? yes, its correct.
<vila> no, not that part
<vila> I had to implement .progress in testtools and that's where I'm unclear about whether testtools can have a subunit dependency..
<lifeless> optional I guess
<vila> http://paste.ubuntu.com/255578/
<vila> of course that '0' should be subunit.PROGRESS_SET
<vila> so more context: testresult modification is for ThreadsafeForwardingResult
<lifeless> yes
<vila> and testsuite is for ConcurrentTestSuite
<vila> or...
<lifeless> the change to init isn't needed
<lifeless> erm
<lifeless> it is, sorry.
<lifeless> but if we're doing it right
<lifeless> I would just implement progress()
<lifeless> rather than counting can calling
<lifeless> *counting and calling*
<vila> ThreadsafeForwardingResult should become an attribute of ConccurrentTestSuite so that bzr can override it and just defines .progress there...
<lifeless> huh?
<lifeless> I think you're smoking something at this point
<vila> the root problem is that TFS don't implement .progress
<lifeless> TFR should combine progress data
<vila> :-D
<lifeless> CTS shouldn't need to do anything
<lifeless> neither call progress nor implement it
<vila> some one has to relay the calls
<lifeless> yes, the result object
<vila> that's TFR
<vila> then someone has to SET the number of tests
<lifeless> no
<lifeless> thats what the individual results do back in bzr
<vila> show them :)
<lifeless> and why I asked you to insert the decorator before the CTS decorator
<lifeless> and the result objects show them, which is why TFR has to combine and forward
<vila> still doesn't work... except if all TestInOtherProcess do the call, all setting the same nb tests, it worked, but is a bit ugly
<vila> ha, well, wait a minute, I need to explain more
<vila> I change the way --parallel=fork works to get a better balancing
<vila> but now, instead of creating n slices of the test suite upfront, I create the slices on demand,
<vila> so the TIOP objects doesn't know anymore how many tests there will be (in total), they learn about them one slice at a time
<vila> lifeless: so there is no more point where a single test.run(result) is called which knows about the whole test suite, there are 'concurrency' not one, so either they all call progress(nb_test, SET) or CTS calls it once
<vila> Does that make sense ?
<lifeless> what drives demand?
<vila> displaying [1234/6801 in 19s] instead of [1234 in 19s]
<lifeless> yes, but what drives your on demand slicing thing
<vila> 30% less execution time for a full run ?
<lifeless> _the logic vila_
<vila> ha, TesttInOtherProcess now start a new process for a given slice, all TIOP objects synchronize on a semaphore to get slices out of the test suite
<lifeless> whats a slice
<vila> tests[first:last]
<lifeless> is tests flat?
<vila> yes
<vila> well, flatten by tests = list(iter_suite_tests(suite))
<lifeless> so you know the count
<vila> yes
<lifeless> how many TIOP's are there?
<vila> osutils.local_concurrency
<lifeless> ok
<lifeless> so, does the thing that creates TIOPs know the count?
<vila> yes, but not the result object
<vila> yes, but it doesn't know not the result object
<vila> yes, but it doesn't know the result object
<vila> it's in fork_for_tests
<lifeless> which creates the suite
<lifeless> you should decorate the suite
<lifeless> erm
<lifeless> no
<lifeless> you want to decorate the suite, and decorate the result that the suite is run with
<lifeless> the first decorator will issue the count you know
<lifeless> the second will eat progress() calls so that the external counts are not passed forward
<vila> right, except that the result is TFR, created by CTS hence I can't decorate it, looks like we are on the same page now
<lifeless> you don't need to decorate tfr
<vila> you just said so ...
<lifeless> no, I said you need to decorate the result you're run with
<lifeless> you'll end up with
<lifeless> BzrTestResult <- ProgressHider <- TFR
<vila> You mean BZRTransformingResult ? And what is ProgressHider ? The misterious culprit ?
<lifeless> yes
<lifeless> you need:
<lifeless> a test result filter to stop progress data from children
<lifeless> thats all
<vila> wow, you're telling me that to have progress reporting I need to stop progress data, let me have one more coffee :)
<lifeless> yes, because you want to do a global optimisation (your TIOPs)
<vila> ok, that means I may have been on the right path, yesterday but failed to realize it,
<vila> I think I will make a first submission without the progress part and add it in another submission, to make things clearer
<poolie> hi vila
<vila> hi poolie !
<benchik> hello
<benchik> i'm trying to bzr merge but i get : bzr: ERROR: No location specified or remembered
<benchik> please help
<LarstiQ> benchik: what do you want to merge from?
<LarstiQ> benchik: `bzr merge location/to/branch/to/merge/from`
<benchik> LarstiQ: the cwd
<LarstiQ> benchik: ok, what do you want to merge in to the cwd?
<benchik> LarstiQ: i always did bzr merge from a dir where i have the sourcecode and it worked, today it doesn'
<benchik> t
<LarstiQ> benchik: that must have been a different dir
<benchik> nope
<LarstiQ> benchik: as the message mentions, `bzr merge` either takes a location to merge into your current branch, or it takes the remembered location
<LarstiQ> benchik: which in this case is not set
<benchik> LarstiQ: it was set before. don't know what happened
<benchik> LarstiQ: ok i gave it the full path and it worked but i wonder why did it forget the path
<LarstiQ> benchik: possible reasons: 1) it got removed from .bzr/branch/branch.conf 2) it got removed from ~/.bazaar/locations.conf, 3) harddisk failure
<LarstiQ> benchik: or 4) this is not the branch you think it i
<LarstiQ> s
<benchik> i think it's the former few
 * igc dinner
<vila> hey LarstiQ !
<LarstiQ> hey vila :)
<matkor> Hi, I get bzr internal error( 1.8 and 1.15) when try added files having enter in their name like: antique^J.py
<matkor> when trying to commit such added files to be strict
<matkor> should I report it as bug ?
<LarstiQ> matkor: yes
<poolie> matkor: i think it's a known bug
<poolie> you should be able to find it then
<poolie> sorry
<matkor> poolie: Yes, I found it .. so not reporting again, can I somehow bump its priority ? - seems it's lasting for a long time now ...
<poolie> you can click 'affects me too' or comment on it
<moldy> hi
<moldy> how do i make bzr forget the submit branch?
<moldy> ah, never mind
<vila> morning jam :)
<jam> morning vila
<jam> I'm a little slow today, have a mild fever
<vila> ow
<lifeless> jam: rest up
<lifeless> health++
<jam> lifeless: thanks.
<vila> jam: just a small question: am I correct in reading plugin.get_standard_plugin_path that windows has no concept of "site" plugins ? Only bzrlib/plugins and $HOME/plugins right ?
<jam> what are you still doing up?
<jam> vila: correct
<vila> jam: good, go rest now :)
<vila> jam: or land 1.19-kg-sorted, whatever is better for your morale :D
<lifeless> jam: just finished raiding
<jam> lifeless: ah, I hope it went well. I assume you guys are in ToC?
<lifeless> tonight was a ulduar run, but yeah, wehave toc full cleared so far each week
<vila> toc ?
<jam> vila: Trial of Champions, IIRC. The current last-raid in World of Warcraft
<vila> haa, ok :)
 * lifeless sleeps
<vila> nothing related to cObsessive-Compulsive Disorder  (aka toc in french :-)
<igc> night all
<kiko> hey, is there anyone around that knows a bit of bzr-git?
<kiko> http://launchpadlibrarian.net/30506243/windmill-trunk-log.txt
<james_w> kiko: hey, rockstar filed that one as bug 414918
<ubottu> Launchpad bug 414918 in bzr-git "Pitivi import fails" [Undecided,New] https://launchpad.net/bugs/414918
<james_w> doesn't help you much though
<rockstar> kiko, I'm not sure why it's failing, but I suspect it might have been a revision generated by an old git
<saedelaere> hi
<saedelaere> is there something like cia.vc that can be used with bazaar? i have a bazaar repo at sourceforge.net. Whenever someone makes a commit i want a message send to my irc channel.
<LarstiQ> saedelaere: there is a cia plugin
<saedelaere> and does this plugin work with sourceforge?
<LarstiQ> I have no idea on what sf does
<saedelaere> ok thanks
<saedelaere> perhaps i can get it to work
<LarstiQ> saedelaere: you can trigger it locally instead of on sf
<saedelaere> http://people.samba.org/bzr/jelmer/bzr-cia/trunk/
<saedelaere> damn the directory is empty
<luks> it's a bzr branch :)
<luks> I thought anybody using bzr has to be used to empty directories :)
<saedelaere> lol ok now i see :)
<vila> wow, who said downloads were hard to find at https://edge.launchpad.net/bzr ? :-D
<beuno> vila, I did
<beuno> and I fixed it!
<beuno> :)
<vila> beuno: woohoo, that's a change for sure :-)
<mtaylor> lifeless: you still awake?
<mtaylor> oh, hrm, probably not
<mtaylor> anybody around who can point me to info on subtree support stuff?
<vila> mtaylor: try abentley-lunch (after his lunch that is :)
<mtaylor> vila: sweet. thanks
<mtaylor> abentley-lunch: whenever you aren't eating lunch...
<vila> mtaylor: as appetizer read: http://bazaar-vcs.org/NestedTreesDesign
<abentley> mtaylor: The subtree stuff is not ready for use yet.
<lifeless> moin
<hno> Is there an easy command for making a branch for the current uncommitted changes? I.e. working on something which felt quick at start and realizing it was much larger and needs a branch of it's own for a while?
<hno> I know shelve/unshelve but it's not quite the same thing..
<LarstiQ> hno: you can try a combination of bzr branch . ../feature; cd ../feature; bzr merge --uncommitted ../trunk
<lifeless> hno: so you're already writing some code
<lifeless> hno: and you want to turn it into a branch?
<hno> LarstiQ: Thanks.. could obviously be improved a bit..
<hno> lifeless: Yes.
<lifeless> bzr switch -b ../newbranch
<hno> lifeless: bzr: ERROR: no such option: -b
<lifeless> well, you have something to look forward too in a newwer bzr:)
<hno> lifeless: 1.18?
<hno> lifeless: Hmm.. ChangeLog says -b was added in 1.17, but I am using 1.17..
<lifeless> could be a plugin intercerpting it
<hno> lifeless: Only plugin I have is bzrtools I think..
<LarstiQ> lifeless: or a misattribution
<lifeless> try bzr help --no-plugins switch
<hno> lifeless: Not mentioned.
<lifeless> ok
<lifeless> docs are wrong then :(
<lifeless> where do you see 1.17 mentioned for it?
<fullermd> It's under the 1.17 heading in NEWS.
<lifeless> ugh
<hno> Why is there a 1.17 heading in the middle of NEWS for 1.18rc1?
<lifeless> hno: is 1.17 repeated?
<Noldorin> hi lifeless
<lifeless> hi Noldorin
<Noldorin> lifeless: i got a reply back from the server admin
<Noldorin> http://pastebin.ca/1535577
<Noldorin> i instructed him to attempt pushing a bzr repo
<Noldorin> but he seemed to ignore that :S
<lifeless> its definitely not operating normally for win2003 server
<Noldorin> heh
<Noldorin> yeah
<Noldorin> but the thing is, a simple rename does work fine
<lifeless> we have other users using that platform without the issues you've reported
<Noldorin> so it's clearly the sequence of commands that causes the problem
<Noldorin> yeah
<Noldorin> i know
<lifeless> here's what I'd do
<lifeless> there is a built in ftp client in windows
<lifeless> if you start cmd.exe
<lifeless> then type 'ftp'
<Noldorin> yeah. there's one in windows explorer too
<Noldorin> ok
<lifeless> you could use the trace we made to create a series of commands
<lifeless> put that in a text document
<lifeless> then paste it into that window
<lifeless> and the ftp client will run them
<lifeless> I would include every command
<Noldorin> yeah, that's what i was going to suggest to
<lifeless> and the commands that put files - you'll need to create files on disk locally that you can put up
<Noldorin> so i'll attempt that right now
<Noldorin> maybe that will be clearer to the admin as well
<Noldorin> lifeless: should i use the dhtransport log for a push using the unmodified bzr program?
<lifeless> Noldorin: that would make sense to me
<Noldorin> ok
<lifeless> skip the chmods as it happens without them
<Noldorin> yeah
<Noldorin> and i'll just replicate the appropiate filesystem structure for the repo to test
<hno> lifeless: seems so, with some changes and a different heading than what's used in 1.17... Would pull up a launchpad diff url if launchpad worked proper...
<lifeless> :(
<hno> launchpad worked some minutes ago, but now I just get redirected to the main page when trying to browse revisions from https://code.launchpad.net/~bzr-pqm/bzr/1.18
 * Noldorin gets confused
 * hno is often confused, but right now mostly tired.
<Noldorin> heh
<Noldorin> i'm probably confused mainly because i'm tired
<Noldorin> and because windows ftp servers are god awful
<hno> Are they? Last time I accessed one I din't have to notice apart from slightly different directory listing than usual..
<Noldorin> well my one is at least
<Noldorin> lifeless will verify that :)
<Noldorin> lifeless: any chance i could give you an ftp login to my server so you could try a few things out? (i.e. reproducing the issue manually)
<Noldorin> i just feel like we're spending more time than we should with me pestering you about what i need to do next...
<lifeless> hno: we have one that claims a rename worked but prevents renaming a different dir to the original path
<lifeless> mv foo bar
<lifeless> mv quux foo *boom*
<lifeless> but the first command doesn't error, and you can even rm bar/gam; rmd bar before the second mv
<Noldorin> lifeless: judging by the log, bzr doesn't seem to be understanding the error messages the ftp server replies with
<denys> I am working on a STARTTLS-type extension for bzr:// (to complement my bzrs:// merge proposal) --- it is easy on the client side, but on the server side requests are executed at a level that knows nothing about the socket used.  I am unsure how to proceed (elegantly).  any suggestions?
<lifeless> Noldorin: the server is giving an error?
<lifeless> Noldorin: could you put your test case and the output you get in the bug please ;)
<Noldorin> well if you look at the -dtransport log, bzr complains about not being able to parse the server error response
<Noldorin> the one i showed you last time
<lifeless> Noldorin: hmm, I didn't see that.
<lifeless> Noldorin: we should still be treating it as an error ...
<Noldorin> yeah..
<Noldorin> you see it now?
<poolie> denys: hm it's a good question
<poolie> i would say that although it's a higher level, there probably is an object chain that you can walk back up to the medium
<poolie> or if not, it might be tasteful to add one
<denys> poolie: not from the request
<poolie> jam, are you still around? want to catch up?
<lifeless> denys: I'd be inclined to do TLS by just opening with an SSL handshake
<poolie> i mean it is inherently a kind of inversion of control, to have a higher-level command affect the layer it's running across
<lifeless> the server can decide that it doesn't look like a normal handshake and switch to it.
<poolie> lifeless: just have the server say 'oh that looks like ssl'?
<lifeless> yes
<lifeless> they aren't confusable AFAIK :)
<poolie> mm
<poolie> that could be cleaner
<poolie> iirc you disliked the idea of it just detecting http in the same way though?
<lifeless> HTTP clients don't know how to handle an older version of our server
<lifeless> browsers specifically
<denys> I thought it would be nice to negotiate the encryption wanted/supported
<lifeless> denys: doesn't SSL do that itself?
<lifeless> denys: also, any negotiation done in cleartext can't be trusted, it could be attacked to get a lower level via MITM
<denys> lifeless: no. there are different incompatible SSL and tthen there TSL and then there is what ever they'll invent next
<lifeless> poolie: I do have mixed feelings about multiple protocols on one socket in general; but not 'its always bad' or 'its always good' :)
<denys> lifeless: that's a point I have been worrying about
<denys> my plan was to start with the lowest common denonminator
<denys> add negitiation latter if wanted
<denys> the lowest common denominator is already in my ssl patch - I just want to make it opportunistic
<denys> I have code to make the decision in authentication.conf
<denys> the point is that you can contact a regular bzr server and then cause it to upgrade the encryption level to whatever level you prefer,   server authentication can be added on top of that for python 1.6.
<poolie> right, getting to native authentication would be great
<poolie> and
<poolie> well, now actually
<poolie> to be a bit more specific
<poolie> authentication and encryption that don't rely on OS accounts or setting up a separate server or client would be great
<poolie> that doesn't necessarily mean it needs to be within the bzr protocol
<denys> that's what I want
<poolie> perhaps we should do both of them by acting as an ssh client and server?
<denys> I want to explore te
<denys> the bzr server option
<denys> many admins will never agree to give external ssh accounts
<denys> not in french universities anyway :-(
<poolie> i'm suggesting that you run
<poolie> 'bzr serve --ssh'
<poolie> and it listens on some port
<poolie> and authenticates you against a bzr-specific database of accounts and keys or passwords
<poolie> using paramiko
<denys> I don't want to do something this specific.  I prefer to setup a framework where arbitrary authentication methods can be setup.
<Noldorin> lifeless: so would an ftp login to my server be of some use to you?
<Noldorin> just for a bit of testing
<denys> a bit like PAM, but simple instead
<poolie> ok
<poolie> you realize there's some scope for that within ssh?
<poolie> i'm just thinking: there's already a protocol that lets you negotiate encryption and authentication
<poolie> maybe we should use it
<lifeless> denys: a custom ssh server will perform better than https; theres less restrictions and overhead in the way we work over it
<poolie> i think he's running bzr+ssl
<poolie> a la stunnel
<lifeless> oh hmm
<lifeless> that should be equivalent
<denys> yes, but ssh needs an account on the target machine and some admins will NEVER allow it.  I want another degree of freedom.
<lifeless> denys: ssh doesn't ;)
<lifeless> denys: launchpads ssh server doesn't use local accounts, nor would what poolie suggested
<poolie> denys: the thing is: OpenSSH requires an OS account
<lifeless> "opensshd" uses the system account db, but there are pure python ssh servere implementations
<poolie> jinx
<denys> you need some account, and then you play games with different connections
<poolie> well
<denys> that's never going to fly for me
<poolie> actually i don't think we're understanding each other
<poolie> what you're talking about is, I think: I have one account on a server, I start a process there listening on a port, then people can connect to it, authenticate, and do stuff?
<denys> I have been working 3 years to get some sort of external VCS access for our univ.  It's really difficult to get things through the administrative hurdles.
<poolie> i'm suggesting just the same architecture except that the protocol encoding would be that specified by the SSH protocol
<Noldorin> lifeless: ?
<lifeless> Noldorin: ?
<Noldorin> lifeless: see my previous message :)
<lifeless> Noldorin: I'm still very focused on our 2.0 release; I doubt I'll have time to personally test this for a few weeks.
<lifeless> Noldorin: I can keep giving you guidance, but for now thats about it.
<Noldorin> ok, fair enough
<poolie> denys: do you see what i mean?
<poolie> i really do want to support your case of having sysadmins who aren't going to help
<denys> poolie: this is not helping me.  I would like to know how to plug an encryption upgrade command into the bzr server.
<poolie> i think you should do that by making connections from the request object up to the medium
<poolie> and then you can call along them from the request handler to say 'start encrypting now'
<poolie> but i'm kind of confused because i don't understand why that doesn't help
<poolie> the thing about running the ssh protocol
<Noldorin> lifeless: was wondering if i could get bzr to print out the exact ftp commands used in its log
<denys> it doesn't help because the request object has NO references to anything above.
<lifeless> Noldorin: edit ftp/__init__.py
<lifeless> denys: poolie: I think you're talking past each other
<denys> there is the do method and that's is
<poolie> Noldorin: if you do that and make it turn on by -Dftp (see debug_flags) that would be nice to merge
<poolie> lifeless: i think so too :-(
<lifeless> denys: I think you're talking about where to write some specific code.
<denys> lifeless: probably
<Noldorin> poolie: could do :)
<lifeless> poolie: I think you're talking about the design for getting encryption hooked into bzr's server without needing OS configuration
<poolie> yes, i am
<denys> poolie: you should approve my ssl patch then ;-)
<poolie> well, i'm trying to answer the first one too, or assure denys that's also possible
<lifeless> my take on this is:
<lifeless> denys: you can probably write an upgrade command for the smart server, but it may be a bit ugly. It would be cleaner to do encryption right up-front if possible. Poolie wants to talk about how that might look.
<denys> lifeless: I have already done encryption up front - see my proposal on lp
<lifeless> yup, which is getting reviewed and polished ;)
<denys> I wanted to also provide an upgrade path for a more traditional connection
<lifeless> denys: what does that offer over the ssl support ?
<denys> you can connect to a normal bzr server and demand an ecnryption upgrade - same advantages as STARTTLS for other protocols
<lifeless> denys: I don't really get the advantage; you connect to a port and you get encryption, either way.
<denys> its the same port!
<fullermd> For one thing, it saves having to juggle multiple ports.
<lifeless> denys: you don't need an upgrade command to do it on the same port
<denys> lifeless: maybe not. but it seemed simplest to me, with a possibility to negotiate the type of encryption.
<lifeless> we've just recently had a mammoth thread on the squid dev list about upgrade: and websockets
<lifeless> simple often isn't ;)
<lifeless> anyhow
<poolie> it seems potentially insecure
<poolie> easy to make a mistake about whether you really got a strong connection
<lifeless> so conceptual issues with having such a command:
<lifeless>  - how will it behave in half duplex connections?
<lifeless>    that is, if done on an http smart server, will it work, or claim to work and break, or just break?
<poolie> igc: did you move some of the doc files into _static?
<poolie> i think that might account for the broken links just posted about
<lifeless>  - what happens to the framing for the end of the current request/response? How do we make sure the wire is clean/we don't have any noise in the link
<denys> I think you guys are asking the wrong questions. there is a basic level of encryption: that's what available portably in python. higher levels could then be negotiated.
<poolie> hm
<poolie> what question do you think we're asking?
<poolie> it's true that ssl (usually) ships with python and paramiko does not
#bzr 2009-08-20
<poolie> but i'm ok with making it a dependency of bzr, we don't aspire to have every feature working on a bare python install
<denys> with a _bare_ install, I can give you encrypted bzr server connections
<denys> surely, that's an improvement (even if minute)
<poolie> so is that the main difference in your view?
<denys> yes - so far, it is something small that improves security and THEN makes possible authentication over an encrypted channel
<dash> i'm using bzr 1.17 and after doing 'bzr shelve' I get this: "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-5')]"
<dash> unshelve seems to work OK, but it worries me a little. :)
<dash> anything I can do to diagnose or fix this?
<lifeless> dash: are you shelving only some changes?
<lifeless> dash: also file a bug
<dash> no, all of them
<dash> OK
<lifeless> what does bzr status show, if you can show me?
<denys> hmm... my more general question has not been answered: how do I get a request to change something in the server e.g. in the connection (socket)?
<lifeless> denys: there isn't any way to do that at the moment, the server doesn't assume a socket even exists
<lifeless> denys: which is why I started talking about framing etc
<dash> lifeless: mmm, this is proprietary code, so i probably can't show it to you verbatim
<denys> lifeless: I know, but should I give up or is there value in trying to make that work?
<lifeless> dash: feel free to transform the filenames
<lifeless> dash: I want the structure
<dash> but it's just 4 files modified, 3 files added, no pending merges, mucho unknowns
<dash> OK
<lifeless> denys: and whether specific items are directories or files
<lifeless> denys: well, I don't see a lot of value, but if you do I'm happy to help you figure it all out.
<poolie> denys, i thought i answered that, or at least pointed in the right direction
<poolie> make the objects link to each other on the way up
<poolie> so then the request can tell the socket to start encryption
<lifeless> denys: the reason I don't see a lot of value is that unlike e.g. SMTP, bzr's protocol aims to layer on transports that are already encrypted. SMTP though, defines a wire protocol for talking on a socket.
<poolie> however, i really wish we could understand each other about ssh :-(
<lifeless> oh wow
<lifeless> http://www.techdirt.com/articles/20090328/1445494290.shtml
<lifeless> copyright law fail
<denys> poolie: there's a lot that I just can't do with with ssh that could be done if I have free reign.  but I have to play with the cards I get.
<lifeless> denys: what sort of things?
<dash> lifeless: http://paste.ubuntu.com/256004/
<poolie> lifeless: mm i saw, that's a bit awful
<denys> lifeless: I can't sell it to admins
<lifeless> denys: it doesn't need system users though, or even to be on port 22
<poolie> mind you it'd probably be infeasible to run such a service _at all_ in au or uk because of libel law
<denys> I can't sell restricted shells
<lifeless> denys: it doesn't even need a shell
<poolie> the SMH restaurant reviewer was sued for criticizing a restaurant
<denys> lifeless: you cannot reason it.  this is not a reasonable requirement . it just is. and I have to deal with it.
<lifeless> oh; so you're saying that when you say 'ssh', your sysadmins think 'open ssh, PAM, passwd files and shells', but when you say 'https' they think 'some custom code I don't need to worry about' ?
<denys> they worry about it, but at least they have pretty goof hanlde on that
<lifeless> even though those two things are totally interchangable? [there are system web servers that offer shells and ssh servers that simply don't...]
<poolie> ah :)
<denys> s/goof/good/
 * poolie made the classic mistake of assuming the requirements were rational
<denys> i have spent 3 years of lobbying :-(
<denys> what I have got is pretty good compared with we what we had before
<lifeless> so
<lifeless> one possibly thing to do would be to make bzrs be bzr+ssh :)
<lifeless> and just not tell anyone
<denys> lifeless: you don't work at a university ibviously
<denys> ;-)
<poolie> so
<lifeless> denys: I used to
<poolie> even if it's not externally visible at all, they're going to object if you're running a standard protocol at the top layer, but not if you're running a hand-crafted protocol?
 * poolie wonders where you draw the line
<denys> lifeless: last time we did domething that the security officer didn#t approve of, he cut the entire university network
<lifeless> denys: wow
<poolie> if it's ssh but you must send the string 'cest la vie' before you start is that ok?
<denys> yeah!
<denys> poolie: no dice
<poolie> ok
<poolie> so that probably explains the confusion
<poolie> i think at least some other it departments would actually prefer people use standard secured protocols
<lifeless> its a form of conflation
<poolie> mm
<lifeless> 'ssh' is being conflated with implementations that have various implications
<poolie> i've heard, years ago, of ssh being banned in favor of telnet
<poolie> i'm not sure if it was that they wanted to sniff your traffic, or just fear of the new
<denys> they may eventually come that conclusion themselve, but it CANNOT be thrust upon them
<AfC> poolie: fear of the new
<lifeless> right
<AfC> denys: [and, that's very astute]
<igc> morning
<poolie> denys: so, ok,
<poolie> sheesh
<igc> poolie: the quick references cards did move some weeks back, yes
<poolie> i'd like to help you out here but i'd also like something that makes sense for other people
<poolie> and i think that's more likely to be builtin ssh
<poolie> how about if you write a small separate program that works just like ssh but is not actually ssh
<lifeless> rephrase
<lifeless> 'uses the same encryption as ssh'
<poolie> in other words it opens an ssl connection, sends a username and password, then runs a server process
<lifeless> :)
<poolie> no, not the same protocol
<poolie> so from bzr's point of view it will be 'program that gives me a connection to the server'
<poolie> and 'program that starts the server in inetd mode'
<denys> poolie: I don't think that forcing EVERYTHING into the same mold is necessarily a good strategy.  I'd like to see where we can take the bzr protocol.
<denys> the other consideration is: how hard is it to set up
<denys> I can guarantee you that setting things up on the university server is unbelievably hard
<poolie> i can believe it
<poolie> i'm reminded of getting an hp-ux account with no compiler and not even any cursor key support in the shell
<poolie> that gets very very tedious
<poolie> anyhow, if you put up clean patches, we can certainly look at them
<denys> my tack is to promove virtual servers - but I still have to ackonoledge the authentication rules set up by the univesity
<poolie> i think your requirements here are weird enough they're not necessarily what we'd generally recommend
<denys> oops
<poolie> but maybe it will turn out to be generally useful
<denys> my requirement are not weird. they are just what we have to deal with in france
<poolie> lifeless & others: so on another topic, i'm wondering if rather than 1.18final we should do 2.0beta1 today
<poolie> with the format set
<poolie> acknowledging we'll need more bug fixes, but we may not need anything other than bug fixes
<poolie> well, some things like selected-file commit may need to be fudged as bug fixes; they arguably are
<lifeless> poolie: uhm
<lifeless> poolie: I really think we're confusing people by changing the release labelling before 2.0
<lifeless> there isn't a stable that we have been patching
<lifeless> so I'm very much in favour of 1.18
<poolie> to take a step back
<lifeless> and only changing the labelling at 2.0
<poolie> we could release 1.18final
<poolie> off that branch
<poolie> and then immediately release 2.0b1 at the base of a new branch
<lifeless> not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive
<poolie> what's wrong with 2.0~beta1?
<poolie> you can't have tildes in the upstream version?
<lifeless> a ~ means sort before
<poolie> right
<lifeless> but its not part of the python version spec
<lifeless> which you said you wanted to follow
<poolie> istm (2, 0, 0, 'beta', 1) === 2.0~beta1
<poolie> what is the problem?
<lifeless> that works for me I think
<poolie> surely that's the commonsense way to represent it in both systems?
<lifeless> well, I'm only aware of ~ having this sort before meaning for dpkg specifically.
<lifeless> I think its fine to start using it elsewhere, but it doesn't follow on its own from the starting point of using python identifiers ;)
<lifeless> poolie: has it been 4 weeks since we released 1.18rc1?
<poolie> i seem to be having a bad morning for communication
<poolie> no
<poolie> it's been a week and a half
<lifeless> then I think we should wait ;)
<poolie> you said
<poolie> > lifeless: not to mention that we still haven't figured out how to make 2.x beta releases sort properly in the debian archive
<poolie> i think i answered that
<lifeless> sure
<poolie> i don't think we have to use the tilde anywhere else
<poolie> in source or windows exe files it can be just 2.0beta1
<poolie> for rpms iirc they already have a special sort algorithm that treats 'beta' as meaning 'before'
<poolie> lifeless: btw i suppose you implicitly fixed https://bugs.edge.launchpad.net/bzr/+bug/413584 ?
<ubottu> Ubuntu bug 413584 in bzr "TestStacking failures when default format is 2a" [High,In progress]
<poolie> i marked it fixed
<lifeless> so did I:P
<AfC> Um
<AfC> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<poolie> bzr info?
<AfC> All I was trying to do was `bzr pull`
<lifeless> AfC: is that a checkout ?
<lifeless>  / bound branch
<AfC> poolie: Repository checkout (format: 1.14-rich-root)
<AfC>   repository checkout root: .
<AfC>         checkout of branch: http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
<AfC> lifeless: yes
<lifeless> AfC: ok, so this is a bug
<AfC> bzr 1.17 brand newly installed
<lifeless> we're not matching urls correctly
<lifeless> bzr unbind
<AfC> k
<lifeless> bzr bind http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk
<AfC> && pull?
<lifeless> then you'll be back to normal
<lifeless> and can use bzr update again
<fullermd> Bug?  Isn't that just what you'd expect to do when pulling a checkout over http?
<AfC> [sometimes I think that you guys should kill "checkout" and only offer branch & bind.
<lifeless> fullermd: no, the %7E != ~
<fullermd> Sure, but what's that matter?
<AfC> or, only offer branch ^W checkout & bind, etc]
<fullermd> If you're trying to pull INTO a http://something, you'd expect locking failure since it isn't writable.
<lifeless> fullermd: it fails the test in bzr.pull for master == source url
<lifeless> fullermd: trust me :) look in malone if you want the gory details
<fullermd> Well, maybe there's another bug there, but it *SHOULD* fail writing over HTTP regardless of any other matching.
<AfC> I was trying to *pull*
<lifeless> fullermd: pulling from the master of a bound branch pulls locally only
<fullermd> In a checkout.  Which means the branch you're trying to write to is across HTTP.
<AfC> And then I recalled I really ought to "update"
<lifeless> can we please not paint the chicken a new colour right now?
<fullermd> It WHAT?  That sounds like an insane level of DWIM...
<AfC> (/me hates the fact that sometimes you do that as one step, sometimes two. eg push pull asymmetry, etc. I think in trying to make it easier we just made it more confusing)
<lifeless> fullermd: I'm not defending it, but its been there for years; and the url mismatch is causing the error AfC is getting
 * fullermd never heard of that before.
<lifeless> fullermd: its part of the original bind patch I think
<AfC> lifeless, poolie: thanks Robert & Martin. Fixed.
 * AfC relocates
<lifeless> brb, fooding
<lifeless> dash: sorry, distractions
<lifeless> dash: so, uhm shelve is failing
<dash> yes
<lifeless> and you're doing shelve --all ?
<dash> using shelve1 at the moment in bzrtools
<dash> lifeless: well i hit 'f' at the first prompt so basically
<lifeless> to humour me, could you try shelve --all?
<dash> sure
<lifeless> also are there any pending merges?
<dash> no pending merges
<lifeless> kk
<dash> same error using --all
<lifeless> ok
<lifeless> definitely file a bug
<dash> except it says new-6 now, don't know if that's related to pulling new revs since i tried last
<lifeless> nope
<lifeless> you've modified another file probably
<dash> the parent of this branch is an svn branch, don't know if that's relevant
<lifeless> it might be; but the shelve operation is all local so shouldn't be
<dash> ok
<dash> guess i'll try this with 1.18rc1 too
<dash> thanks
<mozmck> Do the nautilus extensions work on ubuntu 9.04?  I installed from source and I can't get olive to run and nothing shows up in nautilus.
<mozmck> This is what I get when I try to run olive-gtk:  Traceback (most recent call last):
<mozmck>   File "/usr/local/bin/olive-gtk", line 89, in <module>
<mozmck>     import bzrlib.plugins.gtk.ui as ui
<mozmck> ImportError: No module named gtk.ui
<spiv> mozmck: sounds like you hvaen't got the bzr-gtk plugin installed
<mozmck> spiv: that's what I installed from source: bzr-gtk-0.96.2
<mozmck> I'm running bzr 1.17 from the ppa deb package
<lifeless> how did you install it
<mozmck> ./setup.py install I think.
<lifeless> it may have installed to something not on your python path
<mozmck> oh, how would I find that out?  where is the python path?
<lifeless> if you touch one of the source files
<lifeless> like __init__.py
<lifeless> and install it again, you can see the path it installs the python files to
<mozmck> touch it?
<AfC> $ touch path/to/filename.py
<mozmck> ah, changes the timestamp.  Then how do I find it once installed?
<lifeless> the installer outputs stuff
<lifeless> read what it outputs :)
<mozmck> /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk
<lifeless> and now
<lifeless> python -c "import sys; print sys.path"
<mozmck> '/usr/local/lib/python2.6/dist-packages' is at the end of the printout
<lifeless> ok
<lifeless> python -c "import bzrlib; print bzrlib.__path__"
<mozmck> ['/usr/lib/python2.6/dist-packages/bzrlib']
<lifeless> so, this is a python limitation; by default it doesn't really know how to deal with different locations like that
<lifeless> I suggest moving /usr/local/lib/python2.6/dist-packages/bzrlib/plugins/gtk to /usr/lib/python2.6/dist-packages/bzrlib/plugins/gtk
<mozmck> ah, so I need to tell it to install in /usr/lib somehow
<mozmck> I'll try that
<mozmck> looks like that worked.  The first time I tried to run olive it gave a different error than it was giving, but now it runs.
<mozmck> so should the nautilus stuff work after I log out and back in?
 * igc lunch
<lifeless> so, it feels like every tweet gets a new spam follower
<bialix> igc: hi
<igc> hi bialix
<igc> bialix: is qinfo better now?
<bialix> igc, what version of PyQt/Qt you're have?
<bialix> similar problem with layout and in quncommit
<igc> bialix: PyQt 4.4.4, Qt 4.5.0
<igc> bilaix: jaunty
<igc> bialix: I'm seeing crap layout in quncommit - I'm yet to try tuning that, I just wanted something working first
<bialix> what strange combination!
<igc> bialix: qinfo is ok for me though
<bialix> I think PyQt should be 4.5.x too
<bialix> weird weird weird
<bialix> wait a sec
<bialix> igc: http://imagebin.ca/view/RdaTOA.html
<bialix> this is what I see by default
<bialix> "move tip to" group should not be elastic. progress widget should be
<igc> bialix: ok
<lifeless> vila: hi :P
<bialix> igc: there is several places that needs fixing in quncommit, unfortunately I have urgent work...
<igc> bialix: karmix will be pyqt 4.5.2, qt 4.5.1 by the look of things
 * vila snores
<bialix> igc: how about next plan: I'll merge quncommit as is but make it idden command
<bialix> *hidden
<igc> bialix: if you can, let me fix it in the next hour or two
<igc> bialix: can the 0.14 release wait another few hours?
<bialix> igc: I will do release tonight in my tz, ~ +12 hours from now. But you'll be sleeping
<igc> bialix: cool. I have another 2-3 things to clean up so I'll have them up for review asap
<igc> bialix: I won't get to the qconfig nicer diff/merge tool selection so it will need to come later
<bialix> igc: also, why for you need this code in do_start:
<bialix> 280	+ cwd = urlutils.local_path_to_url(os.getcwd()) + '/'
<bialix> 281	+ if cwd != dest:
<bialix> 282	+ args.append(dest)
<bialix> 283	+ self.process_widget.do_start(None, 'uncommit', *args)
<bialix> igc: never never never never never use bare os.getcwd()!!!
<bialix> os.getcwdu()
<igc> bialix: ah - ok
<bialix> but I think that code is useless
<bialix> you need just append branch location
<bialix> and most important!
<bialix> quncommit should operate on working tree root, not branch root!
<bialix> because if you have light checkout you've got wrong thing
<bialix> see qmerge as example
<igc> bialix: but it needs to work on a treeless branch
<bialix> qpull then
<bialix> igc: yes, it should
<abentley> spiv: re: bug 250451, break-lock never suggests a URL, so I don't think your wording is an improvement.
<igc> bialix: ok, I'll take a look
<bialix> igc: but if there is tree it should uncommit in the tree to update dirstate
<ubottu> Launchpad bug 250451 in bzr "break-lock suggests wrong URL for smart-server branches" [High,Confirmed] https://launchpad.net/bugs/250451
<bialix> igc: lib/html_log.py?
<bialix> is it exisiting code from somewhere else?
<igc> bialix: code I use in explorer
<bialix> ah
<igc> bialix: we could use qlog widget if I knew how
<bialix> we have htmlize function in util.py instead of cgi.escape
<bialix> but maybe it does not matter right now
<davidstrauss> This was a fun bug to run into today: https://bugs.launchpad.net/bzr/+bug/415936
<ubottu> Ubuntu bug 415936 in bzr "Merge into new branch produces strange log" [Undecided,New]
<bialix> igc: ok, so I've made almost full review over quncommit
<igc> bialix: thanks for the fast review
<bialix> igc: I need to go to work, I'll check mails but will be busy
<igc> bialix: ok. Thanks
<bialix> igc: qinfo is not critical for 0.14?
<igc> bialix: well, it breaks in explorer when users ask for Location Information on anything without a WT :-(
<bialix> now qinfo better
<bialix> but anyway something wrong when I'm resizing it
<igc> bialix: resizing is ok on Ubuntu fwiw
<bialix> igc: perhaps I'll merge it anyway and we polish it later
<bialix> wanna my screenshot?
<igc> bialix: please - it's a step forward definitely
<igc> yep
<bialix> igc: http://imagebin.ca/view/21L7Di.html
<bialix> igc: I'm just resize it by vertical up and dowm
<bialix> down
<igc> bialix: might be a bug in QFormLayout in Qt 4.4
<lifeless> poolie: ping
<lifeless> poolie: something is going wrong with your merges to bzr.dev
<lifeless> 1.18 is in there twice, and this morning hno reporting that changes from 1.18 are listed under 1.17
<bialix> igc: maybe, but it looks ugly nevertheless
<bialix> ok, time runs out
 * bialix disappears
<igc> bye for now
<xiaohui> Hi, when I use *bzr push* to my branch on lauchpad.net, it shows that the"Unable to obtain lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock
<xiaohui> held by xiaohui@bazaar.launchpad.net on host crowberry [process #10793]
<xiaohui> locked 13 hours, 41 minutes ago
<xiaohui> Will continue to try until 05:11:09, unless you press Ctrl-C
<xiaohui> If you're sure that it's not being modified, use bzr break-lock lp-45207760:///~xiaohui/opencog/moses/.bzr/branch/lock
<xiaohui> bzr: ERROR: Could not acquire lock "(remote lock)": "
<lifeless> bzr break-lock lp:~xiaohui/opencog/moses
<xiaohui> I use the *bzr break-lock lp:~/xiaohui/opencog/moses* but is unuseful
<xiaohui> then it returns an error:bzr: ERROR: exceptions.TypeError: a float is required
<lifeless> xiaohui: what is your bzr version
<lifeless> I believe that was a bug that we have fixed
<xiaohui> my version is 1.14
<lifeless> I'm quite sure that that is fixed
<spiv> xiaohui: upgrade your bzr, or use "nosmart+lp:~xiaohui/opencog/moses" (I think) as a workaround.
<xiaohui> what is the *nosmart*  mean
<spiv> It disables most of the interesting smart protocol code, and just does direct file accesses.  It's roughly equivalent to sftp.
<spiv> If I'm remembering correctly, it also avoids that bug in that version of bzr.
<xiaohui> hmm, it doesn't work
<xiaohui> so I have to upgrade the bzr
<xiaohui> another error:
<xiaohui> so what should I do? update the version of bzr
<xiaohui> bzr: ERROR: Invalid url supplied to transport: "lp:~/xiaohui/opencog/moses": No such person or team:
<xiaohui> why it said no such person or team
<lifeless> you've mispelt the url
<lifeless> you added a / between ~ and x
<xiaohui> oh , my fault
<vila> hi all
<abentley> With bzr trunk, bzrtools tests are failing due to dirstate locks that did not fail previously: http://pastebin.ubuntu.com/256159/ Any ideas?
<vila> abentley: does that involve some transform_tree ?
<vila> abentley: https://code.launchpad.net/~lifeless/bzr/transform_tree/+merge/10440 may be related ?
<abentley> vila: No, it doesn't involve that.
<vila> I' don't that's been merged yet tough
<vila> abentley: by the way, what TZ are you in right now ? 8-}
<vila> abentley: well, your pastebin shows a 'transform_tree' in the traceback, so have a look at lifeless patch maybe that's what you need
<abentley> Perhaps America/Caffienated.
<vila> abentley: may be I should have said merge.transform_tree
<lifeless> abentley: you may find my merge request put up a couple hours ago fixes them
<lifeless> it fixed something like 1/2 the tests in bzr.dev that had been annotated as not being safe on windows
<spiv> abentley: thanks for pointing out my thinko in that bug title.
<abentley> spiv: np
<lifeless> abentley: if it doesn't fix them, you can make them pass by calling thisTestFailsStrictLocks()
<abentley> vila: Okay, I could have sworn it was failing when opening the tree.
<vila> abentley: I've seen your announce for bzrtools-1.18 but no new commits on lp:bzrtools (and no tag either), that's what you're working on right now ?
<vila> abentley: hehe ,np, get more caffeine :0D
<abentley> vila: did that just before posting to IRC.
<vila> abentley: excellent, pulled
<abentley> lifeless: Your patch fixes my problem.
<lifeless> cool
<poolie1> hi vila?
<vila> hey poolie1
<poolie1> how's stuff?
<vila> good ! ;-D
<mdke> is there anyway that I can tell bzr merge to always prefer the source tree if it encounters a text conflict?
<poolie1> mdke: no, but it'd be a nice feature to add
<spiv> mdke: "bzr revert -r:parent `bzr conflicts`" or something like that would be a rough approximation.
<mdke> poolie1: I'll file a bug I guess.
<poolie1> vila, beyond the stuff in the metronome mail i'm thinking about branching off 2.0 tomorrow
<poolie1> and then asking for only bug fixes into that
<poolie1> what do you think?
<mdke> spiv: thanks, should I run that after the merge or instead of it?
<vila> poolie1: checking mail
<vila> poolie1: right, I agree, 1.18final today and 2.0 tomorrow
<vila> especially since karmic now passes the full test suite :-D
<poolie1> or monday
<poolie1> that's good
<poolie1> it'd be nice to fix some more of the critical 2.0 bugs firs
<poolie1> first*
<vila> poolie1: yeah and check with jam too
<mdke> spiv: the merge command I'm running which gives me the conflicts is "bzr merge -r 147..150 ../intrepid" - any idea how I could adapt your formula to suit that?
<lifeless> poolie1: I'm fine with branching soon; just not 'releases' :)
<mdke> brb
<lifeless> poolie1: by which I mean, 'do you want me to branch 2.0 when I get up tomorrow'
<poolie1> oh that'd be nice
<mdke> spiv: nevermind - I've figured out that I can avoid the conflicts entirely by merging some earlier revisions first. Thanks for the help anyway though
<poolie1> oh i did mention that already
 * igc dinner
<hno>  lifeless: A small piece of information missing from your 2a format switch announcement.. which version are minimum required to use 2a repositories.
<lifeless> hno: 1.16 is the bare minimum, but its had _many many_ bugfixes since then
<lifeless> hno: I would recommend the absolute latest version you can get - 1.18rc1 at the moment, and 2.0 for sure once thats released, as there are still major bugs related to 2a.
<lifeless> (not in correctness, in performance regressions in various corner cases)
<lifeless> hno: the headsup announcement was preventative for folk tracking trunk; we assume those folk know this stuff somewhat :)
<poolie1> omg i just looked at the new project homepage https://edge.launchpad.net/bzr
<poolie1> that is really nice
<bob2> tad verbose
<poolie1> mm the bit about packaging does not scale well
<bob2> yeah
<vila> poolie1: I had the same reaction yesterday evening
<bob2> ah, looks less insane on a small monitor
<bob2> on 24" the downloads stuff falls the bottom of the packages list
<hno> lifeless: I would not bet on it..  memory quickly fades on in which version a format was added, and even quicker on which versions may have had serious bugs in the format...
<lifeless> :)
<lifeless> we'll make a serious song and dance about it when 2.0 is actually released.
<lifeless> bob2: and they say size doesn't matter.
<hno> regarding the new project page.. I agree that the packaging do not scale. Currently overly overbose, and sorted "wrongly". Should have most recent distribution first, and only list the current release per distribution by default with the full history collapsed.
<marcchr> hi
<marcchr> I have a problem merging from a bzr-branch into a svn-checkout. I get "AttributeError: 'Revision' object has no attribute 'foreign_revid'"
<marcchr> http://pastebin.ubuntu.com/256202/
<marcchr> bzr branch spam /tmp/test-zr; [modify something in test-zr and commit]; in spam: bzr merge /tmp/test-zr gives the error
<marcchr> spam is the svn checkout
<poolie1> marcchr: probably your copy of bzr-svn is out of date with bzr
<poolie1> otherwise please file a bug in bugs.launchpad.net/bzr-svn
<vila> lifeless: care to have a look at https://code.edge.launchpad.net/~vila/bzr/selftest-fixes/+merge/10364  ?
<marcchr> bzr-svn 0.6.4 is the latest if I'm not mistaken?
<marcchr> poolie1: ok, I will file a bug
<marcchr> poolie1: I'm using bzr 1.17
<poolie1> ok good night all
<vila> poolie1: good night !
<fullermd> Ooh, ...544432 for the 1.18 tar.  How cute.
<vila> fullermd: Is that the size ?
<fullermd> No, the lplibrarian dir.
 * fullermd tosses ports updates out into the aether.
<spirov92> hey, a quick question...
<spirov92> if I in a branch I make a link to another branch(say, a module) how will bzr handle it?
<spirov92> I mean a symlink
<bob2> as a symlink
<spirov92> but if the module folder has a .bzr folder, will it try to version it?
<bialix> igc: are you still around?
<bialix> igc: question about quncommit
<igc> hi bialix
<bialix> hi igc, I have some time to look at quncoomit
<bialix> it looks better now
<fullermd> spirov92: The symlink isn't dereferenced.  It's just stores as a symlink.
<bialix> igc: I just wonder about terms, like tip
<bialix> igc: why you're using idiom "move tip to"?
<igc> bialix: would you prefer another name like "head"?
<bialix> igc: this is not blocks me from merge, but if you have couple of minutes, I'd better ask
<bialix> igc: no, I mean why we talk about moving tip and not about uncommit actually?
<bialix> igc: e.g. we can show revision details under first radiobutton
<bialix> and put the label for radiobutton: Uncommit last revision:
<bialix> igc: actually I have troubles to correctly translate tip, and it does not seem bzr uses "tip" term internally or in the docs
<igc> bialix: firstly, I think 'tip' is fine ...
<igc> from core-concepts in the User Guide: The last revision is known as the *tip*
<bialix> igc: ok, I did not know this
<bialix> so I can translate tip as "last revision"?
<igc> bialix: yes
<bialix> I understand that "tip" is short and nice word in English
<bialix> as many others: pull and push
<igc> bialix: also, we need to display what revisions will be removed anyhow so there seems limited benefit in displaying that in advance
<igc> bialix: I thought pretty hard about that and ...
<bialix> it so nice to be Englishman and speak in so wonderful language
<igc> I've been through several designs on paper over the last few months thinking about quncommit
<bialix> igc: what if I want uncommit 100 last revisions?
<bialix> what I'll see in confirmation dialog then?
<igc> bialix: we'll display those just like the CLI does
<igc> bialix: that would be very unusual, of course
<bialix> on CLI any long info go out of my console
<bialix> this becomes problem for GUI
<igc> bialix: 99% of the time it's just one revision - to fix the commit message, bug metadata, etc :-)
<bialix> you just can't have an infinite tall dialog, do you? ;-)
<bialix> igc: so if this is 99% cases, why not show ther details right in the quncommit window?
<igc> bialix: I guess we could use a scrolling panel or the qlog widget
<igc> bialix: I'm ok with doing that
<igc> bialix: I just don't think it's mandatory
<igc> to land this
<bialix> igc: no of course.
<bialix> igc: +1 on land the last version
<igc> bialix: thanks. Did you want to merge it or I?
<bialix> igc: I'm just want to discuss with you how it could be improved, especially re better UI for translations to other languages
<bialix> igc: if you can, merge n push it yourself
<igc> bialix: no problem. I do think it can be improved
<igc> bialix: but that can come later
<bialix> yes, of course
<igc> bialix: what about my qbind tweak?
<bialix> but later I forgot what I'm thinking right now
<bialix> qbind tweak sounds ok conceptually
 * bialix looks at qbind patch now
<igc> bialix: there have been a few threads re that on the main bzr list so ...
<igc> I thought we'd make the GUI better at least
<bialix> igc: can we just dump this discussion about quncommit to new bug report?
<bialix> so I don't forget about it later?
<igc> bialix: sure. Also, qexport should be cleaner now though ...
<igc> bialix: I suspect it's still not perfect wrt lightweight checkouts
<igc> bialix: but it ought to be a small tweak from here I hope
<bialix> rats, what's going on with lp?
<bialix> igc: what you mean when said: "there have been a few threads re that on the main bzr list so ..."?
<igc> bialix: about checkout vs branch+bind
<bialix> I'm lack context. This is related to qbind?
<igc> bialix: yes. Basically having a bind checkbox on qbranch is desirable
<igc> bialix: until then, it's nicer if qbind defaults to the parent if never bound before
<bialix> igc: there is combain qgetnew
<bialix> *combine
<bialix> it do everything and makes you sandwitch
<igc> bialix: right, but it's worth improving qbind anyway
 * bialix looking at qbind actually
<igc> bialix: I'm yet to warm to qgetnew
<igc> bbiab
 * bialix is not fun of qget new
<bialix> igc: qbind patch is ok for me
<bialix> igc: perhaps I'll look at qexport improvements later
<bialix> igc: if you have any specific plans about releasing bzr-explorer let me know beforehand, I need to update translations
<garyvdm> Hi all
 * garyvdm was looking for jam
<bialix> Hi garyvdm
<bialix> too early for jam ,I guess
<luks> bah, this reminds me why I stopped caring about bzr development
<bialix> luks: ?
<luks> bialix: nothing, I just read about the 2.0 branching and having a patch submitted at the start of 2.0dev cycle, it reminded me how non-Canonical patches are handled
<luks> it's very demotivating
<bialix> luks: I'm still under impression of discussion about review processes, I was guess it's relates
<bialix> luks: yeah, it seems better way to ensure your patch will be merged is to poke people in this chat
<fullermd> It IS rather disencouraging.
<fullermd> Also makes one want to skip NEWS entries.  You know it'll just cause conflicts that have to be manually fixed anyway, 2 releases later when it's applied.
<garyvdm> Hi bialix/luks
<garyvdm> Hmm my irc is dodge. I can see bialix said hello to me here: http://irclogs.ubuntu.com/2009/08/20/%23bzr.html , but not in my irc client, and I was signed in....
<bialix> your client seems timed out and reconnect then
<garyvdm> luks: :-(  You should raise that as an issue.
<bialix> I've heard this from luks beginnign from 2007
<luks> garyvdm: it's not something I care that much about, it's just sad that bzr is even a GNU project, but the development process is far from the open source standard
<fullermd> Well, I wouldn't go that far...
<luks> I would :)
<fullermd> But that's more a statement on the state of the 'open source standard'.
<luks> well, I wouldn't say a word if patches were ignored and there were no releases
<luks> but the issue is very visible with monthly releases
<garyvdm> bailix: Anything important that you want me to look at for 0.14?
<bialix> garyvdm: I guess everything is ok
<bialix> luks mentioned slower startup of qcommit
<bialix> I see this too
<fullermd> I came across some annoying behavior in qlog that I'm not sure is a bug (or how to describe concisely if it is)...
<bialix> I guess the problem in new treewidget stuff
<luks> that's not easy to fix, I guess
<bialix> garyvdm, luks: I'm still mulling the idea, but I have a feeling that we need either threads for long running stuff or launch subprocess to do heavy work and implement some sort of rpc
<fullermd> Clicking on a rev in the list selects it, but there's no way to un-select it.
<bialix> and implement multi-pass visualisation for things
<bialix> garyvdm: no, I remember
<luks> bialix: well, that will not make it faster, just more responsive
<bialix> garyvdm: problem with misadded
<fullermd> When you expand a branch in the history, it redraws the window, and adjusts placement to show the selected row, if there is one.
<bialix> luks: if we populate the widget in qcommit with simplke data and then add more data, e.g. icons
<fullermd> So, if you've selected a rev, scroll around a while, then expand a branch, *pow* you're dragged way the heck away from what you just expanded.
<bialix> fullermd, garyvdm: I think it was fixed recently?
<garyvdm> My irc seems very delayed.
<garyvdm> bialix: bug 414729.
<ubottu> Launchpad bug 414729 in qbzr "problem with "misadded" items in treeview widget" [High,Confirmed] https://launchpad.net/bugs/414729
<bialix> garyvdm: yes
<bialix> garyvdm: I found the way how to hide this items from qcommit
<bialix> but not from qbrowse
<garyvdm> fullermd: Thats has been fixed.
<fullermd> Hm, guess so.  Can I borrow this time machine sometime?
<garyvdm> fullermd: in rev 902
<bialix> fullermd: you're always welcome
<fullermd> Doubly irritating since I was at 901   :p
<bialix> garyvdm: here where I've started http://pastebin.com/m1cee143
<luks> :)
<bialix> lol
<garyvdm> bialix: re bug 414729: we can just filter out the item in the FilterProxyModel.
<ubottu> Launchpad bug 414729 in qbzr "problem with "misadded" items in treeview widget" [High,Confirmed] https://launchpad.net/bugs/414729
<bialix> garyvdm: we need the list of misadded for qcommit to implicitly commit them
<garyvdm> bialix: I just checked on this: The FilterProxyModel affects what is displayed, but not what is passed to the command line. - So that would be the place to do it.
<bialix> garyvdm: that's nice!
<garyvdm> bialix: You will see in the FilterProxyModel that we allways show an item that is checked, so you will have to override that.
<garyvdm> bialix: I'm going to do some profiling of qcommit. I be afk from about 4pm to about 8pm UTC+2
<bialix> garyvdm: I'll start prepare release after 8pm UTC+2
<bialix> and will be in iRC
<davertron> hi, I'm getting "Cannot lock LockDir" when I try to pull from a remote repo due to a permission denied error trying to write to .bzr/branch/lock; however, if i go look at that directory, my user belongs to the right group and that group has write permission on that directory. Any idea what I'm doing wrong?
<garyvdm> luks, bialix: In what situations is qcommit load slow. It is quick for me.
<davertron> also, another interesting thing is that the parent branch isn't the directory where I get the error from
<bialix> garyvdm: it's not slow as "really sloooooooooooooow". it's just now slower than before treewidget landed
<bialix> qbrowse too
<garyvdm> luks, bialix: If you have a situation that is slow, please email me a .callgrind.
<garyvdm> davertron: please will you pastebin the last entry of ~/.bzr.log
<davertron> garyvdm: from the directory i'm trying to pull from or the one i'm pulling to, or does it matter?
<garyvdm> davertron: there will only be one on your computer.
<garyvdm> davertron: are you on windows?
<davertron> garyvdm: sorry, I'm pulling from a totally different machine, does it matter if it's from the machine i'm pulling to or the machine i'm pulling from?
<davertron> garyvdm: nope, on ubuntu
<garyvdm> davertron: The machine that you ran the bzr command on.
<davertron> garyvdm: http://pastebin.ca/1536285
<davertron> garyvdm: nm, I think i figured it out
<davertron> looking at wrong machine i think
<garyvdm> davertron: Cool
<davertron> i was looking at the permissions on the remote machine, instead of the local machine
<davertron> should have noticed the "file:///" stuff...
<davertron> thanks :)
<vila> http://instantrimshot.com/
<vila> Finally no more './bzr selftest --no-plugins' that fail to test core plugins, welcome `BZR_PLUGIN_PATH=-site ./bzr selftest` :-D
 * beuno is going to release loggerhead today so it can get updated for karmic
<vila> fullermd: funny qlog bug huh ? Drove me nuts too but garyvdm fixed it as soon as I mentioned it :-D (Of course the pity is I mentioned it after having suffered a lot :)
<vila> Can someone remember where we wanted to display the plugins path ?
<bialix> vila: nice
<vila> bialix: https://code.edge.launchpad.net/~bzr/bzr/412930-plugin-path/+merge/10458 pending review :-D
<vila> bialix: Even if you don't vote, I'll appreciate your comments regarding windows,
<bialix> vila: I'll try to look tonight
<bialix> from home
<vila> I've read a couple of bug reports but what needs/can/shouldn't be done on windows is a bit unclear to me,
<bialix> ROTFL
<vila> in particular, is there a clean way to have a 'site' directory for shared plugins ?
<bialix> what?
<vila> a directory where plugins can be installed and used by all users
<vila> If I read the current code correctly we don't even try to define one for win32, I've respected that but I've also read various incoherent reports on that
<davertron> man, still running into permissions errors trying a bzr pull...everything looks like it's going fine, but then i get a "Permission denied" on .bzr/repository/upload/598ikvm63uwlti81qibp.fetch", even though I own that file and have read/write permissions on it
<davertron> everytime i run "bzr pull", i get a new file that is created in that directory and the same "permission denied" error
<davertron> http://pastebin.ca/1536340 output from last entry in ~/.bzr.log
<vila> davertron: you're working under /usr/local/lib ? With what login ?
<davertron> david.davis
<davertron> this is a repo that someone else intitally set up
<davertron> so that's why i think i'm having the issues with it
<davertron> i don't think they did a good job of setting permissions on the damn thing
<vila> the permission denied is related to the containing directory (upload) do you have write access there ?
<davertron> i do
<davertron> in fact, the file that it claims "permission denied" on is created in that directory
<davertron> whenever i run "bzr pull"
<bialix> vila: vso what is your question?
<bialix> vila: do you read bzrlib/plugin.py?
<vila> hmm, yeah, right, sorry, look under the packs directory, that should be the target and the place where you lack access
<vila> bialix: I patched it heavily yes, did you read my merge proposal ?
<vila> :)
<vila> damn, I just realized I dind't preserve the 'no site directory for win32' bit :-/
<bialix> vila: sorry, I'm busy right now
<vila> bialix: np
<bialix> vila: I'll read your patch tonight, from home
<davertron> vila: yeah, i just ran a chmod -R g+w on the whole .bzr dir
<davertron> that seems to have gotten me a little farther
<davertron> the perms on this repo are just all hosed
<davertron> the guy who created it obviously didn't set perms correctly for anyone else to work on it
<davertron> even though it's a damn production deploy repo
<davertron> anyway
<davertron> i'll just have to keep mucking with the stupid perms
<davertron> and try not to take the site down :p
<vila> davertron: may be you should just stop working in /usr/local but install there from root
<vila> You already have a shared repo on another server right ?
<davertron> yes
<davertron> he didn't really set that one up right either :)
<davertron> i had to muck with that for a bit so I could push to it
<vila> davertron: no need to mess with permissions in two different places no ?
<davertron> now i'm mucking more to pull
<davertron> well, bzr doesn't preserve all perms does it?
<vila> davertron: rm -fr the damn thing :-) (Kidding put it aside instead)
<davertron> vila: heh
<davertron> vila: i'll just rm -rf this other developer instead... :P
<davertron> he's got different perms on the different repos, so he probably screwed it all up himself just to get it working in production
<davertron> different groups own different things
<davertron> it's a mess :)
<emmajane> beuno, ping.
<beuno> emmajane, hi
<emmajane> PM ok?
<beuno> always!
<emmajane> excellent. :)
<igc> night
<beuno> igc, night!
<beuno> I forgot to CC you on an email for the bazaar web page design
<beuno> fwding now!
<vila> beuno: wrong window ? :-D
<beuno> vila, no!
<beuno> it's public  :)
<vila> but who is 'you' in 'CC you' then ? :)
<beuno> vila, igc
<beuno> I'm just lazy
<vila> haaa
<vila> right, makes sense, was a bit ambiguous, thought it was for emmajane :)
 * emmajane is apparently off in another world and requires explicit pinging to see windows. :)
<beuno> james_w, hi
<james_w> hey beuno
<beuno> james_w, how are you?
<james_w> good thanks, how about you?
<beuno> pretty good
<beuno> sprinting, as usual  :)
<beuno> james_w, I need your super powers
<james_w> where are you this time?
<beuno> james_w, buenos aires, but sprinting anyway  :)
<james_w> nice
<beuno> with the Ubuntu One guys
<james_w> ah, cool
<beuno> james_w, I've released a new version of Loggerehad
<beuno> so we can get all the changes into loggerhead
<beuno> er
<beuno> karmic
<beuno> :rolleyes"
<james_w> ok
<beuno> james_w, can you upload to ubuntu and/or karmic?
<beuno> jelmer doesn't seem to be around
<james_w> I'll work on it
<beuno> james_w, THANK YOU
<beuno> I'm in London for the last 2 weeks of Sept
<beuno> please come by to say hi and claim your beer
<james_w> heh
<james_w> beuno: I like the new project overview pages, thanks
<beuno> james_w, ah, I'm happy to hear that
<beuno> a fe wmore changes in the pipeline, but it's roughly what it will look like
<james_w> a lot less scrolling and hunting
<beuno> james_w, how does the navigation feel?
<james_w> beuno: better I think, though the fact that what were the tabs are now much less prominent threw me
<james_w> plus I just noticed "Submit code" goes to what I presume is the wrong place
<beuno> james_w, yeah, still working out the quirks
<james_w> I certainly find it much more attractive, but I know you're interested in more than that :-)
<james_w> and I still have quibbles with merge proposals
<beuno> yes, merge proposals is the next thing I'm working on for the 3.0 re-design
<beuno> will CC you on the email, if you like
<beuno> it will go to the launchpad-dev list, if you're subscribed
<james_w> I'm not, but I think I will do so now
<james_w> there's a mail I need to send to it, but I can't remember what right now
<james_w> I can't find a bug for this "Submit code" thing, I'll file it now unless you know it's known
<beuno> james_w, it's been submitted to PQM already
<james_w> ah, excellent
<vila> beuno: 'last bugs reported' and 'last bugs touched' lists should be longer or an access to a longer list should be provided,
<vila> I think the bug mentioned by james_w above is the one filed by lifeless less than a day a ago, and commented by me less than half a day ago, and yet, it's nowhere to be seen...
<beuno> vila, yes, we're trying to figure out that page
<vila> beuno: I understand, that's why I throw my 2 cents remark :)
<vila> ha, here it is: bug #416125
<ubottu> Launchpad bug 416125 in launchpad "product homepage's submit code link leads to +filebug" [Undecided,New] https://launchpad.net/bugs/416125
<vila> ha err, not sent to pqm then, were you talking about a different one ? james_w ? beuno ?
<beuno> vila, the fix should be visible tomorrow
<vila> beuno: don't you mark the bug Fix committed or at least in Progress ?
<vila> or is it just a dupe ?
<beuno> vila, it should be in progress
<beuno> I'll ask  :)
<vila> not really important. I was just wondering
<beuno> vila, feedback is very useful, thank you
<ddaa> hey
<ddaa> anyone has figured out yet how to use the "parent diff" feature of reviewboard?
<ddaa> it's driving me totally nuts
<mtaylor> sadness has happened!
<mtaylor> ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('lua-20081111233858-hzs0ti8sqjaycvlp-16', 'monty@inaugust.com-20081111233949-xwxzzzus31nn99aa')")
<ddaa> Mh okay it SEEMS to expect the following
<ddaa> diff = ancestor::prev..:last
<ddaa> parent-diff = base-of-first-diff-for-this-review-request..ancestor::prev
<ddaa> The problem I'm tying to solve is: How to feed reviewboard updated diffs when the branch to review merged changed from its base branch.
<bialix> vila: why not: bzr --only-user-plugins selftest ...
<rockstar> vila, tarmac just puked on me with the following error: http://pastebin.ubuntu.com/256461/
<rockstar> It happened trying to commit from a heavyweight checkout.
<bialix> rockstar: are you using 2a?
<rockstar> bialix, I am indeed.
<bialix> your server need upgrade maybe
<rockstar> bialix, the server is Launchpad.  While we might be behind a bit, I don't think that's the issue, since I've been dealing with Launchpad all day.
<bialix> error tells that some bzrlib does not understand your format
<bialix> either your local installition or server
<bialix> check /usr/lib/python2.6/dist-packages/bzrlib then
<rockstar> bialix, I'm on bzr.dev
<bialix> run bzr info -v then
<bialix> are you sure that /usr/lib/python2.6/dist-packages/bzrlib is bzr.dev?
<bialix> garyvdm: ping
<garyvdm> bialix: Hi
<sveinung> is this the correct place to ask questions about bzr builddeb?
<james_w> sure
<sveinung> I have checked out, built and installed the latest version from the bzr branch on launchpad
<sveinung> how do I make it use the Debian date?
<sveinung> when importing
<sveinung> I see the code is there
<sveinung> but I cant find an option to enable it
<sveinung> (I look at bzr help import-dsc)
<sveinung> when I say Debian date I mean the one from the changelog
<james_w> hmm, it's not hooked up to the UI is it?
<james_w> it's something I added later, and I didn't think it should be default
<james_w> now I'm not so sure
<sveinung> james_w: Ok, thanks
<sveinung> so I should modify bzr builddeb if I want it?
<james_w> patches welcome :-)
<verterok> join #twisted
<sveinung> james_w: is changelog-time an Ok name for an option?
<james_w> I guess
<james_w> should the default just change instead?
<sveinung> I must admitt I was kind of confused when it used todays date. But I have looked at the autoimported branches at launchpad so I'm not sure if that is what will be least surprising for other people
<sveinung> so I don't know
<james_w> I think it might be better
<james_w> I can't really remember my reasons now :-)
<sveinung> ok
<sveinung> (the it that might be better was to change the default, right?)
<james_w> yeah
<sveinung> james_w: is the test suite run during the building of the debian package?
<lifeless> moin
<sveinung> james_w: I found out how to run the test suite on my own. Merge request sendt
<johnjosephbachir> if i have a lone checkout with no surrounding repo, but then make a repo, make a branch there, and then physcially move my checkout into the repo and bind it to the branch, will it [a] work, and [b] actually take advantage of the repo data?
<bialix> a - yes, b - you need to run reconfigure
 * johnjosephbachir looks at documentation for reconfigure
<johnjosephbachir> bialix: thanks!
<bialix> bzr help reconfigure
<johnjosephbachir> bialix: hmm, even after doing that, my old reconfigured checkout (which i then turned into a branch) is  double the size of a fresh new branch
<bialix> bzr reconfigure --use-shared ?
 * johnjosephbachir reads the documentation more thoroughly......
<johnjosephbachir> bialix: perfect.
<Noldorin> lifeless: ping?
<james_w> thanks sveinung
<sveinung> np :)
<james_w> I'll review tomorrow
<sveinung> great
<lifeless> Noldorin: hi?
<Noldorin> heh
<Noldorin> just checking you were there :)
<Noldorin> lifeless: i'm trying to hack the source into outputing ftp commands now
<Noldorin> but it doesn't seem trivial without altering the source for the actual ftp lib
<Noldorin> any ideas here?
<lifeless> if you want to log the exact commands tcpdump, or wireshark, or similar tools might be better suited
<lifeless> I was suggesting just getting close :)
<Noldorin> hmm, good point
<Noldorin> might just use wireshark.
<Noldorin> does the windows ftp client support ftp scripts?
<Noldorin> the reason i'm wanting to replicate is purely out of laziness :)
<Noldorin> RNTO /texdotnet/.bzr/repository/lock/held
<Noldorin> FTP	Response: 550 /texdotnet/.bzr/repository/lock/held: Cannot create a file when that file already exists.
<Noldorin> lifeless: that's what we expect, right?
<igc> morning
<goneri> hi igc
<igc> hi goneri - I haven't forgotten your patch btw
<goneri> (yes, I'm watching you :D)
<igc> goneri: just flat out on non fast-import stuff yesterday
<goneri> igc: I rewrite the second patch. There is just two tiny patches now.
<goneri> s/rewrite/rewrote
<lifeless> Noldorin: thats the behaviou, yes
<Noldorin> lifeless: so there's a rename command before that which failed?
<Noldorin> renaming /lock/held to something else
<Noldorin> i presume
<lifeless> yes
<lifeless> but if theory is right it isn't actually erroring :)
<lifeless> its just not working
<Noldorin> yeah
<Noldorin> just wanted to double check that
<Noldorin> in the wireshark log
<denys> I am unable to run the full test suite.  it always eventually errors out with "error: can't start new thread".  is there a trick I should know?
<lifeless> is that with or without your patches?
<lifeless> and on what platform?
<denys> without and on gentoo/linux
#bzr 2009-08-21
<lifeless> thats a new one then
<lifeless> uhum
<lifeless> python version?
<lifeless> also file a bug to track this; its not usual :)
<denys> 2.6.2
<Noldorin> lifeless: erm, according to the ftp log, it's quite justified to throw that error
<lifeless> Noldorin: it is?
<Noldorin> a previous rename has occured which renames a certain dir to that name
<Noldorin> yeah, let me paste it for you
<Noldorin> lifeless: http://pastebin.ca/1537024
<Noldorin> search for '/lock/held/'
<Noldorin> and you should see two RNTO commands without any RNFR or RMD commands inbetween
<Noldorin> lines 759 and 825
<lifeless> Noldorin: there is a RNFR for it
<poolie> jam, still around at all?
<Noldorin> lifeless: hm?
<Noldorin> are you assuming that rename commands automatically overwrite existing dirs?
<lifeless> mmm
<lifeless> no, I was looking earlier
<lifeless> is this your patched bzr ?
<Noldorin> yeah, look between those line numbers
<Noldorin> nope
<Noldorin> standard 1.1.7 release
<lifeless> and is it a trace of a single failing command ?
<Noldorin> the command was bzr push -Dtransport ftp://...
<lifeless> did the command complete or error ?
<Noldorin> i got the old lock error
<Noldorin> Unable to obtain lock ftp://alexreg-repos@213.175.198.12/texdotnet/.bzr/reposito
<Noldorin> ry/lock
<Noldorin> held by alexreg@gmail.com on host Alex-Laptop-PC [process #11988]
<Noldorin> locked 7 seconds ago
<lifeless> and it was a new directory ?
<Noldorin> yep
<Noldorin> well i was pushing to a clean dir
<Noldorin> so *do you* assume that rename commands automatically overwrite existing dirs?
<Noldorin> (i'm not terribly familiar with how ftp servers handle requests, in particular linux ones.)
<lifeless> 339 locks 455 unlocks. Thats the 'init' phase. 759 locks. 771 reads-back to check it locked. 785 reads again. 825 tries again.
<lifeless> no, we assume that file systems are horribly broken.
<Noldorin> heh
<lifeless> Noldorin: heres what I get from that trace:
<Noldorin> not horribly broken enough :)
<lifeless> something went wrong and bzr attempts to spin on the lock.
<Noldorin> right
<lifeless> the repeated attempt to acquire the lock is consistent with a failed lock attempt
<Noldorin> i see...
<Noldorin> but the curious thing is...
<Noldorin> it seems to have actually succeeding in creating the lock, no?
<lifeless> the rename succeeded.
<Noldorin> mm
<Noldorin> so what did fail here?
<Noldorin> sorry if i'm being slow
<lifeless> you're not. its tricky.
<Noldorin> quite
<lifeless> do you have the .bzr.log from that run ?
<lifeless> ah
<lifeless> do this
<lifeless> bzr -Dtransport -Dlock push ...
<lifeless> this will log more to the .bzr.log
<Noldorin> right ho
<lifeless> get a network trace at the same time
<Noldorin> lifeless: http://pastebin.ca/1537042
<Noldorin> http://pastebin.ca/1537043
<Noldorin> and yes, that actually is the log from the new run.
<Noldorin> seems to be identical
<Noldorin> erm, network trace
<lifeless> cool
<lifeless> so
<lifeless> look at the .bzr.log
<Noldorin> yep
<lifeless> line 65 locks
<lifeless> line 73 unlockks
<lifeless> or starts the unlock sequence
<Noldorin> that's for the bzr init process, no?
<lifeless> yes
<lifeless> so thats the release
<Noldorin> right. well we know that succeeds at least
<lifeless> then we wite some temp data
<Noldorin> from other things to
<Noldorin> yep
<lifeless> and 105 starts a new lock sequence
<lifeless> which renames into plce at 108
<lifeless> but, at 110 when we read it back we see it is held by the earlier lock object
<lifeless> so I'll make a patch to make that blow up
<lifeless> and then the network log will be cleaner
<Noldorin> alright
<Noldorin> something for me to test now, yeah?
<lifeless> yes
<Noldorin> :)
<lifeless> you can see that the nonce is unchanged
<lifeless> search for 0cgz
<lifeless> the init-lock uses that nonce
<lifeless> and the later lock encounters that lock
<Noldorin> yep
<lifeless> http://pastebin.ca/1537052
<Noldorin> cheers
<lifeless> that works for me, with a local  filesystem ;)
<lifeless> it should work for you too
<Noldorin> erm, should i be editing the source i already hacked
<Noldorin> or do a clean pull?
<lifeless> either
<Noldorin> ok
<lifeless> IIRC the other changes were to lock ?
<Noldorin> yeah
<Noldorin> i think they were mainly delays and such
<Noldorin> maybe an extra command in one or two places
<Noldorin> bzr.log/network trace/both?
<Noldorin> interesting
<Noldorin> i get the 'ftp breakage' message (from our previous test i believe)
<Noldorin> but not your new 'we know its broken now' one
<Noldorin> lifeless: http://pastebin.ca/1537063
<lifeless> the .bzr.log please
<Noldorin> http://pastebin.ca/1537064
<Noldorin> lifeless: anything interesting?
<lifeless> analysing
<lifeless> it tries to unlock twice
<lifeless> uhm
<lifeless> please try on a clean copy
<lifeless> you can 'bzr shelve1' your existing changes
<lifeless> or just bzr diff > old.patch
<lifeless> bzr revert
<lifeless> then apply my new patch
<Noldorin> ok
<Noldorin> sounds sensible
<lamont> lifeless: when I did bzr shelve; bzr commit; bzr unshelve, bzr changed group ownership on (the one) modified file.. .is that expected?
<lifeless> lamont: it writes a new file
<lamont> ah, that would do it
<lifeless> so, 'yes'.
<denys> hmm... (tried something with the test suite)  how long does selftest need for a full run? minutes, hours, days?
<lamont> always sad when a corner-case use-case smacks against designs that make sense for everything else... no worries
<lifeless> if you file a bug that we should preserve that (where we can), we can look at what it will take to do it.
<lamont> lifeless: I'll file the bug
<lifeless> denys: depends on your machine
<lifeless> denys: on mine, 40minutes, on vilas with --parallel=fork, 4 minutes
<lamont> lifeless: you need a new machine. :-p
<lifeless> lamont: no, I need to fix the test suite
<lifeless> we run some code paths millions of times. Thats inefficient.
<Noldorin> lifeless: -Dtransport and -Dlock this time?
<denys> I was wondering about --parallel.  the option's help is completely unhelpful.  I had no idea ARG could be fork (or anything).  I don't know what it does.
<Noldorin> lifeless: erm, i get 'bzr: ERROR: exceptions.NameError: global name 'error' is not defined' in stdout
<lamont> lifeless 416718
<Noldorin> erm, note that 'in stdout' isn't part of the error message :P
<lifeless> Noldorin: a typo
<lifeless> errors.
<lifeless> not error.
<Noldorin> lifeless: where?
<lifeless> in my patch
<lifeless> I wrote error.BzrError twice. I should have written errors.BzrError
<poolie> lifeless: did you make a 2.0 branch?
<lifeless> yes
<lifeless> or rather spm did
<poolie> spiv: ah that explains why you were talking over me :)
<poolie> great
<lifeless> as I can't anymore :P
<spiv> poolie: :)
<Noldorin> bzr: ERROR: epic unlock fail
<Noldorin> lol
<Noldorin> lifeless: you want bzr.log?
<lifeless> Noldorin: please
<spm> lifeless: it was a team effort: you had the daunting task of telling me to "make it so"; I merely had to do the steps. :-P
<lifeless> spm: I am an alpha particle
<spm> ha
<Noldorin> lifeless: http://pastebin.ca/1537092
<lifeless> hey, better than claiming to be cpt kirk
<Noldorin> *confused*
<lifeless> Noldorin: ok, this shows the error we thought was happening
<lifeless> we've done a rename
<lifeless> but we can read the old file back after the rename and delete
<Noldorin> erm, i meant confused about your comments :)
<emmajane> poolie, I've given beuno I bit of feedback as well.
<Noldorin> also confused about this ftp stuff though!
<lifeless> Noldorin: two conversations at once
<poolie> cool, thanks
<Noldorin> yeah
<lifeless> Noldorin: get a network trace of this, and the log.
<Noldorin> lifeless: i know. couldn't help but wondering though
<lifeless> and we should be able to make a demo script
<poolie> jam, i'll put up a patch for the trivial indexerror of bug 416550
<poolie> i don't know what his actual problem is
<Noldorin> lifeless: well we already have the log, no?
<lifeless> the random details will not match the network trace unless they are done at the same time
<lifeless> you need to capture the data sessions to, to have the files that are uploaded
<Noldorin> good point
<Noldorin> like the nonce values
<Noldorin> yeah, never mind.
<Noldorin> late night debugging for the win
<Noldorin> lifeless: http://pastebin.ca/1537106 and http://pastebin.ca/1537107
<lifeless> btw, your password is in clear text in the traces... you may want to change it ;)
<emmajane> poolie, maybe I ping Joey for that though...
<poolie> hi lifeless
<lifeless> Noldorin: can you see if you can read /texdotnet/.bzr/branch-lock/held/info ?
<Noldorin> lifeless: manually?
<lifeless> the trace didn't capture file contents
<lifeless> yes
<Noldorin> ok
<Noldorin> erm, there's nothing in branch-lock/
<Noldorin> lifeless: ..?
<lifeless> so
<lifeless> the server has deleted it
<lifeless> what are you capturing with ?
<Noldorin> wireshark
<lifeless> we need to make it capture the uploads
 * igc ignores email for a few hours and gets back to wrapping up the upgrade patch
<Noldorin> ok
<Noldorin> what port is that?
<Noldorin> (i know that it uses a different connection, from my memory of the ftp protocol)
<lifeless> its dynamic
<lifeless> 227 Entering Passive Mode (213,175,198,12,9,122)
<lifeless> hmm
<lifeless> ok
<lifeless> another small patch
<Noldorin> ok
<lifeless> === modified file 'bzrlib/transport/log.py'
<lifeless> --- bzrlib/transport/log.py     2009-07-01 07:29:37 +0000
<lifeless> +++ bzrlib/transport/log.py     2009-08-21 00:39:32 +0000
<lifeless> @@ -143,6 +143,7 @@
<lifeless>          return return_result
<lifeless>  
<lifeless>      def _shorten(self, x):
<lifeless> +        return x
<lifeless>          if len(x) > 70:
<lifeless>              x = x[:67] + '...'
<lifeless>          return x
<lifeless> then add log+ to the start of the url you push to
<Noldorin> kk
<Noldorin> network trace again?
<lifeless> yes, both again in fact :)
<Noldorin> lifeless: interesting. after i delete the push dir on the ftp server, i have to wait a while before bzr will let me push again
<Noldorin> ~20/30 seconds
<Noldorin> i wonder if that has anything to do with this issue
<lifeless> does bzr pause, or error, or ?
<Noldorin> lifeless: http://pastebin.ca/1537136 and http://pastebin.ca/1537132
<Noldorin> bzr: ERROR: At log+ftp://alexreg-repos@213.175.198.12/texdotnet you have a valid
<Noldorin>  .bzr control directory, but not a branch or repository. This is an unsupported
<Noldorin> configuration. Please move the target directory out of the way and try again.
<Noldorin> started working soon enough though, and that just disappeared.
<lifeless> yes
<lifeless> thats identical behaviour
<lifeless> deletes taking a long time to actually be deleted.
<Noldorin> thought so
<Noldorin> is that the root of all our problems here then, do you think?
<Noldorin> or just another symptom?
<lifeless> Its the root behaviour causing the problems; what drives it I don't know
<Noldorin> yeah, fair enough
<Noldorin> anything helpful in those new logs i just pasted?
<lifeless> yes, we've got the data now
<lifeless> Noldorin: whats the bug number for this?
<Noldorin> lifeless: https://bugs.launchpad.net/bzr/+bug/412244
<lifeless> Noldorin: ok, I've attached sanitised versions to the bug
<lifeless> its late for you, I think
<lifeless> so you should go crash
<lifeless> when you get up, we now have enough data that you can use the StringO stuff in the log trace + the network trace to make a test
<Noldorin> heh, yeah. i've given enough hints as to that
<Noldorin> right
<lifeless> put the strings that are uploaded on disk as files with the right names so you can
<lifeless> push
<lifeless> sory
<lifeless> put FOO
<lifeless> rename
<lifeless> etc
<lifeless> etc
<lifeless> I'll help you validate the test - or anyone here can do that if you turn up while I'm not active
<Noldorin> lifeless: i'll try to catch you tomorrow evening
<Noldorin> (will i be able to?)
<Noldorin> ok
<Noldorin> cool
<Noldorin> mind summarising that in a comment on the bug?
<lifeless> sure thing
<lifeless> well, it will be my weekend
<lifeless> I may or may not be around
<Noldorin> yeah, fair point
<Noldorin> well see you, perhaps
<Noldorin> thanks again, lifeless
<lifeless> np
<Noldorin> have a good weekend
<Noldorin> bye
<lifeless> ciao
<poolie> lifeless: i propose to look at your specific-files-commit thing now
<poolie> john says in https://code.edge.launchpad.net/~lifeless/bzr/commit-specific-files/+merge/9413 there's a previous patch - is that still outstanding, and if so what is it?
<lifeless> iter-changes-partial-parents
<lifeless> its the machinery patch
<poolie> ok and that ends up with you saying you found two bugs and you'd fix them after lunch
<lifeless> and then discussion on the list
<poolie> ok
<lifeless> [meta: this goes back to 'why aren't reviews on the list like they were with BB' :P]
<poolie> we just had that thread
<lifeless> yes, I saw. We had had it before anyway, when we started using code reviews.
<lifeless> and we filed code reviews bugs at the time
<poolie> maybe it should be in a wave
<poolie> email tends to get thread fragmentation too
<lifeless> waves look like a really good fit for bugs
<lifeless> perhaps code too
<poolie> one of the problems is that email doesn't have practically usable urls that you can pass around
<poolie> can you give me the subject of the thread about this?
<poolie> there are a lot mentioning "commit" :) and none apparently mentioning that branch
<poolie> ok i have it
<poolie> "iter_changes, delta consistency and revert"
<igc> poolie ping
<igc> poolie: can we chat re upgrade when you're free?
<igc> poolie: I'd like to discuss the exception catching and whether we should continue with other branches if one fails say
<lifeless> poolie: bug 375013
<lifeless> poolie: I had that set deliberately :(. I thought I was clear in my comments as to why its not closed...
<lifeless> I'd like to know how I can make it clearer in future to avoid us churning.
<FryGuy-> are there any read-write plugins for git?
<lifeless> poolie: comment #6 specifically
<elmo> wildly off topic, but I suspect people here now; are svn revision numbers monotonically increasing within a single tree?
<bob2> yes
<elmo> ta
<igc> elmo: not like bzr though to my knowledge ...
<igc> elmo: svn numbers increase across the repo I think
<lifeless> elmo: no
<bob2> oh, oops
<elmo> haha
<lifeless> elmo: they are monotonically in a svn repo
<lifeless> elmo: they are strictly increasing in a single tree
<igc> elmo: so, IIUIC, the number will increase with a tree but not necessarily be contiguous
<igc> s/number/numbers/
<igc> s/with/within/
<lifeless> elmo: its a single global counter stored in the svn repository - revno in svn is 'transaction sequence number'
<igc> FryGuy: try the bzr-git plugin
<elmo> lifeless/igc/bob2: ta
<lifeless> anytime
<spiv> lifeless, poolie: pyflakes-vim: http://www.vim.org/scripts/script.php?script_id=2441
<lifeless> spiv: heh, yes. saw on facebook yesterday :)
<spiv> :)
<spiv> I remembered it just now because it just happened to highlight some clearly broken code in get_raw_records, which is a bit alarming.
<spiv> I guess the codepath that tries to use the undefined 'current_list' is never triggered...
<igc> lifeless: it looks like upgrading of a shared repo + branches from 0.92 -> 2a is broken currently
<lifeless> igc: how so?
<igc> lifeless: at least as documented in the Upgrade Guide
<igc> lifeless: the shared repo upgrades ok ...
<igc> lifeless: but then trying the branch errors ...
<igc> NoSuchRepository
<spiv> I need to merge mwhudson's lazy_import awareness patch for pyflakes into that vim plugin though.  It's a bit of a shame that it has effectively a fork of pyflakes (to make it faster and also report column numbers)...
<igc> yet info, check and everything else seem ok
<lifeless> igc: how is the repo being upgraded/branch being upgraded?
<FryGuy-> igc: the plugins page said it was read-only, as in i could only branch from git, and not push changes back
<lifeless> [point me at the uprade guide bit that talks about this]
<igc> cd repo; bzr upgrade
<igc> http://doc.bazaar-vcs.org/bzr.1.18rc1-html/en/upgrade-guide/index.html#migrating-branches-in-a-shared-repository
<igc> cd branch-in-repo; bzr upgrade
 * igc pastebins
<lifeless> igc: looks like a regression in upgrade
<lifeless> its probably the fix from poolie to read off disk
<igc> lifeless, poolie: http://pastebin.com/m7178eb8e
<lifeless> igc: have you filed a bug ?
<igc> lifeless: not yet ...
<lifeless> please do :)
<lifeless> I'm fixing now
<igc> I'm tracking down why my upgrade patch isn't working and it seems it's in trunk without my changes
<igc> lifeless: filing bug now
<poolie> mm that probably is my change
<poolie> so the repo is actually ..?
<lifeless> you have to call the api to find it
<lifeless> or handle one not being there.
<poolie> sure
<poolie> i thought i only changed the destination format determination though
<igc> poolie: so the repo and trunk were both 0.92
<poolie> igc, assign it to me
<igc> step 1: upgrade repo - that works
<igc> step 2: upgrade branch - that falls over
<lifeless> igc: the formats don't atter
<igc> alter? matter?
<lifeless> matter
<igc> I suspect not
<lifeless> possibly broken earlier actually
<lifeless> mmm, no. 4608 broke it
<lifeless> fixed
<lifeless> sending for review
<spiv> Hmm, I wish that pdb would let me skip over yield statements (the way 'next' skips over function calls) rather than taking me back to the caller.
<lifeless> that would be nice
<lifeless> of course there's no guarantee it will get back
<spiv> Yeah.
<lifeless> and unlike next it won't see exceptions raised in  the interim
<spiv> I can see why they haven't implemented it, but I don't really care ;)
<igc> thanks lifeless - I'll test out the fix
<spiv> The point of a debugger is to do hard things for me ;)
<lifeless> does pdb do breakpoints?
<lifeless> if so
<lifeless> breakpoint +1
<lifeless> continue
<lifeless> wouldn't be horrible
<spiv> It does, although I've always found them cumbersome so virtually never use them.
<spiv> Maybe it's less cumbersome than unwinding three levels of generator yields and then going back in again...
<lifeless> 1) get a cumbersome recipe. 2) patch to make it easier ;)
<spiv> Right :)
<poolie> lifeless: i don't see the mp
<poolie> trivial review wanted: https://code.edge.launchpad.net/~mbp/bzr/trivial/+merge/10501
<lifeless> https://code.launchpad.net/~lifeless/bzr/upgrade/+merge/10502
<lifeless> poolie: I'd like a test in test_errors  for that, showing the sort of data we were seeing
<lifeless> poolie: with that, I'm +1
<poolie> lifeless: me too, but it's the kind of thing that gives an unsatisfying test
<poolie> if i directly raise a socket error
<poolie> do we know that's consistent with what python does?
<poolie> i guess i could actually make and then fail to bind a socket
<lifeless> I was meaning static data actually
<lifeless> but sure, if it needs a socket to make the old code break..
<poolie> ah yes, that's better
<poolie> ^ re your patch
<igc> lifeless: that test mightn't be good enough?
<igc> lifeless: make_branch_and_tree calls make_branch which always creates it's own non-shared repo IIUIC
<lifeless> igc: how do you mean?
<lifeless> igc: thats why the delete_tree is there :P
<lifeless> igc: try the test without my change to bzrdir.py, if you doubt :)
<igc> lifeless: ah
<lifeless> there was the opprtunity to yak shave
<lifeless> but we're a little short on time at the moment
<poolie> igc: ~poolie is not me
<poolie> and lp has a huge bug that it lets you make that mistake :}
<poolie> i'm ~mbp
<igc> poolie: well LP *did* tell me assigning to poolie was unusual ...
<lifeless> I thought lp queried on new assignees
<lifeless> ^^
<poolie> i do actually write some code you know :)
<igc> because poolie didn't have any other assignments in bzr
<lifeless> igc: it probably will never query again now :)
<poolie> oh i thought it would do that
<poolie> but it's still a bit barn-door-horse
<lifeless> poolie: how many times should it ask though?
<igc> poolie: I went to fix it but the fast moving lifeless had assigned it to himself before I could blink
<poolie> you should be able to just point to one of the common reviewers
<lifeless> personally, I think it should just do it and tell you it was odd afterwards
<poolie> s//contributors
<poolie> there's no good reason you should need to remember
<lifeless> with type-completion listing the folk it knows
<poolie> iow vocabularies should prioritize the likely choices
<poolie> lifeless: i replied to the iter_changes thread
<poolie> i'm not sure that will have unblocked it though
<poolie> what do you think would be a good next step?
<poolie> i can think of
<poolie> 1- read the patches in detail
<poolie> 2- just decide the knownfailure is ok
<poolie> i don't have a problem with 2 for this particular case but it is a concern if this is likely to cause bugs with code making assumptions about the change lists
 * igc lunch
<lifeless> poolie: the knownfailure is the symptom of the API change; Aaron's objections are to the API change, and you also express some concern about it not being symmetrical.
<poolie> right, exactly
<poolie> so i'm trying to work out if those concerns are well founded or not
<lifeless> our UI works on symmetric deltas; our core works on asymmetric deltas.
<lifeless> (e.g. 'bzr diff A B' == reverse_patch(bzr diff B A)
<lifeless> but push A B doesn't send the data A is missing from B, only the data needed to be added to B to have A
<poolie> right
<poolie> and that's actually a bit of a .. well, not accident, but specific choice for this ui
<poolie> it'd be reasonable for someone to want a diff output format that's not symmetric for file deletions
<lifeless> right
<poolie> or indeed not symmetric at all, like ed diffs
<lifeless> so this patch matches bzr diff A B != reverse_patch(bzr diff B A)
<lifeless> *when specific paths are used and inconsistent states would be encountered*
<poolie> even for diff?
<lifeless> yes
<poolie> so one way to make that look less weird is to specif
<lifeless> currently diff will skip alterations to the parents of the names files
<lifeless> and all the related logic
<poolie> bzr_diff(A, B, paths_in_A) != reverse(bzr_diff(B, A, paths_in_B))
<lifeless> yes
<lifeless> precisely
<poolie> is that it?
<poolie> k
<lifeless> well, modulo the fact that we look for paths in [A B]
<lifeless> but thats part of our 'expansion for correctness' logic as well
<poolie> ok so it's actually
<poolie> paths_in=(A, B) vs paths_in=(B, A)
<poolie> or maybe not even precisely that, but the point is that there's more going on here than just the main two inputs
<lifeless> roughly. Its hard to reason about even before the patch.
<lifeless> The key bits are: we diff more than just the named paths; the patch means that 'more' becomes larger when directory changes are involved, and does so assymetrically.
<lifeless> now, named paths diffs don't turn A into B, or vice verca - they are explicitly a subset of the changes.
 * poolie looks at the revert code
<abentley> poolie: I'm around, if you have questions about it.
<lifeless> hi abentley
<abentley> lifeless: hi
<poolie> hi, welcome back
<abentley> poolie: thx
<poolie> actually it's not so much answers about the code i'm looking for as a decision about iter_changes
<poolie> see the scrollback and the list
<poolie> igc or others - any comments on the new slimmer http://bazaar-vcs.org/Roadmap
<abentley> poolie: I've thought about the issues on vacation, though I haven't read tonight's list discussion and I've been offline for ~5 hours.
<poolie> well
<poolie> i don't mean to pull you into it in your evening
<poolie> unless you want to
<abentley> darn flaky wifi.
<abentley> poolie: I don't have clear answers, but I do have the nagging feeling that what commit wants is a similar-but-different API to what revert, shelve, merge, and possibly status want.
<poolie> maybe so
<poolie> at any rate it sometimes needs more data
<poolie> it seems like it should use the same expansion rules
<poolie> iow status should be pretty similar to commit --dry-run
<abentley> poolie: When a parent directory is renamed or moved, should status report that the children have had their path change?
<poolie> abentley: i'd be ok either way tbh
<poolie> perhaps at the api level it should
<abentley> I like the way status works right now.
<lifeless> abentley: do you mean unaltered children?
<poolie> and then at a ui level it might decide that it wants to show the minimum description
<abentley> lifeless: Yes.
<lifeless> abentley: because that isn't changing
<poolie> what does it do now?
<abentley> lifeless: You proposed that "bzr status foo/bar" should report a change to foo.  This is how I extrapolated that.
<lifeless> abentley: if foo has changed, it should yes.
<abentley> lifeless: Even though bar is unaltered?
<abentley> lifeless: Anyhow, I know that if I merge, revert or shelve foo/bar, I don't want to affect foo.
<lifeless> no
<lifeless> if bar hasn't changed, bzr st foo/bar won't report a change to foo
<lifeless> robertc@lifeless-64:/tmp/test$ ~/source/baz/pending/iter-changes-partial-parents/bzr st foo/bar
<lifeless> robertc@lifeless-64:/tmp/test$ bzr st
<lifeless> renamed:
<lifeless>   a/ => foo/
<lifeless> Quite separately to why I'm working on this, there is a bug open that 'bzr st foo/bar', when bar is changed, and foo is renamed, doesn't show foo as changed.
<lifeless> I think some users might like bzr st foo/bar to always show changes to foo; I haven't formulated an opinion on that.
<lifeless> abentley: if you're shelving foo/bar, and foo was renamed; it seems reasonable to me to be asking if the dir should be renamed back. A file-only based VCS would ask about renaming foo/bar back to old/bar
<abentley> lifeless: Oh, I could have sworn that you held that bug up as another example that your approach was the correct way to go.
<abentley> lifeless: Why?  If I go to the dry cleaner to get a shirt cleaned, they don't offer to shower me, too.
<lifeless> They also don't offer to put the threads back into the spiders they came from
<abentley> lifeless: I'm saying "shelve changes to bar".  Shelving changes to foo is not what I want when I ask for that.
<abentley> lifeless: If I want to shelve changes to foo, I can ask for that.
<lifeless> I'm looking for that bug, I can't easily find it :(
<lifeless> abentley: arguably, being at 'foo/bar' is as much of a change to the file as the content changes
<poolie> so i'd like to work out what we have to do to get this unblocked
<poolie> i can see how the expansion might not always be what you want but it's not clearly wrong
<poolie> and there does seem some risk in having asymmetric deltas but that's not clearly wrong either
<abentley> lifeless: But from that perspective, reverting foo is also affecting all the other files in foo, which doesn't align well with the user's minimal request.
<abentley> poolie: I think if we want to maintain iter_changes as a single method, we should have a flag to specify when we want this asymmetric expansion.
<poolie> otherwise it would do no expansion at all?
<lifeless> so there are bits here
<abentley> poolie: It would behave the way it does now, which recurses into subdirectories.
<lifeless> symmetry and correctness
<lifeless> we can make it symmetrical always, at the cost of larger deltas in some corner cases.
<lifeless> and those larger deltas - I don't like  them for the same reason you're arguing against foo being reported
<abentley> lifeless: And at the cost of having to filter it to get the current behaviour back.
<lifeless> they make 'small' requests into larger ones
<lifeless> the expansion to ensure consistent deltas is something that I firmly believe has to be enabled for commit+diff+status+revert.
<lifeless> Those four because: status and diff should show what commit and revert will do
<poolie> i can't remember, is it actually correct that reverting a file in a renamed directory will revert everything else in there?
<lifeless> I think it would be odd and require explanation to have shelve do things differently to revert.
<poolie> or just the rename of the directory?
<lifeless> poolie: it won't with my patch
<abentley> poolie: It will rename the directory.
<lifeless> it would revert that file, and rename the directory back.
<lifeless> which is the same set of changes 'commit' would do given that path.
<lifeless> in fact
<lifeless> its the same set of changes commit /commits today/ given that path.
<abentley> lifeless: So, I don't think that commit foo/bar should commit a rename of foo, either.
<lifeless> abentley: Just to be clear; you are aware that thats what it does at the moment - and always has.
<abentley> lifeless: No, I was not aware that it did that.  I consider that a bug.
<poolie> so maybe you'd want a "strictly minimal" mode
<poolie> i'm not sure that should be any different between commands
<poolie> or that the default would differ
<lifeless> $ bzr st
<lifeless> brenamed:
<lifeless>   a/ => foo/
<lifeless> robertc@lifeless-64:/tmp/test$ bzr commit -m '2' foo/bar
<lifeless> Committing to: /tmp/test/
<lifeless> renamed a => foo
<lifeless> Committed revision 2.
<abentley> lifeless: Anyhow, the argument could be made that since status, diff, revert and shelve *don't* do this expansion, it's commit that should change.
<lifeless> abentley: I'm open to that argument
<lifeless> However, how should commit change?
<igc> poolie: roadmap page looks fine to me - I tweaked my wishlist as well
<lifeless> foo and bar might not exist in the basis, so its impossible to commit foo/bar at all without commiting foo
<abentley> lifeless: I suggest commit should commit adds of parent directories, not renames, and possibly not deletions.
<abentley> lifeless: I'm trying to think of an example where a deletion of a parent would be necessary in order for a commit to succeed.
<lifeless> what about paths, should commit show the path in the committed tree or the path in the working tree of stuff committed?
<lifeless> if it shows the committed tree, status should match, so status should start reporting paths that aren't on the disk in front of the user.
<poolie> lifeless, abentley: so I'm feeling there is more to do here, but it's not something we should block this patch upon
<lifeless> if commit shows the paths from the working tree, then what it actually committed may be very different and confusing to users.
<poolie> would you be desperately unhappy with that?
<abentley> lifeless: I would think working tree.
<lifeless> => this means we might commit a change to 'NEWS' that actually alters a file README.txt in the repository.
<lifeless> mm, to simple an example. Needs a dir - but the idea is obvious
<lifeless> I think it would mean we need to start reporting both paths.
<abentley> lifeless: no matter which tree you show, it will be confusing.  I think the working tree is less confusing.
<lifeless> to be understandable
<lifeless> at the moment the two paths are always the same.
<abentley> poolie: I need to look at the patch.
<poolie> ok, that'd be good
<poolie> but in principle yes?
<poolie> i'm just trying to work out what to do to get this disposed of
<abentley> poolie: No, in principle it sounds like muddling low-level technical details with UI issues.
<abentley> poolie: It doesn't sound like this was necessary to solve the InconsistentDelta issues.
<poolie> i'm trying to understand the first one of those
<poolie> because to me it sounds like the issue that iter_changes should generate consistent deltas is a concern at the level of deltas
<poolie> not a ui concern
<e-jat> hi .. can i use svn n bzr in the same branch ?
<abentley> poolie: It has never been part of the contract of iter_changes that the deltas it generate are consistent in this way.  The desire for this kind of consistency stems from the way commit uses iter_changes, AIUI.
<lifeless> e-jat: kindof; you can use bzr-svn to push and pull between svn and bzr
<lifeless> e-jat: I would suggest having separate trees for the bzr and svn copies though
<poolie> but can't we get similar issues applying inconsistent deltas to the wt eg from revert?
<e-jat> lifeless: thanks for the info ..
<abentley> poolie: No.
<lifeless> poolie: yes, but tree transform has a bunch of machinery to fix these up. The no parent for 'new-5' style bugs are where this is falling down.
<e-jat> so i need to svn export 1st . .then copy it to bzr branch ?
<abentley> poolie: tree transforms go through resolution to handle these cases.
<lifeless> e-jat: no, install bzr-svn
<lifeless> e-jat: then bzr branch svn://foo/bar/baz
<e-jat> lifeless: i hv installed bzr-svn
<e-jat> do that inside the svn branch ?
<lifeless> do it where you want the new bzr branch to be made
<abentley> poolie: Now that tree transforms can be committed, it would even be possible for commit to take advantage of this machinery.
<e-jat> lifeless: thanks ... let me try it 1st ..
<poolie> so, can i help with this at all, or should i leave it to you two to sort it out?
<poolie> or ..?
<abentley> lifeless: Do you feel that it is necessary to change iter_changes in order to fix commit?
<lifeless> Yes, or end up reimplemnting some key chunks o it outside to allow external expansion - and change record_iter_changes to be given both trees to do said expansion
<abentley> lifeless: What about explicitly adding all parents to the iter_changes invocation?
<lifeless> that ends up gathering the entire tree every time (because iter_changes spiders down)
<lifeless> if iter_changes had a non-recursive flag you could do iter_changes[paths], then iter_changes(parents, non_recursive) and filter out any parents already seen
<lifeless> but that still isn't enough, because you need to also include the children of deleted directories where the delete was at the same path as a parent you had to add
<abentley> lifeless: I imagine you wouldn't be in favour of doing the filtering after running iter_changes?
<lifeless> but you don't want to recurse to the children of those children, as the user didn't request them
<lifeless> performance tests show that filtering after doing the full tree is adequately fast on large trees *with hot cache*
<lifeless> but the actual filtering algorithm needed ends up being roughly all of iter_changes anyhow
<lifeless> commit is robust against bad deltas now, so I don't have a strong correctness reason for doing it elsewhere - the worst that will happen is a crash in commit with it refusing to commit.
<lifeless> OTOH doing it in iter_changes means that anyone using iter_changes, or a per_intertree tested version of iter_changes, will be able to pipe their iter_changes through commit with confidence.
<lifeless> ideally, we wouldn't do iter_changes on paths we don't need to, to avoid stating and checking irrelevant files.
<lifeless> if we improve dirstate some more, we should be able to make selective commit really really fast, and thats where doing a full iter_changes would really show up
<abentley> lifeless: my feeling is that if you really need to implement this in iter_changes, you should add a flag to toggle the behaviour, so that we can have the UI discussion without the pressure of blocking a fix.
<lifeless> so; I'm open to that in principle but - I really believe that commit+revert should match status+diff. I'm not sure what commands then, would pass in the flag (or conversely not pass in the flag)
<abentley> lifeless: I really believe that the existing behaviour of revert, status and diff is the best one, and I don't want to have this discussion under pressure.
<lifeless> then have the discussion at a slower rate :)
<lifeless> sleep on it
<lifeless> I'll have a think about ways to land this without changing that behaviour over the weekend
<abentley> lifeless: works for me.
<abentley> poolie: I would appreciate it if you would review https://code.edge.launchpad.net/~abentley/bzr/devnotes/+merge/8766
<poolie> hi, i know
<Kamping_Kaiser> is someone aware of a bzr or bzr-svn cheat sheet?
<lifeless> in the docs, there is a reference card
<Kamping_Kaiser> bril, thanks :)
<vila> hi all
<Kamping_Kaiser> can bzr suck all the details out of an SVN repo (over http) without access to a dump from the svn server?
<bob2> yes
<Kamping_Kaiser> win. thanks again :) *goes to investigate*
<poolie> vila: hello
<poolie> i might call it a day
<poolie> spiv, how did you go with that bug?
<vila> gag of the day: try 'bzr stats' on bzr trunk.... laugh... wonder who will fix that first :-)
<fullermd> Wassat?
<spiv> poolie: it's going well, I've figured out how to hack some simple batching in.  Currently testing/debugging the batching logic I've added.
<poolie> cool
<poolie> i'll mark it inprogress then?
<spiv> Oh yes, please do.
<poolie> all right
<poolie> have a great weekend
<poolie> regards to m
<spiv> With some luck I'll have some useful comments to add to that bug shortly :)
<vila> have a great weekend poolie !
<spiv> Ooh good, looks like it's working when I fetch Launchpad via HTTP, although there is a selftest failure.
<spiv> Ok, and with that pushed up I'm off.  Have a great weekend everyone.
<spiv> vila: oh, and hello and goodbye :)
<vila> spiv: bye, have a great weekend
 * igc dinner
<NEBAP|work> can somebody help me out with a conflict?
<vila> NEBAP|work: Don't ask to ask, ask
<vila> The answer and the people than can answer can and will be different depending on the question :)
<NEBAP|work> k
<NEBAP|work> sorry
<vila> no worries
<NEBAP|work> was interrupted while writing the question ^^
<NEBAP|work> so
<NEBAP|work> IÂ´ve removed some cache files in the local branch
<NEBAP|work> using bzr rm
<NEBAP|work> also removed the hole folder
<NEBAP|work> now there is a "content conflict" in one file under the removed folder
<NEBAP|work> running bzr conflict
<NEBAP|work> shows the file
<NEBAP|work> but using bzr resolve FILE tells me "there is no conflict in ...."
<NEBAP|work> so what should I do?
<vila> That happens when you merge a branch where FILE has been modified
<vila> what does 'bzr st' says ?
<NEBAP|work> one second
<NEBAP|work> tells me: "removed folder xxx", "unknown folder xxx.moved" and "content conflict in xxx.xxx" (which is the file that makes the problem)
<vila> so, you'll have to look into xxx and xxx.moved and make sure the files you want are in the right place with the right content and remove the others
<vila> err, what do you mean with xxx.xxx ?
<vila> xxx/yyy ?
<vila> err xxx/FILE ?
<NEBAP|work> xxx.xxx just an example like "test.txt"
<NEBAP|work> the file is present
<NEBAP|work> bazaar created to files
<NEBAP|work> xxxx.xxx.BASE and xxxx.xxx.OTHER
<NEBAP|work> using bzr mv didnÂ´t work because the files were removed in the local branch
<vila> .BASE, .THIS, .OTHER are for text conflicts, these ones get remoed when you do 'bzr resolve'
<NEBAP|work> so I renamed xxxx.xxx.OTHER to xxxx.xxx and then bzr resolve xxxx.xxx (which worked for one file, but not for a second one)
<vila> .moved are for content conflicts and 'bzr resolve' does not remove them
<vila> I think you have a conflict on a directory not on a file
<NEBAP|work> hmm
<NEBAP|work> itÂ´s a content conflict (according to bzr conflicts)
<vila> 'bzr conflicts' will tells you which items are still seen in conflicts by bzr
<NEBAP|work> yes
<vila> right, can you paste the output somewhere ? 'bzr st' and 'bzr conflicts' ?
<NEBAP|work> yes, just give me a second ;)
<vila> if things are confidential we may do that in PMs if you prefer
<vila> I'd rather look at the true names than asking you to make them anonymous and risk missing a detail
<fullermd> You can't reveal your True Names!
<vila> pff, as long as nobody takes pictures....
<NEBAP|work> vila: http://pastebin.com/d1fdc9a0b  (just removed my name and email)
<vila> hmm, PDA/trunk/TX Event/obj is the directory you don't want to version anymore ?
<NEBAP|work> yes
<NEBAP|work> IÂ´ve removed it in the local branch
<vila> is obj.moved empty ?
<NEBAP|work> no it isnÂ´t
<NEBAP|work> there is also the file that has the conflict
<vila> but you don't care about that file anymore right ? And that's the only file there ?
<NEBAP|work> I donÂ´t need that files anymore
<NEBAP|work> but there are still more files
<NEBAP|work> all files that were in the obj folder before
<vila> are they versioned ?
<NEBAP|work> but I donÂ´t need them, just cache files
<NEBAP|work> they were
<NEBAP|work> but then IÂ´ve removed the hole folder
<NEBAP|work> and added it to the ingore file
<vila> ohhhh
<vila> obj has been deleted is not versioned anymore in the local branch and is in .bzrignore, correct ?
<vila> can you delete obj.moved without losing anything ?
<NEBAP|work> yes
<NEBAP|work> obj is still there (bzr rm obj --keep) but is not versioned anymore
<vila> do that and try 'bzr resolve <path leading to>obj
<NEBAP|work> and IÂ´ve added it to .bzrignore
<NEBAP|work> k
<vila> wow, anyway, that's worth reporting as a bug (once we get you out of trouble)
<NEBAP|work> ^^
<vila> I may be wrong, but it could be that bzr fails to properly report some info because there is a conflict on a path that is now ignored... or something weird like that
<lifeless> vila: I suspect the search only looks at one of the paths involved
<NEBAP|work> k used "bzr rm xxx/obj.moved --force" (-> folder deleted)
<vila> NEBAP|work: and ?
<NEBAP|work> then "bzr resolve xxx/obj" (-> no conflicts)
<vila> \o/
<NEBAP|work> then "bzr resolve xxx/xxxx.xxx" no conflicts
<NEBAP|work> but
<NEBAP|work> there is still the one confilct using "bzr conflicts" ^^
<vila> can you paste again ?
<NEBAP|work> sure, one moment ;)
<vila> and tell me precisely what 'bzr resolve PATH' you issued ?
<NEBAP|work> vila: http://pastebin.com/d314477f4
<NEBAP|work> vila: "bzr resolve "PDA/trunk/TX Event/obj/Release/TX Event.csproj.GenerateResource.Cache"
<vila> try: 'bzr resolve "PDA/trunk/TX Event/obj'
<vila> lifeless: by the way, can't that be related to your iter_changes patch ? (As in will your patch change anything here ?)
<NEBAP|work> I also tried "bzr resolve pda/trunk/tx event/obj" which told me: no conflicts
<vila> PDA not pda ?
<NEBAP|work> yes used both, but its a windows machine which doesnÂ´t care
<NEBAP|work> iho
<NEBAP|work> *imho
<vila> hmpf
<lifeless> vila: it wouldn't change merge at all; it might (but I doubt it) change partial-path merges
<vila> NEBAP|work: 'bzr rm "PDA/trunk/TX Event/obj/Release/TX Event.csproj.GenerateResource.Cache"'
<NEBAP|work> vila: deleted file
<NEBAP|work> confilct is still there
<vila> bzr resolve it now
<vila> argh, no, we still think there is no conflict there :-/
<vila> correct ?
<fullermd> If the file is gone, a straight 'bzr resolve' should notice and catch it...
<vila> fullermd: works only for text conflicts no ?
<fullermd> I thought it caught things like this too,; if it's not there, it can't very well be conflicting.
<NEBAP|work> vila: youÂ´re my hero, that did the trick ;)
<vila> what ?
<NEBAP|work> vila: removed file, solved the conflict, commited and pushed back to the server WITHOUT errors :D
<vila> ok, so the bug is that 'bzr resolve FILE' saying no conflict here is highly misleading,
<vila> NEBAP|work: can you file a bug explaining that ?
<NEBAP|work> puh ^^
<NEBAP|work> I donÂ´t understand where the problem was exactly
<NEBAP|work> I just know the resolve didnÂ´t see the conflict
<vila> 'bzr resolve FILE' told you: no conflict here, bad resolve, tricked you
<NEBAP|work> yes
<NEBAP|work> thatÂ´s it :)
<vila> yes, that's a bug, you were on the right track and bzr tried to derail you
<NEBAP|work> k
<vila> it derailed me too :D (I thought totally wrongly that the conflict was related to the directory)
<NEBAP|work> where should I paste that?
<NEBAP|work> :D
<NEBAP|work> but you found the problem yeah
<vila> https://bugs.launchpad.net/bzr/+filebug
<NEBAP|work> BIG THANKS if I didnÂ´t said it before
<vila> Always happy to help (tm)
 * vila realizes once again that 1) You always found in the last place you search for, 2) Most of the steps that leads to a bug fix are misleading :)
<NEBAP|work> ^^
<NEBAP|work> oh lunchpad crashed with my request ^^ will try it in a few minutes ..
<vila> NEBAP|work: thanks
<NEBAP|work> np, should help other people that face the same problem ;)
<vila> yup, that's the idea and also ensure we'll fix the problem
<NEBAP|work> :)
<bialix> garyvdm, igc: hi guys
<bialix> hello all as well
 * fullermd waves at bialix.
<vila> hello bialix
<bialix> fullermd: hi!
<bialix> vila: bonjour!
 * bialix waves back
<bialix> (I hope it's right)
<bialix> beuno or whoever: this new UI in edge LP is awesome
<bialix> vila: about "the size plugins":  I've tried to lightly joking on your typo
<vila> :-D
<bialix> vila: I hope you get it right ;-)
<bialix> vila: sorry, was unable to read your patch yesterday. I've tried to kick qbzr 0.14 off
<vila> no problem, I replied with more info and hopefully a better explanation about why I wanted you to be involved
 * bialix wonders how I can subscribe on comments for only interesting merge proposals
 * bialix don't want to get entire discussions on all proposals
<fullermd> It's right below the button to auto-approve good merge proposals  :)
<bialix> auto-approve? interesting
<bialix> bb:+1 working there? cooooooooool
<vila> fullermd meets beuno, beuno meets fullermd
<bialix> :-)
 * bialix trying to write awesome announcement for qbzr 0.14
<Noldorin> lifeless: hello?
<bialix> vila: I can answer any questions about windows specific plugins locations
<bialix> vila: just don't say I need re-read entire discussion of you and jam
<vila> bialix: no, it's a different email focused only on 'site' directory
<bialix> vila: yesterday you have questions. today I have time for answers.
<vila> bialix: I wrote them down in the email
<vila> roughly: what is a good definition for 'site' on windows for the various installers ?
<bialix> fullermd: "It's right below the button to auto-approve good merge proposals  :)" -- it was joke, heh?
<vila> but look at the mail
<bialix> vila: what is the "site" for non-windows then?
<vila> explained in the mail too :)
<bialix> so I have to read your recent mail I suspect?
<vila> that may help keep the S/N ratio high here :)
 * bialix mutters: why oh why there is no RSS for merge proposals?
<fullermd> bialix: Yah; if we can teach LP how to recognize good MP's and auto-merge them, we can make it recognize interesting discussions and send them to you  ;>
 * bialix reads email from vila
<bialix> fullermd: ah. yes. brilliant idea!
 * fullermd nods.
<fullermd> I've done my part coming up with the idea.  Now we just wait for vila to implement it!
 * vila not working on lp :)
<fullermd> You can't use that as an excuse forever.
<vila> As long as it works...
<bialix> LOL
<vila> but that reminds me that I should play again with mail scoring....
<vila> from == fullermd => fun++, from == vila => must_read++++ sort of thing :)
<bialix> vila: what you expect to hear from me?
<bialix> vila: q: what if I'm run bzr from sources
<vila> bialix: what can be used for 'site' for bzr.exe, when running from source, etc
<vila> bialix: *I* ask the question first !!!
<bialix> vila: bzrlib even don't try to load plugins from C:\Python25\Lib\site-packages\bzrlib\plugins
<vila-fud> back later
<bialix> rats
<vila-fud> yes, that's what I want to change !
 * fullermd wishes it wouldn't...
<bialix> vila: I don't understand fully all your intents and you run away!
<bialix> vila: it's not fair!
<luks> yeah, I had problems with that on linux earlier
<luks> I had old bzr with old plugins from ubuntu installed in /usr/lib
<luks> and my local bzr was trying to use those plugins, which of course failed
<fullermd> It caused me a huge pile of aggravation when I was trying to quantify the cost of loading the lp plugin.
<fullermd> I'd chmod it off, and it somehow kept loading!  Move it out of the way, still loaded!  Overwrite the files with exorcistic incantations, then delete them and bury them face-down, still loaded!
<fullermd> 10 minutes in, figure out it was loading the LP plugin from the installed bzr.  Nnnnngh.
<bialix> excellent
<bialix> it seems I'm only one happy person with bzr.exe
<fullermd> Well, bzr.exe has certainly never given me any problems   ;)
<bialix> garyvdm: and again hi
<bialix> vila-fud: I've tried hard to answer your questions. But in fact it seems I don't quite understand what was your Question?
<garyvdm> Hi bialix
<bialix> hi :-)
<vila> ok ok, got some sandwiches and I'm back
<bialix> Thanks for your work on karmic battle-front. I'm working on announcement for 0.14. So people will cry if they don;t use qbzr yet
<bialix> garyvdm: ^
 * fullermd quickly uses qbzr to avoid tearing up.
<vila> same here, never encounter a single problem with bzr.exe :-D
<bialix> thats good
<vila> bialix: did you reply by mail or .. ?
<bialix> I've hit Reply (perhaps I should use Reply-All) and it was went to your inbox
<vila> fullermd: 'bzr plugins -v' reveals paths no ?
<fullermd> Sure, if you want to know where it comes from.
<bialix> vila: sent again and to lp too
<fullermd> If you think you already know, you wouldn't check, you'd just keep screaming.
<vila> bialix: ok got it
<vila> fullermd: with my proposed patch you'll do: 'BZR_PLUGIN_PATH=-core bzr <command>' :D
<bialix> vila: ya know it won't work on Windows?
<fullermd> Well, ideally I wouldn't do anything, 'cuz a bzr-from-source reading from an installed-bzr's plugin dir is bogus   :p
<vila> bialix: why ?
<bialix> 'cuz you can't set env variable for one command
<vila> fullermd: not always
<luks> vila: what is a valid use case for that?
<bialix> bad bad windows
<vila> bialix: do it ib bzr.bat then :)
<bialix> hehe
<bialix> I love this part
<bialix> I'm using bzr.exe, not bzr.bat
<vila> luks: fullermd just gave it: obscure way to *not* load a core plugin :)
<bialix> vila: btw, this is why I've tried to ask you yesterday: why not control this things via global command-line options instead of magic values in BZR_PLUGIN_PATH?
<vila> bialix: rats, so you have to use a wrapper then
<vila> haaaa
<luks> vila: I mean for loading system-installed bzr plugins from local bzr
<bialix> aaaaaaaaa
<luks> because I think in most cases the versions will not match
<garyvdm> bialix, vila: FYI, a proof of concept qcommit that gets a commit message from commit_message_template hook: https://code.edge.launchpad.net/~garyvdm/qbzr/read_commit_message_hook
<denys> I have been trying to use "selftest --parallel=fork", but I can't make it work :-(
<bialix> garyvdm: ok, will look at it later
<vila> luks: that's not true if you use PPAs
<garyvdm> bialix: there are some problems with it that I need to solve. When I have time.
<bialix> ok
<vila> luks: I mean, if you use bzr PPA, you'll get some plugins too, so your system stay up-to-date enough to run bzr from sources while not tracking the plugins
<vila> denys: you need lp:testtools and lp:subunit in your PYTHONPATH
<luks> vila: I don't know, I personally think it causes more problems than it solves
<luks> vila: I was actually even going to submit a patch to disable that some time ago, but I figured it would lead to a long discussion :)
<vila> luks: right, same here
<vila> that's why I implement a flexible scheme for BZR_PLUGIN_PATH, I think the default is DWIM and almost correct for almost everybody, so changing the defautl is touchy
<vila> and having the ability to override it from BZR_PLUGIN_PATH should addres the remaining cases (bzr.exe doesn't it anyway :D)
<denys> vila: thanks - just found bug #351459
<ubottu> Launchpad bug 351459 in bzr "Error in parallel selftest: cannot import name ConcurrentTestSuite" [Undecided,Invalid] https://launchpad.net/bugs/351459
<vila> denys: what OS/version are you using ?
<vila> denys: and what processor is on your host...
<denys> python 2.6.2 gentoo/linux. why?
<denys> core 2 duo (xps 1330)
<vila> denys: mostly curiosity, 5% cautious check that it *can* work :)
<vila> denys: python -c "import bzrlib.osutils ; print bzrlib.osutils.local_concurrency()"
<denys> 2
<vila> denys: You know about --starting-with selftest option right ?
<vila> it may help you more than --parallel=fork most of the time
<denys> I know now ;-) I'll give a try
<denys> thanks (off to lunch)
<bialix> luks, garyvdm: about doing heavy work in qbzr in thread/subprocess. luks said yesterday it don't make qbzr faster but more responsive. it's TRUE! I'm really tired for currently semi-frozen UI when it Loading...
<vila> denys: just try 'bzr selftest -s bb.test_serve' :)
<bialix> so this makes it "faster" for me
<vila> denys: quickly, before lunch :)
<garyvdm> bialix: More processEvents required..
<garyvdm> bialix: which dialogs?
<vila> bialix: I told garyvdm to do so long ago :)
<vila> but he said luks didn't agree :)
<vila> . o O (Now, that's starting a flame war :-D )
<garyvdm> bialix: I agree that if we had multi threads, it would be better, but It would be a huge amount of work.
<vila> bialix, luks, garyvdm : BIG REG FLASHING ===> JOKE
<garyvdm> vila: :-)
<bialix> vila: LOL, thanks for flash lights, you remember!
<bialix> garyvdm: More processEvents won;t help
<bialix> garyvdm: just today hit this: want qcommit pending merge, want to copy commit message from one revision; double click on it; qdiff opens, revision details there I see right now but can't select them and copy because diff still loading
<garyvdm> bialix: If you see that the throbber stops spinning: this is a case where more processEvents will help.
<bialix> garyvdm: huge amount of work won't stop the one who want scratch its own itches
<garyvdm> bialix: yes
<garyvdm> luks: Thoughts?
<bialix> garyvdm: current design of running heavy work in the same one thread never provides us more processEvents
<bialix> bzrlib is so slow sometimes
<luks> garyvdm: well, since it's unlikely I'll be the one looking for bugs in threaded qbzr, I don't mind :)
<garyvdm> bialix: If we were to go multi-threaded, we should have 2 threads, 1 for ui, 1 for bzrlib.
<bialix> garyvdm, luks: actually I mulling the idea about doing [possible] heavy work in several passes. E.g. loading working tree status: quickly get iter_changes and have filenames to propogate UI, and then on next pass get additional info (e.g. icons and so on)
<luks> garyvdm: you can't run UI in other than the main thread
<garyvdm> luks: yes
<bialix> or about qdiff: 1) qbuickly get list of changed files, 2) quickly get diff without syntax highlighting; 3) do highlighting
<garyvdm> bialix: Yes the type of thing that I've been trying to do.
<garyvdm> bialix: qlog is very good at that.
<bialix> qlog could be better
<luks> all I know from my experience that threading in python is fun, add bzrlib and you have 2x as much fun, add PyQt and you have 3x as much fun :)
<bialix> if we calculate dotted revnos in 2nd pass
<bialix> luks: cool, so MUCH FUN!
<bialix> :-)
<garyvdm> bialix: yes - vila: when do gdfo?
<luks> bialix: yeah, much fun for nice long evenings :)
<bialix> if you're alone
<garyvdm> bialix: When bzrlib indexes gets gdfo, we will be able to load partial bits of the graph :-)
<luks> I think that if you ever touch bzrlib from two different threads, bad things will happen
<bialix> I have written some multithreaded code in python; pyserial + tkinter actually
<vila> garyvdm: don't hold your breath :-/
<luks> so this would have to be a radical change, such as building a RPC API for bzrlib
<bialix> working with my own devices over COM-port
<bialix> luks: IIRC bzr-exlipse guys do something like this
<garyvdm> luks: yes - that's why I'm telling bialix that it would be *lots* of work
<luks> bialix: it's different when you are working on your code that you can control, and when you are interacting with code that was not designed to work that way
<bialix> luks: that's right, that's why I'd better use subprocesses here
<vila> luks: as long as you lock as you should there shouldn't be problems, do you  have specifics im mind ?
<bialix> although they will be slower on windows (noticeable startup delay)
<luks> vila: honestly, bzrlib is large enough to not trust it by default
<bialix> but subprocesses will use more than 1 core on mulitcore machines
<garyvdm> bialix: subprocess/multi thread both require a rpc layer where most of the work is.
<luks> vila: I know there are a few global variables
<luks> vila: possible other things
<bialix> and again I'm lose: I have only 1 core
<bialix> garyvdm: not exactly
<vila> luks: almost all the network tests involves threads
<bialix> garyvdm: threads will share the same memory
<bialix> supbprocesses won't
<vila> the smart server use threads (I'm pretty sure)
<luks> vila: even better
<bialix> vila: yes
<luks> vila: so you would be mixing threading libraries
<bialix> "[13:54]	<luks>	vila: honestly, bzrlib is large enough to not trust it by default" -- the same here
<vila> your code, your call, just giving my feeling :-)
<vila> do you already have use cases where you need to call bzrlib from 2 different threads ?
<bialix> vila: use case: there is no easy way to stop non-main thread in Python
<vila> AIUI you want one thread for the GUI and one for bzrlib, no problem at all here even if bzrlib uses globals (which we rarely do anyway)
<bialix> vila: how you can cancel bzrlib operation then?
<vila> bialix: that's totally unrelated to the problem of multi threads
<bialix> related
<luks> vila: yes, that's a safe thing to do, but it means building a custom API for bzrlib calls
<vila> not the one luks mentioned about using libraries that may not be thread-safe
<bialix> this is one of reason why we run actual qbzr actions via qsubprocess
<vila> anyway, you can at least stop the bzrlib operation via the progress report mechanism, but 1) that's borderline 2) not guaranteed if progress is badly implemented or if there are bugs
<vila> haaa, that's why luks talks about RPC ?
<luks> vila: we are already doing that :)
<vila> luks: sorry :-( I wish I can spend more time participating to qbzr (starting with reading the code)
<luks> killing the process is done only if we can't stop it via progress report
<vila> ha, ok
<luks> the idea here is to run everything that involves bzrlib in a separate thread or process (it doesn't really matter what)
<garyvdm> by raising an exception, and excepting and ignoring it later...
<luks> which means you need an API to talk with the bzrlib layer
<garyvdm> luks: you and I are on the same page :-)
<garyvdm> luks: and that api would be alot of work...
<luks> yeah
<luks> but on the other hand, many other projects would benefit from that
<luks> because it means you can build native extensions for IDEs, etc.
<vila> luks, garyvdm : you should discuss with verterok
<vila> like... *really*
<luks> bzr-xmloutput is really limited, from that I've seen
<luks> but I've not seen much of it
<garyvdm> luks: Would you use QThread + QEvent or something else?
<vila> bzr-eclipse
<luks> which uses bzr-xmloutput, no?
<vila> and verterok thought a lot about the design even if the code is not there
<vila> luks: I don't know the details sorry :-/
<luks> garyvdm: depends, I think I'd try to move it to a separate process rather than thread
<garyvdm> bzr-eclipse dose use bzr-xmloutput
<luks> network operations are the main reason for that
<garyvdm> ?
<luks> but vila wrote more of them, so maybe they are stoppable
<vila> luks: lol, not at all ! :)
<luks> garyvdm: well, they are using blocking sockets, so if it decides to block due to a bug, we couldn't kill the thread
<garyvdm> luks: If we were to use threads, I would still want to use the method of raising an exception in the progress_report or else where, so that finally's can run and locks can be unlocked.
<bialix> I've heard bzr-eclipse want to build their own xml-rpc wrapper arounf bzrlib because java code can't call python code directly...
<luks> garyvdm: sure, there is no other way
<garyvdm> bialix: yes, bzr-xmloutput
<luks> garyvdm: but I mean situations when the progress report callback won't be called
<bialix> garyvdm: no
<garyvdm> bialix: oh
<bialix> xmloutput is only provides xml formatted output for bzr commands
<garyvdm> luks: on timeout kill the thread...
<bialix> in this sense it similar to qbzr
<luks> garyvdm: yeah, and that's the problem, you can't kill a thread :)
<luks> you can kill a process, but not a thread
<bialix> but! I'm really not expert in eclipse dev! take my words with grain of salt
<bialix> luks: exactly
<bialix> verterok is main dev of eclipse plugin?
<garyvdm> luks, bialix: another reason why I would prefer a bzrlib thread, rather than subprocess: cache.
<vila> bialix: I think so yes
<bialix> garyvdm: cache?
<bialix> verterok from South America IIRC
<luks> garyvdm: what's the problem with that?
<bialix> garyvdm: I was wrong it seems
<bialix> garyvdm: I see something about XMLRPC in xmloutput
<luks> to be clear, I meant using subprocess as a RPC service, so that you can call it multiple times
<bialix> garyvdm: sorry for misinformation
<luks> so cache would be kept in the subprocess
<garyvdm> luks: ah - ok, similar to tbar
<garyvdm> *tbzr
<bialix> yep
<garyvdm> that would work
<garyvdm> bilaix, luks: What would the the performance of the rpc be like for lots of data?
<garyvdm> qlog loads and processes lots of data.
<garyvdm> and qdiff
<bialix> I don't have good experience to say. But it will depends on the communication channel
<bialix> there is good python lib ported from Python 2.6: multiprocesses or something like this
<bialix> it have faster C code to exchange data between processes via pipes
<bialix> we propbaly will want to use bencode for serializing data
<luks> which is blocking, isn't it?
<bialix> luks: not really
<bialix> there is emulation layer siomilar to Queue
<bialix> it won't block
<bialix> that lib called "multiprocessing"
<bialix> available in 2.6 and from PyPi for 2.4 and 2.5
<luks> oh, I see how it works, but I wonder if it can give us some useful callbacks
<bialix> it has some issues with Mac, but I don't understand all details
<bialix> luks: mmm
<bialix> luks: using periodical polling will work
<bialix> or!
<luks> yeah, but seriously suck
<garyvdm> Couldn't we kill a thread with QThread.Terminate  http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qthread.html#terminate
<bialix> run blocking communication with subprocess in the thread
<bialix> it will be 4x fun
<garyvdm> lol
<luks> I'd rather use Qt tools for this
<luks> which are all non-blocking
<luks> but it would mean we have to write the protocol
<garyvdm> As you may have detected, I prefer the idead of using threads, rather than subprocesses.
<bialix> luks: which ones?
<luks> or use threads and signals/slots
<bialix> garyvdm: yes, I've detected
<luks> bialix: QProcess with a custom protocol, if we were using a process
<denys> vila: (back from lunch)
<denys> OK
<denys> tests passed
<denys> bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_connect_to_bzr_ssh is leaking threads among 2 leaking tests.
<bialix> QProcess means using stdin/stdout as comm channel?
<luks> yes
<bialix> that's my original idea
<vila> denys: faster than 'bzr selftest test_server' right ?
<bialix> you simply read my mind
<luks> but we can use pipes too
<luks> there is QLocalSocket
<luks> I mean named pipes
<bialix> perhaps using stdin/out will be simpler at first stage and more portable
<bialix> I dunno what beasts there on Macs
 * bialix recall vila has Mac!
 * garyvdm asks again
<garyvdm> Couldn't we kill a thread with QThread.Terminate http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qthread.html#terminate
<bialix> garyvdm: from the doc: yes
<vila> bialix: but can't run qbzr there :-/
<luks> "The thread may or may not be terminated immediately, depending on the operating systems scheduling policies."
<bialix> but there is scary warning about dangerous
<luks> it's like saying, "please please please kill this thread if you can"
<bialix> :-)
<vila> bialix: otherwise socket/processes are available on work the same than on linux
<garyvdm> bialix: We would only use that if stoping the code by rasieing a exception fails.
<garyvdm> on timeout
<vila> luks: kill -9 <pid> often behaves like that...
<vila> bialix: s/on work/ and work/
<bialix> garyvdm: I prefer to use subprocesses because it will be much easier to debug
<bialix> garyvdm: yes it will be much more work
<bialix> and we need to write debug tools aca terminal program
<bialix> *aka
<bialix> but in the end it will be much simpler
<bialix> but less fun as luks said
<luks> I think it generally doesn't matter which would be used
<luks> as that's easy to change
<garyvdm> Which would be easier to do?
<bialix> does QThreads use native OS threads?
<garyvdm> no
<bialix> or they are affected by GIL
<garyvdm> I don't think so.
<luks> with threads you already have API to communicate with it in a non-blocking way => signals
<bialix> with QProcess you'll signals too
<bialix> you'llhave
<bialix> errr
<luks> yes, but you have to parse the messages
<garyvdm> bilaix: sorry ignore that. I miss read. I don't know
<bialix> luks: yes, it will be overhead
<luks> QThread is a thin wrapper around native thread calls
<bialix> with QThread we will need to send custom signals?
<garyvdm> Yes
<bialix> there is nice thing in Python: Queue
<bialix> but they are GIL-able
<luks> which you don't need
<luks> there is the Qt event loop for this kind of things
<luks> anything running in the same process will be affected by the GIL
<bialix> is there someting like QFifo or QQUeue? /me looks
<bialix> no
<garyvdm> Relevant doc: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/threads.html
 * garyvdm goes to read.
<luks> generally, with threads you don't need to worry about the communication layer
<luks> because Qt has tools for that
<luks> with processes you need to write a RPC service, either a custom one or something like XML-RPC
<luks> but the largest part of this is designing the API for interaction with bzrlib
<luks> not the communication layer
<bialix> garyvdm: yes, xmloutput has inside implementation of XML-RPC server and client
<bialix> it seems looks implicitly suggests to use threads
<bialix> it seems luks implicitly suggests to use threads
 * garyvdm goes to read the picard code
 * bialix really writing announce!
<luks> garyvdm: don't, it's horrible :)
<luks> yes, I was implicitly suggesting to use threads for the first version
<luks> garyvdm: not only it's horrible, but parts of the thread usage will be replaced by processes
<lfaraone> Hi, is there any way to have bzr remember the password for a SVN repo I access frequently?
<NEBAP|work> vila: https://bugs.launchpad.net/bzr/+bug/416903
<ubottu> Launchpad bug 416903 in bzr "'bzr resolve FILE' doesnÂ´t recognize conflict" [Undecided,New]
<luks> lfaraone: I think you can use svn to remember the password, then bzr-svn will use it
<NEBAP|work> vila: hope thatÂ´s ok ^^
<vila> Ideally the commands leading to the problem will ensure we can reproduce it... I'm not sure I can from your description (and I was there to help you :-/)
<vila> but thanks for filing it already !
<NEBAP|work> vila: I also have added the commands into the description, if there is anything additional that will help I maybe can add it too :D
<vila> NEBAP|work: the missing part is: how did you get there ? If you can recreate the problem with a script that would be awesome !
<lfaraone> Hm. I check out a branch with svn, and it checks out version 151. I cd into the dir, run svn up, and am told I'm on rev 151. I run bzr up, and I am told I'm on rev 152.
<lfaraone> s/152/114/
<NEBAP|work> vila: hmm I think I cannot create a script but IÂ´ll add the steps that leads to the problem
<lfaraone> Any idea why?
<vila> lfaraone: try svn up again just in case something happened on your repo maybe ?
<vila> NEBAP|work: great
<luks> lfaraone: aren't you mixing svn and bzr revision numbers?
<lfaraone> luks: But as a lightweight checkout, shouldn't it use master's revnums?
<vila> lfaraone: missed your s/152/114/, what luks says
<lfaraone> vila: http://pastebin.ca/1537585
<luks> lfaraone: no, svn and bzr revision numbers are totally separate
<luks> lfaraone: see bzr log
<luks> it should tell you both bzr and svn revision numbers
<igc> hi bialix, garyvdm, luks, vila
<garyvdm> Hi Ian
<vila> Errk, go to bed Ian ! :)
<NEBAP|work> vila: added the "history", hope that will help ;)
<bialix> igc: I need you help
<bialix> if you don't sleeping of course
<igc> bialix: sure
<vila> NEBAP|work: good, I'll try to write a script from that
<NEBAP|work> vila: ok, if there are any questions, donÂ´t hesitate to ask ;)
<igc> vila: it's only 10pm here - few hours left in my day still :-)
<lfaraone> luks: Thanks.
<luks> huh
<luks> bzr pull fails with bzr: ERROR: exceptions.AttributeError: '_known_graph_pyx.KnownGraph' object has no attribute 'topo_sort'
<garyvdm> luks- you have probably pulled trunk, but not done a make
<luks> oh
<luks> that's it, thanks
 * garyvdm knows that because I was looking at using KnownGraph to make qlog faster.
<bialix> garyvdm: what it means: gdfo?
<garyvdm> greatest distance from origin
<bialix> you asked vila several pages ago
<bialix> oh, it's about revnos?
<garyvdm> Yes
<bialix> k
<garyvdm> For a revision, the gdfo stays stable, even if the tip changes.
<garyvdm> So in theory it can be stored on disk
<bialix> can it be cached therefore?
<luks> does it still require the whole graph loaded?
<vila> gdfo is stable except when ghosts are filled
<garyvdm> And it can be use it determine what parts of the graph need to be loaded it calculate a revno for a revision
<vila> revnos requires most of the graph most of the time, we need to change the way we calculate revnos and then we'll be able to calculate revnos without loading all the graph and gdfo will help
<garyvdm> vila: What is the difficultly with this? Ghosts?
<vila> yes, the way ghosts are handled today, there is no simple way to know when they are filled
<garyvdm> bialix: I've just pushed a change to trunk to make qdiff more responsive during loading.
<bialix> garyvdm: thanks
<garyvdm> bla - not there yet - branches diverged.
<luks> sorry :)
<garyvdm> luks: Just had a look at your latest change. There are lots of other places were we get the revid via .data(). Don't we need to change them to?
<luks> probably
<luks> but I can't see any
<luks> oh, but bzr grep does
<luks> those are usually str(foo.toString())
<luks> so that works fine, but it's not as efficient as it could be
<garyvdm> ok
<vila> NEBAP|work: forgot to ask: what bzr version are you using?
<vila> NEBAP|work: forgot to ask: what bzr version are you using?
<NEBAP|work2> vila: should be 1.16.1
<vila> ok
<NEBAP|work> nickserv identify ongbak
<garyvdm> Time to change your password
<luks> :P
<NEBAP|work> ^^
<NEBAP|work> what is <key>?
<NEBAP|work> by changing password?
<NEBAP|work> ok
<NEBAP|work> done ^^
<vila> NEBAP|work: I've attached a script to the bug but I fail to reproduce the bug, can you see what I miss ?
<bialix> so, what's going on with release announcement mails for bzr itself?
<bialix> I don't see announcement for 1.18rc1
<bialix> but I see there is 1.18 ready
<bialix> and jam has uploaded windows installers
<bialix> anybody understand this new release scheme?
<vila> the RM encoutered problems for 1.18rc1 but we try to stick with the schedule
<vila> the only visible difference should be that announcements should now be made with installers ready
<bialix> I'm asking because I'm used to fw announcement to ru_bzr ML
<vila> hmm
<bialix> and I don't see anything useful to send there for 1.18rc1 at least
<vila> well, do you announce the rcs ?
<bialix> yep
<vila> hmm, well, nobody got announce for it :D
<bialix> I can wrote something myself
<NEBAP|work> vila: maybe the base was also changed after the local branch was created, otherwise I donÂ´t see any missed actions
<vila> the script modifies base after the branching
<NEBAP|work> ah sorry missed that
<NEBAP|work> no so I canÂ´t see any missed actions
<NEBAP|work> weird
<vila> the trouble I have is that you mention .BASE .OTHER files, so I'm wondering where they came from in your case
<vila> or if they are just unrelated to the problem
<NEBAP|work> donÂ´t know, but the files were create when I tried to push
<NEBAP|work> or better
<NEBAP|work> tried to merge after the unsuccessfull push
<garyvdm> bialix: see http://osdir.com/ml/bazaar/2009-08/msg00356.html
<garyvdm> bbl
<NEBAP|work> vila: the file that caused the problem was in the base (server) and local, but I removed it from the history local before merging. Can be possible that both files were changed after branching from the base
<NEBAP|work> vila: looking into the history I can see that removing the files was done before the last change of the base
<NEBAP|work> vila: the last changes on the base are also marked with a red dot instead of a grey one
<vila> ??
<vila> red ? grey ?
<NEBAP|work> using qlog
<NEBAP|work> maybe because IÂ´ve merged the server branch into the local branch instead of the other way round ..
<vila> I don't think the colors are meaningful in qlog... Any comment from our beloved qbzr hackers ?
<NEBAP|work> k
<NEBAP|work> but here is like the history looks
<NEBAP|work> rev 30 -> added new files (local)
<garyvdm> vila: colors are base on the revno, and are stable (if the revno is stable), but don't mean and thing else.
<NEBAP|work> rev 31 -> removed folder
<NEBAP|work> rev 29.1.1 -> last changes on the base (server)
<NEBAP|work> rev 32 -> merged changes
<vila> rev 32 is the one you created *after* solving the problematic conflict ?
<NEBAP|work> is this "switch" because I merged in the wrong direction?
<vila> rev 32 is the one you created *after* solving the problematic conflict ?
<NEBAP|work> yes
<NEBAP|work> this is the last (actual) one
<vila> doesn't look wrong to me, why do you say switch ?
<NEBAP|work> 30 -> 31 -> 29.1.1 -> 32
<NEBAP|work> or is this correct?
<vila> hooo, wait 29.1.1 means your colleague also added the file ! (since he did that based on revno 29)
<NEBAP|work> 29.1.1 is a change on the base (server)
<vila> what does 'bzr st -c 29.1.1' says ?
<vila> what does 'bzr st -c 29.1.1 -v' says ?
<NEBAP|work> just a second
<NEBAP|work> ^^
<NEBAP|work> Error: no working tree exists
<vila> cd `bzr root`
<vila> i.e. go where your WT is or st is meaningless :)
<NEBAP|work> ah ok
<NEBAP|work> IÂ´ve added the tree
<NEBAP|work> same error
<NEBAP|work> IÂ´ve added this to the error description
<vila> where are you ?
<NEBAP|work> in the root of the wt
<NEBAP|work> BUT
<NEBAP|work> when I used bzr push {serverlocation}
<NEBAP|work> it just pushed the history not the wt, donÂ´t know why
<NEBAP|work> maybe that is causing the errors
<vila> do you edit files at {serverlocation} ?
<NEBAP|work> no because there are no files
<NEBAP|work> there is just a folder containing the history
<vila> good, so there can't be conflcits there :)
<NEBAP|work> but itÂ´s not a shared repo
<vila> ok got it
<NEBAP|work> k
<vila> the file has been added from both sides, I'll attach the updated script
<NEBAP|work> does it reproduce the error now?
<igc> goneri ping
<vila> 3 conflicts encountered.
<vila> + bzr resolve dir/file2
<vila> dir/file2 is not conflicted
<NEBAP|work> so it does?
<NEBAP|work> ^^
<igc> goneri: re https://code.launchpad.net/~goneri/bzr-fastimport/347729_git-bzr_doesnt_work ...
<igc> goneri: the commit message doesn't match the code change?
<igc> gineri: does that fix the bug?
<vila> NEBAP|work: Hmm, still not exactly because the file itself is not mentioned in conflics, but that's closer
<igc> goneri: ^^^
<NEBAP|work> vila: hmm hard to reproduce ^^
<vila> NEBAP|work: can you paste 'bzr log -n0 -r28.. -v' somewhere ?
<vila> NEBAP|work: can you paste 'bzr log -n0 -r28.. -v --show-ids' somewhere ?
<goneri> igc: http://bazaar.launchpad.net/~goneri/bzr-fastimport/347729_git-bzr_doesnt_work/revision/210
<NEBAP|work> vila: let me check
<goneri> igc: yes, that's the changes
<goneri> igc: oh wait i'm on crack
<NEBAP|work> vila: bzr: Error: sorry, u'..' not allowed in path
<igc> goneri: :-)
<goneri> line 247: it should be "self.revid_to_mark[revid] = ':' + str(mark)"
<igc> goneri: that sounds more reasonable
<vila> NEBAP|work: no space between 28 and ..
<NEBAP|work> vila: there is not a space
<igc> goneri: can you test that and push it?
<goneri> sure
<vila> meh
<NEBAP|work> used: bzr log path -n0 -r28.. -v > bzr_log.txt
<vila> --show-ids !!!
<vila> don't forget it it's very important
<vila> try without redirecting ?
<NEBAP|work> ah k
<vila> path ? no path ! cd path first
<vila> :)
<NEBAP|work> k
<NEBAP|work> then he goes one dir up which is not a branch: bzr: ERROR: Not a branch: "path/.."
<NEBAP|work> ("path/.." is the folder containt the branch)
<NEBAP|work> should I create a local branch
<vila> You can specify <path> to log, but only to restrict the log to the specified path, i.e. log will display the log entries related to the versioned  <path>
<NEBAP|work> k
<vila> NEBAP|work: are you in the folder where the files you edit are ?
<NEBAP|work> no
<NEBAP|work> on the server
<NEBAP|work> files are on a differenc pc which is shutdown at the moment
<vila> haaaa
<NEBAP|work> should I create a local branch
<vila> then yes
<NEBAP|work> k
<vila> log should work in a tree less branch though...
<NEBAP|work> omg
<NEBAP|work> using pull to retrieve the latest version results in 3 conflicts ^^
<NEBAP|work> its the deleted folder
<NEBAP|work> error: canÂ´t delete because its not empty
<NEBAP|work> should I use
<NEBAP|work> bzr rm to remove them from history?
<vila> where did you create your local branch ?
<vila> and how ?
<NEBAP|work> just updated (bzr pull) my local version of the branch
<vila> where ?
<NEBAP|work> c:\work\...
<vila> is that the server ?
<NEBAP|work> no
<vila> <shudder>
<NEBAP|work> I have 1 server + 2 workstation
<vila> can you issue 'bzr log -r28.. -v --show-ids' there ?
<NEBAP|work> on the server is a branch without wt
<NEBAP|work> vila: I just want to update to the latest version on the server (which contains the merged conflicts that caused the errors)
<vila> NEBAP|work: then do that in a clean context: create a new branch,
<NEBAP|work> k
<vila> it looks like you pulled in a wt with actual changes
<mfer> hello bzr folks
<vila> a pull in wt where 'bzr st' reports nothing should never produce conflicts
<NEBAP|work> no, the only conflicts are in the removed folder because he didnÂ´t want to delete it because they are not empty ..
<NEBAP|work> k
<NEBAP|work> at first I will create a clear brunch
<NEBAP|work> *branch
<mfer> I'm a fairly new bzr user and looking to convert some designers/front end devs from svn. But, many of them use Coda, Textmate, and some other tools like that. They aren't command line folks either. Anyone know if there is any work being done to connect these (plugins?)?
<NEBAP|work> k
<NEBAP|work> branched 32 revisions ;)
<vila> good :)
<NEBAP|work> so now I try to output your commands
<NEBAP|work> same error
<NEBAP|work> he always tries to move a directory up
<NEBAP|work> which is not a wt
<vila> bzr don't move
<NEBAP|work> IÂ´ll try adding quotes
<vila> do you have some wrapper ?
<NEBAP|work> yes
<NEBAP|work> using the quotes it wors ;)
<NEBAP|work> windoofs ^^ (doof means stupid in german ;) )
<vila> where did you have to add quotes ?
<NEBAP|work> IÂ´ve used: bzr log "-n0" "-r28.." -v --show-ids     (looks like windows recognizes the '..' as folder up)
<NEBAP|work> maybe
<garyvdm> mfer: I don't think anyone is working on integration with Coda, and Textmate. Have you looked at bzr-explorer? - It is a general purpose GUI
<NEBAP|work> bzr log -n0 "-r28.." -v --show-ids
<NEBAP|work> is enough
<vila> 8-( bialix ? Any idea ^^
<NEBAP|work> vila: now the output works ;)
<vila> NEBAP|work: ok, so, can you paste it somewhere ?
<NEBAP|work> vila: IÂ´ll send it via email to you if that is ok, because its company data ..
<mfer> garyvdm: I have a little. I'm a command line guy so I don't dive into the gui tools so much. For designers I'm learning it has to be dead simple and work with their existing tools. There was a textmate bundle but it's not very feature rich, fyi.
<divokz> I'm getting an error when using "tbzrcommandw --command=getupdates" on Windows XP.  "RuntimeError: Where is bzr.exe?"  (I've already checked, and it's in my path.)  I'm not finding anything about this via Google either.
<divokz> (Just tested on another box -- it happens in Vista too.)
<divokz> Any ideas on what's going on?
<divokz> I'm using this to try to add a "check for updates" command for XP users of an internal tool I'm making
<divokz> I'd be interested in hearing other options
<garyvdm> divokz: a option is to just run bzr qgetupdates
<garyvdm> divokz or bzr qpull or bzr pull.
<garyvdm> depending on what options you want to give them
<divokz> garyvdm: well, it needs to be part of a GUI tool.   I've tried just using `bzr up` and it just pops up a DOS window without doing much else.  (Works fine on Linux, though.)
<divokz> garyvdm: ah, that does do a GUI thing
<divokz> nice
<divokz> didn't know that
<garyvdm> divokz: wether you do bzr up or bzr pull depends on if the branch is bound or not.
<garyvdm> divokz: just add q to most commands for a gui
<divokz> it is bound
<divokz> well, that's awesome -- still pops up a DOS window (before bringing up the TortoiseBZR one, unlike tbzrcommandw), but I think that's fine
<divokz> (unless you know a way around that -- I'm calling this from a rubyw script)
<divokz> thanks, garyvdm
<garyvdm> Nope no bzrw yet.
<garyvdm> pleasure.
<ScriptFanix> Hi
<goneri> igc: done, lp:~goneri/bzr-fastimport/347729_git-bzr_doesnt_work
<ScriptFanix> are there any way to generate the debian/changelog file from the bzr history ?
<goneri> igc: the test script runs fine now
<igc> goneri: thanks
<garyvdm> ScriptFanix: no, but if you have bzr-builddeb, it will automatically generate a commit message from debian/changelog.
<garyvdm> bialix: What does this say. It is a mail I recived. http://paste.ubuntu.com/256944/
<ScriptFanix> garyvdm: yes, found that. i want it the other way around. anyway, it's just for internal use, so we don't really care about the debian/changelog file anyway :)
<garyvdm> bialix: I just realized that I sent a message to ru_bzr, and it is probably telling me you need to approve the message.
<LeoNerd> If I "bzr branch -r123" to take a branch from an earlier point in history, the new branch seems to contain all the tags of the parent, even those after -r123..
<LeoNerd> Known bug?
<igc> goneri: merged and pushed to rev 218
 * goneri send a big thank you to igc
<igc> gnoeri: you may want to close bug 347729 now
<ubottu> Launchpad bug 347729 in bzr-fastimport "git-bzr doesn't work" [Undecided,New] https://launchpad.net/bugs/347729
<quicksilver> is there a way to preview a merge without actually doing it?
<quicksilver> other than (bzr merge ../fx-xyz; bzr diff | less; bzr revert)
<quicksilver> ah --preview
<quicksilver> duh
<quicksilver> I'm blind :)
<brutimus> I've been trying for the past day to get server-side hooks to fire when i commit over bzr+http (through the smart server using fastcgi).  I've installed my hook at set_rh, and post_change_branch_tip.  They'll fire of i do a local commit on my repo-server, but they don't fire when i commit from the network.  Using Bzr 1.6.1
<brutimus> Also.. I put the hooks in /usr/lib/python2.5/site-packages/bzrlib/plugins/
<brutimus> Gah.. as luck would have it.. I just ran across a changelog for 1.8 that mentions bzr over http will now load plugins.. This looks like it might fix my problem.
<vila> quicksilver: works very nicely as shell-command under emacs, you just have to M-x diff-mode the result :)
<alsuren> is it possible to run bzr serve --allow-writes as a cgi script?
<quicksilver> vila: *nod*
<alsuren> it seems that bzr+http is a valid protocol
<brutimus> alsuren: yes you can run that through fastcgi or mod_python
<bialix> garyvdm: ru_bzr is restricted group, one need to be joined it to post
<bialix> garyvdm: your message simply banned by googlegroups
<alsuren> brutimus: can you point me to some docs?
<brutimus> finding them :-)
<alsuren> thanks
<bialix> garyvdm: never mind
<brutimus> allenap: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<brutimus> I've personally only done it through mod_python as that's what we had setup on our dev serve
<bialix> garyvdm: re qdiff: I don't see any changes in its semi-frozen state even with your latest patch. I guess sooner or later threads or subprocesses will be very desirable to have
<alsuren> s/allenap/alsuren/
<brutimus> whoops
<bialix> garyvdm: bye for now
 * bialix waves
<garyvdm> bye
<sveinung> Is it possible to make bzr-fastimport preserve bug fix metadata?
<sveinung> Don't know the correct termology by I mean the data you get when you do --fixes during a commit.
<sveinung> I have tried Google and looking at the source code but since I don't know the termology I could have missed it
<luks> since it's a format designed for git, I don't think so
<sveinung> ok, thank you
<manuee> hi all
<manuee> i've got a problem using bzr upload... looks like ive already removed some files from the target server, but upload stops if it doesnt find a file it needs to remove... anyway around this so it continues?
<vila> manuee: bzr upload --full
<manuee> ey vila thanks ill give that a try
<manuee> dont think i saw that option on bzr help upload
<manuee> :X
<manuee> ow duh, it just does a full upload
<jseabold> Hello all, is there a way to copy a file with its file history to another bzr branch?  I have some code deep in a branch here path/to/my/old/branch but it is now going to be a standalone package so I need to move it to /path/new/ and preserve file history.  Is this possible?
<fjalvingh> I am trying to branch from 1.14-rich-root format to 2a format on a disk and bzr is already running for 30mins at 100%CPU and 1GB memory!? Any tips?
<bialix> thumper: ping
<bialix> thumer: do you remember problem with SSH keys and access to bzr+ssh from WIndows?
<bialix> tumper: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter7.html see section 7.2.2, 4th paragraph: "To avoid being prompted..."
<bialix> thumper: https://bugs.launchpad.net/bzr/+bug/414743
<ubottu> Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [High,Confirmed]
<phinze> hmm i'm having trouble with getting bzr log to show just the commits i've made in my task branch
<phinze> it seems to only want to show the last revision i merged with parent
<phinze> whereas there are a couple of revisions in my local task branch before that i'm interested in seeing
<LarstiQ> phinze: bzr log -n0 ?
<phinze> LarstiQ: i'm trying bzr log -rancestor:../mainline ; but it just shows the "merge parent" revision i just made to my task branch
<phinze> there are two revisions before that point i would want to see
<phinze> but i want to filter it to show only those revs
<LarstiQ> phinze: you're not looking for `bzr missing` ?
<phinze> LarstiQ: i... am an idiot ;P
<phinze> one of those days...
 * phinze has used bzr missing like every day
<LarstiQ> well, missing and log could use some refactoring
<phinze> yeah i always get the spec mixed up
<phinze> --forward vs --reverse etc
 * LarstiQ meant them doing similar things
<phinze> mmm
<kfogel> What's the latest best recommendation for commit emails from a bzr repository?  I'm trying bzr-hookless-email right now, but so far haven't gotten it to work.
<lifeless> I would still recommend bzr-email
<lifeless> unless you're expecting people to commit via sftp/nfs.
<lifeless> (can't run code on the server via dumb protocols)
<kfogel> lifeless: well, that's the thing.  I'm pretty sure they won't, but am not positive (this is for Emacs), and hate to have a system that's brittle in that way.
<kfogel> Because we'll never remember this, when the time comes (in two years) to debug why commit emails aren't working for so-and-so.
<lifeless> kfogel: don't permit sftp then
<kfogel> lifeless: sure, but are we going to remember why we're not permitting it?  (Aside from the fact that some may object.)
<lifeless> kfogel: I hear that you're pretty good at writing docs.
<lifeless> :)
<kfogel> lifeless: what I'm trying to say is, one way is formally less fragile than the other... but only if it works.
<lifeless> so, hookless is differently fragile
<kfogel> lifeless: one of the things you quickly learn from writing docs is that no one reads them :-)
<kfogel> lifeless: ah, is it?
<lifeless> it depends on a long term server process/cron
<kfogel> lifeless: OIC
<lifeless> it does mail by polling
<kfogel> lifeless: true.  But I think of that as less fragile because it's the only method by which commit emails go out.  In other words, if they break, we'll quickly figure out where to look.
<lifeless> bzr-email depends on being invoked by bzr, which then works both locally and remotely, as long as it /is invoked/ - and bzr on the server only actually runs if you push via a bzr*:// flavour protocol
<kfogel> whereas with the sftp, your commit emails seem to work fine when you test them, it's just this user who said "it's not working for me"
<kfogel> lifeless: yes, I understand the hook-vs-poll thing.
<lifeless> kfogel: for emacs I suspect sftp would be noticable slow too
<lifeless> you've got a massive database and users with all sorts of latency
<lifeless> and you're not trying to host on dreamhost or some itty bitty windows-centric webhost
<kfogel> lifeless: note they're also using  bzr-hookless-email already, apparently https://savannah.gnu.org/support/index.php?106531
<lifeless> they really need to get a proper certificate
<kfogel> lifeless: also, bzr-hookless-email is restartable.  if the cron job drops, you just start it up, it will catch up.
<lifeless> kfogel: sounds like you'd prefer to use bhe.. so do so :)
<kfogel> merely exhaustively analyzing, in the channel :-)
<Noldorin> hi lifeless
<Noldorin> lifeless: heh, it must seem like i'm bothering you every night. i have little better to do at the moment though :)
<lifeless> Noldorin: hi. No - its my sat morning is all, I'm not really here.
<Noldorin> heh, yeah. morning for you :P
<Noldorin> lifeless: does that mean i should catch you another time then? :)\
<lifeless> well,  I can still answer questions and so on but there is likely to be long gaps as I wander off and do stuff ;)
<lifeless> basically you need to take the minimal trace + log and make a demo showing the problem you can show your admins
<Noldorin> actually, i don't really have a question at the moment
<Noldorin> lifeless: did you see my updates?
<Noldorin> i did a lot of testing this morning
<lifeless> no, I hadn't - work mail is shelved till monday :)
<lifeless> whats the summary
<Noldorin> https://bugs.launchpad.net/bzr/+bug/412244
<ubottu> Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP Service IIS6)" [Medium,Confirmed]
<lifeless> so, get your admins to read that ;)
<lifeless> its pretty hard to argue that 'a renamed and deleted file should be readable'
<Noldorin> yep lol
<Noldorin> they replied once saying "FTP on this server is working fine by methods we recommend are used for FTP."
<lifeless> !!!
<Noldorin> but yeah, i'm trying to push it. they're just being stubbornly blind.
<Noldorin> at least we're 100% sure there's nothing wrong with bzr now
<Noldorin> so you're welcome to close it, if you wish
#bzr 2009-08-22
<lifeless> we can look at making a very slow spin
<lifeless> its a fascinating bug
<Noldorin> heh, you could say that, yeah.
<Noldorin> hmm
<Noldorin> the thing is, i'm not sure if it's unique to my ftp server, or somewhat more common
<Noldorin> on windows ftp servers in general
<Noldorin> would be interesting to see if it persists when the server gets upgraded to win 2008
<lifeless> first tinme we've seen it
<lifeless> we've seen other IIS6 related issues
<Noldorin> mm
<Noldorin> though i wouldn't be surprised if others encountered it but didn't have the effort to pursue the problem
<Noldorin> it certainly hasn't been a straightforward one :P
<lifeless> hard to know
<Noldorin> yeah
<BasicOSX> How to I convert a branch to the new 2.0dev format?
<lifeless> BasicOSX: there's an upgrade guide
<lifeless> BasicOSX: but in short, if you have no stacked branches its just 'bzr check; bzr upgrade --2a'
<lifeless> and to upgrade a remote branch just add the url to both those commands
<BasicOSX> lifeless:  got url to migration/upgrade guide? I've been away almost 1 month so I got a lot of reading to do to catch up :-)
<lifeless> docs.b.o
<lifeless> uhm, 1.18 added it, and its in .dev too obviously :)
<BasicOSX> heh, maybe I should bzr update
<floam> does anybody know if any of [bzr, hg, git] set the mtimes of the files in the working tree to the last time a file was updated?
<fullermd> I'm pretty sure none of them do.  That would have bad knockon effects with e.g. make.
<floam> knockon?
<lifeless> floam: consequences
<fullermd> As bzr goes, it handwavingly seems like a relatively simple plugin to write, to at least give a command to set them.
<lifeless> there is a bug open
<fullermd> It would probably be very hard (read: impractical) to try and hook it into everywhere that files get written, though...
<floam> I'm having a hard time imagining the effects, but I'll trust you.
<lifeless> you can do something with care that won't break make and will give some idea about times.
<fullermd> (as a plugin that is)
<floam> seems no different than having my mtimes set in a tarball of a release.
<lifeless> floam: things not building that should, and things building that shouldn't.
<lifeless> floam: tarballs are immutable :)
<fullermd> Yah.  You don't often blat a tarball over an existing dir with .o files.  With VCS's, flinging files around is the norm.
<fullermd> You don't even have to postulate different versions.  Imagine I edit a .c file, build, decide it was crap, and use 'bzr revert' to throw it away.
<fullermd> If revert reset the mtime back to the last commit, the [broken] .o file would be considered up to date by a system (like make) that relies on timestamps.
<floam> ok, good point.
<fullermd> (of course, this is one reason I'm designing for more flexibility in my make replacement.  Watch out for it in, like, 30 years when I catch up on free time  ;)
<floam> I should probably just not let my code care about files' mtimes, as much as I want to.
<floam> I keep my website in version control, and my little python cms+blog stores blog entries as plain text files in markdown, and I use the mtime for the "posted" date.
<fullermd> Funnily enough, I just had a VCS/mtime discussion elsewhere yesterday.  Silly coincidences...
<lifeless> fullermd: you too huh
<lifeless> [build tools]
<fullermd> Well, I have my website under version control, and I use $Date$ keywords for Last Updated.  'course, that's one reason it's still in CVS...
<fullermd> lifeless: Yah.  You won't like mine, though   8-}
<floam> fullermd: yeah, that was my next quesiton. "which modern VCSs have $Date$?"
<floam> but I really wouldn't want to rely on a certain VCS for my code.
<fullermd> I think I heard that hg has a plugin or something for it.
<floam> might as well be shelling out to bzr to find out then.
<fullermd> bzr will ("does" FSVO, but it's too buggy to be useful ATM)
<lifeless> fullermd: if you stop writing in perl I might ;)
<lifeless> floam: bzr can do $Date via filters; hg too, and git as well.
<fullermd> I figure if I go slow enough, it'll be in p6 by the time it's finished...
<floam> wonder if bzr preserves xattrs..
<lifeless> fullermd: parrot is fun. They use my code ;)
<fullermd> I actually DID considering trying to use PIR or some layer in parrot for it instead...
<fullermd> But doing it in perl saves me having to do all that language implementation stuff.  Laziness FTW.
<floam> anyways, re: breaking things: what about ctimes?
<fullermd> You mean recording the mtime from the commit timestamp into the ctime field as an end-run?
<fullermd> I guess you COULD do it, but that would be a pretty wacky hackaround; any app you'd care about the mtime you'd have to rework to look at the ctime field instead.
<floam> don't think so, I think I mean preserving the actual ctime.
<floam> or when it was added to version control.
<fullermd> Mmm.  ctime is rarely going to tell you anything meaningful...
<floam> yeah, except for my actual usecase of blog-posts-as-files, where the creation time is the actual pertinent thing.
<fullermd> But ctime isn't creation time.  It's inode-change time.
<floam> know if any of the VCSs out there preserve it?
<floam> oh?
<floam> didn't know that.
<fullermd> Yah.  A lot of people don't, 'cuz it's so convenient to expand as 'creation', and creation is one of the major things that touches it   :)
<fullermd> But it's not the only.
<floam> so nautilus, os x's finder's Created: fields would have to be absolutely useless
<fullermd> chmod, for instance, is an inode change, so it updates the ctime.
<lifeless> ctime changes on chmod/link; mtime changes on write/trunc
<fullermd> At least some fsen also store an inode birth time, which could populate a Created: field with at least technical correctness.
<fullermd> Of course, any form of 'editing' that uses rename() to atomically update the file means Created isn't necessarily what you think of it as either.
<fullermd> For instance, I made a file, did a chmod to change the ctime, then cat'd it to change the atime.
<floam> hm, I bet OS X is being sneaky and using some sort of xattr or resource fork or HFS trick to get these creation times displayed in Finder that aren't being affected by chmods.
<fullermd> % stat -f'%a %m %c %B' y
<fullermd> 1250925980 1250925730 1250925786 1250925730
<fullermd> The birth and modified times are the same (since I never modified it), but the change time corresponds to the chmod, and the access to the cat.
<fullermd> I don't know how portable birthtimes are.  amc at least you can fairly count on on POSIX filesystems.
<floam> ah
<floam> st_birthtime.
<floam> anyways, I'm just going to add some metadata to my files and set them by hand, I think. thanks for the help.
<fullermd> lifeless: BTW, is the paucity of progressbar updates on 'check' a known blip?
 * fullermd can't remember if it was mentioned.
<lifeless> fullermd: no, I made it update better if anythinh
<lifeless> rather than 5 bars going 0 to full :P
<fullermd> I ran a check on my bzr.dev repo (~25 minutes), and for at least 5 minutes (all I really watched), even the spinner was frozen.
<fullermd> ('course, I'd forgotten about that TREE_ROOT thing, so I don't actually know whether check found any real errors in the repo...)
<NEBAP> is it possible to tell bazaar that IÂ´ve moved a file after I moved it?
<NEBAP> e. g. I have a file file1.ext and now create a folder files and move the file to it, so before: file1.ext after: files/file1.ext
<NEBAP> how can I tell bazaar that IÂ´ve moved the file?
<fullermd> bzr mv file1.ext files/ should notice it's already done and note it down for bzr I thin.
<fullermd> And think, too.
<NEBAP> thanks IÂ´ve found it: bzr mv file1.ext DAL/file1.ext --after
<vila> denys: ping
<vila> denys: don't waste your energy about leaked threads, the problem is known and selftest will even report about them (when it can finish that is), so if you're blocked on gentoo because of that, just try running less tests (with -s) or have a look at my patch for --parallel=fork that will reduce the number of tests run by each subprocess
<denys> vila: sorry, was away from keyboard.  is the problem unfixable?
<vila> denys: of course not :-) But it's not trivial, see my comment on the bug report for more details and some work-arounds
<vila> We never had crashes until recently so the priority was low.
<vila> I'm sorry I didn't see your report earlier, understanding where the threads are coming is really tricky :-/ I hope you enjoyed the trip though :D
<vila> denys: I'm setting up a gentoo VM right now to be able to reproduce the problem, but it's the week-end and my family may require me, so...
<denys> ;-)
<denys> I am the sort of guys who like fixes rather than workarounds. this problem bugs me (literally and figuratively)
<vila> denys: oh ! By the way, I'm pretty surprised that you even encounter the prolem, so may be you can try to understand  gentoo appears to have a lower number of threads that Ubuntu, OSX, Debian, xBSD, etc
<vila> :)
<vila> windows... I can understand because the overall OS model is different, but gentoo...
<denys> hmm:
<denys>  cat /proc/sys/kernel/threads-max
<denys> 114637
<vila> cat /proc/sys/kernel/threads-max
<vila> 24575
<vila> denys: try harder :)
<denys> that's what I mean. it's not a problem of threads-max
<vila> may be python itself has a limit...
<vila> ha ok
<GreySim> I just want to say, I really really love bzr, and thank you all.
 * GreySim loves that commands are intuitive and I don't think I've ever had to look one up.
#bzr 2009-08-23
<dlee> I've tried to avoid asking this here, but after fighting to install a sufficiently full Python 2.6 to support Bzr but failing...
<lifeless> what platform?
<dlee> I'm trying to set up Bzr to do web site file vc on a remote server that, amazingly, seems only to have Python 1.5 and 2.1.  Is there a way to get Bzr running without an actual Python installation?  This is Linux, though I don't know which distro at this point.
<lifeless> you could possibly use freeze
<dlee> freeze?
 * wgrant wouldn't be storing anything on that server...
<lifeless> you'd need to do considerable work to make that get all the lazy-loaded modules correctly though
<lifeless> dlee: its a python thing, makes a big C file with the python pyc files embedded as constant strings.
<lifeless> http://wiki.python.org/moin/Freeze
<dlee> wgrant: hehehe, it's not my web site though, so not my choice there.  Lifeless: thanks I'll look there.
<dlee> Probably more trouble than it's worth... so far I've been doing the ssh/rsync-then-bzr thing, but it's not as easy to use bzr to recover from a mistake real quick that way.
<davidstrauss> dlee: Try some of the publishing plugins
<wgrant> bzr-upload!
<dlee> Thought of that, but I'm not the only updater, just the only one with a vc approach atm.  Don't want to clobber someone else's work.
<dlee> I was hoping for a static bzr for Linux like we (sort of) have for Windows.
<dlee> lifeless: I see from your page that -X excludes, so I bet -I includes.  Would it be sufficient to collect all lazy import lines via grep over bzr source, then make a -I for each?
<lifeless> I don't know
<lifeless> how do the other editors coordinate their changes?
<dlee> This is not a busy development project.  The site needs significant overhall, but everyone else is just making as-needed small changes.  My concern with a publish-based approach is that I'd miss that someone made one and it would be replaced quietly.
<dlee> Mostly I'm trying to use bzr as a safety net.  The site is live, there's no staging version, and it's interconnected enough (database, streaming software on other machines etc.) that I'm not sure how to make that happen.  I'm nervous making sweeping updates to a live site w/o a fallback plan.
<lifeless> I'd consider rsyncing from the site to your machine; commit; bzr upload
<lifeless> that doesn't seem to have a wider race condition than editing by hand on a live server :>
<dlee> rsync/commit is what I've been doing, but I never tried publishing back from here to there.  That would certainly be easier to set up...
<dlee> It does prevent bzr diff on server before upload, but even my proposal has leaks.  Thanks much all, and keep up the good work. :)
<Stavros> hello
<Stavros> i have two diverged branches, how can i replace one with the other?
<Stavros> bzr pull --overwrite?
<bialix> igc: ping
<bialix> igc: qrun!!!
<bialix> igc: check https://bugs.launchpad.net/qbzr/+bug/416939
<ubottu> Launchpad bug 416939 in qbzr "qrun command needed as universal bzr commands launcher" [Medium,In progress]
<cha0s> hey guys... anyone tried running bzr with an expect script? it keeps dying when i try
<cha0s> here's my script: http://codepad.org/PXfNA1J0
<cha0s> say i have a repository 'foo', and there's another repository under it at 'foo/bar'. how do i bzr add foo/bar to the repo in foo? it seems like bzr is totally ignoring it.
<cha0s> say i have a repository 'foo', and there's another repository under it at 'foo/bar'. how do i bzr add foo/bar to the repo in foo? it seems like bzr is totally ignoring it.
<LarstiQ> cha0s: I presume you mean branch, and not repository.
<LarstiQ> cha0s: the answer probably is, you don't
<LarstiQ> cha0s: possibly you want join, but I'm thinking you want something that isn't there yet
<LarstiQ> cha0s: alternatives are using https://launchpad.net/bzr-scmproj, config-manager or just versioing symlinks (and possibly zc.buildout or similar for deploymnet)
<Noldorin> lifeless: hello?
<alsuren> hey chaps. I'm trying to run a bzr http smart server using cgi and it's giving me Logger instance has no attribute 'status'
<alsuren> have you done some horrible monkey-patching to the logging module?
<alsuren> oops. My bad
<sveinung> hello. I'm getting the same backtrace as in bug 417238, but I also had the same issue with the version of bzr-fastimport in Squeeze
<ubottu> Launchpad bug 417238 in bzr-fastimport "KeyError trying to import a bzr fast-export" [High,Fix released] https://launchpad.net/bugs/417238
<sveinung> should I repoen the bug or is this a different issue?
<sveinung> (I get it when I try to fast-import data on top of another one helped by --import-marks)
<bialix> sveinung: please, report it as separate bug report but add note about existing bug
<sveinung> ok
<sveinung> thank you
<bialix> author of fast-import (igc) will decide is it duplicate or not and will be able to mark it correspondingly
<bialix> sveinung: and ensure you're using fresh version from trunk
<sveinung> bialix: sure. Checked it out today, will check out again before reporting just to be sure
<bialix> ok
<alsuren> is it possible to store a bzr repo in an sql/bigtable database?
 * kfogel is away: packing up laptop to go to onShore.  again.
<bialix> alsuren: in theory: yes
<alsuren> bialix: "go implement" right?
<bialix> ?
<alsuren> bialix: if I want it I'll have to implement it myself?
<bialix> well, yes
<bialix> I mean it's possible
<bialix> either as custom transport or as custom repository format
<bialix> perhaps the latter
<bialix> and you can implement it as plugin
<alsuren> bialix: the problem is this: we have a windows server with broken ftp
<bialix> that's bad
<alsuren> it works for normal file transfer most of the time, but bzr breaks
<bialix> I'm sure you have file a bug already
<alsuren> yeah. Noldorin did
<bialix> oh
<bialix> I'm aware of that bug, but don't dive too deep into
<alsuren> I tried hacking together a cgi-wsgi gateway but then realised that cgi scripts don't have write access to the filesystem
<bialix> and you can't use bzr+ssh or bzr+http solution?
<alsuren> so bzr+http doesn't work
<bialix> I know webdav is another option
<bialix> can you?..
<alsuren> that also requires server support
<alsuren> they don't offer dav
<bialix> alsuren: I'm not sure what lifeless told you or Noldorin
<bialix> but maybe will be simpler to try to hack around ftp transport
<alsuren> so the only option left is either fix/workaround the bug noldorin reported or write a bzr+http transport that can commit to sql
<luks> what bug is that?
<bialix> the latter will require custom branch/repository format
<luks> writing a sql backend would be work for a few months, IMO
<bialix> yep, a lot of work
<bialix> luks: hi btw
<luks> hi
<bialix> alsuren: can you say bug number?
<alsuren> does bzr+http use a standard wire protocol for all repo formats, like hg's wire protocol, or is it made of bong?
<alsuren> bialix:  https://bugs.launchpad.net/bzr/+bug/412244?comments=all according to my ff history
<ubottu> Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP Service IIS6)" [Medium,Confirmed]
<bialix> luks ^
<alsuren> what about the wire protool stuff?
<bialix> wire protocol?
<alsuren> how does bzr+http work?
<bialix> for FTP transport bzr uses only filesystem operations
<bialix> it uses bzr smart server protocol under the hood
<bialix> bzr+http ^
<alsuren> and the smart server protocol is repo format agnostic?
<bialix> mostly AFAIK
<luks> the smart server protocol does very little actually
<luks> it's a RPC service
<bialix> there is still a lot of VFS calls in smart server protocol
<bialix> core devs trying to get rid of them and convert it to pure RPC, but it's not yet here
<luks> bialix: well, those VFS calls are also RPC calls :)
<lifeless> moin
<bialix> yes, of course
<luks> alsuren: can't you just setup a windows share and be done with it?
<Noldorin> hi lifeless
<bialix> but they are trying to direct access filesystem on the server
<Noldorin> have i managed to catch you at work now?
<alsuren> okay, so if we want to hack something together, we should add an sql vfs layer and make the smart server pretend that it's committing to a standard filesystem?
<Noldorin> ew
<luks> heh, that's really going to be a seriously large project
<bialix> alsuren: luks question
<Noldorin> this makes me want to get the ftp stuff fixed all the more
<lifeless> what does
<alsuren> Noldorin: can you get the host to give you a CIFS share?
<Noldorin> lifeless: the alternative.
<Noldorin> bzr+http/smart server
<Noldorin> lifeless: so basically, i got another reply from my admin saying there's no problem
<Noldorin> !
<Noldorin> :S
<Noldorin> looks like it's up to us
<lifeless> seriously, wow.
<lifeless> just ...
<lifeless> wow
<Noldorin> i know. idiots
<Noldorin> i'm not even sure they've run the script
<lifeless> I mean, I can understand stubborn.
<Noldorin> which i took time to put together for them
<Noldorin> so they need not even use bzr
<lifeless> are they external to your company?
<Noldorin> lifeless: fcgi storm internet
<Noldorin> erm, stupid clipboard
<Noldorin> lifeless: http://www.storminternet.co.uk/
<Noldorin> this is actually for my personal website. (though i also happen to manage the company website with them)
<Noldorin> lifeless: so where do we go now?
<alsuren> okay. Dinner time for me
<Noldorin> alsuren: see you in a bigt
<alsuren> if anyone knows how hard an sql vfs layer would be to write, tell me
<lifeless> alsuren: not hard, but why?
<Noldorin> he's off now
<lifeless> Noldorin: are there any other protocols you can use to push to this site?
<Noldorin> lifeless: alsuren is trying to help me work around this ftp problem to get a bzr repo on my server another way
<Noldorin> that's what we're thinking
<Noldorin> http with a smart server is the only other option really
<Noldorin> lifeless: might we try hacking the bzr source any more?
<lifeless> Noldorin: it would be faster than ftp
<Noldorin> ah right
<lifeless> Noldorin: we could add a workaround, but it will be extremely slow.
<Noldorin> fair enough then
<Noldorin> i think we should try the smart server approach
<lifeless> you've reported that it takes them up to 30 seconds to action a delete
<Noldorin> yes. more commonly about 5-10 though
<lifeless> still, what should be a milliscond operation will take that long
<Noldorin> indeed
<Noldorin> it's baffling. the admin's reply, included.
<lifeless> I have to admit, if they were my webhost I'd be escalating to the support manager
<lifeless> or higher
<Noldorin> lifeless: to be quite honest, i think i will
<Noldorin> i sent the last email to them on friday
<Noldorin> and they haven't replied since (despite supposed 24/7 support)
<Noldorin> but tomorrow i'm going to get on their case
<alsuren> lifeless: how long do you think it would take/how would you do it?
<alsuren> the hg/bigtable chaps just use a database with strings as keys and binary blobs as values
<alsuren> but I don't know whether sql server has a size limit for binary blobs, or whether I'm going to get screwed by it
<lifeless> a VFS on SQL? a day or so. bzr performing well on top of it? I don't think its possible.
<alsuren> "well"?
<lifeless> if you want bzr on SQL, write a SQLBranch and SQLRepository objects.
<alsuren> lifeless: but then you need both client and server support
<alsuren> surely?
<lifeless> if you want all of bzr's networking features yes. And I'm sure you'd run into a number of TODO's along the way.
<lifeless> whats the overall goal here though?
<alsuren> honestly to work around Noldorin's broken ftp server
<lifeless> adding a 30 second spinlock will be a lot less work
<lifeless> or doing http+wsgi with the smart server
<lifeless> or even bzr+ssh, if they support that
<Noldorin> back
<Noldorin> hmm
<alsuren> yeah, given that the http server mounts the FS read only
<lifeless> I'd be surprised if they let arbitrary clients attach to SQL over the internet
<Noldorin> no SSH i don't think
<Noldorin> lifeless: they do
<lifeless> even anonymous?
<Noldorin> if by attach you mean connect?
<Noldorin> no
<Noldorin> requires a login
<lifeless> so whats in the repository
<Noldorin> erm, just project work
<Noldorin> i have various personal and open-source projects i manage
<alsuren> lifeless: the sql idea would be bzr+http -> cgi script -> vfs hack -> sql
<lifeless> I mean
<lifeless> is it meant to be the website content?
<lifeless> is it meant to be branchable by anonymous, or just by you?
<lifeless> or by $some_group?
<alsuren> lifeless: needs to be private because Noldorin has a habit of storing passwords in his repos like the closed source .NET developer that he secretly is
<lifeless> do they allow SMB/CIFS access?
<lifeless> or webdav?
<alsuren> no
<alsuren> so if we manage to develop/test a spinlock hack and it works on one machine, what are the chances it will make it upstream?
<Noldorin> alsuren: thanks a lot.
<alsuren> it's funny beause it's true :P
<lifeless> alsuren: as an optionally enabled tool, there's no problem includin it in  the core
<Noldorin> lifeless: everything the server supports is listed on that page
<Noldorin> alsuren: i have a private repos dir on my site, which isn't accessible via ftp btw :P
<alsuren> oh like bzr push --workaround-broken-ftp ftp://user:pass@host.com/repo ?
<lifeless> alsuren: or export BZR_FTP_DELETE_TAKES=30
<lifeless> or even a locations.conf setting
<alsuren> 30 sounds like a timeout. Is that what we want or do we want to repeatedly test?#
<lifeless> it may well repeatedly test under the hood
<lifeless> but we don't want to spin-on-unlock forever
<lifeless> in fact, bzr spinlocks already, you see
<lifeless> so in theory just leaving it to spin for 30 seconds should work today
<alsuren> oh I see
 * alsuren is ignorant
<alsuren> one other thing: do you think we actually have any ordering guarantees anymore, or is the lock going to say it's gone but still leave the repo in an unusable state?
<lifeless> its entirely possible that replacing the root node in the repo, and the branch tip data will be extremely fragile in this environment
<lifeless> I won't make any guesses about what will go right ;)
<alsuren> take-home lesson: microsoft is shit at conforming to protocol specifications?
<alsuren> meh
<lifeless> I'm pretty sure its not stock IIS doing this
<lifeless> the ISP may be backing on a high latency  cluster server, for instance
<lifeless> with a distributed lock manager for locking, but we can't see the lock manager using plain ol ftp. Its definitely a bug or deployment issue :P
<lifeless> MS FTP has issues I've seen other users encounter, but to date this one is unique - and most FTP servers have quirks of their own :)
<Noldorin> lifeless: yeah, i think we agreed it's not standalone Windows FTP server causing the problem here
<Noldorin> some silly virus scanner they have running or something
<Noldorin> or some module installed
<alsuren> Noldorin: might be worth testing on some other host, like that free MS student offer thing
<Noldorin> probably won't give very interesting results though
<Noldorin> hrmm
<Noldorin> so what is the conclusion here?
<Noldorin> which protocol are we going for?
<alsuren> Noldorin: ftp with a 30 second spinlock is the thing to try. Just patch it into your client and see if it works
<Noldorin> alsuren: you don't need to tell me that. :)
<Noldorin> that's what i determined with lifeless
<Noldorin> but we thought it wouldn 't be too practical
<alsuren> but writing an sql backend will be even less practical
<alsuren> academically quite an interesting project, but not something you could hack together quickly
<Noldorin> pestering the server admins until they fix the darned issue will be the best solution :)
<Noldorin> though possibly the most effort
<Noldorin> alsuren: yeah, true. i don't exactly have time for any more projects now, as you know though
<thumper> alsuren: I'd be interested if you put together a functional sql backend :)
<alsuren> thumper: propose it as a GSoC project for next year
<thumper> hmm..
<thumper> especially if we can get good locking and high performance out of it
<thumper> isolation would need to be solved
<lifeless> so
<thumper> but then "one repo for the whole world, mwa haha"
<alsuren> thumper: though google would probably want it to work on bigtable and pals too, like their hg hack does
<Noldorin> alsuren: lol.
<lifeless> a bigtable like solution may work well; the architecture we have under the hood is vaguely similar
<lifeless> I _very much_ doubt that something built on a vfs on sql would perform at all well
<alsuren> lifeless: what? and host it on google app engine using datastore?
<lifeless> alsuren: thumper is asking because launchpad hosts 100's of thousands of branches
<alsuren> that would be fun and games. I'd be up for that if someone would give me Â£1000 for it
<lifeless> google app engine is not scaled for individual apps in that manner
<alsuren> thumper: fancy giving me a job at canonical? :D I could fix up the project management features of launchpad while I'm at it.
<thumper> alsuren: :)
<thumper> alsuren: patches accepted now for LP :)
<thumper> alsuren: I found my job at canonical by watching the canonical employment page
<alsuren> thumper: I offered to help, if someone would mentor me https://bugs.edge.launchpad.net/launchpad/+bug/413462
<ubottu> Launchpad bug 413462 in launchpad "Should be able to see graph of blueprints for whole project." [Undecided,New]
<Noldorin> alsuren: you fancy going up to the isle of man, too? :P
<alsuren> lifeless: but I'm no longer a student, so I can't really spend too long on anything that's not going to get me a job
<poolie> hi all
<lifeless> hai
<igc> morning
<igc> hi lifeless, poolie
<poolie> hi igc
<blizzkid> lo all, I did   bzr branch lp:~segphault/gwibber/service-split After that I added a file, but on bzr commit I get bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow. What am I missing or doing wrong?
<lifeless> have you run 'bzr add'?
<blizzkid> lifeless: just after hitting enter I realised I forgot about that one *shame*
#bzr 2010-08-23
<jelmer> anthony__: #ubuntu is probably more appropriate for ubuntu problems
<spiv> Good morning.
<mwhudson> spiv: good morning
<mwhudson> spiv: enjoy your weekend? :)
<mwhudson> i hear something happened in australia
<spiv> mwhudson: turns out we get to join the UK in making 'hung' parliament jokes!
<mwhudson> spiv: congrats
<poolie> hi spiv, lifeless
<lifeless> hi poolie
<spiv> Hi poolie
<poolie> spiv, apparently you are pp this week
<spiv> Oh, right.  Thanks for reminding me :)
* 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: spiv | bzr 2.2-final has gone gold, build those installers
<poolie> np
<poolie> rms complained on behalf of emacs devs about the "locks aren't released on interrupts" bug
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/257217
<ubot5> Launchpad bug 257217 in Bazaar "closing terminal causes stale lock (affected: 0, heat: 2)" [High,Confirmed]
<poolie> iwbn to either check it's unwound, or perhaps auto-delete locks from the same machine where the process is obviously gone
<spiv> Treating SIGHUP as KeyboardInterrupt sounds ok to me.
<poolie> there was a bug about insisting on a username being set
<poolie> that'd be a good start
<poolie> i was thinking of doing that this afternoon since elmo etc seem to find it painful
<spiv> (And quick experiments suggest that SIGHUP is probably what is happening.)
<poolie> istm that using $user@$mailname should be safe, and should probably work without manual configuration on our machine
<poolie> machines
<poolie> arguably we should unwind on sigterm too
<poolie> i think the other problem we're likely to hit here is that the transport may be busy
<poolie> or may not like being interrupted
<spiv> True, although what's the worst that'll happen?  Most likely the worst is that the unwind will run afoul of EINTR issues and fail to unlock, so no worse than the status quo :)
<spiv> And hopefully better for at least some transports.
<poolie> oh, i'm not saying this is a reason not to unwind on those signals
<poolie> rather that people may just find that they get TooManyConcurrent things
<poolie> instead of it actually unlocking
<poolie> however we can fix that one step at a time
<spiv> Right.
<poolie> spiv, i'm away after today, is there anything you want me to do, or to give my attention to?
<spiv> Not off the top of my head.  If I think of something I'll let you know ASAP.
<thumper> http://www.ibm.com/developerworks/aix/library/au-spunix_bazaar/index.html
<thumper> in case people missed it
<thumper> interesting that the author is a ruby on rails guy
<thumper> (interesting in that most of ruby people use git)
<glyph> Hey guys.  Any workaround for this?  <https://bugs.launchpad.net/bzr/+bug/622549>
<ubot5> Launchpad bug 622549 in Bazaar "bzr 2.2 as bundled for MacOS can't make a branch of CalendarServer (affected: 1, heat: 6)" [Undecided,New]
<spiv> jelmer: got a workaround for glyph?
<spiv> glyph: I suppose you could try get Launchpad to import it...
<spiv> glyph: I wouldn't expect it to do much better, but at least it'll cause the LP devs to care about the bug too ;)
<glyph> spiv: Well, you've got the URL :).  Unfortunately my next step is to go back to SVN, unless I can find an immediate workaround.
<glyph> spiv: is there already a launchpad project for C&CS?
<poolie> glyph: i would try installing bzr-svn into ~/.bazaar/plugins
<poolie> from its trunk
<spiv> glyph: not that I know of.  If a quick search doesn't find one I'd just register one.  It's not too hard to shift the branches across later if it turns out there is a project for it already.
<poolie> glyph: to judge from the bug it seems to be a dupe of, it is a bug in the mac packaging not in the code it-self
<glyph> poolie: huh.  from trunk?  how about a release version? :)
<poolie> or the latest release
<glyph> OK, I'll give that a shot tomorrow, catch you later :)
<vila> hi all!
<glyph> poolie: After sticking the last bzr-svn release into my ~/.bazaar/plugins, it is looking good-ish
<poolie> glyph: that's great
<glyph> poolie: thanks for the help :)
<poolie> np, sorry for the snag
<poolie> and thanks for the feedback
<GaryvdM> Hi poolie.
<GaryvdM> I'm looking at Bug #621161
<ubot5> Launchpad bug 621161 in Bazaar "failed to load compiled extension: cannot import name _bytes_to_text_key (affected: 1, heat: 8)" [High,In progress] https://launchpad.net/bugs/621161
* lindbohm.freenode.net changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.2-final has gone gold, build those installers
<poolie> thanks gary
<GaryvdM> poolie: I see you added the *_pyx.c files to the packaging branches, but they are not in the debian unstable branch. Any objection to me removing them?
<poolie> no
<GaryvdM> Ok
<poolie> i didn't intentionally specifically add them
<spiv> cody-somerville: https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/528041 has SRU approval now
<ubot5> Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 145)" [Undecided,Confirmed]
<spiv> Heh.
<GaryvdM> jelmer: It seems like you have renamed .bzrignore to .bzrignore.THIS in  http://bzr.debian.org/pkg-bazaar/bzr/unstable/
<jelmer> GaryvdM: ah, thanks
<Guest76162> I suspect that may be related to bzr merge-upstream removing .bzrignore
<poolie> vila, spiv was going to see about getting the sru policy to state that we're allowed to put in point releases
<poolie> i don't know if we should still push on this
<poolie> spiv it might be worth still just talking the issues over with one of the sru managers
<vila> poolie, spiv: great to hear, I'm pretty our point release policy is in line with the SRU one but we may need a few iterations to convince people
<vila> s/convince/demonstrate or something/
<poolie> mm, i think it is
<poolie> vila, you could talk to them instead/as well if you want
<poolie> i think colin watson is one
<poolie> night spiv, GaryvdM
<GaryvdM> night poolie
<spiv> poolie, vila: I was talking with pitti about this earlier today
<vila> spiv: cool, and the summary is ?
<spiv> vila: the key bit I guess is <pitti> if all the changes in the new version are just safe and tested bug fixes, it's generally accepted
<spiv> vila: plus the regression risk for our changes are quite low (especially as bzr isn't going to make your system unbootable)
<spiv> And concretely he approved the diff for the 2.1.2 update quite quickly: our test suite gives a lot of confidence I think.
<vila> spiv: great, so our efforts will pay off. If we can get newer bzr versions into older ubuntu releases that will make less maintenance for us :)
<poolie> i wonder why the _pyx.c files are showing up in the diff?
<GaryvdM> poolie: In some versions of the packaging branch, .bzrignore is removed / renamed.
<GaryvdM> I'm not sure what creates the diff though, so that may be a miss diagnosis.
<spiv> poolie: My guess is the .deb packages are based on our release tarballs, which include *_pyx.c files IIRC
<spiv> Certainly the packaging branch has no common history with lp:bzr :/
<thrope> hi - is there any way to copy a file from one branch to another unrelated branch while preserving history for that file?
<Noldorin> i'm trying to manually remove a plugin from bzr, but when i delete it from the plugins folder, bzr still recognises it (listed under 'bzr plugins'
<Noldorin> what's the problem here?
<maxb> There must be another copy installed somewhere else
<thrope> Noldorin: maybe you have an egg ... check for anything in site-packages
<Noldorin> thrope, right...
<fullermd> thrope: No, you can't really do that sort of copy.  Files don't have history, history has files.
<thrope> no plugin or tool to just play the commits affecting that file (and only the bits affecting that file) in a new repo?
<fullermd> Not that I know of.  Unless there's something in rewrite.
<thrope> ok thanks
<Noldorin> thrope, maxb: nothing in site-packages now, but it's still listing
<thrope> do you have a .local or anytihng in your home directory?
<maxb> Noldorin: start a python interpreter, do "import bzrlib.plugins.whatever" then "bzrlib.plugins.whatever"
<Noldorin> ok
<Noldorin> thrope, where would that be (on windows)?
<Noldorin> maxb, yeah, so that pointed to a 'tfs' dir in site-packages, which i then removed. same problem though
<thrope> oh I'm not sure - youre user home directory but I think thats much less likely on windows
<thrope> how are you running bzr? if it is through tortoise have you restarted?
<maxb> Noldorin: do it again after removing whatever you removed, then
<Noldorin> maxb, maybe this sheds some light on the problem? http://pastebin.com/D0h8u1xK
<Noldorin> thrope, via the command line.
<Noldorin> it's installed as an EXE until c:\program files\bazaar
<GaryvdM> Noldorin: If you run bzr plugins -v, it shows you the file location that it got the plugin from.
<Noldorin> GaryvdM, unfortunately it doesn't list the directory of the plugins that couldn't load
<Noldorin> just they they couldn't be loaded from 'C:/Program Files/Bazaar/plugins'
<Noldorin> hrmm
<GaryvdM> Noldorin: From the pastebin, it seems you have 3 copies of tfs: 'C:/Program Files/Bazaar/plugins/tfs', 'C:/Program Files/Bazaar/plugins/tfsd' and another that should show in plugins -v
<Odd_Bloke> Hello all.  Is it possible to fast-export a particular subdirectory of my bzr branch (i.e. /addons/accounts/) and get rid of a prefix of the paths?  So all the commits related to /addons/accounts/ would be output as relating to /accounts/.
<jelmer> Odd_Bloke: any reason for not just using "bzr split" ?
<Odd_Bloke> jelmer: Ignorance. :)
<Odd_Bloke> jelmer: I still need to be able to fast-export, to import into a git repo.  bzr split doesn't seem to do this?
<maxb> GaryvdM: new bzr-pipeline packages uploaded to bzr/proposed.
<GaryvdM> maxb: Great~
<GaryvdM> 11 hour build queue though :-(
<maxb> I cheated slightly, and uploaded them as urgency=medium :-)
<maxb> lucid build just finished :-)
<GaryvdM> Oh - I did not know that made a difference :-O
<jam> hey vila, good to have you back
<GaryvdM> Hi jam.
<vila> hey jam ! Good to be around and welcome back too :)
<Noldorin> GaryvdM, http://pastebin.com/KqNnVWc2 - not quite i'm afraid
<Noldorin> GaryvdM, any thoughtS?
<GaryvdM> Noldorin: Well - I would start by removing the tfsd copy.
<Noldorin> GaryvdM, it's not there :S
<jam> vila: ping about https://code.launchpad.net/~jameinel/bzr/2.3-btree-chk-leaf/+merge/31904
<vila> jam: /me scratching head
<vila> jam: they are test fixtures, I can't think of a previous case where we needed test fixtures in production code
<vila> jam: are they static functions or can you call them from a different C module ?
<jam> vila: they are thunks over to the actual C code
<jam> I can call them whatever you want
<jam> I can't really put all of them in another module, since some of them are on the class
<jam> I can call them "_foo" instead of "foo" or py_foo or whatever
<jam> and we have those in other code
<jam> though I probably called them py_foo
<GaryvdM> Noldorin: I'm sorry, I'm not sure then.
<Noldorin> GaryvdM, no worries. but yeah, it's odd. no tfs/tfsd folder anywhere
<vila> jam: I won't block on that but having test fixtures in production code tells me something is wrong either the API doesn't expose the right bits to be testable or we don't test the right things or... dunno, bad feeling
<vila> may be just make them private or something if they are just accessors...
<GaryvdM> Noldorin: Have you looked at .bzr.log?
<vila> it may also be because they should be tested from a C framework...
<vila> jam: may be the 'test_' prefix triggered a knee-jerk
<jam> vila: if I was writing Cython code, I would have used "cpdef foo"
<jam> which defines both a pure-python 'foo' and a C 'foo' and selects the right one at compile time
<vila> they don't test anything really
<vila> hmm, interesting, when do we switch ? :D
<jam> vila: they don't test anything, they expose a function to pure python that I only want the code to be calling from within C
<vila> jam: right, so they are accessors targeted at tests, may be a simple s/test_/get_/ will be enough
<jam> would you be happier with py_ or _py_ prefix?
<vila> jam: yup, I think so
<Noldorin> GaryvdM, http://pastebin.com/hkfm92kc
<Noldorin> interesting
<jam> they are a little bit test related, since the return types, etc are tuned for ease of testing, versus ease of use as an api
<vila> jam: no problem with that, if more uses are discovered, since they are private, they could be tuned again :)
<jam> they aren't exactly accessors, since some of them actually call another function
<jam> but some, yes, since they wrap the internal object back into python objects
<vila> jam: on the other hand, IME tests help a lot to find the right APIs... so I'm not that concerned about them not addressing needs you didn't... need :)
<GaryvdM> Noldorin: Line 13 does seem to suggest that there is a C:/Program Files/Bazaar/plugins\tfsd
<Noldorin> GaryvdM, yeah, it's really strange. it definitely doesn't exit.
<jam> *sigh* I just upgraded to Thunderbird 3, and it turns out to be a bigger memory hog that *Firefox*
<jam> I had to prune a lot of old stuff because otherwise the indexing would hit 1GB+
<jam> (I had ~300k spam messages, that I didn't really want indexed, and was just keeping in case I wanted to train a future spamassassin, sort of thing)
<GaryvdM> jam: Yhea - I ended up disabling the indexing.
<jam> the global search seems interesting, but the bloat, dear god the *bloat* :)
<fullermd> 300k spams?!
<fullermd> Why would you keep a whole week around?
<jam> I should not be getting lag *while typing*
<GaryvdM> I give the indexing a go again when 3.1 is available in ubuntu
<jam> GaryvdM: I also find it very surprising that on Windows, they put the global sqlite file in Roaming. Which means 400-1GB of data gets put in what would be your 'synchronized between machines' location.
<jam> GaryvdM: you *can* select a folder to not be indexed, but you have to do it manually for each folder you want that way, I couldn't find a way to batch select
<jam> which was also pretty annoying, since I was sorting old content
<Noldorin> GaryvdM, as stumped as me, eh?
<GaryvdM> Noldorin: Yhea. I would maybe resort to using pdb, but maybe someone else may be able to help.
<Noldorin> GaryvdM, ok, no worries. thanks anyway
<Noldorin> pdb i might try, yeha
<dahoste> hey #bzr gurus.
<dahoste> I'm a recent convert from svn.  Loving bzr so far.  Lightweight checkouts were the seal-the-deal feature for me (over hg).
<dahoste> I have a new project about to get started, though, and there's a very strong case for needing 'sparse' (sometimes called 'partial') checkouts, which are common in svn-land.
<dahoste> What are the odds of ever seeing good native bzr support for such a feature?
<fullermd> Well, I'd like to see it, but I don't think it's in screaming distance of the top of anybody's todo list...
<dahoste> I.e. is it architecturally feasible, and just hasn't been done yet, or does the notion itself go too severely against the grain of bzr's concept of repo?
<jam> dahoste: the recommendation is to split up the project into multiple smaller projects
<jam> it is against the concept of 'atomic tree'
<jam> possible, we've discussed it periodically
<fullermd> Well, distinguish partial _checkouts_ from partial _branches_.  There's no sensible way to _branch_ just a subpart of a branch, but there's no reason at all that you can't conceptually have a _working tree_ that only has some of the files.
<fullermd> Bah.  So does being able to specify files to 'commit'.  In fact, it's exactly the same againstness.
<jam> but it raises some issues with 'commit' when files aren't present, and what to do if 'merge' would touch files you don't have, etc
<dahoste> yeah, in my case I figured the 'need' for partial checkouts should probably be converted into an argument for re-organizing the project into multiple pieces.  That's sensible to some degree, but still runs aground in some places.   The _ideal_ scenario would indeed allow for partial branches, but partial checkouts would be a huge win.
<dahoste> jam, as for commit issues... it probably makes a huge difference whether a hypothetical 'partial' working tree is partial in a fine-grain sense (i.e. scattershot, file by file, dir by dir) vs. partial in a course-grain sense (the checkout designated a node in the tree as a root point and implicitly included everything from there down, as an 'atomic subtree').    If that makes any sense....
<fullermd> Well, I don't worry about partial branches.  That's a major break, and besides, as long as you're in a repository, the marginal cost of a branch is near zero.
<dahoste> But I'm talking just from an outside perspective.  I don't have any insight into the guts, of either svn or bzr.   For instance, I know svn poops in every dir of the working tree ('.svn') but don't know if that's the lynchpin in its ability to do partials, or is just incidental implementation detail.    And note that I love the fact that bzr doesn't poop all over the working tree.
<rubbs> I'm not familiar with partial checkouts/branch workflows, but would views help?
<fullermd> Well, since svn doesn't have any "base" granularity, it sorta has to have arbitrary support to work at all.
<fullermd> Since each dir only knows about itself and its subdirs in a .svn/ sense, partials Just Work(tm).  Doing it all from a central location requires explicitly adding support.
<jam> dahoste: one of the primary problems with the svn model is that while commit either succeeds or fails, it doesn't track whether the files are in a consistent state across the tree
<jam> meaning. if you commit to 'foo' I can commit to 'bar' without updating foo
<jam> even though they may be logically linked
<jam> pretty much all DVCS take that to the next step, and say that everything in the tree must be up to date for the commit
<jam> (each commit is a tree-wide state)
<jam> being able to branch 'part' of that doesn't make a lot of sense
<dahoste> rubbs, I did initially hope that views combined with a lightweight checkout might scratch the itch well enough.  But my understanding of views is that they're really just local 'convenience' filters, and don't affect what comes/goes over the wire, or what actually resides in the working tree.
<rubbs> dahoste: correct, but I'm not sure why that's such a big problem. Again, I'm naive about partial branch workflows, but why would you not want a consistant branch altogether? Partials to me seem to give a disjointed feel.
<jam> rubbs: my guess is for someone coming from svn, where everything is one-big-tree
<fullermd> Again, distinguish partial branches from partial checkouts.  Since revisions are whole-tree, partial branching is a serious model break.
<fullermd> Partial checkouts aren't.  Certainly you can think of a handful of different levels of support, of increasing demands on the tool, but...
<dahoste> jam, yeah, I guess that's just the inherent trade-off of the design.   And don't get me wrong - I'm not faulting bzr for not being able to do partials.  But it came up as a potential show-stopper for using bzr in a new project, and I just wondered what the likelihood was of bzr ever fielding such a feature.   hg has some half-baked notions about it, but I'm not holding my breath about it either -- I'm sure it faces similar architectural obstacles t
<dahoste> o doing it as bzr.
<jam> dahoste: the most likely solution bzr will implement is similar to git's submodules, and IIRC hg's forest extension. Where you can define that *this* tree depends on 'those' trees. So when you do a checkout of the top level, you get everything, but you can also just request for a single subtree
<fullermd> I don't believe there's a single architectural obstacle.  It's just a moderate hunk of implementation.
<jam> Right now we have scmproj and bzr-externals, to do something like this
<jam> poolie has mentioned that it is likely to be a priority feature in the next 6-month cycle
<fullermd> That's just not the same at all..
<dahoste> rubbs, partials are disjointed.  And even in svn, where it's par for the course, there's an understood responsibility on the part of the person using a partial to keep in mind that they're (purposefully) working with just part of a larger dependent tree.  There's nothing stopping them from doing something stupid and breaking something 'uptree'.
<jam> fullermd: it isn't the same functionality (a priori versus ad hoc subtrees), however it solves the basic use cases that we've determined from people wanting the feature
<jam> "I just want docs" (make it a subtree), etc
 * fullermd points at the ports tree.
<dahoste> yes, hg's forest seems like it might be enough.   And (for me anyway), a priori subtrees would be just fine... I don't need svn's ad hoc support.      Yeah:  it's the classic case of:  subdir so-and-so of a big src tree functions independently _enough_ that someone can contribute to it meaningfully without being burdened with the entire tree.  Particularly if, say, the subtree can be had for a few MBs or less, and the rest of the tree takes a few G
<dahoste> Bs.
<dahoste> And while that's also the case that argues most strongly for just constituting the project as multiple sub-projects, it's nice to be able to still be capable of managing the project from one mega root node (for those that need to).   Having cake and wanting to eat it too.  :)
<dahoste> Thanks all for your thoughts and time.   I'll keep my eye out for progress on nested-trees, or any other similar approach.   Cheers!
<mneptok> http://www.ibm.com/developerworks/aix/library/au-spunix_bazaar/index.html
<maxb> GaryvdM: You said you did an installability test on hardy...... including loggerhead?
<pygi> heya
<pygi> :)
<maxb> Why do we ship testtools and subunit in the bzr PPAs?
<james_w> maxb: they are needed for the testsuite, so either Build-Depends, or for the benefit of developers?
<maxb> lifeless: hi. do we just publish testtools and subunit in the bzr ppas for developer convenience, or is there a greater reason?
<maxb> (I've noticed that Launchpad has somehow managed to silently fail to publish testtools in ~bzr/proposed jaunty+karmic, though the web ui says it has)
<lifeless> I don't remember :(. We do occasionally ask a user to run the test suite to check platform idionsyncracies
<maxb> I am tempted to rebuild both subunit and testtools to get rid of the version numbers which pretend to be main-archive uploads but aren't :-/
<jam> GaryvdM: are you using the win32 ec2 host?
<jam> vila: are you around?
<jam> jml: you don't have any tags for testtools releases aside from 0.9.2
<jam> in lp:testtools
<rubbs> Ok, quick question, it's been quite some time since I've been in the bzr world. In terms of checkouts, a Heavyweight checkout is the default, and really it's just a local branch that sends it's commits to it's master before it commits locally. And a Lightweight checkout is more like SVN checkouts. Is this correct?
<dash> rubbs: correct.
<rubbs> dash: thanks.
<fullermd> Except thinking about heavy checkouts like that is IMAO likely to confuse more than help...
<rubbs> Ok, now I think I'm getting it. Then binding a branch "A" to branch "B" makes A a 'heavy checkout' with B as it's master. Unbinding A from B would change it back to a normal standalone branch (assuming it's not in a repo) correct?
<dash> fullermd: why so?
<rubbs> fullermd: how so? how would you suggest thinking about them?
<fullermd> Cue iteration 11,471 of "bound branches vs heavy checkouts"...
<fullermd> Better to think of no heavy or light, just checkouts with or without a local cache.
<dash> rubbs: some folks have made a distinction between checkouts and bound branches but i never figured it out.
<rubbs> is there something I can read on this. I don't mean to beat an already dead horse
<dash> i do, i do ;D
<rubbs> haha
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches
<rubbs> thank you.
<dash> yeah but that's not documentation about how bzr works =/
<fullermd> No, how bzr works is that it has neither bound branches nor heavy checkouts.  It has something that's part one, part the other, and used for botrh.
<dash> it sounds like you are using those terms differently from everyone else then :)
<fullermd> Leaving aside "how it should be", I still believe that THINKING of the two as separate things and bearing in mind which mechanism you want in any given case, will make things work smoother in the long run, even though to bzr the two are the same.
<fullermd> I don't think so.  I think I'm just using them more clearly.
<dash> so... to bzr, they're the same.
<dash> okay then :)
<fullermd> (I also think bound branches tend to be more confusing than checkouts, and that a lot of people aren't clear as to which role they're trying to use, which is the primary source of corner-painting)
<rubbs> Ok, maybe this would be better to ask the best way to implement the following workflow: I'm looking for a way for developers to have their own branches, but have those branches mirrored on a central location so that it makes it easier for backups (for me). Here's the kicker though, most devs are on the LAN so network traffic wouldn't be bad, but we have two devs who work from home. I'd like a way for them to be able to lots of stuff locally ...
<rubbs> ... and sync up when needed.
<rubbs> to do lots *
<fullermd> IMO, as soon as there's a network involved (even a LAN), light checkouts can be fairly well ignored (perhaps not conceptually, but certainly implementionally)
<fullermd> Bound branches sound like what you want there.
<rubbs> well right, hence the heavy vs bound branch I was goint to ask ;)
<rubbs> sounds like heavy checkouts are more svn-esk and bounc branches are just mirrored branches. (conceptually at least)
<fullermd> The distinction as to which way you'd think about it there, I think, would hinge on the question of how you think about where the branches are.
<fullermd> If you're thinking of devs having their own branches on there machines, that are automagically mirrored to the server when they do stuff, that's a bound branch.
<fullermd> If the dev's branches are on the server, and they just happen to have a full cache of it in their local WT, that's a heavy checkout.
<dash> in other words... a distinction without a difference.
<rubbs> ok, but are they implemented the same way?
<rubbs> I understand what you are saying
<fullermd> Well, history in bzr vs. history in git is a distinction without a difference too.
<fullermd> Well, they're implemented the same way because bzr doesn't acknowledge any distinction.
<rubbs> I will likely teach them the heavy way as I think I'd like them to stick with "server" centric ideology, but I'm hoping that this doesnt' limit me on a technical side. If I do heavies and not bound branches, am I going to cause problems if I need to convert those heavy co's to standalones on their machines?
<rubbs> ah
<rubbs> you just answered my question then. thank you
<rubbs> but I think I understand your distinction there and I think it's going to be easier to teach them that.
<rubbs> thanks
<rubbs> My questinos were more of a clarification of what I was pretty sure I knew, just didn't know how to say it, so you guys helped me figure that out
<dash> rubbs: to convert to a standalone branch you do 'bzr unbind'
<dash> rubbs: and also you can do 'bzr ci --local' to commit without sending it upstream
<dash> (without unbinding)
<rubbs> dash: ah that last one is perfect, I should have remembered that.
<rubbs> thanks
<rubbs> also is there any difference between checkin and commit? should be the same correct?
<fullermd> They're the same command.
<fullermd> The difference is about the same as the difference between [ and test  ;)
<rubbs> haha, great thanks
<ddaa> except less evil... [ is one evil bit of shell hacker
<ddaa> it looks like a grouping syntax, but it's just a command name
<fullermd> I prefer to think of that more as a symtom of the infirmery of sh as a language than a failing of test  ;p
<jelmer> it's evil disguised as cleverness
<dash>  everybody's got a shell with [[ now though
<fullermd> $ which [
<fullermd> /bin/[
<ddaa> sh makes sense as far as it goes, but [ is like a alligator in the hide of a kitten.
<ddaa> dash: that's funny you should say that, considering your nickname :-)
<ddaa> maybe it's even bash.org worthy :-)
<fullermd> Oh, the doubly irony   :p
<fullermd> Extra funny how I just spend the last week watching another round of "we need a better scripting language than sh" run around a mailing list   :p
<ddaa> submitted to bash.org as 928499
<ddaa> fullermd: just saw that on pypi: http://pypi.python.org/pypi/pc/0.0.1
<fullermd> Ick, but you'd have to have python for that   ;]
<fullermd> I like how version 0.0.1 was uploaded today, and 0.0.3 was uploaded...  today.
<fullermd> Now that's fast development.
<ddaa> or banana software
<fullermd> Oh, I was hoping they had a more creative syntax I could steal...  shucks.
<ddaa> like using __repr__ for command substitution? :-)
<fullermd> Over my head   :p
<ddaa> in python<3, `foo` is an alias for repr(foo), it little known though
<fullermd> But I have a vague desire for some sneaky-simple syntax for calling out commands for my creeping-along make(1) replacement.
<fullermd> Haven't yet looked at it in-depth, since it's way down the todo list.
<ddaa> maybe check logix: http://logix-language.sourceforge.net/
<dash> that's pretty dead unfortunately :(
<ddaa> it's still kind of neat
<ddaa> python lacks a good DSL framework
<fullermd> Well, that's why I figure if I work slowly enough at it, I can just convert it to perl 6 before it's ready for release  ;p
<jam> losa ping
<mbarnett> heya jam
<jam> hi mbarnett, I'm trying to figure out if pqm is hung or not, can you check it out? I sent it something that ended up having a lot of failures for python2.4, and I haven't gotten any response yet.
<jam> I fixed it up, and resubmitted, but I don't see the new request either
<jam> I was worried the response email might be too big, and gumming things up
<jam> mbarnett: anyway, its end-of-day for me now, and I think it just showed up, so if you're busy, it can wait until tomorrow
<mbarnett> jam: heh, i'll certainly poke at pqm and look for any obvious errors
<jam> mbarnett: thanks
<mbarnett> welcome
<jelmer> hmm
<sttng359> hello
<sttng359> I'm having trouble with bzr-svn and symlinks not being created correctly
<sttng359> sometimes I get zero-length files where there should be symlinks
<sttng359> svn check out without issue.
<sttng359> When I checkout the images folder directly with bzr, I get symlinks, but when I checkout the top-level trunk folder, it creates zero-length files for symlinks in the images folder
<sttng359> oh, it appears I have bad information in the shared repository I'm using
<sttng359> A fresh checkout of trust without shared repo does create proper symlinks.
<sttng359> trust should be trunk.
<sttng359> is there any way I can try and resync my existing repo with svn?
#bzr 2010-08-24
<jam> sttng359: rm -rf .bzr ; bzr init-repo .; bzr svn-import $SVN ?
<jam> a bit overzealous perhaps
<sttng359> jam: will existing bzr branches made against my current broken branch still work against a fresh svn import or will it look like a new bazaar branch?
<maxb> sttng359: I think there's a good chance they'll work fine, bzr-svn is supposed to be deterministic and repeatable. I'd say they'd definitely work, but I don't understand how your existing repository could be subtley broken in the way you describe
<sttng359> maxb: well, it now looks like every branch I have under that shared repo believes the symlinks should be zero-length files and creating branches outside of that shared repo replicates that, but a fresh checkout using bzr from subversion correctly generates symlinks.
<sttng359> I was using that originally to create a couple different test branches without cluttering up subversion, but I may have to recreate them all.
<sttng359> nope, existing bazaar repos don't recognize my new checkout.
<sttng359> maybe it has to do with using a 1.4 subversion server.
<aaron01> I'm getting "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 50: ordinal not in range(128)" when trying to bzr import a tarball. However, if I import the extracted contents of the tarball it works fine. Ideas?
<spiv> aaron01: sounds like a bug :/
<spiv> aaron01: please file a bug report
<spiv> Hmm.
<spiv> Off the top of my head the tarball import code assumes all filenames are ascii, but the import from filesystem directory can use the system locale to guess filesystem encoding.
<spiv> I'm not sure if tarballs store filenames as bytes or in a defined encoding.  I suspect bytes... but if so, we could add an option to allow you to explicitly specify the filename encoding.
<fullermd> I'd be astonished by anything other than bytes, if for no other reason than that tar predates encodings.  Well, unless you count EBCDIC, maybe...
<spiv> fullermd: well, there have been occasional extensions to the format IIRC, but yes.
<sttng359> spiv: from what I understand, the USTAR format for filename is a byte field
<sttng359> http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current
<sttng359> does bazaar attempt to convert filenames to UTF-8 for storage?
<fullermd> Wow, 8-current...
<spiv> Well, they are unicode in bzr's storage model.  The implementation happens to be UTF-8 IIRC, but that detail isn't particularly relevant here.
<aaron01> I think it might be helpful if the traceback would be more verbose about what file it is failing on
<thumper> BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:0fe7e46a367f403f3a2e51af8fa78962cba9f8d3',)]
<thumper> getting this with 2a merge directives
<spiv> thumper: hmm
<thumper> spiv: probably has stacking issues too
<spiv> thumper: possibly the source repo needs the fix at https://bugs.edge.launchpad.net/bzr/+bug/613698 run on it
<ubot5> Launchpad bug 613698 in Bazaar "need reconcile fixer for bug 522637 "missing referenced chk root keys" (affected: 3, heat: 18)" [High,Fix released]
<spiv> thumper: or possibly there's an issue specific to merge directives
<thumper> spiv: bug 517126
<ubot5> Launchpad bug 517126 in Launchpad Bazaar Integration "BzrCheckError raised creating a merge proposal (affected: 1, heat: 0)" [High,Triaged] https://launchpad.net/bugs/517126
<spiv> thumper: any chance of those "more details" getting filled in? :)
<spiv> thumper: like which branch?  or the contents of the merge directive?
<thumper> spiv: possibly
 * spiv -> lunch
<AfC> Is there a "known" bug about Bazaar not expanding ~ in revision specs?
<fullermd> bug 138787
<ubot5> Launchpad bug 138787 in Bazaar "revspec paths don't interpret user refs (affected: 0, heat: 0)" [Wishlist,Confirmed] https://launchpad.net/bugs/138787
<AfC> fullermd: yeah, that seems like it
<AfC> so annoying
<AfC> fullermd: I'm not sure "user refs" is really the right label for it
<AfC> to me it's "tilda" and "home dir[ectory]"
<AfC> fullermd: can I suggest
<AfC> "revision specs don't expand ~ or ~user in paths"
<AfC> or such?
<fullermd> Well, ideally I'd suggest "fix released"   :p
<fullermd> 3 years in, it's hard to work up much expectation though.
<AfC> be nice
<AfC> fullermd: I commented your bug with our use case; perhaps that'll up its google juice.
<AfC> Cheers
<vila> hi all !
<Kamping_Kaiser> hi all. i had a bzr branch <svn repo> drop out. is there a way to resume it? rerunning bzr branch or bzr up just error, in different ways
<Kamping_Kaiser> i'd rather not redownload 1.8gb again :( (and still going)
<maxb> Was the branch a standalone one or into a shared repo?
<Kamping_Kaiser> standalone
<maxb> Try running 'bzr heads --dead' in the partial branch
<Kamping_Kaiser> ok. i'm just making a copy, i'll try it after that :)
<maxb> Why are you making a copy?
<Kamping_Kaiser> bzr: ERROR: unknown command "heads"
<Kamping_Kaiser> because i can't afford to download 1.8 gb again, so i don't want to break a copy
<maxb> Install bzrtools
<Kamping_Kaiser> hm, i thought i had it. let me check
<Kamping_Kaiser> thanks
<Kamping_Kaiser> i don't have it, branching it atm
<Kamping_Kaiser> maxb: got it, it removed a commit. do i resume by branching again?
<maxb> uh?
<maxb> 'bzr heads --dead' is a query command. it changes nothing
<Kamping_Kaiser> ah, hehe. the svn commit message contained a coment about removing stuff. guess i confused them
<maxb> ok, so bzr heads --dead showed one revision, the latest svn revision that actually got transferred
<maxb> the question now is how to convince bzr to pick up where it left off
<maxb> Does a .bzr/branch/ directory exist at all?
<Kamping_Kaiser> no. there is a .bzr/branch-lock dir, but not branch
<maxb> "bzr branch svnurl ." might work, if not we'll have to get more devious
<Kamping_Kaiser> sadly, 'bzr: ERROR: Target directory "freeciv" already exists.'
<maxb> Try adding --use-existing-dir
<jelmer> 'bzr init && bzr pull <svn-url>' perhaps?
<jelmer> maxb: I think that will still try to create the .bzr dir
<Kamping_Kaiser> jelmer: thats trying to re-download it from scratch.
<Kamping_Kaiser> maxb: that returns 'bzr: ERROR: Already a branch: "freeciv".'
<Kamping_Kaiser> but trying to pull in the dir i get 'not a branch :/
<maxb> I am not so sure, I think jelmer's command would work (run in the directory with the existing .bzr from the first try)
<Kamping_Kaiser> hm
<Kamping_Kaiser> wonder whats going on
<maxb> Any opinions on how long I should wait for potential dissent before copying bzr/proposed to bzr/ppa ?
<jelmer> maxb: I would be surprised if resume worked in a standalone branch
<jelmer> maxb: it's a known bug that it doesn't :)
<jelmer> maxb: Was the pyrex issue fixed?
<maxb> yes
<jelmer> in that case I'd say go for it
<vila> maxb: did we get feedback from people testing bzr/proposed ?
<jelmer> it's working here, and the only other thing I've heard from others is the pyrex issue
<maxb> The only active feedback I'm aware of is the report of the pyrex issue
<maxb> we have tested that the archive as a whole is installable
<vila> maxb: then I agree with jelmer: go
<Kamping_Kaiser> hm, perhaps jelmer was right. its only pulling 2000 revisions, so perhaps its pulling the remaining files
<Kamping_Kaiser> wow... thank you maxb and jelmer, bzr is 'doing stuff' again :)
 * maxb bites the bullet and executes lp-promote.py bzr/proposed bzr/ppa
<bigjools> is the non-compiled extension thing fixed?
<maxb> yes
<bigjools> \o/
<maxb> whee, look at all the little green cogs :-)
 * vila notes: always add green cogs
<Kamping_Kaiser> hm. bzr appears not to handle its terminal getting resized down very wel :/ (unless its my old version, which it could well be)
<jml> sad
<jelmer> jml: ?
<jml> I just had to type this:
<jml> bzr resolve src/zope/testing/testrunner/testrunner-ex src/zope/testing/testrunner/testrunner-ex-pp-lib src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4 src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4/products src/zope/testing/testrunner/testrunner-ex-pp-products src/zope/testing/testrunner/testrunner-ex-pp-products/more src/zope/testing/testrunner/testrunner-ex/sample1 src/zope/testing/testrunner/testrunner-ex/sample1/sample11 src/zope/testi
<jml> r/testrunner-ex/sample1/sample13 src/zope/testing/testrunner/testrunner-ex/sample1/sampletests src/zope/testing/testrunner/testrunner-ex/sample2 src/zope/testing/testrunner/testrunner-ex/sample2/sample21 src/zope/testing/testrunner/testrunner-ex/sample2/sample22 src/zope/testing/testrunner/testrunner-ex/sample2/sample23 src/zope/testing/testrunner/testrunner-ex/sample2/sampletests src/zope/testing/testrunner/testrunner-ex/sample3 src/zope/testing/testrunner/
<jml> x/sampletests
<jelmer> ahh
<jelmer> I was wondering whether you couldn't find your livejournal window :-P
<jml> hah hah
<vila> jml: were there all text conflicts ?
<vila> jml: a bare 'bzr resolve' is supposed to resolve all "auto solvable" conflicts, but...
<jml> vila, no text conflicts.
<jelmer> jml: Or, bzr resolved --all?
<jml> vila, this is the same old bug that I always complain about
<vila> jelmer: vade retro satanas: never use that
<jml> good grief
<vila> jml: oh, the.pyc files ?
<jml> I've never heard anyone say that in Latin
<jml> vila, yes.
<vila> jml: on top my conflicts TODO list... but ETOOMAYTODOLISTS
<vila> jml: crystal ball predicting that it may be surface as soon as this week though...
<vila> jml: oh, in the mean time, I think 'bzr clean-tree --detritus' helps
<jml> vila, thanks.
<Kamping_Kaiser> sheesh. bzr can hammer the cpu when it wants. guess its repacking 1.8gb of data though
<kpettit> I'm new to bzr and trying to figure out the best way to do something.  I have a main code repository that tends to have different code for each customer.  I need to have a main default repository then one for each customer, trying to keep code in sync.  95% of the code stays the same.
<kpettit> I'm trying to figure out the best way to set this up. So I can have in a directory  "main" directory then directories for "customerA" "customerB" etc.
<maxb> It *sounds* like you want a "main" branch containing customer-agnostic code, each customer is a branch off main, main gets merged into customer branches when needed, but never the reverse
<maxb> On the occasion that a change on a customer branch is deemed applicable for main it gets cherrypick-merged
<rubbs> is there any documentation on cherrypick-merges? as kpettit's question is very similar to something we will need here.
<kpettit> rubbs: I'll see if I can find anythning on that  http://wiki.bazaar.canonical.com/CherryPick  is the first thing that comes up.
<rubbs> kpettit: thank you
<kpettit> For my project it's a web html/css/js thing.  Everything is the same except a couple of custom css and js files.  I won't have those in the main repository, but I want to have them in each of the individual customer branches.  So I want to be able to update customer brances with latest default code and also keep seperate customer css/js custom files in their own repository.
<maxb> A cherrypick merge is a merge of a specific changeset *not* an entire branch of history. Of particular importance is to note that Bazaar does not track cherrypick merges at all in its own metadata.
<rubbs> maxb: good to know thank you.
<rubbs> kpettit: sounds similar to us.
<kpettit> so there isn't a good default way to do what we're wanting then I guess?
<kpettit> rubbs: Check this out http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<jml> *sigh*
<jml> Unable to load plugin 'pipeline'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1)
<rubbs> kpettit: yes, I did know about shared repos, and I"m looking into stacked branches.
<kpettit> that sounds promising.
<rubbs> I've used bzr before, but always for personal stuff, so I never needed to know about many features, because I never needed them, but I'm having to (re)learn stuff for our company migration to bzr coming in a few months
<rubbs> I'm trying to come up with a good migration plan
<kpettit> basically doing the same here.  All on SVN right now, but it's painful and doesn't do stuff like this
<rubbs> right
<kpettit> If this idea works it'd be nice to apply the same thing to linux config files.  Where you have a default and branches for customizaitons and such.
<rubbs> Right as I was hired, my boss was talking about starting to use branches and thinking about merging down the line. Luckily he listened to me when I told him that multiple merges with svn was awful
<rubbs> kpettit: you may wish to look at etckeeper
<rubbs> I'm working on a plan for that oo
<rubbs> too*
<rubbs> it can use hg,git, or bzr
<kpettit> :)  I'll do what I can to avoid using cfengine
<rubbs> heh
<kpettit> etckeep is good for a individual system.  I was thinking for global where we have a default and clone to dozens/hundrends of systems then each of those have their own that can be checked in on a main system as seperate repositories.  Makes it easy to clone and develop individual custome systems that way
<rubbs> right. I know a friend of mine is developing something that might fit your needs, but at this point it's not even up to alpha stage yet. He's going to call it Ranchero.
<rubbs> I hope he gets something out soon.
<kpettit> I'll keep my eyes out for it
<rubbs> it could be a while, just a warning. He goes through spurts. Does a lot of work on it, then just lets it die for a while
<kpettit> I'm the same way
<rubbs> Am I correct in thinking that if you have a bound branch, unbind for a while, then rebind, that it will automatically sync revisions?
<rubbs> at the bind?
<rubbs> kpettit: not sure if you saw this, but it may help: http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/adv_merging.html
<kpettit> thanks, reading...
<kpettit> I got etckeeper as well.  The docs say it uses git by default but on ubuntu the default etckeeper package uses bzr which is cool with me
<rubbs> same here, you also use ubuntu for prod servers?
<kpettit> yes
<kpettit> I'm using rackspacecloud and mainly ubuntu 10.04 images
<kpettit> we do alot of windows stuff, but I try to ignore that as much as possible
<rubbs> know that feeling well ;)
<maxb> jml: hmm?
<jml> maxb, I just had to add a ppa, no big deal, just another hurdle.
<maxb> jml: ok, but what combination of ppas did you have that produced the error in the first place?
<jml> maxb, Lucid & the pipeline branch.
<jam> hi vila, thanks for the reviews
<maxb> Oh, I see
<maxb> jml: there's a lp:bzr-pipeline/2.1
<jml> maxb, too late now :)
<maxb> rubbs, kpettit: shared repositories and stacked branches are all about avoiding wasted diskspace - they have no bearing on your development workflow
<vila> hi jam
<kpettit> maxb: got ya.  Any suggestions?
<jam> vila: 'saw' doesn't seem to have python-testtools installed. Did I do something wrong?
<vila> jam: hmm, no, I use a private branch, let me check
<rubbs> maxb: right, I knew that. I'm the systems guy here, so I have to keep that in mind too, and in a way it will impact workflow as permissions to the central server will impact if I need to do stacked vs shared.
<maxb> kpettit: Is there any reason you want your customer specific stuff in a separate *repository*? What did you think of my initial suggesting regarding branches?
<maxb> rubbs: Ah, yes, that's a factor. I'd be interested to know what you end up with, I'm attempting to set up a fledgling bzr environment at my workplace too, in the hopes of wooing them away from svn
<rubbs> kpettit: you could keep things in a shared repo, and have separate branches for each client/customer.
<jam> vila: I set something up using PYTHONPATH, but that is a bit clumsy
<vila> jam: installing testtools and subunit
<jam> vila: thansk
<jam> thanks
<rubbs> maxb: I'm still working on ideas, but if I come up with one, or at least come up with a preliminary plan I'll spam the mailing list. Maybe I can get some improvements on the ideas I have ;)
<kpettit> maxb: you were right on what I want.  The main branch I want copied to child brances.  They child brances will have files that aren't in the main branch that need to be versioned but they will not need to commit from the child to main branch
<maxb> Oh, whilst I have testtools and subunit-knowing folks here: should we be updating the ~bzr ppa to the latest upstream of those?
<vila> damn, babune's xp slave is hosed :-/
<jam> maxb: If you are willing to do the work, it would be great to get the updates :)
<rubbs> kpettit: yeah, I would suggest a shared repo for you then, (or stacked if you want to limit commit access to certain branches) and just merge from the main, into the customer branches.
<kpettit> maxb, rubbs: So I'm trying to figure out the best way to do that, shared repo's seem promosing but I'm still learning.
<rubbs> LP uses stacked branches IIRC.
<maxb> jam: work? what work? dget python-testtools/sid; for i in hardy jaunty karmic lucid; do bzrppa-backport -s -u bzr/proposed -D $i *.dsc; done
<maxb> I really need to stick my handy scripts somewhere :-)
<kpettit> rubbs: that sounds like the right way to go.  I've just setup some test for it so I'm going to play around and see if ti works like I'm expecting.
<maxb> kpettit: the thing you need to understand is that shared repositories are merely a disk space / network io optimization. They don't affect the design of your workflow, really
<kpettit> got ya.  But I can merge from a parent repository to a child one and not overwrite or mess up and files that child has that the parent doesn't?
<rubbs> kpettit: what maxb just said, also adding that each branch will still be insular, by which I mean that even though you will be storing revisions in the same place, it will not automatically add revisions to branches you don't want them in
<rubbs> kpettit: I think you're confusing branches and repositories.
<kpettit> I might be
<kpettit> <-- new at this
<rubbs> branches are just an "order of revisions" in a sort of way. repos are just a place where revisions are stored.
<maxb> repository == an on disk store of revisions, nothing more. branch == a pointer to a revision that is tip of the branch (and implicitly all its ancestors)
<rubbs> by default (stand alone branch without a shared repo) a branch is it's own repository because the only revisions needed in that repo are the same as the ones on the branch.
<rubbs> in a shared repository, you can have many different branches.
<rubbs> revisions that are the same between branches are not duplicated.
<maxb> s/ a branch is it's own repository / both branch and repository are co-located in the same .bzr directory /
<rubbs> so if branch A has revisions 1,2,3 and branch B has 1,2,4 the shared repo will contain 1,2,3,4
<rubbs> thanks for that clarification maxb
<maxb> For clarity's sake, it's best to use a,b,c as placeholder names for revisions, since the integers can be confused with bzr revnos
<rubbs> ah, I will do that in the future
<kpettit> so if my child directories I want them to all keep a up to date copy of main set of code.  but I need them to have files that will never be in the main set of code and keep version info.  So if my parent is a "repository" are my childs of this branches or other repositories sense they will never commit back to the parent?
<rubbs> best to think about repos as a bin to store all revisions in it. Each branch is just a list of revisions and their order. So in your case, you would make a shared repo, then put your "trunk" or "main" in it. Then you would make a branch, also in the same repo, for customerA.
<rubbs> then when you wanted to get changes from the trunk into customerA you just do a "bzr merge trunk" while inside the customerA branch.
<kpettit> got ya.  that's what I'm trying now.  thanks
<rubbs> This will pull changes from trunk in, but will NOT put changes from customerA into trunk.
<rbriggsatuiowa> is there anyway to pass a plugin directory to bzr?
<vila> rbriggsatuiowa: there are several even :) see 'bzr help env-variables'
<vila> rbriggsatuiowa: depending on your need you will use BZR_PLUGIN_PATH or BZR_PLUGINS_AT
<rbriggsatuiowa> vila: bawesome - thanks
<rubbs> is there any way to make a stacked-repo? By which I mean, if I want to have the trunk with read only permissions, can I create a shared repo for each user that is stacked off that main trunk?
<rubbs> I'm looking for a roll your own poormans LP basically
<jam> rubbs: stacking is done at the 'branch' level, not the repo level
<jml> I'm trying to use pipelines to split up a big branch that I've already done a fair bit of work on.
<jam> you *can* set up a default stacking policy
<jml> never really used pipes in anger before
<rubbs> jam: is there any docs on how to do that?
<jam> jml: This is how I did it with regular branches, you could probably do something similar w/ pipelines
<jam> http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
<jam> I've never used bzr-pipeline myself
<jml> I guess if this were a loom, I'd make a trunk thread...
<jml> jam: thanks.
<jam> rubbs: not that I specifically know of, but I'm poking around looking now
<jam> jml: the key is abuse of 'bzr revert' and 'bzr merge' to maintain history, while still splitting out the content into simplified diffs
<rubbs> jam: thanks, I'll keep an eye out for it too. I'm currently re-digesting the official docs
<jml> jam: :)
<vila> pfew, backups are a blessing...
<jam> rubbs: the file is .bzr/control.conf
<rubbs> jam: ah thanks. I'll take a look at it
<jam> you can set 'default_stack_on = ...'
<rubbs> is this per client? or on the server side
<jam> rubbs: on the server side
<rubbs> perfect. Thank you.
<jam> basically, when creating a new branch we look up for a containing repo or just a .bzr directory
<jam> if we find one with that set, then we'll create a stacked branch
<jam> you probably could create shared repos for each user
<jam> and just put "echo ../central-repo > .bzr/control.conf"
<jam> obviously, you'll want to test it :)
<jam> for the full commands:
<rubbs> right. I have no intentions of putting this in place without some testing ;)
<jam> bzr init-repo --no-trees central; bzr init-repo --no-trees user1; echo "../central" > user1/.bzr/control.conf
<jam> although... I think a branch has to be stacked on another branch
<jam> so probably
<jam> echo "../central/trunk"
<rubbs> great thanks, I'm copying that out for reference thank you.
<jam> though you may also be able to do:
<jam> echo -e "default_stack_on = ../central/trunk\ndefault_stack_on:policy=appendpath" depending on how you would use it
<rubbs> sounds good. I have some reading to do now ;)
<jam> rubbs: I don't know about a lot of reading, vs just experimenting :)
<rubbs> haha, true. I'm looking into several things at once. Trying to build up a migration plan. I still have to teach all the devs how to use bzr as well, so i'm reading all the docs so I can try to choose the best workflow to teach to them.
<rubbs> I was told not to give them too many choices on workflows or they are going to run into trouble
<jam> rubbs: good advice
<jam> One thing you can do is start of with the most simplistic model
<jam> and they can adapt to something better as they are able
<jam> I certainly have *my* preferred model, though
<rubbs> right. I was thinking a happy medium between function and ease is bound branches, with their own server space. That way I can back it all up easy and they can have local stuff if needed.
<rubbs> and I can help them along if they have any "customizations" to their workflow
<vila> windows hates me, I swear, it's not the opposite
<rubbs> I'm in the weird position of going from dev to sysadmin, so I actually know bzr from the dev side fairly well. It's all this being a repo admin that's new to me. ;)
<jam> rubbs: :), we'll try to ease your pain
<jam> vila: I still love you
<jam> what's going on with the XP vm?
<jam> bbiab
<vila> jam: no idea, I restored a first backup (known to work), it was broken too, then I went for an older one and it works
<vila> now, there was a vbox upgrade since then and at least one windows upgrade
<vila> but failing to login makes it hard to debug anything :-/
<vila> so I upgraded the vbox extensions on the older backup and I will cross my fingers when the xp update triggers...
<jml> "bzr add-pipe --before foo" seems to make "foo" equivalent to the parent branch
<jml> is "bzr merge -i" different from "bzr merge; bzr shelve" in any way other than negating the "y/n" choice?
<vila> jml: that would greatly simplify the implementation :-P
<vila> jml: sorry, no idea
<jml> vila, ok. related question: how can I tell if the thing I'm about to commit looks like a merge to bzr?
<vila> bzr st will mention pending merges
<jml> vila, thanks :)
<jml> so the answer is "yes"
<jml> "bzr merge -i" forgets the merge
<vila> 8-(
<vila> oh, because it becomes a cherrypick probably
<jml> yeah.
<vila> jml: you're rewriting a too-big patch ?
<jml> vila, indeed I am.
<vila> I wish we had better tools for that...
<jml> vila, not as much as I do right now :)
<vila> jml: almost, I was finishing one yesterday (from a branch to a loom but interrupted during 3 weeks)
<vila> the most annoying bit is that I always find a better way while rewriting those losing a base to compare...
<vila> not that I can imagine tools to help here...
<vila> jml: in the end, one command I often use anyway is: 'bzr merge --preview <old_result>'
<vila> which set submit_branch in branch.conf unfortunately...
<jml> I wish I knew how to stop receiving bzr review mail.
<mgz> hey vila, do you have a branch up anywhere with all your leak bits that I can test locally?
<vila> mgz: oh, I have several, I just put them up for review :)
<mgz> I saw that, just wondering if for-babune or similar still has them all rolled up in one branch
<vila> mgz: but lp:~vila/bzr/leaking-tests should contain everything
<mgz> ta.
<jam> jml: you're probably subscribed to the bzr.dev branch directly?
<vila> mgz: there may still be some rough edges, but I'd like to get them landed first as they have been sitting there for far too long
<jml> jam: no, not directly
<jam> jml: are you in the bzr-core team?
<jml> jam: I'm a member of bzr-core via canonical-bazaar
<jml> jam: I wish to remain a member of canonical-bazaar.
<jam> jml: then figure out how to design launchpad subscriptions so you can explicitly opt-out of stuff, I would like that ability myself :)
<jam> or just set up your >/dev/null procmail filter
<mgz> can you filter based on the message at the end?
<mgz> I think merge proposals have that right, though bugs don't
<jam> mgz: there are some launchpad specific headers you are supposed to use, but I haven't really figured them out
<jam> like:
<jam> X-Launchpad-Message-Rationale: Reviewer
<jam> X-Launchpad-Project: bzr
<mgz> yup, same mechanism.
<jam> X-Launchpad-Notification-Type: code-review
<jam> but there isn't one defining the *target* of the merge, which is weird
<mgz> gmail just doesn't let me filter on anything but a few common headers
<jam> it also doesn't tell you that "you are requested to review" because the group you are in was requested
<jam> versus a direct request of me
<jam> which is something I should file a bug on
<mgz> ah, that's like the bugs bug then.
<SpamapS> Somebody needs to extend IMAP to allow server side filters to be managed directly through IMAP.
<jam> SpamapS: sieveshell
<jml> fwiw, we're doing this atm: https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications
<jam> from the Cyrus suite
<mgz> the bugs header doesn't tell you if you're directly subscribed to the bug if you're a member of a group that'd get email anyway
<SpamapS> there are tons of web interfaces
<SpamapS> But its hard to get imap admins to enable them. ;)
<mgz> merge proposals at least say something different when it's my merge proposal or one I'm reviewing
 * SpamapS puts it on his todo list for crazy ideas. :)
<jml> jam: btw, thanks for the heads up re testtools tags.
<jam> jml: np, I was trying to figure out what versions I had from 'bzr log'
<jml> jam: I hate having to reinvent release procedures for every single project :\
<jam> jml: well, there are some common pieces. I know 'bzr-builddeb' hooks into the tag code so that "bzr tag" can take a default tag name of the last entry in debian/changelog
<jam> It would be interesting to have a "bzr release" function, but so often there is a lot more than just 'export + tag"
<jam> (changing the version strings, etc, etc)
<jml> hooks, perhaps
<jam> jml: yeah, there have certainly been hooks requested for 'bzr export'
<jml> Twisted has a change-versions script used for its release
<jml> (as well as build-news, which takes file-per-news-entry and turns it into an actual news file)
<jml> I also never know which revision to tag.
<jam> jml: approximate is better than nothing :)
<jml> yeah, I know.
<jml> but uncertainty is a paralytic.
<jam> losa ping (about pqm)
<jml> how do you undo "bzr tag"
<mthaddon> jam: hi
<jam> mthaddon: hey, I submitted some stuff to pqm yesterday, which should have failed, but I didn't get a failure email
<dash> jml: bzr tag --delete?
<jam> I can submit it again today, but I figured I'd try to figure out what went wrong first
<jam> dash: yeah, but --delete doesn't propagate well now
<jam> (for now)
<jml> dash, thanks. I was looking for "untag"
<bigjools> heh, bzr tag help didn't do what I expected :)
<mthaddon> jam: but it didn't succeed either? what time?
<jam> mthaddon: yesterday about 5 hours from now
<jam> ~2200 utc
<mthaddon> it's a little hard to tell - there's one at 21:39, one at 22:36
<jam> mthaddon: the latter one is the one I care about
<mthaddon> jam: https://pastebin.canonical.com/36209/
<kpettit> I'm wanting to make bzr our standard VCS, but I have some .NET developers that use VisualStudio.  Are there any plugins and such that work with VisualStudio?  There was one on the 3rdParty page but it says discontinued and it's for a older version.
<jam> mthaddon: I see some warnings, but no real indications of anything, can you try the other?
<mthaddon> jam: https://pastebin.canonical.com/36210/
<jam> mthaddon: well, that does help: smtplib.SMTPSenderRefused: (552, '5.3.4 Message size exceeds fixed limit', 'pqm@bazaar-vcs.org')
<jam> though I don't know how to make it smaller...
<jam> mthaddon: ok, I'm submitting again now. Is there any way to grab the content of the output email in case it fails again?
<jam> (I think my smtp host restricts to <10MB, but that should be plenty for these emails)
<mthaddon> only way would be to send it to a logfile instead of emailing it
<mthaddon> but I think that's something PQM is doing rather than the cronjob that calls PQM if I recall correctly
<rubbs> kpettit: not that I know of, I'm looking for something like that too
<kpettit> rubbs: I'll let you know if I find anything.  Gotta make the Windows guys happy :)
<rubbs> kpettit: ditto ;)
<kpettit> I'm happy with my bzr setup now and moved it to a production server.  The branches work, but the share repository seems to cause issue.
<kpettit> When I go to base directory and do bzr status I get "No Working Tree" and it's looking for a .bzr/checkout
<kpettit> I can go to the individual branches and bzr status works fine there.  Not sure what to do, the origional one I copied from still works fine
<beuno> kpettit, the shared repo does not have a working tree
<beuno> status is for working trees
<kpettit> ah ok.
<kpettit> sorry
<beuno> no need to apologize  :)
<beuno> you can use "bzr info" if you want to be assured everything is fine
<kpettit> ah wonderful.  thanks.  Just wanted to get my "it's ok" from it
<kpettit> trying to see if trac works with it now
<kpettit> woo hoo trac was cake to setup.  love it
<yann2> hi
<maxb> hi
<yann2> is using paths like bzr+ssh supposed to work with bazaar explorer on windows? it seems to get very confused about it, works for some things, but sometimes it tries c:/bzr+ssh:// etc and fails
 * maxb knows nothing about windows
<maxb> james_w: Hi. lp:bzr-builder contains a plugins/builder symlink actually in the branch. Is it something you particularly want there? Because it confuses bzr multi-pull horribly.
<james_w> maxb: it can go away once we can use BZR_PLUGINS_AT to run the tests. mutli-pull should be fixed as well of course :-)
<Kaspi> hello
<Kaspi> is there a way of using bazaar as subversion for beginers? I don't understand why I need to "commit" and then "send" or "push" or "merge" to make changes in the central branch for each dev
<Kaspi> i was following this tutorial: http://doc.bazaar.canonical.com/bzr.2.1/en/mini-tutorial/index.html but I got really confused after getting several errors
<Kaspi> why the "commit" doesn't really commit changes?
<maxb> Commit does commit changes
<maxb> I suggest you move up from the mini-tutorial to the full tutorial, and especially read the "How DVCS is different" section
<jelmer> 'morning maxb
<maxb> evening here :-)
<jelmer> oh, here as well actually :-)
<jelmer> maxb, Whereabouts are you based?
<maxb> London
<jelmer> I thought you were in Australasia for some reason.
<maxb> haha, no
<maxb> I love my ridiculously low ping time to launchpad :-)
<maxb> ~ 5 ms
<sttng359> hello
<sttng359> I am having issues with files loosing their symlink status after certain operations
<sttng359> This branch was imported originally with bzr-svn
<sttng359> When I first did my checkout from svn, the files were symlinks
<sttng359> I think did a remove-tree, and cloned the branch within a shared repo for actual work.
<sttng359> I have since noticed that those symlinks are now zero-length files
<sttng359> I did a checkout of the original branch and they are zero-lenth files as well.
<maxb> This sounds nigh-impossible to debug unless there's a way someone can reproduce the failure mode locally... is the svn public?
<sttng359> maxb: no, but I can create a public svn repo for testing
<maxb> I guess we should first eliminate the obvious... there's no possibility of a filesystem that does not support symlinks being involved?
<sttng359> nope, only a local Ext3 filesystem.
<maxb> hmm
<sttng359> This time I even used a file:// URL for subversion instead of https://
<sttng359> is there a possibility bzr-svn is creating a symlink, but not marking it as a symlink in the repo?
<maxb> jelmer: still around?
<jelmer> sttng359, yes, there has been a bug like that in older versions of bzr-svn
<jelmer> sttng359, but in that case the issue would turn up in the original import
 * maxb is attempting to comprehend the purpose of loom's record command.... is it just so the overall loom state can be pushed and pulled?
<Kaspi> maxb: hmm a better one
<sttng359> jelmer: is bzr-svn-1.0.2 too old by any chance?
<jelmer> sttng359, don't know, sorry
<maxb> 1.0.3 is out, you might as well use it
<sttng359> is there any difference between using co and a svn+https:// or file:// URL vs. svn-import?
<jelmer> sttng359: I *think* it should be new enough
<jelmer> sttng359, no, that doesn't matter
<sttng359> It's only 1 version old
<maxb> the difference between co and svn-import is whether you get one branch or all of them
<Kaspi> maxb: is possible that bzr would "remember" password to a FTP or SFTP location?
<maxb> Try this: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html
<maxb> Basically you write the user and password into ~/.bazaar/authentication.conf
<Kaspi> maxb: yeah.. thank you
<yann2> are there any nice web frontends to bazaar, that allow to browse versions and diffs - and if possible do not require a db?
<maxb> there is loggerhead, which is what you see on launchpad.net
<maxb> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes
<yann2> any demo somewhere?
<maxb> the url I just gave
<yann2> oh right :)
<yann2> I'll give it a try thanks
<maxb> I have yet to find a *good* web interface for browsing a collection of multiple bzr branches
<thumper> jam: ping
<yann2> this one does only one branch? I'll see what I can do
<yann2> fairly new to VCS and am trying to set a whole dev system up :)
<jam> thumper: I'm not really around now, I expect to go at any time for family stuff, but if its quick I'll help :)
<thumper> jam: can I get you to email me tomorrow morning your time about the branch revision work that you started and where it is at now?
<jam> thumper: basically hasn't progressed anywhere. We got the BranchRevision object to be Stormified (so that you can use a multi-column primary key), but haven't tracked that through into actually removing the columns
<jam> also, I haven't done the sit-and-think-about-it to get something like bzr-history-db for your use cases
<jam> most of which want a fast revision_id => branches mapping
<jam> which isn't what bzr-history-db is about (yet)
 * thumper nods
<sttng359> ok, I think I have a better idea what's going on here.
<sttng359> Not all symlinks are being reset in bazaar, only those with a bad history.
<sttng359> TortoiseSVN on Windows does not deal with symlinks properly, instead it creates a text file with the contents of the link, and on check-in, drops the svn:special property, even if that file was not modified.
<sttng359> A user in the past did a checkout of a portion of the tree and later a commit.
<sttng359> I since had to delete those symlinks and re-add them as symlinks.
<sttng359> Other symlinks outside of the portion that the Windows user checked out are still symlinks.
#bzr 2010-08-25
<sttng359> actually, that's not quite it, I actually deleteed those files and created new files as symlinks so they don't have a bad history.
<sttng359> The only files that are messed up are images.
<sttng359> other symlinks are fine.
<sttng359> I recently changed all images including symlinks by adding a svn property svn:mime-type and committed.
<sttng359> When I realized I also modified symlinks, I then droped that property from all symlinks and checked them in.
<sttng359> so all image symlinks now have a history of add, followed by propset, and now propdel.  Other symlinks only have a history of add.
<sttng359> No symlinks have their svn:special modified.
<mtaylor> who does bzr-builddeb?
<mtaylor> I'm having a weird issue with it and an interaction with pdebuild
<mtaylor> some files in the diff (specifically ones in debian/source/include-binaries aren't making it in to the tree when I use pdebuild ... but when I use --builder='debuild' it does the right thing
<lifeless> mtaylor: james_w
<mtaylor> lifeless: thanks
<mtaylor> james_w: ^^ :)
<mtaylor> james_w: if you are so inclined, you can reproduce by grabbing lp:~drizzle-developers/pkg-drizzle/trunk and then running bzr bd --builder='pdebuild' ... it will churn for a while and then fail on the information_schema test
<spiv> Good morning.
<maxb> mtaylor: *sounds* like the problem is more likely pbuilder than bzr-builddeb
<maxb> Try reproducing it without bzr-builddeb in the picture?
<mtaylor> maxb: I haven't ... I'll try that next - although usually bzr bd is the one assembling everything for me, so I'll have to spend a few moments making sure I'm doing the same thing
<james_w> mtaylor: please file a bug
<james_w> I'll look at it, but can't right now, and don't want to forget
<mtaylor> james_w: ok. will do
<mtaylor> james_w: filed. thanks! (I'm just using normal debuild for now, so I've got a workaround and stuff)
<james_w> great, thanks
<lamalex> Can anyone answer a bzr vs. git question? Is there anything similar to git pull --rebase in bzr? I made some changes to my tree, and there were upstream changes. Can I pull them in and have the log be as it should have been had I been up to date in the first place?
<fullermd> Not in one command anyway.
<mwhudson> lamalex: bzr has the slight tendency to regard that as a non-goal
<cody-somerville> I think there is a plugin that allows you to rebasing like that
<mwhudson> generally by having 'log' behave a bit differently and having commands like bzr missing
<lamalex> mwhudson, so bzr says just merge and deal with the merge commits?
<mwhudson> yeah
<lamalex> eh, ok
<wgrant> lamalex: The bzr-rewrite plugin provides the functionality that you seek, but it's discouraged.
<lamalex> wgrant, yeah, I'll just accept the merge commit. I've just gotten used to the git model while working on Banshee.
<vila> hi all !
 * fullermd waves at vila.
<vila> \o_
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.2-final has gone gold, build those installers
<jave> hello
<jave> I'm trying to understand how I can fit a bzr shared repo structure on a hudson build structure
<vila> jave: create it a level above the or at the 'workspace' directory
<vila> jave: make sure to issue 'bzr reconfigure --use-shared' in the existing job directories after creating the repo
<jave> ok, I have an existing bzr chckout, are you saying its possible to convert it to a shared instance?
<vila> jave: yes
<jave> nice!
<vila> jave: create the shared repo *above* your checkout (where exactly depends on your setup and how wide you want to share) with 'bzr init-repo .'
<vila> jave: then, *in* your working trees (where there is a '.bzr' directory) do: 'bzr reconfigure --use-shared'
<vila> jave: alternatively delete all your checkouts after creating the repo
<vila> jave: hudson should re-recreate them and bzr will then find the shared repo and use it
<jave> the bzr server is very slow in this case, so id rather reuse the checkout if at all possible
<jave> in this case the structure looks like this: /var/lib/hudson/jobs/emacs-trunk/workspace/
<jave> /var/lib/hudson/jobs/emacs-imagemagick/workspace/
<vila> jave: then create the shared repo at /var/lib/hudson/jobs/emacs-trunk
<vila> err, oh, in this case, you may even want: /var/lib/hudson/jobs
<jave> but the sibling is emacs-imagick?
<jave> yes, but will bzr notice when the shared repo is not the immediate parent?
<vila> you should issue 'bzr reconfigure --use-shared' in all workspaces
<vila> jave: yes, any level up
<jave> hmmm
<jave> good!
<vila> jave: if you have other bzr branches below /var/lib/hudson/jobs, it's up to you to leave them as standalone branches or reconfigure them to also use the shared repo
<jave> ok
<jave> the imagemagick dir is a failed  tandalone bzr checkout
<vila> jave: if you want to create standalone branches under a shared repo, use 'bzr branch --standalone'
<jave> ok
<vila> jave: failed ? How ? Why ?
<jave> well I tried to initialize it from the savannah bzr repo for emacs from the imagemagick branch, using the hudson bzr plugin. I got a python exception
<vila> jave: and the exception was related to what ?
<jave> I can maybe paste the trace somewhere
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<jave> http://paste.ubuntu.com/483316/
<vila> jave: worth filing a bug
<vila> jave: you may also want to upgrade to 2.2final
<jave> yes, thats why I dodnt file yet :)
<jave> I'm atm trying to see if theres new rpms for fedora yet
<vila> jave: anyway, once you have the shared repo set up, you may *deleted* the checkout under /var/lib/hudson/jobs/emacs-imagemagick/workspace/ and let hudson re-recreate it (it should use the shared repo and shouldn't need to download a lot)
<jave> thanks
<vila> s/*deleted*/*delete*/
<jave> great!
<spiv> vila: hah, I just found one reason why 'bzr status' was taking 25s for that gcc-linaro dev: https://bugs.edge.launchpad.net/ecryptfs/+bug/613873
<ubot5> Launchpad bug 613873 in eCryptfs "stat mtime on encrypted fs doesn't match between calls (affected: 1, heat: 11)" [Medium,Confirmed]
<vila> spiv: urgh
<vila> spiv: I thought we rounded the mtime ? Or is it on windows only ?
<spiv> vila: hmm!
<spiv> Oh, heh:
<spiv> Oh, hmm.
<fullermd> Oh hah, oh hey, oh huh.
<spiv> fullermd: harumph!
<fullermd> That's not 3 letters long!
<spiv> vila: I was going to suggest that maybe rounding of x.11 vs x.99 might account for it, but at a glance we truncate to an int towards zero.
<vila> and the int contains the mtime in what resolution ?
<spiv> vila: seconds
<vila> wow
<spiv> vila: you've ruined my beautiful theory :(
<fullermd> How cruel   :(
<vila> spiv: not sure about that, in the bug you point there is a difference > 0.5 seconds, so it can still apply
<spiv> vila: but only in the sub-second part of the value
<spiv> vila: if we always truncate the time towards zero, and we do, then I think we discard exactly the bits that might be wrong.
<vila> spiv: the bug example starts a 11:14:40.000000000, nothing says it can't start at 11:14:40.5 and still get a adjustment
<vila> spiv: then the first stat can say 11:14:40 and the second 11:14:41
<spiv> Not on my reading of the bug.
<vila> spiv: right, a strict reading invalidates your theory but I still think it's worth subscribing to the bug and ask lool if he can reproduce then bug when not using ecryptfs
<spiv> Judging from the comments, it appears that ecryptfs isn't reliably conveying the sub-second part of mtime.  There's nothing there that suggests to me that the whole seconds part will ever be wrong.
<vila> spiv: right, but nothing either to disprove it
<spiv> This sounds like essentially the same bug the whole linux kernel itself had a few years ago.
<vila> spiv: and one bug in this area says to me that there may be others too...
<spiv> (Individual filesystems started to support subsecond mtimes etc, but the in-memory inode cache only held whole seconds, so you got different answers from lstat depending on if the data came from disk or cache)
<spiv> vila: I certainly agree with the "there may be other bugs" theory :)
 * spiv updates the bug
<vila> spiv: the bug report itself is a gem...
<vila> spiv: gentle nudge to the pp, I've put many wip mps back the review queue (and as such addressed your request about looking at the wip queue :-)
<jave> now I get an exception while converting to shared format
<jave> http://paste.ubuntu.com/483334/
<jave> I cant seem to find 2.2 final rpm:s for fedora 13
<jave> any suggestions?
<thumper> is there any way to check the version of bzr that the remote smart server is using?
<fullermd> There's a ping plugin that shows it...
<spiv> thumper: install lp:bzr-ping, then 'bzr ping URL'
<thumper> spiv: ta
<thumper> fullermd: thanks too
<awilkins> bzr-svn seems to be rather easier to cope with than git-svn ....
<vila> jave: sorry, didn't see your msg earlier
<vila> jave: that sounds like a corrupted repo :-/ cd into your .bzr/repository/packs and issue 'md5sum *.pack'
<vila> jave: the md5 sums should match the file names
<bialix> hey
<bialix> in which section of NEWS should I put the mention of deprecation of parameters passed to function?
<jave> vila: ok Thanks
<jave> I'm beginning to suspect my machine isnt quite feeling well
<vila> jave: most of the time reported corruptions are due to hardware failures or really rude shutdowns
<vila> hey bialix
<bialix> bonjour vila!
<vila> bialix: could be 'Compatibility breaks' or 'New Features' or 'Improvments', it depends
<vila> bialix: there is also 'API changes'
<vila> bialix: reviewers will whine if needed anyway ;)
<bialix> API changes for now seems appropriate for me
<bialix> hmm, but poolie put deprecation news into Compatibility breaks. poolie knows better!
<bigkevmcd> I could use some help with a broken branch :-(
<bigkevmcd> getting crash reports
<vila> bigkevmcd: !paste ?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<ddaa> Where can I find a non-handwavy documentation on what --reprocess does?
 * fullermd is not aware of one.
<ddaa> I had a look at bialix kftp plugin, for cached ftp, and thought about using a disk-backed cache instead of a dict.
<ddaa> I don't *really* need it, but I thought it would be a Good Idea.
<ddaa> I woud like to use a temporary anydbm for that. So I would like to know when the transport is done, so I can delete the cache.
<ddaa> But it seems that Transport has no notion of "close()", allowing to release resources.
<ddaa> So, how can I know I when can delete the disk cache? A hook maybe?
<ddaa> (preferrably, something not involving __del__)
<shentino> What does "rich root" mean?
<vila> ddaa: the question may be *when* to you want to invalidate a cache entry ? IIRC bialix plugin is mainly targeted at .pack files which by definition never need to be invalidated...
<vila> s/to you/do you/
<ddaa> shentino: that the root has a file-id. That's needed at least by bzr-svn, and will be needed for nested trees in the upcoming bzr 2.3.
<vila> ddaa: the 2a format is already rich-root aware and the default
<shentino> ah, as in the root directory has the same stuff that a subdir has?
<ddaa> vila: not only pack files, but indexes, any stuff, ftp is not particularly latency-efficient.
<vila> ddaa: indexes are as immutable as their respective pack file
<ddaa> vila: also, the question is "when can I delete the cache, because I don't care to keep it across invocations, and I don't want to waste disk space."
<ddaa> vila: so, you're saying that .pack, .cix, .iix, .rix, .six, .tix files are all write-once?
<vila> ddaa: there is no '.close()' for transports, there is a '.disconnect()' in a proposed patch, but I don't think it will work for you
<vila> ddaa: given that md5sum xxx.pack == xxx, yes
<ddaa> Well, that's something. At least there are no invalidation semantics to worry about.
<vila> ddaa: in that case .disconnect() can more or less do the trick unless errors occur and we need to reconnect :-/
<vila> ddaa: otherwise... that's atexit or __del__ or ... hooks for all high-level operations. None of which is especially appealing, but that's ftp...
<vila> the lack of a proper readv implementation for ftp doesn't fit well with the pack idea
<ddaa> I guess I can be happy enough with an infinitely persistent cache in ~/.cache/bazaar
 * fullermd will be very happy the day FTP dies the death it should have freakin' died last millennium...
<vila> ddaa: except some pack files will be deleted from the server when a repack occur...
<rubbs> is there any documentation on how to setup PQM? I tried checking the admin guide and even tried looking on the trunk /doc/en/admin-guide doc directory, but PQM is still empty. I'd have no problem documenting it if I knew how to use it :( If not documentation exists, can someone point me in the right direction on how to go about learning about it?
<rubbs> ... if no documentation exists* ...
<ddaa> vila: ack that... thinking of it, the right approach might just be atexit(), because of the "single process" limitation of anydbm.
<ddaa> and ~/.cache/bazaar is the right place anyway because of encrypted home considerations.
<ddaa> thanks, I now have a solution that makes me happy
<vila> ddaa: but why do you want to use anydbm when a transport is associated with a single directory where each path is unique ?
<ddaa> vila: out of laziness, because the kftp code uses a dict, and anydbm does too.
<vila> ddaa: that's a good reason :)
<ddaa> rubbs: offering beer, ham and eggs to lifeless would probably be a move in the right direction :-)
<rubbs> ddaa: I'll offer my first born if that's what it takes [note, I'd have to create a first born first ;)]. But I'd be willing to offer to write official documentation if he just helps me understand it over the course of the next month or so. I've got some time. I'll hit him up on stuff. In the mean time I'll just get a branch and poke around.
<ddaa> rubbs: last time I checked, lifeless was not interested in eating babies anymore, being on a diet and stuff...
<fullermd> Eh, you just need to stay away from the legs.  The wings are pretty lean.
<rubbs> ddaa: ah, that's too bad. I'd seriously send him a case of whatever beer he wanted though ;). I'll ping him when I have some questions. I don't even know quite where to start yet
<ddaa> fullermd: that's interesting, I would be interested in eating cherub wings.
<fullermd> Everybody is.  That's why they're so rare, see.
<rubbs> I've found that if you cook them in baby oil you get a very nice distinct flavor.
<fullermd> Better texture if you coat them with baby powder first.
<ddaa> fullermd: what do you use to make the batter with baby powder?
<awilkins> cornflour
<awilkins> baby powder is mineral in origin and only suitable for dusting
<ddaa> awilkins: I'm sure it's fine for cooking cherubs
<awilkins> I'm told rice flour makes a nice light crispy tempura better
<awilkins> Although I suspect a nice sticky teriyaki glaze may be better
<bialix> hi
<bialix> what does "readv" mean?
<bialix> hi jam
<jam> bialix: Transport.readv() look in bzrlib/transport/__init__.py
<jam> FTPTransport *should* provide a custom one, but it relies on the base "get + seek + read" behavior
<vila> bialix: I think about it as read-variable, you give it a list of (offset, size) to read from a file
<bialix> jam, err, I wonder to know what actually readv stands? read vectors?
<vila> yeah, vector is even better
<ddaa> I think it mean "read vectorized"
<vila> bialix: thanks :)
<bialix> ddaa: thanks
<ddaa> http://www.opengroup.org/onlinepubs/009695399/functions/readv.html
<bialix> jam: re Ftp: as I can see from SFTP implementation I should implement _readv
<jml> one thing I miss from loom with pipeline is the way 'bzr st' would tell me which thread of the loom I was using.
<jam> jml: I use my shell for that
<jml> meh.
<jam> jml: specifically, in each checkout I have it show me the branch name
<jml> ahh.
<jml> I rarely use 'switch', so that works less well for me.
<jam> jml: I have a C program that works pretty well: https://code.edge.launchpad.net/~jameinel/+junk/my_nick
<jml> jam: thanks.
<jam> You need to adapt the Makefile a bit for Linux vs Windows
<jam> that way you don't pay the import bzrlib overhead just to run 'ls' :)
<jam> PS1="\[\e]0;\h \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w$(/home/jameinel/bin/my_nick.exe)\[\e[0m\]\n\$"
<awilkins> jam, If you're using powershell you could write the nick thing as ps script
<awilkins> Shouldn't have too much overhead since you already loaded powershell to run powershell
<jam> awilkins: except I don't ever run powershell :)
<awilkins> jam: Fair enough, are you using cygwin bash?
<jam> yes
<awilkins> I just can't imagine anyone using CMD.exe for more than 10 minutes
<awilkins> Although I suppose cygwin uses cmd.exe as it's terminal
<ddaa> nope, it uses it's own terminal emulator
<ddaa> that's considerably less sucky than cmd.exe, not that is saying much
<awilkins> ddaa, That's odd, because when I open cygwin, I get cmd.exe appearing in my process list :-)
<ddaa> really? I had this impression
<fullermd> Usimg cmd.exe does tend to leave an impression.  Head-shaped.  On the desk.
<awilkins> I think cmd.exe is probably a terminal but the usual shell it runs is bobbins
<fullermd> Or vice versa, depending on the relative quality of your furniture and calcium in your diet...
<awilkins> I have an animated gif of that
<awilkins> Even powershell runs in what is essentially the same terminal
<Kinnison> cmd.exe is the commandline interpreter
<Kinnison> it's what command.com used to be
<jml> How do I test code that uses SMTPConnection?
<awilkins> Make a mock SMTP server?
<awilkins> Or even a mock SMTPConnection
<jml> Yeah, that's roughly what I'm doing now.
<jml> Was hoping bzrlib might have one
<jml> but grep doesn't seem to reveal any.
<awilkins> User learning to use cmd.exe and DOS batch script after using bash : http://imagebin.ca/view/E2RHNegX.html
<fullermd> Yeah, I've seen that used as a forum avatar.
<awilkins> I wonder if it will work as a Skype avatar...
 * fullermd . o O ( bash?  People actually use that? ) O o .
<awilkins> fullermd, Are you one of those dirty .... Korn shell users?
<fullermd> Oh, heck no.  I'm a sparkly clean C shell user   8-}
<Kinnison> fullermd: Cshell? Oh dear
 * Kinnison disassociates himself from fullermd 
<fullermd> It's too late.  You're marked.
<jam> jml, awilkins: class StubSMTPFactory(object):
<jam> in bzrlib/tests/test_smtp_connection.py
 * awilkins looks at the C Shell page on Wiki and likes it
<awilkins> Marked... and spreading the infection
<jml> jam, thanks. I saw that, but it's stubbing at a level below the one I care about.
<vila> C shell... I feel 20 years younger :-)
<fullermd> As if you were bourne again?
<fullermd> Wait.  That's backward...
<vila> It's too late.  You're marked.
<fullermd> Aiee!  Unclean!  Unclean!
<C-S> Good news for all FreeBSD users: more and more ports are available. See: http://www.freshports.org/search.php?query=bzr&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive
<C-S> For all remaining plugin users: if you want me to port your plugin, publish a release file on launchpad.
<fullermd> If you could port testtools/subunit, we could run the test suite   ;)
<C-S> where do I find that?
<C-S> launchpad?
<fullermd> No particularly good idea.  Probably.
<C-S> I don't understand. Aren't these normal plugins?
<fullermd> I know vila has it locally installed in his testing VM; he'd know if there was anything nontrivial about getting it working.
<fullermd> No, they're not plugins, they're regular python libs.
<C-S> I see.
<C-S> I'll have a look what I can do.
<C-S> By the way. There is a stupid bug in bzr-gtk: a file is missing.
<vila> C-S: well done !
<C-S> vila: thanks vila
<vila> C-S: from the release tarball ?
<C-S> vila: bzr-gtk? Yes from the release tarball.  I had to patch setup.py
<vila> C-S: credits.pickle ?
<C-S> vila: exactly...
<C-S> vila: I patched it away :-)
<C-S> vila: and it still works...
<vila> C-S: yeah, one command to generate it... let me find it back
<fullermd> So, you cuked it?  ;)
<C-S> vila: here is my patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/bzr-gtk/files/patch-setup.py?rev=1.1;content-type=text%2Fplain
<C-S> fullermd: it was really necessary, because bzr was already updated on freebsd and the old bzr-gtk did not work anymore...
<vila> C-S: : That's not what is called "taking credit" :-D
<C-S> vila: I agree :-) I'd be happy if the file was still there...
<C-S> vila: by the way, this bug also seems to bother other maintainers: os x, debian etc.
<fullermd> There's a certain joy in looking at a pristine upstream tarball...  then slapping a brute force hack over it to get the port to build.
 * fullermd looks pointedly at the apport stuff in bzr...
<vila> C-S: I know, whoever created the tarball forgot about it
<C-S> vila: don't worry about it. I am looking forward to the next release...
<vila> There is a wiki page I can't find back describing the release process
<vila> C-S: yet, http://wiki.bazaar.canonical.com/bzr-gtk mention FreeBSD and how to install it...
<C-S> fullermd: bzr-gtk is an exception. All other ports work smoothly. The Makefile just installs the things in the right place.
<vila> C-S: hehe, you added that :)
<C-S> vila: right :-)
<vila> C-S: here we go: http://wiki.bazaar.canonical.com/bzr-gtk/releasing
<vila> 3. Update the credits pickle file by running python ./setup.py build_credits
<C-S> vila: perfect, although I'll leave this task to others. I am fully occupied bringing bzr stuff and other stuff to FreeBSD...
<vila> C-S: ok, just mentioning in case your patch broke something
<fullermd> Oh, if it does, we'll just blame it on upstream   8-}
<vila> C-S: as fullermd said, bringing testtools and subunit would be great
<C-S> vila: ah, thanks a lot. I am sure there will soon be a new release of bzr-gtk
<C-S> fullermd: of course :-)
<vila> testtools is pure python, subunit includes a python implementation so may be a bit harder
<C-S> vila: I'll see what I can do.
<vila> testtools is pure python, subunit includes a python implementation (of the subunit protocol) so may be a bit harder
<vila> C-S: I run them from sources as I often need the trunk version
<C-S> vila: so what do these two tools do exactly?
<vila> C-S: testtools is required as it provides some more stuff than the python unittest module
<vila> C-S: subunit... I don't remember if it's strictly required or not, but it helps streaming the test suite results and I need that for running under hudson control
<vila> C-S: in short: none of them are required to *use* bzr, but help a lot to *test* bzr
<C-S> vila: ok. thanks for that explanation
<fullermd> subunit was required for --parallel back before testtools was used at all.
<C-S> so testtools is more important?
<vila> C-S: yes, the best way to check is to run 'bzr selftest'
<C-S> vila: I see.
<C-S> thanks
<mgz> vila: couple of questions on my test cleanup merge proposal branch if you're still around
<mgz> you mentioned you get 2000 tests which complain about leaking even with the testtools change, can I have that list?
<mgz> also, what change to bb.test_log using addCleanup would deal with the cycle? because I'm not seeing it.
<C-S> vila: I just commited the FreeBSD port for testtools. Hope it gets accepted soon.
<fullermd> C-S: You probably want that to by devel/py-testtools...
<C-S> fullermd: I agree, wrote it in the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/149967
<C-S> fullermd: anyway. there seems to be some modules missing still...
<C-S> fullermd: bzr selftest yields: /usr/local/lib/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
<C-S>   RandomPool_DeprecationWarning)
<C-S> bzr: ERROR: No module named layout.test_custom
<C-S> You may need to install this Python library separately.
<fullermd> That's a different problem.  That's paramiko puking on up-to-date pycrypto.
<fullermd> I "solved" that by just dumping paramiko off my system   :|
<C-S> fullermd: ok. Can you try the port? Please tell me if it works for you.
<fullermd> Can't today.  It's way late (in my head).  I'm just fiddling with some relatively mindless stuff before I fall over.
<james_w> mtaylor: hey, interesting problem you've found here
<james_w> I've reproduced the failure locally now
<james_w> mtaylor: just to confirm http://paste.ubuntu.com/483616/ is the test failure you were referring to?
<james_w> looks like it from the log that you provided
<james_w> the source package contains that file in the debian.tar.gz, which indicates to me that debian/source/include-binaries isn't the cause
<james_w> are you sure that it's not just something like that test giving different output in a chroot?
<amogorkon> hello
<cbz> is there any way of getting bzr-svn to save the authentication credentials?
<mtaylor> james_w: yes. that is it
<mtaylor> james_w: it would be _very_ unlikely for that to generate different results in a chroot, but I suppose that anything is possible
<mtaylor> james_w: should I try spinning up a chroot and checking manually?
<james_w> mtaylor: I'm doing that if you can help me verify
<james_w> mtaylor: firstly, installing diff doesn't seem to change the output :-)
<mtaylor> james_w: well that's a good step :)
<mtaylor> btw - I really hate that test case - the binary null that's in it just causes no end of headaches
<james_w> no, I mean that it still complains that it can't run "diff" :-)
<mtaylor> ah. heh
<mtaylor> I should file a bug about that...
<mtaylor> or just replace the test running system - but I digress
<james_w> that's always the solution
<james_w> mtaylor: is DATA_DICTIONARY supposed to be 39 or 40 in the package?
<james_w> 40 it seems
<mtaylor> james_w: oh - sorry - I was distracted spinning up a chroot :)
<james_w> so it looks to me as though it is correct in the source package, but is unpacked incorrectly
<mtaylor> weird
<james_w> though I'm not overly familiar with the v3 format
<mtaylor> me either - still learning it myself
<james_w> and I can't unpack the source package on lucid apparentl
<mtaylor> wow. that's fantastic
<james_w> so the source package that is created by pdebuild outside the chroot is different from the one that it creates in the chroot just as it starts building
<james_w> no, that's not true
<mwhudson> does "Exception AttributeError: "'SmartSSHClientMedium' object has no attribute '_ssh_connection'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://mwhudson@bazaar.launchpad.net/)> ignored" ring any bells for anyone?
<mgz> yes.
<mgz> it rings the "can't write __del__ methods properly" bell.
<mwhudson> oh right
<mwhudson> the real error is
<mwhudson>     bzrlib.global_state.cleanups.add_cleanup(self.flush_all)
<mwhudson> AttributeError: 'NoneType' object has no attribute 'cleanups'
<mgz> that one I haven't run into.
<mwhudson> ah strange
<mwhudson> so if (a) you open a branch over bzr+ssh (b) you haven't called bzrlib.initialize() (c) you have hpss in debug_flags
<mwhudson> then you'll get that error
<mgz> initialize is an ever-growing pain.
<mgz> just give in and always call it.
<mwhudson> funnily enough
<mwhudson> i think i started the chain of events that led to it being added
<mwhudson> because this script that's now failing
<mwhudson> would blow up if you didn't install a ui factory
<Guest83593> cbz: hi
 * jelmer waves
#bzr 2010-08-26
<james_w> mtaylor: so, the failure that stops it extracting for me on lucid is the same problem that building has apparently, but instead of being an error it just silently carries on. I don't see how this ever worked though.
<james_w> mtaylor: the way I see it, it calls tar with -k, which means "don't replace existing files when extracting" and so the updated file that is listed in include-binaries isn't written over the top of the file from upstream.
<jtv> spiv: lifeless tells quite highly of your repo repair skills
<spiv> jtv: was just reading backlog from the other channel
 * jtv cheers him on
<jtv> (btw got the Prague picture?  Women here have a tendency to point at you and ask questions when I show them my pictures)
<spiv> jtv: pastebin the contents of 'find . -type f .bzr/repository'?
<spiv> jtv: I did, thanks :)
<jtv> spiv: not sure what it is you want me to findâthat's not correct "find" syntax.
<spiv> Although I admit to being puzzled why you are showing my picture to various women ;)
<spiv> Oh, thinko
<jtv> spiv: it's just in the batch, I can't help it.  Some quite good ones.
<spiv> 'find .bzr/repository -type f'
<jtv> Got a great one of elmo, like an ultra-modern version of a 17th-century Dutch painting.  But he doesn't like being in pictures so I'm not sharing widely.  :/
<jtv> spiv: http://paste.ubuntu.com/483798/
<spiv> And pastebin 'bzr dump-btree .bzr/repository/pack-names'
<jtv> spiv: http://paste.ubuntu.com/483800/
<spiv> jtv: ok, that definitely looks like you hit a pack-names update race.  The fix should be 'mv .bzr/repository/obsolete_packs/f16*.*ix .bzr/repository/indices/ && mv .bzr/repository/obsolete_packs/f16*.pack .bzr/repository/packs'
<spiv> jtv: which version of bzr?
<lifeless> spiv: not going to roll forward ? or is there no .new file ?
<spiv> lifeless: nope
<jtv> spiv: 2.2.0
<spiv> jtv: drat, that should contain all the fixes jam has made in this area :/
<spiv> jtv: which filesystem?
<jtv> ext4
<jtv> it goes bad from time to timeâ¦ wgrant has reported the same
<jtv> Can I just cp -r to back up my repo?
<spiv> Yep
<jtv> Well, that's done.
<jtv> And it seems to be working!  Yay!
<jtv> Thanks spiv, thanks lifeless  :-)
<spiv> jtv: Now the only question is what caused it :/
<jtv> My candidates are: a recent filesystem corruption and a race condition (the problem struck when I was pulling multiple branches in the same repo)
<wgrant> jtv: It hasn't done that for a long time for me.
<wgrant> Since maybe May.
<spiv> wgrant: that's roughly when jam's fixes landed, IIRC
<jtv> this is about the fs corruption I think, not the repo trouble
<wgrant> FS corruption, yes.
<wgrant> Block device flakes out for a moment, kernel marks it read only, FS goes bye-bye...
<jtv> For me they seemed to go away for a while when I switched from the proprietary nVidia driver to nouveau, but now they're back.
<jtv> Oh, more trouble while running rocketfuel-update.  :-(
<jtv> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <bound method SmartSSHClientMedium.__del__ of SmartSSHClientMedium(bzr+ssh://jtv@bazaar.launchpad.net/)> ignored
<jtv> Exception AttributeError: "'NoneType' object has no attribute 'close'" in <function terminate at 0xa3b895c> ignored
<jtv> sorry, rocketfuel-get.
<spiv> Those are harmless warnings, there have been posts on the list about them.
<jtv> ok
<spiv> (Perhaps utilities/update-sourcecode needs to be updated to call bzrlib.initialize()?)
<vila> hi all !
<vila> spiv: any chance you can review my looms tomorrow ? You did notice you are the pp this week :-D ?
<vila> mgz: pong
<vila> jtv, spiv: bigkevmcd also had a corrupted repo yesterday, also on ext4 :-/ I asked him to file a bug (to track the config details) but I don't see it so far
<spiv> vila: yeah, I'll review
<vila> yeah !
<spiv> vila: interesting... I wonder if bigkevmcd had a crash as well?
<vila> spiv: yeah, a reboot
<spiv> Hmm!
<vila> spiv: an empty .pack file but dirstate and last-revision where mentioning the missing revision
<vila> which can only be explained by a very very dirty fs flush...
<spiv> vila: interesting, quite different to jtv's symptoms then
<spiv> vila: which was pack-names referenced a pack that had been moved to obsolete_packs
<vila> spiv: I didn't follow jtv's crash, can you summzrize or point me to the right... ok
<vila> eeerk an impossible scenario too...
<spiv> No temporary pack-names files lying around (although a couple of upload/*.autopack, not sure how recent)
<vila> hmm, unless a pack-names file creation wasn't flushed (including creation of the temp one and its renaming...)
<vila> twilight  zonesque
<spiv> vila: right
<spiv> so concretely, the fs might guarantee that f = open('foo.new', 'w'); write(f, '...'); close(f); rename('foo.new', 'foo') is atomic in the face of a crash (as I believe ext3 and ext4 do by default now), but not guarantee anything about whether files created and renamed before that will actually hit disk before that.  So the (small) pack-names file might have its update committed, but the larger pack file might not be.
<vila> ...or somehow related to a journalling problem... It's hard to believe that an out-of-order error can happen for the updates of a single process though...
<vila> hehe long mesgs tend to cross on the wire :)
<spiv> Well, in the face of a system crash, I don't think any guarantee is made about the relative order that files are written.
<vila> but journalling is supposed to protect against such scenarios...
<spiv> ext4 defaults to data=ordered, which strictly speaking only guarantees that the file *metadata* is journalled.
<spiv> Search for "* ordered mode" in http://lxr.free-electrons.com/source/Documentation/filesystems/ext4.txt
<vila> i.e. dir content and that's exactly what failled...oh wait, *file* content vs *dir* content :-/
<vila> eerk, ordered is the default :-/ not journal
 * vila revises its beliefs :(
<vila> so the fs is not corrupted... I'm so glad :(
<spiv> And even if data=journalled it's not clear to me if that implies that changes to multiple files are necessarily committed in the same order as a (single) process that issues them.  That doc only clearly states than an individual file will be consistent.
<vila> spiv: if data=journal (and the journal is not lost somehow), then after a crash, the journal is replayed and all updates should be seen
<vila> that's the point of a journal or all bets are off
<spiv> vila: right, but the most recent changes might not be "committed" and lost, so the question of ordering still matters.
<vila> once an update is committed on the main fs, the corresponding entries must be deleted from the journal or be defined in a way that allow them to become no-ops if they are re-played
<spiv> vila: also, see the auto_da_alloc option described at that URL
<vila> spiv: and we don't use fsync right ?
<vila> It's a bit scary to be qualified 'broken' there, sounds like some fs optimizations are a bit user-hostile...
<spiv> vila: right, because it practice it is a huge performance hit because it tends to cause a system-wide flushing of buffered writes :(
<vila> EISHOULDNTHAVETOCARE
<spiv> vila: there have been some "entertaining" discussions on the topic of fsync/ext4/etc summarised on LWN in the last year or so
<spiv> vila: google for o_ponies if you like ;)
<vila> hehe
<vila> All I want is my rug back !
<CcxCZ> hi, I have question about repository layout/workflow, can anyone advise?
<CcxCZ> I have two projects which share common source files. What is the best way to keep it all versioned and make it easy to backport changes from one project to another?
<vila> CcxCZ: the easiest way today is to handle 3 separate projects: project A, project B and project common
<vila> CcxCZ: 'nested trees' is the planned feature you really want here
<vila> CcxCZ: with nested trees you will be able to "nest" project common in both projects and cleanly merge changes made by one project or the other
<CcxCZ> vila: isn't it supported by 2.2?
<vila> CcxCZ: no, at best it will be supported or alpha in 2.3
<CcxCZ> :[
<CcxCZ> vila: thanks for info
<vila> CcxCZ: depending on the volume of shared files and changes, there are some ways to address your need today but nothing trivial :-/
<spiv> Huh, for some reason --lsprof-file foo.callgrind has given me a callgrind file where most of the calls aren't connected to each other :(
<vila> spiv: stop doing things behind callgrind back !
<spiv> vila: I didn't think I was!
<CcxCZ> what's best tool to migrate from svn?
<vila> CcxCZ: bzr-svn allows you to work with bzr while still connecting to an svn server
<maxb> I think in most cases, bzr-svn is also the best tool for a one-shot migration
<CcxCZ> I think it required some specific repository format which was bothersome
<CcxCZ> I'm going to try svn2bzr.py now
<knittl> where can i find docs on compiling bazaar?
<knittl> bzrlib/_static_tuple_c.c:35: fatal error: _simple_set_pyx_api.h: No such file or directory
<jelmer> CcxCZ, it only requires a specific repository format if you're using bzr < 2.0
<jelmer> (which you probably should not anyway..)
<vila> knittl: just try 'make' in the source directory
<vila> knittl: you need pyrex and a C compiler
<knittl> vila: make? i did setup.py install
<knittl> i might be missing pyrex
<knittl> what's the package's name in ubuntu?
<vila> knittl: why do you want to run setup.py if you're using Ubuntu ? There is a ppa with the latest stable versions and if you want to run from sources you shouldn't need setup.py
<knittl> because setup.py is usually the right way for python apps
<knittl> and i need to run from source
<maxb> CcxCZ: svn2bzr.py? Hasn't that project been dead for three years?
<vila> knittl: then run from sources, using setup.py will only make your life harder
<vila> knittl: python-pyrex
<knittl> what is setup.py used for then?
<vila> knittl: *installing* from a release tarball for platforms that doesn't provide binary packages :) If you encounter a problem using it, please file a bug so we can track it
<vila> knittl: but if you want to run from sources, you don't need it (or you will have to run it each time you modify the sources)
<knittl> uhm ok. let's try make
<maxb> Well, that's not entirely true. You only need to re-run it when you modify compiled bits
<vila> knittl: all you need to run from sources is to make the 'bzr' script appears in your PATH
<maxb> And "make" is just a trivial wrapper around setup.py
<knittl> well, run everytime sources change is normal routine for selfcompiled apps
<vila> maxb: I was talking about setup.py, not make
<knittl> no target install
<knittl> :-/
<vila> knittl: 'make' not 'make install'
<knittl> i did make. and then i wanted to install
<vila> knittl: ghaaa, sorry. 'make' will build the extensions in the *source* dir, you can then run from here, no need to install,
<knittl> but i want to install it systemwide
<vila> knittl: if you really really want to install, then yes, run setup.py
<knittl> there we go â¦
<vila> knittl: why not use the version provided by either Ubuntu or one of the ppas described at https://edge.launchpad.net/bzr ? Just curious...
<vila> knittl: some plugins requires that the dependencies are kept in sync and is not a trivial task (/me looks at maxb ;)
<maxb> It's not that hard, either, though
<knittl> running comparisons of different dvcs (latest version from source)
<maxb> I can understand wanting to check out how difficult a self-build is, to not be beholden on packagers
<vila> knittl: then I'd strongly recommend using https://edge.launchpad.net/~bzr/+archive/ppa , it's recent enough to make no differences with bzr.trunk except that the later may drive you into dependencies problems that will be totally irrelevant to a dvcs comparison...
<knittl> hmm
<vila> knittl: anyway, these are the options, use whatever you see fit
<knittl> but it's only rc?
<vila> knittl: nope, see this channel topic, I'm pretty sure all installers are already up-to-date (minus the OSX one ?)
<knittl> what's special about the channel topic?
<vila> knittl: so the official announcement will occur RSN but the sources have been frozen already
<vila> knittl: it says: bzr 2.2-final has gone gold
<vila> not rc nor beta anymore
<knittl> yes. but current trunk is 2.3.0, isn't it?
<vila> knittl: no, it's trunk but will become 2.3 in ~6 months
<knittl> yeah. but it's not 2.2
<knittl> whatever, i'll have a look at the ppa as well
<vila> knittl: indeed, it's not 2.2 and as such is not as stable as 2.2, my point is just to warn you about that. While bzr.dev have a few bug fixes/memory consumption optimizations, I don't think that's worth the risk for a comparison if this means you get a bad user experience (and hard to reproduce problems, trunks of bzr and plugins may change quickly especially just after a release)
<vila> knittl: on the other hand, I'm not aware *today* of any problem in this area...
<knittl> i'm not comparing usability
<vila> knittl: ok, feel free to ask any questions anyway
<knittl> i sure will. thx :)
<CcxCZ> how do I remove project from shared repository?
<maxb> Do you mean branch, not project?
<CcxCZ> yes
<maxb> CcxCZ: You can just delete the branch from disk. Unfortunately there's no way to make bzr purge the data in the repository which is now unreferenced
<CcxCZ> so, the best way to clean shared repository is to make new one and re-branch all branches from the original one
<maxb> If you really need the diskspace, yes
<kiwinote> quick bzr question if anyone knows. I mistyped a branch name, hence merged with a non-existent branch, this didn't time out, so I ctrl+z'ed it. Now I get errors about the dirstate lock not being available. Ideas?
<Glenjamin> hi guys
<Glenjamin> is there any way to tell the merge command to ignore certain files?
<CcxCZ> Glenjamin: you can use --interactive
<Glenjamin> i was hoping for a middleground. I've got a branch which is going to be hanging around with a few changes from trunk - and i'd like be able to merge fiex back upstream without messing around a lot
<Glenjamin> i guess merge -c is probably my best bet
<guiQt> hi! how can i add files that are outside the working tree?
<vila> guiQt: 'bzr add file' unless they are really *outside* of the working tree as in 'above the root of the wt' in which case, you can't
<guiQt> but using bazaar explorer, i can't even see files outside the working tree... :-(
<guiQt> that's the reason of my question
<Glenjamin> guiQt: Under the working tree section, there's a drop down box to the left of "Filter:"
<Glenjamin> what does it say?
<guiQt> Unignored
<CcxCZ> I think he really means outside the wt
<Glenjamin> select "All"
<Glenjamin> or "Unversioned"
<guiQt> i have several project directories and a shared folder. they're all siblings. how can i add files belonging to shared folder?
<Glenjamin> ah, i see
<guiQt> yes, shared is above the root of each project
<Glenjamin> then the previous answers were more accurate - you can't add files that are actually *outside* the working tree
<guiQt> but what is the best strategy for such a case?
<Glenjamin> i believe there's a feature called nested trees in development, that works in a broadly similar way to svn:externals - but i don't know how complete it is yet.
<guiQt> i'm new to versioning systems and i supposed this pattern was frequent: several projects sharing common libraries
<Glenjamin> yes, you'd normally version the common libraries separately
<Glenjamin> and essentially treat them as their own project - which the other projects depend on
<guiQt> so do i till now!
<Glenjamin> which language are you using?
<guiQt> c++ (qt)
<Glenjamin> ah, i'm not really familiar with handling dependencies for C++
<CcxCZ> guiQt: what's the problem versioning it separately?
<CcxCZ> with*
<guiQt> when exporting the project
<guiQt> i'd like to have all my files togheter
<guiQt> not each project uses all shared files
<guiQt> not a problem at all, only a matter of redundancy
<CcxCZ> I'd write an export script for each project, exporting only necessary files
<CcxCZ> if you mean export as in bzr export (without history)
<guiQt> exactly
<guiQt> ok
<guiQt> thank you so much for the talk. see you again. ;-)
<CcxCZ> glad to help :-)
<vila> mgz: pong
<stub> [Errno 11] Resource temporarily unavailable
<stub> http://paste.ubuntu.com/483956/
<stub> Known issue with the new bzr from the PPA, or pebkac?
<stub> pebkac
<stub> So that error can mean 'disk full'
<stub> Freed disk and it is still stuck.
<stub> hulp
<stub> sorted. another window had a 'bzr diff|less' open.
<chx> how can i make bzr resolve by accepting all THIS files as valid?
<jelmer> chx, I think "bzr resolved --take-this"
<chx> weird, bzr help resolved didnt list that option
<james_w> resolve/resolved
<chx> yeah that probably needs 2.2
<chx> i only have 2.1
<chx> i guess revert
<james_w> revert .
<james_w> without the dot it will forget you merged as well, which you don't want
<mgz> vila: still around?
<vila> mgz: not for long
<mgz> well, I'm yours till you need to be gone.
<vila> hehe
<vila> you pinged me .. yesterday ?
<mgz> ah, yeah, two things about my current mp, probably should have just posted there
<mgz> 1) can I have your output with 2000 complaining tests, because I don't get nearly that many (and don't think I skip that much either)
<mgz> 2) how is bb.test_log fixable just with addCleanup?
<vila> hmm, I'll need to re-run that
<mgz> also, if you need any of my results for your leak branch, I've got the full thing
<vila> I don't clearly see where the cycle is, but you should be able to break it in an addCleanup
<vila> if only by deleting the offending attribute
<vila> or setting it to None
<mgz> right, that doesn't work, because it's on the closure over the instance
<mgz> you can't do much with cell objects.
<mgz> and they're not terribly easy to get hold of.
<vila> waitaminute
<mgz> there might be some locals poking trick, but not one I know about.
<vila> rhaa, what's wrong with lp ? I had all sort of random font sizes problems :-/
<mgz> they've changed some css, I see
<mgz> might have caused your browser confusion
<vila> so, for log, isn't it enough to self.log_catcher = None ?
<vila> mgz: after reverting your patch of course
<mgz> nope, and I tested that just to be sure.
<vila> or del it
<mgz> (well, to be exact,
<mgz> +        self.addCleanup(setattr, self, "log_catcher", None)
<mgz> )
<vila> hmm, does the cleanup lambda keep a reference to self in that case ?
<lamont> I rather suspect that bug 249452 in ubuntu was resolved some time ago
<ubot5> Launchpad bug 249452 in bzr (Ubuntu) "bzr overrides the shell prompt settings (affected: 0, heat: 17)" [Undecided,Confirmed] https://launchpad.net/bugs/249452
<jelmer> lamont, did you see poolie's last comment on that bug?
<lamont> yeah, it's fix released in Bazaar, but still open in ubuntu, I'm guessing it never actually made it out as part of 1.6?
<lamont> mostly I didn't want to track down what version it was fixed in for ubuntu
<mgz> vila: because the cycle is between the cell and the instance
<mgz> not the attribute.
<vila> mgz: ha, looking at the source instead of the mp...
<vila> what do you call the 'cell' ?
<mgz> it's the little object python creates for closures to store the outer variables
 * mgz is actually a little shaky on these internal details...
<vila> mgz: so you need to delete the closure
<vila> or step back and re-think the approach taken in def getme(branch)
<mgz> okay, here's a minimal case, what's the right cleanup to add?
<vila> hack in hijacking == True :)
<mgz> http://float.endofinternet.org/bazaar/simple/weakcycle/weakcycle.py
<mgz> the refs and weakref stuff is just to see what's happening, all that's needed is the closure for the cycle.
<vila> del inner ?
<mgz> try it and see :)
<mgz> wait, did I screw that test up..
 * mgz tries being less lame
<mgz> need the bzr TestSuite
<vila> with or without inner defined I get the same result
<mgz> yeah, I minimised too much without checking the negative result
<mgz> fixing...
<vila> mgz: I remember why I did that I think: I needed to get the right LogFormatter object but the registry is a factory so I had to define __new__ to capture the object creation
<vila> there may be alternatives that doesn't involve cycles, but I'm still unsure about the whole cycle elements
<mgz> yeah, the way the test is written currently is explainable
<mgz> okay, so, just deleting something *should* work
<mgz> but... log_catcher isn't sufficent.
<vila> mgz: as long as it's part of the cycle, yes, that's the idea
<vila> so, what constitute this cycle
<vila> mgz: so may be del MyLogFormatter ?
<mgz> no, that's just the type, not involved
<vila> or MyLogFormatter.__new__ = None
 * mgz unshelves his debugging function
<vila> well, __new__ reference self (the test instance)
<vila> mgz: I'll be passing around only for the next hours but will be available if needed around 21h00 my time (in ~3 hours), ack ?
<mgz> yeah, I'll dig a little more, thanks for the help.
<vila> ok
<mgz> okay, I understand now
<mgz> it *is* the __new__ that's the issue, because it's (implicitly) a staticmethod
<vila> mgz: that was my last suggestion, yes, so it should stay defined as long as the... test class is defined ? Ouch
<vila> there is still one bit I don't remember (or may be I didn't understand it either at the time): why defining __init__ isn't enough ?
<vila> mgz: maybe overriding b.log.LogFormatterRegistry.make_formatter can work around the problem...
 * vila off again
<lamont> bzrlib/_dirstate_helpers_pyx.c:9002: warning: dereferencing type-punned pointer will break strict-aliasing rules
<lamont> nice.  only not.
<glen> does bzr have such concept as "tag", how do i add tag to a project, say "2.3", and how do i check if such tag already exists?
<mkanat> glen: bzr tag
<mkanat> glen: and "bzr tags" to see existing ones.
<glen> thanks a bunch!
<mkanat> glen: You probably don't want to tag something just like "2.3" because tags merge across branches.
<mkanat> glen: So you probably want something like myproject-2.3
<glen> i.e it can't start with a number?
<mkanat> glen: It *can*, I just wouldn't recommend it.
<glen> anyway, i see project already has tag set:  "release-2.3-final    4132"
<mkanat> glen: Also, you could have a revision number "2.3", which means you'd have to explicitly do -r tag:2.3 instead of just being able to do -r 2.3
<mkanat> glen: Okay. :-)
<vila> mgz: ping, are there any updates on your mps for testtools or bzr that I should pull before re-running for the 2000 ?
<rocky> don't suppose any setuptools_bzr contributors hang out here? having a problem with setuptools_bzr 2.0 and bzr 2.0
<rocky> er... bzr 2.2.0
<mgz> vila: no, just as is would be great
<vila> hmpf, massive maverick update
<vila> 192 packages, 230MB will be downloaded :)
<vila> hmm, nice colored ascii screen, makes me feel younger :) I prefer the graphic version though, especially when running X...
<vila> at least a reboot fixed it :-/
<vila> mgz: hmm, ran 4 tests... again ? See http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/3/console
 * mgz looks
<vila> mgz: did I use the wrong branch ?
<mgz> is that on 2.7 as per the name?
<vila> yup
<mgz> it doesn't need to be...
<mgz> also, I've not done anything to fix --parallel=fork
<mgz> (yet)
<vila> doesn't need 2.7 ??? Where did I get this belief then ?
<vila> running without --parallel at http://babune.ladeuil.net:24842/job/py27-test-cycles-maverick/4
<mgz> it's probably based on the branch for fixing selftest on 2.7 as that changed a bunch of things that would conflict.
<mgz> that's looking good, thanks vila
<vila> mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :)
<mgz> hmpf, that's still getting junk in the output
<mgz> ...is that what your link is saying too?
<vila> for skipped tests
<mgz> it's still 2.7... that needs tracking down, I'll file a bug already.
<mgz> this is really only a 2.7 thing, right? doesn't appear on any of your other bots.
<vila> mgz: I've setup a dedicated job on babune (it should pull from the bzr branch but not the testtools one though), so it will be easier to re-run or tweak
<mgz> great, thanks.
<vila> I've setup a maverick slave and add the adequate ppa so py27 is the default
<vila> but the ppa lacks pyrex so far
<mgz> I think I'll file against subunit because I've failed at seeing anything wrong in bzr or testtools
<mgz> can always get moved later.
<vila> mgz: if you read the begining of the log, I've added some commands to display what is used
<vila> mgz: I've created a new view to track this kind of jobs: http://babune.ladeuil.net:24842/view/debug/
<mgz> this skipped printing-of-random-details-member thing doesn't actually look fatal
<mgz> so, it might be a seperate bug that's causing the xml parser to fail on the subunit output later
<mgz> that run looks wedged. is that going to be my fault or a known issue?
<vila> mgz: no idea
<vila> mgz: rather, no known cause for hanging runs on mo.... no space left on device :-)
<mgz> wait, now it's progressing
<mgz> er... well
<mgz> IOError: [Errno 28] No space left on device
 * mgz bows to vila
<mgz> and man that 2.7 logging change is obnoxious
<vila> meh, no idea what obnoxious means here ;)
<mgz> the log ends with thousands of tracebacks from the logging module
<vila> looks like tmp is full
<mgz> which isn't nice, or useful.
<vila> there is 1GB log file there
<vila>  WARNING  listening socket error: [Errno 24] Too many open files
<vila> mwahahahahaha
 * vila bangs head on desk
<vila> also known as leaking tests fills up my OSX disk :-(
<mgz> well, at least we're progressing on several fronts, even if it's a pain.
<vila> I don't want to start saying: I've told you....
<cody-somerville> why does bzr launchpad-login try to fetch the +sshkeys page from launchpad for the user?
<vila> but I've been repeating for ages that the leaking tests could blow up at any time...
<vila> cody-somerville: to check that the user can login with one key registered on lp ?
<lifeless> vila: oh hai
<lifeless> and hi mgz
<vila> lifeless: hey !
<mgz> hey lifeless.
<mgz> before I get back to filing this against subunit for lack of better ideas, do you have any smart thoughts on why 2.7 only babune gets skipped [some random details member] in the output?
<mgz> see vila's pastebin ^up there for an example
<vila> mgz: so, either you fix --parallel or you wait for my leaking tests mp to land (or review it :-)
<vila> mgz: s/only/on/ ?
<mgz> well, I mean that it happens on 2.7 but apparently not 2.6
<mgz> ^okay, I'll look at parallel, presume that I can just override osutils.---thingy---concurrency to test
<vila> BZR_CONCCURRENCY even
<mgz> ah, I meant, as in, write a testcase, but yes
 * vila EODing, have fun !
<mgz> bye vila!
<lifeless> well 2.7 added an official skip
<lifeless> which pastebin ?
<mgz> sorry, wrong keyword,
<mgz> <vila> mgz: http://paste.ubuntu.com/484132/ doesn't look good to me :)
<mgz> those ones actually have the 'reason' detail, but others have the 'traceback' or 'log'
<lifeless> whats wrong with it ?
<mgz> it's weird, and we're not sure if it's related to the other things that go wrong with 2.7 like, the xml output not being well-formed
<lifeless> it looks like parameterisation or something to me
<lifeless> the reason you'd get logs and stuff, is if the skip is done late
<lifeless> after test activity
<lifeless> like I say
<lifeless> 2.7 added skip support
<lifeless> so I suspect an interaction with that
<mgz> sounds likely, so, where should I be filing this? bzr? testtools? subunit?
<lifeless> whereever the problem is ;)
<mgz> ;_;
<lifeless> I doubt subunit
<lifeless> very very much
<lifeless> maybe testtools, maybe bzr
<mgz> okay, I'll have another look at testtools first.
<lifeless> but
<lifeless> dunno what the problem is
<lifeless> so - I'd a) reproduce locally
<lifeless> b) use the magic of greyskull^Wpdb
<mgz> the log thing due to a later skip might help, I'll see if I can work out if there's a difference in the tests that have reason and those that have log
<lifeless> they should still have a reason
<lifeless> it will depend on the API they use
<lifeless> if they call addSkip(test, foo) - then reason only
<lifeless> if they call addSkip(test, details=...)
<lifeless> then you'll get log + reason + other stuff
<mgz> getting that out the way will hopefully make tracking down the actual broken output and other weirdness easier
<mgz> another one I saw was a x6 paramatised test that failed,
<mgz> getting traceback-0 through -5
<lifeless> thats bogus
<mgz> as each one failed.
<lifeless> 6 tracebacks would make sense for a server test where multiple threads can die
<mgz> that doesn't look like what this is:
<mgz> right, but this was totally, straight up, adding the
<mgz> gra.
<mgz> wrong paste
<mgz> this:
<mgz> http://float.endofinternet.org/temp/babune_log_extract.txt
<mgz> first fail has traceback. second has traceback, traceback-1, third has traceback, traceback-1, traceback-2... etc
<lifeless> perhaps something is gone fucked up with test parameterisation
<lifeless> like sharing object state or something
<mgz> seems likely.
<mgz> might just be that test case class then?
<lifeless> well
<lifeless> the tracebacks are stored in self._details
<lifeless> if that dict were initialised before parameterisation
<lifeless> and shallow copied
<lifeless> (which I think we do, for various reasons)
<lifeless> [the shallow copying we do]
<lifeless> and indeed
<mgz> okay, food for me now, I'll make a list of these things and file bugs so that the ones I can't work out myself don't get lost.
<lifeless> TestCase.__init__ sets self.__details
<lifeless> so if we're shallow copying we'll be sharing details
<lifeless> and cleanups
<lifeless> and other fun stuff
<lifeless> and clone_with_new_id uses copy.copy
<lifeless> need to check what bzr uses
<lifeless> copy.copy
<lifeless> so, thats why
<lifeless> grah fuckers.
<mgz> okay, so that's something seperate and fixable at least.
<lifeless> probably by implementing the copy hook for TestCase
<lifeless> I don't know what I was thinking
<james_w> hey lifeless
<james_w> lifeless: is testing with different imports a use case for testscenarios? We may want to test against built in json and simplejson using it if possible.
<lifeless> james_w: yes you could use it for that
<lifeless> if you pass in the module to your tests - ('json': {'implementation':__import__('json')]), ('simplejson': {'implementation':__import__('simplejson')])
<lifeless> if you pass in the module to your tests - ('json': {'implementation':__import__('json')]), ('simplejson': {'implementation':__import__('simplejson')])
<james_w> lifeless: ok, thanks, I'll pass that on
<lifeless> james_w: if the module is implicit state in your environment its a bit trickier
<lifeless> I'd probably use a Fixture + scenarios then
<lifeless> and have the setup reimport the right thing for you
<lifeless> and the cleanup replace the original
<james_w> lifeless: generally it as as the code under test will usually do something like "import json; except ImportError: import simplejson as json"
<lifeless> so, I'd be tempted to have a local module
<lifeless> json_impl
<lifeless> which does from json import * / from simplejson import *
<james_w> he has one of those actually
<lifeless> then replacing just it at runtime is reasonable clean
<james_w> lifeless: replacing in terms of mucking about with sys.modules?
 * james_w has never got that involved in import machinery
<lifeless> well
<lifeless> so lets say there is module A
<lifeless> which does 'import json_impl as json'
<lifeless> that means that you have the name json bound to the module currently in sys.modules
<lifeless> you have two places you can muck around with
<lifeless> the bound name - rebind it to a new json_impl (e.g. directly to simplejson), or
<lifeless> the module - change its contents (but not the module object itself)
<lifeless> def change_impl(impl):
<lifeless>     for name in dir(impl):
<lifeless>         globals()[name] = getattr(impl, name)
<lifeless> if that existing in json_impl
<lifeless> existed
<lifeless> you could call
<lifeless> json_impl.change_impl(simplejson)
<lifeless> et voila
<james_w> gotcha, thanks
<lifeless> if there are many A's, then mucking with the module contents is easier.
<lifeless> if there is one A, changing the name binding is easier.
<james_w> we may just support one implementation instead, but it's good to know we have this to ensure that both work if we choose to support both
<lifeless> fairynuff
<lifeless> what are you working on ?
<james_w> lifeless: the launch-control project with Zygmunt that I think you know a bit about.
<ovnicraft> hi folks i want to update my repo at N revno is posible this with bzxr pull revno?
<ovnicraft> bzr*
<lifeless> james_w: I'm not sure I do know that one :)
<james_w> lifeless: a QA dashboard type thing, with automated test results against images
<ovnicraft> is posible what i want to do?
<lifeless> james_w: nice
<beuno> ovnicraft, yes, bzr pull -r REVNO
<ovnicraft> beuno, now if i pull without and -r options and i want to back in revno its posible?
<beuno> ovnicraft, sure, you can "bzr revert -r REVNO
<ovnicraft> beuno, the revert changes are left as uncommited code?
<ovnicraft> revert works fine but when bzr revno show me the latest
<maxb> ovnicraft: Hi, could you restate what exact effect you want to acheive?
<ovnicraft> revno at my revert -r REVNO
<ovnicraft> maxb, changes as uncommited can be logic
<maxb> 'bzr revert -r X' sets the *content* of the tree to that of revision X, but does not change the tree's idea of what revision it is based on.
<maxb> If you want to briefly inspect a previous revision, you probably want 'bzr update -r X' (only fully added in 2.2)
<dev001> When I 'bzr pull' latest source, I get: Using saved parent location: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/; /usr/lib64/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
<dev001> Is this a python issue, or a bzr prob?  the provided link is broken ...
<ovnicraft> maxb, i tried bzr update -r X with 2.1.1
<fullermd> dev001: It's paramiko fighting with pycrypto.
<dev001> fullermd: gesundheit!! ;-)
<dev001> so, which do I fix?
<fullermd> Well, since pycrypto defines its API, paramiko by definition is the broken one.
<fullermd> Back at the beginning of the year when the new pycrypto came out and started throwing errors, I just uninstalled paramiko, figuring it might take a few weeks for a fix.
<fullermd> 'course, that was in January...
 * dev001 digs around, trying to figure out wtf I need paramiko for ...
<fullermd> ssh/sftp, if it's not using a system-installed (e.g. openssh)
<fullermd> Still doesn't seem to be a patch in paramiko git  :|
<dev001> fullermd: beat me to it ... just found the git, and was looking
<fullermd> There's an issue filed for it on github frmo a while back too, with no comments.
#bzr 2010-08-27
<dev001> fullermd: There's a fc13 bug, https://bugzilla.redhat.com/show_bug.cgi?id=611405#c5, that seems to suggest that tho the warning exists, the problem has been negated.  hm ...
<ubot5> bugzilla.redhat.com bug 611405 in python-paramiko "RandomPool_DeprecationWarning in fc13" [Medium,New]
<fullermd> As far as I know (which isn't too far, so don't put much weight on it), there's not actually a _problem_ that it's broken.  But it took about 2 minutes for me to get sick of the crap in my terminal all the time...
<dev001> fullermd: all of 2 minutes?  patient guy!
<fullermd> Oh, yes.  I'm widely known as a calm, patient, tolerant kind of guy.
<dev001> heh
<dev001> fullermd: i'll post @ https://launchpad.net/paramiko.  maybe that'll get some attention.  thx.
<dev001> fullermd fyi -> https://bugs.launchpad.net/paramiko/+bug/271791.  already there ...
<ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 4, heat: 20)" [Medium,Triaged]
<fullermd> Mightn't hurt to pile yourself onto that and up the count of people hitting it.
<dev001> fullermd: piled.
<mtaylor> james_w: fascinating ... related to something else I was just trying building source packages on a lucid box ... and there I'm getting :
<mtaylor> tar: tests/r/information_schema.result: Cannot open: File exists
<mtaylor> tar: Exiting with failure status due to previous errors
<mtaylor> dpkg-source: error: tar --no-same-owner --no-same-permissions --anchored --no-wildcards -xkf - gave error exit status 2
<james_w> mtaylor: yeah, that's what I get too. Did you see the dpkg bug that I filed?
<mtaylor> james_w: oh - no. I should go look
<mtaylor> there it is
<mtaylor> james_w: so essentially I'm just screwed for now :)
<james_w> mtaylor: yeah, not a nice way to fix it
<james_w> mtaylor: you can get your packages building with an ugly solution
<FryGuy-> is there anything I can do in bazaar about my horrible line-ending situation on windows? We're currently using sourcesafe, but I've just been using bazaar and merging the changes manually (and I wrote a script to push bazaar -> ss). This works great for the windows c++ code i'm using
<FryGuy-> However, I'm doing another project now, with a different tool. We recently switched from a unix version of a tool, to a windows version of a tool, and it's been generating mostly CRLF, but some LF in everything it saves out
<FryGuy-> Everything in sourcesafe gets set to LF (from what I can tell), but the tool writes out the files with a mix.
<FryGuy-> When I try to commit my changes to bzr, it rightly says there's a bunch of changes. Is there anything I can do, short of dos2unix everything manually before checking in, to change this?
<FryGuy-> and the tool gets seriously confused if I just change everything to CRLF (so I can't just change everything at once, and use the tool normally after that)
<lifeless> you can probably use a filter
<FryGuy-> would that help for things like qdiff?
<lifeless> probably
<vila> hi all !
<AfC> ! lla ih
<AfC> (we're upside down here)
<methods2> can i edit a log message ?
<AfC> methods2: short answer, no (which sucks, even if there is a good reason for it)
<AfC> methods2: medium answer: if its your commit, and recent (ie, -1) then `bzr uncommit` & then re- `bzr commit`
<AfC> methods2: otherwise, no
<AfC> methods2: long answer, you _can_ use the evil rebase plugin, but assuming this will only change YOUR [copies of] revisions and not any revisions out in thew wild, causing history divergence, and the end result of not getting rid of the message you want to change
<AfC> so,
<AfC> methods2: no
<methods2> lmao
<methods2> ok
<methods2> satic it is
<AfC> {shrug} it's all a consequence of immutable revisions and the (good) idea of wanting to preserve history for future merging purposes.
<methods2> :]
<methods2> satic was the typo in my log message
<AfC> yeah, well
<AfC> you'll get over t
<methods2> already am
<methods2> but a part of me never will
<methods2> lol
 * AfC still hasn't
<AfC> :)
<vila> Well, as far as concepts are involved, immutable is more important than preserving history. Once you've published your revision you want to make sure that everybody is referring to the same thing via the revision-id...
<vila> Regarding history, your log message *is* the one you typed when the revision was created, any change to that *should* be tracked.
<vila> Now, when people ask about this feature, they are right.
<vila> There should be a way to edit such details, but given the constraint above, it's not a trivial problem
<vila> The solution is certainly around making rebase/rewrite easier to use for such scenarios ensuring that only a minimal amount of data need to be distributed so propagate this kind of change...
<vila> s/so prop.../to prop.../
<vila> i.e. editing log should be a first-class citizen operation
<AfC> vila: sure
<AfC> vila: we've talked about it; the problem is that every time we raise it
<AfC> the whole discussion gets torpedoed because someone turns it into the generic history editing problem,
<AfC> (including texts, parent/child relationships, metadata, and tags etc)
<AfC> rather than just keeping it constrained to "I want to commit a revision (sic) that magically alters [overlays] a previous log message"
<AfC> which really ought to be do-able.
<AfC> whereas the general case is indeed nasty.
<vila> Well, it is doable to day as you pointed out above. With some limitations that... can only be addressed by more-or-less adressing the general case. Managing a "simple" overlay will quickly become more complex once people (rightfully) ask: we both fixed the bogus log entry, which version should be kept ?
<vila> AfC: We should *at* least make your "medium answer" easier to use for recent (> 1) commits
<AfC> vila: which actually (much to my personal disgust) brought me [after 4 years of going to lots of trouble to convince people to write good log messages] to realizing that I probably would have been better off with a ChangeLog file after all.
<vila> AfC: hehe, at least the ChangeLog is versioned and as such address the problem :)
<AfC> vila: yeah... it sure would be nice for something to do that in 1 step... cutting and pasting the commit message as (quite unhelpfully) formatted & indented by uncommit is a pain in the ass
<AfC> so I still write good(-ish) commit messages, but my enthusiasm has waned substantially.
<AfC> anyway
<AfC> there are bigger problems facing the human race
<vila> Well, I do typos....
<AfC> like,
<AfC> vi vs emacs
<vila> ... but I still consider commit messages as capturing the intent at commit time. I.e. best effort. Errors occur. Tracing fixes is good.
<vila> So, I kind of like the fact that my typos get tracked :)
<AfC> vila: yeah, but that's not the point, and we both know it; in most projects, commit messages ARE considered the ChangeLog entry, and those projects build their release notes right out of history. bzr is just not good at serving that need.
<AfC> anyway
<AfC> nothing new
<AfC> tough problem
<AfC> there are bigger problems facing the human race
<AfC> like,
<AfC> why is there cat hair in my keyboard?
<AfC> like,
<AfC> why do I have to move to another cafe to get a coffee?
<AfC> (See ya :))
<vila> :)
<knittl> vila: you recommended using bzr ppa?
<vila> knittl: yes
<vila> any problem ?
<knittl> yeah. there's no package for maverick
<vila> 8-/
<vila> maxb: Is there any reason for not building packages for maverick in the bzr ppa ?
<bialix> who I can ask about lp:bzr-website?
<vila> knittl: try https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa , it seems to contain the right stuff
<knittl> okay
<vila> maxb: is it just that you copy the packages for bzr-beta-ppa to bzr-ppa *except* for maverick ?
<vila> maxb: hmm, or am I mixing bzr-beta-ppa with the 'proposed' one you mentioned (which I can't find on lp by the way) ?
<vila> ha, found it https://edge.launchpad.net/~bzr/+archive/proposed
 * bialix waves at vila and says bonjour
<vila> bialix: hey sacha !
<knittl> so i should use proposed? but there are only two packages python-testtools and subunit
<vila> privet
<bialix> poolie has already eoled, hasn't he?
<vila> knittl: huh, I see the same packages in proposed/maverick than in bzr-ppa/lucid
<bialix> sorry
<vila> bialix: eowed on tuesday I think ;)
<knittl> i don't xD
<vila> knittl: argh
<bialix> vila: oh, so he's enjoying vacation?
<vila> knittl: I'm at a loss here, I didn't closely follow what happen there, we need to wait for GaryVdm or maxb to pop up
<vila> bialix: AIUI, yes
<knittl> ok. i'll be here
<bialix> vila: ok
<bialix> vila: as I can see from log now only poolie maintains the bzr-website. I guess I need to wait for his review for may changes
<bialix> s/may/my/
<vila> bialix: where is your mp ?
<bialix> right now filing the first (trivial)
<bialix> https://code.launchpad.net/~bialix/bzr-website/mailman-icon/+merge/33878
<bialix> then want to update info on released versions because it's out of date
<vila> bialix: cool, thanks for caring about that
<bialix> vila: do you know either bazaar.canonical.com using lp:bzr-website to update regularly or not?
<vila> bialix: I think it is
<bialix> hmmm
<vila> bialix: if not, it should :)
<bialix> it seems my patch is not quite right. there is build.py script which (I think) ought to update the index.html. maybe the site updated regularly using build.py? strange, while there is generated index.html then? questions, questions, questions. I need to wait for poolie
<vila> bialix: yeah, things like that should be documented in this branch
<bialix> vila: there is readme but it seems incomplete now
<vila> bialix: yup, my point exactly
<zoyd> hi
<zoyd> what's the 'svn update' equivalent in bzr; i have an incomplete 'bzr branch' checked-out
<AfC> zoyd: depends on what hole you've got yourself stuck in, but
<AfC> zoyd:
<AfC> $ bzr pull URL
<AfC> in that branch will probably get you where you want
<AfC> on the other hand, if you did branch and it never finished,
<AfC> I think you have to start again
<AfC> [there's a bug open for that, I believe]
 * zoyd tries
<zoyd> hmm, appears like i'll have to start over
<AfC> zoyd: if you're on a really dodgy network link
<AfC> zoyd: then try
<AfC> $ bzr init dir
<AfC> $ cd dir
<AfC> $ bzr pull -r 1 URL
<AfC> $ bzr pull -r 10 URL
<AfC> $ bzr pull -r 20 URL
<AfC> ...
<AfC> that'll get you (safe) incremental pull,
<AfC> for whatever Î you find sustainable
<vila> you can even omit URL once the first one succeeds (or use --remember URL if/when needed)
<AfC> vila: yes, of course you're right
<vila> AfC: damn bzr fighting copy/paste :)
<bialix> vila: what is landing procedure for lp:bzr-website branch? can you cancel merging of my first patch?
<zoyd> and that will resume the download then?
<vila> bialix: no idea, I tried to pqm it to see, and cancelling is... hard. Don't worry, I'll take the blame for it :)
<AfC> zoyd: no, it'll pull whatever you tell it to.
<AfC> zoyd: if you're on revno 10
<AfC> and you say pull to revno 20, well, you'll get 11,12..20
<vila> knock knock ? Am I still here ? (I've got a lot of network failures all at once, trying to find a pattern...)
 * zoyd checks if there's a way to know what revision you're at .. "nnnnkB  nkB/s - Fetching revisions:Inserting stream" is very sparse
<vila> zoyd: where are you pulling from ?
<zoyd> lp
<AfC> zoyd: no
<zoyd> then, why not do a 'bzr pull -r <latest-revision>'?
<vila> zoyd: lp seems down for me right now...
<vila> zoyd: or at least experimenting transient failures, you've been warned ;)
<zoyd> lp is very slow here
<vila> zoyd: in generall or just now ?
<zoyd> :)
<vila> funny typo :)
<vila> I can't ping it right now :(
<vila> can't ping google.com either...
<zoyd> bzr branch is reporting a '11059kB 1kB/s ..' but a 'du -sh .bzr' shows 4.1MB only
<vila> zoyd: interesting... anything in .bzr.log ?
<zoyd> hhm no
<vila> ha, my dns servers are back...
<zoyd> ok, now 'du -sh' updated to 6.3MB
<vila> so is lp of course
<zoyd> weird, the buffer wasn't written even after a 'sync'
<zoyd> seems it dumps to disk after large intervals
<zoyd> 14MB downloaded, but 7.5MB on disk. funny.
<zoyd> no wonder the thing can't resume :)
 * maxb pop us
<maxb> *up
<maxb> vila: Hi. The situation is simply that no one really took the decision to support maverick fully yet
<maxb> Also, many of the packages are already up to date in maverick itself
<vila> knittl: ^
<vila> maxb: thanks !
<knittl> ok. so maverick is as recent/outdated as the ppa
<knittl> :D
<vila> :)
<vila> knittl: I guess my initial "use stable version" recommendation doesn't really apply to maverick ;-)
<zoyd> btw, is a web-directory sufficient to publish a repository/branch, or does one need to open any ports?
<maxb> knittl: what specifically is missing for maverick?
<vila> zoyd: for read-access, http is good enough
<vila> maxb: almost everytinh since only testtools and subunit are available ;)
<maxb> erh?
<maxb> Oh, well the PPA is naturally always to be used in conjuction with maverick itself, so there's no point in uploading to the PPA until there's something newer than maverick itself to upload
<vila> maxb: https://edge.launchpad.net/~bzr/+archive/proposed?field.series_filter=maverick
<knittl> well, i'll have to live with it ;)
<maxb> live with what?
<maxb> You can still install everything you need from maverick itself, AFAIK
<knittl> not having 'nightly' builds
<maxb> bah
<maxb> If you want nightly, run from a branch :-)
<vila> maxb: I recommended against that yesterday :) But I didn't realize knittl was running maverick nor what exactly he wanted
<vila> knittl: also note that there is a work in progress to make python-2.7 the default in maverick while bzr 27 support may not be perfect yet
<maxb> hmm. I'd love to continue this conversation, but I'm still in bed, and need to be in the office in a meeting in 30 minutes, so bye!
<vila> maxb: hehe
<knittl> have fun xD
<vila> maxb: and thanks for popping up for the clarifications !
<knittl> yeah. thanks :)
<vila> knittl: by the way, maxb is fully right, maverick is pretty much as the same level than bzr-ppa/lucid so I don't think you're losing anything here
<vila> knittl: what exactly to you need ? bzr ? plugins (which ones) ?
<knittl> i'm comparing bzr+git+hg (again xD) and it would be good if i could compare the most recent versions
<vila> knittl: then bzr 2.2.0 sounds good enough if maverick is the reference platform
<knittl> git and hg is compiled from source
<knittl> :P
<vila> knittl: with different settings than the binary provided by maverick ?
<knittl> no, but more recent
<vila> I see
<vila> knittl: so back to yesterday discussions, 'make' + 'python setup.py' ought to work, bugs welcome if not
<knittl> yeah, bzr-svn complained ;)
<vila> well, that's exactly the kind of problem I warned about :-)
<knittl> i know
<knittl> good olâ plugin system, everybody brings in in discussions ^^
 * jelmer wakes up
<jelmer> knittl: I'm not following, what did bzr-svn complain about?
<vila> knittl: yup and the ppas is the answer for people that don't want broken setups :)
<knittl> version mismatch
<vila> jelmer: hi :)
<cbz> jelmer - i'm having a problem with certificates, pycurl appears to be choking on a wildcarded ssl certificate
<jelmer> cbz: ah, ok - that wouldn't be related to bzr-svn though, it's an issue with pycurl in general.
<cbz> jelmer: interestingly it seems to work on windows but break on linux
<jelmer> cbz: Do you have pycurl installed on windows?
<cbz> i guess it's using whatever is bundled in with the windows bzr installer
<zoyd> oh, this checkout won't get done
<bialix> vila: as I can see that patch is not landed, do you have any error message from pqm?
<vila> bialix: yes, I got one, I'm not allowed to land. I tried to tell you but you had just disconnected, thank for poking (one less item in my stack :-)
<bialix> vila: yep, i-net suddenly died for me. ok, thank you. I'll wait for poolie's review
<vila> bialix: I had transient DNS faillures too, very unusual
<rubbs> Ok, I know this question is probably asked billions of times, but is there a status on SVN externals type functionality? Being able to checkout/branch within another branches working tree? It's not that important for us, but the answer may influence which workflow i encourage (read force) my devs to use.
<jelmer> rubbs, the feature you're looking for is called nested trees
<rubbs> ah. I do some doc lookups. Thank you.
<jelmer> rubbs, it's not implemented yet, though I've seen Martin say that it's one of the next things on his list.
<vila> ghaa, what are the names of the plugins that offer an approximation of nested trees... my memory is failing right now :(
<vila> scm-proj ?
<rubbs> jelmer: ah, thanks. I think at this point I'll have to assume it won't be done in time.
<jelmer> vila: bzr-externals, bzr-scmproj, config-manager
<rubbs> We're looking to migrate in Oct/Nov time fraim
<bialix> bzr-externals
<rubbs> I'll check out bzr externals
<vila> jelmer, bialix: thanks :-}
<vila> how on earth can a python deprecation warning be emitted randomly....
<vila> ...but persistently on babune...
<rubbs> Well, first you must sacrifice a chicken, then throw salt in for directions... I'll just direct you to a black magic expert.
<rubbs> ;)
<vila> I do the chicken thing every morning, but tell me more about the salt one...
<vadi2> bzr-fastimport mentions to do "front-end | bzr fast-import -", but I don't have front-end. Where does it come from?
<maxb> vadi2: front-end is a placeholder term for "thing that exports from your source vcs". Which specific vcs are you exporting from?
<vadi2> From git
<vadi2> Can you suggest the command I should try? I'm not sure
<vadi2> Ah, there is bzr fast-export-from
<maxb> Yes, you could use that, or you could use git fast-export directly
<montywi> hi!
<montywi> anyone that can help with getting rid of a .THIS file that shows up in 'bzr gcommit' but doesn't exist on disk?
<montywi> This happend after doing a merge where someone had deleted files changed in my tree, which I wanted to keep.  I copied the name.c.THIS file to name.c and did 'bzr resolved name.c' but now name.c.THIS still shows up in bzr gcommit
<GaryvdM> montywi: What does bzr status say?
<vadi2> How can I set a working tree for the bzr branch?
<maxb> vadi2: bzr checkout (bzr co)
<vadi2> Hrm. But I just created this branch and imported stuff from git into it. What do I check out?
<GaryvdM> vadi2: Maybe you allready have a working tree. What does bzr info say?
<vadi2> $ bzr info
<vadi2> Shared repository with trees (format: 2a)
<vadi2> Location:
<vadi2>   shared repository: .
<vadi2> It seems doing init again and re-importing worked, it's pushing happily now.
<niemeyer> Hey there!
<niemeyer> I'm trying to decide between looms and pipelines.. can anyone provide some insight into the difference between these?
<niemeyer> Are either of these obsolete?
<niemeyer> s/Are/Is
<vadi2> Er, that went pretty terrible. All it did was duplicate my folders + files, with one set being what I want, and another set being taken off some other random branch...
<vadi2> Is it possible to repair? All I did was import and then push to a new branch on launchpad
<niemeyer> Found a useful thread about it
<niemeyer> http://markmail.org/message/imo4jop3gcm3lgr4#query:+page:1+mid:sjjtebxtdh3th43m+state:results
<vila> niemeyer: they are both maintained. I personally prefer looms but it seems to be a matter of taste
<niemeyer> In case some else cares
<niemeyer> vila: Cool.. I'm just finding it a bit hard to find anything comparing the two, and why someone might prefer one over the other
<vila> niemeyer: both of them have some rough edges, my preference is mainly because I prefer to handle *one* loom rather than a set of branches. On the other hand some commands fly better with multiple branches than multiple threads. It heavily depends on your workflow...
<niemeyer> vila: I don't have any workflow to handle the situation where I want to split work across several branches/threads/whatever to make it easier to review/merge/understand
<niemeyer> vila: (besides a totally manual one)
<niemeyer> vila: So I'm really trying to learn which workflow to adopt :)
<niemeyer> vila: Do you know of any blog posts/documents which compare the workflows?
<vila> "Looms on the other hand currently have no parent pointers per-thread. " is one such example. I.e. each pipe has its own branch.conf where loom has only one
<niemeyer> vila: I see, that's interesting
<vila> splitting will work for both and even the resulting graph should be pretty similar (but since I don't use pipelines I'm not definitive on this)
<vila> s/graph/revision graph/
<vila> 'switch' works for both too, it becomes important once you start pulling in your lowest thread (or first pipe).
<vila> Generally your first thread is your upstream project and you then define successive layers that you want to propose/review independently
<vila> so at commit time you decide where you want to commit. At various times you merge the lower threads into the upper ones (using 'up-threa' or 'up-thread <thread>')
<vila> In any case you more or less need to know which threads haven't been merged up to the top
<smoser> Hey all, I've got a question.  I'm wanting to create a bzr repository with results of test runs.
<smoser> the log output is around 10M size .
<smoser> is there any benefit to checking in a output-testrun.tar.gz rather than output-testrun/*.
<dash> no, that's probably worse
<smoser> If bzr is doing intelligent things in the repository, it seems like doing so may not buy me anything other than local storage (on checkouts)
<smoser> which i really dont care about.
<smoser> dash, thats what i was thinking.  My eperience with git is that it is very good at keeping .git to a small size.
<smoser> bzr does similar things ?
<rubbs> smoser: yes, it does do similar things
<rubbs> IIRC bzr will even pack better than gz
<smoser> so there is no good reason to compress the contents (other than a larger local checkout)
<rubbs> with bzr, no, it's best to avoid checking in binaries as much as possible.
<smoser> right.
<rubbs> so if it's a log, your better off keeping it plain text and bzr will do the right thing.
<smoser> so my only question, then woudl be if it is possible to check out only a given directory (or set of files) from a bzr repository
<smoser> ie, not do a full checkout, so that i could avoid the local space if I had to, just to see files
<smoser> (obviously I can just rm -Rf <other files> afterward, but wonder if i can only check out the onees i want)
<rubbs> IIRC there is no way to check out only a subset of the branch at this point
<rubbs> not sure if it's planned or not either
<smoser> fair enough. In this case, I wouldn't mind having the whole repo (.bzr dir), but would only want to check out certain files at a given revision.
<smoser> its probably not a common use case
<rubbs> I think it's asked about every once and a while, but like I said I'm not sure about the planning or status of said feature.
<niemeyer> lifeless: Sorry, I guess this is a better channel for that kind of question
<niemeyer> Btw, just found out about bzr merge -i
<lifeless> its nice :)
<niemeyer> Does it actually bring the commit message/etc?
<niemeyer> Or is it just a helper to cherrypick without history?
<lifeless> its a helper to do partial merges
<lifeless> so it has all the limitations of a cherrypick
<lifeless> as/when cherrypicking is improved, it will improve
<maxb> lifeless: Hi, do you possibly have time to read my email https://lists.ubuntu.com/archives/bazaar/2010q3/069878.html, and if you agree, activate a new ~bzr/builddeps PPA so I can work on that over the weekend? (New PPA requires team admin)
<lifeless> maxb: I can certainly read it, but I'd want poolie to ack it - has he ? I say this because I'm a bit out of the loop on bzr right now
<maxb> Fair enough. Is poolie travelling or something, do you know? I've not seen him on IRC for a while
<lifeless> yah
<lifeless> he may pop up today/tomorrow
<niemeyer> lifeless: Ok, so no history merging..
<niemeyer> (right now)
<lifeless> yeah
 * niemeyer starts a major manual branch split
<ScottK> Does bzr support doing partial branches/checkouts, or is it required to branch/checkout the entire repository?
<mkanat> ScottK: Whole branch.
<mkanat> ScottK: But you could do a lightweight checkout, too.
<ScottK> That makes checkouts faster, but doesn't really address my use case.
<mkanat> ScottK: Okay. What's your use case?
<ScottK> I've got a project were we'd like to have stuff in a bzr repo that only a few people actually need and it's a large/painful chunk of third party code.
<ScottK> It'd be nice if there was some way the people who didn't need that could manage to not pull it down when they branch/checkout.
<mkanat> ScottK: Hmm. Eventually, subtrees will solve that.
<ScottK> I sold bzr on this project on the basis of svn people can use it like svn and git people can use it ~like git (dvcs anyway) and this is the one place we've run into where that's not quite true.
<mkanat> Yeah.
<mkanat> ScottK: Somebody else in this channel might have a better idea of how to solve your problem.
<ScottK> OK.  Thanks.
<mkanat> ScottK: If it's really only a few people that need it, though, you could just put it into a separate branch.
<mkanat> But then they would have to know to branch that branch into the right place when checking out.
<ScottK> Yep.  That's part of the problem, needing to know that and to know in advance what might need to be treated this way.
 * mkanat nods.
<mkanat> ScottK: I'm guessing this is an enormous amount of data?
<ScottK> mkanat: Not in terms of say gigabytes, but compared to the rest of the tree, yes.
<mkanat> Okay.
<hno> Packaging question. Is there any good arguments why to package bzr-gtk + olive-gtk if also packaging qbzr + bzr-explorer?
<ScottK> Some people have an odd affinity for gtk?
<hno> ScottK: No idea. What triggered the question is that bzr-gtk just got dropped from Fedora due to not having an active Fedora maintainer.
<dobey> what was the command to dump a revision's data in raw form?
<ScottK> hno: I'm a fan of desktop environments that start with K, so you're unlikely to get good arguments from me.
<hno> ScottK: I actuallly run Gnome, but never use bzr gui tools or even care what desktop environment i run in.. happy to run qt/kde apps under gnome when I need them.
<rubbs> ScottK: not that it helps with checking out a subtree, but you may be able to hide some of that data with views.
<maxb> Well, I do like bzr-gtk's integration into the libnotify notifications, even though I use qbzr for most stuff
<dobey> bzr-gtk has some nice stuff
 * hno maintains bzr for Fedora.
<ScottK> The couple of times I've wanted a gui for bzr, I used qbzr.
<dobey> ScottK: that's only because it's not called kbzr ;)
<hno> dobey: can you specify what nice stuff you think bzr-gtk adds?
<dobey> gdiff
<james_w> the back button in gannotate
<hno> dobey: The diff in bzr explorer looks nicer to me. But gdiff is a lot easier to run from the command line.
<dobey> what's bzr explorer?
<hno> james_w: Indeed. That back button is very powerful
<hno> dobey: qbzr after it got split in qbzr qt bindings and bzr-explorer GUI application.
<hno> same split is taking place for bzr-gtk btw.
<mgz> hno: is gdiff from the commandline significantly different from qdiff?
<dobey> i don't know. i don't really use bzr-gtk stuff any more
<hno> mgz: Thanks. qdiff is equivalent to gdiff, and looks visually much nicer.
<dobey> i don't think bzr-gtk has really been developed much in the 'look nice' department
<mgz> s/bzr-//
<hno> james_w: qannotate provides a full history view you can navigate. In some ways similar to the back button in gannotate, but not quite the same. Plus qannotate apparently have trouble showing revision numbers properly.. (cuts initial digits on revisions >999 for me)
<hno> so +1 for gannotate there.
<dobey> mgz: if you want to bash some toolkit, do it in #anti-$toolkit or something please
<dobey> :)
<mgz> :)
<hno> The differences between qdiff and gdiff is not just pure visual candy. qdiff also shows a more detailed diff showing at character level what changed.
<mgz> qbzr devs would probably be interested in you filing bugs on where you think they could improve qannotate hno.
<mgz> might also be true for gdiff, but I'm not really sure there are any active devs.
<hno> mgz: I know. Goal for tonight is to find if there is any reason for me to get bzr-gtk to resurrected in Fedora, or if it should be let to die until further notice.
<hno> I thinks I will let it die in piece for now. Can easily get resurrected should someone feel sufficiently strongly that it's needed, and I guess we will know when Fedora14 ships without bzr-gtk.
<Walex> Is there a largish (Linux kernel sized) publically accessible Bazaar2 repo that I may clone to play around with?
<Walex> Either that or something not quite as large but still significant. Lots of small files (like headers, sources) in particular.
<hno> Walex: Far from linux kernel size, but I find that the squid repository is sufficiently large to expose many sizing issues in bzr operations.. pretty sure there is larger examples around.
<mkanat> Walex: I think people use the emacs repo usually for that.
#bzr 2010-08-28
<Walex> OK, thanks for that. For Mercurial the equivalwent is the Mozilla central repo.
<bzrboy> hi guys, how do i set a bidirectional mirror between a git repo and a bzr repo
<jelmer> hi bzrboy
<jelmer> bzrboy: I'm not sure that's possible yet.
<jelmer> It might be possible with fastexport/fastimport somehow
<jelmer> bzr-git has some preliminary support but that's explicitly disabled in the code at the moment.
<bzrboy> jelmer: thanks
<bzrboy> sorry for the delay, i was trying to figure it out
<Hamled> Is it possible to convert a lightweight checkout into a heavy checkout?
<spiv> Hamled: IIRC 'bzr reconfigure --checkout' will do that
<Hamled> thanks
<Noldorin> hi. i've deleted a certain plugin from my plugins directory, but every time i run bzr it still complains about loading it as if it were there.
<Noldorin> how can i resolve this?
<vila> Noldorin: 'bzr plugins -v' should tell you where bzr finds it
<Noldorin> vila, it's not listed there i'm afraid, only the error
<Noldorin> Unable to load plugin u'tfs' from u'C:/Program Files/Bazaar/plugins'
<vila> Try to have a look at .bzr.log
<mgz> vila: was about to tell you I'd worked out why maverick wasn't showing results, but... the most recent run didn't fail
<mgz> did you poke pyjunitxml already?
<Silasle> What does this mean? http://paste.ubuntu.com/485080/
<Silasle> Or an better question what's the problem? It has worked before but then i removed all my settings (~/.*) and since then it doesn't work.
<cody-somerville> Silasle, you probably need to do bzr launchpad-login <your-lp-id>
<cody-somerville> replacing '<your-lp-id>' with your launchpad id
<cody-somerville> and oh my
<cody-somerville> you did rm -rf ~/.*?
<Silasle> I have done that
<cody-somerville> you probably deleted your ssh key!
<Silasle> And where is this saved?
<cody-somerville> you'll need to generate a new one (or if you already did that), upload it to launchpad
<cody-somerville> ~/.ssh/
<Silasle> That was the problem, i just had to copy my old one from the backup.
<cody-somerville> :-)
<Silasle> Thanks cody-somerville!
<cody-somerville> Silasle, No problem! :)
<Silasle> And then the next problem: bzr: ERROR: Working tree "/home/silas/Dropbox/python/player/" has uncommitted changes (See bzr status). Use --no-strict to force the push.
<Silasle> Oh, not that
<Silasle> That one: http://paste.ubuntu.com/485086/
<cody-somerville> Your branches have diverged.
<cody-somerville> You probably need to merge in changes someone else has made.
<cody-somerville> See "bzr help diverged-branches" for more information.
<Silasle> I have looked at that
<Silasle> Ok, now i solved the problem by just downloading it again and replacing the modified file.
<hno> Is there anyone looking into bzr on Python 2.7?
<mgz> I've filed a bunch of bugs, which I'm gradually working through.
<mgz> see: https://bugs.launchpad.net/bzr/+bugs?field.tag=python2.7
<hno> mgz: Thanks. Already know that list.
<mgz> is there anything else you're concered about?
<mgz> +n
<hno> mgz: Not really, besides having to support bzr on Python2.7..  Anything I can do to help?
<mgz> well, mostly things just need descisions about how to resolve version compat issues
<mgz> but actually the top bug that you've already commented on might be an interesting one to tackel
<mgz> ...I can't spell this evening
<hno> Yes, was thinking the same. Just wanted to check first as I do not know xmlrpclib at all, and not entirely fluient in python in general.
<hno> the second one is beyond me. can't judge what implications changes there may have on bzr.
<mgz> yeah, I'm not sure either, I'll probably just put up a mp to pull out the hacks entirely and see if anyone squeaks
<vila> mgz: huh ? What job are you referring to ?
<mgz> the first should just be case of comparing the code in bzrlib.transport.http._urllib2_wrappers with the 2.7 changes
<mgz> vila: http://babune.ladeuil.net:24842/job/selftest-maverick/26/ - but after I looked at it again I think it might be because of this: http://babune.ladeuil.net:24842/job/selftest-maverick/26/testReport/junit/bzrlib.tests.test_conflicts/TestResolvePathConflict/test_res________________________________________/
<mgz> so, the whole thing died off before the test that was breaking the xml generation was reported or something maybe?
 * vila on phone
<mgz> not urgent, and I'll probably be eating soonish
<vila> mgz: hmm, possibly
<mgz> anyway, I'll fix pyjunitxml to not break (it's yet another not-handling-unicode-properly issue)
<vila> mgz: but selftest-maverick is for bzr.dev, not your branch nor your testtools branch either...
<vila> mgz: ha great !
<mgz> it could actually break on not python 2.7 as well, but depends on the test failure output
<vila> I'm expermienting some weird random failures on gentoo, things like 'lost connection while parsing test success' or something, that may be related
<vila> expermienting... sounds like pippermint, that gives a pleasant taste to the experiment ;)
<mgz> oo, I remember something else I wanted you for vila
<mgz> can you confirm bug 625594 for me?
<ubot5> Launchpad bug 625594 in Bazaar "selftest --parallel test case timings incorrect (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/625594
<mgz> I think it will also be wrong with --parallel=fork but might be mistaken
<hno> How do I add/checkout a workingtree in an existing branch pushed to me?
<mgz> `bzr reconfigure --tree` I think
<hno> Thanks. Seems to work. What is needed to update the tree in future after next push?
<vila> mgz: I'm pretty sure i've never seen any correct timing there but it never itch enough either
<mgz> thanks vila, just wanted to check it wasn't something I'd screwed up locally
<vila> mgz: it would be nice if you're write since it may explain why all tests timings are 0 on babune, which I thought was hudson related
<vila> s/write/right/ (how the hell did I make this typo... English is *not* my native language....)
<mgz> just be glad you don't have to see my french spelling
<vila> lol
<mgz> hno: I don't quite understand what you mean, trees should just stick around, push only affects branch creation
<mgz> okay, food for me now, I'll be back again a little later
<hno> mgz: Thanks. Thought push didn't update the tree.
<vila> hno: it doesn't update the remote tree (unless "remote" is on a local filesystem)
<hno> right. bzr update does.
<hno> all good. Thanks.
<hno> mgz: The first one seems to be a case of pathing around urllib2 to make it behave for bzr use rather than fixing it proper.
#bzr 2010-08-29
<dev001> Anyone here use the QBzr eclipse plugin?  Using the recommended (http://wiki.bazaar.canonical.com/QBzrEclipse) update site, http://bazaar.canonical.com/releases/3rd-party/qbzr-eclipse, returns a "repository not available" in Eclipse.
<Noldorin> i see the following in my bzr log:
<Noldorin> WARNING: "Key 'tfs+http://' already registered"
<Noldorin> where do protocols actually get registered?
<jelmer> Noldorin, they get registered when a plugin is loaded
<jelmer> Noldorin, I've seen that particular error a couple of times when a plugin had syntax errors and was installed in two locations (system and user home)
<Noldorin> jelmer, ah right
<Noldorin> jelmer, problem is, the plugin is installed *nowhere* on my system
<Noldorin> not that i can find
<Noldorin> yet it's still picking it up somehow
<jelmer> Noldorin, it would be..
<Noldorin> ?
<jelmer> Noldorin: this error suggests it's still installed *somewhere*
<Noldorin> ok
<Noldorin> i've checked all the usual places though
<Noldorin> jelmer, anywhere you'd suggest to look now?
<jelmer> Noldorin, have you checked /usr/local ?
<Noldorin> jelmer, Windows. but yes, the equivalent
<Noldorin> jelmer, ok, very strange. it wasn't showing in Windows Explorer, but another utility picked it up
<Noldorin> oh well
<Noldorin> bbl
<vila> Noldorin: ha, finally, the ghost get out of its hole... Tell us what you find as it may happen to someone else and I'd really like to understand what happened to you.
<knittl> how can i do a log on a file which was moved in an earlier revision?
<knittl> bzr log -- $filename does not work
<knittl> :-/
<mgz> vila: this is the runtime problem with your leaks branch:
<mgz> http://float.endofinternet.org/temp/leaking_diff.xml#bt.test_remote.TestRemoteRepositoryCopyContent.test_copy_content_remote_to_local
<mgz> done a great job of squashing leaks, but a fraction of them have turned from 100ms leaks to 5000ms hang timeouts
<mgz> and some are even worse:
<mgz> http://float.endofinternet.org/temp/leaking_diff.xml#bb.test_branch
<mgz> I'll poke around all that orange now.
<mgz> okay, don't completely understand that orange, but the fix is easy
<mgz> don't store the real get_transport method on the test instance and close over self, just close over the real method
<jelmer> hi mgz
<mgz> hey jelmer.
<Noldorin> vila, back. i certainly will. it's baffled me too!
<Noldorin> vila, you there?
<mgz> he's probably having a nice non-work sunday afternoon now :)
<Noldorin> heh, probably.
<Noldorin> so was i, but this bzr stuff is haunting me :)
<vila> mgz: ha, yeah, sure, I know about them but I decided to ignore them for the time being. It should be possible to reduce the timeout though, I just haven't experimented with that
<mgz> yeah, we did discuss them before, just didn't time the full test run previously
<vila> mgz: I have still to see why you need to *avoid* the closures instead of breaking the cycles. 'closures' are too powerful to get rid of them unless there is really no other solution IMNSHO
<mgz> quite often the cycle is accidental and redundant anyway - for instance, the change to get rid of that orange actually makes the code simpler
<vila> Noldorin, mgz: It's raining here. But not in movie theaters. 'Inception' is... one of my favourites from now on :0)
<mgz> I'm off to cinema in an hour or so too.:)
<vila> mgz: also, keep in mind that the get_transport trick is temporary, a better solution will be a hook.
<vila> mgz: hehe, movie already chosen ?
<mgz> scott pilgrim. which I have no idea whether I'll like or not, but hey.
<vila> mgz: hmm, let us know ;-)
<vila> Noldorin: I won't stay long, it's dinner time for me
<Noldorin> vila, sorry, had to disappear
<Noldorin> anyway, seems the main problem was that the file was deleted from the directory index but was still on disk :S
<Noldorin> or something like such
<Noldorin> since windows explorer wasn't listing it
<vila> Noldorin: even with a refresh (F5) ?
<Noldorin> yes
<vila> weird :(
<Noldorin> vila, yes, it's strange. i think bzr/python is doing something strange (non-windows like) to list the plugins directory
<Noldorin> vila, at least you know for future reference though :)
<vila> bzr/python relies on the file system, if something is strange, it's there
<vila> that, or windows explorer...
<Noldorin> vila, yeah, maybe it' just doing something "non-windows-like"
<Noldorin> oh well
<Noldorin> still curious how i can get bzr-tfs set up on windows hmm
<vila> Noldorin: sry, I haven't look into this plugin, yet
<Noldorin> that's fine
<jelmer> Noldorin: are the codeplex repositories available using tfs?
<Noldorin> jelmer, absolutely. it's the 'primary' VCS for codeplex
<jelmer> ah, cool
 * jelmer updates the error message in codeplex to mention bzr-tfs
<mgz> jelmer: it's my understanding that the xml stuff dead code on modern formats as well, but want someone who actually knows to say that.
<jelmer> mgz: In that case, consider it said :-)
<mgz> okay, time for one more bug before I leave
<Noldorin> bzr push tfs+https://tfs.codeplex.com/ircdotnet/devel
<Noldorin> jelmer, i am trying that but no luck
<Noldorin> bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack
<vila> mgz: consider it repeated :)
<Noldorin> ah, seems my url format is bad
<FryGuy-> i had a bunch of problems getting bzr-tfs to work on our tfs 2010 server :(
<mgz> okay cinema tomorrow evening instead
<lifeless> mgz: enjoy
<mgz> left it too late for tonight (and the weather is kinda horrid even for driving into town)
<mgz> lifeless: I've got some changes for pyjunitxml, do you want mps?
<lifeless> please
<mgz> also, aren't expectedfailure and unexpectedsuccess backwards?
<mgz> they get treated like a failure and a success respectively.
<lifeless> good catch
<mgz> I'll switch them, and use... unittest.case._UnexpectedSuccess for the exception name?
<lifeless> thats not very backwards compatible
<lifeless> if its from testtools its ok
<lifeless> (I think; does pyjunitxml use testtools already?)
<mgz> nope.
<lifeless> hmm, or is that just a string literal
<lifeless> if its just a string literal thats ok with me.
<mgz> right, string just for the xml attribute content
<lifeless> its been a while since I opened that project ;)
<mgz> :)
<lifeless> mgz: btw, the monkey patching xml stuff
<lifeless> mgz: -huge- performance win
<mgz> I can imagine, but is it still used?
<lifeless> as jam says, in bundles
<lifeless> I'm neutral on removing the optimisation
<lifeless> let me say that
<mgz> ah, not looked at mail again yet
<lifeless> me, I closed the thread
<lifeless> anyhow, I'm on the fence
<lifeless> some folk still have older format branches
<lifeless> dunno what %; LP probably knows
<mgz> hm, wonder if junit will fall over if a failure element has no content...
<mgz> I can live with updating the hack, just didn't know how important it was and didn't get an answer on the bug, so figured sticking an mp up was a way to get people who cared to speak up
<lifeless> fair 'nuff
<lifeless> mgz: does my comment about LBYL make sense to you?
<lifeless> was possibly a bit opaque
<mgz> lifeless: it does, two thoughts on it,
<mgz> one, I'm not sure on the ideas of what is allowed to raise BzrCommandError so sticking it underneath a similar one for subunit absense seemed safe
<lifeless> you can raise a non BzrCommandError
<Noldorin> FryGuy-, yeah, seems bzr-tfs doesn't like the codeplex servers either
<lifeless> as long as internal=False, it will format the same
<mgz> also, wanted to always raise it, not silently let it pass if concurrency=1
<Noldorin> FryGuy-, from what i've seen...
<FryGuy-> i made a bunch of hacks on mine to get it to work
<FryGuy-> but then it stopped working
<lifeless> mgz: that last bit isn't particularly compelling to me; I'm curious why it is to you ?
<mgz> but could move to bzrlib.tests.fork_decorator instead, which is a bit closer to the actual site
<lifeless> yes, that would be better
<FryGuy-> noldrin: do you want to try my version and see if it's any better?
<lifeless> the main point for me is that this is delegated reponsibility
<mgz> because I'm on a 1 cpu machine and was very confused the other day when trying to repo --parallel things
<lifeless> is there an optimisation to not fork if cpu count = 1? that would be a bug unless its in fork_decorator (because ec2 *has* to go to ec2 :P)
<mgz> there is, both the --parallel decorators do nothing if 1
<lifeless> mgz: there are three :)
<mgz> hiding!
<fullermd> Pah.  If it were REALLY parallel, it would create an arbitrary number of decorators on demand...
<lifeless> mgz: the third is in a plugin
<lifeless> mgz: bzr-ec2test
<mgz> hm, I just hit 's' rather than 'e' in feed-pqm by mistake
<mgz> will that do bad things?
<lifeless> it will use the API
<lifeless> which pqm is not looking at now
<mgz> what letter do I use for "disregard that, I'm an idiot"?
<lifeless> e
<mgz> but it's not in the list any more...
<lifeless> run with --show-queued or whatever the option is
<mgz> ah, ta.
<mgz> ark, now I understand why running the pyjunitxml test suite doesn't work on python 2.4
<mgz> it's the __main__  vs. unittest thing
<mgz> get two different sets of classes so unittest.TestSuite instance is not a __main__.TestSuite
<mgz> what's the normal hack around that?
<lifeless> use python 2.5 ?
<lifeless> boom-tish
<mgz> also fails on 2.5
<lifeless> uhm, sigh
<lifeless> I forget
<mgz> so, presume you need 2.6 at least.
<lifeless> does python -m subunit.run pyjunitxml.test_suite work ?
<mgz> that's a package, not a module, so not for my 2.4 no
<lifeless> python /path/to/subunit/run.py pyjunitxml.test_suite
<mgz> I think I tried using the testtools runner script directly the other day and that didn't work for some other reason
<mgz> okay, nearly at the bug that actually started me on this crusade now...
#bzr 2011-08-22
<Noldorin> hi jelmer
<Noldorin> what's up?
<jimis> Hello
<jimis> Is there a way for "bzr log -p" to display diffs using specific diff flags?
<jimis> In particular I want diff -p
<jimis> hmmm I'm trying to do "bzr diff -cREV1 -cREV2" to get a diff containing various sparse changes, but it seems it doesn't understand that
<vila> hell o guys !
<vindolin> when i click on the icon before modified items in the overview, the diff window briefly opens and closes immediately.. on the console i get: bzr: ERROR: Path(s) are not versioned: __init__.py
<vindolin> ^ bzr explorer
<Merwin> I've got a problem, I made a mistake a switched to a repo I didn't want to. So, I removed the directory. But now, bzr considers I'm still in the repo...
<Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/Logica/addons-opas$ bzr status
<Merwin> bzr: ERROR: Not a branch: "/home/thibaut/OpenERP 6/Logica/addons-opas/trunk/".
<Merwin> Of course, the trunk/directory is deleted
<Merwin> I'm using a colo-branches repo, but switch to colo:xxx doesn't work
<Merwin> Like if my repo was broken. How can I change the branch I'm currently in ?
<Merwin> (Trying to bzr switch somewhere else give me the same error: Not a branch)
<vila> Merwin: did you try the '--force' parameter for switch ?
<Merwin> vila: I'll try
<Merwin> It works, thank you ;)
<vila> Merwin: great
<vila> vindolin: make sure you use the latest versions of bzr/qbzr/bzr-explorer and if the problem persists, file a bug: http://pad.lv/fb/bzr-explorer
<vila> maxb: bzr -2.4.0 all over the place ? \\0 \o/ 0//
<vila> jelmer: so, https://bugs.launchpad.net/bzr-svn/+bug/826946 is still a blocker ?
<ubot5> Ubuntu bug 826946 in Bazaar Subversion Plugin "Commit to svn repo completes, but repo is not updated" [Critical,Triaged]
<jam> morning all
<vila> hi jam !
<maxb> vila: ?
<vila> maxb: celebrating 2.4.0 in the stable ppa ;)
<jelmer> sigh, just had a kernel panic. It's been a while since I've seen one of those.
 * vila kills a goat
<jelmer> vila: :)
<vila> jelmer: so, https://bugs.launchpad.net/bzr-svn/+bug/826946 is still a blocker ?
<ubot5> Ubuntu bug 826946 in Bazaar Subversion Plugin "Commit to svn repo completes, but repo is not updated" [Critical,Triaged]
<jelmer> vila: yes, I have a better idea of what's happening there now though
 * vila nods
<vila> I've read your last comments
<vila> jelmer: any help needed ?
<jelmer> any suggestions on what's actually happening would be most welcome :)
<vila> ha, that's harder  :-/
<vila> you said 'http-specific', any details ?
<jelmer> not at this point
<jelmer> it just seems like all revisions are pushed with empty details
<jelmer> in theory the external users of the svn library shouldn't really care about the transport, but in practice there are a couple of quirks
<jelmer> the bzr-svn testsuite only uses file://
<jimis> Is there a way for "bzr log -p" to display diffs using specific diff flags?
<vila> jimis: not that I know of from the command line, writing a plugin to define a specific log format will give you access to all the control you want though
* Riddell changed the topic of #bzr to: current topic is: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: JAM
<Merwin> Hey guys, when using Bazaar Explorer to merge using meld on Ubuntu, when I save my .THIS file. Am I doing something wrong ? WHich one will be my "final" file ?
<Merwin> I'm using meld to do the merge
<Merwin> Opps, some words are missing : When I save my file with meld, merge markups are not removed from the file.
<Merwin> So, maybe I'm not editing the good one, which one should I edit ?
<jelmer> hi Merwin
<Merwin> hi jelmer :)
<jelmer> Merwin: I think you need to edit the regular file using meld, but I'm not entirely sure (I don't have experience with meld)
<Merwin> What do you use ? If you have a better tool, lemme know !
<Merwin> Currently, Meld opens a 3-file view, with .BASE, .THIS and .OTHER. I'm editing the .THIS file.
<jelmer> Merwin: I just use a regular editor to resolve conflicts
<jelmer> s/use/using/
<Merwin> ok
<Merwin> jelmer: I don't understand. From what I read here : http://doc.bazaar.canonical.com/latest/en/user-guide/resolving_conflicts.html#resolving-a-conflict we have to edit the three files
<Merwin> Why would I do this ?
<jelmer> Merwin: you don't have to edit the tree files
<jelmer> Merwin: you can either edit the main file and resolve the conflicts there, overwrite it with .OTHER or .THIS (if you want to keep one side of the merge only),)
<Merwin> So, if .OTHER is the merge version, and .THIS my version, what is .BASE ?
<jelmer> Merwin: .BASE, .THIS and .OTHER are there so you can copy them over the main file, or e.g. run "diff" between them to see what has changed, use your favorite merge resolve tool (like meld))
<jelmer> Merwin: .BASE is the base version from the 3-way merge; the merge works by applying all of the difference between .BASE and .OTHER to your version
<Merwin> hum
<jelmer> (roughly speaking)
<mgz> you don't generally edit any of those three files, you edit the original
<jelmer> maxb: hi
<maxb> hi
<jelmer> maxb: where was the problem with the bzr-builddeb test suite exactly?
<maxb> test_repack_tarball IIRC
<maxb> The failures should be clearly visible in the daily PPA
<jelmer> yeah, but what was the issue?
<jelmer> I know which tests are failing :)
<maxb> The issue was that it was trying to open an on-disk path that happened to contain ( ) characters, and it was trying to open them as %28 %29
<jelmer> ah, ok
<Riddell> ug, I just had a random X crash, haven't had that in ages, something crashy in the air today
<jelmer> Riddell: ouch
<Riddell> must be solar flares or the like
 * vila kills another goat
 * jelmer wonders where vila finds all those goats in the city centre of Strasbourg
<vila> jelmer: courtesy of fullermd
<fullermd> Aiee!  My goat!
 * fullermd runs out the door to a meeting.
<jimis> How do I tell to "bzr merge -c" to get the last changeset from target branch?
<jimis> is it -c-1?
<jelmer> jimis: yes
<jimis> thanks
<jimis> jelmer: nope, it brought some other changeset, which had various conflicts
<jimis> luckily I used --preview :-)
<jelmer> jimis: It will only merge that change, but that change obviously depends on previous changes, which might cause conflicts.
<jimis> It's in the same file with other changes, but really far away from them
<jimis> is there a way to bring the patch from only that revision?
<jimis> jelmer: I think it brought the one before the tip, not the tip (the last one)
<jelmer> jimis: -c -1 is the changes made for the last revision
<jelmer> jimis: see also "bzr diff -c -1"
<jimis> ah thanks
<jimis> strange that it had all these conflicts
<jimis> so I'll just apply the diff
<jimis> but it doesn't look right, conflicts should be only when changes overlap :-s
<smoser> Anyone know where these messages come from:
<smoser>  Packaging branch version: 5.3.2-1ubuntu4.5
<smoser> Packaging branch status: OUT-OF-DATE
<smoser> I *really* like them.  It might be useful if they provided a link to http://package-import.ubuntu.com/status/ also
<jelmer> smoser: jam added them recently, they come from a hook in the bzr launchpad plugin
<jelmer> smoser: wrt the package-import link, please file a bug :)
<smoser> jelmer, will-do.
<smoser> then, even better would be to not fail the importer
<smoser> ;-)
<smoser> what source package is that ?
<smoser> is it just bzr ?
<jelmer> smoser: yup, it's a plugin bundled with bzr
<smoser> k. so file bug against bzr project
<smoser> thanks
<smoser> jelmer, bug 831428
<ubot5> Launchpad bug 831428 in Bazaar "add link to failed imports in branch out-of-date message" [Undecided,New] https://launchpad.net/bugs/831428
<jelmer> smoser: merci
<jimis> when merge --preview outputs nothing, it means the branch is already merged?
<jelmer> either that, or there are no changes to merge
<jimis> Is there another way to see which branch is merged where, without using a gui?
<jelmer> jimis: "bzr missing"
<jimis> thanks jelmer, very helpful!
<vila> jelmer: looks like your fir for testtools-0.9.2 is not part of bzr-2.4 ?
<jimis> jelmer: and can I see where exactly a merge happened, and at what revision were both trees? log doesn't help, any parameters I'm missing?
<vila> jimis: bzr log -n0 ? (+ --limit=nnn if needed)
<jelmer> vila: yeah, though it's cherrypicked to the relevant debian/ubuntu package
<jimis> I've tried log -n0 -v, but output is not clear about merges
<jimis> I'll check it again
<vila> jimis: yeah, bzr log output is an acquired taste, but really for moderately complex histories, you'd better try bzr qlog (from the qbzr plugin)
<vila> jelmer: hmm, so if we ever upgrade pqm confusion will ensue :-/
<jimis> :-( unfortunately gui access isn't a choice
<vila> jimis: huh ? how come ? remote access ?
<jimis> yeap
<vila> >-(
<jimis> and user access only, not root
<vila> goes without saying... :-(
<jimis> so even if I did compile my own python etc to be able to run bzr 2.4
<vila> jimis: I don't fully understand your use case but bzr log --exclude-common-history may help you at one point
<jimis> I don't have devel libraries to build gui packages, it would be too much hassle to do them from start...
<vila> jimis: OS ?
<jimis> vila: ok I'll try it thans
<jimis> RHEL5 ;-)
<vila> eeesh
<jimis> bzr: ERROR: --exclude-common-ancestry requires -r with two revisions
<jimis> it would be cool to understand I mean current branch versus parent branch :-p
<jimis> anyway :-)
<vila> jimis: bzr log -rancestor:.. ?
<jimis> vila: it was only a "bzr log --exclude-common-ancestry". I was expecting to exclude common history of current and parent branches.
<vila> jimis: ha ! Oh, but it has far more uses and requires a revision range anyway
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, i noticed collocated branches are now supported in bzr :-)
<Noldorin> at least the beta
<Noldorin> jelmer, still had no time to investigate my particular issue with my branch....been busy on holiday
<Noldorin> but soon
<Noldorin> shall be back shortly
<Noldorin> jelmer, but at least i can start testing with GitHub i guess?
<Noldorin> multiple branches
<jelmer> Noldorin: yeah
<Noldorin> jelmer, cool. which releases of each do i want to use?
<Noldorin> bzr, bzr-git, dulwich that is
<jelmer> Noldorin: tip of all three
<Noldorin> jelmer, no releases in either yet?
<Noldorin> err
<Noldorin> any
<jelmer> Noldorin: nope
<Noldorin> jelmer, when do you anticipate them?
<Noldorin> jelmer, i though bzr 2.5b1 has collocated branches support now...
<jelmer> I guess dulwich 0.8.0 is sufficient, but bzr-git and bzr will be a while (about a month I guess)
<jelmer> Noldorin: 2.5b1 isn't out yet
<Noldorin> okay
<Noldorin> jelmer, are you timing a new release of bzr-git/dulwich for around 2.5b1 release time?
<jelmer> Noldorin: depends on if there are any other worthwile fixes at that point
<Noldorin> i see
<Noldorin> jelmer, so maybe i should get working on that bzr-git bug when i return :-)
<Noldorin> the git database issue i guess
<jelmer> Noldorin: what's the problem with running a snapshot?
<jimis> What log -n0 does is that is shows subrevisions that came with merges?
<Noldorin> jelmer, nothing, i'm just curious :-P
<Noldorin> but also, are there windows binary builds for bzr 2.5b1?
<jelmer> there probably will be
<Noldorin> ok cool
<Noldorin> will have a look before long
<Noldorin> brb for now
<CrazyLemon> hey guys..one quick question..is it possible to pull specific files instead of whole branch ?
<CrazyLemon> folders*
<poolie> hi all
<maxb> poolie: Hi. You seem to have a forgotten vim session on jubany
<niemeyer> Hey all
<niemeyer> Who's the bzr MacOS master?
<jelmer> hi niemeyer
<jelmer> niemeyer: probably doxx, though I don't see him around at the moment.
<niemeyer> jelmer: Yo
<jelmer> niemeyer: what's up?
<niemeyer> jelmer: COol.. I just got a note from a friend saying the MacOS bzr fails when unpacking
<niemeyer> He thinks it might be on his side, but not quite sure, so I figured it might be good to at least ping the maintainer
<poolie> hi maxb, niemeyer
<poolie> maxb, does it have something locked? i'll close it
<niemeyer> poolie: Hey!
<niemeyer> https://plus.google.com/109174220542239592378/posts/Pbhi9XB69uV
<jelmer> niemeyer: FWIW I don't see anything related in the bzr-mac-installers lp project bugs, so it'd indeed be good to check with doxx
<poolie> maxb, should be ok now
<maxb> poolie: Thanks. Also, are those local mods to import_package.py yours?
<jelmer> also, hi poolie, maxb
<niemeyer> jelmer: Cool, thanks
<poolie> they are; let me see about cleaning them up
<poolie> hm
<poolie> at the moment i have it tweaked to get the branch using lp.load rather than branches.getByURL
<poolie> the latter is probably better, and i think it's now in trunk
#bzr 2011-08-23
<poolie> maxb, is there any place that th eudd importer summarizes successful imports?
<poolie> ok back in a bit
<AuroraBorealis> so
<AuroraBorealis> how the heck do i install pycrypto for windows >.>
<AuroraBorealis> (which is needed to run bazaar development version or something)
<AuroraBorealis> or rather what version of visual studio do i need to compile it
<vila> Heigh-ho, Heigh-ho
<vila> good morning all
<poolie> hi vila
<vila> hey poolie
<vila> :)
<jelmer> Salut poolie, vila
<vila> jelmer: hey !
<poolie> bon soir
<poolie> shall we have a chat in a few minutes?
<vila> poolie: French is not a coherent language, one say (one word) 'bonsoir', 'bonjour' but (two words) 'bonne soirÃ©e', 'bonne journÃ©e'...
<vila> poolie: yes, mumble or voip ?
<vila> poolie: and of course (two words) 'bon appÃ©tit' ;)
<poolie> heh
<poolie> so much for that
<Riddell> hi
<jelmer> moin Riddell
<poolie> jam, helllo?
<jam> hi poolie
<poolie> jam, mumble?
<poolie> jam: ?
<jam> right, sorry
<jam> brt
<poolie> so vila, thanks for working on the release
<jam> jelmer: poke?
<poolie> so, what else, aside from chasing people up about that?
<vila> so, the summary is that I don't officially announce 2.4.0 waiting for windows installers themselves waiting for a bzr-svn release fixing bug #826946
<ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/826946
<poolie> fair enough, let's decide about that
<poolie> and you worked a bit more on configuration stuff?
<vila> yup, with more to come
<vila> I'm currently encountering issues about how we deal we env variables
<poolie> oh?
<vila> mainly: how are they encoded
<vila> which itself raises the issue of decoding differently paths/urls and other stuff
<poolie> ok, so this is if they hold non-ascii strings etc?
<poolie> "they're in utf-8" :-P
<vila> with also a link to how configObj "helpfully" returns lists when encountering commas (instead of unicode strings in all other cases)
<vila> poolie: or mbcs for windows
<vila> and when I went the "utf-8 rules" route for BZR_HOME I encountered some resistance :)
<vila> and was told to use fs encoding instead
<poolie> vila, you seem to have 0 bugs in progress?
<vila> which is fine except it requires some more input to decide whether an env variable is a path or not
<vila> meh
<vila> https://bugs.launchpad.net/bzr/2.4/+bug/824513 ?
<ubot5> Error: ubuntu bug 2 not found
<poolie> i don't want to create a lot of paperwork but perhaps having just a "environment isn't handled by config" etc makes sense
<vila> oh, that's because it's fixed in trunk but not in 2.4
<poolie> ok, so what's up next?
<vila> once env vars are sorted, option expansion (waiting on env vars but almost ready to submit)
<vila> then 'bzr config' on top of the new design
<vila> then probably a path/url option type (not sure about that yet)
<poolie> ok
<vila> then migrating the remaining options
<poolie> jam, jelmer, does working on this still make sense to you?
<jelmer> poolie: hmm
<jelmer> it'd be nice to finish the work
<jelmer> but there's always plenty of small things to work on
<poolie> jelmer, so you're saying these don't necessarily stick out ahead of other bugs?
<poolie> jr, thanks for the pp mail
<poolie> like i said on the list the main thing is probably to just chase people up to finish them
<poolie> (possibly people is me)
<poolie> jr, i think getting i18n finished off would be well worth while
<poolie> since it seems like it does largely exist
<poolie> i think we will need to fix up the way some strings are handled
<poolie> perhaps we can have a debug flag that turns off gettext entirely, in case something horrible goes wrong
<poolie> oh, one thing i was going to mention is tox
<poolie> http://pypi.python.org/pypi/tox
<poolie> which you can use for a kind of local mini-babune
<vila> poolie: sry, I missed "environment isn't handled by config" msg, what do you mean by that ? Stop supporting env vars ? BZR_EMAIL, EDITOR and so on ? Ignore the existing bugs ? Or just "don't try too hard" for the new stuff ? (Which is the spirit I followed in https://code.launchpad.net/~vila/bzr/convert-default-values/+merge/72431) ?
<poolie> my point was, please file bugs for enhancement work
<poolie> vila, does that answer your question?
<vila> on the surface, yes, on the deeper issue of whether or not we should fix config, not really
<vila> bugs like http://pad.lv/388725, the lack of a proper conf file for working trees, the diverging implementations of config stuff in plugins, needs a re-design.
<ubot5> Launchpad bug 388725 in Duplicity "Report when duplicity is 'done' with restoring a file" [Undecided,New]
<vila> bah, bug #388275
<ubot5> Launchpad bug 388275 in Bazaar "want configuration option to control progress bars" [Medium,Confirmed] https://launchpad.net/bugs/388275
<vila> gha, bug #491196 damn it
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196
<nigelb> poolie: lol, I had babu on /hilight and I got pinged for babune ^-^
<jimis> Hi all, I'm trying to connect to launchpad (bzr launchpad login) but because of a firewall on outgoing connections I can't.
<jimis> Which ports should be allowed to connect? strace shows too many, are they all needed? In particular I can see 785,786,745,53,443
<jelmer> just https and ssh should be sufficient I think
<jelmer> and DNS obviously :)
<jimis> thanks jelmer
<jimis> DNS, why didn't I think of that :-)
<jimis> jelmer: ssh at launchpad is on port 22?
<jelmer> jimis, yep
<jimis> ok, I'll ask for 443 and 22 from the admin
<jimis> I believe 443 will be easy, but we'll have some disagreement on 22 :-p
 * vila pesters useless goats
<poolie> jam, lool just told me he regularly run http://paste.debian.net/127113/
<poolie> to fetch history
<poolie> so, apparently having a lot of history copied is not enough to make the existing get_parent_map patch work really well
<lool> the main reason we're running this is to speed up pushes, because there is only one stacked branch, but it was lacking too much data from gcc-4.4 or 4.6 and that slowed down pushes dramatically
<poolie> right
<poolie> hm
<poolie> i wonder if they should be unstacked altogether if you're doing this  then
<poolie> let's see if jam comes back
<jam> lool: that is fetching into r_4_5, don't you want to fetch into r_4_6?
<jam> or are you saying that doing the fetches into r_4_5 didn't make things faster?
<jam> if 4.5 is the "dev_focus" it should *already* have all the revisions
<jam> the thing we wanted you to run is to push the extra revisions into the stacked branches, until such time that we fix the fetch issues
<jam> (the issue is that when a revision is in the stacked-*on* branch, not the stacked branch, we first query the stacked branch, and then fall back to the stacked-on branch, where we already have the information cached in memory, we just need to access it first.)
<lool> jam: 4.5 is the devfocus, so is the default stacked branch
<lool> jam: what we want is for a push to be fast
<jam> lool: "it is the default branch that gets stacked on"
<jam> lool: what branches are you pushing to regularly? All of them? Just 4.5?
<lool> jam: e.g. I push a new topic branch, for 4.4, 4.5 or 4.6 and I want that push to be fast because launchpad stacks the devfocus (4.5) by default
<lool> jam: 4.4 is probably abandonned by now; 4.5 is mostly bugfixes, the true dev focus is 4.6 AFAIK
<lool> so we push to random new topic branches for merging, and we push to 4.5 and 4.6
<jam> lool: most likely you should try to migrate your dev focus branch to 4.6
<jam> since, in theory, it should always have everything 4.5 has, right?
<jam> (at least after convergence)
<jam> I'm not sure how gcc does multiple mainlines
<jam> do you merge up?
<lool> jam: I don't think we ever merge across 4.x branches; too much upstream delta for this to be useful
<jam> k
<jam> so you'll still need to do some sort of fetch everything if it isn't happening naturally
<lool> jam: I also believe that we should switch the devfocus, but I don't think it would make any concrete difference, would it?
<jam> otherwise the 4.X(not-focus) feature branches will grow
<lool> yes
<jam> lool: for push performance, it should be similar
<jam> just that it takes less maintenance the closer you get it to the actual feature branches
<lool> well, launchpad could be more clever about picking up stacked branches, but that's another story
<jam> for *pull* and *branch* performance, that could be different
<lool> would it?  AIUI, people work with local rev repos (init-repo) so that they already have most of the revs around
<lool> does the lookup in the stacked branch cost a lot to launchpad?
<jam> lool: it is cheap for launchpad, but it is a round trip. the bug is #388269
<jam> lool: if people have shared repos that are populated, it doesn't make a difference
<jam> bug #388269 is about initial branching into an empty shared repo
<ubot5> Launchpad bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,In progress] https://launchpad.net/bugs/388269
<jam> which is *painfully* slow
<jam> like hours doing nothing slow.
<jam> because it sends 100k requests to lp each one replying with "nope, I don't have that"
<lool> so if gcc-4.6 is stacked on gcc-4.5 in launchpad and I branch 4.6, I would hit that bug?
<lool> sounds like I should populate 4.6 with 4.5 contents then, just in case some 4.6 revs are in 4.5 and that it takes a roundtrip to figure it out
<jam> lool: right, it only really matters for big fetches. If it is 50 round trips, not a big deal. The problem is when it is *thousands*
<jam> So you shouldn't have to do it regularly, we just want to do it once
<jam> but we don't have write access.
<lool> I'll do it from my cron which is doing this already
<lool> I've setup a special launchpad account which has write permissions to the linaro toolchain branches
<lool> well only need to be done once indeed; new 4.6 revisions would be pushed only there anyway, not to the stacked branch
<poolie> ok good night
<lool> 'night
<lool> the copy hsa been running for close to an hour now, gah
<jelmer> g'night poolie
<lool> Connection to bazaar.launchpad.net closed by remote host.
<lool> .....
<lool> .... but it still runs
<masterkorp> hello, how do i get the brevision number ?
<masterkorp> *revision
<masterkorp> of the repo
<lool> bzr revno
<lool> but it's per-branch, not per-repo
<masterkorp> lool: thnks i just want anything to help on packaging
 * lool goes out &
<Riddell> jelmer: you did bug 810701 in trunk, how come you milestoned it to 2.4 but didn't put it into 2.4?
<ubot5> Launchpad bug 810701 in Bazaar "i18n.install fails in fails some situations" [High,Fix released] https://launchpad.net/bugs/810701
<jelmer> Riddell: I don't recall, I suspect it was probably around the time the 2.4 branch was opened
<Riddell> jelmer: well this gives me a good opportunity to learn how to do backporting
<Riddell> how is backporting done?  merge request to 2.4 and pqm?
<jelmer> Riddell: yep, basically
<jelmer> Riddell: you'll need pqm commit access to 2.4
<Riddell> and that's different to trunk?
<jelmer> yep
<Riddell> how do I know if I have that?
<jelmer> try to submit something and see if you get back an error :)
<jelmer> otherwise, it should be trivial for jam or vila to submit it once the MP is up on Launchpad
 * vila nods
<vila> jelmer: alternatively mail rt to get this fixed ;)
<Riddell> "merge http://bazaar.launchpad.net/~jr/bzr/2.4-810701-lang-not-set http://bazaar.launchpad.net/~bzr-pqm/bzr/2.4 Command failed!"
<Riddell> guess I don't have permission then
<vila> where did you see that ?
<Riddell> in my e-mail
<vila> ha, ok
<Riddell> what is our magic secret rt address?
<Riddell> well hopefull that won't take a week to go through like it did last time
<vila> Riddell: I can submit it if you want
<Riddell> vila: I'd like to get it in, just to check I understand the process
<vila> Riddell: well, I just did
<vila> argh
<jelmer> if you're going to submit a RT anyway, can you mention me as well?
<Riddell> hah, you're too fast
<vila> Riddell: but once it has landed, you can still merge 2.4 into trunk and submit that
<Riddell> it's already in trunk
<vila> which is really part of the backport workflow
<vila> then merging will make sure noone else have to handle possible conflicts
<Riddell> jelmer: done
<Riddell> vila: so it should be merged to trunk even if it's already in trunk?
<vila> only if the initial proposal wasn't targeted at 2.4
<vila> i.e. if you backported by cherry-picking, conflicts can occur when merging
<Riddell> that's confusing
<vila> if you're the one handling *that* merge, the conflicts will be trivial to solve
<vila> Riddell: what is confusing ?
<vila> that the same change applied to two different branches can conflict ?
<Riddell> yes
<vila> well, backports generally involve slightly different changes
<vila> if the change is *exactly* the same, there should be no conflict
<Riddell> it's the same except for the release note
<vila> ha, then no conflict there obviously (but we try to avoid duplicating the news entries... which means targeting the lower possible series and merging up.. shudder)
<mgz> yeah, release notes/news tend to make life overly complicated
 * mgz fiddled with the bug entries a bit
<mgz> vila: good you mentioned the path-in-envvar thing in the meeting this morning, I wanted to ask you about that since the branch with the config env changes landed
<vila> right, I filed some bugs since then and I'm eagerly awaiting for your comments at least on bug #832028
<ubot5> Launchpad bug 832028 in Bazaar "environment variables are not decoded properly" [Medium,Confirmed] https://launchpad.net/bugs/832028
<mgz> cool, catching up on mail now, will leave comments as I go
<mgz> Riddell: who was it you were helping land a branch in here the other evening?
<mgz> ...I should just grep logs I guess
<mgz> ~weyrick
<Riddell> mgz: that's the one
<Riddell> GRiD
<AuroraBorealis> hello.
<AuroraBorealis> anyone here to help me understanding some of the bzr code base? :D
<jelmer> AuroraBorealis, hey
<jelmer> AuroraBorealis: Sure, ask away :)
<AuroraBorealis> so i'm trying my best to fix https://bugs.launchpad.net/bzr/+bug/81689, and Martin Pool was giving me some pointers to get started, and my first question is what are the TreeTransform classes?
<ubot5> Ubuntu bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed]
<AuroraBorealis> or rather a more general description of them then just "represent a tree transformation
<AuroraBorealis> also: i love how the bzr lazy import system makes pydev + eclipse go crazy.
 * jelmer looks a tthe bug
<jelmer> AuroraBorealis, the tree transform classes live in bzrlib/transform.py IIRC
<AuroraBorealis> yeah i'm looking at them
<jelmer> AuroraBorealis, they're the layer that's used for modifying trees on disk when creating a new checkout or applying a merge to a working tree
<AuroraBorealis> so, baiscally they are just classes that manipulate a tree in some way, either to merge or to write to disk?
<jelmer> AuroraBorealis, they're the infrastructure that's used by merge and the working tree construction code
<AuroraBorealis> ah ok
<jelmer> the merge/revert/checkout code lives on top of tree transform
<AuroraBorealis> cause the method where its throwing the 'can't create symlinks on windows" is in DiskTreeTransform, which i assume is just the class for creating a working tree on disk
<jelmer> AuroraBorealis: the tree transform code is generic - the same TreeTransform class is used to create files on disk as is used to apply the changes of a merge
<jelmer> At least that's my understanding of it - merge would use DiskTreeTransform too
<AuroraBorealis> ok, kinda makes sense
<AuroraBorealis> its also a bit confusing cause in transform.py they are using a lot of dictionaries and i'm nott sure what is used for what :>
<AuroraBorealis> but anyway, i think i know what place to fix it, but should i leave the "file kind" as symlink, or a file?
<jelmer> AuroraBorealis: I'm not sure, I'm not very familiar with the transform code
<jelmer> AuroraBorealis, the best thing to do would probably be to ask on the bug
<AuroraBorealis> i'll post there and mess around on my code, thanks =)
<AuroraBorealis> also, is there a file that lists what...gets called for each of bazaar's actions? like.. bzr add, checkout, merge, etc
<GRiD> hi mgz, did you need something? (re: Riddell helping me land the branch)
<davi_> is there a way to limit the number of revisions in dpush (bzr-git)? looking at the code, it seems it should be possible to pass a stop revision
<jelmer> davi_: Hi
<jelmer> davi_: yes, but I don't think dpush does what you want
<jelmer> davi_: dpush only supports incremental pushes since it changes the source branch
<jelmer> which is fine if you
<jelmer> 're contributing back to an upstream project that is in git
<jelmer> but it doesn't work for the situation where you're maintaining an independent mirror
<jelmer> it sounds like what you want is "proper" push support, which is bug 544776; that would also allow incremental pushing
<ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776
<davi_> jelmer, there won't be "contributing" back, just want to be able to keep some branch (in git) up to date with the upstream (in bzr). is there any problem in changing the source branch? it's a throw away branch any taken from the real upstream
<davi_> *anyway
<jelmer> davi_: If it changes the source branch then you won't be able to pull from bzr anymore, as the histories diverge
<davi_> jelmer, ah. in what what way it changes the source branch history?
<jelmer> davi_: dpush (and this is why it's a separate command, and not part of "bzr push") basically pushes all data that can natively be represented in git into the target branch, then reimports it into bzr
<davi_> jelmer, ah, i wasn't aware of the reimport part. thanks
<jelmer> davi_: you can prevent dpush from rewriting the source branch with the reimported data by using --no-rebase
<jelmer> davi_: but if you do that, then there is no shared history the next time you run dpush
<davi_> jelmer, ok, i should have read the help for dpush more carefully..
<jelmer> davi_: The roundtripping support (in other words, getting "bzr push" to work) is on my long term todo list.
<jelmer> davi_: In the mean time, I suspect bzr fast-export is probably the best alternative
<davi_> jelmer, yeah, saw that the bug report is in progress.
<davi_> jelmer, but one question, if there are two independent source branches, with round tripping, will both be able to push into the git repository? (like, one of the branches has fewer revisions than the other when compared to a upstream branch)
<jelmer> davi_: Yeah
<davi_> jelmer, ok, i shall wait then. thanks
<mgz> GRiD: no, sorry, just wanted to look at the branch as I was interested
<mgz> (I was thinking about a related kind of handling of large files previously and wanted to see how it compared)
<GRiD> mgz, oh ok. how does it compare? :)
<mgz> GRiD: the ui looks similar, which is good
<mgz> and I'm not sure the idea of treating large files as unversioned branch objects like tags is a good one, given the problems tags have run into
<mgz> (the basic idea was to, rather than ignore files larger than threshhold, stash a single copy so it can be branched, but not save all past versions)
<mgz> your branch avoids all the accidental pain without having to add a whole new store, which is a really good thing
<GRiD> ok. well it sounds like your idea had more sophisticated goals, where they knew the large file existed and they didn't want to deal with the overhead of a normal versioned file? this patch was really more on the order of saving people from accidentally committing their ISOs (or whatever)
<mgz> right.
<GRiD> i'd honestly be thrilled to hear this saved someone some pain, i'm not sure how much of a requested feature this really is. it was an old bug :)
<GRiD> (it was really intended as a way for me to jump in bzr hacking)
<GRiD> s/in/into
<mgz> I suspect you'll never hear that, but we'll have fewer reports of OOM or performance issues from people who have such mistakes at some point during their project history
<mgz> which *has* happened quite a lot, so it was a really good bug to tackle.
<GRiD> nod. cool, that's good to hear.
<GRiD> i'm currently taking suggestions on useful bugs to solve for my second effort ...
<mgz> ho ho ho.
<GRiD> ;)
<GRiD> i was looking at some of the performance bugs, since i enjoy working on that kind of thing. but i probably don't know the codebase well enough to dive in that far, yet.
<mgz> if you're up for a little investigation, how about bug 720853 for instance?
<ubot5> Launchpad bug 720853 in bzr search plugin "bzr crashed with RuntimeError in normpath(): maximum recursion depth exceeded while calling a Python object" [High,Confirmed] https://launchpad.net/bugs/720853
<mgz> repo involves a plugin, but the problem seems to be in a specific bit of bzrlib
<GRiD> ok sure, i'll take a look.
<poolie> hi all
#bzr 2011-08-24
<mgz> OOPS-2062AZ5 too late at night...
<mgz> Fourth time lucky, I wonder if putting "lp:" on the start of the prerequisite branch upset anything...
<lifeless> mgz: bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
<mgz> 77 results being the relevent thing? :)
<lifeless> no, there is one for +merge-proposal in there ;)
<mgz> bug 629087 looks likely.
<ubot5> Launchpad bug 629087 in Launchpad itself "Branch:+register-merge timeout submitting merge proposal" [Critical,Triaged] https://launchpad.net/bugs/629087
<lifeless> yeah thats the one
 * mgz metoos
<poolie> hi mgz, scottk
<ScottK> hello poolie.
<ScottK> poolie: It's gone midnight, so I'm about to go to bed, but what's up?
<poolie> just saying hi
<poolie> thanks for the suggestion
<poolie> about out of date branches
<ScottK> Ah.  OK.
<ScottK> Hello back poolie.
<AuroraBorealis> heya.
<AuroraBorealis> how do i tell what gets called when you pass commands to bzr? like, bzr add, checkout, merge, etc
<lifeless> AuroraBorealis: do you mean what python functions run?
<AuroraBorealis> yeah
<AuroraBorealis> i see the Command class and that you have to register
<AuroraBorealis> said commands but i dunno where that gets done o.o
<lifeless> for plugins during the plugins __init__
<lifeless> for core commands by being in builtins.py
<lifeless> or whatever the file is called :)
<AuroraBorealis> ah, thank you =)
* Topic unset by poolie on #bzr
<AuroraBorealis> oh gee.
* poolie 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: JAM
<vila> hi all !
<AuroraBorealis> hi...
<AuroraBorealis> where does the InventoryEntry object store its 'kind' variable?
<AuroraBorealis> i keep seeing it referenced but i never see it created, its not created in __init__ and ctrl+f shows its not created anywhere else in inventory.py..
<AuroraBorealis> never mind i'm stupid, its in the subclasses. although said methods are calling that variable in the super class so they would throw errors if you called said method on the superclass o.o
<ChrisCauser> Hi Everyone, quick question. I'm reading up a lot about why you shouldn't push a feature branch directly upstream. I was just wondering if there was a way to enforce non changing id numbers so the people I work with don't accidentally do this
<poolie> ChrisCauser: yes, set append_revisions_only
<ChrisCauser> Brilliant. Many thanks
<poolie> vila, so if you look at jam's recent get_parent_map work
<poolie> i think there's a constant in it which he did some empirical work to change
<vila> yup
<poolie> i think i suggested it could be configurable and he opted not to
<vila> indeed
<vila> for backport reasons
<poolie> mm
<vila> which is tangential but could become a concern if we never use new features by fearing backport issues, but that's not the main point here
<poolie> so, i don't think going back and changing it to be configurable, which would potentially close 832061, would be especially useful in itself
<vila> I trust jam's work on setting the "best" value here, but that doesn't mean that for some setups this value will be far from optimal
<poolie> sure
<vila> if we can't try new values, we'll never know
<vila> and if the code evolves and the best value is not the best anymore, we'll never know either
<jam> poolie: I also didn't want to introduce yet-another-read of something that doesn't-really-need-to-be-set
<poolie> right
<vila> and if this constant turns out to be easily tweaked based on some (for the sake of the example) branch history property, we can't tweak either
<poolie> so, basically
<vila> jam: right, that's a performance issue
<poolie> i like bugs that correspond to actual problems and where you can tell whether they're fixed or not
<poolie> if you find a way to tweak that constant, or to dynamically configure it to make things faster, that's great
<vila> well, not being able to diagnose whether a constant is good or bad *is* the problem I'm referring to
<jam> vila: so if it was something like "disable it completely" I would consider a config item. If it is just tweaking it, it really depends on how much effect it could have.
<jam> Since my experiments said "very little" outside of edge cases
<poolie> so, being able to change a thing when we don't have any actual reason to think we want to change it is Low
<poolie> there are a lot more important bugs than that
<vila> well, I won't ask you to extend your experiments to lp hosted code...
<jam> vila: so in *this particular* case, I did a fair amount of analysis and testing (a couple days at least) to know that the setting was not going to be very optimizable. I don't know that it applies in every case
<jam> vila: that was tested on lp hosted code
<vila> *all* lp hosted code
<jam> vila: I don't think we really care about the perf on lp:bzrtools as long as it is reasonable, and I tested against lp:gcc-linaro lp:mysql and lp:emacs
<poolie> so, vila, if you had a good reason to suspect that by further tweaking we could get a big improvement, i'd say go for it
<jam> I suppose I could do lp:launchpad
<jam> but I did try to do different types of histories, etc.
<poolie> but that doesn't seem to be where we are
<jam> Yes, this experiment could be done again in a year, etc. But honestly, unless someone is going to spend the time analyzing the results, it won't help much.
<vila> poolie: it's not about *me* it's about anybody willing to try with its *own* know code
<jam> And if they are doing that, they don't need a config setting
<vila> what do they need then ? Modifying the code ?
<jam> vila: sure, or a plugin that modifies the constant, or ...
<poolie> so if someone is going to tune this, it's probably pretty easy for them to make it configurable at that point
<jam> in the end, you need to write a script
<jam> and that can fairly easily get at what you need
<vila> or just a fix for bug #491196...
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196
<poolie> i think adding a command-line option is possibly the thing that would help them most
<poolie> right, i would say that is far in advance of going back and making every thing configurable
<poolie> i think too, many things that could be tuned don't want to be tuned by just changing an integer
<poolie> but possibly changing the algorithm, which is beyond what this can do
<vila> right, changing algorithms is better done via hooks
<vila> but hooks can also be configured
<poolie> or experimenting with an actual patch
<jam> vila: or you can write a plugin...
<jam> or monkey patch, or.
<jam> honestly, if someone wants to experiment with the code, I really don't see a huge difference from them playing with the *code*
<vila> jam: or set a command-line option, which one is the easiest for someone wanting to experiment without knowing the code base ?
<jam> vila: someone who wants to tweak this is going to need to know a whole lot more than a command line option
<jam> note *this*
<jam> Some other things would be good with a command line/environment var
<poolie> vila, a command line option would be great
<poolie> very nice for interactively testing config related stuff, aside from anything else.
<jam> vila: I agree that having a config item that can be set from a command line (env var, argument passed) is the easiest way to play with bulk behavior.
<jam> In this case, I think it is YAGNI.
<jam> You also want to avoid doing the whole fetch
<jam> so you need to hack the code anyway
<poolie> vila do you see what i mean about prefering 'know you're done when' bugs?
<jam> otherwise the 1-5min startup time is lost in the 30min transferring 600MB of data.
<poolie> vila do you see what i mean about prefering 'know you're done when' bugs, and why this isn't really one at the moment
<vila> poolie: yes, but we disagree on "it's done" :)
<poolie> when would it be done?
<vila> we had many cases in the past where one setting (let's just say 'encoding') wasn't properly found (for whatever reasons) and users were blocked because there was no way to override this setting
<poolie> yup
<poolie> i would certainly agree with that
<poolie> in fact i think i have filed a bug about that particular case, or at least someone has
<vila> If we can associate that kind of setting with a *config* setting, we can at least say: 'Look, we'll fix that in the latest stable series, in the mean time, just set it to x in this context)
<vila> I argue that whatever setting (constant or not) should be a config setting to cover these cases and I'd call it done when the know ones are
<poolie> yep
<poolie> if it names some specific things that aren't configurable but should be i'd be totally fine with the bug
<poolie> (bit questionable whether to have one bug or several but the simplest thing would be to start with one)
<poolie> perhaps better to fix the bugs that are already filed though
<vila> :)
<poolie> some of them, like fsenc, are nontrivial to change
<jam> vila: we've had code bugs in the past that we couldn't fix in the stable release. If we could write some python config values we could say "write this config and it will fix the bug for now".
<jam> oh, that is a plugin...
<jam> I'll agree that 'config' seems a little better than a plugin.
<jam> meaning "lighter for the user"
<vila> and doesn't require python knowledge
<vila> I argue that it it was that easy to write a plugin we'll have far more of them today
<jam> vila: but does require to know the config value to set
<jam> and if we have to give them something to use
<jam> we can give them the plugin
<vila> I'm not saying plugins are bad and should never be written, I'm saying that too few people can write them or even install them
<poolie> ok...
<vila> jam: look at bug #320593 and tell me how long the proposed plugin will work
<ubot5> Launchpad bug 320593 in Sedot "nggak bisa buat file rrd setelah ganti system" [Undecided,Fix released] https://launchpad.net/bugs/320593
<vila> shudder
<jam> vila: I'm arguing that the set.difference() between set(users_can_set_a_config_we_recommend).difference(set(users_that_can_install_a_plugin_we_recommend_on_a_bug)) is small
<vila> jam: look at bug #302593 and tell me how long the proposed plugin will work
<ubot5> Launchpad bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed] https://launchpad.net/bugs/302593
<poolie> jam, could you review or maybe finish off https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381 some time?
<jam> vila: longer than writing a config item for it
<jam> poolie: it is in my "in progress" queue
<jam> so yes
<poolie> cool thanks
<vila> jam: huh ? Turning a constant into a config item should be a one-liner (if you exclude the help which you need to write anyway)
<jam> vila: "Reading options for a branch from locations.conf fails with bzr+ssh "
<jam> are you sure you were on the right bug?
<poolie> vila, so
<poolie> let's see if i understand
<poolie> you think that generally speaking we should have configs-with-defaults rather than magic numbers
<vila> jam: https://bugs.launchpad.net/bzr/+bug/302593/+attachment/1157814/+files/fixLocationConfigForBzrSsh.py
<ubot5> Ubuntu bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed]
<vila> poolie: yes
<poolie> i agree with that, though i'd have some concern about the scalability of documentation if it includes lots of stuff most people should never change
<poolie> some of them should perhaps be debug flags with values
<jam> vila: but you could never fix that with a config change
<vila> poolie: which is bug #746993
<ubot5> Launchpad bug 746993 in Bazaar ""bzr help configuration" looks awful" [Medium,Confirmed] https://launchpad.net/bugs/746993
<poolie> iiuc you also think we should go back and look for all things that could potentially be config options and change them
<jam> so yes, the plugin is fragile, it works until you can upgrade to a newer release which has the bug fixed
<jam> and the failure is so large in scope that it is completely outside of "tweaking a config item"
<poolie> well, it goes beyond that, into perhaps having an 'internal' or 'hidden' class of options
<poolie> i don't think that's worth doing until there's actually a motivation to change them
<jam> poolie, vila: We've also falling into the trap in the past of having configurable settings that people can tweak, but not providing a good default.
<jam> because we stop at "ok, they can configure it"
<poolie> that's a risk too
<jam> and defaults really do matter
<vila> know risk
<vila> known risk, but I'm talking about the other end of the spectrum where there is *no* way to change it
<jam> vila: I feel we got a bit off on the wrong foot, though. I agree that *in general* I'd rather have something exposed to the user easily in case something goes wrong.
<jam> This particular case, the reward / benefit was not high enough.
<jam> When we have properly cached configs, that may change.
<poolie> cool
<vila> jam: pfew, thanks
<jam> vila: note that I was clear all along that *this case* was how I handled it.
<vila> jam: right, I never said you did wrong given the existing code base 1
<vila> I'm saying many problems we encountered *could* be far easier to address
<vila> poolie: yes, this may not be the first thing to work on *today* but I'd like us to keep it in mind and not punting every time
<poolie> ok, i just read https://bugs.launchpad.net/bzr/+bugs?field.tag=config
<vila> poolie: in that respect, I feel that 'low' is pretty close to 'wontfix'
<poolie> i think the ones that are High are plausibly high
<vila> well, those are the ones I filed yesterday (except for the first one), I didn't touch the others but I took them into account when writing the devnotes/configuration.txt
<jam> vila: the flip side of the argument is that you've spent a fair amount of time reworking the config stuff, which still isn't quite enough of a change, vs just fixing the bugs we run into that could have been easier with a better config system.
<jam> (limited human time and all that)
<jam> I really like where you are pushing config
<jam> I'm not sure if it was the optimal use of time
<poolie> jam, yeah, that's why i'm looking at that list
<poolie> perhaps vila can finish up the High bugs there and any that naturally fall out from doing it and then move on for a bit
<poolie> perhaps to udd
<vila> jam: my counter-argument to that is that I didn't spent that much CPU time on it considering the results and that we are now with two designs in flight and that is already a concern
<jam> vila: sure, I certainly think it has been started, it is in flight, we need a clear landing for it
<jam> as poolie said, a clear "it is done"
<jam> but I think you're at a point it can be ratcheted down
<jam> rather than a primary focus. Perhaps not
<vila> well, it's certainly not the only thing I'm working on and I fail to see which of the ~10 mps landed in the last 15 days is not on the cirtical path
<poolie> so, in <http://people.canonical.com/~mbp/kanban/vila-kanban.html> (which may be lossy)
<poolie> i see 7 for the last month, and 3 are config related (of which 1 is my fdatasync bug, and fairly serious) and 4 are test suite failures
<vila> poolie: yup, definitely lossy because  I didn't file bugs I was fixing (at the some time slicing the features doesn't match filing bugs in my mind but I can change that (which I started yesterday))
<poolie> anyhow, i think john and i are just keen to have config infrastructure and also to get your help on other things
<jam> vila: poke about https://code.launchpad.net/~vila/bzr/missing-stacks/+merge/71918
<jam> You said "Remote branches ignore bazaar.conf and locations.conf" care to clarify?
<jam> it sounds dangerously wrong
<jam> as locations.conf is provided as a way to *override* settings in branch.conf for remote items.
<jam> remote branches
<soren> Hi. I'm hoping someone can help me decipher this error message:
<soren> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/%2Bbranch/nova/" and relative path "../../../~soren/nova/trunk/"
<soren> It's in response to "bzr lp-propose-merge -m 'something'"
<soren> http://paste.ubuntu.com/673669/ is my ~/.bazaar/locations.conf
<soren> And I have *no* clue what ../../../~soren/nova/trunk/ is.
<soren> Oh. It's from Launchpad.
<soren> :-$
<poolie> hi
<vila> "it sounds dangerously wrong", see revno 5999, I'm not introducing that
<poolie> oh, so i think your parent_branch config setting is wonky
<vila> jam: "it sounds dangerously wrong", see revno 5999, I'm not introducing that
<poolie> hm, or, which branch are you trying to propose?
<vila> jam: I'm just formalizing the existing code
<poolie> soren, basically what's happening is that bzr is trying to infer which branch you intend to merge into, and getting an apparently impossible path
<soren> poolie: Can you try this, please:
<soren> poolie: bzr info lp:nova
<jam> vila: that was *only* for reading *just* branch.conf to get the stacking location
<soren> Just for shits and giggles.
<jam> not *all* settings
<jam> if that's what you've done, great.
<soren> poolie: ...because I get that error doing that as well. ~soren/nova/trunk is something that only ever existed on Launchpad.
<soren> poolie: Hang on, I'll post the .bzr.log.
<jam> (we no longer support using locations.conf to override a stacked location, but we still support it for everything else)
<vila> jam: it's not used yet but the plan is to use it only for this case if that's possible
<vila> jam: and neither do we for default_stacking_on if I understand correctly
<soren> poolie: http://paste.openstack.org/show/2269/
<jam> vila: I think you're right about default_stacking_on but I have limited experience with it.
<soren> poolie: It seems to get the ~soren/nova/trunk bit back from lp (no clue why, though) and tries to make sense of it locally.
<soren> poolie: Or rather, ../../../~soren/nova/trunk which makes even less sense to me.
<vila> jam: but thanks for the poke, I'll double-check (now that you mentioned it, I may have fall into a trap with that)
<soren> poolie: This happens even if I explicitly specify the target branch.
<poolie> vila, can he fix this with bzr config to update the branch conf?
<vila> jam: which in retrospect was my main concern with revno 5999 (even if I didn't make a funny face at the time ;)
<soren> poolie: ..and with an empty locations.conf as well, apparently.
<vila> poolie: in theory yes, in practice there may be bugs with remote branches
<vila> ... they should be filed and fixed of course ;)
<poolie> soren, did you perhaps rename this branch from something else to be the trunk?
<jam> soren: it is a setting in .bzr/branch/branch.conf which is saying that the "parent" branch is ../../../~soren/...
<jam> I'm not sure why we need the parent
<jam> ah, lp-propose is failing
<jam> because it is trying to auto-detect what branch you want to target
<poolie> yes, that's what i said :)
<soren> jam: .bzr/branch/branch.conf:  http://paste.ubuntu.com/673676/
<jam> poolie: yeah, your statements were intermixed around when I was chatting with vila, so I missed bits
<jam> silly conversation threading
<poolie> soren i think 'bzr config -d lp:nova --remove parent_location' should fix it
<soren> poolie: Nope.
<soren> poolie: I haven't referred to anything as trunk in over a year.
<jam> soren: it is the remote one that is probably the issues
<jam> issue
<soren> I'm happy to try it, but:
<soren> http://paste.ubuntu.com/673682/
<vila> I suspect we have been propagating parent_location from local to remote branches in the past (and we may still do so)
<jam> soren: the small issue is that launchpad changed how you access branches, from always being 3-parts (~user/project/branch) to sometimes just +branch/project
<soren> There's no reference to anything called trunk.
<jam> soren: the issue is lp:nova
<soren> ~soren/nova/trunk was abandonded well over a year ago.
<soren> jam: Oh.
<jam> soren: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf
<soren> jam: That makes even less sense to me:
 * vila pesters about not being able to decipher  /+branch-id/362222
<soren> http://paste.ubuntu.com/673683/
<soren> jam: Oh, dear.
<soren> jam: That is so wrong.
<jam> soren: I'm guessing you created the branch by branching from soren all those years ago
<soren> jam: Yes, that's entirely likely.
<jam> soren: what version of bzr are you using?
<soren> Now?
<soren> Bazaar (bzr) 2.4.0
<jam> soren: bzr config -d lp:nova "parent_location="
<soren> I can't.
<jam> should get rid of that setting
<soren> I'm not ~hudson-openstack.
<jam> ugh
<soren> ...but I guess I could become him.
<jam> soren: we can get a sys-admin to do it if you can't
<jam> but it takes a while
 * soren does so while whistling innocently.
<poolie> you're asking a sysadmin?
<vila> I think he's becoming ~hudson-openstack and can't answer from there ;)
<jam> poolie: soren is doing it himself
<jam> well, at least for now
<poolie> oh, really
<jam> if he comes back saying it doesn't work, i'll contact a losa
<jam> poolie: it sounds like ~hudson-openstack is a bot
<jam> (hudson and all that)
<poolie> yeah
 * vila scratches head...
<soren> I'm battling this right now: Unable to copy ownership from "/var/lib/jenkins/.bazaar" to "/var/lib/jenkins/.bazaar/locations.conf". You may want to set it manually.
<soren> GImme a minute.
<vila> launchpad redirects lp:nova to https://code.launchpad.net/~hudson-openstack/nova/trunk but 'bzr config -d<xx>' doen't give the same result
<soren> What does this mean for me?
<soren> uark!
<soren> http://paste.ubuntu.com/673691/
<soren> That can't be good.
<poolie> vila ^^ ?
<soren> lp-propose-merge does seem to be happier, though.
<vila> poolie: wow, that is so wrong, lp urls are not even supposed to be supported... 'lp:novalp:nova' ... is wrong too but
<vila> and bug #832653 filed anyway
<ubot5> Launchpad bug 832653 in Bazaar "bzr config -d lp:nova gives unexpected results" [Medium,Confirmed] https://launchpad.net/bugs/832653
<vila> soren: what's your 'bzr config' output in the branch you ran lp-propose ?
<soren> vila: http://paste.ubuntu.com/673692/
<jam> soren: still looks wrong here: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf
<soren> Yes, ti does.
<soren> it, even.
<vila> soren: so you're not under /home/soren/src/openstack/nova ?
<soren> vila: I am.
<soren> vila: Oh, sorry.
<vila> meh
<vila> ha
<jam> soren: sftp bazaar.launchpad.net ; cd ~hudson-openstack/nova/trunk/.bzr/branch; rm branch.conf
<soren> 10:02 < soren> poolie: ..and with an empty locations.conf as well, apparently.
<soren> vila: I cleared out locations.conf to see if that was causing it.
<vila> ha, ok, empty locations.conf was the missing bit
<jam> soren: though you can continue helping vila debug remote config issues if you want.
<vila> soren: keep in mind that locations.conf *overrides* branch.conf (but seem to act as a default value provider)
<soren> vila: Wow, really?
<soren> That's... wow.
<soren> Ok.
<soren> Is that by design?
<jam> soren: Users have access to locations.conf
<jam> but may not have access to branch.conf
<soren> How can they not have access to branch.conf?
<jam> soren: You can't write to *my* branch.conf
<jam> though you may read it when branching from me
<jam> so locations.conf was designed as a way to override settings for your personal use
<jam> but also grew globs
<vila> soren: see bug #832046
<ubot5> Launchpad bug 832046 in Bazaar "needs a way to specify default values for config options by path" [High,Confirmed] https://launchpad.net/bugs/832046
<jam> which meant that it started providing defaults as well as overrides
<soren> Fascinating.
<jam> which makes things messy
<jam> you need 3 layers, basically
<soren> Defaults, branch, overrides.
<jam> defaults get overridden by branch local config gets overriden by user specified overriedss
<soren> Right.
<soren> That lp:novalp:nova thing... Is that going to cause troupble?
<soren> Or trouble?
<vila> tyops welcome ;)
<fullermd> Rule 1: You always need 1 level more than you have.  Rule 2: The cognitive load limit is always 1 level less than you have    :p
<soren> vila: "tyops"?
<soren> vila: Oh. typos :)
<vila> well, I would be surprised if it applies to lp:nova urls anyway since urls are supposed to be translated already when dealing with locations.conf
<soren> vila: orly?
<vila> soren: yeah, I do less tyops once I invoked the tyop god
<vila> only
<vila> but it doesn't work everytime
<fullermd> Well, maybe this time dog will simile on you.
<vila> fullermd: smile ?
<poolie> pqm might be having trouble?
<poolie> i've asked the sysadmins
<vila> jam: wow, you sent https://code.launchpad.net/~vila/bzr/824513-fadatasync-options/+merge/72454 to pqm *after* I did (lp is misleading, I did the send after the push)
<vila> jam: still I didn't get any answer, did you ?
<jam> vila: I was trying to submit one of mine, I just read the proposal wrong and submitted yours
<vila> poolie: blackbox.test_branch.TestBranch.test_branch_broken_pack FAIL is spurious, dunno if we have a bug for that though
<jelmer> we do
<poolie> yes it's broken; will be fixed soon
<poolie> o/ jelmer
<jelmer> hey poolie :)
<vila> jam: ha, ok, still did you get an answer or is indeed pqm borken, ha right
<vila> jelmer: hey !
<poolie> can you guys re-feed them if necessary when the paper jam is cleared?
<jam> vila: I didn't get any response and the web page is "0 scripts" for me
<jam> poolie: certainly
<vila> jam: ok, same here
<jam> want us to resubmit your "trivial" as well?
<poolie> yes thanks, i have two or three approved
<poolie> i have 10 assigned bugs and i think all but one or two are blocked
<jam> poolie: in what channel did you ask the sysadmins? (Just trying to follow the thread)
<jelmer> jam: #is
<poolie> #is
<jam> poolie, jelmer: Are we doing the udd standup in 5 min?
<poolie> no, it's on holiday for augest
<poolie> *august
<jam> ah, ok
<poolie> afaik
<mgz> afternoon all.
 * jelmer waves to mgz
<vila> mgz: _o/
<poolie> hi mgz
 * poolie fixes a package import, yay
<poolie> hm, bug 832052 is interesting, if it was hit on 2.4.0
<ubot5> Launchpad bug 832052 in bzr (Ubuntu) "bzr crashed with ShortReadvError in _seek_and_read(): readv() read 0 bytes rather than 174 bytes at 0 for "469df00e67f848246f876663fb299e10.rix" (dup-of: 413430)" [Undecided,New] https://launchpad.net/bugs/832052
<ubot5> Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/413430
<poolie> which should have fdatasync on
<jelmer> Riddell: thanks for backporting that i18n fix!
<Riddell> jelmer: the rt got a reply so we should have access to PQM's 2.4 now
<jelmer> Riddell: that was quick
<mgz> jam: ping
<jam> hi mgz, I was wondering when you would show up
<mgz> ha, we were both waiting for each other to say something first?
<jam> I guess so
<Riddell> anybody object if I just turn on translations for the bzr project in launchpad?  I don't see a reason why not
<vila> Riddell: +1 (I thought it has been done :-/)
<jelmer> Riddell: go for it
<vila> Riddell: what series will be impacted ?
<Riddell> that's the next question, do we want to point people at 2.4 or trunk
<jelmer> Riddell: perhaps have it export to a different branch rather than directly to trunk
<jelmer> Riddell: does 2.4 have enough support for translations for translations to actually be usable?
<vila> Riddell: if there is a way to point to trunk-only first that will allow us to debug the fallouts
<Riddell> jelmer: yes, for most of the command help text
<vila> jelmer: only command helps IIRC, so testable but not that useful
<jelmer> I'd prefer targetting trunk in that case; we don't know what other fallout there may be from translations
<Riddell> jelmer: what's your worry about exporting to trunk?
<jelmer> Riddell: worried about a bot committing directly to one of our branches (and perhaps conflicts with pqm)
<Riddell> yep
<Riddell> lp:bzr-translations-export ?
<Riddell> I wonder who should own it
<Riddell> ~bzr-core I guess
<jelmer> Riddell: does it have to be a new project?
<Riddell> jelmer: no, I've set it to lp:~bzr-core/bzr/bzr-translations-export
<jelmer> Riddell: cool
<RenatoSilva> is there a lp plugin command for listing all branches of a project or your junk?
<jelmer> RenatoSilva: I believe someone wrote one, but I'm not sure where you can find it
<RenatoSilva> well, in the lp plugin, no?
<RenatoSilva> a separate lp plugin? ok
<jelmer> RenatoSilva: there isn't anything in the standard lp plugin
<jelmer> though I think it would be an appropriate place for it
<RenatoSilva> ok thanks jelmer
<vila> jelmer: on jubany, there are uncommitted changes to plugins/builddeb and we miss 41 revisions from  lp:builddeb
<vila> jelmer: shouldn't we at least update a bit ?
<jelmer> vila: I have to admit, I've never looked at the bzr-builddeb on jubany
<jelmer> what are the uncommitted changes?
<vila> jelmer: (the uncommitted changes comment out installing the debian changelog merge hook)
<jelmer> that sounds reasonable
<vila> jelmer: and the revno on jubany is 566 (607 on trunk)
<vila> jelmer: what ? Not installing the hook ?
<jelmer> with regard to updating, I think it's a good idea but it would probably need some testing with current udd
<jelmer> vila: yeah, the previous hook didn't very wekll
<jelmer> *well
<vila> work well , got that ;)
<vila> weird, I thought spiv was happy with it... I should have miss some episodes
<vila> jelmer: what kind of testing ?
<jelmer> vila: Spiv added a new changelog merge hook
<jelmer> vila: but I'm pretty sure that was after r566
<vila> jelmer: ha ! So it may be worth re-trying the new one right ?
<vila> jelmer: yeah, looks like revno 596
<jelmer> vila: some internal APIs in bzr-builddeb have changed that udd might rely on
<vila> hmm
<jam> jelmer, vila: Didn't we switch to the system installed versions? Or was that for python-debian?
<vila> python-debian
<vila> jelmer: devscripts is not installed on jubany but you said 'Add dependency on devscripts >= 2.10.59, required now that 'dch --
<vila>     package' is used. LP: #783122' does that apply to jubany ?
<vila> ha, crap
<vila> jelmer: by internals API you meant DistributionBranch ?
<jelmer> vila: that would apply for the changelog merger
<jelmer> vila: though I'm surprised the changelog merger matters at all for jubany - where is that used?
<jelmer> vila: yep
<vila> the devscripts dep you mean ? It seems to require dpkg-dev instead but that one is installed
<vila> jelmer: so for DistributionBranch, udd doesn't use kwargs so an update is probably required and also probably in lock-step with bzr-builddeb update :-/
<vila> ok, harder than I thought, I'll file a bug
<vila> bug #833097
<ubot5> Launchpad bug 833097 in Ubuntu Distributed Development "bzr-builddeb needs to be updated on jubany" [High,Confirmed] https://launchpad.net/bugs/833097
<gdoubleu> I'm seeing odd behavior trying to push to an svn repo: I make a change, commit it, and the dpush.  A commit gets recorded in the svn repo but it is empty, and my working tree returns to the state prior to the commit (i.e. bzr st/diff shows the file/change I had previously committed).  Any ideas?
<gdoubleu> this is with bzr 2.4.0 and bzr-svn 1.1.0dev
<gdoubleu> I tried a fresh branch of the svn repo, but seeing the same behavior
<jelmer> gdoubleu: this is bug 826946
<ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/826946
<gdoubleu> ah, I searched for push and missed this one
<jelmer> gdoubleu: are you using http as well?>
<gdoubleu> well, https
<jelmer> this is actually the bug that is blocking the 1.1.0 release
<gdoubleu> jelmer, is there a previous, working version of bzr-svn that's still compatible with bzr 2.4.0?
<jelmer> gdoubleu: one of the earlier snapshots of lp:bzr-svn, but I'm not sure which one
<gdoubleu> jelmer, fwiw using bzr-svn at revspec date:2011-07-01 works here
<yofel> hey, is there are reason why bzr dailydeb substitutes {date} while fetching the source from bzr? Thanks to that it downloads the source every day I run it even if I already fetched the source already
<jelmer> yofel: not sure I follow - if you don't want the date in there, why not use e.g. {revno} ?
<yofel> jelmer: no, I want the date in there. What I wonder is why if I have '2+git{date}+r{revno}-{revno:packaging}' as version in the recipe. bzr dailydeb makes a stacked branch in like 'work/kdelibs-2+git20110824+r{revno}-{revno:packaging}' when building
<yofel> why doesn't it leave {date} unsubstituted?
<yofel> like that I need to fetch the branch every day
<jelmer> yofel: it rebuilds if the version changes
<jelmer> yofel: and the date changes every day :)
<jelmer> it sounds like you want {revdate}, which is the latest bzr-builder that hasn't yet been deployed to lp
<yofel> jelmer: this is running bzr builder by hand - not on launchpad
<yofel> since I still need to upload some by hand
<jelmer> https://bugs.launchpad.net/bzr-builder/+bug/793072
<ubot5> Ubuntu bug 793072 in bzr-builder "Provide deb-version variables for revision commit time/date" [Medium,Fix released]
<yofel> well, revdate would probably help - if it doesn't substitute it at branch time
<jelmer> yofel: are you running 0.7.1?
<yofel> hm, no, my server is on natty - so 0.6. Did that get fixed?
<jelmer> yofel: no, {date} is still generated at branch construction time
<jelmer> s/generated/expanded/
<jelmer> yofel: on launchpad these directories always get discarded so it doesn't really matter
<jelmer> yofel: you're welcome to file a bug, and I'll see how hard it is to fix
<yofel> ok, I've got plenty of bandwidth myself, so it's not serious. Was just wondering why I have to download a few hundred MBs every day if I already have the branches on disk
<jelmer> yofel: have you considered running it inside of a shared repository?
<yofel> what's a shared repository? ^^
<jelmer> yofel: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<yofel> k, thanks for the pointer
<poolie> hi all
<jelmer> poolie!
<poolie> hi there
<poolie> that is good news about mrevell
#bzr 2011-08-25
<vila> hi all
<maxb> jelmer: You reviewed https://code.launchpad.net/~maxb/bzr/fix-meliae-feature-use/+merge/72353 as "Needs Fixing" without an explanation?
<vila> maxb: on natty, with the bzr ppa in sources.list, bzr-2.4.0 is not proposed. If I try to force its installation, I'm told bzrtools and qbzr should be removed
<vila> maxb: is it because we need new versions for bzrtools and qbzr in the ppa ?
<jam> hi all
<nyuszika7h> Hi
<vila> jam: hey
<maxb> vila: err... I can't reproduce that
 * vila blinks
<vila> maxb: any idea on how I could debug it ?
<maxb> try 'apt-cache policy bzr bzrtools qbzr', and see if anything seems unexpected
<vila> yup, was going down that route and: http://paste.ubuntu.com/674389/
<vila> maybe I should just force the installation of bzr and bzrtools and be done
<maxb> ah, you have apt pins you've forgotten about :-)
<maxb> See /etc/apt/preferences
<vila> oooh, -updates preferred over ppa ?
<maxb> evidently
<vila> ok :)
<vila> So, what are the possibilities here ? Add a pin-priority for ppa ? Move apt/preferences out of the way during the upate ? Just force bzr install ?
<maxb> Well, why do you have an /etc/apt/preferences at all?
<vila> hehe, right, I was there indeed, I used to need it to be able to test -proposed but I don't need it anymore
<vila> maxb: solved, thanks
<poolie> hi jam, maxb, vila
<vila> poolie: hey
<poolie> hi there
<jelmer> hi jam, maxb, poolie, vila
<vila> jelmer: hey
<maxb> morning all :-)
<maxb> jelmer: Could you clarify your "Needs Fixing" on https://code.launchpad.net/~maxb/bzr/fix-meliae-feature-use/+merge/72353 ?
<jelmer> maxb: That was in response to jam's comments, I hadn't seen you had updated the code already
<jelmer> maxb: now approved
<maxb> I thought it most likely was - thanks
<poolie> no jam yet?
<jelmer> he was here earlier this morning
<vila> he's often lunching around  this time of day
<poolie> i always forget you guys are a bit closer than i expect, at least at this time of year
<vila> poolie: funnily enough, I feel the same with you :) I often think: "Damn, still awake ???" before checking your tZ ;)
<poolie> i should stop soon
<poolie> it's 8 here
<deni> hi all
<deni> anyone have any idea how to change the default permissions bzr uses when someone does a push to a local repo
<deni> *local=remote
<Riddell> deni: the files just get written by the receiving sever (ssh or apache or bzr smart server etc) so it just depends on who that server is running as
<deni> Riddell: i use bzr+ssh
<deni> to push to a remote repo
<poolie> hi deni, riddell
<deni> but the permissions are not set accoiring to the defualt umask
<deni> *according
<deni> i have a shared repo .... that need to be g+w
<deni> so i set the default umask to 007....
<deni> so all the files and folders are created with the g+w permission
<deni> bzr seems to disregard that
<deni> cause when i push a newly created local repo on to the remote host it creates the folder with g-w permissions
<jelmer> deni: bzr doesn't track modes, just the exectutable bit
<deni> i've searched a little bit on the net and this seems to be a bzr bug
<deni> jelmer: what do you mean by doesn't track modes?
<jelmer> deni: sorry, I was misunderstanding your question.
<poolie> yes there is a bug for this
<deni> poolie: do you know what the status is for this?
<deni> or if there are any workarounds
<poolie> so first off, are you sure the umask is actually set when the remote bzr shell starts?
<poolie> eg if you do 'ssh myhost mkdir foo'
<poolie> does foo end up with the intended permissions?
<deni> poolie: yes i've tested creating files and folders over ssh and it respects the default umask
<poolie> deni, and doesn't it at least inherit the permissions from the repository directory?
<deni> poolie: here's the scenario
<deni> i create a local repo....do some work....and i decide i want to push this repo onto a remote host so that others can access it and so i can have a backup if my hard drive fails
<deni> i do a push
<deni> the repo is created with the screwed up permissions...
<deni> i have to go ssh onto the remote host
<deni> do a chmod -R
<deni> and after that everything works fine
<deni> but i don't wan't to have to do this every time we create a new project
<poolie> yeah i can understand that
<poolie> it's https://bugs.launchpad.net/bzr/+bug/394559
<ubot5> Ubuntu bug 394559 in Bazaar "want a config option to specify permissions" [Medium,Confirmed]
<deni> i assume i could ssh first and create the folder manually and then do a push and that the permissions would be perserved but that's not the best solution either
<deni> actually that's no different from having to do a chmod
<deni> poolie: i think it has more to with this one https://bugs.launchpad.net/bzr/+bug/50568
<ubot5> Ubuntu bug 50568 in Bazaar "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]
<deni> it's from 2006 and still not solved???
<poolie> that's sftp specific
<poolie> but it has a workaround
<deni> poolie: you mean ACLs?
<deni> seems kind of an overkill for something like this
<poolie> or i believe bzr+ssh will not reset the setgid bit
<deni> still
<deni> that's no different than doing a chmod
<deni> hmm
<deni> no wait
<deni> i'll test that right now
<deni> poolie: it doesn't seem to work
<deni> bzr+ssh screws things up again
<deni> regardless
<poolie> deni, isn't it inheriting them from the containing directory?
<deni> poolie: it appears not
<poolie> hm
<poolie> that's really pretty strange
<deni> i'd say so
<deni> the sitcy bit doesn't do anything other than make it so that the files created in that directory belong to the same group regardless of who creates it
<deni> that doesn't help me much cause bzr users already all belong to the same group
<deni> bzr doesn't change the group or anything like that
<deni> it just doesn't preserve the write permissions that the parrent directory does have
<deni> i don't see how the sitcky bit would help in this situation at all
<poolie> where did the sticky bit even come in to this?
<deni> sorry my bad....i was talking about setdit
<deni> *setgid
<deni> it kinda goes along with the sticky bit so i was thinking about one and talking about the other
<deni> anyway..i tried setting g+s but like i said all that does is make it so that all the files created in my /bzr folder have the same group as the bzr folder
<deni> that does not help at all since the bzr users are already in the same group
<deni> setgid does not preserve the g+w option
<vila> deni: what does 'ssh myhost umask' says ?
<dpi_> hi
<dpi_> can any1 here help me with a bzr problem on Win7 64 ?
<dpi_> plz ?
<vila> deni: just checking, I've been confused in the past about profile files executed or not depending on the way you connect and what command you run, bzr+ssh doesn't start a shell by default so very little is set (unlike when you start a remote shell)
<vila> in other news the babune windows salve reports 105 new failures since revno 6076..6082
<vila> slave
<poolie> ok good night all
<vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-windows/503/
<vila> poolie: g'night !
<nigelb> gosh, I need to stop hilighting my last name, I end up getting pinged for babune :)
<vila> nigelb: soory about that ;)
<nigelb> heh
<jelmer> g'night poolie
<jelmer> Riddell: reviewed i18n-install
<Riddell> a hat trick of approvals, that should keep PQM busy for the next day
<deni> vila: tnx for the info....so bzr+ssh ignores the /etc/profile file
<deni> is there any way around that?
<vila> well, *ssh* does
<deni> so how do you explain the fact that it ignores the umask settings?
<deni> i'm getting all kinds of mixed information
<dpi_> so far, I tracked the problem to pageant and bazaar ... any1 can help me please ?
<vila> so roughly you need to execute the right command which can be achieved either setting bzr_remote_path or tweak your authorized_keys file to execute a wrapper
<jelmer> Riddell: btw, would now be a good time to ask for translations on the mailing list, or do you want to wait with that?
<Riddell> jelmer: it needs to wait at least until launchpad has done the import
<Riddell> but I'd also like to look at topic help and other translations first
<Riddell> we need to consider adding string freezes to our release schedule
<jelmer> Riddell: ah, fair enough
<jelmer> Riddell: perhaps around the same time we do the API freeze ?
<vila> deni: AIUI, *sftp* tweak the group bits, ssh now, it depends on what you ask it to execute (which is often hard to get right)
<Riddell> jelmer: when is that done?
<dpi_> okay, so either I'm mute or no one even cares to say "no, sorry, cannot help"...
<vila> last beta for a series freezes the API
<jelmer> dpi_: Hi
<jelmer> dpi_: Sorry, I don't really have much experience with Bazaar on Windows.
<dpi_> hi Jelmer, thanks I was starting to wonder if I was muted
<dpi_> ;)
<deni> vila: the bottom line is that neither sftp now ssh work the way they should
<dpi_> no problem, thanks for answering
<deni> i think that the best thing i can do is wait for the bug to get fixed....
<deni> or try and look into it myself
<deni> i don't want to fiddle aroung with workarounds that complicate things and confuse everything even more
<vila> deni: well, AIUI, the most used setup is a server with a *single* user and an authorized_keys file so the issue you're encountering doesn't impact enough people to gather the energy to fix it :-}
<deni> vila: ???? i think you got it very wrong....or you a making a joke
<vila> deni: I've heard people using chmod and they seem to be happy with it, I guess it depends on how often you need to do it
<deni> how do you think people colaborate if not via a shared server?
<dpi_> ok, bye people
<vila> deni: I'm just stating what I've heard here and from the bugs
<vila> deni: no, I'm saying you can setup the server with a single user that everybody connect to
<deni> this issues impacts every user of bazaar
<deni> like every single one of them
<vila> deni: like, not at all
<deni> if they are working in some kind of team
<vila> deni: launchpad uses bzr+ssh and there is no need for the sticky group bit
<deni> vila: oh, ok...sorry i missed that in you statement somehow
<deni> but the fact to use a single user for working with bazaar is apsurd
<deni> what's the purpose a multiuser system then
<vila> deni: the only known issue is indeed the group sticky bit, but AFAIK from the bzr code base, the umask is obeyed
<deni> launchapd is a different story alltogether
<deni> vila: nope....it's not just the issue with the group bit....that was just a workaroung
<vila> deni: most people prefer to maintain a *single* authorized_keys file than a bunch of users
<deni> the fact is that the umask is NOT obeyed
<deni> that's the whole problem
<vila> deni: well, bzr internally uses the python chmod which, AFAIK, obeys umask
<deni> that makes absolutely no sense to me..... i have a machine on which there are many users.... all are in the same group...say development....
<vila> deni: I understand the setup, I'm just saying it's not the most used
<deni> i disagree
<deni> i think we are gonna have to agree to disagree on this one
<jelmer> Riddell: I think it's 4 weeks before the final release
<vila> deni: right, looks like I started on the wrong foot, let's restart, what does 'ssh myhost umask' says in your case ?
<Lo-lan-do> Hi all :-)
<vila> Riddell: yup, as jelmer says, 4 weeks before final release (i.e. last beta which also freezes the API so plugin authors can do their releases for the series)
<jelmer> hi Lo-lan-do
<Lo-lan-do> jelmer: I think I've hit a bug in bzr-svn.  Before I report it formally, is there any more info needed beyond what's at http://pastebin.com/bS2yBghd ?
<vila> Riddell: by the way, will it be possible to add more translations for minor releases (or is it not the way it works) ?
<jelmer> Lo-lan-do: looks like bug 826946
<ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/826946
<jelmer> Lo-lan-do: what version of bzr-svn are you using?
<Lo-lan-do> jelmer: 1.1.0~bzr3767-1
<Lo-lan-do> jelmer: Not quite 826946: I get a traceback, and the commit fails, and I'm on svn+ssh://
<Lo-lan-do> (But I've encountered something very like 826946 on an svn+https:// repo too, some time ago)
<jelmer> Lo-lan-do: does that particular file exist if you look with "svn log -v" ?
<Lo-lan-do> Not at the revision mentioned.  It's been renamed to fusionforge.pot about 3000 revisions ago.
<Lo-lan-do> (a bit before the Branch_5_1 was forked from the trunk)
<jelmer> Lo-lan-do: please file a bug
<jelmer> I'm about to fix bug 826946 and then release 1.1.0; hopefully the fix for that one can make it into 1.1.1
<ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "commits to http repository are empty" [Critical,In progress] https://launchpad.net/bugs/826946
<Lo-lan-do> Okay.
<Lo-lan-do> Thanks :-)
<deni> vila: sorry i went away for a while... anyway....umask is set to 007
<deni> i've made some progress btw
<deni> u can make sftp use specific umask by setting so in the sshd_config....
<deni> that affects only sftp though.....if i want to cover sftp, scp and ssh you have to use pam
<deni> so i've set up 007 umask for ssh as well
<deni> vila: now it works fine with bzr because like you said bzr+ssh doesn't execute bash and therefore does not read the settings in /etc/profile
<deni> but setting this up in pam fixed the problem
<vila> deni: \o/
<deni> sort of anyway....now i'm stuck with all users having the default umask 007 which is not that great...
<deni> to have new files in your home directory created with those permissions
<deni> the good part is that the users ~/.profile or .bashrc file can override these settings
<deni> if needed
<vila> right, so the issue (AIUI) with *sftp* is that the bits we send are dropped by the server
<vila> for ssh, it's still unclear to me where exactly the problem appears
<deni> ssh did the same thing as well
<deni> dropped the bits
<vila> one trick would be to set bzr_remote_path to a wrapper that set the umask as you see fit *before* calling 'bzr serve'
<deni> yep...
<deni> several work arounds come to mind
<deni> i've learned quite a few things about umask, sftp, ssh and pam so far :)
<deni> that i dind't know before
<deni> the whole setup seems a little messy but hey :)
<vila> great, if you could add this pieces of wisdom to the bug report, that would be awesome :)
<deni> sure thing
<vila> thanks !
<vila> deni: just to make sure I understood: you're saying that the group bits are dropped by the sftp server and that the profile is not taken into account when executing 'bzr serve' remotely ?
<jelmer> the latter seems reasonable, isn't profile just for login shells?
<vila> yup, just making sure I understand what tricked the unsuspecting users
<Lo-lan-do> Is there a way to tell bzr to use some specific options for ssh?
<Lo-lan-do> (I'm looking for options not in ~/.ssh_config, because I want to have them only for when bzr invokes ssh and not in the general case)
<deni> vila: yeah i know, we established that already :)
<vila> Lo-lan-do: from memory, because we support different ssh implementations, there is no way to specify options
<deni> vila: ups....wrong channel sorry for the highlight
<Lo-lan-do> Ah, I guess BZR_SSH would be it.
<vila> Lo-lan-do: not even -vvv which will make connection issues debugging so much easier :-/
<deni> vila: i've posted the info on the bug btw
<vila> deni: thanks !
<vila> Lo-lan-do: BZR_SSH only specify the shh client, but may be you can use a wrapper and inject options ?
<deni> if i find out more i'll be sure to post.... although i don't think i'll come up with something better....atleast not without looking at the bzr code
<vila> deni: where you'll find that we use chmod(0755) by default hence the bug about making it configurable
<deni> vila:  :)
<Lo-lan-do> Actually, it seems the option I wanted to pass is already used by bzr so I don't really need it :-)
<Lo-lan-do> (I was looking for ControlMaster=no or some equivalent)
<smoser> is it trivial for someone to kick the importer for http://package-import.ubuntu.com/status/qemu-kvm.html#2011-05-16%2017:12:45.463425 ?
<smoser> is it ever trivial to kick the importer to get a package branch fixed?
<jelmer> occasionally
<jelmer> vila, maxb: ^ Does either of you know what's up with that one?
<vila> not without digging but shooting in the dark:
<vila> we've fixed some inconsistent delta bugs for 2.4
<vila> so I'd rather update jubany to 2.4 ?
<vila> jelmer: regarding bug #833097, does http://paste.ubuntu.com/674549/ looks like the kind of fallout from the API change ?
<ubot5> Launchpad bug 833097 in Ubuntu Distributed Development "bzr-builddeb needs to be updated on jubany" [High,Confirmed] https://launchpad.net/bugs/833097
<vila> others may be needed, I just want a quick go/no-go
<vila> not a review ;)
<vila> (yet)
<jelmer> vila: yeah, looks like it
<vila> k, thanks
 * jelmer backports bzr 2.4 to python2.5
<vila> jelmer: err, jubany has python 2.6 already, what do I miss ?
<jelmer> some buildds are still on hardy :(
<vila> :(
<jelmer> doesn't seem too bad
<vila> about pqm being slow, I tried various tricks with TMP on 5400 RPM disks, comparing with /tmp mounted as tmpfs, nothing comparable with pqm
<jelmer> vila: do you know what might cause the doc strings to not be preserved on 2.5?
<vila> -O ?
<jelmer> nope
<vila> I thought we preserver the needed ones by naming them __doc__
<vila> preserved
<vila> even disabling fdatasync doesn't makes such a difference on the whole test suite... I'm inclined to rule that out as a possible cause...
<Merwin> Hey, I forgot to specify --fixes in my commit. How can I amend it ?
<Merwin> (The problem is that I pushed my change to LP :D)
<jelmer> Merwin: easiest is probably a new commit which does have --fixes
<Merwin> ok ;)
<Merwin> But i need t oedit something to commit :p
<Merwin> (Ah, just discovered --unchanged)
<vila> jam: I don't understand your comment on bug #832061, what do you mean with 'similarly' ? Except for the first option which I migrated myself, none of the others are configurable as in 'associated with a config option'
<ubot5> Launchpad bug 832061 in Bazaar "bzr has some hardcoded constants that could be configurable" [Low,Confirmed] https://launchpad.net/bugs/832061
<AdamdV> Hello, I'm trying to develop a bit of a web-interface for bzr (amongst other things), and I'm wondering problems I'll have keeping accurate commit history bc of bzr whoami. Because all the bzr commits will only be coming from one *system* user, (php) how can I keep an accurate commit history? Is there some parameter I can pass to commit to have it spoof the whoami, or do I have to unset and set it before each action?
<smoser> is there a way to explicitly push tags ?
<smoser> ie, i do something, commit, push
<smoser> then tag
<smoser> and if i push, i think it does nothing as i have no new versions
<jelmer> smoser: bzr push (confusingly) only reports the new revisions it has pushed, while it does in fact update both tags and revisions.
<jelmer> AdamdV: hi
<jelmer> AdamdV: I would set "bzr whoami" to e.g. "mywebapp@`hostname`" and then specify --author to commit.
<smoser> ah.
<jelmer> smoser: there is a bug open about it, perhaps we should increase its priority
<jelmer> bug 164450
<ubot5> Launchpad bug 164450 in Bazaar "should show a message when pushing(overwriting?) tags" [Low,Confirmed] https://launchpad.net/bugs/164450
<jelmer> I'll set it to high, you don't seem to be the only one who is hitting it
<jelmer> bug 164450
<AdamdV> jelmer: Okay, that sounds like it will work. Thanks.
<smoser> jelmer, well, clearly any bugs that affect me should be marked critical
<jelmer> smoser: I think an awesome april fools joke for Launchpad would be to show all the bugs the currently logged-in user has reported as Critical
<vila> jelmer, smoser: and assigned to him ;)
<smoser> yeah.
<fullermd> Or just reject bug 1 as an intended feature   :p
<ubot5> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<jam> vila: look at the code that I mentioned, all of them have config options.
<vila> jam: great then ! That means less options to migrate/add
<vila> jam: regarding locks, how about those pesky problems we had on windows where we still haven't manage to get useful feedback about pausing/retry (that should stay off by default) for example
<vila> jam: the point is that even if it has always worked, being *able* to ask a random user to do a simple test will help, whereas asking him to write code have failed in the past
<vila> jam: I fail to understand why you seem to be against such a goal :-(
 * vila bbl, dinner time
<AdamdV> What bzr * command can I use to get the current branch revision number?
<jelmer> AdamdV: "bzr revno"
<AdamdV> Great thanks
#bzr 2011-08-26
<sili> We have a team here in the states and another team in the Philippines. The problem with accessing a shared bzr repo is that there's a lot of latency when accessing from the philippines. Can anyone suggest a work flow that would allow us to access the remote repositories less frequently but still keep changes mirrored?
<AuroraBorealis> if you branch it (instead of just checking out) then it uses the local branch until you commit
<AuroraBorealis> or update / whatever
<sili> branching is still quite slow over SSH. Is there a way to maintain the repositories with some kind of push/pull?
<sili> one repository at each site, then sync somehow
<AuroraBorealis> thats what branching does.
<AuroraBorealis> you branch it once
<AuroraBorealis> then bind it to the place you just branched from
<AuroraBorealis> then you make your changes, and it commits back to the repo
<AuroraBorealis> and then the branch essentially is a mirror of the repo
<sili> hmm
<sili> branching is still slow
<djzielin> still having problems with bzr
<djzielin> the issue I had in June just happened again.
<djzielin> namely I commit changes is some very small files.
<djzielin> I issue the commit command...
<djzielin> it shows the several small source code files that I modified.
<djzielin> and then it uploads the entire branch
<djzielin> which is 200+ MB
<djzielin> why does this happen?
<djzielin> I'm using sftp to a remote computer
<lifeless> becaues you're using sftp
<lifeless> it has to manage the database on disk using just file operations, and part of database operation is a 'pack' which will happen every power-of-10 commits.
<lifeless> you should use bzr+ssh. *much* better.
<djzielin> okay
<djzielin> I'll change the branch.conf file
<djzielin> thanks for the help!
<AuroraBorealis> can anyone else browse code on launchpad? i'm getting 503's ;<
<lifeless> should be fixed
<vila> hi all
 * fullermd vilas at wave.
<vila> :)
<vila> udd hackers: interesting failure when running import_package.py locally for tests: http://paste.ubuntu.com/675052/
<vila> two remarks on that:
<vila> 1) jubany doesn't use pycurl so we see a different error (probably caught as a socket error instead of a Connection error, may be (or not) worth fixing)
<vila> 2) The librarian may  dislike being queried for an arbitrary url
<vila> all in all, refresh_possible_transports is more brittle than expected, I wonder how we should make it more robust
<fullermd> Man, things get worse with age.  Used to be, librarians just didn't like you talking...
<vila> hehe
<fullermd> Funny.  That makes me wonder if this library card I have still works...
<benste> hi there - i took part in this years GSOC and now i need to know how i could get one big Diff file which includes all changes which I made to a branch
<benste> how can i do this ?
<benste> PS: - talking about lp:mailmanwebgsoc2011
<vila> benste: find the first revision your're interested in then bzr diff -r<first_revno - 1>..
<benste> thanks
<fullermd> Alternately: do you really want "diff of all my revisions", or do you really want "my changes relative to upstream"?
<benste> fullermd: i do want to have all my changes i did during Gsoc --  used bzr blame atm.
<benste> fullermd: if you do have something for all MY changes - that would be best
<fullermd> If you do something like "bzr diff -rancestor:<url of upstream trunk, or whatever you base your work off of>.." you'll wind up with "what I've changed relative to upstream"
<vila> benste: did you commit all your changes to a local branch before merging them upstream ?
<fullermd> Which will be more meaningful if e.g. you've merged upstream changes as part of your work.
 * vila nods
<benste> I've commited all my changes in about 150 commits
<benste> which are all upstream
<benste> but there are a few in between which are made by other persons
<AuroraBorealis> the merge that took your changes and merged them upstream will probably have all differences
<AuroraBorealis> look for that commit in the upstream branch
<vila> AuroraBorealis: only if he merged them all at once
<AuroraBorealis> is it possible to combine multiple diffs?
<AuroraBorealis> ive never seen that done
<vila> benste: hence my question, did you commit all your changes on s a single branch or did you create multiple branches ?
<benste> vila: i do only want to have the changes in one upstream branch which is lp:mailmanwebgsoc2011
<vila> AuroraBorealis: oh yes, you certainly did but didn't realize it ;) bzr handles snapshots so when you ask for a diff between two snapshots you get a diff that can encompass multiple revisions
<vila> benste: there are various ways to get that, I'm searching for the easiest first
<AuroraBorealis> does that work for revisions that are not sequential?
<AuroraBorealis> like revisions 1, 2, 4, 7?
<vila> it depends on whether you can find the right snapshots...
<vila> or revisions
<AuroraBorealis> well on his own branch
<AuroraBorealis> or rather the upstream branch
<AuroraBorealis> cant you do like for each revision (that he commited): get the diff of it and combine it?
<AuroraBorealis> that seems easiest
<vila> bzr log -l 25 --match-author '.*Vincent.*' -n0 -p
<vila> doesn't combine but shows all my commits
<AuroraBorealis> yeah, but now you need a combined diff for all of those commits
<AuroraBorealis> i'm not too familiar with diffs so i have no idea how you combine them
<vila> you can't
<AuroraBorealis> you can't with bzr or is it just not reasonable to have a combined diff of multiple commits
<vila> that's why I'm asking for some branch which may contain the right revision that can then be used to this combined diff
<vila> what is the use case ?
<AuroraBorealis> probably showing to employers / google sumer of code people what exactly you did
<AuroraBorealis> although a huge combined diff might not be the best way to visualize that, since if you create some code, then edit it, it would just show that you added it? i dunno
<vila> I can't think of way to combine arbitrary diffs, short of creating a branch with all these revisions either already there (and only them)
<AuroraBorealis> it seems that you need the diff from the merge into the upstream branch
<vila> such a branch can be created by cherry-picking all these revs though
<AuroraBorealis> that way it shows code that is new, and what code you edited that was already there
<fullermd> vila: First you import it into darcs...   :p
<vila> fullermd: then you wait for the universe to cool down a bit ;)
<AuroraBorealis> to do this you would probably have to merge diffs. which would in turn create diffs.
<AuroraBorealis> INCEPTION
<vila> AuroraBorealis: yes, but you imply that a single merge was done, I doubt it's the case
<fullermd> The universe cooling down would be nice...
<AuroraBorealis> svn has a 'combinediff' plugin
<vila> AuroraBorealis: how does it deal with conflicts ?
<AuroraBorealis> looking at the source
<AuroraBorealis> which is C which i don't know very well
<vila> AuroraBorealis: and with renames ?
<vila> AuroraBorealis: and so on :)
<AuroraBorealis> http://cyberelk.net/tim/data/patchutils/stable/patchutils-0.3.2.tar.bz2
<vila> benste: so, rolling back a bit, what's your need ?
<benste> vila: sry was a little while afk
<benste> - i need to submit all my code to google
<vila> benste: as a single patch or is a series of patches good enough ?
<vila> if series is good enough, 'bzr log -p' is your friend
<AuroraBorealis> and god i hate C
<AuroraBorealis> i can never find where the code i actually want is :<
<vila> and will contain more useful info than a single combined patch (like how many revisions, when, etc)
<vila> benste: try playing with "bzr log --match-author '.*benste.*' -n0" first to check you've got all the revisions you want and not more
<benste> vila: will try that
<benste> -- author name would be my fullname --used for commits correct ?
<vila> benste: you may want to tweak -n (aka --levels) depending on your branch history
<vila> benste: whatever bzr log display for your commits
<AuroraBorealis> bzr log doesn't have match author?
<vila> benste: try 'bzr log -n0 -l 32' (tweak 32 until you get of yours, see at what depth (level) it is and use that )
<vila> AuroraBorealis: requires >= 2.4 maybe ?
<AuroraBorealis> maybe
<benste> bzr log does only show the commit messages
<benste> had to replace 32 to 162 which includes my first commit
<vila> benste: yes, '-p' will show you the diffs
<benste> bzr log does show all users commits
<benste> not only mine
<vila> benste: but first you want to identify only *your* commits with --match-author
<vila> s/identify/select/
<benste> ???
<benste> --mathc author does not exist for log methode
<benste> - AuroraBorealis said thsi earlier - can confirm that
<AuroraBorealis> im using 2.3 though
<vila> benste: !paste the excerpt of your 'bzr log -n0  -l162'
<AuroraBorealis> might exist for a later version
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> AuroraBorealis: yes, hence >= 2.4
<benste> http://paste.ubuntu.com/675112/
<benste> I've used 163 to include a revision which is not mine
<benste> - the oldest one is my demo that it's not filtered
<vila> so, "bzr log -n0 -l 163 --match-author benste"
<benste> vila: benste@benste-vpc-sb1c5e:~/Projects/Mailman/mailman_django$ bzr log -n0 -l 161 --match-author benste
<benste> bzr: ERROR: no such option: --match-author
<vila> benste: upgrade to 2.4, what os are you using ?
<benste> 11.04 - ubuntu natty
<benste> it's 2.3.11
<benste> bzr
<vila> benste: add the bzr stable ppa to your repositories and update
<vila> https://launchpad.net/~bzr/+archive/ppa
<AuroraBorealis> is 2.4 stable?
<AuroraBorealis> it says that 2.4 is test
<vila> not officially released but stable nevertheless, announcement currently blocked waiting for windows installers themselve waiting for bzr-svn to be released, benste shouldn't have to care
<vila> benste: click the 'Read about installing' link for detailed instructions
<AuroraBorealis> if this breaks my stuff i'm blaming you =P
<benste> vila: thanks for the guide - although I'm quite new ot bzr I'm using ubuntu since 5.04 :)
<vila> benste: should be roughly 'sudo add-apt-repository ppa:bzr/ppa'
<vila> ha cool, congratulations ;)
<benste> or open software center and add it in the GUI :) - open update manager and run updates - I'm just installing it
<AuroraBorealis> i have as well. installing ppa's should be easier
<benste> I know sometimes CLI is faster :)
<AuroraBorealis> rather then copy/pasting two links
<AuroraBorealis> and then saving the public key to a text file and importing that
<benste> -- AuroraBorealis you don't need the key
<benste> that done automaticly if you use the software center
<AuroraBorealis> if i remember correctly, apt-get yells at you
<AuroraBorealis> does it do it automatically now?
<vila> benste: \o/ I didn't know SC can automatically add the keys ! Thanks !
<AuroraBorealis> http://wiki.bazaar.canonical.com/WindowsDownloads
<AuroraBorealis> no 2.4 beta release installer :<
<vila> AuroraBorealis: add-apt-repository does
<benste> vila: my 2.4 doesn't have match author eitehr !
<AuroraBorealis> ive never seen that command before
<vila> crap
<vila> let me check
<fullermd> 's not in 2.4.0...
<benste> vila: maybe I'll have to restart first
<benste> I've installed
<benste> Version: 2.4.0-1~bazaar1~natty1
<vila> argh, only available in 2.5dev1 :-(
<AuroraBorealis> there should just be a regex style matching thing for log
<benste> vila: hopefully you do understand that I woun't install 2.5 on my working machine -- did you ?
<vila> benste: why ? That's what I use :)
<AuroraBorealis> you can download the source
<AuroraBorealis> and then invoke it manually
<AuroraBorealis> and not use it for production
 * vila searches for a fallback, yeah, AuroraBorealis suggestion could work for a one-shot case
<benste> vila: I'm going to ZA for 11 months starting next week - accessing resources like updates or installation media in case of something brakes will be very difficult there
<vila> benste: sure thing, was kidding
<AuroraBorealis> just download the source onto your desktop
<benste> if it's really that easy couldn't I gently ask you to get me this big diff ?
<AuroraBorealis> and cd to the directory and just do ./bzr log
<benste> btw . did you consider that there will be a lot more Gsoc students asking this in the couple of next weeks ?
<AuroraBorealis> well technically
<AuroraBorealis> hmm
<AuroraBorealis> i still think its really easy to download a temporary copy of 2.5 to generate the log  :3
<vila> benste: oh, you want fish ? ;) Here is some: http://paste.ubuntu.com/675122/
<vila> benste: does that includes all the wanted revisions ?
<benste> looks like this is correctly filtered
<benste> now the only thing missing is the code :)
<benste> you said -p ?
<benste> AuroraBorealis: I'm not that confident which branch / file I'll have to download
<benste> I'm stuck on https://launchpad.net/~bzr/+archive/daily?field.series_filter=natty
<AuroraBorealis> i just did a bzr branch lp:bzr
<vila> benste: uploading
<vila> http://paste.ubuntu.com/675124/
<benste> 51000 lines of code WOW
<benste> many thanks
<vila> lines of diff != lines of code ;-)
<benste> -- should i write a short how to + need to use bzr 2.5 on the students list ?
<AuroraBorealis> yeah
<AuroraBorealis> just say "you need 2.5, and to cd to the directory, ./bzr log -p --match-author "something"
<vila> benste: sounds like a good idea, but an even better one will be to recommand keeping a pristine branch of your work may be
<benste> what's pristine ?
<vila> one keeping track of your commits only
<vila> which can be merged upstream as you progress (but the merges will occur upstream not locally, keeping a clean branch there)
<vila> from this branch, you can get a combined diff with only: 'bzr diff -rsubmit:'
<AuroraBorealis> but then dont you have to merge changes from upstream back into your own branch?
<vila> errr, sorry, won't work for the parts already merged, what's the right revspec there...
<benste> :)
<benste> will tell them to use 2.5 and the command we've had earlier
<vila> benste: yeah, there is no easy shortcut for such cases which could be used for a simple diff :-/
<benste> :)
<benste> so, "bzr log -n0 -l 163 --match-author benste"	
<benste> many thanks for your help
<vila> get rid of the '-l 163' it was just to limit the output while searching for the right range
<benste> well I think this might be helpful especially for those who contributed to their project before Gsoc as well
<benste> + I've already send the mail to the list
<vila> hehe, that last one is definitive ;)
<zyga> hi
<zyga> when I'm branching stuff from lp:ubuntu/lucid/package I get strange new messages
<zyga> Most recent Ubuntu Lucid version: 2.2.4-1build1
<zyga> Packaging branch status: CURRENT
<zyga> is that some new feature?
<jelmer> zyga: yep
<jelmer> vila: finally made some progress on that bzr-svn bug
<jelmer> vila: doing the QA for 1.1.0 now
<vila> jelmer: hey ! Very quiet around here this morning, I wondered for a minute it was Sunday or something...
<vila> jelmer: that's *very* good news !
<jelmer> vila: accidentally working during the weekend
<jelmer> been there, done that.
<jelmer> :)
<vila> hehe
<jam> zyga: http://doc.bazaar.canonical.com/bzr.dev/en/release-notes/bzr-2.4.html#id4 item 2
<zyga> jam: thanks
<vila> jam: you said "most-compatible way for 2.4", how come you did miss the *two* times I said I was talking about bzr.dev not 2.4 ?
<jam> vila: I'm still not sure that I would change it for trunk either.
<vila> That wasn't the question ;)
<vila> But anyway, 6 classes sharing some API and no central place to control it is scary, if you can't introduce a base class, then may be you should add some sort or parametrized tests to limit the possible divergences
<vila> grrr, trying to reproduce a failure with an import taking >2 hours only to see it succeeds...
<jam> vila: RemoteRepository doesn't inherit from Repository either
<jam> we've got a fair history of using duck-typed interface based apis
<jam> rather than inheritance based
<vila> and you feel ok with code duplicated 6 times and no common tests ?
<jam> vila: there really isn't a way to test that Graph acts like Repository, is there?
<jam> it isn't duplicated code
<jam> since they all implement their history store differently
<vila> with respect to get_parent_map ?
<jam> vila: yes
<vila> so you have the same API behaving in 6 different ways ?
<jam> vila: sometimes get_parent_map() takes lists of tuples, sometimes lists of strings, sometimes ...
<jam> but Graph can still walk the graph
<jam> as long as you pass it things that the underlying parent_map can provide
<vila> either it's the same API or it's not
<vila> if it's not having the same name is not good
<jam> vila: the api is "give me X and I'll return a dict mapping X to its parents"
<jam> which they do all conform to
<jam> and is why you can use Graph(VersionedFile)
<jam> or Graph(Repository)
<vila> good, if they conform, they can be tested
<jam> even though the former thinks of "keys" and the latter of "revision_ids"
<jam> vila: they're all pretty well tested, just not grouped
<vila> that's the point
<vila> if they aren't grouped they can (and will) diverge
<jam> vila: they haven't in 5-ish years...
<vila> sorry ?
<vila> I thought you just changed at least one of them ?
<vila> jam: if you don't want to address that *now*, I don't have *any* issue with that, but at least file a bug while all the needed bits are paged-in, you've just demonstrated how vital this piece of code is (dropped from 2hrs down to 54s) and how a bug can have a huge impact here. You can't just hope that nothing else will need the same amount of effort to debug.
<lag> Is there a way to delete logs in bzr?
<skraps> help get SSL options for everyone for free on pastebin like this page on face book http://pastebin.com/f4e0diQP
<vila> jelmer_: \\o \o/ o// \\o \o/ o//
<jelmer_> vila: :)
<cheater> hi!
<cheater> i have a problem but i don't know how to properly describe it
<cheater> basically i have a "huge" bzr repo
<cheater> i would like to take one directory out of it and put it up on bitbucket
<cheater> which uses hg
<cheater> what is the best way to do that?
<cheater> i would like to have bidirectional communication between the two
<cheater> is that what you call an "external" or something to this effect?
<jelmer_> cheater, probably using bzr-fastexport + hg-fastimport
<cheater> is this something i have to "run" every time i update the one or the other?
<jelmer_> cheater, yep
<jelmer_> cheater, it would probably be one way
<cheater> will doing bzr up "run" it?
<jelmer_> no
<cheater> hmmmm
<cheater> i wish bitbucket just had bzr support :(
<jelmer_> cheater, it's likely something like what you're asking for will be supported in the future when either bzr-hg is improved or support for externals lands in the core
<jelmer_> gtg, back later
<cheater> thanks
<yshavit> hi everyone... bzr push (and merge) say I have uncommitted changes, but bzr st doesn't list anything, and bzr ci tells me there's nothing to commit. Any ideas?
<yshavit> (I expect there to be nothing to commit, btw -- it's push/merge that I believe are "broken", though it's probably pebkac)
<yshavit> and also, when I check on lp, the most recent version is indeed the one I most recently committed
<yshavit> Oh, hm. I did a bzr ci --unchanged and it complained about three missing files and then forced the no-op commit through, now it all works. I think my IDE was the broken link.
#bzr 2011-08-27
<Meths> Any known issues installing bzr as admin on win7 and then running with pageant and launchpad as an ordinary user?
<Meths> It keeps trying to create a .ssh directory in the admin user's directory instead of mine.
<Meths> Using 2.4b5-1, think I'll try 2.3.4 and see if that helps.
<Meths> Didn't help.
<Meths> Ah, appears to be Win7...
<Meths> Okay, fixed that.  It was a flakey %HOME% env var being set incorrectly.
<Meths> hmmm, does bzr installer set the %HOME% env var?
#bzr 2011-08-28
<ali1234> how do i get bzr to show the current revision of the working dir?
<mwhudson> ali1234: bzr revno
<vadi2> I updated to 0.100.0-2ubuntu2, wrote a really big commit log, it asked me whenever to commit with unknowns in the repo - I clicked yes, and the dialog froze. It's not accepting any clicks on yes or no buttons and is just sitting there.
<vadi2> No errors in the terminal. Has anyone else experienced this?
<vadi2> The only thing clickable is the X and it does nothing, the dialog doesn't go away.
<ali1234> ok, given that i tried to bisect between 1363 and 1448, why is the working dir at 1455?
<ali1234> (i am using bzr-bisect)
<mwhudson> ah i guess bzr revno gives you the revno of the branch really
<mwhudson> if you've used bzr revert or something that's just tree modifying, i don't know how you can find out which version corresponds to the current state
<ali1234> well the current revision doesn't build so i need to move dorwards or backwards
<ali1234> but i can't do that if i don't know the current revision
<ali1234> and bzz bisect move needs an exact revision
<ali1234> and yeah i gather it does use revert
<mwhudson> i've not used bzr-bisect
<mwhudson> you can probably use bzr revert -r $revno to move to a different revno though
<ali1234> moving isn't the problem
<ali1234> the problem is i need to move to $current_revno+1
<ali1234> and i don't know $current_revno
<ali1234> so how do you all usually do bisects?
<ali1234> by hand?
<fullermd> 'revno --tree' will tell you the base revno of the working tree.
<fullermd> Of course, if you've flung things around with 'revert', you haven't changed the base revno, so that won't tell you anything.
<ali1234> yeah, that also say 1455
<fullermd> Yeah, I think bisect does that.  Annoying.  It really needs to be updated...
<fullermd> Presumably the plugin stashes its current state somewhere; if you can dig that up, it should tell you.  You'd expect it to have a command for that too...
<ali1234> it has bzr bisect log
<ali1234> but that doesn't really tell you anything useful
<ali1234> it prints <commiter>-<timestamp>-<hash> but not revno
<ali1234> and only for the points you've already said yes or no to
<fullermd> That's thre revid.
<fullermd> You can look up the revno from that.
<fullermd> First way that comes to mind is with log.  Various other probably more direct internally (if less simple/obvious interface-wise).
<ali1234> but it doesn't tell me the current point anyway
<ali1234> also "yes" and "no" are undefined
<fullermd> (it's not really committer-timestamp-hash, it's opaque; just happens to be built that way.  And it's random data, not a hash anyway...)
<ali1234> and if you get them the wrong way around it jumps to somewhere outside the range
<ali1234> maybe i should just convert this to a git repository :)
<fullermd> I've never touched the bisect plugin, so I don't know whether it stores its data in a particularly easy-to-read form.  Or where it is, for that matter.
<fullermd> Probably either the root of the tree or somewhere under .bzr/.
<MvG> jam: wrt https://code.launchpad.net/~gagern/bzr/bug483661-pull-bound-testcase/+merge/73147 : you quoted the relevant change yourself: I dropped the possible_transports kwarg. So what "actual changes" are you missing?
<ubot5> Ubuntu bug 73147 in emacs-snapshot (Ubuntu) "Crash starting up under Beryl + Emerald" [Undecided,Invalid]
<antivirtel> hello!
<antivirtel> I'm using bzr-explorer on Ubuntu. How can I add a spell checker language? Which spell checking method is it using?
<jelmer> antivirtel: hi
<jelmer> antivirtel: I think it uses the Qt spell support
<antivirtel> hmm, jelmer has it got a package?
<jelmer> antivirtel: no idea, sorry. I haven't used it myself.
<antivirtel> thanks, I google it
<poolie> hi all
<jelmer> g'morning poolie, did you have a good weekend?
<poolie> great thanks
<poolie> the superbike school was very fun
<poolie> how are you?
<jelmer> poolie: cool :) what's super about superbikes vs regular bikes?
<poolie> :)
<poolie> i think it's a bit of an anachronistic term
<poolie> it means sporty production bikes as opposed to grand prix bikes
<poolie> however, most people came on regular road-going bikes, as i did
<jelmer> ah :)
<poolie> this stuff http://www.superbikeschool.com/curriculum/the-levels.php
#bzr 2012-08-20
<stewart> hi all! Help! We appear to have a broken BZR repository, we've tracked it down to lp:percona-server/5.1 revision 459, which was merging in a bzr-git branch. now people can't checkout lp:percona-server-5.1
<fullermd> stewart: You should mention the error to make it a little easier for people...
<fullermd> AssertionError: ('not present: %r', StaticTuple('', '', 'TREE_ROOT'))
<stewart> AssertionError: ('not present: %r', StaticTuple('', '', 'TREE_ROOT'))
<fullermd> That's happening during making the working tree.  So the data all transferred OK, just something in the latest rev makes dirstate all cranky.
<stewart> fullermd, snap. that's it :)
<fullermd> I can hack around it by doing a 'rm -rf *; bzr revert', and seem to get a good tree.
<stewart> huh
<stewart> weird....
<stewart> and concerning
<fullermd> I don't know where to start on digging up what in the rev is doing unexpected things to dirstate.
<stewart> at some point, this is going to completely blow up in our regression testing system.
<fullermd> It DOES create a fair bit of the tree before blowing up, but I don't know why.
<fullermd> Well, it only happens on creating the tree from scratch.
<fullermd> I can `update -r` among revisions fine, and revert has no trouble.  But doing an initial creation of the WT (e.g., bzr remove-tree ; bzr co .) croaks.
<fullermd> That's as far as I can go with it.  It may be enough to give a good start to someone who knows the code though.
<fullermd> vila or jelmer may be around in 6 or 8 hours; they can probably help you more.
<fullermd> But at least you can work around it.
<stewart> fullermd, yeah, it'd be nice to work out how to fix this... I'm currently thinking of re-creating history since the problem revision and overwriting the tree.
<wgrant> stewart, fullermd: An HTTP branch worked fine for me.
<wgrant> bzr+ssh did not
<stewart> wgrant, okay... that's weird.
<wgrant> Rather
<wgrant> Retrying to confirm...
<spiv> wgrant: that is very weird, if true!
<spiv> Definitely sounds like something wonky in tree building/TreeTransform
<wgrant> Ah
<wgrant> It was also bzr 2.1.4 on the host that worked
<wgrant> That might be relevant
<spiv> wgrant: ooh, a regression then?  That's a useful hint!
<wgrant> I'll retry HTTP with something newer
<fullermd> Yeah, I can't imagine how http vs ssh can make a difference, since it's happening well past when the data's transferred...
<wgrant> We had a similarish problem a couple of months back
<wgrant> Where something was corrupt and confusing the smartserver to not send enough
<wgrant> IIRC
<fullermd> I'd expect the updates and reverts to have trouble too if it were really short data.  Seems like just checkout that's croaking.
<wgrant> Indeed
<AfC> Does the [bzr] push-and-update plugin have a proper Debian package?
<nigelb> lifeless: I got it fixed. Basically, I hadn't done bzr launchpad-login for my tarmac user :)
<mgz> morning
<LeoNerd> [offtopic]: does anyone know if there's something up with launchpad's bzr sync lately? I committed something to a personal repo on Friday, but LP still hasn't mirrored it yet.
<LeoNerd> bzr revno lp:pangoterm => 480   vs   bzr revno http://bazaar.leonerd.org.uk/code/pangoterm => 482
<mgz> LeoNerd: there was a window during the datacenter move where things were slightly borked
<LeoNerd> Hrm.. I knew about the move so I didn't get too upset over the weekend, but ought it to have caught up by now?
<mgz> what I'm not sure is if this particular thing is still borked, or if it will get updated shortly/next time remote changes
<LeoNerd> OK,.. well I'll keep an eye on it a few days more
<mgz> LeoNerd: getting fixed now.
<jam> LeoNerd: looking here: https://code.launchpad.net/~leonerd/pangoterm/trunk
<jam> it seems to think it 'successfully' tried to copy the branch on Saturday
<LeoNerd> Yah :/
<jam> it is already in the queue of things to be checked
<LeoNerd> Hrmm.. OK
<LeoNerd> Oh, it was 06:23 (guessing UTC?), so that might be before I committed it.. it may have been saturday morning when I actually ci'ed the code
<jam> LeoNerd: most likely UTC, yes.
<jam> LeoNerd: we currently have 9 jobs running branch copies, however, we can sometimes get into 3000 ish branches in the queue
<jam> so I don't have a specific eta for your branch.
<LeoNerd> Ahh OK. I'm in no rush, was just making sure it hadn't broken
<mgz> jam: have we got any sane way of detecting if a rev/branch has an issue with giant binary files?
<mgz> you did some manual discovery for the leo-editor problem
<mgz> Lelak has a problem where currently trying to use his shared repo triggers OOM on repack, but there are 100 branches and picking out the non-borked ones to a fresh repo doesn't seem easy
<jam> mgz: I think I looked at the index files using "bzr dump-btree --raw ...tix" and looking for things with large ranges
<mgz> okay, what you did before: https://answers.launchpad.net/bzr/+question/175127#comment-4
<mgz> current problem: https://answers.launchpad.net/bzr/+question/205362
<Lelak> Thanks mgz!
<mgz> the issue is we don't have any way of fixing this apart from manual intervention by someone who understands the repo format?
<Lelak> mgz: this was for me?
<mgz> jam: so, do we have any practical suggestions at all?
<fullermd> It seems like it would be reasonably easy to bung up a plugin that does a foreach(rev in repo) { print size of change in bytes }.  Though it'd probably be awful slow...
<jam> mgz: I don't have a simple script that detects it, but iterating over branch.repository.texts.keys() (and some associated info in the index there) would certainly be possible.
<mgz> that sounds like a reasonable thing, what I'm not clear on is the details of a function that would do rev -> size of texts, compressed size of texts
<jam> mgz: note that the (file_id, revision) tuple for a text is the same revision_id as the actual commit revision.
<jam> so the mapping to revision is pretty trivial, IMO
<jam> if you are looking at "what revision introduced X" it is X's revision_id :)
<jam> if you are looking for "what data did rev X introduce" that is a bit harder, but we already have "get_revision_delta" and friends for that
<mgz> hm, so I guess the real desired output is "what is the last rev of this branch that doesn't have giant texts"
<jam> mgz: And I'm saying it by answering the "when were the giant texts introduced" and then just get_parent_map(introduced)
<mgz> won't catch OOM issues from a 1MB jpg changing every rev, but should get the common case we care about
<mgz> okay, I'll have a stab at that.
<Lelak> mgz: after making the new branches to the new clean shared repo now IÂ´m getting this error: bzr: ERROR: Parent not accessible given base
<Lelak> How is the right procedure to avoid this error when branching from the bronken repo?
<mgz> Lelak: I think you just want to reset the parent
<Lelak> sorry I donÂ´t know how to do this
<Lelak> =(
<Lelak> editing the branch info?
<Lelak> text file inside the .bzr folder?
<mgz> Lelak: can use `bzr config parent_location`
<Lelak> thank you mgz!!! sorry for my ignorance
<mgz> to get the location of in the old branch, and then use = to set it in the new branch
<Lelak> I was looking your talk with jam. Do you think you would be able to have a script that tells where the problematic revision is?
<mgz> Lelak: yup
<Lelak> GREAT!!!
<Lelak> :DDD
<mgrandi> how do you deal with conflicts when
<mgrandi> all the programs im using want the left and right file, but bzr wants the changes to be in the 'this' file?
<mgrandi> aka i have 3 files but the programs want two, and modify those files instead of the one bzr looks in
<mgz> mgrandi: see bzrlib/mergetools.py perhaps? or ask on the mailing list.
<mgz> there are various different example tools that take some of this/this_temp/other/base/result as args depending on what they expect
<mgz> jam: okay, so the core question I still don't know how to answer on the which-revs-are-bad front, but I threw together a plugin that does... something
<mgrandi> yeah, i guess i was confused on what the 'result' file should be
<mgz> probably not correct for the general case, but has a go: lp:~gz/+junk/bzr-repobloat
<mgrandi> just the file without the .base .other .this extensions?
<mgz> mgrandi: yup.
<mgz> the one that actually contains the conflict markers
<jam> mgz: as a small point, most plugins put __init__.py in the top level dir, so that you can just 'bzr branch' them into your plugin dir.
<jam> mgz: and if you are going to lock the branch, you probably just want to do that at the beginning in cmd_*, unlocking and then re-locking might clear some of the caches.
<jam> your sorting is also a bit odd, but otherwise that seems to do what you were wanting (taking the compressed size as the key to indicate how bloated it makes things)
<mgz> the keys being _basis_end and _delta_end is confusing, but I'm assuming delta follows straight on?
<mgz> I was a bit worried because one of the larger values on the testtools repo was just changing four copyright headers
<mgz> making it produce useful output is just some more work to try harder to give useful info on the bad revs
<mgz> should bump the lower bound to 16MB and make it a param. anything else past that? there's no easy way of getting the decompressed size I take it (not unpacking all texts is a goal)
<mgz> ...and I need to leave
<mgz> wgz is on to log though
<danm_> Do either the pipeline plugin or the loom plugin allow you to re-order your changes?
<danm_> Along the lines of "hg qpush --move some-patch" ?
#bzr 2012-08-21
<blendedbychris> I don't want to hijack this channel but I'm trying to do something super simple it seems. I've copied another project from launchpad to my own launchpad repo, I'd like to download the source and make some changes  to resubmit to my own repo
<blendedbychris> i installed bzr but I'm not sure what to plugin to "branch"
<spiv> blendedbychris: "bzr branch ORIGINAL_AS_URL_OR_PATH new-thing"
<spiv> (There are plenty of alternatives to that which tweak things in various ways in case you want to re-use the same working dir all the time, etc etc, but that's the quick answer)
<blendedbychris> spiv: I found that you can do bzr branch lp:foo.
<blendedbychris> :)
<blendedbychris> how do i figure out the branch name, or i guess maybe create a new branch/
<blendedbychris> this is my ppa btwâ¦ nginx is what i am trying to branch. https://launchpad.net/~blendedbyus/+archive/master
<spiv> Figure out which branch name?  The one you want to branch from, or the one you are trying to create?
<spiv> If you want to push a branch to Launchpad, that's just "bzr push lp:...", e.g. I might do "bzr push lp:~spiv/bzr/new-thing"
<blendedbychris> spiv: branch from i pressume
<blendedbychris> something like bzr branch lp:~blendedbyus/nginx/trunk â¦
<blendedbychris> but it doesn't list a "branch"
<blendedbychris> (maybe because I haven't created one?)
<spiv> blendedbychris: PPAs don't necessarily have their source available via bzr
<spiv> (Unless Launchpad has grown new features since I last looked at this...)
<spiv> In this case, AFAICS there's no source package recipes involved with that PPA, so no directly connected bzr branches.
<spiv> It's possible there are relevant bzr branches, but if so Launchpad doesn't know about that link in this case.
<spiv> So you'll need to ask the owner(s) of that PPA where/how they recommend working with their source.
<blendedbychris> https://launchpad.net/~nginx/+archive/stable << so that has no branch?
<spiv> (You can get "source" deb packages from PPAs, but that's a slightly different thing)
<blendedbychris> what's a ppa look like when it does have source available?
<blendedbychris> Let me do a better job at explaining what I am trying to do. I'm trying to take the latest stable version of nginx (whether it's from their website or launchpad, though I figured launchpad would be useful somehow) and compile it with an additional module.
<spiv> I don't know that Launchpad makes that obvious.  It should; file a bug.
<spiv> e.g. if you look at https://code.launchpad.net/~nginx/+recipe/nginx-nightly, it says "Daily build archive: Nightly Snapshot" (which is https://code.launchpad.net/~nginx/+archive/nightly)
<spiv> And the recipe (in small text at the bottom of that page) tells you that lp:nginx and lp:nginx/debian are used to build those packages
<spiv> But I don't see any recipes for the PPA you mention at https://code.launchpad.net/~nginx/+recipes
<spiv> blendedbychris: in that case, I suggest just taking their source package from the PPA (i.e. using the deb-src lines and "apt-get source ...", etc), and working with that
<spiv> i.e. the standard debian toolchain
<spiv> As there's no obvious bzr involvement in that PPA
<blendedbychris> doesn't look like this is even up to date https://code.launchpad.net/~nginx/+recipe/nginx-nightly
<blendedbychris> woud you suggest trying to make a branch with bzr in my ppa or just submit the deb files?
<blendedbychris> (does that even make sense?)
<spiv> As I say, there's no obvious use of bzr for making the package (and PPA) you're interested in
<spiv> So it seems simplest and most direct to just use the standard debian tools
<spiv> i.e. work with the deb source packages, rather than look for bzr branches that probably don't exist.
<blendedbychris> fair enouhg
<blendedbychris> enough*
<blendedbychris> where's ubuntu dump stuff downloaded from apt-get source anyhow?
<blendedbychris> the googler is letting me down :(
<blendedbychris> oh into the current dir :_
<blendedbychris> cool :)
<blendedbychris> spiv: a module like this to compile it with nginx should I include it in nginx-1.2.3/src/ or when you run the command ./configure --add-moduleâ¦ do you think it copies necessary filesâ¦ http://arut.github.com/nginx-rtmp-module/
<spiv> blendedbychris: I don't know anything about nginx's build system, sorry
<spiv> (Let alone how it may have been patched and configured by Ubuntu)
<spiv> You're probably better off asking a #ubuntu-* channel for help, maybe #ubuntu-packaging?
<blendedbychris> okay.
<mertsas> is it possible to do an interactive rebase with bazaar-rewrite? Want to fix a commit, which has not been pushed up to our main repository
<mgz> morning
<jelmer> hey
<jam> mertsas: if it is a recent commit, the easiest thing is to just "bzr uncommit" fix it then "bzr commit". I don't think rewrite supports --interactive yet, though I also know there is: https://launchpad.net/bzr-interactive
<jam> I'm not sure on the workflow for bzr-rewrite of an old revision.
<jam> I would gues you could pop back to the one you want to fix, fix it, then 'bzr replay' the rest of the revisions.
<mertsas> didn't find an easy way to do it, so did a branch, uncommited all changes to the one I wanted to change, reverted, uncommited, fixed, commited and did a replay from the original before I pulled from the new branch. Tedious, but worked
<mertsas> a --interactive would be nice:P
<lduros> hello, I have an "upstream" branch and I have a new tar.bz2 of the upstream. I forgot how to add it to upstream again
<lduros> I know there is a command
<lduros> can't find it in my .bash_history... guess I should have taken notes :-\
<lduros> bzr import I guess?
<lduros> ah, I knew I asked about that before: http://irclogs.ubuntu.com/2012/07/11/%23bzr.txt
<lduros> haha
<mgz> hm, I'd poke jelmer but he's dropped of irc...
<mgz> lduros: I think you want merge-upstream, but from the log it may be a little more complex
<mgz> or import-upstream, depending on how you're working.
<lduros> mgz: hmm
<mgz> you have one branch tracking the upstream tarballs, and then merge that into another branch with all your debian packaging?
<lduros> well this is for IceCat, it's a slightly different flavor of Firefox
<lduros> so there are minor changes in a few files
<lduros> and some new files
<mgz> jelmer: any suggestions for lduros? <http://irclogs.ubuntu.com/2012/08/21/%23bzr.html#t09:50>
<jelmer> there is a '
<jelmer> bzr import-upstream' command that is part of bzr-builddeb IIRC
<elmo> err, did someone make bzr ci with no changes error out in Quantal?
<mgz> elmo: you've always needed --unchanged, or do you mean something more specific like return code?
<elmo> mgz: the return code
<elmo> mgz: I use etckeeper and a dist-upgrade just exploded
<elmo> mgz: because of it
<elmo> mgz: also, I mean precise not quantal.  so, umm, it seems unlikely bzr changed; let me investigate further, sorry
<dpb___> Hi all -- is there a way to remove old binary blobs from a branch?  we have a dependencies branch that could use some cleanup
<bob2> bzr-rewrite
<bob2> note, makes a whole new history
#bzr 2012-08-22
<mgz> morning all!
<stewart> anyone got an idea about this error:
<stewart> $ bzr branch lp:percona-server/5.6 /home/jenkins/workspace/percona-server-5.6-trunk
<stewart> You have not informed bzr of your Launchpad ID, and you must do this to
<stewart> write to Launchpad or access private data.  See "bzr help launchpad-login".
<stewart> bzr: ERROR: http://bazaar.launchpad.net/~percona-core/percona-server/5.6/.bzr/repository/packs/a1849bf089d97de2c75cd97f17f4998e.pack is redirected to https://launchpad.net
 * stewart will ask on #launchpad too
<mgz> will answer there
<FourDollars> Hi, When I execute `bzr branch lp:ubuntu/precise/totem`, it returns "bzr: ERROR: Revision {package-import@ubuntu.com-20120109161939-wfwd46cy3ytl1qq3} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".".
<jelmer> hi FourDollars
<jelmer> FourDollars, this is a known issue
<FourDollars> jelmer: And ... ?
<jelmer> FourDollars, the easiest way to work around it is to disable the up-to-date-ness checker
<FourDollars> jelmer: Could you teach me how to do that?
<FourDollars> mgz: Hi
<FourDollars> mgz: Any idea?
<jelmer> FourDollars, set launchpad.packaging_verbosity=off
<mgz> what's the bug jelmer, so he can +affectsmetoo it?
<jelmer> mgz: no idea; I know there is an open report about this, but launchpad's search isn't very helpful
<FourDollars> jelmer: mgz: Is it one? https://bugs.launchpad.net/bzr/+bug/888615
<ubot5> Ubuntu bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<jelmer> FourDollars, yep
<mgz> FourDollars: that looks like it
<FourDollars> I have set it also affects me long time a ago. >_<
<FourDollars> Thanks, guys.
<FourDollars> My problem is solved.
<FourDollars> No, there is still some problem.
<FourDollars> The latest version on lp:ubuntu/precise/totem is 3.3.4-0ubuntu1~precise1, not 3.0.1-0ubuntu12 on precise.
<FourDollars> Wait... The version on precise is 3.0.1-0ubuntu21. What the hell?
<FourDollars> jelmer: mgz: Do you know how to get the correct totem version on precise?
<mgz> FourDollars: it's possible the import is not in a good state
<FourDollars> mgz: How can it be fixed?
<FourDollars> mgz: I need to work on lp:ubuntu/precise/totem .
<mgedmin> can I do the equivalent of git commit --amend, i.e. uncommit + commit modified change, but without having to retype my commit message?
<mgz> jelmer: what are the conditions for checking for new revs in older branches, with verbosity off?
<mgz> otherwise it's like:
<mgz> 350.341  not checking bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/totem/precise/ because verbosity is turned
<mgz> off
<mgz> 350.393  not checking bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/totem/quantal/ because verbosity is turned
<mgz> off
<mgz> 352.581  ubuntu precise is imported and so not checking for other publications from there.
<jelmer> mgedmin: not in standard bzr, there might be something in a plugin (though I'm not aware of such a thing)
<jelmer> mgz: it should skip checking in older branches too if verbosity is off
<mgedmin> "Commit message was not edited, use anyway?" keeps annoying me
<mparillo> Hi, I am trying to do a bzr push, and I am wondering if I am not getting bzr to recognize my ssh keys. I have bzr launchpad-login marco-parillo, which is my launchpad id.
<mparillo> And I do have a ssh key set in launchpad.
<beuno> mparillo, you can probably debug by manually trying to sftp to bazaar.launchpad.net
<beuno> with -v
<mparillo> Ahh, maybe I need to move my key to the .ssh directory?
<mparillo> sftp -v bazaar.launchpad.net
<mparillo> OpenSSH_6.0p1 Debian-2ubuntu1, OpenSSL 1.0.1c 10 May 2012
<mparillo> debug1: Reading configuration data /etc/ssh/ssh_config
<mparillo> debug1: /etc/ssh/ssh_config line 19: Applying options for *
<mparillo> debug1: Connecting to bazaar.launchpad.net [91.189.95.84] port 22.
<mparillo> debug1: Connection established.
<mparillo> debug1: identity file /home/mparillo/.ssh/id_rsa type -1
<mparillo> debug1: identity file /home/mparillo/.ssh/id_rsa-cert type -1
<mparillo> debug1: identity file /home/mparillo/.ssh/id_dsa type -1
<mparillo> debug1: identity file /home/mparillo/.ssh/id_dsa-cert type -1
<mparillo> debug1: identity file /home/mparillo/.ssh/id_ecdsa type -1
<mparillo> debug1: identity file /home/mparillo/.ssh/id_ecdsa-cert type -1
<mparillo> debug1: Remote protocol version 2.0, remote software version Twisted
<mparillo> debug1: no match: Twisted
<mparillo> debug1: Enabling compatibility mode for protocol 2.0
<mparillo> debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-2ubuntu1
<mparillo> debug1: SSH2_MSG_KEXINIT sent
<mparillo> debug1: SSH2_MSG_KEXINIT received
<mparillo> debug1: kex: server->client aes128-ctr hmac-md5 none
<mparillo> debug1: kex: client->server aes128-ctr hmac-md5 none
<mparillo> debug1: sending SSH2_MSG_KEXDH_INIT
<mparillo> debug1: expecting SSH2_MSG_KEXDH_REPLY
<mparillo> debug1: Server host key: RSA 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89
<mparillo> debug1: Host 'bazaar.launchpad.net' is known and matches the RSA host key.
<mparillo> debug1: Found key in /home/mparillo/.ssh/known_hosts:1
<mparillo> debug1: ssh_rsa_verify: signature correct
<mparillo> debug1: SSH2_MSG_NEWKEYS sent
<mparillo> debug1: expecting SSH2_MSG_NEWKEYS
<mparillo> debug1: SSH2_MSG_NEWKEYS received
<mparillo> debug1: Roaming not allowed by server
<mparillo> debug1: SSH2_MSG_SERVICE_REQUEST sent
<mparillo> debug1: SSH2_MSG_SERVICE_ACCEPT received
<Lasall> !noppaste mparillo
<mparillo> debug1: Authentications that can continue: publickey
<ubot5> Lasall: I am only a bot, please don't think I'm intelligent :)
<mparillo> debug1: Next authentication method: publickey
<mparillo> debug1: Trying private key: /home/mparillo/.ssh/id_rsa
<mparillo> debug1: Trying private key: /home/mparillo/.ssh/id_dsa
<mparillo> debug1: Trying private key: /home/mparillo/.ssh/id_ecdsa
<mparillo> debug1: No more authentication methods to try.
<mparillo> Permission denied (publickey).
<mparillo> Couldn't read packet: Connection reset by peer
<Lasall> !nopaste mparillo
<ubot5> Lasall: I am only a bot, please don't think I'm intelligent :)
<Lasall> arg
#bzr 2012-08-23
<FourDollars> Hi, any update for lp:ubuntu/precise/totem ?
<mgz> er, and morning all
<lifeless> o/
<mgz> jam: so, what exactly is the status of handing the package importer over to l-osas?
<mgz> vincent did give a nice summary I seem to recall, but I now can't find it
<jam> mgz: a reasonable question, and I don't have a quick answer. AIUI one of the key bits to consider it transfered, is that we should not be directly connecting to jubany, even if it means we have to 'chopstick' debug (have them do something, give us the result, tell them what to do next)
<jam> mgz: the last sentence in your email doesn't make sense to me. I think you are missing a verb or something. "(I wonder if they'd find it useful)" perhaps?
<mgz> ...not even read-only? admittedly the habit of poking code locally on jubany needs to die, but there are a lot of logs and things that the web interface doesn't expose
<mgz> and requeuing packages is all done manually at the moment...
<jam> mgz: correct, we should not ssh into jubany, if we need a query run, we should ask them to run it.
<jam> just like for lp
<mgz> so, do have a list of stuff that needs doing apart from taking away our keys? the docs in branch are at least mostly updated for the chroot, and we could just get l-osas to do deployments and user requests for us
<mgz> the length of time a deployment takes is a bit painful, as stopping the package importer when it's got firefox or something in the queue isn't quick.
<idnar> is there an easier way than "bzr log -r-1 --show-ids" to get the tip revision-id?
<jelmer> idnar, bzr revision-info
<idnar> aha! thanks
<jelmer> mgz, icanhasreview?
<jelmer> mgz: I was wondering if you had a moment to look at https://code.launchpad.net/~jelmer/bzr-stats/no-get-ancestry/+merge/121017?
 * mgz goeshaslook
<mgz> ah, bzr-stats, I don't get lp mail about plugin mps
<jelmer> the test coverage isn't great, but previously this code was completely broken
<mgz> ...I didn't even type my "t...t...t...test case?" line
<mgz> which I had sitting in the buffer here for the last five minutes
 * jelmer can read minds
<jelmer> or maybe you're just predictable ;-)
<mgz> :)
<mgz> code looks good, only the middle one is actually doing anything different, right?
<jelmer> mgz: yep, should be more efficient now
<dashua> I'm a little rusty on merges.  Once my branch is approved, what is the command to merge into trunk?
<wgz> dashua: generally just, if you have a copy of trunk locally adjacent to your featur branch, `bzr merge ../feature` then `bzr push`
<wgz> some projects have fancy means of landing things with robots rather than manually though
<dashua> wgz, Ok thanks, I thought I was doing it right, but on LP the commit message usually defaults to Merge branch lp:foo
<dashua> It's not displaying a merged message
<wgz> er.. I missed the "commit" after merging, that's the message that will be shown
<wgz> the commit message in the merge proposal is for robot use, or as a hint if someone else merges your change to trunk for you
<dashua> wgz, Ok great, then LP defaults to the merged branch commit message where it links the branch and corresponding bug report?
<dashua> Ah ok
<dashua> wgz, http://img6.imagebanana.com/img/q44d8lwz/Selection_007.png
<dashua> That type of message is the one I'm missing
<dashua> Merged branch and the link to the bug report
<elmo> hi
<elmo> Uncommit these revisions? ([y]es, [n]o): yes
<elmo> bzr: ERROR: An inconsistent delta was supplied involving 'update-motd.d/00-header', '00header-20120816152510-yb60cvekto41dgii-914'
 * kirkland waves at elmo, and then ducks and covers
<vinmassaro> anyone know how to fix this under mac os 10.8.1? https://gist.github.com/35790586370836aae395
<wgz> elmo: probably bug 910002
<ubot5> Launchpad bug 910002 in Bazaar "uncommitting a dir rename causes InconsistentDelta error" [High,Confirmed] https://launchpad.net/bugs/910002
<elmo> wgz: aha, damn it
<elmo> wgz: I'm even already subscribed to that!
<elmo> wgz: thanks
<wgz> I need some spare weekends to work on bzr bugs :)
<wgz> vinmassaro: you may need to file a bug against bzr-mac-installers, or post more details to the mailing list
<wgz> none of these look directly like your issue: <https://bugs.launchpad.net/bzr-mac-installers/+bugs?field.searchtext=subvertpy>
<sixstring> I'm having trouble pulling changes from an upstream trunk into my local branch. I do "bzr pull lp:upstream-trunk" and it does stuff. However, when I do "bzr merge", it says "Nothing to do." Now, my "parent" branch is not "lp:upstream-trunk". Does that matter? If so, why? And how do I fix it?
<sixstring> BTW, hello #bzr! :)
 * sixstring has a virtual donut for the right answer.
<fullermd> Well, if merge is going from lp:upstream-trunk, of course it'll have nothing to do after you've just pulled from there.
<sixstring> fullermd, i don't understand your answer, but i'll give you credit for answering.
 * sixstring tosses fullermd a healthy virtual jelly donut.
<fullermd> Is that a donut that's healthy because it has virtual jelly, or a jelly donut that's virtually healthy?
<fullermd> Where's it trying to merge from, when you run the argless `merge` (assuming that's what you actually did)?
<sixstring> fullermd, it's as healthy as you can imagine :)
#bzr 2012-08-24
<FourDollars> Hi, any progress of the fix of lp:ubuntu/precise/totem?
<mgz> morning all!
<FourDollars> mgz: Hi, any progress of the fix about lp:ubuntu/precise/totem ?
<mgz> FourDollars: did anyone say they were working on it?
<FourDollars> mgz: No. :(
<FourDollars> However lp:ubuntu/precise-proposed/totem is already came out.
<FourDollars> The information of totem 3.0.1-0ubuntu21 is still missing.
<lifeless> FourDollars: this seems more like a #ubuntu discussion, or -perhaps- #launchpad.
<FourDollars> lifeless: I have mentioned this issue at #ubuntu-devel and cjwatson guides me here and #launchpad.
<FourDollars> I also mention this issue at #launchpad, and someone guides me here too.
<FourDollars> OK, I will try #ubuntu.
<lifeless> there are folk here that work on the importer
<lifeless> but its not a bzr project thing, its for Ubuntu.
<FourDollars> lifeless: Thanks for your information.
#bzr 2012-08-26
<fmarier> I don't understand why my push fails: http://pastebin.ubuntu.com/1167571/ Is that a locking issue on the Launchpad end? (This is a fresh checkout)
<fullermd> Permission more like, I'd say.
<fmarier> fullermd: on the launchpad side?
<fmarier> as far as i can tell, i'm in the group that owns that branch and my ssh key is in my launchpad profile, so i'm not sure why i'm not allowed to push...
<fmarier> but maybe it's more of a launchpad issue than a bzr one...
#bzr 2013-08-19
<Meatball_py> hi, I'm new to bzr, is there any way to merge a bug fix that hasn't been merged by the "official" branch. For example, https://bugs.launchpad.net/+branch/~openerp-dev/openobject-addons/7.0-bug-1156215-rha is a bug fix branch, how can I merge it on my local branch?
<ubot5> Launchpad bug 7 in Launchpad itself "Need help for novice translators" [High,Fix released]
<spiv> Meatball_py: have you tried running "bzr merge THAT_URL" in your local branch?
<spiv> Meatball_py: because that should do what you want (although note that 'bzr merge' will not commit the merge automatically; you need to run 'bzr commit' for that, just like any other edit you may make).
<Meatball_py> spiv: thanks
<andrewk> hello
<andrewk> i have installed the osx bundle for bazaar and everything is working apart from the explorer. When i enter bzr explorer into the terminal i get the following message 'bzr: ERROR: [Errno 60] Can't connect to host '192.168.1.66': Operation timed out'
<andrewk> i am not sure what ip the message is referring to as when you first launch the explorer it is just opening the application and not looking to connect to anywhere else?
<andrewk> got to go but as always i will check the irc logs for replies.
#bzr 2013-08-20
<m_tadeu> hi everyone....is there a way to revert a push?
<jelmer> m_tadeu: you can push the old tip and use --overwrite
<jelmer> sigh
<bob2_> hah
<Marqin> hi, i've found some old bzr repo.. how can i check from where is it pulling without pulling??
<jelmer> Marqin: bzr info
<Marqin> thx
<junrrein> Hi people, I got a question. How can I configure the default text editor (under Linux)? I tried "bzr config editor=gedit" but when running bzr commit, nano is still used instead.
<junrrein> I found out, thanks
<mgz> setting EDITOR works, as should that config command
<kolbe> is there some way to branch/checkout only a single file (or directory, or something) from a tree? so that i can keep that file in sync with the file in the tree without having to branch the entire thing?
<rozzin> kolbe: "bzr export"?
<kolbe> hmmm i don't see how that would help?
<rozzin> I think it lets you export a subdiretory.
<kolbe> i just want to grab http://bazaar.launchpad.net/~maria-captains/maria/5.5-noga-hf/files/head:/plugin/server_audit/
<kolbe> well in order to export a subdirectory i would have to first branch the entire repository, which is exactly what i am trying to avoid
<kolbe> i have a feeling this is not possible with bzr
<rozzin> kolbe: I don't think that's true.
<kolbe> you don't think what is true?
<rozzin> kolbe: I think you can export directly from a remote repository.
<kolbe> rozzin: hm ok i'll try
<rozzin> kolbe: You can also do lightweight checkouts.
<kolbe> *ideally* i'd like to be able to see version history for just things in this directory and be able to bzr pull to update files in it
<rozzin> kolbe: ... which avoids downloading all of the history, and just downloads the current revision.
<kolbe> rozzin: ok neat, export did work, in that it allowed me to grab just that directory but of course it doesn't have any revision info and i can't bzr pull inside of it to update things
<rozzin> Yeah, that's just not how it works--you can't separate out `just the history for this subdirectory'. History isn't tracked like that; there's not a history-per-file like CVS or ClearCase.
<kolbe> yeah
<rozzin> Changesets that can span multiple files are `inside' revisions, not the other way around.
<kolbe> i think bzr doesn't match up very well with how my brain wants to do things, i feel like everything i do is an epic struggle that just ends with me kind of tired and frustrated
<rozzin> What's your frame of reference?
<rozzin> i.e.: what system are you coming from?
<kolbe> no frame of reference, just trying to do certain things that are apparently impossible with bzr
<rozzin> Like?
<kolbe> two major frustrations so far are how absurdly slow it is to branch a large tree
<kolbe> and that if my internet connection is interrupted in the middle of that it's impossible to resume
<rozzin> kolbe: You've never used another version control system before?
<kolbe> rozzin: no, not really
<rozzin> On the up side, once you go through that huge download, you never have to do it again.
<kolbe> right
<kolbe> until i go set up some ec2 instance or some other VM that i want to use for building things and i end up having to branch it again :)
<rozzin> You can avoid the big initial hump, if you want, at the expensive of repeatedly paying it in small increments.
<rozzin> kolbe: No.
<rozzin> kolbe: I'm serious: once you get the data into your shared repository, you never need to download it again.
<kolbe> rozzin: if i want to set up an environment on some other machine, i either have to manually copy my own shared repository there or i have to branch again
<rozzin> Well, yeah. If you want to copy the data to another machine, then you have to copy the data to the other machine. :)
<kolbe> i don't want to copy it, i want to be able to set up a new branch without it taking an hour and without me having to copy anything around on my own ;)
<rozzin> Then do a lightweight checkout.
<kolbe> but then i don't get revision history?
<kolbe> i'm just whining now, don't mind me :)
<rozzin> Dude--you can't have it both ways.
<rozzin> Either you want to copy the data, or you don't.
<rozzin> lightweight checkout `gives you access to the revision history', it just doesn't give you /local/ access to it. It all says remote, which is why the intial action is so much quicker.
<rozzin> it all _stays_ remote, rather.
<rozzin> You can also use a stacked branch.
<rozzin> Thay might be more like what you're looking for.
<rozzin> All of the original revision-history data stays remote, but additional revisions that you add onto that are local.
<kolbe> rozzin: i think it's mostly frustrating that the branching operation requires so much processing instead of being able to just grab a snapshot of the historical information and download it in a big chunk
<rozzin> kolbe: You can always start with a lightweight checkout and then `reconfigure' it into a full branch in the background.
<kolbe> yeah? how do i do that?
<rozzin> I think it's something like: bzr checkout --lightweigth foo bar; bzr reconfigure --tree bar &
<kolbe> neato, maybe i'll try that sometime
<kolbe> thanks!
<rozzin> I mean, you'd really want to run the `reconfigure' in another xterm or screen session or something; you wouldn't actually want to background it, because it'll keep printing stuff out....
<kolbe> yeah
<rozzin> Also, I didn't think there was really that much processing overhead involved in downloading the revision history--isn't it really mostly just the cost of downloading the data?
<rozzin> e.g.: if you have 50 MB of data that you want to download, you have to download 50 MB of data.
<rozzin> ?
<rozzin> I know you were hoping that you could say `just download the 10 MB of history relevant to this subtree'....
<kolbe> it seems to be much more than that
<rozzin> Have you tried just transferring the repository with scp or `ssh ... tar -c ...', and comparing times?
#bzr 2013-08-21
<ovnicraft> hello i have 2 branches what are different so i want to move a directory from branch A to branch B there is any way to do it w/o lost commits ?
<vexo> Hmm, he left, but I think the cleanest solution would probably be fast-export | fast-import-filter | fast-import ?
<rozzin> Or split + join.
<rozzin> Or replay.
<rozzin> Maybe?
<rozzin> Not enough context in the question; I'm not sure what he meant by "different".
<jelmer> rozzin: just merge and mv should work
<vexo> Well, I think the idea was that he didn't want everything else in the 2nd branch, just the one folder
#bzr 2013-08-22
<jelmer> vexo: sure, but you can merge a single directory from a branch
<jelmer> (you'll get the full history from the branch but just the directory you specified)
<vexo> Mmmm, I just tested it, and when merging just a subdirectory (bzr merge other/dir -r0..-1), you don't get the history
<jelmer> vexo: hmm, I wonder if that is a recent change in behaviour
<jelmer> vexo: the other alternative is to merge the full branch and then remove the files you're not interested in
<vexo> Well, yes, that'd obviously always work ;)
<vexo> That could potentially be a large amount of overhead, though, so not necessarily ideal if you really only wanted just the one folder
<rozzin> Such concern about subdirectories. svn really broke people ;)
<bob2> heh
<ok259> I'm using bzr-svn and when I try to bzr commit my changes to the SVN trunk, I get the following error "bzr: ERROR: This operation requires storing bzr-svn metadata in Subversion file properties. These file properties may cause spurious conflicts for other Subversion users during merges. To allow this, set `allow_metadata_in_file_properties = True` in your configuration and try again." I do not want any of my bzr metadata to be visible to other users of th
<ok259> e repository. Is there a way for me to still commit my changes?
<ok259> Ah, I'm so stupid. --lossy is what I need. My apologies.
<janos> hi jelmer, you around?
<janos> jelmer: I just wanted to say thanks for the tweet last week, I appreciate the support
<jelmer> janos: no problem :-)
<janos> jelmer, another thing, the publisher is looking for technical reviewers
<janos> do you know anyone who might be interested? (yourself included!)
<jelmer> janos: sure, I would be happy to do some reviewing - perhaps a chapter or two
<jelmer> janos: some of the other core committers might also be good candidates
<janos> jelmer, great! I'll look them up
#bzr 2013-08-23
<rozzin> Hrm. I sent a message to the bazaar mailing-list a few days ago just before confirming my membership, and it appears to still be stuck in moderation.
<rozzin> Does anyone here have the ability to unfreeze it?
<jelmer> rozzin: see the https://lists.ubuntu.com/mailman/listinfo/bazaar footer - either jam or vila should be able to approve messages in moderation
<jelmer> jam: ^
<rozzin> jelmer: Ah. Thanks.
#bzr 2013-08-24
<jam> rozzin: I don't have the actual password anymore, I could dig through it all with our sysadmins, but if you just send it again once you've confirmed the new one will go through.
#bzr 2013-08-25
<Soroush731> join #wirelessarmy
#bzr 2014-08-20
<kzard> Hi. Is there any place I can look for a bzr 2.6.0 windows installer?
<jelmer> kzard: I don't think there is one for 2.6.0 yet
<jelmer> kzard: 2.6 doesn't have a lot of changes compared to 2.5.x though
<jelmer> kzard: is there a specific feature from 2.6 you need?
<kzard> I'm having an issue with Bazaar Explorer, and thought that the newer version might fix it
<kzard> I installed he newer version of bazaar explorer and it didn't have the extra tools menu I was expecting though
<kzard> anyway, I'm getting "Could not acquire lock. Please retry later." on prettymuch anything I try do in bazaar explorer
<kzard> while the command-line tool seems to work fine
<kzard> For example, I open my local copy of our trunk branch, and click "Log". The log opens fine. I then click "cancel", and bzr explorer hangs and after a few seconds displays that error message.
<kzard> * "close"
<jelmer> kzard: bzr-explorer hasn't changed since august 2012
<kzard> okay
<kzard> ah yes, I see
<kzard> jelmer, any ide3a on what could cause it to report a lock?
<kzard> or how I could fix it?
<jelmer> kzard: sorry, it's been years since I've looked at this code
<kzard> okay
<kzard> what would be a good place to as kfor help?
<jelmer> kzard: for bugs, please report them in the bug tracker for bzr-explorer
<jelmer> kzard: for general help on hacking on bzr-explorer/qbzr, this channel or the bzr mailing list are the best places to ask
<kzard> eh kay
<kzard> * okay
<kzard> I'll ask around a bit more then. I don't know it's a bug yet
#bzr 2014-08-21
<kzard> Hi
<kzard> I need help with bzr on windows
<kzard> Any action I perform using bazaar explorer gives the error message "Could not acquire lock. Please try again later"
<kzard> This does not happen when I use the command line utility
<kzard> It happens for any local / remote branch
<kzard> For example: Open bzr explorer > Select trunk branch > Log  >>> Log displays fine
<kzard> Click "close"
<kzard> bzrw freezes and after a few seconds I get a popup message "Could not acquire lock. Please try again later"
<kzard> *please retry later"
<kzard> any ideas on how I can try to solve this would be appreceated :)
<kzard> or where to look for help
<jelmer> hi kzard
<kzard> hi jelmer :)
<jelmer> kzard: as mentioned yesterday, I would suggest writing to the mailing list
<kzard> blhe
<kzard> * bleh
<jelmer> ?
<kzard> I'm on the verge of just removing any trace of bzr from my pc +_+
<kzard> * local version of "meh"
<kzard> and installing it again
<mbruzek> Hello bzr, I created a branch by accident and it is not needed is there a way for me to delete it from launchpad/bazaar ?
<beuno> mbruzek, sure, there's a delete button in the web UI
<mbruzek> beuno, I did not know that.
<mbruzek> beuno, thank you.
<beuno> np
<mbruzek> Is there a way to do that with a bzr command (just curious, I *just* deleted it)
<mbruzek> ?
<beuno> mbruzek, not that I know of, no
<mbruzek> Thanks again beuno.
#bzr 2014-08-24
<mark06> is there anyway to know if a branch has some uncommitted commit? maybe inspecting .bzr manually?
<lifeless> mark06: bzr heads perhaps?
<mark06> just tested, only one listed for a branch I know it does have uncommits
<lifeless> did you use --all ?
<mark06> ok I read help, --dead-only looks better, thanks :)
<mark06> hi, is it possible to amend a commit to add a forgotten --fixes?
#bzr 2015-08-18
<apuimedo> Hi all
<apuimedo> anybody ever run into
<apuimedo> http://paste.ubuntu.com/12114928/
<apuimedo> https://answers.launchpad.net/launchpad/+question/269816
<apuimedo> bazaar.launchpad.net should really get an ssh upgrade
<apuimedo> in the meantime
<apuimedo> Host bazaar.launchpad.net
<apuimedo>     KexAlgorithms +diffie-hellman-group1-sha1
<apuimedo> in your ~/.ssh/config
<hloeung> apuimedo: there's a bug filed for that (but seems marked as private right now)
<hloeung> (filed against Launchpad)
<hloeung> apuimedo: https://bugs.launchpad.net/launchpad/+bug/1445619 - it's public now
<ubot5> Ubuntu bug 1445619 in Launchpad itself "Launchpad should support SHA2" [High,Triaged]
<apuimedo> thanks hloeung
#bzr 2015-08-22
<rwilbur> How do I get the bazaar homepage (http://bazaar.canonical.com/en/) to rebuild from a new version of lp:bzr-website?
#bzr 2016-08-22
<fullermd> If I were to install Explorer on a Windows system without any other particular setup, what ssh implementation would it wind up using?
#bzr 2016-08-23
<jgdx> hey, any way to get bzr to sign commits using gpg2?
<jgdx> yes, gpg_signing_command = /usr/bin/gpg2. Awesome.
<jgdx> maybe have that as default on yakkety, since gpg seems to be left for dead by gpg-agent
#bzr 2016-08-25
<josharenson> Is there a way to diff against a shelve?
<josharenson> got it... `bzr unshelve --preview`
#bzr 2017-08-25
<throstur> how do I reduce the size of bzr repository packs? It's using like 1G of disk space
<throstur> I ran bzr pack and it increased the size from 1G to 1.9G -.-
<Peng> It saves backups
<Peng> The working set of data is smaller (one hopes) but after "bzr pack" there's a backup of the entire repository
<Peng> in .bzr/repository/obsolete_packs/
<Peng> You can use "bzr pack --clean-obsolete-packs" to remove them
